Evaluation analytique de la précision des systèmes en virgule fixe pour des applications de communication numérique - thèse Informatique - Revenir à l'accueil

 APISENSE-a-distribut..> 04-Jan-2015 21:51  5.7M  

 APISENSE-terminaux-i..> 04-Jan-2015 21:53  5.4M  

 Addition-formulae-on..> 04-Jan-2015 21:26  3.0M  

 Classification-et-ca..> 04-Jan-2015 11:58  1.3M  

 Collaboration-de-tec..> 04-Jan-2015 21:27  2.4M  

 Contributions-a-la-v..> 04-Jan-2015 21:51  5.4M  

 Equilibrage-de-charg..> 04-Jan-2015 21:25  3.2M  

 Faciliter-le-develop..> 04-Jan-2015 21:56  4.4M  

 Factorisation-matric..> 04-Jan-2015 11:59  2.7M  

 Generation-automatiq..> 03-Jan-2015 22:04  2.6M  

 Gestion-de-la-variab..> 04-Jan-2015 21:55  4.8M  

 Idéalisation-d-asse..> 04-Jan-2015 11:57  2.1M  

 Inference-d-invarian..> 04-Jan-2015 11:58  1.5M  

 Integration-de l-inf..> 04-Jan-2015 21:25  3.4M  

 Interrogation-de-gra..> 03-Jan-2015 22:04  2.9M  

 La-gestion-du-trafic..> 03-Jan-2015 22:01  4.1M  

 Langage-de-mashup-Th..> 04-Jan-2015 21:24  4.1M  

 Les-logiciels-de-ges..> 03-Jan-2015 22:03  3.1M  

 Lh-rs-p2p-une-nouvel..> 04-Jan-2015 11:59  2.7M  

 Mesure-de-la-fragili..> 04-Jan-2015 21:24  3.8M  

 Meta-modelisation-du..> 04-Jan-2015 21:56  4.1M  

 Methode-de-classific..> 04-Jan-2015 11:58  1.3M  

 Methodes-sequentiell..> 04-Jan-2015 21:27  2.2M  

 Mise-en-oeuvre-appli..> 04-Jan-2015 21:54  4.4M  

 Modelisation-d-une-a..> 04-Jan-2015 21:53  5.0M  

 Modelisation-et-dete..> 04-Jan-2015 11:57  1.6M  

 Normalisation-et-App..> 03-Jan-2015 22:01  4.1M  

 Prise-en-compte-de-l..> 03-Jan-2015 22:04  2.8M  

 Qualification-system..> 04-Jan-2015 21:26  2.8M  

 Reconnaissance-de-co..> 03-Jan-2015 22:03  3.6M  

 Segmentation-supervi..> 04-Jan-2015 11:58  1.3M  

 Services-de-repartit..> 03-Jan-2015 21:59  4.7M  

 Techniques-visuelles..> 04-Jan-2015 21:27  2.7M  

 The-Emergence-of-Mul..> 03-Jan-2015 22:05  2.5M  

 Trigraphes-de-Berge-..> 03-Jan-2015 22:02  3.9M   

Vers-une-capitalisat..> 03-Jan-2015 22:00 4.6M 

 Application-Agnostic..> 03-Jan-2015 21:16  2.1M  

 Continuity-Editing-f..> 03-Jan-2015 17:35  4.0M  

 Double-WP-Vers-une-p..> 03-Jan-2015 17:36  4.0M  

 Effective-Reproducib..> 03-Jan-2015 21:18  2.0M  

 Enforcing-reuse-and-..> 03-Jan-2015 21:17  2.0M  

 Extracting-Bounded-s..> 03-Jan-2015 21:19  4.0M  

 Fingerprint-Quality-..> 03-Jan-2015 21:16  2.1M  

 GPU-Load-Balance-Gui..> 03-Jan-2015 21:18  4.0M  

 Minkowski-sum-of-pol..> 03-Jan-2015 21:17  2.0M  

 Quality-Assessment-o..> 03-Jan-2015 21:16  2.1M  

 Rester-statique-pour..> 03-Jan-2015 17:35  4.0M  

 The-Power-of-Polynom..> 03-Jan-2015 21:16  2.1M  

 Analyse-numerique-Co..> 03-Jan-2015 17:33  3.0M  

 Approches-m-k-firm-p..> 03-Jan-2015 17:27  3.7M  

 COURS-LA-CULTURE-INF..> 03-Jan-2015 17:25  3.8M  

 CRYPTANALYSE-DE-RSA-..> 03-Jan-2015 17:33  3.0M  

 Cours-Interconnexion..> 03-Jan-2015 17:34  3.0M  

 Cours-d-Analyse-et-C..> 03-Jan-2015 17:22  3.9M  

 Efficient-C++finite-..> 03-Jan-2015 17:30  3.5M  

 Efficient-C++finite-..> 03-Jan-2015 17:31  3.2M  

 Fondements-de-l-Info..> 03-Jan-2015 17:22  4.0M  

 INTRODUCTION-A-L-INF..> 03-Jan-2015 17:24  3.8M  

 Informatique-et-Ling..> 03-Jan-2015 17:24  3.8M  

 Initiation-a-l-infor..> 03-Jan-2015 17:26  3.8M  

 Intelligence-Artific..> 03-Jan-2015 15:16  2.5M  

 Introduction-a-l-ana..> 03-Jan-2015 17:27  3.7M  

 Introduction-a-la-ge..> 03-Jan-2015 17:26  3.8M  

 Le-routage-externe-B..> 03-Jan-2015 17:32  3.1M  

 Le-systeme-d-informa..> 03-Jan-2015 17:32  3.1M  

 Lecture1_Linear_SVM_..> 03-Jan-2015 14:57  2.4M  

 Lecture2_Linear_SVM_..> 03-Jan-2015 14:56  2.4M  

 Lecture3_Linear_SVM_..> 03-Jan-2015 14:56  2.4M  

 Lecture4_Kenrels_Fun..> 03-Jan-2015 14:55  2.4M  

 Lecture5_Kernel_SVM...> 03-Jan-2015 14:55  2.4M  

 Lecture6_SVDD.pdf.htm   03-Jan-2015 14:54  2.4M  

 Lecture7_Cross_Valid..> 03-Jan-2015 14:54  2.4M  

 Lecture8_Multi_Class..> 03-Jan-2015 14:57  2.4M  

 Lecture9_Multi_Kerne..> 03-Jan-2015 14:53  2.5M  

 Lecture10_Outilier_L..> 03-Jan-2015 14:53  2.5M  

 Les-reseaux-sans-fil..> 03-Jan-2015 15:17  2.5M  

 NooJ-pour-l-Intellig..> 03-Jan-2015 17:30  3.2M  

 Outils-Logiques-pour..> 03-Jan-2015 15:15  2.8M  

 Presentation-de-la-r..> 03-Jan-2015 17:33  3.0M  

 Projet-IP-SIG-Signal..> 03-Jan-2015 15:16  2.5M  

 Robotique-Mobile-PDF..> 03-Jan-2015 15:16  2.6M  

 Systeme-informatique..> 03-Jan-2015 15:17  2.5M  

 Systemes-Multi-Agent..> 03-Jan-2015 17:28  3.5M  

 Tutoriel-Android-TP-..> 03-Jan-2015 14:57  2.3M  

 Understanding-SVM-th..> 03-Jan-2015 14:57  2.4M  

 Une-histoire-de-la-m..> 03-Jan-2015 17:28  3.5M  

 Une-introduction-aux..> 03-Jan-2015 17:31  3.1M  

 Vers-une-signalisati..> 03-Jan-2015 17:25  3.8M 

HAL Id: tel-01097176 https://hal.inria.fr/tel-01097176 Submitted on 19 Dec 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.ANNÉE 2014 THÈSE / UNIVERSITÉ DE RENNES 1 sous le sceau de l’Université Européenne de Bretagne pour le grade de DOCTEUR DE L’UNIVERSITÉ DE RENNES 1 Mention : TRAITEMENT DU SIGNAL ET TÉLÉCOMMUNICATION Ecole doctorale MATISSE présentée par Aymen CHAKHARI préparée à l’unité de recherche CAIRN, IRISA, INRIA INSTITUT NATIONALE DE RECHERCHE EN INFORMATIQUE ET AUTOMATIQUE ENSSAT LANNION Evaluation analytique de la précision des systèmes en virgule fixe pour des applications de communication numérique Thèse à soutenir à Lannion le 7 Octobre 2014 devant le jury composé de : Kosai RAOOF Professeur, ENSIM Le Mans / rapporteur Christophe JEGO Professeur, ENSEIRB Bordeaux / rapporteur Meriem JAIDANE Professeur, U2S, ENIT Tunis / examinateur Daniel MENARD Professeur, IETR INSA Rennes / examinateur Pascal SCALART Professeur, ENSSAT Lannion / directeur de thèse Romuald ROCHER Maître de conférences, IRISA / co-directeur de thèse2Résumé Lors de la conception d’applications de traitement de signal, la démarche classique conduit le concepteur d’applications à utiliser dans un premier temps une arithmétique en virgule flottante pour éviter les problèmes liés à la précision des calculs. Cependant, l’implémentation de ces applications nécessite l’utilisation de l’arithmétique virgule fixe puisqu’elle est plus avantageuse en termes de contraintes de coût et de consommation. Par conséquent l’application conçue en arithmétique virgule flottante doit être convertie en arithmétique virgule fixe. Cette opération de conversion se révèle être fastidieuse, aussi des outils de conversion automatique de l’arithmétique virgule flottante vers celle en virgule fixe ont été mis en place afin de répondre aux exigences de temps de mise sur le marché de ces applications. Au sein de ce processus de conversion, l’une des étapes primordiales concerne l’évaluation de la précision de la spécification en virgule fixe. En effet, le changement du format des données de l’application s’effectue en éliminant des bits. Cette conversion conduit à la génération de bruits de quantification qui se propagent au sein du système et dégradent la précision des calculs en sortie de l’application. Par conséquent, cet abaissement dans la précision de calcul doit être maitrisé et évalué pour garantir l’intégrité de l’algorithme et répondre aux spécifications initiales de l’application. Traditionnellement, l’évaluation de la précision s’effectue par le biais de deux approches différentes. La première approche consiste à réaliser des simulations en virgule fixe de l’application afin d’en estimer ses performances. Ces approches basées sur la simulation nécessitent de grandes capacités de calculs et conduisent à des temps d’évaluation prohibitifs. Pour éviter ce problème, le travail mené dans le cadre de cette thèse se concentre sur des approches basées sur l’évaluation de la précision à travers des modèles analytiques. Ces modèles décrivent le comportement du système à travers des expressions analytiques qui permettent d’évaluer une métrique de précision bien définie. Plusieurs modèles analytiques ont été proposés pour évaluer la précision en virgule fixe des systèmes linéaires invariants dans le temps LTI (Linear Time Invariant) et des systèmes linéaires non-LTI non récursifs et récursifs. L’objectif de cette thèse est de proposer des modèles analytiques permettant l’évaluation de la précision des systèmes de communications numériques et des algorithmes de traitement numérique de signal formés d’opérateurs non lisses et non linéaires en terme du bruit. Dans un premier temps, des modèles analytiques pour l’évaluation de la précision des opérateurs de décision et leurs cascades et itérations sont proposés. Dans une seconde étape, une optimisation des largeurs de données est proposée pour l’implémentation matérielle en virgule fixe de l’égaliseur à retour de décision DFE (Decision Feedback Equalizer) en se basant sur les modèles analytiques proposés ainsi que pour les algorithmes de décodage itératif du type turbo-décodage et décodage-LDPC (Low-Density Parity-Check) selon une loi se quantification particulière. Le premier aspect de ce travail concerne la proposition de modèles analytiques pour l’évaluation de la précision des opérateurs non lisses de décision et de la cascade des opérateurs de décision. Par conséquent, la caractérisation de la propagation des erreurs de quantification dans la cascade d’opérateurs de décision est le fondement des modèles analytiques proposés. Ces modèles sont appliqués dans une seconde étape pour l’évaluation de la précision de l’algorithme de décodage sphérique SSFE (Selective Spanning with Fast Enumeration) utilisé pour les systèmes de transmission de type MIMO (Multiple-Input Multiple-Output). Dans une seconde étape, l’évaluation de la précision des structures itératives d’opérateurs de décision a fait l’objet d’intérêt. Une caractérisation des erreurs de quantification engendrées par l’utilisation de l’arithmétique en virgule fixe est introduite pour aboutir à des modèles analytiques permettant l’évaluation de la précision des applications de traitement numérique de signal incluant des structures itératives de décision. Une deuxième approche, basée sur l’estimation d’une borne supérieure de la probabilité d’erreur de décision dans le mode de convergence, est proposée pour l’évaluation de la précision de ces applications et ceci dans un but de réduire les temps d’évaluation. Ces modèles sont appliqués à la problématique de l’évaluation de la spécification virgule fixe de l’égaliseur à retour de décision DFE. Une extension de ces modèles est introduite pour l’évaluation du DFE dans sa version adaptative. Le second aspect de notre travail s’articule autour de l’optimisation des largeurs de données en virgule fixe. Ce processus d’optimisation est basé sur la minimisation de la probabilité d’erreur de décision dans le cadre d’une implémentation sur un FPGA (Field-Programmable Gate Array) de l’algorithme DFE complexe sous contrainte d’une précision donnée. Par conséquent, pour chaque spécification en virgule fixe, la précision est évaluée à travers les modèles analytiques proposés. L’estimation de la consommation des ressources et de la puissance sur le FPGA est ensuite obtenue à l’aide des outils de Xilinx pour faire un choix adéquat des largeurs des données en visant à un compromis précision/coût.La dernière étape de notre travail concerne la modélisation en virgule fixe des algorithmes de décodage itératif. Une modélisation de l’algorithme de turbo-décodage et du décodage LDPC est ensuite proposée. Cette approche intègre la structure particulière de ces algorithmes ce qui implique que les quantités calculées au sein du décodeur ainsi que les opérations, sont quantifiées suivant une approche itérative. De plus, la représentation en virgule fixe utilisée est différente de la représentation classique utilisant le nombre de bits accordé à la partie entière et la partie fractionnaire. L’approche proposée repose sur le couple dynamique et le nombre de bits total. De plus le choix de la dynamique engendre davantage de flexibilité pour les modèles en virgule fixe puisqu’elle n’est plus limitée uniquement à une puissance de deux. Dans une seconde étape, la réduction de la taille des mémoires par des techniques de saturation et de troncature est proposée afin d’être en mesure de cibler des architectures à faible-complexité. Finalement, l’analyse des performances en virgule fixe est faite à travers l’évaluation du taux d’erreur par paquet FER (Frame Error Ratio) en fonction du SNR (Signal to Noise Ratio).5Abstract In designing applications of signal processing, the traditional approach leads the designer of applications to use initially floating point arithmetic in order to avoid problems related to the accuracy of calculations. However, the implementation of these applications requires the use of fixed-point arithmetic because it is more advantageous in terms of constraints of cost and consumption. Therefore, the designed application in floating point arithmetic must be converted to fixed-point arithmetic. This conversion is tedious, so tools for automatic conversion of floating-point arithmetic to the fixed point were established to meet the requirements of time-to-market of these applications. In this conversion process, one of the basic steps concerns the evaluation of the accuracy of the fixed-point specification. Indeed, the change of the data format of the application is performed by removing bits. This conversion results in the generation of quantization noise propagating within the system and degrading the accuracy of calculations of the application output. Therefore, this reduction in the calculation accuracy must be mastered and evaluated in order to ensure the integrity of the algorithm and meet the initial requirements of the application. Traditionally, evaluation of accuracy is performed through two different approaches. The first approach is to perform simulations fixed-point implementation in order to assess its performance. These approaches based on simulation require large computing capacities and lead to prohibitive time evaluation. To avoid this problem, the work done in this thesis focuses on approaches based on the accuracy evaluation through analytical models. These models describe the behavior of the system through analytical expressions that evaluate a defined metric of precision. Several analytical models have been proposed to evaluate the fixedpoint accuracy of Linear Time Invariant systems (LTI) and of non-LTI non-recursive and recursive linear systems. The objective of this thesis is to propose analytical models to evaluate the accuracy of digital communications systems and algorithms of digital signal processing made up of non-smooth and non-linear operators in terms of noise. In a first step, analytical models for evaluation of the accuracy of decision operators and their iterations and cascades are provided. In a second step, an optimization of the data length is given for fixed-point hardware implementation of the Decision Feedback Equalizer DFE based on analytical models proposed and for iterative decoding algorithms such as turbo decoding and LDPC decoding-(Low-Density Parity-Check) in a particular quantization law. The first aspect of this work concerns the proposition analytical models for evaluating the accuracy of the non-smooth decision operators and the cascading of decision operators. So, the characterization of the quantization errors propagation in the cascade of decision operators is the basis of the proposed analytical models. These models are applied in a second step to evaluate the accuracy of the spherical decoding algorithm SSFE (Selective Spanning with Fast Enumeration) used for transmission MIMO systems (MultipleInput Multiple - Output). In a second step, the accuracy evaluation of the iterative structures of decision operators has been the interesting subject. Characterization of quantization errors caused by the use of fixed-point arithmetic is introduced to result in analytical models to evaluate the accuracy of application of digital signal processing including iterative structures of decision. A second approach, based on the estimation of an upper bound of the decision error probability in the convergence mode, is proposed for evaluating the accuracy of these applications in order to reduce the evaluation time. These models are applied to the problem of evaluating the fixed-point specification of the Decision Feedback Equalizer DFE. An extension of these models is introduced for the evaluation of DFE in its adaptive version. The second aspect of our work focuses on the optimization of fixed-point data widths. This optimization process is based on minimizing the decision error probability through the implementation on an FPGA (Field-Programmable Gate Array) of the complex DFE algorithm under the constraint of a given accuracy. Therefore, for each fixed-point specification, accuracy is evaluated through the proposed analytical models. The estimation of resources and power consumption on the FPGA is then obtained using the Xilinx tools to make a proper choice of the data widths aiming to a compromise accuracy/cost. The last step of our work concerns the fixed-point modeling of iterative decoding algorithms. A model of the turbo decoding algorithm and the LDPC decoding is then given. This approach integrates the particular structure of these algorithms which implies that the calculated quantities in the decoder and the operations are quantified following an iterative approach. Furthermore, the used fixed-point representation is different from the conventional representation using the number of bits accorded to the integer part and the fractional part. The proposed approach is based on the dynamic and the total number of bits. Besides, the dynamic choice causes more flexibility for fixed-point models since it is not limited to only a power oftwo. In a second step, the memory size reduction using saturation and truncation techniques is given in order to be able to target low - complexity architectures. Finally, the fixed-point performance analysis is done through the evaluation of Frame Error Ratio FER versus SNR (Signal to Noise Ratio) package.8Table des matières Introduction 1 Contexte de l’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Problématique de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Organisation de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1 Arithmétique virgule fixe 9 1.1 Les différents types de formats de données . . . . . . . . . . . . . . . . . . . . . . . 10 1.1.1 Représentation des nombres entiers . . . . . . . . . . . . . . . . . . . . . . . 11 1.1.2 Le format virgule fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.1.3 Le format virgule flottante . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.1.4 Comparaison arithmétiques virgule flottante et virgule fixe . . . . . . . . . 14 1.2 Modélisation du bruit de quantification . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2.1 Processus de quantification . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2.2 Signal à amplitude continue . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.2.3 Signal à amplitude discrète . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.3 Évaluation de la précision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 1.3.1 Les métriques de précision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.3.2 Les méthodes d’évaluation de la précision par simulation . . . . . . . . . . . 29 1.3.3 Les approches analytiques de l’évaluation de la précision . . . . . . . . . . . 32 1.3.4 Autres effets de la quantification . . . . . . . . . . . . . . . . . . . . . . . . 38 1.3.5 Bilan des deux approches . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 1.3.6 Les approches hybrides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2 Évaluation analytique de la précision des algorithmes de décodage sphérique 41 2.1 Les opérateurs lisses et non lisses . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.1.2 Les opérateurs lisses et non-lisses . . . . . . . . . . . . . . . . . . . . . . . . 43 2.1.3 La quantification d’un opérateur non lisse . . . . . . . . . . . . . . . . . . . 44 2.1.4 Identification d’un opérateur non lisse . . . . . . . . . . . . . . . . . . . . . 44 2.2 Modèle analytique pour l’opérateur de décision . . . . . . . . . . . . . . . . . . . . 47 2.2.1 Modélisation de l’opérateur de décision . . . . . . . . . . . . . . . . . . . . 47 2.2.2 La réponse à la perturbation . . . . . . . . . . . . . . . . . . . . . . . . . . 49 2.2.3 La probabilité d’erreur de décision . . . . . . . . . . . . . . . . . . . . . . . 50 2.3 Cascade d’opérateurs de décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.3.1 Propagation de l’erreur de quantification . . . . . . . . . . . . . . . . . . . . 55 2.3.2 Détermination analytique de la probabilité d’erreur en sortie de la cascade . 56 2.3.3 Analyse de la complexité du modèle analytique . . . . . . . . . . . . . . . . 59 2.4 Application du modèle à l’algorithme SSFE . . . . . . . . . . . . . . . . . . . . . . 60 2.4.1 Modèle du système MIMO . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 12.4.2 Présentation de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.4.3 Application du modèle analytique proposé . . . . . . . . . . . . . . . . . . . 64 2.4.4 Première approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 3 Évaluation de la précision de l’itération d’opérateur de décision 79 3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.1.1 Caractéristiques de la propagation du bruit . . . . . . . . . . . . . . . . . . 80 3.2 Modèle analytique proposé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.2.1 Approche basée sur la résolution d’un système non linéaire à l’aide de l’algorithme de Newton-Raphson . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.2.2 Borne supérieure de la probabilité d’erreur . . . . . . . . . . . . . . . . . . 85 3.3 Évaluation de la précision de l’égaliseur à retour de décision . . . . . . . . . . . . . 88 3.3.1 Présentation de l’algorithme DFE . . . . . . . . . . . . . . . . . . . . . . . 88 3.3.2 Résultat pour le cas non adaptatif . . . . . . . . . . . . . . . . . . . . . . . 89 3.3.3 Solution proposée pour le cas adaptatif . . . . . . . . . . . . . . . . . . . . 90 3.4 Optimisation du format virgule fixe pour l’implémentation matérielle . . . . . . . . 94 3.4.1 Présentation de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 94 3.4.2 Implémentation sur FPGA . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.4.3 Les contraintes du choix du format de représentation . . . . . . . . . . . . . 97 3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4 Évaluation de la précision du turbo décodage 103 4.1 L’optimisation de la largeur des données en virgule fixe . . . . . . . . . . . . . . . 104 4.1.1 Variantes du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.1.2 Variable d’optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 4.1.3 Solution au problème d’optimisation de la longueur du mot de code . . . . 106 4.2 Optimisation du turbo décodage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.2.1 Présentation de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.2.2 Modélisation et design en virgule fixe . . . . . . . . . . . . . . . . . . . . . 111 4.2.3 Réduction de la taille de mémoire . . . . . . . . . . . . . . . . . . . . . . . 114 4.2.4 Performance du turbo décodeur . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.3 Optimisation du décodage LDPC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.3.1 Modélisation et design en virgule fixe d’un décodeur LDPC . . . . . . . . . 122 4.3.2 Réduction de la taille de mémoire . . . . . . . . . . . . . . . . . . . . . . . 124 4.3.3 Performance en virgule fixe du décodeur LDPC . . . . . . . . . . . . . . . . 124 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Conclusion et Perspectives 127 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 A Quantification uniforme et quantification double 129 A.1 Quantification uniforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 A.1.1 Quantification dans le domaine de la fonction caractéristique . . . . . . . . 129 A.2 La quantification double . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 B La méthode de Newton-Raphson pour la résolution des systèmes non linéaires133 B.1 Les systèmes non linéaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 2Table des figures 1 Cycle de conception d’une application de traitement numérique de signal . . . . . . 2 2 Les étapes d’implémentation en virgule fixe . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Représentation des données en virgule fixe . . . . . . . . . . . . . . . . . . . . . . . 12 1.2 Représentation des données en virgule flottante . . . . . . . . . . . . . . . . . . . . 13 1.3 Comparaison de l’évolution du niveau de la dynamique pour les représentations virgule fixe et virgule flottante . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.4 Effet du débordement utilisant la technique de l’enveloppe autour de la valeur . . . 16 1.5 Effet du débordement utilisant la technique de saturation . . . . . . . . . . . . . . 16 1.6 Processus de quantification par arrondi . . . . . . . . . . . . . . . . . . . . . . . . . 21 1.7 Processus de quantification par troncature . . . . . . . . . . . . . . . . . . . . . . . 22 1.8 Modélisation de bruit de quantification additif . . . . . . . . . . . . . . . . . . . . 23 1.9 Densité de probabilité de la loi de troncature continue . . . . . . . . . . . . . . . . 23 1.10 Densité de probabilité de la loi d’arrondi continu . . . . . . . . . . . . . . . . . . . 24 1.11 Densité de probabilité de la loi de troncature discrète . . . . . . . . . . . . . . . . . 26 1.12 Densité de probabilité de la loi d’arrondi discrète . . . . . . . . . . . . . . . . . . . 26 1.13 Densité de probabilité de la loi d’arrondi convergente discrète . . . . . . . . . . . . 27 1.14 Mesure de la puissance de bruit de quantification causé par la virgule fixe . . . . . 31 1.15 Estimation analytique de l’erreur causée par les opérations en virgule fixe . . . . . 33 1.16 Modèle analytique du bruit de quantification . . . . . . . . . . . . . . . . . . . . . 33 1.17 Propagation du bruit de quantification vers la sortie du système . . . . . . . . . . . 36 1.18 Les temps d’optimisation des deux approches en fonction de nombre d’évaluation . 39 2.1 Graphe du système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 2.2 Schéma d’un opérateur dans la précision infinie et la précision finie avec b bits . . . 45 2.3 Représentation d’un signal en virgule fixe avec une dynamique [−1, 1) ....... 46 2.4 Représentation d’un signal en virgule fixe avec une dynamique [−1, 1) ....... 46 2.5 Diagramme de la constellation 16-QAM . . . . . . . . . . . . . . . . . . . . . . . . 47 2.6 Fonctionnement de l’opérateur de décision . . . . . . . . . . . . . . . . . . . . . . . 48 2.7 Modèle de quantification d’un opérateur de décision . . . . . . . . . . . . . . . . . 49 2.8 Réponse à la perturbation à la frontière non lisse ; Cas A : x = xa, Cas B :x = xb . 49 2.9 Un système constitué d’un opérateur non lisse .................... 50 2.10 Probabilité d’erreur de décision totale : cas BPSK . . . . . . . . . . . . . . . . . . 53 2.11 Cascade de deux opérateurs de décision . . . . . . . . . . . . . . . . . . . . . . . . 54 2.12 Non validité du modèle analytique d’estimation de la probabilité d’erreur de décision dans le cas d’une cascade d’opérateurs de décision . . . . . . . . . . . . . . . . 55 2.13 Propagation de l’erreur de quantification dans un système composé de plusieurs opérateurs non lisses en cascade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 2.14 Propagation des erreurs non lisses (corrélées ou non corrélées) . . . . . . . . . . . . 59 2.15 Propagation des erreurs non lisses (corrélées et non corrélées) . . . . . . . . . . . . 61 2.16 Exemple d’un arbre de spanning SSFE avec m = [1, 1, 2, 4] .............. 62 2.17 Exemple d’une énumération rapide (ER) d’une constellation à 8 points . . . . . . . 63 2.18 Cascade d’opérateurs de décisions : cas de l’algorithme SSFE . . . . . . . . . . . . 64 32.19 Probabilité d’erreur de décision totale en fonction du rapport signal à bruit . . . . 67 2.20 Probabilité d’erreur de décision totale en fonction du rapport signal à bruit . . . . 71 2.21 Probabilité d’erreur de décision P3 ij dans le cas d’une puissance du bruit de quantification de 0.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 2.22 Probabilité d’erreur au niveau de l’antenne n˚3 de décision totale dans le cas d’une constellation 4-QAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 2.23 Probabilité d’erreur de décision totale dans le cas d’une constellation 4-QAM . . . 75 2.24 Probabilité d’erreur de décision P2 ij dans le cas d’une constellation 4-QAM . . . . . 76 2.25 Probabilité d’erreur de décision totale dans le cas d’une constellation 4-QAM . . . 77 2.26 Probabilité d’erreur de décision P1 ij dans le cas d’une constellation 4-QAM . . . . . 77 3.1 Système contenant une itération d’opérateur de décision . . . . . . . . . . . . . . . 80 3.2 Système composé d’itération d’opérateurs de décision . . . . . . . . . . . . . . . . . 83 3.3 Probabilité d’erreur de décision pour une constellation QPSK . . . . . . . . . . . . 85 3.4 Bloc-diagramme d’un égaliseur à retour de décision . . . . . . . . . . . . . . . . . . 89 3.5 Borne supérieure analytique et probabilité d’erreur de décision par simulation . . . 89 3.6 Structure de l’égaliseur : mode initial . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.7 Structure de l’égaliseur : mode final . . . . . . . . . . . . . . . . . . . . . . . . . . 91 3.8 Variation des coefficients des filtres de l’égaliseur . . . . . . . . . . . . . . . . . . . 93 3.9 Probabilité d’erreur de décision en fonction du nombre de bits . . . . . . . . . . . . 93 3.10 Architecture d’un égaliseur DFE à coefficients complexes . . . . . . . . . . . . . . . 94 3.11 Diagramme bloc de l’égaliseur DFE implémenté . . . . . . . . . . . . . . . . . . . . 95 3.12 Bloc diagramme de la procédure du test sur FPGA . . . . . . . . . . . . . . . . . . 96 3.13 Architecture du filtre forward .............................. 96 3.14 Entrée et sortie de l’égaliseur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 3.15 Probabilité d’erreur de décision en fonction des deux précisions . . . . . . . . . . . 98 3.16 Probabilité d’erreur de décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 3.17 Nombre de slice registres nécessaires pour obtenir une probabilité d’erreur de dé- cision de P0 = 10−3 avec une précision relative de 0.2. ................ 99 3.18 Nombre de slice lut nécessaires pour obtenir une probabilité d’erreur de décision de P0 = 10−3 avec une précision relative de 0.2..................... 100 3.19 Consommation de puissance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 3.20 Dispositif pour la mesure de la puissance . . . . . . . . . . . . . . . . . . . . . . . . 101 4.1 Turbo codeur de la norme 3GPP-LTE . . . . . . . . . . . . . . . . . . . . . . . . . 107 4.2 Exemple d’un treillis à 8 états . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 4.3 Les notations de BCJR dans le treillis . . . . . . . . . . . . . . . . . . . . . . . . . 108 4.4 Le principe du turbo décodage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 4.5 Fonction en escalier de conversion de la virgule flottante à la virgule fixe . . . . . . 111 4.6 Modèle virgule fixe du bloc SISO dans le turbo décodeur . . . . . . . . . . . . . . . 115 4.7 Analyse de la dynamique pour Nλch = 5 bits . . . . . . . . . . . . . . . . . . . . . 115 4.8 Effet de la quantification des entrées LLRs . . . . . . . . . . . . . . . . . . . . . . . 116 4.9 Analyse de la performance de l’algorithme de turbo-décodage en virgule fixe . . . . 117 4.10 Performance virgule fixe de bout en bout pour différentes valeurs de Aλch ..... 118 4.11 Exemple du graphe tanneur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.12 Matrice prototype du LDPC WIMAX 2/3a . . . . . . . . . . . . . . . . . . . . . . 120 4.13 Représentation du treillis à deux états d’une contrainte de vérification de parité avec dc = 5 ........................................ 121 4.14 Modèle virgule fixe du décodeur BCJR à 2-états . . . . . . . . . . . . . . . . . . . 122 4.15 Modèle virgule fixe du décodage à couche des codes LDPC . . . . . . . . . . . . . . 123 4.16 Effet de la quantification des entrées LLRs . . . . . . . . . . . . . . . . . . . . . . . 125 4.17 Effet de la quantification des métriques cumulées de chemin dans le processeur CN 125 4A.1 Domaine de la fonction caractéristique . . . . . . . . . . . . . . . . . . . . . . . . . 130 A.2 Quantification double . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 B.1 diagramme des cas particuliers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 B.2 méthode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 56Liste des tableaux 1.1 Comparaison de la dynamique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.2 Comparaison du RSBQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3 Paramètres statistiques du bruit généré . . . . . . . . . . . . . . . . . . . . . . . . 28 3.1 État des séquences d’erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.1 Les paramètres du code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.2 Les paramètres virgule fixe optimaux du turbo-décodeur . . . . . . . . . . . . . . . 118 78Glossaire A Arrondi AC Arrondi Convergent APA Algorithmes de Projection Affine ASIC Application Specific Integrated Circuit ASIP Application Specific Instruction-set Processor CA2 Complément à 2 DSP Digital Signal Processor FIR Finite Impulse Response IIR Infinite Impulse Response LMS Least Mean Square LSB Last Significant Bit MCR Moindres Carrés Récursifs MSB Most Significant Bit NLMS Normalize Least Mean Square RLS Recursive Least-Square RSBQ Rapport Signal sur Bruit de Quantification T Troncature TNS Transmission Numérique du Signal 910Notations E Terme d’espérance q Pas de quantification x(n) Donnée scalaire à un instant n X(n) Donnée vectorielle à un instant n X(n) Donnée matricielle à un instant n mX Moyenne de la donnée X(n) scalaire ou matricielle µx Moyenne du scalaire x(n) σ2 x Variance du scalaire x(n) RXX(θ) = E[X(n)Xt (n − θ)] Matrice d’autocorrélation des données X(n) CXX(θ) = E ! (X(n) − mX) " Xt (n − θ) − mt X #$ Matrice de covariance des données X(n) 1112Introduction De nos jours, le Traitement Numérique de Signal ne cesse d’évoluer pour répondre aux exigences actuelles de plusieurs domaines tels que les télécommunications qui ont marqué une avancée impressionnante. De plus, les algorithmes de Traitement Numérique de Signal figurent dans diffé- rentes applications telles que le domaine médical, l’aéronautique, le multimédia et l’électronique grand public. L’évolution rapide de la technologie des semi-conducteurs a conduit à d’énormes innovations dans le domaine de conception des produits électroniques pour implanter des applications de plus en plus complexes. Les équipements électroniques disponibles sur les marchés d’aujourd’hui sont caractérisés par une concurrence entre les grandes entreprises d’électronique pour les rendre plus efficaces et multifonctionnels. Cela s’est manifesté par l’évolution rapide des réseaux radio mobile particulièrement avec la quatrième génération (ou 4G). Par conséquent, les équipements de ces normes intègrent différentes technologies de communication numérique (WIFI, Bluetooth, GPS,...) qui cohabitent ensemble au sein du même équipement avec plusieurs applications fondées sur des algorithmes de traitement numérique de signal. En conséquence, ces grandes firmes d’électronique se trouvent face à un cycle continu de conception et de livraison des produits. A chaque itération de ce cycle, les concepteurs ont besoin de travailler avec une très haute complexité technologique en visant en même temps à fournir davantage de valeur ajoutée au consommateur dans les meilleurs délais. Les smart-phones actuels avec la 4G sont un bon exemple d’un équipement électronique de télécommunication, de traitement de signal et de semi-conducteurs et qui nécessite de très hautes capacités de calcul pour accomplir les diverses applications qui sont embarquées dans ces équipement et assurer les performances demandées pour la voix et le trafic des données. De plus, ils sont équipés de plusieurs outils de multimédia tels que les caméras par exemple pour enregistrer des vidéos et jouer de la musique en temps réel. Tout cela est conçu sous les contraintes d’énergie et de temps. L’exemple des smart-phones peut être généralisé pour la conception des équipements électroniques modernes afin de à minimiser le coût du système en termes de surface de silicium, le profit de la consommation de puissance et le temps d’exécution sous contrainte de performances améliorées en termes de précision de calcul et du temps de réponse. Par conséquent, ces objectifs représentent "pour les concepteurs" un compromis entre les performances et le coût. En conséquence, il est très important de faire les choix adéquats à chaque étape de conception afin d’assurer les meilleurs performances possibles du système global. De plus, le temps de mise sur le marché (Time-to-market) de ces produits doit être réduit. Pour cette raison, la conception et le développement de ces applications nécessitent l’utilisation des outils de haut-niveau qui interviennent dans toutes les étapes du cycle de développement des applications de traitement numérique de signal et de communication numérique. Le rôle de ces outils est de fournir aux concepteurs des facilités d’implantation pour choisir la meilleure architecture à implémenter en permettant de passer d’un haut niveau d’abstraction à une caractérisation bas niveau. Également, le choix des opérateurs utilisés pour implémenter ces algorithmes influence très largement le compromis coût/performance. Les opérateurs en arithmétique virgule flottante et en arithmétique virgule fixe sont les deux choix les plus courants pour l’implémentation de toutes les opérations arithmétiques. Il convient de préciser que l’implémentation en arithmétique virgule fixe possède l’avantage d’une consommation de puissance inférieure à celle en arithmétique virgule flottante, mais aussi elle est marquée par une latence plus courte et des surfaces significativement plus petites. Par conséquent l’arithmétique en virgule fixe est un choix populaire pour l’implémenta- 12 Contexte de l’étude tion des algorithmes de traitement numérique de signal (TNS) qui possèdent des paramètres de performances rigoureux à achever et qui demandent des puissances de calcul élevées. Contexte de l’étude Le processus de conception des algorithmes de traitement numérique de signal s’effectue selon plusieurs étapes. Le concepteur est ainsi amené à faire le choix approprié en considérant plusieurs options disponibles à chaque étape du cycle de conception de l’application. Un choix particulier qui conduit à l’amélioration des performances du système est invariablement associé à l’augmentation indésirable du coût du système. Par conséquent, la prise de décision d’un bon choix est réalisé par l’intermédiaire d’un nombre d’itérations de vérification avant d’arriver au choix optimal. Les différentes étapes de conception d’une application de traitement numérique de signal sont décrites par la figure 1. Figure 1 – Cycle de conception d’une application de traitement numérique de signal La première étape de ce cycle est la définition du cahier de charge en spécifiant les différentes fonctions à accomplir par le système conçu ainsi que les différentes contraintes architecturales du système par rapport à la consommation d’énergie et au niveau temporel. L’étape suivante correspond à la conception de l’algorithme et la spécification d’une description complète de l’algorithme qui est une tâche donnée dans le contexte de cette thèse. A cette étape, des simulations sont effectuées pour vérifier les différents critères conçus à travers des outils tels que Matlab (Mathworks), Scilab (Inria). Ces simulations sont effectuées en utilisant l’arithmétique virgule flottante pour s’affranchir des problèmes de précision des calculs. Une fois l’algorithme est conçu, celui ci est décrit à l’aide d’un langage de programmation (C,C embarqué) et implanté dans le système embarqué. L’implantation peut être logicielle ou matérielle à travers les solutions architecturales tels que ASIC, FPGA ou DSP. L’étape suivante concerne la détermination d’une représentation convenable en virgule fixe. Cette tache est le centre d’intérêt de cette thèse. Les contraintes de coût et de consommation des systèmes embarqués conduisent à l’utilisation de l’arithmétique en virgule fixe puisqu’elles sont moindres par rapport à l’arithmétique virgule flottante car les largeurs des données de cette dernière sont plus larges qu’en format virgule fixe.Problématique de la thèse 3 Généralement, les données en virgule flottante sont codées sur 32 bits alors qu’en virgule fixe, elle sont codées sur 16 bits. Également, les opérateurs en virgule fixe sont moins complexes qu’en virgule flottante. Par contre, le temps de développement en virgule fixe est plus important car les formats des différentes données en virgule fixe doivent être optimisés et bien définis pour éviter le débordement au sein de l’application. Par conséquent une conversion de la logique virgule flottante vers l’arithmétique virgule fixe est effectuée. Cette tâche, longue, peut constituer 30% du temps d’implantation du système. De plus, elle conduit à de nombreuses erreurs et ainsi la représentation en virgule fixe doit garantir l’intégrité de l’application et satisfaire les contraintes de performance. Afin de répondre aux exigences du temps de mise sur le marché, cette conversion est automatisée à travers des outils de conversion automatique qui visent à répondre aux exigences de la précision pour maintenir les performances de l’algorithme tout en optimisant les coûts. Une fois qu’un format convenable de virgule fixe est sélectionné, le système est implémenté et une vérification des performances du système selon les critères de l’utilisateur est effectuée. Si les résultats sont satisfaisants, la conception est clôturée, sinon, toutes les étapes à partir de l’optimisation en arithmétique virgule fixe doivent être répétées pour compenser les lacunes du format virgule fixe précédent. Le bloc d’implémentation n’est pas détaillé dans la figure 1 afin de mettre l’accent sur l’élé- ment central de cette thèse. Dans la pratique, ce bloc est complexe et peut être séparé en plusieurs sous-blocs. Dans le cas d’une implémentation logicielle, il existe des compilateurs, tels que le compilateur GCC (GNU Compiler Collection), qui sont spécifiquement optimisés pour des architectures de processeurs spécifiques. Problématique de la thèse Il existe quatre tâches pour l’implémentation en arithmétique virgule fixe d’un système donné tel que montré par la figure 2. Figure 2 – Les étapes d’implémentation en virgule fixe La première tâche concerne l’estimation de la dynamique des signaux. En effet, une détermination de la dynamique est requise pour connaître l’intervalle des valeurs prises par les données.4 Problématique de la thèse Ensuite le nombre de bits accordé à la partie entière du format virgule fixe est déduit. En d’autres termes, cette première étape conduit à déterminer la position de la virgule qui doit permettre d’éviter la présence de débordements. En addition, un alignement de la virgule des opérandes est effectué par le biais des opérations de recadrage afin d’adapter les données à leurs dynamiques. Dans une seconde étape, l’optimisation en arithmétique virgule fixe nécessite de déterminer le nombre de bits à affecter à la partie fractionnaire. Ce nombre de bits résulte d’un compromis entre le coût d’implantation et la précision des calculs. La deuxième tâche concerne la mesure des pertes en précision causées par l’utilisation des opérateurs et des données en arithmétique virgule fixe. En effet, l’utilisation de l’arithmétique virgule fixe engendre des erreurs de calculs par rapport aux opérations réalisées en précision infinie. Par conséquent, l’évaluation de la précision des calculs est une étape primordiale dans le processus de conception des applications en format virgule fixe. Cette tâche constitue l’objet principal de ce travail de thèse, en particulier l’évaluation de la précision des systèmes de traitement numérique de signal et de communication numérique constitués d’opérateurs non lisses (un-smooth) et non linéaires en terme du bruit. L’évaluation de la précision se fait par le biais d’une métrique caractérisant les performances de la précision qui est généralement le Rapport Signal à Bruit de Quantification (RSBQ). Dans [82], une méthode est présentée pour déterminer la valeur minimale du RSBQ et par conséquent l’optimisation en arithmétique virgule fixe se fait sous une contrainte de précision obtenue par le biais de la valeur minimale du RSBQ. De plus, l’estimation des avantages du coût correspondant à l’utilisation du format virgule fixe constitue un défi à résoudre. En effet, l’objectif visé est de faire un compromis entre les pertes en précision et les gains en coût d’implémentation en respectant les contraintes de la conception et en faisant un choix optimisé du format virgule fixe. Dans le cas d’une implémentation logicielle sur un DSP ou bien un micro-contrôleur, l’architecture est fixée et les opérateurs sont prédéfinis sur une largeur bien précise. Néanmoins, les processeurs peuvent manipuler plusieurs types d’instructions telles que les instructions de type SWP (Sub-Word Parallelism) qui permettent d’accélérer les temps d’exécution en favorisant le parallélisme des opérations. D’autres part, les processeurs fournissent des instructions multipré- cisions permettant de traiter les données enregistrées en mémoire avec une précision plus élevée. Le temps d’exécution Texe de ce type d’instruction est alors plus important et le problème posé consiste à trouver le point optimum de fonctionnement correspondant au temps minimal d’exé- cution Texe satisfaisant également la contrainte de précision RSBQmin. En d’autres termes, le temps d’exécution Texe est minimisé tant que la contrainte de précision RSBQmin est satisfaite. Cette approche conduit au problème d’optimisation suivant : min B∈EB (Texe(B)) tel que RSBQ(B) ≥ RSBQmin (1) où B représente le vecteur contenant les largeurs des données présentes dans l’algorithme et EB désigne l’ensemble des largeurs supportées par le processeur. Le temps d’exécution du code dépend du type d’instruction choisi. L’implémentation matérielle sur un FPGA ou un ASIC est fondée sur une définition de l’architecture qui détermine le nombre d’opérateurs impliqués dans l’application. Particulièrement, la largeur des différents opérateurs arithmétiques est à fixer. Dans ce cas d’implémentation, l’objectif de la méthodologie est de minimiser le coût de l’architecture en termes de consommations de ressources et d’énergie sous contrainte d’une précision donnée des calculs. Les coûts locaux des éléments présents dans l’architecture conduisent à la minimisation du coût global Carch de l’architecture sous la contrainte de précision minimale exprimée par RSBQmin (équation 2). Une telle approche fera l’objet du troisième chapitre de cette thèse dédié à l’implémentation efficace sur FPGA de l’algorithme d’égalisation à retour de décision sous contrainte d’une probabilité d’erreur de décision minimale. min B∈EB (Carch(B)) tel que RSBQ(B) ≥ RSBQmin (2)Contributions 5 Les 2 méthodologies définies par les relations 1 et 2 font appel à une contrainte d’optimisation liée à l’évaluation de la précision des calculs en arithmétique virgule fixe. L’évaluation de cette précision constitue la pierre angulaire de ce travail de thèse. Deux approches différentes sont classiquement envisagées pour effectuer cette tâche : l’approche basée sur des simulations en arithmétique virgule fixe et l’approche basée sur des modèles analytiques permettant de caractériser la métrique de précision. Étant donné que la précision des calcul est évaluée à chaque itération du processus d’optimisation, l’approche par simulation engendre des temps d’optimisation prohibitifs. Par conséquent, pour limiter cet effet, des modèles analytiques ont été proposés pour évaluer la précision en virgule fixe des systèmes de communication numérique et de traitement numérique de signal. Dans ce dernier cas, la métrique de précision (RSBQ(B)) est calculée à chaque itération du processus ce qui nécessite la connaissance de son expression analytique en chaque point du graphe décrivant l’algorithme. Par conséquent, le temps d’évaluation est significativement réduit. Dans la littérature, des approches analytiques ([32], [69]) ont été proposées pour évaluer la précision des systèmes linéaires et invariants dans le temps (LTI), les systèmes non-LTI nonrécursifs dans [70] et également les systèmes LTI et non-LTI récursifs. L’objectif de ce travail de recherche est de proposer des modèles analytiques des systèmes de communication numérique et de traitement numérique de signal formés par des opérateurs non lisses et non linéaires en terme de bruit tels que les algorithmes de décodage sphérique, l’égalisation à retour de décision ou encore le turbo-décodage. De plus, des optimisations des largeurs des données en format virgule fixe pour ces applications ont été abordées en se basant sur les modèles analytiques proposés. Contributions Les travaux effectués durant cette thèse s’articulent autour trois grands piliers. Dans un premier temps, des modèles analytiques pour l’évaluation de la précision des systèmes constitués d’une cascade d’opérateurs non lisses de décision ont été proposées en collaboration avec les travaux de recherche effectués dans le cadre de la thèse de Karthick PARSHAR au sein de la même équipe CAIRN. Cette étude repose sur l’identification d’opérateurs non lisses et sur la caractérisation des bruit de quantification engendrés par ce type d’opérateurs. Dans une seconde étape, ce travail a été étendu à l’analyse du phénomène de propagation des erreurs de décision lorsque plusieurs opérateurs de décision sont utilisés en cascade. Ce travail nous a permis de définir un modèle analytique général permettant d’évaluer la précision de systèmes constitués d’une cascade d’opérateurs de décision comme, par exemple, les systèmes de communications numériques. Ainsi, les modèles analytiques proposés seront appliqués à l’évaluation des algorithmes de décodage sphérique tel que l’algorithme SSFE (Selective Spanning with Fast Enumeration). La seconde contribution de cette thèse concerne l’évaluation de la précision des systèmes de communication numérique basés sur l’itération d’opérateurs non lisses de décision. Cette étude a fait l’objet d’une approche analytique permettant l’évaluation de la précision en arithmétique virgule fixe lorsque l’itération d’opérateurs non lisses de décision converge en se basant sur la résolution d’un système d’équations non linéaires par la méthode de Newton-Raphson. Cependant, le temps d’évaluation de cette approche demeurant assez élevé pour des constellations à forte efficacité spectrale, nous proposons une approche alternative dans une seconde étape afin de remédier à ce problème. Cette dernière fournit une borne supérieure de la probabilité d’erreur de décision lorsque les systèmes convergent. Elle sera appliquée à l’évaluation de la précision de l’égaliseur à retour de décision. Enfin, la dernière contribution de cette partie concerne l’optimisation de l’implémentation en virgule fixe sur FPGA d’un égaliseur numérique à retour de décision ou DFE (Deision Feedback). Cette optimisation est effectuée sous une contrainte de précision exprimée à travers la probabilité d’erreur de décision. Ainsi, une architecture de DFE a été proposée permettant de fixer les largeurs des données de cet algorithme à partir d’un compromis entre la consommation en ressources matérielles et en énergie obtenue pour différentes contraintes de précision. Nous avons proposé une architecture en format virgule fixe du turbo décodeur qui utilise une6 Organisation de la thèse loi de quantification basée sur le couple (A, Nx) où A représente la dynamique de signal et Nx le nombre total de bits utilisés dans la représentation en virgule fixe du signal x à quantifier. Nous montrerons que ce schéma de quantification est plus flexible que la quantification classique représentée par le couple du nombre de bits pour la partie entière et le nombre de bits pour la partie fractionnaire (NI , NF ), sans tenir compte de la dynamique. En effet, dans les approches classiques, la dynamique est généralement limitée à une puissance de deux tandis que cette approche s’affranchit de cette restriction. Dans une seconde étape, nous avons visé à réduire la taille des mémoires utilisées dans l’implémentation du turbo décodeur afin de satisfaire la contrainte de faible complexité. Cette réduction est faite à travers des techniques de saturation et de troncature. Finalement, une évaluation des performances en arithmétique virgule fixe est réalisée par l’analyse des taux d’erreur par paquet FER (Frame Error Rate) en fonction du SNR (Signal to Noise Ratio). Des choix sur la largeur des données sont discutés afin de réaliser un compromis entre les solutions à hautes performances et celles à faibles complexités. L’ensemble de cette méthodologie a également été appliqué à la modélisation d’un décodeur LDPC en se basant sur le principe de fonctionnement du décodage-LDPC. Organisation de la thèse Cette thèse est constituée de quatre parties. Le premier chapitre est un chapitre introductif présentant les différents aspects des arithmétiques en virgule flottante et en virgule fixe avec une comparaison entre les deux arithmétiques en termes de plusieurs critères. Cette comparaison justifie l’intérêt de l’utilisation de la représentation en virgule fixe pour les systèmes embarqués et les algorithmes de traitement numérique de signal. Ensuite, les différentes approches pour l’évaluation de la précision en virgule fixe sont explicitées, en particulier les approches par simulation et les approches basées sur des modèles analytiques. Une comparaison entre ces deux approches est ensuite présentée ce qui conduira à justifier l’avantage de l’utilisation des modèles analytiques en termes d’optimisation du temps d’évaluation et des capacités de calcul. Le deuxième chapitre de cette thèse définit tout d’abord la notion d’opérateurs non lisses en proposant une technique pour les identifier. Nous présentons ensuite un modèle analytique pour l’évaluation de la précision d’un opérateur de décision non lisse. Dans une seconde étape le problème de la propagation des erreurs de décisions dans une cascade d’opérateurs de décision est abordé en proposant des modèles analytiques permettant l’évaluation de ce genre de configuration dans les systèmes de communication numérique. Ces modèles analytiques ont été appliqués à l’algorithme SSFE. La troisième partie de cette thèse est consacrée à la présentation des modèles analytiques permettant l’évaluation de la précision des itérations d’opérateurs de décision. En premier lieu, une étude est menée sur la caractérisation du phénomène de propagation des erreurs causées par l’opérateur de quantification utilisé dans une structure itérée. Deux modèles analytiques sont ensuite présentés pour évaluer la probabilité d’erreur de décision dans le mode de convergence. Ces modèles sont appliqués, dans une seconde étape, pour évaluer la précision de l’algorithme d’égalisation à retour de décision DFE tout en présentant une solution pour l’algorithme DFE adaptatif. La dernière partie de ce chapitre présente une optimisation en arithmétique virgule fixe des largeurs de données du DFE pour une implémentation sur un FPGA. Cette optimisation vise à minimiser le coût de l’architecture en termes de consommation des ressources et de puissance sous une contrainte de précision exprimée sous forme de probabilité d’erreur de décision. Le dernier chapitre de cette thèse présente des modélisations en arithmétique virgule fixe de deux algorithmes de décodage itératif. Nous présentons tout d’abord le principe du turbo décodage. Nous proposons ensuite un modèle en arithmétique virgule fixe pour ce décodeur en se basant sur des techniques de saturation et de troncature pour viser à des solutions à faible complexité. La dernière partie du chapitre est consacrée à l’évaluation expérimentale du modèle proposé à travers la mesure des performances en FER. De même, nous présentons dans la dernière partie le principe de décodage LDPC en proposant une architecture en format virgule fixe deOrganisation de la thèse 7 ce dernier. L’évaluation des performances en arithmétique virgule fixe du modèle proposé est effectuée à travers les résultats obtenus.8Chapitre 1 Arithmétique virgule fixe Sommaire 1.1 Les différents types de formats de données . . . . . . . . . . . . . . . . 10 1.1.1 Représentation des nombres entiers . . . . . . . . . . . . . . . . . . . . . 11 1.1.2 Le format virgule fixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.1.3 Le format virgule flottante . . . . . . . . . . . . . . . . . . . . . . . . . . 12 1.1.4 Comparaison arithmétiques virgule flottante et virgule fixe . . . . . . . 14 1.2 Modélisation du bruit de quantification . . . . . . . . . . . . . . . . . . 20 1.2.1 Processus de quantification . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2.2 Signal à amplitude continue . . . . . . . . . . . . . . . . . . . . . . . . . 23 1.2.3 Signal à amplitude discrète . . . . . . . . . . . . . . . . . . . . . . . . . 25 1.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.3 Évaluation de la précision . . . . . . . . . . . . . . . . . . . . . . . . . . 28 1.3.1 Les métriques de précision . . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.3.2 Les méthodes d’évaluation de la précision par simulation . . . . . . . . . 29 1.3.3 Les approches analytiques de l’évaluation de la précision . . . . . . . . . 32 1.3.4 Autres effets de la quantification . . . . . . . . . . . . . . . . . . . . . . 38 1.3.5 Bilan des deux approches . . . . . . . . . . . . . . . . . . . . . . . . . . 38 1.3.6 Les approches hybrides . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Cette partie est consacrée à la présentation des spécifications de l’arithmétique virgule fixe ainsi que des différentes techniques existantes pour évaluer la précision des systèmes virgule fixe. En effet, les arithmétiques virgule fixe et virgule flottante sont les arithmétiques binaires de données les plus utilisées sur les plates-formes informatiques modernes. La première partie de ce chapitre est consacrée à la description des différents types de codage. Les circuits en arithmétique virgule fixe ont existé depuis les premiers ordinateurs électroniques et les calculateurs. Choisir le format approprié en arithmétique virgule fixe a toujours été un sujet de préoccupation. Auparavant, ce choix était influencé principalement par des considérations liées à la puissance de calcul des processeurs mais également par des considérations sur la mémoire nécessaire en raison de la latence et du coût de celle-ci. La plupart des algorithmes numériques complexes devaient compter sur des tables précalculées durant les calculs. Aujourd’hui, la définition du format en virgule fixe d’un nombre est impactée par des considérations telles que la surface de silicium, le temps d’exécution et la consommation totale d’énergie du dispositif électronique. L’arithmétique virgule fixe répond bien à ces exigences par rapport à l’arithmétique flottante. Par contre, l’utilisation de l’arithmétique virgule fixe engendre la génération de bruits de quantification causés par les débordements lors du changement de format. Ces bruits, présentés dans la deuxième partie de ce chapitre, se propagent ensuite au sein du système global et conduisent à la modification de la qualité de l’application. Par conséquent, l’évaluation de la précision est une étape primordiale lors de la conversion de format flottant au format fixe afin de garantir l’intégrité de l’application. Il 910 Arithmétique virgule fixe est donc important de disposer de méthodologies d’évaluation de cette précision en arithmétique virgule fixe. Ce point fera l’objet de la troisième partie de ce chapitre. Il existe deux familles d’approches : l’approche d’évaluation par simulation qui est basée sur des simulations virgule fixe de l’application et l’approche d’évaluation analytique qui consiste à trouver des modèles analytiques basés sur des métriques. Nous menons ci-après une analyse des points forts de chacune de ces deux approches ce qui nous permettra de sélectionner l’approche retenue dans le cadre de ce travail. 1.1 Les différents types de formats de données Le choix d’une représentation binaire relève d’une problématique qui concerne toute plateforme numérique actuelle. Faire un choix d’une représentation ou d’une arithmétique représente une étape primordiale dans le développement d’une application numérique. Les arithmétiques virgule fixe et virgule flottante sont généralement utilisées dans un but de stockage ou de calcul. En général, les algorithmes de traitement numérique de signal demandent des capacités de calcul intensif. Par conséquent, le choix du bon format de représentation des nombres joue un rôle crucial pour une implémentation efficace de n’importe quel algorithme de traitement numérique de signal. Dans le calcul numérique, le système de numération spécifie la méthode selon laquelle les nombres sont représentés comme étant une séquence de chiffres binaires et il spécifie également les règles pour effectuer les opérations arithmétiques (ex. addition, multiplication etc.) entre ces nombres. Dans la plupart du temps, les calculs scientifiques donnent seulement une approximation de la valeur exacte qui serait obtenue avec une précision infinie. Ceci est une conséquence du nombre limité de bits utilisés dans le système de numération. Quel que soit l’arithmétique virgule fixe ou l’arithmétique virgule flottante utilisée, seulement un nombre fini de bits est utilisé pour la représentation des nombres réels. La précision limitée des standards de codage peut être évaluée selon deux perspectives diffé- rentes. La première concerne la précision des calculs déterminée par l’étape de quantification du système de numération (la distance entre deux nombres). Le second aspect est relatif à la variation de la dynamique maximale permise par la représentation. Cette variation de la dynamique d’un système de numération est donnée par l’ensemble des valeurs possibles qui peuvent être représentées. Elle est évaluée à travers le logarithme du quotient entre les amplitudes maximale et minimale du signal comme indiqué à l’équation (1.1). Par conséquent, la comparaison entre le codage en virgule flottante et en virgule fixe est fondée en particulier sur l’analyse de la précision numérique et la variation de la dynamique selon la relation : DdB = 20log10 %XMAX XMIN & . (1.1) Généralement, les algorithmes pour les systèmes embarqués sont développés en utilisant l’arithmétique virgule flottante afin d’éviter les problèmes liés à la longueur finie d’un mot de code. Ce processus valide l’intégrité de l’algorithme et vérifie si l’algorithme proposé répond bien au cahier des charges. Même si l’erreur inhérente à l’exactitude de calcul existe toujours, elle demeure faible par rapport à celle obtenue par l’arithmétique en virgule fixe. Par conséquent, le calcul en virgule flottante garantit une précision et une variation de dynamique suffisantes dans la plupart des cas. Néanmoins, la plupart des implémentations VLSI utilisent l’arithmétique en virgule fixe pour réduire la surface et la consommation d’énergie et obtenir un matériel rentable. En contrepartie, une dégradation de la précision des calculs est produite en raison du nombre limité de bits utilisés dans la représentation des données. En effet, l’utilisation du codage en virgule fixe introduit des bruits de quantification lors de l’élimination de bits à travers les opérations de saturation (arrondi) et troncature. En outre, cela conduit à l’apparition de débordements à chaque fois que la longueur du mot de code de la partie entière est insuffisante pour représenter l’ensemble de la variation de la dynamique.1.1 Les différents types de formats de données 11 Dans cette section, les différents types d’arithmétiques pour les systèmes numériques sont abordés. En premier lieu, l’arithmétique virgule flottante est introduite, ensuite, l’arithmétique virgule fixe est présentée en la comparant avec celle virgule flottante afin de montrer les avantages et les inconvénients de chacune de ces deux représentations. 1.1.1 Représentation des nombres entiers Numération simple de position Un entier p (compris entre 0 et BN − 1) est décomposé dans la base B d’une façon unique selon la formule suivante : p = N '−1 i=0 aiBi . (1.2) Les ai sont des chiffres compris entre 0 et B − 1. L’entier p est noté dans la base B de la façon suivante : (aN−1...a2a1a0)B ou tout simplement (aN−1...a2a1a0) si la base B a été prédéfinie auparavant. Ainsi la chaîne aN−1...a2a1a0 est nommée l’entier simple associé à p en base B (ESAB) selon : ESAB(aN−1...a2a1a0) = N '−1 i=0 aiBi . (1.3) Notation Signe - Valeur Absolue (SVA) La notation en numération simple d’un nombre signé correspond à la représentation de la valeur absolue de ce nombre en numération simple de position en ajoutant un symbole spécifiant le signe du nombre à représenter. L’inconvénient de cette représentation se manifeste par les opérations mathématiques effectuées sur des nombres respectant cette notation. En effet, à titre d’exemple, l’addition de deux nombres nécessite l’utilisation de deux algorithmes : un algorithme d’addition si les deux nombres possèdent le même signe et un algorithme de soustraction dans le cas contraire. Présentation en complément à la base Afin d’éviter le problème de prise en compte du signe des opérandes présent pour la notation SVA, le système de numération des entiers, en complément à la base B a été créé. Par conséquent dans le cas où B est une base paire, l’entier p = (aN−1...a2a1a0)B¯ est représenté de la façon suivante : – Si 0 ≤ p ≤ BN /2 − 1, la représentation est celle de l’équation (1.2) : ESAB(aN−1...a2a1a0) = p. – Si −BN /2 ≤ p ≤ −1, le codage est réalisé selon l’expression suivante : ESAB(aN−1...a2a1a0) = BN + p. Par conséquent, grâce à cette notation, on utilise un seul algorithme d’addition modulo BN pour réaliser l’addition de tous les entiers compris entre −BN /2 et BN /2. Si le signe du résultat de l’addition est différent de celui des opérandes, il en résulte un dépassement de capacité. Dans le cas où B = 2, cette notation est connue sous le nom de notation à complément à deux (CA2). 1.1.2 Le format virgule fixe Soit x un réel écrit sous la forme x = pK avec p un entier codé selon l’une des représentations décrites précédemment où K est appelé le facteur d’échelle. Ce facteur d’échelle est une puissance de la base B préalablement fixée : K = Bn . La position de la virgule peut alors être référencée par un entier n relativement au bit de poids faible (Least Significant Bit ou LSB) ou par un entier m relativement au bit de poids fort (Most Significant Bit ou MSB). Dans ce cas, le réel x peut se représenter selon la figure 1.1 où les deux entiers n et m représentent les distances entre la virgule et le LSB et le MSB (Most Signifiant Bit) respectivement.12 Arithmétique virgule fixe Figure 1.1 – Représentation des données en virgule fixe La figure 1.1 représente un codage en virgule fixe d’un nombre avec un bit de signe S, m bits pour la partie entière et n bits pour la partie fractionnaire. Le nombre de bits utilisés dans cette représentation est b = m + n + 1. Le format d’une donnée en virgule fixe est entièrement défini par la représentation choisie et la largeur de sa partie entière et de sa partie fractionnaire. Généralement, les nombres en arithmétique virgule fixe utilisent une représentation en complément à deux. La valeur d’un nombre est donnée par la relation suivante : x = −2mS + m '−1 i=−n bi2i . (1.4) Cette représentation possède des propriétés arithmétiques intéressantes pour les opérations d’addition et soustraction. En effet, même si les résultats intermédiaires d’une série d’additions sont en dehors du domaine de définition du codage, le résultat final sera correct si celui-ci appartient au domaine de définition du codage. De plus, l’implantation dans les processeurs numériques des opérateurs traditionnels utilisant ce code est simplifiée lorsque l’on utilise cette représentation. x = −2mS + m '−1 i=−n bi2i . (1.5) Par ailleurs, elle possède l’avantage de n’autoriser qu’une seule représentation possible pour 0. Par conséquent, le domaine des valeurs possibles n’est pas symétrique par rapport à l’origine, et il possède 2m+n valeurs négatives et 2m+n − 1 valeurs positives, soit : D = [−2m; 2m − 2−n]. (1.6) La notation en format virgule fixe est simple et permet d’effectuer les calculs rapidement. En contrepartie, comme le facteur d’échelle K est fixé, la notation en virgule fixe ne permet pas de représenter des nombres d’ordre de grandeur très différents. De plus, il n’est pas toujours facile de fixer a priori le facteur d’échelle si l’ordre de grandeur des valeurs prises par la donnée n’est pas connu par avance. La notation en virgule flottante permet de résoudre ces problèmes. 1.1.3 Le format virgule flottante Le système des nombres en virgule flottante est le standard de codage le plus utilisé lorsqu’une grande précision est requise. Il représente un nombre réel selon une notation scientifique avec une partie fractionnaire appelée mantisse et un facteur d’échelle appelé exposant, comme représenté dans la figure 1.2. L’exposant est défini comme une puissance de la base (typiquement 2 et 10) et il est utilisé comme un facteur d’échelle explicite qui change durant les calculs permettant ainsi1.1 Les différents types de formats de données 13 une dynamique large pour les valeurs représentées. La mantisse détermine la précision de nombre représenté. Figure 1.2 – Représentation des données en virgule flottante Soit x un réel signé écrit en format flottant dans la base B avec un signe S, une mantisse M et un exposant E. La valeur associée à ce réel est donnée par l’équation suivante : x = (−1)SMBE. (1.7) Comme le nombre de bits accordés à la mantisse et à l’exposant peut prendre un grand nombre de valeurs possibles, un format virgule flottante normalisé a été introduit. La norme IEEE pour l’arithmétique virgule fixe binaire (IEEE 745-2008) est utilisée dans la plupart des CPUs d’aujourd’hui. Elle spécifie le format virgule flottante et également les modes d’arrondis. Elle décrit non seulement comment les opérations arithmétiques doivent être effectuées, mais aussi le traitement des exceptions (division par zéro, les débordements,...). La valeur d’un nombre représenté selon le format virgule flottante de la norme IEEE 745 est calculée : x = (−1)S1M2E−biais. (1.8) La mantisse est normalisée pour représenter une valeur dans l’intervalle [1, 2]. Par conséquent, la valeur de son premier bit est fixée à 1 et devient implicite. La valeur de l’exposant est codée comme un nombre non signé. Alors, afin de représenter les nombres inférieurs à 1, un biais est introduit. Ce biais dépend du nombre de bits alloués à l’exposant : biais = 2Ne−1 − 1. Dans le cas d’un format de précision simple, le biais est 127 et la gamme de l’exposant est [−126, 127]. Pour la double précision, le biais est 1023 et l’exposant prend ses valeurs dans [−1022, 1023]. Il est à noter que la représentation d’un nombre n’est pas unique et les zéros à gauche de la mantisse dégradent la précision. Par exemple, considérons la base 10 avec 4 chiffres de mantisse, π peut être représenté par 0.031102 ou 3.142100. Ces deux représentations ne possèdent pas la même précision. Par conséquent, pour éviter cette ambiguïté, une représentation sans zéro à gauche est proposée et correspond à la représentation normalisée en virgule flottante. Dans ce cas, le premier bit de la mantisse représente le coefficient 1 2 et est fixé à 1. La valeur de ce bit est inchangée au cours du traitement et ne figure pas dans dans la représentation. Dans le cas où l’exposant est une puissance de deux (cas binaire), la mantisse et l’exposant sont codés avec une représentation en signe valeur absolue, la valeur de la donnée x est la suivante : x = 2u(−1)SM (1 2 + M '−1 i=1 Ci2−i−1 ) avec u = (−1)SE E '−1 i=1 di2i . (1.9) La valeur 0 n’est pas représentable selon l’équation (1.9). Par conséquent, le domaine de définition des valeurs représentables avec ce codage est l’union de deux sous-domaines donnés par l’expression suivante : DR = * − 2K; −2−K−1 +,* 2−K−1; 2K+ avec K = 2E−1 − 1. (1.10)14 Arithmétique virgule fixe L’écart minimal entre deux valeurs représentables par le code considéré détermine le pas de quantification dont la valeur varie en fonction de la valeur représentée. Pour les valeurs de x comprises dans l’intervalle [−2u, −2u−1] -[2u, 2u−1], le pas de quantification est égal à : q = 2u2−(M+1). (1.11) L’étape de quantification de la norme de codage en virgule flottante dépend de la valeur à représenter. En effet, lorsque la valeur de l’exposant augmente (respectivement diminue), la distance entre deux nombres successifs représentables devient plus importante (respectivement plus faible), i.e. le pas de quantification augmente (respectivement diminue) conformément à la relation d’ordre : 2−(M+1) < q | x | < 2−M. (1.12) Ainsi, la présence d’un facteur d’échelle explicite permet d’adapter le pas de quantification à la valeur de la donnée à coder. 1.1.4 Comparaison arithmétiques virgule flottante et virgule fixe Nous présentons dans cette section une comparaison entre le format virgule flottante et le format virgule fixe afin de mettre en évidence leurs avantages et inconvénients. Cette comparaison est fondée sur l’analyse de deux aspects. Le premier est l’aspect arithmétique et le deuxième est le coté implantation matérielle puisque l’objectif de cette thèse concerne l’évaluation de la précision et la recherche du format optimal de représentation conduisant à une implémentation matérielle efficace en termes de consommation d’énergie et de ressources. Comparaison d’un point de vue arithmétique La qualité du codage est analysée, d’un point de vue arithmétique, en évoquant la dynamique de chacun des deux codages et également le rapport signal à Bruit de quantification. Comparaison de la dynamique Une représentation efficace des nombres doit à la fois supporter une dynamique large mais également disposer d’une grande précision. En d’autres termes, la représentation d’un nombre devient plus polyvalente avec un rapport plus élevé de la dynamique et la précision. Typiquement, les deux formats virgule fixe et virgule flottante sont symétriques par rapport à leur espace des valeurs représentables. Donc, la dynamique dont l’expression est donnée par l’équation (1.1) est utilisée pour mesurer la fidélité du format. Plus la dynamique est importante, plus le débordement est faible. Dans le cas de la représentation en virgule flottante la dynamique s’exprime par l’équation (1.13) : DdB $ 20 log 10(22K+1) avec K = 2Ne−1 − 1. (1.13) Ne représente le nombre de bits accordés à l’exposant. Pour un format en simple précision où l’exposant est représenté par 8 bits, la dynamique devient : DdB = 20 log 10(2(28−1)) = 20log10(2255) $ 1535 dB. (1.14) Pour le format virgule fixe, la dynamique varie linéairement en fonction du nombre de bits, b, utilisé pour la représentation : DdB = 20log10 %XMAX XMIN & = 20log10 ( 2b−1 ) dB. (1.15) En appliquant les propriétés logarithmiques et des simplifications, la relation précédente devient : DdB = 20 (b − 1)log10(2) $ 6.02 (b − 1). (1.16)1.1 Les différents types de formats de données 15 La variation de la dynamique en fonction de la longueur du mot de code est plus importante pour les nombres en virgule flottante que pour les nombres en arithmétique virgule fixe. A titre d’exemple, dans le tableau 1.1 le format en précision simple est comparé avec différents types de représentation des données en format virgule fixe. Une différence importante entre les différents formats peut être observée. En effet, le format virgule fixe sur 128 bits possède significativement une petite dynamique par rapport à la représentation virgule flottante sur 32 bits. Format Dynamique (dB) Précision simple 1535 virgule fixe 16 bits 90 virgule fixe 32 bits 186 virgule fixe 64 bits 379 virgule fixe 128 bits 764 Table 1.1 – Comparaison de la dynamique Figure 1.3 – Comparaison de l’évolution du niveau de la dynamique pour les représentations virgule fixe et virgule flottante En comparant les équations (1.14) et (1.15), il est clair que la dynamique augmente exponentiellement pour le format virgule flottante et linéairement pour le format virgule fixe en fonction du nombre de bits accordés pour la représentation. Dans la figure 1.3, l’évolution de la dynamique en fonction du nombre de bits utilisés est présentée pour les deux formats virgule fixe et virgule flottante. Dans cet exemple, la taille de l’exposant représente le quart de la longueur totale du mot de code de la représentation. Nous pouvons observer que, lorsque la longueur d’un mot de code dépasse 16 bits, la dynamique du format virgule flottante devient plus large par rapport au format virgule fixe. Par conséquent, la représentation virgule flottante sur 32 bits peut être utilisée dans la plupart des applications sans aucun risque de débordement.16 Arithmétique virgule fixe Figure 1.4 – Effet du débordement utilisant la technique de l’enveloppe autour de la valeur Figure 1.5 – Effet du débordement utilisant la technique de saturation Le processus de codage d’un nombre en arithmétique virgule fixe correspond à une représentation d’une valeur réelle x par une autre valeur xˆ appartenant au domaine de codage. A chaque fois que le nombre réel à coder dépasse l’intervalle des valeurs permises par la norme de codage (ce qui veut dire que x /∈ * Xˆmin, Xˆmax+ ), un débordement se produit et une erreur est introduite. Il est alors nécessaire de définir une procédure de gestion de débordement afin d’être en mesure d’attribuer un mot de code dans cette situation. Deux techniques sont alors classiquement utilisées pour effectuer cette gestion du débordement. La première technique, décrite à la figure 1.4,1.1 Les différents types de formats de données 17 consiste à établir une enveloppe autour de la valeur du nombre réel à coder. Cette technique est équivalente à une arithmétique modulaire puisque toute valeur dépassant les bornes est remplacée par sa valeur modulo 2b. La deuxième méthode qui peut être appliquée est l’arithmétique de saturation. Dans ce cas, n’importe quelle valeur dépassant le domaine de codage est remplacée par le nombre représentable le plus proche (la borne maximale ou minimale). Cette technique est présentée par la figure 1.5. L’erreur introduite est plus petite que dans le cas de l’arithmétique modulaire. Cependant, à l’inverse de la technique de l’enveloppe autour de la valeur, l’implémentation de l’arithmétique de saturation nécessite une complexité matérielle plus importante et, par conséquent, son utilisation est limitée dans la pratique. Comparaison du rapport Signal à Bruit de Quantification Pour les applications de traitement numérique de signal (DSP), la précision des calculs est mesurée le plus souvent à travers le critère de Rapport Signal à Bruit de Quantification (RSBQ). Le RSBQ est défini par le rapport entre la puissance du signal (Px) et la puissance de l’erreur (Pe) due au bruit de quantification et il est généralement exprimé selon une échelle logarithmique : RSBQdB = 10log %Px Pe & = 10logE ! x2$ E [e2] . (1.17) Pour un signal x, sa puissance Px peut s’exprimer en fonction de sa dynamique linéaire Dx et du rapport Kx entre la racine carrée de la puissance Px et la dynamique Dx : Px = (KxDx) 2 . (1.18) Par conséquent, dans le cas de l’arithmétique virgule fixe, le RSBQ suit une relation linéaire en fonction de la dynamique, selon : RSBQdB = 20log(Dx) + 20log(Kx) − 10log(Pe) = DdB + 20log(Kx) − 10log(Pe) (1.19) Comme le format virgule fixe possède une quantification uniforme, le RSBQ dépend linéairement de l’amplitude du signal. Lorsque l’amplitude du signal augmente, le rapport bruit de quantification devient plus large et le RSBQ s’améliore. Considérons le cas d’un signal sinusoïdal à grande échelle avec une amplitude A = 2n. La variance du signal est : σ2 x = A2 2 . Le RSBQ devient : RSBQ = 20 log(2n .3 2 ) ≈ 1.76 + 6.02n dB. (1.20) Pour conclure, dans le cas de la représentation virgule fixe avec un signal utilisant la totalité de la dynamique disponible, chaque bit additionnel conduit à l’augmentation du RSBQ de 6 dB approximativement. Contrairement au cas de l’arithmétique virgule fixe, l’arithmétique virgule flottante possède l’avantage d’une étape de quantification proportionnelle à l’amplitude du signal. La valeur du RSBQ utilisant une échelle logarithmique est donnée par l’expression (1.21) et dépend du nombre de bits m utilisé pour la mantisse. En contre partie, le RSBQ de la représentation virgule flottante ne varie pas en fonction de l’amplitude du signal, il peut être considéré constant pour toutes les valeurs de x. RSBQ = 10 log(E ! x2$ evf ) = 10log(5.55 × 22m) ≈ 7.44 + 6.02m (1.21) Dans le tableau (1.2), une comparaison entre le RSBQ des deux formats virgule flottante et virgule fixe est présentée. Nous pouvons remarquer que, pour un même nombre de bits, l’arithmétique18 Arithmétique virgule fixe virgule fixe garantit un RSBQ plus large que celui de l’arithmétique virgule flottante si le nombre est correctement mis à l’échelle. Format RSBQ (dB) Précision simple 151 Précision double 326 virgule fixe 32 bits 194 virgule fixe 64 bits 387 Table 1.2 – Comparaison du RSBQ Comparaison pour les opérations de calcul D’après ce qui précède, il est clair que le format virgule flottante est plus performant que la représentation virgule fixe car il permet d’obtenir une dynamique suffisante et également une meilleure précision. Cependant, ce résultat est obtenu au prix d’une complexité des opérateurs arithmétiques. L’addition et la multiplication étant les deux opérations les plus génériques, nous étudions ci-après les coûts de réalisation de ces opérations. L’addition Le nombre en format virgule fixe est nativement dans le format binaire. Sous cette hypothèse, il est possible d’additionner deux nombres représentés en virgule fixe en utilisant un circuit d’entraînement de report d’addition simple après l’alignement des points binaires de deux nombres. L’effort total pour l’addition en arithmétique virgule fixe $a f ix est égal à l’effort (le coût de réalisation) de l’addition binaire $a : $ a f ix = $a. (1.22) Cependant, le format virgule flottante est avant tout un format compressé. Il est donc nécessaire tout d’abord de décompresser le nombre en virgule flottante afin d’avoir accès au signe, à l’exposant et à la mantisse. Ensuite, l’exposant doit être normalisé en comparant les bits dans la partie exposant des deux nombres et en décalant les bits de la mantisse d’une manière telle que les exposants soient égaux. Si le bit de signe est réglé, les bits de la mantisse sont convertis à leurs formes en complément à deux avant l’addition. Après l’addition, le résultat doit être converti au format complément à deux s’il est négatif. Comparativement, l’addition de deux nombres en arithmétique virgule fixe est relativement plus simple que l’addition en format virgule flottante. Soit $cmp l’effort nécessaire pour la comparaison des exposants et soit $cal l’effort demandé pour le calcul des compléments à deux des deux nombres, l’effort total pour réaliser une addition en virgule flottante $a f lt : $ a f lt = $a + $cmp + 2$cal. (1.23) Les efforts $a, $cmp et $cal sont tous de l’ordre de O (N) lorsque N est le nombre de bits accordés à la sortie de l’additionneur. Le temps pour la décompression du format virgule flottante est négligeable puisque cette opération est triviale du point de vue matériel. La multiplication La multiplication de deux nombres binaires signés au format virgule fixe nécessite l’utilisation d’un multiplicateur matériel. Le résultat de la multiplication possède davantage de bits dans son niveau de dynamique et sa précision. La position du point binaire du nombre résultant en arithmétique virgule fixe est déterminée en prenant en compte les positions du point binaire des deux nombres impliqués dans la multiplication. Habituellement, les bits les moins significatifs du résultat sont rejetés par divers modes d’arrondis ou de troncature pour obtenir le résultat final. Par la suite, l’effort total de la multiplication en format virgule fixe $m f ix est $m c’est à dire le coût correspondant à une multiplication binaire, soit : $ m f ix = $m. (1.24)1.1 Les différents types de formats de données 19 Dans le cas d’une multiplication entre des nombres représentés en virgule flottante, leurs exposants sont simplement additionnés, leurs mantisses et leurs bits de signe sont multipliés entre eux. L’effort total de la multiplication en virgule flottante $m f lt est : $ m f lt = $m + $a. (1.25) La complexité algorithmique d’une multiplication (cas virgule flottante) peut être supérieure à O(N2) et le temps pour l’addition est O(N) avec N est le nombre de bits accordés à la longueur du mot de code à la sortie du multiplicateur. Comparaison de point de vue implémentation matérielle et logicielle Chaque implémentation logicielle ou matérielle possède ses propres contraintes qui déterminent le choix de l’arithmétique la plus adaptée. Dans le cas d’une implémentation logicielle, les longueurs du mot de code sont fixées ou bien alors elles possèdent un nombre limité de représentations dans le format virgule flottante ou virgule fixe. Cependant, le format de la représentation en virgule fixe est flexible dans la mesure où le point binaire n’est pas fixe. Dans les plateformes logicielles typiques, les tailles d’un mot de code en arithmétique virgule fixe sont généralement d’un octet (8bits), moitié d’un mot (16 bits), un mot (32 bits) et aussi longue que mot double (64 bits). Les nombres en virgule flottante sont habituellement selon deux formats : soit la précision simple ou la précision double. De plus, il convient de préciser que les plateformes processeurs supportent les opérations des vecteurs de données SIMD (Single Instruction Multiple Data) [35]. De telles instructions fonctionnent sur un ensemble de données de même taille et de même type rassemblées en un bloc de données, d’une taille fixe, appelé vecteur. Il est alors possible de configurer le chemin de données selon une taille normalisée (le nombre de bits est généralement multiple de quatre ou huit) afin de contrôler plus précisément les longueurs des mots de code en arithmétique virgule fixe. L’implémentation matérielle ouvre également des horizons pour des unités en virgule flottante personnalisées [25] [27]. Dans [40], les spécifications des opérateurs en virgule flottante sont décrites en utilisant une bibliothèque C++ paramétrée d’opérateurs en virgule flottante. Il en résulte une génération automatique des implémentations optimales des opérateurs en virgule flottante dans le matériel de telle sorte que le temps de calcul est suffisamment petit pour atteindre la fréquence désirée de l’opération. L’impact du nombre de bits accordés à l’opérateur en virgule flottante sur le niveau de la dynamique et la précision de l’opération n’est pas aussi simple que dans le cas de système des nombres en virgule fixe. En définitive, il s’avère difficile de faire un choix entre le format virgule fixe et le format virgule flottante sans explorer explicitement toutes les opérations. Certaines stratégies [15] fournissent une bibliothèque paramétrable permettant de faire un choix entre les deux formats à partir de l’étude de différents compromis obtenus à partir de simulations. Dans [11] et [13], le niveau de la dynamique est considéré pour optimiser le format d’un nombre, i.e. minimiser la dynamique des calculs tout en contrôlant la précision à un niveau permettant de ne pas dépasser les coûts de la virgule flottante. Nous pouvons également remarquer que de nombreuses applications de traitement du signal sont linéaires et ces systèmes peuvent faire usage du facteur d’échelle et donc travailler avec une gamme dynamique normalisée. En outre, les applications de traitement du signal et en particulier les algorithmes de communications numériques sont conçus pour fonctionner en présence de bruit de canal dont la valeur est beaucoup plus grande par rapport au bruit de quantification introduit, même lorsqu’une quantification 16 bits est utilisée. Par conséquent, la précision requise pour la mise en œuvre de ces algorithmes n’est pas très stricte. Dans de telles circonstances, il est possible de profiter pleinement de la représentation à virgule fixe. Par conséquent, les applications de traitement numérique de signal et de communications numériques sont le domaine d’intérêt de cette thèse. Au lieu d’utiliser un arbre d’addition à virgule fixe, d’autres travaux [26] utilisent un système de représentation hybride où les nombres à additionner sont normalisés relativement au plus20 Arithmétique virgule fixe grand exposant et où l’addition à virgule fixe est utilisée pour ajouter la mantisse. Cela réduit l’effort de calcul de l’exposant à chaque fois. Une autre possibilité consiste à utiliser le format virgule fixe double. Dans ce cas, un seul bit est utilisé pour représenter l’exposant et la mantisse qui correspond à un nombre signé en virgule fixe. Une telle technique permet de réaliser un compromis entre dynamique et précision en étendant le concept de l’arithmétique virgule flottante. Une troisième alternative utilise un système de nombres en virgule flottante en bloc [24]. Dans ce cas, lorsqu’un groupe de nombres partagent un même exposant, la mantisse de ces nombres peut être différente. Cette technique a été implémentée pour des nombres en virgule flottante dans plusieurs algorithmes de traitement de signal [57] [73] dont notamment la bibliothèque DirectX pour les applications graphiques à haut niveau de dynamique. L’idée commune à toutes ces approches hybrides vise à tirer avantage de la grande plage de dynamique et la haute précision de la représentation en virgule flottante tout en conservant la flexibilité de la représentation en virgule fixe. Conclusion L’arithmétique virgule flottante présente l’avantage d’une dynamique et d’une précision supé- rieures à l’arithmétique virgule fixe. A l’opposé, l’arithmétique virgule fixe, plus flexible, possède des opérateurs moins complexes et conduit à des implémentations moins coûteuses en termes de consommation d’énergie et de ressources matérielles. Cependant, l’implantation en virgule fixe nécessite la maîtrise de la précision des calculs qui est évaluée par des méthodes de simulation ou par des méthodes analytiques que nous présenterons dans la section 1.3. Les méthodes analytiques nécessitent la modélisation des bruits de quantification, c’est pourquoi nous abordons ces notions dans la section suivante. 1.2 Modélisation du bruit de quantification La conversion de la représentation virgule flottante au format virgule fixe conduit à l’élimination de certains bits lors des calculs, ce qui engendre l’apparition de bruits de quantification. Dans cette section, la modélisation du bruit de quantification est évoquée. 1.2.1 Processus de quantification Le mécanisme d’assigner une séquence de chiffres binaires pour une représentation d’une valeur réelle (analogique) x est réalisé par le processus de quantification. L’opération de quantification est présentée dans (1.26), où la valeur du signal x est transformée en une représentation à virgule fixe notée par xˆ : x → xˆ = Q(x). (1.26) Il s’agit d’une procédure non linéaire qui génère une perte de précision puisque seulement un nombre fini de valeurs possibles peuvent être représentées. Plus précisément, lorsque b bits sont utilisés pour représenter un nombre en virgule fixe, 2b valeurs distinctes peuvent être représentées. L’erreur résultante de la différence entre la valeur réelle x et sa représentation en virgule fixe xˆ est appelée bruit de quantification : e(x) = x − x. ˆ (1.27) La résolution de la représentation, notée q, est donnée par la différence minimale entre deux valeurs consécutives représentables. Sa valeur est déterminée par la position du bit de poids le plus faible (LSB) (2−n). Deux modes de quantification sont particulièrement utilisés : la quantification par arrondi et celle par troncature.1.2 Modélisation du bruit de quantification 21 La quantification par arrondi Lorsque la quantification par arrondi est appliquée (figure 1.6), l’amplitude du signal est arrondie au niveau de quantification le plus proche. L’erreur maximale introduite est ±1 2LSB. Par conséquent, l’erreur de quantification introduite (e(x)) dans ce cas est bornée dans l’intervalle ! −q 2 , q 2 $ , soit : xˆ = Q(x) = ∆i + q 2 , ∀x ∈ ]∆i, ∆i+1] . (1.28) Figure 1.6 – Processus de quantification par arrondi La quantification par troncature La méthode de quantification par troncature (figure 1.7) consiste à choisir le niveau de quantification inférieur pour une représentation du signal. Par conséquent, l’erreur de quantification est toujours positive (e(x) ∈ ]0, q]) et un décalage est introduit. On a donc : xˆ = ∆i, ∀x ∈ ]∆i, ∆i+1] . (1.29)22 Arithmétique virgule fixe Figure 1.7 – Processus de quantification par troncature Supposons que le signal x à quantifier soit un signal aléatoire de densité de probabilité (FDP) continue px(x). La quantification de x engendre la génération d’un nouveau signal xˆ de densité de probabilité pxˆ(ˆx) discrète qui est constituée de M valeurs notées pi. Chaque pi est la probabilité que le signal x appartient à un intervalle Ii. Par conséquent, les bornes de l’intervalle Ii sont liées au mode de quantification utilisé (par arrondi ou par troncature). Les valeurs pi sont déterminées par : pi = / Ii px(x)dx. (1.30) Les valeurs discrètes pi sont séparées par le pas de quantification q. Par conséquent la fonction densité de probabilité (FDP) du signal xˆ est : pxˆ(ˆx) = ' M i=1 piδ(ˆx − iq). (1.31) Dans [93], Widrow a montré que lorsque la fonction caractéristique du signal d’entrée x, i.e. la transformée de Fourier de px(x), est nulle alors le signal xˆ peut être modélisé par les deux variables aléatoires (x, e) de densités de probabilité px(x) et pe(e). Par conséquent, le processus de quantification peut être modélisé par l’introduction d’un bruit additif. La sortie du quantificateur est alors égale à la somme du signal d’entrée x et de l’erreur de quantification comme représenté sur la figure 1.8.1.2 Modélisation du bruit de quantification 23 Figure 1.8 – Modélisation de bruit de quantification additif Nous étudierons, dans ce qui suit, plus en détail le bruit de quantification e en différenciant le cas d’un signal d’entrée à amplitude discrète ou à amplitude continue. 1.2.2 Signal à amplitude continue Soit x un signal à amplitude continue avec une FDP continue. Les différents intervalles Ii sont déterminés selon le mode de quantification choisi (arrondi ou troncature). Cas du mode quantification par troncature Dans ce cas, l’intervalle Ii est l’intervalle entre deux valeurs représentables par le codage : Ii = [xi, xi+1[. (1.32) Comme vu précédemment, e(x) ∈ [0, q[. Sa FDP est rectangulaire (figure 1.9), elle est donnée par l’équation : pe(e) = 1 q rect( e − q 2 q ). (1.33) Figure 1.9 – Densité de probabilité de la loi de troncature continue Dans ce cas, la moyenne, la variance et la puissance du bruit de quantification e sont données par les équations suivantes : µe = / ∞ −∞ e pE(e) de = / q 0 1 q e de = q 2 . (1.34)24 Arithmétique virgule fixe σ2 e = / ∞ −∞ (e − µe) 2 pE(e)de = / q 0 1 q ( e − q 2 )2 de = q2 12. (1.35) E(e2) = µ2 e + σ2 e = q2 3 . (1.36) Cas du mode quantification par arrondi Dans ce mode de quantification, l’intervalle Ii et la FDP du bruit de quantification e (figure 1.10) sont définis par : Ii =]pi − q 2 , pi + q 2 [ (1.37) pe(e) = 1 q rect( e q ) (1.38) Figure 1.10 – Densité de probabilité de la loi d’arrondi continu La variance et la moyenne de e s’expriment selon : µe = / ∞ −∞ e p(e)de = / q/2 −q/2 1 q e de = 0 (1.39) σ2 e = / ∞ −∞ (e − µe) 2 p(e)de = / q/2 −q/2 e2 q de = q2 12. (1.40) Sa puissance est alors seulement égale à sa variance de valeur q2 12 . Statistiques du bruit de quantification Auto-corrélation du bruit de quantification e Dans cette section, une étude de la corrélation entre deux bruits est présentée. Nous considérons deux variables aléatoires e1 et e2. La FDP conjointe des deux bruits est définie dans [96] par : pe1,e2 (e1, e2) = rect( e1 q )rect( e2 q )[px1,x2 (x1, x2) ∗ (f(e1).f(e2))] (1.41) où * désigne le produit de convolution. Dans [96], il a été montré que la FDP conjointe s’écrit : pe1,e2 (e1, e2) = 1 q rect( e1 q ) 1 q rect( e2 q ) = pe1 (e1)pe2 (e2). (1.42)1.2 Modélisation du bruit de quantification 25 Par conséquent, la FDP conjointe est décomposée en un produit des FDP des deux bruits indépendants. De plus, en supposant les processus aléatoires stationnaires, la fonction d’auto-corrélation Ree(θ) à un instant θ est définie par l’expression suivante : Ree(θ) = σ2 e δ(θ) + µ2 e. (1.43) avec δ distribution de Dirac. L’erreur de quantification est donc un bruit blanc. Pour une valeur nulle de θ, la puissance est retrouvée. Corrélation avec le signal Le moment d’ordre 2 du signal quantifié xˆ est étudié. Puisque xˆ = x + e, le moment d’ordre 2 est : E(ˆx2) = E(x2) + E(e2)+2E(xe). (1.44) D’autre part, le moment d’ordre 2 est la dérivée seconde de la fonction caractéristique à l’origine. Par conséquent la dérivée seconde de la fonction caractéristique de xˆ donne une nouvelle expression de la corrélation entre x et e, suivant : E(xe) = '∞ i=−∞ qΦ(−i 2π q ) (−1)i πi . (1.45) Donc si Φ(−i 2π q )=0 quelle que soit la valeur de i, l’erreur de quantification n’est pas corrélée au signal. Cette condition est vérifiée dès que le pas de quantification q est inférieur à l’écart-type du signal [96]. Dans le cas contraire, le bruit généré a une puissance supérieure à celle du signal et le bon fonctionnement du système n’est plus assuré. Conclusion Pour conclure, nous pouvons retenir que le bruit généré par la quantification d’un signal à amplitude continue est un bruit blanc, additif, non corrélé avec le signal et indépendant des autres signaux. De plus, sa distribution est uniforme sur son espace de représentation. 1.2.3 Signal à amplitude discrète Nous nous intéressons dans cette section à l’étude d’un signal à amplitude discrète dont la quantification est effectuée par élimination de plusieurs bits d’une donnée. Cette conversion conduit à la génération d’un bruit à amplitude discrète. Les caractéristiques de ce bruit diffèrent selon le mode de quantification considéré. Loi de quantification par troncature L’implantation de cette loi est très simple puisque seulement les bits les plus significatifs sont conservés. La figure 1.11 représente la distribution du bruit où k représente le nombre de bits éliminés.Un modèle fondé sur une équiprobabilité entre les valeurs 0 et 1 est présenté dans [31]. La moyenne et la variance de e sont données par les équations suivantes : µe = q 2 (1 − 2−k) (1.46) σ2 e = q2 12(1 − 2−2k). (1.47)26 Arithmétique virgule fixe Figure 1.11 – Densité de probabilité de la loi de troncature discrète Loi de quantification par arrondi Dans le cas où l’amplitude de signal est discrète, le domaine de représentation n’est pas centré sur 0. Par conséquent, le problème consiste à déterminer la valeur à affecter à une donnée sur la médiane d’un intervalle de représentation pi + q 2 . Cette valeur est fixée à la valeur supérieure représentable pi+1. Par conséquent, ce choix conduit à une moyenne non nulle de l’erreur et un biais plus faible que dans le mode de quantification par troncature. Le signal quantifié xˆ est donné par l’expression suivante : y = Q(x) =    pl si pl ≤ x 0 = [axmax, axmin] si a < 0. (1.62) Cette technique comporte une limitation importante liée à l’estimation pessimiste faite de l’intervalle de définition des données qui devient parfois très large car le résultat fourni est celui du pire cas puisque cette arithmétique ne prend pas en compte les corrélations entre les données. De plus, cette méthode ne s’applique que lorsque la sortie ne dépend que des valeurs d’entrée. Arithmétiques Affines (AA) L’arithmétique affine a été proposée dans [36] afin de s’affranchir des inconvénients de l’arithmétique d’intervalles, et particulièrement de la non prise en considération de la corrélation entre les données. Soit x une donnée décomposée de la façon suivante : x = x0 + 'n i=1 $ixi avec $i ∈ [−1, 1]. (1.63) Les symboles $i sont indépendants et représentent les coordonnées de x sur les composantes xi qui sont les bornes de x. Par conséquent, x0 est la moyenne des valeurs possibles prises par x. Le qualificatif affine vient du fait du développement d’une forme affine en fonction des symboles $i, lors de la propagation des intervalles de définition dans les opérations. L’intérêt de cette méthode est la prise en compte de la corrélation entre les différentes données. Soient x et y deux données décomposées de la façon suivante : x = x0 + 'n i=1 $ixi, (1.64)1.3 Évaluation de la précision 35 y = y0 + 'n i=1 $iyi. (1.65) Pour la somme de ces deux données, c’est une fonction affine des symboles $i : x + y = x0 + y0 + 'n i=1 $i(xi + yi). (1.66) En ce qui concerne l’opération de la multiplication, l’opération xy n’est plus une fonction affine car elle s’écrit selon : xy = x0y0 + 'n i=1 (x0yi + y0xi)$i + 'n i=1 xi$i 'n j=1 yj $j . (1.67) Afin de rendre l’opération sous une forme affine, une majoration du dernier terme de l’équation précédente est introduite par l’introduction de zn+1 tel que : zn+1 > 'n i=1 |xi| 'n j=1 |yj |. (1.68) Par conséquent la multiplication de x par y introduit le symbole $n+1 qui est le facteur associé à zn+1 et s’écrit sous cette forme : x + y = x0y0 + 'n i=1 (x0yi + y0xi)$i + zn+1$n+1. (1.69) Cette arithmétique fournit un intervalle plus fin que celui donné par l’arithmétique d’intervalles puisqu’elle utilise les corrélations spatiales entre les données. Cependant, cette technique produit parfois un intervalle trop lâche car elle ne tient pas compte des corrélations temporelles. Elle peut donc être limitée pour des applications de traitement du signal où les données sont temporellement corrélées (par exemple, les filtres FIR). Méthode basée sur la théorie de la perturbation Wadekar propose dans [91] une approche analytique pour évaluer les bornes de l’erreur de quantification basée sur un développement de Taylor d’ordre 2 de l’erreur en sortie. Soit un opérateur à deux entrées u et v et δu et δv les erreurs au pire cas sur ces données. La fonction de sortie de cet opérateur est f(u, v). L’erreur en sortie s’écrit comme suit : δf = ∂f ∂u(δu) + ∂f ∂v (δv) + 1 2! : ∂2f ∂u2 (δu) 2 + 2 ∂2f ∂u∂v (δuδv) + ∂2f ∂v2 (δv) 2 ; . (1.70) Cette approche, basée sur la propagation des bruits au sein du système, s’applique aussi bien sur des systèmes LTI que non-LTI. Cependant, elle ne peut être appliquée dans le cas de systèmes récursifs ainsi que celui des systèmes itératifs composés d’opérateurs non lisses et non linéaires en termes de bruit. Approches analytique de la puissance de bruit Le bruit engendré par la quantification d’un signal est donné par le modèle PQN. Les contributions du bruit causé par une quantification grossière des signaux déjà quantifiés suivent aussi les dynamiques du théorème de quantification. La puissance de quantification est calculée comme une fonction des moments de premier ordre et du second ordre du signal d’erreur de quantification. L’amplitude du bruit de quantification injecté dans le système par différentes opérations en arithmétique virgule fixe est déterminée selon le format virgule fixe choisi ainsi que le mode de quantification. Si le format virgule fixe est suffisamment large, aucun bruit de quantification est injecté.36 Arithmétique virgule fixe Propagation du bruit et théorie de la perturbation Le changement infinitésimal, créé en sortie du système en raison des calculs en arithmétique virgule fixe, n’affecte pas le comportement macroscopique total du système. L’application de la théorie de perturbation est essentiellement une alternative pour estimer approximativement l’impact de la quantification sous certaines circonstances. Les erreurs causées par le calcul avec des opérateurs en arithmétique virgule fixe sont des petites perturbations dont l’effet sur la sortie peut être maîtrisé avec un bon degré de précision à l’aide de techniques d’approximation linéaire. En effet, cette approximation introduit une tolérance envers les erreurs de quantification pour une application et pose la question de la petite taille du pas de quantification qui devrait être choisi pour être classifiée comme lisse (smooth). Mention contraire, on peut supposer que les quantificateurs sont lisses. En outre, l’opérateur luimême peut être considéré comme lisse ou non lisse en fonction de son comportement fonctionnel. Une opération est considérée comme lisse si la sortie est une fonction continue et différentiable de ses entrées. La technique de propagation du bruit basée sur la théorie des perturbations, tel que présenté dans la présente section, est applicable seulement aux systèmes comprenant des opérateurs lisses et quantificateurs lisses. Figure 1.17 – Propagation du bruit de quantification vers la sortie du système Considérons un opérateur binaire dont les entrées sont x et y et la sortie est z. Si les signaux d’entrée sont perturbés par les bruits bx et by pour obtenir respectivement xˆ et yˆ, la sortie est perturbée par bz pour obtenir zˆ. En d’autres termes, tant que l’opérateur en virgule fixe est lisse, l’impact de petites perturbations à l’entrée se traduit par une perturbation en sortie de l’opérateur sans aucune modification de son comportement macroscopique. Selon la théorie des perturbations, le bruit en sortie bz est une combinaison linéaire des bruits en entrée bx et by : bz = v1bx + v2by. (1.71) Dans ce cas, l’hypothèse sous-jacente est que les termes de bruit bx et by ne soient pas corrélés entre eux, ni avec les signaux d’entrée. Cette hypothèse découle de l’hypothèse suivante relative au modèle PQN de génération du bruit de quantification : le bruit de quantification est indépendant du signal. Les termes v1 et v2 sont obtenus à partir de l’approximation de Taylor du premier ordre de la fonction continue et différentiable f : z = f(x, y) $ f(x, y) + ∂f ∂x(x, y).(x − x) + ∂f ∂y (x, y).(y − y). (1.72) Par conséquent, les termes v1 et v2 sont donnés par : v1 = ∂f ∂x(x, y) v2 = ∂f ∂y (x, y). (1.73) Les termes v1 et v2 peuvent varier dans le temps. De plus, cette méthode n’est pas limitée uniquement aux opérations mais elle peut être appliquée au niveau fonctionnel sur tous les opé-1.3 Évaluation de la précision 37 rateurs appartenant à un même chemin de données et ainsi propager le bruit de quantification de la source jusqu’à la sortie. Soit y, le signal en sortie du système, le bruit correspondant by causé par la quantification est obtenu par la somme de la contribution individuelle des sources de bruit dans le système comme montré dans la figure 1.17. Si hi(n) représente la réponse impulsionnelle du chemin entre la i ème source de bruit et la sortie du système, la contribution de la source de bruit by est calculée par la somme de produits de convolution de la source de bruit et de la réponse impulsionnelle. Considérons un système comportant, à son entrée, N sources de bruit bi, i = 1, ..., N. Il existe alors N chemins indépendants entre chaque source de bruit présente en entrée et la sortie du système. La contribution de la source de bruit bi peut alors être calculée en prenant en compte la réponse impulsionnelle hi(k), k = 0, 1, ... du chemin entre la i ème source de bruit et la sortie du système. Le bruit global en sortie by s’exprime alors comme la somme des N produits de convolution individuels. Dans le cas où les réponses impulsionnelles varient dans le temps, il est donné par : by = ' N i=1 '∞ k=−∞ hi(k, n)bi(n − k) (1.74) où hi(k, n) représente le kième coefficient de la réponse impulsionnelle mesurée à l’instant n. La puissance du bruit en sortie est obtenue comme le moment du second ordre du bruit à la sortie du système et elle est donnée par : E[b2 y] = E([' Ne i=1 '∞ k=−∞ hi(k, n)bi(n − k))2] = ' Ne i=1 '∞ k=−∞ E[h2 i(k, n)]E[bi(n − k) 2] + ' Ne i=1 ' Ne j=1,j&=i '∞ k=−∞ '∞ l=−∞,l&=k E[hi(k, n)hj (l, n)]E[bi(n − k)bj (n − l)]. (1.75) L’expression précédente peut se mettre sous la forme d’une somme des paramètres statistiques de la source du bruit comme suit : E[b2 y] = ' Ne i=1 Kiσ2 bi + ' Ne i=1 ' Ne j=1,j&=i Lijµbiµbj (1.76) où µbi et σbi désignent respectivement la valeur moyenne et la variance du bruit présent à l’entrée numéro i. Les termes Ki et Lij sont constants et dépendent de la réponse impulsionnelle hi associée au chemin n˚i. Cette approche supporte les systèmes récursifs et non récursifs dans le cas des systèmes LTI (Linear-Time Invariant) et non-LTI. L’expression de ces coefficients est : Ki = '∞ k=−∞ E[h2 i(k)], (1.77) Lij = '∞ k=−∞ '∞ l=−∞ E[hi(k)hj (l)]. (1.78) Afin de déterminer les différentes réponses impulsionnelles caractérisant les relations entrées/sortie, le graphe flot de données est partitionné en plusieurs sous-graphes acycliques à des fins d’analyse. En utilisant le modèle de propagation, les fonctions des chemins de ces sous graphes sont déterminées dans le domaine de la transformée en Z. La fonction individuelle de chemin de chaque source de bruit jusqu’à la sortie est obtenue à l’aide de la combinaison des fonctions de ces sous-graphes par substitution de variable. Une autre technique basée sur l’arithmétique affine est proposée dans [54][44] respectivement pour les systèmes LTI et non-LTI. Cette technique consiste à définir une forme affine pour chaque38 Arithmétique virgule fixe source de bruit dans le système en prenant en compte sa valeur moyenne et sa variance. Profitant de l’avantage du modèle de propagation linéaire, les formes affines de bruit sont propagées à travers le système par simulations. Les valeurs de Ki et Lij sont obtenues par l’estimation des formes affines à partir de l’expression du bruit en sortie. Dans le cas d’un systèmes récursif, cette opération est répétée plusieurs fois jusqu’à obtenir convergence de la forme affine caractérisant le bruit en sortie. Dans [85], les coefficients de l’expression de la puissance de bruit en sortie dans l’équation (1.76) sont obtenus à partir du développement au second ordre de la différence entre les expressions du bruit en arithmétique virgule fixe et en arithmétique virgule flottante. Dans ce cas, les coefficients de Taylor sont directement liés aux coefficients Li et Kij présentés précédemment. Ils sont obtenus en résolvant un système d’équations linéaires en effectuant le minimum de simulations en virgule fixe ainsi qu’une seule simulation en virgule flottante. 1.3.4 Autres effets de la quantification Nous avons jusqu’à présent concentré notre analyse sur l’erreur de quantification engendrée par la représentation en arithmétique virgule fixe des données présentes en entrée d’un opérateur. Cependant, l’opération de quantification en arithmétique virgule fixe peut également modifier le comportement global d’un système notamment lorsque l’opération de quantification porte sur les paramètres décrivant ce système. Certains changements peuvent ainsi être particulièrement importants puisqu’ils peuvent affecter la stabilité du système dans certains cas. Ces effets sont étudiés essentiellement selon deux catégories. La première catégorie est l’impact de la quantification des paramètres du système. Dans [55], l’effet de la quantification des coefficients sur les bornes de l’intervalle du signal en sortie est déterminé. A partir des outils d’analyse de l’arithmétique d’intervalles et de l’arithmétique affine, il est ainsi démontré que, dans certains cas, la quantification des coefficients d’un système peut engendrer, en sortie du système, un bruit dont la puissance est plus importante que celle obtenue lors de la quantification des données présentes à l’entrée du système. L’effet de la quantification d’un coefficient sur la sensibilité d’un système global est également étudié dans le domaine de la transformée en z et celui de la transformée de Fourier par les auteurs de [45] et [87]. Enfin, signalons également l’approche proposée dans [51] permettant d’évaluer cette sensibilité à partir d’une technique relativement simple basée sur la simulation. L’effet non linéaire engendré par le processus de quantification peut également jouer un rôle fondamental dans le cas où le système comporte des boucles récursives. Cette situation constitue le cadre principal de ce travail de thèse, et plus particulièrement celui obtenu lorsque ces boucles sont constituées d’opérateurs non lisses tels que les opérateurs de décision. Ainsi, sous certaines conditions, des oscillations peuvent apparaître en sortie du système [71], [86]. Il est alors important de pouvoir détecter l’apparition de cycles limites engendrés par l’opération de quantification. D’autres travaux , e.g. [20], [21], et [90], précisent les conditions garantissant la stabilité asymptotique d’un système. Ces études sont essentiellement basées sur des approches par simulations en raison de la difficulté mathématique rencontrée pour obtenir des expressions analytiques. Aussi, afin de limiter le temps requis pour réaliser ces simulations de façon exhaustive [56], d’autres travaux [53] ont permis d’accélérer l’étape de simulation en utilisant conjointement des techniques d’analyse basées sur l’arithmétique affine. 1.3.5 Bilan des deux approches En premier lieu, les techniques statistiques par simulations en virgule fixe sont particulièrement intéressantes en raison de leur simplicité de réalisation mais également puisqu’elles s’appliquent directement à n’importe quel type de système (linéaire, non linéaire, bouclé, ...). Malheureusement, afin d’obtenir des résultats statistiquement significatifs, il est nécessaire de réaliser ces simulations sur un nombre important de données en entrée (Monte Carlo) ce qui conduit rapi-1.3 Évaluation de la précision 39 dement à des temps de simulation prohibitifs, et plus particulièrement lorsqu’il est nécessaire de balayer l’espace complet des formats en virgule fixe. L’autre approche est l’approche d’évaluation basée sur les modèles analytiques pour évaluer mathématiquement une métrique de précision. Cette approche est basée sur l’évaluation du comportement de bruit par le biais d’une expression mathématique dont le calcul n’est effectué qu’une seule fois. Une fois cette expression analytique disponible, les paramètres statistiques décrivant le bruit s’obtiennent directement et en une seule fois. Par conséquent le temps nécessaire pour l’évaluation de la précision est relativement limité puisqu’il correspond au coût de l’évaluation de cette expression analytique. Ce temps est donc nettement plus faible que celui requis par les approches basées sur la simulation en virgule fixe (cf. figure 1.18). Cependant, l’obtention d’une expression analytique décrivant les propriétés statistiques du bruit de quantification peut se révéler difficile pour certains types de systèmes notamment ceux possédant des opérateurs non lisses. Figure 1.18 – Les temps d’optimisation des deux approches en fonction de nombre d’évaluation 1.3.6 Les approches hybrides Afin d’accélérer les temps d’optimisation, des approches hybrides basées conjointement sur des modèles analytiques et sur des simulations ont été proposées [75]. Ces approches consistent à utiliser des modèles analytiques afin de décrire les éléments du système comportant des opérateurs élémentaires tels que additions, multiplications,..., mais également à utiliser la simulation pour évaluer le comportement d’opérateurs complexes tels que les opérateurs non lisses (un-smooth). Une étape d’évaluation sélective partitionne tout d’abord l’ensemble du système en plusieurs grappes d’opérateurs lisses séparées par des opérateurs non lisses. Pour chaque grappe d’opérateurs lisses, un modèle de sources de bruits est dérivé afin d’analyser l’effet des opérations de quantification, puis ces valeurs sont propagées à travers le système jusqu’à ce qu’un opérateur non lisse soit rencontré. Dans cette approche hybride, les grappes d’opérateurs lisses sont évaluées par le biais d’une approche analytique et les opérateurs non lisses sont évalués par le biais de simulations. Une telle approche permet d’utiliser pleinement les modèles analytiques pour estimer le comportement des blocs lisses, soit donc de bénéficier au maximum de leurs avantages.40 Arithmétique virgule fixe 1.4 Conclusion Nous avons vu dans ce chapitre les différentes types de codage de données et en particulier celui relatif à l’arithmétique en virgule fixe. Cette arithmétique possède d’immenses avantages pratiques essentiellement pour les applications de traitement numérique de signal. Cependant, elle conduit à la génération de bruit de quantification qui se propage au sein de l’application et modifient la précision des calculs. Ainsi, l’évaluation de la précision en virgule fixe est une étape primordiale dans la conception des systèmes en virgule fixe. Afin d’évaluer cette précision, deux approches fondamentales ont été présentées : l’approche par simulation et l’approche analytique. Cette dernière est basée sur l’évaluation d’une métrique de précision par le biais d’une expression mathématique ce qui permet de réduire le temps d’optimisation par rapport à celui requis par l’approche par simulation qui devient prohibitif lorsqu’il s’agit de balayer l’espace des formats en virgule fixe. Les techniques d’évaluation de la précision par les modèles analytiques restent cependant limitées à des systèmes comportant des opérateurs lisses. Par conséquent, il est in- évitable d’utiliser les techniques basées sur la simulation pour certaines applications (ou parties d’application) comportant des opérateurs non lisses (un-smooth operators). Une approche hybride basée sur la combinaison des deux approches pour les applications comportant des opérateurs non lisses a été proposée dans [75]. Toujours dans l’optique de l’amélioration des temps d’optimisation, nous proposons dans le prochain chapitre, une approche purement analytique d’évaluation de la précision pour les opérateurs non lisses qui sera appliquée à l’évaluation de la précision en virgule fixe des algorithmes de décodage sphérique tel que le SSFE (Selective Spanning with Fast Enumeration) composé d’opérateurs lisses et d’opérateurs non lisses (opérateurs de décision).Chapitre 2 Évaluation analytique de la précision des algorithmes de décodage sphérique Sommaire 2.1 Les opérateurs lisses et non lisses . . . . . . . . . . . . . . . . . . . . . . 42 2.1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 2.1.2 Les opérateurs lisses et non-lisses . . . . . . . . . . . . . . . . . . . . . . 43 2.1.3 La quantification d’un opérateur non lisse . . . . . . . . . . . . . . . . . 44 2.1.4 Identification d’un opérateur non lisse . . . . . . . . . . . . . . . . . . . 44 2.2 Modèle analytique pour l’opérateur de décision . . . . . . . . . . . . . 47 2.2.1 Modélisation de l’opérateur de décision . . . . . . . . . . . . . . . . . . 47 2.2.2 La réponse à la perturbation . . . . . . . . . . . . . . . . . . . . . . . . 49 2.2.3 La probabilité d’erreur de décision . . . . . . . . . . . . . . . . . . . . . 50 2.3 Cascade d’opérateurs de décision . . . . . . . . . . . . . . . . . . . . . . 54 2.3.1 Propagation de l’erreur de quantification . . . . . . . . . . . . . . . . . . 55 2.3.2 Détermination analytique de la probabilité d’erreur en sortie de la cascade 56 2.3.3 Analyse de la complexité du modèle analytique . . . . . . . . . . . . . . 59 2.4 Application du modèle à l’algorithme SSFE . . . . . . . . . . . . . . . 60 2.4.1 Modèle du système MIMO . . . . . . . . . . . . . . . . . . . . . . . . . 61 2.4.2 Présentation de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . . . 62 2.4.3 Application du modèle analytique proposé . . . . . . . . . . . . . . . . . 64 2.4.4 Première approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Par rapport à la précision infinie, l’utilisation d’opérations en virgule fixe introduit un bruit de quantification qui modifie la valeur des nombres. Les erreurs de quantification dont les caracté- ristiques ne peuvent pas être déterminées par le modèle PQN sont classées comme des erreurs non lisses (un-smooth). En effet, ce modèle fonctionne correctement tant que le pas de quantification reste faible devant la dynamique du signal comme dans le cas des opérations en arithmétique virgule fixe. Dans le cas des opérateurs non lisses, les erreurs de quantification sont très grandes et souvent comparables à la dynamique du signal quantifié. Dans ce cas, les hypothèses de validité du modèle PQN ne sont plus vérifiées et donc le signal quantifié sera éloigné de la valeur vraie. Un modèle analytique visant à prédire les statistiques de l’erreur à la sortie d’un opérateur non lisse nécessite la connaissance du signal en entrée et les caractéristiques du bruit de quantification associé. De plus, en présence de plusieurs opérateurs non lisses, les caractéristiques de l’erreur de quantification ne sont pas uniquement corrélées avec le signal, mais aussi avec les autres erreurs issues des opérateurs non lisses précédents. Il convient de préciser que dans le cas des 4142 Évaluation analytique de la précision des algorithmes de décodage sphérique opérateurs non lisses, il n’existe pas de modèle analytique permettant d’évaluer leurs précisions en arithmétique virgule fixe. L’objectif de ce chapitre est de proposer un modèle analytique pour évaluer la précision de l’algorithme de décodage sphérique SSFE. Nous commençons par proposer, dans la première section, une étude des différents types d’opérateurs. Nous présentons dans la seconde partie un modèle analytique pour évaluer la précision d’un opérateur non lisse correspondant à l’opérateur de décision en se basant sur la probabilité d’erreur de décision causée par la quantification. La troisième partie du chapitre est consacrée à l’extension de cette méthode au cas d’une cascade d’opérateurs de décision. Enfin, le modèle analytique proposé sera appliqué, dans la dernière partie du chapitre, à l’algorithme de décodage sphérique SSFE. 2.1 Les opérateurs lisses et non lisses Dans cette section, nous présentons les différents types d’opérateurs présents dans les systèmes numériques en faisant la distinction entre opérateurs lisses et non lisses. 2.1.1 Introduction Généralement, les signaux présents en entrées d’un système numérique peuvent être considérés comme des processus aléatoires à temps discret [76], [84]. En revanche, les opérateurs présents dans un système peuvent souvent être traités comme des opérations déterministes qui produisent des processus aléatoires sur leurs sorties sous un environnement de signaux stochastiques [83]. A un instant donné t, chaque signal en entrée, en interne, ou en sortie, est considéré comme une variable aléatoire prenant ses valeurs dans un ensemble de réalisations qui lui est propre (possiblement différent de celui des autres entrées). Chacune de ces variables aléatoires possède une densité de probabilité pouvant varier au cours du temps. Dans ce cas, les signaux sont qualifiés de processus aléatoires non-stationnaires. Dans la réalité, un opérateur O possède un nombre fini K d’entrées représentées par un vecteur (x1, x2, ..., xK)t à l’instant t. Ce vecteur est traité comme un vecteur dont les composantes sont des variables aléatoires, possiblement non stationnaires. Par opérateur, nous entendons par exemple un simple additionneur ou bien, à l’extrême, un système complexe tel qu’un système de communication. Les entrées peuvent être des entrées classiques en chemin de données comme les entrées d’un additionneur, ou bien des entrées constantes comme les coefficients constants d’un filtre LTI ou des paramètres de mise à jour adaptatifs. A l’instant t, une réalisation d’ensemble du vecteur aléatoire (x1, x2, ..., xK)t devient un vecteur régulier appartenant à un domaine Ωt qui consiste en l’ensemble global de réalisations possibles à l’instant t. Dans le cas où des signaux booléens Vrai et Faux sont traités comme des nombres réels tel que 0 et 1 respectivement, Ωt est un sous ensemble de l’espace Euclidien RK de dimension K. Le vecteur aléatoire (x1, x2, ..., xK)t est considéré dans le domaine Ωt : (x1, x2, ..., xK)t ∈ Ωt. (2.1) Soit t>t1 > t2 > ... > 0 et supposons que le système commence à fonctionner à partir de l’instant t=0. A un instant t quelconque, la sortie d’un opérateur causal O dépend de toutes les entrées actuelles et précédentes {(x1, x2, ..., xK)t,(x1, x2, ..., xK)t1 , ...,(x1, x2, ..., xK)tN , ...,(x1, x2, ..., xK)0} et possiblement d’un état interne d’initialisation. Dans un système à échantillonnage régulier, l’instant ti correspond simplement à t − i. Les variables internes décrivant l’état initial sont traitées comme des entrées additionnelles apportées au système par des additionneurs à l’instant 0. Par soucis de concision, nous ne tiendrons pas compte de cet état interne d’initialisation. La sortie de O est donnée par fO(x1, x2, ..., xK, t) où fO est la fonction de transfert de O pouvant s’exprimer par : fO(x1, x2, ..., xK, t) = ΦO,t ((x1, x2, ..., xK)t,(x1, x2, ..., xK)t1 , ...,(x1, x2, ..., xK)0). (2.2)2.1 Les opérateurs lisses et non lisses 43 La fonctionnalité de O à l’instant t est uniquement exprimée par la fonction ΦO,t considérée comme la fonction de transfert instantanée de O à l’instant t. Dans ce cas le vecteur aléatoire des entrées de dimension K×(N+2) {(x1, x2, ..., xK)t,(x1, x2, ..., xK)t1 , ...,(x1, x2, ..., xK)tN ,(x1, x2, ..., xK)0} est désigné par le vecteur {ξ1, ξ2, ..., ξM} comme suit : ξ1 = x1(t), ξ2 = x2(t), ..., ξK = xK(t), ξK+1 = x1(t1), ξK+2 = x2(t1), ..., ξ2K = xK(t1), ... ξM−K+1 = x1(0), ξM−K+2 = x2(0), ..., ξM = xK(0). (2.3) avec M = K × (N + 2). Les quantités (ξ1, ξ2, ..., ξM) sont appelées les variables étendues de (x1, x2, ..., xK) à l’instant t par rapport à l’opérateur O. Par conséquent la sortie de l’opérateur O à l’instant t est réduite à : fO(x1, x2, ..., xK, t) = ΦO,t(ξ1, ξ2, ..., ξM). (2.4) En utilisant la relation (2.4), une valeur numérique de la sortie est disponible seulement avec une réalisation d’ensemble de vecteur aléatoire (ξ1, ξ2, ..., ξM). Les variables étendues correspondent également à un domaine étendu : (ξ1, ξ2, ..., ξM) ∈ Ωt × Ωt1 × ... × Ω0. (2.5) Il est important de noter que fO est une fonction déterministe. Lorsqu’un système est désigné physiquement, une fonction déterministe est souvent exécutée pour traiter certaines entrées aléatoires. Ceci est généralement accepté dans la modélisation des systèmes de traitement numérique de signal. Des exemples d’opérateurs (additionneur, multiplexeur, ...) sont manipulés selon cette modélisation dans [83]. En résumé, tous les facteurs aléatoires caractérisant la sortie d’un opérateur sont introduits par ses entrées aléatoires, alors que la fonction de transfert ΦO,t est une fonction déterministe connue (comme une fonction du temps t). 2.1.2 Les opérateurs lisses et non-lisses Le concept du caractère lisse d’un opérateur est à la base de la théorie des perturbations. Comme défini dans [83], une fonction déterministe ΦO,t est considérée comme lisse sur les signaux quantifiés si elle est continue et dérivable de n’importe quel degré sur un ensemble ouvert dans lequel les signaux arithmétiques font partie, quelles que soient les réalisations des signaux logiques.L’opération O est appelée lisse sur ses entrées arithmétiques, ou brièvement lisse. Dans [83], il a été montré que la dérivabilité de degré 3 est toujours suffisante afin de modéliser les effets de quantifications. Nous pouvons remarquer que le caractère lisse ou non lisse d’un opérateur n’a pas de sens lorsque ses entrées correspondent à des signaux logiques. En revanche, des opérateurs de base tels que additionneurs ou multiplieurs sont lisses. Considérons, par exemple, l’opérateur I inverseur dont la fonction de transfert est donnée par : fI (x, t) = ΦI,t(ξ1, ..., ξM)=1/ξ1. (2.6) Où ξ1 est un signal arithmétique. Il est clair que ΦI,t est lisse si ses entrées appartiennent à ] − ∞, 0[∩]0, +∞[. Par conséquent, cette fonction est lisse sur ce domaine et elle est considérée comme non lisse dans R puisqu’elle n’est plus de classe C1. De même, l’opérateur valeur absolue est lisse sur le même domaine mais pas sur R puisqu’elle n’est pas de classe C1. En fait, la plupart des opérations mathématiques sont lisses sur leurs domaines de définition. D’après ces définitions, les opérateurs de décision avec des entrées arithmétiques et des sorties logiques sont des opérateurs non lisses, mais, ils peuvent être traités comme lisses sur un domaine44 Évaluation analytique de la précision des algorithmes de décodage sphérique de définition bien particulier où les entrées appartiennent à la même région de décision. Les régions non lisses contiennent les entrées arithmétiques qui produisent différentes décisions en ajoutant une perturbation infiniment petite. De plus, d’après [83], un opérateur est non lisse sur un domaine donné si sa fonction caractéristique n’est pas de classe C1 sur ce domaine. 2.1.3 La quantification d’un opérateur non lisse En terme de quantification, nous pouvons considérer un opérateur comme non lisse si la dé- viation des statistiques actuelles de l’erreur issue de sa quantification est suffisamment importante devant les statistiques de l’erreur déterminée par le modèle PQN. Il convient de noter que si la fonction caractéristique de la FDP du signal en entrée est à bande limitée, l’erreur d’estimation est toujours présente. L’amplitude de cette erreur augmente en fonction du pas de quantification. L’acceptabilité de l’erreur est donc un paramètre défini par l’utilisateur. Un compromis doit être trouvé entre (i) l’introduction d’une erreur de quantification importante ce qui permet de considérer certains opérateurs quantifiés dans le système comme étant lisses, et (ii) la maîtrise d’une erreur de quantification limitée qui rend la plupart des opérateurs comme non lisses. Par ailleurs, sachant que l’un des opérateurs en arithmétique virgule fixe est lisse, nous pouvons en déduire le caractère lisse d’autres opérateurs de la connaissance de la largeur de bande du signal dans le domaine de sa fonction caractéristique. 2.1.4 Identification d’un opérateur non lisse Dans un scénario pratique, un système en arithmétique virgule fixe consiste en un certain nombre d’opérations de quantification. Les estimations analytiques obtenues en utilisant le modèle PQN peuvent être erronées lorsqu’elles sont appliquées sur la quantification d’un opérateur non lisse. Par conséquent, il est important de classifier les opérateurs comme lisses ou non lisses en se basant sur les caractéristiques du signal à quantifier et le pas de quantification. Nous proposons dans cette section une technique basée sur le calcul de la fonction caractéristique pour vérifier l’applicabilité du modèle PQN dans le cas de n’importe quel opérateur de quantification uniforme. Cette technique identifie les bornes du pas de quantification afin que le modèle PQM puisse être appliqué pour modéliser le comportement de l’erreur. Cette stratégie considère tout d’abord la totalité des opérations de quantification impliquées dans le graphe du système G constitué par Nop opérateurs reliés par Nc connexions (figure 2.1). Figure 2.1 – Graphe du système Un opérateur est représenté par l’un de ces nœuds et comporte des connexions multiples en entrée et une seule connexion en sortie. En cas d’implémentation utilisant une précision finie, une telle opération peut essentiellement être représentée par le schéma de l’opérateur suivi de l’opération de quantification. Les schémas de l’opération pour les deux précisions finie et infinie sont montrés par la figure 2.2.2.1 Les opérateurs lisses et non lisses 45 Figure 2.2 – Schéma d’un opérateur dans la précision infinie et la précision finie avec b bits Dans le cas d’une implémentation en arithmétique virgule fixe, les entrées des opérateurs sont aussi quantifiées. L’effet de la quantification de l’entrée est couvert par les quantificateurs présents à la sortie du nœud opérateur à partir duquel le signal provient. Par conséquent, un quantificateur peut être associé avec chaque signal. L’effet des entrées quantifiées a un impact sur le comportement de l’erreur à la sortie de l’opérateur considéré. Dans un tel scénario, il est possible d’avoir les effets de la double quantification (annexe A). Cependant, une quantification répétée ne change pas fondamentalement la dynamique. Ainsi, pour évaluer le caractère lisse de chaque opérateur quantifié, il suffit de travailler avec les statistiques des données en double précision à tous les points d’intérêt. La technique développée est présentée dans cette section. Cette technique commence par considérer que tous les opérateurs quantifiés avec un quanti- ficateur Qi sont lisses. Ensuite, des simulations en arithmétique virgule flottante, d’un ensemble exhaustif des vecteurs tests, sont utilisées afin de déterminer les caractéristiques de la FDP fxi (xi) du signal à l’entrée du i eme quantificateur Qi. D’autres techniques alternatives peuvent être utilisées pour estimer la FDP du signal comme par exemple les techniques analytiques présentées dans [75]. La seconde étape consiste en un test de déviation de l’erreur. Pour cela, il est tout d’abord nécessaire d’évaluer, soit analytiquement ou soit par simulation [92], le nombre minimal de bits b du quantificateur (Qb i = b) tels que la déviation $b i du i ème signal d’entrée soit quasi nulle, soit donc que l’opérateur quantifié avec Qi puisse être considéré comme lisse. Une fois ceci réalisé, l’utilisateur fixe un seuil τi correspondant à la tolérance autorisée sur l’erreur d’estimation. Ce seuil peut être spécifique à un quantificateur donné ou bien alors il peut être fixé de manière uniforme à une valeur donnée qui sera appliquée à l’ensemble des quantificateurs du système. Tant que la déviation par rapport au modèle PQN est plus petite que la tolérance à l’erreur (|$b i| < τi), le nombre de bits affectés continue à être décrémenté par 1 et la déviation par rapport au modèle PQN $b i est évaluée de nouveau pour la nouvelle longueur du mot de code affectée. $ b i = Evaluer(fxi , 2−b ). (2.7) Cette opération se répète sous forme d’une boucle. A chaque itération de la boucle, l’opérateur quantifié peut être considéré comme non lisse. Afin de réduire le nombre d’exécutions de la boule, il est également possible d’utiliser une variante de la méthode précédente qui consiste à remplacer l’opération de décrémentation binaire par une procédure de recherche binaire. Lorsque la déviation de l’erreur est supérieure à la tolérance (|$i| b ≥ τi), cela signifie que l’opérateur quantifié qui était lisse jusqu’à l’étape de quantification précédente devient maintenant non lisse. En d’autres termes, cette transition marque la frontière entre le pas de quantification lisse et non lisse pour le signal associé au i eme opérateur. Par conséquent, la valeur de b + 1 est affectée à Qi b afin de marquer la plus petite longueur du mot de code en vertu de laquelle l’opérateur peut être considéré comme lisse.46 Évaluation analytique de la précision des algorithmes de décodage sphérique Figure 2.3 – Représentation d’un signal en virgule fixe avec une dynamique [−1, 1) Afin de bien analyser le comportement de la déviation par rapport au modèle PQN, nous considérons un signal normalisé dans l’intervalle [−1, 1]. Son format virgule fixe est illustré par la figure 2.3. La figure 2.4 montre l’amplitude de l’erreur relative entre le modèle analytique PQN et les estimations de l’erreur obtenues par simulation. Nous considérons dans cette illustration trois FDP : la distribution uniforme, Laplacienne et Gaussienne. L’erreur relative entre le modèle PQN et la simulation est importante dans le cas Laplacien, et, dans une moindre mesure, pour une densité de probabilité gaussienne. Enfin, l’erreur relative devient faible, voire négligeable, dans le cas d’une loi uniforme. En effet, puisque la loi uniforme possède des valeurs réparties sur l’intervalle [−1, 1], par conséquent, sa quantification (avec le plus grand nombre de bits) préserve des formes uniformes et les valeurs de −1 ou 1 contribuent à la puissance totale de bruit. Tandis que, dans le cas de la distribution gaussienne, les valeurs sont plus denses près de la valeur de 0 et donc remises à zéro lorsque des pas de quantification larges sont utilisés. Ceci engendre une déviation large entre l’erreur estimée par le modèle PQN et l’erreur observée par simulation. Ce phénomène est plus visible dans le cas de la distribution Laplacienne où il y a plus de valeurs proches de 0 que dans le cas Gaussien. Comme le pas de quantification est réduit (davantage de bits sont affectés pour la précision), les valeurs ne sont pas remises à 0 et donc convergent à un comportement similaire. Figure 2.4 – Représentation d’un signal en virgule fixe avec une dynamique [−1, 1) Dans l’algorithme décrit précédemment, il est nécessaire d’enregistrer les statistiques de la valeur prise par chaque signal associé à un opérateur de quantification dans le système. En effet, la mémorisation des valeurs de tous les signaux à travers la totalité de la longueur de simulation peut consommer une grande quantité de mémoire et de temps, ce qui peut parfois conduire à une infaisabilité en pratique. Pour remédier à ce problème, il est possible de ne mémoriser qu’uniquement les statistiques des signaux associés à des opérateurs quantifiés soupçonnés d’être non-lisses.2.2 Modèle analytique pour l’opérateur de décision 47 2.2 Modèle analytique pour l’opérateur de décision Figure 2.5 – Diagramme de la constellation 16-QAM Il est fréquent de trouver un certain nombre d’opérateurs lisses et non lisses qui coexistent au sein des systèmes de traitement numérique de signal. Dans les systèmes de communication numérique, les opérateurs correspondent le plus souvent à des opérateurs de décisions QAM présents au sein des algorithmes de réception et ils coexistent avec d’autres opérateurs lisses en arithmétique virgule fixe. Citons à titre d’exemple les algorithmes de décodage sphérique tels le SSFE qui fera l’objet de la dernière partie de ce chapitre et et qui peut être considéré comme une application typique de la propagation du bruit de quantification lors d’une cascade d’opérateurs de décision. Il y a également les algorithmes d’égalisation tels que l’égaliseur à retour de décision qui sera présenté dans le prochain chapitre de cette thèse et qui est constitué d’une itération d’opérateurs de décision. Nous pouvons citer également les algorithmes de turbo décodage abordés dans le dernier chapitre. Bien que les erreurs lisses puissent être estimées en utilisant le modèle additif PQN, la réponse d’un opérateur de décision QAM à une perturbation par le bruit de quantification peut être non linéaire ce qui peut provoquer un large écart par rapport aux estimations obtenues par l’application du modèle de PQN. Par conséquent, il est nécessaire d’analyser l’erreur causée par une quantification d’un opérateur non lisse et estimer son effet sur la performance d’un système. En particulier, étant donné que les opérateurs lisses coexistent avec les opérateurs non lisses, il est nécessaire d’estimer les statistiques de l’erreur à la sortie d’un opérateur non lisse en raison de la perturbation du signal à son entrée. Dans cette partie, nous commençons par modéliser l’opérateur de décision ainsi que sa réponse à une perturbation et proposer un modèle analytique permettant de déterminer la probabilité d’erreur de décision causée par la quantification d’un signal en virgule fixe. Il convient de préciser également que ce travail a été fait en collaboration avec les travaux de recherche menés par K. Parashar [75] dans la même équipe CAIRN. 2.2.1 Modélisation de l’opérateur de décision Considérons le cas général d’un opérateur de décision au sein d’un système de communication numérique. Il s’agit d’un exemple typique d’un opérateur non lisse. La figure 2.5 montre la48 Évaluation analytique de la précision des algorithmes de décodage sphérique constellation 16-QAM avec les différentes régions correspondant à chaque symbole de la constellation. Le principe de fonctionnement d’un opérateur de décision QAM se base sur la différenciation des valeurs d’un signal QAM donné x à l’entrée de cet opérateur. Selon la valeur du signal à l’entrée, cet opérateur affecte à la sortie un symbole Si représentant la région Ri dans laquelle se situe la valeur du signal à l’entrée. Chaque région Ri possède une limite ri. Le symbole Si appartient à l’ensemble des symboles de la constellation S = {S1, S2, ..., SL}, avec Si ∈ RN . N est la dimension du signal transmis (N = 2 pour les signaux QAM). Le fonctionnement de l’opérateur de décision est défini par la figure 2.6. Par conséquent la sortie x˜ de l’opérateur de décision est définie comme suit : x˜ = Si si x ∈ Ri (2.8) Figure 2.6 – Fonctionnement de l’opérateur de décision Ri est la région définie comme le voisinage du point de la constellation Si. La région Ri est un sous-espace de RN et elle consiste essentiellement à l’ensemble des valeurs prises par x qui peuvent être décidées par le symbole Si en sortie. Dans la figure 2.5, la région R1,−1 est l’aire couverte par le rectangle centré sur le point de constellation (1, −1). Ri = {x ∈ R2/i = argmin k |x − Sk| 2} (2.9) Les frontières des symboles de la constellation QAM (−1, 1) et (−3, 3) sont définies par les lignes discontinues. Les aires formées par ces frontières forment les régions R−1,1 et R−3,3. En outre, l’opérateur de décision QAM porte beaucoup de similitudes avec la quantification rencontrée lors de l’étude de l’arithmétique de précision finie. Son fonctionnement est identique sur la voie en phase (axe réel ou horizontal) et sur la voie en quadrature (axe imaginaire ou vertical). Le comportement de l’opérateur QAM, restreint à un seul de ces axes (phase ou quadrature), peut être considéré comme un quantificateur Q de pas de quantification q en cascade avec un opérateur de saturation S de dynamique a comme indiqué sur la figure 2.7.2.2 Modèle analytique pour l’opérateur de décision 49 Figure 2.7 – Modèle de quantification d’un opérateur de décision Le quantificateur Q suit le mode par arrondi et il est centré sur les points de la constellation. La dynamique α correspond à la différence maximale entre deux points de la constellation. Lorsque la dynamique du signal en entrée est comparable à la dynamique α de l’opérateur de saturation S (c-à-d max(x) − min(x) $ α), l’opérateur de saturation peut être ignoré (c-à-d xˆ $ x˜) et l’opérateur de décision peut être approximé à un quantificateur. Lorsque le comportement de l’opérateur de décision QAM est similaire au cas d’un quantifi- cateur qui est utilisé pour modéliser l’arithmétique en précision finie, les statistiques de l’erreur sont non lisses. La différence entre l’opérateur de décision QAM et le quantificateur lisse qui est habituellement rencontré dans l’implémentation en précision finie consiste en un large pas de quantification par rapport au signal. Lorsque le pas de quantification lié à la précision finie est plus faible que la dynamique, le pas de quantification de l’opérateur de décision est souvent comparable au signal lui-même. Par conséquent, l’opérateur de décision est non lisse. 2.2.2 La réponse à la perturbation Dans le cas d’un opérateur non lisse, les statistiques de l’erreur en sortie ne sont plus compatibles avec le modèle PQN. Par conséquent, l’impact du bruit de quantification à la sortie d’un opérateur non lisse peut être analysé en comparant uniquement la réponse de l’opérateur non lisse aux valeurs en entrée dans le cas d’une précision finie et leurs équivalents dans le cas de la précision infinie. L’effet de la perturbation causée par l’accumulation du bruit de quantification à l’entrée d’un opérateur non lisse est illustré par la figure 2.8. Figure 2.8 – Réponse à la perturbation à la frontière non lisse ; Cas A : x = xa, Cas B :x = xb Soit un signal x à l’entrée d’un opérateur non lisse dont les sorties sont les valeurs V1 ou V2 dépendent de la valeur de x. Considérons deux scénarios dans lesquels un signal x prend50 Évaluation analytique de la précision des algorithmes de décodage sphérique des valeurs xa et xb en précision infinie. En virgule fixe, le signal x est perturbé par le bruit de quantification accumulé. Soient qg et qd les distorsions négatives et positives probables maximales. Dans le cas où le signal prend une valeur suffisamment loin de la frontière tel que décrit dans le cas A : (soit x = xa), l’amplitude de la perturbation qg ou qd n’est pas assez grande pour que le signal résultant puisse franchir la frontière de décision. Par conséquent, la valeur attribuée par l’opérateur non lisse, à la fois en précision finie et infinie, est V2 et aucune erreur ne se propage. D’autre part, si une valeur en double précision x est assez proche de la frontière tel que décrit dans le cas B : (soit x = xb), une perturbation positive peut conduire la valeur en virgule fixe à franchir la frontière de décision, soit donc à changer la valeur de la sortie en V2 (à la place de V1) provoquant ainsi un comportement de l’implémentation en précision finie différent de celui en précision infinie. 2.2.3 La probabilité d’erreur de décision Pour analyser l’impact de la quantification, nous utilisons une métrique de précision qui compare les valeurs de divers signaux dans le système lorsque des opérateurs en virgule fixe sont utilisés. En cas de quantificateurs lisses, les erreurs sont faibles et donc facilement captées par le bruit de quantification. Dans le cas des opérateurs non lisses, la puissance des erreurs n’est pas conforme avec le modèle d’erreur analytique PQN. Par conséquent, il devient important d’avoir accès à la fonction de densité de probabilité de l’erreur en sortie de l’opérateur non lisse, ce qui permet également de déduire la puissance de l’erreur. En outre, il est plus fondamental de calculer la probabilité de l’erreur à la sortie de l’opérateur que de déduire directement la puissance du bruit du signal d’erreur de quantification. Probabilité d’erreur de décision Afin d’étudier l’impact du bruit de quantification non lisse accumulé à la sortie d’une première décision, nous considérons un système de traitement de signal (figure 2.9) formé d’un opérateur de décision à la sortie xˆ d’un système lisse. Cette configuration est très fréquente dans les récepteurs des systèmes de communication numérique et dans les algorithmes de décodage et d’égalisation. Figure 2.9 – Un système constitué d’un opérateur non lisse La valeur d’un signal en virgule fixe xˆvf ix(n) à l’entrée de l’opérateur de décision est obtenue par la perturbation de xˆvf lo(n) à cause du bruit de quantification bx(n). Par conséquent le signal en entrée à l’opérateur non lisse de décision s’écrit sous la forme suivante : xˆvf ix(n)=ˆxvf lo(n) + bx(n) (2.10) La probabilité d’erreur de décision causée par le bruit additif de quantification peut être déduite en comparant la sortie en virgule fixe x˜vf ix(n) de l’opérateur de décision à la sortie en virgule flottante x˜vf lo(n). Comme mentionné dans la section précédente, la déviation dans la valeur du signal dans un système en virgule fixe est fonction de la puissance du bruit de quantification associé au signal. Lorsque la valeur du signal est proche de la limite (frontière) de décision et que la puissance du bruit de quantification est suffisamment large, la déviation causée par la perturbation provoque le franchissement de la frontière de décision ce qui génère une sortie2.2 Modèle analytique pour l’opérateur de décision 51 différente de celle produite par un système avec une précision en virgule flottante. Par ailleurs, si la puissance du bruit est suffisamment grande, la déviation de la valeur du signal peut traverser plusieurs frontières ce qui engendre inévitablement une erreur de décision à la sortie. Soit Pi,j la probabilité d’erreur de décision (i .= j) telle que x˜vf lo = Si et x˜vf ix = Sj . Cette erreur correspond au cas où la valeur entrée (située dans la région Ri, est perturbée par le bruit bx de telle sorte que le signal résultant appartienne à la région Rj . Par conséquent, la probabilité d’erreur de décision Pi,j est la probabilité que le signal en entrée en virgule flottante xˆvf lo appartienne à la région Ri et que le signal correspondant en virgule fixe xˆvf ix appartienne à la région Rj . Pi,j = Prob {(ˆxvf lo ∈ Ri) ∩ (ˆxvf lo + bx ∈ Rj )} . (2.11) Soient fb(b) et fx(x) les fonctions densité de probabilité respectivement du bruit bx et du signal d’entrée en arithmétique virgule flottante xˆvf lo. La probabilité Pi que la valeur du signal en entrée xˆvf lo donne une décision x˜vf lo = Si est obtenue en intégrant la FDP fx(x) sur toute la région du symbole correspondant Ri et elle est donnée par : Pi = / Ri fX(x)dx (2.12) Considérons une instance du signal x qui prend la valeur xi ∈ Ri telle que la sortie est x˜ = Si. En connaissant la FDP du bruit de quantification bx, il est possible de calculer la probabilité d’erreur Pxi,j causée par la perturbation du signal avec une valeur xi qui conduit à une décision du symbole Sj (j différent de i) en précision finie en raison du bruit de quantification bx, alors que cette décision correspond au symbole Si en arithmétique virgule flottante. Par conséquent, Pxi,j est définie par : Pxi,j = Prob {xˆvf lo + bx ∈ Rj |xˆvf lo ∈ Ri} (2.13) En supposant que le bruit de quantification est non corrélé avec le signal [92], la relation précé- dente peut encore s’exprimer selon : Pxi,j = lim%→0 / xi+ " 2 xi− " 2 fx(xi)dxi. / Rj fb(b − xi)db. (2.14) La probabilité d’erreur de décision totale Pi,j est obtenue en considérant tous les points de la région Ri et en intégrant la probabilité Pxi,j sur la région Ri : Pi,j = / Ri Pxi,jdxi (2.15) En remplaçant Pxi,j par son expression de l’équation (2.14), la probabilité d’erreur de décision s’écrit : Pi,j = / Ri : fx(xi) / Rj fb(b − xi)db; dxi. (2.16) En arrangeant les termes de l’équation précédente, la probabilité d’erreur de décision peut s’écrire sous la forme suivante : Pi,j = / Ri / Rj fx(xi)fb(b − xi)dbdxi. (2.17) A partir de cette équation, l’influence du bruit de quantification et du signal à l’entrée de l’opérateur de décision peuvent être analysées sur chaque région de décision. Pour ce faire, considérons la fonction de densité de probabilité fTi (b) du signal présent à l’entrée de l’opérateur de décision et tel que xi appartient à Ri lorsque l’on utilise une arithmétique en virgule flottante. Pour chaque région Ri, la FDP de la contribution totale du bruit de quantification est donnée par : fTi (b) = / Rj fx(xi)fb(b − xi)dxi. (2.18)52 Évaluation analytique de la précision des algorithmes de décodage sphérique La probabilité d’erreur de décision Pi,j peut s’écrire en fonction de fTi (b) comme suit : Pi,j = / Rj fTi (b)db. (2.19) En calculant toutes les probabilités Pi,j , nous obtenons la matrice des probabilités P dont les coefficients sont les Pi,j : (Pi,j ) = Px˜vf lo,x˜vf ix(˜xvf lo = Si, x˜vf ix = Sj ). (2.20) La distribution de probabilité du signal réel dans le cas d’un bruit en virgule fixe peut être obtenue sous la forme d’une distribution marginale de la distribution conjointe obtenue jusqu’à présent. Fonction de probabilité jointe Étant donné que la sortie de l’opérateur de décision est discrète, la fonction de densité de l’erreur s’exprime directement en fonction des valeurs de l’ensemble S des symboles de décision. Nous pouvons alors introduire la distance di,j séparant deux symboles de l’alphabet S : di,j = Si − Sj . (2.21) Les erreurs individuelles de décision sont représentées par une fonction discrète qui s’exprime selon qui la fonction δ(˜x) qui la fonction delta de Kronecker. Par conséquent la fonction de probabilité jointe est obtenue par : fx˜(˜x) = ' L i=1 ' L j=1 Pi,j .δ(˜x − di,j ) (2.22) La fonction δ(˜x−di,j ) est une version décalée de la fonction δ dans l’espace bidimensionnel. Cette densité de probabilité est caractérisée par L × L valeurs discrètes correspondant aux différentes permutations de l’ensemble des symboles décision S. Chaque di,j (i .= j) correspond à une erreur de décision générée pour chaque couple (i, j) et la probabilité d’erreur de décision correspondante est Pi,j obtenue par l’équation (2.17). Afin de valider ce modèle de fonction de probabilité, nous pouvons utiliser deux vérifications. La première analyse consiste à vérifier théoriquement que la somme de toutes les probabilités individuelles Pi,j est égale à 1. Comme le signal x est indépendant du bruit de quantification b, la somme peut s’écrire sous cette forme. ' L i=1 ' L j=1 Pi,j = ' L i=1 / Ri fx(xi). ' L j=1 / Rj fb(b − xi).db.dxi (2.23) Par définition, l’aire sous une FDP est toujours égale à 1. Par conséquent, la somme interne ( 4 L j=1 < Rj fB(b − xi).db.dxi) est égale à l’unité car elle correspond à l’intégration de la FDP du bruit de quantification sur l’ensemble ∪Rj . En suivant le même raisonnement, la somme extérieure (4 L i=1 < Ri fX(xi)) est également égale à l’unité. En conséquence, la double somme (2.23) est elle aussi égale à l’unité tout comme la fonction de densité de probabilité (2.22). Par conséquent, nous pouvons conclure que la fonction de probabilité donnée par 2.22 est une fonction densité de probabilité valide. D’autre part, nous pouvons également déterminer la probabilité d’erreur de décision totale Perreur qui est la somme de toutes les probabilités d’erreur de décision individuelle Pi,j|i&=j . Perreur = ' L i=1 ' L j&=i,j=1 Pi,j ∀(i, j) ∈ [1, L] (2.24)2.2 Modèle analytique pour l’opérateur de décision 53 Cette probabilité d’erreur totale peut être déterminée à partir des probabilités individuelles Pi,i qui sont les probabilités de ne pas avoir une erreur de décision. En d’autres termes, la probabilité Pi,i est la probabilité que la sortie de l’opérateur de décision dans le cas de virgule fixe et dans le cas de virgule flottante soit égale au symbole Si. Par conséquent, la probabilité d’erreur de décision totale s’exprime comme suit : Perreur = 1 − ' L i=1 Pi,i (2.25) Figure 2.10 – Probabilité d’erreur de décision totale : cas BPSK La deuxième vérification se base sur la comparaison des probabilités Pi,j obtenues analytiquement par ce modèle avec celles obtenues par simulations. Par conséquent, nous considérons un système tel que décrit dans la figure 2.9 qui est constitué d’un bloc lisse suivi d’un opérateur de décision non lisse. Nous supposons que le signal présent à l’entrée de l’opérateur de décision est un signal gaussien BSPK centré sur les symboles avec une équiprobabilité entre les différents symboles de la constellation (-1, 1) et de variance σ2 ch. Dans ce cas nous avons deux probabilités d’erreur de décision causée par le bruit de quantification b. Ces probabilités sont P−1,1 qui est la probabilité d’avoir en sortie le symbole −1 en virgule flottante alors qu’en virgule fixe nous obtenons le symbole 1 et P1,−1 est la probabilité du cas contraire. Afin de tester la fiabilité de ce modèle, nous supposons que le bruit en entrée de l’opérateur suit une loi gaussienne de moyenne nulle et de variance σ2 b . Les FDP du signal à l’entrée de l’opérateur de décision et du bruit de quantification sont données par : fX(x) = 1 2 √2πσch 8 exp(−(x − 1)2 2σ2 ch ) + exp(−(x + 1)2 2σ2 ch ) 9 . (2.26)54 Évaluation analytique de la précision des algorithmes de décodage sphérique fB(b − x) = 1 √2πσb exp(−(b − x)2 2σ2 b ). (2.27) En appliquant le modèle analytique de l’équation (2.17), nous obtenons les probabilités d’erreur de décision P−1,1 et P1,−1. En raison de l’hypothèse d’équiprobabilité entre les deux symboles de la constellation, les deux probabilités d’erreur de décision P−1,1 et P1,−1 sont égales. Par consé- quent, la probabilité d’erreur totale Perreur est le double de P1,−1. Afin de tester le modèle, nous varions la variance σ2 b de 0.1 jusqu’à 0.8 et nous calculons à chaque fois la probabilité d’erreur de décision totale analytiquement par le modèle obtenu et par simulation. Le calcul par simulation se base sur une simulation en virgule fixe et une simulation en virgule flottante et la comparaison des sorties de l’opérateur de décision dans les deux cas. Si ces deux sorties sont différentes, il s’agit d’une erreur due à la conversion en virgule fixe où en d’autres termes à la perturbation causée par le bruit de quantification additif b. La figure 2.10 présente la probabilité d’erreur de décision obtenue analytiquement et par simulation en fonction de la variance du bruit de quantification. Il convient de préciser que, dans cette expérience, nous modélisons la conversion en virgule fixe par l’ajout du bruit de quantification au signal à l’entrée de l’opérateur. Par contre dans les prochaines expériences nous effectuerons une "vraie" conversion en format virgule fixe et par conséquent chaque RSB correspondra à un format virgule fixe bien déterminé. Nous remarquons d’après la figure 2.10, que les résultats obtenus par le modèle analytique de l’équation (2.17) correspondent fidèlement aux résultats obtenus par simulations. L’erreur maximale entre la probabilité obtenue par simulation et celle obtenue analytiquement est de l’ordre de 1%. 2.3 Cascade d’opérateurs de décision Dans le paragraphe précédent, nous avons proposé un modèle analytique permettant d’estimer la probabilité d’erreur de décision d’un opérateur de décision dans le cas particulier d’un système composé d’un bloc lisse et d’un unique opérateur de décision. Cependant, ce modèle peut-il être appliqué à un système composé de plusieurs opérateurs de décision ? Si l’on considère un tel système, l’erreur causée par la quantification au niveau du premier opérateur de décision se propage tout au long du système en passant par différents blocs pour arriver au deuxième opérateur de décision. Le modèle analytique d’estimation de la probabilité d’erreur de décision n’est plus applicable pour estimer l’erreur de décision au niveau du deuxième opérateur de décision car ce modèle ne tient pas compte de la propagation de l’erreur due à la quantification et au format virgule fixe. Afin de bien illustrer cette problématique, nous considérons un système composé de deux opérateurs de décision tels que montré par la figure 2.11. Figure 2.11 – Cascade de deux opérateurs de décision Le système considéré est un cas simplifié d’un système de décodage sphérique composé de deux antennes. Ce système sera étudié d’une façon approfondie dans la prochaine section. D’après le diagramme bloc du système, nous remarquons que l’entrée xˆ2 du deuxième opérateur de décision OP2 ne dépend pas seulement du signal reçu y2 mais aussi de la sortie x˜1 du premier opérateur de décision. Lorsqu’une erreur de quantification est produite au niveau du premier opérateur,2.3 Cascade d’opérateurs de décision 55 elle se propage jusqu’au deuxième opérateur de décision. Si nous essayons d’appliquer le modèle analytique de l’équation (2.17), nous obtenons des estimations de l’erreur de décision très éloignées des estimations obtenues par simulation. La figure 2.12 représente la probabilité d’erreur de décision estimée au niveau du deuxième opérateur de décision par le modèle analytique à un seul opérateur de décision et également par simulation. Figure 2.12 – Non validité du modèle analytique d’estimation de la probabilité d’erreur de décision dans le cas d’une cascade d’opérateurs de décision Nous pouvons remarquer que la probabilité d’erreur de décision obtenue par le modèle analytique est sous-estimée par rapport à celle obtenue à partir de la simulation. Comme le modèle analytique proposé ne tient pas compte de la propagation des erreurs de quantification, les résultats de la figure 2.12 étaient prévisibles. Par conséquent, il est fondamental d’étudier la propagation de l’erreur de quantification dans un système composé de plusieurs opérateurs non lisses et de tenir compte de cette propagation. Ceci sera présenté dans la prochaine section. 2.3.1 Propagation de l’erreur de quantification Pour valider ce modèle dans le cas d’une cascade d’opérateurs de décision, il est absolument nécessaire de prendre en compte le phénomène de propagation des erreurs de quantification. Considérons le système présenté à la figure 2.13 composé à la fois de plusieurs opérateurs lisses et de N + 1 opérateurs non lisses.56 Évaluation analytique de la précision des algorithmes de décodage sphérique Figure 2.13 – Propagation de l’erreur de quantification dans un système composé de plusieurs opérateurs non lisses en cascade Dans le cas d’une implémentation en virgule fixe, le vecteur des entrées Y = [y1, y2, ..., yN ] est perturbé par le vecteur des bruits de quantification B = [b1, b2, ..., bN ], chaque bruit bi perturbant le signal yi. présent sur la ième entrée. Soient Yvf lo et Yvf ix les vecteurs des entrées respectivement en virgule flottante et en virgule fixe. L’opérateur L représente une fonction lisse comportant 2N entrées correspondant au vecteur Y et au vecteur X˜ = [˜x1, x˜1, ..., x˜N ] constitué des N sorties des opérateurs de décision situés en amont. De même, soient X˜vf lo et X˜vf ix les vecteurs des sorties des N opérateurs de décision qui précèdent le bloc lisse respectivement en arithmétique virgule flottante et en virgule fixe. Soient xˆvf lo N+1 et xˆvf ix N+1 l’entrée au dernier opérateur de décision respectivement en représentation virgule flottante et virgule fixe. Par conséquent, la sortie du bloc lisse en virgule fixe xˆvf ix N+1 est donnée par : xˆvf ix N+1 = L(yvf ix 1 , ..., yvf ix N , x˜vf ix 1 , ..., x˜vf ix N ) = L(yvf lo 1 , ..., yvf lo N , x˜vf lo 1 , ..., x˜vf lo N ) + l(b1, ..., bN , x˜vf lo 1 , ..., x˜vf lo N , x˜vf ix 1 , ..., x˜vf ix N ) + bL = ˜xvf lo N+1 + Lb(B, X˜vf lo, X˜vf ix) + bL (2.28) bL est le bruit ajouté par les quantificateurs lisses lors de l’utilisation d’une implémentation en virgule fixe de la fonction L et Lb est la fonction de la propagation du bruit. Étant donné que la fonction L est lisse, la fonction de propagation du bruit Lb est linéaire par rapport au vecteur des bruits de perturbation b. La propagation des erreurs à la sortie des N opérateurs de décision non lisses à travers la fonction L peut ne pas avoir des caractéristiques linéaires. Par conséquent, la fonction de propagation du bruit Lb doit être évaluée pour chaque erreur et pour toutes les configurations d’erreurs présentes sur les sorties des N opérateurs de décision situés en amont. 2.3.2 Détermination analytique de la probabilité d’erreur en sortie de la cascade Soit vvf lo et vvf ix deux instances des valeurs prises par x˜vf lo et x˜vf ix respectivement. Le signal xˆvf ix N+1 est donné par : xˆvf ix N+1 = ˆxvf lo N+1 + Lv b (B) + bL = ˆxvf lo N+1 + bf (2.29)2.3 Cascade d’opérateurs de décision 57 La fonction de propagation du bruit Lv b est déduite de la fonction Lb de l’équation (2.28) en utilisant les valeurs particulières vvf lo et vvf ix à la place de X˜vf lo et X˜vf ix, respectivement. Par conséquent, la fonction Lb ne varie qu’en fonction du seul paramètre B correspondant au vecteur des perturbations. Ainsi, la propagation des perturbations associées aux signaux en entrées Y à travers la fonction L est caractérisée par une combinaison spécifique donnée des vecteurs de données en entrée de décision en format virgule flottante et virgule fixe. De manière équivalente, nous pouvons considérer que les vecteurs de données en entrée de décisions en arithmétique virgule fixe et virgule flottante représentent conjointement un scénario S des conditions en entrée. En sortie de la fonction L, le bruit généré par les opérations en virgule fixe dans l’implémentation de la fonction L et la propagation des perturbations en entrée peut être résumé et collecté à travers le bruit bf . Soit Mk le nombre des symboles de décision disponibles à la sortie du keme opérateur de décision. Le vecteur X˜ peut prendre C = = N k=1 Mk combinaisons possibles. Si l’on considère le vecteur des valeurs particulières Sk N défini par Sk N = [vvf lo, vvf ix], il existe C × C combinaisons possibles pour ce vecteur La probabilité d’erreur de décision P Sk N i,j à la sortie du (N + 1)eme opérateur de décision pour une combinaison donnée du vecteur des entrées Sk N peut être calculée en utilisant le modèle analytique de l’équation (2.17). P Sk N i,j définit la probabilité que la valeur en sortie du (N + 1)ème opérateur de décision x˜N+1 corresponde à Si en format virgule flottante et à Sj en arithmétique virgule fixe sous la contrainte du scénario défini par les entrées de décision Sk N , elle est donnée par : P Sk N i,j = / Ri / Rj f Sk Nx (x)fb(b − x)dbdx. (2.30) Où la fonction f Sk Nx correspond à la FDP du signal xˆvf lo N+1 pour le scénario Sk N , et fb est la FDP du bruit total de quantification bf obtenu dans l’équation (2.29). La probabilité d’erreur de décision totale est déterminée en considérant l’impact de tous les scénarios possibles sur la sortie de l’opérateur de décision. Par conséquent, la probabilité d’erreur de décision totale, que la sortie du dernier opérateur de décision x˜N+1 corresponde au symbole Si en arithmétique virgule flottante et Sj en virgule fixe, est une somme de toutes les probabilités d’erreur de décision P Sk N i,j sous le scénario Sk N pondérée par la probabilité PSk N de réalisation de tous les scénarios possibles Sk N . Elle est donnée par : Pi,j i&=j = ' C2 k=1 PSk N P Sk N i,j = ' C2 k=1 / Ri / Rj PSk N f Sk Nx (x)fb(b − x)dbdx. (2.31) Afin de déterminer la probabilité d’erreur de décision Pi,j au niveau du dernier opérateur de décision du système considéré, il est nécessaire d’évaluer la probabilité PSk N de l’occurrence du scénario Sk N et la FDP f Sk Nx du signal x˜N+1 à l’entrée du N + 1eme opérateur de décision sous contrainte du scénario Sk N . En ce qui concerne la probabilité PSk N , nous pouvons distinguer le cas où les erreurs de décision sont dépendantes et le cas où elles sont indépendantes. La probabilité PSk N est obtenue comme la probabilité conjointe qu’une combinaison des sorties d’un opérateur de décision se produise selon la description du scénario. Par conséquent, la probabilité de l’occurrence du scénario PSk N est donnée par : PSk N = P((˜xvf lo 1 = S1 i , x˜vf ix 1 = S1 j ) et ... et (˜xvf lo N = SN i , x˜vf ix N = SN j )) (2.32)58 Évaluation analytique de la précision des algorithmes de décodage sphérique où Sr i et Sr j représentent les valeurs prises par la sortie du rème opérateur de décision respectivement en virgule flottante et en virgule fixe. En d’autres termes, PSk N est la probabilité de l’occurrence du kème scénario. Dans le cas où les éléments du vecteur X˜ ne sont pas corrélés, la probabilité conjointe est déterminée par : PSk N = > N r=1 P(˜xvf lo r = Sr i , x˜vf ix r = Sr j ) (2.33) Par conséquent, dans ce cas, nous avons tous les éléments nécessaires pour déterminer analytiquement la probabilité d’erreur de décision à la sortie de chaque opérateur de décision du système y compris le dernier opérateur de décision de la cascade. Par contre, en pratique, nous pouvons rencontrer le cas où les sorties des opérateurs de décision sont corrélées entre elles. La corrélation est déterminée par la topologie du flot du signal et la corrélation entre les vecteurs en entrée utilisés en simulation virgule flottante pour déterminer la FDP du signal. Sous ces conditions, l’impact de chaque sortie de décision sur les autres sorties de décision doit être considéré afin de calculer la probabilité conjointe de l’occurrence des sorties de décision dans le cas du scénario Sk N . Soit Sk P un sous scénario correspondant à un sous ensemble du scénario Sk N . Par conséquent, les éléments des vecteurs X˜vf lo et X˜vf ix ont une longueur P (P ≤ N) et ils sont égaux aux premiers P éléments définis dans le vecteur Sk N . Ainsi, la probabilité conjointe PSk N peut être évaluée à partir des probabilités conditionnelles : PSk N = P((˜xvf lo N = Si, x˜vf ix N = Sj )|Sk N−1).PSk N−1 = P((˜xvf lo N = Si, x˜vf ix N = Sj )|Sk N−1).P((˜xvf lo N−1 = Si, x˜vf ix N−1 = Sj )|Sk N−2). ... P((˜xvf lo 2 = Si, x˜vf ix 2 = Sj )|Sk 1 ). P(˜xvf lo 1 = Si, x˜vf ix 1 = Sj ) ? @A B PSk 1 = N >−1 r=0 P((˜xvf lo N−r = Si, x˜vf ix N−r = Sj )|Sk N−r−1). (2.34) D’après les équations (2.33) et (2.34), il est clair que le calcul de la probabilité de l’occurrence du scénario Sk N nécessite la connaissance des probabilités d’erreurs ainsi que les probabilités conjointes des N entrées de décision. Par conséquent, la probabilité de l’erreur P(˜xvf lo = Si, x˜vf ix = Sj ) des sorties de décision doit être calculée a priori. Cela veut dire que la probabilité de l’erreur en sortie de chaque opérateur de décision du système doit être calculée dans l’ordre de priorité à partir de l’entrée jusqu’à la sortie du système considéré. Après avoir identifié les opérateurs non lisses, il est donc nécessaire d’analyser ces dépendances à partir de l’analyse du graphe flot du système. Lorsque les entrées de décision ne sont pas corrélées, la probabilité conjointe est obtenue par un simple produit entre les différentes probabilités individuelles des scénarios de décision en arithmétique virgule flottante et virgule fixe. D’autres part, dans le cas où les sorties de décision sont corrélées avec d’autres sorties de décision, le calcul de la fonction de probabilité d’erreur de décision du premier opérateur de décision du système se fait par le modèle de l’équation (2.17). La probabilité d’erreur de décision des opérateurs intermédiaires dans le système est déterminée en calculant successivement les probabilités conjointes des erreurs intervenant au sein de l’équation (2.34). Ensuite, les résultats intermédiaires obtenus durant le calcul des différentes probabilités d’erreur de décision sont réutilisés pour le calcul des probabilités des scénarios pour les opérateurs de décision situés en aval.2.3 Cascade d’opérateurs de décision 59 Figure 2.14 – Propagation des erreurs non lisses (corrélées ou non corrélées) Afin de bien illustrer les résultats analytiques établis précédemment, nous considérons le cas générique représenté par le système de la figure 2.14 constitué d’un bloc lisse possédant en entrée H (H ≥ 2) groupes non lisses. Par ailleurs, nous supposons que le signal de l’un des groupes est indépendant des signaux appartenant aux autres groupes mais qu’il est corrélé avec les signaux du même groupe. Soit x˜D le signal en sortie de l’opérateur de décision situé en sortie du bloc lisse. Dans ce cas, les N entrées de décision sont différenciées en H groupes indépendants de N1, N2, ..., NH opérateurs de décision. N’importe quel i eme opérateur de décision est dépendant du i − 1eme opérateur de décision du même groupe. Afin d’être en mesure de déterminer analytiquement la probabilité de l’occurrence de tous les scénarios possibles résultant des N1 + N2 + ... + NH entrées, les différents scénarios sont définis par toutes les entrées possibles des opérateurs non lisses de décision. Comme les H groupes des signaux ne sont pas corrélés, la probabilité de l’occurrence de ces scénarios peut être obtenue par le produit de la probabilité de l’occurrence des scénarios de chaque groupe. Par conséquent, la probabilité totale des scénarios en entrée qui considère les entrées des opérateurs non lisses de décision peut être calculée par : PSk N1+N2+...+NH = > H r=1 PSk Nr (2.35) où PSk Nr , donnée par l’équation (2.34) désigne la probabilité de l’occurrence des scénarios du reme groupe. 2.3.3 Analyse de la complexité du modèle analytique Le calcul d’une probabilité conditionnelle est similaire à celui de la probabilité Pi,j du premier opérateur de décision. Le coût calculatoire nécessaire pour évaluer la probabilité conjointe peut60 Évaluation analytique de la précision des algorithmes de décodage sphérique être mesuré en termes de nombre d’unités d’évaluation numérique de l’intégrale exprimant les Pi,j pour un scénario donné. Ce nombre d’unités d’évaluation dépend bien entendu du nombre de scénarios considérés. Le nombre de fois de l’évaluation dépend du nombre des scénarios. Ce dernier augmente exponentiellement avec le nombre des entrées de décision non lisses qui doivent être prises en considération. Dans tous les cas (corrélation ou non corrélation), il est inévitable d’évaluer ces nombreuses intégrales pour un nombre donné de combinaisons possibles d’erreurs. Supposons qu’il y ait Mk symboles de décision à la sortie du kème opérateur de décision, ils contribuent à Mk combinaisons de scénario. En considérant toutes les combinaisons possibles des sorties des opérateurs de décision, il y a au total C = = N k=1 Mk combinaisons possibles. Par conséquent, la complexité du calcul des probabilités d’erreur à la sortie du (N + 1)ème opérateur de décision (dépendant des N précédents opérateurs de décision) est de l’ordre de de O(C2), où C possède une complexité exponentielle. Afin d’illustrer l’étude mathématique analytique de la section précédente, nous considérons le cas d’une application issue du domaine des communications numériques : le décodage sphérique. Plus particulièrement, nous avons choisi de travailler sur l’algorithme SSFE (Selective Spanning with Fast Enumeration) car il représente un très bon cas d’application d’un système de communication numérique constitué d’une cascade d’opérateurs de décision. Cette étude est présentée dans la prochaine section. 2.4 Application du modèle à l’algorithme SSFE Les systèmes de communications numériques sans fils avec plusieurs entrées et plusieurs sorties MIMO (Multiple-Input Multiple-Output) utilisent plusieurs antennes dans les deux extrémités du canal sans fil. En appliquant le multiplexage spatial (transmission de multiples flux de données concurrentes dans une même bande de fréquence à l’aide de plusieurs antennes), les systèmes sans fil MIMO offrent une augmentation de l’efficacité spectrale par rapport aux systèmes monoantenne. Par conséquent, les systèmes sans fil MIMO sont en mesure de répondre à la demande des débits plus élevés sans augmenter la bande passante. Ils sont donc devenus la technologie de base pour toutes les prochaines normes de communication sans fils, telles que IEEE 802.11n, WiMAX, 3GPP LTE et 3GPP2 UMB. Pour couvrir la vaste gamme d’applications, les ordinateurs futurs devront supporter simultanément une grande variété de normes de communication sans fil. Avec le nombre croissant d’interfaces "air" qui doit être pris en charge, les implémentations traditionnelles, basées sur l’intégration de plusieurs radios spécifiques, deviennent peu rentables. Cela souligne la nécessité de solutions multi-standards flexibles. Dans cet esprit, le détecteur MIMO sépare spatialement les flux de données multiplexées au niveau du côté du récepteur. Pour la mise en œuvre du détecteur, une large gamme d’algorithmes de détection sont disponibles dans la littérature. Le choix d’un algorithme spécifique influence significativement le rendement ainsi que la complexité de la solution matérielle résultante. Parmi les algorithmes les plus utilisés, les récepteurs linéaires à sortie ferme (hard en anglais) possèdent une faible complexité mais souffrent d’une performance limitée en termes de BER (Bit Error Rate). En revanche, le choix d’un récepteur à sortie souple (soft en anglais) basé sur une détection à maximum de vraisemblance (MV) offre une performance maximale mais au prix d’une grande complexité entraînant une consommation d’énergie importante. Afin de satisfaire aux exigences énergétiques des appareils portables du futur, la conception de récepteurs MIMO et leurs implémentations optimisées sont donc devenues un défi majeur. Plusieurs techniques de détection MIMO ont été proposées telles que la détection linéaire, la détection SIC (Successive Interference Cancelation) ou bien encore les algorithmes de type K-Best. Toutefois, ces détecteurs MIMO sont généralement liés à un schéma de modulation et ne sont pas évolutifs lorsque l’on souhaite changer le nombre d’antennes [66]. En outre, leur consommation d’énergie est encore assez élevée. Par conséquent, ils ne sont généralement pas2.4 Application du modèle à l’algorithme SSFE 61 adaptés pour les systèmes multi-standards économes en énergie. C’est pourquoi, nous nous intéressons dans ce chapitre à l’optimisation de l’algorithme SSFE basé sur un spanning sélectif avec énumération rapide ce qui permet de résoudre les problèmes de la détection MV à l’aide d’une décomposition orthogonale triangulaire de la matrice H de canal. Comme nous l’avons précisé dans le premier chapitre, l’arithmétique en virgule fixe répond aux besoins d’implémentation en termes d’une faible complexité et d’une consommation d’énergie réduite par rapport à la représentation équivalente en virgule flottante. En contre partie, la précision en arithmétique virgule fixe doit être maitrisée et évaluée afin de garantir l’intégrité de l’application conçue. Dans cette section, nous présentons tout d’abord le fonctionnement de l’algorithme SSFE puis nous proposerons un modèle analytique afin d’évaluer la précision en sortie de chaque antenne de détection à la réception en se basant sur le modèle analytique présenté précédemment dans le cadre d’une cascade d’opérateurs non lisses de décision. 2.4.1 Modèle du système MIMO Figure 2.15 – Propagation des erreurs non lisses (corrélées et non corrélées) Le modèle du système utilisé est illustré par la figure 2.15. Pour une raison d’exhaustivité, les blocs de correction d’erreur avant FEC (Forward Error Correction) sont montrés dans la figure. Le nombre d’antennes est égal à Nt et Nr respectivement à l’émission et à la réception. Pour une modulation de type W-QAM, un symbole représente l’un de W = 2g points de constellation. L’émetteur transmet un vecteur binaire x de taille gNt × 1 au sein de chaque vecteur symbole s de taille Nt × 1. La transmission de chaque vecteur s à travers le canal MIMO à évanouissement non sélectif en fréquence peut être modélisée par y = H.s+n, où y représente le vecteur symbole reçu de taille Nr × 1, H caractérise la matrice canal de taille Nt × Nr et n est le vecteur bruit. La tâche du détecteur MIMO consiste à retrouver le vecteur symbole s transmis par le transmetteur. Les détecteurs MIMO à sortie souple fournissent non seulement le vecteur de symboles le plus probable s (comme le font les détecteurs à sortie hard), mais aussi le rapport de vraisemblance logarithmique LLR (Log-Likelihood Ratio) qui correspond au rapport entre les vraisemblances de la valeur mesurée à l’entrée du récepteur sous les deux conditions possibles d’émission d’un bit s égal à 0 ou 1. Les décodeurs modernes, tels que les turbo-décodeurs et les décodeurs LDPC, qui feront l’objet du dernier chapitre de cette thèse, constituent un élément critique essentiel des futurs systèmes de transmission et nécessitent l’utilisation d’entrées souples (ou soft) afin d’obtenir des performances optimales en termes de BER. De tels décodeurs comportent deux éléments principaux : un générateur de liste et un générateur LLR. Le générateur de liste détermine une liste L des vecteurs s les plus probables. Parmi les techniques classiquement utilisées pour effectuer cette opération, le détecteur à maximum de vraisemblance offre de meilleures performances en termes de BER mais il possède une complexité62 Évaluation analytique de la précision des algorithmes de décodage sphérique la plus importante. Dans cette section, nous exploitons la technique de réception de type SSFE pour effectuer la génération de liste dans le contexte des transmissions de type MIMO. 2.4.2 Présentation de l’algorithme Contrairement à l’algorithme K-best traditionnellement utilisé, l’algorithme SSFE possède une structure de type flux de données et ne consomme pas beaucoup de mémoire pour les opérations. De plus, le SSFE est basé sur des opérateurs simples et lisses telles que l’addition, le décalage, la soustraction et également la cascade d’opérateurs de décision, ce qui réduit la complexité de l’implémentation. Par ailleurs, il possède l’avantage d’être paramétrable ce qui permet de régler ses paramètres en fonction du compromis complexité/performance ciblé. Pour la détection MV, le détecteur prend ses décisions suivant la règle : sˆ = arg min s∈ΩNt 0y − Hs02 (2.36) avec ΩNt désignant l’ensemble contenant toutes les réalisation possibles du vecteur signal s de taille Nt × 1. Pour la détection MV-proche (near-ML), seulement un nombre limité de vecteur s sont considérés. Une instance de l’algorithme SSFE est caractérisée uniquement par un vecteur scalaire m = [m1, ..., mNt ], mi ≥ W. Les entrées dans ce vecteur spécifient le nombre des symboles scalaires si qui sont pris en compte au niveau de l’antenne Ni. Il est important de noter qu’avec le paramètre m, un compromis complexité/performance est sélectionné. Le calcul de s peut être visualisé avec l’arbre de spanning. Commençant au niveau i = Nt, le SSFE traverse chaque nœud au niveau i + 1 jusqu’à mi nœuds. Un exemple d’un arbre avec m = [1, 1, 2, 4] est illustré dans la figure 2.16. Figure 2.16 – Exemple d’un arbre de spanning SSFE avec m = [1, 1, 2, 4] Le premier nœud racine est noté par TNt+1 = 0. En commençant du niveau i = Nt, la distance euclidienne partielle DEP d’un vecteur symbole si = [si, si+1, ..., sNt ] est donnée par : Ti(si ) = Ti+1(si+1) + C C Cei(si ) C C C 2 (2.37) avec C Cei(si ) C C 2 décrit l’incrémentation de la DEP. L’algorithme SSFE doit sélectionner un ensemble de si = [si, si+1, ..., sNt ] tel que le pas d’incrémentation de la DEP C Cei(si ) C C 2 soit minimisé. En considérant une décomposition a priori QR triangulaire orthogonale de la matrice canal H (H = QR), le pas pour incrémenter la DEP peut être calculé comme suit :2.4 Application du modèle à l’algorithme SSFE 63 C C Cei(si ) C C C 2 = C C C C C C C C C C C C yˆi − ' Nt j=i+1 Rijsj ? @A B bi+1(si+1) −Riisi C C C C C C C C C C C C 2 . (2.38) Les termes Rij sont les coefficients de la matrice R. Comme la minimisation de C Cei(si ) C C 2 est équivalente à la minimisation de C Cei(si )/Rii C C 2 , l’équation précédente peut être transformée (si Rii n’est pas nul) selon : C C Cei(si )/Rii C C C 2 = C C C C C C C bi+1(si+1)/Rii ? @A B %i −si C C C C C C C 2 = 0$i − si02 . (2.39) Nous pouvons également définir le vecteur y " défini par : 0y − H.s02 = c + C C Cy " − R.s C C C 2 , y" = Qt .y (2.40) avec c est une constante. La tâche du SSFE est de sélectionner un ensemble des points de constellation les plus proches autour de $i. Ceci est fait essentiellement en minimisant C Cei(si )/Rii C C 2 dans l’équation (2.39). Lorsque mi = 1, le point de constellation le plus proche de $i est p1 = D($i), où D désigne l’opérateur de décision. Lorsque mi > 1, plusieurs constellations peuvent être énumérées en se basant sur le vecteur d = $i − D($i). Le principe fondamental de cet algorithme consiste donc à augmenter itérativement l’ensemble autour de $i en appliquant des approximations heuristiques. Un exemple d’une énumération de 8-point est montrée dans la figure 2.17. Le premier point et le dernier point sont notés respectivement par les chiffres 1 et 8. Nous pouvons énumérer plusieurs points de la même manière. L’énumération rapide (EN) possède des avantages clairs avec la modulation PSK tel que l’énumération implémentée dans [66]. Les performances de cet algorithme en termes de BER sont présentées dans [66] ainsi que des comparaisons avec d’autres algorithmes concurrents . Figure 2.17 – Exemple d’une énumération rapide (ER) d’une constellation à 8 points A la réception, l’algorithme SSFE traite le vecteur y " pour effectuer des opérations arithmé- tiques lisses et des opérations de décisions en cascade. A titre d’exemple, la figure 2.18 représente,64 Évaluation analytique de la précision des algorithmes de décodage sphérique dans le cas de 4 antennes, le traitement effectué à la réception par l’algorithme SSFE sur le vecteur y " . Figure 2.18 – Cascade d’opérateurs de décisions : cas de l’algorithme SSFE 2.4.3 Application du modèle analytique proposé Dans cette section, nous proposons d’appliquer le modèle analytique présenté précédemment au cas particulier de l’algorithme SSFE à 4 antennes, ceci afin d’évaluer la précision d’une cascade d’opérateurs de décisions non lisses en tenant compte de la propagation de l’erreur causée par le bruit de quantification du format virgule fixe à travers la cascade existante dans le système de l’antenne 4 jusqu’à l’antenne 1. Afin de pouvoir utiliser le modèle de l’équation (3.4), nous devons modéliser cette propagation du bruit de quantification à l’entrée de chaque opérateur de la cascade. Nous présenterons deux approches de modélisation et de prise en compte de la propagation de l’erreur causée par le bruit de quantification. La première approche consiste à tenir compte de la propagation de l’erreur causée par le bruit de quantification dans la FDP du bruit de quantification à l’entrée de l’opérateur de décision courant. La deuxième approche consiste à modéliser cette propagation de l’erreur dans la FDP du signal présent à l’entrée de chaque opérateur de décision de la cascade. 2.4.4 Première approche Afin d’illustrer cette approche simplement, nous présentons tout d’abord l’étude en considé- rant le cas d’une modulation BPSK où la FDP du signal reçu sur chaque antenne est composée par deux gaussiennes centrées sur -1 et 1 avec une variance σ2 ch. Soit f 4 x(x) la FDP du signal à l’entrée de l’opérateur de décision de l’antenne 4 qui est le premier opérateur de la cascade de l’algorithme SSFE. Dans le cas où les signaux de la constellation BPSK sont équiprobables, cette FDP est donnée par : f 4 X(x) = 1 2. √2π.σch 8 exp(−(x − 1)2 2σ2 ch ) + exp(−(x + 1)2 2σ2 ch ) 9 . (2.41)2.4 Application du modèle à l’algorithme SSFE 65 Nous considérons également que le bruit de quantification b à l’entrée de chaque opérateur de décision est un bruit blanc gaussien de moyenne nulle dont la FDP est : f 4 B(x) = 1 √2π.σb . exp(−(x)2 2σ2 b ). (2.42) Dans ce cas, il y a deux symboles -1 et 1 dont les régions de décision correspondent respectivement aux intervalles ]−∞, 0] et [0, +∞[. Pour l’antenne 4, il existe deux probabilités d’erreur de décision P4 −1,1 et P4 1,−1 qui sont déterminées analytiquement par application directe de l’équation (2.17) : P4 −1,1 = / 0 −∞ + /∞ 0 f 4 X(x)f 4 B(b − x)dbdx P4 1,−1 = + /∞ 0 / 0 −∞ f 4 X(x)f 4 B(b − x)dbdx. (2.43) Et la probabilité d’erreur totale est donnée par : P4 erreur = P4 −1,1 + P4 1,−1. (2.44) Antenne 3 Dans le cas de l’opérateur de décision de l’antenne 3, l’entrée xˆ3 dépend non seulement du signal reçu y " 3 mais aussi de la sortie x˜4 de l’opérateur de décision qui lui précède dans l’antenne 4 : xˆ3 = y " 3 R33 − R34 R33 .x˜4. (2.45) Dépendamment de la valeur décidé x˜4 qui est soit -1 ou 1 dans le cas BPSK, xˆ3 peut prendre les valeurs suivantes : xˆ3|x˜4=1 = y " 3 R33 − R34 R33 xˆ3|x˜4=−1 = y " 3 R33 + R34 R33 . (2.46) Par conséquent lorsqu’une erreur se produit au niveau du bloc de décision de l’antenne 4, elle se propage probablement jusqu’aux prochaines antennes 3, 2 et 1. La FDP du signal à l’entrée de l’opérateur de décision de l’antenne 3 s’écrit dans ce cas comme suit : f 3 x(x) = p(˜x4 = 1).f 3 xˆ3|x˜4=1 (x) + p(˜x4 = −1).f 3 xˆ3|x˜4=−1 (x). (2.47) Les fonctions de densité de probabilité f 3 xˆ3|x˜4=1 (x) et f 3 xˆ3|x˜4=−1 (x) respectivement des signaux xˆ3|x˜4=1 et xˆ3|x˜4=−1 sont égales à la FDP du signal reçu au niveau de l’antenne 3 (y " 3/R33) dont la moyenne est décalée respectivement de −R34 R33 et R34 R33 . Dans le cas où (y " 3/R33) est un signal BPSK possédant une FDP composée de deux gaussiennes équiprobables centrées sur -1 et 1, la FDP du signal xˆ3 à l’entrée de l’opérateur de décision s’écrit comme suit : f 3 x(x) = p(˜x4 = 1) 1 2. √2π.σch 8 exp(−(x − 1 + R34 R33 )2 2σ2 ch ) + exp(−(x +1+ R34 R33 )2 2σ2 ch ) 9 + p(˜x4 = −1) 1 2. √2π.σch 8 exp(−(x − 1 − R34 R33 )2 2σ2 ch ) + exp(−(x + 1 − R34 R33 )2 2σ2 ch ) 9 .(2.48)66 Évaluation analytique de la précision des algorithmes de décodage sphérique Afin de déterminer analytiquement la probabilité d’erreur de décision au niveau de l’antenne n˚3, il est nécessaire de déterminer la FDP du bruit à l’entrée de l’opérateur de décision. Ce bruit n’est pas seulement composé par le bruit de quantification dû à l’arithmétique en virgule fixe, mais aussi par le bruit causé par une erreur de décision produite au niveau de l’antenne précédente n˚4 et propagée à l’antenne actuelle n˚3. En effet, lorsqu’une erreur est produite au niveau de l’antenne précédente n˚4 tel que le scénario correspondant Sk n est une décision du symbole Sj en arithmétique virgule fixe mais elle est le symbole Si en arithmétique virgule flottante, le bruit de quantification au niveau de l’antenne n˚3 sera décalé par dij R34 R33 où dij = Si − Sj définie par l’équation (2.21), représente la différence entre les symboles de la constellation impliqués dans le scénario de l’erreur produite au niveau du bloc de décision précédent. Lorsque i .= j , il s’agit bien d’une erreur de décision, tandis que lorsque i = j (dij = 0), il s’agit du cas où il n y avait pas d’erreur de décision. Ce raisonnement englobe les deux cas (i .= j et i = j). Par conséquent, il convient de préciser, que selon cette approche, le bruit à l’entrée de l’opé- rateur de décision en cours est une somme pondérée de plusieurs bruits. Chaque bruit de la somme caractérise un scénario produit au niveau du précédent opérateur de décision multiplié par la probabilité d’occurrence de ce scénario. Dans le cas d’une constellation BPSK, le bruit à l’entrée de l’opérateur de décision de l’antenne n˚3 est une somme pondérée de trois composantes. La première composante est le bruit de quantification de la conversion en virgule fixe au niveau de l’antenne n˚3, que nous supposons blanc gaussien et centré, pondéré par probabilité de bonne décision au niveau du bloc de décision de l’antenne précédente (1 − P4 erreur). La deuxième composante caractérise le cas où il y avait une erreur de décision de type P4 −1,1 au niveau de l’antenne n˚4. Cette composante n’est que le bruit de quantification au niveau de l’antenne n˚3 décalée par d−1,1. R34 R33 = −2. R34 R33 pondéré par la probabilité de l’occurrence de ce scénario qui est P4 −1,1. La troisième composante est l’autre cas de l’erreur de décision au niveau de l’opérateur de décision de l’antenne n˚4 dont la probabilité est P4 1,−1. De même, cette composante est le bruit de quantification de l’antenne n˚3 décalé de 2. R34 R33 . Par conséquent la FDP du bruit présent au niveau de l’opérateur de décision de l’antenne n˚3 est : f 3 B(b − x) = P4 −1,1.f 3 B,−2. R34 R33 (b − x) + P4 1,−1.f 3 B,2. R34 R33 (b − x) + (1 − P4 erreur).f 3 B,0(b − x). (2.49) Dans le cas d’un bruit blanc gaussien, cette FDP s’écrit par : f 3 B(b − x) = P4 −1,1. 1 √2π.σb . exp(−(b − x − 2. R34 R33 )2 2σ2 b ) + P4 1,−1. 1 √2π.σb . exp(−(b − x + 2. R34 R33 )2 2σ2 b ) + (1 − P4 erreur). 1 √2π.σb . exp(−(b − x)2 2σ2 b ). (2.50) Après avoir déterminé les fonctions densité de probabilité du signal xˆ3 et du bruit b3 à l’entrée de l’opérateur de décision de l’antenne n˚3, nous pouvons déterminer les probabilités d’erreurs de décision P3 i,j par application directe de l’équation (2.17) : P3 i,j = / Ri / Rj f 3 X(x)f 3 B(b − x)dbdx. (2.51) Dans le cas BPSK, les probabilités d’erreurs de décision sont : P3 −1,1 = / 0 −∞ + /∞ 0 f 3 X(x)f 3 B(b − x)dbdx P3 1,−1 = + /∞ 0 / 0 −∞ f 3 X(x)f 3 B(b − x)dbdx. (2.52)2.4 Application du modèle à l’algorithme SSFE 67 Nous avons calculé la probabilité d’erreur de décision pour l’opérateur de décision de l’antenne n˚3 qui constitue une cascade avec le précédent opérateur de décision de l’antenne n˚4. Cette technique prend en compte la propagation du bruit de l’erreur produite au niveau de l’antenne n˚4 jusqu’à l’antenne actuelle n˚3. Cette propagation de l’erreur est modélisée dans la FDP du bruit présent à l’entrée de l’opérateur de décision de l’antenne n˚3 en considérant tous les scénarios possibles produits au niveau du bloc de décision de l’antenne n˚4. La figure 2.19 montre la probabilité d’erreur de décision au niveau de l’opérateur de décision de l’antenne 3 obtenue à partir de cette approche analytique ainsi que celle obtenue par simulation pour différentes valeurs du rapport entre la puissance de signal par élément binaire et celle du bruit. Figure 2.19 – Probabilité d’erreur de décision totale en fonction du rapport signal à bruit Nous remarquons que la probabilité d’erreur de décision calculée analytiquement pour l’opé- rateur de décision de l’antenne n˚3 est conforme à la probabilité d’erreur de décision calculée par la technique de simulation virgule fixe et virgule flottante de l’algorithme SSFE dans le cas d’une constellation BPSK. L’erreur maximale entre la probabilité d’erreur estimée analytiquement et la probabilité estimée par simulation est de l’ordre de 2%. Il convient de préciser par ailleurs que le temps d’exécution pris par la simulation pour estimer cette probabilité d’erreur de décision est largement supérieur aux temps pris pour évaluer numériquement la probabilité analytique. Nous présenterons ultérieurement une étude comparative entre les temps d’exécution obtenus par la méthode de simulation et par le modèle analytique afin de montrer l’intérêt de notre contribution pour l’évaluation des applications contenant des bloc lisses et des cascades d’opérateurs non lisses de décision. Cas générique Dans le cas où les signaux reçus sont de type M-QAM avec une équiprobabilité entre les différents points de constellation, nous suivons également la même stratégie que celle68 Évaluation analytique de la précision des algorithmes de décodage sphérique utilisée dans le cas BPSK afin de déterminer la fonction de densité de probabilité du signal présent à l’entrée de l’opérateur de décision de l’antenne n˚3 ainsi que celle du bruit présent en entrée de l’opérateur. Nous appliquerons ensuite l’intégrale de l’équation (2.17) pour obtenir les différentes probabilités d’erreur de décision P3 i,j . Afin d’évaluer de façon analytique les performances de décision de l’antenne n˚3, il est nécessaire de calculer en premier lieu les FDP f 3 x(x) et fB(b−x). Supposons que la sortie de l’opérateur de décision de l’antenne n˚4 soit x˜4 = Si , alors l’entrée de l’opérateur courant de décision est donnée d’après (2.45) par : xˆ3|x˜4=Si = y " 3 R33 − R34 R33 .Si. (2.53) Par conséquent, la FDP de xˆ3 est définie par : f 3 x = ' M t=1 P(˜x4 = St)fxˆ3|x˜4=Si (2.54) où fxˆ3|x˜4=Si désigne la FDP du signal xˆ3|x˜4=Si qui correspond encore, d’après (2.53), à la FDP du signal y " 3 R33 décalée par R34 R33 .Si. Après cette étape, nous devons déterminer la FDP du bruit b3 à l’entrée de l’opérateur de décision de l’antenne n˚3 en tenant compte de la propagation jusqu’à l’antenne n˚3 d’une erreur de décision due à l’arithmétique virgule fixe et en considérant tous les scénarios possibles d’erreurs produites dans le bloc de décision précédent de l’antenne n˚4. Par conséquent la FDP f 3 B(x) s’écrit par : f 3 b (x) = ' M i=1 ' M j=1 P4 i,j .f 3 B|dij (x) (2.55) où fB|dij désigne la FDP de la composante du bruit présent en entrée de l’opérateur de décision et correspondant à un scénario d’erreur P4 i,j au niveau de l’opérateur de décision de l’antenne n˚4. Cette FDP est la FDP f 3 B|0(b − x) du bruit de quantification causé par la conversion du signal xˆ3 en entrée de l’opérateur de décision en virgule fixe décalée par R34 R33 .dij = R34 R33 .(Si − Sj ). Arrivant à ce stade, nous avons tous les éléments nécessaires pour évaluer la probabilité d’erreur de décision causée par la conversion en format virgule fixe et la propagation des erreurs de quantification pour l’antenne n˚3 dans le cas d’une constellation de type M-QAM. Antenne 2 : Considérons maintenant l’étape suivante de l’architecture du récepteur SSFE, c’est à dire celle qui consiste à évaluer la précision de l’opérateur de décision situé au niveau de l’antenne n˚2. Comme dans le cas de l’antenne n˚3, nous commencerons par une étude dans le cas d’une constellation de type BPSK pour mettre en évidence les mécanismes intervenant dans la propagation du bruit d’un opérateur à l’autre de la cascade et nous présenterons le cas générique pour une constellation de type QAM. Dans le cas de l’antenne n˚2, l’opérateur de décision constitue une cascade avec les deux opérateurs de décision correspondant aux antennes n˚2 et n˚3 situées en amont. Par conséquent l’entrée xˆ2 de l’opérateur de décision de l’antenne n˚2 ne dépend pas seulement du signal reçu y " 2 mais aussi des sorties x˜3 et x˜4 des opérateurs de décision respectivement des antennes n˚3 et n˚4 : xˆ2 = y " 2 R22 − R24 R22 x˜4 − R23 R22 x˜3. (2.56) Afin de déterminer les probabilités d’erreur de décision P2 i,j (lorsque i est égal à j, on obtient alors les probabilités de bonne décision) au niveau de l’opérateur de décision de l’antenne n˚2 et appliquer l’équation (2.17), il faut déterminer la FDP du signal xˆ2 présent en entrée de l’opérateur de décision f(2) x (x) mais également la FDP f(2) B (x) du bruit b2 présent à cette même entrée. Selon cette approche, nous modélisons la propagation des erreurs dans la FDP du bruit en entrée de2.4 Application du modèle à l’algorithme SSFE 69 l’opérateur de décision. A partir de la connaissance de ces FDP, il est possible d’analyser le phénomène de propagation des erreurs à partir de l’analyse de la FDP du bruit présent en entrée de l’opérateur de décision selon l’approche précédemment présentée. Les erreurs survenues au sein des opérateurs de décision des antennes n˚3 et 4, situées en amont, vont donc se propager au sein du système et ceci jusqu’à l’antenne n˚2. Nous commençons par déterminer la FDP du signal en entrée de l’opérateur de décision. Dans le cas d’une modulation BPSK prenant ses valeurs dans l’alphabet {−1, +1}, le signal xˆ2 peut prendre quatre valeurs dépendamment des sorties x˜3 et x˜4 des opérateurs de décision des antennes n˚3 et 4 respectivement. Ce signal est donné par : xˆ2|x˜4=1,x˜3=1 = y " 2 R22 − R24 R22 − R23 R22 xˆ2|x˜4=−1,x˜3=−1 = y " 2 R22 + R24 R22 + R23 R22 xˆ2|x˜4=1,x˜3=−1 = y " 2 R22 − R24 R22 + R23 R22 xˆ2|x˜4=−1,x˜3=1 = y " 2 R22 + R24 R22 − R23 R22 . (2.57) Par conséquent, la FDP du signal xˆ2 à l’entrée de l’opérateur de décision de l’antenne n˚2 est donnée par : f(2) x (x) = p(˜x4 = 1, x˜3 = 1).f 2 xˆ2|x˜4=1,x˜3=1 (x) + p(˜x4 = −1, x˜3 = −1).f 2 xˆ2|x˜4=−1,x˜3=−1 (x) + p(˜x4 = −1, x˜3 = 1).f 2 xˆ2|x˜4=−1,x˜3=1 (x) + p(˜x4 = 1, x˜3 = −1).f 2 xˆ2|x˜4=1,x˜3=−1 (x(2.58) ) où fxˆ2|x˜4=i,x˜3=j désigne la FDP du signal reçu sur l’antenne n˚2 ( y " 2 R22 décalé par −Si. R24 R22 − Sj . R23 R22 . Par conséquent, il est nécessaire de calculer la probabilité p(˜x4 = Si, x˜3 = Sj ). Celle ci est donnée par : p(˜x4 = Si, x˜3 = Sj ) = p(˜x3 = Sj |x˜4 = Si).p(˜x4 = Si). (2.59) Or le signal xˆ3|x˜4=Si présent en entrée de l’opérateur de décision de l’antenne n˚3 sous condition que la sortie de l’opérateur de décision de l’antenne n˚4 soit le symbole Si est donné par : xˆ3|x˜4=Si = y " 3 R33 − Si. R34 R33 . (2.60) Par conséquent la probabilité p(˜x3 = Sj |x˜4 = Si) peut s’écrire comme suit : p(˜x3 = Sj |x˜4 = Si) = / Rj fxˆ3|x˜4=Si (x)dx. (2.61) où fxˆ3|x˜4=Si représente la FDP du signal y " 3 R33 décalée par −Si. R34 R33 . Dans les mêmes conditions d’une constellation BPSK avec des distributions gaussiennes, nous avons : p(˜x4 = Si) = 1 2 ; Si = ±1 (2.62) fxˆ3|x˜4=Si (x) = 1 2. √2π.σch 8 exp(−(x − 1 + Si. R34 R33 )2 2σ2 ch ) + exp(−(x +1+ Si. R34 R33 )2 2σ2 ch ) 9 . (2.63) Il est alors possible, à partir des relations précédentes, d’exprimer la fonction de densité de probabilité du signal présent à l’entrée de l’opérateur de décision xˆ2 de l’antenne n˚2 en tenant70 Évaluation analytique de la précision des algorithmes de décodage sphérique compte de tous les scénarios des sorties de décision des opérateurs des antennes n˚3 et 4 situées en amont. Afin de pouvoir déterminer les probabilités d’erreur de décision P2 i,j de l’antenne n˚2, il est nécessaire d’estimer la FDP du bruit b2 à l’entrée de cet opérateur de décision en tenant compte du bruit de quantification dû au format virgule fixe au niveau de l’antenne n˚2 et de la propagation des erreurs de décision produites au niveau des antennes n˚3 et 4. De façon similaire à ce qui a été exposé pour le cas de l’antenne n˚3, nous modélisons la propagation de ce bruit au sein de la FDP du bruit b2 en entrée de l’opérateur de décision situé sur la voie n˚2. Nous considérerons également comme précédemment que le bruit b2 possède plusieurs composantes, chacune caractérisant un scénario antérieur parfaitement déterminé au niveau des antennes n˚3 et 4. Or, pour chaque antenne, nous avons trois scénarios possibles dans le cas d’une modulation de type BPSK (pas d’erreur, une erreur de type P−1,+1 et une erreur de type P+1,−1), ce qui conduit à un total de 9 composantes possibles. Par conséquent, la FDP du bruit b2 à l’entrée de l’opérateur de décision situé au niveau de l’antenne n˚2 est donnée par : f(2) B (x) = ' 9 k=1 p(Sk BPSK).f(2) B|Sk BPSK (x). (2.64) Avec p(Sk BPSK) est la probabilité de l’occurrence du scénario Sk BPSK. fSk BPSK est la FDP de la composante du bruit qui caractérise la propagation de l’erreur générée par ce scénario. A titre d’exemple, si l’on considère le scénario correspondant à une erreur de type P−1,+1 et P+1,−1 respectivement au niveau des antennes n˚4 et 3, la probabilité de réalisation de ce scénario est alors donnée par : P((˜xvf lo 4 = −1, x˜vf ix 4 = 1),(˜xvf lo 3 = −1, x˜vf ix 3 = −1) ? @A B scenario propagé ) = P4 −1,1.P3 1,−1. (2.65) Par ailleurs, la FDP f(2) B|Sk BPSK (x) de la composante de bruit associée à ce scénario sera donnée par la FDP du bruit de quantification de moyenne décalée de −(−1 − 1). R24 R22 − (1 − (−1)). R23 R22 . En suivant cette stratégie, nous pouvons déterminer toutes les composantes qui modélisent la propagation des erreurs de décisions engendrées par l’arithmétique virgule fixe et par conséquent la FDP du bruit b2 présent à l’entrée de l’opérateur de décision de l’antenne n˚2 est déterminée. A ce stade de notre analyse, nous avons tous les éléments nécessaires pour appliquer l’équation (2.17) afin d’exprimer les probabilités d’erreur de décision P2 i,j . Afin d’évaluer numériquement les quantités impliquées dans cette approche mathématique, nous avons calculé les différentes expressions analytiques à l’aide de MATHEMATICA [50] qui est un logiciel de calcul formel. Les résultats ainsi obtenus sont donnés à la figure 2.20 où nous avons représenté la probabilité totale d’erreur de décision en fonction du rapport signal à bruit dans le cas d’une constellation de type BPSK lorsque les bruits de quantification et le bruit de canal sont considérés comme gaussiens (hypothèses similaires à celles faites lors de l’analyse de l’antenne n˚3). D’après cette figure, nous remarquons la coïncidence entre la probabilité d’erreur de décisions obtenue à l’aide du modèle analytique et celle obtenue à partir de simulations de type Monte Carlo pour des RSB compris entre 0 et 10 dB. De même que dans le cas de l’antenne n˚3, l’erreur maximale entre les deux probabilités estimées est de l’ordre de 2%.2.4 Application du modèle à l’algorithme SSFE 71 Figure 2.20 – Probabilité d’erreur de décision totale en fonction du rapport signal à bruit Cas générique Dans le cas d’une constellation de type M-QAM, le signal à l’entrée de l’opé- rateur de décision de l’antenne n˚2 est défini par la relation (2.56). En considérant de plus que les sorties des opérateurs de décision des antennes n˚4 et n˚3 soient respectivement les symboles Si et Sj , nous obtenons : xˆ2|x˜4=Si,x˜3=Sj = y " 2 R22 − Si R24 R22 − Sj R23 R22 . (2.66) Par conséquent, la FDP du signal xˆ2 à l’entrée de l’opérateur de décision de l’antenne n˚2 est donnée par : f(2) x (x) = ' M i=1 ' M j=1 p(˜x4 = Si, x˜3 = Sj ).f(2) xˆ2|x˜4=Si,x˜3=Sj (x). (2.67) Avec f(2) xˆ2|x˜4=Si,x˜3=Sj (x) (Si = ±1; Sj = ±1) est la FDP du signal ( y " 2 R22 reçu sur l’antenne n˚2 décalé par −Si. R24 R22 − Sj . R23 R22 . Les probabilités p(˜x4 = Si, x˜3 = Sj ) sont déterminées de la même façon que le cas BPSK. Il ne reste qu’à déterminer la FDP du bruit b2 en entrée de l’opérateur de décision afin d’exprimer toutes les probabilités d’erreur de décision P2 i,j en tenant compte de la propagation des différents scénarios possibles d’erreurs de décision produites au niveau des antennes n˚3 et n˚4. Pour les antennes n˚3 et n˚4, il y a M(M − 1) erreurs de décision possibles causées par le format arithmétique virgule fixe pour chaque antenne excepté le scénario où il n’y a pas d’erreur de décision. Le nombre de scénarios possibles de propagation des erreurs des précédents blocs de décision jusqu’à l’opérateur de décision de l’antenne n˚2 et (M(M − 1) + 1)2. Nous avons donc :72 Évaluation analytique de la précision des algorithmes de décodage sphérique f(2) B (x) = (M(M−1)+1) ' 2 k=1 p(Sk M−QAM).f(2) B|Sk BPSK (x). (2.68) Les différentes probabilités de l’occurrence des scénarios p(Sk M−QAM) sont déterminées de la même façon que le cas BSPK. Deuxième approche L’approche précédente nécessite d’évaluer la FDP du signal et du bruit à l’entrée de chaque opérateur de décision pour chaque antenne de l’algorithme SSFE en tenant compte de tous les scénarios possibles de la propagation des erreurs de décision d’un opérateur à un autre dans la cascade considérée. La nature itérative d’une telle approche entraîne naturellement une complexité importante de l’implémentation associée dans le cas générique, et ceci d’autant plus que la constellation numérique utilisée possède un haut rendement spectral. Afin de réduire cette complexité, nous proposons de modéliser la propagation des erreurs de décision dans la FDP du signal en entrée de l’opérateur de décision considéré dans la cascade en tenant compte de tous les scénarios possibles. Antenne 3 Avec cette technique, nous prenons en compte la distance dij = Si − Sj lorsqu’une erreur de décision est produite au niveau de l’opérateur de décision de l’antenne n˚4 avec une probabilité P4 i,j . Soit xˆ3,ij le signal à l’entrée du bloc de décision de l’antenne n˚3 qui prend en compte la différence dij entre les symboles impliqués dans l’erreur produite au niveau de l’antenne n˚4 : xˆ3,ij = y " 3 R33 − R34 R33 dij . (2.69) La FDP fxˆ3,st (x) du signal xˆ3,ij est égale à la FDP du y " 3 R33 décalée par R34 R33 dij . Par consé- quent la probabilité d’erreur de décision P3 i,j au niveau de l’opérateur de décision de l’antenne n˚3 correspond à la somme pondérée des probabilités d’erreur de décision partielles P3 i,j|s,t sous contrainte de la propagation d’un scénario d’erreur de décision produit lors du bloc de décision de l’antenne n˚4 correspondant à l’évènement aléatoire suivant : pour l’antenne n˚4, décision d’un symbole St en arithmétique virgule fixe alors que ce symbole correspond à Ss en arithmétique flottante. La probabilité d’un tel évènement sera notée P4 s,t dans la suite du manuscrit. Chaque élément de cette somme est pondéré par la probabilité de l’occurrence du scénario qui lui correspond. Au niveau de l’antenne n˚3, la probabilité d’erreur de décision P3 i,j|s,t est obtenue à partir de la relation (2.17) suivant : P" 3 i,j|s,t = / Ri / Rj fxˆ3,st (x))f 3 B(b − x)dbdx. (2.70) Par conséquent les probabilités d’erreur de décision P3 i,j sont déterminées par : P3 ij = ' M s,t=1 P4 s,t / Ri / Rj fxˆ3,st (x)f 3 B(b − x)db.dx (2.71) P3 ij = / Ri / Rj ( ' M s,t=1 P4 s,tfxˆ3,st (x))f 3 B(b − x)dbdx. (2.72) La figure 2.21 représente, dans le cas d’une constellation de type 4-QAM, la probabilité d’erreur de décision au niveau de l’antenne n˚3 estimée à partir de l’équation (2.72) mais également celle obtenue à partir de simulations de type Monte Carlo. La constellation 4-QAM est constituée2.4 Application du modèle à l’algorithme SSFE 73 de 4 symboles modulés : S1 = 1+ i; S2 = −1 + i; S3 = −1 − i; S4 = 1 − i. Chaque symbole Sk est composé d’une composante en phase Sre k et d’une composante en quadrature Sim k qui prennent leurs valeurs de façon équiprobable dans l’alphabet binaire -1,+1. Nous considérons que les signaux reçus sur les antennes suivent une loi gaussienne dont la FDP est donnée par : fX(x, y) = 1 2.π.σ2 ch . 1 M ' M i=1 exp(−(x − Sre i )2 − (y − Sim i )2 2σ2 ch ). (2.73) Nous considérons également que le bruit de quantification est un bruit blanc bidimensionnel dont la FDP est donnée par : fB(x, y) = 1 2.π.σ2 b . exp(−(x)2 − (y)2 2σ2 b ). (2.74) La figure 2.21 représente les probabilités d’erreur de décision Pij évalués analytiquement et par simulation dans le cas d’une puissance du bruit de quantification de 0.5. Figure 2.21 – Probabilité d’erreur de décision P3 ij dans le cas d’une puissance du bruit de quantification de 0.5 Nous pouvons remarquer que les Pii sont les probabilités les plus élevées parce qu’elles sont en d’autres termes les probabilités de ne pas avoir une erreur de décision. Par contre les probabilités d’erreur de décision PS1,S3 et PS3,S1 sont quasiment égales et correspondent aux probabilités d’erreur de décision les plus faibles car les symboles S1 et S3 sont les symboles les plus éloignés de la constellation. C’est également le cas pour les probabilités PS2,S4 et PS4,S2 . De façon analogue aux résultats établis dans le cas de la première approche, nous représentons à la figure 2.22 la probabilité d’erreur de décision totale obtenue à partir de l’approche analytique présentée ci-avant et celle obtenue à partir de simulations de type Monte-Carlo.74 Évaluation analytique de la précision des algorithmes de décodage sphérique Figure 2.22 – Probabilité d’erreur au niveau de l’antenne n˚3 de décision totale dans le cas d’une constellation 4-QAM Antenne 2 En suivant le même raisonnement que précédemment, nous analysons ci-après les performances de l’algorithme SSFE au niveau de l’antenne de réception n˚2. Soit xˆ2,ij,st le signal présent à l’entrée de l’opérateur de décision de l’antenne n˚2 sous contrainte d’un scénario comportant une erreur de décision provenant des opérateurs de décision situés en amont (antenne n˚3 et/ou n˚3). En appelant Pk s,t la probabilité de commettre une erreur de décision correspondant à l’évènement aléatoire suivant : pour l’antenne n˚k, décision d’un symbole St en arithmétique virgule fixe alors que ce symbole correspond à Ss en arithmétique flottante, nous avons : xˆ2,ij,st = y " 2 R22 − R24 R22 dij − R23 R22 dst. (2.75) La FDP de xˆ2,ij,st est égale à la FDP de y " 2 R22 décalée par −R24 R22 dij − R23 R22 dst. Par conséquent les probabilités d’erreur de décision P2 ij sont égales à la somme pondérée des probabilités partielles P" 2 i,j|st,pq qui sont déterminées en appliquant le modèle de l’équation (2.17) à la FDP fxˆ2,pq,st de xˆ2,pq,st et la FDP du bruit de quantification en les multipliant par la probabilité de l’occurrence de ce scénario P4 p,qP3 s,t, soit : P2 ij = / Ri / Rj ( ' M p,q,s,t=1 P4 p,qP3 s,tfxˆ(2),pq,st (x))f(2) B (b − x)dbdx. (2.76) Antenne n˚1 Pour l’antenne n˚1 qui est la dernière antenne du système MIMO considéré, nous utilisons la même technique pour déterminer les probabilités d’erreur de décision P1 ij . Par conséquent nous définissons f1(x) la FDP du signal à l’entrée de l’opérateur de décision de2.4 Application du modèle à l’algorithme SSFE 75 l’antenne n˚1, en tenant compte de tous les scénarios d’erreurs et de bonnes décisions possibles au niveau des autres antennes précédentes n˚2, 3 et 4, par : f 1(x) = ' M p,q,s,t,v,w=1 P4 p,qP3 s,t.P2 v,wfxˆ1,pq,st,vw (x). (2.77) où fxˆ1,pq,st,vw (x) désigne la FDP du signal xˆ1,pq,st,vw à l’entrée de l’opérateur de décision de l’antenne n˚1 sous contrainte d’un scénario d’erreur de décision au niveau des antennes situées en amont dont la probabilité d’occurrence est P4 p,q.P3 s,t.P2 v,w. Elle est égale à la FDP du signal reçu y " 1 R11 décalée par −R14 R11 .dpq − R13 R11 .dst − R12 R11 .dvw. Par conséquent les probabilités d’erreur de décision P1 i,j sont définies par : P1 ij = / Ri / Rj f1(x)f 1 B(b − x)dbdx. (2.78) Figure 2.23 – Probabilité d’erreur de décision totale dans le cas d’une constellation 4-QAM Comme dans le cas de l’antenne n˚3, nous représentons sur les figures 2.23 et 2.25 les probabilités d’erreur de décision au niveau des antennes n˚2 et n˚1. Les conditions d’expérimentations sont identiques à celles sélectionnées précédemment pour l’étude de l’antenne n˚3. Ainsi, les signaux reçus correspondent aux symboles 4-QAM perturbés un bruit blanc additif, bi-variant, gaussien, et centré. De même, le bruit de quantification est modélisé dans ces expériences par un bruit blanc gaussien bidimensionnel de moyenne nulle. La matrice R utilisée dans ces expériences est donnée par :76 Évaluation analytique de la précision des algorithmes de décodage sphérique R =   −0.4993 −0.1413 − 0.1131i 0.3099 − 0.3319i −0.4374 + 0.3375i 0 0.48 −0.025 − 0.1395i 0.1814 + 0.1514i 00 0.403 −0.0303 − 0.1145i 00 0 −0.4766   (2.79) Figure 2.24 – Probabilité d’erreur de décision P2 ij dans le cas d’une constellation 4-QAM Nous remarquons que la probabilité d’erreur de décision totale causée par l’arithmétique virgule fixe augmente d’une antenne à l’autre de la cascade d’opérateurs de décision pour un rapport signal à bruit donné en entrée du récepteur. Ce résultat était prévisible puisque la propagation des erreurs de décision non lisses augmente la probabilité d’avoir d’autres erreurs de décision au sein des opérateurs de décision correspondant aux antennes situées en aval de l’antenne courante. En effet, le bruit à l’entrée de l’opérateur de décision considéré n’est pas seulement constitué du bruit de quantification du format virgule fixe, mais aussi d’autres bruits modélisant les erreurs engendrées par les opérateurs de décision situés en amont de l’antenne courante. Nous pouvons également vérifier la robustesse de notre modèle analytique en comparant les probabilités d’erreur de décision Pi,j analytiques et celles obtenues par simulation. La somme de toutes les probabilités Pi,j est égale à 1, ce qui valide le modèle analytique proposé. De plus d’après les figures, il est clair que les probabilités obtenues analytiquement sont très proches des probabilités par simulation avec une marge d’erreur très faible (inférieure à 1%).2.4 Application du modèle à l’algorithme SSFE 77 Figure 2.25 – Probabilité d’erreur de décision totale dans le cas d’une constellation 4-QAM Figure 2.26 – Probabilité d’erreur de décision P1 ij dans le cas d’une constellation 4-QAM Afin de montrer l’intérêt du modèle analytique proposé, nous citons un ordre de grandeur du temps d’exécution mis pour estimer l’ensemble des probabilités d’erreur de décision P1 i,j au niveau de l’opérateur de décision de l’antenne n˚1. Le temps d’exécution nécessaire pour évaluer78 Évaluation analytique de la précision des algorithmes de décodage sphérique numériquement les probabilités P1 i,j dans le cas d’une constellation 4-QAM est de 6 minutes et 37 secondes. Par contre, le temps nécessaire à la simulation de toute la chaîne de transmission MIMO avec un détecteur SSFE en arithmétique virgule flottante et en arithmétique virgule fixe est de l’ordre 47 minutes et 56 secondes avec les mêmes ressources informatiques et les mêmes capacités de calcul et mémoire (Processeur Intel i7 2.50 GHz, 4 coeurs, RAM : 4 Go). 2.5 Conclusion Dans ce chapitre, nous avons caractérisé les opérateurs non lisses et leurs identifications. Dans un premier temps, nous avons présenté un modèle analytique pour l’évaluation de la précision d’un opérateur de décision non lisse en estimant la probabilité d’erreur de décision causée par la quantification du format virgule fixe. Ensuite, nous avons analysé la propagation des erreurs de décision au sein d’un système contenant plusieurs opérateurs non lisses de décision afin d’être en mesure de proposer un modèle général pour évaluer la précision des systèmes contenant une cascade d’opérateurs de décision en tenant compte de la propagation des erreurs et de tous les scénarios d’erreurs possibles dans la cascade. En outre, nous avons développé ce modèle dans le cas de l’algorithme SSFE en proposant deux approches pour estimer les probabilités d’erreur de décision au sein de chaque opérateur de décision impliqué dans la cascade au niveau de l’algorithme. Nous avons réussi à proposer un modèle analytique pour évaluer la cascade d’opérateurs de décision et résoudre le problème d’évaluation de l’influence de la représentation en virgule fixe pour une certaine classe d’algorithmes de communications numériques. Cependant, d’autres algorithmes, également constitués par des blocs d’opérations lisses et des opérateurs de décision, ne peuvent être analysés à l’aide de ce modèle en raison de leur structure récursive. Le récepteur à égaliseur à retour de décision (DFE pour Decision Feedback Equalizer) en est un exemple important. Dans le prochain chapitre nous proposerons des modèles analytiques pour évaluer ce genre de configuration et nous montrerons comment les modèles proposés peuvent contribuer à une implémentation matérielle efficace en termes de consommation de ressources matérielles et d’énergie.Chapitre 3 Évaluation de la précision de l’itération d’opérateur de décision Sommaire 3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 3.1.1 Caractéristiques de la propagation du bruit . . . . . . . . . . . . . . . . 80 3.2 Modèle analytique proposé . . . . . . . . . . . . . . . . . . . . . . . . . . 81 3.2.1 Approche basée sur la résolution d’un système non linéaire à l’aide de l’algorithme de Newton-Raphson . . . . . . . . . . . . . . . . . . . . . . 81 3.2.2 Borne supérieure de la probabilité d’erreur . . . . . . . . . . . . . . . . 85 3.3 Évaluation de la précision de l’égaliseur à retour de décision . . . . . 88 3.3.1 Présentation de l’algorithme DFE . . . . . . . . . . . . . . . . . . . . . 88 3.3.2 Résultat pour le cas non adaptatif . . . . . . . . . . . . . . . . . . . . . 89 3.3.3 Solution proposée pour le cas adaptatif . . . . . . . . . . . . . . . . . . 90 3.4 Optimisation du format virgule fixe pour l’implémentation matérielle 94 3.4.1 Présentation de l’architecture . . . . . . . . . . . . . . . . . . . . . . . . 94 3.4.2 Implémentation sur FPGA . . . . . . . . . . . . . . . . . . . . . . . . . 95 3.4.3 Les contraintes du choix du format de représentation . . . . . . . . . . . 97 3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Nous avons présenté dans le chapitre précédent des modèles analytiques pour évaluer la précision des opérateurs non lisses de décision et leurs cascades en estimant la probabilité d’erreur de décision causée par le bruit de quantification de l’arithmétique virgule fixe et également la propagation des erreurs de décision d’un opérateur de décision à un autre dans un système constitué d’une cascade de ces opérateurs, tel par exemple qu’un récepteur utilisant un décodage sphérique de type SSFE. Néanmoins, d’autres systèmes de communication numérique et de traitement de signal, tels que les algorithmes d’égalisation à retour de décision ou bien encore le turbo décodage, présentent des itérations d’opérateurs non lisses au sein d’une structure récursive ce qui est encore équivalent à considérer une cascade infinie d’opérateurs de décision. Par conséquent, il est intéressant de se demander dans quelle mesure les modèles proposés au chapitre précédent pour l’évaluation de la précision des applications contenant des cascades d’opérateurs de décision sont applicables pour évaluer les itérations d’opérateurs de précision lisses et sous quelles contraintes ? Donc, il est nécessaire d’analyser la propagation des erreurs de décision non lisses dans ces applications en modélisant cette propagation du bruit et des erreurs de décision. En effet, il est fondamental de caractériser l’effet des erreurs de décision dans des applications d’itérations d’opérateurs non lisses de décision spécifiquement au moment où l’application converge vers les performances visées par le concepteur. A notre connaissance, il n’existe aucun modèle analytique disponible dans la littérature permettant d’évaluer les performances de ces applications en virgule fixe pour un format bien déterminé. Par conséquent, il est important de proposer des modèles analytiques permettant de caractériser les erreurs de décision lors de la phase asymptotique 7980 Évaluation de la précision de l’itération d’opérateur de décision de ces applications comportant des itérations d’opérateurs non lisses. En effet, il est nécessaire de pouvoir disposer de tels outils afin de sélectionner le format optimal de représentation en arithmétique virgule fixe en termes de probabilité d’erreur de décision minimale mais aussi en termes d’optimisation de l’implémentation matérielle à travers la minimisation des ressources et de la consommation en énergie. Ce chapitre vise à présenter des modèles analytiques permettant d’évaluer la précision des applications formées de structures récursives d’opérateurs non lisses. Nous présenterons dans un premier temps la problématique de la propagation des erreurs dans le cas de ces applications. Ensuite deux modèles analytiques pour évaluer la précision des itérations d’opérateurs de décision seront représentés par deux approches différentes. Nous validerons ces modèles dans la troisième section en les appliquant dans le cas de l’égaliseur à retour de décision DFE (Decision Feedback Equaliser). Dans la dernière section de ce chapitre, nous illustrons l’intérêt de ces modèles analytiques dans le cas particulier de l’optimisation du format en virgule fixe du DFE pour une implémentation sur FPGA. 3.1 Problématique Nous considérons un système représenté par la figure 3.1 constitué par des blocs d’opérations lisses et une itération d’opérateurs de décision. Ce système est constitué d’une opération de décision dont la sortie influence la prochaine décision jusqu’à une convergence de l’application du système. Figure 3.1 – Système contenant une itération d’opérateur de décision Ce système est composé de N entrées Y = [y1, y2, ..., yN ] qui sont perturbées par les bruits de quantification B = [b1, b2, ..., bN ]. Chaque bruit bi perturbe l’entrée yi. Soient xˆi et x˜i respectivement l’entrée et la sortie de l’opérateur de décision à la i eme itération. Le second bloc d’opérations lisses dont la fonction est L2(ˆxi−1, xˆi−2, ..., xˆi−Tl ) possède à son entrée les sorties de l’opérateur de décision aux itérations précédant l’itération actuelle avec une mémoire de taille Tl éléments. Dans la suite du chapitre, nous nommerons xˆvf lo i et xˆvf ix i les entrées de l’opérateur de décision à l’itération n˚i respectivement en arithmétique virgule flottante et virgule fixe. De même, x˜vf lo i et x˜vf ix i correspondent aux sorties de l’opérateur de décision à l’itération n˚i respectivement en arithmétique virgule flottante et virgule fixe. 3.1.1 Caractéristiques de la propagation du bruit Dans le chapitre précédent, nous avons présenté un modèle analytique pour l’évaluation de la précision d’un opérateur de décision non lisse. Ce modèle n’est plus valide pour évaluer la précision d’un système constitué d’une structure récursive de plusieurs opérateurs de décision. Par conséquent, il est nécessaire de modifier ce modèle et de l’adapter aux contraintes de ces3.2 Modèle analytique proposé 81 systèmes en tenant compte de tous les scénarios d’erreurs possibles et leurs propagations dans le système considéré. De même, il est fondamental de caractériser la propagation des erreurs de décision et leur impact non seulement sur la décision de l’itération en cours, mais aussi lorsque le système converge. Pour cette raison, il est important de modéliser cette propagation dans le mode de convergence des systèmes comportant des itérations d’opérateurs non lisses. A l’itération courante (n˚i), le signal présent en entrée de l’opérateur de décision est donné par : xˆvf ix i = L1(˜xvf ix i−1 , x˜vf ix i−2 , ..., x˜vf ix i−Tl ) + L2(yvf ix 1 , ..., yvf ix N ) = L1(˜xvf lo i−1 , x˜vf lo i−2 , ..., x˜vf lo i−Tl ) + L2(yvf lo 1 , ..., yvf lo N ) + l(bi−Tl , ..., bi−1, x˜vf ix i−1 , x˜vf ix i−2 , ..., x˜vf ix i−Tl , x˜vf lo i−1 , x˜vf lo i−2 , ..., x˜vf lo i−Tl ) + bL = ˆxvf lo i + Lpro(Bi , X˜i vf lo, X˜i vf ix) + bL (3.1) où Bi est le vecteur des perturbations à l’itération i. Lpro représente la fonction de propagation du bruit de quantification lors des itérations précédentes en respectant la taille Tl de la mémoire du bloc lisse situé après l’opérateur de décision de l’itération. Le signal bL correspond au bruit ajouté par les opérateurs lisses de l’implémentation en arithmétique virgule fixe des fonctions lisses L1 et L2. Enfin, X˜i vf ix = [˜xvf ix i−1 , x˜vf ix i−2 , ..., x˜vf ix i−Tl ] et X˜i vf lo = [˜xvf lo i−1 , x˜vf lo i−2 , ..., x˜vf lo i−Tl ] désignent les vecteurs contenant les sorties des opérateurs de décision enregistrées dans la mémoire du bloc lisse respectivement en arithmétique virgule fixe et virgule flottante. La propagation des erreurs à la sortie de l’opérateur de décision des itérations précédentes possède des caractéristiques non lisses. Par conséquent, la fonction Lpro de la propagation des bruits de quantification doit être évaluée pour chaque erreur de la première itération jusqu’à l’itération courante en cours d’évaluation. Cette évaluation est nécessaire jusqu’à la convergence du système où l’impact de la quantification doit être négligeable si l’on souhaite obtenir une évaluation précise des paramètres de ce système. 3.2 Modèle analytique proposé L’objectif de la caractérisation de la propagation des erreurs de quantification d’une itération à l’autre consiste à évaluer les différentes probabilités d’erreur de décision Pij lorsque le système converge. En effet, la convergence du système conduit à une convergence au niveau des probabilités d’erreur de décision d’une itération à une autre. En d’autres termes, l’évolution de la probabilité d’erreur de décision d’une itération à une autre est négligeable lors de la phase de convergence asymptotique. Deux approches différentes sont proposées pour résoudre cette problématique. La première approche est basée sur une résolution d’un système non linéaire en utilisant la méthode de NewtonRaphson qui sera détaillée dans la section suivante. La deuxième approche est fondée sur le principe de détermination d’une borne supérieure de l’erreur de décision dans la zone de convergence du système. 3.2.1 Approche basée sur la résolution d’un système non linéaire à l’aide de l’algorithme de Newton-Raphson Considérons vvf lo et vvf ix deux instances des valeurs prises respectivement par X˜i vf lo et X˜i vf ix. Par conséquent, la fonction de propagation s’écrit sous sa forme particulière l v pro qui est réduite à une fonction dépendante du vecteur des perturbations Bi. Le signal en virgule fixe à l’entrée de l’opérateur de décision au cours de l’itération i s’écrit par la relation suivante : xˆvf ix i = ˆxvf lo i + l v pro(Bi) + bL = ˆxvf lo i + bt. (3.2) Les vecteurs des données en entrée de l’opérateur de décision en arithmétique virgule fixe et virgule flottante représentent conjointement un scénario S déterminé par les conditions en82 Évaluation de la précision de l’itération d’opérateur de décision entrée et la propagation des signaux à travers les blocs lisses L1 et L2. Les bruits des blocs lisses engendrés par l’implémentation en arithmétique virgule fixe sont intégrés au sein du paramètre bt. En ce qui concerne l’opérateur de décision, nous considérons dans la suite que, à chaque itération, celui-ci effectue une décision dans un alphabet correspondant aux M symboles constituant la constellation de la modulation utilisée. Ainsi, le vecteur X˜i peut prendre C = MTl combinaisons possibles. Le vecteur V i défini par V i = [vvf lo, vvf ix] représente un scénario bien déterminé des valeurs particulières prises par les vecteurs X˜i vf lo et X˜i vf ix. Il existe C × C scénarios possibles. Par conséquent, après N itérations, la probabilité P Sk i,j d’erreur de décision est déterminée comme dans le cas de la cascade d’opérateurs de décision par l’équation suivante : P Sk i,j = / Ri / Rj fSk x (x)fb(b − x)dbdx. (3.3) Cette probabilité représente la probabilité que la valeur de x˜N corresponde à Si en arithmé- tique virgule flottante et à Sj en arithmétique virgule fixe sous la la condition de la réalisation d’un scénario Sk. La fonction fSk x (x) représente la FDP du signal xˆvf lo N correspondant à la réalisation du scénario Sk. De façon analogue, fb(b) correspond à la FDP du bruit total bt. La probabilité P i, j d’erreur de décision Pi,j à la sortie de l’opérateur de décision au cours de l’itération N est déterminée en considérant tous les scénarios possibles de propagation des erreurs de quantification. Par conséquent, la probabilité d’erreur de décision P N i,j à la sortie de l’opérateur de décision de l’itération N est une somme des probabilités P Sk i,j d’erreurs de décision sous la contrainte du scénario Sk pondérées par la probabilité PSk de réalisation de ce scénario. P N i,j = ' C2 k=1 PSk P Sk i,j = ' C2 k=1 / Ri / Rj PSk fSk x (x)fb(b − x)dbdx. (3.4) La détermination des probabilités Psk est faite de la même façon que dans le cas d’une cascade d’opérateurs de décision en respectant la taille de la mémoire Tl du bloc lisse sauvegardant les sorties de l’opérateur de décision obtenues lors des itérations précédentes. Par conséquent, la probabilité Psk de l’occurrence du scénario k est donnée par : PSk = P((˜xvf lo N−1 = SiN−1 , x˜vf ix N−1 = SjN−1 ) et ... et (˜xvf lo N−Tl = SiN−Tl , x˜vf ix N−Tl = SjN−Tl )). (3.5) Les paramètres Sir et Sjr représentent les valeurs prises par les sorties de l’opérateur de décision respectivement en arithmétique virgule flottante et virgule fixe au cours de l’itération r. Considérons le cas où les sorties de l’opérateur de décision ne sont pas corrélées. Par conséquent la probabilité de l’occurrence du scénario k est le produit des probabilités d’erreur de décision Pk ir,jr = P(˜xvf lo r = Sir , x˜vf ix r = Sjr ) : PSk = N >−1 r=N−Tl Pk ir,jr . (3.6) Ainsi, la probabilité d’erreur de décision P N i,j s’écrit sous la forme suivante : P N i,j = ' C2 k=1 N >−1 r=N−Tl Pk ir,jr .P Sk i,j = P N−1 i,j + β (3.7) où β désigne une quantité positive. Par conséquent, la probabilité d’erreur de décision Pi,j converge puisqu’elle constitue une suite croissante et majorée. L’objectif est d’évaluer cette probabilité analytiquement dans le mode de convergence. Nous pouvons utiliser l’approche analytique3.2 Modèle analytique proposé 83 de la cascade d’opérateurs de décision pour déterminer analytiquement la probabilité d’erreur de décision dans la zone de convergence. Par contre, lorsqu’il s’agit d’un nombre assez élevé d’itérations pour atteindre le mode de convergence, cette approche nécessite de très grandes capacités de calculs pour prendre en compte tous les scénarios possibles. Par conséquent, il est nécessaire de trouver une autre piste afin d’évaluer analytiquement cette probabilité d’erreur de décision lorsque le système converge. Soit Pk le vecteur des probabilités d’erreur de décision Pk i,j à l’itération k défini par : Pk = [Pk 1,1, Pk 1,2, ..., Pk i,j , ..., Pk M,M] T . (3.8) Lors de la phase de convergence asymptotique, on a Pk = P quel que soit k>k0, avec P représentant le vecteur des probabilités d’erreur de décision. Par conséquent, l’équation (3.7) conduit à un système non linéaire de M2 inconnues sous la conditions que 4 M i,j=1 Pi,j = 1. En conséquence, le problème d’évaluation de la précision conduit à la résolution d’un système non linéaire à M2 inconnues défini par : P = RP .P (3.9) avec RP représentant une matrice de dimension M2 × M2 et qui dépend du vecteur P ce qui rend le système (3.9) non linéaire. Afin de résoudre numériquement ce problème non linéaire, nous avons sélectionné l’algorithme de Newton-Raphson en raison de la simplicité de sa mise en œuvre, mais aussi pour son efficacité et sa rapidité. Considérons un système non linéaire de dimension n défini par : fi(x1, x2, ..., xn) = 0; 1 ≤ i ≤ n. (3.10) Soit X = (x1, x2, ..., xn). Au voisinage de X, nous pouvons écrire un développement de Taylor à l’ordre 1 pour chaque fonction fi : fi(X + δX) = fi(X) + 'n j=1 dfi dxj (X)δxj + O(0δX02 ). (3.11) Le principe de l’algorithme de Newton-Raphson consiste à considérer que l’on puisse connaître un vecteur X qui se situe dans le le voisinage de la solutions optimale. Ensuite, nous cherchons δX tel que X + δX s’approche de la solution en négligeant les termes de second ordre dans le développement de Taylor. Nous itérons ce processus, i.e. X < −X + δX, jusqu’à ce que le terme correctif δX devienne négligeable ce qui conduit à la phase de convergence asymptotique. Par conséquent, le système non linéaire est réduit à un système linéaire avec n equations et n inconnues qui sont les éléments du vecteur δX. Le détail de l’algorithme Newton-Raphson est explicité dans l’annexe. Afin de valider cette approche, nous considérons le système défini par la figure 3.2. Figure 3.2 – Système composé d’itération d’opérateurs de décision Ce système est constitué d’un opérateur de décision en itération avec un filtre FIR de L coefficients. Le signal xˆk à l’entrée de l’opérateur de décision au cours de l’itération k dépend84 Évaluation de la précision de l’itération d’opérateur de décision non seulement du signal reçu xk mais aussi des sorties de l’opérateur de décision x˜ au cours des itérations précédentes sous contrainte de la taille de la mémoire du filtre L. Le signal xˆk est défini par : xˆk = xk − ' L l=1 hl.x˜k−l (3.12) où hi désignent les coefficients du filtre H. Nous visons à déterminer la probabilité d’erreur de décision dans le mode de convergence du système en s’appuyant sur l’approche explicitée ci dessus. Soit ze k le signal qui prend en compte le signal xk et soit ∆i,j la différence entre les symboles impliqués dans l’erreur produite dans les itérations précédentes. Le signal ze k s’écrit par : ze k = xk − ' L l=1 hl.∆il,jl . (3.13) Par conséquent, la FDP fze k (x) du signal ze k dépend des probabilités d’erreur de décision précédentes Pk−1 i1,j1 ,Pk−2 i2,j2 ,...,P0 ik,jk . Pour k ≤ L, Cette FDP s’écrit par : fze k (x) = ' M i1=1 ' M j1=1 ... ' M iL=1 ' M jL=1 Pk−1 i1,j1 ...Pk−L iL,jL .fzk i1,j1,...iL,jL (x) (3.14) avec fzk i1,j1,...ik,jk (x) est la FDP du signal xk dont la moyenne est décalée par 4 k l=1 hl.∆il,jl . La probabilité d’erreur de décision Pk i,j pour l’itération k est donnée par : Pk i,j = / Ri / Rj fze k (x).fB(b − x)db.dx. (3.15) Dans le mode de convergence où Pk = P quelque soit k>k0, nous définissons le signal ze par le signal qui prend en compte la propagation des erreurs de décision dont la FDP est défini par : fze (x) = ' M i1=1 ' M j1=1 ... ' M iL=1 ' M jL=1 Pi1,j1 ...PiL,jL .fzi1,j1,...iL,jL (x). (3.16) La probabilité d’erreur de décision dans le mode de convergence s’écrit alors suivant : Pi,j = / Ri / Rj ' M i1=1 ' M j1=1 ... ' M iL=1 ' M jL=1 Pi1,j1 ...PiL,jL .fzi1,j1,...iL,jL (x).fB(b − x)db.dx. (3.17) Nous obtenons ainsi un système de la forme P = RP .P dont la résolution peut être obtenue par la méthode de Newton-Raphson. Pour tester ce modèle générique, nous utilisons des signaux reçus xk composés de M composantes gaussiennes correspondant aux M symboles de la constellation M-QAM perturbés par la présence d’un bruit de canal blanc, bi-variant gaussien de variance σ2 b et centré. fxk (x) = ' M j=1 1 M 1 √2πσy exp(−(x − Sj ) 2 2σ2 y ). (3.18) fB(x) = 1 √2πσb exp(−(x) 2 2σ2 b ). (3.19) Afin d’évaluer l’influence de la variance du bruit de quantification sur le système, nous modifions le nombre de bits du format de quantification. Ainsi, pour chaque puissance de bruit, l’exécution de3.2 Modèle analytique proposé 85 l’algorithme du système permet d’obtenir les signaux en sortie du système en arithmétique virgule fixe et virgule flottante. Il est alors possible de comparer les sorties de l’opérateur de décision dans le mode de convergence asymptotique ce qui permet d’obtenir la probabilité d’erreur de décision par simulation Monte Carlo. Par ailleurs, nous avons programmé en langage C l’algorithme de Newton-Raphson afin de solutionner le système non linéaire (3.9) décrit précédemment, et ainsi d’obtenir quasi-analytiquement la probabilité d’erreur de décision dans le mode de convergence asymptotique. La figure 3.3 montre la probabilité d’erreur de décision obtenue analytiquement par notre modèle ainsi par ainsi que celle obtenue par simulations dans le cas particulier d’une constellation de type QPSK et d’un filtre H à retour de décision constitué de 4 coefficients {h1, h2, h3, h4}. Figure 3.3 – Probabilité d’erreur de décision pour une constellation QPSK Nous remarquons que les résultats analytiques correspondent à ceux obtenus par simulation avec une marge d’erreur inférieure à 1%. Nous pouvons donc conclure que le modèle analytique proposé permet de prendre en compte la cascade d’opérateurs de décision induits par le caractère récursif du système 3.2.2 Borne supérieure de la probabilité d’erreur Lorsque le calcul de la probabilité d’erreur de décision devient trop complexe d’un point de vue purement calculatoire, une autre alternative fondée sur une borne supérieure de la probabilité d’erreur de décision peut être envisagée. Nous présentons dans cette section cette deuxième approche pour évaluer la précision en virgule fixe des systèmes constitués d’une structure récursive intégrant un ou plusieurs opérateurs non lisses de décision. Soit ek l’erreur de décision causée par la conversion en format virgule fixe à l’instant k. Chaque erreur ek−j prend une valeur d’un ensemble de D valeurs distinctes. Si seulement K < ∞ erreurs passées affectent la décision en cours, la séquence d’erreur (ek−1, ..., ek−K) est par conséquent une des DK valeurs distinctes. Si chacune des DK séquences est assignée à un état, les séquences d’états résultantes constituent une chaîne de Markov. Nous considérons ci-après une alternative pour définir l’affectation des états du système. Pour cela, soit V un entier arbitraire, nous définissons alors les (V + 1) états du système suivant :86 Évaluation de la précision de l’itération d’opérateur de décision Em = {ek−1, ek−2, . . ., |ek−j = 0, 1 ≤ j ≤ m, ek−m−1 .= 0} , 0 ≤ m ≤ V − 1 EV = {ek−1, ek−2, . . ., |ek−j = 0, 1 ≤ j ≤ V } . (3.20) Par conséquent, Em consiste à représenter toutes les séquences d’erreurs constituées de m valeurs nulles suivies d’une unique valeur d’erreur non nulle (à part pour le cas de EV , pour lequel ek−V −1 peut également être nulle). L’ensemble de ces (V + 1) états peut être illustré par le tableau suivant : Etat Séquence d’erreur (E=Erreur, X=Peu importe, 0=Pas d’erreur) E0 EXX... E1 0EXX... E2 00EXX... . . . EV −1 00...0EXX...(M-1 zéros) EV 00...00XX...(M zéros) Table 3.1 – État des séquences d’erreurs Dans une seconde étape, nous définissons un processus aléatoire Sk qui prend une des valeurs entières {0, 1, ..., V }. Supposons que l’état du système soit égal à Ej lorsque le signal xk est reçu et définissons alors Sk = j. Sk est la séquence des états du système. La probabilité que l’état du système soit Em lorsque le signal xk est reçu est la probabilité que Sk = m et elle est définie par la somme des probabilités conditionnelles sous contrainte de l’état du système à l’itération k − 1. p(Sk = m) = ' V i=0 p(Sk = m|Sk−1 = i)p(Sk−1 = i). (3.21) Notons la probabilité p(Sk = i) = pi, par conséquent, pm s’écrit par la relation suivante : pm = ' V i=0 p(Sk = m|Sk−1 = i)pi, 0 ≤ m. ≤ V (3.22) Nous pouvons remarquer que l’état Sk = j ne peut être atteint qu’à partir de l’état Sk−1 = j−1, 1 ≤ m ≤ M. Par conséquent, la plupart des probabilités de transition dans l’équation (3.22) sont nulles. De ce fait, nous définissons la probabilité αm d’une décision correcte étant donné que l’état du système est Sk = m, soit encore : αm = p {ek = 0|Sk = m} . (3.23) Par conséquent, la probabilité que l’état du système soit m est simplifiée par : p0 = ' V m=0 (1 − αm)pm. (3.24) pm = αm−1pm−1, 1 ≤ m ≤ V − 1. (3.25) pV = αV −1pV −1 + αV pV . (3.26) Les probabilités pm, m = 1, ..., V − 1 et pM peuvent être exprimées à partir de p0 suivant : pm = p0 m >−1 i=0 αi, 1 ≤ m ≤ V − 1 (3.27)3.2 Modèle analytique proposé 87 et : pV = p0(1 − αV ) −1 V >−1 i=0 αi. (3.28) En tenant compte du fait que 4 V i=0 pi = 1, nous obtenons : p0 = Q−1 V (3.29) avec : QV =1+ V '−2 i=0 > i m=0 αm + (1 − αV ) −1 V >−1 m=0 αm. (3.30) Notre but est de déterminer la probabilité d’erreur de décision totale PE définie par : PE = p {ek .= 0} = p0 = Q−1 V . (3.31) L’équation (3.29) nous donne uen expression analytique de cette probabilité d’erreur. Il est possible de calculer les probabilités de transition αj , 0 ≤ j ≤ V . Par contre, ce calcul nécessite des capacités calculatoires importantes, et ceci d’autant plus que la constellation utilisée possède un haut rendement spectral (i.e. le cardinal de la constellation devient important). Pour solutionner ce problème, nous proposons de déterminer une borne supérieure de la probabilité d’erreur de décision PE. Pour cela, il est suffisant de borner chacune des probabilités αj , j = 0, ..., V − 1, ce qui revient à trouver α∗ j tel que : 0 ≤ α∗ j ≤ αj ≤ 1. (3.32) Pour V ≤ m ≤ K , toutes les probabilités de transition sont égales. Elles sont définies par : αm = 1 − $ (3.33) où $ désigne la probabilité d’erreur en l’absence d’erreurs de décisions passées. Par conséquent la quantité QK est donné par : QK =1+ V '−1 i=0 > i m=0 αm + K '−2 i=V > i m=0 αm + (1 − αK) −1 V >−1 m=0 αm. K >−1 m=V αm (3.34) soit encore : QK =1+ V '−1 i=0 > i m=0 αm + K '−2 i=V (1 − $) i−V +1 V >−1 m=0 αm + $ −1(1 − $) K−V V >−1 m=0 αm. (3.35) et : QV =1+ V '−2 i=0 > i m=0 αm + $ −1 V >−1 m=0 αm. (3.36) Nous avons montré dans [10] que dans le cas d’une constellation de type M-QAM, αm ≥ 1 M . Par conséquent, en insérant cette relation dans (3.36), nous obtenons un borne inférieure de QV donnée par : QV ≥ 1 + V '−2 i=0 ( 1 M ) i+1 + 1 $ ( 1 M ) V (3.37) QV ≥ (M − 1)($MV + 1) + $M2(MV −1 − 1) $MV (M − 1) . (3.38) Ce qui engendre une majoration de la probabilité d’erreur de décision PE qui est égale à Q−1 V par :88 Évaluation de la précision de l’itération d’opérateur de décision PE ≤ $MV (M − 1) (M − 1)($MV + 1) + $M2(MV −1 − 1). (3.39) Ce résultat constitue un résultat très intéressant car il permet de déterminer une borne supé- rieure de la probabilité d’erreur de décision en fonction du nombre M d’états de la constellation QAM, et également en fontion du paramètre $ qui exprime le format de quantification sélectionné. Nous proposons de tester ce modèle analytique en considérant une application fondamentale de tout récepteur numérique moderne : l’égaliseur à retour de décision ou DFE (pour Decision Feedback Equalizer) dont le fonctionnement sera explicité dans la section ci-après. 3.3 Évaluation de la précision de l’égaliseur à retour de décision Les canaux de transmission réels, tels que les canaux sans-fil de type 4G ou bien encore la transmission sur fibre optique à 400 Gbit/s, sont caractérisés par une propagation de type multi-trajet pouvant introduire un niveau d’interférence entre symboles (ISI) important ce qui peut, dans certains cas, être le principal facteur limitatif du système de transmission considéré. Pour combattre cette limitation, il est possible d’intégrer au sein du récepteur un égaliseur à retour de décision (ou DFE). Cette technique a attiré une attention considérable en raison de sa capacité à supprimer l’interférence entre symbole postcurseur par la partie récursive (ou feedback) de l’égaliseur. De plus, étant donné que seule la partie directe (ou feedfoward) est perturbée par le bruit introduit par le canal de transmission, le compromis bruit/performances ne se pose pas dans la partie récursive ce qui constitue un avantage certain. Le principe dans le fonctionnement d’un tel égaliseur est présenté dans la section suivante. 3.3.1 Présentation de l’algorithme DFE Du fait de leurs nombreux avantages, les égaliseurs à retour de décision (DFE) sont couramment utilisés afin d’éliminer dans les signaux de communication la distorsion induite par les canaux de propagation. En effet, même lorsque l’interférence entre symbole engendrée par le canal est sévère et que le niveau de bruit est important, il est possible d’optimiser les paramètres de l’égaliseur afin qu’il atteigne des performances optimales, i.e. une erreur quadratique moyenne faible aux bornes du circuit de décision. Par ailleurs, du point de vue complexité matérielle, cette technique s’avère très compétitive par rapport à des solutions alternatives telles que par exemple le récepteur à maximum de vraisemblance. Le bloc-diagramme d’un égaliseur à retour de décision est présenté à la figure 3.4. Cet égaliseur est constitué par deux filtres : le filtre forward et le filtre feedback (retour d’information). Les deux filtres sont généralement implémentés à un rythme symbole cependant le filtre forward peut également être implémenté à un rythme fractionnaire (par rapport au rythme symbole) ce qui procure une immunité du récepteur par rapport au choix de l’instant optimal d’échantillonnage. Ce filtre est un filtre transverse qui prend en entrée la sortie du filtre récepteur et de l’échantillonneur. Par conséquent, il ressemble d’une certaine façon à un filtre linéaire. Le filtre feedback prend en entrée les sorties passées de l’opérateur de décision. Puisque ce filtre utilise les décisions passées pour générer sa sortie, il doit être strictement causal. Le filtre forward enlève une partie des interférences ISI du signal reçu, mais en contrepartie laisse une partie des interférences ISI dans le signal (généralement, il s’agit d’interférence intersymbole postcurseur). Le filtre feedback estime l’interférence ISI résiduelle des décisions passées et il la soustrait de la sortie du filtre forward comme montré dans la figure 3.4.3.3 Évaluation de la précision de l’égaliseur à retour de décision 89 Figure 3.4 – Bloc-diagramme d’un égaliseur à retour de décision La solution à retour de décision donne généralement de meilleures performances que l’égaliseur linéaire (i.e. uniquement la partie forward) et ceci pour une complexité additionnelle acceptable. La faible amélioration du bruit du DFE provient du fait qu’en supposant qu’il n’y a pas d’erreur de décision, l’opérateur de décision enlève tout le bruit présent dans le signal [52]. 3.3.2 Résultat pour le cas non adaptatif Dans cette section, nous utilisons l’approche exposée dans le paragraphe 3.2.2 reposant sur le calcul d’une borne supérieure de la probabilité d’erreur de décision pour évaluer la précision d’un égaliseur non adaptatif à structure fixe comme indiqué dans la figure 3.4. Les signaux reçus sont composés des M symboles de la constellation M-QAM perturbés par un bruit de canal supposé blanc, centré et gaussien. Afin d’évaluer les performances de l’approche proposée, nous faisons varier le format de la représentation en virgule fixe, puis, pour chaque format, nous calculons la probabilité d’erreur de décision $ afin d’estimer la borne supérieure. D’autre part nous simulons le DFE en virgule fixe et en virgule flottante afin d’obtenir également la probabilité d’erreur de décision par simulation de type Monte Carlo. Figure 3.5 – Borne supérieure analytique et probabilité d’erreur de décision par simulation La figure 3.5 montre la probabilité d’erreur de décision estimée par simulation ainsi que celle90 Évaluation de la précision de l’itération d’opérateur de décision obtenue de manière analytique à l’aide de l’approche proposée dans le cas d’une constellation 4-QAM et d’un filtre à retour de décision comportant 4 coefficients. Nous pouvons remarquer que la probabilité obtenue avec l’approche analytique proposée se révèle plus précise lorsque le bruit de quantification possède une faible puissance ce qui est généralement le cas en pratique. 3.3.3 Solution proposée pour le cas adaptatif Comme le canal de propagation est inconnu, l’implémentation de l’égaliseur à retour de dé- cision DFE doit se faire d’une façon adaptative. Dans un DFE classique l’adaptation se fait par le biais d’une séquence d’apprentissage, ce qui engendre une diminution du débit utile de la transmission. C’est pour cette raison que de nombreux travaux se sont portés sur la recherche de solutions d’égaliseurs ne nécessitant aucune séquence d’apprentissage. On parle alors d’égalisation aveugle. Dans cet esprit, nous nous sommes intéressés à la solution proposée dans [52] où l’égaliseur possède deux modes de fonctionnement : le mode initial où l’égaliseur est formé de la cascade d’un filtre blanchissant purement récursif R, d’un filtre transverse J et d’un correcteur de phase CP. L’originalité du dispositif provient du fait que chaque étage est adapté par rapport à un critère local spécifique ce qui améliore la robustesse du système global ainsi que la rapidité de convergence des coefficients des filtres numériques vers la solution optimale. Une fois que le processus d’égalisation est suffisamment avancé (ce qui se mesure à travers l’erreur quadratique moyenne aux bornes du circuit de décision), la structure du récepteur est modifiée en un égaliseur conventionnel de type DFE pour lequel les coefficients de la partie backward sont directement obtenus à partir de ceux du filtre blanchissant R. Le caractère réversible de cette modification apporte au nouvel égaliseur un avantage important qui se manifeste dans le fait qu’il peut apprendre de ses propres décisions sans risque de divergence. Considérons une séquence de données discrètes d(k) de moyenne nulle et de variance égale à l’unité. Soit H(z) la fonction du transfert du canal de propagation définie par : H(z) = ' N l=0 h(l)z−l . (3.40) Le signal observé est perturbé par un bruit blanc gaussien additif n(k) de variance σ2 n. Le signal reçu s’exprime de la façon suivante : s(k) = ' N l=0 d(k − l)h(l) + n(k). (3.41) L’égaliseur linéaire MMSE (solution de Wiener) admet comme fonction de transfert : C(z) = σ2 dH∗(1/z∗) σ2 dH(z)H∗. (1/z∗) + σ2 n (3.42) Généralement, cet égaliseur est implémenté en utilisant un filtre transverse d’ordre important (idéalement infini) pour éviter les risques d’instabilité. Cependant, l’utilisation d’un filtre récursif (de type IIR) possède des avantages certains. En premier lieu, le choix d’une structure récursive nécessite en général un nombre de paramètres, i.e. de coefficients, plus faible que celui requis par un filtre transverse équivalent. Enfin, cette structure permet de faire évoluer simplement un schéma d’égalisation linéaire vers un schéma d’égalisation non linéaire de type retour de décision. En effet, les coefficients du filtre IIR blanchissant sont estimés durant la première phase de l’algorithme et correspondent aux coefficients de prédiction linéaire arrière (ou backward) du signal reçu. Ensuite, dans la seconde phase de l’algorithme, ces coefficients sont tout simplement utilisés pour initialiser les coefficients du filtre à retour de décision. Considérons la relations (3.42), le dénominateur de C(z) n’est autre que la densité spectrale de puissance (d.s.p) Ss(z) du signal observé s(k). Par conséquent, si N est le nombre de zéros de la fonction de transfert du canal H(z), alors Ss(z) possède 2N racines, N d’entre elles étant à l’intérieur du cercle unité et les N autres étant à l’extérieur. La DSP Ss(z) peut ainsi se factoriser comme suit :3.3 Évaluation de la précision de l’égaliseur à retour de décision 91 Ss(z) = KG(z)G∗(1/z∗). (3.43) avec G(z) est un polynôme à phase minimale et K une constante réelle positive, on a alors : G(z) = > N k=1 (1 − zkz−1) avec |zk| < 1. (3.44) Ainsi, la fonction de transfert de l’égaliseur est la suivante : C(z) = 1 G(z) σ2 d K H∗( 1 z∗ ) G∗( 1 z∗ ) . (3.45) Le filtre 1 G(z) peut alors être implémenté comme un filtre récursif stable. Ce filtre est également le filtre blanchissant les observations parce que la densité spectrale de puissance de sa sortie est égale à A. Par conséquent, l’égaliseur linéaire optimal est implémenté tel qu’indiqué sur la figure 3.6, où A(z) = G(z) − 1 et B(z) = σ2 d K H∗( 1 z∗ ) G∗( 1 z∗ ) . Figure 3.6 – Structure de l’égaliseur : mode initial Si nous comparons l’égaliseur linéaire optimal avec le DFE conventionnel (figure 3.7), nous pouvons voir que le passage de l’un à l’autre se fait simplement par un changement de structure : inversion de la position des filtres A(z) et B(z). Figure 3.7 – Structure de l’égaliseur : mode final Dans le contexte aveugle, il suffit de trouver les critères permettant de trouver une solution proche de celle du MMSE. La solution de mise en œuvre consiste à mettre en place un algorithme itératif. La détermination du filtre A(z) = 4LA k=1 akz−k demande de minimiser : J1(A) = E[|u(k)| 2]. (3.46) Avec A = (a1, a2, ...aLA )T . L’algorithme itératif qui donne la solution désirée s’écrit alors à l’itération k par : u(k) = s(k) − A(k−1)TULA (k − 1), (3.47) Ak = A(k−1) + vAu(k)U∗ LA (k − 1). (3.48) où A0 = [0, 0, ..0]T et ULA (k−1) = (u(k−1), ..., u(k−LA))T et vA est un pas positif correctement choisi et assurant la convergence de l’algorithme.92 Évaluation de la précision de l’itération d’opérateur de décision Plusieurs algorithmes aveugles de déconvolution permettent de déterminer le filtre B(z) = σ2 d K H∗( 1 z∗ ) G∗( 1 z∗ ) . Le critère de Godard [47] permet de déterminer un égaliseur B(z) de type zero forcing dans un contexte non bruité. Si le bruit n’est pas très fort, le filtre B(z) résultant d’une minimisation du critère de Godard est proche de la solution MMSE souhaitée. L’algorithme itératif qui minimise le critère de Godard est le suivant : v1(k) = B(k−1)TULB+1(k), (3.49) B(k) = B(k−1) + vBv1(k)(1 − |v1(k)| 2)U∗ LB+1(k). (3.50) Où B0 = [0, ..., 01, 0, ..., 0]T et vB un pas positif bien choisi. Nous obtenons à la sortie du CMA (constant modulus algorithm) une estimée des symboles à un retard près et une constante complexe près. Donc, il est nécessaire de mettre en place une méthode de correction de phase. Le critère retenu est : J3(θ) = E[|v1(k) exp(−jθ) − ˆ d1(k)| 2]. (3.51) Où ˆ d1(k) est le keme symbole décidé. Dès que les filtres B(z) et A(z) sont proches de leur valeur finale (lorsque l’erreur quadratique estimée est inférieure à un seuil), le changement de structure peut être effectué. Les filtres B(z), A(z) et θ sont alors adaptés de manière à minimiser le critère (3.51). L’algorithme du gradient stochastique s’écrit : A(k) = A(k−1) + vA( ˆ d2(k) − w2(k))Dˆ ∗(k), (3.52) B(k) = B(k−1) + vB( ˆ d2(k) − w2(k)) exp(jθ(k − 1))T∗(k), (3.53) θ(k) = θ(k − 1) + vθ($(k) + β ' k i=1 $(i)). (3.54) Où y(k)=(B(k−1)T T(k)) exp(jθ(k − 1)), T(k)=[s(k), ..., s(k − LB)]T , Dˆ(k)=[ ˆ d2(k − 1), ... ˆ d2(k − LA)]T , $(k) = Im[w2(k)( ˆ d2(k) − w2(k))∗], (3.55) et vθ est un pas positif bien choisi assurant la convergence de l’algorithme, β est un paramètre positif et θ(0) = 0. Cet algorithme possède l’avantage majeur de posséder une très bonne réactivité et ceci pour un faible coût calculatoire. Son inconvénient est le temps de convergence. Il est également possible d’adapter le mode de fonctionnement de l’algorithme à un mode burst adapté aux systèmes de transmission (tels que le GSM, la 3G, le LTE) où l’information utile est transmise sous forme de slots. Le principe général de ce mode burst repose sur le constat que les paramètres A, B et θ sont plus proches de leurs valeurs optimales à la fin d’un bloc plutôt que au début d’un bloc. Il est alors possible d’itérer la procédure sur un même bloc en initialisant l’algorithme avec les valeurs obtenues en fin de bloc lors de la précédente itération. Ceci permet de réduire nettement le temps de convergence de l’algorithme moyennant une perte de réactivité. Bien évidemment, dans ce fonctionnement en mode burst, il est nécessaire que le canal de propagation soit stationnaire sur la durée du bloc (ce qui est généralement le cas car la durée d’un bloc est choisie comme étant inférieure au temps de cohérence du canal de propagation). Afin de pourvoir évaluer la précision d’un tel égaliseur adaptatif, nous simulons l’algorithme DFE adaptatif en utilisant l’algorithme LMS pour mettre à jour les coefficients des filtres feedback et forward. Dans un second temps, nous remarquons que la variation des coefficients des filtres est très petite lorsque le DFE converge voire même quasiment nulle. La figure 3.8 montre la variation des coefficients des filtres forward et feedback au cours du temps.3.3 Évaluation de la précision de l’égaliseur à retour de décision 93 Figure 3.8 – Variation des coefficients des filtres de l’égaliseur Par conséquent, nous prenons les valeurs des coefficients des filtres dans la zone de convergence et nous les utilisons pour un égaliseur non adaptatif. Ensuite, nous procédons de la même manière qu’un égaliseur non adaptatif en utilisant le modèle analytique de la borne supérieur pour évaluer la probabilité d’erreur de décision dans le régime de convergence de l’égaliseur DFE. Figure 3.9 – Probabilité d’erreur de décision en fonction du nombre de bits Nous reprenons ci-dessous les mêmes conditions expérimentales que celles utilisées précédemment dans le paragraphe 3.2.2. Afin d’évaluer les performances du modèle proposé, nous faisons94 Évaluation de la précision de l’itération d’opérateur de décision varier le nombre de bits du format de représentation en virgule fixe des paramètres (coefficients, signaux) caractérisant l’égaliseur adaptatif de type DFE. Pour chaque format de représentation en virgule fixe, nous évaluons la borne supérieure de la probabilité d’erreur de décision à partir du modèle analytique proposé ainsi que celle estimée par des simulations de type Monte-Carlo. Ces résultats sont représentés sur la figure 3.9 pour une modulation numérique de type 4-QAM. Nous pouvons constater que le modèle analytique proposé permet d’obtenir une estimation fiable de la probabilité d’erreur de décision sur une large gamme de formats de représentation. D’après la figure précédente, il est clair que plus la précision est importante (i.e. augmentation du nombre de bits accordés au format en virgule fixe, plus la probabilité d’erreur de décision causée par la perte en précision de la quantification du format en virgule fixe diminue. Cependant, l’augmentation de la précision engendre également des effets sur la consommations des unités de calcul ainsi que sur l’utilisation des ressources matérielles. Par conséquent, le choix d’un format spécifique de représentation en virgule fixe doit résulter d’un compromis entre la précision obtenue et la consommation du circuit électronique. Cet aspect fera l’objet de la prochaine section où nous montrons que les modèles analytiques proposés peuvent être utilisés efficacement afin de sélectionner un format de représentation en virgule fixe optimisant l’implémentation matérielle d’un égaliseur de type DFE sur FPGA. 3.4 Optimisation du format virgule fixe pour l’implémentation matérielle Dans cette section, l’intérêt du modèle analytique proposé est analysé pour une problématique correspondant à l’implémentation d’un égaliseur de type DFE à coefficients complexes sur FPGA. Nous commençons par présenter la problématique de l’évaluation des coûts de l’implémentation, ensuite nous représentons l’architecture considérée pour l’égaliseur à coefficients complexes et, enfin, nous présentons le choix d’implémentation que nous avons retenu en fonction du compromis entre précision et consommation en énergie et en ressources matérielles. 3.4.1 Présentation de l’architecture Figure 3.10 – Architecture d’un égaliseur DFE à coefficients complexes3.4 Optimisation du format virgule fixe pour l’implémentation matérielle 95 En raison du grand nombre d’applications qui l’utilisent, nous avons choisi d’étudier le cas de l’égaliseur DFE à coefficients complexes composé de deux voies : la voie réelle (ou en phase) et la voie imaginaire (ou en quadrature). Chacune de ces voies est assimilée à une DFE réel mais, additionnellement, des filtres croisés sont insérés entre voies en phase et quadrature ce qui donne lieu à une architecture dite en papillon (ou butterfly) comme représenté à la figure 3.10. Un modèle matériel de l’égaliseur a été développé en utilisant le langage de description matériel HDL(Hardware Description Language) et synthétisé en utilisant l’outil de synthèse de Xilinx (ISE Xilinx). Les simulations du comportement du modèle et la post-synthèse ont été effectuées en utilisant ModelSim. Le schéma d’implémentation de l’égaliseur DFE conçu est donné par la figure 3.11. Figure 3.11 – Diagramme bloc de l’égaliseur DFE implémenté L’égaliseur consiste en une horloge globale et des entrées Reset synchrones. Les entrées sont introduites dans l’égaliseur en utilisant un signal de contrôle de chargement (Load Control Signal). Le processus d’égalisation est initialisé par le signal début (Start Signal). Après la fin de l’égalisation, les données égalisées (Equalized Data) peuvent être obtenues lorsque le signal sortie prête (DataOut Ready Signal) est positionné. La réception des données peut être connue par le biais du signal d’acquittement (DataOut Ack Signal) pour recevoir le prochain bit. Le port état de l’égaliseur (Equalized Status) indique la progression (Active/Idle) de l’égaliseur. Il convient de préciser que les entrées sont chargées en série dans l’égaliseur. Également, les données égalisées sont lues bit par bit en série. Cette technique est utilisée en raison du nombre limité des ports entrées sorties disponibles dans le FPGA. Elle fournit également des flexibilités pour implémenter l’égaliseur DFE avec des longueurs de précision variables sans modifier le port de configuration. 3.4.2 Implémentation sur FPGA Afin de démontrer de l’intérêt des méthodes analytiques proposées dans le cadre de ce travail, nous avons implémenté l’égaliseur DFE à coefficients complexes sur une carte FPGA de type Xilinx Vertex 5 (ML550). Un environnement de test a été développé afin de tester l’égaliseur implémenté. Cette procédure du test est illustrée par la figure 3.12.96 Évaluation de la précision de l’itération d’opérateur de décision Figure 3.12 – Bloc diagramme de la procédure du test sur FPGA Un module de communication RS232 est embarqué dans le FPGA avec le module d’égaliseur DFE pour faire l’interfaçage avec le port RS232 de l’ordinateur. Pour assurer la communication entre le FPGA et l’ordinateur, nous utilisons le logiciel @Matlab. Un driver du port de communication série a été développé en utilisant la programmation C et exécuté dans l’environnement Matlab. Une vitesse de transmission maximale de l’ordre de 115200 kbps est utilisée pour la communication des données en série. Les données en entrée sont générées avec Matlab et envoyées au FPGA avec les signaux de contrôle appropriés. Après le processus d’égalisation, les données égalisées reçues à travers le même port série sont utilisées pour analyser les performances non seulement de l’égaliseur, mais aussi la précision des données en format virgule fixe. L’architecture considérée est composée de 4 filtres forward et 4 filtres feedback. Il y a deux filtres en phase et deux filtres en quadrature pour chaque type de filtre. Par conséquent le signal reçu est décomposé en deux signaux (réel et imaginaire). Chaque signal est filtré par les deux filtres forward en phase et en quadrature. Ensuite, la partie réelle est filtrée par le filtre forward en phase et ajoutée à la partie imaginaire filtrée par le filtre forward en quadrature. La même procédure est faite pour la partie imaginaire. Après cela, chaque voie est ajoutée au symbole décidé filtré par les deux filtres feedback en phase et en quadrature. L’architecture de chaque filtre est donnée par la figure 3.13 Figure 3.13 – Architecture du filtre forward Chaque filtre est composé par deux blocs mémoire de même longueur l : l’un pour stocker les coefficients du filtre et le second pour mémoriser les données en entrée. A l’entrée du filtre, une horloge est utilisée afin d’assurer la synchronisation. Le flot de données en entrée est tout d’abord mémorisé au sein de l’opérateur de retard élémentaire. Chaque valeur est ensuite multipliée par le biais d’un multiplieur avec le coefficient correspondant qui est stocké dans la mémoire des coefficients. Finalement, l’ensemble des valeurs pondérées par les coefficients du filtre est sommé à l’aide d’un additionneur. Pour le filtre feedback, nous avons également considéré une architecture identique à celle du filtre forward.3.4 Optimisation du format virgule fixe pour l’implémentation matérielle 97 Au sein de l’émetteur et du récepteur, des filtres en cosinus surélevé sont utilisés afin de satisfaire à la condition de Nyquist assurant la nullité de l’interférence entre symboles. Le canal de propagation entre Tx et Rx correspond à un canal de type multi-trajets. Une fois que l’égaliseur a atteint son régime asymptotique de convergence, nous prenons les valeurs des coefficients des filtres et les stockons dans les mémoires de nos filtres. Ensuite, nous implémentons notre architecture en utilisant @Matlab pour une constellation de type M-QAM. La figure 3.14 montre que l’égaliseur implémenté effectue bien l’égalisation. Nous commençons par initialiser les mémoires des filtres par des zéros. Ensuite, nous mettons à jour la mémoire des filtres pour chaque itération. Nous avons utilisé 8 coefficients pour le filtre Forward et 4 coefficients pour le filtre Backward avec un facteur de sur-échantillonnage égal à 8. Figure 3.14 – Entrée et sortie de l’égaliseur 3.4.3 Les contraintes du choix du format de représentation Une fois l’architecture générale définie, les données sont ensuite converties en un format de représentation en virgule fixe et il est possible d’estimer la borne de la probabilité d’erreur de dé- cision causée par l’opération de quantification en virgule fixe. Les données en format virgule fixe sont alors utilisées pour estimer les ressources consommées pour le format de précision considéré. En faisant varier la précision des données présentes en entrée du filtre forward ainsi que celles de la sortie du filtre backward au sein de l’architecture de la figure 3.10, il est alors possible d’estimer la borne supérieure de la probabilité d’erreur de décision en utilisant le modèle analytique décrit précédemment. Pour chaque format de précision considéré, les ressources consommées par l’implémentation FPGA sont également estimées en parallèle à l’aide des outils Xilinx. Pour les tests, nous avons choisi de fixer la partie entière du format des données en virgule fixe à 2 bits. Pour faire varier le format de la précision, le nombre na de bits de la partie fractionnaire des entrées du filtre forward ainsi que le nombre nb de la partie fractionnaire de la sortie du filtre feedback varient entre 4 et 16 bits. Pour chaque configuration ainsi obtenue définie par le couple (na, nb), nous calculons la borne supérieure de la probabilité d’erreur de décision ainsi que les ressources consommées par le FPGA. La figure 3.15 est une représentation logarithmique en 3D de la probabilité d’erreur de décision causée par la conversion du format en virgule flottante vers l’arithmétique virgule fixe exprimée en fonction du couple (na, nb) exprimant la précision des données en entrée du filtre forward ainsi qu’en sortie du filtre feedback. Cette même courbe peut également être projetée sur le plan 2D98 Évaluation de la précision de l’itération d’opérateur de décision (na, nb) en utilisant une échelle de couleur pour exprimer la valeur de la probabilité d’erreur de décision (cf. figure 3.20). Figure 3.15 – Probabilité d’erreur de décision en fonction des deux précisions Bien évidemment, nous constatons que la probabilité d’erreur de décision diminue lorsque la précision augmente. De plus, nous pouvons trouver plusieurs couples de précision qui donnent approximativement la même probabilité d’erreur de décision. Nous obtenons ainsi un ensemble de couples de précision (na, nb) qui partagent approximativement la même probabilité d’erreur de décision. Sur la figure 3.15, ceci se manifeste par des régions qui possèdent la même couleur. Afin de faire un choix entre les couples de précisions (na, nb) qui appartiennent à un même ensemble de probabilité d’erreur de décision, il est alors intéressant de pouvoir estimer les ressources consommées par le FPGA en termes de nombre de slices occupés, de slice luts ou slices de type Flip Flop. Nous fixons un critère d’approximation et nous cherchons toutes les précisions qui possèdent approximativement la même borne supérieure de probabilité d’erreur de décision à un facteur prêt. En d’autres termes, nous choisissons une probabilité d’erreur de décision P0 et un facteur d’approximation α, puis nous cherchons les formats en virgule fixe dont les probabilités d’erreur de décision P vérifient le critère : |P − P0| P0 ≤ α. (3.56)3.4 Optimisation du format virgule fixe pour l’implémentation matérielle 99 Figure 3.16 – Probabilité d’erreur de décision Nous représentons sur les figures 3.17 et 3.18 le nombre de slice lut et slice registre occupés pour un ensemble de probabilité d’erreur de décision qui vérifie ce critère pour des paramètres : P0 = 10−3 et α = 0.2. Figure 3.17 – Nombre de slice registres nécessaires pour obtenir une probabilité d’erreur de décision de P0 = 10−3 avec une précision relative de 0.2. Par conséquent, nous devons choisir le format de données qui consomme le minimum de ressources sur le FPGA.100 Évaluation de la précision de l’itération d’opérateur de décision Figure 3.18 – Nombre de slice lut nécessaires pour obtenir une probabilité d’erreur de décision de P0 = 10−3 avec une précision relative de 0.2. Figure 3.19 – Consommation de puissance Un autre aspect intéressant est la consommation de la puissance ou d’énergie. C’est pour cette raison que nous avons choisi de travailler avec la carte ML550 car elle permet de mesurer la puissance consommée. En effet, cette carte possède une résistance Kelvin qui permet de mesurer le courant circulant à travers le cœur du FPGA. La valeur de cette résistance est suffisamment petite (quelque milli-ohm) pour conduire à une perturbation minimale de l’alimentation. Les variations de la tension à travers la résistance (représentant la variation du courant) sont très petites (quelques mV ) et il est difficile de les mesurer. Par conséquent, afin de faciliter les mesures, un amplificateur de tension (le INA333 de chez Texas Instrument) est inséré aux bornes de la résistance (cf. figure 3.20) afin de faciliter la mesure. Cet amplificateur possède un gain de 1003.5 Conclusion 101 pour une bande passante de 3.5kHz. Figure 3.20 – Dispositif pour la mesure de la puissance Si l’on considère une résistance de mesure de courant de R = 10mW sur la carte ML550 et un gain G = 100 pour l’amplificateur, nous obtenons une relation directe entre la tension et le courant circulant dans la résistance : U = R ∗ I (3.57) Uampl = R ∗ I ∗ G = R ∗ I ∗ 100 = 0.01 ∗ I ∗ 100 = I. (3.58) La tension d’alimentation du FPGA est 1V et la variation de cette tension est inférieure à 0.05V (par mesure). La puissance est directement liée à la tension de l’amplificateur. P = Uampl ∗ V ≈ Uampl. (3.59) La dernière étape est l’analyse des résultats obtenus en fonction de la précision choisie. A ce stade, nous avons tous les éléments pour analyser l’influence de la précision choisie sur la consommation en énergie et en ressources de l’algorithme. Il suffit alors de mesurer cette consommation pour un ensemble de formats de représentation des données en virgule fixe dont la borne supé- rieure de probabilité d’erreur de décision satisfait à la condition (3.56). Nous souhaitons pouvoir déterminer le format de données qui engendre une consommation minimale de puissance et de ressources sur le FPGA. A partir de la figure 3.19, nous pouvons constater que ce minimum est atteint pour une consommation d’environ 63.25mW ce qui correspond à une probabilité d’erreur de décision de 9.5710−4. Nous constatons sur la figure 3.18 que le format optimal de données précédent (format A) est également celui qui fournit la consommation la plus faible de slice LUT par rapport à toutes les autres représentations possibles de l’ensemble considéré. Par contre, pour ce qui concerne le critère du nombre de slice registre, la figure 3.17 montre que la précision (format B) dont la probabilité d’erreur de décision est de 9.8810−4 s’avère la plus intéressante. Nous pouvons dans ce cas conclure que la première précision, i.e. le format A, est un bon compromis entre le coût en consommation de puissance et les performances en termes de probabilité d’erreur de décision. 3.5 Conclusion Nous avons traité dans ce chapitre le problème de propagation des erreurs de décision causées par l’arithmétique virgule fixe dans l’itération d’opérateur de décision au sein d’une structure récursive. Ce problème se rencontre dans de nombreuses applications de traitement du signal et de communications numériques, et plus particulièrement, dans l’opération d’égalisation à retour de décision. Pour cette application, nous avons présenté deux approches différentes pour estimer la probabilité d’erreur de décision dans le régime de convergence de l’égaliseur DFE. Les modèles analytiques proposés sont valides pour tout système constitué d’itération d’opérateurs de décision. Le premier modèle fournit une expression quasi-exacte de la probabilité d’erreur de décision et102 Évaluation de la précision de l’itération d’opérateur de décision il est basé sur la résolution d’un système non linéaire par la méthode de Newton Raphson. Cependant, ce premier modèle peut être limité par les grandes capacités de calcul requises dans le cas de constellations à haut rendement spectral (i.e. à grand nombre d’états). Le second modèle proposé est fondé quant à lui sur l’estimation d’une borne supérieure de la probabilité d’erreur de décision. Ce modèle a été utilisé pour choisir le format optimal en arithmétique virgule fixe pour réaliser une implémentation matérielle rigoureuse en termes de consommation de ressources et d’énergie. D’autres applications à structure itérative non linéaire telles que les turbo décodeurs et les décodeurs LDPC n’ont pas été évaluées et dimensionnées en format virgule fixe dans la littérature. C’est pour cette raison que nous consacrons le prochain chapitre à l’étude spécifique de ces applications.Chapitre 4 Évaluation de la précision du turbo décodage Sommaire 4.1 L’optimisation de la largeur des données en virgule fixe . . . . . . . . 104 4.1.1 Variantes du problème . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.1.2 Variable d’optimisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 4.1.3 Solution au problème d’optimisation de la longueur du mot de code . . 106 4.2 Optimisation du turbo décodage . . . . . . . . . . . . . . . . . . . . . . 106 4.2.1 Présentation de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . . . 106 4.2.2 Modélisation et design en virgule fixe . . . . . . . . . . . . . . . . . . . 111 4.2.3 Réduction de la taille de mémoire . . . . . . . . . . . . . . . . . . . . . 114 4.2.4 Performance du turbo décodeur . . . . . . . . . . . . . . . . . . . . . . . 116 4.3 Optimisation du décodage LDPC . . . . . . . . . . . . . . . . . . . . . . 119 4.3.1 Modélisation et design en virgule fixe d’un décodeur LDPC . . . . . . . 122 4.3.2 Réduction de la taille de mémoire . . . . . . . . . . . . . . . . . . . . . 124 4.3.3 Performance en virgule fixe du décodeur LDPC . . . . . . . . . . . . . . 124 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126 Les systèmes de communications modernes comptent sur l’opération de codage canal pour améliorer la fiabilité de la liaison de communication et par conséquent la qualité de service (QoS) à l’utilisateur final. Pour atteindre cet objectif, un bloc d’informations issues de la source est encodé en un mot de code comportant de la redondance de l’information de source sous forme de bits de parité. A la réception, ces bits de parité sont exploités par le décodeur pour effectuer la correction d’erreur en avant (Forward Error Correction FEC), signifiant la correction partielle ou complète des erreurs introduites par la transmission à travers un canal bruité. Deux catégories principales de codes de canal ont gagné l’élan de la communauté scientifique et industrielle : les codes de contrôle de parité à faible densité [46] et la concaténation en série ou en parallèle des codes convolutifs [80] : on parle alors de SCCC (pour Serial Concatenated Convolutional Code) ou de PCCC (pour Parallel Concatenated Convolutional Code). Les codes LDPC ont été conçus en premier lieu par R. Gallager dans les années 60, ils ont été vite abandonnés à cause de la technologie micro électronique inadéquate et incapable de satisfaire à la complexité de l’algorithme de décodage. Dans le début des années 90, les codes de canal sont devenus plus populaires, lorsque C. Berrou et A. Glavieux ont inventé le turbo décodage des PCCCs [22], vite étendu aux SCCCs [80][81]. Ces travaux ont marqué l’entrée dans une nouvelle ère des communications numériques puisqu’ils ont ouvert la voie à de nombreuses activités de recherche et d’avancées dans le domaine de la théorie de l’information. Par ailleurs, l’évolution continue de la technologie VLSI (Very Large Scale of Integration) a renforcé le succès des turbo codes et codes LDPC. Les processus CMOS submicroniques permettent l’implémentation des décodeurs en maintenant une fréquence d’horloge très élevée et donc ceci permet d’avoir un très 103104 Évaluation de la précision du turbo décodage haut débit. Actuellement, divers standards de communication spécifient l’utilisation de turbo ou LDPC codes ou les deux pour la correction d’erreurs. Ceci couvre différentes applications et services tels que les réseaux d’accès i.e. les réseaux d’accès locaux sans fil (W-LANs) [9] et les ré- seaux d’accès métropolitains sans fil tels que la norme WIMAX [8], les réseaux cellulaires à haute vitesse avec tout d’abord la norme UMTS-2000 [1], puis la norme 3GPP [6], jusqu’à l’évolution vers la 3GPP-LTE [7], la communication par satellite [2] [4], les terminaux portatifs [5] et les liens de données à très haut débit sur fibre optique [3]. Chaque standard spécifie les paramètres de ses codes tels que la longueur des blocs, le rendement du code et le débit de décodage. Par conséquent, la conception des décodeurs multi-standard représente un défi technologique essentiel afin de concevoir des architectures flexibles satisfaisant aux contraintes liées à la consommation en puissance et à la surface des puces. La définition de l’architecture VLSI en virgule fixe de l’algorithme de décodage qui est flexible, utilise le plus faible nombre de bits et possède des très bonnes performances de correction d’erreur. Par la suite, elle est un moyen efficace d’atteindre une meilleure implémentation du décodeur considéré, en tenant compte d’une complexité réduite et d’une faible consommation de puissance. D’autre part, les unités de traitement de signal numérique (DSP) en virgule flottante ou en virgule fixe sont inadéquates pour cet objectif. En plus de leur consommation de puissance importante, ces unités DSP ne répondent qu’aux exigences de débit des normes les plus lentes, et seulement avec des hauts degrés de parallélisme et donc avec une consommation de puissance en hausse. Pour cette raison, nous développons ci-après un modèle précis en virgule fixe pour un décodeur turbo et un décodeur LDPC, et ceci dans un cadre unifié exploitant les analogies communes à ces deux types de codes et leurs algorithmes de décodage associés. Dans la première partie, nous décrivons la problématique de l’optimisation de la largeur des données en virgule fixe. Nous présentons ensuite le principe du turbo décodage par le biais de l’algorithme BCJR (Bahl, Cocke, Jelinek and Raviv) appliqué aux codes convolutionnels. Dans une seconde étape, nous proposerons un modèle en virgule fixe pour le turbo décodeur en détaillant les choix relatifs à la dynamique et à la quantification des opérations au sein du décodeur. Finalement, nous présenterons les performances obtenues par le décodeur LDPC proposé en analysant les courbes de taux d’erreur par paquet ou FER (pour Frame Error Rate). 4.1 L’optimisation de la largeur des données en virgule fixe Le coût et la précision des systèmes implémentés en utilisant l’arithmétique virgule fixe sont fonction des longueurs de mot de code assigné. Étant donné qu’il existe plusieurs possibilités pour sélectionner la largeur d’un mot de code, le choix du format virgule fixe pour chaque signal doit être effectué avec précaution. Pour un algorithme donné, nous définissons w le vecteur constitué par les longueurs de mot de code de chaque entrée dans l’implémentation en virgule fixe. Nous pouvons alors définir l’expression C(w) de la fonction d’évaluation en virgule fixe ainsi que la métrique de précision λ(w) en fonction de ce seul paramètre w. 4.1.1 Variantes du problème Afin d’optimiser le processus de conversion d’un algorithme en arithmétique fixe, il est nécessaire de réaliser un compromis en coût d’implémentation et précision des calculs. Ce compromis peut être établi de manière (i) à obtenir les meilleures performances en imposant une contrainte sur les coûts en consommation (puissance, ressources), ou bien alors de manière (ii) à limiter la complexité d’implémentation pour une contrainte en performance minimale. Par conséquent, le problème d’optimisation de la spécification en virgule fixe d’un algorithme peut être mené suivant deux variantes principales. Nous discutons ci-dessous des principales caractéristiques de ces deux approches.4.1 L’optimisation de la largeur des données en virgule fixe 105 Problème de maximisation de performance Dans ce problème, la contrainte principale concerne le coût d’implémentation. Étant donné le budget du coût maximal Cbudget, l’objectif consiste à maximiser la précision du système λ. Ce problème peut être formulé comme suit : max(λ(w)) sous contrainte C(w) ≤ Cbudget. (4.1) Problème de minimisation du coût Dans ce problème, les performances de l’algorithme spécifié en virgule fixe imposent une contrainte sur le problème d’optimisation. Étant donné le bruit de quantification maximal λobjectif , l’objectif du problème d’optimisation est de minimiser le coût C de son implémentation. Ceci s’écrit formellement par : min(C(w)) sous contrainte λ(w) ≤ λobjectif . (4.2) La sélection entre les deux versions du problème d’optimisation est dictée par les exigences de la conception. Le concepteur peut choisir de résoudre le problème de minimisation de coût s’il a des contraintes sévères de précision en laissant une marge suffisante pour le coût total. Par ailleurs, le choix du concepteur peut être la maximisation de performance s’il y a des contraintes sévères sur le coût d’implémentation tout en faisant le compromis sur la précision des calculs. Dans une situation idéale, le compromis établi en résolvant les problèmes pour diverses contraintes cibles est unique et identique. Ceci correspond à la solution optimale de Pareto [75] d’un système donné. Malheureusement, les solutions à ces problèmes d’optimisation sont souvent obtenues à partir d’algorithmes heuristiques ce qui peut parfois conduire à une solution qui ne corresponde pas l’optimal absolu. 4.1.2 Variable d’optimisation Un système de traitement de signal correspond à des centaines d’opérations en virgule fixe. A titre d’exemple, l’algorithme de FFT à 64 points possède 960 opérations incluant des additions et des multiplications avec des constantes. La partie entière et la partie fractionnaire des formats en virgule fixe sont choisies de façon à fournir un niveau de dynamique et une précision suffisante pour tous les signaux. Il est possible d’avoir des longueurs de données flexibles pour les architectures flexibles comme un FPGA ou les architectures des DSP modernes avec un support SIMD. Afin de résoudre le problème d’optimisation des longueurs des données, chaque choix de la longueur d’un mot de code pour chaque opération en virgule fixe doit être optimal. Soit M le nombre des signaux dans le système. Si chaque signal possède N configurations possibles pour la longueur de son mot de code, il existe NM combinaisons possibles de vecteurs de longueur de mot de code. Ceci exprime le paradigme de l’affectation multiple de longueurs de mot de code pour l’amélioration en virgule fixe. Affecter la même longueur du format pour chaque signal réduit la complexité du problème d’optimisation. Ceci est connu comme le paradigme d’affection uniforme des longueurs de mot de code pour le raffinement virgule fixe. Dans cette approche, toutes les opérations sont effectuées par la même longueur. En d’autres termes, tous les signaux et les opérateurs dans le système possèdent le même format en virgule fixe. Cette approche pour la conception en virgule fixe des systèmes de traitement de signal est utilisée pour l’implémentation des architectures de chemin de données de largeur fixe. Le format en arithmétique virgule fixe est choisi de telle sorte que la partie entière est la partie fractionnaire soient suffisamment larges pour que la contrainte de précision soit vérifiée pour tous les signaux. Si le paradigme uniforme de la longueur de mot de code devait être utilisé, le nombre de combinaisons de longueurs des mots de code qui sont nécessaires avant d’atteindre l’optimalité est N, où N est le nombre de configurations de longueur de mot de code réalisables dans l’architecture donnée.106 Évaluation de la précision du turbo décodage 4.1.3 Solution au problème d’optimisation de la longueur du mot de code Auparavant, le problème de raffinement en virgule fixe était traité en utilisant le paradigme uniforme de longueur de mot de code (ULM). Dans le paradigme ULM, tous les signaux sont assignés à la même longueur de mot de code de virgule fixe et au même format. Par contre, chaque signal est assigné à un format virgule fixe approprié en fonction de sa sensibilité à la sortie du système. Il a été montré que le paradigme de multiple longueurs de mot de code (MLM) donne parfois de meilleurs résultats que les formats virgule fixe obtenus en utilisant le paradigme ULM [42]. Les avantages de la résolution du problème de raffinement de virgule fixe en utilisant le paradigme MLM se fait au prix de la résolution du problème d’optimisation NP-hard. Bien que les solutions de raffinement virgule fixe soient simplement O(N), où N est le choix varié du format de longueur du mot de code si le diagramme ULM est utilisé à la place. Des techniques variées pour résoudre les problèmes d’optimisation de la longueur du mot de code peuvent être catégorisées en approches à base optimale, stochastique et heuristique-rapide [75]. 4.2 Optimisation du turbo décodage Nous présentons dans cette section un modèle en virgule fixe du décodeur turbo afin d’optimiser les formats en virgule fixe des différentes quantités impliquées dans l’algorithme de décodage et ceci dans le but d’améliorer les performances en terme de taux d’erreur par paquet FER. En premier lieu, nous décrivons dans le paragraphe ci-après le principe général du décodage turbo, puis nous présentons le modèle proposé en virgule fixe en se basant sur le fonctionnement de l’algorithme de turbo décodage. Enfin, dans la dernière partie, nous analysons les performances de l’algorithme de turbo décodage en fonction des différents choix possibles des formats de données en virgule fixe. 4.2.1 Présentation de l’algorithme Avant de présenter l’algorithme de décodage turbo, il est fondamental de décrire le principe des codes turbo pour bien expliciter le fonctionnement de l’algorithme de décodage Les codes turbo En se concentrant sur la classe des codes convolutionnels concaténés parallèles PCCC (Parallel Concatenated Convolutional Codes), la figure 4.1 montre le codeur du turbo code pour la norme 3GPP-LTE. Ce dernier est composé de deux codeurs systématiques, récursifs, en parallèle où l’unité supérieure et inférieure sont alimentées par une version directe et une version entrelacée des bits d’information respectivement. L’entrelacement des bits du mot de l’information est effectuée dans le bloc Π de la figure 4.1. Chaque codeur RSC (Recursive Systematic Code) est un registre à décalage à retour linéaire LFSR (Linear-Feedback Shift-Register) particulier dont les bits de sortie ci, i = 0, 1, appelés aussi bits de parité, sont déterminés en fonction de l’état S du registre, des connections en avant et en arrière, mais également de la valeur du bit u présent à l’entrée du codeur.4.2 Optimisation du turbo décodage 107 Figure 4.1 – Turbo codeur de la norme 3GPP-LTE Les performances du turbo code dépendent des paramètres des RSC tels que le nombre d’états, noté v, et le lien de retour. Le nombre d’états v est lié au nombre d’éléments de mémoire dans le RSC qui est lui-même relié à la longueur de contrainte L du code (L = 4 dans l’exemple de la figure 4.1) suivant la relation v = 2L−1. Figure 4.2 – Exemple d’un treillis à 8 états108 Évaluation de la précision du turbo décodage Le processus de codage du RSC peut être effectivement représenté en ayant recours au graphe de treillis représenté par la figure 4.2 pour un codeur 3GPPP-LTE. Il s’agit d’un diagramme montrant l’évolution en temps de l’état LFSR et décrivant les transitions entre les paires des états consécutifs comme indiqué sur la figure 4.2. Chaque branche du treillis reliant deux états consécutifs est labellisée par la paire de symboles d’information présents en entrée des RSC et par les bits de parité produits en sortie du codeur turbo. Ainsi, pour une suite de bits d’information donnée, le processus de codage peut être décrit par un chemin spécifique au sein des différentes branches décrivant le treillis du code. Visant à améliorer les capacités de correction d’erreur, les turbo codes M-aires sont devenus largement utilisés dans les standards de communication récents après leur introduction dans les années 2000 [23]. Dans ce cas, chaque symbole d’information prend ses valeurs dans un ensemble comportant M > 2 valeurs d’amplitude possibles (M = 2 correspond à un code binaire). Chaque symbole peut être exprimé sur m bits, donc M = 2m. Des valeurs importantes de M peuvent être envisagées afin d’améliorer le pouvoir de correction d’erreur du turbo décodeur, mais ces valeurs ne sont pas d’une grande utilisation en pratique en raison de la complexité excessive de l’algorithme de décodage associé. L’algorithme de décodage BCJR (Bahl-Cocke-Jelinek-Raviv) L’algorithme BCJR est un passage obligé pour le turbo décodage puisqu’il est appliqué au décodage des deux composantes de décodage RSC du turbo code [63]. La figure 4.3 résume les notations utilisées par l’algorithme de décodage BCJR d’un code convolutionnel M-aire (M = 2m). Figure 4.3 – Les notations de BCJR dans le treillis La branche orientée e connecte l’état de départ SS(e) à l’état d’arrivé Se(e). u(e) est l’information symbole liée à la branche e, issue de l’ensemble U = {0, 1, ..., M −1}, avec M = 2m. Pour un symbole d’information u(e) présent en entrée du codeur et une mémoire correspondant à l’état Ss, le codeur génère à sa sortie un symbole codé c(e) associé à la branche e dont les éléments sont les bits codés ci(e), i = 0, 1, ..., n − 1 de c(e). Alors, pour m bits d’information codés dans le symbole u, n ≥ m bits codés sont générés et le rapport r = m/n est appelé le rendement du code. Correspondant à une forme particulière du décodage MAP, l’algorithme BCJR vise à la maximisation de la probabilité a posteriori du bit transmis pour une observation donnée du mot de code reçu dans le bruit. Pour une implémentation efficace, l’algorithme est formulé en termes de messages de fiabilités sous la forme des rapports logarithmiques de vraisemblance LLRs (LogLikelihood Ratios). Soit x une variable aléatoire M − aire dont la valeur est dans l’ensemble X = {x0, x1, ..., xM−1}. Son LLR est défini par : LLR(x = xi) = log P(x = xi) P(x = x0) (4.3) avec i = 1, 2, ..., M − 1. x0 est utilisé comme le symbole de référence pour la normalisation, par conséquent seulement M − 1 LLRs sont associés pour une variable aléatoire M − aire. L’algorithme BCJR implique les quantités suivantes dans son fonctionnement de décodage (nous utilisons les mêmes notations que [81]) :4.2 Optimisation du turbo décodage 109 – λch k,i est l’information canal a priori pour le bit codé ci à l’instant k, avec i = 0, 1, ..., n − 1 et k = 0, 1, ..., N −1. λch k,i fréquemment nommé entrée LLR, désigne l’entrée de l’algorithme BCJR. – γk(c(e)) (ou simplement γk(e)) est la métrique cumulative associée au symbole codé c(e) sur la branche e à l’instant k. γk(c(e)) est fréquemment appelée métrique de branche. – λI k(u(e)) (ou simplement λI k(e)) est l’information a priori associée au symbole d’information u(e) sur la branche e à l’instant k. – λO k (u(e)) (ou simplement λO k (e)) est l’information extrinsèque a posteriori associée au symbole d’information u(e) sur la branche e à l’instant k. – AAP P k (u(e)) (ou simplement AAP P k (e)) est la probabilité a posteriori APP associée au symbole d’information u(e) sur la branche e à l’instant k. L’algorithme BCJR commence par calculer les métriques branches γk(e) par la relation suivante : γk(e) = n '−1 i=0 ci(e).λch k,i (4.4) avec k = 0, 1, ...N − 1 est l’index du treillis. La métrique branche γk(e) et l’information extrinsèque a priori λI k(e) conduisent à calculer les récursions forward et backward α" et β " , calculées dans le domaine logarithmique par les relations suivantes : α " k+1(Si) = ∗ max e:SE(e)=Si {α " k(SS(e)) + γk(e) + λI k(e)} (4.5) β " k(Si) = ∗ max e:SS(e)=Si {β " k+1(SE(e)) + γk(e) + λI k(e)} (4.6) avec ∗ max(a, b) est l’opérateur défini par : ∗ max(a, b) = max(a, b) + log(1 + e−|a−b| ). (4.7) Cependant, l’opérateur max∗ peut être approximé par une simple opération max pour les implémentations à faible complexité. Les récursions forward et backward α et β sont évaluées à travers l’ensemble des branches e entrantes et sortantes respectivement d’un état Si à l’instant k + 1 pour la métrique forward α, et à l’instant k pour la métrique backward β. Ces récursions sont initialisées avec α" 0 = αinit et β " N = βinit à l’instant k = 0 et k = N, respectivement. Fermeture du treillis : transformation en code en bloc Tout code convolutif est convertible en un code en bloc. Il suffit de stopper l’avance dans le treillis après un nombre de branches fixé par la longueur du code en blocs recherché. Une méthode triviale consiste à couper le treillis sans spécifier l’état final (troncature). La bonne méthode transforme le code convolutif en un code en bloc en forçant le retour à l’état 0 par une terminaison du treillis. En effet, les valeurs d’initialisation dépendent de la stratégie de terminaison sélectionnée. Ainsi, (i) pour des codes sans terminaison, les valeurs d’initialisation sont [1/v,...,1/v] ; (ii) pour les codes dont la terminaison est zéro, ces valeurs sont égales à [1, 0, ..., 0] et, (iii) pour des codes circulaires, les valeurs d’initialisation des métriques de chemins (forward et backward) correspondent aux valeurs obtenues à l’itération précédente. Les récursions métriques sont sous forme des probabilités logarithmiques. Afin d’augmenter la robustesse de l’algorithme [72][37], elles sont normalisées. La valeur prise comme référence est typiquement celle de l’état S0, ce qui conduit aux récursions normalisées suivantes : αk(Si) = α " k(Si) − α " k(S0) (4.8) βk(Si) = β " k(Si) − β " k(S0). (4.9) Une fois que les récursions forward et backward sont disponibles pour tous les états du treillis, l’estimation a posteriori du symbole d’information u est déduite par :110 Évaluation de la précision du turbo décodage λO k (ui) = ∗ max e:u(e)=ui {αk(SS(e)) +γk(e) +βk+1(SE(e))}− ∗ max e:u(e)=u0 {αk(SS(e)) +γk(e) +βk+1(SE(e))} (4.10) Comme elle n’est pas directement liée au message a priori en entrée λI k(e), la probabilité APP en sortie λO k (ui) est dite extrinsèque. Le principe du turbo décodage L’algorithme de turbo-décodage est obtenu par application directe de l’algorithme BCJR à ces deux composantes RSC selon le diagramme de la figure 4.4 où les deux unités marquées SISO-1 et SISO-2 sont des unités SISO (Soft-in Soft-out). L’algorithme évolue au cours du temps par l’échange itératif des messages extrinsèques qui sont les sorties a posteriori des blocs SISO. L’algorithme est alimenté par les estimations canal a priori λch k,i, sous la forme de LLR et calculées selon l’équation (4.3) pour des symboles binaires (M = 2). La sortie du bloc SISO-1, appelée λext,1 dans la figure 4.4, est entrelacée par l’entrelaceur Π avant d’être transmise au bloc SISO-2 comme une information a priori. Ce dernier bloc reçoit également en parallèle une version entrelacée de l’estimation du canal a priori λch k,i, puis il fournit en sortie un message de fiabilité a posteriori λext,2. Après inversion de l’opération d’entrelacement, cette fiabilité est adressée à l’entrée du bloc SISO-1 en tant qu’estimation a priori raffinée des symboles transmis. Figure 4.4 – Le principe du turbo décodage Comme montré dans la figure 4.4, la sortie du turbo décodeur est donnée par l’estimation a posteriori AAP P k du symbole transmis. Elle est obtenue par la sommation des deux messages extrinsèques (non entrelacées) disponibles en sortie des deux unités SISO. Elle est donnée par : AAP P k (ui) = λext,1 k (ui) + λext,2 k (ui) (4.11) avec ui ∈ U = {u0, u1, ..., uM−1} et k = 0, 1, ..., K − 1.4.2 Optimisation du turbo décodage 111 4.2.2 Modélisation et design en virgule fixe Considérons un système de numération de base B, la représentation en virgule fixe X d’un signal réel x est exprimée par : X = N 'I−1 n=0 anBn + ' NF n=1 bnB−n (4.12) avec NI et NF sont respectivement le nombre d’entier appartenant à l’ensemble D = {0, 1, ..., B− 1} et représentant la partie entière et fractionnaire de x. Le nombre Nx = NI + NF est le nombre total de nombres utilisés pour représenter x en base B. La multiplication de (4.12) par le facteur BNF appelé facteur d’échelle est pratique pour se débarrasser du point décimal et elle est efficace pour une implémentation DSP en virgule fixe. Dans le cas d’un système binaire avec B = 2, X devient un nombre entier sous la forme de : X = N 'x−1 n=0 xn2n (4.13) où xn, n = 0, 1, ..., Nx − 1 sont les chiffres binaires de la représentation entière de x, avec xn = BNF −n pour n = 0, 1, ..., NF − 1 et xn = an−NF pour n = NF , NF + 1, ..., NF + NI − 1. Loi de conversion Figure 4.5 – Fonction en escalier de conversion de la virgule flottante à la virgule fixe Soit un signal x défini dans le domaine des réels, x ∈ R, sa représentation virgule fixe X sur Nx bits est donnée selon une loi bien précise. Comme seulement un nombre limité Nx de bits est disponible, le domaine de x doit être contraint à un intervalle de R, soit [−A, A]. Donc, une saturation préventive du signal dans l’intervalle [−A, A] doit être effectuée et la valeur de A sera interprétée comme une dynamique. L’opération de la conversion en virgule fixe peut être effectuée suivant la transformation suivante : J X = min(2Nx−1, 1 x ∆x + 0.52), x ≥ 0 X = max(2Nx+1, 1 x ∆x − 0.52),x< 0 (4.14)112 Évaluation de la précision du turbo décodage où ∆x = 2A 2N −1 est le pas de quantification, c’est à dire la différence maximale entre deux différentes valeurs flottantes qui sont codées dans le même symbole X en virgule fixe. La valeur de ∆x est une mesure de la résolution de la représentation. En d’autres termes, c’est le poids du bit le moins significatif (Least Significant Bit LSB) x0 de X. Il convient de préciser que (4.14) effectue non seulement la quantification du signal d’entrée, mais elle limite son domaine à l’intervalle [−A, A], comme le montre la figure 4.5. Les valeurs supérieures (inférieures) à A(−A) sont saturées au plus grand niveau positif 2Nx−1 − 1(le plus petit niveau négatif −2Nx−1 − 1). Dans (4.14), seulement 2Nx−1 niveaux de virgule fixe sont utilisés (le co-domaine de la fonction de transformation est symétrique par rapport au niveau 0), ce choix empêche l’algorithme de dériver vers des valeurs négatives comme montré dans [37]. Ainsi, la paire (A, Nx) définit complètement la quantification du signal en virgule flottante x, et fournissant la dynamique et le poids de LSB ∆x utilisé pour sa représentation. Cette approche est similaire a celle décrite dans [37] et [30] pour la quantification des entrées LLRs, et elle est plus flexible que celle généralement adaptée dans la littérature [72][19][78], où le format virgule fixe est spécifié par les paires (NI , NF ), sans tenir compte de la dynamique du signal réel sous-jacent. En d’autres termes, la dynamique du signal réel est souvent mise sous la forme A = 2NI−1 et elle est limitée à une puissance de deux. Par contre, la représentation que nous proposons dans cette thèse dépasse cette restriction. Elle sera appliquée à chaque élaboration interne en virgule fixe du turbo décodeur. Modélisation virgule fixe du turbo décodeur Plusieurs travaux dans la littérature ont traité cette problématique de modélisation en virgule fixe des algorithmes de décodage itératif [72][39][30]. De plus, des indications utiles sont fournies pour l’implémentation pratique du turbo décodeur [19][12] et du décodeur LDPC [88][78]. En outre, les modèles dans [72] et [37] fournissent des bornes pour l’augmentation maximale des signaux impliqués à l’intérieur du décodeur Turbo. L’algorithme de turbo décodage est reformulé dans le domaine de l’arithmétique virgule fixe pour impliquer les opérations avec des entiers. Suivant une approche en cascade, toutes les opérations impliquées dans l’algorithme sont successivement converties en leur représentant en virgule fixe une après l’autre. 1-L’information canal a priori : Les LLRs canal sont quantifiés selon (4.14) en utilisant un seuil Aλch et Nλch bits. 2-La métrique de branche : Le calcul de γk(e) dans (4.4) implique la somme de messages de fiabilités canal a priori λch k,i, i = 0, 1, ..., n − 1. Par conséquent, dans le pire des cas, la somme cohérente γk(e) est donnée par : γk(e) = n.Aλch (4.15) La représentation en virgule fixe Γ de γ doit être représentée avec : Aγ = n.Aλch (4.16) et le nombre de bits de γ est donné par : Nγ = Nλch + 3log2(n)4. (4.17) 3-L’opérateur max∗ : L’opération z = max∗(x, y) implique le calcul du max des deux signaux x et y, et l’addition du terme correctif dans l’intervalle ]0, log2]. Par conséquent, la dynamique de z est majorée par Az. Elle est donnée par la relation suivante : Az = max(Ax, Ay) + log2. (4.18)4.2 Optimisation du turbo décodage 113 Afin de laisser la comparaison possible, les versions en virgule fixe X et Y de x et y respectivement doivent avoir la même résolution, soit donc ∆x = ∆y = ∆. Sous cette hypothèse, le nombre de bits nécessaires pour représenter z peut être déduit de la définition de ∆ comme suit : 2Nz = 2.Az ∆ +1= 2.A ∆ + 2.log2 ∆ + 1 = (2N − 1) + 2.log2 ∆ +1=2N (1 + log2 A ) (4.19) avec A = max(Ax, Ay) et N = max(Nx, Ny). Par conséquent, nous supposons que A > log2 ce qui est généralement le cas, alors l’expression (4.19) donne : Nz = 3log2 % 2N % 1 + log2 A &&4 = N + 1. (4.20) Par contre, les équations (4.19) et (4.20) sont strictement maintenues lorsque x = Ax = y = Ay = A i.e. lorsque la contribution du terme correctif est maximale. En plus de ce cas très défavorable, le bit additionnel exprimé dans (4.20) n’est pas réellement exploité et l’utilisation de Az = max(Ax, Ay) est généralement suffisante. Par conséquent, le résultat de l’opérateur max∗ peut être saturé sur Nz = N bits. Cette approximation conduit à de très faibles pertes d’information et par la suite possède un impact négligeable sur les performances de l’algorithme. Ainsi, l’opération max∗ en virgule fixe devient : Z = max∗(X, Y ) = min{max(X, Y ) + LUT(D), L} (4.21) avec L = 2N−1 −1 est le seuil de saturation. Dans cette dernière expression, le terme correctif est quantifié en utilisant la même résolution ∆ que les entrées x et y et il est enregistré dans une table de recherche LUT (look-up table) adressée par D = |X − Y |. 4-L’information extrinsèque a posteriori Puisque les messages de fiabilités extrinsèques a posteriori et les récursions forward/backward sont mutuellement dépendants à travers le principe turbo itératif, leur représentation en virgule fixe peut être étudiée sous l’hypothèse que les récursions métriques d’état soient représentées sur Nα = Nβ = Nγ + h bits, où h est un entier. D’après l’équation (4.10), la dynamique de λO est majorée par : AλO = (Aα + Aβ + Aγ) − (−Aα − Aβ − Aγ)=2.(2Aα + Aγ)=2Aγ.(1 + 2h+1) (4.22) avec Aα = 2hAγ et Aα = Aβ. Nous pouvons alors exprimer la représentation de la précision de λO à partir de la relation NλO = 3log2(2AλO /∆λO + 1)4 bits, ce qui donne : NλO =1+ Nγ + 3log2(1 + 2h+1)4 =1+ Nγ + 3max∗ 2(0, h + 1)4 (4.23) avec la fonction max∗ 2 correspondant à l’opérateur max∗ en base deux, et défini par : max∗ 2(a, b) = max∗(a, b) + log2(1 + 2−|a−b| ). (4.24) Deux cas peuvent être distingués : a) h ≥ 0 : Il est facile de prouver que 3max∗ 2(0, h + 1)4 = h + 2, par conséquent, NλO = Nγ + h +3= Nα + 3. b) h < 0 : 3max∗ 2(0, h + 1)4 = 1, NλO = Nγ +2= Nα + 2 − h. Dans les deux cas, NλO est une fonction connue de Nα et h.114 Évaluation de la précision du turbo décodage 5-Les récursions métriques d’état A cause de leur calcul itératif, l’amplitude des récursions forward/backward continue à augmenter tout au long du treillis si les récursions ne sont pas contrôlées par des moyens de saturations. Sous les mêmes hypothèses (Nα = Nγ + h), l’augmentation des métriques d’état après une étape de mise à jour est majorée par : 2(Aα + Aγ + AλI )=2Aα(2 + 2−h + AλI /Aα) (4.25) où l’information a priori λI est en effet la sortie a posteriori du bloc SISO précédent et donc AλI = AλO . En remplaçant (4.22) dans (4.25), cette dernière devient : 2Aα(1 + 2−h + 2.h−1.21−h) = 2(5 + 2−h + 21−h)Aα. (4.26) Nous pouvons donc conclure que la dynamique de α augmente d’un facteur de 2(5 + 3.2−h) après chaque itération du turbo décodeur ce qui se traduit par l’ajout de 1 + 3log2(5 + 3.2−h)4 bits. De même que précédemment, deux cas de figure peuvent se présenter : – h ≥ 0 : le terme 2(5 + 3.2−h) est borné par 5 et 8, ce qui engendre l’addition de 4 bits à chaque itération. – h < 0 : le terme 3log2(5 + 3.2−h)4 est évalué à 2 − h et, au total, 3 − h éléments binaires sont ajoutés à chaque étape. Par conséquent, la saturation de 4 ou 3 − h bits respectivement, empêche l’augmentation incontrôlée des métriques d’état représentées par (Aα, Nα). Dans [72] et [37], des bornes sont données pour la dynamique des récursions métriques d’état, et sont utilisées pour dimensionner la pré- cision interne du bloc SISO. Par contre, dans l’approche que nous proposons, la résolution des métriques d’état est une entrée libre du modèle et elle est contrôlée par des moyens de saturation. 4.2.3 Réduction de la taille de mémoire Le schéma complet du décodeur SISO est représenté à la figure 4.6. Une implémentation pratique d’un décodeur turbo code est basée sur l’utilisation étendue de mémoire comme un moyen pour échanger les messages extrinsèques et stocker les résultats intermédiaires qui correspondent aux métriques cumulées de chemin. Par conséquent, il est clair que la complexité totale du décodeur est fortement dominée par les mémoires. Les techniques comme la troncature du bit de poids le plus faible LSB et la saturation du bit de poids le plus fort MSB sont très efficaces pour limiter la taille des données enregistrées dans la mémoire. Par contre, l’utilisation de la saturation est préférable puisqu’elle réduit non seulement la taille de la mémoire, mais aussi les unités des chemins de données pour accéder à la mémoire. D’autre part, les données ayant subi des troncatures avant l’enregistrement, dans la mémoire, doivent être décalées à gauche après récupération de la mémoire pour restaurer la résolution originale car le poids du LSB ∆ et les chemins de données ne bénéficient d’aucune réduction dans la taille. Pour un signal x, les notation Tx et Sx désignent, respectivement, le nombre de LSB tronqués et MSB saturés avant le stockage dans la mémoire. Pour le turbo décodeur, la troncature et la saturation sont effectuées à chaque itération sur les métriques cumulées de chemins enregistrées dans la mémoire α/β-MEM (Tα et Tβ respectivement) et sur l’information extrinsèque a posteriori stockée dans la mémoire A-MEM (TA et SA respectivement) comme indiqué sur la figure 4.6.4.2 Optimisation du turbo décodage 115 Figure 4.6 – Modèle virgule fixe du bloc SISO dans le turbo décodeur Figure 4.7 – Analyse de la dynamique pour Nλch = 5 bits116 Évaluation de la précision du turbo décodage 4.2.4 Performance du turbo décodeur Les performances de correction d’erreur et les pertes liées à l’implémentation du modèle virgule fixe développé dans la section précédente sont analysées par des simulations. Un système de communication complet formé du codeur, du modulateur, du canal de transmission introduisant un bruit additif blanc gaussien AWGN, du démodulateur et du décodeur décrit précédemment a été developpé en langage C avec une implémentation du modèle paramétrique en virgule fixe. Nous avons considéré un turbo décodeur satisfaisant à la norme 3GPP-LTE dont les paramètres sont décrits dans le tableau 4.1. Les performances en virgule fixe sont mesurées sous forme des courbes de taux d’erreur par paquet FER en fonction du rapport signal à bruit Eb/N0 (SNR). La norme Taille m Longueur K Taux R Nombre d’itération Nit 3GPP-LTE 1 1504 1/3 10 Table 4.1 – Les paramètres du code Le premier point critique de la conception en virgule fixe concerne l’identification d’une valeur optimale de la dynamique de l’entrée LLR Aλch . La figure 4.7 représente les performances FER pour différentes valeurs de Aλch . Les entrées LLRs λch sont codées sur Nλch = 5 bits tandis que les métriques de chemins forward et backward sont représentées sur un nombre de bits suffi- samment important (Nα = 6) afin que les pertes d’implémentation ne soient causées que par la quantification des entrées λch. Figure 4.8 – Effet de la quantification des entrées LLRs L’impact de la quantification des entrées LLRs est analysé par la figure 4.8 où la FER est tracée en fonction de la dynamique Aλch pour trois différentes valeurs de Nλch 4, 5 et 6 bits. Les trois courbes sont obtenues pour un Eb/N0 = 1.2dB, avec une simulation en virgule flottante4.2 Optimisation du turbo décodage 117 comme référence. D’après cette figure, la valeur Aλch = 10 semble être la meilleure pour un nombre de bits de 4 et 5. Tandis que Aλch = 12 est le meilleur choix pour 6 bits. D’après la figure 4.7, nous constatons que, plus que la valeur de Aλch est petite, plus les pertes dues à l’implémentation sont faibles. Le cas où Aλch = 10 correspond à une détérioration majorée par 0.1dB par rapport au modèle de référence en virgule flottante, tandis que l’augmentation de la dynamique conduit à une résolution ∆λch très grossière, ce qui engendre des pertes considérables particulièrement pour les faibles SNR. Si l’on s’intéresse maintenant aux performances obtenues pour une faible dynamique, i.e. pour Aλch = 5, ce paramétrage correspond à une quantification grossière des entrées canal LLRs car de nombreux échantillons en virgule flottante vont être saturés à la valeur ±Aλch . Ces saturations entraînent une perte de signifiance dans les variables internes de l’algorithme de décodage turbo (bloc SISO-1 et SISO-2), soit donc une augmentation du bruit de quantification ce qui se traduit par un aplatissement des courbes de taux d’erreur. Par conséquent, nous sélectionnons la valeur Aλch = 10 pour la suite de l’analyse. Il convient de préciser par ailleurs qu’une telle analyse de l’influence de la représentation en virgule fixe d’un turbo décodeur constitue un travail original car ce type d’analyse n’est pas présent dans la littérature scientifique. En effet, les travaux disponibles dans la littérature sont limités par des schémas "classiques" de quantification qui conduisent à un pas très grossier lorsque la dynamique Aλch est contrainte à une puissance de deux. La figure 4.9 représente les performances FER pour différentes valeurs des paramètres en virgule fixe définies dans la section de modélisation en virgule fixe du décodeur et exprimées par le triplet (Nλch , Nα, NA). Figure 4.9 – Analyse de la performance de l’algorithme de turbo-décodage en virgule fixe D’après la figure 4.9, il est clair qu’aucune perte n’est observée en saturant 3 bits sur les118 Évaluation de la précision du turbo décodage Signal Configuration A Configuration B LLR Canal a priori (10,5) (10,5) Métriques de branches (RCS r = 1/2) (20,6) (20,6) Métriques de chemin (40,7) (20,6) Les bits saturés pour α/β (Sα) 2 2 Les messages extrinsèques a posteriori (40,7) (20,6) Nombre de bits saturés sur les messages extrinsèques (SA) 3 3 Table 4.2 – Les paramètres virgule fixe optimaux du turbo-décodeur fiabilités extrinsèques (SA = 3) lorsque Nα = 3, tandis que la saturation de seulement 1 bit sur les récursions métriques (Sα = 1, Nα = 6) conduit à une perte de l’ordre de 0.18dB pour les forts SNR. La troncature d’un bit des itérations métriques (Tα = 1) et les fiabilités extrinsèques (TA = 1) dégrade légèrement les performances FER pour les faibles SNR où les LSBs portent la plupart de l’information, ce qui n’est pas surprenant, tandis que les pertes deviennent presque négligeables pour les forts SNR. Finalement, visant à une solution à très faible complexité, les itérations et les métriques extrinsèques peuvent être représentées sur Nα = NA = 6 bits avec une perte d’implémentation de 0.3 dB pour les forts SNR. Figure 4.10 – Performance virgule fixe de bout en bout pour différentes valeurs de Aλch Le tableau 4.2 résume les paramètres de la spécification en figure fixe obtenue dans deux configurations. La première configuration, qui sera par la suite nommée configuration A, est orientée pour obtenir les meilleures performances, tandis que la deuxième configuration , qui sera par la suite nommée configuration B, est dédiée pour une faible complexité. La configuration B est plus impliquée pour analyser l’effet conjoint de la dynamique des entrées et la quantification grossière de l’algorithme sur la performance totale de correction d’erreur. La4.3 Optimisation du décodage LDPC 119 figure 4.10 montre que les courbes de FER s’aplatissent pour Aλch = 5 et Aλch = 8. Ceci est dû à la distorsion importante introduite par une très forte saturation des entrées a priori du canal, mais également au bruit de quantification généré en propre par l’algorithme (blocs SISO-1 et SISO-2). La valeur Aλch = 10 conduit à une perte minimale de performances par rapport à la courbe de référence obtenue avec l’arithmétique à virgule flottante, mais en contrepartie il apparaît une saturation des performances pour de forts SNRs (aplatissement de la courbe FER = f(Eb/N0)). A contrario, l’utilisation de A = 12 empêche ce phénomène d’aplatissement, mais ceci est obtenu au prix d’une perte en SNR de l’ordre de 0.25dB par rapport à la courbe de référence (i.e. virgule flottante). 4.3 Optimisation du décodage LDPC Dans cette section, nous présentons un modèle en virgule fixe du décodeur LDPC pour aboutir à une analyse des performances FER en virgule fixe. Nous commençons par présenter le principe du décodage LDPC. Ensuite, nous présentons le modèle en virgule fixe des différentes opérations impliquées dans l’algorithme de décodage, puis nous analysons les performances de l’approche proposée en fonction du niveau de bruit introduit par le canal de transmission et des différents paramétrages possibles pour la représentation en virgule fixe de l’algorithme. Avant de présenter l’algorithme de décodage LDPC, nous présentons tout d’abord le principe général des codes LDPC pour bien expliciter ensuite le principe de leur décodage. Figure 4.11 – Exemple du graphe tanneur Les codes LDPC Les codes LDPC sont des codes linéaires définis par une matrice creuse H appelée matrice de contrôle de parité. On dit qu’un mot de code x est valide s’il appartient à l’espace nul ou au noyau de H défini par l’ensemble H (HxT = 0). La matrice H = {hij} de contrôle de parité possède un nombre de colonnes N égal au nombre de bits dans le mot code transmis et un nombre de lignes M correspondant au nombre de contraintes de contrôle de parité. La différence P = N − M désigne le nombre de bits de parité ajoutés par le codeur LDPC. Chaque ligne de la matrice décrit une contrainte de contrôle de parité. Lorsque le jeme bit du mot de code participe au i ème contrôle de parité, alors le terme hi,j de la matrice H est fixé à l’unité. Dans le contraire, il est nul. Les codes LDPC peuvent être également décrits en utilisant un graphe appelé graphe de Tanner [89] qui est composé de nœuds de variables (VNs), représentés avec des cercles et de nœuds de contrôle (CNs) représentés par des carrés. Chaque VN représente un bit du mot code transmis et correspond à une colonne de H. Une connexion entre le i ème nœud variable VN et le jème nœud de contrôle CN, dénommée branche, correspond à un terme hij = 1 dans la matrice120 Évaluation de la précision du turbo décodage H de contrôle de parité et relie graphiquement la contrainte de parité à un bit du mot code. Le nombre des branches connectées à un VN (CN) est appelé le degré de nœud de variable, dv (degré de nœuds de contrôle, dc). Un exemple de graphe de Tanner est présenté par la figure 4.11. Figure 4.12 – Matrice prototype du LDPC WIMAX 2/3a La conception de la matrice de contrôle de parité affecte la performance de correction d’erreur et la complexité du décodeur LDPC [38][67]. L’idée de base consiste à arranger les ’1’ dans la matrice de contrôle de parité selon des configurations qui facilitent la mise en parallèle des opérations de décodage. Ainsi, la matrice de contrôle de parité est partitionnée en matrices carrées plus petites, qui peuvent être des permutations ou des changements cycliques de la matrice unité, encore appelée matrice circulante [95]. La figure 4.12 montre la matrice prototype du code LDPC WiMAX 2/3a avec une longueur 2304 : elle est partitionnée en sous-matrices de taille Z ×Z avec Z = 96, où une entrée nulle correspond à toutes les matrices 0, et une entrée non nulle spécifie la rotation appliquée à la matrice unité. Décodage des codes LDPC L’algorithme de décodage des codes LDPC est communément nommé algorithme de "propagation de la croyance" ou BP (pour Belief Propagation) ou plus généralement l’algorithme de passage de messages [79]. Cet algorithme est optimal si le code ne contient pas de cycles mais il peut cependant être considéré en pratique comme une référence pour des codes comportant des cycles. Dans ce cas, la séquence des élaborations, nommée ordonnancement (schedule), affecte considérablement la performance en termes de vitesse de convergence et de taux de correction d’erreur. L’ordonnancement le plus simple est l’ordonnancement à deux phases FS (flooding Schedule) [41] qui se déroule en deux phases consécutives où tous les nœuds de contrôle de parité et tous les nœuds de variables sont mis à jour dans un ordre pré-déterminé. Un ordonnancement plus intéressant mais aussi plus efficace concerne l’ordonnancement à couche (ou LS pour Layered Schedule) [67][41]. Comparé à la variante à deux phases (FS), l’ordonnancement de type LS double pratiquement la vitesse de convergence de décodage pour des codes comportant des cycles ou n’en comportant pas [58]. Ceci est atteint en regardant le code comme la connexion de couches, "layers" [49] qui échangent des messages de fiabilité. Spécifiquement, des messages a posteriori sont disponibles pour la couche suivante immédiatement après le calcul, et non pas à l’itération suivante comme dans la phase FS. Les couches peuvent être des ensembles de nœuds de contrôles (CN) ou de nœuds de variables (VN) consécutifs et, par4.3 Optimisation du décodage LDPC 121 conséquent, l’algorithme basé sur CN (ou horizontal) ou l’algorithme basé sur VN (ou verticale) ont été définis dans [41]. Décodage horizontal des couches HLD (Horizontal Layered Decoding) L’algorithme HLD met à jour les contraintes de contrôle de parité séquentiellement autour de la matrice de contrôle de parité. La principale caractéristique de cet algorithme est la mise à jour continue, lors du décodage, d’une métrique cumulative yn associée à chaque nœud de variable (VN) dans le code, n = 0, 1, ..., N − 1, et nommée sortie souple (ou SO pour Soft Output). La mise à jour des informations disponibles au nœud de contrôle numéro m (qui sera noté CNm dans la suite) , avec m = 0, 1, ..., M − 1, est basée sur la disponibilité de messages vtoc (pour Variable-To-Check), notés µn,m, dirigés du nœud variable (VN) numéro n (qui sera noté par suite VNn) vers le nœud CNm, et mis à jour selon : µ(q) m,n = y(q) n − $ (q) n,m (4.27) où $ (q) n,m désigne le message ctov (pour check-to-variable) propagé du nœud CNm vers le nœud VNn au cours de l’itération précédente. Dans l’équation (4.27), l’indice n appartient à l’ensemble Nm constitué des indices des nœuds VNs connectés au noeud CNm, et l’indice q = 0, 1, ..., Nit,max − 1 désigne l’indice de l’itération. Les messages raffinés ctov $ (q+1) n,m sont produits comme résultat de la mise à jour des nœuds de contrôle (check node). Et en se basant sur ceci, l’ensemble des sorties souples SOs impliqués dans le nœud de contrôle CN m, c’est à dire yn avec n ∈ Nm, est mis à jour par la relation suivante : y(q+1) n = µ(q) m,n + $ (q+1) m,n = y(q) n − $ (q) n,m + $ (q+1) m,n . (4.28) Grâce au mécanisme décrit par les relations (4.27) et (4.28), les opérations de contrôle des nœuds comptent sur les mises à jour des sorties souples SOs. L’algorithme HLD est initialisé à l’itération q = 0 avec : J y (0) n = λch n $ (0) m,n = 0 (4.29) avec λch n est la LLR de l’estimation du canal a priori des bits reçus dans le bruit, m = 0, 1, ..., M−1 et n ∈ Nm. Mise à jour des nœuds de contrôle : Concernant la mise à jour de contrôle de nœud, il a été montré dans [67] que la contrainte de contrôle de parité peut être vue comme un code convolutif à deux états, où un état (S0) est associé à la parité paire, et l’autre état (S1) à la parité impaire. La taille du bloc du code équivalent est égale au degré dc des nœuds de contrôle (CN). Un exemple de représentation en treillis est donné par la figure 4.13. Figure 4.13 – Représentation du treillis à deux états d’une contrainte de vérification de parité avec dc = 5122 Évaluation de la précision du turbo décodage Cette analogie permet à l’algorithme BCJR d’être également utilisé pour la mise à jour du contrôle de parité des codes LDPC, et l’algorithme de décodage résultant est dénommé TDMP (pour Turbo-Decoding Message Passing) [67]. L’algorithme est alimenté avec des messages vtoc comme information a priori et produit des messages ctov comme sorties a posteriori, sans mé- trique branche du canal. Donc, dans la mise à jour du nœud de contrôle CN m, les métriques cumulées de chemin sont simplifiées selon : J αk+1 = max∗(αk, µ(q) m,n) − max∗(αk + µ(q) m,n, 0) βk = max∗(βk+1, µ(q) m,n) − max∗(βk+1 + µ(q) m,n, 0) (4.30) où le paramètre k = 1, 2, ..., dc(m) − 1 désigne l’indice temporel au sein du treillis, avec dc(m) le degré du nœud de contrôle CNm, et n = Nm(k) l’indice du nœud de variable VN impliqué à l’étape k. Les relations de mise à jour données par (4.30) sont initialisées avec α0 = 1 et βdc = 1. Par la suite, le calcul des informations extrinsèques a posteriori peut être reformulé de la manière suivante : $ (q+1) m,n = max∗(αk, βk+1) − max∗(αk + βk+1, 0) (4.31) avec k = 0, 1, ..., dc(m) − 1 et n = Nm(k). 4.3.1 Modélisation et design en virgule fixe d’un décodeur LDPC Comme dans le cas du turbo décodeur, la modélisation en virgule fixe est fondée sur une approche en cascade où les opérations impliquées dans l’algorithme de décodage sont quantifiées les unes après les autres. Nous pouvons donc appliquer le modèle préalablement décrit que nous proposons dans le cadre de cette thèse. Il permet d’analyser indépendamment l’effet sur les performances (a) des entrées LLR a priori, (b) des messages ctov, et (c) des métriques cumulées de chemins au sein des relations de mise à jour des nœuds de contrôle. 1-Calcul des messages vtoc : Le calcul des messages vtoc µ selon (4.27) implique les sorties souples SOs et les messages ctov. Considérons que les entrées LLR sont quantifiées avec (Aλ, Nλ) et les messages ctov sont quantifiés avec (A%, N%) et soient ∆λ et ∆% leur résolution, respectivement. Soit le rapport ρ = ∆λ/∆% contraint à être une puissance de deux. Cette supposition réduit le nombre des variables indépendantes dans le modèle : seulement trois variables sont indépendantes parmi les quatre variables Aλ,Nλ,A% et N% indépendantes. C’est aussi la seule solution viable pour une implémentation optimisée de l’algorithme. Figure 4.14 – Modèle virgule fixe du décodeur BCJR à 2-états4.3 Optimisation du décodage LDPC 123 Si le rapport ρ est supérieur à 1, i.e. lorsqu’une résolution plus fine est utilisée pour les messages ctov, les rapports de vraisemblance canal (LLRs) a priori doivent être décalées à gauche de σλ = log2(ρ) bits à apporter sur la même résolution des messages ctov, ces derniers n’étant pas décalés (σ% = 0). Dans l’autre cas, aucun décalage n’est nécessaire sur les entrées LLRs (σ% = 0), tandis que les messages ctov doivent être décalés de σ% = −log2(ρ) bits. Figure 4.15 – Modèle virgule fixe du décodage à couche des codes LDPC Les rapports de vraisemblance canal (LLRs) a priori sont utilisés pour initialiser les entrées souples (SO) et donc ces deux quantités possèderont la même résolution ∆y = ∆λ. Par conséquent, la relation entre la résolution (∆%) des messages ctov et celle ( ∆y) des entrées souples (SO) sera identique à celle existant entre ∆% et ∆λ, c’est à dire entre la résolution des messages ctov et celle des entrées LLR. Sous ces considérations, les entrées souples (SOs) sont initialisées avec une version réduite des entrées LLRs de telle sorte que les données enregistrées ou récupérées du bloc mémoire du SO/λ utilisent la même résolution des messages ctov comme illustré dans la figure 4.15 . Ainsi, pour calculer les messages vtoc en virgule fixe, il est possible dans ces conditions de réaliser directement la soustraction Y − E et car les résolutions des deux opérandes sont identiques. Une fois les messages vtoc disponibles, il sont saturés de deux façons en parallèle : (a) une saturation sur Nµ bits pour l’entrée de l’unité de mise à jour des nœuds de contrôle (CN), et (b) une saturation sur Nv bits pour la mise à jour de la sortie souple (SO) dans la relation (4.28). 2- La mise à jour des SOs : La somme dans (4.28) est effectuée entre les messages ctov mis à jour E et les messages vtoc M" saturés sur Nv bits. Sa sortie est saturée sur Ny bits. Comme la sortie souple (SO) est toujours égale à la somme de dv des messages ctov entrant à un nœud de variable (VN) donné, Ny est donné par : Ny = N% + 3log2(dv,max)4 (4.32) où dv,max représente le degré maximal du nœud de variable (VN) dans le code. Par contre, on parle d’une solution à faible complexité lorsque les SOs sont saturées sur un nombre de bits inférieur à Ny donné par (4.32). 3-Les récursions métrique d’état : L’expression (4.30) combine les messages vtoc avec les métriques de chemins (forward et backward), et de la même manière pour le calcul des messages vtoc. Différentes résolutions pour les deux signaux peuvent être considérées. De même que précédemment, nous contraignons le rapport ρ = ∆λ/∆% à être égal à une puissance entière de deux. Ce facteur est utilisé pour aligner les représentations en virgule fixe M et A des variables µ et α représentant les métriques de chemins. Par conséquent, les repré- sentations en virgule fixe M et A sont décalées respectivement de σµ = log2(ρ) et σα = −log2(ρ) lorsque le paramètre ρ est supérieur à l’unité. Dans le cas contraire, ces représentations ne sont124 Évaluation de la précision du turbo décodage pas modifiées. Ainsi, la somme α + µ dans (4.30) devient en représentation en virgule fixe : A.2σα + M.2σµ (4.33) comme représenté sur la figure 4.14. Les autres opérations de l’algorithme peuvent être représentées au format virgule fixe en utilisant la méthodologie qui a précédemment été décrite dans la section dédiée au turbo décodage. Seules quelques modifications peuvent être apportées afin de simplifier la mise en œuvre. Ainsi, comme indiqué sur la figure 4.14, en définissant le paramètre B = max{Nα + σα, Nµ + σµ}, à chaque itération nous pouvons représenter la nouvelle valeur de A en virgule fixe sur B + 1 bits. Cette valeur est tout d’abord décalée à droite de sa bits puis saturée sur le nombre désiré de Nα bits. 4-Les messages APP ctov : Comme montré dans la figure 4.14, les messages ctov sont calculés avec les métriques cumulées de chemin récursions disponibles au sein de la mémoire. Ces métriques sont représentées sur Mα bits ce qui implique que la mise à jour des messages raffinés ctov donnée par la relation (4.31) peut être représentée en virgule fixe sur Mα + 2 éléments binaires. Une fois que l’information a posteriori est mise à jour, une opération de décalage (à gauche pour σα et à droite pour σ%) est réalisée afin de revenir à une résolution correspondant à celle des messages ctov. La saturation finale restaure la représentation sur N% bits. 4.3.2 Réduction de la taille de mémoire Comme dans le cas du turbo décodeur, l’implémentation est fondée sur l’utilisation étendue de mémoire pour accumuler l’estimation en sortie et stocker les résultats intermédiaires correspondant à la mise à jour des métriques cumulées de chemin et des messages ctov. Dans le cas du décodeur LDPC, la troncature est effectuée sur les messages ctov (T% bits), sur les SOs (Ty bits) et sur les métriques cumulées de chemin forward et backward (Tα bits). Comme indiqué sur la figure 4.14, ces signaux sont décalés (à gauche) juste après récupération de la mémoire, puis les saturations sont effectuées sur les messages ctov (saturés sur M% bits) et les récursions de métriques de chemins α/β (saturées sur Mα bits), tandis que les sorties souples SOs ne nécessitent pas de saturation après leur calcul. 4.3.3 Performance en virgule fixe du décodeur LDPC Nous présentons dans ce paragraphe, les résultats obtenus avec la méthode de représentation en virgule fixe exposée précédemment pour un algorithme de décodage LDPC. Pour ces expérimentations, le code LDPC utilisé correspond à une version proche de celui utilisé par la norme WIMAX dont les paramètres principaux sont : un rendement de codage R = 2/3, N = 1056, un degré maximal dv,max = 6 pour les nœuds de variable VN, et un degré maximal dc,max = 11 pour les nœuds de contrôle CN . L’effet de la quantification des entrées LLR est analysé sur la figure 4.16 où le taux d’erreur par paquet (FER) est représenté en fonction de la dynamique Aλ pour trois différentes valeurs de Nλ soit 4, 5 et 6 bits. Les quatre courbes représentées sur cette figure ont été obtenues pour un rapport signal à bruit Eb/N0 = 3.25dB à l’entrée du récepteur. La courbe correspondant à la représentation en virgule flottante sera prise comme référence. Nous pouvons constater que, pour des valeurs de Nλ de 4 ou 5 bits, les meilleures performances sont alors obtenues pour une dynamique Aλ de 10 bits. Par contre, lorsque Nλ est égal à 6 bits, la valeur optimale de la dynamique de Aλ est de 12 bits. Dans la suite, nous sélectionnons une précision des entrées LLR correspondant au réglage suivant (Aλ, Nλ) = (10, 5) ce qui conduit à un bon compromis performances/complexité. Une analyse similaire a été menée pour la représentation en virgule fixe des métriques cumulées de chemins dans le processeur CN. Les résultats correspondants sont présentés sur la figure 4.17.4.3 Optimisation du décodage LDPC 125 Figure 4.16 – Effet de la quantification des entrées LLRs Figure 4.17 – Effet de la quantification des métriques cumulées de chemin dans le processeur CN Dans ce cas, les courbes de performances (FER) sont évaluées en fonction de Eb/N0, i.e. le rapport signal à bruit présent en entrée du filtre de réception. Afin d’éviter les pertes dues à la quantification des messages ctov et des sorties souples (SOs), une quantification très fine est utilisée pour ces deux signaux en se basant sur un nombre suffisant de bits et une dynamique126 Évaluation de la précision du turbo décodage large. En particulier, la précision (160,12) est utilisée pour les messages ctov tandis que 3 bits additionnels (dv,max = 6) sont alloués pour les sorties souples SOs et Ny = 15. De même, pour les messages vtoc nous avons choisi de travailler avec une dynamique de Nµ = 15 bits. Le reste de l’algorithme est exécuté en précision quasi-virgule flottante. Nous pouvons constater qu’il est suffisant d’utiliser environ 7 ou 8 bits afin d’éviter le phénomène de FER résiduel (i.e. aplatissement des courbes FER) et Nα = 6 fournit de bonnes performances. 4.4 Conclusion Nous avons abordé dans ce chapitre la problématique de l’optimisation des largeurs de données impliquées dans les algorithmes de système de traitement de signal ainsi que les opérations effectuées dans ces algorithmes. Nous avons commencé par proposer une modélisation en virgule fixe du turbo décodeur en se basant sur le principe de fonctionnement de l’opération de décodage. Cette modélisation est fondée sur la quantification en cascade des différentes opé- rations récursives dans l’algorithme de décodage. Une analyse des performances du modèle en virgule fixe est présentée sous forme de courbes de taux d’erreur par paquet FER en fonction du SNR. De plus, cette modélisation nous permet de faire une exploration totale du compromis performance/complexité de l’architecture. La même stratégie a été effectuée pour modéliser en virgule fixe le décodeur LDPC en analysant les performances des choix en virgule fixe par le biais des courbes FER en fonction des paramètres virgule fixe choisis en visant des solutions à faible complexité d’implémentation avec le minimum de pertes de performance.Conclusion et Perspectives L’utilisation de l’arithmétique en virgule fixe [14] pour implémenter les algorithmes de traitement numérique de signal afin de pouvoir satisfaire aux contraintes de coût, de performance et de consommation d’énergie. La réduction du temps de mise sur le marché de ces applications nécessite l’utilisation d’outils de haut niveau de conversion automatique de l’arithmétique virgule flottante vers l’arithmétique virgule fixe. Cette conversion vise à minimiser les coûts de l’implémentation en termes de surface d’architecture, de consommation d’énergie et du temps d’exécution du code sous une contrainte de la précision des calculs pour garantir l’intégrité de l’application. Par conséquent, l’évaluation de la précision en arithmétique virgule fixe est une étape importante et nécessaire pour accomplir la conversion automatique en virgule fixe au sein de ces outils et aboutir à optimiser la largeurs de données en format virgule fixe. Ainsi, à chaque itération du processus d’optimisation, la précision est évaluée à travers des métriques. Cette évaluation peut se faire par des simulations en format virgule fixe qui conduisent à des temps d’évaluation prohibitifs ou bien en proposant des modèles analytiques permettant de réduire d’une façon très significative les temps d’évaluation. L’objectif de cette thèse est de proposer des modèles analytiques pour évaluer la précision des systèmes de communication numérique et de traitement numérique de signal formés d’opérateurs non lisses et non linéaires en terme du bruit. Le travail de recherche effectué au cours de cette thèse est fondé sur trois parties différentes. Dans un premier temps, nous avons défini des modèles analytiques d’évaluation de la précision pour les opérateurs de décision et la cascade d’opérateurs de décision. Cette étude a porté sur la caractérisation de la propagation des erreurs de décision dues à la quantification des données au sein d’une cascade d’opérateurs non lisses. Nous avons ainsi proposé un modèle analytique permettant d’estimer la probabilité d’erreur de décision au niveau de chaque élément de la cascade. Cette approche peut être appliquée à tout type de système constitué de cascade d’opérateurs décision. A titre d’exemple, nous avons appliqué l’approche proposée à l’évaluation des performances de l’algorithme de décodage sphérique SSFE en arithmétique virgule fixe. Nous avons ainsi montré que le modèle analytique permet d’estimer les probabilités d’erreur de décision pour chaque opérateur de décision impliqué dans la cascade de cette application. La deuxième partie concerne l’évaluation de la précision des systèmes itératifs d’opérateurs non lisses de décision, en particulier, les algorithmes d’égalisation à retour de décision. Nous avons tout d’abord caractérisé le phénomène de propagation des erreurs de décision au sein de ces systèmes. Deux modèles analytiques ont été proposés afin d’évaluer la probabilité d’erreur de décision de telles structures récursives La première approche basée sur la résolution d’un système non linéaire par le biais de la méthode de Newton-Raphson donne une estimation fiable de la probabilité d’erreur de décision due à la quantification en format virgule fixe. La seconde approche fournit une borne supérieure de la probabilité d’erreur de décision avec un temps d’évaluation largement réduit par rapport à la première approche. Cette dernière a été appliquée pour estimer la précision d’un égaliseur à retour de décision DFE. Une solution a été proposée pour étendre cette approche pour l’évaluation du DFE dans sa version adaptative. La dernière étape de ce travail a été consacrée à l’optimisation de la largeur des données impliquées dans l’algorithme DFE pour réaliser une implémentation efficace sur FPGA en termes de consommation de ressources et de puissance sous une contrainte de précision exprimée en fonction de la probabilité d’erreur de décision. La dernière partie de cette thèse s’articule autour de la modélisation en arithmétique virgule 127128 Perspectives fixe des algorithmes de décodage itératif de type turbo-décodage et décodage LDPC. Cette étude a conduit à la proposition de deux modèles en virgule fixe pour le turbo-décodeur et décodeur LDPC en quantifiant les différentes opérations et récursions impliquées dans le fonctionnement des algorithmes de décodage. La loi de quantification utilisée se base sur une représentation différente du schéma classique utilisant le nombre de bits pour la partie entière et le nombre de bits pour la partie fractionnaire. La représentation proposée accorde davantage de flexibilité pour la dynamique des signaux qui peut prendre des valeurs différentes d’une puissance de deux. Nous avons ainsi proposé plusieurs paramétrages réalisant différents compromis entre performances de l’application en arithmétique virgule fixe (taux d’erreur par paquet ou FER) et complexité de l’architecture. Des techniques de saturation et de troncature ont été proposées pour réduire la taille des mémoires afin de viser à des solutions à faible complexité. Des simulations de bout en bout ont permis de valider l’approche proposée en quantifiant les récursions impliquées dans les algorithmes de décodage pour en évaluer les performances des choix des largeurs des données en arithmétique virgule fixe. Perspectives La caractérisation des opérateurs non lisses est une étape obligatoire pour développer des modèles analytiques permettant l’évaluation de la précision des systèmes constitués de ce type d’opérateurs. Par conséquent, il s’avère important de pouvoir établir une classification de ce type d’opérateurs selon leurs propriétés mathématiques, et en particulier en fonction des propriétés de continuité et dérivabilité. Cette classification peut être la base de développement d’une approche générale permettant l’évaluation de la précision des systèmes de communication numérique et de traitement numérique de signal afin d’être en mesure de proposer un outil de haut niveau permettant l’évaluation de la précision de ces systèmes. Une seconde perspective concerne l’implémentation en virgule fixe de l’égaliseur à retour de décision en visant à quantifier les opérations itératives impliquées dans cet algorithme. De plus nous pouvons également réduire la taille des mémoires pour réaliser une architecture en arithmé- tique virgule fixe à faible complexité. En addition, nous pouvons également étendre les approches analytiques proposées pour évaluer la précision du DFE, en tenant compte de la variation des coefficients des filtres feedback et forward à chaque itération pour augmenter la précision de l’évaluation et ceci en prévoyant cette variation ou bien en utilisant des techniques d’apprentissage non-supervisé pour estimer les bornes de la variation de ces coefficients et les intégrer dans les approches analytiques proposées. Une dernière perspective peut être évoquée au sujet des algorithmes de décodage itératif. En effet, une approche analytique pour évaluer la précision de ces algorithmes peut être abordée en s’inspirant des modèles développés dans le cadre du DFE. En effet, les deux structures sont similaires puisqu’elle sont basées sur des calculs itératifs incluant un bloc de décision en sortie. Par conséquent, les modèles développés pour le cas du DFE dans le cadre de cette thèse peuvent être étendus pour évaluer la précision du turbo-décodeur et du décodeur LDPC selon les contraintes de précision et de coût d’implémentation souhaitées par l’utilisateur.Annexe A Quantification uniforme et quantification double Nous présentons dans cet annexe le principe de la quantification uniforme et double avec caractérisation dans le domaine de la fonction caractéristique. A.1 Quantification uniforme Le processus de quantification est par définition non lisse dans le sens strict. Pour déterminer l’applicabilité du modèle PQN à l’étude du processus de quantification, la relation entre la dynamique D du signal d’entrée et le pas de quantification q doit être considérée. Lorsque le pas de quantification est beaucoup plus petit que la dynamique du signal (q 5 α), il est possible de modéliser l’erreur introduite par la quantification en utilisant le modèle PQN. Cette hypothèse d’un faible pas de quantification (relativement à la dynamique du signal) est à l’origine des propriétés du modèle additif PQN. Dans le cas d’un opérateur non lisse, le pas de quantification est large et souvent comparable à la dynamique du signal D. Dans ces conditions, les propriétés de l’erreur de quantification, y compris la forme de bruit, sa propriété d’additivité et son indépendance statistique avec le signal d’entrée sont discutables et remises en question. Il est alors nécessaire de considérer un cadre plus général où les propriétés statistiques du bruit de quantification varient en fonction de la FDP du signal d’entrée et en fonction du pas de quantification. Dans cette section, nous présentons les dynamiques de la quantification des signaux réels dans le domaine de la fonction caractéristique. Cette analyse est ensuite appliquée pour les signaux quantifiés afin d’apprécier le processus de quantification durant une mise en cascade de deux opérateurs de quantification. A.1.1 Quantification dans le domaine de la fonction caractéristique Le phénomène de quantification ressemble à l’échantillonnage de Nyquist. De façon analogue à l’échantillonnage de Nyquist qui est défini sur l’axe temporel, la quantification peut être considérée comme l’échantillonnage tout au long de l’axe d’amplitude du signal. De ce fait, la FDP du signal et sa fonction caractéristique (FC) qui est sa transformée de Fourier sont analogues au signal dans son domaine temporel et sa représentation dans le domaine de Fourrier. De la même façon, le pas de quantification q joue un rôle similaire à la période d’échantillonnage de Nyquist T. La FC φx(u) du signal original x se répète tout au long de l’axe de son domaine u, la fréquence radian de quantification a un intervalle ψ = 2π q . La figure A.1 montre le chevauchement des fonctions caractéristiques du signal quantifié lorsque le pas de quantification est supérieur ou égal à qb. La largeur de bande d’un signal quantifié est définie par l’intervalle des pulsations [0, Wx], où Wx correspond à la pulsation limite engendrant une discontinuité dite à crenelage entre les images successives de la fonction caractéristique. Cette largeur de bande est donc est déterminée 129130 Quantification uniforme et quantification double à partir du pas de quantification selon : Wx = 2π qb tel que ∀ |u| ≥ 2π qb (A.1) Figure A.1 – Domaine de la fonction caractéristique Lorsque le pas de quantification est suffisamment faible, la fréquence angulaire est grande de telle sorte qu’elle ne permet pas le chevauchement de la fonction φx(u). Comme les pas de quanti- fication augmentent, la répétition est plus fréquente provoquant un crénelage/ Cette observation est connue par le premier théorème de quantification (TQ1). En d’autres termes, ce n’est que l’application du théorème d’échantillonnage de Nyquist selon l’axe d’amplitude du signal. Dans la figure A.1 q1 est le plus grand pas de quantification de telle sorte que TQ1 est satisfaite. Le second théorème de quantification (TQ2) assouplit les conditions fixées par TQ1 et permet le chevauchement des images de répétition des FC du signal. Le second théorème de quantification (TQ2) précise les conditions dans lesquelles les moments du signal d’origine peuvent être récupérés obtenusA.1, le plus grand pas de quantification qui peut satisfaire à la condition de TQ2 est noté qb. Soit Sr le moment d’ordre r du signal erreur de quantification et Rr est la covariance entre le moment d’ordre r de signal d’entrée x et l’erreur de quantification e. Les moments du signal quantifié xˆ sont données par : E[ˆxr] = E[xr] + Sr + Rr avec Rr = E[(x − x¯) r(e − e¯) r] (A.2) Lorsque les théorèmes TQ1 et TQ2 sont satisfaits, la valeur des coefficients Rr est nulle pour tout r. En d’autres termes, le modèle PQN peut être utilisé pour déterminer analytiquement l’effet du bruit de quantification. Le pas de quantification est assez grand pour que qb marque la frontière entre l’applicabilité et la non-applicabilité du modèle PQN. Lorsque le pas de quantification est augmenté au-delà de cette limite, la valeur de Rr devient non nulle, et les propriétés statistiques du signal quantifié s’écartent des valeurs données par le modèle PQN. Dans la pratique, le signal d’entrée prend un ensemble de valeurs finies et il est donc limité dans le domaine de la FDP. Théoriquement, cela rend la FC de la bande de signal illimitée. En d’autres termes, contrairement au cas représenté sur la figure A.1, la FC est en fait théoriquement nulle seulement à l’infini. Les théorèmes de quantification TQ3 et TQ4 se placent dans des conditions lorsque n’importe quel moment arbitraire du bruit de quantification et du signal peuvent être mutuellement orthogonales (i.e Rr dans l’équation (A.2) est nulle pour n’importe quel r) et leA.2 La quantification double 131 bruit de quantification continue d’être uniformément distribuée indépendamment du lieu où la FC passe à 0. Par conséquent, le modèle PQN est applicable sur un quantificateur de pas de quantification q si la fonction caractéristique d’entrée et ses dérivées prennent la valeur 0 à tous les points correspondant aux multiples de la fréquence angulaire de quantification φ = 2π q . A.2 La quantification double Tout système dans la pratique se compose de nombreux quantificateurs qui causent une quantification répétée tout au long d’un chemin de données en virgule fixe. Lorsque les théorèmes de quantification sont bien définis pour la première quantification, l’application du modèle PQN pour le phénomène de double quantification n’est pas rigoureusement définie car le sujet d’une cascade de plusieurs quantificateur n’est pas précisé par le modèle PQN particulièrement lorsqu’il s’agit d’opérateurs non lisses. Dans [85], il a été supposé que tous les quantificateurs sont toujours conformes aux conditions du modèle PQN. Afin de justifier cela, considérons une double quantification comme dans la figure A.2 avec deux quantificateurs en mode arrondi. Bien que la puissance du bruit total est affectée en raison d’une moyenne non nulle finie, la dynamique de la quantification n’est pas affectée dans le mode par troncature. Figure A.2 – Quantification double Dans les travaux présentés dans [92], la function densité de probabilité fxˆ1 (x) du signal xˆ1 à la sortie du premier quantificateur est donnée par : fxˆ1 (x)=(fx(x) ∗ fb1 (x)).cq1 (x) = '∞ m=−∞ δ(x − m.q1) m.q1+ q1 / 2 m.q1− q1 2 fx(α)dα. (A.3) avec δ est la fonction d’impulsion, fx(x) et fn1 (x) sont respectivement les FDP du signal d’entrée x et du signal de quantification au niveau du premier quantificateur. cq1 (x) est le train d’impulsions du premier quantificateur espacé de q1 unités et il est donné par : cq1 (x) = '∞ m=−∞ q1.δ(x − m.q1). (A.4) L’entrée du second quantificateur xˆ1 est de nature discrète. Cependant, les dynamiques de la quantification des signaux dont la FDP est discrète sont inchangées. En raison de l’amplitude discrète du signal d’entrée, il suffit de considérer l’erreur due à la quantification au niveau des points discrets. La FDP discrète du bruit de quantification au niveau du deuxième quantificateur fb2 (x) peut être écrite en discrétisant encore le niveau avec le pas de quantification du quantificateur précédent : fb2 (p) = J 1 k −k 2 ≤ p < k 2 0 autre part (A.5) avec p = xˆ q1 est une variable discrète correspondante à xˆ et k = q2 q1 est le rapport des pas de quantification. Lorsque un circuit arithmétique binaire est utilisé, il convient de noter que les pas de quantification des quantifications successives sont des puissance de 2. En d’autres termes,132 Quantification uniforme et quantification double échantillonner le train d’impulsions du premier quantificateur a un taux de k donne cq2 (x). Sa version discrétisée peut être écrite comme suit : cq2 (p) = '∞ m=−∞ k.δ(p − m.k). (A.6) La FDP du signal xˆ2 est une fonction de la FDP discrète. Elle peut être simplifiée suivant : fxˆ2 (p)=(fxˆ1 (p) ∗ fb2 (p)).cq2 (p) =   '∞ β=−∞ fb2 (p − β).fxˆ1 (β)   .cq2 (p) =   p+ k '2 β=p− k 2 1 k .fxˆ1 (β)   .cq2 (p) =   p+ k '2 β=p− k 2 1 k .fxˆ1 (β)   . '∞ m=−∞ k.δ(p − m.k) = '∞ m=−∞ δ(p − m.k) m.k+ k '2 β=m.k− k 2 fxˆ1 (β). (A.7) La FDP du signal xˆ2 est une fonction de la FDP discrète fxˆ1 (p) avec β est le compteur de k échantillons discrètes de la FDP du signal xˆ1 centrée sur m.k pour toute m. Elle peut être simplifiée comme une fonction du signal en précision infinie comme : fxˆ2 ( x q1 ) = '∞ m=−∞ δ( x q1 − m. q2 q1 ) m. q2 q1 + q2 '2q1 x q1 =m. q2 q1 − q2 2q1 fxˆ1 ( x q1 ) fxˆ2 (x) = '∞ m=−∞ δ(x − m.q2) m.q2+ q2 ' 2 x=m.q2− q2 2 fxˆ1 (x). (A.8) Considérons maintenant qu’un seul quantificateur soit utilisé pour obtenir xˆ2 avec un pas de quantification q2 = k.q1. La FDP du signal directement obtenu de l’équation A.3 s’écrit par la relation suivante : fxˆ2 (x) = '∞ m=−∞ δ(x − mq2) / mq2+ q2 2 mq2− q2 2 fx(α)dα (A.9) Le pas de quantification du deuxième quantificateur est un entier multiple du pas de quantification du premier quantificateur. Ainsi, la superficie totale couverte par l’intégrale entre le niveau (−q2 2 , q2 2 ) est aussi bonne que l’addition de k échantillons de la FDP dans l’intervalle. Cela se traduit par : / mq2+ q2 2 mq2− q2 2 fx(α)dα = m.q2+ q2 ' 2 x=m.q2− q2 2 fxˆ1 (x). (A.10) En comparant les relations (A.8) et (A.9), il est clair que la FDP du signal quantifié en cas de double quantification est la même que dans le cas de la seule quantification. Ce résultat signifie que les théorèmes de quantification sont applicables même dans le cas de la double de quantification comme si elle est appliquée sur le signal d’origine. En d’autres termes, le modèle PQN peut être appliqué pour estimer les statistiques globales du bruit de quantification à la sortie d’un quantificateur quelconque indépendamment du fait que le quantificateur agit sur un signal continu ou un signal déjà quantifié.Annexe B La méthode de Newton-Raphson pour la résolution des systèmes non linéaires B.1 Les systèmes non linéaires Le cas des systèmes non linéaires est beaucoup plus délicat que celui des des systèmes linéaires car les non-linéarités sont génératrices d’instabilités numériques fortes. Considérons l’exemple relativement simple du système suivant de deux équations à deux inconnues : J f1(x, y) = x2 − (y2 − 1)2 = 0 f2(x, y) == (x2 − 2)2 − 2y2 = 0 (B.1) L’équation f1(x, y)=0 correspond à une ligne courbe dans le plan xy ; de même pour l’équation f2(x, y)=0 . Le problème qui se pose alors consiste à rechercher les intersections de ces lignes courbes. En outre, ces lignes courbes peuvent dans certains cas dégénérer en simples points, ou encore en zones continues à deux dimensions (un demi-plan par exemple). Le cas particulier des fonctions ci-dessus est illustré par le diagramme suivant : Figure B.1 – diagramme des cas particuliers 133134 La méthode de Newton-Raphson pour la résolution des systèmes non linéaires Les équations f1(x, y)=0 et f2(x, y)=0 définissent des coniques, en conséquence la résolution du système défini par ces 2 équations revient à chercher tous les points d’intersections entre ces coniques. Sans le cas de l’exemple précédent, on observe huit solutions possibles. Si l’on généralise le problème précédent à un système de n équations à n inconnues, les lignes courbes précédentes sont généralement remplacées par des hyper-courbes de dimension n-1, ce qui rend le problème encore plus complexe. En fait, il n’y a pas de méthode miracle universelle et il est généralement nécessaire d’introduire des informations complémentaires sur le système à résoudre. Ceci peut concerner, par exemple, le nombre de solutions distinctes (en particulier, peuton attendre une unique solution ?) ou bien encore la position approximative de ces solutions. Toute autre information a priori sur le système est généralement bienvenue, sous réserve de modifier en conséquence l’implémentation des méthodes numériques de résolution. Sous réserve que l’on parvienne à cerner le problème posé, on peut simplifier le problème et généraliser la méthode de Newton-Raphson à n dimensions. Typiquement, le problème posé est du type :    f1(x1, x2, ..., xn)=0 f2(x1, x2, ..., xn)=0 . . . fn(x1, x2, ..., xn)=0 (B.2) Au voisinage d’un vecteur X = (x1, x2, ..xn), , chacune des fonctions fi peut être approximée par son développement de Taylor à un ordre donné. Si l’on considère une approximation à l’ordre 1, nous obtenons : fi(X + ∂X) = fi(X) + 'n j=1 ∂fi ∂xj (X)δxj + O(||δX||2) (B.3) Le principe de la méthode de Newton-Raphson repose alors sur les hypothèses suivantes : - le vecteur X n’est pas très éloigné de la solution cherchée, - on cherche alors δX de sorte que X + δX se rapproche encore de la solution, - on néglige tous les termes au-delà du second ordre dans le développement de Taylor , - on itère le processus jusqu’à ce que le terme correctif δXsoit assez faible. Figure B.2 – méthodeB.1 Les systèmes non linéaires 135 Il en résulte alors le système d’équations suivant : fi(X + δX) = fi(X) + 'n j=1 ∂fi ∂xj (X)δxj = 0 donc 'n j=1 ∂fi ∂xj (X)δxj = −fi(X) (B.4) On obtient alors un système linéaire de n équations à n inconnues dont la solution correspond aux composantes du vecteur δX. Le système peut alors être solutionné par des méthodes classiques adaptées à ce genre de problème. L’organigramme suivant détaille les principales phases de la méthode de Newton-Raphson.136 La méthode de Newton-Raphson pour la résolution des systèmes non linéairesBibliographie [1] Universal mobile telecommunication system, european telecommunications standards institute. ETSI UMTS TM, June 2000. [2] Satellite digital video broadcasting of second generation (dvb-s2). ETSI Standard EN302307, Feb 2005. [3] Physical layer and management parameters for 10 gb/s operation, type 10gbase-t. 802.3 Working Group, Sep 2006. [4] Digital video broadcasting (dvb) ; interaction channel for satellite distribution systems. European Telecommunications Standards Institute, July 2007. [5] Framing structure, channel coding and modulation for satellite services to handheld devices (sh) below 3 ghz,. Digital Video Broadcasting group, July 2007. [6] 3rd generation partnership project - technical specification group radio access network- high speed downlink packet access (hsdpa)-overall description. 3rd Gener. Partnership Project, Sept 2009. [7] Evolved universal terrestrial radio access (e-utra). 3rd Gener. Partnership Project 2, June 2009. [8] Ieee standard for local and metropolitan area network : Air interface for broadband wireless access systems, ieee computer society. IEEE Std 802.16TM, May 2009. [9] Local and metropolitan area networks specific requirements part 11 : Wireless lan medium access control (mac) and physical layer (phy) specifications amendment 5 : Enhancements for higher throughput. IEEE 802.11nTM., 2009. [10] R. Rocher A. Chakhari and P. Scalart. Analytical approach to evaluate fixed point accuracy for an iteration of decision operators. In In Proceedings of the IEEE International Conference on Computer Applications Technology (ICCAT 2013), Jan 2013. [11] W. Luk P. Cheung A. Gaffar, O. Mencer and N. Shirazi. Floating-point bit-width analysis via automatic differentiation. In International Conference on Field Programmable Logic and Applications, FPL2002,, pages 158–165, 2002. [12] L. Gonzalez-Perez A. Morales-Cortes, R. Parra-Michel and T. Cervantes. Finite precision analysis of the 3gpp standard turbo decoder for fixed-point implementation in fpga devices. in Int. Conf. on Reconfig. Computing FPGAs, pages 43–48, 2008. [13] M. Moussa A. Savich and S.Areibi. The impact of arithmetic representation on implementing mlp-bp on fpgas : A study. IEEE. Transactions on Neural Networks, pages 240–252, 2007. [14] T. Adali and S.H. Ardalan. Convergence and error analysis of the Fixed-Point RLS Algorithm with correlated inputs. In IEEE Conference on Acoustics, Speech and Signal Processing (ICASSP’90), pages 1479–1482, 1990. [15] P. Belanovic and M. Lesser. A library of parameterized floating-point modules and their use. In International Conference on Field Programmable Logic and Applications, FPL2002, pages 657–666, 2002. [16] P. Belanovic and M. Rupp. Fixify : A Toolset for Automated Floating-point to Fixedpoint Conversion. In International Conference on Computing, Communications and Control Technologies (CCCT’04), pages 28–32, 2004. 137138 BIBLIOGRAPHIE [17] P. Belanovic and M. Rupp. Automated Floating-point to Fixed-point Conversion with the fixify Environment. In IEEE Rapid System Prototyping (RSP’05), pages 172–178, 2005. [18] F. Berens and N. Naser. Algorithm to system-on-chip design flow that leverages systemstudio and systemc. Synopsys Inc, 2004. [19] T. Blankenship and B. Classon. Fixed-point performance of low complexity turbo decoding algorithms. in IEEE Vehicular Techn. Conf. (VTC), 2 :1483–1487, 2001. [20] T. Bose and M.-Q. Chen. Over flow oscillations in state-space digital filters. IEEE Transactions on Circuits and Systems, 38 :807–810, jul 1991. [21] T. Bose and M.-Q. Chen. Stability of digital filters implemented with two’s complement truncation quantization. IEEE Transactions on Circuits and Systems, 40 :24–31, jan 1992. [22] A. Glavieux C. Berrou and P. Thitimajshima. Near shannon limit error correcting coding and decoding : Turbo codes. in IEEE Intern. Conf. on Commun., 2 :1064–1070, May 1993. [23] C. Douillard C. Berrou, M. Jezequel and S. Keroudan. The advantages of non-binary turbo codes. In in Inform. Theory Workshop, pages 61–62, Sep 2001. [24] P. Cheung C. Ewe and G. A. Constantinides. Error modeling of dual fixed-point arithmetic and its application in field programmable logic. In International Conference on Field Programmable Logic and Applications, FPL2005, pages 124–129, 2005. [25] P. Leong-W. Luk C. H. Ho, C. W. Yu and S. Wilton. Floating-point fpga : Architecture and modeling. IEEE. Transactions on Very Large Scale Integration Systems, pages 1709–1718, 2009. [26] M. Lu C. He, G. Qin and W. Zhao. An efficient implementation of high accuracy finite difference computing engine on fpgas. In International Conference on Application Specific Systems, Architectures and Processors, pages 95–98, 2006. [27] S. Wilton P. Leong C. W. Yu, J. Lamoureux and W. Luk. The coarse-grained/ fine-grained logic interface in fpgas with embedded floating-point arithmetic. International Journal of Reconfigurable Computing, pages 1–10, 2008. [28] J.M. Cheneaux, L.S. Didier, and F. Rico. The fixed cadna library. Real Number and Computers, September 2003. [29] J.M. Cheneaux and J.Vignes. Les fondements de l’arithmétique stochastique. C.R. Académie des Sciences, pages 1435–1440, 1992. [30] Jung-Fu Cheng and T. Ottosson. Linearly approximated log-map algorithms for turbo decoding. Vehicular Technology Conference Proceedings, 2000. VTC 2000-Spring Tokyo. 2000 IEEE 51st, 3 :2252 – 2256, May 2000. [31] G. Constantinides, P. Cheung, and W. Luk. Truncation Noise in Fixed-Point SFGs. IEEE Electronics Letters, 35(23) :2012–2014, November 1999. [32] G. Constantinides, P. Cheung, and W. Luk. Roundoff-noise shaping in filter design. In IEEE Symposium on Circuits and Systems (ISCAS’00), pages IV57–IV60, Geneva, Switzerland, May 28-31 2000. Institute of Electrical and Electronics Engineers. [33] M. Coors, H. Keding, O. Luthje, and H. Meyr. Integer Code Generation For the TI TMS320C62x. In International Conference on Acoustics, Speech, and Signal Processing 2001 (ICASSP’01), Sate Lake City, US, May 2001. [34] L. De Coster, M. Ade, R. Lauwereins, and J.A. Peperstraete. Code Generation for Compiled Bit-True Simulation of DSP Applications. In Proceedings of the 11th International Symposium on System Synthesis (ISSS’98), Taiwan, December 1998. [35] P. Raghavan L. Van der Perre J. Huisken D. Novo, A. Kritikakou and F. Catthoor. Ultra low energy domain specific instruction-set processor for on-line surveillance. IEEE 8th Symposium on Application Specific Processors (SASP), pages 30–35, mar 2010. [36] L.H. de Figueiredo and J. Stolfi. Affine Arithmetic : Concepts and Applications. Numerical Algorithms, pages 1–13, 2003.BIBLIOGRAPHIE 139 [37] C. Douillard E. Boutillon and G. Montorsi. Iterative decoding of concatenated convolutional codes : implementation issues. Proc. IEEE, 95 :1201–1227, June 2007. [38] J. Castura E. Boutillon and F. Kschischang. Decoder-first code design. in Intern. Symp. on Turbo Codes and Related Topics, pages 459–462, Sep 2000. [39] W. J. Gross E. Boutillon and P. G. Gulak. Vlsi architectures for the map algorithm. IEEE Trans. Commun, 51 :175–185, 2003. [40] C. Klein F. de Dinechin and B. Pasca. Generating high-performance custom floating-point pipelines. In International Conference on Field Programmable Logic and Applications, FPL 2009, pages 59–64, 2009. [41] J. Tousch F. Guilloud, E. Boutillon and J.-L. Danger. Generic description and synthesis of ldpc decoders. IEEE Trans. Commun, 55 :2084–2091, November 2006. [42] P. Y. K. Cheung G. A. Constantinides and W. Luk. Wordlength optimization for digital signal processing. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems, 32 :1432–1442, 2003. [43] G. Leyva C. Carreras G Caffarena, J. A. Lopez and O. Nieto Taladriz. Architectural synthesis of fixed-point dsp datapaths using fpgas. International Journal on Reconfigurable Computing, pages 1–8, January 2009. [44] J. A. Lopez G. Caffarena, C. Carreras and A. Fernandez. Sqnr estimation of fixed-point dsp algorithms. EURASIP Journal on Advanced Signal Processing, pages 1–21, Feb 2010. [45] M. Gevers G. Li and Youxian S. Performance analysis of a new structure for digital filter implementation. IEEE Transactions on Circuits and Systems I : Fundamental Theory and Applications, 47 :474–482, apr 2000. [46] R. Gallager. Low-Density Parity-Check Codes. PhD thesis, Massachusetts Institutes of Technology, 1960. [47] D.N. Godard. Self recovering equalization and carrier tracking in two dimensional data communications systems. IEEE Trans. on Communications, 28(11) :1867–1875, November 1980. [48] O. Luthje H. Keding, M. Coors and H. Meyr. Fast bit-true simulation. In Proceedings of the 38th annual Design Automation Conference, pages 708–713, 2001. [49] D. Hocevar. A reduced complexity decoder architecture via layered decoding of ldpc codes. in IEEE Work. on Signal Proc. Systems, SISP 2004, pages 107–112, 2004. [50] http ://reference.wolfram.com/language/. [51] G. Caffarena J. A. Lopez and C. Carreras. Fast and accurate computation of l2 sensitivity in digital filter realizations. In Technical Report, University Politechnica de Madrid,, 2006. [52] O. Macchi J. Labat and C. Laot. Adaptive decision feedback equalization : can you skip the training period ? IEEE Trans. on Communication, pages 921–930, July 1998. [53] C. Carreras J.A. Lopez, G. Caffarena and O. Nieto-Taladriz. Analysis of limit cycles by means of affne arithmetic computer-aided tests. In 12th European Signal Processing Conference (EUSIPCO 2004), pages 991–994, 2004. [54] C. Carreras J.A. Lopez, G. Caffarena and O. Nieto-Taladriz. Fast and accurate computation of the roundoff noise of linear time-invariant systems. IET Circuits, Devices Systems, 2 :393– 408, aug 2008. [55] G. Caffarena J.A. Lopez, C. Carreras and O. Nieto-Taladriz. Fast characterization of the noise bounds derived from coefficient and signal quantization. In Circuits and Systems, 2003. ISCAS ’03. Proceedings of the 2003 International Symposium on, 4 :309–312, may 2008. [56] F. Cruz-Roldan J.D.O. Campo and M. Utrilla-Manso. Tighter limit cycle bounds for digital filters. IEEE Signal Processing Letters, 13 :149–152, mar 2006.140 BIBLIOGRAPHIE [57] K. Kalliojarvi and J. Astola. Roundoff errors in block-floating-point systems. IEEE Transactions on Signal Processing, pages 783–790, apr 1996. [58] H. Kfir and I. Kanter. Parallel versus sequential updating for belief propagation decoding. Physica A Statistical Mechanics and its Applications, 330 :259–270, Dec 2003. [59] S. Kim, K. Kum, and W. Sung. Fixed-Point Optimization Utility for C and C++ Based Digital Signal Processing Programs. In Workshop on VLSI and Signal Processing ’95, Osaka, November 1995. [60] S. Kim and W. Sung. Fixed-Point-Simulation Utility for C and C++ Based Digital Signal Processing Programs. In Twenty-eighth Annual Asilomar Conference on Signals, Systems, and Computer, October 1994. [61] S. Kim and W. Sung. Fixed-Point Error Analysis and Word Length Optimization of 8x8 IDCT Architectures. IEEE Transactions on Circuits and Systems for Video Technology, 8(8) :935–940, December 1998. [62] K. I. Kum and W. Sung. Combined word-length optimization and high-level synthesis of digital signal processing systems. IEEE Transactions on Computer Aided Design of Integrated Circuits and Systems, 20 :921–930, 2001. [63] F. Jelinek L. Bahl, J. Cocke and J. Raviv. Optimal decoding of linear codes for minimizing symbol error rate. IEEE Trans. Inf. Theory, pages 284–287, Mar 1974. [64] R. Lauwereins L. De Coster, M. Ade and J. Peperstraete. Code generation for compiled bit-true simulation of dsp applications. In Proceedings of the 11th International Symposium on System Synthesis 1998, pages 9–14, dec 1998. [65] P. Lapsley, J. Bier, A. Shoham, and E. A. Lee. DSP Processor Fundamentals : Architectures and Features. Berkeley Design Technology, Inc, Fremont, CA, 1996. [66] E. E. Lopez A. Bourdoux D. Novo L. Van Der Perre M. Li, B. Bougard and F. Catthoor. Selective spanning with fast enumeration : A near maximum-likelihood mimo detector designed for parallel programmable baseband architectures. In IEEE International Conference on Communications (ICC) 2008, May 2008. [67] M. Mansour and N. Shanbhag. High-throughput ldpc decoders. IEEE Transactions on VLSI System, 11 :976–996, Dec 2003. [68] P. Meignen. Analyse statistique de systémes en virgule fixe. Technical report, ENSSAT, Lannion, Septembre 2005. [69] D. Menard. Methodologie de compilation d’algorithmes de traitement du signal pour les processeurs en virgule fixe, sous contrainte de precision. PhD thesis, Universite de Rennes I, Lannion, Dec 2002. [70] D. Menard, R. Rocher, P. Scalart, and O. Sentieys. SQNR determination in non-linear and non-recursive fixed-point systems. In XII European Signal Processing Conference (EUSIPCO’04), pages 1349–1352, Vienna, Austria, September 2004. [71] S.K. Mitra. Digital signal processing laboratory using matlab. WCB/Mc-GrawHill, University of California, Santa Barbara, 1999. [72] G. Montorsi and S. Benedetto. Design of fixed-point iterative decoders for concatenated codes with interleavers. IEEE J. Sel. Areas Commun, 19 :871–882, 2001. [73] A. Oppenheim. Realization of digital filters using block-floating-point arithmetic. IEEE Transactions on Audio and Electroacoustics, 18 :130–136, jun 1970. [74] E. Ozer, A.P. Nisbet, and D. Gregg. Stochastic Bitwidth Approximation Using Extreme Value Theory for Customizable Processors. Technical report, TrinityCollege, Dublin, Ireland, October 2003. [75] K. Parashar. System-level Approaches for Fixed-point Refinement of Signal Processing Algorithms. PhD thesis, Universite de Rennes I, Lannion, Dec 2012.[76] J. Proakis. Digital Communications, volume 1. McGraw-Hill, 4 edition, 2000. [77] N. Hervé R. Rocher, D. Menard and O. Sentieys. Fixed-point configurable hardware components. EURASIP Journal on Embedded Systems, pages 1–13, January 2006. [78] S. Wilson R. Zarubica, R. Hinton and E. Hall. Efficient quantization schemes for ldpc decoders. in IEEE Military Commun. Conf. (MILCOM), pages 1–5, 2008. [79] T. J. Richardson and R. L. Urbanke. Efficient encoding of low density parity check codes. IEEE Trans. Inf. Theory, 47 :638–656, Feb 2001. [80] G. Montorsi S. Benedetto, D. Divsalar and F. Pollara. Serial concatenation of interleaved codes : performance analysis, design and iterative decoding. IEEE Trans. Inf. Theory., 44 :909–926, May 1998. [81] G. Montorsi S. Benedetto, D. Divsalar and F. Pollara. Soft-input soft-output modules for the construction and distributed iterative decoding of code networks. Europ. Trans. on Telecomm., 9, Apr 1998. [82] R. Serizel. Implantation en virgule fixe d’un codeur audio. Master’s thesis, ENSSAT, Lannion, Septembre 2006. [83] C. Shi. Floating-point to Fixed-point Conversion. PhD thesis, University of California, Berkeley, Lannion, Apr 2004. [84] C. Shi and R. W. Brodersen. Floating-point to fixed-point conversion. IEEE Trans. Signal Processing, 2004. [85] C. Shi and R.W. Brodersen. A perturbation theory on statistical quantization effects in fixedpoint dsp with non-stationary inputs. In Proceedings of the 2004 International Symposium on Circuits and Systems, ISCAS 2004, volume 3, may 2004. [86] W. Mecklenbrauker T. Claasen and J. Peek. Effects of quantization and over ow in recursive digital filters. Acoustics, Speech and Signal Processing, IEEE Transactions on, 24 :517–529, dec 1976. [87] T. Inoue W. Zeng T. Hinamoto, S. Yokoyama and Wu-Sheng Lu. Analysis and minimization of l2-sensitivity for linear systems and two-dimensional state-space filters using general controllability and observability gramians. IEEE Transactions on Circuits and Systems I : Fundamental Theory and Applicationsn, 49 :1279–1289, sep 2002. [88] Z. Wang T. Zhang and K. Parhi. On finite precision implementation of low density parity check codes decoder. in Proc. IEEE ISCAS, 4 :202–205, May 2001. [89] R. Tanner. A recursive approach to low complexity codes. IEEE Trans. Inf. Theory, 27 :533– 547, Sep 1981. [90] C. Mullis W. Mills and R. Roberts. Digital filter realizations without overflow oscillations. IEEE Transactions on Acoustics, Speech and Signal Processing, 26 :334–338, aug 1978. [91] S. Wadekar and A. Parker. Accuracy Sensitive Word-Length Selection for Algorithm Optimization. IEEE/ACM International Conference on Computer Design (ICCAD’98), pages 54–61, 1998. [92] B. Widrow and I. Kollar. Quantization noise : Roundoff error in digital computation, signal processing, control, and communications. Cambridge University Press, Cambridge, UK, 2008. [93] B. Widrow, I. Kollár, and M.-C. Liu. Statistical Theory of Quantization. IEEE Transactions on Instrumentation and Measurement, 45(2) :353–361, Apr. 1996. [94] Xilinx. System generator for dsp. In http ://www.xilinx.com. [95] H. Zhong and T. Zhang. Block-ldpc : A practical ldpc coding system design approach. IEEE Trans. Circuits Syst, 52 :766–775, Apr 2005. [96] U. Zölzer. Digital Audio Signal Processing. John Wiley and Sons, August 1997. 141 Un ˆılot formel pour les transformations de mod`eles qualifiables Jean-Christophe Bach To cite this version: Jean-Christophe Bach. Un ˆılot formel pour les transformations de mod`eles qualifiables. Programming Languages. Universit´e de Lorraine, 2014. French. HAL Id: tel-01081055 https://tel.archives-ouvertes.fr/tel-01081055 Submitted on 6 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Institut National de Recherche en Informatique et Automatique Universit´e de Lorraine Ecole doctorale IAEM (Informatique, Automatique, ´ Electronique et Math´ematiques) ´ Un ˆılot formel pour les transformations de mod`eles qualifiables THESE ` pr´esent´ee et soutenue publiquement le 12 septembre 2014 pour l’obtention du Doctorat de l’Universit´e de Lorraine (sp´ecialit´e informatique) par Jean-Christophe Bach Composition du jury Rapporteurs : Antoine Beugnard Professeur, Telecom Bretagne Laurence Duchien Professeur, Universit´e de Lille 1, LIFL Examinateurs : Mark van den Brand Professeur, Eindhoven University of Technology Benoˆıt Combemale Maˆıtre de conf´erences, Universit´e de Rennes 1, IRISA, Inria Marc Pantel Maˆıtre de conf´erences, Universit´e de Toulouse, INPT, IRIT Encadrant de th`ese : Pierre-Etienne Moreau Professeur, Universit´e de Lorraine, Ecole des Mines de Nancy ´ Laboratoire Lorrain de Recherche en Informatique et ses Applications — UMR 7503iiiii Remerciements Je tiens `a remercier mes encadrants de th`ese, Marc Pantel et Pierre-Etienne Moreau, qui ont accept´e de m’encadrer en tant que doctorant, malgr´e la distance pour l’un et les responsabilit´es administratives pour l’autre. Je voudrais aussi remercier les personnes qui m’ont fait l’honneur d’accepter de faire partie de mon jury de soutenance : Laurence Duchien et Antoine Beugnard qui ont accept´e d’ˆetre rapporteurs de ce travail de th`ese, Benoˆıt Combemale et Mark van den Brand d’en ˆetre examinateurs. Merci aux membres et ex-membres de l’´equipe Pareo, `a Lo¨ıc ainsi qu’au groupe du projet quarteFt, sans qui ce travail n’aurait pas ´et´e possible. Et bien sˆur, un merci `a toutes celles et ceux qui m’ont accompagn´es durant cette th`ese. En particulier Kar¨en qui a ´et´e pr´esente tout au long de ma th`ese malgr´e sa vie bien charg´ee, son mari, son fils et ses concours. Merci `a Pierre, Gilles, Martin et ses trolls (et pas forc´ement dans cet ordre) pour les discussions scientifiques, techniques et politiques, ainsi que les rafraˆıchissantes pauses de « bidouille & m´ediation scientifique ». Evidemment, je n’oublie pas mes impitoyables relectrices-correctrices — Chlo´e, Kar ´ ¨en et Marion — et leur rigueur qui m’ont aid´e `a am´eliorer la qualit´e grammaticale, orthographique et typographique de mon tapuscrit. Une mention sp´eciale `a mes soutiens distants : `a Cl´audia qui m’a soutenu par la mise en place d’une fili`ere br´esilienne d’importation de Tang et de caf´e ; `a Val´erie depuis Rennes qui r´edigeait en parall`ele. Et parce que dans la th`ese il n’y a pas que la th`ese, merci `a toutes les personnes avec qui j’ai discut´e et pass´e du temps : Cl´ement, Sergue¨ı et le triumvirat C´eline-Fabrice-Guillaume pour les discussions politico-syndicales ; Paul, Pini, Jonathan, Christophe et tous les connect´es du canal de discussion relay´ee par Internet #linux pour leurs trolls et d´ebats libro-informatiques ; Ju, S´eb, les membres de LDN et autres d´efenseurs du logiciel libre et d’un Internet neutre ; Nico lors de mes retours pour mise au vert `a Lille. Une pens´ee pour les adorables petits bouts — L´eonard, Margaux et Thomas — qui m’ont aid´e `a me changer les id´ees. Enfin, merci `a mes parents sans qui je n’aurais pu commencer ni finir cette ´epreuve.ivTable des mati`eres Table des figures ix Introduction 1 I Etat de l’art 5 ´ 1 Un langage bas´e sur la r´e´ecriture : Tom 7 1.1 R´e´ecriture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.1.1 Signature alg´ebrique et termes . . . . . . . . . . . . . . . . . . . . . 7 1.1.2 Filtrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1.3 R´e´ecriture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 1.1.4 Strat´egies de r´e´ecriture . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2 Le langage Tom . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.2.1 Signature alg´ebrique . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.2 Construction backquote « ‘ » . . . . . . . . . . . . . . . . . . . . . . 14 1.2.3 Filtrage de motif . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 1.2.4 Notations implicite et explicite . . . . . . . . . . . . . . . . . . . . . 18 1.2.5 Strat´egies : maˆıtriser l’application des r`egles de r´e´ecriture . . . . . . 19 1.3 Ancrages formels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.4 Domaines d’applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.5 Apport de la th`ese au projet Tom . . . . . . . . . . . . . . . . . . . . . . . 24 2 Transformations de mod`eles 27 2.1 Mod´elisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2 Transformations de mod`eles . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.2.1 Taxonomie des transformations . . . . . . . . . . . . . . . . . . . . 32 2.2.2 Approches de d´eveloppement des transformations de mod`eles . . . 33 2.2.3 Outils existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 2.3 Limitations actuelles et points d’am´elioration . . . . . . . . . . . . . . . . 37 3 V´erification du logiciel 39 3.1 Approches pour la v´erification du logiciel . . . . . . . . . . . . . . . . . . . 39 3.1.1 Relecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 vvi Table des mati`eres 3.1.2 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.1.3 Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.1.4 Preuve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.1.5 Model-checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.2 Certification et qualification . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.3 Tra¸cabilit´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 II Contributions 45 4 Transformations de mod`eles par r´e´ecriture 47 4.1 Choix et int´erˆet d’une approche hybride . . . . . . . . . . . . . . . . . . . 47 4.2 Repr´esentation de mod`eles par une signature alg´ebrique . . . . . . . . . . . 48 4.3 Transformation de mod`eles par r´e´ecriture . . . . . . . . . . . . . . . . . . . 49 4.3.1 Approche compositionnelle . . . . . . . . . . . . . . . . . . . . . . . 50 4.3.2 R´esolution - r´econciliation . . . . . . . . . . . . . . . . . . . . . . . 53 4.4 Validation par un cas d’´etude . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.5 Synth`ese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5 Sp´ecification et tra¸cabilit´e des transformations 57 5.1 Sp´ecification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 5.2 Tra¸cabilit´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2.1 Tra¸cabilit´e interne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.2 Tra¸cabilit´e de sp´ecification . . . . . . . . . . . . . . . . . . . . . . . 59 5.3 Synth`ese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6 Outils pour exprimer une transformation de mod`eles en Tom 63 6.1 Exemple d’utilisation des outils . . . . . . . . . . . . . . . . . . . . . . . . 63 6.1.1 Exemple support . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.1.2 Mode op´eratoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.2 Extension du langage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 6.2.1 Expression d’une transformation . . . . . . . . . . . . . . . . . . . . 70 6.2.2 R´esolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.2.3 Tra¸cabilit´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.3 Travaux d’impl´ementation . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 6.3.1 Architecture du projet Tom et chaˆıne de compilation . . . . . . . . 72 6.3.2 G´en´erateur d’ancrages alg´ebriques . . . . . . . . . . . . . . . . . . . 75 6.3.3 Mise en œuvre de l’extension . . . . . . . . . . . . . . . . . . . . . . 78 6.4 Synth`ese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 7 Etudes de cas : illustration et utilisation du langage 83 ´ 7.1 Cas SimplePDLToPetriNet . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 7.1.1 M´etamod`eles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83vii 7.1.2 Exemple de processus et de r´eseau de Petri r´esultant . . . . . . . . 84 7.1.3 Impl´ementation en utilisant les outils d´evelopp´es . . . . . . . . . . 85 7.2 Aplatissement d’une hi´erarchie de classes . . . . . . . . . . . . . . . . . . . 93 7.2.1 Exemple de transformation . . . . . . . . . . . . . . . . . . . . . . . 93 7.2.2 M´etamod`ele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.2.3 Impl´ementation utilisant les outils d´evelopp´es . . . . . . . . . . . . 94 7.3 Synth`ese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 8 R´esultats exp´erimentaux 101 8.1 Utilisabilit´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 8.2 Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 8.2.1 Tom-EMF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 8.2.2 Transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 8.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 Conclusion 111 A Etude de cas : Transformation SimplePDLToPetriNet 115 ´ A.1 Code de la transformation SimplePDLToPetriNet . . . . . . . . . . . . . . 115 A.2 Mod`ele source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 A.3 Mod`ele r´esultant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 A.4 V´erification du r´esultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 B Etude de cas : aplatissement d’une hi´erarchie de classes 123 ´ B.1 Code de la transformation . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 B.1.1 Version 1 : transformation en Java+EMF . . . . . . . . . . . . . . . 123 B.1.2 Version 2 : transformation en Tom+Java simple (+EMF) . . . . . . 124 B.1.3 Version 3 : transformation en Tom+Java avec strat´egies (+EMF) . . 126 B.1.4 Version 4 : transformation en Tom+Java avec les nouvelles constructions (+EMF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 C Impl´ementation ATL de SimplePDLToPetriNet 131 Glossaire 135 Bibliographie 137viii Table des mati`eresTable des figures 1.1 Exemple de repr´esentation arborescente d’un terme. . . . . . . . . . . . . . . . 8 1.2 Notation des positions dans un terme. . . . . . . . . . . . . . . . . . . . . . . . 8 1.3 Exemple de r`egle de r´e´ecriture : distributivit´e de la multiplication par rapport `a l’addition dans un anneau, `a savoir x × (y + z) → (x × y) + (x × z). . . . . . 10 1.4 Propri´et´es sur les relations binaires. . . . . . . . . . . . . . . . . . . . . . . . . 11 1.5 Fonctionnement global du projet Tom en d´ebut de th`ese. . . . . . . . . . . . . . 25 1.6 Fonctionnement global de Tom et contributions de ce travail de th`ese au projet. 26 2.1 Organisation du MDA en 4 niveaux d’abstraction (3+1). . . . . . . . . . . . . 29 2.2 Interpr´etation des niveaux d’abstraction du MDA. . . . . . . . . . . . . . . . . 30 2.3 Classification des cat´egories de transformations de mod`eles. . . . . . . . . . . . 33 2.4 Architecture du standard QVT [OMG08]. . . . . . . . . . . . . . . . . . . . . . 36 4.1 M´etamod`ele des graphes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2 Transformation du mod`ele source A;B en un mod`ele cible graphique. . . . . . . 50 4.3 R`egles de transformation de A, ; et B. . . . . . . . . . . . . . . . . . . . . . . . . 50 4.4 Sch´ema d’extension du m´etamod`ele cible par l’ajout d’´el´ements interm´ediaires resolve. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.5 R`egles de transformation de A, ; et B effectives avec la construction d’´el´ements resolve (en pointill´es color´es). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.6 R´esultat interm´ediaire de la transformation, avant phase de r´esolution. . . . . . 53 4.7 Phase de r´esolution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.8 R`egles de transformation de A, ; et B effectives, avec tra¸cage des ´el´ements correspondant `a un ´el´ement resolve d’une autre d´efinition (token color´e de la couleur du r´esultat d’une d´efinition). . . . . . . . . . . . . . . . . . . . . . . . . 54 4.9 Exemple de processus SimplePDL. . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.10 R´eseau de Petri correspondant au processus d´ecrit par la figure 4.9. . . . . . . . 55 4.11 Transformations ´el´ementaires composant SimplePDLToPetriNet. . . . . . . . . 55 5.1 M´etamod`ele SimplePDL possible. . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2 M´etamod`ele des r´eseaux de Petri. . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.3 M´etamod`ele g´en´erique de trace. . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.1 Exemple de transformation de texte en formes g´eom´etriques color´ees. . . . . . . 63 6.2 Un m´etamod`ele pouvant d´ecrire le formalisme textuel (source) utilis´e dans l’exemple support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 6.3 Un m´etamod`ele pouvant d´ecrire le formalisme graphique (cible) utilis´e dans l’exemple support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 6.4 Diagramme d’activit´e d´ecrivant le processus de compilation d’un programme Tom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.5 Phases du compilateur Tom. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.6 Processus de compilation d’une transformation de mod`eles Tom-EMF. . . . . . 76 ixx Table des figures 6.7 Bootstrap de Tom-EMF : remplacement des ancrages alg´ebriques Ecore.tom ´ecrits manuellement par les ancrages g´en´er´es. . . . . . . . . . . . . . . . . . . . 77 6.8 Processus de r´esolution de liens inverses. . . . . . . . . . . . . . . . . . . . . . . 81 7.1 M´etamod`ele SimplePDL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 7.2 M´etamod`ele des r´eseaux de Petri. . . . . . . . . . . . . . . . . . . . . . . . . . . 84 7.3 Exemple de processus d´ecrit dans le formalisme SimplePDL. . . . . . . . . . . . 85 7.4 R´eseau de Petri ´equivalent au processus d´ecrit par la figure 7.3. . . . . . . . . . 85 7.5 R´eseau de Petri r´esultant de la transformation d’un Process. . . . . . . . . . . . 86 7.6 R´eseau de Petri r´esultant de la transformation d’une WorkDefinition. . . . . . 88 7.7 R´eseau de Petri r´esultant de la transformation d’une WorkSequence. . . . . . . 90 7.8 Aplatissement d’une hi´erarchie de classes. . . . . . . . . . . . . . . . . . . . . . 93 7.9 M´etamod`ele d’UML simplifi´e. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.10 M´etamod`ele consid´er´e pour l’´etude de cas. . . . . . . . . . . . . . . . . . . . . . 94 7.11 Arbres repr´esentant les mod`eles source des exemples SimplePDLToPetriNet (a) et ClassFlattening (b). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.1 Forme g´en´erale des mod`eles d’entr´ee g´en´er´es. . . . . . . . . . . . . . . . . . . . 104 8.2 R´eseaux de Petri images d’un Process, d’une WorkDefinition et d’une WorkSequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 8.3 Temps moyen de transformation (en ms) en fonction du nombre d’´el´ements dans le mod`ele source (phase 1, phase 2, total). . . . . . . . . . . . . . . . . . . 106Introduction Le sujet de cette th`ese est l’´elaboration de m´ethodes et outils pour le d´eveloppement logiciel fiable s’appuyant sur des transformations de mod`eles. Plus pr´ecis´ement, la question est de savoir comment am´eliorer la confiance dans un logiciel et dans son processus de d´eveloppement alors que les chaˆınes de d´eveloppement se complexifient et que les outils se multiplient. L’industrie adopte progressivement les techniques de l’Ing´enierie Dirig´ee par les Mod`eles. L’un des int´erˆets de ce domaine est d’acc´el´erer le d´eveloppement logiciel `a moindre coˆut par l’usage de langages d´edi´es et d’outils de g´en´eration de code. Dans ce contexte, les logiciels sont donc en partie issus de chaˆınes de transformations op´er´ees sur des mod`eles jusqu’`a la g´en´eration du code et sa compilation. Dans le cadre du d´eveloppement de syst`emes critiques, les logiciels doivent ˆetre v´erifi´es afin d’ˆetre certifi´es. Se pose alors la question de la qualification des logiciels utilis´es dans les chaˆınes de d´eveloppement des syst`emes critiques. Il faut s’assurer que les outils n’introduisent pas de bogue `a chaque ´etape du processus de d´eveloppement et qu’une trace puisse ˆetre conserv´ee, de la sp´ecification au code. Le langage Tom repose sur le calcul de r´e´ecriture et fournit des fonctionnalit´es telles que le filtrage `a des langages g´en´eralistes comme Java ou Ada. Des constructions de haut niveau permettent de d´ecrire formellement des algorithmes. Il offre la possibilit´e d’´etablir des r`egles de transformation pour ´ecrire des outils de transformation sˆurs. La finalit´e de cette th`ese est donc de proposer des m´ethodes et outils pour exprimer des transformations de mod`eles qualifiables. On s’int´eresse `a fournir des constructions d´edi´ees pour d´ecrire une transformation de mod`eles et pour assurer la tra¸cabilit´e entre le mod`ele source et le mod`ele cible. Le but ´etant alors de donner des ´el´ements de confiance suppl´ementaires `a l’utilisateur responsable de la v´erification de la chaˆıne de d´eveloppement. 12 Introduction Contexte et motivations Les syst`emes se complexifiant, l’ing´enierie dirig´ee par les mod`eles (IDM) a apport´e des solutions pour faciliter et acc´el´erer le d´eveloppement logiciel. Ce domaine a v´eritablement pris son essor `a la fin du XX`eme si`ecle avec la publication de l’initiative MDA (Model Driven Architecture) par l’OMG (Object Management Group). L’industrie a adopt´e les m´ethodes et technologies issues du monde des mod`eles, y compris dans le cadre du d´eveloppement de syst`emes critiques. Cependant, si la mani`ere de d´evelopper un logiciel ainsi que les technologies utilis´ees ont chang´e depuis les d´ebuts de l’informatique, les contraintes li´ees `a la maintenance (´evolution du logiciel, d´eboguage) ainsi qu’`a la fiabilit´e (qualification, certification) persistent. Les technologies des domaines critiques tels que l’a´eronautique, l’automobile et la m´edecine reposant de plus en plus sur l’informatique, il est particuli`erement important de s’assurer du bon fonctionnement des logiciels avant leur mise en production. Pour cela, il est n´ecessaire de les v´erifier. Plusieurs approches compl´ementaires sont disponibles pour augmenter la confiance en un logiciel : le test, la preuve, la simulation et le model-checking. Chacune d’entre elles comporte ses sp´ecificit´es, ses avantages et ses inconv´enients. Dans le cadre de la qualifi- cation et de la certification, ces approches sont rarement suffisantes une `a une et sont donc g´en´eralement combin´ees ou pratiqu´ees en parall`ele. Lors de la certification, il est n´ecessaire d’avoir une confiance forte dans les outils utilis´es dans le processus de d´eveloppement. Cette confiance est accord´ee par leur qualification qui exige une tra¸cabilit´e entre la sp´ecification et l’impl´ementation d’un logiciel. L’int´egration de l’IDM dans les chaˆınes de d´eveloppement de syst`emes critiques tendant `a se g´en´eraliser, il est fondamental de d´evelopper des m´ethodes et des outils pour aider au processus de qualification des nouveaux outils. Dans ce contexte, nous nous proposons de travailler `a l’´elaboration de m´ethodes et d’outils permettant d’apporter des ´el´ements de confiance pour la qualification du logiciel. Nous nous pla¸cons `a la fronti`ere de deux domaines : celui de l’Ing´enierie Dirig´ee par les Mod`eles ainsi que celui de la r´e´ecriture de termes. L’industrie a vu l’int´erˆet pratique de l’IDM et a adopt´e les outils qui en sont issus. Les m´ethodes formelles, en particulier le domaine de la r´e´ecriture qui nous int´eresse, sont quant `a elles moins connues, mais indispensables pour un d´eveloppement logiciel de qualit´e. Se placer `a la fronti`ere des deux domaines permet de tirer le meilleur des deux mondes et de pousser l’utilisation des m´ethodes formelles dans l’ing´enierie du logiciel, que ce soit dans un cadre acad´emique ou industriel. L’un des piliers de l’IDM r´eside dans les transformations de mod`eles. Nous souhaitons leur apporter plus de fiabilit´e en fournissant des outils s’appuyant sur le langage Tom. Celui-ci repose sur la r´e´ecriture et le filtrage pour manipuler et transformer des structures complexes. Il s’int`egre au sein de langages g´en´eralistes tels que Java et offre des constructions d´edi´ees permettant `a l’utilisateur d’appr´ehender et d’exprimer plus ais´ement des algorithmes complexes `a mettre en œuvre dans un langage g´en´eraliste. Fournir des constructions de haut niveau est un moyen de donner plus de confiance `a l’utilisateur dans le code r´esultant : les algorithmes sont exprim´es plus formellement et il est donc plus facile de raisonner dessus `a des fins de v´erification du logiciel. Un autre avantage d’une approche reposant sur des constructions d´edi´ees r´eside dans la r´eduction des coˆuts de d´eveloppement : l’usage de g´en´erateurs de code permet de r´eduire la quantit´e de travail et le temps par rapport `a un d´eveloppement manuel. Contributions Dans ce contexte, la contribution de cette th`ese comprend trois volets principaux : Transformation de mod`eles par r´e´ecriture : Nous avons d´evelopp´e une m´ethode de transformation de mod`eles par r´e´ecriture de termes. Pour cela, nous op´erons une transformation permettant de manipuler un mod`ele sous la forme d’un terme alg´ebrique. Nous nous appuyons ensuite sur les strat´egies de r´e´ecriture du langage Tom pour mettre en œuvre la m´ethode de transformation. Cette m´ethode se d´eroule en deux temps : nous effectuons d’abord une transformation par parties qui fournit des r´esultats partiels, puis3 nous r´esolvons ces r´esultats interm´ediaires pour former le mod`ele cible r´esultant. Nous avons donc ´etendu le langage Tom en proposant un ˆılot formel d´edi´e pour transformer les mod`eles. Ce nouvel ˆılot impl´emente notre m´ethode de transformation par r´e´ecriture. Repr´esentation alg´ebrique de mod`eles : Pour transformer un mod`ele dans notre contexte de r´e´ecriture de termes, il est n´ecessaire d’op´erer au pr´ealable un changement d’espace technologique. Pour ce faire, nous proposons un outil permettant de donner une vue alg´ebrique d’un mod`ele. Il traduit un m´etamod`ele donn´e en une signature alg´ebrique int´egrable dans notre environnement Tom. Tra¸cabilit´e d’une transformation de mod`eles : Afin de r´epondre aux exigences du processus de qualification, nous avons travaill´e sur la tra¸cabilit´e des transformations et avons propos´e une tra¸cabilit´e de sp´ecification. Nous l’avons impl´ement´ee par un ˆılot formel d´edi´e permettant d’ajouter une forme de tra¸cabilit´e au sein d’un langage g´en´eraliste tel que Java. Durant ce travail de th`ese, nous nous sommes attel´es `a d´evelopper des outils op´erationnels impl´ementant notre travail. Nous avons toujours gard´e `a l’esprit qu’ils doivent pouvoir ˆetre aussi utilis´es par des utilisateurs ext´erieurs en vue d’un usage dans un cadre industriel. Nous avons donc exp´eriment´e et am´elior´e nos outils afin de leur permettre un passage `a l’´echelle. De plus, tout ce que nous avons d´evelopp´e est disponible librement et gratuitement sur le site du projet Tom. L’ensemble de nos exp´eriences reposant sur du code ouvert document´e ainsi que sur des mod`eles diffus´es librement, cela assure leur reproductibilit´e par un utilisateur averti. Cet aspect d’ouverture et de diffusion libre des r´esultats et des donn´ees s’inscrit dans le mouvement de l’open science, qui est indispensable `a une recherche v´erifiable et reproductible. Nous posons ainsi les conditions id´eales pour tout utilisateur souhaitant tester, v´erifier, utiliser, modifier et ´etendre nos travaux. Plan de la th`ese La suite de ce document se d´ecompose en huit chapitres r´epartis dans deux grandes parties. La premi`ere consiste en un ´etat de l’art de trois chapitres, traitant trois th´ematiques li´ees au contexte de cette th`ese. La seconde constitue les contributions de ce travail de th`ese. Nous r´esumons bri`evement chaque chapitre. Conseils et guide de lecture : Chaque chapitre de la premi`ere partie peut ˆetre lu ind´ependamment des autres. Les chapitres 4 et 5 expliquent le fond du travail de th`ese, tandis que les chapitres 6, 7 et 8 sont plus techniques. Le chapitre 6 d´ecrit les travaux d’impl´ementation des deux chapitres pr´ec´edents. Le chapitre 7 illustre l’utilisation des outils appliqu´es sur deux cas d’´etude. Le chapitre 8 comprend des r´esultats exp´erimentaux et donne des perspectives d’´evolution technique de nos outils. Partie I : Etat de l’art ´ Les trois chapitres composant l’´etat de l’art traitent de la r´e´ecriture et du langage Tom 1, des transformations de mod`eles 2 ainsi que de la v´erification du logiciel 3. Chapitre 1 – Un langage bas´e sur la r´e´ecriture : Tom Dans ce chapitre, nous donnons le cadre formel de la r´e´ecriture et d´efinissons toutes les notions importantes sous-jacentes au langage Tom. Nous le d´ecrivons ensuite et d´etaillons les diff´erentes constructions le composant. Nous nous appuyons sur des exemples simples pour les illustrer. Ce chapitre peut constituer un manuel court du langage Tom. Chapitre 2 – Transformations de mod`eles Ce chapitre donne le cadre de la mod´elisation et des transformations de mod`eles. Nous donnons une taxonomie des transformations qui se r´epartissent selon les crit`eres li´es aux4 Introduction m´etamod`eles et aux changements de niveau d’abstraction. Nous expliquons aussi quelles sont les approches principales pour transformer des mod`eles et quels sont les outils existants. Chapitre 3 – V´erification du logiciel Ce chapitre d´ecrit le contexte de la v´erification du logiciel et plus particuli`erement celui de la qualification et de la certification. C’est dans ce contexte que s’inscrit notre travail de th`ese. Partie II : Contributions La seconde partie regroupe les contributions de ce travail de th`ese, d´ecoup´ees en cinq chapitres r´esum´es ci-apr`es. Chapitre 4 – Transformations de mod`eles par r´e´ecriture Dans ce chapitre, nous exposons notre approche de transformation de mod`eles dans notre environnement utilisant la r´e´ecriture. Elle consiste `a repr´esenter des mod`eles sous la forme de termes en op´erant un changement d’espace technologique, puis `a effectuer une transformation par parties du mod`ele source. Chaque partie est transform´ee sans notion d’ordre grˆace `a une strat´egie de r´e´ecriture. L’ensemble des transformations partielles est suivi d’une phase de r´esolution du r´esultat partiel et produit le mod`ele cible. Chapitre 5 – Sp´ecification et tra¸cabilit´e des transformations Dans ce chapitre, nous exprimons la tra¸cabilit´e d’une transformation de mod`ele exig´ee par le processus de qualification. Elle consiste `a lier les sources aux cibles de la transformation en fonction de la sp´ecification. Chapitre 6 – Outils pour exprimer une transformation de mod`eles en Tom Dans ce chapitre, nous d´etaillons les outils d´evelopp´es durant cette th`ese pour la mise en œuvre des m´ecanismes expliqu´es dans les chapitres 4 et 5. Nous expliquons donc comment nous op´erons le changement d’espace technologique, en quoi consiste le nouvel ˆılot formel du langage Tom pour exprimer une transformation de mod`eles. Nous d´ecrivons l’impl´ementation au sein du projet Tom. Chapitre 7 – Etudes de cas : illustration et utilisation du langage ´ Dans ce chapitre, nous illustrons l’utilisation de nos outils sur deux ´etudes de cas : SimplePDLToPetriNet et l’aplatissement d’une hi´erarchie de classe. La premi`ere ´etude permet de d´etailler le processus complet d’´ecriture. L’´etude de la seconde transformation a pour but de montrer les points d’am´elioration de nos outils et d’ouvrir des perspectives de recherche et de d´eveloppement suite `a ce travail. Chapitre 8 – R´esultats exp´erimentaux Ce chapitre est compos´e de r´esultats exp´erimentaux pour donner une premi`ere ´evaluation de nos outils. Nous les avons test´es sur des mod`eles de tailles importantes afin de les pousser `a leurs limites en termes de performances et de valider leur potentiel usage dans un cadre industriel. Nous d´ecrivons aussi l’´evolution de nos outils suite aux premi`eres exp´eriences et nous tirons certaines conclusions.Premi`ere partie Etat de l’art ´ 5Chapitre 1 Un langage bas´e sur la r´e´ecriture : Tom Dans ce chapitre, nous abordons les notions ´el´ementaires utiles `a la lecture de ce document. Nous pr´esentons d’abord la r´e´ecriture de termes, puis nous d´ecrivons le langage Tom [MRV03, BBK+07] et nous terminons par les ancrages formels. 1.1 R´e´ecriture 1.1.1 Signature alg´ebrique et termes Cette section traite des notions de base concernant les alg`ebres de termes du premier ordre. D´efinition 1 (Signature). Une signature F est un ensemble fini d’op´erateurs (ou symboles de fonction), dont chacun est associ´e `a un entier naturel par la fonction d’arit´e, ar : F → N. Fn d´esigne le sous-ensemble de symboles d’arit´e n, c’est-`a-dire Fn = {f ∈ F | ar(f) = n}. L’ensemble des constantes est d´esign´e par F0. On classifie parfois les termes selon leur type dans des sortes. On parle alors de signature multi-sort´ee. D´efinition 2 (Signature alg´ebrique multi-sort´ee). Une signature multi-sort´ee est un couple (S, F) o`u S est un ensemble de sortes et F est un ensemble d’op´erateurs sort´es d´efini par F = S S1,...,Sn,S∈S FS1,...,Sn,S. Le rang d’un symbole de fonction f ∈ FS1,...,Sn,S not´e rank(f) est d´efini par le tuple (S1,. . . ,Sn,S) que l’on note souvent f : S1 × . . . × Sn → S D´efinition 3 (Terme). Etant donn´e un ensemble infini d´enombrable de variables ´ X et une signature F, on d´efinit l’ensemble des termes T (F, X ) comme le plus petit ensemble tel que : — X ⊆ T (F, X ) : toute variable de X est un terme de T (F, X ); — pour tous t1, . . . , tn ´el´ements de T (F, X ) et pour tout op´erateur f ∈ F d’arit´e n, le terme f(t1, . . . , tn) est un ´el´ement de T (F, X ). Pour tout terme t de la forme f(t1, . . . , tn), le symbole de tˆete de t, not´e symb(t) est, par d´efinition, l’op´erateur f. Un symbole de fonction dont l’arit´e est variable est appel´e op´erateur variadique, c’est-`a-dire qu’il prend un nombre arbitraire d’arguments. D´efinition 4 (Variables d’un terme). L’ensemble Var(t) des variables d’un terme t est d´efini inductivement comme suit : 78 Chapitre 1. Un langage bas´e sur la r´e´ecriture : Tom — Var(t) = ∅, pour t ∈ F0 ; — Var(t) = {t}, pour t ∈ X ; — Var(t) = Sn i=1 Var(ti), pour t = f(t1, . . . , tn). On note souvent a, b, c, . . . les constantes et x, y, z, . . . les variables. On repr´esente les termes sous forme arborescente. Par exemple, on peut repr´esenter le terme f(x, g(a)) comme dans la figure 1.1 : f x g a Figure 1.1 – Exemple de repr´esentation arborescente d’un terme. D´efinition 5 (Terme clos). Un terme t est dit clos s’il ne contient aucune variable, c’est-`adire si Var(t) = ∅. On note T (F) l’ensemble des termes clos. Chaque nœud d’un arbre peut ˆetre identifi´e de mani`ere unique par sa position. D´efinition 6 (Position). Une position dans un terme t est repr´esent´ee par une s´equence ω d’entiers naturels, d´ecrivant le chemin de la racine du terme jusqu’`a un nœud t|ω du terme. Un terme u a une occurrence dans t si u = t|ω pour une position ω dans t. On notera Pos(t) l’ensemble des positions d’un terme t et t[t 0 ]ω le remplacement du sousterme de t `a la position ω par t 0 . Par exemple, la figure 1.2 illustre la notation des positions pour le terme t = f(x, g(a)). On obtient l’ensemble des positions Pos(t) = {, 1, 2, 21} ce qui correspond respectivement aux sous-termes t| = f(x, g(a)), t|1 = x, t|2 = g(a) et t|21 = a. f x g a ω =  ω = 1 ω = 2 ω = 21 Figure 1.2 – Notation des positions dans un terme. 1.1.2 Filtrage Une substitution est une op´eration de remplacement, uniquement d´efinie par une fonction des variables vers les termes clos. D´efinition 7 (Substitution). Une substitution σ est une fonction de X vers T (F), not´ee lorsque son domaine Dom(σ) est fini, σ = {x1 7→ t1, . . . , xk 7→ tk}. Cette fonction s’´etend de mani`ere unique en un endomorphisme σ 0 : T (F, X ) → T (F, X ) sur l’alg`ebre des termes, qui est d´efini inductivement par : — σ 0 (x) =  σ(x) si x ∈ Dom(σ) x sinon — σ 0 (f(t1, . . . , tn)) = f(σ 0 (t1), . . . , σ0 (tn)) pour tout symbole de fonction f ∈ Fn.1.1. R´e´ecriture 9 D´efinition 8 (Filtrage). Etant donn´es un motif p ´ ∈ T (F, X ) et un terme clos t ∈ T (F), p filtre t, not´e p << t, si et seulement s’il existe une substitution σ telle que σ(p) = t : p << t ⇔ ∃σ, σ(p) = t On parle de filtrage unitaire lorsqu’il existe une unique solution `a l’´equation de filtrage. Si plusieurs solutions existent, le filtrage est non unitaire. Le filtrage peut aussi ˆetre modulo une th´eorie ´equationnelle. Cela signifie que l’on a associ´e une th´eorie ´equationnelle au probl`eme de filtrage. D´efinition 9 (Filtrage modulo une th´eorie ´equationnelle). Etant donn´es une th´eorie ´equa- ´ tionnelle E, un motif p ∈ T (F, X ) et un terme clos t ∈ T (F), p filtre t modulo E, not´e p << E t, si et seulement s’il existe une substitution σ telle que σ(p) =E t, avec =E l’´egalit´e modulo E : p << E t ⇔ ∃σ, σ(p) =E t Dans la suite de cette section, nous allons expliquer ce concept, donner des exemples de th´eories ´equationnelles et illustrer notre propos. Une paire de termes (l, r) est appel´ee ´egalit´e, axiome ´equationnel ou ´equation selon le contexte, et est not´ee (l = r). Une th´eorie ´equationnelle peut ˆetre d´efinie par un ensemble d’´egalit´es. Elle d´efinit une classe d’´equivalence entre les termes. Dans la pratique, les th´eories ´equationnelles les plus communes sont l’associativit´e, la commutativit´e et l’´el´ement neutre (ainsi que leurs combinaisons). D´efinition 10 (Op´erateur associatif). Un op´erateur binaire f est associatif si ∀x, y, z ∈ T (F, X ), f(f(x, y), z) = f(x, f(y, z)). Par exemple, l’addition et la multiplication sont associatives sur l’ensemble des r´eels R : ((x + y) + z) = (x + (y + z)) et ((x × y) × z)) = (x × (y × z)). En revanche, la soustraction sur R n’est pas associative : ((x − y) − z) 6= (x − (y − z)). D´efinition 11 (Op´erateur commutatif). Un op´erateur binaire f est commutatif si ∀x, y ∈ T (F, X )f(x, y) = f(y, x). Par exemple, l’addition et la multiplication sont commutatives sur R, ainsi x + y = y + x et x × y = y × x. Ce qui n’est pas le cas de la soustraction sur R, en effet x − y 6= y − x. D´efinition 12 (El´ement neutre) ´ . Soit un op´erateur binaire f et x ∈ T (F, X ), la constante e ∈ T (F) est : — neutre `a gauche pour f si f(e, x) = x ; — neutre `a droite pour f si f(x, e) = x ; — neutre si elle est neutre `a gauche et neutre `a droite pour f. Pour illustrer cette notion d’´el´ement neutre, examinons la constante 0 avec l’addition sur l’ensemble des r´eels R : — 0 + x = x, 0 est donc neutre `a gauche pour l’addition ; — x + 0 = x, 0 est donc neutre `a droite pour l’addition ; — on en d´eduit que 0 est neutre pour l’addition sur R. On note g´en´eralement A, U et C les th´eories ´equationnelles engendr´ees respectivement par l’´equation d’associativit´e, l’´equation de neutralit´e et celle de commutativit´e. On note AU la th´eorie engendr´ee par les ´equations d’associativit´e et de neutralit´e. La th´eorie associative est associ´ee aux op´erateurs binaires. Pour des raisons techniques, elle est souvent associ´ee `a une syntaxe variadiques dans les langages de programmation fond´es sur la r´e´ecriture. Par exemple, l’op´erateur variadique list est simul´e par l’op´erateur nil d’arit´e nulle, ainsi que par l’op´erateur binaire cons. Cela permet d’´ecrire que le terme10 Chapitre 1. Un langage bas´e sur la r´e´ecriture : Tom list(a, b, c) est ´equivalent au terme list(list(a, b), c), et qu’ils peuvent ˆetre repr´esent´es par cons(a, cons(b, cons(c, nil))). On peut alors d´efinir des op´erations modulo une th´eorie ´equationnelle : on parlera de filtrage ´equationnel lorsque le filtrage sera associ´e `a une telle th´eorie. Pour illustrer cette notion, prenons deux exemples simples de filtrage. Exemple 1 : Le filtrage associatif avec ´el´ement neutre (AU) — aussi appel´e filtrage de liste — est un probl`eme bien connu en r´e´ecriture. Il permet d’exprimer facilement des algorithmes manipulant des listes. En consid´erent X1∗ et X2∗ comme ides variables repr´esentant 0 ou plusieurs ´el´ements d’une liste, le probl`eme de filtrage list(X1∗, x, X2∗)  list(a, b, c) admet trois solutions : σ1 = {x → a}, σ2 = {x → b} et σ3 = {x → c}. Exemple 2 : Illustrons le filtrage associatif-commutatif (AC) et l’addition, dont les axiomes d’associativit´e et commutativit´e sont les suivants : — ∀x, y, plus(x, y) = plus(y, x) ; — ∀x, y, plus(x, plus(y, z)) = plus(plus(x, y), z). Le probl`eme de filtrage plus(x, y)  plus(a, b) pr´esente deux solutions distinctes modulo AC : σ1 = {x → a, y → b} et σ2 = {x → b, y → a}. 1.1.3 R´e´ecriture En r´e´ecriture, on oriente des ´egalit´es que l’on appelle des r`egles de r´e´ecriture et qui d´efi- nissent un calcul. D´efinition 13 (R`egle de r´e´ecriture). Une r`egle de r´e´ecriture est un couple (l,r) de termes dans T (F, X ), not´ee l → r. l est appel´e membre gauche de la r`egle, et r membre droit. Un exemple de r`egle de r´e´ecriture est l’addition de n’importe quel entier x avec 0 : x + 0 → x Un autre exemple un peu plus complexe de r`egle de r´e´ecriture est la distributivit´e de la multiplication par rapport `a l’addition dans un anneau, comme illustr´e par la figure 1.3. × x + y z −→ + × x y × x z Figure 1.3 – Exemple de r`egle de r´e´ecriture : distributivit´e de la multiplication par rapport `a l’addition dans un anneau, `a savoir x × (y + z) → (x × y) + (x × z). D´efinition 14 (Syst`eme de r´e´ecriture). Un syst`eme de r´e´ecriture sur les termes est un ensemble de r`egles de r´e´ecriture (l,r) tel que : — les variables du membre droit de la r`egle font partie des variables du membre gauche (Var(r) ⊆ Var(l)) ; — le membre gauche d’une r`egle n’est pas une variable (l /∈ X ). D´efinition 15 (R´e´ecriture). Un terme t ∈ T (F, X ) se r´e´ecrit en t 0 dans un syst`eme de r´e´ecriture R, ce que l’on note t →R t 0 , s’il existe : — une r`egle l → r ∈ R ;1.1. R´e´ecriture 11 — une position ω dans t; — une substitution σ telle que t|ω = σ(l) et t 0 = t[σ(r)]ω. On appelle radical le sous-terme t|ω. Pour une relation binaire →, on note →∗ sa fermeture transitive et r´eflexive. La fermeture transitive, r´eflexive et sym´etrique de → — qui est alors une relation d’´equivalence — est not´ee ↔∗ . D´efinition 16 (Forme normale). Soit → une relation binaire sur un ensemble T. Un ´el´ement t ∈ T est r´eductible par → s’il existe t 0 ∈ T tel que t → t 0 . Dans le cas contraire, on dit qu’il est irr´eductible. On appelle forme normale de t tout ´el´ement t 0 irr´eductible de T tel que t →∗ t 0 . Cette forme est unique. Deux propri´et´es importantes d’un syst`eme de r´e´ecriture sont la confluence et la terminaison. Lorsque l’on souhaite savoir si deux termes sont ´equivalents, on cherche `a calculer leurs formes normales et `a v´erifier si elles sont ´egales. Cela n’est possible que si la forme normale existe et qu’elle est unique. Une forme normale existe si → termine, et son unicit´e est alors assur´ee si → est confluente, ou si elle v´erifie la propri´et´e de Church-Rosser, qui est ´equivalente. D´efinition 17 (Terminaison). Une relation binaire → sur un ensemble T est dite terminante s’il n’existe pas de suite infinie (ti)i≥1 d’´el´ements de T telle que t1 → t2 → · · ·. D´efinition 18 (Confluence). Soit une relation binaire → sur un ensemble T. (a) → est confluente si et seulement si : ∀t, u, v (t →∗ u et t →∗ v) ⇒ ∃w,(u →∗ w et v →∗ w) (b) → v´erifie la propri´et´e de Church-Rosser si et seulement si : ∀u, v, u ↔∗ v ⇒ ∃w,(u →∗ w et v →∗ w) (c) → est localement confluente si et seulement si : ∀t, u, v (t → u et t → v) ⇒ ∃w,(u →∗ w et v →∗ w) La figure 1.4 illustre ces propri´et´es. t u v w (a) Confluence ∗ ∗ ∗ ∗ u v w (b) Church-Rosser ∗ ∗ ∗ t u v w (c) Confluence locale ∗ ∗ Figure 1.4 – Propri´et´es sur les relations binaires. 1.1.4 Strat´egies de r´e´ecriture En r´e´ecriture, on applique habituellement de mani`ere exhaustive toutes les r`egles sur le terme pour calculer sa forme normale, c’est-`a-dire que l’on applique toutes les r`egles jusqu’`a ce qu’aucune r`egle ne puisse plus ˆetre appliqu´ee. Il est cependant courant d’´ecrire des syst`emes de r´e´ecriture ne terminant pas ou n’´etant pas confluents. La m´ethode d’application des r`egles adopt´ee prend donc de l’importance, car elle a, dans ce cas, un effet sur le r´esultat. Il est par12 Chapitre 1. Un langage bas´e sur la r´e´ecriture : Tom cons´equent important d’avoir un contrˆole sur l’application des r`egles du syst`eme de r´e´ecriture. C’est l’objet du concept de strat´egie que nous allons d´ecrire dans cette section. Illustrons ce probl`eme par un exemple o`u l’on consid`ere le syst`eme de r´e´ecriture suivant avec la signature {a, f}, a ´etant d’arit´e 0 et f d’arit´e 1 :  f(x) → f(f(x)) (r1) f(a) → a (r2) Sans aucune pr´ecision sur la mani`ere d’appliquer les r`egles, nous remarquons qu’il existe une suite infinie de pas de r´e´ecriture partant de f(a) si l’on applique toujours la r`egle r1 : f(a) r1 −→ f(f(a)) r1 −→ f(f(f(a))) r1 −→ · · · Le calcul ne termine pas. Si l’on applique les r`egles de r´e´ecriture r1 et r2 diff´eremment, nous constatons que f(a) se r´eduit en a : f(a) r1 −→ f(f(a)) r2 −→ f(a) r2 −→ a ↓ r2 a Cet exemple illustre clairement le fait que les r´esultats du calcul ne sont pas les mˆemes selon la m´ethode d’application des r`egles. Pour avoir des calculs qui terminent, on pourrait alors adopter une strat´egie d’application des r`egles donnant la priorit´e `a la r`egle r2 : f(a) → a par rapport `a la r`egle r1 : f(x) → f(f(x)). Apr`es cette intuition de ce qu’est une strat´egie, nous pouvons donner des d´efinitions plus formelles des concepts li´es. La notion de syst`eme abstrait de r´eduction (Abstract Reduction System – ARS) [BKdV03] est une mani`ere abstraite de mod´eliser les calculs par transformations pas `a pas d’objets, ind´ependamment de la nature des objets qui sont r´e´ecrits. Un ARS peut se d´efinir comme un couple (T , →), o`u → est une relation binaire sur l’ensemble T . De l`a, [KKK+08] donne une repr´esentation des ARS sous forme de graphe et introduit le concept de strat´egie abstraite. D´efinition 19 (Syst`eme abstrait de r´eduction). Un syst`eme abstrait de r´eduction (ARS) est un graphe orient´e ´etiquet´e (O, S). Les nœuds O sont appel´es objets, les arˆetes orient´ees S sont appel´ees pas. Pour un ensemble de termes T (F, X ), le graphe (T (F, X ), S) est l’ARS correspondant `a un syst`eme de r´e´ecriture R. Les arˆetes correspondent `a des pas de r´e´ecriture de R et sont ´etiquet´ees par le nom des r`egles de R. D´efinition 20 (D´erivation). Soit un ARS A : 1. un pas de r´eduction est une arˆete ´etiquet´ee φ compl´et´ee de sa source a et de sa destination b. On note un pas de r´eduction a →φ A b, ou simplement a →φ b lorsqu’il n’y a pas d’ambigu¨ıt´e ; 2. une A-d´erivation (ou s´equence de T -r´eductions) est un chemin π dans le graphe A ; 3. lorsque cette d´erivation est finie, π peut s’´ecrire a0 →φ0 a1 →φ1 a2 · · · →φn−1 an et on dit que a0 se r´eduit en an par la d´erivation π = φ0φ1 . . . φn−1 ; not´ee aussi a0 →φ0φ1...φn−1 an ou simplement a0 →π an. n est la longueur de π ; (a) la source de π est le singleton {a0}, not´ee dom(π); (b) la destination de π est le singleton {an}, not´ee π[a0]. 4. une d´erivation est vide si elle n’est form´ee d’aucun pas de r´eduction. La d´erivation vide de source a est not´ee ida. D´efinition 21 (Strat´egie abstraite). Soit un ARS A : 1. une strat´egie abstraite est un sous-ensemble de toutes les d´erivations de A ; 2. appliquer la strat´egie ζ sur un objet a, not´e par ζ[a], est l’ensemble de tous les objets atteignables depuis a en utilisant une d´erivation dans ζ : ζ[a] = {π[a] | π ∈ ζ}. Lorsqu’aucune d´erivation dans ζ n’a pour source a, on dit que l’application sur a de la strat´egie a ´echou´e ;1.2. Le langage Tom 13 3. appliquer la strat´egie ζ sur un ensemble d’objets consiste `a appliquer ζ `a chaque ´el´ement a de l’ensemble. Le r´esultat est l’union de ζ[a] pour tous les a de l’ensemble d’objets ; 4. le domaine d’une strat´egie est l’ensemble des objets qui sont la source d’une d´erivation dans ζ : dom(ζ) = S δ∈ζ dom(δ); 5. la strat´egie qui contient toutes les d´erivations vides est Id = {ida | a ∈ O}. Concr`etement, on peut exprimer ces strat´egies de mani`ere d´eclarative grˆace aux langages de strat´egies que proposent la plupart des langages `a base de r`egles tels que Elan [Vit94, BKK+98, BKK+96], Stratego [VBT98, Vis01a], Maude [CELM96, CDE+02, CDE+11] et Tom, que nous allons pr´esenter dans la section suivante. Elan. Elan propose deux types de r`egles : les r`egles anonymes syst´ematiquement appliqu´ees (servant `a la normalisation de termes) et les r`egles ´etiquet´ees pouvant ˆetre d´eclench´ees `a la demande sous contrˆole d’une strat´egie. Le r´esultat de l’application d’une telle r`egle sur un terme est un multi-ensemble de termes, ce qui permet de g´erer le non-d´eterminisme. Elan a introduit la notion de strat´egie en proposant un langage de combinateurs permettant de composer les strat´egies et de contrˆoler leur application. Parmi ces combinateurs, on retiendra notamment l’op´erateur de s´equence, des op´erateurs de choix non-d´eterministes et des op´erateurs de r´ep´etition. Stratego. S’inspirant d’Elan, Stratego se concentre sur un nombre restreint de combinateurs ´el´ementaires, ainsi que sur leur combinaison. A ces combinateurs (s´equence, identit´e, ´echec, ` test, n´egation, choix d´eterministe et non-d´eterministe) sont ajout´es un op´erateur de r´ecursion (µ) et des op´erateurs permettant d’appliquer la strat´egie : sur le i `eme fils du sujet (i(s)), sur tous les sous-termes du sujet (All(s)), sur le premier fils du sujet sans ´echec (One(s)), sur tous les sous-termes du sujet sans ´echec (Some(s)). Grˆace `a ces op´erateurs, il est possible d’´elaborer des strat´egies de haut niveau telles que TopDown et BottomUp. Maude. L’approche de Maude est un peu diff´erente : le contrˆole sur l’application des r`egles s’op`ere grˆace `a la r´eflexivit´e du syst`eme [CM96, CM02]. Les objets du langage Maude ayant une repr´esentation meta, il est possible d’utiliser un op´erateur (meta-apply) pour appliquer les r`egles. Cet op´erateur ´evalue les ´equations, normalise le terme, et retourne la metarepr´esentation du terme r´esultant de l’´evaluation. On peut contrˆoler l’application des r`egles de r´e´ecriture par un autre programme d´efini par r´e´ecriture. Pour des raisons pratiques, des travaux ont ´et´e men´es plus r´ecemment [MOMV05, EMOMV07] pour offrir un langage de strat´egies plus proche de ce que Elan, Stratego et Tom proposent. Tom. A partir du concept de strat´egie et en s’inspirant de ces langages, ` Tom impl´emente lui aussi un langage de strat´egies [BMR08, BMR12]. Il est fond´e sur des strat´egies ´el´ementaires (Identity et Fail), sur des combinateurs de composition (Sequence, Recursion —µ—, Choice, Not, IfThenElse) et de travers´ee (All, One, Up et Omega). De ces combinateurs, `a l’image de Stratego, des strat´egies compos´ees peuvent ˆetre ´elabor´ees (Try, Repeat, Innermost, etc.). Nous reviendrons sur les strat´egies de Tom dans la section suivante, en particulier sur leur utilisation concr`ete au sein du langage. 1.2 Le langage Tom Tom [MRV03, BBK+07] est un langage con¸cu pour enrichir des langages g´en´eralistes de fonctionnalit´es issues de la r´e´ecriture et de la programmation fonctionnelle. Il ne s’agit pas d’un langage stand-alone : il est l’impl´ementation du concept des « ˆılots formels » (formal islands) [BKM06] qui sont ajout´es au sein de programmes ´ecrits dans un langage hˆote. Les14 Chapitre 1. Un langage bas´e sur la r´e´ecriture : Tom constructions Tom sont transform´ees et compil´ees vers le langage hˆote. Parmi les fonctionnalit´es apport´ees par Tom, on compte le filtrage de motif (pattern-matching), les r`egles de r´e´ecriture, les strat´egies, ainsi que les ancrages alg´ebriques (mappings). Dans la suite de cette section, nous d´ecrirons le langage Tom en illustrant ses fonctionnalit´es et constructions par des exemples simples. Sauf indication contraire, les extraits de code hˆote seront en Java. Pour une documentation compl`ete et d´etaill´ee, le lecteur int´eress´e pourra se r´ef´erer au manuel disponible en t´el´echargement [BBB+09] ou directement en ligne [BB+13]. Les outils sont tous accessibles via le site officiel du projet Tom 1 . 1.2.1 Signature alg´ebrique Tom permet `a l’utilisateur de sp´ecifier des signatures alg´ebriques multi-sort´ees via l’outil Gom [Rei07]. Le langage Gom permet de d´ecrire une structure de donn´ees et d’en g´en´erer l’impl´ementation typ´ee en Java. Le listing 1.1 illustre une d´efinition de signature Gom : 1 module Peano 2 abstract syntax 4 Nat = zero() 5 | suc(n:Nat) Listing 1.1 – Signature alg´ebrique Gom pour les entiers de Peano. Un module Gom est compos´e d’un pr´eambule comportant un nom — Peano dans cet exemple — pr´ec´ed´e du mot-clef module (ligne 1). Le d´ebut de la signature est annonc´e par le mot-clef abstract syntax (ligne 2). Cet exemple ´etant extrˆemement simple, le pr´eambule est compos´e uniquement de ces deux lignes. Pour un module plus complexe qui utiliserait des types d´efinis dans une autre signature, la clause imports suivie des signatures `a importer peut ˆetre intercal´ee entre les deux clauses pr´ec´edentes. Le projet Tom fournit notamment une biblioth`eque de signatures pour les types primitifs (types builtin) tels que les entiers (int), les caract`eres (char), les flottants (float) et les chaˆınes de caract`eres (String). La signature en elle-mˆeme est compos´ee d’un ensemble de sortes — Nat dans notre exemple — ayant des constructeurs — zero et suc ici. Ce g´en´erateur propose un typage fort au niveau de la structure de donn´ees Java g´en´er´ee, ce qui garantit que les objets cr´e´es sont conformes `a la signature multi-sort´ee. Un second aspect int´eressant de cet outil est le fait qu’il offre le partage maximal [AC93], rendant les structures g´en´er´ees tr`es efficaces en temps (tests d’´egalit´e en temps constant) et en espace. Les classes g´en´er´ees peuvent ˆetre modifi´ees par l’interm´ediaire de la fonctionnalit´e de hooks. Ce m´ecanisme permet d’ajouter des blocs de code Java aux classes g´en´er´ees (par exemple, int´egration d’attributs invisibles au niveau alg´ebrique, mais manipulables par la partie Java de l’application) ou d’associer une th´eorie ´equationnelle telle que A, AC, ACU `a certains op´erateurs. Il est mˆeme possible de sp´ecifier cette th´eorie ´equationnelle par des r`egles de normalisation. Les termes construits sont ainsi toujours en forme normale. La signature est compil´ee en une impl´ementation Java ainsi qu’un ancrage permettant l’utilisation de cette structure dans les programmes Tom. Dans un premier temps, pour pr´esenter les constructions du langage Tom, nous ne nous pr´eoccuperons pas de ces ancrages ni de l’impl´ementation concr`ete Java. 1.2.2 Construction backquote « ‘ » La construction ‘ (backquote) permet de cr´eer la structure de donn´ees repr´esentant un terme alg´ebrique en allouant et initialisant les objets en m´emoire. Elle permet `a la fois de construire un terme et de r´ecup´erer la valeur d’une variable instanci´ee par le filtrage de motif. Ainsi, on peut construire des termes de type Nat de l’exemple pr´ec´edent avec des instructions 1. Voir http://tom.loria.fr/.1.2. Le langage Tom 15 backquote. L’instruction Tom+Java « Nat un = ‘suc(zero()); » d´eclare une variable un dont le type est Nat, ayant pour valeur le repr´esentant alg´ebrique suc(zero()). Un terme backquote peut aussi contenir des variables du langage hˆote, ainsi que des appels de fonctions. Ainsi, l’instruction Nat deux = ‘suc(un); permet de cr´eer le terme deux `a partir de un cr´e´e pr´ec´edemment. Le compilateur Tom n’analysant pas du tout le code hˆote, notons que nous supposons que la partie hˆote — un dans l’exemple — est conforme `a la signature alg´ebrique et que le terme est donc bien form´e. L’utilisation du backquote permet `a l’utilisateur de cr´eer un terme et de manipuler sa vue alg´ebrique sans se soucier de son impl´ementation concr`ete dans le langage hˆote. 1.2.3 Filtrage de motif Dans la plupart des langages g´en´eralistes tels que C ou Java, on ne trouve pas les notions de type alg´ebrique et de terme, mais uniquement celle de types de donn´ees compos´ees (structures C et objets Java). De mˆeme, la notion de filtrage de motif (pattern-matching) que l’on retrouve dans les langages fonctionnels tels que Caml ou Haskell n’existe g´en´eralement pas dans la plupart des langages imp´eratifs classiques. Le filtrage permet de tester la pr´esence de motifs (pattern) dans une structure de donn´ees et d’instancier des variables en fonction du r´esultat de l’op´eration de filtrage. Ces constructions sont apport´ees par Tom dans des langages g´en´eralistes. Il devient donc possible de filtrer des motifs dans Java. En outre, les constructions de filtrage de Tom ´etant plus expressives que dans Caml (notamment le filtrage ´equationnel et le filtrage non lin´eaire), il est possible de les employer aussi en son sein pour utiliser le filtrage ´equationnel. Le lex`eme %match introduit la construction de filtrage de Tom. Celle-ci peut ˆetre vue comme une g´en´eralisation de la construction habituelle switch-case que l’on retrouve dans beaucoup de langages g´en´eralistes. Cependant, plutˆot que de filtrer uniquement sur des entiers, des caract`eres, voire des chaˆınes de caract`eres, Tom filtre sur des termes. Les motifs permettent de discriminer et de r´ecup´erer l’information contenue dans la structure de donn´ees alg´ebrique sur laquelle on filtre. Dans le listing 1.2 suivant, nous reprenons l’exemple des entiers de Peano pour lesquels nous encodons l’addition avec Tom et Java. Pour ce premier exemple o`u les deux langages apparaissent en mˆeme temps, nous adoptons un marquage visuel pour d´esigner Java (noir) et Tom (gris). Cela permet de visualiser le tissage ´etroit entre le langage Tom et le langage hˆote dans lequel il est int´egr´e. Par la suite, le principe ´etant compris, nous n’adopterons plus ce code visuel. 1 Nat peanoPlus(Nat t1, Nat t2) { 2 %match(t1, t2) { 3 x, zero() -> { return ‘x; } 4 x, suc(y) -> { return ‘suc(peanoPlus(x,y)); } 5 } 6 } Listing 1.2 – Exemple d’utilisation du filtrage avec l’addition des entiers de Peano. Dans cet exemple, la fonction peanoPlus prend en arguments deux termes t1 et t2 de type Nat repr´esentant deux entiers de Peano, et retourne la somme des deux. Le calcul est op´er´e par filtrage en utilisant la construction %match : — elle prend un ou plusieurs arguments — deux dans notre exemple — entre parenth`eses ; — elle est compos´ee d’un ensemble de r`egles de la forme membre gauche -> {membre droit} ; — le membre gauche est compos´e du ou des motifs s´epar´es les uns des autres par une virgule ; — le membre droit est un bloc de code mixte (hˆote + Tom).16 Chapitre 1. Un langage bas´e sur la r´e´ecriture : Tom Dans notre exemple, le calcul de filtrage est le suivant : — si zero() filtre t2, alors le r´esultat de l’´evaluation de la fonction peanoPlus est x, instanci´e par t1 par filtrage ; — si suc(y) filtre t2, alors le symbole de tˆete du terme t2 est suc. Le sous-terme y est ajout´e `a x et le r´esultat de l’´evaluation de peanoPlus est donc suc(peanoPlus(x,y)). L’expression de la fonction peanoPlus est donn´ee par filtrage et d´efinit une fonction Java qui peut ˆetre utilis´ee comme toute autre fonction Java dans le programme. Notons cette particularit´e qu’a le langage Tom de compl`etement s’int´egrer au langage hˆote sans pour autant ˆetre intrusif. Ainsi, le compilateur Tom n’analyse que le code Tom (parties gris´ees dans le listing 1.2), les instructions hˆotes n’´etant pas examin´ees et ne fournissant aucune information au compilateur. Les instructions Tom sont traduites vers le langage hˆote et remplac´ees en lieu et place, sans modification du code hˆote existant. Une deuxi`eme particularit´e des constructions de filtrage du langage Tom est li´ee `a la composition des membres droits des r`egles : plutˆot qu’ˆetre de simples termes, il s’agit en fait d’instructions du langage hˆote qui sont ex´ecut´ees lorsqu’un filtre est trouv´e. Si aucune instruction du langage hˆote ne rompt le flot de contrˆole, toutes les r`egles peuvent potentiellement ˆetre ex´ecut´ees. Pour interrompre ce flot lorsqu’un filtre est trouv´e, il faut utiliser les instructions ad-hoc du langage hˆote, telles que break ou return, comme dans le listing 1.2. Filtrage associatif. Dans le cas d’un filtrage non unitaire (filtrage pour lequel il existe plusieurs solutions, voir 1.1.2), l’action est ex´ecut´ee pour chaque filtre solution. Le filtrage syntaxique ´etant unitaire, il n’est pas possible d’exprimer ce comportement. Le langage Tom dispose de la possibilit´e d’op´erer du filtrage associatif avec ´el´ement neutre (ou filtrage de liste, not´e AU dans la section 1.1.2) qui n’est pas unitaire et qui permet d’exprimer ais´ement des algorithmes op´erant du filtrage sur des listes. Il est ainsi possible de d´efinir des op´erateurs variadiques (op´erateurs d’arit´e variable, par exemple les op´erateurs de listes), comme nous l’avons vu dans la section pr´ec´edente (1.1.2). Dans le listing 1.3 suivant, nous reprenons notre exemple des entiers de Peano que nous augmentons d’un nouveau constructeur, concNat de sorte NatList et dont les sous-termes sont de type Nat. 1 module Peano 2 abstract syntax 4 Nat = zero() 5 | suc(n:Nat) 7 NatList = concNat(Nat*) Listing 1.3 – Signature alg´ebrique Gom avec op´erateur variadique pour les entiers de Peano. L’op´erateur concNat peut ˆetre vu comme un op´erateur de concat´enation de listes de Nat : concNat() repr´esente la liste vide d’entiers naturels, concNat(zero()) la liste ne contenant que zero() et concNat(zero(),suc(zero()),suc(suc(zero()))) la liste contenant trois entiers naturels : 0, 1 et 2. La liste vide est l’´el´ement neutre. Tom distingue syntaxiquement les variables de filtrage repr´esentant un ´el´ement — par exemple x dans le listing 1.2 — et les variables repr´esentant une sous-liste d’une liste existante en ajoutant le caract`ere *. Le filtrage associatif permet d’op´erer une it´eration sur les ´el´ements d’une liste comme l’illustre l’exemple du listing 1.4 : 1 public void afficher(NatList liste) { 2 int i = 0; 3 %match(liste) { 4 concNat(X1*,x,X2*) -> { 5 i = ‘X1.length();1.2. Le langage Tom 17 6 System.out.println("liste("+i+") = " + ‘x); 7 } 8 } 9 } Listing 1.4 – Filtrage associatif. Dans cet exemple, liste est une liste d’entiers naturels, de type NatList impl´ement´e par le type Java NatList. Nous souhaitons afficher ces entiers avec leur position dans la liste. L’action est ex´ecut´ee pour chaque filtre trouv´e, et les variables de listes X1* et X2* sont instanci´ees pour chaque sous-liste pr´efixe et suffixe de la liste liste. X1 correspond `a un objet Java de type NatList, la m´ethode length() retournant la longueur de la liste peut donc ˆetre utilis´ee pour obtenir l’indice de l’´el´ement x. L’´enum´eration s’op`ere tant que le flot d’ex´ecution n’est pas interrompu. Dans notre exemple, nous nous contentons d’afficher l’´el´ement et sa position. L’ex´ecution de la proc´edure afficher sur l’entr´ee liste = ‘conc(zero(), zero(), suc(suc(zero())), zero()) donne : liste(0) = zero() liste(1) = zero() liste(2) = suc(suc(zero())) liste(3) = zero() Le langage Tom offre aussi la possibilit´e de proc´eder `a du filtrage non-lin´eaire (motifs pour lesquels une mˆeme variable apparaˆıt plusieurs fois). Le listing 1.5 ci-apr`es illustre ce m´ecanisme : dans la fonction supprimerDoublon, la variable x apparaˆıt `a plusieurs reprises dans le motif. 1 public NatList supprimerDoublon(NatList liste) { 2 %match(liste) { 3 concNat(X1*,x,X2*,x,X3*) -> { 4 return ‘supprimerDoublon(concNat(X1*,x,X2*,X3*)); 5 } 6 } 7 return liste; 8 } Listing 1.5 – Filtrage associatif non lin´eaire. Parmi les notations disponibles dans le langage, certaines sont tr`es couramment utilis´ees et apparaˆıtront dans les extraits de code de ce document. Nous les illustrons dans le listing 1.6 dont le but est d’afficher un sous-terme de la liste liste ayant la forme suc(suc(y)), ainsi que sa position dans la liste, s’il existe : 1 public void chercher(NatList liste) { 2 %match(liste) { 3 concNat(X1*,x@suc(suc(_)),_*) -> { 4 System.out.println(‘x + " trouv´e, en position " + ‘X1.length()); 5 } 6 } 7 } Listing 1.6 – Notations : alias et variable anonyme. Les notations _ et _* pour les sous-listes d´esignent des variables dites anonymes : c’est-`adire que leur valeur ne peut ˆetre utilis´ee dans le bloc action de la r`egle. La notation @ permet de cr´eer des alias : ainsi, on peut nommer des sous-termes obtenus par filtrage. L’alias permet de v´erifier qu’un motif filtre — suc(suc(_)) dans notre exemple — tout en instanciant une variable — x — avec la valeur de ce sous-terme. Si on applique la proc´edure chercher18 Chapitre 1. Un langage bas´e sur la r´e´ecriture : Tom `a l’entr´ee pr´ec´edente d´efinie comme liste = ‘conc(zero(), zero(), suc(suc(zero())), zero()), on obtient le r´esultat suivant : suc(suc(zero())) trouv´e, en position 2 1.2.4 Notations implicite et explicite Lorsque l’on ´ecrit un pattern dans le membre gauche d’une r`egle, il est possible d’´ecrire l’op´erateur et ses champs de deux mani`eres. Ces derniers ´etant nomm´es, plutˆot qu’´ecrire l’op´erateur avec tous ses arguments (notation explicite), on peut utiliser leurs noms dans le motif pour expliciter des sous-termes particuliers et en omettre d’autres. Ces derniers sont alors ignor´es lors du filtrage. Cette notation est dite implicite et s’utilise via les lex`emes [ et ]. Il existe ´egalement une notation `a base de contraintes qui peut rendre l’´ecriture implicite plus naturelle dans certains cas. Consid´erons un exemple simple pour illustrer ces deux notations : si on d´efinit les personnes comme des termes construits en utilisant l’op´erateur Personne, d’arit´e 3 et de type Personne, ayant les arguments nomm´es nom et prenom de type « chaˆıne de caract`eres », et age de type entier, les trois fonctions suivantes du listing 1.7 sont ´equivalentes : 1 %gom() { 2 module Contacts 3 abstract syntax 4 Personne = Personne(nom:String, prenom:String, age:int) 5 } 6 7 public boolean peutConduireExplicite(Personne p) { 8 %match(p) { 9 Personne(_,_,a) -> { return (‘a>18); } 10 } 11 } 12 13 public boolean peutConduireImplicite(Personne p) { 14 %match(p) { 15 Personne[age=a] -> { return (‘a>18); } 16 } 17 } 18 19 public boolean peutConduireImplicite2(Personne p) { 20 %match(p) { 21 Personne[age=a] && a>18 -> { return true; } 22 } 23 return false; 24 } Listing 1.7 – Illustration des notations explicite et implicite. Outre l’ind´eniable gain en lisibilit´e du code qu’elle apporte de par l’utilisation des noms, la notation implicite am´eliore la maintenabilit´e du logiciel d´evelopp´e. En effet, dans le cas d’une extension de la signature (ajout d’un champ numTelephone, par exemple), l’usage de la notation explicite impose d’ajouter un _ dans toutes les r`egles o`u l’op´erateur Personne est utilis´e. Dans notre exemple, la premi`ere fonction — peutConduireExplicite() — devrait donc ˆetre modifi´ee, contrairement aux deux autres — peutConduireImplicite() et peutConduireImplicite2(). Avec cette notation, seuls les motifs manipulant explicitement les champs ayant ´et´e chang´es doivent ˆetre modifi´es, d’o`u une plus grande robustesse au changement.1.2. Le langage Tom 19 Dans la suite de ce manuscrit, nous utiliserons indiff´eremment l’une ou l’autre des notations dans les extraits de code propos´es. 1.2.5 Strat´egies : maˆıtriser l’application des r`egles de r´e´ecriture On peut analyser la structure de termes et encoder des r`egles de transformation grˆace `a la construction %match. Le contrˆole de l’application de ces r`egles peut alors se faire en Java en utilisant par exemple la r´ecursivit´e. Cependant, traitement et parcours ´etant entrelac´es, cette solution n’est pas robuste au changement et le code peu r´eutilisable. En outre, il est difficile de raisonner sur une telle transformation. Une autre solution est d’utiliser des strat´egies [BMR08, BMR12], qui sont un moyen d’am´eliorer le contrˆole qu’a l’utilisateur sur l’application des r`egles de r´e´ecriture. Le principe de programmation par strat´egies permet de s´eparer le traitement (r`egles de r´e´ecriture, partie m´etier de l’application) du parcours (travers´ee de la structure de donn´ees arborescente), et de sp´ecifier la mani`ere d’appliquer les r`egles m´etier. Tom fournit un puissant langage de strat´egies, inspir´e de Elan [BKK+98], Stratego [VBT98], et JJTraveler [Vis01b]. Ce langage permet d’´elaborer des strat´egies complexes en composant des combinateurs ´el´ementaires tels que Sequence, Repeat, TopDown et la r´ecursion. Il sera donc en mesure de contrˆoler finement l’application des r`egles de r´e´ecriture en fonction du parcours d´efini. Le listing 1.8 illustre la construction %strategy, ainsi que son utilisation : 1 %strategy transformationPeano() extends Identity() { 2 visit Nat { 3 plus(x, zero()) -> { return ‘x; } 4 plus(zero(), x) -> { return ‘x; } 5 one() -> { return ‘suc(zero()); } 6 } 7 } 8 ... 9 public static void main(String[] args) { 10 ... 11 Nat number = ‘plus(plus(suc(suc(one())), one()), 12 plus(suc(one()), zero()) ); 13 Strategy transformStrat = ‘BottomUp(transformationPeano()); 14 Nat transformedNumber = transformStrat.visit(number); 15 System.out.println(number + " a ´et´e transform´e en " + transformedNumber); 16 ... 17 } Listing 1.8 – Exemple d’utilisation de strat´egie. Dans cet exemple, nous supposons que notre signature contient d’autres op´erateurs : plus et one de type Nat. La strat´egie transformationPeano r´e´ecrit les constructeurs one en suc(zero()) et les constructeurs plus(zero(),x) en x. Ligne 1, additionPeano ´etend Identity, ce qui donne le comportement par d´efaut de la strat´egie : si aucune r`egle ne s’applique, aucune transformation n’a lieu, par opposition `a Fail qui sp´ecifie que la transformation ´echoue si la r`egle ne peut ˆetre appliqu´ee. La construction visit (ligne 2) op`ere un premier filtre sur les sortes de type Nat sur lesquelles les r`egles doivent s’appliquer. Les r`egles sont quant `a elles construites sur le mˆeme mod`ele que les r`egles de la construction %match, d´ecrite dans la section 1.2.3. Le membre gauche est un pattern, tandis que le membre droit est un bloc action compos´e de code Tom+Java. Ensuite, la strat´egie est compos´ee avec une strat´egie de parcours fournie par une biblioth`eque appel´ee sl. Le terme la repr´esentant est cr´e´e, et sa m´ethode visit est appliqu´ee sur le nombre que nous souhaitons transformer. Pour l’entr´ee donn´ee, le r´esultat affich´e est le suivant (les couleurs ont ´et´e ajout´ees pour faire apparaˆıtre clairement les sous-termes transform´es) :20 Chapitre 1. Un langage bas´e sur la r´e´ecriture : Tom plus(plus(suc(suc(one())), one()), plus(suc(one()),zero())) a ´et´e transform´e en plus(plus(suc(suc(suc(zero()))), suc(zero())), suc(suc(zero()))) Pour des informations plus d´etaill´ees sur les strat´egies Tom ainsi que sur leur impl´ementation dans le langage, nous conseillons la lecture de [Bal09, BMR08, BMR12] ainsi que la page d´edi´ee du site officiel du projet Tom 2 . 1.3 Ancrages formels Pr´ec´edemment, nous avons vu que nous pouvons ajouter des constructions de filtrage au sein de langages hˆotes et que nous sommes en mesure de filtrer des termes. Les constructions de filtrage sont compil´ees ind´ependamment des impl´ementations concr`etes des termes. Ainsi, dans les exemples, nous filtrons sur des termes de type Nat et NatList, d´efinis dans la signature Gom. Cependant, les fonctions Java prennent des param`etres d’un type donn´e que le compilateur Java est cens´e comprendre, et nous n’avons pas d´etaill´e la mani`ere dont le lien entre les types Tom et les types Java est assur´e. A la compilation, les ` instructions sur les termes alg´ebriques sont traduites en instructions sur le type de donn´ees concret repr´esentant ces termes alg´ebriques. Le m´ecanisme permettant d’´etablir cette relation entre les structures de donn´ees alg´ebriques et concr`etes s’appelle le m´ecanisme d’ancrage, ou mapping. Il permet de donner une vue alg´ebrique d’une structure de donn´ees quelconque afin de pouvoir la manipuler `a l’aide des constructions Tom, sans modifier l’impl´ementation concr`ete. On sp´ecifie les mappings `a l’aide des constructions Tom %typeterm, %op et %oplist pour d´ecrire respectivement les sortes, les op´erateurs alg´ebriques et les op´erateurs variadiques. Dans la section 1.2.1, nous avons d´efini une signature alg´ebrique, et l’outil Gom g´en`ere une impl´ementation concr`ete ainsi que les ancrages. Cela nous permet de rendre ce m´ecanisme compl`etement transparent pour l’utilisateur. Pour expliquer les constructions constituant les mappings, nous allons les expliciter sans passer par la g´en´eration de Gom. Pour la suite de cette section, nous prenons l’exemple du type Individu et de l’op´erateur personne, qui prend trois arguments : un nom et un pr´enom, de type String, et un ˆage de type int. Nous adoptons aussi une notation pour lever toute ambigu¨ıt´e sur les types : nous pr´efixons les types Java de la lettre J, et nous utiliserons l’impl´ementation qui suit. Nous consid´erons les classes Java JIndividu et JIndividuList suivantes qui impl´ementent respectivement les types alg´ebriques Individu et IndividuList. 1 static class JIndividu { } 2 static class JIndividuList { } Nous consid´erons ensuite les classes Java Jpersonne et JconcJIndividu suivantes qui impl´ementent les op´erateurs alg´ebriques : 1 static class Jpersonne extends JIndividu { 2 public String nom; 3 public String prenom; 4 public int age; 5 public Jpersonne(String n, String p, int a) { 6 this.nom = n; 7 this.prenom = p; 8 this.age = a; 9 } 10 static class JconcJIndividu extends JIndividuList { 2. Voir http://tom.loria.fr/wiki/index.php5/Documentation:Strategies/.1.3. Ancrages formels 21 11 private LinkedList list; 12 public JconcJIndividu() { list = new LinkedList(); } 13 public JconcJIndividu(JIndividu i, LinkedList l) { 14 if (l!=null) { 15 this.list = l; 16 } else { 17 JconcJIndividu(); 18 } 19 list.addFirst(i); 20 } 21 public boolean isEmpty() { 22 return list.isEmpty(); 23 } 24 public List getTail() { 25 LinkedList tail = null; 26 if (list.size()>1) { 27 tail = list.subList(1,list.size()-1); 28 } 29 return tail; 30 } 31 } Les sortes Individu et IndividuList sont exprim´ees via le lex`eme %typeterm comme le montre le listing 1.9 suivant : 1 %typeterm Individu { 2 implement { JIndividu } 3 is_sort(s) { (s instanceof JIndividu) } 4 } Listing 1.9 – Ancrage du type Individu avec l’impl´ementation Java JIndividu. La construction %typeterm permet d’´etablir la relation entre le type alg´ebrique Individu et le type concret Java JIndividu. Deux sous-constructions la composent : — implement donne l’impl´ementation effective du langage hˆote `a lier au type alg´ebrique ; — is sort est utilis´ee en interne par le compilateur pour tester le type d’un ´el´ement (optionnel) ; La sorte Individu ´etant d´efinie, il est n´ecessaire de sp´ecifier `a Tom comment construire et comment d´etruire (d´ecomposer) les termes de ce type. Pour cela, nous utilisons la construction %op, comme illustr´e par le listing 1.10 o`u l’op´erateur personne est d´efini : 1 %op Individu personne(nom:String, prenom:String, age:int) { 2 is_fsym(s) { (s instanceof Jpersonne) } 3 get_slot(nom,s) { ((Jpersonne)s).nom } 4 get_slot(prenom,s) { ((Jpersonne)s).prenom } 5 get_slot(age,s) { ((Jpersonne)s).age } 6 get_default(nom) { ’’Simpson’’ } 7 get_default(prenom) { ’’Pierre-Gilles’’ } 8 get_default(age) { 42 } 9 make(t0,t1,t2) { new Jpersonne(t0,t1,t2) } 10 } Listing 1.10 – Constructeur personne. La d´efinition d’op´erateurs passe par une construction compos´ee de quatre sous-constructions :22 Chapitre 1. Un langage bas´e sur la r´e´ecriture : Tom — is fsym sp´ecifie la mani`ere de tester si un objet donn´e repr´esente bien un terme dont le symbole de tˆete est l’op´erateur ; — make sp´ecifie la mani`ere de cr´eer un terme ; — get slot (optionnel) sp´ecifie la mani`ere de r´ecup´erer la valeur d’un champ du terme ; — get default (optionnel) donne la valeur par d´efaut de l’attribut. Notons que Tom ne permet pas la surcharge d’op´erateurs, c’est-`a-dire qu’il n’est pas possible de d´efinir plusieurs op´erateurs ayant le mˆeme nom, mais des champs diff´erents. La construction %oplist est le pendant de %op pour les op´erateurs variadiques. Ainsi, dans le listing 1.11, nous pouvons d´efinir un op´erateur de liste d’individus concIndividu, de type IndividuList, et acceptant un nombre variable de param`etres de type Individu.1.3. Ancrages formels 23 1 %oplist IndividuList concIndividu(Individu*) { 2 is_fsym(s) { (s instanceof JconcJIndividu) } 3 get_head(l) { ((JconcJIndividu)l).list.getFirst() } 4 get_tail(l) { ((JconcJIndividu)l).getTail() } 5 is_empty(l) { ((JconcJIndividu)l).isEmpty() } 6 make_empty() { new JconcJIndividu() } 7 make_insert(t,l) { new JconcJIndividu(t,l) } 8 } Listing 1.11 – Op´erateur de liste d’Individus. Les sous-constructions suivantes la composent : — is fsym sp´ecifie la mani`ere de tester si un objet donn´e repr´esente bien un terme dont le symbole de tˆete est l’op´erateur ; — make empty sp´ecifie la mani`ere de cr´eer un terme vide ; — make insert sp´ecifie la mani`ere d’ajouter un fils en premi`ere position `a la liste ; — get head sp´ecifie la mani`ere de r´ecup´erer le premier ´el´ement de la liste ; — get tail sp´ecifie la mani`ere de r´ecup´erer la queue de la liste (sous-liste constitu´ee de la liste priv´ee du premier ´el´ement) ; — is empty sp´ecifie la mani`ere de tester si une liste est vide. Notons que le langage Tom supporte aussi le sous-typage [KMT09, Tav12]. Il est donc possible de sp´ecifier un type comme sous-type d’un autre type d´ej`a exprim´e. Cette relation de sous-typage exprim´ee dans les types Tom doit ´evidemment ˆetre coh´erente avec celle exprim´ee dans l’impl´ementation concr`ete en Java. Reprenons l’exemple pr´ec´edent des individus et consid´erons diff´erents sens possibles : ˆetre vivant (sens couramment utilis´e, d’o`u le constructeur personne), sp´ecimen vivant d’origine animale ou v´eg´etale (en biologie) et ´el´ement constituant un ensemble (en statistiques). Le type Individu pouvant ˆetre ambigu, nous d´ecidons de le pr´eciser en int´egrant des sous-types. Pour cela, il existe une construction Tom permettant de sp´ecifier un sous-type dans un ancrage alg´ebrique : extends, qui compl`ete la construction %typeterm. 1 %typeterm IndividuBiologie extends Individu { 2 implement { JIndividuBiologie } 3 is_sort(s) { (s instanceof JIndividuBiologie) } 4 equals(t1,t2) { (t1.equals(t2)) } 5 } 6 public class JIndividuBiologie extends Individu { 7 ... 8 } Listing 1.12 – Exemple de d´eclaration de type avec sous-typage. Dans le listing 1.12, nous d´eclarons donc un nouveau type, IndividuBiologie, sous-type de Individu (lignes 1 `a 5). Il est impl´ement´e par le type Java JIndividuBiologie dont la relation de sous-typage avec JIndividu est exprim´ee par la construction Java consacr´ee `a l’h´eritage : extends (ligne 7). Il est ensuite possible de d´efinir de mani`ere classique des op´erateurs de type IndividuBiologie comme l’illustre le listing 1.13. 1 %op IndividuBiologie animal(espece:String) { 2 ... 3 } 4 %op IndividuBiologie vegetal(espece:String) { 5 ... 6 }24 Chapitre 1. Un langage bas´e sur la r´e´ecriture : Tom Listing 1.13 – Constructeurs de type IndividuBiologie. 1.4 Domaines d’applications Tom est particuli`erement utile pour parcourir et transformer les structures arborescentes comme XML par exemple. Il est donc tout `a fait indiqu´e pour ´ecrire des compilateurs ou interpr´eteurs, et plus g´en´eralement des outils de transformation de programmes ou de requˆetes. Outre son utilisation pour ´ecrire le compilateur Tom lui-mˆeme, nous noterons son usage dans les cadres acad´emiques et industriels suivants : — impl´ementation d’un m´ecanisme d´efini par Guillaume Burel dans sa th`ese [Bur09] pour une m´ethode des tableaux particuli`ere appel´ee TaMeD [Bon04] ; — prototypage de langages tels que MiniML dont la compilation a ´et´e d´ecrite par Paul Brauner dans sa th`ese [Bra10] ; — impl´ementation d’un assistant `a la preuve tel que Lemuridae d´evelopp´e par Paul Brauner pour un calcul des s´equents nomm´e LKMS [Bra10] ; — impl´ementation de compilateurs ou interpr´eteurs, comme le compilateur +CAL 2.0 3 qui traduit des algorithmes exprim´es en +CAL en TLA+ pour faire du model-checking ; — raisonnement formel sur la plateforme Rodin 4 . Il s’agit d’un outil industriel open source d´evelopp´e par Systerel 5 qui permet de formaliser, d’analyser et de prouver les sp´ecifi- cations de syst`emes complexes ; — outil de transformation de requˆetes OLAP (OnLine Analytical Processing) en requˆetes SQL (Structured Query Language) pour assurer la r´etro-compatibilit´e entre les versions du logiciel Crystal Reports 6 d´evelopp´e par Business Object 7 ; — transformations de mod`eles qualifiables pour les syst`emes embarqu´es temps-r´eel dans le projet quarteFt 8 port´e par le LAAS-CNRS 9 , l’IRIT 10, l’ONERA-DTIM 11 et Inria Nancy ainsi que nos partenaires industriels Airbus 12 et Ellidiss Software 13. C’est dans ce cadre que s’inscrit cette th`ese. 1.5 Apport de la th`ese au projet Tom Durant cette th`ese, j’ai contribu´e techniquement au projet Tom. La figure 1.5 illustre le fonctionnement global du syst`eme Tom au d´ebut de ma th`ese, et sert de point de comparaison avec la figure 1.6 pour illustrer cet apport de d´eveloppement. La contribution technique de cette th`ese au projet Tom a consist´e en l’extension du langage Tom par l’ajout de constructions haut-niveau d´edi´ees `a la transformation de mod`eles. Ces constructions haut niveau (%transformation, %resolve et %tracelink) sont d´etaill´ees dans le chapitre 6. La construction %transformation impl´emente une m´ethode propos´ee dans [BCMP12] pour transformer des mod`eles EMF Ecore, tout en simplifiant l’´ecriture de la transformation pour l’utilisateur. Cette m´ethode se d´eroule en deux phases : 3. Voir https://gforge.inria.fr/projects/pcal2-0/. 4. Voir http://www.event-b.org/. 5. Voir http://www.systerel.fr/. 6. Voir http://crystalreports.com/. 7. Voir http://www.businessobjects.com/. 8. Site du projet : http://quarteft.loria.fr/. 9. Laboratoire d’Analyse et d’Architecture des Syst`emes : http://www.laas.fr/. 10. Institut de Recherche en Informatique de Toulouse : http://www.irit.fr/. 11. Office national d’´etudes et de recherches a´erospatiales : http://www.onera.fr/fr/dtim/. 12. Voir http://www.airbus.com/. 13. Voir http://www.ellidiss.com/.1.5. Apport de la th`ese au projet Tom 25 Compilateur Tom Tom + Java Ancrages alg´ebriques Gom Signature Gom Structures de donn´ees Java Code Java Compilateur Java 110010 101110 010100 Figure 1.5 – Fonctionnement global du projet Tom en d´ebut de th`ese. — une phase de d´ecomposition de la transformation en transformations ´el´ementaires encod´ees par des strat´egies Tom ; — une phase de r´econciliation durant laquelle le r´esultat interm´ediaire obtenu lors de la premi`ere phase est rendu coh´erent et conforme au m´etamod`ele cible. Les constructions %resolve et %tracelink servent `a la phase de r´econciliation d’une transformation de mod`ele suivant la m´ethode propos´ee. En suivant cette approche, l’utilisateur peut ´ecrire les transformations ´el´ementaires de mani`ere ind´ependante et sans aucune notion d’ordre d’application des pas d’ex´ecution de la transformation. La construction %tracelink pr´esente aussi un int´erˆet en termes de tra¸cabilit´e de la transformation. Nous souhaitons g´en´erer des traces d’ex´ecution de la transformation `a la demande de l’utilisateur, ce pour quoi %tracelink a ´et´e con¸cue. Cela a eu pour cons´equence l’ajout d’un nouveau greffon (voir la figure 6.5) dans la chaˆıne de compilation (transformer ), ainsi que l’adaptation de cette chaˆıne, du parser au backend, afin de prendre en compte cette extension du langage. Outre l’´evolution du langage Tom lui-mˆeme, le g´en´erateur d’ancrages alg´ebriques Tom-EMF a aussi ´evolu´e et est maintenant disponible en version stable. Nos contributions au projet Tom apparaissent en pointill´es sur la figure 1.6.26 Chapitre 1. Un langage bas´e sur la r´e´ecriture : Tom Compilateur Tom Tom + Java Ancrages alg´ebriques Gom Signature Gom Structures de donn´ees Java Ancrages alg´ebriques Tom-EMF Java EMF (MM) Code Java MM de lien Compilateur Java 110010 101110 010100 Figure 1.6 – Fonctionnement global de Tom et contributions de ce travail de th`ese au projet.Chapitre 2 Transformations de mod`eles Dans ce chapitre, nous pr´esentons un domaine du d´eveloppement logiciel en plein essor : l’Ing´enierie Dirig´ee par les Mod`eles (IDM). Nous pr´esentons les approches actuelles et les notions importantes de ce domaine indispensables `a la bonne compr´ehension de ce document. Dans un premier temps, nous expliquons ce qu’est l’IDM et notamment l’approche MDA (Model Driven Architecture). Ensuite, nous abordons la probl´ematique des transformations de mod`eles, et enfin nous pr´esentons bri`evement certains outils tr`es utilis´es. 2.1 Mod´elisation A partir des ann´ees 80, l’ing´enierie du logiciel a ´et´e marqu´ee par l’approche objet dans ` laquelle le principe « Tout est objet » pr´evaut. Ce principe permet d’amener les outils et les technologies `a la simplicit´e, la g´en´eralit´e et la bonne int´egration dans les syst`emes. Cette approche repose sur la notion d’objet, qui est une instance d’une classe, qui peut h´eriter d’une autre classe (surclasse). L’arriv´ee de l’IDM a renouvel´e les notions phares guidant le d´eveloppement logiciel. Le principe « Tout est objet » est remplac´e par celui du « Tout est mod`ele » [BB04] [B´e05]. Les notions de mod`ele repr´esentant un syst`eme, et conforme `a un m´etamod`ele sont apparues. L’approche IDM vise `a ´elever le niveau d’abstraction dans la sp´ecification logicielle, et `a augmenter l’automatisation dans le d´eveloppement. L’id´ee promue par l’IDM est d’utiliser les mod`eles `a diff´erents niveaux d’abstraction pour d´evelopper les syst`emes, et ainsi ´elever le niveau d’abstraction dans la sp´ecification du programme. L’augmentation de l’automatisation dans le d´eveloppement logiciel est obtenue en utilisant des transformations de mod`eles ex´ecutables. Les mod`eles de plus haut niveau sont transform´es en mod`eles de plus bas niveau jusqu’`a ce que le mod`ele puisse ˆetre ex´ecut´e en utilisant soit la g´en´eration de code, soit l’interpr´etation du mod`ele (ex´ecution du mod`ele). La d´efinition mˆeme de mod`ele a longtemps ´et´e discut´ee, et de nombreuses propositions — dont notamment celle de [BG01], ainsi que celle de [KWB03] — nous permettent de donner la d´efinition suivante : D´efinition 22 (Mod`ele). Un mod`ele est la repr´esentation ou l’abstraction d’un (ou d’une partie d’un) syst`eme, ´ecrit dans un langage bien d´efini. Un mod`ele doit pouvoir ˆetre utilis´e `a la place du syst`eme mod´elis´e pour r´epondre `a une question sur le syst`eme repr´esent´e. Il en d´ecoule la d´efinition de la relation repr´esente entre le mod`ele et le syst`eme mod´elis´e [AK03, Sei03, B´e05]. Du fait de l’utilisation du mod`ele `a la place du syst`eme, cette repr´esentation doit ˆetre pertinente. La d´efinition pr´ec´edente am`ene aussi `a pr´eciser la notion de langage bien d´efini : D´efinition 23 (Langage bien d´efini). Un langage bien d´efini est un langage avec une forme 2728 Chapitre 2. Transformations de mod`eles bien d´efinie (syntaxe), et une signification (s´emantique), qui est appropri´ee pour une interpr´etation automatique par un ordinateur 14 . Pour pouvoir utiliser un mod`ele, son langage de mod´elisation doit ˆetre pr´ecis´e. Il est repr´esent´e par un m´etamod`ele. D´efinition 24 (M´etamod`ele). Un m´etamod`ele est un mod`ele qui d´efinit le langage d’expression d’un mod`ele [OMG06a], c’est-`a-dire le langage de mod´elisation. Dans la suite de ce document, nous noterons les m´etamod`eles MM, indic´es en fonction de leur nature : ainsi un m´etamod`ele source — respectivement cible — sera not´e MMs — respectivement MMt. La relation qui lie un mod`ele `a son m´etamod`ele est la relation de conformit´e, c’est-`a-dire qu’un m´etamod`ele est la sp´ecification d’un mod`ele : on dit qu’un mod`ele est conforme `a son m´etamod`ele. La publication en 2000 de l’initiative MDA [StOS00] par l’OMG 15 a consid´erablement amplifi´e l’int´erˆet de l’IDM. Le MDA est la vision qu’a l’OMG de l’IDM : il s’agissait de d´efinir un cadre pour utiliser concr`etement les mod`eles dans le d´eveloppement logiciel [KWB03, MKUW04]. Pour cela, elle propose diff´erents standards pour r´esoudre des probl`emes soulev´es par l’ing´enierie dirig´ee par les mod`eles : — ´etablissement de nouveaux langages de mod´elisation [OMG06a] ; — mod´elisation des syst`emes [OMG09, OMG11] ; — expression de la s´emantique statique des mod`eles et des m´etamod`eles [OMG06b] ; — repr´esentation des mod`eles sous forme de documents XML (pour l’interop´erabilit´e)[OMG13] ; — repr´esentation des parties graphiques d’un mod`ele au format XML [OMG03]. L’OMG a donc propos´e le standard MOF [OMG06a] 16 comme un sous-ensemble du diagramme de classes UML. Intuitivement, un m´etamod`ele est compos´e d’un ensemble de m´etaclasses qui contiennent des attributs et des op´erations comme les classes en programmation orient´ee objet. Les m´etaclasses peuvent ˆetre li´ees par h´eritage, et par une m´etarelation (une association ou une composition). Chaque mod`ele doit se conformer `a un tel m´etamod`ele, c’est-`a-dire ˆetre un ensemble d’´el´ements, d’attributs et de relations entre les ´el´ements se conformant `a leurs m´etad´efinitions. Ce standard MOF — compos´e de EMOF 17 et CMOF 18 depuis la version 2.0 — permet d’´etablir de nouveaux langages de mod´elisation et se situe au sommet d’une architecture en quatre couches propos´ee par l’OMG (figure 2.1). La couche M0 est celle du monde r´eel qui est repr´esent´e par des mod`eles de la couche M1. Ces mod`eles sont conformes `a leurs m´etamod`eles — couche M2 — qui sont eux-mˆemes d´ecrits par le m´etam´etamod`ele MOF — couche M3. Ce dernier est unique et m´etacirculaire, c’est-`a-dire qu’il se d´ecrit lui-mˆeme. D´efinition 25 (M´etam´etamod`ele). Un m´etam´etamod`ele est un m´etamod`ele qui d´ecrit un langage de m´etamod´elisation. Il permet donc de d´efinir des langages de mod´elisation et est m´etacirculaire, c’est-`a-dire qu’il se d´ecrit lui-mˆeme. Cette approche hi´erarchique est classique et on la retrouve dans plusieurs autres domaines de l’informatique. Une telle hi´erarchie d´efinit ce que l’on appelle un espace technique (ou espace technologique) [KBA02, B´e06]. Ainsi, nous parlerons de modelware, de grammarware [KLV05, KKK+] pour l’espace des grammaires d´efinies par l’EBNF 19, de dataware (ou parfois DBware) 14. Traduction de [KWB03], page 16 : A well-defined language is a language with well-defined form (syntax), and meaning (semantics), which is suitable for automated interpretation by a computer. 15. Object Management Group : http://www.omg.org/. 16. Meta Object Facility : http://www.omg.org/mof/. 17. Essential MOF 18. Complete MOF 19. Extended Backus-Naur Form2.1. Mod´elisation 29 M0 M1 M2 M3 monde r´eel monde des mod`eles syst`eme S mod`ele m m´etamod`ele MM m´etam´etamod`ele MMM est repr´esent´e par est conforme `a est conforme `a est conforme `a Figure 2.1 – Organisation du MDA en 4 niveaux d’abstraction (3+1). avec SQL et de documentware avec XML. Ce que nous appelons m´etamod`ele dans l’espace des mod`eles correspond `a la grammaire dans l’espace grammarware, au type dans les langages de programmation, au sch´ema dans les espaces documentware et dataware. Pour illustrer notre propos, dans la figure 2.2, nous interpr´etons les niveaux d’abstraction de cette organisation en couches du MDA et faisons une analogie avec l’espace technique des grammaires. Ainsi, MOF correspond `a l’EBNF, tandis que la couche M2 contient les langages d´efinis par la grammaire, la couche M1 les programmes ´ecrits dans ces langages, et M0 consiste en les ex´ecutions de ces programmes. Outre MOF, l’OMG propose d’utiliser d’autres standards dans son approche MDA, notamment UML (Unified Modeling Language) et (OCL Object Constraint Language) : — UML est le standard de mod´elisation des syst`emes logiciels. Il est compos´e depuis 2009 [OMG09] du paquetage UML 2.2 Superstructure qui est le standard pour la mod´elisation orient´ee objet, ainsi que du paquetage UML 2.2 Infrastructure d´ecrivant le noyau commun entre MOF et UML. — OCL a ´et´e propos´e pour exprimer la s´emantique axiomatique des mod`eles et des m´etamod`eles. Il permet d’exprimer des contraintes sur les m´etamod`eles (invariant, pre- et post-conditions sur les op´erations), afin de mieux les d´efinir pour ensuite pouvoir les outiller. L’initiative MDA se concentre sur la variabilit´e technique d’un logiciel, c’est-`a-dire sur la mani`ere de sp´ecifier un logiciel ind´ependamment de la plateforme, afin de mettre en œuvre des syst`emes durables et maintenables. Elle propose d’´elaborer diff´erents mod`eles pour d´efinir une architecture de sp´ecification `a plusieurs niveaux. Pour cela, les notions de CIM (Computation Independent Model), PIM (Platform Independent Model) et PSM (Platform Specific Model) ont ´et´e introduites : — CIM : mod`ele d’exigence, d´efini hors de toute consid´eration informatique (par exemple, le diagramme de cas d’utilisation UML) ; — PIM : ce mod`ele d´efini ind´ependamment de la plateforme d’ex´ecution est aussi appel´e mod`ele d’analyse et conception ;30 Chapitre 2. Transformations de mod`eles M0 M1 M2 M3 monde r´eel une situation m1 m2 m MMUML MMSP EM MOF est repr´esent´e par est conforme `a est conforme `a est conforme `a Ex´ecution du programme Programme Grammaire du langage de programmation EBNF niveaux d’abstraction monde des mod`eles monde des grammaires Figure 2.2 – Interpr´etation des niveaux d’abstraction du MDA. — PSM : mod`ele de code, pour lequel les caract´eristiques de la plateforme d’ex´ecution ont ´et´e prises en compte. Le passage de PIM `a PSM peut se faire par des transformations de mod`eles, int´egrant parfois des transformations interm´ediaires de PIM `a PIM (pour des raisons d’interop´erabilit´e), d’o`u leur place de choix dans les approches mod`eles pour le d´eveloppement logiciel. Le MDA fournit un socle pour aider l’IDM `a se d´evelopper. Cependant, il s’agit d’une vision parmi d’autres [FEBF06]. On pense notamment aux usines logicielles (Software Factories) [GS03] dont l’id´ee est de se calquer sur le processus de production du monde mat´eriel pour mettre en œuvre celui du monde logiciel. Il s’agit de composer des applications `a partir d’un grand nombre d’outils, de patterns, de mod`eles et de frameworks. Les id´ees principales de cette approche sont : — la sp´ecialisation des fournisseurs et d´eveloppeurs de logiciels ; — l’utilisation d’outils d´edi´es (transformations de mod`eles, langages et outils de mod´elisation) ; — l’int´egration syst´ematique de code r´eutilisable. Microsoft a int´egr´e ces concepts au sein de son framework .NET et de son environnement de d´eveloppement. De son cˆot´e, IBM a activement contribu´e `a l’approche MDA en ´etant le principal d´eveloppeur de UML et en participant `a l’´elaboration des standards MOF, XMI et CWM. IBM donne sa vision du MDA dans [BBI+04] o`u ces trois principes sont d´evelopp´es : — repr´esentation directe : il faut se d´etacher du domaine technologique et se concentrer sur les id´ees et concepts du domaine m´etier. R´eduire la distance s´emantique entre le domaine m´etier et la repr´esentation permet de r´epondre plus directement et pr´ecis´ement aux probl`emes. Pour prendre en compte ces situations m´etier, on utilise des langages d´edi´es ( Domain Specific Language, DSL) ; — automatisation : il faut automatiser tout ce qui ne n´ecessite pas d’intelligence et de r´eflexion ;2.2. Transformations de mod`eles 31 — standards ouverts : les standards encouragent la cr´eation de communaut´es autour d’outils, et un d´eveloppement ouvert permet d’assurer que ces standards soient impl´ement´es de mani`ere coh´erente tout en poussant `a leur adoption. Les communaut´es autour des plateformes de logiciel libres ont un rˆole structurant. IBM a donc propos´e son langage de m´etamod´elisation — Ecore — pour l’Eclipse Modeling Framework (EMF) [SBPM09]. Il s’aligne quasiment sur EMOF, et cette proximit´e des deux m´etamod`eles permet `a EMF de supporter directement EMOF comme une s´erialisation XMI alternative de Ecore. Le passage de l’un `a l’autre consiste essentiellement en des tˆaches de renommage de classes et de fonctionnalit´es. Ecore est int´egr´e dans l’environnement Eclipse et est l’un des frameworks les plus utilis´es pour la manipulation de mod`eles, ce qui en fait un standard de facto. Il fait le lien entre la programmation Java et la mod´elisation. C’est pourquoi nous avons choisi EMF comme premi`ere technologie pour les outils d´evelopp´es durant cette th`ese. Pour une description approfondie du MDA, le lecteur int´eress´e pourra se r´ef´erer `a [KWB03], [Bro04] et [BS05]. 2.2 Transformations de mod`eles Les transformations de mod`eles sont au cœur de l’IDM [SK03]. Elles permettent d’automatiser les tˆaches r´ep´etitives — application d’un traitement `a un grand nombre de mod`eles ou multiples applications d’un traitement sur un mod`ele — ainsi que des tˆaches complexes et sujettes `a erreurs si elles ´etaient effectu´ees manuellement par un utilisateur. Les transformations de mod`eles sont aussi utiles dans le cas o`u le d´eveloppement d’un syst`eme est segment´e et que les rˆoles dans le d´eveloppement sont s´epar´es : si le sp´ecialiste de la plateforme n’est pas le sp´ecialiste du syst`eme d´evelopp´e, le traitement par l’un d’un mod`ele produit par l’autre est particuli`erement complexe. Les transformations de mod`eles permettent un gain accru en termes de productivit´e, de maˆıtrise de la complexit´e, de diminution des risques et donc, finalement, de coˆut. Elles sont utilis´ees pour r´ealiser des tˆaches vari´ees telles que : — la r´eing´enierie (refactoring) : tˆache qui consiste `a changer un logiciel de telle sorte que son comportement ext´erieur n’est pas affect´e tout en am´eliorant sa structure interne 20 ; — la g´en´eration de code : processus qui produit du code `a partir d’instructions abstraites en prenant en compte les caract´eristiques de la plateforme cible d’ex´ecution ; — le raffinement : transformation d’une sp´ecification abstraite en une sp´ecification (plus) concr`ete ; — la normalisation : mise en conformit´e d’un logiciel, adaptation du style de code, etc. ; — la migration : passage d’une technologie (ou d’une version `a une autre d’une technologie) `a l’autre ; — la s´erialisation : processus de mise en s´erie des donn´ees sous la forme d’un fichier ; — la r´etro-conception ou r´etro-ing´enierie (reverse engineering) : ´etude d’un programme pour en comprendre le fonctionnement interne et sa m´ethode de conception. D´efinition 26 (Transformation de mod`ele). Une transformation de mod`ele T est une relation d’un (ou plusieurs) m´etamod`ele(s) source(s) MMs vers un (ou plusieurs) m´etamod`ele(s) cible(s) MMt. On la notera : T : MMs → MMt (ou T : MMs0 × . . . × MMsn → MMt0 × . . . × MMtm dans le cas d’une transformation de n m´etamod`eles sources vers m m´etamod`eles cibles). Dans la suite du document, nous consid´ererons essentiellement des transformations de mod`eles d’un seul m´etamod`ele source vers un seul m´etamod`ele cible (T : MMs → MMt). 20. Traduction de la d´efinition de [Fow99]32 Chapitre 2. Transformations de mod`eles Compte tenu de la diversit´e des transformations, tant par leurs approches de d´eveloppement, que par les structures de donn´ees dont elles se servent pour repr´esenter les mod`eles qu’elles manipulent, que par les caract´eristiques des m´etamod`eles sources et cibles, de nombreux travaux ont ´et´e men´es pour tenter de les classifier [CH03], [SK03], [CH06], [MG06]. 2.2.1 Taxonomie des transformations On distingue diff´erents types de transformations de mod`eles que l’on peut d´efinir et classifier selon que les m´etamod`eles source et cible sont identiques ou non, et selon qu’ils appartiennent ou non au mˆeme niveau d’abstraction. C’est `a partir de ces crit`eres que [MG06] a propos´e une taxonomie des transformations de mod`eles sur laquelle nous nous appuyons dans cette section. D´efinition 27 (Transformation endog`ene). Une transformation T : MMs → MMt est dite endog`ene si MMs = MMt, c’est-`a-dire si les m´etamod`eles source et cible sont identiques. Par exemple, une activit´e de r´eing´enierie d’un logiciel est une transformation endog`ene. Par analogie avec les langues naturelles, la reformulation d’une phrase en est aussi une. Une transformation endog`ene s’op`ere dans un mˆeme espace technologique, si les modifications sont directement appliqu´ees sur le mod`ele source, on parle de transformation in-place. Dans le cas contraire, il s’agit d’une transformation out-place. D´efinition 28 (Transformation exog`ene). Une transformation T : MMs → MMt est dite exog`ene si MMs 6= MMt, c’est-`a-dire si les m´etamod`eles cible et source sont diff´erents.. Par exemple, la migration d’un syst`eme ou la r´e´ecriture d’un logiciel dans un autre langage est une transformation exog`ene. En utilisant l’analogie pr´ec´edente, la traduction en est aussi une. Une transformation exog`ene est toujours out-place et peut permettre un changement d’espace technique. D´efinition 29 (Transformation horizontale). Une transformation est dite horizontale si les mod`eles source et cible appartiennent au mˆeme niveau d’abstraction. Par exemple, l’activit´e de r´eing´enierie est une transformation horizontale (endog`ene), tout comme celle de migration (exog`ene). D´efinition 30 (Transformation verticale). Une transformation est dite verticale si les mod`eles source et cible n’appartiennent pas au mˆeme niveau d’abstraction. Par exemple, la r´etro-conception et le raffinement sont des transformations verticales, respectivement exog`ene et endog`ene. La figure 2.3 r´esume sous forme matricielle cette classification en fonction des deux crit`eres : — les colonnes classifient les transformations selon le changement de niveau d’abstraction (transformation verticale vs horizontale) ; — les lignes classifient les transformations selon que le m´etamod`ele cible est le mˆeme (ou non) que le m´etamod`ele source (transformation endog`ene vs exog`ene).2.2. Transformations de mod`eles 33 ms mt niveaux d’abstraction x y z Transformation horizontale ms niveaux mt d’abstraction w x y z Transformation verticale MMs ms conforme `a MMt mt conforme `a Transformation exog`ene Migration, S´erialisation G´en´eration de code, Retro-conception MM conforme `a ms mt Transformation endog`ene Optimisation, R´eing´enierie, Normalisation, Simplification Raffinement Figure 2.3 – Classification des cat´egories de transformations de mod`eles. 2.2.2 Approches de d´eveloppement des transformations de mod`eles Les transformations de mod`eles peuvent ˆetre classifi´ees selon leurs approches de d´eveloppement et selon les structures de donn´ees repr´esentant les mod`eles. Trois approches de transformation de mod`eles sont d´efinies dans [BS05] : — par programmation ; — par template ; — par mod´elisation. Dans l’approche par programmation, une transformation est d´evelopp´ee en utilisant des langages de programmation « classiques » (g´en´eralistes) g´en´eralement orient´es objet, tels que Java. La transformation se pr´esente sous la forme d’un programme et le d´eveloppeur a acc`es `a tout l’´ecosyst`eme existant (environnement de d´eveloppement, biblioth`eques, documentation, communaut´e d’utilisateurs. . . ). Cela en fait une approche tr`es r´epandue. Dans l’approche par template, un mod`ele cible param´etr´e (ou mod`ele template) est d´efini. La transformation consiste alors `a proc´eder au remplacement des param`etres en utilisant les valeurs fournies par le mod`ele source. C’est ce qu’impl´emente le logiciel Softeam MDA Modeler. La troisi`eme approche identifi´ee — l’approche par mod´elisation — consiste `a consid´erer la transformation elle-mˆeme comme un mod`ele conforme `a son m´etamod`ele de transformation. L’OMG a d´efini le standard Query/View/Transformation (QVT) pour mod´eliser les transformations de mod`eles [OMG08]. Il est compos´e de trois langages conformes `a MOF — QVT-Operational, QVT-Relations et QVT-Core — regroupant deux paradigmes de description des transformations de mod`eles : Approche op´erationnelle : une transformation de mod`ele est exprim´ee comme une s´equence de pas d’ex´ecution ´el´ementaires qui construisent le mod`ele cible (instanciation des nouveaux ´el´ements, initialisation des attributs, cr´eation des liens, etc.) en utilisant les informations du mod`ele source. Cette approche, appel´ee op´erationnelle, est34 Chapitre 2. Transformations de mod`eles imp´erative. Elle peut ˆetre impl´ement´ee en utilisant des outils d´edi´es tels que Kermeta, QVT-Operational, ou en utilisant des biblioth`eques au sein d’un langage g´en´eraliste. Approche relationnelle : une transformation de mod`ele peut aussi ˆetre d´efinie comme des relations devant exister entre la source et la cible `a la fin de la transformation. Cette approche, appel´ee relationnelle (ou d´eclarative), n’est pas directement ex´ecutable, mais peut parfois ˆetre traduite en une transformation op´erationnelle. La principale diff´erence entre les deux approches est le fait que l’approche op´erationnelle n´ecessite de d´ecrire le contrˆole comme une partie de la transformation, tandis que cet aspect est g´er´e par le moteur d’ex´ecution dans le cas de l’approche relationnelle. Un autre aspect diff´erenciant des transformations de mod`eles est la question de la repr´esentation des mod`eles. Si le type de structure de donn´ees permettant de repr´esenter un mod`ele peut ˆetre ind´ependant de l’approche, la repr´esentation choisie a toutefois des cons´equences concr`etes concernant les outils utilis´es pour les transformations. On peut distinguer ainsi rois grandes familles d’outils de transformation : Transformation de texte (fichiers). L’approche la plus simple et intuitive `a comprendre, mais aussi, historiquement, la plus ancienne, consiste `a transformer s´equentiellement des fi- chiers donn´es en entr´ee `a des scripts, qui produisent eux-mˆemes des fichiers en sortie. C’est l’approche adopt´ee par les outils s’appuyant sur AWK, sed ou Perl. Ils conviennent particuli`erement bien aux transformations les plus simples, qui sont g´en´eralement assez faciles `a comprendre et `a maintenir. Cependant, cette approche n´ecessite de parser l’entr´ee et de s´erialiser la sortie, et ne permet pas de manipuler une structure plus abstraite [GLR+02]. Transformation d’arbres. La structure d’arbre est une seconde repr´esentation courante des mod`eles. L’arbre en entr´ee est parcouru et des nœuds sont cr´e´es au fur et `a mesure de l’ex´ecution des pas de transformation pour g´en´erer un arbre de sortie (ou modifier directement l’arbre source). C’est l’approche des outils de transformation reposant sur XML tels que XSLT [W3C99] ou XQuery 21 [BCF+10, RCD+11]. C’est aussi traditionnellement l’approche des compilateurs et, plus g´en´eralement, des outils de l’espace technique grammarware (les langages respectent des grammaires — des m´etamod`eles — conformes `a EBNF). Transformation de graphes. Un troisi`eme type de repr´esentation de mod`ele possible est le graphe (orient´e et ´etiquet´e). C’est souvent la repr´esentation adopt´ee par les outils modernes d´edi´es `a la mod´elisation et aux transformations de mod`eles (par exemple AGG [Tae04]). Cette repr´esentation est fortement li´ee `a l’approche de d´eveloppement de transformation par mod´elisation que nous avons d´ecrite plus haut. C’est aussi la principale repr´esentation de mod`eles de la plupart des outils que nous allons pr´esenter dans la section suivante. 2.2.3 Outils existants Dans cette section, nous pr´esentons diff´erents outils utilis´es dans le cadre de l’IDM pour mod´eliser ou d´evelopper des transformations de mod`eles. Ces outils adoptent l’une ou l’autre des approches d´ecrites dans la section pr´ec´edente, voire une combinaison de plusieurs m´ethodes. Du fait de leur faible niveau d’abstraction et de leur usage peu appropri´e pour d´evelopper des transformations complexes dans un contexte industriel, nous ne nous ´etendrons pas sur les outils de transformation de texte (type AWK, sed ou Perl). Outils g´en´eralistes Pour ´ecrire une transformation de mod`eles, il est n´ecessaire de s´electionner non seulement une approche, mais ´egalement un langage et un type d’outil. Si le MDA plaide en faveur 21. Plus exactement XQuery Update Facility [RCD+11] ´etant donn´e que XQuery 1.0 n’a pas de fonctionnalit´e pour modifier les donn´ees.2.2. Transformations de mod`eles 35 d’outils et de langages d´edi´es (DSL), il est tout `a fait possible d’´ecrire une transformation de mod`eles comme n’importe quel autre programme informatique, en choisissant un langage g´en´eraliste. On l’utilise g´en´eralement avec un framework fournissant des fonctionnalit´es pour manipuler les mod`eles. EMF. EMF [SBPM09] est un framework de mod´elisation ouvert initi´e par IBM. Int´egr´e `a l’environnement Eclipse, il comprend une infrastructure de g´en´eration de code pour d´evelopper des applications `a partir de mod`eles pouvant ˆetre sp´ecifi´es en utilisant UML, XML ou Java. Ces mod`eles peuvent ensuite ˆetre import´es et manipul´es avec les services fournis par EMF. Le m´etamod`ele central du framework est Ecore. Il est align´e sur EMOF (le passage de l’un `a l’autre consiste essentiellement en quelques renommages), ce qui en fait son impl´ementation de r´ef´erence. Compte tenu de l’environnement (Eclipse) dans lequel il est int´egr´e, ainsi que du langage de programmation g´en´eraliste utilis´e (Java) et des standards li´es (XML et UML), EMF est une technologie int´eressante dans le cas d’un d´eveloppement de transformation par des utilisateurs « non sp´ecialistes » 22. Il a l’avantage d’ˆetre bien outill´e et maintenu, de b´en´eficier d’une large communaut´e d’utilisateurs et de pouvoir facilement ˆetre coupl´e avec les outils des ´ecosyst`emes Java, UML et XML. Nous reparlerons par la suite de EMF qui nous a servi de technologie de support pour le d´eveloppement de nos outils. XML. Une famille d’outils utilisables pour les transformations est celle de l’espace technique XML. Les mod`eles sont des arbres conformes `a des sch´emas, et des outils de transformation tels que XSLT [W3C99] et XQuery Update Facility [RCD+11] permettent de parcourir et transformer les documents XML. Bien que verbeuse, la syntaxe XML a l’avantage d’ˆetre simple et tr`es r´epandue. Beaucoup d’outils et d’applications utilisant nativement XML, il peut ˆetre int´eressant d’avoir une vision arbre XML des mod`eles. Ces outils peuvent aussi ˆetre utilis´es en conjonction de frameworks tels que EMF sans adaptation majeure, ceux-ci ayant g´en´eralement une fonctionnalit´e de s´erialisation XML (standard XMI de l’initiative MDA). Outils de transformation d’arbres. Les outils g´en´eralistes de transformation d’arbres — plus couramment associ´es aux mondes de la compilation, de l’analyse de code et de la r´e´ecriture qu’`a l’IDM — ont aussi leur rˆole `a jouer en IDM et peuvent fournir une base technique solide pour la construction d’autres outils. Outre le langage Tom [MRV03, BBK+07, BB+13] sur lequel nous nous sommes appuy´es pour ce travail, d’autres outils de la communaut´e pr´esentent un int´erˆet certain. Notons par exemple Rascal 23 [KHVDB+11, KvdSV11], le langage de m´etaprogrammation con¸cu pour l’analyse de programmes qui succ`ede `a ASF+SDF [BDH+01]. Il existe sous forme d’un plugin Eclipse et permet d’analyser, d’effectuer des requˆetes et de transformer des programmes sous la forme de mod`eles conformes `a M3 24 . Pour le mˆeme type d’utilisation, l’outil Spoofax 25 [KV10] — lui aussi disponible sous forme d’un plugin Eclipse — int`egre Stratego [VBT98],[Vis01a] et SDF. Il permet d’´ecrire des transformations de programmes en utilisant des r`egles et des strat´egies de r´e´ecriture. Le syst`eme Maude 26[CM96, CELM96, CDE+02] est un autre outil de r´e´ecriture. Il comprend une infrastructure orient´ee objet permettant d’impl´ementer des mod`eles et m´etamod`eles. Des travaux ont ´et´e men´es dans ce sens par plusieurs ´equipes [RRDV07, RV08, Rus11], 22. Nous d´esignons par utilisateur non sp´ecialiste tout utilisateur ayant b´en´efici´e d’une formation satisfaisante en informatique avec un socle th´eorique minimal, un apprentissage de la programmation orient´ee objet, ainsi que l’utilisation d’outils tels que Eclipse. Par exemple, un jeune ing´enieur en d´ebut de carri`ere est un d´eveloppeur non sp´ecialiste. Son expertise est donc bien sup´erieure `a celle d’un ´etudiant n’ayant pas encore re¸cu de formation, mais inf´erieure `a celle d’un ing´enieur expert de son domaine depuis de longues ann´ees. 23. Voir http://www.rascal-mpl.org/. 24. M´etamod`ele g´en´erique pour repr´esenter du code pars´e dans Rascal, http://tutor.rascal-mpl.org/ Rascal/Libraries/lang/java/m3/m3.html. 25. Voir http://strategoxt.org/Spoofax/. 26. Voir http://maude.cs.uiuc.edu/.36 Chapitre 2. Transformations de mod`eles ce qui a donn´e naissance `a divers outils dont le projet MOMENT27 qui permet d’effectuer des transformations de mod`eles EMF avec Maude [BM09, BO10]. ¨ Outils de r´e´ecriture de graphes. L’une des repr´esentations de mod`eles pouvant ˆetre le graphe, l’utilisation d’outils de r´e´ecriture de graphes est une approche qui a ´et´e exp´eriment´ee [Tae10, SK08] en utilisant des outils cat´egoriques tels que le single-pushout et le doublepushout, ainsi que le formalisme de sp´ecification Triple Graph Grammar (TGG) [K¨on05]. Dans cette cat´egorie d’outils, on notera Moflon 28 qui repose sur le m´ecanisme TGG pour impl´ementer des transformations de mod`eles [AKRS06], Henshin 29[ABJ+10] reposant sur le syst`eme AGG 30[Tae04], ainsi que VIATRA2 31 [VB07]. Du fait de la complexit´e des algorithmes li´es `a la transformation de graphes — et donc des ressources n´ecessaires pour transformer efficacement des graphes de grande taille —, le principal probl`eme de l’approche par r´e´ecriture de graphes r´eside dans le coˆut ´elev´e des transformations et la difficult´e de passer `a l’´echelle. Outils d´edi´es La solution largement mise en avant en IDM pour le d´eveloppement de transformations de mod`eles est l’utilisation de langages d´edi´es. On pense notamment au standard QVT [OMG08] propos´e par l’initiative MDA. QVT. Il est compos´e de trois langages de transformation diff´erents, comme illustr´e par la figure 2.4 : d’une part QVT-Relations et QVT-Core pour la partie d´eclarative, d’autre part QVT-Operational pour la partie imp´erative. RelationsToCore Operational Transformation Mappings Relations Core Black Box Figure 2.4 – Architecture du standard QVT [OMG08]. QVT-Relations et QVT-Core constituent la partie d´eclarative de QVT. QVT-Relations est un langage orient´e utilisateur avec une syntaxe textuelle et graphique permettant de d´efinir des transformations `a un niveau d’abstraction ´elev´e (repr´esentation graphique possible). QVTCore est quant `a lui plus bas niveau avec uniquement une syntaxe textuelle. Il sert `a sp´ecifier la s´emantique de QVT-Relations sous la forme d’une transformation Relations2Core. L’expression d’une transformation avec QVT d´eclaratif est une association de motifs (patterns) entre la source et la cible. Bien que relativement complexe `a prendre en main, il permet de d´efinir des transformations bidirectionnelles. OptimalJ ´etait une impl´ementation commerciale de QVTCore, mais son d´eveloppement a cess´e. Les outils Medini-QVT 32 , Eclipse MMT (anciennement Eclipse M2M 33) ainsi que MOMENT [BM09] impl´ementent quant `a eux QVT-Relations. Le langage QVT-Operational supporte la partie imp´erative de QVT. De par la nature mˆeme du style imp´eratif, la navigation et la cr´eation d’´el´ements du mod`ele cible sont explicites. QVTOperational ´etend QVT-Relations et QVT-Core par ajout de constructions imp´eratives telles 27. Voir http://moment.dsic.upv.es/. 28. Voir http://www.moflon.org/. 29. Voir http://www.eclipse.org/modeling/emft/henshin/. 30. Attributed Graph Grammar : http://user.cs.tu-berlin.de/~gragra/agg/. 31. Sous-projet de GMT : http://www.eclipse.org/gmt/. 32. http://projects.ikv.de/qvt/wikia 33. http://www.eclipse.org/m2m/2.3. Limitations actuelles et points d’am´elioration 37 que la s´equence, la r´ep´etition, la s´election, etc. ainsi que par des constructions OCL. SmartQVT et Eclipse MMT Operational QVT impl´ementent QVT-Operational. QVT-like. Les outils dont nous allons parler ici n’impl´ementent pas, `a proprement parler, le standard QVT, mais sont cependant suffisamment proches et similaires pour ˆetre souvent class´es dans la cat´egorie des QVT-like. Le premier d’entre eux est tr`es certainement ATL 34 [BDJ+03, BJRV05, JK06, JABK08] : il s’agit d’un des langages les plus utilis´es dans la communaut´e des mod`eles et est int´egr´e dans l’environnement Eclipse [AI04]. Il permet de sp´ecifier une transformation d’un ensemble de mod`eles sources en un ensemble de mod`eles cibles. Ecrire un programme ´ ATL consiste `a ´ecrire des r`egles (rules) en donnant une source et une cible. Une r`egle peut faire appel `a des fonctions d’aide (helper ) permettant d’effectuer un traitement (collecte de valeurs dans une liste, etc.). Outre ATL, d’autres outils QVT-like existent, notamment Tefkat 35 [LS06] (qui propose une syntaxe `a la SQL et offre une impl´ementation de QVT-Relations), GReAT [AKS03, BNvBK07] et VIATRA2 [VB07], qui sont des outils de transformation de graphes. Ces deux derniers sont distribu´es sous forme d’un plugin Eclipse ce qui leur permet d’interagir avec l’environnement EMF. Enfin, dans cette cat´egorie d’outils, nous pouvons ajouter JQVT36 qui est un moteur QVT pour Java. Il est int´egr´e dans Eclipse, est compatible avec EMF et n’utilise pas OCL, mais Xbase 37 . Kermeta. Il s’agit d’un environnement de m´etamod´elisation dans Eclipse. Il permet de d´e- finir et sp´ecifier des langages de mod´elisation d´edi´es. Le langage Kermeta 38 [DFF+10] mˆele plusieurs paradigmes de programmation (orient´e objet, orient´e aspects [MFJ05, MFV+05], par contrats, fonctionnel) et fournit un support complet de Ecore et de EMOF. Ainsi, tout mod`ele Kermeta conforme `a EMOF est aussi un programme Kermeta valide. Une d´efinition Kermeta peut ˆetre compil´ee pour produire un mod`ele ex´ecutable. Le code g´en´er´e est exprim´e en Java et Scala, qui peut ˆetre ensuite compil´e pour ˆetre ex´ecut´e sur la machine virtuelle Java. 2.3 Limitations actuelles et points d’am´elioration Le lancement de l’initiative MDA a donn´e un v´eritable ´elan `a l’IDM et de nombreux outils ont vu le jour. Cependant, malgr´e l’int´erˆet ind´eniable de cette approche pour le d´eveloppement logiciel, l’IDM n’est pas encore fortement ´etablie dans les chaˆınes de d´eveloppement industrielles et gagne lentement du terrain. La complexit´e des syst`emes s’accroissant, l’industrie voit dans l’IDM une solution pour am´eliorer leur d´eveloppement tout en diminuant leurs coˆuts. En effet, pour appr´ehender cette complexit´e, il est n´ecessaire pour les d´eveloppeurs d’abstraire les probl`emes. Pour ce faire, il faut des outils accessibles et utilisables dans un cadre industriel. La grande diversit´e des outils peut aussi ˆetre un frein `a l’adoption des techniques de l’IDM : un trop grand nombre d’outils et de technologies segmente le domaine, ce qui peut empˆecher que les communaut´es atteignent une masse critique. De plus, beaucoup d’outils adoptant les concepts de l’IDM sont issus de la recherche et sont utilis´es par un public acad´emique. N’ayant pas forc´ement vocation `a industrialiser les prototypes d´evelopp´es, le monde de la recherche produit souvent des outils peu accessibles tant sur leur forme (ergonomie, non conformit´e aux pratiques industrielles habituelles) que sur le fond (concepts peu connus et maˆıtris´es par peu de monde, expertise n´ecessaire). Ce frein li´e `a la multiplicit´e des outils peu accessibles peut ˆetre lev´e par l’´etablissement de standards tels que ceux propos´es par l’OMG, ainsi que par le d´eploiement d’environnements comme Eclipse pour pousser `a la cristallisation et au d´eveloppement de communaut´es autour des technologies li´ees. 34. http://www.eclipse.org/atl/ 35. http://tefkat.sourceforge.net/ 36. http://sourceforge.net/projects/jqvt/ 37. https://wiki.eclipse.org/Xbase 38. http://www.kermeta.org38 Chapitre 2. Transformations de mod`eles Un autre aspect limitant vient de l’adaptation des chaˆınes de d´eveloppement logicielles existantes `a ces nouvelles m´ethodes de d´eveloppement et `a ces nouveaux outils. Compte tenu de leur coˆut d’int´egration et des changements induits par une telle modification d’un processus de d´eveloppement, il n’est pas raisonnable d’adopter un nouvel outil encore `a l’´etat de prototype ou n´ecessitant des comp´etences sp´ecifiques maˆıtris´ees par un petit nombre d’experts ou encore n’ayant aucun lien avec des technologies d´ej`a pr´esentes dans la chaˆıne de d´eveloppement existante. Il faut donc mettre en œuvre des ponts entre les technologies pour les rendre plus attrayantes et plus facilement int´egrables, afin de faciliter ce processus fortement consommateur de ressources. Outre l’adaptation normale des chaˆınes de d´eveloppement aux nouveaux outils, certains domaines ont des contraintes strictes de qualit´e concernant les outils de production du logiciel. C’est le cas des chaˆınes de d´eveloppement des syst`emes critiques que l’on retrouve notamment en a´eronautique, dans le secteur automobile, ainsi que dans celui de la sant´e. Les logiciels produits et servant `a produire sont soumis `a des exigences l´egales n´ecessitant des processus lourds de validation du logiciel. Le domaine de l’IDM ´etant relativement jeune, il n’est pas encore pleinement adopt´e dans ce type d’industrie qui a besoin d’outils adapt´es `a ses contraintes permettant de faciliter la validation du logiciel `a moindre coˆut (et pr´esenter ainsi un int´erˆet sup´erieur par rapport `a l’existant). L’un des aspects les plus int´eressants est l’usage de l’IDM dans le cadre du d´eveloppement fiable : pour les probl´ematiques l´egales ´evoqu´ees pr´ec´edemment, la demande industrielle est tr`es forte, et peu de r´eponses concr`etes existent ou alors pour des coˆuts d´eraisonnables. C’est dans ce contexte que nous nous proposons d’apporter un ´el´ement de solution avec ce travail, afin d’accompagner l’adoption de nouveaux outils tout en am´eliorant la qualit´e du logiciel. Nous abordons la probl´ematique de la validation du logiciel dans le chapitre 3.Chapitre 3 V´erification du logiciel Il est extrˆemement difficile de garantir l’absence totale d’erreurs dans un logiciel. Et cette tˆache est d’autant plus ardue que le logiciel est complexe. Les bogues pouvant avoir des cons´equences d´esastreuses et coˆuteuses, il est n´ecessaire de valider, v´erifier et tester le logiciel avant leur mise en production. Dans ce chapitre, nous pr´esentons le contexte de la v´erification du logiciel dans lequel ce travail s’inscrit. Nous expliquons diff´erentes approches pour v´erifier le logiciel 3.1. Nous pr´esentons aussi la qualification et la certification 3.2 qui exigent une tra¸cabilit´e. 3.1 Approches pour la v´erification du logiciel Dans cette section, nous abordons diff´erentes mani`eres de v´erifier le logiciel afin d’en am´eliorer sa qualit´e, et donc la confiance que l’utilisateur peut avoir dans les logiciels qu’il utilise. Nous pr´esentons d’abord des approches logicielles pratiques comme la relecture, les tests et la simulation, puis la preuve et le model-checking qui sont des approches formelles. Ces m´ethodes pour v´erifier le logiciel et am´eliorer sa qualit´e sont g´en´eralement utilis´ees de mani`ere conjointe, selon le niveau d’exigence vis´e (les contraintes pour une application sur ordiphone ne sont pas les mˆemes que pour celles d’un calculateur de vol). 3.1.1 Relecture Une premi`ere approche ´evidente pour tout d´eveloppeur est la relecture de code. Informelle, elle consiste `a parcourir du code d´evelopp´e pr´ec´edemment et `a s’assurer qu’il est conforme aux exigences. Pour am´eliorer la fiabilit´e d’une relecture, la tendance est de faire relire du code d’un d´eveloppeur `a un autre d´eveloppeur n’ayant pas particip´e au d´eveloppement, et de croiser les relectures. Cependant, si cette m´ethode est largement r´epandue et encourag´ee, elle est loin d’ˆetre fiable. En effet, la relecture d´epend totalement d’un relecteur humain dont l’´etat au moment de la relecture (comp´etences, fatigue, concentration, etc.) conditionne le r´esultat. Si la relecture permet de rep´erer les bogues les plus ´evidents, elle permet difficilement de rep´erer les plus subtils. De plus, d´ependant des comp´etences et de l’exp´erience du relecteur, cette m´ethode est fortement soumise `a son intuition. Une v´erification d’un logiciel par relecture pourra ainsi ˆetre tr`es diff´erente selon le d´eveloppeur. Si la relecture est indispensable dans tout d´eveloppement, elle n’est pas suffisante pour du logiciel exigeant une forte fiabilit´e. Elle pr´esente toutefois l’avantage d’ˆetre naturelle `a tout d´eveloppeur ayant suivi une formation ad´equate 39 et d’ˆetre peu coˆuteuse : en effet, elle ne n´ecessite pas de comp´etences et d’outils suppl´ementaires qu’il a ´et´e n´ecessaire pour ´ecrire le logiciel `a relire. Cette approche de 39. La relecture fait partie int´egrante de la m´ethodologie du d´eveloppement g´en´eralement enseign´ee dans les formations en informatique. 3940 Chapitre 3. V´erification du logiciel v´erification peut ´eventuellement ˆetre suffisante pour des applications peu complexes, non critiques et peu diffus´ees (par exemple : un script pour renommer des fichiers dans un r´epertoire personnel). Elle reste efficace pour trouver des erreurs et constitue un ´el´ement fondamental de certaines approches agiles. 3.1.2 Tests Une seconde approche est de tester tout programme informatique avant sa mise en production, l’intensit´e des tests permettant d’obtenir plus d’assurance. Il existe diverses m´ethodologies et techniques pour tester du code. On citera par exemple la mise en place de tests unitaires cens´es tester des unit´es de code (fonctions, classes). Des frameworks d´edi´es aux tests unitaires ont ainsi ´et´e d´evelopp´es, comme par exemple JUnit 40. Cela a ´et´e popularis´e par les m´ethodes agiles, notamment eXtreme Programming [BA04] qui repose en partie sur l’approche dirig´ee par les tests (Tests Driven Development [Bec03]). Remarquons que les sc´enarios de tests peuvent ˆetre consid´er´es comme une forme de sp´ecification. Bien que l’utilisation de tests permette d’am´eliorer grandement la qualit´e du logiciel durant sa phase de d´eveloppement en r´eduisant les d´efauts [WMV03], la solution des tests unitaires commence `a montrer ses limites lors de d´eveloppements de logiciels complexes o`u les bogues peuvent avoir des origines plus nombreuses. Du fait des coˆuts et des d´elais de d´eveloppement, il n’est pas rare de ne pas ´ecrire de tests pour se concentrer sur le logiciel lui-mˆeme. Par cons´equent, certaines parties de code ne sont pas test´ees et sont donc susceptibles de contenir des bogues. Des techniques de g´en´eration automatique de tests ont vu le jour pour augmenter la couverture de tests et tester au maximum les cas limites. Nous noterons par exemple QuickCheck [CH00, Hug10] pour tester les programmes Haskell, ainsi que ses impl´ementations et variantes pour d’autres langages tels que Scala 41 , Dart 42 , Java 43 , Ruby 44 , Python 45 , etc. Ces m´ethodes ont ´et´e transpos´ees dans le cadre de l’IDM. L’approche dirig´ee par les tests [GP09] s’est d´evelopp´ee, et des travaux de v´erification par le test ont ´et´e men´es pour les transformations de mod`eles [FSB04]. Des frameworks de test [LZG05], ainsi que des outils de g´en´eration de tests [BFS+06, Lam07, SBM09] et de g´en´eration de code tests [RW03] ont donc aussi vu le jour, accompagn´es d’outils et de techniques de qualification des donn´ees de tests pour les transformations de mod`eles [FBMT09]. Les tests permettent de d´etecter des comportements anormaux, mais d’autres comportements anormaux peuvent aussi naˆıtre d’une combinaison de comportements normaux de modules fonctionnels ind´ependamment. Le probl`eme pouvant alors provenir d’une incompr´ehension entre les ´equipes de d´eveloppeurs ou entre le client et le fournisseur (sp´ecification ambigu¨e). Si l’int´egration de tests est absolument n´ecessaire dans le processus de d´eveloppement d’un logiciel, elle se r´ev`ele insuffisante dans le cas du logiciel critique. En effet, tester intens´ement un logiciel permet de tester son comportement dans la plupart des cas, mais rien ne garantit que toutes les situations ont ´et´e test´ees. 3.1.3 Simulation Il peut aussi ˆetre extrˆemement difficile de tester correctement un syst`eme du fait de sa complexit´e, des fortes ressources demand´ees ou de la particularit´e de sa plateforme d’ex´ecution. Les tests ´ecrits et men´es durant le d´eveloppement peuvent se r´ev´eler peu r´ealistes ou fort ´eloign´es des conditions r´eelles d’utilisation. Pour r´epondre `a ce probl`eme de r´ealisme du comportement d’un syst`eme sous conditions d’utilisation r´eelles, une approche li´ee aux tests revient `a simuler le syst`eme pour ´etudier son comportement et d´etecter les anomalies. L’int´erˆet de ce type d’approche est que l’on peut travailler sur un syst`eme qui serait coˆuteux `a 40. http://www.junit.org 41. ScalaCheck : http://code.google.com/p/scalacheck/ 42. PropCheck : https://github.com/polux/propcheck 43. QuickCheck pour Java [EF13] : https://bitbucket.org/blob79/quickcheck 44. RushCheck : http://rushcheck.rubyforge.org/ 45. qc : http://github.com/dbravender/qc3.1. Approches pour la v´erification du logiciel 41 d´eployer pour tester en conditions r´eelles. Notons par exemple les domaines du nucl´eaire ou de l’avionique qui ne permettent pas ais´ement (et `a faible coˆut) des tests logiciels en conditions r´eelles, en particulier lors des premi`eres ´etapes de d´eveloppement. L’inconv´enient de ce type de m´ethode de v´erification est qu’il faut reproduire fid`element un environnement et que les tests sont fortement conditionn´es par la plateforme d’ex´ecution sur lesquels ils sont ex´ecut´es et par les technologies employ´ees. Dans le cas d’une informatique simple, la simulation est une option int´eressante, mais sa difficult´e de mise en œuvre croˆıt avec la complexit´e du syst`eme (nombreuses d´ependances, syst`emes exotiques, mat´eriel non disponible hors chaˆıne de production d´edi´ee, mod`eles physiques complexes, etc.). Ainsi, en a´eronautique, il est extrˆemement complexe et coˆuteux de mod´eliser int´egralement l’environnement afin de simuler tous les syst`emes de l’avion. L’approche adopt´ee revient alors `a proc´eder `a une succession de phases simulant des mod`eles de l’environnement m´ecanique, physique, des calculateurs, du r´eseau, du logiciel, etc. La derni`ere ´etape avant le vol r´eel est l’Aircraft Zero — Iron Bird qui int`egre toute l’informatique r´eelle sur un banc d’essai. 3.1.4 Preuve A l’oppos´e de ces approches vues comme tr`es pragmatiques et largement utilis´ees dans ` l’industrie, une autre approche pour am´eliorer la confiance dans un logiciel consiste `a prouver formellement les algorithmes. Le probl`eme est alors formalis´e sous la forme d’axiomes et de buts qu’il faut atteindre en d´emontrant des th´eor`emes. Une preuve math´ematique peut ˆetre ´ecrite `a la main, mais pour faciliter le processus et pour diminuer les risques d’introduction d’erreurs li´ees au facteur humain, des outils assistants `a la preuve tels que Coq [The04, BC04] et Isabelle/HOL [NPW02] ont ´et´e d´evelopp´es. Une preuve Coq est cens´ee donner une forte confiance dans le logiciel d´evelopp´e et prouv´e. Cependant, si la preuve de la correction d’un algorithme donne une garantie irr´efutable du bon comportement de cet algorithme, elle ne donne pas obligatoirement la garantie du bon comportement du logiciel. En effet, ce sont les algorithmes et les sp´ecifications qui sont g´en´eralement formellement prouv´es et non les impl´ementations elles-mˆemes 46. Or, le facteur humain n’est pas `a n´egliger, l’impl´ementation concr`ete du logiciel d´ependant fortement du d´eveloppeur et des outils utilis´es durant le processus. En outre, lors d’une preuve, le contexte r´eel n’est pas forc´ement pris en compte et certaines conditions d’utilisation r´eelles peuvent fortement influencer le comportement et la fiabilit´e de l’application. 3.1.5 Model-checking Le model-checking est une autre approche formelle que l’on peut consid´erer comme ´etant entre preuve et test. Elle consiste `a abstraire (mod´eliser) un probl`eme ou un syst`eme selon un formalisme (langage) donn´e, puis `a explorer l’espace d’´etats possibles de ce syst`eme pour v´erifier qu’aucun ´etat ne viole une propri´et´e donn´ee (un invariant par exemple). On peut consid´erer que cela revient `a du test exhaustif, ce qui a donc valeur de preuve. L’int´erˆet du model-checking est que — contrairement aux tests — il est g´en´eralement ind´ependant de la plateforme d’ex´ecution et qu’il apporte une v´erification formelle du syst`eme. Par exemple, les outils CADP 47 [GLMS11] et TINA 48 [BRV04] sont deux model-checkers dont les formalismes d’expression des mod`eles sont respectivement LOTOS et les r´eseaux de Petri. On peut toutefois reprocher au model-checking de ne pas toujours ˆetre suffisamment proche de la r´ealit´e et d’avoir un coˆut en ressources ´elev´e dans le cas de syst`emes complexes. Cela a conduit certains `a compl´eter le model-checking par l’analyse `a l’ex´ecution sur des applications r´eelles simul´ees [BM05]. L’IDM reposant sur les mod`eles qui sont des abstractions de probl`emes, 46. « Beware of bugs in the above code ; I have only proved it correct, not tried it » – D.E. Knuth, 1977 ; citation et explication accessibles sur sa page personnelle : http://www-cs-faculty.stanford.edu/~uno/faq. html 47. http://cadp.inria.fr 48. http://projects.laas.fr/tina42 Chapitre 3. V´erification du logiciel il est naturel d’adopter le model-checking pour v´erifier le logiciel produit par ces m´ethodes. On peut adjoindre des contraintes aux mod`eles avec des langages tels qu’OCL dans le cas de UML, mais un mod`ele n’est pas n´ecessairement imm´ediatement v´erifiable. Il n´ecessite souvent une ou plusieurs transformations afin de pouvoir ˆetre v´erifi´e au moyen d’un model-checker. C’est une approche courante que d’op´erer une suite de transformations permettant de passer du mod`ele servant de sp´ecification au mod`ele v´erifiable, ainsi que de la sp´ecification vers l’application r´eelle. Cependant, comme pr´ec´edemment, il s’agit `a nouveau de v´erifier un mod`ele et non pas le code g´en´er´e r´eel. Chaque transformation se doit donc d’ˆetre simple afin que l’on puisse garantir la pr´eservation du comportement d’un pas `a l’autre. Ce type d’approche est tr`es utilis´e en IDM. Nous notons imm´ediatement qu’une telle approche pour s’assurer du bon fonctionnement du logiciel n´ecessite non seulement une v´erification du mod`ele, mais aussi une garantie que la transformation elle-mˆeme est correcte. 3.2 Certification et qualification Le processus de certification n’est pas n´ecessaire pour tous les logiciels et tous les secteurs d’activit´e. Il fait en revanche partie int´egrante du processus de d´eveloppement logiciel dans le cadre de d´eveloppement de syst`emes critiques, par exemple dans les domaines de l’a´eronautique, de l’automobile (du transport en g´en´eral) et de la sant´e. La loi impose le respect d’exigences en fonction de cr´edits de certification demand´es. D´efinition 31 (Cr´edit de certification). Acceptation par l’autorit´e de certification qu’un processus, un produit ou une d´emonstration satisfait les exigences de certification. D´efinition 32 (Certification). Processus d’approbation par une autorit´e de certification d’un produit. Ces exigences sont fix´ees par des standards de certification : en a´eronautique, le standard actuel est la norme DO-178C/ED-12C 49 [Spe11a]. Elle donne des objectifs (et non des moyens) dont le nombre et le niveau augmentent avec le niveau de criticit´e. Ces niveaux de criticit´e (ou niveaux DAL, pour Development Assurance Level) sont not´es de A `a E, A ´etant le plus critique, E le moins critique : Niveau A : (Erreur catastrophique) un d´efaut du syst`eme ou sous-syst`eme ´etudi´e peut provoquer un probl`eme catastrophique (s´ecurit´e du vol ou atterrissage compromis, crash de l’avion) ; Niveau B : (Erreur dangereuse) un d´efaut du syst`eme ou sous-syst`eme ´etudi´e peut provoquer un probl`eme majeur entraˆınant des d´egˆats s´erieux voire la mort de quelques occupants ; Niveau C : (Erreur majeure) un d´efaut du syst`eme ou sous-syst`eme ´etudi´e peut provoquer un probl`eme s´erieux entraˆınant un dysfonctionnement des ´equipements vitaux de l’appareil (pas de mort) ; Niveau D : (Erreur mineure) un d´efaut du syst`eme ou sous-syst`eme ´etudi´e peut provoquer un probl`eme pouvant perturber la sˆuret´e du vol (pas de mort) ; Niveau E : (Erreur sans effet) un d´efaut du syst`eme ou sous-syst`eme ´etudi´e peut provoquer un probl`eme sans effet sur la sˆuret´e du vol. Dans le cadre du processus de certification de syst`emes critiques, les outils utilis´es pour le d´eveloppement doivent ˆetre v´erifi´es afin de s’assurer de leur bon fonctionnement et qu’ils n’introduisent pas d’erreurs dans le logiciel. Les pratiques de d´eveloppement logiciel ´evoluant, notamment par l’adoption croissante de l’approche dirig´ee par les mod`eles qui plaide pour l’automatisation maximale des tˆaches, 49. La notation DO- correspond au nom donn´e `a ce standard aux Etats-Unis d’Am´erique, tandis que la ´ notation ED- est celle en vigueur en Europe.3.3. Tra¸cabilit´e 43 de nouveaux outils sont int´egr´es aux processus de d´eveloppement. L’introduction d’outils automatiques dans une chaˆıne de d´eveloppement de syst`eme soumis `a certification impose l’une des deux approches suivantes : — v´erifier les donn´ees produites par l’outil a posteriori ; — qualifier l’outil. La qualification d’un logiciel participe `a atteindre un objectif exig´e par le processus de certification et permet d’obtenir de la confiance dans les fonctionnalit´es d’un outil. Ce processus de qualification peut ˆetre appliqu´e `a une ou plusieurs fonctions dans un outil, `a un outil unique ou `a un ensemble d’outils. D´efinition 33 (Qualification). La qualification d’outils est le processus n´ecessaire pour obtenir des cr´edits de certification d’un outil. Ces cr´edits peuvent uniquement ˆetre garantis pour un usage donn´e dans un contexte donn´e. L’int´erˆet de la qualification d’un outil est d’obtenir suffisamment de confiance en cet outil pour pouvoir l’int´egrer dans une chaˆıne de d´eveloppement sans avoir `a v´erifier ses donn´ees de sortie ensuite. Le choix entre l’approche de qualification et de v´erification a posteriori revˆet un aspect strat´egique : si la qualification d’un outil peut avoir un coˆut ´elev´e fixe, elle n’en g´en`ere pas plus par la suite, tandis que la v´erification a posteriori aura un coˆut r´ecurrent. La DO-178/ED-12 d´efinit des cat´egories d’outils (sans impact, v´erification et compilateur, g´en´erateur de code) ainsi que des crit`eres de qualification. Elle pr´ecise les exigences de qualification adapt´ees aux diff´erents types d’outils et `a leur utilisation. La norme DO- 330/ED-251 [Spe11b] donne des instructions pour la qualification d’outils. Elle d´efinit aussi cinq niveaux de qualification d’outils (TQL — Tool Qualification Levels) qui sont fonction de ces trois crit`eres ainsi que de la criticit´e du logiciel d´evelopp´e : TQL-1 `a 3 : ces niveaux concernent les g´en´erateurs de code et outils dont la sortie fait partie du logiciel embarqu´e et qui peuvent donc introduire des erreurs ; TQL-4 `a 5 : ces niveaux concernent les outils de v´erification, qui ne peuvent pas introduire d’erreurs, mais qui peuvent ´echouer `a en d´etecter (outils de tests, analyseurs de code statique) Selon son utilisation et selon le type de production de l’outil, le niveau de qualification sera diff´erent. Un outil ne peut donc ˆetre qualifi´e une fois pour toutes. En revanche, il peut ˆetre qualifiable pour chaque projet, c’est-`a-dire pre qualifi´e pour chaque projet. L’IDM plaidant pour l’automatisation des tˆaches et l’usage d’outils automatisant les tˆaches, il faut v´erifier ces outils. Dans ce contexte, l’un des probl`emes majeurs de l’IDM est le grand nombre d’outils non qualifi´es et non certifi´es impliqu´es dans les chaˆınes de d´eveloppement, notamment des g´en´erateurs de code, des outils de traduction, et de mani`ere plus g´en´erale des outils automatisant au maximum les tˆaches de transformation. 3.3 Tra¸cabilit´e Une probl´ematique fondamentale des compilateurs dans le cadre de la certification d’un logiciel est d’assurer la tra¸cabilit´e entre le code source et le code binaire, ce qu’exige la norme DO-178/ED-12. Cette exigence pour les compilateurs et g´en´erateurs de code est g´en´eralisable `a toutes les transformations, donc aux transformations de mod`eles `a partir desquelles les logiciels sont produits. Assurer cette tra¸cabilit´e permet aussi de respecter la contrainte de s´eparation de le sp´ecification, de l’impl´ementation et de la v´erification tout en ´etant capable de relier les unes aux autres. D´efinition 34 (Tra¸cabilit´e). La norme DO-330 [Spe11b] d´efinit la tra¸cabilit´e comme une association entre objets telle qu’entre des sorties de processus, entre une sortie et son processus d’origine, ou entre une sp´ecification et son impl´ementation.44 Chapitre 3. V´erification du logiciel L’IDM plaidant pour l’automatisation maximale des tˆaches r´ep´etitives et l’utilisation de g´en´erateurs de code pour produire le logiciel `a partir de mod`eles, il est n´ecessaire de v´erifier les transformations qui en sont le cœur. L’un des angles d’attaque du probl`eme de la qualifi- cation est de fournir des outils de transformations qualifiables, qui assurent la tra¸cabilit´e des transformations. Dans le cas d’une transformation de mod`ele, le m´etamod`ele source fait partie de la sp´ecification et le mod`ele source la donn´ee d’entr´ee. Il convient donc de conserver une trace de la transformation en maintenant un lien entre la source et la cible. On retrouve souvent deux situations : — la trace se fait au niveau macroscopique (mod`ele d’entr´ee et mod`ele de sortie) et la granularit´e est extrˆemement faible, ce qui rend la trace peu informative ; — la trace s’op`ere de mani`ere tr`es d´etaill´ee (comme un debug) ce qui g´en`ere une trace importante de tout ce qui s’est produit durant la transformation. Si toutes les informations sont pr´esentes, se pose le probl`eme de la pertinence des donn´ees recueillies : la quantit´e d’informations peut rendre la trace inexploitable, les ´el´ements jug´es int´eressants risquant d’ˆetre noy´es dans la trace. Outre le respect strict des exigences de qualification, les informations de trace peuvent ˆetre tr`es utiles pour des tˆaches telles que le debugging ou l’analyse d’impact (cons´equences d’une modification). La tra¸cabilit´e des transformations de mod`ele est un aspect important que la plupart des outils traitent en apportant un support d´edi´e, comme pour les outils QVT, ATL, Tefkat ou Kermeta [FHN+06]. D’autres outils tels que AGG, VIATRA2 et GReAT n’ont pas de support d´edi´e `a cette tra¸cabilit´e, cependant les informations de trace peuvent ˆetre cr´e´ees comme des ´el´ements cibles. G´en´eralement, la tra¸cabilit´e est class´ee en deux cat´egories : explicite et implicite. La premi`ere signifie que les liens de trace sont directement captur´es en utilisant explicitement une syntaxe concr`ete ad´equate. La tra¸cabilit´e implicite est quant `a elle le r´esultat d’une op´eration de gestion des mod`eles (une requˆete sur des artefacts g´en´er´es par exemple). Un probl`eme r´ecurrent de l’impl´ementation de la tra¸cabilit´e est qu’elle est souvent fortement li´ee `a l’impl´ementation de la transformation, ce qui est probl´ematique dans le cadre de la qualification qui impose de pr´eserver une s´eparation entre l’impl´ementation et la sp´ecification. Pour la qualification, il faut donc fournir des informations pertinentes sans qu’elles soient perdues dans la masse de donn´ees, tout en ayant une tra¸cabilit´e qui soit suffisamment d´ecoupl´ee `a l’impl´ementation, mais donnant une granularit´e interm´ediaire. C’est dans ce contexte que nous nous proposons de travailler, et nous proposons de fournir des outils permettant d’aider `a la qualification de transformations de mod`eles.Deuxi`eme partie Contributions 45Chapitre 4 Transformations de mod`eles par r´e´ecriture Dans ce chapitre, nous expliquons l’approche que nous avons adopt´ee pour mettre en œuvre les transformations de mod`eles. Dans la section 4.1, nous pr´esentons l’aspect hybride de notre approche, les choix li´es ainsi que son int´erˆet. Nous abordons ensuite la probl´ematique de la repr´esentation des mod`eles dans notre approche dans la section 4.2. Nous expliquons dans la section 4.3 les m´ecanismes en jeu pour notre approche de transformation de mod`eles par r´e´ecriture. 4.1 Choix et int´erˆet d’une approche hybride Si le principe de la transformation elle-mˆeme est un principe qui peut sembler classique, car adopt´e par d’autres outils tels que QVT ou ATL, notre environnement de travail est tr`es diff´erent de celui des autres outils, ce qui fait l’originalit´e de notre approche. Comme nous l’avons vu dans le chapitre 2, il existe de multiples approches pour impl´ementer des transformations de mod`eles. L’un des choix possibles est d’opter pour une approche par programmation en utilisant un langage g´en´eraliste tel que Java. On lui adjoint un framework et un ensemble de biblioth`eques pour faciliter la repr´esentation et la manipulation de mod`eles, notamment EMF. Ensuite, la transformation revient `a l’´ecriture d’un programme qui charge un mod`ele en entr´ee et produit un mod`ele en sortie. Cette approche pr´esente certains avantages. Les langages g´en´eralistes sont habituellement plus accessibles `a la plupart des d´eveloppeurs tant par le fait qu’une formation d’informaticien comprend g´en´eralement l’apprentissage de langages g´en´eralistes que par le fait que ces langages suivent des paradigmes de programmation bien identifi´es. En outre, cette plus grande accessibilit´e a aussi pour effet de faciliter le d´eveloppement de communaut´es, ainsi que d’outils d’aide au d´eveloppement (IDE, biblioth`eques, etc.) et de documentation. Ces effets entretiennent alors le cercle vertueux de la facilit´e d’acc`es. A l’oppos´e, il peut ˆetre difficile ou long d’impl´ementer une transformation ` complexe alors qu’un langage d´edi´e proposerait les constructions ad´equates pour ce type de tˆache. Une deuxi`eme possibilit´e est de suivre les recommandations MDA qui encouragent l’utilisation de DSL. Cela a l’avantage d’ˆetre exactement adapt´e `a la tˆache vis´ee. L’inconv´enient est que les DSL ont g´en´eralement une visibilit´e plus limit´ee, avec des communaut´es plus petites et un outillage moins ´etoff´e. De plus, la comp´etence est plus difficile `a trouver ou induit des coˆuts de formation plus ´elev´es. Notre approche est une approche hybride, pour combler le foss´e entre les langages g´en´eralistes et d´edi´es, afin de b´en´eficier du meilleur des deux mondes. Nous proposons d’utiliser le langage Tom pour exprimer des transformations de mod`eles, ce qui nous permet de nous int´egrer dans des langages g´en´eralistes tout en apportant des fonctionnalit´es suppl´ementaires 4748 Chapitre 4. Transformations de mod`eles par r´e´ecriture par ses constructions. Comme pr´esent´e dans le chapitre 1, Tom repose sur le calcul de r´e´ecriture et impl´emente la fonctionnalit´e de strat´egie de r´e´ecriture, ce qui permet de d´ecoupler les r`egles m´etier du parcours des structures de donn´ees. Nous proposons donc de transformer des mod`eles par r´e´ecriture, en nous appuyant sur les strat´egies. Manipulant des termes, il nous faut repr´esenter les mod`eles sous cette forme pour pouvoir les transformer. Nous avons aussi fait le choix d’une int´egration dans un environnement de production pouvant ˆetre consid´er´e comme typique, `a savoir l’´ecosyst`eme Java. De plus, nous avons choisi de travailler dans un premier temps avec une technologie courante et tr`es utilis´ee — EMF — qui devient un standard de fait. Partant de ces choix et de nos contraintes, notre approche consiste `a exprimer un mod`ele EMF sous la forme d’un terme puis `a le transformer par r´e´ecriture. Nous op´erons donc des transformations de mod`eles en changeant d’espace technologique pour pouvoir nous appuyer sur nos m´ethodes et outils d´ej`a ´eprouv´es. Nous d´ecrivons le premier aspect de notre approche — la repr´esentation des mod`eles — dans la section 4.2, puis nous d´etaillons les principes mis en œuvre dans une transformation dans la section 4.3. 4.2 Repr´esentation de mod`eles par une signature alg´ebrique R´e´ecrivant des termes, la premi`ere ´etape de notre approche est d’´elaborer une repr´esentation ad´equate des mod`eles. Compte tenu de ce besoin et de notre approche, nous proc´edons en premier lieu par `a un changement d’espace technologique. Un m´etamod`ele dans le monde des mod`eles correspond `a une signature dans celui des termes, tandis qu’un mod`ele — conforme `a son m´etamod`ele — correspond `a un terme — conforme `a sa signature alg´ebrique —. Lors de ce changement, un aspect a priori probl´ematique de notre repr´esentation sous forme de terme d’un mod`ele vient du fait qu’un terme est une structure arborescente tandis qu’un mod`ele est g´en´eralement vu comme un graphe (un ensemble de nœuds et d’arcs). Une transformation de mod`ele est donc une fonction de transformation de graphe qu’il faut encoder dans notre contexte. L’un des aspects de notre approche est d’op´erer une transformation pr´ealable permettant de consid´erer une transformation de mod`eles comme une transformation de termes. Cela est possible ´etant donn´e que l’on obtient un arbre de recouvrement par la relation de composition, ce qui nous permet d’´etablir une vue ad´equate des mod`eles sous la forme d’un terme. Nous avons donc d´evelopp´e un outil — appel´e Tom-EMF — que nous d´ecrivons techniquement dans le chapitre 6, et qui, pour un m´etamod`ele EMF Ecore donn´e, produit sa signature alg´ebrique Tom correspondante, utilisable dans un programme Tom+Java. Bien que cet outil repose pour le moment sur une technologie particuli`ere, il est tout `a fait possible de l’´etendre ou d’´ecrire un outil similaire adapt´e `a d’autres technologies. Dans notre repr´esentation, pour chaque m´etaclasse, une sorte lui correspond, ainsi qu’un op´erateur. Une m´etaclasse pouvant avoir des attributs et des op´erations, l’op´erateur a les champs correspondants. Les relations sont repr´esent´ees par des attributs simples dans le cas d’associations. Dans le cas de relations de composition, des sortes et op´erateurs variadiques additionnels sont cr´e´es, et un attribut de ce type est ajout´e `a l’op´erateur ayant la relation de composition. Pour illustrer notre propos, consid´erons un m´etamod`ele simple permettant de d´ecrire des graphes (figure 4.1). Un graphe (Graph) est compos´e de Nodes et d’Arcs. Chaque arc a un poids, une source et une cible. Ces extr´emit´es sont de type Node, un Node pouvant avoir plusieurs arcs entrants et sortants. La repr´esentation sous forme de signature alg´ebrique de ce m´etamod`ele est alors donn´ee par le listing 4.1. Les m´etaclasses Graph, Node et Arc ont chacune une sorte qui lui correspond (nous avons conserv´e les mˆeme noms). Un op´erateur — pr´efix´e par op dans l’exemple — est associ´e `a chacune d’entre elles. Les attributs pr´esents dans les m´etaclasses sont bien report´es au niveau des op´erateurs (name et weight). Les relations4.3. Transformation de mod`eles par r´e´ecriture 49 Graph Arc weight : Int Node name : String nodes * graph 1 arcs * graph 1 source 1 * outgoings target 1 * incomings Figure 4.1 – M´etamod`ele des graphes. d’association sont traduites par des param`etres additionnels : l’op´erateur opArc poss`ede ainsi deux param`etres suppl´ementaires source et target. Le cas des relations de composition (relations nodes et arcs) est trait´e par la cr´eation d’op´erateurs variadiques (opNodeList et opArcList dans notre exemple) ainsi que de leurs sortes associ´ees (NodeList et ArcList). Graph = opGraph(nodes:NodeList, arcs:ArcList) Node = opNode(name:String, graph:Graph, incomings:ArcList, outgoings:ArcList) Arc = opArc(weight:Int, graph:Graph, source:Node, target:Node) NodeList = opNodeList(Node*) ArcList = opArcList(Arc*) Listing 4.1 – Signature alg´ebrique correspondant au m´etamod`ele de la figure 4.1. Grˆace `a ce changement d’espace technologique, nous encodons la fonction qui transforme un mod`ele non plus comme une fonction de r´e´ecriture de graphe, mais comme une fonction de r´e´ecriture de termes. 4.3 Transformation de mod`eles par r´e´ecriture Etant en mesure de repr´esenter des mod`eles sous forme de termes, nous pouvons d´ecrire ´ notre approche pour les transformer. Son principe est similaire `a celui de l’approche de QVT et ATL et peut sembler classique dans le domaine des mod`eles. Toutefois, ce n’est pas le cas dans l’environnement dans lequel nous ´evoluons, et plus g´en´eralement dans le domaine des outils de transformation g´en´eralistes d´edi´es aux arbres. Habituellement, `a l’instar d’un compilateur, les outils de transformation d’arbres proc`edent `a des parcours et `a des modifications successives sur un arbre qui est pass´e de phase en phase de l’outil. Dans notre approche, nous d´ecomposons les transformations en deux phases distinctes. La premi`ere est une transformation par parties qui consiste `a cr´eer les ´el´ements cibles du mod`ele r´esultant ainsi que des ´el´ements additionnels que nous appelons ´el´ements resolve, en r´ef´erence au resolve de QVT et au resolveTemp d’ATL. Ces ´el´ements permettent de faire r´ef´erence `a des ´el´ements qui n’ont pas encore ´et´e cr´e´es par la transformation. La seconde phase, quant `a elle, a pour objectif de rendre le mod`ele cible r´esultat coh´erent, c’est-`a-dire conforme au m´etamod`ele cible en ´eliminant les ´el´ements resolve et en les rempla¸cant par des r´ef´erences vers50 Chapitre 4. Transformations de mod`eles par r´e´ecriture les ´el´ements effectivement cr´e´es par la transformation. Cette seconde phase n’ajoute aucun nouvel ´el´ement cible au r´esultat. Pour illustrer notre propos dans ce chapitre, nous nous appuierons sur un exemple visuel permettant de bien comprendre le m´ecanisme de d´ecomposition-r´esolution. Supposons que nous souhaitons transformer une s´equence A;B textuelle en sa forme graphique correspondante comme d´ecrit par la Figure 4.2. Dans cet exemple, le choix des couleurs des connecteurs est arbitraire : nous aurions tr`es bien pu choisir de colorer le cercle en vert et le carr´e en bleu. Supposons donc que ce d´ecoupage est sp´ecifi´e et impos´e. A ;B −→ Figure 4.2 – Transformation du mod`ele source A;B en un mod`ele cible graphique. 4.3.1 Approche compositionnelle Une fois le probl`eme de la repr´esentation des mod`eles r´esolu, il est possible d’instancier un mod`ele (cr´eation d’un terme conforme `a la signature alg´ebrique) et d’op´erer une transformation sur le terme le repr´esentant. L’´ecriture d’une transformation de mod`eles peut se faire par une approche proc´edurale monolithique. L’utilisateur construit la transformation par ´etapes (transformation steps), dont l’ordre s’impose naturellement en fonction des besoins des diff´erents ´el´ements : par exemple, la transformation d´ecrite dans la Figure 4.2 peut se d´ecomposer en trois ´etapes que nous illustrons dans la Figure 4.3. A −→ (a) ; −→ (b) B −→ (c) Figure 4.3 – R`egles de transformation de A, ; et B. La transformation de A (´etape (a)) donne un hexagone et un cercle rouges connect´es, celle de B (´etape (c)) un pentagone et un connecteur bleus, celle de ; (´etape (b)) produit un triangle et un carr´e connect´es verts, ainsi qu’un connecteur suppl´ementaire. Pour qu’un connecteur ou arc puisse ˆetre cr´e´e, il est n´ecessaire de connaˆıtre chaque extr´emit´e. Ainsi, la transformation de A ne pose aucun souci particulier : un seul arc est cr´e´e entre deux ´el´ements cr´e´es (hexagone et cercle) dans cette mˆeme ´etape de transformation. En revanche, la transformation de B en un pentagone est cens´ee aussi construire un arc dont l’une des extr´emit´es (petit carr´e) n’est pas cr´e´ee dans cette ´etape de transformation. Il est donc n´ecessaire que l’´etape de transformation construisant cette deuxi`eme extr´emit´e se d´eroule avant celle produisant l’arc (c). Le carr´e servant de seconde extr´emit´e `a l’arc est construit dans l’´etape de transformation de ; qui devra donc ˆetre ex´ecut´ee avant (c). Nous notons que cette ´etape g´en`ere un autre arc dont l’une des extr´emit´es n’est pas connue dans (b). L’´etape de transformation produisant cette extr´emit´e d’arc qui nous int´eresse (petit cercle) est (a). Il est donc naturel d’ex´ecuter (a) avant (b). Finalement, pour que cette transformation puisse ˆetre ex´ecut´ee sans qu’il n’y ait de probl`eme d’´el´ements manquant, l’utilisateur doit adopter les ´etapes de transformation4.3. Transformation de mod`eles par r´e´ecriture 51 dans l’ordre suivant : (a), puis (b), puis (c). S’il ne respecte pas cet ordre, il sera confront´e au probl`eme de cr´eation d’´el´ements avec des informations manquantes. Cependant, cette approche n’est pas toujours possible, notamment lorsque l’on manipule des structures cycliques. Lorsqu’elle est possible, elle n´ecessite une parfaite expertise ainsi qu’une connaissance globale de la transformation pour ˆetre capable d’organiser les diff´erentes ´etapes. De plus, avec une telle m´ethode une transformation sera g´en´eralement monolithique. Elle sera donc peu g´en´erique et le code peu r´eutilisable, l’encodage du parcours du mod`ele ainsi que les transformations ´etant ad-hoc. G´en´eralement, le parcours du mod`ele sera encod´e par des boucles et de la r´ecursivit´e, et un traitement particulier sera d´eclench´e lorsqu’un ´el´ement donn´e sera d´etect´e. Parcours et traitement seront donc ´etroitement li´es. La moindre modification du m´etamod`ele source ou cible implique donc de repenser la transformation. Nous souhaitons au contraire faciliter le d´eveloppement et la maintenance du code que l’utilisateur ´ecrit pour une transformation, tout en le rendant r´eutilisable pour une autre transformation. Il est donc important d’adopter une m´ethode permettant une grande modularit´e du code. Notre approche est d’op´erer une transformation par parties : il faut d’abord d´ecomposer une transformation complexe en transformations les plus simples (ce que nous nommons transformations ´el´ementaires ou d´efinitions). Chacune d’entre elles est d´ecrite par une r`egle ou un ensemble de r`egles. La transformation globale est ensuite construite en utilisant ces transformations ´el´ementaires. Mais dans ce cas se pose le probl`eme de la d´ependance des d´efi- nitions entre elles, ainsi que de l’utilisation d’´el´ements issus d’une transformation ´el´ementaire dans une autre transformation ´el´ementaire. Ce qui a des cons´equences sur l’ordre d’application des d´efinitions : il peut ˆetre absolument n´ecessaire qu’une partie de la transformation soit effectu´ee pour que les autres ´etapes puissent ˆetre appliqu´ees. De plus, par souci d’utilisabilit´e, nous ne souhaitons pas que l’utilisateur ait besoin de se soucier de l’ordre d’application des transformations ´el´ementaires. Nous souhaitons qu’il se concentre uniquement sur la partie m´etier de la transformation. Il faut donc mettre en œuvre un m´ecanisme permettant de r´esoudre les d´ependances. Dans notre contexte, nous effectuons des transformations dites out-place, ce qui signifie que le mod`ele source n’est pas modifi´e. Le mod`ele cible r´esultant est construit au fur et `a mesure de la transformation, et n’est pas obtenu par modifications successives du mod`ele source — transformation in-place, comme le font les outils VIATRA [VVP02] / VIATRA2 [VB07] et GrGen.NET [JBK10] par exemple. Partant de ce constat, les transformations ´el´ementaires composant notre transformation n’entretiennent aucune d´ependance dans le sens o`u la sortie d’une transformation ´el´ementaire n’est pas l’entr´ee d’une autre transformation ´el´ementaire. Dans notre approche compositionnelle, chaque sortie d’une transformation ´el´ementaire est une partie du r´esultat final. Dans l’exemple, nous conservons la d´ecomposition propos´ee dans la Figure 4.3 en trois r`egles simples. Nous avons d´ecompos´e une transformation complexe en d´efinitions ind´ependantes et nous pouvons les appliquer. Subsiste cependant le probl`eme de l’usage dans une d´efinition d’´el´ements cr´e´es dans une autre d´efinition. Comme l’ordre d’´ecriture et d’application des transformations ´el´ementaires ne doit pas ˆetre une contrainte pour l’utilisateur, nous avons choisi de r´esoudre ce probl`eme par l’introduction d’´el´ements temporaires — ´el´ements dits resolve — qui font office d’´el´ements cibles durant la transformation, et qui sont substitu´es en fin de transformation lors d’une seconde phase. Cette d´enomination fait ´evidemment r´ef´erence au resolve de QVT et au resolveTemp de ATL. Partant du principe que toutes les transformations ´el´ementaires peuvent ˆetre d´eclench´ees ind´ependamment dans n’importe quel ordre (voire en parall`ele), il faut ˆetre en mesure de fournir un ´el´ement cible lorsque le traitement d’une d´efinition le n´ecessite. Nous proposons donc de construire un terme temporaire repr´esentant l’´el´ement final qui a ´et´e ou qui sera construit lors de l’application d’une autre d´efinition. Ce terme doit pouvoir ˆetre int´egr´e dans le mod`ele cible temporaire pour ˆetre manipul´e en lieu et place du terme cibl´e cens´e ˆetre construit dans une autre d´efinition. Il doit donc respecter les contraintes de types du m´etamod`ele cible tout en portant des informations suppl´ementaires telles qu’un identifiant, une r´ef´erence `a l’´el´ement52 Chapitre 4. Transformations de mod`eles par r´e´ecriture source d’origine et une r´ef´erence `a l’´el´ement cible. Nous ´etendons donc le m´etamod`ele cible MMt afin que ces contraintes soient respect´ees et que le mod`ele interm´ediaire r´esultant soit conforme `a un m´etamod`ele cible ´etendu, not´e MMtresolve . Ainsi, tout ´el´ement resolve e i tresolve du mod`ele interm´ediaire enrichi mtresolve sera de type un sous-type de l’´el´ement cibl´e e i t du mod`ele cible mt. Les ´el´ements e i tresolve sont les ´el´ements e i t d´ecor´es d’une information sur le nom de l’´el´ement cible repr´esent´e ainsi que d’une information sur l’´el´ement source dont ils sont issus. En termes de m´etamod`ele (Figure 4.4), pour tout ´el´ement cible e i t — instance d’un ´el´ement Ei t du m´etamod`ele cible MMt — issu d’un ´el´ement source e j s — instance du m´etamod`ele source MMs — et n´ecessitant un ´el´ement resolve e i tresolve durant la transformation, un ´el´ement Ei tresolve est cr´e´e dans le m´etamod`ele ´etendu MMtresolve . Cet ´el´ement h´erite de l’´el´ement cible Ei t . MMs MMtresolve MMt Ej s Ei t Ei tresolve Ei t Figure 4.4 – Sch´ema d’extension du m´etamod`ele cible par l’ajout d’´el´ements interm´ediaires resolve. Cette premi`ere phase produit donc un mod`ele cible non conforme au m´etamod`ele cible MMt de la transformation globale, mais conforme au m´etamod`ele cible ´etendu MMtresolve . Elle peut s’´ecrire sous la forme d’une fonction c : MMs → MMtresolve qui cr´ee des ´el´ements cible `a partir des ´el´ements du mod`ele source. La Figure 4.5 permet d’illustrer le m´ecanisme des ´el´ements resolve. Nous reprenons la Figure 4.3 d´ecrivant les trois d´efinitions composant notre transformation exemple, et nous int´egrons les ´el´ements resolve (repr´esent´es par des formes en pointill´es). Pr´ec´edemment, nous avons vu que nous pouvions appliquer la d´efinition (a) compl`etement ind´ependamment ´etant donn´e qu’elle ne n´ecessite aucun r´esultat ou partie de r´esultat issu d’une autre d´efinition. Cette ´etape ne change donc pas et ne cr´ee aucun ´el´ement r´esolve. La d´efinition (b) n´ecessite en revanche un cercle rouge – normalement cr´e´e dans la d´efinition (a) – pour pouvoir cr´eer un arc. Un ´el´ement dont le type (cercle pointill´e) est sous-type de l’´el´ement cible (cercle) est donc cr´e´e. Nous serons donc par la suite en mesure de manipuler le cercle pointill´e comme un cercle classique et de filtrer sur tous les cercles, en pointill´es ou non. La couleur donn´ee `a un ´el´ement resolve dans la Figure 4.5 permet de repr´esenter l’information de la d´efinition d’origine de l’´el´ement cibl´e par l’´el´ement resolve et donc d’encoder le lien entre les deux ´el´ements. Le mˆeme principe est appliqu´e `a la d´efinition (c) qui n´ecessite un ´el´ement normalement cr´e´e dans la d´efinition (b), d’o`u la g´en´eration d’un ´el´ement de type carr´e pointill´e vert. A −→ (a) ; −→ (b) B −→ (c) Figure 4.5 – R`egles de transformation de A, ; et B effectives avec la construction d’´el´ements resolve (en pointill´es color´es). Durant cette premi`ere phase de transformation par parties, chaque d´efinition a produit un ensemble d’´el´ements tous disjoints, les ´el´ements cens´es provenir d’autres d´efinitions ayant ´et´e repr´esent´es par des ´el´ements resolve.4.3. Transformation de mod`eles par r´e´ecriture 53 Nous encodons les d´efinitions par des strat´egies de r´e´ecriture que nous composons avec d’autres strat´egies. Il en r´esulte une strat´egie plus complexe qui encode cette premi`ere phase de transformation. Dans notre exemple de transformation Text2Picture, nous avons identifi´e trois d´efinitions — (a), (b) et (c) — qui seront encod´ees respectivement par les strat´egies Sa, Sb et Sc. Nous les combinons avec la s´equence et une strat´egie de parcours — TopDown ici — pour former la strat´egie Sphase1 = T opDown(Seq(Sa, Sb, Sc)). 4.3.2 R´esolution - r´econciliation L’application des transformations ´el´ementaires sur le mod`ele source a produit un r´esultat interm´ediaire non conforme au m´etamod`ele cible MMt, car compos´e de plusieurs r´esultats partiels incluant des ´el´ements resolve, comme illustr´e par la Figure 4.6. −→ c A ;B Figure 4.6 – R´esultat interm´ediaire de la transformation, avant phase de r´esolution. Pour obtenir un r´esultat coh´erent conforme au m´etamod`ele cible, il est n´ecessaire d’effectuer un traitement sur ce r´esultat interm´ediaire. C’est ce que nous appelons la phase de r´esolution ou r´econciliation, dont le but est de fusionner des ´el´ements disjoints pour les rendre identiques. Elle consiste `a parcourir le terme r´esultant, `a trouver les ´el´ements temporaires resolve, puis `a reconstruire un terme r´esultat en rempla¸cant ces termes temporaires par les termes qu’ils ´etaient cens´es remplacer. Etant donn´e que toutes les ´ d´efinitions ont ´et´e appliqu´ees, nous sommes certains que l’´el´ement final existe, et qu’il peut se substituer `a l’´el´ement temporaire examin´e. −→ r Figure 4.7 – Phase de r´esolution. Cette phase de r´esolution est elle-mˆeme encod´ee par une strat´egie Sphase2 qui r´e´ecrit un terme-resolve (c’est-`a-dire la repr´esentation d’un mod`ele contenant des ´el´ements interm´ediaires resolve sous la forme d’un terme) en terme cible, conforme `a la signature cible. Ce remplacement est possible grˆace aux informations suppl´ementaires qui enrichissent le type cible ainsi qu’aux informations que nous sauvegardons durant la transformation. Ces informations additionnelles sont des informations sur les relations existant entre les ´el´ements cibles et les ´el´ements sources dont ils sont issus. Elles sont obtenues par le biais d’actions explicites de la part de l’utilisateur : tout terme cr´e´e dans une transformation peut ˆetre trac´e sur demande. C’est ce qu’illustre la Figure 4.8 : les jetons color´es correspondent `a une action explicite de trace d’un terme qui a ´et´e cr´e´e dans la d´efinition. Ainsi, dans cet exemple, l’utilisateur a marqu´e un ´el´ement dans la d´efinition (a) qui correspond `a l’´el´ement cibl´e par l’´el´ement resolve de la d´efinition (b). Il en est de mˆeme avec l’´el´ement de type carr´e des d´efinitions (b) et (c). Une autre approche possible eˆut ´et´e de tracer syst´ematiquement tous les termes cr´e´es, mais nous avons fait ce choix dans le but d’am´eliorer la lisibilit´e de la trace. Toutes ces54 Chapitre 4. Transformations de mod`eles par r´e´ecriture A −→ (a) ; −→ (b) B −→ (c) Figure 4.8 – R`egles de transformation de A, ; et B effectives, avec tra¸cage des ´el´ements correspondant `a un ´el´ement resolve d’une autre d´efinition (token color´e de la couleur du r´esultat d’une d´efinition). informations suppl´ementaires constituent ce que nous appelons le mod`ele de lien. Il maintient tout au long de la transformation des relations entre les ´el´ements sources et les ´el´ements cibles qui en sont issus. Dans ce cas pr´ecis, le tra¸cage des liens a eu un usage purement m´ecanique pour permettre la r´esolution de liens. Cependant, outre cet usage pour la phase de r´esolution, le construction d´edi´ee au marquage de termes et le mod`ele de lien nous permettent d’assurer la tra¸cabilit´e de la transformation `a des fins de v´erification a posteriori. Nous traitons de ce sujet dans le chapitre 5. Ainsi, une transformation T est la compos´ee de deux fonctions c : MMs → MMtresolve et r : MMtresolve → MMt. La transformation compl`ete T : MMs → MMt est donc d´efinie par T = r ◦ c. L’encodage d’une telle fonction dans notre approche est une strat´egie S mettant en s´equence les deux strat´egies repr´esentant chaque phase, qui peut se r´esumer par S = Seq(Sphase1, Sphase2). Outre les avantages ´evoqu´es en d´ebut de chapitre, un des int´erˆets de cette approche compositionnelle reposant sur les strat´egies de r´e´ecriture apparait imm´ediatement : reposant sur les strat´egies de r´e´ecriture, nous b´en´eficions naturellement de la modularit´e intrins`eque `a ce concept que le langage de strat´egies de Tom impl´emente. Il est ainsi possible de r´eutiliser les d´efinitions dans une autre transformation, sans adaptation lourde du code. On pourrait imaginer que la phase de r´esolution devienne bloquante dans ce cas, cependant, comme nous le verrons dans la description de l’impl´ementation de notre approche (chapitre 6), cette phase est g´en´er´ee et peut aussi ˆetre g´en´er´ee sous la forme de plusieurs strat´egies distinctes — plus simples — r´eutilisables dans le cadre d’une autre transformation. 4.4 Validation par un cas d’´etude Pour valider la proposition, nous nous sommes appuy´es sur une ´etude de cas : la transformation SimplePDLToPetriNet. Nous ne rentrons pour le moment pas dans les d´etails et n’expliquons pas pr´ecis´ement les m´etamod`eles des formalismes consid´er´es. Nous pr´eciserons la cas dans le chapitre 5 qui suit, puis nous le d´evelopperons dans son int´egralit´e dans le chapitre 7 avec son impl´ementation. Pour r´esumer cette ´etude de cas, l’objectif est de transformer des processus g´en´eriques d´ecrits dans le formalisme SimplePDL en leur repr´esentation sous la forme de r´eseaux de Petri. Par exemple, la figure 4.9 d´ecrit un processus simple nomm´e root compos´e de deux activit´es : A et B. Ces deux activit´es sont li´ees par une contrainte de pr´ec´edence startToFinish (s2f ). Cela signifie que l’activit´e A doit avoir commenc´e pour pouvoir terminer l’activit´e B. A B s2f root: Figure 4.9 – Exemple de processus SimplePDL.4.4. Validation par un cas d’´etude 55 Ce processus g´en´erique peut s’exprimer sous la forme d’un r´eseau de Petri tel qu’illustr´e par la figure 4.10 suivante. Les places sont repr´esent´ees par des cercles rouges, les transitions par des carr´es bleus et les arcs par des fl`eches. Les fl`eches en pointill´es sont des arcs de synchronisation, celles en trait plein noir sont des arcs normaux cr´e´es dans des diff´erentes d´efinitions, la fl`eche verte est un arc obtenu par la d´efinition transformant la s´equence (qui impose la contrainte de pr´ec´edence). Dans ce r´eseau de Petri, lorsque la premi`ere transition de Proot est franchie, le jeton de la premi`ere place est ajout´e `a la seconde place de Proot. Un jeton est aussi ajout´e aux premi`eres places des r´eseaux A et B, ce qui a pour effet de d´emarrer les tˆaches. La transition tf inish de B ne peut ˆetre franchie que si A a d´emarr´e. Proot A pstarted B tf inish s2f Figure 4.10 – R´eseau de Petri correspondant au processus d´ecrit par la figure 4.9. Cette transformation peut ˆetre d´ecompos´ee en trois d´efinitions. Chacune d’entre elles produit un r´eseau de Petri. Nous les repr´esentons toutes les trois dans la figure 4.11 qui suit (les nœuds en pointill´es sont des ´el´ements interm´ediaires resolve). Dans cette version du cas d’´etude, le m´ecanisme de cr´eation d’´el´ements temporaires resolve est utilis´e dans le cadre de deux d´efinitions, celle qui transforme les WorkDefinitions et celle qui transforme les WorkSequences. Le m´ecanisme de marquage est quant `a lui utilis´e dans la d´efinition qui transforme les Process afin d’effectuer la correspondance avec les ´el´ements Process WorkDefinition WorkSequence ↓ ↓ ↓ Figure 4.11 – Transformations ´el´ementaires composant SimplePDLToPetriNet.56 Chapitre 4. Transformations de mod`eles par r´e´ecriture resolve cr´e´es dans la transformation ´el´ementaire qui prend en entr´ee une WorkDefinition. Des ´el´ements sont aussi trac´es dans cette derni`ere pour assurer la r´esolution avec les ´el´ements interm´ediaires produits dans la d´efinition qui transforme les Worksequences. Nous avons mis en œuvre ce m´ecanisme global de r´esolution que nous d´etaillons techniquement dans le chapitre 6. Le m´ecanisme de marquage (ou tra¸cage) est une forme de tra¸cabilit´e, la tra¸cabilit´e interne (ou technique) qui est ´etroitement li´ee `a l’impl´ementation de la transformation. 4.5 Synth`ese Dans ce chapitre, nous avons pr´esent´e notre approche pour transformer les mod`eles. Elle est hybride ´etant donn´e qu’il ne s’agit pas d’utiliser uniquement un langage g´en´eraliste ou un langage d´edi´e, mais d’avoir une approche interm´ediaire o`u nous int´egrons des constructions d´edi´ees au sein d’un langage g´en´eraliste. Ce proc´ed´e est rendu possible par l’utilisation du langage Tom pr´esent´e dans le chapitre 1 et qui repose sur le calcul de r´e´ecriture. Une telle approche a l’avantage de pouvoir faire b´en´eficier l’utilisateur du meilleur des deux mondes des langages g´en´eralistes et d´edi´es `a la fois. Ainsi, l’utilisateur d´eveloppant une transformation en Tom+Java aura les constructions sp´ecifiques aux transformations de mod`eles tout en conservant l’outillage existant de Java. Nous avons aussi expliqu´e que notre approche se base sur la r´e´ecriture de termes. Compte tenu du fait que nous transformons des mod`eles, notre approche commence par un changement d’espace technologique rendu possible grˆace `a un outil de g´en´eration d’ancrages formels que nous avons d´evelopp´e. Il nous permet de repr´esenter des mod`eles Ecore sous la forme de termes, que nous pouvons ensuite parcourir et transformer avec des strat´egies de r´e´ecriture. Ces strat´egies de r´e´ecriture encodent les transformations ´el´ementaires composant la transformation globale, elle-mˆeme encod´ee par une strat´egie de r´e´ecriture. Dans un but d’accessibilit´e de l’approche et des outils pour les utilisateurs, nous avons choisi de proposer une m´ethode permettant `a l’utilisateur de ne pas avoir `a g´erer l’ordonnancement des pas d’ex´ecution. Notre solution `a ce probl`eme est l’introduction d’´el´ements interm´ediaires dits resolve qui jouent le rˆole d’´el´ements cibles tant que ces derniers ne sont pas cr´e´es. Une transformation selon notre approche est donc compos´ee de deux phases distinctes : la premi`ere o`u les ´el´ements cibles et cibles interm´ediaires sont cr´e´es, et la seconde qui consiste `a r´esoudre les liens, c’est-`a-dire `a supprimer les ´el´ements interm´ediaires et `a remplacer les liens pointant vers eux par des liens vers les ´el´ements cibles qu’ils repr´esentaient.Chapitre 5 Sp´ecification et tra¸cabilit´e des transformations Dans ce chapitre, nous abordons la notion de sp´ecification et de tra¸cabilit´e d’une transformation de mod`eles. Les syst`emes se complexifiant, l’IDM a apport´e des solutions pour faciliter et acc´el´erer le d´eveloppement logiciel. Cependant, si la mani`ere de d´evelopper un logiciel ainsi que les technologies utilis´ees ont chang´e depuis les d´ebuts de l’informatique, les contraintes li´ees `a la maintenance (´evolution du logiciel, d´eboguage) et `a la fiabilit´e (qualification, certification) restent identiques. Ainsi, dans le cadre des transformations qualifiables, nous souhaitons avoir confiance dans les transformations d´evelopp´ees, du point de vue formel (pour la v´erification) ainsi que de celui de l’autorit´e de certification. La norme DO-178/ED-12 exige la tra¸cabilit´e entre le code source et le code objet, c’est donc une probl´ematique essentielle des compilateurs dans le contexte de la qualification. Cette probl´ematique est g´en´eralisable `a toute transformation, notamment aux transformations de mod`eles. En effet, l’ing´enierie dirig´ee par les mod`eles ´etant de plus en plus pr´esente dans les chaˆınes de d´eveloppement de syst`emes critiques, du code g´en´er´e `a partir d’un mod`ele peut faire partie du logiciel final. 5.1 Sp´ecification Dans le chapitre 3, nous avons vu qu’il fallait qualifier les transformations dans le cadre du d´eveloppement de syst`emes critiques. Il est important de sp´ecifier les transformations pour v´erifier leur conformit´e, afin de disposer de la tra¸cabilit´e code source–code objet. Pour cela, nous nous appuyons sur les transformations de mod`eles. Reprenons le cas d’utilisation SimplePDLToPetriNet bri`evement illustr´e dans le chapitre pr´ec´edent et sp´ecifions les mod`eles source et destination ci-apr`es. Le langage SimplePDL dont le m´etamod`ele est donn´e figure 7.1 permet d’exprimer simplement des processus g´en´eriques. Un processus (Process) est compos´e d’´el´ements (ProcessElement). Chaque ProcessElement r´ef´erence son processus parent et peut ˆetre soit une WorkDefinition, soit une WorkSequence. Une WorkDefinition d´efinit une activit´e qui doit ˆetre effectu´ee durant le processus (un calcul, une action, etc.). Une WorkSequence d´efinit quant `a elle une relation de d´ependance entre deux activit´es. La deuxi`eme (successor ) peut ˆetre d´emarr´ee — ou termin´ee — uniquement lorsque la premi`ere (predecessor ) est d´ej`a d´emarr´ee — ou termin´ee — selon la valeur de l’attribut linkType qui peut donc prendre quatre valeurs : startToStart, finishToStart, startToFinish ou finishToFinish. Afin de pouvoir repr´esenter des processus hi´erarchiques, une WorkDefinition peut elle-mˆeme ˆetre d´efinie par un processus imbriqu´e (r´ef´erence process), qui conserve un lien vers l’activit´e qu’il d´ecrit (r´ef´erence from). Le m´etamod`ele donn´e par la figure 5.2 permet d’exprimer les r´eseaux de Petri. Un tel r´eseau se d´efinit par un ensemble de nœuds (Node) qui sont soit des places de type Place, 5758 Chapitre 5. Sp´ecification et tra¸cabilit´e des transformations Process name : String ProcessElement WorkDefinition name : String WorkSequence linkType : WorkSequenceType <> WorkSequenceType startToStart finishToStart startToFinish finishToFinish processElements * parent 1 successor 1 * linksToPredecessors predecessor 1 * linksToSuccessors Figure 5.1 – M´etamod`ele SimplePDL possible. soit des transitions de type Transition, ainsi que par des arcs (Arc). Un arc (orient´e) relie deux nœuds de types diff´erents (le r´eseau de Petri est un graphe biparti) et peut ˆetre de type normal ou read-arc. Il sp´ecifie le nombre de jetons (weight — poids —) consomm´es dans la place source ou produits dans la place cible lorsqu’une transition est tir´ee. Un readarc v´erifie uniquement la disponibilit´e des jetons sans pour autant les consommer (test de franchissement). Le marquage d’un r´eseau de Petri est d´efini par le nombre de jetons dans chaque place (marking). PetriNet name : String Arc kind : ArcKind weight : Int Node name : String Place marking : Int Transition <> ArcKind normal read arc nodes * net 1 arcs * net 1 source 1 * outgoings target 1 * incomings Figure 5.2 – M´etamod`ele des r´eseaux de Petri. 5.2 Tra¸cabilit´e La tra¸cabilit´e est tr`es importante dans le cadre de la maintenance pour pouvoir suivre l’´evolution d’un logiciel et d´etecter des bugs introduits durant le cycle de vie de l’application. C’est un pr´ecieux outil pour l’analyse et la v´erification de transformations, ce qui explique que ce soit une exigence de qualification. La tra¸cabilit´e peut prendre plusieurs formes. Nous distinguons notamment la tra¸cabilit´e interne (autrement appel´ee technique) de la tra¸cabilit´e5.2. Tra¸cabilit´e 59 de sp´ecification. 5.2.1 Tra¸cabilit´e interne La tra¸cabilit´e interne ou technique [Jou05] a un usage purement technique au sein de la transformation. C’est-`a-dire qu’elle est utilis´ee pour op´erer la transformation, mais n’est pas n´ecessairement utile dans le cadre d’un processus de qualification. Dans les approches compositionnelles des transformations comme la nˆotre, il faut mettre en œuvre un m´ecanisme permettant d’assembler les r´esultats partiels. Dans notre cas, si des ´el´ements interm´ediaires resolve sont cr´e´es, il est n´ecessaire de pouvoir les faire correspondre `a des ´el´ements cibles r´eels. Il faut donc pouvoir marquer les ´el´ements susceptibles de correspondre `a un resolve donn´e afin d’assurer la r´ealisation de la phase de r´esolution. Nous avons mis en œuvre cette tra¸cabilit´e dans le cadre de notre approche d´ecrite dans le chapitre 4 et nous la d´ecrivons plus pr´ecis´ement dans le chapitre 6. Nous ne nous attardons donc pas sur cette notion dans ce chapitre. Du fait de son usage, la tra¸cabilit´e technique est ´etroitement li´ee `a l’impl´ementation de la transformation. Elle est difficilement g´en´erique, ce qui peut n´ecessiter de la r´eing´enierie lors d’une ´evolution de la transformation. 5.2.2 Tra¸cabilit´e de sp´ecification La tra¸cabilit´e de sp´ecification est quant `a elle une exigence de qualification. C’est-`a-dire qu’il faut pouvoir lier une source `a une cible selon une sp´ecification donn´ee. Ce type de tra¸cabilit´e n’a pas d’usage technique pour le bon d´eroulement de la transformation elle-mˆeme et n’est pas n´ecessairement li´ee `a l’impl´ementation. La tra¸cabilit´e des transformations de mod`eles ´etant un ´el´ement essentiel dans un cadre industriel, beaucoup de langages l’ont impl´ement´e. Cependant, les langages tels que QVTRelations et ATL proposent une tra¸cabilit´e m´ecanique, mais qui n’est pas substituable `a la tra¸cabilit´e de sp´ecification. En IDM, l’usage de UML est courant et comme nous avons pu le voir dans le chapitre 2, un m´etamod`ele permet de sp´ecifier un langage. Pour exprimer la tra¸cabilit´e dans ce contexte, il est donc naturel d’utiliser des m´etaclasses pour avoir un formalisme coh´erent. On peut alors exprimer simplement la tra¸cabilit´e par le m´etamod`ele 5.3. Trace transfoName : String TraceLink ruleName : String SourceElement TargetElement links * sources 1..* targets 1..* Figure 5.3 – M´etamod`ele g´en´erique de trace. Une Trace concerne une transformation donn´ee nomm´ee. Elle est compos´ee d’un ensemble de relations (ou de liens de trace TraceLink) entre des ´el´ements sources et cibles. Un lien de trace ´etablit une relation entre un ou plusieurs ´el´ements sources (SourceElement) et un ou plusieurs ´el´ements cibles (TargetElement). Une relation de trace est nomm´ee et peut ˆetre consid´er´ee comme une r`egle ayant un membre gauche (source) et en membre droit (cible). Ce m´etamod`ele est g´en´erique afin de donner une intuition. Il doit cependant ˆetre sp´ecifique pour chaque transformation donn´ee. Dans le cas de SimplePDLToPetrinet, SourceElement de la figure 5.3 est remplac´e par les m´etaclasses Process, WorkDefinition et WorkSequence ou alors est leur surtype. Dans le cas d’un framework comme EMF, on peut utiliser EObject.60 Chapitre 5. Sp´ecification et tra¸cabilit´e des transformations Lors de la certification et de la qualification, les sp´ecifications sont cependant tr`es souvent ´ecrites en langue naturelle (fran¸cais ou anglais). Le tˆache de l’expert qualifieur consiste alors `a comparer la sp´ecification textuelle au code du logiciel et aux sorties produites pour des entr´ees donn´ees. Cette tˆache est complexe et fortement sujette `a erreurs du fait du rˆole central que joue l’humain dans ce processus. Tout doit donc ˆetre mis en œuvre pour assister l’expert qualifieur en lui fournissant des ´el´ements de confiance suppl´ementaires. C’est le rˆole des outils et de leurs impl´ementations de la tra¸cabilit´e. Cette trace peut revˆetir diff´erents aspects et n’est pas forc´ement utilisable avec des outils automatiques. Par exemple, l’impl´ementation de la tra¸cabilit´e peut consister en la g´en´eration de commentaires lisibles par un humain. C’est d’ailleurs l’approche adopt´ee par l’outil b2llvm — hors du contexte de l’IDM — qui op`ere une transformation du langage B vers le langage interm´ediaire de LLVM 50. Ces commentaires facilitent la lecture et la compr´ehension du code par l’expert, mais ne sont cependant pas r´eutilisables en tant que tels comme entr´ees d’un outil automatique de v´erification. Un point particuli`erement int´eressant est d’assurer la tra¸cabilit´e d’une transformation en g´en´erant une trace formelle exploitable a posteriori par d’autres outils. L’int´erˆet est alors de permettre de se passer de l’´ecriture d’une preuve formelle — coˆuteuse `a obtenir — tout en conservant une confiance forte dans la transformation. Une telle trace g´en´er´ee lors d’une transformation peut-ˆetre utilis´ee de deux mani`eres : — elle peut ˆetre compar´ee `a une trace de r´ef´erence donn´ee en sp´ecification ; — des propri´et´es donn´ees en sp´ecification peuvent ˆetre v´erifi´ees. Dans le premier cas d’utilisation, le format de la trace doit ˆetre parfaitement sp´ecifi´e afin que, pour une entr´ee et une transformation donn´ees, la trace puisse ˆetre compar´ee `a une trace de r´ef´erence. Cette derni`ere fait alors office de sp´ecification de la transformation. Dans le second cas d’utilisation de la trace, il faut pouvoir exprimer des propri´et´es `a v´eri- fier. Dans le contexte de la mod´elisation, OCL est utilis´e pour d´ecrire des r`egles s’appliquant sur des mod`eles UML. Lors d’une transformation de mod`ele, des pre-conditions peuvent donc ˆetre ´ecrites pour les ´el´ements sources, des post-conditions pour les ´el´ements cibles et des invariants pour les liens de tra¸cabilit´e. Dans notre approche, nous avons propos´e une tra¸cabilit´e de sp´ecification. La transformation par r´e´ecriture pr´esent´ee ´etant une transformation par parties, nous agr´egeons un ensemble de r`egles (d´efinitions) pour obtenir la transformation finale. Chacune de ces d´efinitions est nomm´ee et nous utilisons son nom pour construire le lien de trace lors de la g´en´eration du m´etamod`ele de lien (au temps de compilation). Le membre gauche de nos r`egles constitue la source de chaque lien de trace, tandis que les ´el´ements du membre droit sont les cibles de la relation de trace. Sur action explicite de l’utilisateur, nous ´etablissons une relation un ´el´ement source et ´el´ement cible. Dans sa forme actuelle, notre impl´ementation permet de lier plusieurs cibles `a une seule source (relations 1..N), l’objectif ´etant `a terme d’´etablir des liens entre plusieurs sources et plusieurs cibles (relations N..N). Reprenons le cas de la transformation SimplePDLToPetriNet et choisissons une r`egle comme exemple : Process2PetriNet. Cette r`egle transforme les ´el´ements Process du mod`ele source en un r´eseau de Petri compos´e de trois places (p ready, p running et p f inished), deux transitions (t start et t f inish) et de quatre arcs (ready2start, start2running, running2f inish et f inish2f inished). De cette description textuelle, nous pouvons sp´ecifier la relation liant la source src aux ´el´ements cibles comme suit : Process2PetriNet = { src : Process ; p_ready, p_running, p_finished : Place ; t_start, t_finish : Transition ; ready2start, start2running, running2finish, finish2finished : Arc } 50. Le projet LLVM est une infrastructure de compilateur modulaire et r´eutilisable, voir http://www.llvm. org.5.3. Synth`ese 61 On peut faire de mˆeme avec les relations WorkDefinition2PetriNet et WorkSequence2PetriNet pour compl´eter la sp´ecification. Il est ensuite possible d’exprimer des contraintes sur cette relation, notamment des contraintes de nommage des ´el´ements cibles. Dans notre cas, supposons que l’on impose que le nom d’un ´el´ement cible soit compos´e de deux parties, sur le principe suivant : — le nom de l’´el´ement source lui ayant donn´e naissance en pr´efixe ; — un suffixe pertinent pour d´ecrire l’´el´ement (par exemple ready pour la place p ready). Avec ces conventions, nous pouvons par exemple ´ecrire la contrainte de nommage pour la place p ready peut ˆetre ´ecrite comme suit (concat() est l’op´eration de concat´enation des chaˆınes de caract`eres dans OCL) : p_ready.Name = src.Name.concat(’_’).concat(p_ready.Name); La trace est donc exploitable `a des fins de qualification. 5.3 Synth`ese Nous avons vu qu’on pouvait distinguer deux types de tra¸cabilit´e : interne et de sp´ecification. Nous avons mis en œuvre les deux, la premi`ere ´etant absolument n´ecessaire `a la bonne r´ealisation de notre approche, la seconde ´etant utile pour le d´eveloppement de transformations qualifiables. Nous avons vu dans le chapitre 3.3 que la tra¸cabilit´e est g´en´eralement class´ee en deux cat´egories : implicite et explicite. Un aspect important de notre approche r´eside dans notre choix d’une tra¸cabilit´e explicite, ce qui implique l’introduction d’une syntaxe concr`ete dans le langage pour capturer explicitement les liens de trace. Dans le cas d’un choix implicite, tout doit ˆetre trac´e et il faut pr´evoir un m´ecanisme pour trier et s´electionner les informations pertinentes a posteriori (un syst`eme de requˆete sur la trace g´en´er´ee par exemple). Notre choix pr´esente l’int´erˆet de produire des traces cibl´ees d’une taille plus raisonnable. Elles sont donc exploitables plus facilement a posteriori. Enfin, un autre point int´eressant qui ne peut transparaˆıtre sans aborder la question technique tient au fait de notre environnement technologique hybride. En effet, nous apportons une tra¸cabilit´e au sein d’un langage g´en´eraliste par l’ajout d’une construction d´edi´ee. Dans un environnement homog`ene et parfaitement maˆıtris´e, la difficult´e est lev´ee rapidement, la tra¸cabilit´e pouvant ˆetre assur´ee relativement simplement. En revanche, dans notre contexte, nous sommes `a la fronti`ere de deux mondes que l’utilisateur peut franchir selon ses convenances. Si l’utilisation du langage Tom et la manipulation de termes ne lui conviennent pas, l’utilisateur peut revenir `a un mode de programmation en pur Java, auquel cas nous perdons le contrˆole de cette partie du code. Ajouter la tra¸cabilit´e dans cet environnement devient plus complexe. Nous d´etaillons la mise en œuvre de notre approche dans le chapitre 6. Finalement, notre approche permet un usage a posteriori de la trace g´en´er´ee `a des fins de v´erification dans le cadre de la qualification.62 Chapitre 5. Sp´ecification et tra¸cabilit´e des transformationsChapitre 6 Outils pour exprimer une transformation de mod`eles en Tom Dans ce chapitre, nous traitons de notre contribution au langage Tom et de la mani`ere dont notre approche de transformation de mod`eles par r´e´ecriture est impl´ement´ee. Dans un premier temps, nous donnons le mode op´eratoire concret pour utiliser nos outils en nous appuyant sur l’exemple de transformation vu pr´ec´edemment. Nous pr´esentons ensuite l’extension du langage Tom d´edi´ee aux transformations de mod`eles, puis nous expliquons son impl´ementation technique au sein du compilateur, ainsi que l’impl´ementation du g´en´erateur d’ancrages formels. 6.1 Exemple d’utilisation des outils Cette section pr´esente l’utilisation de nos outils d’un point de vue concret. Nous expliquons le processus d’´ecriture d’une transformation de mod`eles avec eux. Pour cela, nous proposons de nous appuyer sur la transformation de texte en formes g´eom´etriques color´ees pr´esent´ee dans un chapitre pr´ec´edent et que nous rappelons dans la section 6.1.1 ci-apr`es. L’objectif de cette transformation est purement p´edagogique et sert uniquement `a illustrer l’utilisation de nos outils pour ensuite introduire notre extension du langage. Nous ne nous int´eressons donc pas `a sa pertinence ni `a son utilit´e dans le cadre d’un d´eveloppement en contexte industriel. 6.1.1 Exemple support Le principe g´en´eral de cette transformation de mod`ele est de transformer un mod`ele sous forme de texte en une repr´esentation graphique, comme l’illustre la figure 6.1. A ;B −→ Figure 6.1 – Exemple de transformation de texte en formes g´eom´etriques color´ees. 6364 Chapitre 6. Outils pour exprimer une transformation de mod`eles en Tom Les figures 6.2 et 6.3 sont deux m´etamod`eles que nous proposons et auxquels les mod`eles source et cible de la figure 6.1 se conforment respectivement. Text name : String Symbol SemiColon Letter AText BText symbols * letters 1..* right * * linksToLefts left * * linksToRights Figure 6.2 – Un m´etamod`ele pouvant d´ecrire le formalisme textuel (source) utilis´e dans l’exemple support. Un texte (Text) est compos´e de lettres (Letter ) et de symboles (Symbol). Dans notre exemple, les lettres peuvent ˆetre soit des A (AText), soit des B (BText) ; tandis que les symboles sont des points-virgules (SemiColon). Une image GeoPicture est compos´ee de formes (Shape) caract´eris´ees par une couleur (Color, pouvant prendre les valeurs red, green et blue). Shape est abstraite, et plusieurs formes concr`etes en h´eritent (Triangle, Pentagon, Hexagon, Square, Circle). Les formes g´eom´etriques sont reli´ees entre elles par des segments (Segmen).6.1. Exemple d’utilisation des outils 65 GeoPicture name : String Segment Shape color : Color Triangle Pentagon Hexagon Square Circle <> Color red green shapes blue 0..* picture 1 segments 0..* picture 1 outgoings 0..* 1 source 0..* incomings 1 target Figure 6.3 – Un m´etamod`ele pouvant d´ecrire le formalisme graphique (cible) utilis´e dans l’exemple support. 6.1.2 Mode op´eratoire Concr`etement, un utilisateur souhaitant impl´ementer une transformation de mod`ele devra op´erer par ´etapes, obtenues en fonction de l’outil principal `a utiliser : 1. Eclipse : mod´elisation et g´en´eration des structures de donn´ees Java-EMF ; 2. Tom-EMF : g´en´eration des ancrages formels pour repr´esenter les mod`eles comme des termes (passerelle op´erant le changement d’espace technologique) ; 3. Tom+Java : ´ecriture effective de la transformation. Etape 1 : ´ La premi`ere ´etape consiste `a mod´eliser le probl`eme, c’est-`a-dire `a d´efinir les m´etamod`eles source et cible, en utilisant Eclipse ou tout autre outil capable de g´en´erer un m´etamod`ele au format .ecore. Supposons que ces m´etamod`eles source et cible s’appellent respectivement text.ecore et picture.ecore. Depuis ces m´etamod`eles, le g´en´erateur de code de EMF (GenModel) permet de g´en´erer les structures de donn´ees Java correspondantes qui permettent d’instancier et de manipuler les mod`eles. L’utilisateur souhaitant impl´ementer la transformation n’a pas forc´ement besoin de se plonger dans ce code, ´etant donn´e que par la suite il ne manipulera pas directement les mod`eles en Java +EMF, mais plutˆot des termes alg´ebriques. Une fois le code des m´etamod`eles source et cible g´en´er´e, il suffit de l’exporter sous la forme d’archives .jar (par exemple text.jar et picture.jar dans notre cas). Une fois cette op´eration accomplie, Eclipse n’est plus n´ecessaire. Etape 2 : ´ La seconde ´etape de la mise en œuvre d’une transformation consiste `a g´en´erer les ancrages alg´ebriques `a partir de la repr´esentation EMF des m´etamod`eles. Cette ´etape est r´ealis´ee en utilisant un outil nomm´e Tom-EMF. L’utilisateur applique Tom-EMF sur l’archive (ou les archives) en sp´ecifiant le nom complet de l’EPackage (ou des EPackages) concern´e(s).66 Chapitre 6. Outils pour exprimer une transformation de mod`eles en Tom Concr`etement, la commande suivante permet d’effectuer l’op´eration (nous supposons que les archives .jar sont dans le r´epertoire courant not´e . et nous ne les nommons donc pas explicitement : $> emf-generate-mappings -cp . text.TextEPackage picture.PictureEPackage Un m´ecanisme de pr´efixe a aussi ´et´e pr´evu pour r´esoudre les conflits de noms. Nous supposons dans notre exemple qu’il n’y en a pas et que l’utilisateur n’a pas `a sp´ecifier des pr´efixes. La commande pr´ec´edente entraˆıne la g´en´eration de deux fichiers d’ancrages — un par EPackage sp´ecifi´e — nomm´es respectivement text.TextEPackage.tom et picture.PictureEPackage.tom. Dans notre exemple, les types et op´erateurs ne sont pas pr´efix´es. Si l’utilisateur avait choisi de sp´ecifier un pr´efixe, chaque mapping aurait eu un pr´efixe (les types primitifs et Ecore sont exclus). La passerelle permettant d’op´erer le changement d’espace technologique ´etant g´en´er´ee, l’outil Tom-EMF n’est plus utile pour le reste du d´eveloppement. Etape 3 : ´ Il s’agit de l’´ecriture en Tom+Java de la transformation `a proprement parler. Cette ´etape consiste en un d´eveloppement Java classique int´egrant des constructions Tom en son sein, notamment %transformation pour sp´ecifier la transformation. Pour pouvoir manipuler les mod`eles comme des termes alg´ebriques, il est n´ecessaire d’inclure les fichiers d’ancrages que nous venons de g´en´erer avec Tom-EMF. Dans notre exemple, les inclusions (ˆılot formel %include) et la transformation (ˆılot formel %transformation) apparaissent comme illustr´e dans le listing 6.1. 1 ... 2 public class TestText2Picture { 3 ... 4 %include{ text.TextEPackage.tom } 5 %include{ picture.PictureEPackage.tom } 6 ... 7 %transformation Text2Picture(gp:GeoPicture):text.ecore -> picture.ecore { 8 ... 9 definition Letter2Shape traversal ‘TopDown(Letter2Shape(gp)) { 10 AText() -> { ... } 11 BText() -> { ... } 12 } 13 ... 14 definition Symbol2Shape traversal ‘BottomUp(Symbol2Shape(gp)) { 15 SemiColon() -> { ... } 16 } 17 ... 18 } 19 ... 20 public static void main(String[] args) { 21 ... 22 ‘Text2Picture(gp).visit(input_model); 23 ‘TopDown(Resolve(gp)).visit(gp); 24 } 25 ... 26 } Listing 6.1 – Forme g´en´erale de la transformation Text2Picture ´ecrite en Tom+Java.6.2. Extension du langage 67 Dans ce programme, un mod`ele peut ˆetre soit charg´e en utilisant les services EMF (chargement d’un mod`ele s´erialis´e dans un fichier .xmi), soit cr´e´e avec la construction backquote de Tom (‘), comme tout autre terme. Quelle que soit la m´ethode choisie, le mod`ele peut ensuite ˆetre manipul´e en tant que terme. A ce titre, il est possible de filtrer des motifs et d’appliquer ` des strat´egies de r´e´ecriture (donc des transformations Tom). Une fois le d´eveloppement termin´e, le programme doit ˆetre compil´e en deux temps. Il faut proc´eder `a une compilation Tom pour dissoudre les ˆılots formels Tom dans le langage hˆote, puis compiler normalement le code Java g´en´er´e en int´egrant les biblioth`eques g´en´er´ees par EMF. L’ex´ecution du programme est identique `a toute ex´ecution de programme Java. $> tom TestText2Picture.t $> javac -cp ./text.jar:./picture.jar:${CLASSPATH} TestText2Picture.java $> java -cp ./text.jar:./picture.jar:${CLASSPATH} TestText2Picture 6.2 Extension du langage Nous avons vu le mode op´eratoire pour ´ecrire une transformation de mod`eles avec nos outils dans la section pr´ec´edente, sans d´etailler le langage lui-mˆeme. Nous d´ecrivons nos constructions dans cette section. Nous avons vu dans le chapitre 4 que nous d´ecomposons les transformations de mod`eles en transformations ´el´ementaires (Letter2Shape par exemple), encod´ees par des strat´egies de r´e´ecriture. Nous formons ensuite une strat´egie en les composant avec d’autres combinateurs ´el´ementaires tels que Sequence ou TopDown. Nous avons aussi vu que cela constitue la premi`ere phase d’une transformation suivant notre approche et qu’il faut proc´eder `a une seconde phase — r´esolution —, elle aussi encod´ee par une strat´egie de r´e´ecriture. Pour mettre en œuvre la m´ethode g´en´erale de transformation que nous proposons [BCMP12], nous avons ajout´e trois constructions principales au langage Tom : — %transformation pour exprimer une transformation (listing 6.2) ; — %resolve pour int´egrer et cr´eer les ´el´ements resolve (listing 6.3) ; — %tracelink pour assurer la r´esolution des liens ainsi que la tra¸cabilit´e de la transformation (listing 6.4). TransformationConstruct ::= ’%transformation’ TransformationName ’(’[TransformationArguments]’)’ ’:’ FileName ’->’ FileName ’{’ (Definition)+ ’}’ TransformationArguments ::= SubjectName ’:’ AlgebraicType ( ’,’ SubjectName ’:’ AlgebraicType )* Definition ::= ’definition’ DefinitionName ’traversal’ Strategy ’{’ (DefinitionRule)+ ’}’ DefinitionRule ::= Pattern ’->’ ’{’ BlockList ’}’ Listing 6.2 – Syntaxe concr`ete de la construction %transformation. ResolveConstruct ::= ’%resolve’ ’(’ VarName ’:’ TypeName ’,’ VarName ’:’ TypeName ’)’ VarName ::= Identifier TypeName ::= Identifier Listing 6.3 – Syntaxe concr`ete de la construction %resolve. TracelinkConstruct ::= ’%tracelink’ ’(’ VarName ’:’ TypeName ’,’ BackQuoteTerm ’)’ VarName ::= Identifier TypeName ::= Identifier Listing 6.4 – Syntaxe concr`ete de la construction %tracelink.68 Chapitre 6. Outils pour exprimer une transformation de mod`eles en Tom Ces constructions nous permettent d’impl´ementer des transformations avec les caract´eristiques suivantes, selon des crit`eres propos´es par Czarnecki [CH03, CH06] : — r`egles de transformation : une r`egle contient des patterns et des variables, et b´en´eficie de typage. L’application des r`egles peut ˆetre contrˆol´ee par le param´etrage des transformations ´el´ementaires que l’utilisateur averti peut faire varier ; — ordonnancement des r`egles : nos r`egles ne sont pas ordonn´ees ni interactives. Par d´efaut, et si le flot d’ex´ecution n’est pas interrompu (par des instructions du type break ou return), les r`egles sont appliqu´ees sur tous les motifs filtr´es du mod`ele source. Ce comportement peut toutefois ˆetre modifi´e par le param´etrage de la d´efinition en cours via une strat´egie ad-hoc. L’ordre d’´ecriture des d´efinitions et des r`egles n’a pas d’impact sur le r´esultat final ; — d´ecoupage en phases : nos transformations sont constitu´ees de deux phases, l’une pour transformer, l’autre pour r´esoudre les liens ; — sens des r`egles et des transformations : nos r`egles sont unidirectionnelles, nos transformations ne sont pas naturellement bidirectionnelles ; — modularit´e et m´ecanismes de r´eutilisation : nos transformations reposent sur le langage de strat´egies de r´e´ecriture de Tom dont l’une des caract´eristiques est la modularit´e. Si une r`egle ne peut ˆetre directement r´eutilis´ee ailleurs, une d´efinition (un ensemble de r`egles) peut en revanche l’ˆetre ; — relation entre l’entr´ee et la sortie : le mod`ele cible est diff´erent du mod`ele source, mˆeme dans le cas d’une transformation endog`ene (transformation out-place) ; — port´ee de la transformation : tout ou partie du mod`ele peut ˆetre transform´e, en fonction des patterns dans les r`egles d´efinies par l’utilisateur ; — tra¸cabilit´e : durant une transformation, nous maintenons des liens entre les ´el´ements sources et cibles. La syntaxe des nouvelles constructions du langage ainsi que les caract´eristiques des transformations de notre approche ´etant ´etablies, d´etaillons pr´ecis´ement ces constructions. Pour illustrer notre propos, nous nous appuierons sur la transformation propos´ee en exemple pr´ec´edemment. Cette transformation consiste `a transformer le mod`ele texte A;B en une figure constitu´ee de formes g´eom´etriques (figure 6.1). Afin d’illustrer concr`etement l’extension du langage, nous nous appuierons sur l’extrait de code donn´e par le listing 6.5. Les points de suspension d´enotent le fait qu’il est parcellaire dans le but de mettre en avant les nouvelles constructions du langage et de rendre plus lisible l’extrait de code ainsi que son explication. Nous adoptons en outre le code visuel suivant : les nouvelles constructions du langage apparaissent en bleu tandis que le texte soulign´e et color´e marque les correspondances dans la transformation entre les ´el´ements des constructions. Ce code visuel permet de comprendre clairement les relations entre les termes cr´e´es par les nouvelles constructions du langage.6.2. Extension du langage 69 1 %transformation Text2Picture(link:LinkClass, gp:GeoPicture): 2 "text.ecore" -> "picture.ecore" { 3 4 definition Letter2Shape traversal ‘TopDown(Letter2Shape(link,gp)) { 5 source@BText() -> { 6 //use target_right 7 Shape greenSquare = %resolve(source:BText,target_right:Square); 8 Shape bluePentagon = ‘Pentagon(blue()); 9 Segment segment = ‘Segment(bluePentagon, greenSquare); 10 ... 11 } 12 AText() -> { 13 %tracelink(target_left:Circle,‘Circle(red())); //define target_left 14 Shape redHexagon = ‘Hexagon(red()); 15 Segment segment = ‘Segment(redHexagon, target_left); 16 ... 17 } 18 ... 19 } 20 21 definition Symbol2Shape traversal ‘BottomUp(Symbol2Shape(link,gp)) { 22 SemiColon[left=l] -> { 23 Shape greenTriangle = ‘Triangle(green()); 24 %tracelink(target_right:Square,‘Square(green())); //define target_right 25 Segment right_segment = ‘Segment(greenTriangle, target_right); 26 Shape redCircle = %resolve(l:AText,target_left:Circle);//use target_left 27 Segment left_segment = ‘Segment(redCircle, greenTriangle); 28 ... 29 } 30 ... 31 } 32 ... 33 } Listing 6.5 – Extrait de code de la transformation Text2Picture illustrant les nouvelles constructions Tom d´edi´ees aux transformations de mod`eles et correspondant aux transformations pr´esent´ees dans la figure 4.870 Chapitre 6. Outils pour exprimer une transformation de mod`eles en Tom 6.2.1 Expression d’une transformation Une transformation prend un mod`ele source en param`etre et renvoie un mod`ele cible. L’encodant sous la forme d’une strat´egie de r´e´ecriture compos´ee, nous proposons une construction haut niveau g´erant automatiquement sa combinaison. Elle est compos´ee de transformations ´el´ementaires — d´efinitions —, repr´esent´ees par des blocs definition. Une d´efinition op`ere une transformation sur des ´el´ements d’un type unique : deux ´el´ements ayant des types diff´erents (et sans surtype commun) ne peuvent ˆetre transform´es dans une mˆeme d´efinition. Une transformation comporte donc au moins autant de d´efinitions qu’il y a de types d’´el´ements que l’utilisateur souhaite transformer. Chaque d´efinition est constitu´ee d’un ensemble de r`egles de r´e´ecriture compos´ees d’un pattern (membre gauche) ainsi que d’une action (membre droit). Une action est un bloc pouvant contenir du code hˆote et du code Tom. De plus, chaque d´efinition — encod´ee par une strat´egie — est nomm´ee et param´etr´ee par une strat´egie de parcours que l’utilisateur averti peut faire varier. Chacune de ces d´efinitions est ´ecrite sans notion d’ordre par rapport aux autres d´efinitions et elles n’entretiennent aucune d´ependance dans le sens o`u l’entr´ee de l’une n’est pas la sortie d’une autre. La transformation est de type out-place (la source n’est jamais modifi´ee) et la source de chaque d´efinition est le mod`ele source. Le r´esultat de la transformation ne d´epend donc pas de l’ordre d’´ecriture des d´efinitions adopt´e par l’utilisateur. La transformation finale est encod´ee par une strat´egie qui est une s´equence de ces d´efinitions. Dans l’exemple, la transformation nomm´ee Text2Picture est introduite par le lex`eme %transformation (ligne 1). Elle sert `a transformer un mod`ele conforme au m´etamod`ele text.ecore en un mod`ele conforme au m´etamod`ele picture.ecore, ce qui est symbolis´e par les noms de fichiers des deux m´etamod`eles de part et d’autre du lex`eme -> (ligne 2). Cette transformation prend deux arguments : link qui est le mod`ele de lien qui sera peupl´e durant la transformation, et gp qui est le mod`ele cible qui sera construit au fur et `a mesure de l’avanc´ee des pas d’ex´ecution. Cette transformation est constitu´ee d’au moins deux d´efinitions nomm´ees Letter2Shape (ligne 4) et Symbol2Shape (ligne 20). Elles sont toutes deux param´etr´ees par une strat´egie introduite par le mot-clef traversal pouvant ˆetre diff´erente pour chaque d´efinition (bien que cela n’ait pas d’impact dans cet exemple, nous avons utilis´e deux strat´egies diff´erentes — TopDown et BottomUp — pour illustrer cette possibilit´e). C’est cette strat´egie qui est utilis´ee pour appliquer les transformations ´el´ementaires. Il est `a noter que les param`etres de la transformation sont aussi les param`etres de ces strat´egies. Les d´efinitions sont constitu´ees de r`egles de r´e´ecriture `a l’image des strat´egies Tom. Le fait que la d´efinition qui traduit les lettres en formes g´eom´etriques soit ´ecrite avant ou apr`es celle qui transforme les symboles n’a aucune importance. La d´efinition Letter2Shape comprend deux r`egles : l’une pour transformer les ´el´ements de type BText (lignes 5 `a 10) et l’autre pour transformer les ´el´ements de type AText (lignes 11 `a 16). La d´efinition Symbol2Shape est quant `a elle constitu´ee d’une seule r`egle qui transforme les ´el´ements de type SemiColon (lignes 21 `a 28). Une fois d´efinie, une transformation peut ˆetre utilis´ee (appel´ee) comme toute autre strat´egie Tom via la fonction visit(). Seule, la construction %transformation permet d’exprimer la premi`ere phase de la transformation en g´en´erant une strat´egie compos´ee. 6.2.2 R´esolution La seconde phase de la transformation (r´esolution) est exprim´ee grˆace `a deux autres constructions. Pour int´egrer et cr´eer des ´el´ements interm´ediaires resolve, nous avons introduit une nouvelle construction : %resolve (syntaxe donn´ee dans le listing 6.3). Elle permet de cr´eer les termes interm´ediaires pour repr´esenter les ´el´ements cens´es ˆetre cr´e´es dans une autre d´efinition. Cette construction correspond `a une sp´ecialisation de la construction backquote (‘), en ce sens qu’elle cr´ee un terme tout en d´eclenchant un autre traitement, `a savoir la g´en´eration6.2. Extension du langage 71 d’un mapping d´edi´e. La construction %resolve prend deux param`etres : l’´el´ement source en cours de transformation et le nom de l’´el´ement de l’image d’un ´el´ement transform´e dans une autre d´efinition que ce terme est cens´e repr´esenter. Cet ´el´ement transform´e dans une autre d´efinition est quant `a lui marqu´e comme pouvant ˆetre r´esolu via la construction %tracelink (syntaxe donn´ee dans le listing 6.4). Elle est le pendant de %resolve et apparaˆıt obligatoirement dans le code si l’utilisation d’´el´ements interm´ediaires est n´ecessaire. Elle correspond elle aussi `a une sp´ecialisation de la construction backquote : elle permet de cr´eer un terme tout en mettant `a jour la structure de donn´ees qui maintient les liens de tra¸cabilit´e interne (pour la r´esolution). La construction %tracelink prend deux param`etres : le nom du terme marqu´e (accompagn´e de son type) ainsi que le terme lui-mˆeme (terme backquote). Dans notre exemple support, la transformation d’un ´el´ement B en la forme constitu´ee d’un pentagone bleu et d’un connecteur n´ecessite l’introduction d’un ´el´ement resolve. En effet, le connecteur carr´e est cr´e´e dans une autre d´efinition — Symbol2Shape — et nous devons utiliser le m´ecanisme de cr´eation d’´el´ements interm´ediaires resolve. A la ligne 6, nous ` instancions donc un terme resolve qui remplacera temporairement l’´el´ement target_right de l’image de la transformation du symbole SemiColon (;). Outre le fait de jouer le rˆole de placeholder et de pouvoir ˆetre manipul´e comme s’il s’agissait d’un ´el´ement classique du mod`ele cible, l’´el´ement resolve maintient aussi un lien entre l’´el´ement source (b, de type BText) qui a provoqu´e sa cr´eation et la cible repr´esent´ee. Dans notre exemple, ce m´ecanisme est r´eit´er´e dans la d´efinition suivante (ligne 25) et peut ˆetre utilis´e autant de fois que n´ecessaire dans la transformation. 6.2.3 Tra¸cabilit´e Nous avons ´egalement ´etendu le langage afin d’ajouter la tra¸cabilit´e aux transformations. Une possibilit´e eˆut ´et´e de tracer syst´ematiquement les termes cr´e´es, puis de mettre en œuvre un m´ecanisme de requˆete pour retrouver les informations int´eressantes. Cependant, cette approche aurait donn´ee des traces extrˆemement verbeuses et donc peu exploitables. Pour ´eviter cet ´ecueil, nous avons fait le choix d’une tra¸cabilit´e `a la demande, impl´ement´ee par la construction %tracelink dont la syntaxe a ´et´e donn´ee en d´ebut de section dans le listing 6.4. Bien que techniquement impl´ement´ee par un unique lex`eme, la notion de tra¸cabilit´e est double. Ce lex`eme a donc actuellement deux usages — pour deux types de tra¸cabilit´e — `a savoir : — assurer la tra¸cabilit´e interne (ou technique) : pour sp´ecifier les ´el´ements correspondant aux ´el´ements resolve cr´e´es lors de la transformation, afin que la phase de r´esolution puisse effectuer le traitement (nous pouvons parler de resolveLink) ; — assurer la tra¸cabilit´e au sens de la qualification logicielle : construire d’une part le m´etamod`ele de lien `a la compilation de la transformation, et d’autre part peupler la trace `a l’ex´ecution (nous parlons dans ce cas de trace). Quelle que soit la tra¸cabilit´e voulue, nous souhaitons sp´ecifier `a la demande quels sont les ´el´ements que nous cr´eons que nous souhaitons tracer. L’utilisateur doit donc explicitement d´esigner les termes Tom `a tracer. Chaque terme tra¸cable appartenant `a une d´efinition de la transformation, l’´el´ement du mod`ele source dont il est issu est implicite. Du point de vue de l’utilisateur, tracer un terme revient simplement `a utiliser la construction d´edi´ee en sp´ecifiant son nom, son type et en ´ecrivant le terme via la construction backquote. Dans le cadre d’une tra¸cabilit´e interne, la construction correspond au pendant des ´el´ements resolve (resolveLink). La cr´eation d’´el´ements resolve dans la transformation implique alors l’utilisation d’au moins un marquage de ce type. Cette utilisation est celle pr´esent´ee dans la section pr´ec´edente. Dans le cadre d’une tra¸cabilit´e de transformation au sens de la qualification logicielle, la construction de trace peut ˆetre utilis´ee de mani`ere ind´ependante de la construction pour la72 Chapitre 6. Outils pour exprimer une transformation de mod`eles en Tom r´esolution. Une transformation peut donc comporter des constructions de trace sans qu’aucune construction de r´esolution ne soit utilis´ee. Dans notre approche, l’utilisateur ne fournit pas de m´etamod`ele de lien a priori. La construction de trace permet de g´en´erer le m´etamod`ele de lien de la transformation lors de la compilation, c’est-`a-dire de g´en´erer les structures liant sources et cibles en fonction des termes trac´es. A l’ex´ecution, ces structures sont peupl´ees pour ` maintenir les relations entre les sources et les cibles de la transformation. La construction de trace lie un ´el´ement cible cr´e´e `a la source en cours de transformation, ce qui permet d’´etablir un ensemble de relations 1..N (une source associ´ee `a plusieurs cibles). Dans notre exemple support, l’utilisateur a d´ecid´e d’op´erer une trace minimale, c’est-`adire que les ´el´ements trac´es sont ceux qui doivent imp´erativement ˆetre trac´es pour que la r´esolution s’op`ere correctement. C’est donc la tra¸cabilit´e technique qui est essentiellement utilis´ee ici. Les traces sont activ´ees par les lex`emes %tracelink (lignes 12 et 23). Celui de la ligne 23 correspond `a l’´el´ement resolve de la ligne 6 (soulign´e en magenta), tandis que celui de la ligne 12 `a celui de la ligne 25 (soulign´e en noir). L’utilisateur aurait bien ´evidemment pu tracer les autres ´el´ements cr´e´es (par exemple bluePentagon `a ligne 7). Mˆeme si l’usage de %tracelink dans cet exemple fait transparaˆıtre la volont´e de l’utilisateur d’avoir uniquement une tra¸cabilit´e technique, un mod`ele de lien minimal de la transformation est n´eanmoins cr´e´e. La transformation sp´ecifie un mod`ele de lien (link dans notre cas) dans lequel nous stockons les associations ´etablies entre les ´el´ements sources et les ´el´ements cibles trac´es tout au long de la transformation. En fin de transformation, cette trace peut ˆetre s´erialis´ee pour un usage ult´erieur. En exp´erimentant nos outils, nous nous sommes aper¸cus que l’utilisation d’une construction unique pour deux usages distincts pouvait perturber l’utilisateur. Nous projetons donc `a terme de s´eparer cette construction en deux constructions distinctes, chacune adapt´ee `a une des tra¸cabilit´es. 6.3 Travaux d’impl´ementation Les travaux d’impl´ementation pour ´etendre le langage ont concern´e deux parties du projet Tom : d’une part le compilateur Tom, d’autre part l’outil Tom-EMF. Avant de d´etailler la mani`ere dont nous avons mis en œuvre notre extension du projet, nous d´ecrivons l’architecture du projet Tom ainsi que le processus de compilation dans le contexte de Java. Cela nous permettra ensuite d’expliquer comment nous nous sommes int´egr´es dans l’existant. 6.3.1 Architecture du projet Tom et chaˆıne de compilation Le projet Tom s’articule autour de trois outils distincts utilisables ind´ependamment : le compilateur lui-mˆeme, Gom et l’outil de g´en´eration d’ancrages formels Tom-EMF. Le projet Tom comprend aussi un ensemble de biblioth`eques (notamment la biblioth`eque de strat´egies sl, des ancrages alg´ebriques, un outil de conversion DOM XML vers Gom et inverse, une biblioth`eque de bytecode Java, etc.) ainsi que de tr`es nombreux exemples et tests unitaires. La gestion des phases de compilation est assur´ee par la plateforme sur laquelle s’appuient Tom et Gom. L’ensemble du projet compte environ 60 000 lignes de code, r´eparties dans les sous-projets engine (compilateur Tom lui-mˆeme), gom, library, emf, ainsi que platform. L’essentiel du code source est ´ecrit en Tom (+Java) ainsi qu’en Java pur. La Table 6.1 r´esume cette r´epartition par projet et par langage.6.3. Travaux d’impl´ementation 73 Sous-projet Nombre de lignes par langage Total tom gom java ada python engine 20 467 471 2690 - - 23 628 library 15 062 297 2547 2074 1746 21 726 gom 9572 188 1734 - - 11 494 emf 1479 - - - - 1479 platform 416 16 602 - - 1034 Total 46 996 972 7573 2074 1746 59 351 % 79,17% 1,64% 12,76% 3,49% 2,94% 100% Table 6.1 – Nombre de lignes de code dans le projet Tom, par sous-projet et par langage Le langage Tom a ´et´e con¸cu pour ´etendre des langages hˆotes. La chaˆıne de compilation (figure 6.5) a ´et´e pens´ee de mani`ere `a minimiser le code sp´ecifique `a chaque langage hˆote. Le compilateur ne traitant que la partie Tom et n’analysant pas le code hˆote, seules les constructions Tom sont pars´ees puis trait´ees par chaque phase du compilateur, jusqu’`a la compilation `a proprement parler. Durant cette phase, plutˆot que de compiler directement vers le langage cible, Tom compile vers un langage interm´ediaire (IL) qui sert de langage pivot. Les constructions de ce langage sont ensuite traduites dans le langage cible lors de la derni`ere phase de compilation. Ainsi, l’extension `a un nouveau langage passe par l’´ecriture d’un nouveau backend sans forc´ement avoir `a r´e´ecrire ou adapter la chaˆıne compl`ete du compilateur. Nos exemples sont centr´es sur Java ´etant donn´e que son backend est le plus avanc´e. Cependant Tom supporte d’autres langages : Ada, C, Caml, C#, Python. Le tableau 6.2 donne l’impl´ementation des fonctionnalit´es en fonction des backends. Langage Filtrage Ancrages Strat´egies Gom Tom-EMF %transformation Ada X X X × en cours en cours Java X X X X X X C X X × × × × Caml X X × × × × C# X X × × × × Python X X X × × × Table 6.2 – Impl´ementation de fonctionnalit´es de Tom par langage cible. Un programme est ´ecrit en Tom+langage hˆote, accompagn´e d’ancrages pour faire le lien avec les structures de donn´ees hˆotes. Le compilateur analyse les constructions Tom et g´en`ere le code hˆote correspondant qui, coupl´e aux structures de donn´ees hˆotes, constitue un programme ´ecrit dans le langage hˆote que l’on compile avec le compilateur ad´equat. La figure 6.4 explique ce fonctionnement global des outils du projet Tom dans l’environnement Java. La partie haute d´ecrit le processus de compilation d’un programme Tom coupl´e `a Gom, tandis que la partie basse se concentre sur le processus dans le cadre des transformations de mod`eles, c’est-`a-dire en utilisant l’outil Tom-EMF pour g´en´erer les ancrages alg´ebriques. Ces outils peuvent bien ´evidemment ˆetre utilis´es ind´ependamment.74 Chapitre 6. Outils pour exprimer une transformation de mod`eles en Tom Compilateur Tom Tom + Java Ancrages alg´ebriques Gom Signature Gom Structures de donn´ees Java Ancrages alg´ebriques EMF MM .ecore Tom-EMF Java EMF (MM) Code Java Compilateur Java 110010 101110 010100 Figure 6.4 – Diagramme d’activit´e d´ecrivant le processus de compilation d’un programme Tom. Le compilateur Tom se d´ecompose en phases – ´ecrites en Tom+Java – qui sont chaˆın´ees les unes apr`es les autres. Chacune proc`ede `a une transformation bien d´efinie sur l’entr´ee, et fournit une sortie `a la phase suivante. Nous d´ecrivons bri`evement chacune de ces phases ci-apr`es, et nous repr´esentons l’architecture du compilateur Tom avec la figure 6.5. Les blocs marqu´es en traits pointill´es indiquent les phases o`u nos travaux d’impl´ementation se sont essentiellement concentr´es tandis que la phase color´ee ´etait inexistante avant ce travail de th`ese. C’est le cœur de l’impl´ementation permettant de traiter l’extension du langage d´edi´ee aux transformations de mod`eles. transformer Code Tom parser syntax checker desugarer typer type checker expander compiler optimizer backend Code hˆote Compilateur Tom Figure 6.5 – Phases du compilateur Tom. Parser : Le parser produit un arbre de syntaxe abstraite (AST, Abstract-Syntax Tree) `a6.3. Travaux d’impl´ementation 75 partir du code d’entr´ee. Les constructions Tom sont repr´esent´ees par des nœuds particuliers tandis que les blocs de code hˆote sont stock´es dans l’arbre comme des chaˆınes de caract`eres. Dans le cas d’une construction %gom (ou de l’utilisation d’un fichier .gom), l’outil Gom est appel´e et son parser prend le relais pour l’analyse du bloc. Transformer : Le transformer est une phase qui a ´et´e ajout´ee durant cette th`ese afin de traiter les constructions du langage d´edi´ees aux transformations de mod`eles. Il traite en particulier les constructions %transformation, %resolve et %tracelink, les AST issus de ces deux derni`eres ´etant des sous-arbres de l’AST issu de %transformation. La mise en œuvre de cette phase est d´etaill´ee dans la section 6.3.3. Syntax checker : Le syntax checker effectue des v´erifications syntaxiques sur l’AST. Par exemple, il v´erifie que chaque symbole de fonction a ´et´e d´eclar´e et qu’il n’y a pas de d´ependance circulaire entre les conditions de filtrage. Desugarer : Le desugarer simplifie l’AST en transformant les diff´erents types de nœuds repr´esentant des constructeurs de langage hˆote en nœuds g´en´eriques. De plus, les variables anonymes y sont nomm´ees avec des noms frais (noms qui n’ont jamais ´et´e utilis´es pr´ec´edemment). Typer : Le typer effectue l’inf´erence de type et propage les types inf´er´es dans l’AST. Typer checker : Le type checker v´erifie les types et les rangs des symboles. Il v´erifie par exemple que les occurrences d’une mˆeme variable sont du mˆeme type. Expander : L’expander transforme une derni`ere fois l’AST avant la compilation : il traite les nœuds issus des constructions %strategy et g´en`ere les introspecteurs (structures pour parcourir un terme). Compiler : Le compiler transforme les nœuds Tom en instructions du langage interm´ediaire (IL, pour Intermediate Language) qui sert de langage pivot. Optimizer : L’optimizer est responsable de l’optimisation du code ´ecrit dans le langage interm´ediaire. Il limite par exemple le nombre d’assignations de variables. Backend : Le backend est le g´en´erateur de code cible. Durant cette phase, le langage interm´ediaire est traduit en instructions du langage cible. 6.3.2 G´en´erateur d’ancrages alg´ebriques Dans cette partie, nous d´ecrivons techniquement le g´en´erateur d’ancrages formels TomEMF. Il a ´et´e ´ecrit pour r´epondre au besoin de repr´esentation des mod`eles EMF sous la forme de termes Tom. Il est lui-mˆeme ´ecrit en Tom+Java et fonctionne de mani`ere compl`etement ind´ependante de l’extension du langage d´edi´ee aux transformations de mod`eles. Il est utilis´e de mani`ere stand-alone, c’est-`a-dire comme un logiciel `a part enti`ere, ex´ecut´e sans ˆetre appel´e par un programme Tom externe. La figure 6.6 d´ecrit le principe g´en´eral de fonctionnement que nous expliquons ci-apr`es : 1. Eclipse : m´etamod´elisation et g´en´eration des structures java (a) L’utilisateur ´ecrit un m´etamod`ele Ecore manuellement, ou en utilisant les modeling tools de Eclipse ; (b) Il g´en`ere ensuite le g´en´erateur de code Java (GenModel) `a partir de ce m´etamod`ele via Eclipse ; (c) Il g´en`ere ensuite les structures Java correspondantes et les exporte sous la forme d’une archive (.jar) ; 2. Tom-EMF : g´en´eration des ancrages alg´ebriques (a) L’utilisateur charge les structures Java g´en´er´ees et sp´ecifie `a Tom-EMF le(s) EPackage(s) pour le(s)quel(s) il souhaite g´en´erer des ancrages ; (b) Un fichier de mappings (.tom) est g´en´er´e par paquet ;76 Chapitre 6. Outils pour exprimer une transformation de mod`eles en Tom 3. Tom et Java : transformation de mod`eles (a) L’utilisateur inclut les ancrages dans sa transformation via la construction %include et importe les structures de donn´ees Java (import) ; (b) L’utilisateur peut alors utiliser les types apparaissant dans le m´etamod`ele et ´ecrire la transformation en Tom+Java, en utilisant ou non l’extension du langage, d´edi´ee aux transformations de mod`eles ; (c) La suite du processus est identique `a une utilisation classique de Tom (compilation du code Tom, puis du code Java). Compilateur Tom Tom + Java Ancrages alg´ebriques Tom-EMF Structures Java EMF EMF MM .ecore Code Java Compilateur Java 110010 101110 010100 Figure 6.6 – Processus de compilation d’une transformation de mod`eles Tom-EMF. Ce g´en´erateur extrait une signature alg´ebrique utilisable par Tom `a partir du code JavaEMF repr´esentant le m´etamod`ele. Au d´epart en tant que proof of concept, nous avons adapt´e et ´etendu le g´en´erateur d’ancrages Tom-EMF afin de construire un g´en´erateur pleinement op´erationnel d´edi´e aux mod`eles. Compte tenu de la forte utilisation de Java dans le d´eveloppement logiciel ainsi que de celle de Eclipse et de EMF dans la communaut´e de l’ing´enierie dirig´ee par les mod`eles, nous avons fait le choix de nous concentrer dans un premier temps sur ces technologies pour obtenir un outil fonctionnel. Cependant, nous ne nous limitons pas `a ces choix et n’excluons pas une ouverture de Tom-EMF `a d’autres technologies et langages. Notamment, certaines exp´eriences ont ´et´e men´ees dans le but d’´etendre l’outil au langage Ada et au framework GMS. Une autre piste d’extension envisag´ee est l’utilisation de KMF 51. Le d´eveloppement d’une transformation en Java-EMF n´ecessitant de toute mani`ere de g´en´erer la structure de donn´ees du m´etamod`ele pour l’utiliser au sein du programme, nous avons choisi de conserver dans un premier temps ce fonctionnement de g´en´eration de signature alg´ebrique `a partir du code. Cependant, si l’outil devait ˆetre ´etendu `a d’autres langages et technologies, nous pourrions revoir nos choix afin de g´en´erer la signature directement `a partir du m´etamod`ele au format .ecore. 51. Kevoree Modeling Framework : http://www.kevoree.org/kmf6.3. Travaux d’impl´ementation 77 Dans sa forme actuelle, Tom-EMF est en mesure de traiter plusieurs paquetages Ecore (EPackages) en entr´ee, et de g´en´erer un fichier d’ancrages pour chacun d’entre eux. Si des ´el´ements du m´etamod`ele sont utilis´es alors qu’ils appartiennent `a un autre EPackage du m´etamod`ele (ou d’un autre m´etamod`ele charg´e en m´emoire), alors notre g´en´erateur g´en`ere les mappings en cascade, tout en ´evitant la g´en´eration multiple d’un mˆeme paquetage. De la mˆeme mani`ere, cet outil ne g´en`ere les ancrages formels que pour les types qui n’en ont pas d´ej`a. Durant l’op´eration, nous maintenons donc un ensemble d’ancrages g´en´er´es et `a g´en´erer pour les types rencontr´es. Pour chaque EPackage sp´ecifi´e par l’utilisateur, Tom-EMF r´ecup`ere les EClassifiers (surclasse commune de EClass et EDataType permettant de sp´ecifier les types d’op´erations, de structural features et de param`etres) et g´en`ere les ancrages alg´ebriques associ´es. Si le m´etamod`ele sp´ecifie qu’un ´el´ement EClass poss`ede la propri´et´e abstract, l’op´erateur (%op) n’est naturellement pas g´en´er´e. Lorsque la multiplicit´e d’un attribut est strictement sup´erieure `a 1 (structural feature many), le champ de l’op´erateur est un type liste. Un ancrage suppl´ementaire est alors g´en´er´e, accompagn´e de l’op´erateur variadique correspondant. Les associations et compositions sont donc repr´esent´ees de cette mani`ere. Il est `a noter que Tom disposant d’un moteur d’inf´erence de type ´equip´e du sous-typage [KMT09], nous avons int´egr´e cette fonctionnalit´e dans Tom-EMF. Lorsque l’option ad´equate (-nt) est activ´ee, les ancrages g´en´er´es prennent en compte le sous-typage propos´e par Ecore. Si un type n’a pas de surtype explicitement donn´e, le surtype g´en´er´e dans l’ancrage est EObject (le type Object de Ecore) afin de correspondre aux conventions de EMF. Cette fonctionnalit´e de g´en´eration des sous-types est toutefois limit´ee au sous-typage simple : en effet Ecore supporte l’h´eritage multiple, mais pas Java (au niveau des classes). Nous verrons dans la section suivante que la fonctionnalit´e de sous-typage de Tom est utilis´ee en interne par le m´ecanisme de r´esolution (g´en´eration et remplacement des ´el´ements resolve). S’agissant des types issus des m´etamod`eles Ecore ou UML (ainsi que les types dits builtin), ceux-ci sont trait´es `a part (et non en cascade lorsqu’ils apparaissent) ´etant donn´e qu’il s’agit de m´etamod`eles tr`es utilis´es et que leurs types sont souvent inclus dans les transformations. De ce fait, nous diffusons les ancrages pour ces m´etamod`eles en tant que biblioth`eques dans le projet Tom. L’outil Tom-EMF lui-mˆeme est ´ecrit en Tom+Java et utilise ces ancrages Ecore. La premi`ere utilisation de notre g´en´erateur a donc ´et´e pour terminer son bootstrap, ce qui nous a permis de remplacer les ancrages ´ecrits manuellement par des ancrages g´en´er´es, comme l’illustre la figure 6.7. Dans cette figure, les fl`eches en trait plein sont `a comprendre comme des flux d’entr´ee et sortie, tandis que les fl`eches en pointill´es signifient int´egration `a l’outil. Tom-EMF Ecore.tom (manuel) Ecore.jar Ecore.tom Figure 6.7 – Bootstrap de Tom-EMF : remplacement des ancrages alg´ebriques Ecore.tom ´ecrits manuellement par les ancrages g´en´er´es. Tom-EMF g`ere aussi le pr´efixage des noms de types et d’op´erateurs g´en´er´es. En effet, il n’est pas rare de nommer de la mˆeme mani`ere des ´el´ements de m´etamod`eles diff´erents, mais qui n’appartiennent pas aux mˆemes paquetages. Cependant, Tom n’ayant pas de syst`eme d’espaces de noms (namespaces) pour ses types et op´erateurs, nous offrons `a l’utilisateur la possibilit´e de pr´efixer les ancrages g´en´er´es.78 Chapitre 6. Outils pour exprimer une transformation de mod`eles en Tom Enfin, pour rendre compl`etement op´erationnel le pont entre les deux espaces technologiques, Tom-EMF comprend un outil additionnel : EcoreContainmentIntrospector. Il s’agit d’une biblioth`eque permettant le parcours de mod`eles par des strat´egies. Elle repose sur le fait que le mod`ele poss`ede une structure arborescente par la relation de composition et d´e- finit le parcours de mod`eles suivant ces relations. Cette biblioth`eque s’utilise en conjonction des strat´egies (l’utilisateur passe cet introspecteur d´edi´e `a Ecore en param`etre de la strat´egie). Techniquement, cette biblioth`eque sp´ecialis´ee fournit des services n´ecessaires `a Tom pour compter, r´ecup´erer et modifier les enfants d’un nœud d’un terme repr´esentant un mod`ele. 6.3.3 Mise en œuvre de l’extension Dans cette partie, nous d´ecrivons la mise en œuvre de l’extension du langage au sein du compilateur Tom. Lors de l’impl´ementation de constructions d’un langage, plusieurs modifications de la chaˆıne de compilation sont n´ecessaires, de l’analyseur syntaxique au g´en´erateur de code. Dans notre cas, s’agissant de nouvelles constructions avec de nouveaux lex`emes, il fallait ´etendre le parser (d´ebut de chaˆıne) pour pouvoir les reconnaˆıtre. Ensuite, ces constructions entraˆınant la g´en´eration de code qui n’´etait pas encore trait´e par le compilateur, le backend (fin de chaˆıne) a aussi ´et´e ´etendu. Cependant, ces deux tˆaches ne sont pas le cœur de la mise en œuvre de l’extension du langage d´edi´ee aux transformations de mod`eles. En effet, l’essentiel de l’impl´ementation r´eside dans l’ajout d’une nouvelle phase — le transformer — dont la charge est de transformer les nœuds de l’arbre sp´ecialis´e dans la transformation de mod`eles en des strat´egies. A cela s’ajoute la g´en´eration automatique d’ancrages ainsi que celle de la ` trace dont les instructions sont ajout´ees `a l’arbre. Parser. L’aspect inhabituel de l’analyseur syntaxique de Tom r´eside dans le fait qu’il n’analyse pas tout le code, mais uniquement les ˆılots formels. Le code hˆote est quant `a lui vu comme une chaˆıne de caract`eres qui est parcourue jusqu’`a l’ˆılot suivant. Ce type d’analyse o`u la grammaire du langage n’est pas totalement d´efinie est appel´e fuzzy parsing : seule la grammaire de Tom l’est, totalement (on parle de grammaire ˆılot ou island grammar ). L’analyseur syntaxique de Tom repose sur le tr`es populaire g´en´erateur de parser ANTLR 52, ainsi que sur GomAntlrAdapter, un outil du projet permettant de lier les arbres g´en´er´es par ANTLR aux structures Gom. Lorsque le parser principal d´etecte une construction donn´ee, il donne la main `a un parser d´edi´e (Tom ou Gom). Il s’agissait donc d’´etendre ces analyseurs pour mettre en œuvre les nouvelles constructions, en ajoutant de nouvelles r`egles ad´equates dans la grammaire. En parall`ele, la signature de Tom a ´et´e ´etendue afin de prendre en compte ces nouvelles constructions. Transformer. Le cœur de la mise en œuvre de l’extension de Tom d´edi´ee aux transformations de mod`eles se situe au niveau du plugin transformer, juste apr`es l’analyseur syntaxique, et avant la phase de typage. Ce choix de nous ins´erer tˆot dans la chaˆıne de compilation est tout `a fait logique : la seule contrainte forte que nous avions ´etait d’apparaˆıtre avant l’expander — plugin d´edi´e aux strat´egies — et nous souhaitions aussi b´en´eficier au maximum des ´el´ements de contrˆole d´ej`a impl´ement´es dans le compilateur Tom (syntax checker, typer, type checker ). Cette phase prend en entr´ee l’arbre issu de l’analyseur syntaxique et produit un arbre syntaxique ne contenant plus aucun sous-arbre de type Transformation obtenu apr`es parsing de la construction %transformation. Elle est impl´ement´ee de mani`ere classique — du point de vue d’un d´eveloppeur Tom —, `a savoir qu’une strat´egie Tom est appliqu´ee sur l’arbre en entr´ee. Les nœuds de type Resolve et Tracelink obtenus `a partir du parsing des constructions %resolve et %tracelink sont forc´ement des sous-arbres des arbres dont la racine est un nœud Transformation ´etant donn´e que ces constructions sont uniquement utilisables dans le 52. ANother Tool for Language Recognition : http://www.antlr.org6.3. Travaux d’impl´ementation 79 cadre des transformations de mod`eles. En ne manipulant que ces derniers, nous sommes donc en mesure de collecter et traiter tous les nœuds Resolve et Tracelink. Dans le sous-arbre repr´esentant une transformation, nous filtrons les nœuds de type Resolve correspondant aux utilisations de la construction %resolve. Si un tel motif est filtr´e, le m´ecanisme d’enrichissement du m´etamod`ele cible pr´esent´e dans le chapitre 4 est d´eclench´e. Il est alors n´ecessaire de cr´eer d’une part les structures de donn´ees concr`etes repr´esentant les ´el´ements resolve, et d’autre part des ancrages alg´ebriques correspondants. Pour illustrer concr`etement ce m´ecanisme, reprenons l’instruction %resolve(l:AText,target_left:Circle); de l’exemple pr´ec´edent transformant du texte en figure g´eom´etrique. Elle entraˆıne la g´en´eration de la structure Java par le backend, donn´ee dans le listing 6.6 (par souci de lisibilit´e, les noms ont ´et´e simplifi´es et les attributs sont publics). 1 private static class ResolveATextCircle extends Circle { 2 public String name; 3 public AText o; 4 5 public ResolveATextCircle(Circle o, String name) { 6 this.name = name; 7 this.o = o; 8 } 9 } Listing 6.6 – Exemple de classe Java g´en´er´ee impl´ementant un ´el´ement resolve. La classe g´en´er´ee — ici ResolveATextCircle — ´etend naturellement la classe de l’´el´ement cible — Circle dans notre cas — que l’´el´ement resolve est cens´e repr´esenter. Cette classe est associ´ee `a un ancrage et la relation d’h´eritage de Java est exprim´ee par un sous-type dans le mapping d´ecrit dans le listing 6.7. Etant donn´e que ce m´ecanisme a lieu durant le processus ´ de compilation Tom->Java, cet ancrage n’apparaˆıt pas en tant que tel, mais est directement g´en´er´e en m´emoire pour ˆetre traduit en Java par la suite. Le listing 6.7 est n´eanmoins une traduction fid`ele du mapping qui serait ´ecrit en Tom. 1 %typeterm ResolveATextCircle extends Circle { 2 implement { ResolveWorkATextCircle } 3 is_sort(t) { t instanceof ResolveATextCircle } 4 } 5 6 %op Circle ResolveATextCircle(o:AText,name:String) { 7 is_fsym(t) { t instanceof ResolveATextCircle } 8 get_slot(name, t) { t.name } 9 get_slot(o, t) { t.o } 10 make(o,name) { new ResolveATextCircle(o,name) } 11 } Listing 6.7 – Exemple d’ancrage alg´ebrique g´en´er´e pour un ´el´ement resolve. C’est aussi dans le transformer que nous filtrons tous les symboles de type Tracelink. Pour chaque instruction de tra¸cage, le transformer cr´ee (ou r´ecup`ere si elle existe d´ej`a) ce que nous appelons une ReferenceClass. Il s’agit d’une structure de donn´ees permettant de r´ef´erencer les ´el´ements cibles trac´es. En termes d’impl´ementation Java, nous fournissons une interface ReferenceClass extrˆemement simple (listing 6.8) que les structures de donn´ees g´en´er´ees impl´ementent.80 Chapitre 6. Outils pour exprimer une transformation de mod`eles en Tom 1 package tom.library.utils; 2 3 public interface ReferenceClass { 4 public Object get(String name); 5 } Listing 6.8 – Interface devant ˆetre impl´ement´ee par les structures de type ReferenceClass. Ces classes sont essentiellement constitu´ees d’attributs (les r´ef´erences vers les ´el´ements cibles), de leurs m´ethodes d’acc`es (get et set) ainsi que d’une m´ethode permettant d’associer un nom `a un ´el´ement. Le listing 6.9 montre une classe qui serait g´en´er´ee dans le cas de notre exemple de transformation de texte en formes g´eom´etriques. 1 public static class tom__reference_class_Letter2Shape 2 implements tom.library.utils.ReferenceClass { 3 private Circle target_left; 4 public Circle gettarget_left() { return target_left; } 5 public void settarget_left(Circle value) { this.target_left = value; } 6 7 public Object get(String name) { 8 if(name.equals("target_left")) { 9 return gettarget_left(); 10 } else { 11 throw new RuntimeException("This field does not exist:" + name); 12 } 13 } 14 } Listing 6.9 – Exemple de classe g´en´er´ee impl´ementant l’interface ReferenceClass dans le cas de la transformation Text2Picture. Une structure de type ReferenceClass est elle-mˆeme li´ee `a l’´el´ement source filtr´e par la r`egle qui lui a donn´e naissance. Techniquement, cela consiste `a maintenir une table de hachage dont les clefs sont des sources de type EObject et dont les valeurs sont ces structures de donn´ees. Cette table de hachage fait partie int´egrante du mod`ele de lien de la transformation, impl´ement´e par la classe LinkClass (fournie en tant que biblioth`eque avec son ancrage associ´e). Toute d´efinition d’un sous-arbre Transformation est quant `a elle transform´ee en une strat´egie comprenant les r`egles de la d´efinition, accompagn´ee de son symbole. Une strat´egie plus complexe est ensuite compos´ee `a partir de ces strat´egies. Finalement, tout nœud de type Transformation est remplac´e par sa strat´egie nouvellement cr´e´ee ainsi que par une ´eventuelle strat´egie de r´esolution. Backend. En fin de chaˆıne de compilation, au niveau du g´en´erateur de code (backend), le travail a consist´e `a ajouter des fonctions de g´en´eration de la phase de r´esolution ainsi que celles pour le m´etamod`ele de lien qui n’existaient pas auparavant. Ces derni`eres produisent du code similaire `a celui que nous avons montr´e pr´ec´edemment dans les listings 6.8 et 6.9, dans la partie d´ecrivant la m´ecanique du greffon transformer. La mise en œuvre de la g´en´eration de la phase de r´esolution a fait l’objet de nombreuses ´evolutions au cours de ce travail. Nous d´ecrirons son ´etat stable actuel (inclus dans la derni`ere version stable publi´ee : Tom-2.10) ainsi que celui de la prochaine version stable.6.3. Travaux d’impl´ementation 81 La phase de r´esolution ´etant encod´ee sous la forme d’une strat´egie de r´e´ecriture, sa g´en´eration est en partie identique `a la g´en´eration de strat´egies classiques. Cependant, elle se distingue d’elles par le fait qu’il faille aussi ´ecrire une proc´edure suppl´ementaire permettant d’effectuer la r´esolution de liens inverses. Cette proc´edure consiste `a notifier tous les objets du mod`ele ayant un pointeur vers l’objet qui vient d’ˆetre modifi´e pour que ce pointeur pointe vers le nouvel objet et non plus vers l’´el´ement resolve. La figure 6.8 illustre ce m´ecanisme. La figure 6.8a est l’´etat du mod`ele en fin de premi`ere phase. Il est constitu´e d’´el´ements cibles ainsi que d’´el´ements resolve (en pointill´es). Les ´el´ements `a r´esoudre sont d´etect´es et l’´el´ement cible effectif est identifi´e (figure 6.8b). Tous les ´el´ements faisant r´ef´erence `a cet ´el´ement resolve doivent aussi ˆetre mis `a jour. Dans l’exemple, le connecteur entre le pentagone bleu et le carr´e vert r´ef´erence le carr´e vert temporaire. Son extr´emit´e (un pointeur vers l’´el´ement resolve) est mise `a jour pour r´ef´erencer l’´el´ement cible final (figure 6.8c). Une fois la r´esolution de liens inverses effectu´ee, le mod`ele ne comprend plus d’´el´ement resolve (6.8d). (a) (b) (c) (d) Figure 6.8 – Processus de r´esolution de liens inverses. Dans le contexte de EMF, ce traitement peut ˆetre fait en utilisant les services fournis. Dans la strat´egie de r´esolution, nous effectuons donc une r´esolution de liens inverses pour chaque ´el´ement resolve trouv´e et remplac´e. La proc´edure de r´esolution de liens inverses peut ˆetre automatis´ee ; mais d´ependant des types des ´el´ements du mod`ele, elle ne peut ˆetre g´en´erique et doit donc ˆetre g´en´er´ee pour chaque transformation. Pour rendre possible la g´en´eration de ce code additionnel dans les strat´egies, il a ´et´e n´ecessaire de modifier la signature des strat´egies afin de pouvoir embarquer du code suppl´ementaire, ainsi que l’expander. Le backend des strat´egies a ensuite ´et´e adapt´e afin de prendre en compte cette nouveaut´e. Signalons que la phase de r´esolution n’apparaˆıt pas dans l’extrait de code pr´esent´e plus tˆot dans le chapitre. Il ne s’agit pas d’une simplification du code pour les besoins de notre propos, mais bien du fonctionnement normal de nos outils. En effet, la phase de r´esolution est enti`erement g´en´er´ee, en fonction de l’utilisation des constructions %resolve au sein de la transformation. Ainsi, une transformation ne n´ecessitant pas d’´el´ement resolve (donc sans utilisation du lex`eme %resolve) n’a pas de phase de r´esolution. A l’inverse, l’utilisation de la ` construction provoque la g´en´eration du bloc de r´esolution d´edi´e au type trait´e. Dans la version actuellement publi´ee de l’outil (Tom-2.10), cette phase est encod´ee par une unique strat´egie que l’utilisateur n’´ecrit qu’indirectement par l’usage judicieux des constructions de r´esolution. L’application de la strat´egie de r´esolution est n´eanmoins `a la charge de l’utilisateur au sein de son programme. Il doit appeler la strat´egie en l’appliquant sur le mod`ele interm´ediaire cr´e´e lors de la premi`ere phase. Par la suite, nous avons exp´eriment´e notre langage et avons constat´e que l’utilisation intensive des services EMF avait des cons´equences importantes sur les performances de la transformation, tant du point de vue de la m´emoire consomm´ee que du temps. Nous avons donc fait ´evoluer la phase de r´esolution en nous passant des services EMF pour la r´esolution de liens. Dans un premier temps, plutˆot que d’utiliser les m´ethodes EMF, nous avons ´ecrit notre propre m´ethode de r´esolution en ´evitant de parcourir tous les objets du mod`ele comme le fait EMF. Dans un second temps, nous avons ´ecrit une phase de r´esolution sans strat´egie afin de ne plus du tout parcourir le mod`ele interm´ediaire. Pour r´ealiser cette optimisation, nous conservons tout au long de la transformation un ensemble de r´ef´erences inverses pour chaque ´el´ement resolve cr´e´e (les seuls ´el´ements du mod`ele interm´ediaire concern´es par la r´esolution82 Chapitre 6. Outils pour exprimer une transformation de mod`eles en Tom de liens inverses). Nous d´etaillerons l’aspect performances de nos outils dans le chapitre 8. Nous avons aussi exp´eriment´e une version modulaire de la phase de r´esolution. Plutˆot que de g´en´erer une strat´egie monolithique effectuant toute la r´esolution, nous avons ´ecrit une solution alternative g´en´erant plusieurs strat´egies de r´esolution partielle, chacune de ces strat´egies n’effectuant la r´econciliation que sur un type de terme donn´e. Dans notre exemple, cette alternative g´en´ererait deux strat´egies distinctes, ainsi qu’une strat´egie combinant les deux. L’inconv´enient de cette solution est qu’elle est plus complexe `a prendre en main pour l’utilisateur. Cependant, elle a l’avantage d’offrir une plus grande modularit´e en d´ecomposant la seconde phase. Ainsi, le code g´en´er´e pour une d´efinition peut ˆetre r´eutilis´e dans une autre transformation, et l’utilisateur averti prendra soin d’accompagner la d´efinition de la (ou des) strat´egie(s) de r´esolution correspondante(s). Pour des raisons d’utilisabilit´e de nos outils, nous avons fait le choix de diffuser la version du g´en´erateur de phase de r´esolution monolithique dans la version stable de Tom. 6.4 Synth`ese Dans ce chapitre, nous avons d’abord montr´e une utilisation concr`ete de nos outils appliqu´ee sur un exemple simple. Nous avons pr´esent´e l’extension du langage Tom permettant de mettre en œuvre notre approche de transformation. Les trois aspects principaux de cette extension sont : l’expression de la transformation elle-mˆeme, le m´ecanisme de r´esolution et d’extension du m´etamod`ele cible par des ´el´ements temporaires, ainsi que la tra¸cabilit´e. Ces ´el´ements sont respectivement mis en œuvre par les constructions %transformation, %resolve et %tracelink. Nous avons par ailleurs pr´esent´e nos travaux d’impl´ementation ainsi que leur int´egration au sein du projet Tom. Nous avons notamment d´ecrit le g´en´erateur d’ancrages alg´ebriques Tom-EMF permettant d’op´erer le changement d’espace technologique modeles ` → termes. Nous avons de plus expliqu´e comment nous analysions et transformions les sous-arbres issus des nouvelles constructions du langage Tom dans la phase transformer, et quel ´etait le code g´en´er´e par le backend. Nous avons exp´eriment´e nos outils et les premiers retours nous donnent des pistes de travail int´eressantes sur l’usage des technologies externes sur lesquelles le prototype repose, sur le concept de modularit´e d’une transformation (et donc aussi de la r´esolution), mais aussi sur la conception du langage lui-mˆeme (s´eparation explicite des tra¸cabilit´es). Nous reparlerons de ces exp´eriences et des perspectives offertes dans la suite de ce document. Tout au long de ce chapitre, nous nous sommes appuy´es sur l’exemple simple d’une transformation de texte en formes g´eom´etriques color´ees pour expliquer les m´ecanismes en jeu. Nous nous proposons d’´etudier une transformation compl`ete dans le chapitre suivant.Chapitre 7 Etudes de cas : illustration et ´ utilisation du langage Dans ce chapitre, nous pr´esentons un cas d’´etude et expliquons le processus complet ainsi que son impl´ementation, depuis les m´etamod`eles jusqu’au code de la transformation. Dans la section 7.1, nous pr´esentons le cas d’´etude SimplePDLToPetriNet tandis que dans la section 7.2 nous pr´esentons le cas de la transformation de l’aplatissement d’une hi´erarchie de classes. 7.1 Cas SimplePDLToPetriNet Dans cette section, nous pr´esentons la transformation SimplePDLToPetriNet introduite dans les chapitres pr´ec´edents. Elle a ´et´e pr´esent´ee et trait´ee par Benoˆıt Combemale [Com08]. Son principe est de transformer la repr´esentation d’un processus exprim´e avec le langage SimplePDL en sa repr´esentation exprim´ee dans le formalisme des r´eseaux de Petri. L’int´erˆet de cette transformation dans la communaut´e est de travailler sur la v´erification : dans le formalisme SimplePDL, il n’est pas possible de v´erifier directement le processus d´ecrit tandis que sous forme de r´eseau de Petri — qui est un mod`ele math´ematique —, il est tout `a fait possible de l’utiliser avec un model-checker pour en v´erifier des propri´et´es. Nous rappelons d’abord les m´etamod`eles permettant d’exprimer un processus que nous avons d´ej`a pr´esent´es et expliqu´es pr´ec´edemment, puis nous donnons un exemple de processus d´ecrit en SimplePDL ainsi que sa version sous forme de r´eseau de Petri. 7.1.1 M´etamod`eles M´etamod`ele source : formalisme SimplePDL Nous reprenons le m´etamod`ele 5.1 que nous compl´etons afin de pouvoir repr´esenter des processus hi´erarchiques. Nous ajoutons deux relations opposite entre les m´etaclasses WorkDefinition et Process, les autres ´el´ements restant identiques. Une WorkDefinition peut ainsi ˆetre elle-mˆeme d´efinie par un processus imbriqu´e (r´ef´erence process), qui conserve un lien vers l’activit´e qu’il d´ecrit (r´ef´erence from). Nous obtenons le m´etamod`ele illustr´e par la figure 7.1. 8384 Chapitre 7. Etudes de cas : illustration et utilisation du langage ´ Process name : String ProcessElement WorkDefinition name : String WorkSequence linkType : WorkSequenceType <> WorkSequenceType startToStart finishToStart startToFinish finishToFinish processElements * process 0..1 from 0..1 parent 1 successor 1 * linksToPredecessors predecessor 1 * linksToSuccessors Figure 7.1 – M´etamod`ele SimplePDL. M´etamod`ele cible : formalisme des r´eseaux de Petri Nous reprenons le m´etamod`ele des r´eseaux de Petri propos´e dans le chapitre 5, sans aucune modification additionnelle. La figure 7.2 est un rappel du m´etamod`ele des r´eseaux de Petri que nous utilisons. PetriNet name : String Arc kind : ArcKind weight : Int Node name : String Place marking : Int Transition <> ArcKind normal read arc nodes * net 1 arcs * net 1 source 1 * outgoings target 1 * incomings Figure 7.2 – M´etamod`ele des r´eseaux de Petri. 7.1.2 Exemple de processus et de r´eseau de Petri r´esultant Nous d´ecidons de traiter l’instance de SimplePDL suivante : le processus hi´erarchique compos´e d’activit´es et de contraintes de pr´ec´edence illustr´e par la figure 7.3. Dans cet exemple, le processus root est compos´e de deux activit´es, A et B, reli´ees par une s´equence start2start not´ee s2s, ce qui signifie que B peut d´emarrer uniquement si A a d´ej`a d´emarr´e. B est elle-mˆeme d´ecrite par un processus (child) compos´e de deux activit´es, C et D reli´ees par une s´equence finish2start not´ee f2s. Ainsi, C doit ˆetre termin´ee pour que D puisse d´emarrer. Ce processus est conforme au m´etamod`ele SimplePDL donn´e par la figure 7.1. Notre but est de transformer sa repr´esentation actuelle en sa repr´esentation sous forme d’un r´eseau de Petri. La figure 7.4 est le r´esultat attendu pour cette transformation.7.1. Cas SimplePDLToPetriNet 85 A B C D s2s f2s child: root: Figure 7.3 – Exemple de processus d´ecrit dans le formalisme SimplePDL. C pf inished D tstart f2s pready Pchild pf inished B tstart tf inish A pstarted s2s Proot Figure 7.4 – R´eseau de Petri ´equivalent au processus d´ecrit par la figure 7.3. Dans cette figure ainsi que dans la suite du document, nous repr´esentons les places par des cercles rouges, et les transitions par des carr´es bleus. Les arcs de type normal sont mat´erialis´es par des fl`eches en trait plein noires, ou vertes dans le cas du r´esultat de la transformation d’une WorkSequence. Ceux en pointill´es correspondent aux synchronisations entre ´el´ements, c’est-`a-dire aux arcs de type read arc. 7.1.3 Impl´ementation en utilisant les outils d´evelopp´es Les m´etamod`eles ainsi qu’un exemple de mod`ele d’entr´ee et son r´esultat attendu ayant ´et´e pr´esent´es, d´etaillons la transformation, ainsi que sa mise en œuvre avec nos outils. Pour am´eliorer la lisibilit´e — et donc la compr´ehension —, les extraits de code apparaissant dans cette section sont l´eg`erement simplifi´es par rapport `a l’impl´ementation r´eelle qui est donn´ee en annexe A.1. Nous avons notamment supprim´e certains param`etres et modifi´e des noms de variables (ajouts de pr´efixes P et W D par exemple) afin d’extraire l’essentiel du code en tˆachant d’´eviter toute confusion au lecteur. Nous avons aussi conserv´e une coh´erence entre les sch´emas et les extraits de code. Pour transformer le processus d´ecrit par la figure 7.3, on peut ais´ement isoler trois transformations ´el´ementaires qui composent la transformation globale. Chacune d’entre elles transforme un type d’´el´ement du mod`ele source : respectivement Process2PetriNet, WorkDefinition2PetriNet et WorkSequence2PetriNet pour les ´el´ements Process, WorkDefinition et WorkSequence. Ces transformations ´el´ementaires sont impl´ement´ees par des sous-constructions definition. ProcessToPetriNet. Un Process SimplePDL est traduit par un r´eseau de Petri de la forme de celui donn´e par la figure 7.5. Cette transformation ´el´ementaire est impl´ement´ee par la86 Chapitre 7. Etudes de cas : illustration et utilisation du langage ´ d´efinition P2PN donn´ee par le listing 7.1. Ppready source Ptstart Pprunning Ptf inish Ppf inished target Figure 7.5 – R´eseau de Petri r´esultant de la transformation d’un Process. L’image d’un processus est donc constitu´ee de trois places (Ppready , Pprunning et Ppf inished ), deux transitions (Ptstart et Ptf inish ) et quatre arcs. Dans le cas o`u il s’agit d’un processus hi´erarchique, il peut y avoir un arc de synchronisation pointant vers la premi`ere place (Ppready ) et un autre partant de la derni`ere place (Ppf inished ). Techniquement, nous impl´ementons cette transformation ´el´ementaire par une d´efinition comprenant une seule r`egle filtrant tous les ´el´ements Process du mod`ele source (ligne 2). Dans cette r`egle, seul le nom du processus nous importe, nous n’instancions donc que la variable name. Dans le membre droit de la r`egle, les places et arcs de l’image d’un Process sont cr´e´es comme tout terme Tom, en utilisant la construction backquote (lignes 3 `a 5, et 9 `a 12). En revanche, pour cr´eer les deux transitions Pt_start et Pt_finish, nous utilisons la construction %tracelink afin de tracer ces deux ´el´ements (lignes 6 et 7). Notons que ces transitions nouvellement cr´e´ees et trac´ees sont imm´ediatement utilis´ees dans la construction des arcs du r´eseau de Petri. Le bloc de code des lignes 14 `a 23 sert `a la gestion des processus hi´erarchiques : dans un tel cas, un processus poss`ede un processus p`ere qui est une WorkDefinition non null, et il existe un traitement particulier. Il s’agit de cr´eer des ´el´ements resolve par la construction %resolve (lignes 16 et 20) pour jouer le rˆole de transitions cr´e´ees dans une autre d´efinition. En effet, ces deux nœuds sont cens´es ˆetre cr´e´es par la transformation de WorkDefinitions en r´eseaux de Petri. Ils sont repr´esent´es par les deux carr´es bleus aux bords pointill´es sur la figure 7.5. Les deux ´el´ements resolve peuvent ˆetre imm´ediatement utilis´es dans la construction d’autres termes (lignes 18 et 22, arcs en pointill´es sur la figure 7.5) ou avec Java (lignes 17 et 21).7.1. Cas SimplePDLToPetriNet 87 1 definition P2PN traversal ‘TopDown(P2PN(tom__linkClass,pn)) { 2 p@Process[name=name] -> { 3 Place Pp_ready = ‘Place(name+"_ready", 1); 4 Place Pp_running = ‘Place(name+"_running", 0); 5 Place Pp_finished = ‘Place(name+"_finished", 0); 6 %tracelink(Pt_start:Transition, ‘Transition(name+"_start", pn, 1, 1)); 7 %tracelink(Pt_finish:Transition, ‘Transition(name+"_finish", pn, 1, 1)); 8 9 ‘Arc(Pt_start, Pp_ready, pn, ArcKindnormal(), 1); 10 ‘Arc(Pp_running, Pt_start, pn, ArcKindnormal(), 1); 11 ‘Arc(Pt_finish, Pp_running, pn, ArcKindnormal(), 1); 12 ‘Arc(Pp_finished, Pt_finish, pn, ArcKindnormal(), 1); 13 14 WorkDefinition from = ‘p.getFrom(); 15 if (from!=null) { 16 /* WDt_start et WDt_finish : transitions de l’image d’une activit´e que 17 d´ecrit le processus, par exemple B dans la figure 7.4 */ 18 Transition source = %resolve(from:WorkDefinition, WDt_start:Transition); 19 source.setNet(pn); 20 Arc tmpZoomIn = ‘Arc(Pp_ready, source, pn, ArcKindnormal(), 1); 21 22 Transition target = %resolve(from:WorkDefinition, WDt_finish:Transition); 23 target.setNet(pn); 24 Arc tmpZoomOut = ‘Arc(target, Pp_finished, pn, ArcKindread_arc(), 1); 25 } 26 } 27 } Listing 7.1 – P2PN : Code de la d´efinition ProcessToPetriNet WorkDefinitionToPetriNet. Une WorkDefinition SimplePDL est traduite par un r´eseau de Petri de la forme de celui donn´e par la figure 7.6. Cette transformation ´el´ementaire est impl´ement´ee par la d´efinition WD2PN donn´ee dans le listing 7.2. Le r´eseau de Petri r´esultant de cette transformation ´el´ementaire ressemble beaucoup `a celui obtenu par transformation d’un Process. Il se diff´erencie par un arc et une place suppl´ementaires W Dpstarted apr`es la transition W Dtstart . Ces ´el´ements additionnels par rapport `a l’image d’un Process permettent l’ajout d’une s´equence entre deux WorkDefinitions. L’image d’une activit´e est donc constitu´ee de quatre places (W Dpready , W Dprunning et W Dpf inished , W Dpstarted ), deux transitions (W Dtstart et W Dtf inish ) et cinq arcs. Dans le cas o`u il s’agit d’un processus hi´erarchique, deux arcs de synchronisation avec le processus parent sont pr´esents : l’un venant de la transition Ptstart de l’image du processus parent et pointant sur la place W Dpready , l’autre partant de W Dpf inished et pointant sur la transition Ptf inish de l’image du Process parent. Cette d´efinition est impl´ement´ee par le bloc definition WD2PN, comprenant une r`egle similaire `a celle de la d´efinition P2PN, la diff´erence ´etant que nous filtrons des ´el´ements de type WorkDefinition et non plus Process (ligne 2). Les places et les transitions sont cr´e´ees grˆace `a la construction backquote (lignes 3 et 5) ou via %tracelink (lignes 4, 6, 7 et 8). Tous ces termes — trac´es ou non — sont imm´ediatement utilis´es pour construire les arcs du r´eseau de Petri r´esultant (lignes 10 `a 14). En fin de bloc definition (lignes 16 `a 25), les ´el´ements interm´ediaires resolve repr´esent´es dans la figure 7.6 par les deux carr´es bleus avec les bords pointill´es sont cr´e´es (lignes 19 et 23). Ils sont utilis´es respectivement comme source et destination des arcs de synchronisation88 Chapitre 7. Etudes de cas : illustration et utilisation du langage ´ W Dpready parentstart W Dtstart W Dprunning W Dpstarted W Dtf inish W Dpf inished parentf inish Figure 7.6 – R´eseau de Petri r´esultant de la transformation d’une WorkDefinition. avec le processus parent cr´e´es lignes 23 et 27. Le fait de tracer quatre ´el´ements dans cette d´efinition aura pour cons´equence de g´en´erer `a la compilation une ReferenceClass ayant quatre champs correspondants.7.1. Cas SimplePDLToPetriNet 89 1 definition WD2PN traversal ‘TopDown(WD2PN(tom__linkClass,pn)) { 2 wd@WorkDefinition[name=name] -> { 3 Place WDp_ready = ‘Place(name+"_ready", pn, 1); 4 %tracelink(WDp_started:Place, ‘Place(name+"_started", pn, 0)); 5 Place WDp_running = ‘Place(name+"_running", pn, 0); 6 %tracelink(WDp_finished:Place, ‘Place(name+"_finished", pn, 0)); 7 %tracelink(WDt_start:Transition, ‘Transition(name+"_start", pn, 1, 1)); 8 %tracelink(WDt_finish:Transition, ‘Transition(name+"_finish", pn, 1, 1)); 9 10 ‘Arc(WDt_start, WDp_ready, pn, ArcKindnormal(), 1); 11 ‘Arc(WDp_started, WDt_start, pn, ArcKindnormal(), 1); 12 ‘Arc(WDp_running, WDt_start, pn, ArcKindnormal(), 1); 13 ‘Arc(WDt_finish, WDp_running, pn, ArcKindnormal(), 1); 14 ‘Arc(WDp_finished, WDt_finish, pn, ArcKindnormal(), 1); 15 16 SimplePDLSemantics.DDMMSimplePDL.Process parent = ‘wd.getParent(); 17 /* Pt_start et Pt_finish : transitions de l’image d’un processus, par 18 exemple Proot dans la figure 7.4 */ 19 Transition source = %resolve(parent:Process, Pt_start:Transition); 20 source.setNet(pn); 21 Arc tmpDistribute = ‘Arc(WDp_ready, source, pn, ArcKindnormal(), 1); 22 23 Transition target = %resolve(parent:Process, Pt_finish:Transition); 24 target.setNet(pn); 25 Arc tmpRejoin = ‘Arc(target, WDp_finished, pn, ArcKindread_arc(), 1); 26 } 27 } Listing 7.2 – WD2PN : Code de la d´efinition WorkDefinitionToPetriNet WorkSequenceToPetriNet. Une WorkSequence SimplePDL est traduite par un r´eseau de Petri constitu´e d’un arc, comme illustr´e par la figure 7.7. Cette transformation ´el´ementaire est impl´ement´ee par la d´efinition WS2PN donn´ee par le listing 7.3. Dans cette d´efinition, seul un arc est cr´e´e `a partir de l’´el´ement source filtr´e (WorkSequence). Cependant, tout arc ayant deux extr´emit´es et ces deux extr´emit´es ´etant des ´el´ements obtenus lors de l’application d’autres transformations ´el´ementaires, il est n´ecessaire de construire des ´el´ements resolve. Les extr´emit´es de l’arc image d´ependent du type de la WorkSequence filtr´ee. Nous filtrons donc sur linkType (ligne 5) et, compte tenu des r`egles ´ecrites et du fait que Tom donne toutes les solutions possibles du filtrage, nous avons la garantie que pour un type de contrainte de pr´ec´edence donn´e, deux r`egles seront d´eclench´ees (une parmi celles des lignes 6 et 9, l’autre parmi celles des lignes 13 et 16). Apr`es ex´ecution de ce bloc, les variables source et target sont bien initialis´ees et peuvent ˆetre utilis´ees pour construire l’arc image wsImage (ligne 23) de la s´equence filtr´ee.90 Chapitre 7. Etudes de cas : illustration et utilisation du langage ´ source target Figure 7.7 – R´eseau de Petri r´esultant de la transformation d’une WorkSequence. 1 definition WS2PN traversal ‘TopDown(WS2PN(tom__linkClass,pn)) { 2 ws@WorkSequence[predecessor=p,successor=s,linkType=linkType] -> { 3 Place source= null; 4 Transition target= null; 5 %match(linkType) { 6 (WorkSequenceTypefinishToFinish|WorkSequenceTypefinishToStart)[] -> { 7 source = %resolve(p:WorkDefinition, WDp_finished:Place); 8 } 9 (WorkSequenceTypestartToStart|WorkSequenceTypestartToFinish)[] -> { 10 source = %resolve(p:WorkDefinition, WDp_started:Place); 11 } 12 13 (WorkSequenceTypefinishToStart|WorkSequenceTypestartToStart)[] -> { 14 target = %resolve(s:WorkDefinition, WDt_start:Transition); 15 } 16 (WorkSequenceTypestartToFinish|WorkSequenceTypefinishToFinish)[] -> { 17 target = %resolve(s:WorkDefinition, WDt_finish:Transition); 18 } 19 } 20 source.setNet(pn); 21 target.setNet(pn); 22 23 Arc wsImage = ‘Arc(target,source, pn, ArcKindread_arc(), 1); 24 } 25 } Listing 7.3 – WS2PN : Code de la d´efinition WorkSequenceToPetriNet7.1. Cas SimplePDLToPetriNet 91 Transformation globale. Ces blocs definition s’int`egrent dans une transformation Tom+ Java dont la forme g´en´erale du code est donn´ee par le listing 7.4. Le code complet de la transformation est quant `a lui donn´e dans l’annexe A.1 et est directement accessible dans le d´epˆot du projet 53. Notons que cette transformation sert aussi de support pour la documentation sur le site officiel de Tom 54. Expliquons le reste du code de la transformation dans ses grandes lignes : d´ebut : Les points de suspension de la ligne 1 repr´esentent du code java classique (package et import). ancrages : Au sein de la classe SimplePDLToPetriNet, nous notons l’usage de plusieurs constructions %include. Celle de la ligne 3 sert `a charger les ancrages formels de la biblioth`eque de strat´egies, celle de la ligne 4 charge l’ancrage du mod`ele de lien (fourni comme biblioth`eque) et celle de la ligne 5 permet de charger les types Ecore, eux aussi fournis sous la forme d’une biblioth`eque. Les deux ancrages charg´es lignes 7 et 8 ont ´et´e g´en´er´es par Tom-EMF. Le bloc de code suivant montre des d´eclarations de variables et l’´ecriture d’un mapping minimal permettant d’utiliser la classe SimplePDLToPetriNet comme un type Tom. Les points de suspension suivants repr´esentent du code Java (d´eclarations de variables, etc.). transformation : Les trois d´efinitions constituent le corps d’un bloc %transformation (lignes 18 `a 29). Nous avons choisi de les ´ecrire dans l’ordre dans lequel nous les avons pr´esent´ees, cependant nous rappelons que cet ordre n’a aucune importance avec notre approche. main : Nous avons extrait une partie de main(). Avant l’extrait, il s’agit de contrˆoles ainsi que du code permettant de charger un mod`ele ou cr´eer un mod`ele en Tom dans le cas o`u aucun fichier n’est pass´e en param`etre. L’extrait comprend quant `a lui la cr´eation de la strat´egie de transformation (ligne 38) ainsi que son appel (ligne 40). La strat´egie de r´esolution est appel´ee `a la ligne 42. Etant g´en´er´ee, son nom est construit de mani`ere ´ pr´edictible pour l’utilisateur, `a partir du nom de la transformation ainsi que d’un pr´efixe explicite (tom_StratResolve_). La strat´egie appel´ee `a la ligne 44 sert pour l’affichage du r´esultat de la transformation. fin : Le reste du code qui n’est pas montr´e dans le listing 7.4 consiste en des m´ethodes d’affichage et de s´erialisation pour obtenir un r´eseau de Petri compatible avec le format d’entr´ee du model-checker TINA 55 [BRV04]. Usage de cette transformation. Cette transformation ´etant bien connue, elle nous a servi de support pour le d´eveloppement de nos outils. Son int´erˆet ´etant de pouvoir v´erifier formellement des propri´et´es de son r´esultat, nous avons d´epass´e le simple d´eveloppement de la transformation pour v´erifier nos r´esultats. C’est pour cette raison que le mod`ele cible est g´en´er´e par d´efaut au format d’entr´ee de TINA. Cela nous permet de le visualiser et d’en v´erifier des propri´et´es avec le model-checker. Ainsi, nous avons pu exprimer une formule ainsi que des propri´et´es en logique temporelle lin´eaire (LTL) telles que la terminaison. Nous les avons ensuite v´erifi´ees avec TINA sur le r´eseau de Petri r´esultant de la transformation. La formule, les propri´et´es ainsi que les r´esultats sont donn´es en annexe A.4 de ce document. 53. https://gforge.inria.fr/scm/?group_id=78 54. http://tom.loria.fr/wiki/index.php5/Documentation:Playing_with_EMF 55. http://projects.laas.fr/tina92 Chapitre 7. Etudes de cas : illustration et utilisation du langage ´ 1 ... 2 public class SimplePDLToPetriNet { 3 %include{ sl.tom } 4 %include{ LinkClass.tom } 5 %include{ emf/ecore.tom } 6 7 %include{ mappings/DDMMPetriNetPackage.tom } 8 %include{ mappings/DDMMSimplePDLPackage.tom } 9 10 private static PetriNet pn = null; 11 private static LinkClass tom__linkClass; 12 13 %typeterm SimplePDLToPetriNet { implement { SimplePDLToPetriNet }} 14 public SimplePDLToPetriNet() { 15 this.tom__linkClass = new LinkClass(); 16 } 17 ... 18 %transformation SimplePDLToPetriNet(tom__linkClass:LinkClass,pn:PetriNet) : 19 "metamodels/SimplePDL.ecore" -> "metamodels/PetriNet.ecore" { 20 definition P2PN traversal ‘TopDown(P2PN(tom__linkClass,pn)) { 21 /* code du listing 7.1 */ 22 } 23 definition WD2PN traversal ‘TopDown(WD2PN(tom__linkClass,pn)) { 24 /* code du listing 7.2 */ 25 } 26 definition WS2PN traversal ‘TopDown(WS2PN(tom__linkClass,pn)) { 27 /* code du listing 7.3 */ 28 } 29 } 30 31 public static void main(String[] args) { 32 ... 33 SimplePDLToPetriNet translator = new SimplePDLToPetriNet(); 34 Introspector introspector = new EcoreContainmentIntrospector(); 35 // processus `a transformer 36 simplepdl.Process p_root = ‘Process("root", ...); 37 38 Strategy transformer = 39 ‘SimplePDLToPetriNet(translator.tom__linkClass,translator.pn); 40 transformer.visit(p_root, introspector); 41 //Appel de la strat´egie de r´esolution g´en´er´ee 42 ‘TopDown(tom__StratResolve_SimplePDLToPetriNet(translator.tom__linkClass, 43 translator.pn)).visit(translator.pn, introspector); 44 ‘TopDown(Sequence(PrintTransition()),PrintPlace()).visit(translator.pn, 45 introspector); 46 ... 47 } 48 ... 49 } Listing 7.4 – Forme g´en´erale du code de la transformation SimplePDLToPetriNet7.2. Aplatissement d’une hi´erarchie de classes 93 7.2 Aplatissement d’une hi´erarchie de classes Cette deuxi`eme ´etude de cas avait pour but d’´evaluer l’int´erˆet et les limites ´eventuelles des nouvelles constructions int´egr´ees au langage Tom. Il s’agit d’une transformation endog`ene tr`es simple : l’aplatissement d’une hi´erarchie de classes. Nous disposons de classes, dont certaines h´eritent d’autres. Nous souhaitons aplatir cette hi´erarchie en reportant les attributs des surclasses dans les classes qui sont les feuilles de l’arbre hi´erarchique. Nous choisissons aussi de nommer les nouvelles classes reprenant tous les attributs h´erit´es. Les classes qui ne sont pas impliqu´ees dans une relation d’h´eritage ne changent pas. Nous pr´esentons un exemple de transformation dans la section 7.2.1 et le m´etamod`ele dans la section 7.2.2. Pour ´evaluer et comparer, nous avons ´ecrit plusieurs impl´ementations de cet exemple, que nous d´ecrivons dans la section 7.2.3. 7.2.1 Exemple de transformation Nous consid´erons comme mod`ele source la hi´erarchie de classes donn´ee par le membre gauche de la figure 7.8. La classe C poss`ede un attribut attrC de type C et n’est dans aucune hi´erarchie de classes. La classe B est quant `a elle dans une hi´erarchie de classes : elle h´erite de A qui h´erite elle-mˆeme de D, surclasse de toute la hi´erarchie. La classe B a deux attributs attrB1 et attrB2 de types C. Cette transformation aplatit la hi´erarchie et doit donc produire le mod`ele cible illustr´e par le membre droit de la figure 7.8. Il s’agit d’un mod`ele constitu´e de deux classes : la classe C — qui reste inchang´ee par rapport au mod`ele source — ainsi qu’une classe DAB qui rassemble tous les attributs de la hi´erarchie de classe aplatie. C attrC : C D attrD : C A B attrB1 : C attrB2 : C −→ C attrC : C DAB attrD : C attrB1 : C attrB2 : C (a) (b) Figure 7.8 – Aplatissement d’une hi´erarchie de classes. 7.2.2 M´etamod`ele S’agissant d’une transformation endog`ene, le m´etamod`ele source est identique au m´etamod`ele cible. Pour cette transformation, nous utilisons le m´etamod`ele simplifi´e d’UML donn´e par la figure 7.9. Les Classifiers sont des ´el´ements ayant un nom et ´etant de type DataType ou de type Class. Un ´el´ement Class peut avoir des attributs (Attribute), qui sont eux-mˆemes des Classifiers. Dans notre contexte technique, nous avons besoin d’une racine afin d’obtenir un arbre de recouvrement. Nous avons donc ajout´e une racine virtuelle dans le m´etamod`ele — ´el´ement VirtualRoot — qui contient tous les Classifiers (relation de composition).94 Chapitre 7. Etudes de cas : illustration et utilisation du langage ´ VirtualRoot Classifier name : String DataType Class isAbstract : boolean Attribute name : String children 0..* root 1 attributes 0..* type 1 subclass 0..* 0..* superclass Figure 7.9 – M´etamod`ele d’UML simplifi´e. Pour les besoins de l’´etude et afin de simplifier les explications et le d´eveloppement, nous avons consid´er´e une version ´epur´ee du m´etamod`ele illustr´e par la figure 7.10. VirtualRoot Class name : String Attribute name : String children 0..* root 1 attributes 0..* type 1 subclass 0..* 0..* superclass Figure 7.10 – M´etamod`ele consid´er´e pour l’´etude de cas. 7.2.3 Impl´ementation utilisant les outils d´evelopp´es Nous avons impl´ement´e cet exemple de plusieurs mani`eres afin de comparer l’int´erˆet d’utiliser les outils d´evelopp´es durant cette th`ese pour la transformation de mod`eles : 1. La premi`ere version de cette impl´ementation est ´ecrite en pur Java (+EMF), sans l’aide de Tom, des nouvelles constructions et des outils li´es tels que Tom-EMF. Il s’agit d’une version mˆelant r´ecursivit´e et it´eration ; 2. la deuxi`eme version est ´ecrite en Tom+Java mais sans user des strat´egies ni de la nouvelle construction %transformation. En revanche, nous avons utilis´e Tom-EMF pour g´en´erer les mappings ; 3. la troisi`eme impl´ementation est une application de la m´ethode pr´esent´ee dans [BCMP12], `a savoir l’´ecriture d’une transformation en utilisant les strat´egies de r´e´ecriture, mais sans la construction haut niveau %transformation ; 4. la quatri`eme et derni`ere version utilise les outils d´evelopp´es dans le cadre de cette th`ese. Pour des raisons de lisibilit´e, nous faisons uniquement apparaˆıtre des extraits significatifs de code de cette transformation dans cette section. Le code complet des impl´ementations est donn´e dans l’annexe B.1. Version 1 : Java-EMF. L’impl´ementation en Java-EMF d’une telle transformation se r´ev`ele sans v´eritable difficult´e. Le principe est de parcourir les classes du mod`ele source et d’appliquer7.2. Aplatissement d’une hi´erarchie de classes 95 un aplatissement r´ecursif sur celles qui sont les feuilles de l’arbre d’h´eritage. Cette transformation peut ˆetre impl´ement´ee en environ 40 lignes de code, comme le montre le listing 7.5 (code complet en annexe B.1.1). 1 public static VirtualRoot v1_processClass(VirtualRoot root) { 2 org.eclipse.emf.common.util.EList newChildren = 3 new org.eclipse.emf.common.util.BasicEList(); 4 for(Class cl : root.getChildren()) { 5 if(cl.getSubclass().isEmpty()) { 6 newChildren.add(flattening(cl)); 7 } 8 } 9 VirtualRoot result = (VirtualRoot) ClassflatteningFactory.eINSTANCE.create( 10 (EClass)ClassflatteningPackage.eINSTANCE.getEClassifier("VirtualRoot")); 11 result.eSet(result.eClass().getEStructuralFeature("children"), newChildren); 12 return result; 13 } 14 15 public static Class flattening(Class toFlatten) { 16 Class parent = toFlatten.getSuperclass(); 17 if(parent==null) { 18 return toFlatten; 19 } else { 20 Class flattenedParent = flattening(parent); 21 EList head = toFlatten.getAttributes(); 22 head.addAll(flattenedParent.getAttributes()); 23 Class result = (Class)ClassflatteningFactory.eINSTANCE. 24 create((EClass)ClassflatteningPackage.eINSTANCE.getEClassifier("Class")); 25 result.eSet(result.eClass().getEStructuralFeature("name"), flattenedParent.getName()+toFlatten.getName()); 26 result.eSet(result.eClass().getEStructuralFeature("attributes"), head); 27 result.eSet(result.eClass().getEStructuralFeature("superclass"), flattenedParent.getSuperclass()); 28 result.eSet(result.eClass().getEStructuralFeature("subclass"), (new BasicEList()) ); 29 result.eSet(result.eClass().getEStructuralFeature("root"), virtR); 30 return result; 31 } 32 } 33 ... 34 public static void main(String[] args) { 35 ... 36 VirtualRoot translator.virtR = v1_processClass(source_root); 37 ... 38 } Listing 7.5 – Version 1 : Impl´ementation de la transformation d’aplatissement de hi´erarchie de classes en Java. Les pr´e-requis pour cette version de la transformation sont de maˆıtriser Java et de connaˆıtre un minimum EMF afin d’ˆetre en mesure d’´ecrire les appels ad´equats pour cr´eer un ´el´ement. Un d´efaut de cette impl´ementation est la lisibilit´e du code, le langage Java ainsi que le framework EMF ´etant particuli`erement verbeux. Version 2 : Tom+Java-EMF. Pour rem´edier `a ce d´esagr´ement — qui peut devenir un enjeu fort dans le cadre de la maintenance logicielle industrielle — nous avons modifi´e l’impl´ementation initiale avec Tom, afin d’user de ses facilit´es d’´ecriture. L’utilisation de la construction %match (filtrage de motif) ainsi que du backquote (cr´eation et manipulation de termes) permettent notamment d’am´eliorer la lisibilit´e du programme. Le listing 7.6 est le code r´esultant de l’´evolution du pr´ec´edent listing, int´egrant du code Tom simple (le code complet est donn´e dans l’annexe B.1.2). Cet extrait de code est plus concis que la version en pur Java et EMF (moins de 25 lignes pour la transformation elle-mˆeme), mais il est surtout plus lisible. Pour utiliser la construction backquote (‘) comme nous le faisons dans ce listing, des ancrages alg´ebriques sont n´ecessaires. Nous avons bien ´evidemment utilis´e notre g´en´erateur d’ancrages formels Tom-EMF plutˆot que de les ´ecrire manuellement. L’utilisateur n’a donc pas de travail additionnel `a fournir par rapport `a une transformation en pur Java et EMF autre que la commande de g´en´eration (dans96 Chapitre 7. Etudes de cas : illustration et utilisation du langage ´ 1 public static VirtualRoot v2_processClass(VirtualRoot root) { 2 EList children = root.getChildren(); 3 EList newChildren = ‘cfClassEList(); 4 %match(children) { 5 cfClassEList(_*,cl@cfClass(_,_,_,cfClassEList(),_),_*) -> { 6 newChildren = ‘cfClassEList(flattening(cl),newChildren*); 7 } 8 } 9 return ‘cfVirtualRoot(newChildren); 10 } 11 12 public static Class flattening(Class toFlatten) { 13 Class parent = toFlatten.getSuperclass(); 14 if(parent==null) { 15 return toFlatten; 16 } else { 17 Class flattenedParent = flattening(parent); 18 EList head = toFlatten.getAttributes(); 19 head.addAll(flattenedParent.getAttributes()); 20 return ‘cfClass(flattenedParent.getName()+toFlatten.getName(), head, flattenedParent.getSuperclass(), 21 cfClassEList(), virtR); 22 } 23 } 24 ... 25 public static void main(String[] args) { 26 ... 27 VirtualRoot translator.virtR = v2_processClass(source_root); 28 ... 29 } Listing 7.6 – Version 2 : Impl´ementation de la transformation d’aplatissement de hi´erarchie de classes en Tom+Java. la pr´ec´edente version, l’utilisateur doit aussi ´ecrire le m´etamod`ele et g´en´erer le code EMF avec Eclipse). Version 3 : Tom+Java-EMF avec strat´egies. Les strat´egies ´etant un aspect important de Tom, nous ´ecrivons une autre version de cette transformation les utilisant. C’est l’occasion de mettre en œuvre la m´ethode pr´esent´ee dans [BCMP12]. Dans cette nouvelle impl´ementation (extrait dans le listing 7.7, code complet en annexe B.1.3), nous utilisons toujours les ancrages alg´ebriques g´en´er´es par Tom-EMF et nous ajoutons une strat´egie Tom. L’usage des strat´egies avec des mod`eles EMF Ecore implique aussi l’utilisation de l’outil EcoreContainmentIntrospector pr´esent´e dans 6.3.2. Pour rappel, il permet le parcours des mod`eles EMF Ecore vus sous leur forme de termes. Habituellement, l’utilisation des strat´egies Tom simplifie syst´ematiquement et grandement l’´ecriture de code ainsi que sa lisibilit´e, le parcours — trait´e par les biblioth`eques que nous fournissons — ´etant s´epar´e du traitement. Cependant, apr`es ´ecriture et ex´ecution de la transformation, nous nous apercevons que la transformation n’est ni v´eritablement plus courte, ni plus lisible, ni plus efficace que les impl´ementations pr´ec´edentes. C’est en observant plus pr´ecis´ement le m´etamod`ele de notre exemple, la transformation attendue ainsi que l’outil permettant l’utilisation des strat´egies que l’on identifie la raison. Un mod`ele EMF a une racine unique par la relation de composition et peut donc ˆetre repr´esent´e sous la forme d’un arbre, comme nous le faisons dans Tom. La figure 7.11 illustre ce m´ecanisme appliqu´e aux mod`eles sources des deux exemples que nous pr´esentons dans ce chapitre. Dans cette figure, les deux termes sont repr´esent´es de mani`ere classique : la racine est en haut, les feuilles en bas. Un losange noir — le symbole de la relation de composition en mod´elisation — a ´et´e ajout´e `a chaque endroit o`u la relation est une relation de composition, c’est-`a-dire `a chaque relation p`ere-fils. L’arbre est bien un arbre par la relation de composition. Si l’on examine la figure 7.11a, nous nous apercevons que les relations de sa structure correspondent `a celles qui nous int´eressent dans l’exemple, `a savoir les relations de composi-7.2. Aplatissement d’une hi´erarchie de classes 97 1 %strategy FlatteningStrat(translator:UMLClassesFlattening) extends Identity() { 2 visit cfVirtualRoot { 3 cfVirtualRoot(cfClassEList(_*,cl@cfClass(n,_,_,cfClassEList(),_),_*)) -> { 4 EList newChildren = translator.virtR.getChildren(); 5 translator.virtR = ‘cfVirtualRoot(cfClassEList(flattening(cl),newChildren*)); 6 } 7 } 8 } 9 10 public static Class flattening(Class toFlatten) { 11 Class parent = toFlatten.getSuperclass(); 12 if(parent==null) { 13 return toFlatten; 14 } else { 15 Class flattenedParent = flattening(parent); 16 EList head = toFlatten.getAttributes(); 17 head.addAll(flattenedParent.getAttributes()); 18 return ‘cfClass(flattenedParent.getName()+toFlatten.getName(), head, 19 flattenedParent.getSuperclass(), cfClassEList(), null); 20 } 21 } 22 ... 23 public static void main(String[] args) { 24 ... 25 VirtualRoot translator.virtR = ‘cfVirtualRoot(cfClassEList()); 26 Strategy transformer = ‘BottomUp(FlatteningStrat(translator)); 27 transformer.visit(source_root, new EcoreContainmentIntrospector()); 28 ... 29 } Listing 7.7 – Version 3 : Impl´ementation de la transformation d’aplatissement de hi´erarchie de classes en Tom+Java avec strat´egies. P rocessroot W DA W S1 W DB P rocesschild W DC W S2 W DD (a) SimplePDLToPetriNet. V irtualRoot D A B C (b) ClassFlattening. Figure 7.11 – Arbres repr´esentant les mod`eles source des exemples SimplePDLToPetriNet (a) et ClassFlattening (b). tion. En revanche, dans le cas de l’exemple de l’aplatissement d’une hi´erarchie de classes, la relation entre ´el´ements qui nous int´eresse v´eritablement est la relation d’h´eritage, mod´elis´ee par une relation bidirectionnelle subclass–superclass et non par une relation de composition. Nous repr´esentons ces relations « int´eressantes » dans la figure 7.11b par des fl`eches rouges. La seule relation de composition de cet exemple est une relation de composition artificielle que nous avons cr´e´ee (ainsi que l’´el´ement de type VirtualRoot) afin d’avoir une racine et donc de pouvoir ´ecrire ce mod`ele EMF Ecore. Notre outil EcoreContainmentIntrospector descendra98 Chapitre 7. Etudes de cas : illustration et utilisation du langage ´ bien dans les arbres, mais dans le cas du second exemple, il ne servira qu’`a obtenir tous les fils de cette racine virtuelle qui sont `a plat. Ensuite, pour l’aplatissement en lui-mˆeme, nous faisons tout de mˆeme appel `a une fonction flattening() r´ecursive, que nous utilisions ou non des strat´egies. Pass´e ce constat, la derni`ere version de l’impl´ementation reposant elle aussi sur les strat´egies de r´e´ecriture mais avec les nouvelles constructions, nous pouvons supposer qu’elle ne sera pas meilleure (plus lisible, plus concise et plus efficace). Nous constatons effectivement que l’impl´ementation est moins lisible et moins concise, avec une efficacit´e similaire. Diff´erents facteurs permettent d’expliquer ce r´esultat : d’une part, comme pour la version pr´ec´edente, les relations nous int´eressant ne sont pas celles constituant l’arbre de recouvrement, d’autre part, cette transformation est trop simple pour tirer parti de nos outils. Expliquons plus en d´etail cet aspect. Dans cette transformation, nous ne pouvons extraire plusieurs transformations ´el´ementaires. La transformation globale sera donc constitu´ee d’une seule d´efinition, encod´ee par une strat´egie de r´e´ecriture, comme dans la version pr´ec´edente de l’impl´ementation. Ainsi, le gain habituellement apport´e par la construction %transformation est compl`etement absent. Outre ce point, nous constatons qu’aucun ´el´ement en cours de transformation ne n´ecessite le r´esultat d’un autre ´el´ement devant ˆetre transform´e. Il n’y a donc pas besoin d’introduire d’´el´ement resolve dans la transformation. L’un des apports de nos outils ´etant de g´erer l’ordonnancement des pas d’ex´ecution en g´en´erant une strat´egie de r´esolution, son int´erˆet reste limit´e pour cette transformation. Finalement, nous pouvons donc d´eduire de cet exemple que nos outils ne sont pas pleinement adapt´es `a toutes les transformations. Dans ces quatre impl´ementations, la deuxi`eme version semble ˆetre le compromis le plus judicieux. Le g´en´erateur de mappings y joue un rˆole majeur, nous utilisons une partie du langage Tom, en revanche nous nous passons des constructions plus complexes telles que les strat´egies ainsi que les nouvelles constructions int´egr´ees durant cette th`ese. Cependant, les nouvelles constructions pour de tels exemples ne sont pas pour autant inint´eressantes : en effet, si la r´esolution (et sa construction associ´ee %resolve) n’apporte pas de gain, il subsiste le second aspect de nos travaux, `a savoir la tra- ¸cabilit´e. L’utilisation de la construction %tracelink afin de g´en´erer un mod`ele de lien reste possible. Une autre conclusion de l’´etude de cet exemple est que nous avons d´evelopp´e nos outils en visant la couverture d’un grand nombre de transformations, notamment celles o`u les relations de composition sont au cœur. Une perspective serait maintenant de travailler `a l’´elaboration d’outils g´erant d’autres relations ou ´etant plus g´en´eriques. Nous pensons notamment `a des strat´egies de r´e´ecriture que nous pourrions param´etrer par des types de relations `a suivre. 7.3 Synth`ese Dans ce chapitre, nous avons pr´esent´e deux cas d’´etude pour deux objectifs distincts : SimplePDLToPetriNet et UMLHierarchyFlattening. La transformation SimplePDLToPetriNet nous a permis de pr´esenter l’utilisation des outils que nous avons d´evelopp´es durant cette th`ese en d´eroulant compl`etement une transformation. La seconde ´etude de cas nous a permis de donner une premi`ere ´evaluation de nos outils dans un contexte o`u ils ne peuvent donner leur pleine mesure. L’objectif de cette seconde ´etude de cas ´etait de rep´erer les points d’am´elioration de nos outils, tant dans leur mise en œuvre actuelle qu’envisag´ee, et de nous donner de nouvelles perspectives techniques et scientifiques. En effet, si cette ´etude de cas nous a montr´e que nos outils n’´etaient pas tous adapt´es dans toutes les situations, elle nous a permis en revanche de relever un point int´eressant. La relation de composition dans les mod`eles est centrale et se retrouve bien souvent au cœur des transformations de mod`eles. Dans notre contexte, elle nous permet d’avoir la vision arborescente des mod`eles que nous pouvons parcourir. Cependant, pour certaines transformations comme celle d’aplatissement d’une hi´erarchie de classes, la relation d’int´erˆet n’est pas celle de composition. Partant de ce constat, il est int´eressant de7.3. Synth`ese 99 se poser la question de la g´en´eralisation des strat´egies pour les transformations de mod`eles. Une piste est la param´etrisation des strat´egies par le type de relation `a suivre lors de la travers´ee des termes. Dans un premier temps, pour tester la validit´e de ce principe, on pourrait impl´ementer un introspecteur d´edi´e `a d’autres types de relations (h´eritage notamment). Cette extension l`everait la limitation r´ev´el´ee par la seconde ´etude de cas. Ensuite, une seconde question d’int´erˆet serait de travailler sur la possibilit´e de param´etrer dynamiquement une strat´egie : est-il possible de changer le type de lien `a suivre en cours de parcours ? Ce type de m´ecanisme permettrait de d´eclencher localement une strat´egie avec un autre type de parcours, et donc d’adopter une strat´egie de r´e´ecriture en fonction du contexte. Le premier exemple nous a aussi servi de support pour le d´eveloppement de nos outils, et notre confiance en notre impl´ementation de cette transformation ´etant forte, nous nous en sommes aussi servi pour mener des exp´eriences que nous pr´esentons dans le chapitre suivant.100 Chapitre 7. Etudes de cas : illustration et utilisation du langage ´Chapitre 8 R´esultats exp´erimentaux Dans ce chapitre, nous pr´esentons des r´esultats exp´erimentaux obtenus avec nos outils, notamment leurs performances. Nous discutons notre approche et nos choix technologiques, leur int´erˆet, ainsi que les limitations et perspectives de notre impl´ementation technique. Nous avons tent´e d’´evaluer nos outils afin d’am´eliorer les points limitants et de parfaire nos points forts par rapport `a d’autres outils tels qu’ATL ou d’autres outils de transformation utilisant des strat´egies de r´e´ecriture. 8.1 Utilisabilit´e Compte tenu du fait qu’un de nos objectifs ´etait de simplifier le processus de d´eveloppement pour les utilisateurs, un premier aspect de notre ´evaluation concerne l’utilisabilit´e de nos outils. Fortement d´ependant du contexte et de l’utilisateur, ce crit`ere est difficilement mesurable et quantifiable. Nous pouvons toutefois exposer des retours utilisateurs. Nous avons pu tester en conditions r´eelles une partie de nos outils : il s’agissait de d´evelopper une transformation en Tom+Java dans le cadre du projet quarteFt par une entreprise partenaire du projet. Le d´eveloppeur ´etait un ing´enieur en informatique maˆıtrisant le langage Java ainsi que l’environnement Eclipse. Il ne connaissait pas Tom, ni les langages `a base de r`egles de r´e´ecriture, ni le concept de strat´egie avant de commencer. La prise en main du langage Tom sans les nouvelles constructions s’est faite sans aucune difficult´e et sans r´eel besoin de support de notre part hormis la documentation officielle en ligne. Nous avons donn´e un support informel pour l’usage des strat´egies Tom afin d’acc´el´erer son d´eveloppement. L’outil Tom-EMF a ´et´e utilis´e pour g´en´erer les ancrages formels inclus dans la transformation. Si l’usage en lui-mˆeme n’a pas pos´e de probl`eme `a l’ing´enieur (peu d’options diff´erentes, documentation centralis´ee), nous lui avons fourni un support plus important. En effet, l’usage par un non d´eveloppeur a permis de d´ecouvrir des bugs et des manques de fonctionnalit´es (besoin de g´en´eration massive de mappings en une seule fois qui a donn´e lieu `a la fonctionnalit´e de g´en´eration multiple de EPackages, conflits de noms qui a donn´e lieu `a la fonctionnalit´e de pr´efixage, g´en´eration multiple des ancrages pour les biblioth`eques UML2 et Ecore, etc.). Ces premiers retours utilisateur ont jou´e un rˆole important dans l’am´elioration de l’outil Tom-EMF. Lors de ce test en conditions r´eelles, l’utilisateur a suivi la m´ethodologie avec les strat´egies, mais n’a cependant pas utilis´e les constructions Tom haut-niveau d´edi´ees aux transformations de mod`eles. En effet, elles n’´etaient pas incluses dans la version stable du moment. L’aspect hybride de notre approche a permis `a l’utilisateur d’ˆetre tr`es rapidement op´erationnel sans qu’il ait `a apprendre un nouveau langage complet. De plus, du fait de son environnement de d´eveloppement, sa transformation a pu ˆetre imm´ediatement int´egr´ee dans les outils d´evelopp´es, ce qui n’aurait pas ´et´e aussi simple avec des langages tels que ATL, Kermeta ou mˆeme Stratego. Si notre approche utilisant Tom fournit moins de fonctionnalit´es 101102 Chapitre 8. R´esultats exp´erimentaux pour la transformation de mod`eles que ATL, nous avons l’avantage de ne pas nous s´eparer des fonctionnalit´es (biblioth`eques notamment) du langage g´en´eraliste consid´er´e (Java dans notre cas), ce qui permet `a l’utilisateur d’exprimer tout de mˆeme ce qu’une construction Tom ne pourrait pas fournir nativement. Le principe d’utiliser des strat´egies de r´e´ecritures pour encoder les transformations de mod`eles semble aussi un choix judicieux du point de vue de l’utilisateur : la d´ecomposition d’une transformation en transformations ´el´ementaires est naturelle pour appr´ehender la complexit´e et le principe d’´ecriture de r`egles est aussi courant dans d’autres langages. Nous ne changeons donc pas fondamentalement les habitudes du d´eveloppeur. Grˆace aux m´ecanismes en jeu dans notre approche, nous avons une forte expressivit´e dans les motifs (membre gauche) et nous offrons une grande libert´e `a l’utilisateur dans les actions (membre droit) grˆace `a leur nature composite. Le fait que notre approche se fonde sur un changement d’espace technologique pourrait paraˆıtre limitant en premi`ere approche (outil suppl´ementaire pour op´erer le changement), cependant cet outil (g´en´erateur d’ancrages formels) est extrˆemement simple d’utilisation et ne n´ecessite qu’une seule intervention en d´ebut de d´eveloppement. Le choix de l’usage d’un outil par rapport `a un autre ne peut ˆetre d´efinitif et universel : il doit ˆetre effectu´e de mani`ere r´efl´echie en tenant compte de crit`ere tels que l’environnement de d´eveloppement, les fonctionnalit´es respectives des outils envisag´es ainsi que les performances des outils. Dans un contexte Java+EMF, compte tenu des premiers retours, le choix de nos outils est pertinent. 8.2 Performances De mani`ere g´en´erale, un outil peut ˆetre extrˆemement int´eressant scientifiquement, mais inutilisable du fait de ses performances (impl´ementation inefficace ou probl`eme `a r´esoudre trop complexe). Dans un cadre industriel, cette question se pose rapidement, ´etant donn´e que des mod`eles « r´eels » (g´en´eralement de plus grandes tailles que ceux utilis´es pour le prototypage initial) sont transform´es. Il est donc naturel d’´evaluer ses performances, mˆeme si n’est pas l’objectif premier de l’outil. Dans le domaine de la v´erification du logiciel, les outils de model-checking sont g´en´eralement des outils consommateurs de ressources (temps et m´emoire), ce qui peut constituer un goulet d’´etranglement dans une chaˆıne de d´eveloppement imposant une v´erification de ce type. Il ne faut donc pas que les autres traitements aient des performances moindres (et deviendraient de fait le nouveau goulet d’´etranglement), ou que leurs temps d’ex´ecution ajoutent trop de d´elais avant ce goulet. Un second aspect de l’´evaluation des performances vient du fait que beaucoup d’outils de transformation existent, mais leur passage `a l’´echelle est souvent un facteur limitant. C’est donc dans ce contexte que nous avons effectu´e une premi`ere ´evaluation des performances de nos outils, d’une part Tom-EMF, d’autre part les constructions haut-niveau d´edi´ees aux transformations de mod`eles. 8.2.1 Tom-EMF Nous avons exp´eriment´e Tom-EMF sur divers m´etamod`eles afin de nous assurer de son passage `a l’´echelle. Tr`es rapidement, nous avons constat´e que peu de tr`es gros m´etamod`eles sont utilis´es, les m´etamod`eles Ecore et UML ´etant souvent les plus gros m´etamod`eles utilis´es r´eguli`erement. Nous avons donc appliqu´e notre outil sur ces m´etamod`eles pour g´en´erer les mappings correspondant, ainsi que sur les parties des deux m´etamod`eles du cas d’utilisation pr´esent´e dans le chapitre 7.1. Nous constatons que les temps de g´en´eration donn´es dans la table 8.1 sont extrˆemement bas, de l’ordre de la seconde. Notre outil de g´en´eration d’ancrages est tout `a fait capable de g´erer un « gros » m´etamod`ele, dans un temps n´egligeable par rapport `a la dur´ee de d´eveloppement et d’ex´ecution d’une transformation comme nous allons le voir. Consid´erant ces temps de g´en´eration pour de tels m´etamod`eles, nous estimons que les performances de l’ou-8.2. Performances 103 M´etamod`ele Ecore Mappings Tom Temps moyen de #eClassifiers #sortes #op´erateurs g´en´eration (en ms) Ecore 52 56 28 24 UML2 264 345 346 1527 SimplePDL 4 8 10 256 PetriNet 2 8 8 254 Table 8.1 – Tailles de quelques m´etamod`eles significatifs ainsi que des mappings Tom-EMF correspondant. til Tom-EMF sont largement suffisantes et qu’elles ne sont pas limitantes dans la chaˆıne de d´eveloppement. Outre l’aspect performances que nous jugeons satisfaisant, cet outil s’est av´er´e simple `a utiliser pour un utilisateur compl`etement ext´erieur au projet Tom. Cela nous donne un indice positif sur l’utilisabilit´e de notre outil. 8.2.2 Transformation Afin de tester les performances du langage, nous avons utilis´e la transformation SimplePDLToPetriNet sur des mod`eles de tailles diff´erentes. Nous avons fait ce choix, car ayant servi de support au d´eveloppement de nos outils, nous en avions une bonne maˆıtrise tout en ayant une confiance ´elev´ee dans son impl´ementation. Nous l’avons aussi impl´ement´ee dans d’autres langages afin d’avoir des points de comparaison avec l’existant. S’agissant d’une transformation connue dans le domaine, nous avons pu corriger et am´eliorer ces impl´ementations grˆace `a celles existantes. Pour le mod`ele d’entr´ee, nous avons d´efini un processus param´etrable g´en´er´e de mani`ere d´eterministe en fonction de deux param`etres : — le nombre de WorkDefinitions pr´esentes (N) ; — le fait qu’il y ait ou non des WorkSequences. Le processus d’entr´ee n’est pas hi´erarchique, mais cela n’a pas d’impact sur la complexit´e du mod`ele d’entr´ee ´etant donn´e que : — l’image d’un Process est plus simple que l’image d’une WorkDefinition, nous pouvons nous limiter `a jouer sur le nombre de WorkDefinitions plutˆot que sur le nombre de Process ; — un processus p`ere existant, des ´el´ements resolve sont dans tous les cas cr´e´es pour chaque WorkDefinition ; — l’ajout de s´equences entre les activit´es permet d’ajouter d’autres ´el´ements resolve et donc augmenter la complexit´e du mod`ele d’entr´ee et de la transformation. Il s’agissait surtout d’ˆetre en mesure de g´en´erer des mod`eles d’entr´ee d´efinis simplement, mais parfaitement maˆıtris´es (dont les ´el´ements sources sont d´enombrables de mani`ere fiable) et pouvant atteindre de tr`es grosses tailles (plusieurs millions d’´el´ements). La figure 8.1 donne la forme g´en´erale d’un tel processus donn´e en entr´ee ainsi que le r´eseau de Petri r´esultant par l’application de la transformation SimplePDLToPetriNet. En fonction des deux param`etres et de la d´efinition du processus, nous pouvons parfaitement d´enombrer les ´el´ements constituant le mod`ele source, ainsi que ceux constituant le r´esultat. Il est aussi possible de d´enombrer pr´ecis´ement les ´el´ements interm´ediaires resolve cr´e´es. Ainsi, dans notre exemple, pour un processus avec N WorkDefinitions (N > 1) chaˆın´ees, il y a N − 1 WorkSequences. Les r`egles de transformation produisant des r´eseaux de Petri identiques `a ceux vus dans le chapitre 7.1 que nous rappelons dans la figure 8.2, nous ´etablissons le tableau 8.2 donnant les r`egles de production des ´el´ements sources. Dans ce tableau, n et104 Chapitre 8. R´esultats exp´erimentaux · · · · · · · · · Figure 8.1 – Forme g´en´erale des mod`eles d’entr´ee g´en´er´es. r signifient respectivement normal et resolve, les abr´eviations Pl, Tr, A, P, WD, WS correspondent respectivement `a Place, Transition, Arc, Process, WorkDefinition et WorkSequence. Les trois derni`eres colonnes du tableau sont les totaux d’´el´ements resolve cr´e´es (Tresolve), d’´el´ements cr´e´es (Tinterm´ediaire ), et d’´el´ements dans les versions finales des images des sources apr`es r´esolution (Tf inal). Figure 8.2 – R´eseaux de Petri images d’un Process, d’une WorkDefinition et d’une WorkSequence. Compte tenu du fait que nos mod`eles d’entr´ee g´en´er´es n’ont pas de processus hi´erarchiques, les arcs de synchronisation ainsi que les ´el´ements resolve associ´es n’existent pas dans l’image du Process. Ainsi, pour un processus compos´e de N WorkDefinitions (avec N > 1) on obtient 14N + 8 ´el´ements cibles normaux et 4N − 2 ´el´ements resolve, comme le r´esume la table 8.3. Les valeurs que nous donnons par la suite sont celles d’exp´eriences men´ees sur un serveur ayant les caract´eristiques suivantes : — syst`eme Unix 64 bits ;8.2. Performances 105 Source Places Transitions Arcs Tresolve Tinterm´ediaire Tf inal n r n r P 3 0 2 0 4 0 9 9 WD 4 0 2 2 7 2 15 13 WS 0 1 0 1 1 2 3 1 Table 8.2 – D´enombrement des ´el´ements cibles cr´e´es `a partir d’´el´ements sources. Places Transitions Arcs Tresolve Tnormal n r n r 4N + 3 N − 1 2N + 2 3N − 1 8N + 3 4N − 2 14N + 8 Table 8.3 – D´enombrement des ´el´ements cibles cr´e´es en fonction du nombre de WorkDefinitions donn´e en entr´ee (N > 1). — RAM : 24 GB ; — processeurs : 2 × 2,93 GHz Quad-Core Intel Xeon. Cependant, mis `a part pour les transformations `a plusieurs millions d’´el´ements qui demandent des ressources sup´erieures `a celles fournies par un poste de bureau, ces exp´eriences peuvent tout `a fait ˆetre reproduites sur une machine bien plus modeste. La table 8.4 donne les temps moyens de la transformation appliqu´ee sur des mod`eles de tailles diff´erentes. La premi`ere colonne donne le nombre d’´el´ements sources du mod`ele d’entr´ee en fonction du param`etre d’entr´ee N. La deuxi`eme colonne donne le nombre d’´el´ements constituant le mod`ele r´esultant. Les temps moyens sont donn´es par les colonnes suivantes, en s´eparant les deux phases, la derni`ere colonne donnant les dur´ees totales. Pour donner une id´ee de la taille des donn´ees, la s´erialisation .xmi d’un mod`ele `a 2 000 000 d’´el´ements sources (derni`ere ligne) est un fichier d’environ 320 Mo. #src (2N) #tgt phase 1 phase 2 Total temps % temps % 20 148 16,7ms 97,09 0,5ms 2,91 17,2ms 200 1408 66ms 90,66 6,8ms 9,34 72,8ms 1000 7008 208ms 87,76 29ms 12,24 237ms 2000 14 008 359ms 86,92 54ms 13,08 413ms 4000 28 008 833ms 85,35 143ms 14,65 976ms 6000 42 008 ∼1,47s 86,98 223ms 13,02 ∼1,69s 8000 56 008 ∼2,4s 87,27 342ms 12,73 ∼2,75s 10 000 70 008 ∼3,61s 88,03 491ms 11,97 4,1s 20 000 140 008 ∼13,4s 88,16 ∼1,8s 11,84 ∼15,2s 40 000 280 008 ∼0min 52s 88,14 ∼0min 7s 11,86 ∼0min 59s 100 000 700 008 ∼5min 22s 88,54 ∼0min 42s 11,46 ∼6min 4s 200 000 1 400 008 ∼20min 50s 88,22 ∼2min 47s 11,78 ∼23min 37s 2 000 000 14 000 008 ∼35h 40min 84,87 ∼6h 30min 11,78 ∼42h 10min Table 8.4 – Mesures de dur´ees de transformation en fonction des tailles des mod`eles sources. La figure 8.3 donne une repr´esentation graphique des temps d’ex´ecution en fonction de la taille du mod`ele d’entr´ee. Plus le mod`ele source est gros, plus la dur´ee de la transformation est ´elev´ee. Nous notons que plus le mod`ele source est important, plus la part de la premi`ere phase de la transformation est importante par rapport `a la phase de r´esolution. Cela s’explique par deux facteurs : d’une part par la transformation elle-mˆeme qui cr´ee bien plus d’´el´ements106 Chapitre 8. R´esultats exp´erimentaux cibles (normaux et resolve) qu’elle ne doit en r´esoudre, d’autre part par les am´eliorations et optimisations que nous avons apport´ees au code g´en´er´e et aux m´ecanismes d´evelopp´es. 0 50 000 100 000 150 000 200 000 0 500 000 1 000 000 1 500 000 P1 P2 T Nombre de sources T emps moyen (en ms) (P1) Temps moyen phase #1 (P2) Temps moyen phase #2 (T) Temps moyen total Figure 8.3 – Temps moyen de transformation (en ms) en fonction du nombre d’´el´ements dans le mod`ele source (phase 1, phase 2, total). En effet, ces r´esultats ne sont pas les r´esultats que nous pourrions obtenir avec la version stable actuelle de nos outils : initialement, la phase de r´esolution ´etait largement plus consommatrice de ressources et la dur´ee d’une transformation ´etait quasiment celle de la seconde phase (environ 99% du temps d’ex´ecution pour des mod`eles de taille >100). De plus, dans leur premi`ere version stable publi´ee, outre une certaine lenteur, nos outils consomment une grande quantit´e de m´emoire. Lors des premi`eres exp´eriences, nos transformations ´etaient beaucoup plus longues `a s’ex´ecuter que la mˆeme transformation d´evelopp´ee en ATL (donn´ee en C). Nous ne pouvions ex´ecuter une transformation d’un mod`ele source de 20 000 ´el´ements ou plus, par manque de m´emoire (20GB allou´es par d´efaut). De son cˆot´e, ATL franchissait ce seuil est bloquait aux alentours de 50 000 ´el´ements sources par manque de m´emoire. C’est ce qu’illustre le tableau 8.5 qui donne les temps d’ex´ecution de deux versions de nos outils, que nous comparons `a ceux avec ATL. Nous avons donc travaill´e en priorit´e sur l’am´elioration du code g´en´er´e pour la phase de r´esolution afin de corriger ces lacunes. Dans un premier temps, constatant que l’essentiel du temps ´etait pass´e dans l’appel de fonctions du framework EMF, nous avons modifi´e la r´esolution de liens. Nous nous reposions exclusivement sur les m´ethodes emf g´erant la r´esolution de liens, qui ´etaient appel´ees au sein de la strat´egie de r´esolution. Cependant, l’impl´ementation de cette m´ethode dans le framework EMF n’est pas assez efficace. Nous avons donc impl´ement´e notre propre r´esolution de liens. Dans un second temps, nous avons continu´e `a optimiser en modifiant notre approche lors de la trace technique des objets cr´e´es. Ces am´eliorations successives ont drastiquement diminu´e la dur´ee d’ex´ecution de la seconde phase par rapport `a la premi`ere qui concentre maintenant l’essentiel du temps processeur d’une transformation. Finalement, nous avons abouti `a la version actuelle qui sera int´egr´ee dans la prochaine version stable de Tom. Tout au long de la transformation, nous stockons les ´el´ements trac´es servant `a la r´esolution (tra¸cabilit´e technique) ainsi que les ´el´ements r´ef´eren¸cant les ´el´ements interm´ediaires resolve (c’est-`a-dire ayant un pointeur vers un ´el´ement resolve, par exemple un arc image d’une WorkSequence dans l’exemple SimplePDLToPetriNet). En d´ebut de phase de r´esolution, nous r´ecup´erons l’ensemble des ´el´ements interm´ediaires temporaires. Nous le parcourons et pour chaque ´el´ement de cet ensemble, nous parcourons l’ensemble des objets le r´ef´eren¸cant pour leur appliquer la r´esolution de lien. Avec notre im-8.2. Performances 107 N #src (2N) #tgt Tom ATL v1 v2 Simple 10 20 148 83ms 17ms - 100 200 1408 638ms 73ms - 500 1000 7008 ∼38s 237ms - 1000 2000 14 008 ∼4min 14s 414ms - 2000 4000 28 008 ∼36min 55s 976ms - 3000 6000 42 008 ∼1h 59min 1,7s - 4000 8000 56 008 ∼4h 24min 2,8s - 5000 10 000 70 008 ∼8h 14min 4,1s ∼28s 10 000 20 000 140 008 N/A ∼0min 15s ∼1min 41s 20 000 40 000 280 008 N/A ∼0min 59s ∼7min 38s 50 000 100 000 700 008 N/A ∼6min 4s ∼1h 39min 100 000 200 000 1 400 008 N/A ∼23min 37s ∼ 1 000 000 2 000 000 14 000 008 N/A ∼42h 10min ∼ Table 8.5 – Comparaison des performances entre Tom (premi`ere et derni`ere versions) et ATL. pl´ementation, nous parcourons le minimum d’objets possible, ce qui r´eduit consid´erablement les parcours (notamment par rapport `a EMF). Ces optimisations nous ont apport´e un gain cons´equent nous permettant de passer d’outils transformant difficilement des petits mod`eles de 10 000 ´el´ements en des outils capables de transformer des mod`eles de plusieurs millions d’´el´ements. Finalement, ces premiers r´esultats exp´erimentaux nous permettent d’exprimer un avis sur nos choix technologiques initiaux, en particulier sur l’utilisation de EMF. Si ce choix paraissait naturel pour pouvoir avoir une couverture initiale maximale de chaˆınes de d´eveloppement, d’outils et d’utilisateurs, il paraˆıt beaucoup moins naturel lorsque l’on commence `a s’int´eresser aux performances. En effet, notre travail de profiling et d’optimisation nous a montr´e que le facteur limitant essentiel r´esidait dans les appels EMF. Leur limitation puis leur suppression a drastiquement am´elior´e les performances de nos outils. Dans notre contexte, et pour les tˆaches demand´ees, nous n’avions finalement pas un besoin fondamental de toutes les fonctionnalit´es fournies par EMF. Une version simplifi´ee et optimis´ee de la gestion des r´ef´erences inverses suffisait amplement pour notre phase de r´esolution. Il est donc plus int´eressant en termes de performances pures et de m´emoire de nous passer de la technologie de support (EMF dans notre impl´ementation actuelle) pour tout ce qui rel`eve de la m´ecanique interne de la transformation. De plus, nous affranchir totalement d’une technologie nous permet d’obtenir des outils plus g´en´eriques, et donc plus facilement int´egrables dans d’autres contextes et chaˆınes de d´eveloppement. Cependant, si le choix initial d’utilisation des services EMF pour le moteur des transformations s’est av´er´e peu judicieux et a ´et´e remis en cause en cours de th`ese, il a ´et´e fondamental pour avoir une impl´ementation concr`ete et un support de travail. De plus, notre travail a mis en avant ce choix peu judicieux pour la mise en œuvre de m´ecanismes internes de nos transformations, ce qui ne remet pas en cause l’usage d’EMF dans d’autres contextes avec d’autres outils, ni mˆeme son usage avec Tom. En effet, au-del`a des constructions haut-niveau qui s’appuyaient partiellement sur EMF, subsiste notre outil de g´en´eration automatique d’ancrages formels qui permet d’op´erer le changement d’espace technologique. Cet outil reste extrˆemement int´eressant pour faciliter l’´ecriture des transformations — de mani`ere totalement ind´ependante du langage de transformation ainsi que de sa mise en œuvre technique — dans un contexte Java-EMF.108 Chapitre 8. R´esultats exp´erimentaux 8.3 Perspectives L’ensemble de nos outils peut ˆetre actuellement consid´er´e comme un prototype op´erationnel. Cependant, dans le cadre d’une utilisation plus large et dans un contexte industriel r´eel, on pourrait s’orienter vers diff´erents aspects qui ont ´emerg´e de ce travail de th`ese et des premiers r´esultats exp´erimentaux. Nous avons pu ´eprouver l’int´erˆet de notre approche hybride pour d´evelopper des transformations de mod`eles. Cette approche facilite de d´eveloppement grˆace aux outils de g´en´eration de code et aux constructions haut-niveau avec une forte expressivit´e, tout en conservant l’environnement global existant. Il reste donc possible d’utiliser les sp´ecificit´es du langage g´en´eraliste au sein duquel nous nous int´egrons pour certaines tˆaches tout en manipulant des termes dans une autre partie de l’application. Le travail d’adaptation que l’utilisateur doit fournir est de fait plus faible, d’o`u une plus grande efficacit´e. Notre approche a aussi l’avantage de perturber au minimum la chaˆıne de d´eveloppement et le choix de l’adopter n’est pas irr´eversible ou coˆuteux dans le sens o`u chaque transformation d´evelopp´ee peut ˆetre remplac´ee par sa version dans le langage hˆote (ou ´ecrite avec un autre outil) sans changer le reste du logiciel. Dans cette optique d’int´egration non-intrusive dans des environnements existants, une voie serait de travailler `a la g´en´eralisation de nos outils afin d’´etendre l’approche `a d’autres langages et technologies. Par exemple, un premier pas dans cette direction pourrait ˆetre de se pencher sur l’utilisation de Kevoree ainsi que sur l’extension au langage Ada (des travaux sur le sujet ont d´ej`a ´et´e entam´es). L’utilisation de constructions haut-niveau et d’outils de g´en´eration permet `a l’utilisateur de se concentrer sur le cœur de l’application et de d´el´eguer `a un outil automatique les tˆaches r´ep´etitives sujettes `a erreurs pour un humain. Cela contribue `a augmenter la confiance dans le logiciel d´evelopp´e. Un autre axe de travail consisterait `a r´efl´echir sur les strat´egies que nous utilisons pour transformer des mod`eles. Nous nous sommes aper¸cus que certaines relations ´etaient souvent vues comme int´eressantes (composition), mais que dans certaines situations, d’autres relations pouvaient ˆetre le centre de la transformation. Travailler sur la param´etrisation des strat´egies de r´e´ecriture par des types de relation `a suivre pourrait ˆetre une voie `a explorer. Un autre aspect int´eressant que d’autres outils couvrent est la transformation de mod`eles multiples : actuellement notre approche consid`ere un seul mod`ele source et un seul mod`ele cible. Cependant, on pourrait gagner en expressivit´e en permettant d’´ecrire des transformations `a plusieurs sources et cibles. Bien que les outils soient compl`etement op´erationnels, une optimisation serait probablement n´ecessaire pour un usage plus large dans un cadre industriel, tant du point de vue de leurs performances que de leur utilisabilit´e. Nos travaux d’am´elioration des performances par r´eing´enierie de la phase de r´esolution constituent une premi`ere ´etape qui sera concr´etis´ee dans une prochaine release du projet Tom. Du point de vue de la modularit´e et de la r´eutilisation du code, les strat´egies de r´e´ecriture nous fournissent un socle int´eressant de par leur modularit´e intrins`eque. Nos exp´erimentations sur le sujet ont abouti `a un prototype de nos outils avec phase de r´esolution modulaire. Cependant, pour des raisons de confort d’utilisation pour le d´eveloppeur, nous avons choisi de ne pas int´egrer cette fonctionnalit´e par d´efaut dans la version stable actuelle. Nous avons cependant une base de travail pour r´efl´echir `a cet aspect. Il faut toutefois noter que les ´evolutions de nos outils dues `a l’am´elioration de leurs performances risquent d’entrer en concurrence avec l’approche adopt´ee dans notre prototype modulaire. De fait, l’aspect performance est actuellement privil´egi´e. Nous avons aussi pu apporter une tra¸cabilit´e au sein d’un langage g´en´eraliste tel que Java. Il s’agissait d’apporter une aide substantielle au processus de qualification d’un logiciel. L’aspect tra¸cabilit´e des transformations semble ˆetre un th`eme particuli`erement prometteur. En effet, les industries d´eveloppant du logiciel critique ont un besoin accru de tra¸cabilit´e pour qualifier et certifier leurs outils. L’adoption de l’ing´enierie dirig´ee par les mod`eles a entraˆın´e l’usage de nouvelles m´ethodes et de nouveaux outils tandis que les contraintes l´egales8.3. Perspectives 109 subsistent. Partant de ce constat, les travaux sur la tra¸cabilit´e `a des fins de validation du logiciel offrent des perspectives int´eressantes. Dans l’impl´ementation actuelle de nos travaux, les constructions pour la tra¸cabilit´e ne sont pas distinctes. Une premi`ere ´etape serait de distinguer clairement (par deux constructions distinctes du langage) la tra¸cabilit´e utilis´ee `a des fins purement techniques (usage pour la phase de r´esolution) et la tra¸cabilit´e m´etier. Notre approche de trace `a la demande permet d´ej`a de limiter la taille des traces et donc de les rendre plus exploitables a posteriori. Se pose aussi la question de l’exploitation du mod`ele de lien, de mani`ere automatique ou non dans le processus de qualification.110 Chapitre 8. R´esultats exp´erimentauxConclusion La qualification d’outil est une ´etape fondamentale dans le processus de certification du logiciel. L’objectif principal de cette th`ese ´etait de contribuer `a l’´elaboration de m´ethodes et outils pour am´eliorer la confiance dans les outils int´egr´es dans les chaˆınes de d´eveloppement critiques. Le langage Tom d´evelopp´e dans l’´equipe a ´et´e le support de ces travaux. Contributions Une m´ethode de transformation de mod`eles par r´e´ecriture Dans cette th`ese, nous avons pr´esent´e une m´ethode pour transformer des mod`eles en nous appuyant sur des strat´egies de r´e´ecriture. Cette m´ethode nous permet d’exprimer ais´ement une transformation `a partir de r`egles, sans aucune notion d’ordre d’application.En nous pla¸cant dans le cadre du langage Tom, nous avons fait le choix d’ˆetre `a la fronti`ere entre les langages d´edi´es et les langages g´en´eralistes, afin d’en tirer le meilleur des deux mondes. Nous avons donc propos´e un ˆılot formel d´edi´e aux transformations de mod`eles qui s’int`egre au sein du langage g´en´eraliste Java. Du fait du fonctionnement de notre m´ethode hybride, nos transformations sont modulaires. Cette qualit´e est fondamentale en ing´enierie du logiciel, que ce soit pour la maintenance ou la cr´eation de nouveaux outils. Une repr´esentation de mod`eles sous la forme de termes alg´ebriques Pour transformer des mod`eles selon notre m´ethode hybride, il est n´ecessaire d’op´erer un changement d’espace technologique entre le monde des mod`eles et celui des termes. Nous avons donc ´etabli une repr´esentation des mod`eles sous la forme de termes alg´ebriques. Cette derni`ere repose sur l’obtention d’un arbre de recouvrement du mod`ele par la relation de composition. Un outil impl´emente cette repr´esentation par la g´en´eration de la signature alg´ebrique correspondant `a un m´etamod`ele donn´e. Cela permet d’instancier des mod`eles et de les manipuler en tant que termes alg´ebriques. Une tra¸cabilit´e des transformations L’exigence de tra¸cabilit´e qu’impose le processus de qualification nous a conduits `a proposer un ˆılot formel permettant de lier un ´el´ement source `a des ´el´ements cibles. Cette construction d´edi´ee permet d’ajouter une tra¸cabilit´e au sein d’une transformation ´ecrite dans un langage g´en´eraliste tel que Java. Des outils accessibles pour am´eliorer la confiance dans le logiciel Tout au long de ce travail, nous nous sommes appliqu´es `a mettre en œuvre des outils impl´ementant nos travaux. Nos choix ont aussi ´et´e guid´es par notre souci d’accessibilit´e et de diffusion. C’est pourquoi nous nous sommes appuy´es sur les langages et frameworks tr`es utilis´es et ayant d´ej`a perc´e dans l’industrie. Si certains choix ont pu ˆetre remis en cause suite `a nos ´evaluations et aux tests de performance, il n’en demeure pas moins qu’ils nous ont 111112 Conclusion ´et´e tr`es utiles pour obtenir un premier prototype op´erationnel. Les outils d´evelopp´es doivent faciliter le d´eveloppement logiciel en limitant le code ´ecrit manuellement et en maximisant le code g´en´er´e. De plus, dans cette optique d’am´elioration de la confiance dans le logiciel, il est tr`es important de diffuser des outils de production dont le code source est librement consultable, modifiable et rediffusable afin de pouvoir les v´erifier, corriger, am´eliorer et utiliser. Par cons´equent, tous nos outils sont diffus´es sous licence libre. Perspectives Les perspectives qu’ouvre ce travail sont multiples, les chaˆınes de d´eveloppement de syst`emes critiques ayant de besoins forts pour la qualification d’outils. Diff´erents travaux peuvent ˆetre entrepris pour ´etendre et prolonger les contributions de cette th`ese, que ce soit au niveau de la repr´esentation et du parcours de mod`eles, de l’expression et de la tra¸cabilit´e des transformations ou de la g´en´eralisation des m´ethodes et outils. Strat´egies param´etr´ees L’une des pistes de recherche consiste `a travailler sur les strat´egies. Dans le chapitre 7, nous avons mis en avant un cas d’´etude qui ne permet pas de donner la pleine mesure de nos outils. Cela s’explique par le principe de notre repr´esentation de mod`eles sous la forme de termes ainsi que par leur parcours. Nous construisons un arbre de recouvrement par la relation de composition pour obtenir une vue arborescente du mod`ele. Ensuite, les strat´egies les parcourent en suivant ces liens de composition. Bien que ce type d’utilisation couvre la majeure partie des cas, il existe des situations o`u la relation de composition n’est pas la relation d’int´erˆet de l’utilisateur, comme nous l’avons montr´e. Afin de rem´edier `a ce probl`eme, il faudrait pouvoir d´efinir une alternative pour les strat´egies de parcours en offrant la possibilit´e de les param´etrer par les types de liens `a suivre. Un second prolongement serait alors de pouvoir param´etrer localement un parcours, en fonction d’un contexte donn´e. Modularit´e des transformations et r´eutilisation Un aspect r´ecurrent en g´enie logiciel est la modularit´e et la r´eutilisation du code. Du fait de notre approche construite sur les strat´egies de r´e´ecriture, nous offrons d´ej`a une certaine modularit´e des transformations et permettons la r´eutilisation du code de chaque transformation ´el´ementaire. Cependant, les d´efinitions ´ecrites pour une transformation donn´ee peuvent rarement ˆetre r´eutilis´ees directement, sans aucune modification. Un axe de travail serait donc de r´efl´echir `a l’expression des d´efinitions les rendant plus g´en´eriques. Ensuite, le prototype modulaire de la phase de r´esolution de notre approche pourrait ˆetre affin´e, ´etendu et simplifi´e afin d’accompagner chaque d´efinition par une strat´egie de r´esolution ´el´ementaire. G´en´eralisation et ouverture `a d’autres technologies Nous nous sommes appuy´es sur la technologie EMF et le langage Java pour d´evelopper des outils et tester nos travaux. A terme, il serait int´eressant de g´en´eraliser notre m´ethode ` de repr´esentation et de transformation de mod`eles en ouvrant nos outils `a d’autres langages g´en´eralistes et `a d’autres technologies. Nous pensons notamment au langage Ada pour lequel nous avons men´e quelques exp´erimentations et dont un backend est maintenant pr´esent dans Tom. Les strat´egies ont ´et´e impl´ement´ees et peuvent ˆetre utilis´ees dans un programme Ada. Ce langage ´etant utilis´e pour le d´eveloppement de syst`emes temps r´eel et embarqu´es pour son haut niveau de fiabilit´e et de s´ecurit´e, nous pourrions nous concentre sur ce langage. L’une des difficult´es de la gestion de Ada r´eside dans l’absence de garbage collector. On ne peut donc ais´ement impl´ementer toutes les fonctionnalit´es de Tom (notamment le partage maximal) qui113 existent avec le langage Java. La g´en´eralisation de nos outils nous permettrait aussi de nous ouvrir `a d’autres technologies que EMF. Nous pensons notamment `a Kevoree qui semble ˆetre un bon candidat, tant du point de vue fonctionnalit´es que performances. Tra¸cabilit´e : extension et usage Nous avons fourni une tra¸cabilit´e qui pourrait ˆetre ´etendue, d’une part `a des transformations comprenant des sources multiples, d’autre part `a des objectifs de d´etection et r´ecup´eration d’erreurs. Cela demanderait de r´efl´echir `a l’´evolution du m´etamod`ele de trace. Ensuite, cette tra¸cabilit´e fournie par Tom pourrait ˆetre g´en´eralis´ee afin de d´epasser le cadre de l’ˆılot formel d´edi´e aux transformations de mod`eles. Enfin, de mani`ere pragmatique et `a court terme, nous envisageons de modifier le langage pour s´eparer la construction de tra¸cabilit´e en deux constructions distinctes, l’une d´edi´ee `a la tra¸cabilit´e interne, l’autre `a la tra¸cabilit´e de sp´eci- fication.114 ConclusionAnnexe A Etude de cas : Transformation ´ SimplePDLToPetriNet A.1 Code de la transformation SimplePDLToPetriNet Ce code est accessible sur le d´epˆot officiel du projet Tom : https://gforge.inria.fr/ scm/?group_id=78. Pour plus d’informations sur le sujet, le lecteur pourra aussi se r´ef´erer `a la documentation en ligne accessible sur cette page : http://tom.loria.fr/wiki/index. php5/Documentation:Playing_with_EMF. 1 import org.eclipse.emf.common.util.*; 2 import org.eclipse.emf.ecore.*; 3 import org.eclipse.emf.ecore.util.ECrossReferenceAdapter; 4 import org.eclipse.emf.ecore.xmi.*; 5 import org.eclipse.emf.ecore.xmi.impl.*; 6 7 import SimplePDLSemantics.DDMMSimplePDL.*; 8 import petrinetsemantics.DDMMPetriNet.*; 9 10 import SimplePDLSemantics.EDMMSimplePDL.*; 11 import petrinetsemantics.EDMMPetriNet.*; 12 import SimplePDLSemantics.SDMMSimplePDL.*; 13 import petrinetsemantics.SDMMPetriNet.*; 14 import SimplePDLSemantics.TM3SimplePDL.*; 15 import petrinetsemantics.TM3PetriNet.*; 16 17 import java.util.*; 18 import java.util.concurrent.ConcurrentMap; 19 import java.util.concurrent.ConcurrentHashMap; 20 import java.io.File; 21 import java.io.Writer; 22 import java.io.BufferedWriter; 23 import java.io.OutputStreamWriter; 24 import java.io.FileOutputStream; 25 import java.io.FileInputStream; 26 27 import tom.library.utils.ReferenceClass; 28 import tom.library.utils.LinkClass; 29 import tom.library.sl.*; 30 import tom.library.emf.*; 31 32 public class SimplePDLToPetriNet { 33 34 %include{ sl.tom } 35 %include{ LinkClass.tom } 36 %include{ emf/ecore.tom } 37 38 %include{ mappings/DDMMPetriNetPackage.tom } 39 %include{ mappings/DDMMSimplePDLPackage.tom } 40 41 %include{ mappings/EDMMPetriNetPackage.tom } 42 %include{ mappings/EDMMSimplePDLPackage.tom } 43 %include{ mappings/SDMMPetriNetPackage.tom } 44 %include{ mappings/SDMMSimplePDLPackage.tom } 115116 Annexe A. Etude de cas : Transformation SimplePDLToPetriNet ´ 45 %include{ mappings/TM3PetriNetPackage.tom } 46 %include{ mappings/TM3SimplePDLPackage.tom } 47 48 %typeterm SimplePDLToPetriNet { implement { SimplePDLToPetriNet }} 49 50 private static Writer writer; 51 private static PetriNet pn = null; 52 private static LinkClass tom__linkClass; 53 54 public SimplePDLToPetriNet() { 55 this.tom__linkClass = new LinkClass(); 56 } 57 58 59 %transformation SimplePDLToPetriNet(tom__linkClass:LinkClass,pn:PetriNet) : "metamodels/SimplePDLSemantics_updated.ecore" -> "metamodels/PetriNetSemantics_updated.ecore" { 60 61 definition P2PN traversal ‘TopDown(P2PN(tom__linkClass,pn)) { 62 p@Process[name=name] -> { 63 Place p_ready = ‘Place(name + "_ready", pn,ArcEList(), ArcEList(), 1); 64 Place p_running = ‘Place(name + "_running", pn,ArcEList(), ArcEList(), 0); 65 Place p_finished = ‘Place(name + "_finished", pn,ArcEList(), ArcEList(), 0); 66 String n1 = ‘name+"_start"; 67 %tracelink(t_start:Transition, ‘Transition(n1, pn,ArcEList(), ArcEList(), 1, 1)); 68 n1 = ‘name+"_finish"; 69 %tracelink(t_finish:Transition, ‘Transition(n1, pn,ArcEList(), ArcEList(), 1, 1)); 70 71 ‘Arc(t_start, p_ready, pn,ArcKindnormal(), 1); 72 ‘Arc(p_running, t_start, pn,ArcKindnormal(), 1); 73 ‘Arc(t_finish, p_running, pn,ArcKindnormal(), 1); 74 ‘Arc(p_finished, t_finish, pn,ArcKindnormal(), 1); 75 76 WorkDefinition from = ‘p.getFrom(); 77 if (from!=null) { 78 Transition source = %resolve(from:WorkDefinition,t_start:Transition); 79 source.setNet(pn); 80 Arc tmpZoomIn = ‘Arc(p_ready,source,pn,ArcKindnormal(), 1); 81 82 Transition target = %resolve(from:WorkDefinition,t_finish:Transition); 83 target.setNet(pn); 84 Arc tmpZoomOut = ‘Arc(target,p_finished,pn,ArcKindread_arc(), 1); 85 } 86 } 87 } 88 89 definition WD2PN traversal ‘TopDown(WD2PN(tom__linkClass,pn)) { 90 wd@WorkDefinition[name=name] -> { 91 //System.out.println("Je suis un A"); 92 Place p_ready = ‘Place(name + "_ready", pn,ArcEList(), ArcEList(), 1); 93 String n1 = ‘name+"_started"; 94 %tracelink(p_started:Place, ‘Place(n1, pn,ArcEList(), ArcEList(), 0)); 95 Place p_running = ‘Place(name+"_running", pn,ArcEList(), ArcEList(), 0); 96 n1 = ‘name+"_finished"; 97 %tracelink(p_finished:Place, ‘Place(n1, pn,ArcEList(), ArcEList(), 0)); 98 n1 = ‘name+"_start"; 99 %tracelink(t_start:Transition, ‘Transition(n1, pn,ArcEList(), ArcEList(), 1, 1)); 100 n1 = ‘name+"_finish"; 101 %tracelink(t_finish:Transition, ‘Transition(n1, pn,ArcEList(), ArcEList(), 1, 1)); 102 103 ‘Arc(t_start, p_ready, pn,ArcKindnormal(), 1); 104 ‘Arc(p_started, t_start, pn,ArcKindnormal(), 1); 105 ‘Arc(p_running, t_start, pn,ArcKindnormal(), 1); 106 ‘Arc(t_finish, p_running, pn,ArcKindnormal(), 1); 107 ‘Arc(p_finished, t_finish, pn,ArcKindnormal(), 1); 108 109 SimplePDLSemantics.DDMMSimplePDL.Process parent = ‘wd.getParent(); 110 Transition source = %resolve(parent:Process,t_start:Transition); 111 source.setNet(pn); 112 Arc tmpDistribute = ‘Arc(p_ready,source,pn,ArcKindnormal(), 1); 113 114 Transition target = %resolve(parent:Process,t_finish:Transition); 115 target.setNet(pn); 116 Arc tmpRejoin = ‘Arc(target,p_finished,pn,ArcKindread_arc(), 1); 117 } 118 } 119 120 definition WS2PN traversal ‘TopDown(WS2PN(tom__linkClass,pn)) { 121 ws@WorkSequence[predecessor=p,successor=s,linkType=linkType] -> { 122 Place source= null; 123 Transition target= null; 124 WorkDefinition pre = ‘p;A.1. Code de la transformation SimplePDLToPetriNet 117 125 WorkDefinition suc = ‘s; 126 %match(linkType) { 127 (WorkSequenceTypefinishToFinish|WorkSequenceTypefinishToStart)[] -> { 128 source = %resolve(pre:WorkDefinition,p_finished:Place); 129 } 130 (WorkSequenceTypestartToStart|WorkSequenceTypestartToFinish)[] -> { 131 source = %resolve(pre:WorkDefinition,p_started:Place); 132 } 133 134 (WorkSequenceTypefinishToStart|WorkSequenceTypestartToStart)[] -> { 135 target = %resolve(suc:WorkDefinition,t_start:Transition); 136 } 137 (WorkSequenceTypestartToFinish|WorkSequenceTypefinishToFinish)[] -> { 138 target = %resolve(suc:WorkDefinition,t_finish:Transition); 139 } 140 } 141 source.setNet(pn); 142 target.setNet(pn); 143 144 Arc wsImage = ‘Arc(target,source, pn,ArcKindread_arc(), 1); 145 } 146 } 147 } 148 149 public static void main(String[] args) { 150 System.out.println("\nStarting...\n"); 151 152 XMIResourceImpl resource = new XMIResourceImpl(); 153 SimplePDLSemantics.DDMMSimplePDL.Process p_root; 154 Map opts = new HashMap(); 155 opts.put(XMIResource.OPTION_SCHEMA_LOCATION, java.lang.Boolean.TRUE); 156 157 if (args.length>0) { 158 DDMMSimplePDLPackage packageInstance = DDMMSimplePDLPackage.eINSTANCE; 159 File input = new File(args[0]); 160 try { 161 resource.load(new FileInputStream(input),opts); 162 } catch (Exception e) { 163 e.printStackTrace(); 164 } 165 p_root = (SimplePDLSemantics.DDMMSimplePDL.Process) resource.getContents().get(0); 166 } else { 167 System.out.println("No model instance given in argument. Using default hardcoded model."); 168 WorkDefinition wd1 = ‘WorkDefinition(null,WorkSequenceEList(),WorkSequenceEList(),"A",null); 169 WorkDefinition wd2 = ‘WorkDefinition(null,WorkSequenceEList(),WorkSequenceEList(),"B",null); 170 WorkDefinition wd3 = ‘WorkDefinition(null,WorkSequenceEList(),WorkSequenceEList(),"C",null); 171 WorkDefinition wd4 = ‘WorkDefinition(null,WorkSequenceEList(),WorkSequenceEList(),"D",null); 172 WorkSequence ws1 = ‘WorkSequence(null,WorkSequenceTypestartToStart(),wd1,wd2); 173 WorkSequence ws2 = ‘WorkSequence(null,WorkSequenceTypestartToFinish(),wd3,wd4); 174 175 p_root = ‘Process("root",ProcessElementEList(wd1,wd2,ws1),null); 176 SimplePDLSemantics.DDMMSimplePDL.Process p_child = ‘Process("child",ProcessElementEList(wd3,wd4,ws2), wd2); 177 178 wd1.setParent(p_root); 179 wd2.setParent(p_root); 180 wd2.setProcess(p_child); 181 182 wd3.setParent(p_child); 183 wd4.setParent(p_child); 184 185 ws1.setParent(p_root); 186 ws2.setParent(p_child); 187 } 188 SimplePDLToPetriNet translator = new SimplePDLToPetriNet(); 189 190 try { 191 translator.pn = ‘PetriNet(NodeEList(),ArcEList(),"main"); 192 193 //System.out.println("Initial Petri net"); 194 //‘Sequence(TopDown(PrintTransition()),TopDown(PrintPlace())).visit(translator.pn, new EcoreContainmentIntrospector()); 195 196 /*//transformer is equivalent to: 197 Strategy transformer = ‘Sequence( 198 TopDown(Process2PetriNet(translator)), 199 TopDown(WorkDefinition2PetriNet(translator)), 200 TopDown(WorkSequence2PetriNet(translator)) 201 ); 202 */ 203 204 //NOTE: force the user to give the link as first parameter, and target118 Annexe A. Etude de cas : Transformation SimplePDLToPetriNet ´ 205 //model as second one 206 Strategy transformer = ‘SimplePDLToPetriNet(translator.tom__linkClass,translator.pn); 207 transformer.visit(p_root, new EcoreContainmentIntrospector()); 208 ‘TopDown(tom__StratResolve_SimplePDLToPetriNet(translator.tom__linkClass,translator.pn)).visit(translator.pn, new EcoreContainmentIntrospector()); 209 210 211 //for generation of textual Petri nets usable as input for TINA 212 String outputName = "resultingPetri.net"; 213 writer = new BufferedWriter(new OutputStreamWriter(new 214 FileOutputStream(new File(outputName)))); 215 216 System.out.println("\nResult"); 217 ‘Sequence(TopDown(PrintTransition()),TopDown(PrintPlace())).visit(translator.pn, 218 new EcoreContainmentIntrospector()); 219 220 System.out.println("\nFinish to generate "+outputName+" file, usable as input for TINA"); 221 writer.flush(); 222 writer.close(); 223 System.out.println("done."); 224 225 } catch(VisitFailure e) { 226 System.out.println("strategy fail!"); 227 } catch(java.io.FileNotFoundException e) { 228 System.out.println("Cannot create Petri net output file."); 229 } catch (java.io.IOException e) { 230 System.out.println("Petri net save failed!"); 231 } 232 } 233 234 %strategy PrintArc() extends Identity() { 235 visit Arc { 236 Arc[source=node1, target=node2] -> { 237 System.out.println(‘node1.getName() + " -> " + ‘node2.getName()); 238 } 239 } 240 } 241 242 %strategy PrintTransition() extends Identity() { 243 visit Transition { 244 tr@ResolveWorkDefinitionTransition[tom_resolve_element_attribute_name=name] -> { 245 System.out.println("tr resolve " + ‘name); 246 return ‘tr; 247 } 248 249 ptr@ResolveProcessTransition[tom_resolve_element_attribute_name=name] -> { 250 System.out.println("tr process resolve " + ‘name); 251 return ‘ptr; 252 } 253 254 Transition[name=name,incomings=sources,outgoings=targets] -> { 255 String s = " "; 256 String t = " "; 257 %match { 258 ArcEList(_*,Arc[kind=k,weight=w,source=node],_*) << sources && Place[name=placename]<< node -> { 259 s += ‘placename + ((‘k==‘ArcKindread_arc())?"?":"*") + ‘w + " "; 260 } 261 ArcEList(_*,Arc[kind=k,weight=w,target=node],_*) << targets && Place[name=placename]<< node -> { 262 t += ‘placename + ((‘k==‘ArcKindread_arc())?"?":"*") + ‘w + " "; 263 } 264 } 265 multiPrint("tr " + ‘name + s + "->" + t); 266 } 267 268 269 } 270 } 271 272 %strategy PrintPlace() extends Identity() { 273 visit Place { 274 pl@ResolveWorkDefinitionPlace[tom_resolve_element_attribute_name=name] -> { 275 System.out.println("pl resolve " + ‘name); 276 return ‘pl; 277 } 278 279 Place[name=name,initialMarking=w] && w!=0 -> { 280 multiPrint("pl " + ‘name + " " + "(" + ‘w + ")"); 281 } 282 283 } 284 }A.2. Mod`ele source 119 285 286 public static void multiPrint(String s) { 287 System.out.println(s); 288 try { 289 writer.write(s+"\n"); 290 } catch (java.io.IOException e) { 291 System.out.println("Petri net save failed!"); 292 } 293 } 294 295 } A.2 Mod`ele source Cette transformation a ´et´e test´ee avec de nombreux mod`eles. Le mod`ele donn´e par le listing 1 est le mod`ele donn´e en exemple dans la section 7.1 du chapitre 7. Il s’agit aussi du mod`ele par d´efaut de la transformation dans le cas o`u aucun mod`ele n’est pass´e en param`etre (c’est en fait le mod`ele ´equivalent directement construit en Tom sans chargement de fichier). Listing 1 – Mod`ele source de l’exemple pour la transformation SimplePDLToPetriNet (format .xmi) A.3 Mod`ele r´esultant Le mod`ele source donn´e pr´ec´edemment produit le mod`ele cible suivant 2, qui est en fait le r´eseau de Petri r´esultant de la transformation, s´erialis´e sous la forme d’un fichier au format compatible avec l’entr´ee du model-checker TINA [BRV04] (il est aussi affich´e directement sur la sortie standard) : tr root_start root_ready*1 -> root_running*1 A_ready*1 B_ready*1 tr root_finish root_running*1 A_finished?1 B_finished?1 -> root_finished*1 tr child_start child_ready*1 -> child_running*1 C_ready*1 D_ready*1 tr child_finish child_running*1 C_finished?1 D_finished?1 -> child_finished*1 tr B_start B_ready*1 A_started?1 -> B_started*1 B_running*1 child_ready*1 tr B_finish B_running*1 child_finished?1 -> B_finished*1 tr A_start A_ready*1 -> A_started*1 A_running*1 tr A_finish A_running*1 -> A_finished*1 tr C_start C_ready*1 -> C_started*1 C_running*1 tr C_finish C_running*1 -> C_finished*1 tr D_start D_ready*1 -> D_started*1 D_running*1 tr D_finish D_running*1 C_started?1 -> D_finished*1 pl root_ready (1) pl child_ready (1) pl A_ready (1) pl B_ready (1) pl C_ready (1) pl D_ready (1) Listing 2 – Mod`ele cible r´esultant de la transformation SimplePDLToPetriNet (format lisible par TINA)120 Annexe A. Etude de cas : Transformation SimplePDLToPetriNet ´ A.4 V´erification du r´esultat La boˆıte `a outils TINA 56 (version 3.1.0) a ´et´e utilis´ee pour v´erifier le mod`ele r´esultant de la transformation de mod`ele SimplePDLToPetriNet. Proc´edure Le r´esultat de la transformation est un r´eseau de Petri dans un format lisible par TINA (fichier result.net. La proc´edure ci-apr`es permet de reproduire l’exp´erience : 1. Visualisation du r´eseau de Petri : ~/tina-3.1.0/bin/nd result.net (sauvegarde au format .ndr) 2. Construction du graphe d’atteignabilit´e : ~/tina-3.1.0/bin/tina -C result.ndr result.ktz (le format .ktz est un format binaire propri´etaire) 3. V´erification de propri´et´es : ~/tina-3.1.0/bin/selt result.ktz prop.ltl >> result.selt (le fichier prop.ltl d´ecrit ci-apr`es contient les formules et les propri´et´es `a v´erifier) Formule et propri´et´es 1 op finished = T /\ A_finished /\ B_finished /\ C_finished /\ D_finished; 2 3 [] (finished => dead); 4 [] (dead => finished); 5 [] <> dead ; 6 - <> finished; Listing 3 – Formule et propri´et´es LTL `a v´erifier sur le mod`ele r´esulatnt de la transformation SimplePDLToPetriNet Le listing 3 contient une formule et quatre propri´et´es exprim´ees en LTL afin de pouvoir ˆetre utilis´ees avec TINA. Nous les d´ecrivons ci-apr`es, dans l’ordre : ligne 1 : Il s’agit de la formule d´efinissant l’op´erateur finished comme >∧Af inished∧Bf inished∧ Cf inished ∧ Df inished. Cela signifie que l’on consid`ere le processus complet termin´e lorsque toutes les activit´es le composant sont termin´ees (lorsqu’il y a un jeton dans chaque place f inished des activit´es A, B, C et D). ligne 3 : (f inished ⇒ dead). Cette premi`ere propri´et´e signifie que tout processus dans son ´etat final est termin´e. ligne 4 : (dead ⇒ f inished). Cette deuxi`eme propri´et´e peut ˆetre traduite par « tout processus termin´e est dans son ´etat final » (correction partielle). ligne 5 : ♦dead. Cette troisi`eme propri´et´e est la propri´et´e de terminaison qui assure que « toute ex´ecution se termine ». ligne 6 : ¬♦f inished. Cette quatri`eme propri´et´e peut ˆetre traduite par « l’´etat final n’est jamais atteint » et revient `a v´erifier la propri´et´e de consistance faible (existence d’au moins une ex´ecution du processus). Note : dead est une propri´et´e pr´ed´efinie vraie uniquement sur les ´etats de blocage. 56. http://projects.laas.fr/tina APISENSER : a distributed platform for deploying, executing and managing data collection campaigns using smart devices Nicolas Haderer To cite this version: Nicolas Haderer. APISENSER : a distributed platform for deploying, executing and managing data collection campaigns using smart devices. Mobile Computing. Universit´e des Sciences et Technologie de Lille - Lille I, 2014. French. HAL Id: tel-01087325 https://tel.archives-ouvertes.fr/tel-01087325 Submitted on 25 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Département de formation doctorale en informatique UFR IEEA École doctorale SPI Lille APISENSE® : une plate-forme répartie pour la conception, le déploiement et l’exécution de campagnes de collecte de données sur des terminaux intelligents THÈSE présentée et soutenue publiquement le 05/11/2014 pour l’obtention du Doctorat de l’Université Lille I (spécialité informatique) par Haderer Nicolas Composition du jury Rapporteurs : Chantal Taconet, TELECOM SudParis, France Ernesto Exposito, INSA Toulouse, France Examinateurs : Stéphane Frénot, INSA Lyon, France Luigi Lancieri, Université Lille I, France Directeur : Lionel Seinturier, Université Lille I, France Co-encadrant : Romain Rouvoy, Université Lille I, France Laboratoire d’Informatique Fondamentale de Lille – Inria Lille - Nord Europe UMR Lille 1/CNRS 8022R É S UM É Le mobile crowdsensing est une nouvelle forme de collecte de données exploitant la foule de terminaux intelligents déjà déployés à travers le monde pour collecter massivement des données environnementales ou comportementales d’une population. Ces dernières années, ce type de collecte de données a suscité l’intérêt d’un grand nombre d’acteurs industriels et académiques dans de nombreux domaines tels que l’étude de la mobilité urbaine, la surveillance de l’environnement, la santé ou l’étude des comportements socioculturels. Cependant, le mobile crowdsensing n’en n’est qu’à ses premiers stades de développement, et de nombreux défis doivent encore être relevés pour pleinement profiter de son potentiel. Ces défis incluent la protection de la vie privée des utilisateurs, les ressources énergétiques limitées des terminaux mobiles, la mise en place de modèles de récompense et de déploiement adaptés pour recruter les utilisateurs les plus à même de collecter les données désirées, ainsi que faire face à l’hétérogénéité des plateformes mobiles disponibles. Dans cette thèse, nous avons cherché à réétudier les architectures des systèmes dédiés au mobile crowdsensing pour adresser les limitations liées au développement, au déploiement et à l’exécution de campagnes de collecte de données. Les différentes contributions proposées sont articulées autour APISENSE®, la plate-forme résultante des travaux de cette thèse. Plus particulièrement, APISENSE® propose un environnement distribué favorisant le développement et le déploiement rapides de campagnes de collecte, tout en prenant en considération des contraintes telles que la protection de la vie privée des utilisateurs ou encore les ressources énergétiques limitées de leurs terminaux. Pour atteindre ces objectifs, APISENSE® repose sur le modèle de composant SCA et sur l’ingénierie des lignes de produits logiciels, offrant ainsi un environnement modulaire et facilement configurable pour supporter une grande diversité de campagnes de collecte. Un modèle de programmation de haut niveau a également été proposé permettant de s’affranchir de toute la complexité liée aux développements d’applications de collecte mobiles. APISENSE® a été utilisé pour réaliser une campagne de collecte de données déployée auprès d’une centaine d’utilisateurs au sein d’une étude sociologique, et évalué à travers des expériences qui démontrent la validité, l’efficacité et le passage à échelle de notre solution. iiiA B S T R A C T Mobile crowdsensing is a new form of data collection that takes advantage of millions smart devices already deployed throughout the world to collect massively environmental or behavioral data from a population. Recently, this type of data collection has attracted interest from a large number of industrials and academic players in many areas, such as the study of urban mobility, environmental monitoring, health or the study of sociocultural attitudes. However, mobile crowdsensing is in its early stages of development, and many challenges remain to be addressed to take full advantage of its potential. These challenges include privacy, limited energy resources of devices, development of reward and recruitment models to select appropriates mobile users and dealing with heterogeneity of mobile platforms available. In this thesis, we aim to reconsider the architectural design of current mobile crowdsensing systems to provide a simple and effective way to design, deploy and manage data collection campaigns. The main contributions of this thesis are organize around APISENSE®, the resulting platform of this research. In particular, APISENSE® offers a distributed environment based on the SCA component model and software product line engineering , providing a modular and flexible environment to support a wide variety of data collection campaigns. Futhemore, APISENSE® takes into account constraints, such as protecting the privacy of users or limited energy resources devices. We also propose a high-level programming model to get rid of the complexity associated with the development of mobile data collection applications. APISENSE® has been used to carry out a data collection campaign deployed over hundred of users in a sociological study and evaluated through experiments demonstrating the validity, effectiveness and scalability of our solution. vTA B L E D E S M AT I È R E S 1 introduction 9 1.1 Contexte 9 1.2 Problématiques 10 1.3 Objectif du manuscrit 12 1.4 Contributions 13 1.5 Plan du manuscrit 15 1.6 Publications 16 I État de l’art 19 2 systèmes de collecte de données 21 2.1 Mobile crowdsensing 22 2.1.1 Qu’est ce que le Mobile crowdsensing ? 22 2.1.2 Classification des applications 23 2.1.3 Discussion 27 2.2 Les challenges clés du Mobile crowdsensing 28 2.2.1 Sécurité et Vie privée 28 2.2.2 Gestion des ressources 29 2.2.3 Hétérogénéité des équipements et des OS 30 2.2.4 Diffusion et passage à l’échelle des applications 31 2.2.5 Implication et incitation des usagers 32 2.2.6 Discussion 33 2.3 Travaux connexes 34 2.3.1 Funf Open Sensing Framework 34 2.3.2 MyExperience : A System for In situ Tracing and Capturing of User Feedback on Mobile Phones 36 2.3.3 Medusa : A programming framework for crowd-sensing applications 38 2.3.4 PRISM : Platform for Remote Sensing using Smartphones 42 2.3.5 Bubble-sensing 45 2.3.6 Pogo, a Middleware for Mobile Phone Sensing 46 12.3.7 AnonySense : A System for Anonymous Opportunistic Sensing 48 2.4 Synthèse et conclusion 49 II Contributions 53 3 collecte mobile de données 55 3.1 Introduction 55 3.2 Considérations et objectifs de conception 57 3.3 Langage de programmation des collectes 59 3.3.1 Concept de l’interface de programmation 60 3.3.2 Collecte de données dirigée par les évènements 60 3.3.3 Les actions 64 3.4 Intergiciel de collecte 68 3.4.1 Couche d’exécution 68 3.4.2 Couche de contrôle 72 3.4.3 Couche d’interaction 74 3.5 Évaluation du prototype 78 3.5.1 Quelques exemples de collectes 79 3.5.2 Coût énergétique d’une expérience de collecte 87 3.6 Conclusion 88 4 collecte répartie de données 91 4.1 Introduction 91 4.2 Infrastructure répartie de traitement des données 92 4.3 Architecture du serveur central 94 4.3.1 L’enregistrement des participants 95 4.3.2 L’enregistrement des expériences de collecte 96 4.3.3 Déploiement des tâches de collecte 98 4.3.4 Gestion des nœuds de collecte 99 4.4 Architecture des noeuds de collecte 100 4.4.1 Modèle de caractèristiques d’une campagne de collecte 101 4.4.2 Création d’une nouvelle campagne 107 4.4.3 Intéraction entre les composants 110 4.4.4 Extension des nœuds de collecte 112 4.5 Campagne de collecte communautaire 113 24.5.1 Extension du modèle de programmation 116 4.5.2 Coordonner l’exécution des tâches de collecte 119 4.6 Conclusion 124 III Évaluations 127 5 pratiques culturelles et usages de l’informatique connectée 129 5.1 Introduction 130 5.2 Contexte et objectif de l’étude PRACTIC 130 5.3 Développement de l’étude PRACTIC 131 5.3.1 Collecte opportuniste 132 5.3.2 Collecte participative 135 5.3.3 Retour utilisateur 136 5.3.4 Discussions 136 5.4 Déploiement de l’étude PRACTIC 139 5.4.1 Protocole du déploiement 139 5.4.2 Participation 140 5.5 Conclusion 143 6 évaluation du modèle collaboratif 145 6.1 Introduction 145 6.2 Mise en place de l’expérience 145 6.3 Résultats 148 6.3.1 Quantité de données et couverture géographique 148 6.3.2 Consommation énergétique 151 6.4 Conclusion 154 IV Conclusion 157 7 conclusion 159 7.1 Rappel des motivations 159 7.2 Rappel des contributions 160 7.2.1 Collecte mobile de données 160 7.2.2 Collecte répartie de données 161 7.3 Perspectives 162 3bibliographie 165 4TA B L E D E S F I G U R E S Figure 1 Vue d’ensemble de APISENSE® 15 Figure 2 Développement d’une application mobile avec FunfInABox 35 Figure 3 Architecture de Medusa [55] 41 Figure 4 Architecture de PRISM [16] 44 Figure 5 Architecture de Bubble-sensing [45] 45 Figure 6 Architecture de Anonysense [62] 48 Figure 7 Tableau comparatif des plate-formes MCS 52 Figure 8 Interface de Programmation APISENSE 61 Figure 9 Exemple de capture d’écran d’un retour utilisateur 67 Figure 10 Architecture de l’intergiciel mobile 69 Figure 11 Interaction de la couche d’exécution 69 Figure 12 Règles de confidentialité 75 Figure 13 Exemple de contenu web disponible via le FeedbackManager 78 Figure 14 Flux de données de l’expérience Manipulation de Lego NXT 82 Figure 15 Impact d’APISENSE sur la consommation énergétique 88 Figure 16 Impact des capteurs sur la consommation énergétique 89 Figure 17 Vue d’ensemble d’APISENSE® 93 Figure 18 Architecture SCA du serveur central 96 Figure 19 Modèle de caractéristiques d’une campagne de collecte 102 Figure 20 Architecture initiale d’un nœud de collecte 107 Figure 21 Processus de génération d’une architecture SCA 108 Figure 22 Architecture SCA d’une campagne de collecte 109 Figure 23 Interaction des composants APISENSE® 111 Figure 24 Exemple d’extension : Export des données au format KML 114 Figure 25 Composant SCA responsable du recrutement collaboratif 120 Figure 26 Distribution des capteurs virtuels 121 Figure 27 Données collectées par l’étude PRACTIC 132 Figure 28 Exemple de retour utilisateur PRACTIC 137 Figure 29 Gain en terme de lignes de code obtenu grâce à APISENSE® pour le développement de l’étude PRACTIC 138 5Figure 30 Nombre d’inscriptions par jour à PRACTIC 140 Figure 31 Diversité des équipements mobiles 141 Figure 32 Taux de participation à la collecte opportuniste 141 Figure 33 Taux de participation à la collecte participative et opportuniste 142 Figure 34 Représentation des sessions d’allumage de l’écran du terminal d’un participant cumulées au cours de 40 jours 142 Figure 35 Architecture du simulateur de traces de mobilité 147 Figure 36 Comparaison de la quantité de données collectées en fonction du nombre de dispositifs mobiles et de l’objectif de couverture géographique 149 Figure 37 Comparaison de la couverture géographique selon différentes périodes de la journée 150 Figure 38 Comparaison des moyennes de la consommation énergétique en fonction de la concentration de dispositifs mobiles dans la zone de collecte 152 Figure 39 Répartition des charges énergétiques suivant les approches : (a) individuelle, (b) collaborative avec une objectif de couverture de 1000 m 2 , (c) collaborative avec un objectif de couverture de 500 m2 153 6L I S T E D E S TA B L E A U X Table 1 Liste des fonctions d’observation d’événements prédéfinis. 61 Table 2 Liste des paramètres d’une fonction de rappel 61 Table 3 Configuration de l’observation de la position d’un utilisateur 62 Table 4 Liste des fonctions d’un objet de souscription 64 Table 5 Liste des fonctions de la façade de collecte 65 Table 6 Liste des fonctions de la façade dédiée à la création des questionnaires 66 Table 7 Exemples de tâches de collecte implémentées avec APISENSE. (*Lignes de code) 80 Table 8 Tableau décrivant la qualité du système de classification 85 Table 9 Comparaison de l’expressivité et du nombre de lignes de code 87 Table 10 Propriétés définissant une expérience de collecte 97 Table 11 Interface de programmation dédiée à la définition des campagnes de collecte communautaires. 116 Table 12 Façade utilisée pour les besoins de l’application PRACTIC 138 71 I N T R O D U C T I O N 1.1 contexte La dernière génération de terminaux intelligents tels que les smartphones ou les tablettes tactiles est rapidement devenue omniprésente dans notre quotidien. On recense, actuellement, plus d’un milliard de smartphones à travers le monde et ce nombre ne va cesser d’augmenter [42]. Non seulement dotés d’une grande capacité de calcul et d’une connexion Internet en continu, ces terminaux sont désormais programmables et équipés d’un grand nombre de capteurs sophistiqués permettant de prendre des images, capter des sons, mesurer la température ou la pression atmosphérique tout en donnant la position géographique. De ce fait, leurs usages permettent de générer de nombreuses traces numériques d’activités, capables d’identifier nos habitudes, nos relations sociales ainsi que l’environnement dans lequel on évolue. De par leurs fortes présences dans notre société et leurs hautes prouesses technologiques, ces terminaux ont ouvert la voie à une nouvelle forme de collecte de données à grande échelle, récemment appelée le Mobile Crowd Sensing (MCS) [27]. Plus particulièrement, le MCS fait référence à l’ensemble des applications qui impliquent des citoyens ordinaires, munis de leurs terminaux intelligents, afin de collecter et de partager des données dans le but de mesurer des phénomènes d’un intérêt commun. Ces dernières années, de nombreuses recherches ont été menées pour tenter d’exploiter le potentiel du MCS dans de nombreux domaines tels que l’étude de la mobilité urbaine ou des comportements sociaux, la surveillance de l’environnement ou la santé [39, 11]. Quelques exemples d’applications novatrices dans ce secteur comprennent la collecte et le partage de données concernant la qualité de l’air [19], le trafic routier [51], la pollution sonore [47], les performances cyclistes [20], ou encore des informations relatives aux prix des produits de consommation [17]. 91.2 problématiques Comme la revue de la littérature l’indique, le MCS n’en n’est qu’à ses premiers stades de développement, et de nombreux défis doivent encore être relevés pour pleinement profiter de son potentiel [39, 27, 66]. Ces défis sont particulièrement liés à l’implication d’individus rationnels, qui sont au centre du système de collecte de données. Cela demande de prendre en considération de nombreux aspects non-fonctionnels qui ne sont pas directement liés à la collecte de données difficiles en elle-même, rendant par conséquent le développement de ces systèmes encore difficile. Plus particulièrement, il est nécessaire de prendre en compte les points suivants : énergie : Bien que la dernière génération des terminaux intelligents continue de fournir plus de puissance de calcul, de mémoire, d’espace de stockage et de capteurs de plus en plus sophistiqués, les ressources énergétiques de ces terminaux restent limitées. Sans une gestion rigoureuse de l’énergie consommée par les applications de collecte, la batterie de ces terminaux peut s’épuiser en quelques heures, décourageant ainsi les individus à installer ces applications. respect de la vie privée : Sans un mécanisme de protection approprié, les applications mobiles peuvent se devenir de parfaits espions, en révélant potentiellement des informations privées sur leur propriétaire. Il est par exemple possible qu’elles puissent enregistrer des conversations intimes ou prendre des photos d’une scène privée, d’identifier des trajets quotidiennement empruntés par le propriétaire du terminal et d’observer ses principaux lieux de vie tels que son domicile ou son lieu de travail. Ce point représente également un frein majeur pour l’acceptation de ces applications par les individus. D’un autre coté, certaines de ces données peuvent se révéler indispensables pour l’objectif de la collecte de données. compromis : Prendre en compte ces deux derniers points demande généralement le développement d’algorithmes sophistiqués permettant de faire un compromis entre l’énergie consommée par les applications mobiles, leur niveau d’intrusion dans la vie privée des individus et la qualité des données collectées. diversité : De plus, les développeurs doivent également faire face à la diversité des systèmes d’exploitations mobiles disponibles sur le marché (par ex. Android, iOS). Pour déployer une application auprès d’un grand nombre d’individus, les développeurs doivent généralement étudier et développer une application pour chacun de ces systèmes, entraînant par conséquent un coût important (c.-à-d. temps de développement, monétaire). 10passage á l’échelle : Finalement, ces systèmes doivent également faire face au défi de collecter une grande quantité de données reportées par des utilisateurs répartis à travers le monde. De ce fait, déployer une application auprès de plusieurs millions d’utilisateurs qui collectent et propagent continuellement des données vers un serveur serait inefficace, et demanderait des ressources importantes en terme de CPU, de mémoire et d’espace de stockage de l’infrastructure hébergeant l’application serveur pour stocker et analyser ces données. En outre, ces applications peuvent générer un lot considérable de données qui peuvent être inutiles, surtout si la collecte vise uniquement une région spécifique ou une population particulière. Dans ce contexte, il est nécessaire de mettre en place un modèle de déploiement adapté pour recruter les bons utilisateurs au bon moment, capable de collecter seulement les données utiles à la campagne de collecte. À ce jour, beaucoup d’efforts ont principalement portés sur la réalisation de systèmes monolithiques, difficilement réutilisables dans un contexte non anticipé [6]. Ces systèmes ont été conçus complètement indépendamment les uns des autres, ne partageant aucun module logiciel commun, alors qu’ils ont à faire face à des problématiques communes. La mise en place d’une nouvelle campagne de collecte demande généralement de développer un nouveau système à partir de zéro, pouvant entraîner la négligence de certains aspects non fonctionnels, comme protéger la vie privée des individus, à cause de contrainte de temps ou une expertise limitée dans ce domaine. Ce manque d’approche réutilisable, également pointé du doigt dans la littérature [39, 27, 60, 66], entrave ainsi l’adoption du MCS par de nombreux acteurs intéressés par ce type de collecte. Dans cette thèse, nous avons cherché à réétudier les architectures des systèmes dédiées au MCS pour adresser les limitations identifiées ci-dessus liées au développement, au déploiement et à l’exécution d’une campagne de collecte de données. Plus particulièrement, l’objectif des travaux de cette thèse est de proposer une plate-forme générique, favorisant le développement et le déploiement rapides de campagnes de collecte de données pouvant être menées dans une grande variété de domaines. 111.3 objectif du manuscrit Comme nous l’avons décrit dans la section précédente, le développement d’applications utilisant le MCS comme source de collecte de données est une tâche complexe, nécessitant une grande expertise. Toutefois, pour ouvrir cette forme de collecte à de nombreux acteurs académiques et industriels, nous proposons dans cette thèse une plate-forme générique qui facilite le développement et le déploiement de ces applications de collecte. Plus particulièrement, nous adressons dans cette thèse les points suivants : Simplifier le développement des applications de collecte Le premier défi concerne le développement des applications de collecte. Actuellement, ce développement nécessite une grande expertise dans les systèmes d’exploitation des terminaux mobiles disponibles sur le marché. Pour simplifier leur développement, il est nécessaire de proposer un modèle de programmation nouveau fournissant une abstraction complète de ces systèmes d’exploitation. Dans ce contexte, les principaux défis sont de proposer un modèle : i) assez général pour supporter une grande variété d’activités de collecte qui peuvent impliquer une grande variété de capteurs, ii) permettant de minimiser l’expertise nécessaire dans les technologies mobiles afin d’accéder aux fonctionnalités offertes par les capteurs des terminaux mobiles, ainsi que leurs collectes et leurs propagations vers l’infrastructure serveur, iii) et finalement portable pour être en mesure de s’exécuter sur les différents systèmes d’exploitation. D’autre part, il est nécessaire de fournir un environnement fiable assurant la confidentialité des utilisateurs, efficace pour ne pas empêcher une utilisation normale des terminaux mobiles et faciles d’utilisation pour les utilisateurs voulant participer aux collectes de données. Mise en œuvre d’une plate-forme générique de collecte de données Le deuxième défi concerne l’architecture de la plate-forme responsable du déploiement des applications de collecte, de la persistance et de l’analyse des données collectées. La plupart des plate-formes proposées actuellement sont souvent monolithiques, donnant très peu ou pas de possibilités de personnalisation. Cependant, les applications de collectes peuvent être menées dans une grande variété de domaines, nécessitant diffé- 12rents services de l’application serveur pour analyser et stocker les données collectées ou encore déployer ces applications. Pour prendre en compte cette diversité, la flexibilité et l’extensibilité doivent être les propriétés clés de l’architecture mise en œuvre. Cela demande par conséquent de proposer un modèle identifiant les points communs et les différentes exigences des applications de collecte qui peuvent être réalisées. Ce modèle doit s’appuyer sur les bonnes pratiques de l’ingénierie logiciel pour fournir un cadre logiciel modulaire et configurable, et être utilisé simplement par les différents acteurs voulant mener de nouvelles collectes de données pour leurs permettre d’exprimer leurs exigences. D’autre part, la plate-forme doit être capable de passer à l’échelle, c’est-à-dire d’être capable d’impliquer un grand nombre d’utilisateurs mobiles ainsi qu’un grand nombre d’acteurs voulant définir de nouvelles collectes d’un grand volume de données. 1.4 contributions En réponse à ces défis, ces travaux ont abouti à la définition, l’implémentation et l’évaluation d’une plate-forme baptisée APISENSE®. La finalité de APISENSE® est de permettre une mise en place rapide de campagnes de collectes de données à travers des terminaux mobiles intelligents. Nous proposons ici une vue d’ensemble de la solution proposée illustrée par la figure 1. APISENSE® distingue deux rôles évoluant dans la plate-forme. Le premier, appelé simplement utilisateur, peut être un acteur voulant définir et déployer de nouvelles campagnes de collecte de données à travers des terminaux mobiles. Les utilisateurs peuvent utiliser un nœud de collecte dédié (DataGathering Node), qui peut être déployé sur une infrastructure publique ou privée selon leur exigence, et se servir des services fournis par celui-ci pour définir de nouvelles tâches de collecte grâce à un langage de script dédié, déployer la tâche à travers un sous-ensemble d’individus ainsi qu’exploiter ou exposer les données collectées (par ex. visualisation, analyse). Le second rôle, appelé participant, est un individu possédant un terminal mobile. Les participants peuvent utiliser une application mobile dédiée pour télécharger les tâches de collecte, les exécuter dans un environnement sécurisé et automatiquement propager les données collectées. Dans APISENSE®, la mise en relation entre les nœuds de collecte et les participants est assurée par le serveur central (Central Server). Dans un sens, le serveur central peut être perçu comme un magasin dédié aux tâches de collecte. Typiquement, son rôle est 13d’assurer le déploiement des tâches de collecte soumises par les nœuds de collecte, et également d’assurer une première couche d’anonymat des participants. Les objectifs présentés dans la section précédente sont adressés avec APISENSE® de la manière suivante : • À l’issue d’une étude approfondie des architectures présentées dans la littérature (cf. chapitre 2 section 2.3), nous avons proposé un modèle permettant de représenter la variabilité des systèmes responsables du développement et du déploiement de campagnes de collectes de données (cf. chapitre 3 section 4.4). Ce modèle est ensuite fourni aux utilisateurs leur permettant de définir des exigences selon la spécificité des campagnes qu’ils veulent mener. Une application serveur dédiée (c.-à-d. DataGathering Node dans la figure 1) est ensuite générée suite aux exigences définies, fournissant un ensemble de services permettant de développer et de déployer de nouvelles campagnes de collecte, d’assurer la persistance des données collectées par les dispositifs mobiles ainsi que de connecter des services additionnels pour extraire ou traiter ces données. • Nous avons défini un modèle de programmation de haut niveau permettant de s’affranchir de toute la complexité liée aux développements mobiles. Basée sur un langage de script, cette abstraction a été conçue pour être assez générale pour supporter une grande variété d’applications de collecte, facilement accessible pour des utilisateurs ayant très peu d’expertise en programmation mobile, et facilement portable pour être exécutée dans différents environnements mobiles (par ex. Android, iOS, Window Mobile)(cf. chapitre 3 section 3.3). • Pour assurer l’exécution des campagnes de collecte définies par notre modèle de programmation, nous proposons un environnement d’exécution dédié aux utilisateurs mobiles. Cet environnement est responsable du téléchargement, de l’exécution des applications de collectes et de la propagation des données collectées (cf. chapitre 3 section 3.4). Principalement, cet environnement met l’accent sur la consommation énergétique liée à l’exécution d’une campagne de collecte et la protection de la vie privée des utilisateurs. • Nous proposons des modèles et des algorithmes dédiés à l’optimisation de l’exécution de campagnes de collecte. L’optimisation proposée réside en deux points. Pour le premier, nous proposons un modèle de déploiement de tâches de collecte contextuel, permettant d’attribuer une application de collecte à un individu en fonction de propriétés temporelles, géographiques et de capacité 14de détection. Pour le second, nous proposons un algorithme permettant de coordonner l’exécution des tâches de collecte, entre les dispositifs répondant aux mêmes propriétés, afin d’équilibrer les coûts énergétiques entre les terminaux et de diminuer la redondance des données collectées(cf. chapitre 4 section 4.5). Figure 1 – Vue d’ensemble de APISENSE® 1.5 plan du manuscrit Ce manuscrit est divisé en quatre parties. La première partie donne une vue d’ensemble de l’état de l’art dans le domaine du Mobile crowdsensing. La seconde partie décrit les contributions de ce manuscrit. La troisième porte sur la validation des contributions proposées. Et finalement la quatrième conclut ce manuscrit et décrit les perspectives issues des travaux de cette thèse. Plus particulièrement, la suite de ce document est organisé comme suit. Partie 1 : État de l’art Chapitre 1 : Systèmes de collecte de données Ce chapitre a pour objectif de donner dans un premier un temps une vison plus approfondie du Mobile crowdsensing ainsi que ses problématiques. Nous décrivons par la suite des travaux proches à ceux proposés dans cette thèse et nous identifions leurs limitations. 15Partie 2 : Contributions Chapitre 3 : Collecte mobile de données Ce chapitre traite de l’environnement mobile de APISENSE®. Il décrit tout d’abord le modèle de programmation proposé permettant de minimiser le coût du développement des applications de collecte de données. Par la suite, il présente l’architecture de l’environnement mobile dédié à l’exécution des applications de collecte. Chapitre 4 : Collecte répartie de données Ce chapitre présente l’architecture et les choix d’implémentation de l’environnement serveur APISENSE® permettant de déployer des applications de collecte ainsi que d’exploiter les données collectées. Partie 3 : Validations Chapitre 5 : Pratiques culturelles et usages de l’informatique connectée Ce chapitre présente une campagne de collecte déployée auprès d’une centaine d’utilisateurs, réalisée au sein d’une étude sociologique nommée PRATIC (Pratiques Culturelles et Usages de l’Informatique Connectée). Chapitre 6 : Performance et efficacité de APISENSE® présente une validation quantitative sur les performances de APISENSE® Partie 4 : Conclusion Chapitre 7 : Conclusion Finalement, ce chapitre conclut ce manuscrit et expose les perspectives des travaux présentés. 1.6 publications Les travaux de cette thèse ont été réalisés au sein de l’équipe SPIRALS commune à Inria et à l’Université Lille 1 au sein de l’UMR LIFL (Laboratoire d’Informatique Fondamentale de Lille). Ils ont donné lieu aux publications scientifiques suivantes. Conférence International • Dynamic Deployment of Sensing Experiments in the Wild Using Smartphones. Nicolas Haderer, Romain Rouvoy and Lionel Seinturier. In 13th International IFIP 16Conference on Distributed Applications and Interoperable Systems (DAIS), pages 43-56. • A Federated Multi-Cloud PaaS Infrastructure. Fawaz Paraiso, Nicolas Haderer, Philippe Merle, Romain Rouvoy, Lionel Seinturier. In 5th IEEE International Conference on Cloud Computing (2012), pages 392-399. Chapitre de livre • A Cloud-based Infrastructure for Crowdsourcing Data from Mobile Devices. Nicolas Haderer, Fawaz Paraiso, Christophe Ribeiro, Philippe Merle, Romain Rouvoy, Lionel Seinturier Wenjun Wu. Cloud-based Software Crowdsourcing, Springer, 2014 (To appear) Workshop • A preliminary investigation of user incentives to leverage crowdsensing activities. Nicolas Haderer, Romain Rouvoy and Lionel Seinturier. 2nd International IEEE PerCom Workshop on Hot Topics in Pervasive Computing (PerHot) (2013), pp. 199-204. • Towards Multi-Cloud Configurations Using Feature Models and Ontologies. Clément Quinton, Nicolas Haderer, Romain Rouvoy and Laurence Duchien. In Proceedings of the 1st International Workshop on Multi-Cloud Applications and Federated Clouds, Multi-Cloud’13. Prague, Czech Republic, 22 April 2013, pp. 21-26. Vulgarisation scientifique • APISENSE : Crowd-Sensing Made Easy. Nicolas Haderer, Romain Rouvoy, Christophe Ribeiro, Lionel Seinturier. ERCIM News, ERCIM, 2013, Special theme : Mobile Computing, 93, pp. 28-29. • Le capteur, c’est vous ! Nicolas Haderer, Christophe Ribeiro, Romain Rouvoy, Simon Charneau, Vassili Rivron, Alan Ouakrat, Sonia Ben Mokhtar, Lionel Seinturier L’Usine Nouvelle, L’Usine Nouvelle, 2013, 3353, pp. 74-75 • Campagne de collecte de données et vie privée. Nicolas Haderer, Miguel Nuñez Del Prado Cortez, Romain Rouvoy, Marc-Olivier Killijian and Matthieu Roy. 3ème Journées du GDR CNRS GPL (2012), pp. 253-254. Rapport de recherche • AntDroid : A distributed platform for mobile sensing. Nicolas Haderer, Romain Rouvoy, Lionel Seinturier. [Research Report], 2012, pp. 27. RR-7885 17Première partie État de l’art 192 S Y S T ÈM E S D E C O L L E C T E D E D O N N É E S Sommaire 2.1 Mobile crowdsensing 22 2.1.1 Qu’est ce que le Mobile crowdsensing ? 22 2.1.2 Classification des applications 23 2.1.3 Discussion 27 2.2 Les challenges clés du Mobile crowdsensing 28 2.2.1 Sécurité et Vie privée 28 2.2.2 Gestion des ressources 29 2.2.3 Hétérogénéité des équipements et des OS 30 2.2.4 Diffusion et passage à l’échelle des applications 31 2.2.5 Implication et incitation des usagers 32 2.2.6 Discussion 33 2.3 Travaux connexes 34 2.3.1 Funf Open Sensing Framework 34 2.3.2 MyExperience : A System for In situ Tracing and Capturing of User Feedback on Mobile Phones 36 2.3.3 Medusa : A programming framework for crowd-sensing applications 38 2.3.4 PRISM : Platform for Remote Sensing using Smartphones 42 2.3.5 Bubble-sensing 45 2.3.6 Pogo, a Middleware for Mobile Phone Sensing 46 2.3.7 AnonySense : A System for Anonymous Opportunistic Sensing 48 2.4 Synthèse et conclusion 49 212.1 mobile crowdsensing 2.1.1 Qu’est ce que le Mobile crowdsensing ? En 2010, Ganti et al. définissent le Mobile crowdsensing comme la participation d’un groupe d’individus, disposant de terminaux mobiles intelligents qui, collectivement, partagent des informations pour la mesure ou la cartographie de phénomènes d’un intérêt commun". Typiquement, le MCS offre de nombreux avantages par rapport aux méthodes classiques de collecte de données telles que les réseaux de capteurs (WSNs), qui peuvent impliquer des coûts importants liés à l’installation d’un grand nombre de capteurs statiques et de leurs maintenances. En effet, des millions de dispositifs mobiles sont déjà déployés dans la nature, portés par des utilisateurs dans leur vie quotidienne. Avec la généralisation des magasins d’applications (par ex. App Store, Google Play), il est désormais possible pour des petites organisations comme des équipes de recherche ou des petites entreprises de rapidement délivrer une application mobile auprès de cette masse d’utilisateurs. Par exemple, au lieu d’installer un ensemble de caméras le long des routes, il est possible de collecter des données du trafic routier et de détecter les embouteillages en utilisant le GPS des dispositifs mobiles des conducteurs. Un autre avantage de l’utilisation de ces dispositifs est le nombre de capteurs multimodaux inclus dans ces appareils, permettant une collecte d’information contextuelle de haut niveau. En effet, le GPS peut fournir la position d’un utilisateur. Le microphone, quand il n’est pas utilisé pour les communications téléphoniques, peut être utilisé comme capteur acoustique. L’accéléromètre peut être, quant à lui, utilisé pour identifier les modes de transport des utilisateurs, leur activité journalière (par ex. temps passé en position assise, à dormir, à marcher, à courir) mais aussi détecter des dégâts importants sur une route. De nouveaux capteurs peuvent également facilement être ajoutés à ceux initialement préinstallés, en utilisant des connexions sans fils comme le Bluetooth pour communiquer entre eux. Quelques exemples sont les bracelets connectés qui peuvent mesurer la fréquence cardiaque 1 d’un individu, ou les capteurs qui mesure la qualité de l’air [19]. Pour finir, le dernier avantage est de pouvoir inclure les utilisateurs dans le processus de collecte, bénéficiant ainsi de l’intelligence humaine pour collecter des données sémantiquement complexes à identifier à partir de simples capteurs. Par exemple, un utilisateur peut facilement identifier la dégradation d’installations 1. http://pulseon.fi/ 22publiques, prendre une photo de ces dégâts et l’envoyer à la collectivité territoriale concernée [35]. Grâce à ces avantages, le MCS a suscité l’intérêt d’un grand nombre d’acteurs industriels et académiques dans des domaines tels que l’étude de la mobilité urbaine ou des comportements sociaux, la surveillance de l’environnement et la santé [39, 11]. Cependant, l’utilisation des dispositifs mobiles possédés par des individus introduit également de nouvelles problématiques, comme la préservation de la vie privée des utilisateurs, la grande consommation énergétique des applications de collecte ou alors comment inciter les utilisateurs à installer et exécuter ces applications. Dans la suite de cette section, nous présentons tout d’abord une vue d’ensemble de ces applications avant de décrire avec plus de précision ces problématiques. 2.1.2 Classification des applications Dans la littérature, il existe un grand nombre d’applications de collecte de données, mettant en évidence l’utilisation du MCS dans une grande variété de domaines. Globalement, ces applications peuvent être classées selon deux critères : le sujet à observer et le mode d’acquisition des données. Le classement selon le sujet à observer se scinde, lui encore, en deux dimensions : les applications de collecte personnelle et les applications de collecte communautaire. Les applications de collecte personnelle visent à observer et analyser le comportement d’un individu (e.g., activité physique, mode de transport), tandis que les applications de collecte communautaire visent à observer des phénomènes (à plus grande échelle) sur l’environnement (par ex. qualité réseaux, pollution atmosphérique ou sonore) ou sur une infrastructure publique (e.g., trafic routier, place de parking disponible, dégâts de matériel public). Le classement selon le mode d’acquisition de données peut également se scinder en deux modalités appelées : collecte participative et collecte opportuniste. Dans la collecte participative, l’utilisateur est directement impliqué dans la prise de décision de la collecte (i.e., en décidant quand, comment et quelles données doivent être collectées). Au contraire, dans la collecte opportuniste, elle est complètement automatisée par l’application, sans nécessiter une intervention de l’utilisateur. 23Collecte personnelle ou communautaire Dans les systèmes de collecte personnelle, l’ objectif est d’observer des phénomènes liés à un individu. Dans ce type de système, toutes les données collectées sont géné- ralement couplées avec un identifiant unique, permettant de suivre l’évolution d’un utilisateur spécifique à travers le temps. Elles sont généralement rendues à l’utilisateur sous forme d’un rapport détaillé sur son activité, partagées à travers un réseau social ou alors agrégées à travers plusieurs utilisateurs afin d’identifier divers comportements. Ce type de collecte est généralement utilisé dans les domaines de la santé, du sport ou de l’environnement. Dans le domaine de l’environnement par exemple, PEIR [51](Personal Environmental Impact Report) est un système permettant aux utilisateurs de se servir de leurs dispositifs mobiles afin de déterminer leur exposition aux polluants présents dans leur environnement. PEIR collecte continuellement les données GPS vers un serveur pour y effectuer une série de traitement consistant à segmenter les différents déplacements des utilisateurs, identifier les modes de transports (par ex. bus, voiture) et calculer la quantité de gaz carbonique émise lors des déplacements. Pour le calcul de l’émission du gaz carbonique, PEIR couple les informations des déplacements avec plusieurs bases de données : celles des principales entreprises polluantes, et celles de la météo et du trafic routier. Sur un site Internet spécifique, les utilisateurs peuvent ensuite consulter les rapports de leurs déplacements, les aidants à modifier leurs comportements et protéger leur santé. Dans le domaine du sport, BikeNet [20] fournit aux cyclistes une application leur permettant de mesurer leurs expériences sportives. BikeNet combine les données du GPS et de l’accéléromètre pour calculer la vitesse, les calories perdues ainsi que la qualité des routes empruntées. Les données collectées peuvent être visualisées par les cyclistes eux-mêmes, ou être agrégées avec d’autres utilisateurs afin de construire une carte complète des pistes cyclables. Les systèmes de collecte personnelle sont également beaucoup utilisés dans le cadre d’expériences scientifiques. Par exemple, EmotionSense [56] est un système dédié aux études de psychologie sociale. Il tente d’établir une relation entre le bien-être d’un utilisateur et ses interactions sociales ou ses activités. Pour identifier ces informations, EmotionSense analyse continuellement trois types d’informations. Premièrement, les conversations téléphoniques des utilisateurs pour mesurer leurs émotions durant leurs appels. Deuxièmement, les périphériques Bluetooth voisins pour identifier les 24personnes se trouvant régulièrement à proximité. Et finalement l’accéléromètre pour identifier l’activité régulière de l’utilisateur. Dans un autre contexte, HealthAware [28] est une application visant à observer l’obésité des utilisateurs. Avec cette application, les utilisateurs peuvent prendre en photo leur nourriture, ce qui permet au système de leur fournir en retour des informations sanitaires complémentaires sur cette nourriture. HealthAware collecte également les données de l’accéléromètre pour mesurer l’activité physique quotidienne des utilisateurs. Le système fournit en retour un rapport complet sur l’activité effectuée, et rappelle aux utilisateurs l’importance de garder une activité physique quotidienne pour être en bonne santé. Les systèmes de collecte communautaire visent, quant à eux, à observer des phénomènes à plus grande échelle, sur l’environnement ou sur des infrastructures publiques afin d’améliorer la vie d’une communauté (par ex. toutes les personnes habitant dans une ville, les étudiants d’une université). Quelques scénarios types de ce genre de collecte comprennent la mesure de la pollution atmosphérique en milieu urbain, ou l’observation des réseaux routiers afin de détecter les embouteillages ou des dégâts importants sur la chaussée. CommonSense [19] est un exemple d’application dédié à l’observation de la pollution atmosphérique. L’application mobile de CommonSense combine les données GPS avec des données fournies par un capteur externe mesurant la qualité de l’air ambiant. La communication entre le mobile et le capteur externe est assurée par une connexion Bluetooth. Les capteurs externes ainsi que l’application sont déployés auprès de la population, qui collectivement propage leurs positions ainsi que la qualité de l’air vers un serveur. Les données sont ensuite agrégées et peuvent être visualisées sur un site Internet spécifique. Similairement, NoiseTube [47] utilise directement les microphones des dispositifs mobiles pour mesurer la pollution sonore en milieu urbain. Un autre type de collecte communautaire implique la mesure de phénomènes en relation avec des infrastructures publiques. Par exemple, Nericell [50] est un projet qui a pour objectif de mesurer différents phénomènes issus du trafic routier. Ce projet analyse continuellement la position d’un utilisateur qui, couplée avec les informations issues de l’accéléromètre, permet de détecter la dégradation d’une route ou des freinages d’urgences et, couplée avec le microphone, permet de détecter un fort trafic à partir du bruit ambiant. Dans un autre contexte, LiveCompare [17] est une application qui permet de comparer différents prix d’un même article se trouvant dans des magasins situés à proximité 25d’un utilisateur. Avec cette application, les utilisateurs peuvent se servir de leur dispositif pour prendre en photo le code-barres d’un article. Le code est ensuite décrypté, et envoyé vers un serveur avec la position de l’utilisateur et la photo. En échange, LiveCompare fournit aux utilisateurs les différents prix disponibles pour ce même produit, en fonction des magasins se trouvant à proximité. Un autre exemple d’application est CreekWatcher 2 . Cette application surveille les niveaux et la pollution des eaux, à l’aide des rapports des utilisateurs, comme des photos prises à divers endroits au bord des étendues d’eau, ou des messages texte sur le quantité de déchets. Ces informations peuvent ensuite être exploitées par des commissions de contrôle des eaux. Collecte participative ou opportuniste Indépendant du sujet à observer, un facteur déterminant du succès d’une application est le niveau d’implication des utilisateurs dans le processus de collecte [38]. Typiquement, le processus de collecte peut prendre deux formes appelées collecte opportuniste [39] et participative [7]. Dans celle dite opportuniste, la collecte de données est complètement automatisée par l’application mobile (par ex. "collecter la position toutes les cinq minutes"). Cette approche a le principal avantage de minimiser l’intervention humaine dans le processus de collecte. Cela est particulièrement utile dans le cadre d’une collecte communautaire, permettant d’assurer la propagation de données régulièrement sur le serveur (sans que l’utilisateur soit contraint à accomplir des tâches quotidiennes sur son dispositif). Cependant, ces applications sont plus difficiles à développer, et consomment également beaucoup de ressources énergétiques. En effet, la difficulté principale pour développer ce type d’application est de déterminer dans quel contexte se trouve le dispositif mobile, afin d’assurer une certaine qualité des données collectées. Par exemple dans l’application NoiseTube [47], qui a pour objectif d’observer la pollution sonore, il est nécessaire de mesurer le niveau sonore uniquement quand le dispositif est hors de la poche ou du sac de l’utilisateur. Dans ce cas, cette issue peut être résolue en utilisant le capteur de lumière, mais par conséquent, nécessite la consommation de ressources plus conséquentes. 2. http://www.ibm.com/smarterplanet/us/en/water_management/article/creek_ watch.html 26Au contraire, la collecte dite participative nécessite une plus grande implication de la part des utilisateurs. Par exemple, dans l’application LiveCompare [17], les utilisateurs doivent manuellement prendre une photo du produit qu’ils veulent comparer. Le principal avantage de cette approche est qu’elle permet de bénéficier de l’intelligence humaine pour réaliser des opérations plus complexes. Si nous reprenons l’exemple de application NoiseTube [47], l’approche participative peut permettre de résoudre facilement le problème du contexte du dispositif, en demandant aux utilisateurs de prendre une mesure du niveau sonore manuellement lorsque leur dispositif est hors de leur poche. Cependant, l’inconvénient de cette approche est que la qualité des données, ainsi que la fréquence à laquelle elles sont collectées, dépend fortement de l’enthousiasme des utilisateurs pour l’application. 2.1.3 Discussion Dans cette section, nous avons présenté une vue d’ensemble du MCS, ses principales caractéristiques ainsi que les domaines d’applications utilisant le MCS comme source d’approvisionnement de données. Cependant, jusqu’à ce jour, les applications développées ont principalement été élaborées dans un contexte applicatif spécifique, et difficilement réutilisable. En effet, ces applications ont été conçues complètement indé- pendamment des unes des autres, ne partageant aucun module logiciel commun, alors qu’elles ont à faire face à des problématiques communes. Ce manque de solutions réutilisables, largement pointé du doigt dans la littérature ces dernières années [39, 27, 60, 66], rend non seulement le développement d’une application spécifique difficile, mais il y a aussi la problématique du recrutement des participants qui doit être repris de zéro pour chaque application. Avec la popularité croissante du MCS dans de nombreuses communautés scienti- fiques, fournir une plate-forme générique permettant un rapide développement et un déploiement d’une large variété de campagnes de collecte de données devient une nécessité [27]. C’est donc dans cette lignée que s’inscrivent les travaux de cette thèse. Cependant, réaliser une telle plate-forme comporte de nombreux défis, que nous présentons dans la section suivante. 272.2 les challenges clés du mobile crowdsensing Dans cette section, nous identifions les principaux défis à relever afin proposer une plateforme générique dédiée aux développements et aux déploiements de campagne de collecte de données. Principalement, nous identifions cinq défis : Sécurité et vie privée, Gestion des ressources, Hétérogénéité des équipements et des OS, Diffusion et passage à l’échelle de applications, Implication et incitation des usagers. Pour chacun des défis, nous décrivons brièvement la problématique ainsi que les différentes solutions envisagées dans l’état de l’art. 2.2.1 Sécurité et Vie privée Respecter la vie privée des utilisateurs est peut-être la responsabilité la plus fondamentale d’une plate-forme de collecte. Les utilisateurs sont naturellement sensibles aux données collectées sur leurs dispositifs, spécialement si ces informations comprennent leurs localisations, des images sensibles ou alors des communications audios. En effet, de nombreux travaux [36] ont montré que de nombreuses données, même si elles peuvent paraître anodines prises individuellement, peuvent révéler de nombreuses informations sensibles sur les habitudes ou les relations sociales d’un individu lorsqu’elles sont agrégées dans la durée. Par exemple, les données de géolocalisation collectées avec le GPS, couplées avec des données temporelles peuvent être utilisées pour inférer les trajets quotidiens empruntés par un utilisateur, ou encore ses principaux lieux de vies tels que son domicile ou son lieu de travail [26]. Afin de protéger la vie privée des utilisateurs, de nombreuses solutions ont été envisagées dans la littérature. Christin et al. [11] donne une bonne vue d’ensemble des techniques utilisées selon le contexte de la collecte, qu’elle soit personnelle ou communautaire. Typiquement, ces techniques peuvent consister à utiliser un alias pour assurer les communications entre le serveur et le dispositif mobile, à perturber volontairement les données collectées avant de les propager vers le serveur (en modifiant par exemple les coordonnées GPS), à agréger les données entre n utilisateurs partageant des propriétés communes (par ex. n participant situés dans le même quartier), ou alors à échanger alternativement les traces de mobilités entre plusieurs utilisateurs. 28Cependant, bien que ces approches permettent d’assurer une certaine confidentialité des utilisateurs, elles impliquent également une dégradation des données qui sont collectées. Dans ce cas, il est nécessaire de faire un compromis entre qualité et confidentialité. Ce compromis peut être fait en effectuant un maximum de traitement directement dans le dispositif mobile. Par exemple, Nericell [50] adopte cette approche en analysant toutes les données issues de l’accéléromètre et du microphone localement, et propage uniquement des informations de haut niveau sur le serveur (par ex. fort trafic). Une autre solution envisagée par Christin et al. [11] est de laisser la possibilité aux utilisateurs de définir leurs exigences en matière de vie privée. En effet, la notion de vie privée peut énormément varier d’un individu à un autre. Par exemple, certain utilisateur peuvent être retissant à partager leur position contraire à d’autre. Dans ce contexte, il est nécessaire de fournir aux utilisateurs des moyens leur permettant de spécifier les données qu’ils veulent partager, dans quelles circonstances (par ex. temps, position), et surtout dans quel but. 2.2.2 Gestion des ressources Alors que les smartphones continuent de fournir plus de puissance de calcul, de mémoire, d’espace de stockage et de capteurs de plus en plus sophistiqués, les ressources énergétiques de ces dispositifs restent limitées. En effet, certaines applications déployées [49] montrent que la durée de vie de la batterie d’un dispositif, peut être réduite de 20 heures à 6 heures si certaines ressources sont exploitées activement. Par exemple les ressources du CPU pour traiter un grand volume de données (par ex. traitement de données audio), les ressources de certains capteurs comme le GPS, ou encore des ressources de communications (par ex. 3G, WIFI) pour partager en temps réel les données collectées. Un aspect intéressant pour réduire la consommation énergétique de ces applications est la multimodalité de certains capteurs. En effet, cela peut permettre de faire un compromis entre la qualité des données, en terme de fréquence d’échantillonnage et de précision, et le coût énergétique lié à leurs acquisitions. L’exemple le plus courant est l’acquisition de la position d’un utilisateur, qui peut être obtenue soit par le GPS, impliquant une grande coût énergétique, mais fournissant une grande précision (5- 20 mètres), soit par WiFi ou par la triangularisation GSM, qui sont moins précis 29(20-1000 mètres), mais ont une taxe énergétique moins importante. À partir de ce constat, de nombreux travaux ont été proposés dans la littérature, essayant d’alterner l’utilisation de ces différents capteurs pour faire le plus efficacement ce compromis. Par exemple, EnLoc [14] adapte la fréquence d’échantillonnage et les capteurs haute et basse qualité en fonction de la batterie de l’utilisateur. Matador [8] propose également un algorithme adaptatif, mais pour déterminer si l’utilisateur se trouve dans une zone précise. SenseLoc [34] active le GPS uniquement si l’utilisateur se déplace en utilisant l’accéléromètre pour identifier son activité. Cependant, un inconvénient de ces approches est qu’elles ont été conçues pour un contexte applicatif spécifique, et qu’elles ne sont donc pas forcement adaptées pour un autre. De plus, ces approches restent limitées lorsque de multiples applications coexistent dans un même dispositif. Par exemple, les applications dédiées à l’observation de la pollution sonore et du trafic routier nécessitent toutes les deux des données de géolocalisation. Dans ce contexte, ces applications effectuent leurs propres échantillonnages des données GPS, pouvant entraîner une surconsommation énergétique du dispositif mobile. Cela limite ainsi les utilisateurs à participer à un nombre limité d’applications. 2.2.3 Hétérogénéité des équipements et des OS Un autre aspect à prendre en considération est l’hétérogénéité des systèmes d’exploitation et des équipements disponibles. En effet, selon Gartner Inc. 3 , les ventes de smartphones en 2013 ont totalisé plus de 1,8 milliards d’unité, réparties principalement entre trois systèmes d’exploitation (OS), Android 4 avec 78,4% de part de marché, iOS 5 avec 15,6 % et Windows Phone 6 avec 3,2%. Bien que ce marché en pleine effervescence — soit une augmentation 3.5% depuis 2012 —, confirme le potentiel du Mobile crowdsensing pour la collecte de données à grande échelle, cela induit aussi un long processus de développement pour prendre en considération tous ces systèmes d’exploitation. Pour le développement d’une application sur un OS spécifique, un ensemble d’outils et d’APIs sont fournis aux développeurs. Ces APIs sont implémentées généralement dans des langages de programmation différents, par exemple Java pour Android et 3. Gartner Inc. http://www.gartner.com/newsroom/id/2665715 4. Android : http://www.android.com 5. iOS : http://www.apple.com/fr/ios 6. Windows Phone : http://www.windowsphone.com 30Objective-C ou Apple Swift 7 pour iOS. Ceci implique qu’une application développée pour l’un de ces OS est incompatible avec les autres. Par conséquent, cela demande aux développeurs d’étudier et de développer une application spécifique pour chaque OS disponible, afin de pouvoir impliquer un maximum d’utilisateurs dans le système de collecte. Cette diversité a été soulignée par l’expérience menée par Balan et coll. [4], qui ont mis plus six mois pour le développement et le déploiement d’une expérience de collecte à travers 15,000 taxis à Singapour. Pour faire face à cette hétérogénéité, également identifiée par [60], il est nécessaire de concevoir les applications de collecte dans un langage de haut niveau. Dans ce contexte, le défi consiste à proposer une abstraction assez générale pour supporter le dé- veloppement d’applications variées (opportuniste et participative), qui peut également impliquer une grande variété de capteurs, portables pour supporter la diversité des plate-formes mobiles (c.-à-d. Android, iOS, Windows Mobile), et finalement accessibles pour minimiser l’expertise nécessaire dans les technologies mobiles. 2.2.4 Diffusion et passage à l’échelle des applications La diffusion des applications est un aspect crucial pour assurer le passage à l’échelle d’une plate-forme de collecte. Généralement, la diffusion des applications mobiles est assurée par les magasins traditionnels proposés par les plate-formes mobiles (par ex. Google Play pour Android, Apple Store pour iOS). Cependant, une fois disponible dans un magasin, l’application peut être potentiellement téléchargée par des millions d’utilisateurs à travers le monde. Ces utilisateurs peuvent alors générer un lot considérable de données qui peuvent être inutiles, surtout si la collecte vise uniquement une région spécifique ou une population particulière. De plus, la période de prolifération des mises à jours de ces applications vers les utilisateurs peut prendre plusieurs heures jusqu’à plusieurs jours selon le magasin utilisé (par ex. quelques heures pour Google Play jusqu’à plusieurs heures pour Apple Store). Dans le cadre du MCS, cette période est beaucoup trop longue, spécialement si l’objectif est de collecter des données lors d’un événement ne durant que quelque jours, comme un festival ou une fête nationale. En effet, lors de ces manifestations, après avoir récolté les premières données, il peut s’avérer nécessaire de 7. https://developer.apple.com/swift 31mettre rapidement à jour l’application afin d’améliorer la qualité de la collecte ou de remédier à des défauts de programmation. Dans ce cadre, il est nécessaire de développer de nouveaux mécanismes pour déployer ces applications de collecte [39]. Ces mécanismes devront prendre en compte plusieurs considérations. La première est de maîtriser le déploiement de ces applications vers les participants les plus à même à collecter les données désirées, en limitant le nombre d’utilisateurs impliqués dans la collecte, ou en ne visant qu’une population particulière (par ex. région géographique, tranche d’âge), tout en assurant leurs confidentialités. La deuxième considération est d’assurer un rapide déploiement de leurs mises à jour pour adresser les exigences évolutives liées aux premières données collectées, ou tout simplement pour corriger des erreurs de programmation. La dernière, aussi envisagée par [27, 60], est de permettre de coordonner l’exécution des campagnes à travers plusieurs dispositifs, notamment dans les campagnes de collecte communautaire. En effet, généralement ces applications collectent périodiquement (toutes les x secondes) des données sans prendre en considération si un autre dispositif placé à proximité exécute la même application. Cela peut ainsi entraîner une forte duplication de données collectées, en particulier en milieu urbain où il peut y avoir une forte densité d’utilisateurs. Dans ce contexte, effectuer une coordination entre ces dispositifs pourrait permettre de diminuer la quantité de données redondantes sur le serveur, et également équilibrer les charges énergétiques entre les dispositifs, réduisant ainsi l’énergie globale consommée lors de l’exécution de la campagne. 2.2.5 Implication et incitation des usagers Inévitablement, sans une participation adéquate des utilisateurs, il peut être très difficile d’obtenir la masse de données critique pour l’application. Cependant, comme nous l’avons mentionné dans les sous-sections précédentes, en utilisant une application de collecte, les utilisateurs consomment de nombreuses ressources de leurs dispositifs, et peuvent potentiellement s’exposer à la divulgation d’informations confidentielles. Dans ce contexte, un utilisateur peut ne pas être intéressé à participer à l’application, à moins de recevoir une récompense adaptée. Dans ce contexte, de nombreux travaux ont porté sur la réalisation d’un modèle économique permettant d’attribuer des récompenses financières aux utilisateurs en fonction de leur participation. Ces modèles peuvent être statiques [57], en attribuant 32un prix fixe aux données partagées par les utilisateurs, ou dynamiques [40] en faisant varié le prix des données en fonction de la couverture des premières données partagée, pour inciter par exemple les utilisateurs à se déplacer dans des zones peu couvertes. Cependant, bien que ces modèles puissent favoriser la participation des utilisateurs et améliorer la qualité des données obtenues, collecter des données à grande échelle peut nécessiter un budget considérable, qui n’est pas forcément accessible par exemple pour des équipes de recherche. Dans ce contexte, de nombreux modèles alternatifs, non monétaires, ont été explorés dans la littérature ces dernières années. Ces sources de motivation peuvent par exemple s’inscrire dans le cadre d’une démarche citoyenne ou scientifique en aidant à diminuer l’émission de gaz carbonique dans la nature par exemple [51]. Ces sources peuvent également prendre la forme d’un jeu, en simulant une compétition entre les utilisateurs, en partageant ses performances sur les réseaux sociaux [49], ou en attribuant des récompenses virtuelles. Une dernière source de motivation est d’obtenir un bénéfice direct en partageant des données, par exemple dans l’application LiveCompare [17], les utilisateurs peuvent bénéficier des prix scannés par les autres utilisateurs. 2.2.6 Discussion Le principal objectif d’une plate-forme générique de collecte de données est de permettre la fédération d’une large communauté d’utilisateurs, avec des niveaux d’expertises et des exigences différentes. En effet, les campagnes de collecte de données peuvent être de différents types, qui peuvent être de type communautaire ou personnel, et peuvent également impliquer différents niveaux de participation de la part des utilisateurs (c.-à-d. collecte opportuniste et participative). Comme nous en avons discuté tout au long de cette section, la mise en place d’une campagne demande de faire de nombreux compromis. Que ce soit sur la qualité des données, leur quantité, la préservation de la vie privée des utilisateurs ou encore la consommation énergétique des applications de collecte. Nous avons également vu que dans la littérature, de nombreux modèles ou algorithmes ont été proposés pour adresser ces points. Cependant, aucun de ces modèles ne représente une solution idéale, et ne peut être appliqué seulement dans un contexte applicatif spécifique (par ex. population visée, type de de données collectées). Dans ce contexte, nous pensons que la flexibilité et l’extensibilité doivent être les propriétés clés de l’architecture logicielle d’une plate-forme générique. La flexibilité fait 33référence à la capacité de la plate-forme à s’adapter à la diversité des campagnes de collecte qui peuvent être menées. Cette diversité peut faire référence à différents types de données qui peuvent être collectées (c.-à-d. impliquant de nombreux capteurs), aux technologies utilisées pour les sauvegarder (c.-à-d. base de données), et les structurer (c.-à-d. méthode d’indexation) et les analyser. Quant à l’extensibilité, elle fait référence à la capacité de la plate-forme pour intégrer de nouvelles contributions, afin de faire face aux exigences des utilisateurs non anticipées. Dans ce cadre, la plate-forme pourrait permettre également à des scientifiques travaillant sur une problématique spécifique du MCS (par ex. vie privée, modèle de récompense, etc.), de se focaliser sur leur domaine d’expertise sans avoir à redévelopper un système complet et donc participer à l’amélioration de la plate-forme. Dans la section suivante, nous faisons une étude comparative des différentes plateformes ayant reçu beaucoup d’attention dans la littérature ces dernières années, et ayant ce même objectif. 2.3 travaux connexes Comme nous l’avons vue dans la section précédente, le développement d’application de collecte de données demande de faire face à de nombreux défis. Dans cette section, nous décrivons un certain nombre de travaux existants, proposant des plate-formes ayant pour objectif de simplifier leurs développements et leurs déploiements. Pour chaque travail présenté, nous décrivons brièvement l’architecture générale adoptée, et nous les confrontons par rapport aux défis définis dans la section précédente. 2.3.1 Funf Open Sensing Framework Funf [1] est une plate-forme open source dédié aux développements d’applications de collecte de données mobiles basées sur le système d’exploitation Android. Initialement, Funf a été développé par le MIT Media Lab, afin de proposer aux scientifiques un outil plus générique pour les aider à facilement concevoir leurs applications de collecte. Le concept de base proposé par Funf est appelé Probe. Typiquement, un Probe est un module logiciel (c.-à-d. portion de code Android) assurant la capture de données d’un capteur physique ou logique (par ex. GPS, température, contact). Pour le développement 34des applications, Funf met à disposition un service appelé FunfInABox, accessible via une interface web. L’interface propose un formulaire qui permet aux scientifiques de sélectionner et configurer un ensemble de Probe à inclure dans l’application mobile (cf. figure 2). Le formulaire validé, FunfInABox procède alors à la génération de l’application et de la mettre à disposition des scientifiques à travers un compte Dropbox, un service de stockage et de partage de fichier en ligne. L’application peut également être configurée pour propager périodiquement les données collectées vers le même compte Dropbox, ou sur un serveur HTTP. Pour des raisons de sécurité, toutes les données collectées sont encryptées, et toutes les données sensibles telles que les contacts ou les SMS sont automatiquement hachés. Funf fournit également un ensemble de scripts qui peuvent être utilisés par les scientifiques pour décrypter les données, les insérer dans une base de données relationnelle et visualiser les données. Figure 2 – Développement d’une application mobile avec FunfInABox Funf se diffère principalement par sa simplicité. En effet, l’utilisation d’un formulaire web permet de rapidement développer une nouvelle application sans nécessiter toutes sortes d’expertise en programmation. Cependant, les applications qui peuvent être développées restent très basiques, limitées à la collecte périodique de données brutes de capteurs, et ne supportent pas les interactions avec les utilisateurs. De plus, les applications générées ne proposent pas aux utilisateurs de mécanismes leur permettant de contrôler les données qui sont collectées sur leurs dispositifs ni de retour sur celles-ci. D’autres parts, Funf ne fournissent pas de service spécifique pour aider les utilisateurs à déployer leurs applications vers les dispositifs mobiles. Ils sont alors contraints d’utiliser les magasins d’applications, devant faire face aux problématiques discutées précédemment(cf. section 2.2.4). 352.3.2 MyExperience : A System for In situ Tracing and Capturing of User Feedback on Mobile Phones Jon Froehlich et al. [25] proposent une approche plus flexible pour développer des applications de collecte avec MyExperience. 1 2 3 4 6 7 8 9 14 15 16 17 18 00:30 19 CallQuality 20 21 22 23 25 cellnetwork.png 26 27 Bad 28 Poor 29 Fair 30 Good 31 Excellent 32 33 34 Listing 2.1 – MyExperience : Exemple de configuration de collecte de données MyExperience facilite la définition d’une expérience collecte en proposant une abstraction appelée Sensors Triggers et Actions au-dessus du langage descriptif XML. Dans cette abstraction, les triggers combinent les flux des données fournis par les sensors et une expression logique pour déterminer quand une action doit être déclenchée. 36Pour capturer l’expérience d’un utilisateur, cette abstraction supporte la définition de questionnaires, qui peuvent être présentés à l’utilisateur périodiquement, ou après un évènement spécifique. Le listing 2.1 montre par exemple une expérience affichant à un utilisateur un questionnaire lui demandant la qualité de sa communication vocale après un appel téléphonique. Cependant, l’abstraction proposée a plusieurs limitations. La première est que les triggers qui exécutent les actions ne peuvent pas exécuter une seconde action en fonction du résultat de la première. Cela empêche par exemple de déclencher un nouveau questionnaire en fonction des premières réponses fournies. La deuxième concerne l’expressivité de l’abstraction qui reste limitée aux balises XML définies au préalable. Cette limitation par exemple empêche le développement d’algorithmes contextuels complexes (par ex. inférence de l’activité d’un utilisateur) complexe. Et finalement, MyExperience reste limité aux collectes participatives. L’architecture de la plate-forme MyExperience est composée de deux parties spéci- fiques : i) une application mobile Windows Mobile, responsable de de l’exécution des fichiers XML et ii) une application serveur, responsable de la persistance des données collectées. L’application mobile supporte également la propagation automatique des données vers le serveur. La propagation des données est effectuée lorsqu’une connexion réseau est détectée, et utilise le protocole HTTPS pour sécuriser le transfert des données. L’application fournit également une option permettant d’utiliser un algorithme de cryptographie SHA-1 pour hacher les données confidentielles des utilisateurs (par ex. SMS, contacts, numéro de téléphone). Cependant, MyExperience ne fournit pas de mécanisme particulier pour aider les scientifiques à déployer leurs expériences. L’application mobile ne supportant l’exécution que d’une seule expérience, cela empêche par exemple aux scientifiques de bénéficier des applications déjà installées chez les utilisateurs pour déployer leurs propres expériences.Néanmoins, MyExperience fournit plusieurs mécanismes permettant la mis à jours des expériences à distance, en envoyant la nouvelle expérience par SMS ou un message électronique aux utilisateurs concernés. Cependant, cela nécessite que les scientifiques aient connaissance du numéro de télé- phone ou de l’adresse électronique des utilisateurs, ce qui met en péril l’anonymat des utilisateurs. 372.3.3 Medusa : A programming framework for crowd-sensing applications Medusa, présenté par Ra et al. [55], est une plate-forme de programmation et de distribution de tâches de collecte participatives. Medusa s’adresse principalement aux utilisateurs finaux, sans expertise en programmation. Un exemple typique d’application présentée est celui du citoyen journaliste, permettant au journaliste de recruter des citoyens mobiles pour récolter des vidéos et des commentaires d’un évènement spécifique (par ex. accident, feu de forêt). Dans Medusa, la spécification d’une nouvelle tâche consiste à définir une séquence d’actions qui doivent être exécutées par les mobiles. Pour spécifier cette séquence d’actions, Medusa propose MedScript, une abstraction de haut niveau basé sur XML. MedScript propose deux niveaux d’abstractions : les stages et les connecteurs. Les stages permettent de définir une action élémentaire qui doit exécutée par le dispositif. MedScript distingue deux type de stages : i) les stages consistant à extraire des données des capteurs (par ex. GPS, accéléromètre) appelés SPC-Stage, et les stages nécessitant une intervention humaine (par ex. prendre une vidéo, documenté une photo) appelés Hit-Stage. Chaque stage inclut également plusieurs paramètres, comme une date d’expiration, un contexte d’exécution (par ex. région spécifique ou période de la journée) et également inclure une récompense financière pour inciter les utilisateurs à exécuter les stages. Par exemple, le listing 2.2 décrit l’application du citoyen journaliste. Cette application comporte quatre stages et deux connecteurs définissant l’enchaînement suivant : Recruit -> TakePicture -> GetSummary -> UploadData . Le premier stage permet de recruter les utilisateurs, le deuxième demande aux utilisateurs de prendre une photo dans une région spécifique, le troisième demande aux utilisateurs de commenter la photo prise et finalement le dernier permet d’envoyer le commentaire et la photo vers le serveur. 1 2 Citizen-Journalst 3 4 Recruit HIT 5 recruit 6 7 Citizen Journalist Demonstration 8 18:00:00 12/16/2011 9 .05 10

W_WID

3811 12 13 14 GetSummary SPC 15 medusalet_videosummary 16 immediate none 17 18 IMAGE 19

SUMMARY

20 21 22 23 TakePicture SPC 24 medusalet_mediagen 25 location=34.020259|-118.290131|40, user-initiated 26 27 -t image 28

IMAGE

29 30 31 32 UploadData SPC 33 medusalet_uploaddata 34 none textdesc 35 36 SUMMARY 37 38 39 40 41 Recruit 42 TakePicture Hiring 43 44 45 TakePicture 46 GetSummary Hiring 47 48 49 GetSummary 50 UploadData Hiring 51 52 Listing 2.2 – Le journaliste citoyen développé en MedScript language Pour le déploiement des tâches de collecte, l’architecture de Medusa (cf. figure 3) est composé d’un ensemble de service exécuté sur une infrastructure serveur, et une 39application mobile distribuée auprès d’un ensemble d’utilisateurs. Nous décrivons brièvement le rôle de ces composants. Le Interpreter est le point d’entré de Medusa, il accepte les tâches décrites en MedScript, vérifie leur validité et les envoies aux Task Tracker. Le Task Tracker est responsable de coordonner l’exécution des tâches vers les dispositifs mobiles. Pour chaque tâche, le Task Tracker lui associe une instance dédiée responsable du suivie des différents stages associés à la tâche. Dans ce cas, si la tâche doit être exécuté par 50 utilisateurs (c.-à-d. collecter 50 images dans l’exemple présenté), 50 instances seront alors instanciées dans le Task Tracker. Pour chaque stage inclus dans la tâche, l’instance associé à la tâche notifie l’application mobile assignée lui demandant d’exécuter le stage. Une fois le stage complété, l’application mobile alerte le Task Tracker et attend une instruction pour exécuter le stage suivant. Une fois tous les stages terminés, le Task Tracker averti l’initiateur de la tâche et rend les données disponibles dans le Data Repository. Le Worker Manager sert principalement d’interface avec le service Amazon Mechanical Turk (AMT) 8 , qui est utilisé pour la phase de recrutement. Lorsque le Task Tracker instancie une nouvelle tâche, une description de la tâche ainsi que sa rémunération est postée sur le service AMT. Les participants peuvent alors se connecter sur le service AMT avec leur application mobile, et s’inscrire auprès de la tâche qu’il les intéresse. Une fois inscrit, le Worker Manager notifie le Task Tracker, qui peut alors procéder à l’exécution des stages. AMT est également utilisé pour assurer les communications (c.-à-d. par SMS) entre le Task Tracker et les applications mobiles, et la rémunération des utilisateurs. Cette approche permet d’assurer l’anonymat des utilisateurs, dans le sens où Medusa n’a pas besoin de connaître l’identité réelle des utilisateurs pour communiquer avec eux et les récompenser. Le Stage Library représente la partie extensible de Medusa. Chaque stage supporté par MedScript est associé à un exécutable Android stocké dans le Stage Library. Les exécutables sont alors téléchargés par les dispositifs mobiles avant d’exécuter le stage associé. Cette approche permet d’étendre les capacités offertes par MedScript sans avoir à recompiler l’application mobile et la redéployer. L’ Application mobile est composée de deux services appelés StageTracker et MedBox. Le Stage Tracker est responsable des communications entre l’ap- 8. Amazon mechanical turk : https://www.mturk.com 40plication mobile et les services du serveur. Ces communications comprennent le téléchargement des exécutables des différents stages, d’analyser les SMS envoyés par AMT et propager les données vers le serveur. La MedBox est responsable de l’exécution des stages dans le dispositif mobile. Un stage peut être exécuté soit directement après une notification du Stage Tracker, soit en fonction du contexte de l’utilisateur (c.-à-d. zone géographique ou période de la journée). L’application mobile fournit également plusieurs mécanismes pour contrôler les ressources consommées par l’application mobile et assurer la confidentialité des participants. Pour la gestion des ressources, Medusa laisse la possibilité aux participants de définir des limites en terme de CPU, réseau ou mémoire utilisées lors de l’exécution des stages. Pour assurer la confidentialité, l’application mobile demande une confirmation aux utilisateurs avant de propager les données sur le serveur. Cela permet aux utilisateurs de vérifier si les données collectées peuvent être compromettantes vis-à-vis de leurs vies privées. Figure 3 – Architecture de Medusa [55] Medusa propose certains aspects intéressants à l’égard des considérations discutées dans la section précédente. Ces aspects sont l’intégration d’un service tiers comme AMT, pour assurer l’anonymat des utilisateurs, la possibilité d’intégrer des récom- 41penses financières, ou encore proposer une application mobile générique favorisant la participation des utilisateurs à plusieurs tâches de collecte. Cependant Medusa a plusieurs limitations. La première réside lors de la phase de recrutement des utilisateurs. En effet, si nous reprenons l’exemple du citoyen journaliste, il faudrait que, idéalement, seul les utilisateurs se situant à proximité de l’événement couvert par le journaliste, puissent être capables de s’inscrire à la tâche. Or, bien que Medusa supporte la notion de contexte d’exécution (par ex. exécuter un stage dans une zone géographique), celle-ci est interprétée uniquement par l’application mobile après la phase d’enregistrement. Ainsi, de nombreux utilisateurs peuvent s’enregistrer sans qu’ils ne soient à proximité de l’événement visé. Une autre limitation réside dans l’abstraction du modèle de programmation proposé, qui reste limité à la définition de tâche participatives et communautaires. Par exemple, cette abstraction ne permet pas de définir des tâches suivant l’évolution d’un utilisateur à travers une longue période (par ex. "collecter toutes les 5 minutes la position du GPS"). Et finalement, la dernière limitation réside dans les mécanismes d’extension de Medusa. En effet, pour étendre les fonctionnalités offertes par MedScript, les développeurs ont besoin de développer un nouveau module Java compatible Android. Ce mécanisme a deux inconvénients. Le premier concerne la sécurité. En effet, un développeur mal intentionné peut développer un stage envoyant des SMS à l’insu des participants, ou récupérer des données confidentielles (par ex. contacts) et les envoyer vers un service tiers. Et le deuxième rend exclusive Medusa uniquement pour Android, empêchant de faire face à l’hétérogénie des OS mobiles. 2.3.4 PRISM : Platform for Remote Sensing using Smartphones PRISM [16] est une plate-forme adressant particulièrement trois points qui sont la généralité, la sécurité et le passage à l’échelle. Pour adresser la généralité, PRISM propose une application mobile permettant le téléchargement de tâches de collecte écrites en code natif. Cette approche permet de faciliter la réutilisation de code et de donner une totale flexibilité pour le développement de tâches complexes et variés. Dans ce cadre, PRISM supporte le développement de tâche participatives et opportunistes. Néanmoins, cette approche a plusieurs limitations. Premièrement, le développement de code natif demande une grande expertise en programmation et dans les plate-formes mobiles. PRISM ne fournit pas d’API de 42plus haut pour simplifier leurs développements. Deuxièmement, le développement de code natif ne permet pas de faire face à l’hétérogénéité des OS mobiles. Le code développé reste alors exclusivement exécutable par OS mobile supporté par PRISM, en l’occurrence Windows Mobile. Et finalement, permettre à des développeurs tiers de déployer du code natif sur les dispositifs mobiles peut également poser des problèmes de sécurité et de confidentialité vis-à-vis des participants. Pour limiter les problèmes de sécurité, PRISM implémente un mécanisme d’interposition, empêchant les tâches d’accéder à des fonctions critiques de l’appareil. L’application mobile observe également les ressources énergétique et réseaux consommées par les tâches, et stoppe leurs exécutions si elles dépassent une valeur limite. Cela permet de renforcer la sécurité de l’appareil, en évitant que des tâches épuisent totalement la batterie des utilisateurs. Pour permettre aux utilisateur de contrôler les données collectées durant l’exécution des tâches, PRISM fournit un mécanisme de contrôle d’accès comprenant trois niveaux : i) No Sensors empêchant tous accès, ii) Location Only permettant l’accès uniquement aux capteurs de position et All Sensors autorisant tous les accès. En ce qui concerne le passage à l’échelle du système, PRISM propose une approche permettant de maîtriser le déploiement des tâches de collecte à un sous-ensemble d’utilisateurs. La figure 4 décrit l’architecture globale de PRISM comprenant deux parties spécifiques : i) une application mobile pour Window Mobile, responsable de l’exécution des tâches soumise par le serveur, et ii) le serveur PRISM, acceptant des tâches d’applications tierces pour les déployer auprès des applications mobiles. Dans PRISM, le déploiement des taches de collecte est assuré via approche push-based, c’est-à-dire permettant au serveur de pousser les applications directement vers les dispositifs mobiles. Cette approche a le principal avantage d’assurer un déploiement rapide des applications, sans que les utilisateurs soient obligés de se connecter réguliè- rement sur le serveur pour voir si une nouvelle tâche est disponible. Pour permettre aux développeurs de définir un sous-ensemble de dispositifs pour déployer leurs tâches, PRISM fournit une API comportant deux niveaux de raffinements (cf. listing 2.3). 1 // set up the first level coarse-grained predicate 2 L1pred = new FirstLevelPredicate(); 3 L1pred.location = ; 4 L1pred.radius = ; 5 L1pred.stationary = false; 6 L1pred.cameraPresent = true; 7 L1pred.numOfPhones = ; 43Figure 4 – Architecture de PRISM [16] 8 // set up the second level fine-grained predicate 9 L2pred = new SecondLevelPredicate(); 10 L2pred.location = ; 11 L2pred.radius = ; 12 // set up the application with the predicates 13 PRSIMapp = new PRISMApplication(); 14 PRSIMapp.Init(); 15 PRISMapp.SetPredicates(L1pred, L2pred); 16 PRISMapp.SetBinary(); 17 PRISMapp.DistributeToPhones(); 18 // read and process data sent by phones 19 while (appData = PRISMapp.GetData()) { 20 ; 21 } Listing 2.3 – Exemple d’application développée avec PRISM Le premier niveau permet de spécifier les capteurs nécessaires pour exécuter la tâche, le nombre de mobiles désirés et une vaste région géographique. Le deuxième niveau permet quant à lui de définir contexte plus précis (par ex. lorsque l’utilisateur se déplace, se trouve dans une zone précise). Pour être en mesure de déployer les tâches de collecte, PRISM requiert une connaissance complète des dispositifs mobiles ainsi que leurs mobilités. Cette connaissance est assurée par une phase d’enregistrement assurée par les dispositifs mobiles. Lors de l’enregistrement, les dispositifs mobiles 44reportent deux sortes d’informations comprenant des données statiques (par ex. capteurs disponibles) et des informations dynamiques (par ex. position et niveau de batterie restant). Cependant, cela nécessite que les dispositifs envoient constamment leurs positions pour permettre au serveur d’avoir une vision en temps réel de leur répartition. Cela peut causer par conséquent un trafic réseau important si de nombreux dispositifs sont connectés au serveur, et également négliger la confidentialité des utilisateurs. Lorsqu’une nouvelle tâche est soumise au serveur PRISM, celui-ci compare le premier niveau de raffinement avec tous les dispositifs enregistrés au préalable, et la déploie uniquement aux dispositifs correspondants au premier niveau de raffinement. Le deuxième niveau de raffinement sera ensuite interprété par l’application mobile, qui déclenchera l’exécution de la tâche en fonction des contraintes spécifiées. 2.3.5 Bubble-sensing Bubble-sensing [45] est un système dédié aux déploiements de tâches de collecte participative et communautaire. Ce système focalise principale sur les méthodes de dé- ploiements des tâches de collecte qui doivent être exécutées dans une région spécifique. La figure 5 illustre son architecture. Figure 5 – Architecture de Bubble-sensing [45] Dans le modèle proposé par Bubble-sensing, la création d’une tâche est initiée par le dispositif d’un participant (dispositif A dans la figure 5). Le dispositif joue alors le rôle de bubble anchor, et est responsable de la maintenance de la tâche de collecte dans la zone géographique d’intérêt. Une tâche est définie par un tuple : i) action qui définie 45la tâche à réalisé par les participants (par ex. prendre une photo, une vidéo), région qui définie une zone géographique représentant la bulle où la tâche doit être exécutée, et une durée qui définie la date limite ou l’action doit être réalisé. La tâche est disséminée périodiquement, par des communications à courte distance (par ex. Bluetooth, Wifi direct), jusqu’à ce qu’un autre dispositif mobile reçoive et accepte d’exécuter la tâche en question (dispositif C). Les données collectées sont ensuite envoyées sur le bubble-server. Dans le cas ou l’initiateur de la tâche quitte la zone géographique initialement définie, un message est alors disséminé à tous les autres dispositifs se trouvant à proximité. Dans le cas ou un autre dispositif reçoive le message, il devient alors le bubble anchor (dispositif B) responsable de la maintenance de la tâche dans la bulle. En utilisant cette approche, Bubble-sensing permet d’éviter aux dispositifs de reporter continuellement leur position auprès d’une entité centrale. Cependant, cela implique qu’il y est constamment la présence de participants volontaire pour jouer le rôle de bubble-anchor dans la zone géographique d’intérêt, sinon la tâche de collecte serait alors perdu. 2.3.6 Pogo, a Middleware for Mobile Phone Sensing Pogo [6] est une plate-forme proposée par Brouwers et al., qui a pour objectif d’aider les scientifiques à développer et déployer des tâches de collecte à grande échelle. Trois types d’acteurs sont identifiés dans Pogo. Les participants propriétaires des dispositifs mobiles, les scientifiques et un administrateur. Les participants mobiles exécutent une application mobile dédiée, développée pour Android. En installant l’application mobile, les participants acceptent de partager les ressources de leurs dispositifs pour exécuter des tâches développées par les scientifiques. Les scientifiques, quant à eux, peuvent exécuter une application sur leur ordinateur pour développer de nouvelles tâches et les déployer. Et finalement l’administrateur est responsable d’assigner un ensemble de participants aux scientifiques. Cette assignation est effectuée à partir d’un serveur central, qui garde également une trace de tous les dispositifs et des données qu’ils partagent. Cependant, les auteurs donnent très peu d’informations sur cette phase d’assignation, si elle est manuelle ou automatisée. Une fois un participant assigné à un scientifique, Pogo assure le déploiement des tâches par une approche push-based. Cette approche permet d’assurer un rapide déploiement des mises à jour des tâches, mais implique également un manque de transparence sur les données qui sont 46collectées sur les dispositifs des participants ni avec qui ils les partagent. Nous pensons que ce manque de transparence peut freiner leurs participations, surtout qu’aucun mécanisme d’incitation n’est proposé. Dans Pogo, les tâches de collecte peuvent être développées en JavaScript. Pour simplifier le développement des tâches, Pogo propose une abstraction basée sur le pattern publish-subcribe [21], permettant d’effectuer des communications asynchrone entre entre les scripts et les capteurs. La figure 2.4 illustre un exemple de tâches reportant toutes les minutes les points d’accès WiFi sur les ordinateurs des scientifiques. Comparée aux approches précédentes, l’utilisation du JavaScript comporte de nombreux avantages. Tout d’abord, cela permet de bénéficier de l’expressivité d’un langage générale, permettant ainsi de définir des algorithmes contextuels complexes. Ensuite, l’utilisation du JavaScript permet également de favoriser la réutilisation de code. Et finalement de nombreux projet open sources proposent des moteurs d’exécutions pour l’exécution de code JavaScript sur Android 9 , iOS 10 ou Window Mobile 11, permettant d’assurer la portabilité du code développée vers diverses plate-formes. Cependant, l’abstraction proposée par Pogo ne permet pas d’interagir avec les participants, restant exclusivement réservé à la collecte opportuniste de données. 1 function start(){ 2 3 subscribe(’wifi-scan’, function(msg){ 4 5 publish(msg,’wifi-scan’) 6 7 } , { interval : 60 * 1000 }) } Listing 2.4 – Exemple d’application développée avec Pogo Pogo protège la vie privée des utilisateurs finaux en cachant leur identité aux scientifiques. En outre, les utilisateurs finaux conservent le contrôle de leurs données et sont en mesure de contrôler les capteurs utilisés par l’application. Pogo prend également la consommation d’énergie en considération en coordonnant la transmission des données pour les faire coïncider avec les transmissions d’autres applications. Cela permet d’éviter d’activer les interfaces réseaux constamment qui engendre un grand coût énergétique. 9. Android : https://developer.mozilla.org/enUS/docs/Rhino 10. iOS :https://github.com/phoboslab/JavaScriptCore-iOS 11. https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey 472.3.7 AnonySense : A System for Anonymous Opportunistic Sensing Shin et al. introduisent une plate-forme appelée AnonySense [62], adressant majoritaire les problématiques de confidentialité dans les systèmes de collecte opportuniste. Figure 6 – Architecture de Anonysense [62] 1 ( Expires 1196728453 ) 2 ( Accept (= @WiFi a/b/g ) ) 3 ( Report (LOCATION APLIST) 4 ( Every 60 seconds ) 5 ( In ( (1 1) (2 2) (3 0)))) Listing 2.5 – Exemple d’application développée en AnonyTL Pour la description des tâches de collecte, Anonysense propose sur un langage dédié appelé AnonyTL, inspiré de la syntaxe Lisp. AnonyTL permet de spécifier le comportement d’une tâche en fournissant un ensemble de conditions d’acception, des reports de données, et une date d’expiration. Le listing 2.5 décrit un exemple de tâche exprimée en AnonyTL. Cette tâche peut être acceptée uniquement par des dispositifs connectés à une borne WiFi, et collecte l’ensemble des bornes WiFi voisines ainsi que la position toutes les 60 secondes lorsque l’utilisateur se trouve dans une zone précise. Les auteurs proposent, un nouveau argument, le choix d’un nouveau langage pour fournir une notation plus concise et plus compréhensible. Cependant, cette concision diminue également l’expressivité du langage, et empêche également la réutilisation de code pré-existant. 48Le modèle proposé par Anonysense comporte les éléments suivants : un ensemble de dispositifs mobiles (MN), d’applications tierces (App), une autorité d’enregistrement (RA), un service de distribution de tâches (TS), et un service de rapport (RS) et un service d’anonymisation (AS). Dans ce modèle, un App soumet une tâche à l’autorité d’enregistrement (RA). Le RA vérifie ensuite si la tâche respecte la confidentialité des utilisateurs avant de la transmettre au service de distribution (TS). A intervalles réguliers, les MNs se connectent au TS et téléchargent l’ensemble des tâches disponibles. Les MNs choisissent ensuite les tâches qu’ils veulent accepter. Lorsqu’un rapport est prêt, les MNs l’envoient directement au RS ou au AS selon la sensibilité des données. Si le rapport contient des données sensibles, le rapport est envoyé au AS, dans le cas contraire, il est envoyé directement au RS. 2.4 synthèse et conclusion Dans cette section, nous faisons un bilan des plate-formes décrites dans la section précédente. Le tableau 7 fournit un récapitulatif de ces approches et les positionne par rapport aux défis décris en section 2.2. En ce qui concerne les abstractions proposées pour le développement des tâches de collecte, seulement PRISM [16] supporte à la fois le développement de tâche opportuniste et participative, en permettant le déploiement de code natif directement vers les dispositifs mobiles. Cependant, il ne fournit par d’abstraction particulière permettant de simplifier le développement des tâches de collecte. De plus, le déploiement de code natif reste exclusivement réservé à un système d’exploitation mobile spécifique, dans ce cas Windows Mobile. Pour le déploiement et le recrutement des tâches de collecte, principalement deux approches coexistent. La première est l’approche pull-based, adoptée par Medusa [55] et Anonysense, où les dispositifs sont responsables de télécharger les tâches de collecte auprès du serveur. Le principal avantage de cette approche est qu’elle permet d’assurer un certain degré de transparence, dans le sens où les participants peuvent sélectionner les tâches qu’ils souhaitent exécuter. Cependant, le temps de propagation des tâches peut être relativement long, et demande aux participants de vérifier constamment si une nouvelle tâche est disponible. Pour le recrutement des participants, Anonysense permet 49de sélectionner un sous ensemble de participants basé sur leur position. Pour assurer un temps de propagation rapide malgré l’approche pull-based utilisée, l’application mobile télécharge régulièrement toutes les tâches de collecte disponibles sur le serveur et exécute celles qui correspondent à son contexte. Cependant, cela peut impliquer un coût énergétique important des applications mobiles si de nombreuses tâches sont disponibles sur le serveur et ne correspondent pas au contexte du dispositif. La deuxième est l’approche push-based, adoptée par PRISM [16] et Pogo [6], où au contraire c’est le serveur qui déploie les tâches directement auprès des dispositifs mobiles. Son principal avantage est qu’elle permet un déploiement rapide des tâches de collecte, qui peut être très bénéfique dans le cadre où une rapide mise à jour de l’application doit être effectuée. Cependant, cette approche manque de transparence, dans le sens où les participants n’ont pas conscience des données qui sont collectées sur leur dispositif mobile. Pour le recrutement des utilisateurs, PRISM propose également un modèle basé sur la position des participants. Afin de permettre au système d’identi- fier les participants se situant dans une région spécifique, les applications mobiles ont besoin de reporter continuellement leur position sur le serveur, ce qui peut causer par conséquent un trafic réseau important si de nombreux dispositifs sont connectés au serveur. Finalement, la majorité de ces plate-formes propose une architecture centralisée, composée d’une application serveur pour le déploiement des tâches de collecte et une application mobile responsable de leurs exécutions. Cependant, ce style architectural impose à tous les utilisateurs du système de partager les ressources de l’infrastructure hébergeant la plate-forme, des mécanismes de stockage de données, le modèle financier imposé par le fournisseur de l’infrastructure et également la législation du pays où l’infrastructure est hébergée. Cela impose également les modèles mis en place pour déployer une application vers les terminaux mobiles, des mécanismes pour protéger la vie privée des utilisateurs, de récompense ainsi que la structure des données collectées. Dans ce contexte, nous pensons que ce type d’architecture limite fortement la réutilisation du système dans un contexte d’application non initialement prévu, ainsi que son passage à l’échelle. De plus, l’entité centrale représente un point unique de défaillance, qui, en cas d’attaque, peut compromettre l’ensemble des données collectées. Dans ce chapitre, nous avons présenté une vue d’ensemble du Mobile crowdsensing, ses caractéristiques, ses avantages ainsi que les défis qui doivent être adressés pour le déploiement de campagnes de collecte de données à grande échelle. À cause de ces 50nombreux défis, la mise en place de campagnes de collecte reste encore difficile, et reste réservée à des développeurs experts. Bien que de nombreuses plate-formes ont été proposées dans l’état de l’art pour simplifier le développement et le déploiement des ces campagnes, les solutions proposées restent encore restreintes à un contexte d’application particulier. De plus, la centralisation de leur architecture limite fortement la réutilisation de ces systèmes dans un autre contexte applicatif ainsi que leurs passages à l’échelle. À partir de ce constat, cela nous a mené à proposer APISENSE®, une plateforme répartie pour la conception, le déploiement et l’exécution de campagnes de collecte de données. Plus particulièrement, APISENSE® c’est : 1. Un modèle de programmation facilitant le développement de tâches de collecte participatives et opportunistes 2. Un environnement mobile sécurisé assurant l’exécution des tâches de collecte 3. Une architecture décentralisée permettant d’assurer le passage à l’échelle de la plate-forme 4. Un modèle permettant de configurer une application serveur responsable du déploiement des tâches de collecte, de la persistance ainsi que de l’exploitation des données collectées. Dans le chapitre suivant, nous présentons notre première contribution concernant le modèle de programmation des tâches de collecte ainsi que l’environnement mobile dédié à leur exécution. 51Figure 7 – Tableau comparatif des plate-formes MCS 52Deuxième partie Contributions 533 C O L L E C T E M O B I L E D E D O N N É E S Sommaire 3.1 Introduction 55 3.2 Considérations et objectifs de conception 57 3.3 Langage de programmation des collectes 59 3.3.1 Concept de l’interface de programmation 60 3.3.2 Collecte de données dirigée par les évènements 60 3.3.3 Les actions 64 3.4 Intergiciel de collecte 68 3.4.1 Couche d’exécution 68 3.4.2 Couche de contrôle 72 3.4.3 Couche d’interaction 74 3.5 Évaluation du prototype 78 3.5.1 Quelques exemples de collectes 79 3.5.2 Coût énergétique d’une expérience de collecte 87 3.6 Conclusion 88 3.1 introduction Le Mobile Crowd Sensing (MCS) est un mode de collecte de données qui a récemment été défini comme :" la participation d’un groupe d’individus, disposant de terminaux mobiles intelligents, qui collectivement, partagent des informations pour la mesure ou la cartographie de phénomènes d’un intérêt commun." [27]. Ces dernières années, le MCS a suscité l’intérêt d’un grand nombre d’acteurs académiques, dans des domaines tels que l’étude de la mobilité urbaine, la surveillance de l’environnement, la santé ou l’étude des comportements sociaux [9]. Cependant, le développement de ces applications reste une tâche complexe. En effet, ces applications ont besoin de faire face à de nombreuses propriétés non fonctionnelles telles que les ressources énergétiques limitées des dispositifs mobiles, le respect de 55la confidentialité des utilisateurs mobiles, ou encore le coût du recrutement d’un nombre important d’utilisateurs. À cause de cette complexité, il peut être très difficile pour de nombreuses acteurs de développer leurs applications capables de récolter la masse de données nécessaires pour leurs études. Ces dernières années, de nombreuses communautés scientifiques, utilisant le MCS dans leur processus expérimental, ont beaucoup discuté des bénéfices que pourrait apporter un système facilitant ce mode d’acquisition de données [27, 60, 66, 68]. Dans ce contexte, nous proposons dans cette thèse APISENSE®, une plate-forme visant de nombreux acteurs privés, publics ou académiques, leurs permettant de facilement développer et déployer des applications de collecte de données à travers des utilisateurs mobiles. Dans le chapitre section 1.4, page 13 , nous avons présenté une vue d’ensemble d’APISENSE®. Nous rappelons brièvement que le système est composé de trois entités logicielles i) un serveur central responsable du déploiement de tâches de collecte, ii) des nœuds de collecte dédiés aux utilisateurs, responsable du déploiement des tâches de collecte vers le serveur central et la persistance des données collectées, et finalement iii) un agent mobile, dédié aux participants (c.-à-d. utilisateur mobile) responsables de l’exécution des tâches de collecte. Dans ce chapitre, nous présentons notre première contribution qui consiste à proposer un modèle de programmation visant à minimiser l’expertise nécessaire liée aux développements d’applications de collecte, et la conception d’un environnement d’exécution mobile dédié à aux applications développées par notre interface de programmation. structure du chapitre La suite du chapitre est organisée comme suit : dans la section 3.2, nous faisons un bref rappel des problématiques et des solutions proposées dans l’état de l’art, et identifions les considérations prises en comptes pour la conception de notre solution. Nous présentons par la suite en section 3.3 une vue d’ensemble de l’interface de programmation proposée pour le développement des tâches de collecte. En section 3.4, nous présentons l’architecture du substrat d’exécution dédié à l’exécution des tâches de collecte. Nous présentons en section 3.5 l’évaluation d’un prototype réalisé sur Android, avant de conclure en section 3.6. 563.2 considérations et objectifs de conception Afin d’avoir une large applicabilité, permettant de définir une grande variété de tâches de collecte, nous devons proposer un modèle de programmation qui demande de prendre en considération principalement les trois points suivants : Diversité des tâches de collecte : Une tâche de collecte consiste à définir quel est le type de données (par ex. position, image), quand le processus de collecte doit être effectué (par ex. toutes les 5 minutes, lorsqu’un événement spécifique apparait) et comment une donnée doit être capturée. En ce qui concerne le comment, typiquement deux méthodes peuvent être utilisées. La première demande une interaction avec l’utilisateur (appelée collecte participative [7]), en lui demandant de répondre à un questionnaire ou prendre une photo par exemple. La deuxième s’effectue de manière autonome (appelée collecte opportuniste [39]), en interagissant directement avec les capteurs mobiles embarqués dans les terminaux mobiles. Diversité des traitements locaux : Pour la définition d’une tâche de collecte, quatre préoccupations doivent être prises en considérations : i) la limitation des ressources énergétiques, ii) la quantité des données générées et propagées vers le serveur, iii) la qualité des données et finalement iv) la confidentialité des participants. Prendre en compte ces considérations demande généralement de faire des compromis entre elles, en effectuant un traitement local avant de propager les données vers le serveur. L’objectif de ces traitements est de diminuer les données à propager sur le serveur, en remontant uniquement les données essentielles pour l’expérience, économisant ainsi la batterie de l’utilisateur par la réduction de communications réseau. Ces traitements peuvent consister à filtrer les données aberrantes, inférer une information contextuelle de haut niveau à partir de données brutes (par ex. mode de transport), ou encore alterner l’utilisation des capteurs en fonction de leurs consommations énergétiques (par ex. GPS vs géolocalisation GSM). Diversité des plate-formes mobiles : D’autre part, permettre le déploiement des tâches de collecte vers un grand nombre de participants demande également de prendre en compte la diversité des plate-formes mobiles disponibles. Ceci amène généralement à étudier et réaliser une application mobile spécifique pour chacune d’entre elles. Cette diversité a été soulignée par l’expérience menée par Balan et coll. [4], qui ont mis plus 57de six mois pour le développement et le déploiement d’une expérience de collecte à travers 15,000 taxis à Singapour. En tant que plate-forme de collecte de données, APISENSE® a deux publics distincts : i) les utilisateurs qui veulent définir de nouvelles campagnes de collecte de données, ii) les participants qui exécuteront ces tâches de collecte sur leur dispositif mobile. Dans ce contexte, à partir des considérations décrites ci-dessus et de ces deux publics distincts évoluant dans APISENSE®, nous identifions les objectifs de conception suivants : Objectif de conception pour les utilisateurs : Afin de minimiser le niveau d’expertise nécessaire liée aux développements des applications de collecte, il est nécessaire de fournir une abstraction facilitant leurs développements. Dans ce contexte, l’objectif est de proposer un langage de programmation reposant sur trois propriétés : 1. la généralité : pour supporter une grande variété d’activités de collecte (c.-à-d. participative et/ou opportuniste), qui peuvent également impliquer une grande variété de capteurs. 2. l’accessibilité : permettant de minimiser l’expertise nécessaire dans les technologies mobiles afin d’accéder aux fonctionnalités offertes par les capteurs des terminaux mobiles, ainsi que leurs collectes et leurs propagations vers l’infrastructure serveur. 3. la portabilité : afin d’éviter de devoir définir plusieurs tâches de collecte pour différentes plate-formes mobiles, l’abstraction proposée doit être en mesure de s’exécuter sur ces différentes plate-formes. Objectif de conception pour les participants : Inévitablement, les participants mobiles jouent un rôle central dans le processus de collecte. Afin de favoriser leurs participations, nous pensons que la confiance et la transparence doivent être un aspect fondamental du système. Cela nécessite que les utilisateurs mobiles aient connaissance des données qui sont collectées sur leurs terminaux, avec qui ils les partagent et dans quel but. D’autre part, favoriser l’acceptabilité des utilisateurs demande de fournir un substrat d’exécution permettant de : 1. Contrôler la confidentialité : en laissant la possibilité aux utilisateurs de choisir les données qui sont partagées, les capteurs qui peuvent être utilisés par les 58applications de collecte, et dans quelle circonstance les données peuvent être partagées. 2. Minimiser l’impact énergétique : lié à l’exécution d’une application de collecte, pour ne pas empêcher une utilisation normale du dispositif. Notamment si de multiples applications doivent être exécutées sur un seul dispositif. 3. Récompense adaptée : pour favoriser la participation des utilisateurs mobiles, en rendant ludique le but de la collecte de données, ou en récompensant les utilisateurs financièrement selon la nature des données collectées. 3.3 langage de programmation des collectes Pour le développement des tâches de collecte, nous avons opté pour le langage de script JavaScript. Le choix du JavaScript est motivé principalement pour trois raisons. Premièrement, JavaScript est un langage accessible et populaire, bénéficiant de l’expressivité d’un langage générale. Cela donne aux utilisateurs une grande liberté pour définir des traitements complexes, intégrer des libraires déjà existantes de traitement de données (par ex. clustering) pour inférer des données de haut niveau directement dans le dispositif mobile. Ensuite, JavaScript est facilement transportable et exécutable sur de nombreuses plateformes mobiles, permettant un rapide déploiement et une rapide propagation des mis à jour de la tâche de collecte. Et finalement, d’un point de vue plus technique, JavaScript est nativement exécuté dans un bac à sable (sandbox en anglais), facilitant le contrôle des fonctionnalités des dispositifs mobiles accessibles par les scripts. Pour faciliter le développement des tâches de collecte, nous proposons une interface de programmation (API) dédiée à la collecte de données, au-dessus de JavaScript. Le principal objectif de l’API est de fournir une abstraction complète des technologies mobiles, permettant le développement d’application de collecte de données, sans avoir une expertise particulière dans ces technologies. Dans APISENSE, une tâche de collecte est spécifiée par un ou plusieurs scripts JavaScript, qui peuvent être déployés et exécutés sur les dispositifs mobiles des participants. Dans la suite de cette section, nous présentons une vue d’ensemble de l’API proposée. 593.3.1 Concept de l’interface de programmation Comme le montre la figure 8, notre API consiste en un ensemble de variables pré- définies, appelée façades, définissant l’ensemble des fonctionnalités accessibles par les scripts. Plus précisément, une façade permet d’interagir avec les ressources d’un dispositif, et est implémentée dans le langage natif de la plate-forme d’exécution. Ces ressources peuvent être par exemple des capteurs physiques (par ex. température, GPS), des capteurs logiciels (par ex. appel téléphonique, installation d’une application) ou encore l’interface graphique du dispositif mobile. Dans notre API, chaque façade proposée fait référence à une ressource spécifique, et délimite un sous-ensemble de fonctionnalités fourni par celle-ci. Ce procédé permet ainsi d’empêcher l’utilisation complète des fonctionnalités des dispositifs mobiles, pour des raisons de sécurité et de confidentialité vis-à-vis du participant. Par exemple, cela permet de crypter toutes les informations sensibles (par ex. contacts, numéro de téléphone, etc.), d’empêcher l’installation de nouvelles applications ou encore de faire des appels téléphoniques. Également pour des raisons de confidentialité, nous laissons la possibilité aux participants de contrôler les façades accessibles par les scripts de collecte. Par exemple, un participant peut à tout moment enlever la possibilité à un script de déterminer sa position, ou d’être notifié lorsqu’il reçoit des SMS. La communication entre les scripts et les façades peut s’effectuer de deux manières différentes. La première, de manière asynchrone, permet aux scripts d’être notifiés du changement des états des capteurs des dispositifs mobiles. La deuxième, de manière synchrone, permet aux scripts de collecte d’effectuer une action spécifique, ou alors de lire directement le dernier état d’un capteur. 3.3.2 Collecte de données dirigée par les évènements L’écoute des évènements permet de déclencher une action ou un traitement en fonction du contexte de l’utilisateur mobile. Par exemple, la collecte de données peut être déclenchée uniquement lorsque l’utilisateur est en situation de mobilité. L’observation du contexte consiste principalement à observer le changement d’état d’un capteur interne du dispositif. Pour interagir avec les capteurs, les façades proposent un ensemble de fonctions permettant aux scripts d’être notifiés de ce changement d’état. Le tableau 1 montre quelques exemples de façade et des fonctions associées dédiées à l’observation d’un événement particulier. L’observation consiste donc à souscrire une 60Figure 8 – Interface de Programmation APISENSE Façade Fonction Description $location onLocationChange Observation du changement de position $battery onBatteryStateChange Observation de l’état de la batterie $acc onAccelerometerChange Observation de l’accélération $phone onPhoneCall Observation des appels téléphonique Table 1 – Liste des fonctions d’observation d’événements prédéfinis. Paramètre Type Description configuration JSONObject Configuration de l’observation de l’état du capteur callback function(event,subscription) Fonction de rappel condition (optionnel) String Condition logique Table 2 – Liste des paramètres d’une fonction de rappel 61fonction de rappel, à une façade responsable du capteur capable de générer l’événement voulu. La souscription comprend trois paramètres, permettant la configuration du capteur, la fonction de rappel et une expression logique permettant de raffiner l’observation des événements, et retourne un objet de type Subscriber. configuration Le premier paramètre configuration laisse la possibilité de configurer l’observation du capteur en question. La configuration peut être utilisée afin de faire un compromis en qualité des données transmises par les capteurs (c.-à-d. fréquence d’échantillonnage, précision) et l’énergie consommée liée à l’observation du capteur. Un exemple classique est l’observation du changement de la position d’un utilisateur. Généralement, ce compromis peut être effectué en alternant le type de capteur utilisé — entre le GPS fournissant une grande précision, mais consommant beaucoup d’énergie, et le réseau qui au contraire consomme moins d’énergie, mais fournit une localisation moins précise —, ou la fréquence d’échantillonnage. Le tableau 2 illustre les configurations du capteur de position possibles. Fonction Description period Période d’échantillonnage de la position provider Capteur de position utilisé : gps ou network Table 3 – Configuration de l’observation de la position d’un utilisateur fonction de rappel Le deuxième paramètre permet d’enregistrer une fonction qui sera exécutée lors du changement d’état du capteur observé. Par exemple, le listing suivant montre la syntaxe permettant à un script de collecte d’être notifié lorsque l’utilisateur est en situation de mobilité : $location.onLocationChanged({provider : ["gps"]},function(event){ // code exécuté lorsque une nouvelle position est détectée }) Chaque événement est défini par un ensemble d’attributs, sérialisés par un ensemble de clés/valeurs utilisant le formalisme JSON. Chaque événement est au minimum défini par un nom, et la date de sa production. Le listing suivant illustre un exemple d’événement produit lorsqu’une nouvelle position de l’utilisateur est détectée : 62{ event : "location", time : 18005010510, latitude : 50.65, longitude : 2.11, accuracy : 100, speed : 3 } Dans cet exemple, l’événement est défini par cinq attributs indiquant la position de l’utilisateur (c.-à-d.latitude, longitude), la précision de la position (c.-à-d.accuracy) et la vitesse de l’utilisateur (c.-à-d.speed). condition logique Optionnellement, l’écoute d’événement peut être raffinée en insérant une condition lors de la souscription. La condition se définit par un opérateur appliqué à un attribut appartenant à l’événement et à une valeur. Plusieurs conditions peuvent être exprimées en ajoutant des opérateurs logiques de type et, ou ou non. (cf. listing 3.1). Le listing suivant illustre un exemple utilisant une expression logique, implémentant une solution naïve pour déterminer si l’utilisateur est en train de marcher : $location.onLocationChanged({provider : ["gps"]},function(event){ // code exécuté lorsque l’utilisateur marche }," &((speed > 3),(speed < 5)) ") Dans cet exemple, nous observons donc le changement de position, et nous définissons que la fonction de rappel doit être exécutée uniquement si l’utilisateur se déplace à une vitesse comprise entre trois et cinq Kilomètres/h. 1 expression ::= key’(’[condition+]’)’ | condition 2 condition ::= eventAttribute operator value 3 key ::= ( "!" | "&" | "|" ) 4 operator ::= ( "<" | "==" | ">" | "<=" | ">=" ) 5 eventName ::= alpha* 6 eventAttribute ::= alpha* 7 value ::= alphanumeric* Listing 3.1 – Grammaire BNF d’une expression logique objet de souscription Pour maintenir un lien entre la souscription et le script, un objet de type Subscriber (cf. table 4) est retourné lors de l’enregistrement. L’objet de souscription permet d’annuler la souscription à un événement particulier 63(fonction suspend), permettant d’éteindre un capteur actif afin de conserver l’énergie du dispositif mobile. La méthode resume permet de reprendre une souscription qui a été annulée. Fonction Description suspend Suppression de l’observation resume Redémarrage de la souscription Table 4 – Liste des fonctions d’un objet de souscription 3.3.3 Les actions En plus de l’observation des événements, les façades fournissent également des fonctions permettant d’exécuter des actions spécifiques. Dans la suite de cette soussection, nous présentons les principales actions prédéfinies par notre API qui sont la collecte et la propagation de données, l’interaction avec l’utilisateur mobile ou encore définir des informations pouvant être fournies en retour aux utilisateurs sur les données collectées. Collecte et propagation des données La collecte de données est effectuée à l’aide de la façade dédiée $trace. Cette façade possède trois fonctions comme le montre le tableau 5. La première permet de sauvegarder une donnée dans la base de données locale du terminal mobile (méthode add). Les données sont sous la forme d’un objet JSON, n’imposant aucune structure de données particulière pour représenter les données collectées. Cela laisse ainsi une grande flexibilité aux utilisateurs de définir leurs propres structures. Additionellement, les utilisateurs peuvent ajouter des méta-informations (méthode addHeader), permettant de diminuer la collecte de données redondantes, et leurs agrégations une fois propagées vers le serveur. Ces méta-informations représentent généralement des données statiques, c’est à dire qui n’évoluent pas dans le temps. L’API permet également de définir la stratégie pour propager les données vers les nœuds de collecte grâce à la méthode send. Lors de l’appel à cette fonction, la façade propagera les données sauvegardées dans la base de données locale si une connexion est disponible, sinon les données seront propagées une fois la connexion retrouvée. Dans le cas où aucune stratégie n’est définie, les données seront propagées automatiquement une fois que le 64dispositif est branché sur secteur et possède une connexion réseau. Cela permet de diminuer la consommation énergétique des dispositifs des participants. Fonction Description add(data) Collecter une donnée addHeader(key,value) Collecter une donnée statique send() Propagation des données collectées Table 5 – Liste des fonctions de la façade de collecte Interaction avec l’utilisateur Collecter des données de façon transparente peut ne pas être suffisant dans certains cas. En effet, certaines informations comme la satisfaction d’un utilisateur ou ses intentions sont difficilement perceptibles à partir de donnée brute. Prenons par exemple une collecte de donnée visant à observer la qualité du signal réseau d’un utilisateur mobile. Il peut être intéressant de voir comment la qualité du signal réseau influe sur la qualité de la communication vocale. Cependant, cette information peut être très difficilement inférée à partir des données brutes issues des capteurs. Dans ce contexte, une solution possible est de proposer des questionnaires d’évaluation aux utilisateurs. Ce type de collecte est également appelé collecte participative. Pour supporter la collecte participative, notre API dispose d’une façade permettant la création et la publication de questionnaire aux utilisateurs mobiles. Le tableau 6 illustre les principales fonctions fournies par cette façade. La création d’un nouveau questionnaire s’effectue à partir de la fonction create de la façade $survey. La fonction retourne un objet de type Survey, disposant d’un ensemble de fonctions permettant d’insérer des questions ouvertes (par ex. zone de texte), de question fermée (par ex. case à cocher), ainsi que des captures multimédias (c.-à-d. photo, vidéo, audio). La fonction then permet de modifier la séquence des questions proposée à l’utilisateur, qui est par défaut dans l’ordre de leurs créations. Cela permet par exemple de proposer des questions différentes selon les premières réponses données par l’utilisateur. Nous illustrerons un exemple de création de questionnaire dans la sous-section 3.5.1 . 65Facade $survey Return Fonction Description Survey create Création d’un nouveau questionnaire void publish(survey,callback) Publication du questionnaire Type Survey void close(label,question,responses) Création d’une question fermée void open(label,question) Création d’une question ouverte void image(label,format) Capture photo void audio(label,format) Capture audio void video(label,format) Capture vidéo void then(label,callback) Spécification de la prochaine fonction Table 6 – Liste des fonctions de la façade dédiée à la création des questionnaires Retour utilisateur Afin de favoriser leurs participations des utilisateurs, et surtout maintenir les utilisateurs dans la durée, nous avons intégré à notre API la possibilité d’effectuer facilement des retours visuels sur les données collectées par l’utilisateur mobile. Ces retours visuels peuvent être directement développés utilisant le couple JavaScript/HTML, fournissant une grande flexibilité pour concevoir des retours selon la nature de collecte de données. Pour simplifier leurs développements, nous proposons des modules complémentaires qui peuvent être inclus dans la tâche de collecte lors de son déploiement, ou téléchargés dynamiquement lors de l’exécution du script. Actuellement nous proposons deux modules génériques permettant de créer automatiquement des graphes ou des cartes géographiques à partir des données collectées. Par exemple, le listing 3.2 décrit un exemple l’utilisation d’un module facilitant la génération de graphe. Dans cet exemple, les trois premières permettent de charger le module (ligne 1), créer un nouveau graphique (ligne 2) et rendre disponible le graphique pour les utilisateurs (ligne 3). Les lignes suivantes permettent d’observer les évènements relatifs aux changements de la force du signal GSM (ligne 7), et d’ajouter une nouvelle valeur au graphique lorsqu’un nouvel évènement est détecté (ligne 9). La figure 9 montre une capture d’écran du rendu graphique de cet exemple. 66// signal strenght chart configuration var chartLib = require("lib-chart.js") chart = chartLib.area({name : "GSM Signal Strength Chart"}); chart.publish(); // telephony sensor monitoring initialization $telephony.onSignalStrengthChanged(function(event){ chart.add({ x : event.time, event.level }); }); Listing 3.2 – Exemple de retour utilisateur Figure 9 – Exemple de capture d’écran d’un retour utilisateur Dans cette section, nous avons présenté une vue d’ensemble de notre API, dédié aux développements des tâches de collectes de notre système. Une documentation plus détaillée est également disponible le site internet dédié à APISENSE 1 . Dans la 1. http://apisense.io 67section suivante, nous présentons les concepts et l’architecture de l’intergiciel dédié à l’exécution de l’interface de programmation présentée dans cette section. 3.4 intergiciel de collecte Dans la première section de ce chapitre, nous avons présenté une interface de programmation dédiée aux développements de tâche de collecte en environnement mobile. Dans cette section, nous présentons en détail l’architecture de l’intergiciel responsable de l’exécution des tâches de collecte. D’un point de vue utilisateur, l’intergiciel se dé- cline sous la forme d’une application mobile, qui peut être téléchargée et installée afin de participer aux expériences de collecte de données. Dans ce cadre, l’application peut être perçue comme un conteneur générique de tâches de collecte, capable d’interagir avec les différents serveurs pour la propagation des données collectées (vers les nœuds de collecte), le téléchargement des tâches de collecte (auprès du serveur central) ainsi que leurs exécutions. La figure 10 illustre une vue d’ensemble de l’architecture de l’intergiciel se déclinant en trois couches. Dans la suite de cette section, nous présentons en détails chacune de ces couches dédiées à : i) l’exécution des tâches de collecte (cf. sous-section 3.4.1), au contrôle des ressources du dispositif mobile (cf. sous-section 3.4.2), et iii) aux interactions avec les différentes entités logicielles d’APISENSE® (cf. sous-section 3.4.3). 3.4.1 Couche d’exécution Nous présentons ici la couche responsable de l’exécution des tâches de collecte développées avec l’interface de programmation que nous avons présentée dans la section précédente. La première couche de l’architecture présentée est responsable de l’exécution des tâches de collecte. La Figure 11 illustre plus en détail les différents modules et les interactions nécessaires à l’exécution des tâches de collecte. Le point d’entrée de cette couche est le Script Manager, qui est responsable de créer ou détruire une instance d’exécution d’une tâche de collecte, selon l’ordre envoyé par le Privacy Manager. Dans ce contexte, l’objectif clé est de fournir un environnement d’exécution sécurisé, permettant également aux participants de contrôler les données qu’ils partagent pour des raisons de confidentialité. Cependant, généralement tous les accès aux données brutes des capteurs peuvent constituer une menace pour la 68Figure 10 – Architecture de l’intergiciel mobile Figure 11 – Interaction de la couche d’exécution 69vie privée des participants. Par exemple, l’accès au microphone peut être utilisé pour enregistrer une conversation téléphonique souhaitant rester privée. L’accès continu au GPS peut permettre à un utilisateur anonyme d’être identifié juste en couplant des informations géographiques et temporelles [26]. Néanmoins, ce risque reste inhérent dans le domaine de la collecte de données. En effet, si nous voulons une protection parfaite, tous les accès aux capteurs devraient être bloqués. Pour mitiger ces risques, nous laissons la possibilité aux participants de contrôler les capteurs accessibles par les tâches de collecte (cf. 3.4.2). Pour la gestion de ce contrôle d’accès, chaque instance d’exécution d’une tâche de collecte est exécutée dans un bac à sable dédié (sandbox en anglais), permettant d’intercepter tous les appels entre les tâches de collecte et les capteurs du dispositif. Ainsi, toutes les fonctionnalités de l’interface de programmation sont fournies par un ensemble de façades (cf. sous-section 3.3.1), représentant également le point d’extension de notre l’architecture. Une façade est un objet, écrit en code natif de la plate-forme mobile, permettant l’interaction entre les tâches de collecte et l’environnement mobile. Le listing 3.3 montre l’exemple d’un squelette d’implémentation sous Android, de la façade permettant d’accéder aux capteurs de localisation. Dans cette façade, la fonction getReferenceName retourne le nom de la variable qui est utilisée pour accéder aux fonctions fournies par la façade. Chaque fonction annotée par une annotation @ScriptMethod, indique au moteur de script que la fonction est accessible par les tâches de collecte. Si nous reprenons l’exemple illustré dans la section précédente (cf. sous-section 3.3), la fonctionnalité $location.onLocationChanged accessible par la tâche de collecte, est implémentée par la façade LocationFacade, injectée en tant que variable $location et implémentant la fonction onLocationChanged. 1 public class LocationFacade extends AbstractAndroidFacade{ 2 3 public String getReferenceName() {return "location";} 4 5 public String getSensorDescription(){ ... 6 7 @ScriptMethod 8 public ISubscriber onLocationChanged( 9 JSONObject params,IScriptFunction callback,String... filters){ 10 // subscribe to location sensor update 11 return ... 12 } 13 14 public void shutdown() { ... // clean sensor subscription } 15 } 70Listing 3.3 – Squelette de l’implémentation d’une façade sur Android Lors de la création d’une nouvelle instance d’exécution, le Script Manager effectue une requête au Privacy Manager pour lister l’ensemble des capteurs admis par le participant. Le Script Manager injectera alors seulement les façades correspondantes aux capteurs qui auront été admis par le participant. Dans ce cadre, les façades correspondant aux capteurs non autorisés ne seront pas injectées, empêchant les scripts de bénéficier des fonctionnalités du capteur en question. Réguler l’accès aux capteurs Pour interagir avec les capteurs du dispositif mobile, les façades doivent interagir avec le Sensor Controller. Son objectif est principalement de réguler l’accès aux capteurs du dispositif et de filtrer les données sensibles. Par exemple, lorsqu’une façade demande l’accès à des informations de type SMS ou numéro de téléphone, les données retournées par la couche de contrôle seront automatiquement cryptées pour protéger la vie privée des participants. Deux types de communications peuvent être effectuées avec le Sensor Controller, des communications de type asynchrone permettant la lecture continuelle de l’état d’un capteur et de type synchrone afin de lire directement l’état d’un capteur. Pour économiser la batterie du dispositif mobile, le Sensor Controller dispose de deux mécanismes. Le premier est un mécanisme de cache, dédié aux communications synchrones. Ce mécanisme permet principalement de limiter une lecture excessive de l’état d’un capteur. Ce mécanisme consiste principalement à définir une fenêtre temporelle dans laquelle seront insérées toutes les données récupérées par le Sensor Controller via les APIs des systèmes mobiles, donnant accès aux données fournis par les capteurs physiques. Avant de procéder à un nouvel accès aux capteurs, la couche de contrôle vérifiera dans un premier temps si la donnée demandée est disponible dans la fenêtre temporelle. Si elle est disponible, la valeur du cache sera alors renvoyée. Le deuxième mécanisme mis en place tente de minimiser le nombre de souscriptions effectuées aux capteurs des dispositifs. Typiquement, un script peut être notifié du changement d’état d’un capteur en enregistrant à une façade une fonction de rappel, une expression logique permettant de filtrer les états ainsi qu’une période indiquant la fréquence des mises à jour des données. Dans le cas où plusieurs scripts procèdent 71à la souscription d’un même capteur avec une période différente, le Sensor Controller effectuera seulement une souscription aux capteurs correspondants, avec une période correspondante à la plus petite période des deux souscriptions. Prenons le cas par exemple où deux scripts effectuent une souscription au capteur GPS avec les périodes respectives de 10 et 20 secondes. Dans ce cas, le Sensor Controller effectuera une seule souscription au capteur GPS avec une fréquence d’échantillonnage égale à 10 secondes, et notifiera les deux scripts toutes les 10 secondes de la nouvelle position. 3.4.2 Couche de contrôle Cette couche est responsable du contrôle de l’exécution des scripts de collecte. Le contrôle consiste à automatiquement démarrer ou arrêter un script de collecte, à partir d’un ensemble de contraintes contextuelles définies par les participants et les expé- riences. Ces contraintes peuvent par exemple permettre aux participants d’empêcher l’exécution d’un script en dehors de la période allant de 9 heures et 18 heures ou lorsque le participant est en dehors d’une zone géographique. Un autre scénario envisagé est d’empêcher l’exécution d’un script si le niveau de la batterie est inférieur à 30 %. Ces contraintes peuvent être classifiées en quatre catégories : contrainte temporelle, contrainte géographique, contrainte de ressource et contrainte de capteur. Ces contraintes sont respectivement interprétées par les modules TimeConstraint, ZoneContraint, ResourceConstraint et SensorConstraint. Contrainte temporelle Ces contraintes, interprétées par le module Time Constraint, permettent de spécifier différentes périodes de la journée durant lesquelles les expériences ont l’autorisation d’être exécutées. Ces contraintes sont modélisées comme un ensemble de périodes où chaque période est définie par un temps de départ et un temps de fin. Pour une expérience donnée, la contrainte temporelle est vérifiée si, à instant t, t appartient au moins à une période définie par le participant et à une période définie par le contexte d’exécution de l’expérience. La surveillance contextuelle des contraintes temporelle consiste à surveiller l’horloge interne du dispositif mobile. Pour chaque contrainte définie, ce module programme une alarme, demandant au système d’être notifié au début et à la fin de la période définissant la contrainte. 72Contrainte géographique Interprétées par le module Zone Constraint, les contraintes géographiques permettent de spécifier un ensemble de lieux ou de régions, dans lesquelles les scripts peuvent être exécutés selon la position du participant. Une contrainte géographique est modélisée par un ensemble de régions circulaires en terme de latitude, longitude et un rayon en kilomètre. Pour une expérience donnée, la contrainte géographique est vérifiée si à une position p donnée, p est inclus au moins dans une zone définie par le participant ou par le contexte d’exécution de l’expérience. En ce qui concerne la surveillance contextuelle, surveiller activement la position de l’utilisateur peut engendrer une grande consommation énergétique du dispositif. Pour diminuer cette consommation énergétique, nous utilisons un algorithme fréquemment utilisé [3, 8] dans la littérature. Typiquement, l’idée principale est i) d’utiliser alternativement les différents mécanismes permettant de déterminer la position d’un utilisateur — entre le GPS fournissant une grande précision, mais consommant beaucoup d’énergie, et le réseau qui au contraire consomme moins d’énergie, mais est beaucoup moins précis —, ii) et la fréquence d’échantillonnage en fonction de la distance de l’utilisateur et la zone la plus proche de sa position actuelle. Contrainte de ressource Ces contraintes permettent de limiter les ressources consommées par l’application. Le participant peut par exemple définir un seuil de batterie pour stopper l’exécution de toutes les expériences de collecte pour éviter un épuisement complet de sa batterie. Une autre ressource qui peut être contrôlée est la quantité de données échangées via une connexion de données mobiles qui peut induire un coût monétaire pour le participant. Dans ce cadre, le participant peut définir un seuil maximum de données transmises lorsqu’une connexion est utilisée. Contrainte de capteur Ces contraintes permettent de spécifier les fonctionnalités permises par les scripts de collecte. Dans l’interface de programmation proposée pour définir une expérience de collecte, nous avons vu que les fonctionnalités accessibles par les scripts se font par l’intermédiaire de façades. Pour chaque façade, le participant a la possibilité de définir s’il autorise l’accès à l’ensemble des fonctionnalités proposées par la façade. Par exemple, le participant peut enlever l’autorisation de la façade $sms, qui supprimera la possibilité de recueillir des informations relatives aux SMS envoyés et lus. 73Dans l’architecture présentée précédemment en figure 10, les modules TimeConstraint, ZoneConstraint et RessourceConstraint ont pour rôle de surveiller le contexte du dispositif (e.g. horloge interne, position, niveau de batterie) et d’envoyer un message au Privacy Manager afin de notifier un changement de contexte du dispositif mobile. Lors de la notification, le Privacy Manager vérifie pour chaque expérience si les contraintes spécifiées par le participant et par l’expérience sont respectées. Dans ce cas, le Privacy Manager interprètera les contraintes de capteurs définies par le module Sensor Constraint pour générer une nouvelle instance d’exécution ou stopper l’exécution d’une expérience de collecte. 3.4.3 Couche d’interaction La dernière couche présenté dans cette section représente la couche de plus haut niveau de l’intergiciel. Cette couche est principalement responsable des interactions entre le dispositif mobile avec les différentes entités logicielles de notre architecture et le participant. Typiquement, cinq types d’interactions sont nécessaires au déroulement des expériences de collecte : i) l’enregistrement auprès du serveur central, ii) la souscription à une expérience de collecte, iii) la mise à jour des expériences, iv) l’interaction avec les participants et finalement v) la propagation des données collectées. Dans la suite de cette sous-section, nous présentons ces interactions et les modules responsables de leurs fonctionnements. Souscription du dispositif Le processus d’enregistrement, géré par le Profile Manager, permet d’informer le serveur central de la disponibilité d’un nouveau périphérique mobile pour l’exécution de nouvelles tâches de collecte. Typiquement, cette phase d’enregistrement consiste à fournir des informations générales du dispositif et du participant, permettant de proposer des expériences de collecte adéquates. Dans ce contexte, deux sortes d’informations sont principalement échangées. Les premières sont des informations relatives au dispositif mobile incluant le type du dispositif (par ex. smartphone, tablette), son système d’exploitation (par ex. Android, iOS), ses performances ainsi que les capteurs embarqués (par ex. température, GPS). Pour raffiner la proposition des expériences, les participants ont la possibilité de compléter ces informations volontairement en indiquant les différents lieux de vie dans lequel ils évoluent (par ex. maison, travail) son statut (par ex. professionnel) ainsi que son âge.Toutes les informations transmises 74Figure 12 – Règles de confidentialité resteront confidentielles, c’est-à-dire qu’elles ne seront pas directement accessibles par les nœuds de collecte du système. Ces informations seront utilisées uniquement par le serveur central lors de la phase du déploiement des expériences de collecte. D’autre part, afin de protéger la vie privée des participants, le Profile Manager permet aux participants de définir certaines règles de confidentialités (cf. figure 12). Principalement trois catégories de règles peuvent être définies. Les deux premières permettent de spécifier des zones géographiques et temporelles, indiquant à l’agent mobile une interdiction d’exécuter des tâches de collecte. La dernière catégorie permet de spécifier des règles d’autorisations, permettant d’empêcher l’activation des capteurs ou l’accès aux données brutes du capteur si l’utilisateur ne veut pas partager une information. Nous aborderons plus en détails ce point dans la sous-section suivante (cf. sous-section 3.4.2). Souscription à une expérience Une fois le dispositif enregistré, les participants ont la possibilité de lister (via le ExperimentManager), un sous ensemble d’expériences de collecte proposées par les utilisateurs. Les expériences sont retournées en fonction des informations fournies lors de la phase d’enregistrement. Chaque expérience est définie tout d’abord par un nom ainsi qu’une brève description indiquant l’objectif de la collecte de données. La description d’une expérience est également caractérisée par un contexte d’exécution définissant quand l’expérience doit être exécutée. Le contexte d’exécution est défini 75selon une dimension géographique (par ex. à l’intérieur d’une zone) et une dimension temporelle (par ex. période dans la journée). D’autre part, des informations relatives aux capteurs utilisés sont fournies pour indiquer aux participants quels sont les types de données qui peuvent être collectées sur leurs dispositifs. À partir de l’ensemble des descriptions disponibles, le participant a la possibilité de soumettre une souscription à une expérience de collecte. Dans ce cadre, la souscription déclenchera le téléchargement des scripts associés dans le système de fichier du dispositif mobile ainsi que des informations complémentaires propres aux scripts de collecte. Ces informations comprennent la version actuelle des scripts de collecte, l’adresse du serveur de collecte ayant initié l’expérience ainsi qu’un identifiant anonyme généré lors de la souscription. L’identifiant anonyme généré par le serveur central est unique pour chaque expérience. Cette identifiant servira alors de clé d’authentification lors de la propagation des données vers le serveur de collecte. Lorsque les scripts de l’expérience sont téléchargés, le module déclenche automatiquement son exécution. Néanmoins le participant garde à tout moment la possibilité d’arrêter son exécution. Mise à jour des expériences La mise à jour des expériences de collecte est gérée par le module NotificationManager. Les mise à jour sont effectuées par des communications de type push, c’est-à-dire des communications serveur vers mobile. Dans notre contexte applicatif, cela permet d’éviter de faire des requêtes périodiques vers le serveur, induisant un surcoût énergétique pour assurer une rapide prolifération. Pour assurer ce type de communication, nous utilisons des services intermédiaires proposés par les plate-formes mobiles actuelles, telles que APNs (Apple Push Notification service) pour plateformes tournant sur iOS et GCM (Google Cloud Messaging) pour les plateformes Android. Généralement, pour utiliser ce type de service, les dispositifs mobiles doivent tout d’abord procéder à une phase d’enregistrement auprès du service en question. Cette phase permet l’obtention d’un identifiant unique, qui devra ensuite être partagé avec le serveur — dans notre contexte, le serveur central— voulant envoyer des messages vers le dispositif en question. Le serveur peut ensuite faire appel au service dédié en utilisant les identifiants partagés pour propager directement des informations auprès des dispositifs mobiles. Dans ce contexte, lorsqu’une nouvelle version d’une expérience est déployée, le serveur central envoie un message à tous les participants ayant souscrits à l’expérience en question. Ce message est ensuite intercepté par le NotificationManager qui déclenchera automati- 76quement le téléchargement de la nouvelle version, sans imposer aux participants de télécharger à nouveau la tâche de collecte manuellement. Retour utilisateur Le Feedback Manager est responsable de l’interaction entre les tâches de collecte et les participants. Comme nous l’avons mentionné précédemment (cf. sous-section 3.3.3, page 66 ), l’interface de programmation proposée permet de diffuser des visualisations aux participants. Ces visualisations peuvent consister à fournir des statistiques sur les données collectées sous forme de graphique ou de carte, leur demander de prendre une photo d’un évènement particulier ou répondre à un questionnaire. Ces visualisations peuvent être directement développées en HTML/JavaScript, fournissant une grande flexibilité pour définir leurs propres visualisations en fonction de la nature de leurs expériences. D’autre part, cela permet également d’être indépendant de la plate-forme d’exécution, évitant ainsi le développement de plusieurs visualisations selon les plateformes visées. Dans ce cadre, nous tirons bénéfice des modules fournis par les plateformes mobiles (par ex. WebView 2 pour Android, UIWebView 3 pour iOS) pour faciliter l’intégration de contenus web dans une application mobile. Dans ce contexte, les tâches de collecte peuvent interagir avec le FeedBackManager, via une façade dédiée, permettant de publier un nouveau contenu accessible par le participant. Chaque contenu web est ensuite sérialisé et sauvegardé dans une base de données, et pourra être visualisé par le participant à tout moment à partir d’une interface graphique fournie par le FeedBackManager, (cf. figure 13). Propagation des données La propagation des données vers les nœuds de collecte est gérée par le TrackManager. Lors de l’exécution d’une tâche de collecte, les données collectées sont transmises au TrackManager qui les sauvegarde dans la base de donnée locale du dispositif. Pour chaque expérience, le processus de propagation (cf. sous-section 3.3.3) consiste à compresser les données collectées, ajouter des méta-informations sur la configuration du dispositif du participant (c.-à-d. filtre de vie privée) et à faire appel au service dédié du serveur de collecte ayant initié l’expérience pour l’envoi des données. Pour des raisons de sécurité, l’envoi des données s’effectue en utilisant le protocole HTTPS pour le cryptage des données. 2. Android WebView : http://tinyurl.com/android-webview 3. iOS UIWebView : http://tinyurl.com/ios-webview 77Figure 13 – Exemple de contenu web disponible via le FeedbackManager Nous venons de présenter dans cette section l’intergiciel mobile responsable de l’exécution de tâche de collecte, développée avec l’interface de programmation présentée dans la première section de chapitre. Dans la section suivante, nous présentons l’évaluation d’un prototype implémentant les concepts proposés dans ce chapitre. 3.5 évaluation du prototype Afin d’implémenter les concepts présentés dans ce chapitre sur une plate-forme mobile spécifique, celle-ci doit permettre principalement i) d’effectuer des processus en tâche de fond, ii) permettre la lecture en continue des capteurs, iii) et finalement être capable d’intégrer un moteur de script dans une application. Lorsque nous avons commencé le développement de notre prototype, la plate-forme Android correspondait parfaitement à ces caractéristiques, contrairement aux systèmes d’exploitation iOS qui ne permettaient pas d’exécuter des processus en tâche de fond limitant ainsi le développement d’application de collecte opportuniste. Cependant, les récentes mise à jour de ce système d’exploitation fournissent désormais ce support, rendant portable notre système pour iOS. Par manque de temps, nous n’avons pas pu fournir un prototype complet sur ce système d’exploitation, mais nous avons fourni une preuve de faisabilité disponible en open source 4 . Le prototype Android proposé a été conçu pour être utilisé comme application autonome ou comme librairie. En tant qu’application autonome, l’application peut être 4. https://github.com/APISENSE/APISENSE-SDK-iOS 78téléchargée par des participants voulant évoluer dans le système en flashant un QR code publié sur le site internet APISENSE® 5 . Plus particulièrement, le prototype réalisé à été développé en utilisant la version 2.3 du SDK proposé par Android. L’ensemble des modules proposés par l’architecture est inclus dans un Service de haute priorité pour prévenir que le système ne supprime notre application lorsqu’il a besoin de mémoire. Pour l’exécution des scripts, nous utilisons Rhino 6 , un moteur d’exécution JavaScript pour Java, qui permet l’interopérabilité des deux langages. L’ensemble du code réalisé représente approximativement 30000 lignes de codes, incluant l’interface graphique et l’architecture de l’application et les façades développées. Dans la suite cette section, nous présentons plusieurs cas réels d’expériences, montrant la diversité des tâches de collecte qui peuvent être réalisées à l’aide notre interface de programmation. Nous comparons par la suite son expressivité avec les différentes approches proposées dans la littérature, et discutons du coût énergétique lié à l’exécution des tâches de collecte sur les dispositifs mobiles. 3.5.1 Quelques exemples de collectes Pour démontrer l’expressivité de l’interface de programmation proposée dans ce chapitre, nous avons implémenté quatre tâches de collecte différentes (cf. table 7). Chaque tâche de collecte est inspirée de l’état de l’art, et démontre différents aspects de APISENSE. Wifi/Blutooth Scanner Wifi/Blutooth Scanner est une application opportuniste, montrant une interaction avec les capteurs Wi-Fi et Bluetooth d’un dispositif. Le listing 3.4 illustre le script implémentant cette application. L’objectif du script est de collecter, toutes les minutes, les points d’accès WIFI et les périphériques Bluetooth d’un utilisateur mobile. Dans le script, nous enregistrons une fonction de rappel aux façades $wifi et $bluetooth responsables des interactions avec ces capteurs, et nous configurons les capteurs pour qu’ils effectuent une nouvelle recherche toutes les minutes (period:"1 min"). La 5. http://www.apisense.fr 6. http://www.mozilla.org/rhino 79Application Capteurs Description Wifi-Blutooth Scanner Réseaux Application opportuniste. Collecte périodiquement les périphériques Bluetooth et Wi-Fi. Citoyen Journaliste GPS + Questionnaire Application participative. Demande à l’utilisateur de prendre une photo lorsqu’il se situe dans une zone géographique. Qualité Réseau Réseau + Questionnaire + Télé- phone Combinaison d’une application opportuniste et participatif.pour corréler la qualité d’une communication en fonction de la qualité du signal GSM. Exploiter des capteurs externes Bluetooth Communication avec un robot Lego Mindstorms NXT Inférence Conxtuelle Accéléromètre + Questionnaire Intégration d’une machine d’apprentissage pour inférer l’activité d’un utilisateur. Table 7 – Exemples de tâches de collecte implémentées avec APISENSE. (*Lignes de code) fonction de rappel enregistrée collecte alors les résultats donnés par les capteurs pour les propager vers le serveur ($trace.add(event)). 1 $wifi.onScan({period : "1 min"},function(event){ 2 $trace.add(event) 3 }) 4 $bluetooth.onScan({period : "1 min"}, function(event){ 5 $trace.add(event) 6 }) Listing 3.4 – Tâche de collecte : Wifi/Bluetooth Scanner Nous décrivons dans l’exemple suivant un exemple de collecte participative. Le Citoyen Journaliste L’objectif de cette application est de montrer comment une tâche de collecte peut interagir avec un utilisateur. Le Citoyen Journaliste, présenté initialement en [29], demande aux utilisateurs mobiles de prendre une image dans une région géographique spécifique, et de la commenter. Le script présenté dans le listing 3.5, crée d’abord un questionnaire (ligne 1-3). En ligne 5 nous observons la position de l’utilisateur et définissons que la fonction enregistrée (ligne 6-8) doit être exécutée uniquement lorsque la position de l’utilisateur se trouve dans le polygone précis (ligne 8). La fonction enregistrée publie le questionnaire à l’utilisateur (ligne 6), et collecte les données pour les propager vers le serveur lorsque l’utilisateur aura répondu au questionnaire. 801 var survey = $survey.create(); 2 survey.image("Take a picture"); 3 survey.open("Add a comment"); 4 5 $location.onLocationChanged(function(event){ 6 $survey.publish(survey,function(content){ 7 $trace.add(content); 8 $task.finish(); 9 }); 10 },"&((lat >= 0)(lat <= 1)(lon >= 0)(lon <= 1))") Listing 3.5 – Tâche de collecte : Le Citoyen Journalist Qualité Réseau Dans cette application, inspirée de MyExperience [25], nous voulons étudier la corrélation entre la qualité du signal réseau et la qualité de la communication vocale. Dans cette application (cf. listing 3.6), nous voulons montrer deux nouvelles propriétés de notre interface de programmation qui sont i) sa capacité à pourvoir adapter la séquence des questions d’un questionnaire en fonction des premières réponses d’un utilisateur et ii) combiner une collecte opportuniste et participative Dans la première partie du script (ligne 1-6), nous collectons la force du signal réseau GSM lorsque l’utilisateur est en situation de mobilité. Afin d’effectuer un retour sur les données collectées, nous insérons un nouveau point dans la visualisation proposée (ligne 6). Dans la deuxième partie du script (ligne 8-14), nous définissons un questionnaire et ajoutons deux questions relatives à la qualité d’une communication vocale. La première question consiste à demander la qualité de sa communication vocale. La deuxième consiste à lui demander pourquoi le participant a considéré que la communication a été mauvaise. Nous définissons ensuite l’enchaînement des questions (ligne 15-18) qui consiste à proposer uniquement la deuxième question uniquement si l’utilisateur a répondu une réponse spécifique à la première question. Ensuite, nous proposons le questionnaire lorsque l’utilisateur a terminé une communication vocale. 1 $location.onLocationChanged(function(event){ 2 $trace.add({ 3 latlng : [event.latitude,event.longitute], 4 signal : $telephony.signalStrength() 5 }) 6 }) 7 818 var qualitySurvey = $survey.create() 9 qualitySurvey.close("q1", 10 "Quelle a été la qualité de votre communication ?", 11 ["Trés Mauvaise", "Mauvaise", "Moyenne", "Bonne", "Excellente"]) 12 qualitySurvey.close("q2", 13 "Quel a été le probléme ?", 14 ["écho", "grésillement", "voix coupé"]) 15 qualitySurvey.then("q1",function(response){ 16 if (response == "Trés Mauvaise") 17 return "q2" 18 }) 19 20 $phone.onCallFinish(function(event){ 21 $survey.publish(qualitySurvey, function(content){ 22 $trace.add({ 23 latlng : $location.lastLocation(), 24 signal : $telephony.signalStrength(), 25 content : content 26 }) 27 })} Listing 3.6 – Exemple d’application participative Exploiter des capteurs externes Figure 14 – Flux de données de l’expérience Manipulation de Lego NXT Dans cette expérience, nous montrons que notre interface de programmation peut également être utilisée pour interagir avec des capteurs externes, afin de collecter des données qui ne peuvent pas être initialement capturées avec les capteurs initialement inclus dans les dispositifs mobiles. Cette expérience exploite les capteurs intégrés d’un robot Lego Mindstorms NXT (c.-à-d. capteur de contact, d’ultrason, de température et de pression atmosphérique), et permet également d’interagir avec le moteur du robot afin d’en prendre le contrôle à partir de la tâche de collecte. 82Comme le montre la figure 14, l’expérience est composée de deux scripts : NXT.js et Task.js décris par le listing 3.7. Le rôle du premier script est de faire une abstraction avec les différentes fonctionnalités des robots NXT. Ce script communique avec la façade responsable de l’interface Bluetooth, pour établir une connexion avec le robot et le manipuler à distance. Ce script peut être ensuite intégré dans le script Task.js en tant que librairie (ligne 1). Dans cet exemple, nous établissons une connexion avec un robot NXT à proximité (ligne 8), et déclenchons les moteurs du robot pour le faire avancer. Nous réagissons également lorsque le robot rencontre un obstacle pour le faire changer de direction (ligne 11-13). Les lignes (15-22) permettent ensuite de collecter des données capturées par les capteurs du dispositif mobile (par ex. GPS) et des capteurs du robot NXT (c.-à-d. pression atmosphérique et température) lorsqu’il se déplace. 1 var nxt = require("NXT.js"); 2 3 var change_direction = function(){ 4 nxt.move_back() 5 nxt.turn_left({ ’angle’ : 45 * random(), ’duration’ : ’2s’}) 6 nxt.move_forward() 7 } 8 nxt.onConnect({’timeout’: ’30s’},function(){ 9 nxt.move_forward() 10 11 nxt.onTouch(function(){ 12 change_direction() 13 }) 14 15 $location.onLocationChanged({provider : ["network"]},function(event){ 16 $trace.add({ 17 latlng : [event.latitude,event.longitude], 18 pressure : nxt.pressure(), 19 temperature : nxt.temperature() 20 }) 21 }) 22 }) Listing 3.7 – Tâche de collecte : Manipulation de Lego NXT Inférence Contextuelle Dans cette dernière expérience, l’objectif est de montrer que APISENSE® peut également être utilisé pour rapidement prototype et valider empiriquement des algorithmes contextuels. Dans ce scénario, nous voulons mettre en place un modèle d’apprentissage permettant de reconnaître l’activité d’un utilisateur (c.-à-d. assis, debout, marche, courir, monter ou descendre des escaliers). L’idée générale de l’approche est d’observer 83les données transmises par le capteur d’accélération afin de déterminer l’activité de l’utilisateur. Le script décrit dans le listing 3.8 implémente l’algorithme initialement proposé en [37]. 1 var classes = ["walk","jog","stand", "sit", "up", "down"]; 2 var current = 0; var buffer = new Array(); 3 var model = weka.newModel(["avrX","avrY",...], classes); 4 var filter = "|(dx>"+delta+")(dy>"+delta+")(dz>"+delta+")"; 5 6 var input = $accelerometer.onChange(filter, 7 function(acc) { buffer.push(acc) }); 8 9 var learn = time.schedule({ period: ’5s’ }, function(t) { 10 if (model.learn(classes[current]) >= threshold) { 11 current++; 12 } 13 if (current < classes.length) { // Learning phase 14 input.suspend(); 15 var output = $dialog.display( 16 { message: "Select movement", spinner: classes }); 17 model.record(attributes(buffer), output); 18 sleep(’2s’); 19 buffer = new Array(); 20 input.resume(); 21 } else { // Exploitation phase 22 dialog.display({message: "Learning phase completed"}); 23 learn.cancel(); 24 model.setClassifier("NAIVE_BAYES"); 25 time.schedule({ period: ’5s’ }, function(t) { 26 trace.add({ 27 position: model.evaluate(attributes(buffer)), 28 stats: model.statistics() }); 29 buffer = new Array(); 30 } } }); Listing 3.8 – Tâche de collecte : Inférence Contextuelle. Le script se décompose en deux phases : i) une phase d’apprentissage et ii) une phase d’exploitation. Pour réaliser la phase d’apprentissage, nous avons intégré un algorithme d’apprentissage [44] implémenté en Java dans l’intergiciel mobile, et nous avons ajouté une façade pour utiliser ses fonctionnalités à partir du script. Durant la phase d’apprentissage, le script génère une boite de dialogue demandant à l’utilisateur de répéter des mouvements spécifiques. Lorsque l’utilisateur exécute les mouvements demandés, nous enregistrons les données d’accélérations selon les trois axes, et calculons des métriques (c.-à-d. moyenne, l’écart type, etc. ) sur les valeurs obtenues. Ces métriques sont ensuite insérées dans l’algorithme d’apprentissage et le mouvement qui à été effectué. Une fois que suffisamment de données ont été insérées dans le modèle d’apprentissage, le 84Predicted Class Acc (%) Walk Jog Stand Sit Up Down Walk 66 0 4 0 0 0 94,3 Jog 0 21 0 0 0 0 100 Stand 4 0 40 0 0 0 90,9 Sit 0 0 2 83 0 0 97,6 Up stair 0 0 0 0 22 0 100 Down stair 0 0 0 0 0 11 100 Table 8 – Tableau décrivant la qualité du système de classification script passe en phase d’exploitation. Dans cette phase, nous évaluons, toutes les cinq secondes, les métriques des données d’accélération dans le modèle d’apprentissage. Le résultat correspondant au mouvement de l’utilisateur et ensuite sauvegardé avec les statistiques du modèle obtenu pour les reporté sur le serveur. Le tableau 8 reporte la matrice de confusion décrivant la qualité du système de classification obtenue par un utilisateur durant cette expérience. La matrice illustre le nombre de mouvements effectués durant cette expérience, et la haute précision des prédictions obtenues pour chacun des mouvements. Discussion Dans cette sous-section, nous discutons de l’expressivité et la complexité des approches décrites dans l’état de l’art avec APISENSE®. Nous utilisons le nombre de lignes de code pour comparer la complexité avec deux applications de collecte couvrant les deux formes d’acquisition de données qui sont la collecte opportuniste (application Wifi-Bluetooth Scanner) et participative (application Citoyen Journaliste). Le tableau 9 présente le nombre de lignes de code nécessaires pour développer ces applications. Le symbole X signifie que l’application ne peut pas être exprimée et le symbole ? signifie que l’application est réalisable, mais que nous n’avons pas d’information sur le nombre de lignes de code nécessaire avec l’approche concernée. En terme de lignes de code, APISENSE® est beaucoup plus concis (4 lignes) que les approches utilisant le langage déclaratif XML pour concevoir une application. C’est la cas avec MyExperience (27 lignes) et Medusa (45 lignes) pour l’application Citoyen Journaliste. De plus ces deux dernières approches ne supportent la définition d’application de collecte purement opportuniste comme l’application Wifi-Blutooth 85Scanner. Même si la concision de notre code est à peu près similaire à Anonysense (7 lignes de code) et Pogo (6 lignes de code), notre approche comporte de nombreux avantages comparés à ces approches. Par apport à Anonysense, qui utilise un DSL pour le développement des applications, le langage JavaScript nous permet d’avoir une plus grande flexibilité pour concevoir des traitements plus complexes, et surtout nous permet de facilement réutiliser du code déjà existant, comme nous l’avons montré dans l’application présentée en sous-section (cf. 3.5.1). Par rapport à Pogo, utilisant également une interface de programmation basée sur JavaScript, notre interface de programmation supporte les tâches de collecte de données participative qui n’est pas possible avec l’interface proposée par Pogo. La seule approche proposée supportant la collecte opportuniste et participative est PRISM, qui propose le déploiement d’applications de collecte écrites en code natif. Cependant PRISM ne propose pas d’abstraction pour faciliter le développement de ses applications, nécessitant une expertise approfondie en développement mobile. L’application Citoyen Journaliste nécessite par exemple 330 lignes de code. En outre, le développement natif des applications les rend exclusives pour un OS mobile, demandant par conséquent d’étudier et développer une nouvelle version de l’application pour supporter l’hétérogénéité des OS disponible. Nous avons présenté dans cette section un ensemble d’applications réalisables avec APISENSE®. Nous pensons que APISENSE® propose un bon compromis entre toutes les approches proposée dans l’état de l’art, supportant la collecte opportuniste (application Wifi/Blutooth Scanner), participative (application Citoyen Journaliste), ou une combinaison des deux (application Qualité Réseau) tout en fournissant une abstraction complète des technologies mobiles. En proposant une interface de programmation au-dessus de JavaScript, APISENSE® permet également de définir des traitements complexes (application Inférence contextuelle), et faciliter la réutilisation de code déjà existant (application Exploiter des capteurs externes). Nous pensons que la réutilisation est un aspect fondamental pour le succès APISENSE®, favorisant son utilisation par de nombreux acteurs académiques ou industriels, avec des niveaux d’expertises différents dans la collecte de données. En effet, les experts du domaine peuvent proposer des modules ou algorithmes complexes, utilisant les capteurs des dispositifs pour inférer des informations de haut niveau (par ex. activité de l’utilisateur, mode de transport), ou encore utiliser intelligemment les différents capteurs pour réduire la consommation énergétique des applications de collecte dans un contexte spécifique [14]. Ces modules pourront être ensuite réutilisés par des utilisateurs non experts. Et finalement, l’utilisation de JavaScript permet également de supporter l’hétérogénéité des OS mobiles 86Wifi-Blutooth Scanner Citoyen Journaliste APISENSE 4 9 Medusa [55] X 45 MyExperience [25] X 27 Anonysense [62] 5 X Pogo [6] 4 X PRISM [16] ? 330 Table 9 – Comparaison de l’expressivité et du nombre de lignes de code pour s’affranchir d’étudier et développer une nouvelle application pour chaque OS disponible. 3.5.2 Coût énergétique d’une expérience de collecte Dans cette section, nous comparons la consommation énergétique de notre prototype réalisé sur Android avec Funf [1], une application présentée dans l’état de l’art APISENSE® ( section 2.3.1, page 34 ). Nous rappelons que Funf est un outil permettant de générer des applications natives Android à la carte. Pour réaliser cette expérience, nous avons exécuté chaque application durant 24 heures, sur un Nexus-S réinitialisée à une configuration par défaut, pour limiter le bruit qui peut être induit par d’autres applications. Chaque application est configurée pour collecter toutes les 10 minutes des informations de la batterie du dispositif mobile. Le résultat de cette expérience est illustré par la figure 15 Dans cette courbe, l’abscisse représente le temps, et l’ordonnée la tension en millivolt représentant le niveau de la batterie du dispositif. La tension d’un dispositif varie généralement entre 4200 millivolts, représentant 100% de niveau de batterie, et 3200 millivolts. Comparé à une application native (baseline), nous pouvons observer que le surcoût énergétique de notre prototype est faible comparé à une application native, et moins important que celui imposé par Funf. Bien que notre solution soit plus consommatrice qu’une application native, notre solution ne nécessite aucune expertise particulière de la plate-forme Android, et rend également transparent le déploiement de l’application et la propagation des données pour les développeurs. Comme la consommation énergétique dépend fortement de i) la nature de l’expé- rience, ii) du type de capteur utilisé et iii) du volume des données produit, nous avons réalisé une seconde expérience permettant d’estimer l’impact des différents capteurs 87 4100 4120 4140 4160 4180 4200 0 200 400 600 800 1000 1200 1400 Voltage (mV) Time (s) Android Native Application Funf Bee.sense Figure 15 – Impact d’APISENSE sur la consommation énergétique sur la consommation de la batterie (cf. figure 16). Pour cette expérience, nous avons développé trois scripts, qui ont été exécutés séparément sur trois dispositifs mobiles. Le premier script (APISENSE + Bluetooth), déclenche un scan toutes les minutes et collecte le niveau de la batterie aussi bien que le résultat du scan. Le second (APISENSE + GPS) collecte également toutes les minutes les données GPS tandis que le dernier script collecte des données relatives au point d’accès WIFI. Cette expérience démontre que même avec un stress important sur les capteurs, il est possible de collecter des données durant une journée normale de travail sans avoir à recharger le dispositif mobile (40% d’énergie consommée après 10 Heures d’activation du GPS). 3.6 conclusion Le développement d’applications mobiles dédiées à la collecte de données est un processus long et complexe. Généralement, afin de déployer l’application vers un grand nombre d’utilisateurs, plusieurs applications ont besoin d’être développées pour faire face à la diversité des plate-formes mobiles disponibles. D’autre part, ces applications doivent généralement prendre en compte des aspects non fonctionnels tels que la 88 0 20 40 60 80 100 0 100 200 300 400 500 Battery level (%) Time (min) APISENSE APISENSE + GPS APISENSE + Bluetooth APISENSE + WiFi Figure 16 – Impact des capteurs sur la consommation énergétique protection de la vie privée des utilisateurs ainsi que la consommation énergétique de ces applications. Dans ce chapitre, nous avons présenté notre approche pour diminuer le coût lié aux développements d’applications mobiles dédiées à la collecte de données. Plus particulièrement, nous avons présenté dans un premier temps une interface de programmation de haut niveau pour la définition d’une application de collecte. L’interface proposée a été conçue pour i) faire face à la diversité des applications de collecte (i.e. participative, opportuniste), ii) supporter l’hétérogénéité des plate-formes mobiles iii) tout en permettant de s’abstraire de la complexité liée au développement mobile. Nous avons ensuite présenté l’environnement mobile dédié aux utilisateurs en charge de l’exécution de l’interface proposée. Nous avons particulièrement présenté son architecture composée de quatre couches pour i) le déploiement et la propagation des données, ii) permettre aux utilisateurs de contrôler des les données collectées sur leurs dispositifs, iii) l’exécution des applications de collecte et iv) limiter la consommation énergétique liée à l’exécution d’une application de collecte. Dans le chapitre suivant, nous allons présenter l’environnement serveur de notre architecture. 894 C O L L E C T E R É PA RT I E D E D O N N É E S Sommaire 4.1 Introduction 91 4.2 Infrastructure répartie de traitement des données 92 4.3 Architecture du serveur central 94 4.3.1 L’enregistrement des participants 95 4.3.2 L’enregistrement des expériences de collecte 96 4.3.3 Déploiement des tâches de collecte 98 4.3.4 Gestion des nœuds de collecte 99 4.4 Architecture des noeuds de collecte 100 4.4.1 Modèle de caractèristiques d’une campagne de collecte 101 4.4.2 Création d’une nouvelle campagne 107 4.4.3 Intéraction entre les composants 110 4.4.4 Extension des nœuds de collecte 112 4.5 Campagne de collecte communautaire 113 4.5.1 Extension du modèle de programmation 116 4.5.2 Coordonner l’exécution des tâches de collecte 119 4.6 Conclusion 124 4.1 introduction L’objectif des travaux de cette thèse est de proposer une solution générique, facilitant le développement et le déploiement de campagnes de collecte de données à travers des dispositifs mobiles. Dans le chapitre précédent, nous avons présenté l’environnement mobile de APISENSE®, la plate-forme résultante des travaux de cette thèse. Nous avons proposé un modèle de programmation facilitant le développement d’applications mobiles dédiées à la collecte de données et un intergiciel déployé au préalable sur les dispositifs mobiles, dédié à leurs exécutions. 91Dans ce chapitre, nous présentons notre deuxième contribution concernant l’architecture et l’implémentation de l’environnement serveur de APISENSE®, responsable du déploiement des campagnes de collecte, de la persistance des données ainsi que leurs analyses. Ce chapitre adresse particulièrement deux défis introduit en début de manuscrit, qui sont la généralité de la plate-forme, concernant la capacité de la plate-forme à supporter une grande diversité de campagnes de collecte ainsi que son passage à l’échelle. structure du chapitre La suite du chapitre est organisée comme suit : en section 4.2, nous présentons une vue d’ensemble de l’architecture proposée, et discutons des bénéfices de cette architecture par rapport aux solutions de l’état de l’art. Dans les sections 4.3 et 4.4, nous présentons en détail l’architecture des différentes entités logicielles de APISENSE®, ainsi que les méthodes de conceptions et de modélisations utilisées. Dans le chapitre 4.5, nous proposons une optimisation améliorant le passage à l’échelle du système avant de conclure en section 4.6. 4.2 infrastructure répartie de traitement des données Avant de présenter en détail l’architecture proposée dans ce chapitre, nous présentons ici une vue globale de la plate-forme APISENSE®. La figure 17 donne un aperçu simpli- fié des différentes entités logicielles qui la composent, et leurs principales interactions. L’architecture est principalement composée de trois parties distinctes : un ensemble de nœuds de collecte (DataGathering Node), un serveur central (Central Server) et un ensemble de nœuds mobiles avec une application dédiée installée au préalable par les participants. Nous avons déjà présenté les noeuds mobiles dans le chapitre précédent (cf. 3.4, page 68 ). APISENSE® adopte une architecture décentralisée, où le serveur central est assumé comme le tiers de confiance de la plate-forme. Plus particulièrement, le serveur central est responsable du déploiement des tâches de collecte soumises par les nœuds de collecte, vers les nœuds mobiles du système. Afin de fournir un déploiement adapté (par ex. zone géographique, type de dispositif mobile), le serveur central a besoin de maintenir à jour un ensemble d’informations, sur les dispositifs mobiles disponibles pour exécuter des tâches de collecte. Dans ce contexte, nous supposons que le serveur central est géré par un acteur de confiance, qui peut être une organisation publique, ou une structure de recherche. 92Figure 17 – Vue d’ensemble d’APISENSE® La gestion des campagnes de collecte est assurée par les nœuds de collecte, qui peuvent être dédiés à un ou plusieurs utilisateurs. Typiquement, la gestion d’une campagne de collecte comporte quatre phases : i) définir une tâche de collecte, ii) recruter un sous-ensemble de dispositifs mobiles, iii) assurer la persistances des données collectées (c.-à-d. dans une base de données) lors de l’exécution de la tâche iv), exploiter les données. Pour réaliser ces différentes étapes, un nœud de collecte propose un environnement fournissant un ensemble de services qui peuvent être entièrement configurés par les utilisateurs. La configuration consiste en la sélection de modules implémentant la logique dédiée à la réalisation d’une étape d’une campagne de collecte. Dans ce cadre, les modules proposés peuvent implémenter différentes stratégies selon la nature de la campagne. Par exemple, la phase de collecte peut inclure un modèle particulier d’anonymisation des données pour assurer la confidentialité des participants. Ce choix de conception, séparant les préoccupations du déploiement ainsi que la collecte et l’analyse des données, nous permet de rompre avec le syndrome de l’enfermement propriétaire. Premièrement, en offrant la possibilité aux utilisateurs de déployer leurs nœuds de collecte sur l’infrastructure de leur choix, leur permettant 93ainsi de garder un contrôle total sur les données collectées durant leurs campagnes. Les nœuds de collecte peuvent ainsi être déployés vers une infrastructure publique ou privée, en fonction des préoccupations éthiques ou légales en rapport avec le stockage des données. De plus, les nœuds de collecte des utilisateurs sont complètement isolés les uns des autres, améliorant la sécurité et la disponibilité de leurs environnements, permettant d’effectuer des traitements lourds sur les données collectées sans affecter les autres instances. Et finalement, en gardant une entité centrale (c.-à-d. le serveur central), cela permet aux nouveaux utilisateurs de bénéficier d’un ensemble de participants déjà disponibles pour exécuter leurs tâches de collecte, s’affranchissant ainsi d’une longue période de recrutement. Après avoir présenté une vue globale de la plate-forme APISENSE®, nous présentons dans la suite de ce chapitre l’architecture et les services fournis par le serveur central (cf. section 4.3), ainsi que les nœuds de collecte (cf. section 4.4). 4.3 architecture du serveur central Comme nous l’avons présenté dans la section précédente, APISENSE® est une plate-forme répartie dédiée aux déploiements et à l’exécution de campagnes de collectes de données. Afin de fournir une plate-forme modulaire, facilement extensible et configurable, APISENSE® est une plate-forme orientée service, utilisant un modèle à composants logiciels pour modéliser les différentes applications serveur qui la composent. Plus spécifiquement, APISENSE® est basée sur le modèle SCA [46], un standard initié par le consortium OASIS, dédié à la modélisation d’architectures tout en étant indépendant des langages de programmation, des protocoles de communication, des langages de description d’interface et des propriétés non fonctionnelles. La figure 18 illustre le modèle SCA du serveur central. Dans SCA, les bases des constructions sont les composants logiciels, qui peuvent offrir des services, ou solliciter d’autres composants via des références. Les services ainsi que les références peuvent être connectés à l’aide de fils (wire en anglais). SCA spécifie un modèle à composants hiérarchiques, laissant la possibilité d’implémenter un composant par un langage de programmation, ou par un ensemble de sous composants. Dans le dernier cas, ces composants sont appelés composite. Afin de supporter l’interaction entre des services distants, SCA spécifie la notion de communication distante (binding), permettant de décrire 94le protocole que le client devra utiliser pour invoquer un service. Dans l’architecture SCA proposée, les composants ParticipantFrontend, GatheringNodeFrontend ScientistFrontend et représentent les points d’entrés pour les différents acteurs qui interagissent avec le serveur central. Ces composants exposent leurs services en tant que ressource REST, accessibles via le protocole HTTP. Plus particulièrement, ces composants fournissent quatre types services nécessaires au fonctionnement du système, dédié à : L’enregistrement des participants : ce service (participant registration) est accessible par les dispositifs mobiles, permettant l’enregistrement d’un nouveau participant volontaire pour exécuter de nouvelles tâches de collecte. L’enregistrement des expériences de collecte : ce service (deploy scripts) est accessible par les nœuds de collecte, et permet aux utilisateurs d’enregistrer de nouvelles expériences de collecte. Le déploiement des expériences de collecte : ces services (list experiment, download script, recruit participants) assurent la propagation des expériences vers les terminaux mobiles. La gestion des nœuds de collecte : ces services (user registration, deploy data gathering node, downloads modules) représentent les points d’entré dans le système pour les utilisateurs voulant créer et configurer un nœud de collecte. Nous présentons dans la suite de cette section les services fournis par ces composants. 4.3.1 L’enregistrement des participants L’enregistrement des participants permet d’informer le serveur central de la présence et de la disponibilité des participants pour exécuter des tâches de collecte. Ce service, fourni par le composant DeploymentService, est invoqué par les nœuds mobiles lors de leurs installations sur les terminaux mobiles des participants. L’inscription inclut des informations statiques sur la configuration matérielle des terminaux des participants, ainsi que des informations confidentielles. Les informations matérielles comprennent le type du terminal (par ex. smartphone, tablette), le système d’exploitation utilisé (par ex. Android, iOS) ainsi que l’ensemble des capteurs embarqués dans le terminal. Les informations confidentielles comprennent par défaut le nom, le prénom et une adresse électronique valide. Cependant, le participant a la possibilité de raffiner ces informations, volontairement, en indiquant des lieux géographiques — à gros grain (par ex. pays, région ou ville) — où il évolue, son statut ainsi que son âge. Ces informations sont ensuite stockées dans une base de données, et serviront 95Figure 18 – Architecture SCA du serveur central lors de la phase de déploiement. Pour des raisons de confidentialité, elles pourront être accessibles uniquement par le serveur central, c’est-à-dire qu’elles ne seront pas accessibles par les nœuds de collecte du système. 4.3.2 L’enregistrement des expériences de collecte Accessible par les nœuds de collecte du système, ce service, fourni par le composant Recruitment, permet l’enregistrement d’une expérience de collecte auprès du serveur central. Cette enregistrement comprend deux catégories d’éléments. La première correspond a un ensemble de fichiers JavaScript définissant la tâche de collecte (cf. section 3.3, page 59 ). La deuxième catégorie définit les propriétés de l’expérience et également ses exigences en matière de déploiement. Ces propriétés sont définies par un ensemble de clés/valeurs utilisant le formalisme JSON. Comme le montre le tableau 10, trois catégories de propriétés sont actuellement supportées : global : définit principalement des informations générales sur l’expérience de collecte. Ces propriétés ne sont pas interprétées par le serveur central, mais 96propriété nom description global name Nom de l’expérience description Description du but de la collecte de données version Version de l’expérience de collecte privacy Description du modèle de protection de la vie privée incentive Description du modèle de récompense nodeurl URL du nœud de collecte de collecte recruitment sensors Liste des capteurs utilisées par la tâche de collecte max_numbers Nombre maximum de participants admis dans l’expé- rience de collecte area Zone globale de collecte (par ex. pays, région, ville) platform Liste de plate-formes mobiles context area Liste de zone géographique. period Liste de période journalière Table 10 – Propriétés définissant une expérience de collecte permettent d’informer les participants sur les objectifs de l’expérience (description), le modèle de confidentialité (privacy) et de récompense (incentive). recruit : permet de définir les participants autorisés à participer à une expérience de collecte. Ces propriétés permettent de limiter le nombre de participants impliqué dans l’expérience (max_numbers), de sélectionner des participants évoluant dans un lieu géographique (area) — à gros grains (par ex. pays, région ou ville) —, disposant d’un terminal ayant les capteurs nécessaires pour l’exécution de la tâche de collecte (sensors) et disposant d’une plate-forme mobile spécifique (platform). context : permet de spécifier le contexte d’exécution de la tâche de collecte une fois propagée vers les terminaux mobiles. Dans ce cadre, les propriétés permettent de spécifier une liste de zones géographiques (area) — région circulaire définie par les coordonnées du centre et un rayon exprimé en mètres —, et une liste de périodes journalières (period) dans lesquelles l’expérience doit s’exécuter. Ces propriétés seront ensuite interprétées par les nœuds mobiles, qui seront responsables de déclencher ou de stopper l’exécution de la tâche de collecte (cf. section 3.4.2, page 72 ). 974.3.3 Déploiement des tâches de collecte Une fois l’expérience enregistrée, deux stratégies principales peuvent être considérées pour propager les tâches de collecte vers les nœuds mobiles des participants [16]. La première approche (push-based) consiste à déployer automatiquement l’expérience de collecte auprès des utilisateurs mobiles. Dans la deuxième (pull-based), le nœud mobile télécharge la tâche de collecte après une action volontaire du participant, ou en effectuant une requête périodiquement vers le serveur pour voir si une nouvelle expérience est disponible [62]. Dans ce cadre le serveur central supportent ces deux approches pour la propagation des tâches de collecte. Approche pull-based La première approche (pull-based) est supportée par les composants Pull, DeploymentService et PropertyMatcher. Dans un premier temps, les participants peuvent accéder au service proposé par le Pull, via leur dispositif mobile, pour récupérer une liste d’expériences mises à disposition par les utilisateurs. Dans ce cadre, le PropertyMatcher détermine les expériences accessibles pour le participant, en faisant la correspondance entre les propriétés de recrutement des expériences, et des informations partagées par le participant lors de son inscription. Des informations générales sont fournies pour chaque expérience accessible, permettant au participant de visualiser le but de l’expérience de collecte, du modèle de confidentialité et de récompense ainsi que les capteurs utilisés lors de son exécution. À partir de ces informations, le participant a alors la possibilité de s’enregistrer à une expérience. Lors de la souscription, un identifiant anonyme est alors généré. Cet identifiant est ensuite envoyé au nœud de collecte ayant initié l’expérience et à l’agent mobile, pour l’avertir d’un nouveau recrutement dans l’expérience. Dans ce cadre, l’identifiant anonyme servira pour toutes les communications entre les nœuds de collecte et les participants, comme lors de la propagation des données. Cela permet en effet aux participants de ne pas révéler leurs identités réelles lors des interactions avec les nœuds de collecte, assurant ainsi une première couche d’anonymisation. Une fois la souscription terminée, l’agent mobile peut alors télécharger la tâche de collecte associée et déclencher son exécution. Approche push-based La deuxième approche (push-based) est supportée par les composants Push, et également par le composant PropertyMatcher. Dans ce cadre, le Push fournit un service, 98accessible par les nœuds de collecte, pour pousser directement une tâche de collecte vers les agents mobiles des participants. Ce processus comprend deux étapes. La première consiste à envoyer un message vers les agents mobiles acceptant ce mode de déploiement, et correspondant aux propriétés de l’expérience. La deuxième étape est ensuite similaire à l’approche présentée ci-dessus, c’est-à-dire composée de la phase de souscription et de téléchargement de la tâche de collecte. Pour établir ce type de propagation, il est nécessaire de supporter des communications dans le sens serveur vers terminaux mobiles. Typiquement, ce type de communication peut être effectué en utilisant des services dédiés, proposés par les fournisseurs des OS mobiles tels que GCM (Google Cloud Messaging) pour Android ou APNs (Apple Push Notification service) pour iOS. Dans ce contexte, le composant PushService est en charge de l’interaction avec ces services pour envoyer des messages vers les terminaux mobiles selon l’OS mobile visé. Indépendamment de l’approche utilisée, le composant Push permet également aux nœuds de collecte de propager des messages aux utilisateurs mobiles s’étant inscrits à leurs expériences. Ces messages peuvent être propagés soit à un participant en particulier, ou alors à l’ensemble des participants ayant souscrits à l’expérience. Deux types de messages peuvent être transmis : update : Message indiquant la disponibilité d’une nouvelle mise à jour de l’expérience. Dans ce cadre, ce message déclenchera le téléchargement de la nouvelle version de l’expérience par les nœuds mobiles. Cela permet de rapidement adapter le comportement de l’expérience une fois déployée. notification : Ces messages permettent aux utilisateurs de notifier l’état d’avancement de l’expérience en cours, en partageant des statistiques globales des données collectées avec tous les participants. 4.3.4 Gestion des nœuds de collecte Les derniers services présentés sont responsables de la création et de la configuration des nœuds de collecte. Un utilisateur voulant évoluer dans APISENSE®, peut se connecter au service géré par le composant DataGatheringRepository via une interface web, et déclencher le téléchargement de leur propre nœud de collecte. Celui-ci pourra ensuite être déployé vers une infrastructure publique ou privée, selon les exigences des utilisateurs. 99Un nœud de collecte peut être téléchargé suivant deux formats : 1. En tant qu’image virtuelle pré-configurée, permettant son déploiement au-dessus d’un environnement virtualisé. Dans ce cadre, l’image virtuelle comprend toute la pile logicielle nécessaire au bon fonctionnement du nœud de collecte. Plus particulièrement, elle est composée d’une distribution Linux, d’une machine virtuelle Java (JVM), d’une base de données MongoDb 1 pour le stockage des données, et FraSCAti responsable de l’exécution des composants SCA du nœud de collecte. 2. En tant qu’archive web (.war), permettant son déploiement directement au-dessus d’un serveur d’application (c.-à-d. Apache Tomcat). Le service fourni par le ComponentRepository propose un ensemble de composants modulaires, dédiés à la configuration d’un nœud de collecte. Les utilisateurs peuvent accéder à ce service via leur nœud de collecte nouvellement déployé, pour télécharger et assembler des composants dans leur nœud de collecte en fonction de la nature des expériences qu’ils veulent mener. Nous présentons ce point plus en détail dans la section suivante. 4.4 architecture des noeuds de collecte Dans la section précédente, nous avons présenté l’architecture et les services fournis par le serveur central de la plate-forme APISENSE®. Dans ce chapitre, nous présentons l’architecture des nœuds de collecte, et plus particulièrement comment nous tirons profit du modèle SCA pour fournir des nœuds de collecte facilement configurables. Les nœuds de collecte sont les entités logicielles de notre système responsables de la gestion des campagnes de collecte des utilisateurs. Nous rappelons qu’une campagne est essentiellement composée de quatre étapes qui consiste : 1. à définir une tâche de collecte via une interface de programmation dédiée, 2. à publier la tâche de collecte auprès du serveur central pour le recrutement des participants, 3. à assurer la persistance des données collectées par les dispositifs, 4. et finalement à analyser et exploiter les données collectées Par ailleurs, une expérience peut également comporter un modèle de protection de la vie privée des participants, ainsi qu’un modèle de récompense. 1. https://www.mongodb.org 100Pour faire face à la diversité des expériences qui peuvent être menées, les nœuds de collecte peuvent être entièrement configurés selon la nature d’une expérience. Cette configuration consiste essentiellement à assembler un ensemble de composants SCA, où chaque composant est responsable de la logique fonctionnelle d’une étape d’une expérience. Dans ce contexte, plusieurs composants peuvent être dédiés à une même étape, représentant la partie variable d’une configuration. Pour guider les utilisateurs dans ce processus d’assemblage, nous avons adopté une approche basée sur l’ingénierie des Lignes de Produits Logiciels (LDPs) [12, 52] (en anglais SPL pour Software Product Line). Typiquement, l’idée est i) de définir un Modèle de Caractéristiques (MC) [32](en anglais FM pour Feature Model) qui capture les caractéristiques communes et les points de variabilité d’une configuration d’une expérience, ii) d’implémenter le MC comme un assemblage de composants SCA et de proposer le MC aux utilisateurs pour leurs permettre de sélectionner les composants selon la nature des expériences qu’ils veulent mener. Dans la suite de cette section, nous présentons le MC dédié à la configuration des expériences de collecte en sous-section 4.4.1, un exemple d’architecture SCA généré et leurs interactions permettant la réalisation d’une campagne de collecte, et nous finissons par présenter le mécanisme d’extension permettant d’adresser les exigences non anticipées. 4.4.1 Modèle de caractèristiques d’une campagne de collecte La notion de Modèle de Caractéristiques (MC), introduite par Kang et al. [32], est une technique de modélisation permettant la description d’un ensemble d’artéfacts réutilisables, qui peuvent être utilisés pour créer une famille de logiciels qui possède des caractéristiques communes, mais exhibant également des différences. Le MC représente ainsi l’ensemble des choix proposés à un utilisateur pour lui permettre de configurer un logiciel spécifique à ses besoins. Typiquement, un MC est spécifié sous forme d’arbre, dont les nœuds représentent les caractéristiques d’un logiciel et les arcs spécifient des liens de composition entre les caractéristiques. Trois catégories de caractéristique peuvent être définies : les caractéristiques obligatoires, les caractéristiques optionnelles et les caractéristiques alternatives. Additionnellement, des règles de composition peuvent être définies, établissant une 101relation entre les caractéristiques. Ces règles peuvent prendre deux formes i) une caractéristique qui nécessite la sélection d’une autre caractéristique (définissant une interdépendance entre les caractéristiques), et ii) la sélection d’une caractéristique peut exclure la sélection d’une autre. Dans notre contexte d’utilisation, nous utilisons cette technique pour modéliser les différents choix proposés aux utilisateurs pour leur permettre de configurer les services d’une campagne de collecte selon les spécificités de celle-ci. La figure 19 illustre le MC dédié à la configuration d’une campagne de collecte. Typiquement, le MC identifie principalement cinq points de variabilités pour i) configurer l’environnement de développement des tâches de collecte (SensingTask Description), ii) choisir un modèle de recrutement des utilisateurs (Recruitment), iii) choisir une série de traitements sur les données collectées avant leurs insertions dans la base de données (OnlineProcessing), iv) spécifier l’indexation des données dans la base de données (Collector), v) exposer des services au-dessus des données collectées (Service). Nous décrivons à présent brièvement ces différents points de variabilités et les caractéristiques actuellement supportées. Figure 19 – Modèle de caractéristiques d’une campagne de collecte 102SensingTask Description Ce premier point de variabilité permet aux utilisateurs de sélectionner l’interface web dédiée aux développements des tâches de collecte vue dans le chapitre précédent (cf. section 3.3). La première interface, définie par la caractéristique CodeEditor, propose un éditeur de code en ligne — avec coloration syntaxique, complétion de code, etc. — permettant le développement des tâches de collecte directement en JavaScript. La deuxième interface, définie par la caractéristique Form, quant à elle, fournit une interface web permettant le développement des tâches à partir d’un formulaire. Le formulaire permet principalement de spécifier le type de données à collecter (par ex. position, accéléromètre, périphérique Bluetooth) avec la fréquence de collecte pour chaque donnée (par ex. toutes les cinq minutes). Après validation du formulaire, un fichier JavaScript est généré à partir des choix effectués par l’utilisateur. Le formulaire permet de rendre accessible le développement des tâches pour des utilisateurs n’ayant aucune expertise en programmation. Cependant, le formulaire limite l’expressivité des tâches qui peuvent être développées, en définissant uniquement des tâches de collecte périodique de données. Nous prévoyons dans des travaux futurs de proposer des métaphores visuelles pour développer des tâches de collecte plus complexes, tout en permettant leur développement par des utilisateurs n’ayant aucune expertise en développement. Certains travaux ont déjà été proposés dans ce sens tels que Scratch [48, 58] ou Alice [15] ou plus récemment App Inventor 2 . Le principe de ces approches consiste à fournir un environnement intuitif, dans lequel on associe des composants visuellement pour définir le comportement d’une application. Recruitment Ce deuxième point de variabilité permet de sélectionner le modèle utilisé pour recruter un sous-ensemble de participants exécutant la tâche de collecte. Dans ce contexte, le recrutement consiste essentiellement à interagir avec les services du serveur central pour déployer la tâche de collecte et assurer sa mise à jour, définir un sous-ensemble de participants autorisés à l’exécuter et son contexte d’exécution. Les deux caractéristiques associées à ce point de variabilité (Individuel et Collaborative) permettent de faire face aux différentes échelles de collecte (cf. section 2.1.2) que sont la collecte personnelle et la collecte communautaire. La caractéristique Individuel propose un modèle simple de recrutement des participants dédié à la collecte personnelle de données, qui a généralement pour objectif de suivre l’activité d’un individu à travers le temps. Nous présentons plus en détail en 2. http://appinventor.mit.edu 103sous-section 4.4.4 ce modèle et les différentes interactions entre les nœuds mobiles, le serveur central et les nœuds de collecte nécessaires. La caractéristique Collaborative propose un modèle principalement dédié à la collecte communautaire de données, qui a généralement pour objectif de surveiller des phénomènes liés à l’environnement des participants (par ex. surveiller la qualité du signal réseau dans la ville de Paris). Nous décrirons plus en détail ce modèle dans la section 4.5. Online Processing Ce point de variabilité permet de définir un ensemble de traitements à effectuer sur les données collectées avant leurs insertions dans une base de données. Les traitements peuvent consister à calculer des statistiques globales sur les données collectées (caracté- ristique Statistique), calculer un modèle d’incitation pour récompenser les participants (point de variabilité Incentive), ou encore effectuer des traitements modifiant les données collectées pour assurer leurs confidentialités (point de variabilité Privacy). Incentive Ce point de variabilité définit le modèle de récompense de l’expérience de collecte. Typiquement, l’incitation peut prendre une grande variété de formes. Par exemple, ré- compenser les participants financièrement [41] pour les données partagées, ou transférer des mécanismes de jeux dans le contexte de la collection de données [69]. Généralement, un modèle de récompense a pour objectif d’augmenter la participation des utilisateurs, et de les motiver à partager des données plus pertinentes pour l’expérience. Actuellement, nous supportons un modèle de récompense [24] basé sur la quantité et la qualité des données partagée par des participants. Ce modèle est également utilisé dans des applications mobiles populaires telles que Waze 3 ou encore Foursquare 4 . Le modèle est basé sur le concept de récompense [69] qui peut prendre deux formes différentes. La première consiste à émuler une compétition, en effectuant un classement entre les participants. Dans ce cadre, le modèle peut être configuré par les utilisateurs, en attribuant des points selon le type de données partagées. Le deuxième permet d’attribuer des badges/trophées, en fonction du nombre de points remportés par les participants. 3. https://www.waze.com 4. https://foursquare.com 104Dans l’application mobile présentée dans le chapitre précédant, plusieurs mécanismes permettent aux participants de contrôler les données qui sont collectées par leur dispositif (cf. chapitre 3 sous-section 3.4.2, page 72 ). Ce mécanisme peut être utilisé par exemple par les participants pour empêcher l’application d’activer le GPS qui consomme beaucoup d’énergie. Dans ce cas, les utilisateurs peuvent contrebalancer l’énergie utilisée par les capteurs, et la sensibilité des données — d’un point de vue vie privée —, en attribuant plus de points selon les données collectées par les participants. Par exemple, le capteur GPS est bien connu pour fournir une grande précision pour déterminer la position d’un utilisateur, mais consomme beaucoup plus d’énergie que la géolocalisation GSM, moins précise. Dans ce contexte, pour inciter les participants à partager leurs capteurs GPS, plus de points peuvent être attribués aux données collectées par le GPS. Privacy Additionnellement, un modèle de confidentialité peut être intégré dans l’expérience de collecte. Dans ce cadre, les composants implémentant ces modèles sont responsables de l’assainissement des données reportées par les participants, avant leurs insertions dans la base de données. Actuellement nous supportons un modèle classique de perturbation [2], consistant à modifier les coordonnées spatiales et temporelles en y ajoutant une perturbation aléatoire. La perturbation est introduite par un bruit gaussien à l’intérieur d’une sphère de rayon r centré sur les coordonnées d’origine. Nous envisageons d’intégrer plusieurs modèles issus de l’état de l’art [11] tels que des modèles de dissimulation spatiale [64, 30, 62]. Collector Ce point de variabilité est responsable de la persistance ainsi que de l’indexation des données collectées dans une base de données. Actuellement, la persistance des données est effectuée avec la technologie MongoDB, une base de données non-relationnelle orientée documents. Dans notre cas d’utilisation, le principal bénéfice de cette technologie est de ne pas imposer un schéma spécifique pour sauvegarder les données. En effet, de nombreux systèmes [25, 22] utilisent des bases de données SQL qui nécessitent la définition de schéma statique pour structurer les données. Ce choix de conception limite alors la réutilisation du système nécessitant la sauvegarde de données ayant une structure non prévue dans le schéma défini au préalable. Dans ce cadre, MongoDB représente une technologie fournissant la flexibilité nécessaire pour faire face à l’hétérogénéité des données qui peuvent être collectées durant les expériences. 105Les données sont sérialisées sous la forme d’un tableau JSON. Dans ce cadre, l’utilisation du formalisme JSON fournit une grande flexibilité aux utilisateurs pour représenter les données, selon le type des capteurs impliqués dans la tâche de collecte. La structure des données est définie par les utilisateurs lors du développement de la tâche de collecte (cf. sous-section 3.3.3). Les métadonnées sont générées par l’application mobile, comportant l’identifiant unique de l’utilisateur — crée par le serveur central lors de l’enregistrement du participant dans l’expérience —, la version de la tâche de collecte ainsi que la date où les données ont été générées. Les utilisateurs ont également la possibilité de compléter ces méta-informations. Dans ce cadre, ces méta-informations peuvent être utilisées pour structurer les données dans la base de données, par exemple indexer les données par jour (caractéristique DateIndex), par utilisateur (caractéristique UserIndex) ou utiliser un index géographique (caractéristique GeoIndex) pour faciliter le traitement des données à caractère géographique. Service Le dernier point de variabilité permet de sélectionner des services responsables d’exposer les données après leurs sauvegardes dans la base de données. Actuellement, nous supportons des composants génériques qui permettent de fournir une interface web donnant un accès à la base de données (caractéristique Query), de visualiser des statistiques sur données collectées sous forme de graphe (caractéristique Chart), visualiser sous forme de carte (caractéristique Map) si l’indexation sélectionnée dans la partie précédente utilise un index géographique, ou alors d’exporter les données dans divers formats (point de variabilité Export) (c.-à-d. CSV, JSON, XML). Dans cette section, nous avons présenté notre approche pour permettre de faire à face à la diversité des campagnes de collecte qui peuvent être menées par les utilisateurs. Pour prendre en compte cette diversité, nous avons proposé de modéliser l’environnement responsable de la gestion d’une campagne comme une famille de produits à l’aide de Modèle de Caractéristique (MC). Le MC présenté permet de définir les points communs et également les différences relatives aux campagnes de collecte. Ces différences peuvent consister à utiliser différents modèles de confidentialité, de recrutement ou d’incitation selon la nature de l’expérience, choisir différentes façons pour développer les tâches de collecte selon le niveau de programmation des utilisateurs ou alors structurer et exposer les données collectées durant la campagne. Ainsi, le MC définit l’ensemble des choix présentés aux utilisateurs pour leur permettre de configurer leurs campagnes de collecte en fonction de leurs exigences. Dans la section 106suivante, nous décrivons comment un nœud de collecte génère un environnement assurant la gestion d’une campagne de collecte à partir des choix effectués par les utilisateurs et comment les utilisateurs peuvent étendre les nœuds de collecte pour faire face à des exigences non anticipées. 4.4.2 Création d’une nouvelle campagne Toutes les caractéristiques initialement introduites dans la section précédente sont associées à un composites SCA. La création d’une nouvelle campagne consiste donc à intégrer et à assembler dans l’architecture initiale du nœud de collecte (cf. figure 20) un ensemble de composite SCA. Dans ce cadre, le MC permet de spécifier l’ensemble des assemblages valides pour générer une nouvelle instance de campagne de collecte. Une fois déployé, un nœud de collecte (cf. figure 20) est composé de quatre composants génériques, dédiés à la création d’une nouvelle campagne : ExperimentManager, WebManager, ModuleManager et le ReconfigurationManager. Figure 20 – Architecture initiale d’un nœud de collecte Le point d’entrée de cette architecture est le composant ExperimentManager. Ce composant est responsable du déclenchement de la génération d’une nouvelle campagne. Pour lancer cette génération, ce dernier composant a besoin de trois informations : i) le nom de la campagne de collecte, ii) une description de l’objectif de la collecte, iii) et l’ensemble des caractéristiques sélectionnées dans le MC par les utilisateurs. La 107création d’une nouvelle campagne peut également s’effectuer à partir d’une interface web fournie par le composant WebManager. La figure 21 montre une vision simplifiée de la génération d’une nouvelle campagne. Figure 21 – Processus de génération d’une architecture SCA Une fois la sélection validée, en fonction des différentes contraintes exprimées dans le MC, le composant ExperimentManager procède alors aux téléchargements des différents composites associés aux caractéristiques sélectionnées, auprès du serveur central via le composant ModuleLibrary. Une fois les composites téléchargés, le composant ExperimentManager exploite alors les capacités d’introspection du moteur d’exécution SCA via le composant ReconfigurationManager pour instancier les composites téléchargés dans l’architecture du nœud de collecte. Par exemple, la figure 22 illustre une nouvelle instance générée à partir de la sélection des caractéristiques suivantes : CodeEditor, Individuel, Badge, Pertubation, userIndex, Query, Export-KML. Cette nouvelle instance expose ainsi de nouveaux services permettant 108Figure 22 – Architecture SCA d’une campagne de collecte 109d’éditer une tâche de collecte associée à la campagne (composant SensingTask :CodeEditor), de déployer cette tâche auprès du serveur central afin de recruter un ensemble de participants (composant Recruitement :Individuel), d’anonymiser et de sauvegarder les données collectées par les participants (composant Privacy :Perturbation et Collector :UserIndex), configurer le mécanisme de récompense (composant Incentive :Ranking) et finalement exploiter les données collecter (composant Service :Query et Service :Export :KML). Nous présentons de manière plus détaillée dans la section suivante comment ces composants interagissent entre eux lors d’une campagne de collecte configurée avec un modèle de recrutement Individuel. L’exécution d’une campagne communautaire sera décrite en section 4.5. 4.4.3 Intéraction entre les composants Après avoir présenté les différents composants logiciels formant le serveur central et les nœuds de collecte de APISENSE®, nous présentons dans cette sous-section leurs interactions. La figure 23 montre un diagramme de séquence illustrant les différents messages échangés entre les acteurs du système (c.-à-d. utilisateurs et participants) et les composants de APISENSE®, lors de l’exécution d’une campagne de collecte personnelle. Comme le montre le diagramme, la réalisation d’une campagne de collecte comporte trois phases : la création de la campagne de collecte (phase 1), le déploiement d’une tâche de collecte vers les dispositifs mobiles des participants (phase 2) et la propagation des données vers un nœud de collecte. (phase 3). phase 1 - création d’une campagne de collecte La création d’une nouvelle campagne de collecte est initiée par un utilisateur à partir de son nœud de collecte. La création de la campagne consiste à sélectionner un ensemble de caractéristiques, appartenant au MC, définissant la configuration de la campagne de collecte. À partir d’une configuration valide, le composant ExperimentManager télécharge les composants SCA associés aux caractéristiques auprès du serveur central et génère une nouvelle instance de la campagne (cf. figure 22). La nouvelle instance est un composite SCA, constitué d’un ensemble de composants qui exposent automatiquement de nouveaux services permettant le développement de la tâche de collecte (composant SensingTask), de la publier (composant Recruitment), de reporter les données collectées par les dispositifs mobiles (composant DataHandler) et de récupérer les données collectées (composant Query). 110Figure 23 – Interaction des composants APISENSE® 111phase 2 - déploiement de la tâche de collecte Une fois les services de la nouvelle campagne de collecte exposés, les utilisateurs peuvent alors développer la tâche de collecte associée à la campagne de collecte via le composant SensingTask, configurer les propriétés de déploiement de la tâche de collecte (cf. section 4.3.2) et la publier auprès du serveur central via le composant Deployment. Une fois publiée, le composant Recruitment du serveur central analyse les propriétés de la tâche de collecte et notifie tous les participants, correspondant à ces propriétés, de la disponibilité d’une nouvelle tâche de collecte est disponible. Les participants volontaires peuvent alors s’y inscrire. Dans ce cas, le dispositif mobile télécharge la tâche de collecte et l’identifiant anonyme généré lors de l’inscription qui est également partagé avec le composant ExperimentManager du nœud de collecte. Une fois téléchargée, la tâche de collecte est alors exécutée sur le dispositif mobile. phase 3 - propagation des données La dernière phase consiste à reporter les données collectées durant l’exécution de la tâche de collecte. Les données sont directement reportées auprès du composant DataHandler du nœud de collecte ayant initié la tâche de collecte. Lors de la propagation des données, l’identifiant anonyme est également envoyé, permettant au nœud de collecte de vérifier si les données proviennent bien d’un utilisateur inscrit à l’expérience. Si l’identifiant est valide, le composant DataHandler fait appel au composant Privacy qui est responsable de l’assainissement des données, avant leur sauvegarde et leur indexation dans la base de données via le composant Collector. Les utilisateurs peuvent alors accéder aux données sauvegardées, exporter les données collectées, et également retourner à la phase 2 afin de modifier le comportement de la tâche de collecte en fonction des résultats observés. Nous venons de décrire l’ensemble des interactions des composants APISENSE® permettant la réalisation d’une campagne de collecte de données. La section suivante présente le mécanisme d’extension de APISENSE® permettant le développement et l’intégration de nouveau composant dans la plate-forme. 4.4.4 Extension des nœuds de collecte En définissant un nœud de collecte comme une application SCA, nous bénéficions aussi de sa modularité pour facilement étendre la plate-forme. Dans cette sous-section, nous présentons comment de nouveaux services peuvent être ajoutés à un nœud de 112collecte. L’ajout d’un nouveau service est effectué à partir d’une archive ZIP, que nous appellerons une contribution. Comme le montre l’exemple illustré par la figure 24, une contribution contient la description d’une caractéristique, associée à un composite SCA, ainsi que l’ensemble des artéfacts implémentant le composite (c.-à-d. code compilé, scripts). La contribution présentée vise donc à ajouter un nouveau service responsable d’exporter les données collectées sous le format KML 5 , un format d’encodage utilisant le formalisme XML destiné à la gestion de l’affichage de données géospatiales dans les systèmes d’information géographique. Dans ce cadre, le premier élément vise à définir la contribution comme une caracté- ristique s’inscrivant dans le MC général présenté en sous-section 4.4.1. La description de la caractéristique définit donc le nœud parent (c.-à-d. caractéristique Export dans l’exemple), identifiant un nouveau point de variabilité, les caractéristiques requises, et le composite SCA associé. Dans cet exemple, le composite définit un nouveau service (c.-à-d. export service), exposé comme une ressource REST. Afin de récupérer les données collectées, le composant déclare une référence vers un composant fournissant un service de requête vers la base de données. Et finalement, le composant, déclare son implémentation comme étant une implémentation en Java. Les nœuds de collecte et le serveur central fournissent un service dédié aux déploiements de nouvelles contributions. Dans ce cadre, un utilisateur peut déployer une contribution directement dans son nœud de collecte, ou directement sur le serveur central pour la partager avec les autres utilisateurs du système. 4.5 campagne de collecte communautaire Dans la section précédente, nous avons présenté les principaux composants des nœuds de collecte et plus particulièrement comment ces composants peuvent être assemblés pour créer des services dédiés à une campagne de collecte spécifique. Nous avons également présenté le premier modèle de recrutement Individuel, où le recrutement est basé uniquement sur les propriétés des participants. Dans cette section, nous décrivons le modèle de recrutement Communautaire. Ce type de campagne, également appelé public sensing dans la littérature [33], consiste à collecter continuellement des données relatives à l’environnement des participants (par ex. bruit ambiant, qualité réseaux, pollution de l’air) dans une zone géographique [47, 63, 50]. 5. https://developers.google.com/kml/documentation 113Figure 24 – Exemple d’extension : Export des données au format KML 114Typiquement, une approche couramment utilisée dans ce type de campagne consiste à impliquer un maximum de dispositifs mobiles dans la collecte de données. Cependant, ces dispositifs collectent périodiquement (c.-à-d. toutes les x secondes) ces données environnementales sans prendre en considération si un autre nœud mobile placé à proximité collecte les mêmes données [27]. Cette approche naïve peut s’avérer inef- ficace principalement pour deux raisons. La première est qu’elle peut impliquer la remontée d’une grande quantité de données similaires, en particulier en milieu urbain ou une forte concentration d’utilisateurs (c.-à-d. situés à proximité) peuvent collecter simultanément ces données identiques. Cela demande par conséquent beaucoup plus de ressources côté serveur pour stocker ces données et les analyser. La seconde est qu’elle implique également une grande perte énergétique des appareils mobiles qui collectent ces données similaires. Récemment, Sheng et al. [59] ont montré qu’effectuer une collaboration entre les dispositifs, en fonction d’un objectif de couverture de la zone à observer, pouvait radicalement diminuer l’énergie consommée par l’ensemble des dispositifs, et par conséquent diminuer également le volume de données transmises sur le serveur. Dans ce cas, les objectifs de couverture définissent uniquement la quantité de données nécessaire pour la campagne, permettant de faire un compromis entre la quantité des données collectées, et le coût énergétique liée à leurs acquisitions. Pour effectuer la collaboration, cette approche fais l’hypothèse que les trajets de chaque appareil mobile est connue à l’avance. À partir de ces trajets, l’algorithme proposé dans cette approche permet d’assimiler les tâches de collecte uniquement aux mobiles capables de couvrir les objectifs de couvertures définis au préalable . Cependant, faire l’hypothèse que la mobilité de chaque appareil mobile est connue à l’avance peut être difficilement appliqué en déploiement réel, dû à la difficulté de prédire les trajectoires des participants [60]. Dans ce contexte, nous présentons dans cette section un modèle de recrutement collaboratif, permettant de coordonner l’exécution des tâches de collecte sans avoir une connaissance au préalable de la mobilité des participants. Le modèle proposé a pour objectif dans un premier temps de diminuer la consommation énergétique globale de tous les dispositifs impliqués dans la campagne, et également de diminuer la quantité de données propagées vers le nœud de collecte. Dans notre architecture, ce modèle est assuré par le composant associé à la caractéristique Collaboration du MC présentée en sous-section 4.4.1. Pour assurer la coordination des tâches, le composant se base sur des propriétés de couverture géographique et temporelle décrites par les utilisateurs, leur permettant de définir seulement la quantité de données nécessaires pour leur 115campagne. Pour définir ces propriétés, ainsi que différentes exigences en relation avec leur campagne, nous proposons une interface de programmation complémentaire à celle présentée dans le chapitre précédent (cf. section 3.3). Dans la suite de cette section, nous présentons tout d’abord l’interface de programmation proposée suivie d’un exemple de campagne de collecte développée avec cette interface. Nous présentons par la suite les différents processus assurant l’exécution ainsi que la coordination des ces campagnes de collecte. 4.5.1 Extension du modèle de programmation Dans cette section, nous présentons l’interface de programmation dédié à la définition de campagne de collecte de données communautaire. La table 11 illustre les principales fonctions proposées par cette interface. Phase Méthode Description Collecte sense(callback : function()) Enregistrement d’une tâche de collecte Recrutement accept(function()) Définition des dispositifs autorisés à exécuter une tâche ranking(function(users)) Classement des dispositifs prioritaires pour l’exécution de la tâche Couverture geoCoverage(bound : Array, coverage : String) Définition des propriétés de couverture géographique timeCoverage(during : Number, every : Number) Définition des propriétés de couverture temporelle duplicate(n : Number) Nombre de dispositifs attribués à une tâche selon les propriétés de couverture. Table 11 – Interface de programmation dédiée à la définition des campagnes de collecte communautaires. Typiquement, la définition d’une campagne de collecte communautaire comprend trois phases : collecte, recrutement, couverture. collecte : La première phase consiste à enregistrer la tâche de collecte qui sera distribuée auprès des nœuds mobiles. La tâche de collecte décrit les données qui doivent être collectées et reportées par les nœuds mobiles (cf. section 3.3, page 59 ). L’enregistrement de celle-ci est effectué en insérant une fonction de rappel 116à la méthode sense. Cette tâche sera ensuite exécutée par les nœuds mobiles lorsqu’ils seront assignés à celle-ci. recrutement : La deuxième phase consiste à définir la stratégie de recrutement des nœuds mobiles. Cette phase permet de filtrer les nœuds mobiles, ou d’en privilégier certains en fonction de leur contexte lors de l’attribution de la tâche de collecte. Par exemple, cela permet de baser le recrutement sur certains attributs (par ex. type de connexion réseaux, vitesse de déplacement), ou de privilégier les nœuds mobiles ayant le niveau de batterie le plus élevé. Le filtrage des nœuds mobiles consiste à enregistrer une fonction de rappel à la méthode accept. Cette fonction sera exécutée par les nœuds mobiles avant l’attribution de la tâche de collecte à un ou plusieurs nœuds. Cette fonction a pour objectif d’observer le contexte du nœud mobile, et définir si celui-ci est autorisé à exécuter la tâche. Dans ce cas, cette fonction doit retourner une liste de propriétés (par ex. niveau de batterie, vitesse de déplacement, qualité du signal réseau), dans le cas contraire, elle doit retourner une valeur nulle. La méthode ranking permet de privilégier certains nœuds mobiles pour exécuter une tâche de collecte, basée sur les propriétés retournées par la méthode accept. couverture : La troisième phase permet de définir les objectifs de couverture temporelle et géographique de la campagne de collecte. Cela permet par exemple de faire un compromis entre le coût énergétique utilisé par l’ensemble de nœuds mobiles, et la quantité de données reportées pendant la campagne. L’objectif de couverture temporelle peut être défini par la méthode timeCoverage, qui prend deux paramètres. Ces deux paramètres permettent de spécifier pendant combien de temps la tâche de collecte doit être exécutée et à quelle fréquence (par ex. exécuter la tâche pendant 30 minutes toutes les heures). L’objectif de couverture géographique peut être défini par la méthode geoCoverage, qui prend également deux paramètres. Ces paramètres permettent de spécifier la zone géographique globale de la campagne et à quelle granularité la tâche de collecte doit être distribuée (par ex. exécuter la tâche dans la ville de Paris tous les 500 mètres). La méthode duplicate permet de définir le nombre de dispositifs attribués à la tâche de collecte en fonction des propriétés de couvertures. Exemple d’application Afin de mieux illustrer le modèle de programmation proposé, nous présentons ici un exemple de campagne de collecte de données. Nous utiliserons également cet exemple comme un fil conducteur tout au long de cette section. Dans cette campagne, décrites par le listing 4.1, nous voulons mettre en place une collecte de 117données permettant d’élaborer une cartographie représentant la qualité des réseaux GSM en fonction des opérateurs des réseaux mobiles dans la ville de Paris. La première phase consiste à enregistrer la tâche de collecte de cette campagne (ligne 2-9). La tâche de collecte consiste à exécuter 10 Ping (Packet INternet Groper) réseaux à une machine distante particulière lorsque le participant a changé de position (ligne 3), et à collecté la latence moyenne des requêtes effectuées (ligne 7), la position de l’utilisateur (ligne 6) ainsi que son opérateur de réseau mobile (ligne 5). La deuxième phase consiste à définir la stratégie de recrutement des utilisateurs. Dans cette phase, nous voulons recruter uniquement les participants disposant d’une connexion de données mobiles (ligne 13). Pour les participants ayant ce type de connexion, nous renvoyons le niveau actuel de leur batterie pour pouvoir privilé- gier l’attribution de la tâches de collecte au participant disposant du niveau de batterie le plus élevé (ligne 18-20). Dans le cas contraire, le participant n’est pas autorisé à exécuter la tâche de collecte. Dans la troisième phase, nous définissons les propriétés de couverture pour optimiser l’énergie utilisée par l’ensemble des dispositifs mobile, et minimiser la quantité de données reportées sur le serveur. Pour cela, nous définissons que la tâche de collecte doit être exécutée au maximum par deux participants (ligne 25) répartis tous les cinqcents mètres dans la ville de Paris (ligne 23), et que la tâche doit être exécutée pendant trente minutes toutes les heures (ligne 24). 1 // phase 1 : définition de la tâche de collecte 2 sense(function() { 3 $location.onLocationChanged(function(event) { 4 $trace.add({ 5 operator : $telephony.operator(), 6 loc: [event.latitude, event.longitude], 7 latency : $network.ping(10,"http://...").average}); 8 })} 9 }) 10 11 // phase 2 : définition de la stratégie de recrutement 12 accept(function(){ 13 if (network.connectionType() != "WIFI"){ 14 15 return {battery : $battery.level()} 16 }else return undefined 17 }) 18 ranking(function(users){ 19 return users.sort("battery").select(); 20 }) 21 22 //phase 3 : définition des objectifs de couverture 11823 geoCoverage([[50.614291,3.13282],[50.604159,3.15239]],"500 m") 24 timeCoverage("30 min","1 H") 25 duplicate(2) Listing 4.1 – Tâche de collecte : Observer la qualité réseau Dans cette section, nous avons présenté le modèle de programmation proposé pour définir des campagnes de collecte supportant la collecte collaborative de données. Nous décrivons dans la suite de cette section comment ces campagnes sont exécutées par les nœuds de collecte. 4.5.2 Coordonner l’exécution des tâches de collecte Dans cette section, nous décrivons le modèle et les algorithmes mis en œuvre pour supporter la coordination des tâches de collecte en fonction des propriétés de couvertures géographique et temporelle. Le principal défi qui doit être adressé pour mettre en œuvre une coordination optimisée est de permettre au nœud de collecte d’avoir une vision aussi précise que possible de la réparation géographique des nœuds mobiles disponibles. Cependant, en utilisant une approche naïve qui consisterait à reporter continuellement la position des dispositifs mobiles vers le serveur ne seraient pas efficace pour plusieurs raisons. Premièrement, cela pourrait engendrer un trafic trop important de messages échangés entre les nœuds mobiles et le serveur, spécialement si de nombreux mobiles sont impliqués dans la campagne. Deuxièmement, cela impliquerait une trop grande consommation énergique des nœuds mobiles, dû à l’activation constante de capteur comme le GPS. Et finalement, classifier les nœuds mobiles en fonction de leur distance les uns par rapport aux autres, en utilisant des algorithmes de clustering [31] par example, entraînerait un surcharge du serveur, spécialement si cette classification doit être effectuée en permanence sur un grand volume de données. Pour adresser ce défi, nous avons adopté pour une approche de virtualisation de capteur, initialement proposée dans les réseaux de capteurs (WSNs). [10]. Typiquement, la virtualisation consiste à rajouter une couche logicielle abstraite, appelée couche virtuelle, composée d’un ensemble de capteurs virtuels, superposée à une couche physique. Un capteur virtuel est une entité logicielle autonome, responsable de gérer le flux de messages entre le serveur et un groupe de capteurs caractérisés par des propriétés communes (par ex. zone géographique, type de capteurs). Dans notre approche, l’idée 119principale est de diviser la zone globale de collecte en plusieurs zone géographiques en fonction des propriétés de couverture géographique de la campagne de collecte. Pour chaque zone, nous attribuons un capteur virtuel qui sera responsable de coordonner l’exécution des tâches entre les nœuds mobiles situé dans sa zone. Dans ce contexte, les nœuds mobiles ont uniquement besoin de partager leur position lorsqu’ils entrent ou sortent de la zone gérée par un capteur virtuel. Le composant responsable de l’exécution des campagnes de collecte communautaire et de la gestion des capteurs virtuels est le composite Recruitment :Collaborative (cf. figure 25). Ce composant est associé à la caractéristique Collaborative du point de variabilité Recruitement dans le modèle de caractéristiques présenté en sous-section 4.4.1. Figure 25 – Composant SCA responsable du recrutement collaboratif Ce composite est constitué des trois composants : i) ScriptEngine responsable de l’exécution du script JavaScript définissant la campagne de collecte, ii) VSManager responsable de la création et la gestion des capteurs virtuels et iii) Deployment responsable d’interagir avec le serveur central pour déployer les scripts auprès des nœuds mobiles. L’exécution d’une campagne communautaire comprend trois phases : i) la phase de génération des capteurs virtuels, ii) la phase de connexion des nœuds mobiles avec les capteurs virtuels, iii) et la phase de coordination de l’exécution des tâches de collecte. Nous décrivons à présent l’ensemble de ces étapes. Phase 1 : Génération des capteurs virtuels L’objectif ici est de générer un ensemble de capteurs virtuels responsables de coordonner l’exécution des tâches de collecte entre les nœuds mobiles. La génération de ces capteurs virtuels est assurée par le composant VSManager. Chaque capteur virtuel est caractérisé par une propriété définissant la zone géographique incluse dans la zone 120globale de collecte des données. La génération de ces capteurs est effectuée à partir de la méthode geoCoverage(bound,coverage) de l’interface de programmation, définissant la zone géographique globale de la collecte (paramètre bound), et la taille de la zone gérée par un capteur virtuel (paramètre coverage). À partir de ces paramètres, le composant VSManager génère et instancie un ensemble de capteurs virtuels, et les distribue pour couvrir l’intégralité de la zone globale de collecte (cf. figure 26). Typiquement, un capteur virtuel est un composite SCA disposant de deux services : composant RegistrationService et CoordinationService. Le premier service est dédié à l’enregistrement des nœuds mobiles. Ce service est exposé en tant que ressource REST, accessible à partir d’une URL générée à partir de la zone géographique dont il est responsable. Dans ce cas, les nœuds mobiles sont responsables de s’enregistrer auprès du capteur virtuel en fonction de leur position. Le deuxième service est responsable d’attribuer une tâche de collecte à un ou plusieurs nœuds mobiles qui se sont enregistrés au préalable. Nous détaillons ces différents points dans les section suivantes. Figure 26 – Distribution des capteurs virtuels Phase 2 : Connexion des appareils mobiles et des capteurs virtuels La deuxième phase consiste à établir une connexion entre les nœuds mobiles et les capteurs virtuels. Pour établir cette connexion, les nœuds mobiles ont tout d’abord besoin de télécharger la tâche de collecte auprès du serveur central. Le déploiement de la tâche de collecte vers le serveur central, assurée par le composant DeploymentService, 121suit le même procédé qui celui présenté en sous-section 4.4.4. Comme le montre la figure 26, la tâche de collecte comporte deux fichiers JavaScript : sense.js correspondant au code JavaScript responsable de la collecte des données (ligne 3-8 dans l’exemple décrit par le listing 4.1), et VSmonitoring.js. Dans un premier temps, seulement le fichier VSmonitoring.js est exécuté. Ce dernier script télécharge dans un premier temps l’ensemble des propriétés des capteurs virtuels générés (c.-à-d. zone géographique et l’URL du service d’enregistrement). À partir de ces propriétés, ce script observe continuellement la position du nœud mobile pour déterminer la présence du nœud mobile se situe dans une zone gérée par un capteur virtuel, et est responsable de l’enregistrement et du dé-enregistrement auprès du capteur virtuel associé. En ce qui concerne la surveillance de la position du nœud mobile, nous utilisons un algorithme couramment utilisé dans la littérature pour déterminer si un dispositif se trouve dans une zone spécifique, tout en minimisant le coût énergétique. Typiquement, l’idée principale derrière est i) d’utiliser alternativement les différents mécanismes permettant de déterminer la position d’un utilisateur — entre le GPS fournissant une grande précision, mais consommant beaucoup d’énergie, et le réseau qui, au contraire, consomme moins d’énergie, mais est beaucoup moins précis —, ii) et la fréquence d’échantillonnage en fonction de la distance entre l’utilisateur et le capteur virtuel le plus proche de sa position actuelle. Phase 3 : Coordonner l’exécution des tâches de collecte Dans cette section, nous présentons l’algorithme utilisé par les capteurs virtuel pour coordonner l’exécution des tâches de collecte entre les nœuds mobiles enregistrés auprès d’un capteur virtuel. Le principal défi dans cette partie est de faire face à la connectivité imprévisible des nœuds mobiles. En effet, on ne peut pas partir du postula que tous les nœuds enregistrés sont réellement disponibles pour exécuter une tâche. De nombreux phénomènes peuvent empêcher les nœuds mobiles d’avertir un capteur virtuel qu’ils ne sont plus disponibles, comme la perte d’un signal réseau, un épuisement complet de la batterie ou tout simplement l’extinction du téléphone mobile par le participant. Pour prendre en considération ces phénomènes, l’idée principale de notre approche consiste à dupliquer le nombre de nœuds mobiles assignés à une tâche de collecte, et à intégrer une phase de demande d’exécution afin d’éviter d’avoir à assigner une tâche à un nœud qui n’a pas annulé son enregistrement au capteur virtuel. 122L’algorithme (cf. algorithme 1) est déclenché périodiquement en fonction des propriétés de couverture temporelle qui peuvent être définies par l’interface de programmation avec la méthode geoCoverage(duration,every). Algorithm 1 Algorithme de coordination des tâches de collecte Require: connectedDevices : List of connected devices activeDevices : List of activated devices t : Time threshold Task(tstart,tend) : Temporal properties of the sensing task duplicate : Maximum number of devices to assign the sensing task if (size(activeDevices) < duplicate) then candidates ⇐ connectedDevices − activeDevices if notEmpty(candidates) then availableCandidates ⇐  broadcastTaskRequestEvent(candidates) repeat receive(Device(id, n)) add(availableCandidates,Device(id, properties)) until timeout t is reached for (i = 0 → (size(activeDevices) − duplicate))) do device ⇐ ranking(availableCandidates) activeDevices ⇐ device + activeDevices availableCandidates ⇐ availableCandidates − device broadcastTaskExecutionRequest(device, tstart, tstop) end for end if end if L’algorithme vérifie tout d’abord si le nombre de dispositifs mobile déjà assigné à une tâche (size(activeDevice)) est inférieur à la propriété de duplication. Dans ce cas, nous définissons une liste candidate comme un ensemble de dispositifs connectés et n’exécutant pas actuellement une tâche de collecte. Pour tous les candidats, un message leur est envoyées avec la fonction de recrutement définie par l’interface de programmation (ligne 12-17 dans l’exemple du listing 4.1), — dans notre exemple, nous voulons recruter uniquement les nœuds mobiles disposant d’une connexion GSM —. Le capteur virtuel attend ensuite un temps t la réponse des dispositifs mobiles. Les nœuds correspondant à la méthode de recrutement répondent ensuite au capteur virtuel avec un ensemble de propriétés indiquant leurs états actuels (par ex. niveau de 123batterie, type de connexion de données). Ces nœuds sont ensuite ajoutés à une liste indiquant leurs disponibilités pour exécuter la tâche de collecte. Ces nœuds sont ensuite classifiés par la méthode ranking. Cette méthode correspond à celle définie par l’interface de programmation (ligne 18-20 du listing 4.1), permettant de privilégier certains nœuds par rapport à leurs propriétés. Dans notre exemple, nous privilégions les noeuds mobiles disposant du niveau de batterie le plus élevé. À la fin du processus, un nouveau message est envoyé aux nœuds mobiles leur demandant d’exécuter la tâche de collecte. Les noeuds mobiles recevant ce message démarrent l’exécution de la tâche de collecte jusqu’à la date définie par tend ou lorsque les nœuds quittent de la zone gérée par le capteur virtuel. Cela permet de réattribuer la tâche de collecte à un autre nœud. À la fin de l’exécution, toutes les données collectées sont ensuite propagées directement sur le nœud de collecte. 4.6 conclusion APISENSE® propose un environnement facilitant la gestion de campagnes de collecte de données. Pour supporter une grande diversité de campagne de collecte, nous avons proposé un modèle permettant de configurer un environnement serveur (c.-à-d. honey) responsable de l’exécution d’une campagne de collecte. Ainsi, ce modèle est utilisé pour configurer les services d’un nœud de collecte en fonction des spécificités des campagnes de collecte. Cette configuration comprends cinq points : i) configurer l’environnement de développement des tâches de collecte, ii) choisir un modèle de recrutement des participants, iii) choisir une série de traitements sur les données collectées avant leur insertion dans la base de données (par ex. anonymisation des données), iv) spécifier l’indexation des données dans la base de données, v) exposer des services pour exploiter les données collectées. À partir de ce modèle, un nœud de collecte peut être ensuite généré et déployé par les utilisateurs vers une infrastructure qui peut être publique ou privée selon la nature des données collectées. Cela leur permet de garder un contrôle total sur l’infrastructure hébergeant les données collectées durant leurs campagnes. APISENSE® se distingue également par son architecture décentralisée, permettant d’améliorer le passage à l’échelle du système. Son architecture est ainsi composée d’un ensemble de nœuds de collecte organisé autour du serveur central. Concernant le serveur central, son principal objectif est d’assurer le déploiement des tâches de 124collecte soumises par les nœuds de collecte vers les participants de la plate-forme qui se sont enregistrée au préalable. Ce procédé a principalement deux avantages. Le premier est d’assurer une première couche d’anonymat des participants, dans le sens où tous les nœuds de collecte ne peuvent pas déployer les tâches de collecte sans passer par le serveur central. Le deuxième permet aux nouveaux utilisateurs de bénéficier d’un ensemble de participants déjà disponibles pour exécuter des tâches de collecte, leur évitant ainsi une longue période de recrutement. Finalement, nous avons proposé une extension de APISENSE® dédiée à l’optimisation de l’exécution de campagne de collecte communautaire. L’optimisation proposée permet de coordonner l’exécution des tâches de collecte entre les dispositifs mobiles en fonction de propriétés de couvertures géographique et temporelle. Principalement, cette optimisation a pour objectif dans un premier temps de diminuer la consommation énergétique globale de tous les dispositifs impliqués dans la campagne, et également de diminuer la quantité de données propagées vers le nœud de collecte. La description des contributions de ce manuscrit est à présent terminée. Dans les chapitres suivants, nous présentons les évaluations de la plate-forme APISENSE®. 125Troisième partie Évaluations 1275 P R AT I Q U E S C U LT U R E L L E S E T U S A G E S D E L’ I N F O RM AT I Q U E C O N N E C T É E Sommaire 5.1 Introduction 130 5.2 Contexte et objectif de l’étude PRACTIC 130 5.3 Développement de l’étude PRACTIC 131 5.3.1 Collecte opportuniste 132 5.3.2 Collecte participative 135 5.3.3 Retour utilisateur 136 5.3.4 Discussions 136 5.4 Déploiement de l’étude PRACTIC 139 5.4.1 Protocole du déploiement 139 5.4.2 Participation 140 5.5 Conclusion 143 Dans cette partie, nous présentons les évaluations de la plate-forme APISENSE® en deux chapitres. Dans le premier chapitre, nous présentons une campagne de collecte déployée auprès d’une centaine d’utilisateurs, réalisée au sein de l’étude PRATIC (Pratiques Culturelles et Usages de l’Informatique Connectée). Ce chapitre a pour objectif de montrer le gain en terme de coût de développement apporté par notre plate-forme, et également de montrer la faisabilité de notre approche dans un cas réel d’utilisation. Le deuxième chapitre évalue le passage à l’échelle de APISENSE® pour la réalisation de campagne de collecte communautaire. Nous évaluons notamment le gain du modèle de recrutement collaboratif, permettant de faire un compromis entre l’énergie consommée par les dispositifs mobiles et la quantité de données générées tout en gardant une bonne couverture de collecte. 1295.1 introduction Dans la partie précédente de ce manuscrit, nous avons présenté en intégralité APISENSE®, la plate-forme résultante des travaux de cette thèse. Comme nous l’avons déjà évoqué, le principal objectif de cette thèse est d’ouvrir l’accès du Mobile Crowd Sensing à de nombreux acteurs privés ou académiques, en leur permettant de facilement développer et déployer leurs campagnes de collecte de données. Dans ce chapitre, nous présentons une campagne réalisée au sein d’une étude sociologique nommée PRACTIC 1 (Pratiques Culturelles et Usages de l’Informatique Connectée), qui vise à comprendre l’usage des technologies numériques connectées en matière d’habitudes et de routines de consommations culturelle et médiatique. Cette étude a été réalisée par une équipe pluridisciplinaire, composée de deux ingénieurs en informatique pour le développement des scripts de collecte, et deux chercheurs en sciences de l’information et de la communication pour l’interprétation des données collectées. Par le biais de la description de cette étude, nous cherchons tout d’abord à montrer la faisabilité de notre approche pour être utilisée dans un cas réel d’utilisation, et plus particulièrement évaluer le gain en terme de cout de développement apporté par APISENSE®. 5.2 contexte et objectif de l’étude practic Le principe de l’étude PRACTIC est né de notre rencontre avec des chercheurs en sociologie, dans le cadre du projet de l’Observatoire Scientifique de l’Internet 2 initié par INRIA 3 . Un premier objectif de cette collaboration est de voir en quelle mesure les nouveaux mécanismes de collecte de données, comme le Mobile Crowd Sensing, peuvent augmenter les méthodes traditionnelles de la recherche numérique en sciences sociales. En effet, de nos jours, la nouvelle génération des terminaux intelligents comme les tablettes ou les smartphones sont fortement intégrés dans la vie sociale et culturelle des individus. Cette intégration représente de nouvelles opportunités pour les sciences sociales, qui peuvent ainsi collecter massivement et sur le long terme, des données comportementales des individus de manière non intrusive. De plus, cela nous a permis de confronter notre plate-forme à un déploiement réel, et d’être utilisée par des personnes tierces à notre équipe. 1. http ://beta.apisense.fr/practic 2. http ://metroscope.org/ 3. www.inira.fr 130L’étude PRACTIC est composée majoritaire de deux phases. La première est une phase de collecte de données auprès d’un ensemble de participants volontaires, combinant les collectes de données opportuniste et participative (c.-à-d. questionnaire). Dans le cadre de PRACTIC, la confrontation de la collecte opportuniste et participative permet de mesurer l’écart entre la représentation des individus sur l’utilisation de leur smartphone et leur pratique effective. La seconde phase comprend des traitements statistiques sur les données collectées qui aboutiront sur quelques entretiens individuels. Dans ce chapitre, nous décrivons uniquement la première phase de l’étude qui est directement en relation avec la plate-forme APISENSE®. Nous décrivons à présent le développement de cette phase de collecte. 5.3 développement de l’étude practic La phase de collecte a entièrement été développée par APISENSE®, en utilisant son modèle de programmation (cf. chapitre 3 section 3.3) pour la description des données collectées sur les environnements mobiles, et un nœud de collecte déployé sur un serveur privé pour la persistance des données. Cette phase a été développée par un Ingénieur Jeune Diplômé (IDJ) en informatique, intégré pour les besoins de l’étude, qui n’avait aucune compétence particulière en programmation mobile au début du développement. L’application PRACTIC a d’abord connu plusieurs phases de test auprès d’un sous ensemble de participants. Ces différentes itérations ont permis d’identifier certains bugs, et d’ajouter des fonctionnalités non anticipées qui ont permis de consolider APISENSE® et l’enquête. Durant cette phase de test, l’ingénieur en question été responsable de faire la transition entre les exigences des sociologues, et les capacités offertes par notre plate-forme. La figure 27 illustre les principales données collectées par l’application PRACTIC. Un aspect intéressant ici est qu’elle utilise un large éventail des fonctionnalités proposées par APISENSE®. La collecte de données comprend principalement trois parties différentes que sont la collecte opportuniste de données, la collecte participative et les retours utilisateurs, correspondant respectivement à plusieurs scripts de collecte. Nous décrivons à présent brièvement ces différents points, et comparons à la fin de cette section le gain en terme de coût de développement apporté par notre modèle de programmation. 131Figure 27 – Données collectées par l’étude PRACTIC 5.3.1 Collecte opportuniste La première partie vise à collecter la diversité des rythmes de vie ainsi que des usages sociaux ou culturels des dispositifs mobiles. Toutes ces données sont collectées automatiquement par l’application sans nécessiter une intervention des participants. Typiquement, trois types de données sont collectées : Contenu Mobile, Activité de l’utilisateur, et Contexte mobile. Chaque type de données correspond à un script de collecte spécifique. Nous présentons brièvement un exemple simplifié des scripts de collecte développés. Contenu Mobile Le contenu mobile (cf. listing 5.1) vise à identifier des profils culturels des participants en fonction du contenu de leur appareil mobile. Dans le cadre de PRACTIC, la dimension culturelle est vue à deux niveaux : le type des applications mobiles installées (c.-à-d. jeux,divertissement, communication), les genres musicaux des participants. Le listing 5.1 décrit le script de collecte associé. La première partie du script (ligne 1-6) est déclenchée une seule fois lors de la première exécution du script. Dans cette partie, un ensemble de méta-données est collecté comprenant la liste des applications installées (nom, date d’installation, catégorie), et celle des fichiers musicaux présents (nom, artiste, format d’encodage, taille en Ko). La deuxième partie vise à identifier les cycles d’installation et de désinstallation des applications. Cette partie est réalisée 132automatiquement lorsqu’un événement concernant l’installation ou la désinstallation est déclenchée par le système mobile. 1 $schedule.once(function(){ 2 // store media files meta-data 3 $trace.add($media.getAudioFiles()); 4 // store installed applications meta-data 5 $trace.add($app.getLaunchableApplications()); 6 }); 7 8 $app.onAppInstallEvent(function(app){ 9 // store new installed or uninstalled application meta-data 10 $trace.add(app); 11 }); Listing 5.1 – Collecte du contenu mobile Activité utilisateur Cette partie vise à collecter les différents rythmes de vie et d’usages des dispositifs mobiles. Les usages sont principalement séparés en deux catégories correspondant aux usages natifs des téléphones mobiles (c.-à-d. appels et SMS) et les nouveaux usages introduis par la nouvelle génération des terminaux intelligents. Le listing 5.2 décrit l’utilisation de la façade $phone permettant de collecter des données sur les appels et les SMS émis et reçus. Pour des raisons de confidentialité, le contenu des appels et des SMS ainsi que l’identifiant des correspondants ne sont pas accessibles à partir des scripts. Seules la durée des communications ainsi que la taille des SMS sont disponibles. 1 $phone.onCallCompleted(function(call){ $trace.add(call) }); 2 3 $phone.onSMS(function(sms){ $trace.add(sms) }) Listing 5.2 – Collecte des usages natifs des dispositifs mobile La deuxième catégorie, illustrée par le listing 5.4 identifie les sessions d’utilisation des dispositifs. Celles-ci comprennent les sessions générales d’utilisations (écran allumé et éteint) et les sessions d’utilisation des applications. L’identification des sessions générales peut être effectuée par le biais de la façade $screen permettant d’intercepter les événements liés à l’écran du dispositif (lignes 2 et 22). Une session commence lorsque l’événement onScreenOn est déclenché. À la suite de cet événement, le script vérifie toutes les secondes (ligne 5) l’application exécutée en premier plan du dispositif (ligne 6), et collecte une session applicative lorsque l’application détectée est différente de la précédente (lignes 7-20). La session générale se termine lorsque l’événement 133onScreenOff est déclenché, dans ce cas la vérification des applications exécutées en premier plan est annulée (ligne 30), et cela déclenche également une nouvelle collecte de données correspondant à la durée de la session générale (lignes 25-29). 1 var subscription,startSession,subscription,appName,startApp; 2 $screen.onScreenOn(function(screen){ 3 4 startSession = screen.time; 5 subscription = $schedule.every("1 s",function(event){ 6 var currentApp = $app.currentApplicationName(); 7 if (appName != currentApp){ 8 9 appName = currentApp; 10 startApp = event.time; 11 12 // store application session 13 $trace.add({ 14 event : "ApplicationSession", 15 start : startApp, 16 end : event.time, 17 name : appName 18 }); 19 }; 20 }); 21 }); 22 $screen.onScreenOff(function(event){ 23 24 // store screen session 25 $trace.add({ 26 event : "ScreenSession", 27 start : startSession, 28 end : event.time 29 }); 30 subscription.suspend(); 31 }); Listing 5.3 – Collecte des usages des applications mobile Contexte mobile Finalement, la dernière catégorie des données collectées permet de mettre en perspective l’utilisation des applications et leurs contextes (cf. listing 5.4). Cela permet d’identifier par exemple si certaines applications sont utilisées uniquement lorsque le participant se trouve à son domicile ou sur son lieu de travail,ou encore d’observer si la qualité du réseau ou le niveau de batterie influe sur l’utilisation de certaines applications. Cette catégorie comprend les cycles de chargement et le niveau de la batterie (lignes 10-12), le contexte réseau (ligne 7-9) constitué du type de connexion 134de données (c.-à-d. Wi-Fi, 3G/4G), et de la force du signal réseau GSM (lignes 1-6). Pour déterminer si l’utilisateur est en situation de mobilité, le choix a été fait de collecter uniquement les identifiants des antennes cellulaires, qui permettent d’avoir une approximation de la localisation du participant sans entraîner une consommation énergétique supplémentaire de l’application mobile [65]. 1 $telephony.onSignalStrengthChanged(function(signal){ 2 $trace.add({ 3 level : signal.level, 4 cellId : $telephony.cellId() 5 }); 6 }); 7 $network.onNetworkStateChange(function(networkEvent){ 8 $trace.add(networkEvent); 9 }); 10 $battery.onBatteryStateChange(function(batteryEvent){ 11 $trace.add(batteryEvent); 12 }); Listing 5.4 – Collecte des usages des applications mobiles 5.3.2 Collecte participative Le questionnaire vise à collecter des données déclaratives sur l’équipement, les usages et le rapport à la vie privée des participants. Il est composé de 152 questions, dont certaines ne sont pas obligatoires. Par exemple, dans la partie des usages, le fait de ne pas posséder une tablette par exemple permet de ne pas répondre à un sous-groupe de questions. Entre 20 et 30 minutes sont nécessaires pour répondre intégralement au questionnaire. Les questions sont organisées au sein de quatre grandes parties : à propos de vous (16 questions), équipements (36), pratiques culturelles et usage de l’informatique connectée (60) et publicité en ligne et privée (19). Le questionnaire peut être complété à tout moment par les participants à partir de leurs dispositifs. Le listing 5.5 montre une très brève partie du questionnaire développé. Typiquement, les réponses du questionnaire vont être croisées par les sociologues avec les données collectées automatiquement par l’application. 1 var survey = $survey.create("PRACTIC"); 2 // ... 3 var q88 = survey.close("Quel est le lecteur musical que vous utilisez le plus ?",[ 4 "Chaine Hi-Fi / Platine Vinyle", 5 "Baladeur/MP3", 1356 "Smartphone", 7 "L’ordinateur (musique enregistrée sur le disque dur ou CD)", 8 "La radio", 9 "La television (chaines musicales comme MTV)", 10 "Autre lecteur de musique" 11 ]); 12 var q88b = survey.open("Quel autre lecteur utilisez-vous ?"); 13 var q89 = survey.close("Quel est votre maniére d’écoute principale avec votre lecteur ?",[ 14 "Casque audio", 15 "Enceinte/Ampli", 16 "Sans rien" 17 ]); 18 q88.then(function(response){ 19 20 if (response == "Autre lecteur de musique"){ 21 return q88b; 22 } 23 else return q89; 24 }); Listing 5.5 – Extrait du questionnaire PRACTIC 5.3.3 Retour utilisateur La dernière partie des scripts de collecte vise à donner un aperçu aux participants des données collectées. Typiquement, l’objectif de cette partie est d’agir en toute transparence vis-à-vis des participants sur les données qui sont collectées sur leurs dispositifs, et d’apporter un aspect ludique à l’application. L’idée est de permettre aux participants de confronter leur perception de l’utilisation de leur dispositif avec leur usage réel. La figure 28 montre un exemple de retour utilisateur sur la durée totale d’utilisation de son appareil. Cette partie a été développée intégralement en HTML/JavaScript. 5.3.4 Discussions Dans cette section, nous avons décrit l’ensemble des scripts de collecte qui a été nécessaire dans le cas de l’étude PRACTIC. Nous allons maintenant identifier le gain apporté par APISENSE® pour le développement de ce cas d’étude. L’application mobile APISENSE®, responsable du téléchargement, de l’exécution des scripts et de la propagation des données collectées a été développée en utilisant la version 2.3 du SDK de Android. L’application APISENSE® fournit de nombreuses abstractions qui simplifient 136Figure 28 – Exemple de retour utilisateur PRACTIC le développement d’une application de collecte de données. La première permet tout d’abord d’avoir une abstraction complète du SDK Android pour accéder aux données fournies par Android, et intercepter les différents événements internes au dispositif mobile grâce aux façades. Le tableau 12 récapitule les façades qui ont été utilisées pour développer PRACTIC, et leur nombre de lignes de code Java qui ont été nécessaires à leur développement. Au total, ces façades comptent approximativement 6000 lignes de code. Pour les besoins de l’étude, en collaboration avec l’ingénieur responsable du développement de PRACTIC, nous avons dû intégrer deux nouvelles façades pour lister les fichiers musicaux (façade $media) et pour observer les évènements liés à l’écran d’un dispositif (façade $screen). Ces façades peuvent être à présent disponibles pour le développement de nouveaux scripts de collecte. L’application APISENSE® dispose également d’un ensemble de services responsables de l’exécution des scripts de collecte en tâche de fond,d’interagir avec le serveur central d’APISENSE® pour le téléchargement et de la mise à jour des scripts de collecte, d’interagir avec les nœuds de collecte des scientifiques pour propager automatiquement les données collectées, et de contrô- ler les ressources consommées par les scripts de collecte (cf. chapitre 3 section 3.4). Cette partie comporte approximativement plus de 20000 lignes de code. Pour finir, l’application mobile APISENSE® possède également une interface graphique générique destinée aux participants (6000 lignes de code). 137Façade Description LOC $survey Génération et publication d’un questionnaire 1277 $feedback Intégration de visualisation HTML/JavaScript 2144 $network Observation du contexte réseau 259 $telephony Observation du réseau cellulaire 400 $phone Observation des communications 600 $battery Observation des états de la batterie 158 $app Observation des applications 362 $trace Collecte et propagation des données 376 $screen (nouvelle) Observation de l’écran 235 $media (nouvelle) Liste du contenu 210 Table 12 – Façade utilisée pour les besoins de l’application PRACTIC La figure 29 met en évidence le gain en terme de lignes de codes obtenu grâce à APISENSE® par rapport aux scripts développés. Au total, seulement 7 % de codes spécifiques ont eu besoin d’être développés pour l’étude PRACTIC. Les principaux efforts de développement résident dans la description des 150 questions et leurs enchaînements (760 lignes) et dans les interfaces graphiques effectuant un retour sur les données obtenues (1600 lignes). Dans la section suivante, nous présentons le protocole de déploiement de l’application. Figure 29 – Gain en terme de lignes de code obtenu grâce à APISENSE® pour le développement de l’étude PRACTIC 1385.4 déploiement de l’étude practic Après avoir présenté dans son ensemble les scripts de collecte de l’étude PRACTIC, nous présentons dans cette section son protocole de déploiement et discutons de la participation à cette étude. 5.4.1 Protocole du déploiement Pour la mise en place de l’étude PRACTIC, un nœud de collecte a tout d’abord été déployé sur un serveur privé des scientifiques. Le nœud de collecte a été configuré pour utiliser un modèle de recrutement individuel, pour indexer les données collectées par utilisateur et pour utiliser un système de classement à point (cf. chapitre 4 section 4.4.1) afin de maximiser la participation des utilisateurs. Pour que les données collectées soient pleinement exploitables par les sociologues, ils ont besoin qu’elles soient collectées au minimum pendant 14 jours par participant, et que celui-ci ait répondu au questionnaire de l’enquête. Dans ce contexte, les points sont attribués de la manière suivante : • 50 points pour les participants ayant installé l’application sur une tablette et un smarpthone, remplis le questionnaire et ayant généré plus de 14 jours de données. • 20 points pour les participants qui ont installé sur un seul appareil (smartphone ou tablette), avec le questionnaire rempli et toujours un minimum de 14 jours de données générées. • 1 point par jour de données générées • 2 points si le questionnaire est rempli Des lots ont été prévus pour récompenser les meilleurs participants comprenant une tablette tactile, un smarpthone, une liseuse ainsi que des disques durs externes et des clés USB. Le nœud de collecte a également été utilisé pour le développement des scripts de collecte ainsi que leurs déploiements auprès d’un serveur central que nous avions au préalablement déployé sur un service Microsoft Azure 4 . Pour des raisons éthiques et légales, l’étude PRACTIC a été soumise et validée par la Commission National de l’Informatique et des Libertés 5 (CNIL). 4. http ://azure.microsoft.com/fr-fr/ 5. http://www.cnil.fr/ 139Les participants intéressés à participer à l’étude PRACTIC doivent tout d’abord télécharger et installer l’application mobile APISENSE® publiée sur le site internet APISENSE® 6 en flashant un QR code. À partir de l’application, les participants pourront alors s’enregistrer auprès de l’étude PRACTIC. L’enregistrement déclenchera automatiquement le téléchargement et l’exécution des scripts de collecte après la validation d’une charte de confidentialité. Un identifiant unique est généré et accordé à chaque participant lors de son inscription. Ce n’est qu’en acceptant de communiquer cet identi- fiant avec les chercheurs qu’ils pourront être identifiés. Nous présentons dans la suite de cette section le niveau de participation à PRACTIC, et discutons des premiers retours de l’expériences. 5.4.2 Participation L’étude PRACTIC s’est déroulée du 10 MARS au 19 Avril 2014. La figure 30 montre le nombre d’utilisateurs inscrits par jour, ainsi que l’accumulation du nombre d’inscriptions durant l’étude. Au total, 88 participants ont été recrutés durant l’étude. Figure 30 – Nombre d’inscriptions par jour à PRACTIC Un aspect intéressant des participants recrutés est la diversité de leurs équipements (cf. figure 31), ce qui nous a permis de tester APISENSE® sur 45 modèles de smartphones différents. Outre le nombre d’inscriptions, le succès de l’étude repose principalement sur le taux de participation des utilisateurs tout au long de l’étude. Pour que les données 6. http://www.apisense.fr 140Figure 31 – Diversité des équipements mobiles d’un participant soient exploitables par les chercheurs, il est nécessaire qu’elles aient été collectées au moins sur une période de 14 jours, et que celui-ci ait répondu au questionnaire de l’application. Figure 32 – Taux de participation à la collecte opportuniste 141Figure 33 – Taux de participation à la collecte participative et opportuniste Sur l’ensemble des participants, comme la montre la figure 32, 48 ont collecté des données plus de 14 jours, 21 de 4 à 13 jours, 13 de 1 à jour 6 qui n’ont collecté aucune donnée. Les participants ayant répondu au questionnaire sont au nombre de 25, et les participants ayant à la fois répondu au questionnaire et collecté au moins 14 jours de données sont au nombre de 12 (cf. figure 34). Ces derniers représentent les cas d’étude concrets pour les scientifiques. Bien que ce nombre soit inférieur à celui escompté au début de l’étude, un point positif des premiers résultats obtenus permet de valider que les dispositifs sont bien au cœur des pratiques de certains participants. La figure 34 par exemple représente le nombre de sessions applicatives, ainsi que leurs durées, sur une période de 40 jours Cette courbe met bien en évidence les différents rythmes des usages d’un participant en particulier, qui utilise son dispositif tout au long de la journée, et qui intensifie son utilisation en fin de journée. Figure 34 – Représentation des sessions d’allumage de l’écran du terminal d’un participant cumulées au cours de 40 jours 1425.5 conclusion Dans ce chapitre, nous avons présenté un cas réel de campagne de collecte de données développée et déployée avec APISENSE® au sein d’une étude sociologique. Nous avons montré que APISENSE® permettait réduire le temps de développement d’une campagne de collecte en proposant un modèle de programmation permettant de s’abstraire complètement des technologies mobiles. Dans le cas de cette étude, le modèle de programmation a permis d’économiser plus de 90% de code nécessaire à son développement. La campagne développée a été déployée auprès de 88 utilisateurs sur une période d’un mois et demi. 143É VA L U AT I O N D U M O D È L E C O L L A B O R AT I F 6 Sommaire 6.1 Introduction 145 6.2 Mise en place de l’expérience 145 6.3 Résultats 148 6.3.1 Quantité de données et couverture géographique 148 6.3.2 Consommation énergétique 151 6.4 Conclusion 154 6.1 introduction Dans ce chapitre, notre objectif est de montrer la validité du modèle de recrutement collaboratif présenté dans le chapitre 4 en section 4.5, page 113 qui permet de coordonner l’exécution des tâches de collecte entre les dispositifs mobiles. Nous rappelons que le but de cette coordination est dans un premier temps de répartir les charges énergétiques entre les dispositifs mobiles durant la campagne de collecte, puis dans un second temps de diminuer la quantité de données propagées vers les nœuds de collecte en limitant la propagation de données dupliquées. La validité du modèle est évaluée sur quatre critères : i) la quantité de données propagées sur les nœuds de collecte, ii) la quantité d’énergie utilisée par les dispositifs mobiles ainsi que iii) le surcoût induit par notre approche pour effectuer la coordination des tâches, iv) la couverture géographique des données obtenues. Pour valider notre modèle, nous avons mené une expérience et développé un environnement de simulation que nous détaillons dans la section suivante. 6.2 mise en place de l’expérience Pour cette évaluation, nous reprenons l’exemple de l’application présentée dans la section 4.5.1 page 116 qui est une version simplifiée d’une collecte de données exposée 145dans LiveLab [61]. L’objectif de cette application est d’utiliser les dispositifs mobiles pour mesurer la qualité des réseaux GSM en milieu urbain. Le listing 6.1 décrit la tâche de collecte associée à cette application qui consiste à exécuter 10 Pings réseaux (Packet INternet Groper) toutes les trente secondes et à collecter la latence moyenne des Pings effectués ainsi que la position du dispositif obtenue avec par GPS. 1 $location.onLocationChanged({period : "30s", provider : "GPS"},function(event) { 2 $trace.add({ 3 loc: [event.latitude, event.longitude], 4 latency : $network.ping(10,"http://...").average}); 5 })} Listing 6.1 – Tâche de collecte : Mesure de la latence réseau Pour évaluer notre approche, nous avons simulé le recrutement des dispositifs suivant un modèle où tous les dispositifs exécutent la tâche de collecte indépendamment les uns des autres, et suivant le modèle collaboratif, où les capteurs virtuels coordonnent l’exécution des tâches de collecte entre les dispositifs mobiles (cf. 4.5.2, page 119 ). Pour une évaluation réaliste et à grande échelle, nous utilisons des traces de mobilités réelles provenant de 10000 taxis équipés de GPS dans la ville de Pékin en Chine [67]. Ces données ont été collectées sur une période d’une semaine allant du 2 au 8 février 2008. Afin d’utiliser ces données, nous avons développé un simulateur illustré par la figure 35. Le simulateur comprend trois composants : un Manager, un ensemble d’Agents et un nœud de collecte (DataGathering Node). agents : Les agents sont responsables de générer le trafic réseau simulant les interactions entre les dispositifs mobiles et le nœud de collecte. Ces interactions sont simulées à partir d’un fichier de mobilité comprenant une série de tuples (date, latitude, longitude) représentant les déplacements d’un taxi à travers le temps. Pour l’expérience, nous avons implémenté deux types d’agents : i) les agents individuels et ii) les agents collaboratifs. Les agents individuels exécutent la tâche de collecte en continu tout au long de l’expérience, c’est-à-dire qu’ils collectent toutes les 30 secondes leur position selon le fichier de mobilité, et propagent l’ensemble des données collectées sur le nœud de collecte toutes les 5 minutes. Quant aux agents collaboratifs, ils s’enregistrent auprès des capteurs virtuels selon leur position à un instant t, et exécutent la tâche de collecte lorsqu’ils ont reçu une demande d’exécution de la part du capteur virtuel. Pour assurer une montée en charge du simulateur, les agents sont répartis auprès de plusieurs machines 146virtuelles hébergées sur la plate-forme Microsoft Windows Azure 1 . Des machines virtuelles de taille Small (A1) 2 sont utilisées, correspondant à un processeur à 1 coeur, 1,75 Go de mémoire et une carte réseau de 100 Mbit/s. datagathering node : Pour la simulation, nous avons déployé un nœud de collecte (cf. section 4.4, page 100 ) sur une machine virtuelle hébergée sur Microsoft Windows Azure. Une machine virtuelle de taille Medium (A2) est utilisée, correspondant à un processeur à 2 coeurs, 3,5 Go de mémoire et une carte réseau de 200 Mbit/s. manager : Ce dernier composant est responsable de répartir les fichiers de mobilité auprès des agents déployées sur les machines virtuelles, et de lancer le début de la simulation afin de synchroniser les agents. Figure 35 – Architecture du simulateur de traces de mobilité Pour les simulations présentées dans la suite de ce chapitre, nous utilisons les données du 3 février 2008 représentant la journée où le plus de données ont été produites. Les tâches de collecte sont déployées dans une zone de collecte de 10 km2 situés dans le centre-ville de Pékin, durant une durée de 30 minutes. 1. http://azure.microsoft.com 2. http://azure.microsoft.com/en-us/pricing/details/virtual-machines 1476.3 résultats Dans cette section, nous présentons les résultats obtenus à travers les différentes expériences menées grâce au simulateur développé. Nous discutons des résultats en fonction de la quantité, de la couverture géographique des données collectées ainsi que de l’énergie utilisée par les dispositifs mobiles durant les expériences et du surcoût engendré par notre approche. Pour évaluer les gains de notre modèle de recrutement, nous avons déployé, à travers le simulateur, la tâche de collecte présentée dans le listing 6.1 suivant trois modèles appelé individual, coll(1000 m), et coll(500 m). individual : dans ce modèle, les dispositifs exécutent la tâche de collecte indépendamment les uns des autres. Ils obtiennent une nouvelle position du GPS toutes les 30 secondes, et exécutent la tâche de collecte lorsque leur position se situe dans la zone de collecte définie. coll(1000 m) : dans ce modèle, l’exécution de la tâche de collecte est coordonnée par les capteurs virtuels déployés dans le nœud de collecte. L’objectif de couverture est fixé tous les 1000 mètres dans la zone de collecte avec 5 dispositifs attribués à la tâche (cf. section 4.5.1). coll(500 m) : ce modèle est identique au précédent sauf que nous avons fait varier l’objectif de couverture tous les 500 mètres dans la zone de collecte. Cela nous permet d’étudier l’impact de la couverture définie sur la quantité de données collectées et sur la consommation énergétique des dispositifs mobiles. 6.3.1 Quantité de données et couverture géographique Tout d’abord, nous comparons la quantité des données collectées. Les courbes illustrées par la figure 36 comparent la quantité de données collectées (en kilobyte) pour les trois tâches de collecte déployées en fonction du nombre de dispositifs. La première tâche, illustrée par la courbe individual, représente la quantité de données lorsque les dispositifs collectent individuellement la tâche de collecte. Les deux suivantes, illustrées par les courbes coll(1000 m) et coll(500 m) représentent les tâches de collecte déployées en utilisant le modèle collaboratif. Nous avons fait varier entre 500 et 10000 le nombre de dispositifs simulés durant cette expérience. Comme le montre cette figure, lorsqu’aucune collaboration n’est effectuée, la quantité de données générées augmente linéairement, allant jusqu’à 12000 KB de données produites pour 10000 dispositifs. En effectuant une collaboration, la quantité de données se stabilise autour des 6000 KB pour 148un objectif de couverture de 500 m2 et 2500 KB pour un objectif de 1000 m2 . Pour 10000 dispositifs, cela représente respectivement une diminution de 50% et 80% de quantité de données propagées vers le serveur. Ce gain s’explique, car lorsque suffisamment de dispositifs se trouvent dans une même zone (par ex. plus de 5 dispositifs dans une zone de 500 m2 pour la tâche coll(500 m)), le capteur virtuel associé à cette zone attribut seulement à 5 dispositifs la tâche de collecte, évitant ainsi aux autres dispositifs de la même zone d’exécuter la tâche de collecte. Figure 36 – Comparaison de la quantité de données collectées en fonction du nombre de dispositifs mobiles et de l’objectif de couverture géographique Cependant, pour valider notre approche, il est essentiel de comparer la quantité de données avec la couverture réellement obtenue. Pour cela, nous avons mené une deuxième expérience impliquant 10000 dispositifs mobiles, et nous avons observé la couverture géographique obtenue à travers différentes périodes de la journée par rapport à la quantité de données collectées. La couverture est définie par le pourcentage de zone couverte par les données collectées, soit 400 zones de 500 m2 dans la zone de collecte d’une surface de 10 Km2 . La figure 37 illustre le résultat de cette expérience. Dans cette figure, les courbes bleu et verte représentent respectivement la couverture obtenue par les approches individuelle (individual-SP) et collaborative (coll(500 m)- 149SP), et les colonnes rouge (individual-Data) et jaune (coll(500 m)-Data) la quantité de données collectées par ces deux approches. Comme le montre cette figure, la couverture des données obtenue varie tout au long de la journée, pour atteindre un pic à 17 H représentant une forte mobilité des taxis dans la zone de collecte. Ce que nous pouvons observer d’intéressant, c’est que les couvertures obtenues par ces deux approches sont relativement équivalentes, bien que la quantité de données collectées par l’approche collaborative soit toujours inférieure à celle de l’approche individuel. La différence des couvertures obtenues entre les deux approches est due à la mobilité des taxis. En effet, si un taxi se déplace à grande vitesse, celui-ci peut traverser une zone avant que le capteur virtuel associé n’est le temps de lui attribuer une tâche. Cependant, dans cette simulation, la perte de la couverture obtenue ne varie pas au delà des 2%. Figure 37 – Comparaison de la couverture géographique selon différentes périodes de la journée À travers ces deux expériences, nous avons montré que l’approche collaborative que nous avons proposée permet de diminuer la quantité de données propagées vers le serveur tout en gardant une couverture presque similaire à une approche classique. Nous allons maintenant évaluer les gains de cette approche sur la consommation énergétique des dispositifs mobiles. 1506.3.2 Consommation énergétique Pour évaluer l’énergie consommée par les dispositifs mobiles liée au trafic réseau et à l’acquisition de la position par le GPS, nous utilisons deux modèles énergétiques très référencés dans la littérature. Le premier modèle, proposé par Balasubramanian et al. [5], permet de déterminer l’énergie liée à la transmission de données par des réseaux sans fil. Dans le contexte de cette évaluation, nous assumons que toutes les données sont transmises par un réseau 3G. Ce modèle divise l’énergie consommée en trois parties. La première est liée à l’activation de l’interface de communication évaluée à 3,5 Joules. La deuxième est liée à la transmission des données évaluée à 0.025 Joule/KB. Et la dernière est liée au temps que l’interface de communication soit désactivée après la transmission des données. Ce temps est évalué à 12,5 secondes et l’interface consomme 0,62 Joule/s jusqu’à ce qu’elle soit désactivée. Dans le cadre où deux transmissions de données sont effectuées en dessous des 12,5 secondes, l’énergie consommée par cette dernière partie est négligée. Pour le deuxième modèle, nous utilisons celui proposé par Lin et al. [43], qui évalue l’énergie liée à l’acquisition périodique d’une position par le GPS à 1,4 Joules par position obtenue. Les courbes illustrées par la figure 38 comparent la consommation énergétique des trois tâches de collecte déployées dans la première expérience de la section précédente par rapport à la concentration de dispositifs mobiles dans la zone de collecte. L’énergie est donnée en Joule et correspond à la moyenne énergétique consommée par l’ensemble des dispositifs mobiles. Comme attendue, la consommation énergétique de la tâche individuelle (individual) est indépendante de la concentration des dispositifs mobiles, et reste constante autour des 600 Joules en moyenne par dispositif. En revanche, les tâches collaboratives (coll(1000 m) et coll(500 m)) bénéficient de cette concentration croissante en évitant de collecter des données non nécessaires pour atteindre les objectifs de couverture, et ainsi réduire la consommation énergétique moyenne par dispositif. Pour coll(1000 m), le gain sur la consommation énergétique des dispositifs varie entre 43% pour 500 dispositifs et 82% pour 10000 dispositifs, tandis que pour coll(500 m), ce gain varie entre 40% et 70%. Afin de mieux comprendre où le gain énergétique est effectué, les graphiques de la figure 39 montrent la répartition des charges énergétiques consommées durant l’expérience pour les trois tâches individual (a), coll(1000 m) (b) et coll(500 m) (c). Dans cette figure, la partie bleue (Localisation) des colonnes représente la consommation 151Figure 38 – Comparaison des moyennes de la consommation énergétique en fonction de la concentration de dispositifs mobiles dans la zone de collecte causée par l’acquisition d’une position par le GPS, la partie rouge (Sensing Task) à l’exécution des Pings réseaux (cf. listing 6.1 ligne 4) et la partie orange (VS Messages) aux communications avec les capteurs virtuels. Comme le montre cette figure, le gain de la collaboration sur la consommation énergétique est particulièrement liée à l’acquisition des positions par le GPS. En effet, dans cette approche, les dispositifs ont seulement besoin d’obtenir une position pour déterminer à quel capteur virtuel ils doivent s’enregistrer, permettant à ces dispositifs de réduire la fréquence de l’acquisition d’une nouvelle position si leur vitesse est relativement réduite ou en position statique (cf. section 4.5.2, page 121 ). Cela représente dans cette expérience un gain respectif de 86% et 80% pour les tâches coll(1000 m) et coll(500 m). Dans ce contexte, une grande perte énergétique du modèle de recrutement individuelle s’explique par le fait que même les dispositifs ne se situant pas dans la zone de collecte sont obligés de continuellement activer leur GPS afin de déterminer s’ils sont dans la zone étudiée ou non. En ce qui concerne l’énergie consommée par l’exécution des Pings réseaux, le gain reste limité lorsque peu de dispositifs sont impliqués dans l’expérience. Pour le modèle coll(1000 m), le gain est seulement de 4% et devient négatif pour coll(500 m). Ceci s’explique par le surcoût énergétique engendré par les communications des dispositifs avec les capteurs virtuels. Néanmoins, le gain énergétique s’accroît lorsque plus de dispositifs sont impliqués pour atteindre 81% pour coll(1000 m) et 55% pour le modèle coll(500 m). 152Figure 39 – Répartition des charges énergétiques suivant les approches : (a) individuelle, (b) collaborative avec une objectif de couverture de 1000 m 2 , (c) collaborative avec un objectif de couverture de 500 m2 153Comme attendu, ces chiffres montrent que le gain énergétique lié à la coordination des tâches varie selon la concentration des dispositifs mobiles dans la zone de collecte et également des objectifs de couvertures définies. Cependant cela révèle également les limitations du modèle évalué dans ce chapitre. En effet, dans le contexte où la concentration des dispositifs mobiles est trop faible pour permettre une coordination des tâches, notre modèle consommerait plus qu’un modèle classique à cause des communications nécessaires avec les capteurs virtuels. D’autre part, notre modèle reste limité si l’objectif de couverture nécessaire pour la campagne de collecte doit être très élevé (par ex. tous les 50 mètres). Cela engendrerait un trafic réseau trop important, car les dispositifs seraient sens cesse en train de communiquer avec les capteurs virtuels, spécialement dans un cas de forte mobilité. Dans ce contexte, la solution proposée ici reste principalement efficace pour les campagnes de collecte nécessitant une couverture géographique de collecte d’une centaine de mètres ou plus. Quelques exemples de ce type de campagnes sont la mesure de la qualité de l’air [19], ou la mesure de la qualité des réseaux sans fil comme présentés dans ce chapitre [61]. 6.4 conclusion Nous avons présenté dans ce chapitre l’évaluation du modèle de recrutement collaboratif proposé dans APISENSE®. Ce modèle s’appuie sur la forte concentration des dispositifs en milieu urbain pour coordonner l’exécution des tâches de collecte entre ces dispositifs selon un objectif de couverture géographique. Pour évaluer ce modèle, nous avons présenté plusieurs expériences basées sur des traces réelles de mobilités provenant de 10000 taxis. Par le biais des expériences menées, nous avons montré qu’en coordonnant l’exécution des tâches, le modèle proposé comporte principalement deux avantages par rapport à un modèle de recrutement où tous les dispositifs les exécutent de manière indépendante. Les expériences ont montré que notre approche permet dans un premier temps de diminuer la quantité de données propagée sur le serveur de plus de 50% lorsque 10000 dispositifs mobiles sont impliqués, tout en gardant une couverture géographique des données collectées similaire. Nous avons également montré que la coordination des tâches de collecte permettait de diminuer la consommation énergétique de ces dispositifs jusqu’à 70%. 154Dans le prochain chapitre, nous concluons en faisant un bilan des contributions présentées dans ce manuscrit, et discutons des perspectives de développements et de recherches issues des travaux de cette thèse. 155Quatrième partie Conclusion 1577 C O N C L U S I O N Sommaire 7.1 Rappel des motivations 159 7.2 Rappel des contributions 160 7.2.1 Collecte mobile de données 160 7.2.2 Collecte répartie de données 161 7.3 Perspectives 162 Ce chapitre, qui finalise la présentation faite au travers de ce manuscrit, s’organise de la manière suivante. La section 7.1 rappelle le contexte dans lequel se sont inscrits les travaux réalisés et la problématique qui en est à l’origine. La section 7.2 résume les contributions décrites dans ce manuscrit. Enfin la section 7.3 définit un ensemble de pistes de recherche et de développement en lien avec les travaux de cette thèse. 7.1 rappel des motivations Le Mobile crowdsensing est une nouvelle alternative exploitant la foule de terminaux intelligents déjà déployés à travers le monde pour la collecte massive de données environnementales ou comportementales de la population. Ces dernières années, ce type de collecte de données a suscité l’intérêt d’un grand nombre d’acteurs industriels et académiques dans des domaines tels que l’étude de la mobilité urbaine, la surveillance de l’environnement, la santé ou l’étude des comportements sociaux. Malgré le potentiel du Mobile crowdsensing, les campagnes de collecte réalisées impliquant un grand nombre d’utilisateurs mobiles sont rares et restent principalement développées par des experts. Ceci est particulièrement dû à l’absence de prise en compte d’aspects non fonctionnels des systèmes proposés dédiés au MCS. En effet, réaliser une campagne de collecte impliquant un grand nombre d’utilisateurs mobiles demande de faire face à de nombreux défis. Ces défis incluent la protection de la vie privée des utilisateurs, les ressources énergétiques limitées des terminaux mobiles, la 159mise en place de modèles de récompense et de déploiement adaptés pour recruter les utilisateurs les plus à même de collecter les données désirées, ainsi que de faire face à l’hétérogénéité des plate-formes mobiles disponibles (par ex. Android, iOS...). À ce jour, beaucoup d’efforts ont principalement portés sur la réalisation de systèmes monolithiques, difficilement réutilisable dans un contexte non anticipé. Ce manque d’approche réutilisable demande généralement de devoir réinventer la roue pour chaque nouveau système, entravant ainsi l’adoption du MCS pour de nombreux acteurs n’ayant pas les compétences, ni le temps de développer un système capable de répondre à leurs exigences. Dans cette thèse, nous avons cherché à réétudier les architectures des systèmes dédiés au MCS pour adresser les limitations actuelles liées au développement, au déploiement et à l’exécution d’une campagne de collecte de données. Les différentes contributions proposées sont articulées autour APISENSE®, la plate-forme résultante des travaux de cette thèse. APISENSE® propose un environnement distribué permettant de simplifier le développement et le déploiement de campagnes de collecte de données à travers des utilisateurs mobiles. Nous décrivons dans la section suivante un résumé des contributions décrites dans ce manuscrit. 7.2 rappel des contributions Dans cette section, nous synthétisons nos contributions présentées dans le chapitre 3 et le chapitre 4 au travers de l’implémentation de la plate-forme APISENSE®. 7.2.1 Collecte mobile de données Dans notre première contribution, nous avons tout d’abord proposé un modèle de programmation pour simplifier le développement de tâches de collecte de données (cf. chapitre 3 section 3.3, page 59 ). Pour concevoir ce modèle, nous avons tenu compte de trois propriétés qui sont la portabilité, la généralité, et l’accessibilité. En ce qui concerne la portabilité, nous avons basé notre modèle sur le langage de script JavaScript, qui est facilement exécutable sur de nombreux systèmes d’exploitation des dispositifs mobiles actuels. Pour l’accessibilité, nous avons proposé une interface de programmation simple et efficace fournissant une abstraction complète des technologies mobiles. Et pour la généralité, l’interface a été conçue pour supporter une grande variété d’activités de 160collecte, comprenant la collecte opportuniste et participative (cf. chapitre 2 section 2.1.2, page 26 ). Plus particulièrement, l’interface proposée permet de facilement écouter les changements d’état des capteurs mobiles pour la collecte de données opportuniste, d’interagir avec l’utilisateur mobile pour la collecte de données participative ainsi que définir les stratégies de propagation des données. Nous avons également présenté dans ce chapitre l’architecture de l’environnement mobile (cf. chapitre 3 section 3.4, page 68 ) assurant l’exécution des tâches de collecte. Cette architecture met principalement l’accent sur la sécurité et le respect de la confi- dentialité des participants. Pour atteindre cet objectif, tous les scripts sont exécutés dans un bac à sable dédié. Ainsi, cela nous permet de contrôler tous les accès des scripts vers les capteurs des dispositifs mobiles. Par le biais d’une interface graphique, nous laissons la possibilité aux utilisateurs mobiles de définir des contraintes empêchant toute activité de collecte non désirées. Ces contraintes sont classifiées en quatre catégories : temporelles, géographiques, de ressources consommées et de capteurs utilisés. 7.2.2 Collecte répartie de données Dans cette deuxième contribution, le défi adressé concerne la généralité de la plateforme pour concevoir une grande variété de campagnes de collecte ainsi que son passage à l’échelle. Pour supporter une grande diversité de campagnes de collecte, nous avons proposé un Modèle de Variabilité (MC) [32] (en anglais FM pour Feature Model), capturant les différentes configurations d’une application serveur responsable de la gestion des campagnes de collecte (cf. chapitre 4 section 4.4.1, page 101 ). Cette configuration réside en cinq points : i) configurer l’environnement de développement des tâches de collecte, ii) choisir un modèle de recrutement des participants, iii) choisir une série de traitements sur les données collectées avant leur insertion dans la base de données (par ex. anonymisation des données), iv) spécifier l’indexation des données dans la base de données, v) exposer des services pour exploiter les données collectées. Ce modèle est ensuite fourni aux utilisateurs pour leur permettre de définir des exigences selon la spécificité des campagnes qu’ils veulent mener. À partir des ces exigences, une application serveur (appelée nœud de collecte) est générée et configurée fournissant un environnement dédié à la gestion des campagnes de collecte des utilisateurs. En ce qui concerne le passage à l’échelle de la plate-forme, nous avons proposé une architecture décentralisée, séparant les préoccupations du déploiement ainsi que de la 161collecte et l’analyse des données (cf. chapitre 4 section 4.2, page 92 ). L’architecture résultante est composée d’un ensemble de nœuds de collecte et d’un serveur central. Dans cette architecture, le serveur central est responsable du déploiement des tâches de collecte soumises par les nœuds de collecte vers les participants de la plate-forme qui se sont enregistrés au préalable. Les nœuds de collecte, quant à eux, fournissent un environnement dédié permettant aux utilisateurs de développer de nouvelles tâches de collecte, de les déployer auprès du serveur central, et d’exploiter les données qui ont été collectées durant l’exécution des tâches de collecte. Ce procédé a principalement deux avantages. Le premier est d’assurer une première couche d’anonymat des participants, dans le sens où tous les nœuds de collecte ne peuvent pas déployer les tâches de collecte sans passer par le serveur central. Le deuxième permet aux nouveaux utilisateurs de bénéficier d’un ensemble de participants déjà disponibles pour exécuter des tâches de collecte, leur évitant ainsi une longue période de recrutement. Finalement, nous avons proposé une extension de APISENSE® dédiée à l’optimisation de l’exécution de campagne de collecte communautaire (cf. chapitre 4 section 4.5, page 113 ). L’optimisation proposée permet de coordonner l’exécution des tâches de collecte entre les dispositifs mobiles en fonction de propriétés de couvertures géographique et temporelle. Principalement, cette optimisation a pour objectif dans un premier temps de diminuer la consommation énergétique globale de tous les dispositifs impliqués dans la campagne, et également de diminuer la quantité de données propagées vers le nœud de collecte. 7.3 perspectives Dans cette section, nous présentons un ensemble de pistes de développement et de recherche en lien avec les travaux présentés dans cette thèse. Une première contribution au développement d’APISENSE® serait dans un premier temps de porter l’application mobile sur les divers systèmes d’exploitation mobiles disponibles sur le marché (par ex. iOS, Windows Mobile). Bien que nous avons effectué une preuve de concept de la portabilité de l’application mobile d’APISENSE® sur iOS, le prototype réalisé n’est pas encore opérationnel pour être déployé à grande échelle. 162Concernant la partie serveur de APISENSE®, plusieurs améliorations à court terme peuvent être envisagées. La première concerne la sécurité lors de la propagation des données des dispositifs vers les nœuds de collecte. En effet, actuellement l’emplacement du participant peut être déterminé en identifiant l’adresse IP du point d’accès utilisé pour propager les données, permettant potentiellement d’identifier son domicile même si les données en elles-mêmes ne permettent pas de révéler cette information. Dans ce contexte, une priorité serait d’utiliser des routeurs ou relais spécifiques (par ex. routeur oignon [18]) pour cacher l’adresse IP lors de la propagation des données. Une autre amélioration à court terme serait d’intégrer des outils de visualisation génériques permettant de rapidement explorer les données collectées à travers une Interface web. Par exemple, il serait intéressant d’établir des connexions entre les nœuds de collecte et des services tels que CartoDB 1 ou Google Fusion Tables 2 qui proposent ce type de fonctionnalité. Une autre amélioration serait de supporter le déploiement automatique des nœuds de collecte vers les infrastructures des utilisateurs. Cette tâche reste encore manuelle et peut demander une certaine expertise pour administrer le système responsable de leurs exécutions. Certains travaux dans notre équipe ont déjà été initiés dans ce sens [53, 54] et nous prévoyons de rapidement les intégrer dans APISENSE®. D’autres pistes de développement seraient d’implémenter les différents modèles de protection de la vie privée et de récompense proposés dans la littérature. Dans ce contexte, il serait intéressant de déployer des campagnes utilisant ces différents modèles sur des échantillons de participants, afin d’évaluer leurs impacts sur leurs participations. Nous pensons que APISENSE® peut être une plate-forme idéale pour permettre aux scientifiques travaillant sur ces problématiques pour les aider à mettre au point et valider leurs algorithmes. Bien que le modèle de programmation proposé dans cette thèse fournisse une abstraction complète des technologies mobiles, une expertise en programmation est quand même nécessaire pour le développement des tâches de collecte. Dans ce contexte, il pourrait être intéressant de proposer un niveau d’abstraction encore plus élevé ne nécessitant aucune expertise. Ce niveau d’abstraction peut s’appuyer par exemple sur certains travaux déjà existant comme App Inventor 3 ou Alice [15] qui proposent 1. http://cartodb.com 2. http://tables.googlelabs.com 3. http://appinventor.mit.edu 163des métaphores visuelles pour le développement des applications, ou encore sur le langage naturel. Dans ce contexte, le modèle de programmation que nous avons proposé pourrait être utilisé comme langage pivot avec ce nouveau niveau d’abstraction. Une autre perspective serait de mettre en place des métriques permettant d’évaluer la qualité des données collectées. Très peu de recherche ont encore été menées dans ce sens, bien que cela représente une problématique importante de ce type d’applications. En effet, de nombreux facteurs peuvent influer sur la qualité des données comme le type de matériel utilisé, la mobilité des utilisateurs, etc. En effet, sans connaître le niveau de fiabilité des données, il peut être très difficile de savoir si les données collectées sont représentatives du monde réel ou du comportement des participants. La mise en place de ces métriques pourrait également permettre de mettre en place de nouveaux modèles de recrutement des participants dans les campagnes de collecte. Dans ce contexte, selon les exigences de la campagne, les participants fournissant les données de plus grande qualité pourraient être privilégiés. Dans cette thèse, nous avons particulièrement investi sur le développement d’un système de collecte de données avec APISENSE®. Cependant, la collecte en elle même ne représente qu’une partie des futurs systèmes d’informations se basant sur le pouvoir de la foule pour atteindre une quantité massive de données. De nombreux défis doivent encore être relevés pour traiter ces données, en extraire des comportements complexes et diffuser des informations en temps réel à partir de leurs analyses [68]. Un cas d’utilisation que nous souhaitons investir est l’utilisation du Mobile crowdsensing pour élaborer un système de détection de tremblement de terre. Certaines initiatives ont déjà vu le jour comme le projet Quake-Catcher Network [13], qui permet de recueillir les données issues des capteurs de mouvement présents dans les disques durs des ordinateurs, transformant alors ceux-ci en sismographes. Comme mentionné par Faulkner et al. [23], cette approche peut être complétée en utilisant les accéléromètres intégrés dans les dispositifs mobiles qui peuvent fournir une mesure plus précise et plus complète de la distribution géographique des secousses lors d’un tremblement de terre. Cependant, développer un système fiable, capable d’analyser continuellement les données produites par des centaines de milliers de capteurs, extraire uniquement les informations pertinentes et propager une alerte sismique seulement en quelques secondes restent actuellement un véritable défi. 164B I B L I O G R A P H I E [1] Nadav Aharony, Wei Pan, Cory Ip, Inas Khayal, and Alex Pentland. Social fmri : Investigating and shaping social mechanisms in the real world. Pervasive and Mobile Computing, 7(6) :643–659, 2011. [2] Marc P Armstrong, Gerard Rushton, Dale L Zimmerman, et al. Geographically masking health data to preserve confidentiality. Statistics in medicine, 18(5) :497–525, 1999. [3] Patrick Baier, Frank Durr, and Kurt Rothermel. Psense : Reducing energy consumption in public sensing systems. In Advanced Information Networking and Applications (AINA),26th International Conference on, pages 136–143. IEEE, 2012. [4] Rajesh Krishna Balan, Khoa Xuan Nguyen, and Lingxiao Jiang. Real-time trip information service for a large taxi fleet. In Proceedings of the 9th international conference on Mobile systems, applications, and services, pages 99–112. ACM, 2011. [5] Niranjan Balasubramanian, Aruna Balasubramanian, and Arun Venkataramani. Energy consumption in mobile phones : a measurement study and implications for network applications. In Proceedings of the 9th conference on Internet measurement conference, pages 280–293. ACM, 2009. [6] Niels Brouwers and Koen Langendoen. Pogo, a middleware for mobile phone sensing. In Proceedings of the 13th International Middleware Conference, pages 21–40. Springer-Verlag New York, Inc., 2012. [7] J Burke, D Estrin, M Hansen, A Parker, N Ramanathan, S Reddy, and MB Srivastava. Participatory sensing. In In : Workshop on World-Sensor-Web (WSW’06) : Mobile Device Centric Sensor Networks and Applications, 2006. [8] Iacopo Carreras, Daniele Miorandi, Andrei Tamilin, Emmanuel R Ssebaggala, and Nicola Conci. Matador : Mobile task detector for context-aware crowd-sensing campaigns. In Pervasive Computing and Communications Workshops (PERCOM Workshops), International Conference on, pages 212–217. IEEE, 2013. 165[9] Guanling Chen, David Kotz, et al. A survey of context-aware mobile computing research. Technical report, Technical Report TR2000-381, Dept. of Computer Science, Dartmouth College, 2000. [10] NM Chowdhury and Raouf Boutaba. A survey of network virtualization. Computer Networks, 54(5) :862–876, 2010. [11] Delphine Christin, Andreas Reinhardt, Salil S Kanhere, and Matthias Hollick. A survey on privacy in mobile participatory sensing applications. Journal of Systems and Software, 84(11) :1928–1946, 2011. [12] Paul Clements and Linda Northrop. Software product lines : practices and patterns. 2002. [13] Elizabeth S Cochran, Jesse F Lawrence, Carl Christensen, and Ravi S Jakka. The quake-catcher network : Citizen science expanding seismic horizons. Seismological Research Letters, 80(1) :26–30, 2009. [14] Ionut Constandache, Shravan Gaonkar, Matt Sayler, Romit Roy Choudhury, and Landon Cox. Enloc : Energy-efficient localization for mobile phones. In INFOCOM, pages 2716–2720. IEEE, 2009. [15] Stephen Cooper, Wanda Dann, and Randy Pausch. Teaching objects-first in introductory computer science. In ACM SIGCSE Bulletin, volume 35, pages 191–195. ACM, 2003. [16] Tathagata Das, Prashanth Mohan, Venkata N Padmanabhan, Ramachandran Ramjee, and Asankhaya Sharma. Prism : platform for remote sensing using smartphones. In Proceedings of the 8th international conference on Mobile systems, applications, and services, pages 63–76. ACM, 2010. [17] Linda Deng and Landon P Cox. Livecompare : grocery bargain hunting through participatory sensing. In Proceedings of the 10th workshop on Mobile Computing Systems and Applications, page 4. ACM, 2009. [18] Roger Dingledine, Nick Mathewson, and Paul Syverson. Tor : The secondgeneration onion router. Technical report, DTIC Document, 2004. [19] Prabal Dutta, Paul M Aoki, Neil Kumar, Alan Mainwaring, Chris Myers, Wesley Willett, and Allison Woodruff. Common sense : participatory urban sensing using 166a network of handheld air quality monitors. In Proceedings of the 7th ACM conference on embedded networked sensor systems, pages 349–350. ACM, 2009. [20] Shane B Eisenman, Emiliano Miluzzo, Nicholas D Lane, Ronald A Peterson, GahngSeop Ahn, and Andrew T Campbell. Bikenet : A mobile sensing system for cyclist experience mapping. ACM Transactions on Sensor Networks (TOSN), 6(1) :6, 2009. [21] Patrick Th Eugster, Pascal A Felber, Rachid Guerraoui, and Anne-Marie Kermarrec. The many faces of publish/subscribe. ACM Computing Surveys (CSUR), 35(2) : 114–131, 2003. [22] Hossein Falaki, Ratul Mahajan, and Deborah Estrin. Systemsens : a tool for monitoring usage in smartphone research deployments. In Proceedings of the sixth international workshop on MobiArch, pages 25–30. ACM, 2011. [23] Matthew Faulkner, Michael Olson, Rishi Chandy, Jonathan Krause, K Mani Chandy, and Andreas Krause. The next big one : Detecting earthquakes and other rare events from community-based sensors. In Information Processing in Sensor Networks (IPSN), 2011 10th International Conference on, pages 13–24. IEEE, 2011. [24] Zachary Fitz-Walter and Dian Tjondronegoro. Exploring the opportunities and challenges of using mobile sensing for gamification. In Proceedings of the 13th International Conference on Ubiquitous Computing (UbiComp’11) : Workshop on Mobile Sensing, 2011. [25] Jon Froehlich, Mike Y Chen, Sunny Consolvo, Beverly Harrison, and James A Landay. Myexperience : a system for in situ tracing and capturing of user feedback on mobile phones. In Proceedings of the 5th international conference on Mobile systems, applications and services, pages 57–70. ACM, 2007. [26] Sébastien Gambs, Marc-Olivier Killijian, and Miguel Núñez del Prado Cortez. Show me how you move and i will tell you who you are. In Proceedings of the 3rd ACM SIGSPATIAL International Workshop on Security and Privacy in GIS and LBS, pages 34–41. ACM, 2010. [27] Raghu K Ganti, Fan Ye, and Hui Lei. Mobile crowdsensing : Current state and future challenges. Communications Magazine, IEEE, 49(11) :32–39, 2011. [28] Chunming Gao, Fanyu Kong, and Jindong Tan. Healthaware : Tackling obesity with health aware smart phone systems. In Robotics and Biomimetics (ROBIO), 2009 IEEE International Conference on, pages 1549–1554. IEEE, 2009. 167[29] Shravan Gaonkar, Jack Li, Romit Roy Choudhury, Landon Cox, and Al Schmidt. Micro-blog : sharing and querying content through mobile phones and social participation. In Proceedings of the 6th international conference on Mobile systems, applications, and services, pages 174–186. ACM, 2008. [30] Kuan Lun Huang, Salil S Kanhere, and Wen Hu. Preserving privacy in participatory sensing systems. Computer Communications, 33(11) :1266–1280, 2010. [31] Anil K Jain and Richard C Dubes. Algorithms for clustering data. Prentice-Hall, Inc., 1988. [32] Kyo C Kang, Sholom G Cohen, James A Hess, William E Novak, and A Spencer Peterson. Feature-oriented domain analysis (foda) feasibility study. Technical report, DTIC Document, 1990. [33] Wazir Zada Khan, Yang Xiang, Mohammed Y Aalsalem, and Quratulain Arshad. Mobile phone sensing systems : a survey. Communications Surveys & Tutorials, IEEE, 15(1) :402–427, 2013. [34] Donnie H Kim, Younghun Kim, Deborah Estrin, and Mani B Srivastava. Sensloc : sensing everyday places and paths using less energy. In Proceedings of the 8th ACM Conference on Embedded Networked Sensor Systems, pages 43–56. ACM, 2010. [35] Stephen F King and Paul Brown. Fix my street or else : using the internet to voice local public service concerns. In Proceedings of the 1st international conference on Theory and practice of electronic governance, pages 72–80. ACM, 2007. [36] John Krumm. A survey of computational location privacy. Personal and Ubiquitous Computing, 13(6) :391–399, 2009. [37] Jennifer R Kwapisz, Gary M Weiss, and Samuel A Moore. Activity recognition using cell phone accelerometers. ACM SigKDD Explorations Newsletter, 12(2) :74–82, 2011. [38] Nicholas D Lane, Shane B Eisenman, Mirco Musolesi, Emiliano Miluzzo, and Andrew T Campbell. Urban sensing systems : opportunistic or participatory ? In Proceedings of the 9th workshop on Mobile computing systems and applications, pages 11–16. ACM, 2008. 168[39] Nicholas D Lane, Emiliano Miluzzo, Hong Lu, Daniel Peebles, Tanzeem Choudhury, and Andrew T Campbell. A survey of mobile phone sensing. Communications Magazine, IEEE, 48(9) :140–150, 2010. [40] Juong-Sik Lee and Baik Hoh. Dynamic pricing incentive for participatory sensing. Pervasive and Mobile Computing, 6(6) :693–708, 2010. [41] Juong-Sik Lee and Baik Hoh. Sell your experiences : a market mechanism based incentive for participatory sensing. In Pervasive Computing and Communications (PerCom), 2010 IEEE International Conference on, pages 60–68. IEEE, 2010. [42] P Lilly. Mobile devices to outnumber global population by 2017. URL http ://tinyurl. com/pbodtus [Accessedon : 2013-08-06]. [43] Kaisen Lin, Aman Kansal, Dimitrios Lymberopoulos, and Feng Zhao. Energyaccuracy trade-off for continuous mobile device location. In Proceedings of the 8th international conference on Mobile systems, applications, and services, pages 285–298. ACM, 2010. [44] Pengfei Liu, Yanhua Chen, Wulei Tang, and Qiang Yue. Mobile weka as data mining tool on android. In Advances in Electrical Engineering and Automation, pages 75–80. Springer, 2012. [45] Hong Lu, Nicholas D Lane, Shane B Eisenman, and Andrew T Campbell. Bubblesensing : Binding sensing tasks to the physical world. Pervasive and Mobile Computing, 6(1) :58–71, 2010. [46] C Matthew MacKenzie, Ken Laskey, Francis McCabe, Peter F Brown, Rebekah Metz, and Booz Allen Hamilton. Reference model for service oriented architecture 1.0. OASIS Standard, 12, 2006. [47] Nicolas Maisonneuve, Matthias Stevens, Maria E Niessen, and Luc Steels. Noisetube : Measuring and mapping noise pollution with mobile phones. In Information Technologies in Environmental Engineering, pages 215–228. Springer, 2009. [48] David J Malan and Henry H Leitner. Scratch for budding computer scientists. ACM SIGCSE Bulletin, 39(1) :223–227, 2007. [49] Emiliano Miluzzo, Nicholas D Lane, Kristóf Fodor, Ronald Peterson, Hong Lu, Mirco Musolesi, Shane B Eisenman, Xiao Zheng, and Andrew T Campbell. Sensing meets mobile social networks : the design, implementation and evaluation of the 169cenceme application. In Proceedings of the 6th ACM conference on Embedded network sensor systems, pages 337–350. ACM, 2008. [50] Prashanth Mohan, Venkata N Padmanabhan, and Ramachandran Ramjee. Nericell : rich monitoring of road and traffic conditions using mobile smartphones. In Proceedings of the 6th ACM conference on Embedded network sensor systems, pages 323–336. ACM, 2008. [51] Min Mun, Sasank Reddy, Katie Shilton, Nathan Yau, Jeff Burke, Deborah Estrin, Mark Hansen, Eric Howard, Ruth West, and Péter Boda. Peir, the personal environmental impact report, as a platform for participatory sensing systems research. In Proceedings of the 7th international conference on Mobile systems, applications, and services, pages 55–68. ACM, 2009. [52] Klaus Pohl, Günter Böckle, and Frank Van Der Linden. Software product line engineering : foundations, principles, and techniques. Springer, 2005. [53] Clément Quinton, Romain Rouvoy, and Laurence Duchien. Leveraging feature models to configure virtual appliances. In Proceedings of the 2nd International Workshop on Cloud Computing Platforms, page 2. ACM, 2012. [54] Clément Quinton, Nicolas Haderer, Romain Rouvoy, and Laurence Duchien. Towards multi-cloud configurations using feature models and ontologies. In Proceedings of the 2013 international workshop on Multi-cloud applications and federated clouds, pages 21–26. ACM, 2013. [55] Moo-Ryong Ra, Bin Liu, Tom F La Porta, and Ramesh Govindan. Medusa : A programming framework for crowd-sensing applications. In Proceedings of the 10th international conference on Mobile systems, applications, and services, pages 337–350. ACM, 2012. [56] Kiran K Rachuri, Mirco Musolesi, Cecilia Mascolo, Peter J Rentfrow, Chris Longworth, and Andrius Aucinas. Emotionsense : a mobile phones based adaptive platform for experimental social psychology research. In Proceedings of the 12th ACM international conference on Ubiquitous computing, pages 281–290. ACM, 2010. [57] Sasank Reddy, Deborah Estrin, Mark Hansen, and Mani Srivastava. Examining micro-payments for participatory sensing data collections. In Proceedings of the 12th ACM international conference on Ubiquitous computing, pages 33–36. ACM, 2010. 170[58] Mitchel Resnick, John Maloney, Andrés Monroy-Hernández, Natalie Rusk, Evelyn Eastmond, Karen Brennan, Amon Millner, Eric Rosenbaum, Jay Silver, Brian Silverman, et al. Scratch : programming for all. Communications of the ACM, 52 (11) :60–67, 2009. [59] Xiang Sheng, Jian Tang, and Weiyi Zhang. Energy-efficient collaborative sensing with mobile phones. In INFOCOM, 2012 Proceedings IEEE, pages 1916–1924. IEEE, 2012. [60] Xiang Sheng, Xuejie Xiao, Jian Tang, and Guoliang Xue. Sensing as a service : A cloud computing system for mobile phone sensing. In Sensors, 2012 IEEE, pages 1–4. IEEE, 2012. [61] Clayton Shepard, Ahmad Rahmati, Chad Tossell, Lin Zhong, and Phillip Kortum. Livelab : measuring wireless networks and smartphone users in the field. ACM SIGMETRICS Performance Evaluation Review, 38(3) :15–20, 2011. [62] Minho Shin, Cory Cornelius, Dan Peebles, Apu Kapadia, David Kotz, and Nikos Triandopoulos. Anonysense : A system for anonymous opportunistic sensing. Pervasive and Mobile Computing, 7(1) :16–30, 2011. [63] Sebastian Sonntag, Lennart Schulte, and Jukka Manner. Mobile network measurements-it’s not all about signal strength. In Wireless Communications and Networking Conference (WCNC), 2013 IEEE, pages 4624–4629. IEEE, 2013. [64] Latanya Sweeney. k-anonymity : A model for protecting privacy. International Journal of Uncertainty, Fuzziness and Knowledge-Based Systems, 10(05) :557–570, 2002. [65] Emiliano Trevisani and Andrea Vitaletti. Cell-id location technique, limits and benefits : an experimental study. In Mobile Computing Systems and Applications (WMCSA). Sixth IEEE Workshop on, pages 51–60. IEEE, 2004. [66] Yu Xiao, Pieter Simoens, Padmanabhan Pillai, Kiryong Ha, and Mahadev Satyanarayanan. Lowering the barriers to large-scale mobile crowdsensing. In Proceedings of the 14th Workshop on Mobile Computing Systems and Applications, page 9. ACM, 2013. [67] Jing Yuan, Yu Zheng, Xing Xie, and Guangzhong Sun. Driving with knowledge from the physical world. In Proceedings of the 17th ACM SIGKDD international conference on Knowledge discovery and data mining, pages 316–324. ACM, 2011. 171[68] Arkady Zaslavsky, Charith Perera, and Dimitrios Georgakopoulos. Sensing as a service and big data. arXiv preprint arXiv :1301.0159, 2013. [69] Gabe Zichermann and Christopher Cunningham. Gamification by design : Implementing game mechanics in web and mobile apps. " O’Reilly Media, Inc.", 2011. 172173 Contributions `a la v´erification et `a la validation efficaces fond´ees sur des mod`eles Alo¨ıs Dreyfus To cite this version: Alo¨ıs Dreyfus. Contributions `a la v´erification et `a la validation efficaces fond´ees sur des mod`eles. Computation and Language. Universit´e de Franche-Comt´e, 2014. French. HAL Id: tel-01090759 https://hal.inria.fr/tel-01090759 Submitted on 4 Dec 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Thèse de Doctorat é c o l e d o c t o r a l e s c i e n c e s p o u r l ’ i n g é n i e u r e t m i c r o t e c h n i q u e s U N I V E R S I T É D E F R A N C H E - C O M T É n Contributions à la vérification et à la validation efficaces fondées sur des modèles Aloïs DREYFUSThèse de Doctorat é c o l e d o c t o r a l e s c i e n c e s p o u r l ’ i n g é n i e u r e t m i c r o t e c h n i q u e s U N I V E R S I T É D E F R A N C H E - C O M T É THÈSE présentée par Aloïs Dreyfus pour obtenir le Grade de Docteur de l’Université de Franche-Comté Spécialité : Informatique Contributions à la vérification et à la validation efficaces fondées sur des modèles Unité de Recherche : FEMTO-ST DISC Soutenue le 22/10/2014 devant le Jury : Pierre-Cyrille Heam ´ Directeur de thèse Professeur à l’Université de Franche-Comté Olga Kouchnarenko Directrice de thèse Professeur à l’Université de Franche-Comté Ioannis Parissis Rapporteur Professeur à Grenoble INP Pierre Rety ´ Rapporteur Maître de Conférences HDR à l’Université d’Orléans Pascal Poizat Examinateur Professeur à l’Univ. Paris Ouest Nanterre La Défense N ◦ X X XRemerciements J’aimerais tout d’abord remercier mes encadrants et mentors, Olga et Pierre-Cyrille, qui m’ont fait confiance, soutenu et conseillé pendant 6 ans (2 ans en tant qu’ingénieur, puis 4 ans pour mon doctorat). Lorsque mon moral et ma motivation étaient en berne, au point que l’idée folle de jeter l’éponge a parfois effleuré mon esprit fatigué, vous avez su trouver quoi dire et/ou quoi faire pour m’encourager et m’aider à rester dans la course. Je remercie vivement les membres du jury, qui ont accepté d’évaluer mon travail de thèse et plus particulièrement les rapporteurs, Ioannis Parissis et Pierre Réty, qui ont en plus accepté la tâche conséquente de lire, comprendre et critiquer ce mémoire. Je tiens ensuite à remercier mes parents Pierrette et Laurent, ainsi que ma grande soeur Fanny et mon petit frère Chouch, pour leur sempiternel et inconditionnel soutien. J’ai de la chance de vous avoir, et je ne vous dirai jamais assez à quel point je vous aime ♥♥♥♥. Je remercie de même Nico et le loulou, pour tout le bonheur que vous apportez à notre famille depuis que vous en faites partie. Je remercie également celles et ceux qui m’ont aidé à tenir jusqu’au bout, parfois peut-être sans même s’en rendre compte. Je pense particulièrement à Cyber, Tcharlz, Nesnours, @ngel, Fouad, Oscar, Aydeé, Richard, Justine, Lysiane et Anne-Sorya. Et je ne voudrais surtout pas oublier de remercier ma soupape de décompression dijonnaise : Cyber, Anne-Sophie, Chloé, ainsi que Féfé et Jean-Marc, pour votre hospitalité, nos délires et nos discussions, qui m’ont fait un bien fou quand j’avais le moral dans les chaussettes ! Puis j’aimerais remercier mes compagnons de galère : Jibouille, Éric, Abdallah, Hamida, Hadrien, Doudou, P.C., Kalou, Jérôme, Oscar, Séb, Mathias, Roméo, Kerkouette, Sékou, Alexandru, Julien, Lionel, Ivan, Youssou, Bety, Nicolas, Jean-Marie, Fouad, Alexander, Vincent H., Rami, John, Guillaume, Lemia, David, Valérie, Naima, Paco, Sarga, Alban, Aydeé, Yanbo, Régis, Lamiel, Elena et Alexandre, pour l’ambiance agréable et conviviale qui rend les levers du matin plus faciles (ou moins difficiles, c’est selon). Je souhaite bon courage et bon vent à ceux qui rament en ce moment même. Il reste encore tellement de monde (amis, cousins, collègues, . . .) que j’apprécie vraiment et qui méritent que je les remercie, qu’il est clair que je ne pourrai pas être exhaustif. Donc j’espère que celles et ceux que je n’ai pas cités ne m’en tiendront pas rigueur.Sommaire I Introduction 15 1 Prologue 17 1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.3 Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 1.4 Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2 Préliminaires théoriques et notations 21 2.1 Automates et langages réguliers . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.1.1 Mots et langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.1.2 Automates finis et expressions régulières . . . . . . . . . . . . . . . . . 21 2.1.3 Produit d’automates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1.4 Isomorphisme d’automates . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.1.5 Réduction d’un automate . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.1.6 Transducteurs lettre à lettre finis . . . . . . . . . . . . . . . . . . . . . . 26 2.1.7 Appliquer un transducteur à un automate . . . . . . . . . . . . . . . . . 27 2.1.8 Appliquer un transducteur à un langage . . . . . . . . . . . . . . . . . . 28 2.2 Grammaires algébriques et automates à pile . . . . . . . . . . . . . . . . . . . . 28 2.2.1 Grammaires algébriques . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.2 Automates à pile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2.3 Génération aléatoire uniforme d’un arbre de dérivation dans une grammaire 31 2.2.4 D’un NPDA vers une grammaire algébrique . . . . . . . . . . . . . . . . 33 II Approximations régulières pour l’analyse d’accessibilité 35 3 Contexte et problématiques 39 3.1 Introduction et énoncé du problème . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2 Technique proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.3 Calcul de la sur-approximation . . . . . . . . . . . . . . . . . . . . . . . . . . . 43SOMMAIRE 8 3.4 Raffinement d’approximations . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 4 Contribution : Critères de fusion syntaxiques 49 4.1 In et Out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2 Left et Right . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.3 Combinaisons de fonctions d’approximation . . . . . . . . . . . . . . . . . . . . 53 4.4 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5 Contribution : Fonction d’approximation qui utilise les états du transducteur 55 5.1 Définitions supplémentaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2 Critère de fusion qui utilise les états du transducteur . . . . . . . . . . . . . . . . 58 5.3 Raffiner les approximations qui utilisent les états du transducteur . . . . . . . . . 61 5.4 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6 Conclusion de la partie II 67 III Combiner génération aléatoire et critère de couverture, à partir d’une grammaire algébrique ou d’un automate à pile 69 7 Contexte et problématiques 73 7.1 Le test logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7.1.1 Test automatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 7.1.2 Test à partir de modèles (MBT) . . . . . . . . . . . . . . . . . . . . . . 74 7.1.3 Critères de couverture . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 7.1.4 Test aléatoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.1.5 Génération aléatoire-uniforme d’un chemin dans un graphe fini . . . . . 75 7.1.6 Test à partir de modèles à pile . . . . . . . . . . . . . . . . . . . . . . . 76 7.2 Où se situe-t-on ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.2.1 Génération aléatoire de chemins contre parcours aléatoire . . . . . . . . 77 7.2.2 Combiner génération aléatoire et critères de couverture . . . . . . . . . . 78 7.2.3 Modèles réguliers (sans pile) contre modèles algébriques (à pile) . . . . . 80 7.2.4 Contribution : Combiner génération aléatoire et critères de couverture, dans des modèles à pile . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 8 Contribution : Application sur les grammaires 83SOMMAIRE 9 8.1 Calculer pX,n et pX,Y,n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 8.2 Calculer |EX,n(G)| et |EX,Y,n(G)| . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 8.3 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 9 Contribution : Application sur les automates à piles 91 9.1 Génération aléatoire-uniforme de DFA-Traces cohérentes . . . . . . . . . . . . . 93 9.1.1 Génération aléatoire de DFA-traces cohérentes . . . . . . . . . . . . . . 93 9.2 Critères de couverture d’un PDA . . . . . . . . . . . . . . . . . . . . . . . . . . 94 9.2.1 Le critère Tous les états . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 9.2.2 Le critère Toutes les transitions . . . . . . . . . . . . . . . . . . . . . . 95 9.2.3 Combiner test aléatoire et critères de couverture . . . . . . . . . . . . . . 97 9.3 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 9.3.1 Information technique . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 9.3.2 Exemple illustratif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 9.3.3 Exemple illustratif pour les critères de couverture . . . . . . . . . . . . . 101 9.3.4 Temps d’exécution sur plus d’exemples . . . . . . . . . . . . . . . . . . 103 9.4 Cas d’étude : l’algorithme Shunting-Yard . . . . . . . . . . . . . . . . . . . . . 106 9.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 9.4.2 Automate sous-jacent pour l’algorithme Shunting-Yard . . . . . . . . . . 106 9.4.3 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 9.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 10 Conclusion de la partie III 113 IV Conclusions et perspectives 115 11 Conclusions et perspectives 117Table des figures 2.1 Aex (Exemple d’automate) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2 Aex2 (Deuxième exemple d’automate) . . . . . . . . . . . . . . . . . . . . . . . 22 2.3 A1 × A2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.4 Aex × Aex2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.5 Automates isomorphes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.6 Aex/∼ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.7 T(A1)/∼exe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.8 In(Aex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.9 Tex (Exemple de transducteur) . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.10 Tex(Aex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.11 T(A1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.12 Token ring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.13 Arbre de dérivation correspondant à la séquence S, aS b, aT bb, abb . . . . . . . . 29 2.14 Apower, exemple de NPDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 2.15 Algorithme Génération aléatoire . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.16 Exemple d’une grammaire qui génère des DFA-traces cohérentes . . . . . . . . . 33 3.1 Approche par sur-approximation . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.2 Sur-approximations successives . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.3 Calcul de CRight(A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.4 Semi-algorithme PointFixe . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 3.5 Token ring : semi-algorithme PointFixe avec F = Left . . . . . . . . . . . . . . 45 3.6 Situation nécessitant un raffinement de l’approximation . . . . . . . . . . . . . . 46 3.7 Algorithme Analyse en arrière . . . . . . . . . . . . . . . . . . . . . . . . 46 3.8 Principe du raffinement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1 In(Aex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2 Out(Aex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.3 A Le f t,2 ex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 4.4 A Right,3 ex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51TABLE DES FIGURES 12 4.5 Left(Atr1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.6 Right(Aex) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.7 Résultats avec des critères syntaxiques . . . . . . . . . . . . . . . . . . . . . . . 54 5.1 x · Aex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.2 Aex3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.3 Aex4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.4 Token ring : Appliquer un transducteur T à un QC × Q ∗ T -automate (1) . . . . . . 57 5.5 Token ring : Appliquer un transducteur T à un QC × Q ∗ T -automate (2) . . . . . . 58 5.6 Token Ring : fusion en fonction des états du transducteur (1) . . . . . . . . . . . 59 5.7 Token ring : fusion en fonction des états du transducteur (2) . . . . . . . . . . . . 59 5.8 Semi-algorithme PointFixeT . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 5.9 Situation nécessitant un raffinement de l’approximation . . . . . . . . . . . . . . 62 5.10 Algorithme Séparer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.11 Algorithme Raffiner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 5.12 Exemples pour les algorithmes Séparer et Raffiner . . . . . . . . . . . . . . . 63 5.13 Semi-algorithme Vérif-avec-raffinement . . . . . . . . . . . . . . . . . . . 64 5.14 Types d’automates C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.15 Résultats avec la méthode reposant sur les états du transducteur comme critère de fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.1 Classification des différents types de tests . . . . . . . . . . . . . . . . . . . . . 74 7.2 Exemple de graphe fini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 7.3 Exemple 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 7.4 Exemple 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 7.5 Génération aléatoire - Algorithme 1 . . . . . . . . . . . . . . . . . . . . . . . . 79 7.6 Génération aléatoire - Algorithme 2 . . . . . . . . . . . . . . . . . . . . . . . . 79 7.7 Génération aléatoire - Algorithme 3 . . . . . . . . . . . . . . . . . . . . . . . . 80 7.8 Calcul des probabilités πe, afin d’optimiser la probabilité de couvrir C . . . . . . 80 7.9 Programme en C, qui calcule x n . . . . . . . . . . . . . . . . . . . . . . . . . . 81 7.10 Graphe de flot de contrôle de x n . . . . . . . . . . . . . . . . . . . . . . . . . . 81 8.1 Arbre de dérivation de la grammaire G de l’exemple 8.3 . . . . . . . . . . . . . . 86 8.2 Arbre de dérivation de la grammaire GX de l’exemple 8.3 . . . . . . . . . . . . . 86 9.1 Méthode de test aléatoire d’un programme . . . . . . . . . . . . . . . . . . . . . 92 9.2 Génération aléatoire de DFA-traces cohérentes . . . . . . . . . . . . . . . . . . . 93TABLE DES FIGURES 13 9.3 Automate sous-jacent de A6 exe . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 9.4 Automate sous-jacent de A (6,h,9) exe . . . . . . . . . . . . . . . . . . . . . . . . . . 96 9.5 Calcul des probabilités πq, afin d’optimiser la probabilité de couvrir Q . . . . . . 97 9.6 Fonctions mutuellement récursives . . . . . . . . . . . . . . . . . . . . . . . . . 98 9.7 Amodulo : NPDA de l’exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 9.8 Automate Axpath . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 9.9 Algorithme Shunting-Yard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 9.10 Automate sous-jacent pour l’algorithme Shunting-Yard . . . . . . . . . . . . . . 108 9.11 Implémentation en C de l’algorithme Shunting-Yard, que nous avons testée 1/2 . 109 9.12 Implémentation en C de l’algorithme Shunting-Yard, que nous avons testée 2/2 . 110I Introduction1 Prologue 1.1/ Contexte Le développement de programmes sûrs, sécurisés et exempts de bogues est un des problèmes les plus difficiles de l’informatique moderne. Les logiciels sont omniprésents dans notre quotidien, et on leur confie des tâches de plus en plus sensibles, comme le transfert de nos données bancaires lorsque l’on commande sur internet. On parle de logiciels critiques lorsque les conséquences d’un dysfonctionnement peuvent être particulièrement graves, comme lorsque des vies ou lorsque d’importantes sommes d’argent (millions/milliards d’euros) sont en jeux. Sont concernés par exemple les logiciels utilisés pour les systèmes de transport (avions, trains, voitures, . . .), l’énergie (réseau de distribution, centrales, . . .), la santé (gestion des hôpitaux, appareils médicaux, . . .), la finance (bourse, paiement en ligne ou par carte, . . .), ou encore dans le domaine militaire (missiles, drones, communications cryptées, . . .) ou dans l’aérospatiale (fusées, satellites, . . .). Il est donc indispensable de pouvoir s’assurer de la qualité de ces logiciels. Dans ce contexte, on peut distinguer deux techniques complémentaires pour évaluer la qualité d’un système informatique : la vérification et le test. La vérification consiste à prouver mathématiquement qu’un code ou un modèle d’application ré- pond aux attentes (ou propriétés) décrites dans sa spécification. Elle peut se faire avec un assistant de preuve (par exemple Coq) qui aide l’ingénieur à construire des preuves formelles, pouvant même démontrer certains lemmes de façon automatique. La vérification peut aussi se faire par évaluation de modèle – on utilise couramment le terme anglais model-checking –, qui est une méthode qui tente de vérifier si d’après le modèle du système, l’ensemble de ses états atteignables satisfait (ou pas) des propriétés. Un des principaux inconvénients de la vérification est la complexité algorithmique des techniques existantes, qui les rend difficilement applicables à des systèmes de taille importante. Contrairement à la vérification, le test ne fournit pas de preuve formelle en amont. Mais les techniques de test sont applicables à des systèmes de grande taille, et en pratique elles sont pertinentes dans le développement de logiciels de qualité. Le test occupe une part de plus en plus importante du développement de logiciels, au point que se développent des méthodes de développement piloté par les tests – abrégé en TDD, pour l’anglais Test Driven Development –, qui préconisent d’écrire les tests avant d’écrire le code source. Au cours de la dernière décennie, afin de faire face à cette importance croissante de la phase de test, de nombreux travaux ont été réalisés dans l’objectif de passer des méthodes de test manuelles (fondées sur l’expérience) à des méthodes automatiques ou semi-automatiques fondées sur des méthodes formelles.PARTIE I. Introduction - CHAPITRE 1. PROLOGUE 18 1.2/ Contributions Cette thèse présente des contributions à la vérification et à la validation à base de modèles. Notre contribution dans le cadre de la vérification, consiste à définir deux nouvelles techniques d’approximation pour le model-checking régulier, dans le but de fournir des (semi-)algorithmes efficaces. On calcule des sur-approximations de l’ensemble des états accessibles, avec l’objectif d’assurer la terminaison de l’exploration de l’espace d’états. L’ensemble des états accessibles (ou les sur-approximations de cet ensemble) est représenté par un langage régulier, lui même codé par un automate fini. La première technique consiste à sur-approximer l’ensemble des états atteignables en fusionnant des états des automates, en fonction de critères syntaxiques simples, ou d’une combinaison de ces critères (cf. section 4). La seconde technique d’approximation consiste aussi à fusionner des états des automates, mais cette fois-ci à l’aide d’un transducteur (cf. section 5.2). De plus, pour cette seconde technique, nous développons une nouvelle approche pour raffiner les approximations (cf. section 5.3), qui s’inspire du paradigme CEGAR (cf. section 3.4). Ces deux techniques d’approximation pour le model-checking régulier ont été publiées dans [DHK13a]. Pour le test, notre contribution est la définition d’une technique qui permet de combiner la génération aléatoire avec un critère de couverture, à partir d’une grammaire algébrique ou d’un automate à pile. Dans [DGG+12], il est expliqué comment biaiser une approche de test aléatoire uniforme dans un graphe fini, en utilisant des contraintes données par un critère de couverture, afin d’optimiser la probabilité de satisfaire ce critère. Mais un graphe fini représente souvent une abstraction forte du système sous test, il y a donc un risque que de nombreux tests abstraits ne soient pas concrétisables (c’est-à-dire jouables sur l’implémentation). Nous avons enrichi cette approche afin de l’appliquer sur des modèles algébriques (des grammaires algébriques dans le chapitre 8, et des automates à pile dans le chapitre 9), ce qui permet de réduire le degré d’abstraction du modèle et donc de générer moins de tests non concrétisables. Notre technique qui permet de combiner la gé- nération aléatoire avec un critère de couverture à partir d’une grammaire algébrique a été publiée dans [DHK13b], et celle sur les automates à pile a été publiée dans [DHKM14]. 1.3/ Plan Dans le chapitre 2, nous introduisons toutes les définitions, notations, propositions et théorèmes indispensables à la lecture de cette thèse. Nous présentons tout d’abord les notions relatives aux automates et langages réguliers, puis les notions relatives aux grammaires algébriques et aux automates à pile. La partie II présente nos contributions dans le domaine de la vérification : Le chapitre 3 introduit le model-checking régulier et le raffinement d’approximations. Dans le chapitre 4, nous présentons une technique pour le model-checking régulier, qui consiste à sur-approximer l’ensemble des états atteignables en fusionnant des états des automates, en fonction de critères syntaxiques simples, ou d’une combinaison de ces critères. Le chapitre 5 présente une technique utilisant un nouveau critère de fusion, qui exploite la relation de transition du système. La partie III présente nos contributions dans le domaine du test : Le chapitre 7 présente le contexte de nos travaux. Nous combinons ensuite de la génération aléatoire avec un critère de couverture, dans une grammaire (chapitre 8), puis dans un automate à pile (chapitre 9).PARTIE I. Introduction - CHAPITRE 1. PROLOGUE 19 1.4/ Publications Cette thèse s’appuie sur des travaux ayant fait l’objet de publications. Voici une liste de celles auxquelles j’ai participé : [DHK13a] contient deux méthodes de model-checking régulier : La première méthode utilise des critères syntaxiques que l’on peut combiner avec des opérateurs logiques (cf. chapitre 4), et la seconde exploite la relation de transition du système (cf. chapitre 5). [DHK13b] expose notre méthode pour combiner de la génération aléatoire avec un critère de couverture, dans le cadre du test à partir d’une grammaire (cf. chapitre 8). [DHKM14] détaille comment combiner de la génération aléatoire avec un critère de couverture, à partir d’un automate à pile (cf. chapitre 9).2 Preliminaires th ´ eoriques et notations ´ Cette section présente les notations et définitions nécessaires à la compréhension du document. 2.1/ Automates et langages reguliers ´ 2.1.1/ Mots et langages Un alphabet est un ensemble fini d’éléments appelés lettres. Un mot u sur un alphabet Σ est une juxtaposition de lettres de Σ. Le nombre de lettres de u (comptées avec multiplicité) est appelé longueur de u. L’ensemble des mots sur un alphabet Σ est noté Σ ∗ . On appelle langage sur un alphabet Σ tout sous-ensemble de Σ ∗ . Le mot vide (le mot de longueur nulle) est noté ε. L’ensemble Σ ∗ \ {ε} est noté Σ + . 2.1.2/ Automates finis et expressions reguli ´ eres ` Un automate fini A sur un alphabet Σ est un 5-uplet (Q, Σ, E, I, F) où : — Q est l’ensemble fini des états, — E ⊆ Q × Σ × Q est l’ensemble fini des transitions, — I ⊆ Q est l’ensemble fini des états initiaux, — F ⊆ Q est l’ensemble fini des états finaux. Dans le cadre de nos recherches nous avons uniquement travaillé sur des automates finis, l’utilisation par la suite du terme "automate" désignera donc un automate fini. Le terme "automate fini" est abrégé en NFA, pour l’anglais Nondeterministic Finite Automaton. On définit la taille de A par |A| = |Q| + |E|. Un automate est déterministe si I est un singleton et pour tout (p, a) ∈ Q × Σ il existe au plus un q ∈ Q tel que (p, a, q) ∈ E. Le terme "automate déterministe" est abrégé en DFA, pour l’anglais Deterministic Finite Automaton. Un automate est complet si pour tout (p, a) ∈ Q × Σ il existe au moins un q ∈ Q tel que (p, a, q) ∈ E. Pour une transition de la forme (p, a, q), p est l’état de départ, a est l’étiquette, et q est l’état d’arrivée. Deux transitions (p1, a1, q1) et (p2, a2, q2) sont dites consécutives si q1 = p2. Un chemin de A est une suite finie (éventuellement vide) de transitions (p1, a1, q1) . . . (pn, an, qn) consécutives. Le nombre entier n est la longueur du chemin, et le mot a1 . . . an est son étiquette. On dit qu’un chemin est réussi lorsque p1 est un état initial, et qn un état final. Un mot u est reconnu par A si u est l’étiquette d’un chemin réussi de A. On appelle langage reconnu par A l’ensemble des mots reconnus par l’automate A, et on le note L(A). Si A est déterministe et complet, pour tout état p et tout mot u, il existe un unique état de A, noté p ·A u accessible en lisant à partir de l’état p, un chemin étiqueté par u. S’il n’y a pas d’ambiguïté sur l’automate A, on écrit plus simplement p · u. Par convention, soit ε le mot vide, p · ε = p. Un état p est accessible s’il existe un chemin d’un état initial vers p, et co-accessible s’il existe unPARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 22 chemin de p vers un état final. Un automate dont les états sont tous accessibles et co-accessibles est dit élagué. Si A n’est pas élagué, supprimer tous ses états qui ne sont pas à la fois accessibles et co-accessibles, ainsi que toutes les transitions liées, produit un automate élagué qui reconnaît le même langage. Dans les figures, les automates sont généralement donnés sous forme élaguée afin d’en faciliter la compréhension. Une expression régulière sur un alphabet Σ est une expression reg définie par la grammaire suivante : reg := B | (reg ∪ reg) | (reg · reg) | reg∗ , où B est un ensemble fini de mots. Par exemple ({ab, b} ∗ ∪({aa}· {a} ∗ )) est une expression régulière sur {a, b}. Pour simplifier, si u est un mot et reg une expression régulière, les expressions du type {u} ∗ , {u} · L et L · {u} sont respectivement écrites u ∗ , u · L (ou même uL) et L · {u} (et même Lu). De plus, on omet parfois les parenthèses, l’étoile étant prioritaire sur le produit, lui-même prioritaire sur l’union. L’expression ({ab, b} ∗∪({aa}·{a} ∗ )) sera simplement notée {ab, b} ∗∪aaa∗ . On confondra dans la suite une expression régulière avec le langage qu’elle reconnaît, la sémantique étant naturellement celle de l’union, produit et de l’étoile sur les langages. Exemple 2.1. La figure 2.1 et la figure 2.2 représentent Aex et Aex2, qui sont deux exemples d’automates finis. L’automate Aex (figure 2.1) reconnaît les mots de la forme a∗ba, ou a∗bb, ou a ∗bba, ou a∗bbc. L’automate Aex2 = (Qex2, Σex2, Eex2, Iex2, Fex2) (figure 2.2) reconnaît les mots de la forme b∗ c, et on a Qex2 = {1, 2}, Σex2 = {b, c}, Eex2 = {(1, b, 1), (1, c, 2)}, Iex2 = {1} et Fex2 = {2}. 1 2 3 a b b 4 a a, c Aex Figure 2.1 – Aex (Exemple d’automate) 1 2 b c Figure 2.2 – Aex2 (Deuxième exemple d’automate) Définition 2.1. Langage régulier Un langage est dit régulier s’il appartient à la plus petite famille de langages contenant les langages finis et close par union, produit et étoile.PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 23 D’après le théorème de Kleene, un langage est régulier si et seulement s’il est reconnu par un automate fini. De plus, un langage est régulier si et seulement s’il est exprimable par une expression régulière. Il faut aussi noter que l’on peut montrer que l’ensemble des langages réguliers sur un alphabet donné est clos par intersection et complément. Définition 2.2. Problème régulier Un problème est dit régulier s’il est représentable avec uniquement des langages réguliers. 2.1.3/ Produit d’automates Le produit de deux automates, A1 = (Q1, Σ1, E1, I1, F1) et A2 = (Q2, Σ2, E2, I2, F2), noté A1×A2, est l’automate (Q, Σ, E, I, F) où : — Q = Q1 × Q2, — Σ = Σ1 T Σ2, — E = {((p1, p2), a, (q1, q2)) | ∃a ∈ Σ1 T Σ2, (p1, a, q1) ∈ E1, (p2, a, q2) ∈ E2}, — I = I1 × I2, — F = F1 × F2. Intuitivement, l’ensemble des chemins de A1 × A2 est composé des chemins qui existent à la fois dans A1 et dans A2 (au nom des états près). Il reconnaît les mots qui font à la fois partie du langage de A1 et du langage de A2. L(A1 × A2) = L(A1) T L(A2). Exemple 2.2. La figure 2.3 représente deux automates A1 et A2 ainsi que leur produit, notée A1 × A2. 1 2 a a, b b (a) A1 4 3 a b b a (b) A2 1, 4 2, 4 1, 3 2, 3 a a b a b b b a (c) A1 × A2 Figure 2.3 – A1 × A2 Exemple 2.3. L’automate Aex reconnaît les mots de la forme a∗ba, ou a∗bb, ou a∗bba, ou a∗bbc, et Aex2 reconnaît les mots de la forme b∗ c. Le produit Aex ×Aex2 de ces deux automates reconnaît donc le mot bbc. La figure 2.4 représente la version élaguée de l’automate Aex × Aex2 (c’est-à- dire qu’on a enlevé les états qui ne sont pas atteignables à partir d’un état initial, et les états qui n’atteignent aucun état final). 2.1.4/ Isomorphisme d’automates Deux automates A1 = (Q1, Σ, E1, I1, F1) et A2 = (Q2, Σ, E2, I2, F2) sont isomorphes s’il existe une bijection f : Q1 → Q2 qui satisfait (p, a, q) ∈ E1 si et seulement si (f(p), a, f(q)) ∈ E2, et f(I1) = I2, f(F1) = F2.PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 24 1 2 3 a b b 4 a a, c Aex 1 2 b c Aex2 1, 1 2, 1 3, 1 4, 2 b b c Aex × Aex2 Figure 2.4 – Aex × Aex2 Autrement dit, deux automates sont isomorphes s’ils sont identiques à un renommage des états près. Exemple 2.4. La figure 2.5 représente deux automates isomorphes : Aex et A 0 ex. La bijection f : Qex → Q 0 ex est la suivante : f(1) = 0, f(2) = 2, f(3) = 1, f(4) = 3. 1 2 3 a b b 4 a a, c Aex 0 2 1 a b b 3 a a, c A 0 ex Figure 2.5 – Automates isomorphes 2.1.5/ Reduction d ´ ’un automate Soient A un automate, Aˆ = (Qˆ, Σ, Eˆ, ˆI, Fˆ) l’automate élagué obtenu à partir de A, et ∼⊆ Q × Q une relation d’équivalence. On note A/∼ l’automate (Qˆ/∼, Σ, E 0 , I 0 , F 0 ) où E 0 = {( ˜p, a, q˜) | ∃p ∈ p˜ et ∃q ∈ q˜ tels que (p, a, q) ∈ Eˆ}, I 0 = {p˜ | ∃p ∈ p˜ T ˆI}, et F 0 = {p˜ | ∃p ∈ p˜ T Fˆ}. Intuitivement, l’automate A/∼ est obtenu en regroupant les états de chaque classe d’équivalence de la version élaguée de A. Il est trivial que L(A) ⊆ L(A/∼). La notion de réduction d’automate peut également être étendue à toutes les relations : si ∼ est une relation sur Q alors A/∼ est l’automate A/∼, où ∼ est la fermeture réflexive, symétrique et transitive de ∼. Exemple 2.5. Soit ∼ une relation sur Q définie comme ceci : soit p et q deux états de A, p∼q si et seulement s’il existe dans A une transition qui va de p vers q et qui a pour étiquette la lettrePARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 25 c. Pour Aex on a 3∼4. La relation ∼ n’étant pas une relation d’équivalence, Aex/∼ est l’automate Aex/∼ tel que ∼ est la fermeture réflexive, symétrique, et transitive de ∼. On obtient cet automate en fusionnant l’état 3 avec l’état 4, qui font partie d’une même classe d’équivalence (cf. figure 2.6). 1 2 3 a b b 4 a a, c Aex 1 2 3, 4 a b b, a a, c Aex/∼ Figure 2.6 – Aex/∼ Exemple 2.6. D’après l’automate T(A1) (cf. figure 2.11) et la relation ∼exe dont les classes sont {(1, 4), (2, 4), (1, 3)} et {(2, 3)}, l’automate T(A1)/∼exe est représenté sur la Fig. 2.7. 1, 4 2, 4 1, 3 2, 3 b b a b a a a b (a) T(A1) 1,4 2,4 1,3 2,3 b a a, b (b) T(A1)/∼exe Figure 2.7 – T(A1)/∼exe Définition 2.3. Fonction d’approximation Une fonction d’approximation F est une fonction qui associe à tout automate A, une relation ∼ A F sur les états de A. L’automate A/∼ A F sera noté F(A). On défini inductivement F n (A) par F 0 (A) = A, et F n (A) = F(F n−1 (A)) pour n > 0. La fonction d’approximation F est isomorphisme-compatible si pour toute paire d’automates isomorphes A1, A2, et pour tout isomorphisme ϕ de A1 vers A2, p ∼ A1 F q si et seulement si ϕ(p) ∼ A2 F ϕ(q). Intuitivement, cela signifie que pour être isomorphisme-compatible, une fonction d’approximation ne doit pas dépendre du nom des états. Exemple 2.7. Soit In la fonction d’approximation qui associe à tout automate A, la relation ∼ A In sur les états de A telle que, soient p et q deux états de A, p ∼ A In q si et seulement si l’ensemblePARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 26 des étiquettes des transitions qui arrivent sur l’état p est égal à l’ensemble des étiquettes des transitions qui arrivent sur l’état q. Dans l’automate Aex de la figure 2.8, 2 ∼ Aex In 3 car l’ensemble des étiquettes des transitions qui arrivent sur l’état 2 est égal à l’ensemble des étiquettes des transitions qui arrivent sur l’état 3 (qui est égal à {b}). Pour obtenir l’automate In(Aex), on fusionne donc l’état 2 et l’état 3 de l’automate Aex (cf. figure 2.8). 1 2 3 a b b 4 a a, c Aex 1 2, 3 a b b 4 a, c In(Aex) Figure 2.8 – In(Aex) 2.1.6/ Transducteurs lettre a lettre finis ` Un transducteur lettre à lettre fini T est un automate fini dont l’alphabet Σ est de la forme Σe × Σs , où Σe est appelé alphabet d’entrée et Σs est appelé alphabet de sortie. On notera les étiquettes (ae, as) sous la forme ae|as . L’étiquette d’un chemin ae1|as1 . . . aen|asn s’écrira sous la forme d’un couple (ae1 . . . aen, as1 . . . asn). Tout transducteur T sur Σe × Σs induit une relation RT sur Σ ∗ e × Σ ∗ s définie par : pour tous aei ∈ Σe et as j ∈ Σs , (ae1 . . . aen, as1 . . . asm) ∈ RT si et seulement si n = m et le mot (ae1, as1) . . . (aen, asn) est reconnu par T. Pour tout langage I, RT (I) est l’ensemble des mots v tels qu’il existe un mot u dans I, et (u, v) ∈ RT . La clôture réflexive et transitive de RT est notée R ∗ T . La notion de transducteur est dans la littérature plus générale que la définition donnée ici. Mais comme nous n’utiliserons que des transducteurs lettre à lettre, l’utilisation dans la suite du document du terme transducteur désignera un transducteur lettre à lettre fini. Exemple 2.8. La figure 2.9 représente Tex, qui est un exemple de transducteur. Soit Tex = (Qex, Σeex × Σsex, Eex, Iex, Fex), on a Qex = {1, 2, 3}, Σeex = {a, b}, Σsex = {a, b}, Eex = {(1, a|a, 1), (1, b|b, 1), (1, b|a, 2), (2, a|b, 3), (3, a|a, 3), (3, b|b, 3)}, Iex = {1} et Fex = {1, 3}. 1 2 3 a|a, b|b a|a, b|b b|a a|b Tex Figure 2.9 – Tex (Exemple de transducteur)PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 27 2.1.7/ Appliquer un transducteur a un automate ` Soit A = (QA, ΣA, EA, IA, FA) un automate, et T = (QT , ΣeT ×ΣsT , ET , IT , FT ) un transducteur, T(A) est l’automate (Q, Σ, E, I, F) défini par : — Q = QA × QT , — Σ = ΣsT , — E = {(pA, pT ), b, (qA, qT ) | ∃a ∈ ΣA T ΣeT et ∃b ∈ ΣsT tels que (pA, a, qA) ∈ EA et (pT , a|b, qT ) ∈ ET }, — I = IA × IT , — F = FA × FT . Intuitivement, l’application d’un transducteur T à un automate A ressemble beaucoup à un produit d’automates. Sauf qu’on utilise l’alphabet d’entrée du transducteur pour trouver les chemins en commun, mais qu’on remplace ensuite la lettre d’entrée par la lettre de sortie correspondante. Par définition, L(T(A)) est l’ensemble des mots v qui satisfont (u, v) ∈ RT avec u ∈ L(A). Si T = (QT , ΣeT × ΣsT , ET , IT , FT ) est un transducteur, on note T −1 le transducteur (QT , ΣsT × ΣeT , E 0 T , IT , FT ) avec E 0 T = {(p, (b, a), q) | (p, (a, b), q) ∈ ET }. On peut démontrer que (u, v) ∈ RT si et seulement si (v, u) ∈ RT−1 . Exemple 2.9. T ex(Aex) L’automate Aex reconnaît les mots de la forme a∗ba, a ∗bb, a∗bba et a∗bbc, et le transducteur Tex reconnaît les mots de la forme [(a|a) ∪ (b|b)]∗ (b|a)(a|b)[(a|a) ∪ (b|b)]∗ . L’application Tex(Aex) du transducteur Tex à l’automate Aex reconnaît donc les mots de la forme a∗ab, a∗bab, a∗ba, a∗bb, et a∗bba. La figure 2.10 représente une version élaguée de l’automate Tex(Aex) (c’est-à-dire qu’on a enlevé les états qui ne sont pas atteignables à partir d’un état initial, et les états qui n’atteignent aucun état final). 1 2 3 a b b 4 a a, c Aex 1 2 3 a|a, b|b a|a, b|b b|a a|b Tex 1, 1 2, 1 3, 1 a b b 2, 2 a 3, 2 a 4, 3 b b 4, 1 a a Tex(Aex) Figure 2.10 – Tex(Aex) Exemple 2.10. T (A1) D’après le transducteur T et l’automate A1 (cf. figure 2.11), T(A1) est représenté sur la figure 2.11. Exemple 2.11. Token ringPARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 28 1 2 a a, b b (a) A1 4 3 a|b b|a b|a a|b (b) T 1, 4 2, 4 1, 3 2, 3 b b a b a a a b (c) T(A1) Figure 2.11 – T(A1) 1 2 b a (a) Atr 3 4 a|b a|a, b|b b|a (b) Ttr 1, 4 1, 3 2, 3 b a b a (c) Atr1=Ttr(Atr) après élagage Figure 2.12 – Token ring 2.1.8/ Appliquer un transducteur a un langage ` Soit T = (Q, Σe × Σs , E, I, F) un transducteur et K un langage, l’application de T à K donne un langage T(K) = {v ∈ Σ ∗ s |∃u ∈ K, (u, v) ∈ L(T)} (avec la convention (a|b)(c|d) = (ac, bd)). Proposition 2.12 Soit A un automate et T un transducteur, T(L(A)) = L(T(A)) L’application d’un transducteur à un automate et l’application d’un transducteur à un langage sont deux opérations étroitement liées. Il est connu que l’application d’un transducteur T au langage reconnu par un automate A donnera comme résultat le langage reconnu par T(A). 2.2/ Grammaires algebriques et automates ´ a pile ` 2.2.1/ Grammaires algebriques ´ Une grammaire algébrique – appelée aussi parfois grammaire non contextuelle ou encore grammaire hors contexte – est un 4-uplet G = (Σ, Γ, S 0, R), où : — Σ et Γ sont des alphabets finis disjoints, — S 0 ∈ Γ est le symbole initial, — R est un sous-ensemble fini de Γ × (Σ ∪ Γ) ∗ .PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 29 Les éléments de Σ sont appelés symboles terminaux, et les éléments de Γ sont appelés symboles non-terminaux. Un élément (X, u) de R est appelé une règle de la grammaire et est fréquemment noté X → u. Un mot u1 ∈ (Σ ∪ Γ) ∗ est un successeur de u0 ∈ (Σ ∪ Γ) ∗ dans la grammaire G s’il existe v ∈ Σ ∗ , w, x ∈ (Σ ∪ Γ) ∗ , S ∈ Γ tels que u0 = vS w et u1 = vxw et S → x ∈ R. Une dérivation complète 1 de la grammaire G est une séquence finie u0, . . . , uk de mots de (Σ∪Γ) ∗ telle que u0 = S 0, uk ∈ Σ ∗ et pour tout i, ui+1 est un successeur de ui . Un arbre de dérivation de G est un arbre fini dont les nœuds internes sont étiquetés par des lettres de Γ, dont les feuilles sont étiquetées par des éléments de Σ ∪ {ε}, dont la racine est étiquetée par S 0 et qui satisfait : si un nœud est étiqueté par X ∈ Γ et si ses fils sont étiquetés par α1, . . . , αk (dans cet ordre), alors (X, α1 . . . αk) ∈ R et soit α1 = ε et k = 1, soit tous les αi’s sont dans Γ ∪ Σ. La taille d’un arbre de dérivation est donnée par le nombre de nœuds de l’arbre. Notons qu’il existe une bijection entre l’ensemble des dérivations complètes d’une grammaire et l’ensemble des arbres de dérivations de cette grammaire. Pour une grammaire algébrique G, En(G) représente l’ensemble des arbres de dérivation de G composés de n nœuds. On dit qu’un arbre de dérivation couvre un élément X de Γ si au moins un de ses nœuds est étiqueté par X. Et on dit qu’un arbre de dérivation couvre une règle X → u de R si cette règle est utilisée dans la dérivation complète correspondante. Exemple 2.13. Grammaire algébrique Soit la grammaire G = ({a, b}, {S, T}, S, R), avec R = {S → T b, S → aS b, T → ε}). La séquence S, aS b, aT bb, abb est une dérivation complète de la grammaire. L’arbre de dérivation associé à cette séquence est représenté dans la figure 2.13. On peut y voir que les éléments S et T ainsi que la règle S → aS b sont couverts, puisqu’ils apparaissent dans l’arbre de dérivation. S S a b b T ε Figure 2.13 – Arbre de dérivation correspondant à la séquence S, aS b, aT bb, abb 2.2.2/ Automates a pile ` Un automate à pile est un 6-uplet A = (Q, Σ, Γ, δ, qinit, F) où : — Q est l’ensemble fini des états, — Σ (alphabet d’entrée) et Γ (alphabet de la pile) sont des alphabets finis disjoints tels que ε < Σ et ⊥ ∈ Γ, — qinit ∈ Q est l’état initial, — F est l’ensemble des états finaux, — δ est une fonction partielle de Q × (Σ ∪ {ε}) × Γ vers Q × Γ ∗ telle que pour tout q ∈ Q, pour tout X ∈ Γ \ {⊥}, et pour tout a ∈ Σ ∪ {ε} : — si δ(q, a, X) = (p,w) alors w ∈ (Γ \ {⊥}) ∗ , — si δ(q, a, ⊥) = (p,w) alors w = ⊥w 0 avec w 0 ∈ (Γ \ {⊥}) ∗ . La lettre ⊥ est appelée le symbole de pile vide, ou encore le fond de la pile. Le terme "automate à pile" est abrégé en PDA, pour l’anglais PushDown Automaton. Une configuration d’un PDA est un élément de Q × {⊥}(Γ \ {⊥}) ∗ , c’est-à-dire une paire dont le premier élément est dans Q, et le second élément est un mot qui commence par ⊥ et dont aucune des autres lettres n’est ⊥. Intuitivement, la seconde partie encode la valeur courante de la pile. La configuration initiale est 1. Comme v ∈ Σ ∗ , cette dérivation est une dérivation gauche.PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 30 (qinit, ⊥). Deux configurations (q, ⊥u) et (p, ⊥v) sont a-consécutives, avec a ∈ Σ ∪ {ε}, si u = ε et δ(q, a, ⊥) = (p, ⊥v), ou si u est de la forme u0X avec X ∈ Γ \ {⊥} et qu’il existe w ∈ Γ ∗ tel que δ(q, a, X) = (p,w) et v = u0w. 0 1 2 5 4 6 7 9 8 10 a b c e push(S ) pop(S ) pop(S ) pop(S ) g h i j Figure 2.14 – Apower, exemple de NPDA Une PDA-trace de longueur n dans un PDA est une séquence C1a1C2a2 . . .CnanCn+1 où les Ci’s sont des configurations, les ai’s sont dans Σ ∪ {ε} et tels que C1 est la configuration initiale, pour tout i, Ci et Ci+1 sont ai-consécutives, et Cn+1 est de la forme (p, ⊥) avec p ∈ F. Un automate à pile normalisé – abrégé en NPDA, pour l’anglais Normalised PushDown Automaton – est un PDA tel que pour tout état q, pour tout a ∈ Σ ∪ {ε}, et pour tout X ∈ Γ, si δ(q, a, X) = (p,w) alors on se trouve dans l’un des cas suivants : (i) a = ε et w = ε, ou (ii) a = ε et w est de la forme w = XY avec Y ∈ Γ, ou (iii) a , ε et w = X. Il faut également que si δ(q, ε, X) = (p, XY), alors pour tout Z ∈ Γ, δ(q, ε, Z) = (p, ZY) – c’est-à- dire qu’une transition qui ajoute un élément au sommet de la pile peut être déclenchée indépendamment de l’état de la pile –, et que si δ(q, a, X) = (p, X), alors pour tout Z ∈ Γ, δ(q, a, Z) = (p, Z) – c’est-à-dire qu’une transition qui lit une lettre en entrée peut également être déclenchée indépendamment de l’état de la pile –. 2 Intuitivement, le cas (i) correspond à l’action de dépilement (pop) – c’est-à-dire retirer l’élément au sommet de la pile –, le cas (ii) correspond à l’action d’empilement (push) – c’est-à-dire ajouter un élément au sommet de la pile –, et le cas (iii) correspond à l’action de lecture (read) – c’est- à-dire consommer l’élément suivant de l’entrée (sans modifier la pile) –. L’automate sous-jacent d’un NPDA A = (Q, Σ, Γ, δ, qinit, F) est l’automate (Q, Σ ∪ {pop(X), push(X) | X ∈ Γ}, µ, qinit, F), où l’ensemble des transitions µ est défini par : (i) δ(q, ε, X) = (p, ε) si et seulement si µ(q, pop(X)) = p, (ii) δ(q, ε, X) = (p, XY) si et seulement si µ(q, push(Y)) = p, (iii) δ(q, a, X) = (p, X) si et seulement si µ(q, a) = p. Une NPDA-trace est une PDA-trace dans un NPDA. Les définitions ci-dessus peuvent être illustrées par le NPDA de la figure 2.14, qui correspond au graphe à droite de la figure 7.10. Pour cet automate Q = {0, . . . , 10}, Σ = {a, b, c, e, g, h, i, j}, Γ = {⊥, S }, qinit = 0, F = {4, 8, 10} et δ est 2. Ces conditions ne réduisent pas le pouvoir d’expression puisqu’il est possible d’encoder toute transition de la forme δ(q, ε, X) = (p, XY) qui requiert un X au sommet de la pile pour être déclenchée, par δ(q, ε, X) = (qnew1, ε) et pour tout Z ∈ Γ, δ(qnew1, ε, Z) = (qnew2, ZX) et δ(qnew2, ε, Z) = (p, ZY). Il en est de même pour toute transition de la forme δ(q, a, X) = (p, X) qui requiert un X au sommet de la pile pour être déclenchée, qui peut être encodée par δ(q, ε, X) = (qnew1, ε) et pour tout Z ∈ Γ, δ(qnew1, ε, Z) = (qnew2, ZX) et δ(qnew2, a, Z) = (p, Z).PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 31 défini par les flèches : pour une arête de la forme (q, a, p) avec a ∈ Σ, alors on a δ(q, a, ⊥) = (p, ⊥) et δ(q, a, S ) = (p, S ) ; pour une arête de la forme (q, pop(S ), p) alors δ(q, ε, S ) = (p, ε) ; pour une arête de la forme (q, push(S ), p) alors δ(q, ε, ⊥) = (p, ⊥S ) et δ(q, ε, S ) = (p, S S ). La séquence (0, ⊥)a(1, ⊥)c(5, ⊥)ε(0, ⊥S )a(1, ⊥S )c(5, ⊥)ε(0, ⊥S S )a(1, ⊥S S )b(2, ⊥S S ) e(4, ⊥S S )ε(6, ⊥S )h(9, ⊥S )j(10, ⊥S )ε(6, ⊥)g(7, ⊥)i(8, ⊥) est une NPDA-trace dans le NPDA. Cette trace correspond à l’exécution de power(3,2), que l’on a détaillée dans l’exemple 7.3. Notons que chaque paire (q,w) signifie que le système est dans l’état q et que la pile d’appels est w. Par exemple, (2, ⊥S S ) signifie que le système est dans l’état 2 et qu’il y a deux appels non terminés à la fonction power. Chaque NPDA-trace d’un NPDA est associée à une DFA-trace dans l’automate sousjacent selon la projection suivante : la NPDA-trace C1a1 . . . anCn est associée au chemin (q1, a1, q2) . . . (qn−1, an, qn), où les Ci’s sont de la forme (qi ,wi). Par exemple, la DFA-trace associée à la NPDA-trace ci-dessus est (0, a, 1)(1, c, 5)(5, ε, 0) . . . (6, g, 7)(7, i, 8). Cette projection est notée proj et est injective. Son image forme un sous-ensemble de DFA-traces, appelées DFA-traces cohérentes de l’automate sous-jacent, qui est en bijection avec l’ensemble des NPDA-traces. 2.2.3/ Gen´ eration al ´ eatoire uniforme d ´ ’un arbre de derivation dans une grammaire ´ Le problème de la génération aléatoire uniforme sur les grammaires peut s’écrire ainsi : Problème 2.14. Génération aléatoire d’un arbre de dérivation dans une grammaire Entrée : Une grammaire algébrique G, un nombre entier positif n Question : Générer aléatoirement avec une distribution uniforme, des arbres de dérivation de G de taille n ? Nous allons expliquer ici comment résoudre ce problème en utilisant des techniques combinatoires bien connues [FS08]. Notons que des techniques plus avancées permettent un calcul plus rapide, comme dans [DZ99]. Pour faciliter la compréhension, on utilise habituellement des lettres majuscules pour nommer les symboles non-terminaux Soit une grammaire algébrique G = (Σ, Γ, S 0, R), un symbole nonterminal X de Γ, et un entier positif i, le nombre d’arbres de dérivation de taille i généré par (Σ, Γ, X, R) est noté x(i) – c’est-à-dire qu’on utilise la lettre minuscule correspondante au symbole initial –. Soit un nombre entier positif n, pour tout symbole S ∈ Γ, on peut calculer la séquence d’entiers positifs s(1), . . . , s(k), . . .. Le calcul récursif de ces s(i) est le suivant : Pour tout entier strictement positif k et toute règle r = (S,w1S 1 . . . wnS nwn+1) ∈ R, avec wj ∈ Σ ∗ et S i ∈ Γ, on pose    βr = 1 + Pn+1 i=1 |wi |, αr(k) = P i1+i2+...+in=k−βr Qj=n j=1 sj(ij) si n , 0, αr(k) = 0 si n = 0 et k , βr , αr(βr) = 1 si n = 0. Il est connu que s(k) = P r∈R∩(S×(Σ∪Γ) ∗ ) αr(k) (cf. [FS08, Théorème I.1]). Par hypothèse, il n’y a pas de règle de la forme (S, T) dans R avec S, T ∈ Γ, donc tous les ij dans la définition de αr sont strictement inférieurs à k. Les s(i) peuvent donc être calculés récursivement.PARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 32 Considérons par exemple la grammaire ({a, b}, {X}, X, {r1,r2,r3}) avec r1 = (X, XX) r2 = (X, a) et r3 = (X, b). On a βr1 = 1 + 0 = 1, βr2 = 1 + 1 = 2, βr3 = 1 + 1 = 2. Donc x(k) = P i+j=k−1 x(i)x(j) si k , 2, et x(2) = 1 + 1 + P i+j=2−1 x(i)x(j) = 2, sinon. Par conséquent, x(1) = 0, x(2) = 2, x(3) = x(1)x(1) = 0, x(4) = x(1)x(2) + x(2)x(1) = 0, x(5) = x(2)x(2) = 4, etc. . .. Les deux arbres de dérivation de taille 2 sont X | a et X | b . Les quatre arbres de dérivation de taille 5 sont les arbres de la forme X /\ Z1 Z2 , où Z1 et Z2 sont des arbres de dérivation de taille 2. Pour générer des arbres de dérivation de taille n, on doit calculer tous les s(i), pour S ∈ Γ et i ≤ n, avec la méthode ci-dessus. Ce calcul peut être effectué en un temps polynomial. Ensuite, la génération aléatoire consiste à appliquer récursivement l’algorithme décrit dans la figure 2.15. Génération aléatoire Entrée : une grammaire algébrique G = (Σ, Γ, X, R), un nombre entier strictement positif n. Sortie : un arbre de dérivation t de G, de taille n. Algorithme : 1. Soit {r1,r2, . . . ,r`} l’ensemble des éléments de R dont le premier élément est X. 2. Si Pj=` j=1 αrj (n) = 0, alors retourner “Exception”. 3. Choisir i ∈ {1, . . . , `} avec une probabilité Prob(i = j) = αr i (n) Pj=` j=1 αr j (n) . 4. ri = (X, Z1 . . . Zk), avec Zj ∈ Σ ∪ Γ. 5. Le symbole racine de t est X. 6. Les fils de t sont Z1, . . . , Zk dans cet ordre. 7. {i1, . . . , im} = {j | Zj ∈ Γ}. 8. Choisir (x1, . . . , xm) ∈ N m tel que x1 + . . . + xm = n − βri avec une probabilité Prob(x1 = `1, . . . , xm = `m) = Qj=m j=1 zij (` j) αri (n) . 9. Pour tout ij , le ij-ème sous-arbre de T est obtenu en appliquant l’algorithme Génération aléatoire sur (Σ, Γ, Zij , R) et ` j . 10. Retourner t. Figure 2.15 – Algorithme Génération aléatoire Il est connu [FS08] que cet algorithme produit une génération uniforme d’arbres de dérivations de taille n – c’est-à-dire que chaque arbre de dérivation a la même probabilité d’être généré –. Notons qu’une exception est renvoyée à l’étape 2 s’il n’y a aucun élément de la taille donnée. Pour l’exemple présenté précédemment, il n’y a pas d’élément de taille 3, il n’est donc pas possible de générer un arbre de dérivation de taille 3. En exécutant l’algorithme sur cet exemple avec n = 2, à l’étape 1 on considère l’ensemble {r1,r2,r3} puisque toutes ces règles ont X comme élément gauche. Comme αr1 (2) = 0, αr2 (2) = 1, αr3 (2) = 1, à l’étape 3 la probabilité que i = 1 est 0, la probabilité que i = 2 est 1/2 et la probabilité que i = 3 est 1/2. Si la valeur i = 2 est choisie, l’arbre généré a X comme symbole racine et a comme unique fils. L’exécution de l’algorithme avec n = 3 s’arrête à l’étape 2 puisqu’il n’y a pas d’arbre de taille 3. En exécutant l’algorithme sur cet exemple avec n = 5, à l’étape 1 on considère l’ensemble {r1,r2,r3}. Comme αr1 (5) = 4, αr2 (5) = 0, αr3 (5) = 0, la valeur i = 1 est choisie avec une probabilité 1. Par conséquent, l’arbre a X comme symbole racine, et ses deux fils sont étiquetés par X. C’est pourquoi à l’étape 7, l’ensemble considéré est {1, 2}. A l’étape 8, on a n − βr1 = 5 − 1 = 4. La probabilité que i1 = 1 et i2 = 3 est 0 car x(1) = 0. De même, la probabilité que i1 = 3 et i2 = 1 est aussi 0. La probabilité que i1 = 2 etPARTIE I. Introduction - CHAPITRE 2. PRÉLIMINAIRES THÉORIQUES ET NO . . . 33 ΣG ={(0, a, 1), (1, c, 5), (5, push(S ), 0), (1, b, 2), (2, e, 4), (4, pop(S ), 6), (6, g, 7), (7, i, 8), (8, pop(S ), 6), (6, h, 9), (9, j, 10), (10, pop(S ), 6)}, et RG ={(T, LRD(6, g, 7)(7, i, 8)), (T, LRD(6, h, 9)(9, j, 10)), (T, (0, a, 1)(1, b, 2)(2, e, 4)), (R, LRD), (R, (0, a, 1)(1, c, 5)(5, push(S ), 0)(0, a, 1)(1, b, 2)(2, e, 4)(4, pop(S ), 6)), (L, (0, a, 1)(1, c, 5)(5, push(S ), 0)), (D, (6, g, 7)(7, i, 8)(8, pop(S ), 6)), (D, (6, h, 9)(9, j, 10)(10, pop(S ), 6))}. Figure 2.16 – Exemple d’une grammaire qui génère des DFA-traces cohérentes i2 = 2 est donc 1. L’algorithme est ensuite exécuté récursivement sur chacun des fils avec n = 2 : chacun des quatre arbres est choisi avec une probabilité 1/4. Puisqu’on peut très simplement représenter un graphe sous la forme d’une grammaire, on peut utiliser cette méthode de génération aléatoire uniforme d’un arbre de dérivation dans une grammaire afin de générer aléatoire-uniformément des chemins dans un graphe. Considérons par exemple l’automate A, sous-jacent au NPDA décrit dans la figure 2.14. Des DFAtraces cohérentes de A sont générées à partir de la grammaire (ΣG, ΓG, T, RG) de la figure 2.16, avec ΓG = {T, L, R, D}. 2.2.4/ D’un NPDA vers une grammaire algebrique ´ Plusieurs algorithmes classiques permettent la transformation d’un NPDA en une grammaire algébrique (par exemple, [Sip96]). Le théorème présenté ci-dessous est une combinaison directe de résultats bien connus sur les PDA. Théorème 2.15 Soit A un NPDA, on peut calculer en temps polynomial une grammaire G, qui satisfait les assertions suivantes : — Le nombre de règles de G est au plus quadratique de la taille de A, et G ne contient aucune règle de la forme (X, Y), avec X et Y qui sont des symboles de la pile. — Il existe une bijection ϕ de l’ensemble des dérivations complètes de G vers l’ensemble des NPDA-traces de A. — L’image par ϕ d’une dérivation complète de G peut être calculée en temps polynomial. Notons que la complexité précise des algorithmes dépend des structures de données choisies, mais qu’elles peuvent toutes être implémentées de manière efficace.II Approximations reguli ´ eres pour l ` ’analyse d’accessibilite´PARTIE II. Approximations reguli ´ eres pour l ` ’analyse d’accessibilite´ 37 Dans cette partie, notre contribution est la définition de deux nouvelles techniques d’approximation pour le model-checking régulier, dans le but de fournir des (semi-)algorithmes efficaces. On calcule des sur-approximations de l’ensemble des états accessibles, avec l’objectif d’assurer la terminaison de l’exploration de l’espace d’états. L’ensemble des états accessibles (ou les surapproximations de cet ensemble) est représenté par un langage régulier, lui même codé par un automate fini. La première technique consiste à sur-approximer l’ensemble des états atteignables en fusionnant des états des automates, en fonction de critères syntaxiques simples, ou d’une combinaison de ces critères (cf. section 4). La seconde technique d’approximation consiste aussi à fusionner des états des automates, mais cette fois-ci à l’aide d’un transducteur (cf. section 5.2). De plus, pour cette seconde technique, nous développons une nouvelle approche pour raffiner les approximations (cf. section 5.3), qui s’inspire du paradigme CEGAR (cf. section 3.4). Les propositions sont évaluées sur des exemples de protocoles d’exclusion mutuelle (cf. section 4.4 et section 5.4).3 Contexte et problematiques ´ 3.1/ Introduction et enonc ´ e du probl ´ eme ` Dans ce chapitre, nous allons présenter le problème d’accessibilité, puis sa traduction dans le cadre plus particulier du model-checking régulier qui en est un cas particulier. Enfin, nous présenterons l’approche par approximations régulières qui est une façon d’aborder le problème de l’analyse d’accessibilité par model-checking régulier. Analyse d’accessibilite´ L’analyse d’accessibilité est une question importante dans la vérification de logiciels, car elle permet d’en assurer la sécurité et la sûreté (c’est-à-dire que quelque chose de mauvais ne se produira pas). Elle consiste à vérifier (prouver) sur une description formelle du système, que certaines confi- gurations peuvent être atteintes. On peut exprimer le problème de la façon suivante : Problème 3.1. Accessibilité Entrée : Un ensemble de configurations initiales I, une relation d’évolution du système R, un ensemble d’états B. Question : Le système décrit par I et R, peut-il atteindre un état de B ? Par exemple, savoir si un point de programme particulier est atteignable est un problème d’accessibilité, de même que de savoir si une machine de Turing reconnaît un langage non vide. Le problème d’accessibilité est indécidable dans la plupart des formalismes. Plusieurs approches ad hoc ont été développées afin de trouver des heuristiques ou de déterminer des formalismes pour lesquels le problème est décidable. Parmi ces approches, l’analyse d’accessibilité symbolique repose sur des représentations finies d’ensembles infinis d’états. Le model checking régulier – abrégé en RMC, pour l’anglais Regular Model Checking – est une approche symbolique utilisant des ensembles réguliers pour représenter des ensembles d’états : I et B sont des langages réguliers, donnés le plus souvent par des automates finis (parfois des expressions régulières) et R est les plus souvent une relation régulière donnée par un transducteur (ou un système de réécriture). Dans ce cadre, le problème d’accessibilité reste indécidable et est abordé des deux façons suivantes : — soit en travaillant sur des classes d’ensembles réguliers et des relations pour lesquelles le problème de l’accessibilité est décidable (voir par exemple [GGP08]), — soit en développant des approches semi-algorithmiques basées sur des accélérations ou des approximations (voir par exemple [DLS01, DLS02]). L’analyse d’accessibilité permet de vérifier des propriétés de sûreté : si l’ensemble d’états B est un ensemble d’états d’erreurs, et que l’analyse d’accessibilité montre que le système ne peut pas atteindre un état de B, alors on a vérifié une propriété de sûreté (c’est une propriété qui dit quePARTIE II. Approximations reguli ´ eres pour l ` ’analyse d’ac . . . - CHAPITRE 3. CONTEXTE ET PROBLÉMATIQUES 40 quelque chose de mauvais ne doit pas pouvoir se produire, comme par exemple le fait que le train d’atterrissage d’un avion ne doit pas pouvoir être rentré si l’avion est au sol). D’autres types de propriétés, plus complexes, peuvent souvent se recoder dans le cadre de l’analyse d’accessibilité. Model-Checking regulier ´ Le problème de l’analyse d’accessibilité par model-checking régulier sur les mots peut se formaliser ainsi : Problème 3.2. RMC-1 Entrée : Un langage régulier I (ensemble de configurations initiales), une relation calculable R (relation d’évolution du système), un langage régulier B (propriété d’erreur). Question : R ∗ (I) T B = ∅ ? En représentant l’ensemble de configurations initiales par un automate A0, la relation d’évolution du système par un transducteur T, et la propriété d’erreur par un automate B, on peut définir le problème de l’analyse d’accessibilité par RMC sur les mots de la façon suivante : Problème 3.3. RMC-2 Entrée : Deux automates finis A0 et B sur un même alphabet Σ, et un transducteur T sur Σ × Σ. Question : R ∗ T (L(A0)) ∩ L(B) = ∅ ? Comme la sortie dépend de la fermeture réflexive et transitive, on peut supposer sans perte de généralité que pour tout u ∈ Σ ∗ , (u, u) ∈ RT . On supposera donc que toutes les relations étudiées par la suite contiennent l’identité. Depuis presque 20 ans, le model-checking régulier est un domaine de recherche actif en informatique (cf. [CGP00] et [BKe08] pour une vue d’ensemble). De nombreux travaux ont donc traité (et traitent encore) de variantes de ce problème. Par exemple, dans [KMM+97], les auteurs proposent de représenter les configurations possibles d’un tableau de processus sous la forme d’un ensemble régulier de mots – autrement dit, un langage régulier – défini par un automate A, et de représenter l’effet d’une action du système sous la forme d’une règle de réécriture qui modifie l’automate A (un transducteur). Mais ce travail traite uniquement des transducteurs qui représentent l’effet d’une seule application de la transition, et il y a de nombreux protocoles pour lesquels l’analyse d’accessibilité ne se termine pas. Puis dans [WB98], les auteurs présentent l’idée de vérifier différents types de systèmes infinis en les représentant sous la forme de langages réguliers. Les principales méthodes pour contourner le problème de non-terminaison de l’analyse d’accessibilité, et donc pour atteindre un point fixe, sont l’accélération [JN00, BJNT00, DLS01, DLS02, AJNd03, BLW03], l’élargissement (extrapolation) [BJNT00, Tou01, Leg12], et l’abstraction d’automates [BHV04]. Dans [BJNT00], les auteurs présentent le concept du model-checking régulier, et s’intéressent au calcul des états atteignables à partir d’un ensemble donné d’états initiaux, ainsi qu’au calcul de la fermeture transitive de la relation de transition. Ils proposent pour cela une technique s’appuyant sur la théorie des automates, et une technique d’accélération. Cet article est l’un des premiers à présenter la notion de model-checking régulier, et il est donc souvent utilisé comme référence pour les travaux dans ce domaine. Il s’intéresse au calcul des états atteignables à partir d’un ensemble donné d’états initiaux, et de la fermeture transitive de la relation de transition. Deux techniques y sont proposées. La première technique, basée sur la théorie des automates, consiste à considérer la relation d’évolution du système comme un transducteur T, à construire une matrice qui regroupePARTIE II. Approximations reguli ´ eres pour l ` ’analyse d’ac . . . - CHAPITRE 3. CONTEXTE ET PROBLÉMATIQUES 41 tous les chemins possibles de T, à considérer cette matrice comme un unique transducteur T ∗ (dont chaque colonne est un état) que l’on va minimiser et déterminiser. Mais cette technique n’est applicable qu’à certains protocoles réguliers, car pour pouvoir construire la matrice qui regroupe tous les chemins possibles de T, il faut que celui-ci ne contienne aucune boucle. La deuxième technique consiste à deviner automatiquement l’ensemble obtenu après application d’une relation d’évolution T, à partir d’un ensemble régulier donné, puis à vérifier si celui-ci est correct. Pour deviner cet ensemble, on compare les ensembles φ et T(φ) afin de détecter une éventuelle croissance (par exemple T(φ) = φ.Λ pour un Λ régulier quelconque), puis à extrapoler en faisant l’hypothèse que chaque application de T aura le même effet. On fait ensuite un test de point fixe pour s’assurer que l’ensemble obtenu est bien une sur-approximation de T ∗ (φ). D’après l’article, cette technique a été appliquée sur les protocoles d’exclusion mutuelle de Szymanski, Burns, Dijkstra, sur le protocole de Bakery de Lamport et sur le Token passing protocol, mais seule l’application au Token passing protocol est présentée. Cette technique n’est pas non plus applicable à tous les protocoles réguliers : la relation T doit préserver la taille des mots et doit être noethérienne pour s’appliquer à un mot qu’un nombre fini de fois. Dans [AJNd03], les auteurs proposent des améliorations de ces techniques qui réduisent la taille des automates intermédiaires, lors du calcul de la clôture transitive. C’est dans la même confé- rence que Sébastien Bardin, Alain Finkel, Jérôme Leroux et Laure Petrucci proposent leur outil de vérification FAS T (pour Fast Acceleration of S ymbolic Transition systems) [BFLP03]. L’outil FAS T tente de calculer R ∗ T (I) – c’est-à-dire l’ensemble exact des configurations accessibles – en se basant sur des accélérations du transducteur T. Dans [BHV04], les auteurs proposent une technique de vérification des systèmes infinis paramétrés qui combine du model-checking régulier et de la vérification par abstraction. D’après cet article, l’explosion des états est un des plus gros problèmes du model-checking régulier, et une des sources de ce problème vient de la nature même des techniques de model-checking régulier de l’époque (2004). Ces techniques tentent de calculer l’ensemble d’accessibilité exact. Il propose donc de remplacer les techniques d’accélération précises par un calcul d’abstraction qui, lorsqu’un point fixe sera atteint, représentera une sur-approximation de l’ensemble des états atteignables. L’article propose une abstraction par fusion d’états, qui est assez proche de la technique qu’on a utilisée. Il présente également la possibilité de raffiner l’abstraction (ce qui, dans notre méthode, revient à durcir le critère de fusion avec un ET logique), au cas où l’approximation contiendrait un état d’erreur. Mais ils ne peuvent raffiner l’abstraction que si la relation ∼ sur les états est de la forme suivante : soit A un automate, p et q deux états de A, et P un ensemble fini d’automates, p ∼ A q si et seulement si quelque soit P de P, L(P) T L(A Right,p ) , ∅ si et seulement si L(P) T L(A Right,q ) , ∅ (les automates A Right,p et A Right,q sont définis dans ce mémoire, dans la section 4.2). Pour raffiner l’abstraction avec des relations de cette forme, l’article propose d’ajouter des automates dans P. Cette technique est applicable sur une grande variété de systèmes, mais ne laisse pas de liberté concernant la forme des critères de fusion (on peut seulement décider du contenu de P). Dans [LGJJ06], les auteurs s’intéressent à l’analyse et la vérification de systèmes communiquants par des files de communication non bornées. Ils proposent une méthode d’analyse et de vérifi- cation de systèmes communiquants (ce sont des systèmes formés de processus séquentiels, communiquant par des files de communication non bornées), qui consiste à travailler sur des abstractions des systèmes en question. Dans le cadre de cet article, les processus sont d’états fi- nis, et l’alphabet des messages échangés est également fini. Les protocoles étudiés sont le protocole de Connexion/Déconnexion, le Buffer infini, et l’Alternating Bit Protocol, et ils sont représentés par des systèmes de transitions étiquetés. Les auteurs proposent un treillis abstrait fondé sur les langages réguliers, afin d’étudier les systèmes avec une seule file de communication, puis ils généralisent leur proposition aux systèmes avec plusieurs files. Récemment, dePARTIE II. Approximations reguli ´ eres pour l ` ’analyse d’ac . . . - CHAPITRE 3. CONTEXTE ET PROBLÉMATIQUES 42 nouveaux résultats en model-checking régulier ont été obtenus pour des protocoles spécifiques comme les CLP [FPPS11], les systèmes communiquants par des files [LGJJ06], les langages d’arbres [AJMd02, BT11], ou la vérification de chaînes relationnelles utilisant des automates multi-pistes [YBI11]), en utilisant des techniques spécifiques aux catégories de systèmes données [Boi12]. Approximations reguli ´ eres ` De nombreuses méthodes de vérification proposées jusqu’ici sont des méthodes exactes, or il est souvent difficile, voire impossible, de trouver un point fixe de façon exacte, et donc de conclure. Puisque la valeur exacte de l’ensemble des états atteignables par le système – noté R ∗ (I) (cf. fi- gure 3.1) – n’est pas forcément calculable, nous utilisons l’approche par approximations régulières. Cette approche est très utilisée pour attaquer le problème du model-checking régulier, et consiste à calculer un langage régulier K, qui contient R ∗ (I). On dit alors que K est une sur-approximation de R ∗ (I). I R(I) ... B R ∗ (I) ? ? ? K Figure 3.1 – Approche par sur-approximation L’enjeu est de démontrer que R ∗ (I) T B = ∅. Si on a K T B = ∅, on peut l’affirmer. Mais si après calcul, K T B , ∅, alors on ne peut rien déduire sur R ∗ (I) T B. On cherchera donc une sur-approximation moins grossière de R ∗ (I). La difficulté – et l’objectif même de cette partie de la thèse – est de trouver une façon automatique de calculer un ensemble K, qui permette de conclure le plus souvent possible (chaque fois que possible serait l’idéal). Or, les résultats d’une méthode de calcul par rapport à une autre diffèrent beaucoup selon le protocole qu’on souhaite vérifier. 3.2/ Technique proposee´ Nos contributions visent à améliorer la méthode générique de [BHV04] en donnant des moyens de construire des sur-approximations en fusionnant des états abstraits du système (et non du transducteur, qui n’est jamais modifié). Notre méthode utilise une approche par sur-approximations successives, qui consiste à calculer RT (I) puis à en calculer une sur-approximation I1, à calculer ensuite RT (I1) puis à en calculer une sur-approximation I2, ... et ainsi de suite jusqu’à atteindre un point fixe, qui sera notre surapproximation K de R ∗ T (I) (cf. figure 3.2). Malgré le fait que l’approche par sur-approximations successives augmente les chances de trouver un point fixe, on peut avoir besoin d’appliquer le transducteur de nombreuses fois avant d’en trouver un, ce qui multiplie à chaque fois le nombre d’états de l’automate obtenu. En fusionnantPARTIE II. Approximations reguli ´ eres pour l ` ’analyse d’ac . . . - CHAPITRE 3. CONTEXTE ET PROBLÉMATIQUES 43 automate A0 langage I = L(A0) automate Ae 1 = T(A0), langage RT (I) = L(Ae 1 ) automate A1 = C(T(A0)) langage I1 = L(A1) automate Ae 2 = T(A1), langage RT (I1) = L(Ae 2 ) Ii = L(Ai) . . . automate An = C(T(An−1)) langage In = L(An) automate Ae n+1 = T(An), langage RT (In) = L(Ae n+1 ) automate An+1 = C(T(An)) langage In+1 = L(An+1) In+1 = In =⇒ K = In application du transducteur (relation d’évolution) fusion d’états (sur-approximation) . . . . . . Figure 3.2 – Sur-approximations successives des états entre eux, la sur-approximation effectuée à chaque étape (flèches en diagonale sur la figure 3.2) doit donc également empêcher l’explosion du nombre d’états. Afin de déterminer les états à fusionner, on définit un ou plusieurs critères de fusion, qui sont les points communs que doivent avoir deux états pour être fusionnés. Ces critères sont définis sous la forme de relations entre les états (deux états seront fusionnés s’ils sont en relation), qui sont elles-même obtenues à partir de fonctions d’approximations (cf. définition 2.3). Le choix de bons critères de fusion, et donc de bonnes fonctions d’approximation, est extrêmement important. Si le critère est trop large l’approximation reconnaîtra des mots de B (la propriété d’erreur) avant d’atteindre un point fixe, et s’il est trop restrictif, on ne fusionnera pas d’états et la taille de l’automate risque d’exploser. Il faut également que les critères soient rapidement calculables, et qu’ils puissent s’appliquer à tous types de problèmes réguliers (cf. définition 2.2). 3.3/ Calcul de la sur-approximation Dans cette section, on explique comment calculer une sur-approximation K de R ∗ T (I) (cf. fi- gure 3.2), à partir d’une fonction d’approximation F. Proposition 3.4 Pour tout automate A, si F est une fonction d’approximation isomorphismecompatible, alors la séquence (F n (A))n∈N est ultimement constante, à isomorphisme près. Notons CF(A) la limite de (F n (A))n∈N. Si pour tout automate A et toute paire d’états p, q de A, on peut vérifier en temps polynomial si p ∼ A F q, alors CF(A) peut également être calculé en temps polynomial. Preuve. Soit A un automate et ∼ une relation d’équivalence sur les états de A. Si ∼ n’est pas l’identité, alors A/∼ a strictement moins d’états que A. Sinon, A/∼ est isomorphe à A. C’est pourquoi, dans la séquence (F n (A))n∈N, le nombre d’états des automates diminue et si F k (A) etPARTIE II. Approximations reguli ´ eres pour l ` ’analyse d’ac . . . - CHAPITRE 3. CONTEXTE ET PROBLÉMATIQUES 44 F k+1 (A) ont le même nombre d’états, alors (F n (A))n≥k, est finalement constant, à l’isomorphisme près. Si l’équivalence des états est calculée en temps polynomial, alors l’automate quotient peut également être calculé en temps polynomial : il suffit de calculer les composantes fortement connexes, du graphe de la relation ∼. De plus, puisque la convergence est obtenue en au plus n états, où n est le nombre d’états de A, CF(A) peut être calculé en temps polynomial. Exemple 3.5. La figure 3.3 représente un automate A, ainsi que le calcul de CRight(A) (la relation Right est définie plus tard, dans la section 4.2). 1 2 3 4 5 6 a a b b b b b (a) A 1 3 4 256 a a b b b (b) Right(A) 1 3 2456 a b b (c) Right2 (A)=CRight(A) Figure 3.3 – Calcul de CRight(A) Semi-Algorithme PointFixe Entrée : A, T, B, F Si L(CF(T(A))) ∩ L(B) , ∅ alors retourner Non-conclusif FinSi Si L(CF(T(A))) = L(A) alors retourner Sûr FinSi Retourner PointFixe(CF(T(A)),T,B,F) Figure 3.4 – Semi-algorithme PointFixe Dans le semi-algorithme PointFixe (cf. figure 3.4), soit un automate A (état du système), un transducteur T (relation de transition), un automate B (propriété d’erreur), et une fonction d’approximation isomorphisme-compatible F (critère de fusion), la première vérification (le vide) peut être effectuée en temps polynomial. Malheureusement, l’égalité des langages ne peut pas être vérifiée en temps polynomial (les automates impliquées ne sont pas déterministes). Cependant, des algorithmes récemment développés [DR10, ACH+10, BP12] permettent de résoudre le problème du test de l’inclusion de langages (et donc de l’égalité) très efficacement. Notons également que le test d’égalité peut être remplacé par un autre test – comme l’isomorphisme ou encore la (bi)simulation – qui implique l’égalité ou l’inclusion des langages, puisque par construction L(A) ⊆ L(CF(T(A))). Dans ce cas le test serait plus rapide, mais la convergence moins rapide. Proposition 3.6 Le semi-algorithme PointFixe est correct : s’il retourne Sûr, alors R∗ T (L(A))∩ L(B) = ∅. Preuve. Si le semi-algorithme PointFixe retourne Sûr, alors on a calculé un automate A0 tel que L(A0 ) = L(CF(T(A0 )))). On prouve tout d’abord que RT (L(A0 )) = L(A0 ) : puisque l’identité est inclue dans RT , il suffit de prouver que RT (L(A0 )) ⊆ L(A0 ). Si u ∈ RT (L(A0 )), alors APISENSER : une plate-forme r´epartie pour la conception,le d´eploiement et l’ex´ecution de campagnes de collecte de donn´ees sur des terminaux intelligents Nicolas Haderer To cite this version: Nicolas Haderer. APISENSER : une plate-forme r´epartie pour la conception,le d´eploiement et l’ex´ecution de campagnes de collecte de donn´ees sur des terminaux intelligents. Mobile Computing. Universit´e des Sciences et Technologie de Lille - Lille I, 2014. French. HAL Id: tel-01087240 https://hal.inria.fr/tel-01087240 Submitted on 25 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Département de formation doctorale en informatique UFR IEEA École doctorale SPI Lille APISENSE® : une plate-forme répartie pour la conception, le déploiement et l’exécution de campagnes de collecte de données sur des terminaux intelligents THÈSE présentée et soutenue publiquement le 05/11/2014 pour l’obtention du Doctorat de l’Université Lille I (spécialité informatique) par Haderer Nicolas Composition du jury Rapporteurs : Chantal Taconet, TELECOM SudParis, France Ernesto Exposito, INSA Toulouse, France Examinateurs : Stéphane Frénot, INSA Lyon, France Luigi Lancieri, Université Lille I, France Directeur : Lionel Seinturier, Université Lille I, France Co-encadrant : Romain Rouvoy, Université Lille I, France Laboratoire d’Informatique Fondamentale de Lille – Inria Lille - Nord Europe UMR Lille 1/CNRS 8022R É S UM É Le mobile crowdsensing est une nouvelle forme de collecte de données exploitant la foule de terminaux intelligents déjà déployés à travers le monde pour collecter massivement des données environnementales ou comportementales d’une population. Ces dernières années, ce type de collecte de données a suscité l’intérêt d’un grand nombre d’acteurs industriels et académiques dans de nombreux domaines tels que l’étude de la mobilité urbaine, la surveillance de l’environnement, la santé ou l’étude des comportements socioculturels. Cependant, le mobile crowdsensing n’en n’est qu’à ses premiers stades de développement, et de nombreux défis doivent encore être relevés pour pleinement profiter de son potentiel. Ces défis incluent la protection de la vie privée des utilisateurs, les ressources énergétiques limitées des terminaux mobiles, la mise en place de modèles de récompense et de déploiement adaptés pour recruter les utilisateurs les plus à même de collecter les données désirées, ainsi que faire face à l’hétérogénéité des plateformes mobiles disponibles. Dans cette thèse, nous avons cherché à réétudier les architectures des systèmes dédiés au mobile crowdsensing pour adresser les limitations liées au développement, au déploiement et à l’exécution de campagnes de collecte de données. Les différentes contributions proposées sont articulées autour APISENSE®, la plate-forme résultante des travaux de cette thèse. Plus particulièrement, APISENSE® propose un environnement distribué favorisant le développement et le déploiement rapides de campagnes de collecte, tout en prenant en considération des contraintes telles que la protection de la vie privée des utilisateurs ou encore les ressources énergétiques limitées de leurs terminaux. Pour atteindre ces objectifs, APISENSE® repose sur le modèle de composant SCA et sur l’ingénierie des lignes de produits logiciels, offrant ainsi un environnement modulaire et facilement configurable pour supporter une grande diversité de campagnes de collecte. Un modèle de programmation de haut niveau a également été proposé permettant de s’affranchir de toute la complexité liée aux développements d’applications de collecte mobiles. APISENSE® a été utilisé pour réaliser une campagne de collecte de données déployée auprès d’une centaine d’utilisateurs au sein d’une étude sociologique, et évalué à travers des expériences qui démontrent la validité, l’efficacité et le passage à échelle de notre solution. iiiA B S T R A C T Mobile crowdsensing is a new form of data collection that takes advantage of millions smart devices already deployed throughout the world to collect massively environmental or behavioral data from a population. Recently, this type of data collection has attracted interest from a large number of industrials and academic players in many areas, such as the study of urban mobility, environmental monitoring, health or the study of sociocultural attitudes. However, mobile crowdsensing is in its early stages of development, and many challenges remain to be addressed to take full advantage of its potential. These challenges include privacy, limited energy resources of devices, development of reward and recruitment models to select appropriates mobile users and dealing with heterogeneity of mobile platforms available. In this thesis, we aim to reconsider the architectural design of current mobile crowdsensing systems to provide a simple and effective way to design, deploy and manage data collection campaigns. The main contributions of this thesis are organize around APISENSE®, the resulting platform of this research. In particular, APISENSE® offers a distributed environment based on the SCA component model and software product line engineering , providing a modular and flexible environment to support a wide variety of data collection campaigns. Futhemore, APISENSE® takes into account constraints, such as protecting the privacy of users or limited energy resources devices. We also propose a high-level programming model to get rid of the complexity associated with the development of mobile data collection applications. APISENSE® has been used to carry out a data collection campaign deployed over hundred of users in a sociological study and evaluated through experiments demonstrating the validity, effectiveness and scalability of our solution. vTA B L E D E S M AT I È R E S 1 introduction 9 1.1 Contexte 9 1.2 Problématiques 10 1.3 Objectif du manuscrit 12 1.4 Contributions 13 1.5 Plan du manuscrit 15 1.6 Publications 16 I État de l’art 19 2 systèmes de collecte de données 21 2.1 Mobile crowdsensing 22 2.1.1 Qu’est ce que le Mobile crowdsensing ? 22 2.1.2 Classification des applications 23 2.1.3 Discussion 27 2.2 Les challenges clés du Mobile crowdsensing 28 2.2.1 Sécurité et Vie privée 28 2.2.2 Gestion des ressources 29 2.2.3 Hétérogénéité des équipements et des OS 30 2.2.4 Diffusion et passage à l’échelle des applications 31 2.2.5 Implication et incitation des usagers 32 2.2.6 Discussion 33 2.3 Travaux connexes 34 2.3.1 Funf Open Sensing Framework 34 2.3.2 MyExperience : A System for In situ Tracing and Capturing of User Feedback on Mobile Phones 36 2.3.3 Medusa : A programming framework for crowd-sensing applications 38 2.3.4 PRISM : Platform for Remote Sensing using Smartphones 42 2.3.5 Bubble-sensing 45 2.3.6 Pogo, a Middleware for Mobile Phone Sensing 46 12.3.7 AnonySense : A System for Anonymous Opportunistic Sensing 48 2.4 Synthèse et conclusion 49 II Contributions 53 3 collecte mobile de données 55 3.1 Introduction 55 3.2 Considérations et objectifs de conception 57 3.3 Langage de programmation des collectes 59 3.3.1 Concept de l’interface de programmation 60 3.3.2 Collecte de données dirigée par les évènements 60 3.3.3 Les actions 64 3.4 Intergiciel de collecte 68 3.4.1 Couche d’exécution 68 3.4.2 Couche de contrôle 72 3.4.3 Couche d’interaction 74 3.5 Évaluation du prototype 78 3.5.1 Quelques exemples de collectes 79 3.5.2 Coût énergétique d’une expérience de collecte 87 3.6 Conclusion 88 4 collecte répartie de données 91 4.1 Introduction 91 4.2 Infrastructure répartie de traitement des données 92 4.3 Architecture du serveur central 94 4.3.1 L’enregistrement des participants 95 4.3.2 L’enregistrement des expériences de collecte 96 4.3.3 Déploiement des tâches de collecte 98 4.3.4 Gestion des nœuds de collecte 99 4.4 Architecture des noeuds de collecte 100 4.4.1 Modèle de caractèristiques d’une campagne de collecte 101 4.4.2 Création d’une nouvelle campagne 107 4.4.3 Intéraction entre les composants 110 4.4.4 Extension des nœuds de collecte 112 4.5 Campagne de collecte communautaire 113 24.5.1 Extension du modèle de programmation 116 4.5.2 Coordonner l’exécution des tâches de collecte 119 4.6 Conclusion 124 III Évaluations 127 5 pratiques culturelles et usages de l’informatique connectée 129 5.1 Introduction 130 5.2 Contexte et objectif de l’étude PRACTIC 130 5.3 Développement de l’étude PRACTIC 131 5.3.1 Collecte opportuniste 132 5.3.2 Collecte participative 135 5.3.3 Retour utilisateur 136 5.3.4 Discussions 136 5.4 Déploiement de l’étude PRACTIC 139 5.4.1 Protocole du déploiement 139 5.4.2 Participation 140 5.5 Conclusion 143 6 évaluation du modèle collaboratif 145 6.1 Introduction 145 6.2 Mise en place de l’expérience 145 6.3 Résultats 148 6.3.1 Quantité de données et couverture géographique 148 6.3.2 Consommation énergétique 151 6.4 Conclusion 154 IV Conclusion 157 7 conclusion 159 7.1 Rappel des motivations 159 7.2 Rappel des contributions 160 7.2.1 Collecte mobile de données 160 7.2.2 Collecte répartie de données 161 7.3 Perspectives 162 3bibliographie 165 4TA B L E D E S F I G U R E S Figure 1 Vue d’ensemble de APISENSE® 15 Figure 2 Développement d’une application mobile avec FunfInABox 35 Figure 3 Architecture de Medusa [55] 41 Figure 4 Architecture de PRISM [16] 44 Figure 5 Architecture de Bubble-sensing [45] 45 Figure 6 Architecture de Anonysense [62] 48 Figure 7 Tableau comparatif des plate-formes MCS 52 Figure 8 Interface de Programmation APISENSE 61 Figure 9 Exemple de capture d’écran d’un retour utilisateur 67 Figure 10 Architecture de l’intergiciel mobile 69 Figure 11 Interaction de la couche d’exécution 69 Figure 12 Règles de confidentialité 75 Figure 13 Exemple de contenu web disponible via le FeedbackManager 78 Figure 14 Flux de données de l’expérience Manipulation de Lego NXT 82 Figure 15 Impact d’APISENSE sur la consommation énergétique 88 Figure 16 Impact des capteurs sur la consommation énergétique 89 Figure 17 Vue d’ensemble d’APISENSE® 93 Figure 18 Architecture SCA du serveur central 96 Figure 19 Modèle de caractéristiques d’une campagne de collecte 102 Figure 20 Architecture initiale d’un nœud de collecte 107 Figure 21 Processus de génération d’une architecture SCA 108 Figure 22 Architecture SCA d’une campagne de collecte 109 Figure 23 Interaction des composants APISENSE® 111 Figure 24 Exemple d’extension : Export des données au format KML 114 Figure 25 Composant SCA responsable du recrutement collaboratif 120 Figure 26 Distribution des capteurs virtuels 121 Figure 27 Données collectées par l’étude PRACTIC 132 Figure 28 Exemple de retour utilisateur PRACTIC 137 Figure 29 Gain en terme de lignes de code obtenu grâce à APISENSE® pour le développement de l’étude PRACTIC 138 5Figure 30 Nombre d’inscriptions par jour à PRACTIC 140 Figure 31 Diversité des équipements mobiles 141 Figure 32 Taux de participation à la collecte opportuniste 141 Figure 33 Taux de participation à la collecte participative et opportuniste 142 Figure 34 Représentation des sessions d’allumage de l’écran du terminal d’un participant cumulées au cours de 40 jours 142 Figure 35 Architecture du simulateur de traces de mobilité 147 Figure 36 Comparaison de la quantité de données collectées en fonction du nombre de dispositifs mobiles et de l’objectif de couverture géographique 149 Figure 37 Comparaison de la couverture géographique selon différentes périodes de la journée 150 Figure 38 Comparaison des moyennes de la consommation énergétique en fonction de la concentration de dispositifs mobiles dans la zone de collecte 152 Figure 39 Répartition des charges énergétiques suivant les approches : (a) individuelle, (b) collaborative avec une objectif de couverture de 1000 m 2 , (c) collaborative avec un objectif de couverture de 500 m2 153 6L I S T E D E S TA B L E A U X Table 1 Liste des fonctions d’observation d’événements prédéfinis. 61 Table 2 Liste des paramètres d’une fonction de rappel 61 Table 3 Configuration de l’observation de la position d’un utilisateur 62 Table 4 Liste des fonctions d’un objet de souscription 64 Table 5 Liste des fonctions de la façade de collecte 65 Table 6 Liste des fonctions de la façade dédiée à la création des questionnaires 66 Table 7 Exemples de tâches de collecte implémentées avec APISENSE. (*Lignes de code) 80 Table 8 Tableau décrivant la qualité du système de classification 85 Table 9 Comparaison de l’expressivité et du nombre de lignes de code 87 Table 10 Propriétés définissant une expérience de collecte 97 Table 11 Interface de programmation dédiée à la définition des campagnes de collecte communautaires. 116 Table 12 Façade utilisée pour les besoins de l’application PRACTIC 138 71 I N T R O D U C T I O N 1.1 contexte La dernière génération de terminaux intelligents tels que les smartphones ou les tablettes tactiles est rapidement devenue omniprésente dans notre quotidien. On recense, actuellement, plus d’un milliard de smartphones à travers le monde et ce nombre ne va cesser d’augmenter [42]. Non seulement dotés d’une grande capacité de calcul et d’une connexion Internet en continu, ces terminaux sont désormais programmables et équipés d’un grand nombre de capteurs sophistiqués permettant de prendre des images, capter des sons, mesurer la température ou la pression atmosphérique tout en donnant la position géographique. De ce fait, leurs usages permettent de générer de nombreuses traces numériques d’activités, capables d’identifier nos habitudes, nos relations sociales ainsi que l’environnement dans lequel on évolue. De par leurs fortes présences dans notre société et leurs hautes prouesses technologiques, ces terminaux ont ouvert la voie à une nouvelle forme de collecte de données à grande échelle, récemment appelée le Mobile Crowd Sensing (MCS) [27]. Plus particulièrement, le MCS fait référence à l’ensemble des applications qui impliquent des citoyens ordinaires, munis de leurs terminaux intelligents, afin de collecter et de partager des données dans le but de mesurer des phénomènes d’un intérêt commun. Ces dernières années, de nombreuses recherches ont été menées pour tenter d’exploiter le potentiel du MCS dans de nombreux domaines tels que l’étude de la mobilité urbaine ou des comportements sociaux, la surveillance de l’environnement ou la santé [39, 11]. Quelques exemples d’applications novatrices dans ce secteur comprennent la collecte et le partage de données concernant la qualité de l’air [19], le trafic routier [51], la pollution sonore [47], les performances cyclistes [20], ou encore des informations relatives aux prix des produits de consommation [17]. 91.2 problématiques Comme la revue de la littérature l’indique, le MCS n’en n’est qu’à ses premiers stades de développement, et de nombreux défis doivent encore être relevés pour pleinement profiter de son potentiel [39, 27, 66]. Ces défis sont particulièrement liés à l’implication d’individus rationnels, qui sont au centre du système de collecte de données. Cela demande de prendre en considération de nombreux aspects non-fonctionnels qui ne sont pas directement liés à la collecte de données difficiles en elle-même, rendant par conséquent le développement de ces systèmes encore difficile. Plus particulièrement, il est nécessaire de prendre en compte les points suivants : énergie : Bien que la dernière génération des terminaux intelligents continue de fournir plus de puissance de calcul, de mémoire, d’espace de stockage et de capteurs de plus en plus sophistiqués, les ressources énergétiques de ces terminaux restent limitées. Sans une gestion rigoureuse de l’énergie consommée par les applications de collecte, la batterie de ces terminaux peut s’épuiser en quelques heures, décourageant ainsi les individus à installer ces applications. respect de la vie privée : Sans un mécanisme de protection approprié, les applications mobiles peuvent se devenir de parfaits espions, en révélant potentiellement des informations privées sur leur propriétaire. Il est par exemple possible qu’elles puissent enregistrer des conversations intimes ou prendre des photos d’une scène privée, d’identifier des trajets quotidiennement empruntés par le propriétaire du terminal et d’observer ses principaux lieux de vie tels que son domicile ou son lieu de travail. Ce point représente également un frein majeur pour l’acceptation de ces applications par les individus. D’un autre coté, certaines de ces données peuvent se révéler indispensables pour l’objectif de la collecte de données. compromis : Prendre en compte ces deux derniers points demande généralement le développement d’algorithmes sophistiqués permettant de faire un compromis entre l’énergie consommée par les applications mobiles, leur niveau d’intrusion dans la vie privée des individus et la qualité des données collectées. diversité : De plus, les développeurs doivent également faire face à la diversité des systèmes d’exploitations mobiles disponibles sur le marché (par ex. Android, iOS). Pour déployer une application auprès d’un grand nombre d’individus, les développeurs doivent généralement étudier et développer une application pour chacun de ces systèmes, entraînant par conséquent un coût important (c.-à-d. temps de développement, monétaire). 10passage á l’échelle : Finalement, ces systèmes doivent également faire face au défi de collecter une grande quantité de données reportées par des utilisateurs répartis à travers le monde. De ce fait, déployer une application auprès de plusieurs millions d’utilisateurs qui collectent et propagent continuellement des données vers un serveur serait inefficace, et demanderait des ressources importantes en terme de CPU, de mémoire et d’espace de stockage de l’infrastructure hébergeant l’application serveur pour stocker et analyser ces données. En outre, ces applications peuvent générer un lot considérable de données qui peuvent être inutiles, surtout si la collecte vise uniquement une région spécifique ou une population particulière. Dans ce contexte, il est nécessaire de mettre en place un modèle de déploiement adapté pour recruter les bons utilisateurs au bon moment, capable de collecter seulement les données utiles à la campagne de collecte. À ce jour, beaucoup d’efforts ont principalement portés sur la réalisation de systèmes monolithiques, difficilement réutilisables dans un contexte non anticipé [6]. Ces systèmes ont été conçus complètement indépendamment les uns des autres, ne partageant aucun module logiciel commun, alors qu’ils ont à faire face à des problématiques communes. La mise en place d’une nouvelle campagne de collecte demande généralement de développer un nouveau système à partir de zéro, pouvant entraîner la négligence de certains aspects non fonctionnels, comme protéger la vie privée des individus, à cause de contrainte de temps ou une expertise limitée dans ce domaine. Ce manque d’approche réutilisable, également pointé du doigt dans la littérature [39, 27, 60, 66], entrave ainsi l’adoption du MCS par de nombreux acteurs intéressés par ce type de collecte. Dans cette thèse, nous avons cherché à réétudier les architectures des systèmes dédiées au MCS pour adresser les limitations identifiées ci-dessus liées au développement, au déploiement et à l’exécution d’une campagne de collecte de données. Plus particulièrement, l’objectif des travaux de cette thèse est de proposer une plate-forme générique, favorisant le développement et le déploiement rapides de campagnes de collecte de données pouvant être menées dans une grande variété de domaines. 111.3 objectif du manuscrit Comme nous l’avons décrit dans la section précédente, le développement d’applications utilisant le MCS comme source de collecte de données est une tâche complexe, nécessitant une grande expertise. Toutefois, pour ouvrir cette forme de collecte à de nombreux acteurs académiques et industriels, nous proposons dans cette thèse une plate-forme générique qui facilite le développement et le déploiement de ces applications de collecte. Plus particulièrement, nous adressons dans cette thèse les points suivants : Simplifier le développement des applications de collecte Le premier défi concerne le développement des applications de collecte. Actuellement, ce développement nécessite une grande expertise dans les systèmes d’exploitation des terminaux mobiles disponibles sur le marché. Pour simplifier leur développement, il est nécessaire de proposer un modèle de programmation nouveau fournissant une abstraction complète de ces systèmes d’exploitation. Dans ce contexte, les principaux défis sont de proposer un modèle : i) assez général pour supporter une grande variété d’activités de collecte qui peuvent impliquer une grande variété de capteurs, ii) permettant de minimiser l’expertise nécessaire dans les technologies mobiles afin d’accéder aux fonctionnalités offertes par les capteurs des terminaux mobiles, ainsi que leurs collectes et leurs propagations vers l’infrastructure serveur, iii) et finalement portable pour être en mesure de s’exécuter sur les différents systèmes d’exploitation. D’autre part, il est nécessaire de fournir un environnement fiable assurant la confidentialité des utilisateurs, efficace pour ne pas empêcher une utilisation normale des terminaux mobiles et faciles d’utilisation pour les utilisateurs voulant participer aux collectes de données. Mise en œuvre d’une plate-forme générique de collecte de données Le deuxième défi concerne l’architecture de la plate-forme responsable du déploiement des applications de collecte, de la persistance et de l’analyse des données collectées. La plupart des plate-formes proposées actuellement sont souvent monolithiques, donnant très peu ou pas de possibilités de personnalisation. Cependant, les applications de collectes peuvent être menées dans une grande variété de domaines, nécessitant diffé- 12rents services de l’application serveur pour analyser et stocker les données collectées ou encore déployer ces applications. Pour prendre en compte cette diversité, la flexibilité et l’extensibilité doivent être les propriétés clés de l’architecture mise en œuvre. Cela demande par conséquent de proposer un modèle identifiant les points communs et les différentes exigences des applications de collecte qui peuvent être réalisées. Ce modèle doit s’appuyer sur les bonnes pratiques de l’ingénierie logiciel pour fournir un cadre logiciel modulaire et configurable, et être utilisé simplement par les différents acteurs voulant mener de nouvelles collectes de données pour leurs permettre d’exprimer leurs exigences. D’autre part, la plate-forme doit être capable de passer à l’échelle, c’est-à-dire d’être capable d’impliquer un grand nombre d’utilisateurs mobiles ainsi qu’un grand nombre d’acteurs voulant définir de nouvelles collectes d’un grand volume de données. 1.4 contributions En réponse à ces défis, ces travaux ont abouti à la définition, l’implémentation et l’évaluation d’une plate-forme baptisée APISENSE®. La finalité de APISENSE® est de permettre une mise en place rapide de campagnes de collectes de données à travers des terminaux mobiles intelligents. Nous proposons ici une vue d’ensemble de la solution proposée illustrée par la figure 1. APISENSE® distingue deux rôles évoluant dans la plate-forme. Le premier, appelé simplement utilisateur, peut être un acteur voulant définir et déployer de nouvelles campagnes de collecte de données à travers des terminaux mobiles. Les utilisateurs peuvent utiliser un nœud de collecte dédié (DataGathering Node), qui peut être déployé sur une infrastructure publique ou privée selon leur exigence, et se servir des services fournis par celui-ci pour définir de nouvelles tâches de collecte grâce à un langage de script dédié, déployer la tâche à travers un sous-ensemble d’individus ainsi qu’exploiter ou exposer les données collectées (par ex. visualisation, analyse). Le second rôle, appelé participant, est un individu possédant un terminal mobile. Les participants peuvent utiliser une application mobile dédiée pour télécharger les tâches de collecte, les exécuter dans un environnement sécurisé et automatiquement propager les données collectées. Dans APISENSE®, la mise en relation entre les nœuds de collecte et les participants est assurée par le serveur central (Central Server). Dans un sens, le serveur central peut être perçu comme un magasin dédié aux tâches de collecte. Typiquement, son rôle est 13d’assurer le déploiement des tâches de collecte soumises par les nœuds de collecte, et également d’assurer une première couche d’anonymat des participants. Les objectifs présentés dans la section précédente sont adressés avec APISENSE® de la manière suivante : • À l’issue d’une étude approfondie des architectures présentées dans la littérature (cf. chapitre 2 section 2.3), nous avons proposé un modèle permettant de représenter la variabilité des systèmes responsables du développement et du déploiement de campagnes de collectes de données (cf. chapitre 3 section 4.4). Ce modèle est ensuite fourni aux utilisateurs leur permettant de définir des exigences selon la spécificité des campagnes qu’ils veulent mener. Une application serveur dédiée (c.-à-d. DataGathering Node dans la figure 1) est ensuite générée suite aux exigences définies, fournissant un ensemble de services permettant de développer et de déployer de nouvelles campagnes de collecte, d’assurer la persistance des données collectées par les dispositifs mobiles ainsi que de connecter des services additionnels pour extraire ou traiter ces données. • Nous avons défini un modèle de programmation de haut niveau permettant de s’affranchir de toute la complexité liée aux développements mobiles. Basée sur un langage de script, cette abstraction a été conçue pour être assez générale pour supporter une grande variété d’applications de collecte, facilement accessible pour des utilisateurs ayant très peu d’expertise en programmation mobile, et facilement portable pour être exécutée dans différents environnements mobiles (par ex. Android, iOS, Window Mobile)(cf. chapitre 3 section 3.3). • Pour assurer l’exécution des campagnes de collecte définies par notre modèle de programmation, nous proposons un environnement d’exécution dédié aux utilisateurs mobiles. Cet environnement est responsable du téléchargement, de l’exécution des applications de collectes et de la propagation des données collectées (cf. chapitre 3 section 3.4). Principalement, cet environnement met l’accent sur la consommation énergétique liée à l’exécution d’une campagne de collecte et la protection de la vie privée des utilisateurs. • Nous proposons des modèles et des algorithmes dédiés à l’optimisation de l’exécution de campagnes de collecte. L’optimisation proposée réside en deux points. Pour le premier, nous proposons un modèle de déploiement de tâches de collecte contextuel, permettant d’attribuer une application de collecte à un individu en fonction de propriétés temporelles, géographiques et de capacité 14de détection. Pour le second, nous proposons un algorithme permettant de coordonner l’exécution des tâches de collecte, entre les dispositifs répondant aux mêmes propriétés, afin d’équilibrer les coûts énergétiques entre les terminaux et de diminuer la redondance des données collectées(cf. chapitre 4 section 4.5). Figure 1 – Vue d’ensemble de APISENSE® 1.5 plan du manuscrit Ce manuscrit est divisé en quatre parties. La première partie donne une vue d’ensemble de l’état de l’art dans le domaine du Mobile crowdsensing. La seconde partie décrit les contributions de ce manuscrit. La troisième porte sur la validation des contributions proposées. Et finalement la quatrième conclut ce manuscrit et décrit les perspectives issues des travaux de cette thèse. Plus particulièrement, la suite de ce document est organisé comme suit. Partie 1 : État de l’art Chapitre 1 : Systèmes de collecte de données Ce chapitre a pour objectif de donner dans un premier un temps une vison plus approfondie du Mobile crowdsensing ainsi que ses problématiques. Nous décrivons par la suite des travaux proches à ceux proposés dans cette thèse et nous identifions leurs limitations. 15Partie 2 : Contributions Chapitre 3 : Collecte mobile de données Ce chapitre traite de l’environnement mobile de APISENSE®. Il décrit tout d’abord le modèle de programmation proposé permettant de minimiser le coût du développement des applications de collecte de données. Par la suite, il présente l’architecture de l’environnement mobile dédié à l’exécution des applications de collecte. Chapitre 4 : Collecte répartie de données Ce chapitre présente l’architecture et les choix d’implémentation de l’environnement serveur APISENSE® permettant de déployer des applications de collecte ainsi que d’exploiter les données collectées. Partie 3 : Validations Chapitre 5 : Pratiques culturelles et usages de l’informatique connectée Ce chapitre présente une campagne de collecte déployée auprès d’une centaine d’utilisateurs, réalisée au sein d’une étude sociologique nommée PRATIC (Pratiques Culturelles et Usages de l’Informatique Connectée). Chapitre 6 : Performance et efficacité de APISENSE® présente une validation quantitative sur les performances de APISENSE® Partie 4 : Conclusion Chapitre 7 : Conclusion Finalement, ce chapitre conclut ce manuscrit et expose les perspectives des travaux présentés. 1.6 publications Les travaux de cette thèse ont été réalisés au sein de l’équipe SPIRALS commune à Inria et à l’Université Lille 1 au sein de l’UMR LIFL (Laboratoire d’Informatique Fondamentale de Lille). Ils ont donné lieu aux publications scientifiques suivantes. Conférence International • Dynamic Deployment of Sensing Experiments in the Wild Using Smartphones. Nicolas Haderer, Romain Rouvoy and Lionel Seinturier. In 13th International IFIP 16Conference on Distributed Applications and Interoperable Systems (DAIS), pages 43-56. • A Federated Multi-Cloud PaaS Infrastructure. Fawaz Paraiso, Nicolas Haderer, Philippe Merle, Romain Rouvoy, Lionel Seinturier. In 5th IEEE International Conference on Cloud Computing (2012), pages 392-399. Chapitre de livre • A Cloud-based Infrastructure for Crowdsourcing Data from Mobile Devices. Nicolas Haderer, Fawaz Paraiso, Christophe Ribeiro, Philippe Merle, Romain Rouvoy, Lionel Seinturier Wenjun Wu. Cloud-based Software Crowdsourcing, Springer, 2014 (To appear) Workshop • A preliminary investigation of user incentives to leverage crowdsensing activities. Nicolas Haderer, Romain Rouvoy and Lionel Seinturier. 2nd International IEEE PerCom Workshop on Hot Topics in Pervasive Computing (PerHot) (2013), pp. 199-204. • Towards Multi-Cloud Configurations Using Feature Models and Ontologies. Clément Quinton, Nicolas Haderer, Romain Rouvoy and Laurence Duchien. In Proceedings of the 1st International Workshop on Multi-Cloud Applications and Federated Clouds, Multi-Cloud’13. Prague, Czech Republic, 22 April 2013, pp. 21-26. Vulgarisation scientifique • APISENSE : Crowd-Sensing Made Easy. Nicolas Haderer, Romain Rouvoy, Christophe Ribeiro, Lionel Seinturier. ERCIM News, ERCIM, 2013, Special theme : Mobile Computing, 93, pp. 28-29. • Le capteur, c’est vous ! Nicolas Haderer, Christophe Ribeiro, Romain Rouvoy, Simon Charneau, Vassili Rivron, Alan Ouakrat, Sonia Ben Mokhtar, Lionel Seinturier L’Usine Nouvelle, L’Usine Nouvelle, 2013, 3353, pp. 74-75 • Campagne de collecte de données et vie privée. Nicolas Haderer, Miguel Nuñez Del Prado Cortez, Romain Rouvoy, Marc-Olivier Killijian and Matthieu Roy. 3ème Journées du GDR CNRS GPL (2012), pp. 253-254. Rapport de recherche • AntDroid : A distributed platform for mobile sensing. Nicolas Haderer, Romain Rouvoy, Lionel Seinturier. [Research Report], 2012, pp. 27. RR-7885 17Première partie État de l’art 192 S Y S T ÈM E S D E C O L L E C T E D E D O N N É E S Sommaire 2.1 Mobile crowdsensing 22 2.1.1 Qu’est ce que le Mobile crowdsensing ? 22 2.1.2 Classification des applications 23 2.1.3 Discussion 27 2.2 Les challenges clés du Mobile crowdsensing 28 2.2.1 Sécurité et Vie privée 28 2.2.2 Gestion des ressources 29 2.2.3 Hétérogénéité des équipements et des OS 30 2.2.4 Diffusion et passage à l’échelle des applications 31 2.2.5 Implication et incitation des usagers 32 2.2.6 Discussion 33 2.3 Travaux connexes 34 2.3.1 Funf Open Sensing Framework 34 2.3.2 MyExperience : A System for In situ Tracing and Capturing of User Feedback on Mobile Phones 36 2.3.3 Medusa : A programming framework for crowd-sensing applications 38 2.3.4 PRISM : Platform for Remote Sensing using Smartphones 42 2.3.5 Bubble-sensing 45 2.3.6 Pogo, a Middleware for Mobile Phone Sensing 46 2.3.7 AnonySense : A System for Anonymous Opportunistic Sensing 48 2.4 Synthèse et conclusion 49 212.1 mobile crowdsensing 2.1.1 Qu’est ce que le Mobile crowdsensing ? En 2010, Ganti et al. définissent le Mobile crowdsensing comme la participation d’un groupe d’individus, disposant de terminaux mobiles intelligents qui, collectivement, partagent des informations pour la mesure ou la cartographie de phénomènes d’un intérêt commun". Typiquement, le MCS offre de nombreux avantages par rapport aux méthodes classiques de collecte de données telles que les réseaux de capteurs (WSNs), qui peuvent impliquer des coûts importants liés à l’installation d’un grand nombre de capteurs statiques et de leurs maintenances. En effet, des millions de dispositifs mobiles sont déjà déployés dans la nature, portés par des utilisateurs dans leur vie quotidienne. Avec la généralisation des magasins d’applications (par ex. App Store, Google Play), il est désormais possible pour des petites organisations comme des équipes de recherche ou des petites entreprises de rapidement délivrer une application mobile auprès de cette masse d’utilisateurs. Par exemple, au lieu d’installer un ensemble de caméras le long des routes, il est possible de collecter des données du trafic routier et de détecter les embouteillages en utilisant le GPS des dispositifs mobiles des conducteurs. Un autre avantage de l’utilisation de ces dispositifs est le nombre de capteurs multimodaux inclus dans ces appareils, permettant une collecte d’information contextuelle de haut niveau. En effet, le GPS peut fournir la position d’un utilisateur. Le microphone, quand il n’est pas utilisé pour les communications téléphoniques, peut être utilisé comme capteur acoustique. L’accéléromètre peut être, quant à lui, utilisé pour identifier les modes de transport des utilisateurs, leur activité journalière (par ex. temps passé en position assise, à dormir, à marcher, à courir) mais aussi détecter des dégâts importants sur une route. De nouveaux capteurs peuvent également facilement être ajoutés à ceux initialement préinstallés, en utilisant des connexions sans fils comme le Bluetooth pour communiquer entre eux. Quelques exemples sont les bracelets connectés qui peuvent mesurer la fréquence cardiaque 1 d’un individu, ou les capteurs qui mesure la qualité de l’air [19]. Pour finir, le dernier avantage est de pouvoir inclure les utilisateurs dans le processus de collecte, bénéficiant ainsi de l’intelligence humaine pour collecter des données sémantiquement complexes à identifier à partir de simples capteurs. Par exemple, un utilisateur peut facilement identifier la dégradation d’installations 1. http://pulseon.fi/ 22publiques, prendre une photo de ces dégâts et l’envoyer à la collectivité territoriale concernée [35]. Grâce à ces avantages, le MCS a suscité l’intérêt d’un grand nombre d’acteurs industriels et académiques dans des domaines tels que l’étude de la mobilité urbaine ou des comportements sociaux, la surveillance de l’environnement et la santé [39, 11]. Cependant, l’utilisation des dispositifs mobiles possédés par des individus introduit également de nouvelles problématiques, comme la préservation de la vie privée des utilisateurs, la grande consommation énergétique des applications de collecte ou alors comment inciter les utilisateurs à installer et exécuter ces applications. Dans la suite de cette section, nous présentons tout d’abord une vue d’ensemble de ces applications avant de décrire avec plus de précision ces problématiques. 2.1.2 Classification des applications Dans la littérature, il existe un grand nombre d’applications de collecte de données, mettant en évidence l’utilisation du MCS dans une grande variété de domaines. Globalement, ces applications peuvent être classées selon deux critères : le sujet à observer et le mode d’acquisition des données. Le classement selon le sujet à observer se scinde, lui encore, en deux dimensions : les applications de collecte personnelle et les applications de collecte communautaire. Les applications de collecte personnelle visent à observer et analyser le comportement d’un individu (e.g., activité physique, mode de transport), tandis que les applications de collecte communautaire visent à observer des phénomènes (à plus grande échelle) sur l’environnement (par ex. qualité réseaux, pollution atmosphérique ou sonore) ou sur une infrastructure publique (e.g., trafic routier, place de parking disponible, dégâts de matériel public). Le classement selon le mode d’acquisition de données peut également se scinder en deux modalités appelées : collecte participative et collecte opportuniste. Dans la collecte participative, l’utilisateur est directement impliqué dans la prise de décision de la collecte (i.e., en décidant quand, comment et quelles données doivent être collectées). Au contraire, dans la collecte opportuniste, elle est complètement automatisée par l’application, sans nécessiter une intervention de l’utilisateur. 23Collecte personnelle ou communautaire Dans les systèmes de collecte personnelle, l’ objectif est d’observer des phénomènes liés à un individu. Dans ce type de système, toutes les données collectées sont géné- ralement couplées avec un identifiant unique, permettant de suivre l’évolution d’un utilisateur spécifique à travers le temps. Elles sont généralement rendues à l’utilisateur sous forme d’un rapport détaillé sur son activité, partagées à travers un réseau social ou alors agrégées à travers plusieurs utilisateurs afin d’identifier divers comportements. Ce type de collecte est généralement utilisé dans les domaines de la santé, du sport ou de l’environnement. Dans le domaine de l’environnement par exemple, PEIR [51](Personal Environmental Impact Report) est un système permettant aux utilisateurs de se servir de leurs dispositifs mobiles afin de déterminer leur exposition aux polluants présents dans leur environnement. PEIR collecte continuellement les données GPS vers un serveur pour y effectuer une série de traitement consistant à segmenter les différents déplacements des utilisateurs, identifier les modes de transports (par ex. bus, voiture) et calculer la quantité de gaz carbonique émise lors des déplacements. Pour le calcul de l’émission du gaz carbonique, PEIR couple les informations des déplacements avec plusieurs bases de données : celles des principales entreprises polluantes, et celles de la météo et du trafic routier. Sur un site Internet spécifique, les utilisateurs peuvent ensuite consulter les rapports de leurs déplacements, les aidants à modifier leurs comportements et protéger leur santé. Dans le domaine du sport, BikeNet [20] fournit aux cyclistes une application leur permettant de mesurer leurs expériences sportives. BikeNet combine les données du GPS et de l’accéléromètre pour calculer la vitesse, les calories perdues ainsi que la qualité des routes empruntées. Les données collectées peuvent être visualisées par les cyclistes eux-mêmes, ou être agrégées avec d’autres utilisateurs afin de construire une carte complète des pistes cyclables. Les systèmes de collecte personnelle sont également beaucoup utilisés dans le cadre d’expériences scientifiques. Par exemple, EmotionSense [56] est un système dédié aux études de psychologie sociale. Il tente d’établir une relation entre le bien-être d’un utilisateur et ses interactions sociales ou ses activités. Pour identifier ces informations, EmotionSense analyse continuellement trois types d’informations. Premièrement, les conversations téléphoniques des utilisateurs pour mesurer leurs émotions durant leurs appels. Deuxièmement, les périphériques Bluetooth voisins pour identifier les 24personnes se trouvant régulièrement à proximité. Et finalement l’accéléromètre pour identifier l’activité régulière de l’utilisateur. Dans un autre contexte, HealthAware [28] est une application visant à observer l’obésité des utilisateurs. Avec cette application, les utilisateurs peuvent prendre en photo leur nourriture, ce qui permet au système de leur fournir en retour des informations sanitaires complémentaires sur cette nourriture. HealthAware collecte également les données de l’accéléromètre pour mesurer l’activité physique quotidienne des utilisateurs. Le système fournit en retour un rapport complet sur l’activité effectuée, et rappelle aux utilisateurs l’importance de garder une activité physique quotidienne pour être en bonne santé. Les systèmes de collecte communautaire visent, quant à eux, à observer des phénomènes à plus grande échelle, sur l’environnement ou sur des infrastructures publiques afin d’améliorer la vie d’une communauté (par ex. toutes les personnes habitant dans une ville, les étudiants d’une université). Quelques scénarios types de ce genre de collecte comprennent la mesure de la pollution atmosphérique en milieu urbain, ou l’observation des réseaux routiers afin de détecter les embouteillages ou des dégâts importants sur la chaussée. CommonSense [19] est un exemple d’application dédié à l’observation de la pollution atmosphérique. L’application mobile de CommonSense combine les données GPS avec des données fournies par un capteur externe mesurant la qualité de l’air ambiant. La communication entre le mobile et le capteur externe est assurée par une connexion Bluetooth. Les capteurs externes ainsi que l’application sont déployés auprès de la population, qui collectivement propage leurs positions ainsi que la qualité de l’air vers un serveur. Les données sont ensuite agrégées et peuvent être visualisées sur un site Internet spécifique. Similairement, NoiseTube [47] utilise directement les microphones des dispositifs mobiles pour mesurer la pollution sonore en milieu urbain. Un autre type de collecte communautaire implique la mesure de phénomènes en relation avec des infrastructures publiques. Par exemple, Nericell [50] est un projet qui a pour objectif de mesurer différents phénomènes issus du trafic routier. Ce projet analyse continuellement la position d’un utilisateur qui, couplée avec les informations issues de l’accéléromètre, permet de détecter la dégradation d’une route ou des freinages d’urgences et, couplée avec le microphone, permet de détecter un fort trafic à partir du bruit ambiant. Dans un autre contexte, LiveCompare [17] est une application qui permet de comparer différents prix d’un même article se trouvant dans des magasins situés à proximité 25d’un utilisateur. Avec cette application, les utilisateurs peuvent se servir de leur dispositif pour prendre en photo le code-barres d’un article. Le code est ensuite décrypté, et envoyé vers un serveur avec la position de l’utilisateur et la photo. En échange, LiveCompare fournit aux utilisateurs les différents prix disponibles pour ce même produit, en fonction des magasins se trouvant à proximité. Un autre exemple d’application est CreekWatcher 2 . Cette application surveille les niveaux et la pollution des eaux, à l’aide des rapports des utilisateurs, comme des photos prises à divers endroits au bord des étendues d’eau, ou des messages texte sur le quantité de déchets. Ces informations peuvent ensuite être exploitées par des commissions de contrôle des eaux. Collecte participative ou opportuniste Indépendant du sujet à observer, un facteur déterminant du succès d’une application est le niveau d’implication des utilisateurs dans le processus de collecte [38]. Typiquement, le processus de collecte peut prendre deux formes appelées collecte opportuniste [39] et participative [7]. Dans celle dite opportuniste, la collecte de données est complètement automatisée par l’application mobile (par ex. "collecter la position toutes les cinq minutes"). Cette approche a le principal avantage de minimiser l’intervention humaine dans le processus de collecte. Cela est particulièrement utile dans le cadre d’une collecte communautaire, permettant d’assurer la propagation de données régulièrement sur le serveur (sans que l’utilisateur soit contraint à accomplir des tâches quotidiennes sur son dispositif). Cependant, ces applications sont plus difficiles à développer, et consomment également beaucoup de ressources énergétiques. En effet, la difficulté principale pour développer ce type d’application est de déterminer dans quel contexte se trouve le dispositif mobile, afin d’assurer une certaine qualité des données collectées. Par exemple dans l’application NoiseTube [47], qui a pour objectif d’observer la pollution sonore, il est nécessaire de mesurer le niveau sonore uniquement quand le dispositif est hors de la poche ou du sac de l’utilisateur. Dans ce cas, cette issue peut être résolue en utilisant le capteur de lumière, mais par conséquent, nécessite la consommation de ressources plus conséquentes. 2. http://www.ibm.com/smarterplanet/us/en/water_management/article/creek_ watch.html 26Au contraire, la collecte dite participative nécessite une plus grande implication de la part des utilisateurs. Par exemple, dans l’application LiveCompare [17], les utilisateurs doivent manuellement prendre une photo du produit qu’ils veulent comparer. Le principal avantage de cette approche est qu’elle permet de bénéficier de l’intelligence humaine pour réaliser des opérations plus complexes. Si nous reprenons l’exemple de application NoiseTube [47], l’approche participative peut permettre de résoudre facilement le problème du contexte du dispositif, en demandant aux utilisateurs de prendre une mesure du niveau sonore manuellement lorsque leur dispositif est hors de leur poche. Cependant, l’inconvénient de cette approche est que la qualité des données, ainsi que la fréquence à laquelle elles sont collectées, dépend fortement de l’enthousiasme des utilisateurs pour l’application. 2.1.3 Discussion Dans cette section, nous avons présenté une vue d’ensemble du MCS, ses principales caractéristiques ainsi que les domaines d’applications utilisant le MCS comme source d’approvisionnement de données. Cependant, jusqu’à ce jour, les applications développées ont principalement été élaborées dans un contexte applicatif spécifique, et difficilement réutilisable. En effet, ces applications ont été conçues complètement indé- pendamment des unes des autres, ne partageant aucun module logiciel commun, alors qu’elles ont à faire face à des problématiques communes. Ce manque de solutions réutilisables, largement pointé du doigt dans la littérature ces dernières années [39, 27, 60, 66], rend non seulement le développement d’une application spécifique difficile, mais il y a aussi la problématique du recrutement des participants qui doit être repris de zéro pour chaque application. Avec la popularité croissante du MCS dans de nombreuses communautés scienti- fiques, fournir une plate-forme générique permettant un rapide développement et un déploiement d’une large variété de campagnes de collecte de données devient une nécessité [27]. C’est donc dans cette lignée que s’inscrivent les travaux de cette thèse. Cependant, réaliser une telle plate-forme comporte de nombreux défis, que nous présentons dans la section suivante. 272.2 les challenges clés du mobile crowdsensing Dans cette section, nous identifions les principaux défis à relever afin proposer une plateforme générique dédiée aux développements et aux déploiements de campagne de collecte de données. Principalement, nous identifions cinq défis : Sécurité et vie privée, Gestion des ressources, Hétérogénéité des équipements et des OS, Diffusion et passage à l’échelle de applications, Implication et incitation des usagers. Pour chacun des défis, nous décrivons brièvement la problématique ainsi que les différentes solutions envisagées dans l’état de l’art. 2.2.1 Sécurité et Vie privée Respecter la vie privée des utilisateurs est peut-être la responsabilité la plus fondamentale d’une plate-forme de collecte. Les utilisateurs sont naturellement sensibles aux données collectées sur leurs dispositifs, spécialement si ces informations comprennent leurs localisations, des images sensibles ou alors des communications audios. En effet, de nombreux travaux [36] ont montré que de nombreuses données, même si elles peuvent paraître anodines prises individuellement, peuvent révéler de nombreuses informations sensibles sur les habitudes ou les relations sociales d’un individu lorsqu’elles sont agrégées dans la durée. Par exemple, les données de géolocalisation collectées avec le GPS, couplées avec des données temporelles peuvent être utilisées pour inférer les trajets quotidiens empruntés par un utilisateur, ou encore ses principaux lieux de vies tels que son domicile ou son lieu de travail [26]. Afin de protéger la vie privée des utilisateurs, de nombreuses solutions ont été envisagées dans la littérature. Christin et al. [11] donne une bonne vue d’ensemble des techniques utilisées selon le contexte de la collecte, qu’elle soit personnelle ou communautaire. Typiquement, ces techniques peuvent consister à utiliser un alias pour assurer les communications entre le serveur et le dispositif mobile, à perturber volontairement les données collectées avant de les propager vers le serveur (en modifiant par exemple les coordonnées GPS), à agréger les données entre n utilisateurs partageant des propriétés communes (par ex. n participant situés dans le même quartier), ou alors à échanger alternativement les traces de mobilités entre plusieurs utilisateurs. 28Cependant, bien que ces approches permettent d’assurer une certaine confidentialité des utilisateurs, elles impliquent également une dégradation des données qui sont collectées. Dans ce cas, il est nécessaire de faire un compromis entre qualité et confidentialité. Ce compromis peut être fait en effectuant un maximum de traitement directement dans le dispositif mobile. Par exemple, Nericell [50] adopte cette approche en analysant toutes les données issues de l’accéléromètre et du microphone localement, et propage uniquement des informations de haut niveau sur le serveur (par ex. fort trafic). Une autre solution envisagée par Christin et al. [11] est de laisser la possibilité aux utilisateurs de définir leurs exigences en matière de vie privée. En effet, la notion de vie privée peut énormément varier d’un individu à un autre. Par exemple, certain utilisateur peuvent être retissant à partager leur position contraire à d’autre. Dans ce contexte, il est nécessaire de fournir aux utilisateurs des moyens leur permettant de spécifier les données qu’ils veulent partager, dans quelles circonstances (par ex. temps, position), et surtout dans quel but. 2.2.2 Gestion des ressources Alors que les smartphones continuent de fournir plus de puissance de calcul, de mémoire, d’espace de stockage et de capteurs de plus en plus sophistiqués, les ressources énergétiques de ces dispositifs restent limitées. En effet, certaines applications déployées [49] montrent que la durée de vie de la batterie d’un dispositif, peut être réduite de 20 heures à 6 heures si certaines ressources sont exploitées activement. Par exemple les ressources du CPU pour traiter un grand volume de données (par ex. traitement de données audio), les ressources de certains capteurs comme le GPS, ou encore des ressources de communications (par ex. 3G, WIFI) pour partager en temps réel les données collectées. Un aspect intéressant pour réduire la consommation énergétique de ces applications est la multimodalité de certains capteurs. En effet, cela peut permettre de faire un compromis entre la qualité des données, en terme de fréquence d’échantillonnage et de précision, et le coût énergétique lié à leurs acquisitions. L’exemple le plus courant est l’acquisition de la position d’un utilisateur, qui peut être obtenue soit par le GPS, impliquant une grande coût énergétique, mais fournissant une grande précision (5- 20 mètres), soit par WiFi ou par la triangularisation GSM, qui sont moins précis 29(20-1000 mètres), mais ont une taxe énergétique moins importante. À partir de ce constat, de nombreux travaux ont été proposés dans la littérature, essayant d’alterner l’utilisation de ces différents capteurs pour faire le plus efficacement ce compromis. Par exemple, EnLoc [14] adapte la fréquence d’échantillonnage et les capteurs haute et basse qualité en fonction de la batterie de l’utilisateur. Matador [8] propose également un algorithme adaptatif, mais pour déterminer si l’utilisateur se trouve dans une zone précise. SenseLoc [34] active le GPS uniquement si l’utilisateur se déplace en utilisant l’accéléromètre pour identifier son activité. Cependant, un inconvénient de ces approches est qu’elles ont été conçues pour un contexte applicatif spécifique, et qu’elles ne sont donc pas forcement adaptées pour un autre. De plus, ces approches restent limitées lorsque de multiples applications coexistent dans un même dispositif. Par exemple, les applications dédiées à l’observation de la pollution sonore et du trafic routier nécessitent toutes les deux des données de géolocalisation. Dans ce contexte, ces applications effectuent leurs propres échantillonnages des données GPS, pouvant entraîner une surconsommation énergétique du dispositif mobile. Cela limite ainsi les utilisateurs à participer à un nombre limité d’applications. 2.2.3 Hétérogénéité des équipements et des OS Un autre aspect à prendre en considération est l’hétérogénéité des systèmes d’exploitation et des équipements disponibles. En effet, selon Gartner Inc. 3 , les ventes de smartphones en 2013 ont totalisé plus de 1,8 milliards d’unité, réparties principalement entre trois systèmes d’exploitation (OS), Android 4 avec 78,4% de part de marché, iOS 5 avec 15,6 % et Windows Phone 6 avec 3,2%. Bien que ce marché en pleine effervescence — soit une augmentation 3.5% depuis 2012 —, confirme le potentiel du Mobile crowdsensing pour la collecte de données à grande échelle, cela induit aussi un long processus de développement pour prendre en considération tous ces systèmes d’exploitation. Pour le développement d’une application sur un OS spécifique, un ensemble d’outils et d’APIs sont fournis aux développeurs. Ces APIs sont implémentées généralement dans des langages de programmation différents, par exemple Java pour Android et 3. Gartner Inc. http://www.gartner.com/newsroom/id/2665715 4. Android : http://www.android.com 5. iOS : http://www.apple.com/fr/ios 6. Windows Phone : http://www.windowsphone.com 30Objective-C ou Apple Swift 7 pour iOS. Ceci implique qu’une application développée pour l’un de ces OS est incompatible avec les autres. Par conséquent, cela demande aux développeurs d’étudier et de développer une application spécifique pour chaque OS disponible, afin de pouvoir impliquer un maximum d’utilisateurs dans le système de collecte. Cette diversité a été soulignée par l’expérience menée par Balan et coll. [4], qui ont mis plus six mois pour le développement et le déploiement d’une expérience de collecte à travers 15,000 taxis à Singapour. Pour faire face à cette hétérogénéité, également identifiée par [60], il est nécessaire de concevoir les applications de collecte dans un langage de haut niveau. Dans ce contexte, le défi consiste à proposer une abstraction assez générale pour supporter le dé- veloppement d’applications variées (opportuniste et participative), qui peut également impliquer une grande variété de capteurs, portables pour supporter la diversité des plate-formes mobiles (c.-à-d. Android, iOS, Windows Mobile), et finalement accessibles pour minimiser l’expertise nécessaire dans les technologies mobiles. 2.2.4 Diffusion et passage à l’échelle des applications La diffusion des applications est un aspect crucial pour assurer le passage à l’échelle d’une plate-forme de collecte. Généralement, la diffusion des applications mobiles est assurée par les magasins traditionnels proposés par les plate-formes mobiles (par ex. Google Play pour Android, Apple Store pour iOS). Cependant, une fois disponible dans un magasin, l’application peut être potentiellement téléchargée par des millions d’utilisateurs à travers le monde. Ces utilisateurs peuvent alors générer un lot considérable de données qui peuvent être inutiles, surtout si la collecte vise uniquement une région spécifique ou une population particulière. De plus, la période de prolifération des mises à jours de ces applications vers les utilisateurs peut prendre plusieurs heures jusqu’à plusieurs jours selon le magasin utilisé (par ex. quelques heures pour Google Play jusqu’à plusieurs heures pour Apple Store). Dans le cadre du MCS, cette période est beaucoup trop longue, spécialement si l’objectif est de collecter des données lors d’un événement ne durant que quelque jours, comme un festival ou une fête nationale. En effet, lors de ces manifestations, après avoir récolté les premières données, il peut s’avérer nécessaire de 7. https://developer.apple.com/swift 31mettre rapidement à jour l’application afin d’améliorer la qualité de la collecte ou de remédier à des défauts de programmation. Dans ce cadre, il est nécessaire de développer de nouveaux mécanismes pour déployer ces applications de collecte [39]. Ces mécanismes devront prendre en compte plusieurs considérations. La première est de maîtriser le déploiement de ces applications vers les participants les plus à même à collecter les données désirées, en limitant le nombre d’utilisateurs impliqués dans la collecte, ou en ne visant qu’une population particulière (par ex. région géographique, tranche d’âge), tout en assurant leurs confidentialités. La deuxième considération est d’assurer un rapide déploiement de leurs mises à jour pour adresser les exigences évolutives liées aux premières données collectées, ou tout simplement pour corriger des erreurs de programmation. La dernière, aussi envisagée par [27, 60], est de permettre de coordonner l’exécution des campagnes à travers plusieurs dispositifs, notamment dans les campagnes de collecte communautaire. En effet, généralement ces applications collectent périodiquement (toutes les x secondes) des données sans prendre en considération si un autre dispositif placé à proximité exécute la même application. Cela peut ainsi entraîner une forte duplication de données collectées, en particulier en milieu urbain où il peut y avoir une forte densité d’utilisateurs. Dans ce contexte, effectuer une coordination entre ces dispositifs pourrait permettre de diminuer la quantité de données redondantes sur le serveur, et également équilibrer les charges énergétiques entre les dispositifs, réduisant ainsi l’énergie globale consommée lors de l’exécution de la campagne. 2.2.5 Implication et incitation des usagers Inévitablement, sans une participation adéquate des utilisateurs, il peut être très difficile d’obtenir la masse de données critique pour l’application. Cependant, comme nous l’avons mentionné dans les sous-sections précédentes, en utilisant une application de collecte, les utilisateurs consomment de nombreuses ressources de leurs dispositifs, et peuvent potentiellement s’exposer à la divulgation d’informations confidentielles. Dans ce contexte, un utilisateur peut ne pas être intéressé à participer à l’application, à moins de recevoir une récompense adaptée. Dans ce contexte, de nombreux travaux ont porté sur la réalisation d’un modèle économique permettant d’attribuer des récompenses financières aux utilisateurs en fonction de leur participation. Ces modèles peuvent être statiques [57], en attribuant 32un prix fixe aux données partagées par les utilisateurs, ou dynamiques [40] en faisant varié le prix des données en fonction de la couverture des premières données partagée, pour inciter par exemple les utilisateurs à se déplacer dans des zones peu couvertes. Cependant, bien que ces modèles puissent favoriser la participation des utilisateurs et améliorer la qualité des données obtenues, collecter des données à grande échelle peut nécessiter un budget considérable, qui n’est pas forcément accessible par exemple pour des équipes de recherche. Dans ce contexte, de nombreux modèles alternatifs, non monétaires, ont été explorés dans la littérature ces dernières années. Ces sources de motivation peuvent par exemple s’inscrire dans le cadre d’une démarche citoyenne ou scientifique en aidant à diminuer l’émission de gaz carbonique dans la nature par exemple [51]. Ces sources peuvent également prendre la forme d’un jeu, en simulant une compétition entre les utilisateurs, en partageant ses performances sur les réseaux sociaux [49], ou en attribuant des récompenses virtuelles. Une dernière source de motivation est d’obtenir un bénéfice direct en partageant des données, par exemple dans l’application LiveCompare [17], les utilisateurs peuvent bénéficier des prix scannés par les autres utilisateurs. 2.2.6 Discussion Le principal objectif d’une plate-forme générique de collecte de données est de permettre la fédération d’une large communauté d’utilisateurs, avec des niveaux d’expertises et des exigences différentes. En effet, les campagnes de collecte de données peuvent être de différents types, qui peuvent être de type communautaire ou personnel, et peuvent également impliquer différents niveaux de participation de la part des utilisateurs (c.-à-d. collecte opportuniste et participative). Comme nous en avons discuté tout au long de cette section, la mise en place d’une campagne demande de faire de nombreux compromis. Que ce soit sur la qualité des données, leur quantité, la préservation de la vie privée des utilisateurs ou encore la consommation énergétique des applications de collecte. Nous avons également vu que dans la littérature, de nombreux modèles ou algorithmes ont été proposés pour adresser ces points. Cependant, aucun de ces modèles ne représente une solution idéale, et ne peut être appliqué seulement dans un contexte applicatif spécifique (par ex. population visée, type de de données collectées). Dans ce contexte, nous pensons que la flexibilité et l’extensibilité doivent être les propriétés clés de l’architecture logicielle d’une plate-forme générique. La flexibilité fait 33référence à la capacité de la plate-forme à s’adapter à la diversité des campagnes de collecte qui peuvent être menées. Cette diversité peut faire référence à différents types de données qui peuvent être collectées (c.-à-d. impliquant de nombreux capteurs), aux technologies utilisées pour les sauvegarder (c.-à-d. base de données), et les structurer (c.-à-d. méthode d’indexation) et les analyser. Quant à l’extensibilité, elle fait référence à la capacité de la plate-forme pour intégrer de nouvelles contributions, afin de faire face aux exigences des utilisateurs non anticipées. Dans ce cadre, la plate-forme pourrait permettre également à des scientifiques travaillant sur une problématique spécifique du MCS (par ex. vie privée, modèle de récompense, etc.), de se focaliser sur leur domaine d’expertise sans avoir à redévelopper un système complet et donc participer à l’amélioration de la plate-forme. Dans la section suivante, nous faisons une étude comparative des différentes plateformes ayant reçu beaucoup d’attention dans la littérature ces dernières années, et ayant ce même objectif. 2.3 travaux connexes Comme nous l’avons vue dans la section précédente, le développement d’application de collecte de données demande de faire face à de nombreux défis. Dans cette section, nous décrivons un certain nombre de travaux existants, proposant des plate-formes ayant pour objectif de simplifier leurs développements et leurs déploiements. Pour chaque travail présenté, nous décrivons brièvement l’architecture générale adoptée, et nous les confrontons par rapport aux défis définis dans la section précédente. 2.3.1 Funf Open Sensing Framework Funf [1] est une plate-forme open source dédié aux développements d’applications de collecte de données mobiles basées sur le système d’exploitation Android. Initialement, Funf a été développé par le MIT Media Lab, afin de proposer aux scientifiques un outil plus générique pour les aider à facilement concevoir leurs applications de collecte. Le concept de base proposé par Funf est appelé Probe. Typiquement, un Probe est un module logiciel (c.-à-d. portion de code Android) assurant la capture de données d’un capteur physique ou logique (par ex. GPS, température, contact). Pour le développement 34des applications, Funf met à disposition un service appelé FunfInABox, accessible via une interface web. L’interface propose un formulaire qui permet aux scientifiques de sélectionner et configurer un ensemble de Probe à inclure dans l’application mobile (cf. figure 2). Le formulaire validé, FunfInABox procède alors à la génération de l’application et de la mettre à disposition des scientifiques à travers un compte Dropbox, un service de stockage et de partage de fichier en ligne. L’application peut également être configurée pour propager périodiquement les données collectées vers le même compte Dropbox, ou sur un serveur HTTP. Pour des raisons de sécurité, toutes les données collectées sont encryptées, et toutes les données sensibles telles que les contacts ou les SMS sont automatiquement hachés. Funf fournit également un ensemble de scripts qui peuvent être utilisés par les scientifiques pour décrypter les données, les insérer dans une base de données relationnelle et visualiser les données. Figure 2 – Développement d’une application mobile avec FunfInABox Funf se diffère principalement par sa simplicité. En effet, l’utilisation d’un formulaire web permet de rapidement développer une nouvelle application sans nécessiter toutes sortes d’expertise en programmation. Cependant, les applications qui peuvent être développées restent très basiques, limitées à la collecte périodique de données brutes de capteurs, et ne supportent pas les interactions avec les utilisateurs. De plus, les applications générées ne proposent pas aux utilisateurs de mécanismes leur permettant de contrôler les données qui sont collectées sur leurs dispositifs ni de retour sur celles-ci. D’autres parts, Funf ne fournissent pas de service spécifique pour aider les utilisateurs à déployer leurs applications vers les dispositifs mobiles. Ils sont alors contraints d’utiliser les magasins d’applications, devant faire face aux problématiques discutées précédemment(cf. section 2.2.4). 352.3.2 MyExperience : A System for In situ Tracing and Capturing of User Feedback on Mobile Phones Jon Froehlich et al. [25] proposent une approche plus flexible pour développer des applications de collecte avec MyExperience. 1 2 3 4 6 7 8 9 14 15 16 17 18 00:30 19 CallQuality 20 21 22 23 25 cellnetwork.png 26 27 Bad 28 Poor 29 Fair 30 Good 31 Excellent 32 33 34 Listing 2.1 – MyExperience : Exemple de configuration de collecte de données MyExperience facilite la définition d’une expérience collecte en proposant une abstraction appelée Sensors Triggers et Actions au-dessus du langage descriptif XML. Dans cette abstraction, les triggers combinent les flux des données fournis par les sensors et une expression logique pour déterminer quand une action doit être déclenchée. 36Pour capturer l’expérience d’un utilisateur, cette abstraction supporte la définition de questionnaires, qui peuvent être présentés à l’utilisateur périodiquement, ou après un évènement spécifique. Le listing 2.1 montre par exemple une expérience affichant à un utilisateur un questionnaire lui demandant la qualité de sa communication vocale après un appel téléphonique. Cependant, l’abstraction proposée a plusieurs limitations. La première est que les triggers qui exécutent les actions ne peuvent pas exécuter une seconde action en fonction du résultat de la première. Cela empêche par exemple de déclencher un nouveau questionnaire en fonction des premières réponses fournies. La deuxième concerne l’expressivité de l’abstraction qui reste limitée aux balises XML définies au préalable. Cette limitation par exemple empêche le développement d’algorithmes contextuels complexes (par ex. inférence de l’activité d’un utilisateur) complexe. Et finalement, MyExperience reste limité aux collectes participatives. L’architecture de la plate-forme MyExperience est composée de deux parties spéci- fiques : i) une application mobile Windows Mobile, responsable de de l’exécution des fichiers XML et ii) une application serveur, responsable de la persistance des données collectées. L’application mobile supporte également la propagation automatique des données vers le serveur. La propagation des données est effectuée lorsqu’une connexion réseau est détectée, et utilise le protocole HTTPS pour sécuriser le transfert des données. L’application fournit également une option permettant d’utiliser un algorithme de cryptographie SHA-1 pour hacher les données confidentielles des utilisateurs (par ex. SMS, contacts, numéro de téléphone). Cependant, MyExperience ne fournit pas de mécanisme particulier pour aider les scientifiques à déployer leurs expériences. L’application mobile ne supportant l’exécution que d’une seule expérience, cela empêche par exemple aux scientifiques de bénéficier des applications déjà installées chez les utilisateurs pour déployer leurs propres expériences.Néanmoins, MyExperience fournit plusieurs mécanismes permettant la mis à jours des expériences à distance, en envoyant la nouvelle expérience par SMS ou un message électronique aux utilisateurs concernés. Cependant, cela nécessite que les scientifiques aient connaissance du numéro de télé- phone ou de l’adresse électronique des utilisateurs, ce qui met en péril l’anonymat des utilisateurs. 372.3.3 Medusa : A programming framework for crowd-sensing applications Medusa, présenté par Ra et al. [55], est une plate-forme de programmation et de distribution de tâches de collecte participatives. Medusa s’adresse principalement aux utilisateurs finaux, sans expertise en programmation. Un exemple typique d’application présentée est celui du citoyen journaliste, permettant au journaliste de recruter des citoyens mobiles pour récolter des vidéos et des commentaires d’un évènement spécifique (par ex. accident, feu de forêt). Dans Medusa, la spécification d’une nouvelle tâche consiste à définir une séquence d’actions qui doivent être exécutées par les mobiles. Pour spécifier cette séquence d’actions, Medusa propose MedScript, une abstraction de haut niveau basé sur XML. MedScript propose deux niveaux d’abstractions : les stages et les connecteurs. Les stages permettent de définir une action élémentaire qui doit exécutée par le dispositif. MedScript distingue deux type de stages : i) les stages consistant à extraire des données des capteurs (par ex. GPS, accéléromètre) appelés SPC-Stage, et les stages nécessitant une intervention humaine (par ex. prendre une vidéo, documenté une photo) appelés Hit-Stage. Chaque stage inclut également plusieurs paramètres, comme une date d’expiration, un contexte d’exécution (par ex. région spécifique ou période de la journée) et également inclure une récompense financière pour inciter les utilisateurs à exécuter les stages. Par exemple, le listing 2.2 décrit l’application du citoyen journaliste. Cette application comporte quatre stages et deux connecteurs définissant l’enchaînement suivant : Recruit -> TakePicture -> GetSummary -> UploadData . Le premier stage permet de recruter les utilisateurs, le deuxième demande aux utilisateurs de prendre une photo dans une région spécifique, le troisième demande aux utilisateurs de commenter la photo prise et finalement le dernier permet d’envoyer le commentaire et la photo vers le serveur. 1 2 Citizen-Journalst 3 4 Recruit HIT 5 recruit 6 7 Citizen Journalist Demonstration 8 18:00:00 12/16/2011 9 .05 10

W_WID

3811 12 13 14 GetSummary SPC 15 medusalet_videosummary 16 immediate none 17 18 IMAGE 19

SUMMARY

20 21 22 23 TakePicture SPC 24 medusalet_mediagen 25 location=34.020259|-118.290131|40, user-initiated 26 27 -t image 28

IMAGE

29 30 31 32 UploadData SPC 33 medusalet_uploaddata 34 none textdesc 35 36 SUMMARY 37 38 39 40 41 Recruit 42 TakePicture Hiring 43 44 45 TakePicture 46 GetSummary Hiring 47 48 49 GetSummary 50 UploadData Hiring 51 52 Listing 2.2 – Le journaliste citoyen développé en MedScript language Pour le déploiement des tâches de collecte, l’architecture de Medusa (cf. figure 3) est composé d’un ensemble de service exécuté sur une infrastructure serveur, et une 39application mobile distribuée auprès d’un ensemble d’utilisateurs. Nous décrivons brièvement le rôle de ces composants. Le Interpreter est le point d’entré de Medusa, il accepte les tâches décrites en MedScript, vérifie leur validité et les envoies aux Task Tracker. Le Task Tracker est responsable de coordonner l’exécution des tâches vers les dispositifs mobiles. Pour chaque tâche, le Task Tracker lui associe une instance dédiée responsable du suivie des différents stages associés à la tâche. Dans ce cas, si la tâche doit être exécuté par 50 utilisateurs (c.-à-d. collecter 50 images dans l’exemple présenté), 50 instances seront alors instanciées dans le Task Tracker. Pour chaque stage inclus dans la tâche, l’instance associé à la tâche notifie l’application mobile assignée lui demandant d’exécuter le stage. Une fois le stage complété, l’application mobile alerte le Task Tracker et attend une instruction pour exécuter le stage suivant. Une fois tous les stages terminés, le Task Tracker averti l’initiateur de la tâche et rend les données disponibles dans le Data Repository. Le Worker Manager sert principalement d’interface avec le service Amazon Mechanical Turk (AMT) 8 , qui est utilisé pour la phase de recrutement. Lorsque le Task Tracker instancie une nouvelle tâche, une description de la tâche ainsi que sa rémunération est postée sur le service AMT. Les participants peuvent alors se connecter sur le service AMT avec leur application mobile, et s’inscrire auprès de la tâche qu’il les intéresse. Une fois inscrit, le Worker Manager notifie le Task Tracker, qui peut alors procéder à l’exécution des stages. AMT est également utilisé pour assurer les communications (c.-à-d. par SMS) entre le Task Tracker et les applications mobiles, et la rémunération des utilisateurs. Cette approche permet d’assurer l’anonymat des utilisateurs, dans le sens où Medusa n’a pas besoin de connaître l’identité réelle des utilisateurs pour communiquer avec eux et les récompenser. Le Stage Library représente la partie extensible de Medusa. Chaque stage supporté par MedScript est associé à un exécutable Android stocké dans le Stage Library. Les exécutables sont alors téléchargés par les dispositifs mobiles avant d’exécuter le stage associé. Cette approche permet d’étendre les capacités offertes par MedScript sans avoir à recompiler l’application mobile et la redéployer. L’ Application mobile est composée de deux services appelés StageTracker et MedBox. Le Stage Tracker est responsable des communications entre l’ap- 8. Amazon mechanical turk : https://www.mturk.com 40plication mobile et les services du serveur. Ces communications comprennent le téléchargement des exécutables des différents stages, d’analyser les SMS envoyés par AMT et propager les données vers le serveur. La MedBox est responsable de l’exécution des stages dans le dispositif mobile. Un stage peut être exécuté soit directement après une notification du Stage Tracker, soit en fonction du contexte de l’utilisateur (c.-à-d. zone géographique ou période de la journée). L’application mobile fournit également plusieurs mécanismes pour contrôler les ressources consommées par l’application mobile et assurer la confidentialité des participants. Pour la gestion des ressources, Medusa laisse la possibilité aux participants de définir des limites en terme de CPU, réseau ou mémoire utilisées lors de l’exécution des stages. Pour assurer la confidentialité, l’application mobile demande une confirmation aux utilisateurs avant de propager les données sur le serveur. Cela permet aux utilisateurs de vérifier si les données collectées peuvent être compromettantes vis-à-vis de leurs vies privées. Figure 3 – Architecture de Medusa [55] Medusa propose certains aspects intéressants à l’égard des considérations discutées dans la section précédente. Ces aspects sont l’intégration d’un service tiers comme AMT, pour assurer l’anonymat des utilisateurs, la possibilité d’intégrer des récom- 41penses financières, ou encore proposer une application mobile générique favorisant la participation des utilisateurs à plusieurs tâches de collecte. Cependant Medusa a plusieurs limitations. La première réside lors de la phase de recrutement des utilisateurs. En effet, si nous reprenons l’exemple du citoyen journaliste, il faudrait que, idéalement, seul les utilisateurs se situant à proximité de l’événement couvert par le journaliste, puissent être capables de s’inscrire à la tâche. Or, bien que Medusa supporte la notion de contexte d’exécution (par ex. exécuter un stage dans une zone géographique), celle-ci est interprétée uniquement par l’application mobile après la phase d’enregistrement. Ainsi, de nombreux utilisateurs peuvent s’enregistrer sans qu’ils ne soient à proximité de l’événement visé. Une autre limitation réside dans l’abstraction du modèle de programmation proposé, qui reste limité à la définition de tâche participatives et communautaires. Par exemple, cette abstraction ne permet pas de définir des tâches suivant l’évolution d’un utilisateur à travers une longue période (par ex. "collecter toutes les 5 minutes la position du GPS"). Et finalement, la dernière limitation réside dans les mécanismes d’extension de Medusa. En effet, pour étendre les fonctionnalités offertes par MedScript, les développeurs ont besoin de développer un nouveau module Java compatible Android. Ce mécanisme a deux inconvénients. Le premier concerne la sécurité. En effet, un développeur mal intentionné peut développer un stage envoyant des SMS à l’insu des participants, ou récupérer des données confidentielles (par ex. contacts) et les envoyer vers un service tiers. Et le deuxième rend exclusive Medusa uniquement pour Android, empêchant de faire face à l’hétérogénie des OS mobiles. 2.3.4 PRISM : Platform for Remote Sensing using Smartphones PRISM [16] est une plate-forme adressant particulièrement trois points qui sont la généralité, la sécurité et le passage à l’échelle. Pour adresser la généralité, PRISM propose une application mobile permettant le téléchargement de tâches de collecte écrites en code natif. Cette approche permet de faciliter la réutilisation de code et de donner une totale flexibilité pour le développement de tâches complexes et variés. Dans ce cadre, PRISM supporte le développement de tâche participatives et opportunistes. Néanmoins, cette approche a plusieurs limitations. Premièrement, le développement de code natif demande une grande expertise en programmation et dans les plate-formes mobiles. PRISM ne fournit pas d’API de 42plus haut pour simplifier leurs développements. Deuxièmement, le développement de code natif ne permet pas de faire face à l’hétérogénéité des OS mobiles. Le code développé reste alors exclusivement exécutable par OS mobile supporté par PRISM, en l’occurrence Windows Mobile. Et finalement, permettre à des développeurs tiers de déployer du code natif sur les dispositifs mobiles peut également poser des problèmes de sécurité et de confidentialité vis-à-vis des participants. Pour limiter les problèmes de sécurité, PRISM implémente un mécanisme d’interposition, empêchant les tâches d’accéder à des fonctions critiques de l’appareil. L’application mobile observe également les ressources énergétique et réseaux consommées par les tâches, et stoppe leurs exécutions si elles dépassent une valeur limite. Cela permet de renforcer la sécurité de l’appareil, en évitant que des tâches épuisent totalement la batterie des utilisateurs. Pour permettre aux utilisateur de contrôler les données collectées durant l’exécution des tâches, PRISM fournit un mécanisme de contrôle d’accès comprenant trois niveaux : i) No Sensors empêchant tous accès, ii) Location Only permettant l’accès uniquement aux capteurs de position et All Sensors autorisant tous les accès. En ce qui concerne le passage à l’échelle du système, PRISM propose une approche permettant de maîtriser le déploiement des tâches de collecte à un sous-ensemble d’utilisateurs. La figure 4 décrit l’architecture globale de PRISM comprenant deux parties spécifiques : i) une application mobile pour Window Mobile, responsable de l’exécution des tâches soumise par le serveur, et ii) le serveur PRISM, acceptant des tâches d’applications tierces pour les déployer auprès des applications mobiles. Dans PRISM, le déploiement des taches de collecte est assuré via approche push-based, c’est-à-dire permettant au serveur de pousser les applications directement vers les dispositifs mobiles. Cette approche a le principal avantage d’assurer un déploiement rapide des applications, sans que les utilisateurs soient obligés de se connecter réguliè- rement sur le serveur pour voir si une nouvelle tâche est disponible. Pour permettre aux développeurs de définir un sous-ensemble de dispositifs pour déployer leurs tâches, PRISM fournit une API comportant deux niveaux de raffinements (cf. listing 2.3). 1 // set up the first level coarse-grained predicate 2 L1pred = new FirstLevelPredicate(); 3 L1pred.location = ; 4 L1pred.radius = ; 5 L1pred.stationary = false; 6 L1pred.cameraPresent = true; 7 L1pred.numOfPhones = ; 43Figure 4 – Architecture de PRISM [16] 8 // set up the second level fine-grained predicate 9 L2pred = new SecondLevelPredicate(); 10 L2pred.location = ; 11 L2pred.radius = ; 12 // set up the application with the predicates 13 PRSIMapp = new PRISMApplication(); 14 PRSIMapp.Init(); 15 PRISMapp.SetPredicates(L1pred, L2pred); 16 PRISMapp.SetBinary(); 17 PRISMapp.DistributeToPhones(); 18 // read and process data sent by phones 19 while (appData = PRISMapp.GetData()) { 20 ; 21 } Listing 2.3 – Exemple d’application développée avec PRISM Le premier niveau permet de spécifier les capteurs nécessaires pour exécuter la tâche, le nombre de mobiles désirés et une vaste région géographique. Le deuxième niveau permet quant à lui de définir contexte plus précis (par ex. lorsque l’utilisateur se déplace, se trouve dans une zone précise). Pour être en mesure de déployer les tâches de collecte, PRISM requiert une connaissance complète des dispositifs mobiles ainsi que leurs mobilités. Cette connaissance est assurée par une phase d’enregistrement assurée par les dispositifs mobiles. Lors de l’enregistrement, les dispositifs mobiles 44reportent deux sortes d’informations comprenant des données statiques (par ex. capteurs disponibles) et des informations dynamiques (par ex. position et niveau de batterie restant). Cependant, cela nécessite que les dispositifs envoient constamment leurs positions pour permettre au serveur d’avoir une vision en temps réel de leur répartition. Cela peut causer par conséquent un trafic réseau important si de nombreux dispositifs sont connectés au serveur, et également négliger la confidentialité des utilisateurs. Lorsqu’une nouvelle tâche est soumise au serveur PRISM, celui-ci compare le premier niveau de raffinement avec tous les dispositifs enregistrés au préalable, et la déploie uniquement aux dispositifs correspondants au premier niveau de raffinement. Le deuxième niveau de raffinement sera ensuite interprété par l’application mobile, qui déclenchera l’exécution de la tâche en fonction des contraintes spécifiées. 2.3.5 Bubble-sensing Bubble-sensing [45] est un système dédié aux déploiements de tâches de collecte participative et communautaire. Ce système focalise principale sur les méthodes de dé- ploiements des tâches de collecte qui doivent être exécutées dans une région spécifique. La figure 5 illustre son architecture. Figure 5 – Architecture de Bubble-sensing [45] Dans le modèle proposé par Bubble-sensing, la création d’une tâche est initiée par le dispositif d’un participant (dispositif A dans la figure 5). Le dispositif joue alors le rôle de bubble anchor, et est responsable de la maintenance de la tâche de collecte dans la zone géographique d’intérêt. Une tâche est définie par un tuple : i) action qui définie 45la tâche à réalisé par les participants (par ex. prendre une photo, une vidéo), région qui définie une zone géographique représentant la bulle où la tâche doit être exécutée, et une durée qui définie la date limite ou l’action doit être réalisé. La tâche est disséminée périodiquement, par des communications à courte distance (par ex. Bluetooth, Wifi direct), jusqu’à ce qu’un autre dispositif mobile reçoive et accepte d’exécuter la tâche en question (dispositif C). Les données collectées sont ensuite envoyées sur le bubble-server. Dans le cas ou l’initiateur de la tâche quitte la zone géographique initialement définie, un message est alors disséminé à tous les autres dispositifs se trouvant à proximité. Dans le cas ou un autre dispositif reçoive le message, il devient alors le bubble anchor (dispositif B) responsable de la maintenance de la tâche dans la bulle. En utilisant cette approche, Bubble-sensing permet d’éviter aux dispositifs de reporter continuellement leur position auprès d’une entité centrale. Cependant, cela implique qu’il y est constamment la présence de participants volontaire pour jouer le rôle de bubble-anchor dans la zone géographique d’intérêt, sinon la tâche de collecte serait alors perdu. 2.3.6 Pogo, a Middleware for Mobile Phone Sensing Pogo [6] est une plate-forme proposée par Brouwers et al., qui a pour objectif d’aider les scientifiques à développer et déployer des tâches de collecte à grande échelle. Trois types d’acteurs sont identifiés dans Pogo. Les participants propriétaires des dispositifs mobiles, les scientifiques et un administrateur. Les participants mobiles exécutent une application mobile dédiée, développée pour Android. En installant l’application mobile, les participants acceptent de partager les ressources de leurs dispositifs pour exécuter des tâches développées par les scientifiques. Les scientifiques, quant à eux, peuvent exécuter une application sur leur ordinateur pour développer de nouvelles tâches et les déployer. Et finalement l’administrateur est responsable d’assigner un ensemble de participants aux scientifiques. Cette assignation est effectuée à partir d’un serveur central, qui garde également une trace de tous les dispositifs et des données qu’ils partagent. Cependant, les auteurs donnent très peu d’informations sur cette phase d’assignation, si elle est manuelle ou automatisée. Une fois un participant assigné à un scientifique, Pogo assure le déploiement des tâches par une approche push-based. Cette approche permet d’assurer un rapide déploiement des mises à jour des tâches, mais implique également un manque de transparence sur les données qui sont 46collectées sur les dispositifs des participants ni avec qui ils les partagent. Nous pensons que ce manque de transparence peut freiner leurs participations, surtout qu’aucun mécanisme d’incitation n’est proposé. Dans Pogo, les tâches de collecte peuvent être développées en JavaScript. Pour simplifier le développement des tâches, Pogo propose une abstraction basée sur le pattern publish-subcribe [21], permettant d’effectuer des communications asynchrone entre entre les scripts et les capteurs. La figure 2.4 illustre un exemple de tâches reportant toutes les minutes les points d’accès WiFi sur les ordinateurs des scientifiques. Comparée aux approches précédentes, l’utilisation du JavaScript comporte de nombreux avantages. Tout d’abord, cela permet de bénéficier de l’expressivité d’un langage générale, permettant ainsi de définir des algorithmes contextuels complexes. Ensuite, l’utilisation du JavaScript permet également de favoriser la réutilisation de code. Et finalement de nombreux projet open sources proposent des moteurs d’exécutions pour l’exécution de code JavaScript sur Android 9 , iOS 10 ou Window Mobile 11, permettant d’assurer la portabilité du code développée vers diverses plate-formes. Cependant, l’abstraction proposée par Pogo ne permet pas d’interagir avec les participants, restant exclusivement réservé à la collecte opportuniste de données. 1 function start(){ 2 3 subscribe(’wifi-scan’, function(msg){ 4 5 publish(msg,’wifi-scan’) 6 7 } , { interval : 60 * 1000 }) } Listing 2.4 – Exemple d’application développée avec Pogo Pogo protège la vie privée des utilisateurs finaux en cachant leur identité aux scientifiques. En outre, les utilisateurs finaux conservent le contrôle de leurs données et sont en mesure de contrôler les capteurs utilisés par l’application. Pogo prend également la consommation d’énergie en considération en coordonnant la transmission des données pour les faire coïncider avec les transmissions d’autres applications. Cela permet d’éviter d’activer les interfaces réseaux constamment qui engendre un grand coût énergétique. 9. Android : https://developer.mozilla.org/enUS/docs/Rhino 10. iOS :https://github.com/phoboslab/JavaScriptCore-iOS 11. https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey 472.3.7 AnonySense : A System for Anonymous Opportunistic Sensing Shin et al. introduisent une plate-forme appelée AnonySense [62], adressant majoritaire les problématiques de confidentialité dans les systèmes de collecte opportuniste. Figure 6 – Architecture de Anonysense [62] 1 ( Expires 1196728453 ) 2 ( Accept (= @WiFi a/b/g ) ) 3 ( Report (LOCATION APLIST) 4 ( Every 60 seconds ) 5 ( In ( (1 1) (2 2) (3 0)))) Listing 2.5 – Exemple d’application développée en AnonyTL Pour la description des tâches de collecte, Anonysense propose sur un langage dédié appelé AnonyTL, inspiré de la syntaxe Lisp. AnonyTL permet de spécifier le comportement d’une tâche en fournissant un ensemble de conditions d’acception, des reports de données, et une date d’expiration. Le listing 2.5 décrit un exemple de tâche exprimée en AnonyTL. Cette tâche peut être acceptée uniquement par des dispositifs connectés à une borne WiFi, et collecte l’ensemble des bornes WiFi voisines ainsi que la position toutes les 60 secondes lorsque l’utilisateur se trouve dans une zone précise. Les auteurs proposent, un nouveau argument, le choix d’un nouveau langage pour fournir une notation plus concise et plus compréhensible. Cependant, cette concision diminue également l’expressivité du langage, et empêche également la réutilisation de code pré-existant. 48Le modèle proposé par Anonysense comporte les éléments suivants : un ensemble de dispositifs mobiles (MN), d’applications tierces (App), une autorité d’enregistrement (RA), un service de distribution de tâches (TS), et un service de rapport (RS) et un service d’anonymisation (AS). Dans ce modèle, un App soumet une tâche à l’autorité d’enregistrement (RA). Le RA vérifie ensuite si la tâche respecte la confidentialité des utilisateurs avant de la transmettre au service de distribution (TS). A intervalles réguliers, les MNs se connectent au TS et téléchargent l’ensemble des tâches disponibles. Les MNs choisissent ensuite les tâches qu’ils veulent accepter. Lorsqu’un rapport est prêt, les MNs l’envoient directement au RS ou au AS selon la sensibilité des données. Si le rapport contient des données sensibles, le rapport est envoyé au AS, dans le cas contraire, il est envoyé directement au RS. 2.4 synthèse et conclusion Dans cette section, nous faisons un bilan des plate-formes décrites dans la section précédente. Le tableau 7 fournit un récapitulatif de ces approches et les positionne par rapport aux défis décris en section 2.2. En ce qui concerne les abstractions proposées pour le développement des tâches de collecte, seulement PRISM [16] supporte à la fois le développement de tâche opportuniste et participative, en permettant le déploiement de code natif directement vers les dispositifs mobiles. Cependant, il ne fournit par d’abstraction particulière permettant de simplifier le développement des tâches de collecte. De plus, le déploiement de code natif reste exclusivement réservé à un système d’exploitation mobile spécifique, dans ce cas Windows Mobile. Pour le déploiement et le recrutement des tâches de collecte, principalement deux approches coexistent. La première est l’approche pull-based, adoptée par Medusa [55] et Anonysense, où les dispositifs sont responsables de télécharger les tâches de collecte auprès du serveur. Le principal avantage de cette approche est qu’elle permet d’assurer un certain degré de transparence, dans le sens où les participants peuvent sélectionner les tâches qu’ils souhaitent exécuter. Cependant, le temps de propagation des tâches peut être relativement long, et demande aux participants de vérifier constamment si une nouvelle tâche est disponible. Pour le recrutement des participants, Anonysense permet 49de sélectionner un sous ensemble de participants basé sur leur position. Pour assurer un temps de propagation rapide malgré l’approche pull-based utilisée, l’application mobile télécharge régulièrement toutes les tâches de collecte disponibles sur le serveur et exécute celles qui correspondent à son contexte. Cependant, cela peut impliquer un coût énergétique important des applications mobiles si de nombreuses tâches sont disponibles sur le serveur et ne correspondent pas au contexte du dispositif. La deuxième est l’approche push-based, adoptée par PRISM [16] et Pogo [6], où au contraire c’est le serveur qui déploie les tâches directement auprès des dispositifs mobiles. Son principal avantage est qu’elle permet un déploiement rapide des tâches de collecte, qui peut être très bénéfique dans le cadre où une rapide mise à jour de l’application doit être effectuée. Cependant, cette approche manque de transparence, dans le sens où les participants n’ont pas conscience des données qui sont collectées sur leur dispositif mobile. Pour le recrutement des utilisateurs, PRISM propose également un modèle basé sur la position des participants. Afin de permettre au système d’identi- fier les participants se situant dans une région spécifique, les applications mobiles ont besoin de reporter continuellement leur position sur le serveur, ce qui peut causer par conséquent un trafic réseau important si de nombreux dispositifs sont connectés au serveur. Finalement, la majorité de ces plate-formes propose une architecture centralisée, composée d’une application serveur pour le déploiement des tâches de collecte et une application mobile responsable de leurs exécutions. Cependant, ce style architectural impose à tous les utilisateurs du système de partager les ressources de l’infrastructure hébergeant la plate-forme, des mécanismes de stockage de données, le modèle financier imposé par le fournisseur de l’infrastructure et également la législation du pays où l’infrastructure est hébergée. Cela impose également les modèles mis en place pour déployer une application vers les terminaux mobiles, des mécanismes pour protéger la vie privée des utilisateurs, de récompense ainsi que la structure des données collectées. Dans ce contexte, nous pensons que ce type d’architecture limite fortement la réutilisation du système dans un contexte d’application non initialement prévu, ainsi que son passage à l’échelle. De plus, l’entité centrale représente un point unique de défaillance, qui, en cas d’attaque, peut compromettre l’ensemble des données collectées. Dans ce chapitre, nous avons présenté une vue d’ensemble du Mobile crowdsensing, ses caractéristiques, ses avantages ainsi que les défis qui doivent être adressés pour le déploiement de campagnes de collecte de données à grande échelle. À cause de ces 50nombreux défis, la mise en place de campagnes de collecte reste encore difficile, et reste réservée à des développeurs experts. Bien que de nombreuses plate-formes ont été proposées dans l’état de l’art pour simplifier le développement et le déploiement des ces campagnes, les solutions proposées restent encore restreintes à un contexte d’application particulier. De plus, la centralisation de leur architecture limite fortement la réutilisation de ces systèmes dans un autre contexte applicatif ainsi que leurs passages à l’échelle. À partir de ce constat, cela nous a mené à proposer APISENSE®, une plateforme répartie pour la conception, le déploiement et l’exécution de campagnes de collecte de données. Plus particulièrement, APISENSE® c’est : 1. Un modèle de programmation facilitant le développement de tâches de collecte participatives et opportunistes 2. Un environnement mobile sécurisé assurant l’exécution des tâches de collecte 3. Une architecture décentralisée permettant d’assurer le passage à l’échelle de la plate-forme 4. Un modèle permettant de configurer une application serveur responsable du déploiement des tâches de collecte, de la persistance ainsi que de l’exploitation des données collectées. Dans le chapitre suivant, nous présentons notre première contribution concernant le modèle de programmation des tâches de collecte ainsi que l’environnement mobile dédié à leur exécution. 51Figure 7 – Tableau comparatif des plate-formes MCS 52Deuxième partie Contributions 533 C O L L E C T E M O B I L E D E D O N N É E S Sommaire 3.1 Introduction 55 3.2 Considérations et objectifs de conception 57 3.3 Langage de programmation des collectes 59 3.3.1 Concept de l’interface de programmation 60 3.3.2 Collecte de données dirigée par les évènements 60 3.3.3 Les actions 64 3.4 Intergiciel de collecte 68 3.4.1 Couche d’exécution 68 3.4.2 Couche de contrôle 72 3.4.3 Couche d’interaction 74 3.5 Évaluation du prototype 78 3.5.1 Quelques exemples de collectes 79 3.5.2 Coût énergétique d’une expérience de collecte 87 3.6 Conclusion 88 3.1 introduction Le Mobile Crowd Sensing (MCS) est un mode de collecte de données qui a récemment été défini comme :" la participation d’un groupe d’individus, disposant de terminaux mobiles intelligents, qui collectivement, partagent des informations pour la mesure ou la cartographie de phénomènes d’un intérêt commun." [27]. Ces dernières années, le MCS a suscité l’intérêt d’un grand nombre d’acteurs académiques, dans des domaines tels que l’étude de la mobilité urbaine, la surveillance de l’environnement, la santé ou l’étude des comportements sociaux [9]. Cependant, le développement de ces applications reste une tâche complexe. En effet, ces applications ont besoin de faire face à de nombreuses propriétés non fonctionnelles telles que les ressources énergétiques limitées des dispositifs mobiles, le respect de 55la confidentialité des utilisateurs mobiles, ou encore le coût du recrutement d’un nombre important d’utilisateurs. À cause de cette complexité, il peut être très difficile pour de nombreuses acteurs de développer leurs applications capables de récolter la masse de données nécessaires pour leurs études. Ces dernières années, de nombreuses communautés scientifiques, utilisant le MCS dans leur processus expérimental, ont beaucoup discuté des bénéfices que pourrait apporter un système facilitant ce mode d’acquisition de données [27, 60, 66, 68]. Dans ce contexte, nous proposons dans cette thèse APISENSE®, une plate-forme visant de nombreux acteurs privés, publics ou académiques, leurs permettant de facilement développer et déployer des applications de collecte de données à travers des utilisateurs mobiles. Dans le chapitre section 1.4, page 13 , nous avons présenté une vue d’ensemble d’APISENSE®. Nous rappelons brièvement que le système est composé de trois entités logicielles i) un serveur central responsable du déploiement de tâches de collecte, ii) des nœuds de collecte dédiés aux utilisateurs, responsable du déploiement des tâches de collecte vers le serveur central et la persistance des données collectées, et finalement iii) un agent mobile, dédié aux participants (c.-à-d. utilisateur mobile) responsables de l’exécution des tâches de collecte. Dans ce chapitre, nous présentons notre première contribution qui consiste à proposer un modèle de programmation visant à minimiser l’expertise nécessaire liée aux développements d’applications de collecte, et la conception d’un environnement d’exécution mobile dédié à aux applications développées par notre interface de programmation. structure du chapitre La suite du chapitre est organisée comme suit : dans la section 3.2, nous faisons un bref rappel des problématiques et des solutions proposées dans l’état de l’art, et identifions les considérations prises en comptes pour la conception de notre solution. Nous présentons par la suite en section 3.3 une vue d’ensemble de l’interface de programmation proposée pour le développement des tâches de collecte. En section 3.4, nous présentons l’architecture du substrat d’exécution dédié à l’exécution des tâches de collecte. Nous présentons en section 3.5 l’évaluation d’un prototype réalisé sur Android, avant de conclure en section 3.6. 563.2 considérations et objectifs de conception Afin d’avoir une large applicabilité, permettant de définir une grande variété de tâches de collecte, nous devons proposer un modèle de programmation qui demande de prendre en considération principalement les trois points suivants : Diversité des tâches de collecte : Une tâche de collecte consiste à définir quel est le type de données (par ex. position, image), quand le processus de collecte doit être effectué (par ex. toutes les 5 minutes, lorsqu’un événement spécifique apparait) et comment une donnée doit être capturée. En ce qui concerne le comment, typiquement deux méthodes peuvent être utilisées. La première demande une interaction avec l’utilisateur (appelée collecte participative [7]), en lui demandant de répondre à un questionnaire ou prendre une photo par exemple. La deuxième s’effectue de manière autonome (appelée collecte opportuniste [39]), en interagissant directement avec les capteurs mobiles embarqués dans les terminaux mobiles. Diversité des traitements locaux : Pour la définition d’une tâche de collecte, quatre préoccupations doivent être prises en considérations : i) la limitation des ressources énergétiques, ii) la quantité des données générées et propagées vers le serveur, iii) la qualité des données et finalement iv) la confidentialité des participants. Prendre en compte ces considérations demande généralement de faire des compromis entre elles, en effectuant un traitement local avant de propager les données vers le serveur. L’objectif de ces traitements est de diminuer les données à propager sur le serveur, en remontant uniquement les données essentielles pour l’expérience, économisant ainsi la batterie de l’utilisateur par la réduction de communications réseau. Ces traitements peuvent consister à filtrer les données aberrantes, inférer une information contextuelle de haut niveau à partir de données brutes (par ex. mode de transport), ou encore alterner l’utilisation des capteurs en fonction de leurs consommations énergétiques (par ex. GPS vs géolocalisation GSM). Diversité des plate-formes mobiles : D’autre part, permettre le déploiement des tâches de collecte vers un grand nombre de participants demande également de prendre en compte la diversité des plate-formes mobiles disponibles. Ceci amène généralement à étudier et réaliser une application mobile spécifique pour chacune d’entre elles. Cette diversité a été soulignée par l’expérience menée par Balan et coll. [4], qui ont mis plus 57de six mois pour le développement et le déploiement d’une expérience de collecte à travers 15,000 taxis à Singapour. En tant que plate-forme de collecte de données, APISENSE® a deux publics distincts : i) les utilisateurs qui veulent définir de nouvelles campagnes de collecte de données, ii) les participants qui exécuteront ces tâches de collecte sur leur dispositif mobile. Dans ce contexte, à partir des considérations décrites ci-dessus et de ces deux publics distincts évoluant dans APISENSE®, nous identifions les objectifs de conception suivants : Objectif de conception pour les utilisateurs : Afin de minimiser le niveau d’expertise nécessaire liée aux développements des applications de collecte, il est nécessaire de fournir une abstraction facilitant leurs développements. Dans ce contexte, l’objectif est de proposer un langage de programmation reposant sur trois propriétés : 1. la généralité : pour supporter une grande variété d’activités de collecte (c.-à-d. participative et/ou opportuniste), qui peuvent également impliquer une grande variété de capteurs. 2. l’accessibilité : permettant de minimiser l’expertise nécessaire dans les technologies mobiles afin d’accéder aux fonctionnalités offertes par les capteurs des terminaux mobiles, ainsi que leurs collectes et leurs propagations vers l’infrastructure serveur. 3. la portabilité : afin d’éviter de devoir définir plusieurs tâches de collecte pour différentes plate-formes mobiles, l’abstraction proposée doit être en mesure de s’exécuter sur ces différentes plate-formes. Objectif de conception pour les participants : Inévitablement, les participants mobiles jouent un rôle central dans le processus de collecte. Afin de favoriser leurs participations, nous pensons que la confiance et la transparence doivent être un aspect fondamental du système. Cela nécessite que les utilisateurs mobiles aient connaissance des données qui sont collectées sur leurs terminaux, avec qui ils les partagent et dans quel but. D’autre part, favoriser l’acceptabilité des utilisateurs demande de fournir un substrat d’exécution permettant de : 1. Contrôler la confidentialité : en laissant la possibilité aux utilisateurs de choisir les données qui sont partagées, les capteurs qui peuvent être utilisés par les 58applications de collecte, et dans quelle circonstance les données peuvent être partagées. 2. Minimiser l’impact énergétique : lié à l’exécution d’une application de collecte, pour ne pas empêcher une utilisation normale du dispositif. Notamment si de multiples applications doivent être exécutées sur un seul dispositif. 3. Récompense adaptée : pour favoriser la participation des utilisateurs mobiles, en rendant ludique le but de la collecte de données, ou en récompensant les utilisateurs financièrement selon la nature des données collectées. 3.3 langage de programmation des collectes Pour le développement des tâches de collecte, nous avons opté pour le langage de script JavaScript. Le choix du JavaScript est motivé principalement pour trois raisons. Premièrement, JavaScript est un langage accessible et populaire, bénéficiant de l’expressivité d’un langage générale. Cela donne aux utilisateurs une grande liberté pour définir des traitements complexes, intégrer des libraires déjà existantes de traitement de données (par ex. clustering) pour inférer des données de haut niveau directement dans le dispositif mobile. Ensuite, JavaScript est facilement transportable et exécutable sur de nombreuses plateformes mobiles, permettant un rapide déploiement et une rapide propagation des mis à jour de la tâche de collecte. Et finalement, d’un point de vue plus technique, JavaScript est nativement exécuté dans un bac à sable (sandbox en anglais), facilitant le contrôle des fonctionnalités des dispositifs mobiles accessibles par les scripts. Pour faciliter le développement des tâches de collecte, nous proposons une interface de programmation (API) dédiée à la collecte de données, au-dessus de JavaScript. Le principal objectif de l’API est de fournir une abstraction complète des technologies mobiles, permettant le développement d’application de collecte de données, sans avoir une expertise particulière dans ces technologies. Dans APISENSE, une tâche de collecte est spécifiée par un ou plusieurs scripts JavaScript, qui peuvent être déployés et exécutés sur les dispositifs mobiles des participants. Dans la suite de cette section, nous présentons une vue d’ensemble de l’API proposée. 593.3.1 Concept de l’interface de programmation Comme le montre la figure 8, notre API consiste en un ensemble de variables pré- définies, appelée façades, définissant l’ensemble des fonctionnalités accessibles par les scripts. Plus précisément, une façade permet d’interagir avec les ressources d’un dispositif, et est implémentée dans le langage natif de la plate-forme d’exécution. Ces ressources peuvent être par exemple des capteurs physiques (par ex. température, GPS), des capteurs logiciels (par ex. appel téléphonique, installation d’une application) ou encore l’interface graphique du dispositif mobile. Dans notre API, chaque façade proposée fait référence à une ressource spécifique, et délimite un sous-ensemble de fonctionnalités fourni par celle-ci. Ce procédé permet ainsi d’empêcher l’utilisation complète des fonctionnalités des dispositifs mobiles, pour des raisons de sécurité et de confidentialité vis-à-vis du participant. Par exemple, cela permet de crypter toutes les informations sensibles (par ex. contacts, numéro de téléphone, etc.), d’empêcher l’installation de nouvelles applications ou encore de faire des appels téléphoniques. Également pour des raisons de confidentialité, nous laissons la possibilité aux participants de contrôler les façades accessibles par les scripts de collecte. Par exemple, un participant peut à tout moment enlever la possibilité à un script de déterminer sa position, ou d’être notifié lorsqu’il reçoit des SMS. La communication entre les scripts et les façades peut s’effectuer de deux manières différentes. La première, de manière asynchrone, permet aux scripts d’être notifiés du changement des états des capteurs des dispositifs mobiles. La deuxième, de manière synchrone, permet aux scripts de collecte d’effectuer une action spécifique, ou alors de lire directement le dernier état d’un capteur. 3.3.2 Collecte de données dirigée par les évènements L’écoute des évènements permet de déclencher une action ou un traitement en fonction du contexte de l’utilisateur mobile. Par exemple, la collecte de données peut être déclenchée uniquement lorsque l’utilisateur est en situation de mobilité. L’observation du contexte consiste principalement à observer le changement d’état d’un capteur interne du dispositif. Pour interagir avec les capteurs, les façades proposent un ensemble de fonctions permettant aux scripts d’être notifiés de ce changement d’état. Le tableau 1 montre quelques exemples de façade et des fonctions associées dédiées à l’observation d’un événement particulier. L’observation consiste donc à souscrire une 60Figure 8 – Interface de Programmation APISENSE Façade Fonction Description $location onLocationChange Observation du changement de position $battery onBatteryStateChange Observation de l’état de la batterie $acc onAccelerometerChange Observation de l’accélération $phone onPhoneCall Observation des appels téléphonique Table 1 – Liste des fonctions d’observation d’événements prédéfinis. Paramètre Type Description configuration JSONObject Configuration de l’observation de l’état du capteur callback function(event,subscription) Fonction de rappel condition (optionnel) String Condition logique Table 2 – Liste des paramètres d’une fonction de rappel 61fonction de rappel, à une façade responsable du capteur capable de générer l’événement voulu. La souscription comprend trois paramètres, permettant la configuration du capteur, la fonction de rappel et une expression logique permettant de raffiner l’observation des événements, et retourne un objet de type Subscriber. configuration Le premier paramètre configuration laisse la possibilité de configurer l’observation du capteur en question. La configuration peut être utilisée afin de faire un compromis en qualité des données transmises par les capteurs (c.-à-d. fréquence d’échantillonnage, précision) et l’énergie consommée liée à l’observation du capteur. Un exemple classique est l’observation du changement de la position d’un utilisateur. Généralement, ce compromis peut être effectué en alternant le type de capteur utilisé — entre le GPS fournissant une grande précision, mais consommant beaucoup d’énergie, et le réseau qui au contraire consomme moins d’énergie, mais fournit une localisation moins précise —, ou la fréquence d’échantillonnage. Le tableau 2 illustre les configurations du capteur de position possibles. Fonction Description period Période d’échantillonnage de la position provider Capteur de position utilisé : gps ou network Table 3 – Configuration de l’observation de la position d’un utilisateur fonction de rappel Le deuxième paramètre permet d’enregistrer une fonction qui sera exécutée lors du changement d’état du capteur observé. Par exemple, le listing suivant montre la syntaxe permettant à un script de collecte d’être notifié lorsque l’utilisateur est en situation de mobilité : $location.onLocationChanged({provider : ["gps"]},function(event){ // code exécuté lorsque une nouvelle position est détectée }) Chaque événement est défini par un ensemble d’attributs, sérialisés par un ensemble de clés/valeurs utilisant le formalisme JSON. Chaque événement est au minimum défini par un nom, et la date de sa production. Le listing suivant illustre un exemple d’événement produit lorsqu’une nouvelle position de l’utilisateur est détectée : 62{ event : "location", time : 18005010510, latitude : 50.65, longitude : 2.11, accuracy : 100, speed : 3 } Dans cet exemple, l’événement est défini par cinq attributs indiquant la position de l’utilisateur (c.-à-d.latitude, longitude), la précision de la position (c.-à-d.accuracy) et la vitesse de l’utilisateur (c.-à-d.speed). condition logique Optionnellement, l’écoute d’événement peut être raffinée en insérant une condition lors de la souscription. La condition se définit par un opérateur appliqué à un attribut appartenant à l’événement et à une valeur. Plusieurs conditions peuvent être exprimées en ajoutant des opérateurs logiques de type et, ou ou non. (cf. listing 3.1). Le listing suivant illustre un exemple utilisant une expression logique, implémentant une solution naïve pour déterminer si l’utilisateur est en train de marcher : $location.onLocationChanged({provider : ["gps"]},function(event){ // code exécuté lorsque l’utilisateur marche }," &((speed > 3),(speed < 5)) ") Dans cet exemple, nous observons donc le changement de position, et nous définissons que la fonction de rappel doit être exécutée uniquement si l’utilisateur se déplace à une vitesse comprise entre trois et cinq Kilomètres/h. 1 expression ::= key’(’[condition+]’)’ | condition 2 condition ::= eventAttribute operator value 3 key ::= ( "!" | "&" | "|" ) 4 operator ::= ( "<" | "==" | ">" | "<=" | ">=" ) 5 eventName ::= alpha* 6 eventAttribute ::= alpha* 7 value ::= alphanumeric* Listing 3.1 – Grammaire BNF d’une expression logique objet de souscription Pour maintenir un lien entre la souscription et le script, un objet de type Subscriber (cf. table 4) est retourné lors de l’enregistrement. L’objet de souscription permet d’annuler la souscription à un événement particulier 63(fonction suspend), permettant d’éteindre un capteur actif afin de conserver l’énergie du dispositif mobile. La méthode resume permet de reprendre une souscription qui a été annulée. Fonction Description suspend Suppression de l’observation resume Redémarrage de la souscription Table 4 – Liste des fonctions d’un objet de souscription 3.3.3 Les actions En plus de l’observation des événements, les façades fournissent également des fonctions permettant d’exécuter des actions spécifiques. Dans la suite de cette soussection, nous présentons les principales actions prédéfinies par notre API qui sont la collecte et la propagation de données, l’interaction avec l’utilisateur mobile ou encore définir des informations pouvant être fournies en retour aux utilisateurs sur les données collectées. Collecte et propagation des données La collecte de données est effectuée à l’aide de la façade dédiée $trace. Cette façade possède trois fonctions comme le montre le tableau 5. La première permet de sauvegarder une donnée dans la base de données locale du terminal mobile (méthode add). Les données sont sous la forme d’un objet JSON, n’imposant aucune structure de données particulière pour représenter les données collectées. Cela laisse ainsi une grande flexibilité aux utilisateurs de définir leurs propres structures. Additionellement, les utilisateurs peuvent ajouter des méta-informations (méthode addHeader), permettant de diminuer la collecte de données redondantes, et leurs agrégations une fois propagées vers le serveur. Ces méta-informations représentent généralement des données statiques, c’est à dire qui n’évoluent pas dans le temps. L’API permet également de définir la stratégie pour propager les données vers les nœuds de collecte grâce à la méthode send. Lors de l’appel à cette fonction, la façade propagera les données sauvegardées dans la base de données locale si une connexion est disponible, sinon les données seront propagées une fois la connexion retrouvée. Dans le cas où aucune stratégie n’est définie, les données seront propagées automatiquement une fois que le 64dispositif est branché sur secteur et possède une connexion réseau. Cela permet de diminuer la consommation énergétique des dispositifs des participants. Fonction Description add(data) Collecter une donnée addHeader(key,value) Collecter une donnée statique send() Propagation des données collectées Table 5 – Liste des fonctions de la façade de collecte Interaction avec l’utilisateur Collecter des données de façon transparente peut ne pas être suffisant dans certains cas. En effet, certaines informations comme la satisfaction d’un utilisateur ou ses intentions sont difficilement perceptibles à partir de donnée brute. Prenons par exemple une collecte de donnée visant à observer la qualité du signal réseau d’un utilisateur mobile. Il peut être intéressant de voir comment la qualité du signal réseau influe sur la qualité de la communication vocale. Cependant, cette information peut être très difficilement inférée à partir des données brutes issues des capteurs. Dans ce contexte, une solution possible est de proposer des questionnaires d’évaluation aux utilisateurs. Ce type de collecte est également appelé collecte participative. Pour supporter la collecte participative, notre API dispose d’une façade permettant la création et la publication de questionnaire aux utilisateurs mobiles. Le tableau 6 illustre les principales fonctions fournies par cette façade. La création d’un nouveau questionnaire s’effectue à partir de la fonction create de la façade $survey. La fonction retourne un objet de type Survey, disposant d’un ensemble de fonctions permettant d’insérer des questions ouvertes (par ex. zone de texte), de question fermée (par ex. case à cocher), ainsi que des captures multimédias (c.-à-d. photo, vidéo, audio). La fonction then permet de modifier la séquence des questions proposée à l’utilisateur, qui est par défaut dans l’ordre de leurs créations. Cela permet par exemple de proposer des questions différentes selon les premières réponses données par l’utilisateur. Nous illustrerons un exemple de création de questionnaire dans la sous-section 3.5.1 . 65Facade $survey Return Fonction Description Survey create Création d’un nouveau questionnaire void publish(survey,callback) Publication du questionnaire Type Survey void close(label,question,responses) Création d’une question fermée void open(label,question) Création d’une question ouverte void image(label,format) Capture photo void audio(label,format) Capture audio void video(label,format) Capture vidéo void then(label,callback) Spécification de la prochaine fonction Table 6 – Liste des fonctions de la façade dédiée à la création des questionnaires Retour utilisateur Afin de favoriser leurs participations des utilisateurs, et surtout maintenir les utilisateurs dans la durée, nous avons intégré à notre API la possibilité d’effectuer facilement des retours visuels sur les données collectées par l’utilisateur mobile. Ces retours visuels peuvent être directement développés utilisant le couple JavaScript/HTML, fournissant une grande flexibilité pour concevoir des retours selon la nature de collecte de données. Pour simplifier leurs développements, nous proposons des modules complémentaires qui peuvent être inclus dans la tâche de collecte lors de son déploiement, ou téléchargés dynamiquement lors de l’exécution du script. Actuellement nous proposons deux modules génériques permettant de créer automatiquement des graphes ou des cartes géographiques à partir des données collectées. Par exemple, le listing 3.2 décrit un exemple l’utilisation d’un module facilitant la génération de graphe. Dans cet exemple, les trois premières permettent de charger le module (ligne 1), créer un nouveau graphique (ligne 2) et rendre disponible le graphique pour les utilisateurs (ligne 3). Les lignes suivantes permettent d’observer les évènements relatifs aux changements de la force du signal GSM (ligne 7), et d’ajouter une nouvelle valeur au graphique lorsqu’un nouvel évènement est détecté (ligne 9). La figure 9 montre une capture d’écran du rendu graphique de cet exemple. 66// signal strenght chart configuration var chartLib = require("lib-chart.js") chart = chartLib.area({name : "GSM Signal Strength Chart"}); chart.publish(); // telephony sensor monitoring initialization $telephony.onSignalStrengthChanged(function(event){ chart.add({ x : event.time, event.level }); }); Listing 3.2 – Exemple de retour utilisateur Figure 9 – Exemple de capture d’écran d’un retour utilisateur Dans cette section, nous avons présenté une vue d’ensemble de notre API, dédié aux développements des tâches de collectes de notre système. Une documentation plus détaillée est également disponible le site internet dédié à APISENSE 1 . Dans la 1. http://apisense.io 67section suivante, nous présentons les concepts et l’architecture de l’intergiciel dédié à l’exécution de l’interface de programmation présentée dans cette section. 3.4 intergiciel de collecte Dans la première section de ce chapitre, nous avons présenté une interface de programmation dédiée aux développements de tâche de collecte en environnement mobile. Dans cette section, nous présentons en détail l’architecture de l’intergiciel responsable de l’exécution des tâches de collecte. D’un point de vue utilisateur, l’intergiciel se dé- cline sous la forme d’une application mobile, qui peut être téléchargée et installée afin de participer aux expériences de collecte de données. Dans ce cadre, l’application peut être perçue comme un conteneur générique de tâches de collecte, capable d’interagir avec les différents serveurs pour la propagation des données collectées (vers les nœuds de collecte), le téléchargement des tâches de collecte (auprès du serveur central) ainsi que leurs exécutions. La figure 10 illustre une vue d’ensemble de l’architecture de l’intergiciel se déclinant en trois couches. Dans la suite de cette section, nous présentons en détails chacune de ces couches dédiées à : i) l’exécution des tâches de collecte (cf. sous-section 3.4.1), au contrôle des ressources du dispositif mobile (cf. sous-section 3.4.2), et iii) aux interactions avec les différentes entités logicielles d’APISENSE® (cf. sous-section 3.4.3). 3.4.1 Couche d’exécution Nous présentons ici la couche responsable de l’exécution des tâches de collecte développées avec l’interface de programmation que nous avons présentée dans la section précédente. La première couche de l’architecture présentée est responsable de l’exécution des tâches de collecte. La Figure 11 illustre plus en détail les différents modules et les interactions nécessaires à l’exécution des tâches de collecte. Le point d’entrée de cette couche est le Script Manager, qui est responsable de créer ou détruire une instance d’exécution d’une tâche de collecte, selon l’ordre envoyé par le Privacy Manager. Dans ce contexte, l’objectif clé est de fournir un environnement d’exécution sécurisé, permettant également aux participants de contrôler les données qu’ils partagent pour des raisons de confidentialité. Cependant, généralement tous les accès aux données brutes des capteurs peuvent constituer une menace pour la 68Figure 10 – Architecture de l’intergiciel mobile Figure 11 – Interaction de la couche d’exécution 69vie privée des participants. Par exemple, l’accès au microphone peut être utilisé pour enregistrer une conversation téléphonique souhaitant rester privée. L’accès continu au GPS peut permettre à un utilisateur anonyme d’être identifié juste en couplant des informations géographiques et temporelles [26]. Néanmoins, ce risque reste inhérent dans le domaine de la collecte de données. En effet, si nous voulons une protection parfaite, tous les accès aux capteurs devraient être bloqués. Pour mitiger ces risques, nous laissons la possibilité aux participants de contrôler les capteurs accessibles par les tâches de collecte (cf. 3.4.2). Pour la gestion de ce contrôle d’accès, chaque instance d’exécution d’une tâche de collecte est exécutée dans un bac à sable dédié (sandbox en anglais), permettant d’intercepter tous les appels entre les tâches de collecte et les capteurs du dispositif. Ainsi, toutes les fonctionnalités de l’interface de programmation sont fournies par un ensemble de façades (cf. sous-section 3.3.1), représentant également le point d’extension de notre l’architecture. Une façade est un objet, écrit en code natif de la plate-forme mobile, permettant l’interaction entre les tâches de collecte et l’environnement mobile. Le listing 3.3 montre l’exemple d’un squelette d’implémentation sous Android, de la façade permettant d’accéder aux capteurs de localisation. Dans cette façade, la fonction getReferenceName retourne le nom de la variable qui est utilisée pour accéder aux fonctions fournies par la façade. Chaque fonction annotée par une annotation @ScriptMethod, indique au moteur de script que la fonction est accessible par les tâches de collecte. Si nous reprenons l’exemple illustré dans la section précédente (cf. sous-section 3.3), la fonctionnalité $location.onLocationChanged accessible par la tâche de collecte, est implémentée par la façade LocationFacade, injectée en tant que variable $location et implémentant la fonction onLocationChanged. 1 public class LocationFacade extends AbstractAndroidFacade{ 2 3 public String getReferenceName() {return "location";} 4 5 public String getSensorDescription(){ ... 6 7 @ScriptMethod 8 public ISubscriber onLocationChanged( 9 JSONObject params,IScriptFunction callback,String... filters){ 10 // subscribe to location sensor update 11 return ... 12 } 13 14 public void shutdown() { ... // clean sensor subscription } 15 } 70Listing 3.3 – Squelette de l’implémentation d’une façade sur Android Lors de la création d’une nouvelle instance d’exécution, le Script Manager effectue une requête au Privacy Manager pour lister l’ensemble des capteurs admis par le participant. Le Script Manager injectera alors seulement les façades correspondantes aux capteurs qui auront été admis par le participant. Dans ce cadre, les façades correspondant aux capteurs non autorisés ne seront pas injectées, empêchant les scripts de bénéficier des fonctionnalités du capteur en question. Réguler l’accès aux capteurs Pour interagir avec les capteurs du dispositif mobile, les façades doivent interagir avec le Sensor Controller. Son objectif est principalement de réguler l’accès aux capteurs du dispositif et de filtrer les données sensibles. Par exemple, lorsqu’une façade demande l’accès à des informations de type SMS ou numéro de téléphone, les données retournées par la couche de contrôle seront automatiquement cryptées pour protéger la vie privée des participants. Deux types de communications peuvent être effectuées avec le Sensor Controller, des communications de type asynchrone permettant la lecture continuelle de l’état d’un capteur et de type synchrone afin de lire directement l’état d’un capteur. Pour économiser la batterie du dispositif mobile, le Sensor Controller dispose de deux mécanismes. Le premier est un mécanisme de cache, dédié aux communications synchrones. Ce mécanisme permet principalement de limiter une lecture excessive de l’état d’un capteur. Ce mécanisme consiste principalement à définir une fenêtre temporelle dans laquelle seront insérées toutes les données récupérées par le Sensor Controller via les APIs des systèmes mobiles, donnant accès aux données fournis par les capteurs physiques. Avant de procéder à un nouvel accès aux capteurs, la couche de contrôle vérifiera dans un premier temps si la donnée demandée est disponible dans la fenêtre temporelle. Si elle est disponible, la valeur du cache sera alors renvoyée. Le deuxième mécanisme mis en place tente de minimiser le nombre de souscriptions effectuées aux capteurs des dispositifs. Typiquement, un script peut être notifié du changement d’état d’un capteur en enregistrant à une façade une fonction de rappel, une expression logique permettant de filtrer les états ainsi qu’une période indiquant la fréquence des mises à jour des données. Dans le cas où plusieurs scripts procèdent 71à la souscription d’un même capteur avec une période différente, le Sensor Controller effectuera seulement une souscription aux capteurs correspondants, avec une période correspondante à la plus petite période des deux souscriptions. Prenons le cas par exemple où deux scripts effectuent une souscription au capteur GPS avec les périodes respectives de 10 et 20 secondes. Dans ce cas, le Sensor Controller effectuera une seule souscription au capteur GPS avec une fréquence d’échantillonnage égale à 10 secondes, et notifiera les deux scripts toutes les 10 secondes de la nouvelle position. 3.4.2 Couche de contrôle Cette couche est responsable du contrôle de l’exécution des scripts de collecte. Le contrôle consiste à automatiquement démarrer ou arrêter un script de collecte, à partir d’un ensemble de contraintes contextuelles définies par les participants et les expé- riences. Ces contraintes peuvent par exemple permettre aux participants d’empêcher l’exécution d’un script en dehors de la période allant de 9 heures et 18 heures ou lorsque le participant est en dehors d’une zone géographique. Un autre scénario envisagé est d’empêcher l’exécution d’un script si le niveau de la batterie est inférieur à 30 %. Ces contraintes peuvent être classifiées en quatre catégories : contrainte temporelle, contrainte géographique, contrainte de ressource et contrainte de capteur. Ces contraintes sont respectivement interprétées par les modules TimeConstraint, ZoneContraint, ResourceConstraint et SensorConstraint. Contrainte temporelle Ces contraintes, interprétées par le module Time Constraint, permettent de spécifier différentes périodes de la journée durant lesquelles les expériences ont l’autorisation d’être exécutées. Ces contraintes sont modélisées comme un ensemble de périodes où chaque période est définie par un temps de départ et un temps de fin. Pour une expérience donnée, la contrainte temporelle est vérifiée si, à instant t, t appartient au moins à une période définie par le participant et à une période définie par le contexte d’exécution de l’expérience. La surveillance contextuelle des contraintes temporelle consiste à surveiller l’horloge interne du dispositif mobile. Pour chaque contrainte définie, ce module programme une alarme, demandant au système d’être notifié au début et à la fin de la période définissant la contrainte. 72Contrainte géographique Interprétées par le module Zone Constraint, les contraintes géographiques permettent de spécifier un ensemble de lieux ou de régions, dans lesquelles les scripts peuvent être exécutés selon la position du participant. Une contrainte géographique est modélisée par un ensemble de régions circulaires en terme de latitude, longitude et un rayon en kilomètre. Pour une expérience donnée, la contrainte géographique est vérifiée si à une position p donnée, p est inclus au moins dans une zone définie par le participant ou par le contexte d’exécution de l’expérience. En ce qui concerne la surveillance contextuelle, surveiller activement la position de l’utilisateur peut engendrer une grande consommation énergétique du dispositif. Pour diminuer cette consommation énergétique, nous utilisons un algorithme fréquemment utilisé [3, 8] dans la littérature. Typiquement, l’idée principale est i) d’utiliser alternativement les différents mécanismes permettant de déterminer la position d’un utilisateur — entre le GPS fournissant une grande précision, mais consommant beaucoup d’énergie, et le réseau qui au contraire consomme moins d’énergie, mais est beaucoup moins précis —, ii) et la fréquence d’échantillonnage en fonction de la distance de l’utilisateur et la zone la plus proche de sa position actuelle. Contrainte de ressource Ces contraintes permettent de limiter les ressources consommées par l’application. Le participant peut par exemple définir un seuil de batterie pour stopper l’exécution de toutes les expériences de collecte pour éviter un épuisement complet de sa batterie. Une autre ressource qui peut être contrôlée est la quantité de données échangées via une connexion de données mobiles qui peut induire un coût monétaire pour le participant. Dans ce cadre, le participant peut définir un seuil maximum de données transmises lorsqu’une connexion est utilisée. Contrainte de capteur Ces contraintes permettent de spécifier les fonctionnalités permises par les scripts de collecte. Dans l’interface de programmation proposée pour définir une expérience de collecte, nous avons vu que les fonctionnalités accessibles par les scripts se font par l’intermédiaire de façades. Pour chaque façade, le participant a la possibilité de définir s’il autorise l’accès à l’ensemble des fonctionnalités proposées par la façade. Par exemple, le participant peut enlever l’autorisation de la façade $sms, qui supprimera la possibilité de recueillir des informations relatives aux SMS envoyés et lus. 73Dans l’architecture présentée précédemment en figure 10, les modules TimeConstraint, ZoneConstraint et RessourceConstraint ont pour rôle de surveiller le contexte du dispositif (e.g. horloge interne, position, niveau de batterie) et d’envoyer un message au Privacy Manager afin de notifier un changement de contexte du dispositif mobile. Lors de la notification, le Privacy Manager vérifie pour chaque expérience si les contraintes spécifiées par le participant et par l’expérience sont respectées. Dans ce cas, le Privacy Manager interprètera les contraintes de capteurs définies par le module Sensor Constraint pour générer une nouvelle instance d’exécution ou stopper l’exécution d’une expérience de collecte. 3.4.3 Couche d’interaction La dernière couche présenté dans cette section représente la couche de plus haut niveau de l’intergiciel. Cette couche est principalement responsable des interactions entre le dispositif mobile avec les différentes entités logicielles de notre architecture et le participant. Typiquement, cinq types d’interactions sont nécessaires au déroulement des expériences de collecte : i) l’enregistrement auprès du serveur central, ii) la souscription à une expérience de collecte, iii) la mise à jour des expériences, iv) l’interaction avec les participants et finalement v) la propagation des données collectées. Dans la suite de cette sous-section, nous présentons ces interactions et les modules responsables de leurs fonctionnements. Souscription du dispositif Le processus d’enregistrement, géré par le Profile Manager, permet d’informer le serveur central de la disponibilité d’un nouveau périphérique mobile pour l’exécution de nouvelles tâches de collecte. Typiquement, cette phase d’enregistrement consiste à fournir des informations générales du dispositif et du participant, permettant de proposer des expériences de collecte adéquates. Dans ce contexte, deux sortes d’informations sont principalement échangées. Les premières sont des informations relatives au dispositif mobile incluant le type du dispositif (par ex. smartphone, tablette), son système d’exploitation (par ex. Android, iOS), ses performances ainsi que les capteurs embarqués (par ex. température, GPS). Pour raffiner la proposition des expériences, les participants ont la possibilité de compléter ces informations volontairement en indiquant les différents lieux de vie dans lequel ils évoluent (par ex. maison, travail) son statut (par ex. professionnel) ainsi que son âge.Toutes les informations transmises 74Figure 12 – Règles de confidentialité resteront confidentielles, c’est-à-dire qu’elles ne seront pas directement accessibles par les nœuds de collecte du système. Ces informations seront utilisées uniquement par le serveur central lors de la phase du déploiement des expériences de collecte. D’autre part, afin de protéger la vie privée des participants, le Profile Manager permet aux participants de définir certaines règles de confidentialités (cf. figure 12). Principalement trois catégories de règles peuvent être définies. Les deux premières permettent de spécifier des zones géographiques et temporelles, indiquant à l’agent mobile une interdiction d’exécuter des tâches de collecte. La dernière catégorie permet de spécifier des règles d’autorisations, permettant d’empêcher l’activation des capteurs ou l’accès aux données brutes du capteur si l’utilisateur ne veut pas partager une information. Nous aborderons plus en détails ce point dans la sous-section suivante (cf. sous-section 3.4.2). Souscription à une expérience Une fois le dispositif enregistré, les participants ont la possibilité de lister (via le ExperimentManager), un sous ensemble d’expériences de collecte proposées par les utilisateurs. Les expériences sont retournées en fonction des informations fournies lors de la phase d’enregistrement. Chaque expérience est définie tout d’abord par un nom ainsi qu’une brève description indiquant l’objectif de la collecte de données. La description d’une expérience est également caractérisée par un contexte d’exécution définissant quand l’expérience doit être exécutée. Le contexte d’exécution est défini 75selon une dimension géographique (par ex. à l’intérieur d’une zone) et une dimension temporelle (par ex. période dans la journée). D’autre part, des informations relatives aux capteurs utilisés sont fournies pour indiquer aux participants quels sont les types de données qui peuvent être collectées sur leurs dispositifs. À partir de l’ensemble des descriptions disponibles, le participant a la possibilité de soumettre une souscription à une expérience de collecte. Dans ce cadre, la souscription déclenchera le téléchargement des scripts associés dans le système de fichier du dispositif mobile ainsi que des informations complémentaires propres aux scripts de collecte. Ces informations comprennent la version actuelle des scripts de collecte, l’adresse du serveur de collecte ayant initié l’expérience ainsi qu’un identifiant anonyme généré lors de la souscription. L’identifiant anonyme généré par le serveur central est unique pour chaque expérience. Cette identifiant servira alors de clé d’authentification lors de la propagation des données vers le serveur de collecte. Lorsque les scripts de l’expérience sont téléchargés, le module déclenche automatiquement son exécution. Néanmoins le participant garde à tout moment la possibilité d’arrêter son exécution. Mise à jour des expériences La mise à jour des expériences de collecte est gérée par le module NotificationManager. Les mise à jour sont effectuées par des communications de type push, c’est-à-dire des communications serveur vers mobile. Dans notre contexte applicatif, cela permet d’éviter de faire des requêtes périodiques vers le serveur, induisant un surcoût énergétique pour assurer une rapide prolifération. Pour assurer ce type de communication, nous utilisons des services intermédiaires proposés par les plate-formes mobiles actuelles, telles que APNs (Apple Push Notification service) pour plateformes tournant sur iOS et GCM (Google Cloud Messaging) pour les plateformes Android. Généralement, pour utiliser ce type de service, les dispositifs mobiles doivent tout d’abord procéder à une phase d’enregistrement auprès du service en question. Cette phase permet l’obtention d’un identifiant unique, qui devra ensuite être partagé avec le serveur — dans notre contexte, le serveur central— voulant envoyer des messages vers le dispositif en question. Le serveur peut ensuite faire appel au service dédié en utilisant les identifiants partagés pour propager directement des informations auprès des dispositifs mobiles. Dans ce contexte, lorsqu’une nouvelle version d’une expérience est déployée, le serveur central envoie un message à tous les participants ayant souscrits à l’expérience en question. Ce message est ensuite intercepté par le NotificationManager qui déclenchera automati- 76quement le téléchargement de la nouvelle version, sans imposer aux participants de télécharger à nouveau la tâche de collecte manuellement. Retour utilisateur Le Feedback Manager est responsable de l’interaction entre les tâches de collecte et les participants. Comme nous l’avons mentionné précédemment (cf. sous-section 3.3.3, page 66 ), l’interface de programmation proposée permet de diffuser des visualisations aux participants. Ces visualisations peuvent consister à fournir des statistiques sur les données collectées sous forme de graphique ou de carte, leur demander de prendre une photo d’un évènement particulier ou répondre à un questionnaire. Ces visualisations peuvent être directement développées en HTML/JavaScript, fournissant une grande flexibilité pour définir leurs propres visualisations en fonction de la nature de leurs expériences. D’autre part, cela permet également d’être indépendant de la plate-forme d’exécution, évitant ainsi le développement de plusieurs visualisations selon les plateformes visées. Dans ce cadre, nous tirons bénéfice des modules fournis par les plateformes mobiles (par ex. WebView 2 pour Android, UIWebView 3 pour iOS) pour faciliter l’intégration de contenus web dans une application mobile. Dans ce contexte, les tâches de collecte peuvent interagir avec le FeedBackManager, via une façade dédiée, permettant de publier un nouveau contenu accessible par le participant. Chaque contenu web est ensuite sérialisé et sauvegardé dans une base de données, et pourra être visualisé par le participant à tout moment à partir d’une interface graphique fournie par le FeedBackManager, (cf. figure 13). Propagation des données La propagation des données vers les nœuds de collecte est gérée par le TrackManager. Lors de l’exécution d’une tâche de collecte, les données collectées sont transmises au TrackManager qui les sauvegarde dans la base de donnée locale du dispositif. Pour chaque expérience, le processus de propagation (cf. sous-section 3.3.3) consiste à compresser les données collectées, ajouter des méta-informations sur la configuration du dispositif du participant (c.-à-d. filtre de vie privée) et à faire appel au service dédié du serveur de collecte ayant initié l’expérience pour l’envoi des données. Pour des raisons de sécurité, l’envoi des données s’effectue en utilisant le protocole HTTPS pour le cryptage des données. 2. Android WebView : http://tinyurl.com/android-webview 3. iOS UIWebView : http://tinyurl.com/ios-webview 77Figure 13 – Exemple de contenu web disponible via le FeedbackManager Nous venons de présenter dans cette section l’intergiciel mobile responsable de l’exécution de tâche de collecte, développée avec l’interface de programmation présentée dans la première section de chapitre. Dans la section suivante, nous présentons l’évaluation d’un prototype implémentant les concepts proposés dans ce chapitre. 3.5 évaluation du prototype Afin d’implémenter les concepts présentés dans ce chapitre sur une plate-forme mobile spécifique, celle-ci doit permettre principalement i) d’effectuer des processus en tâche de fond, ii) permettre la lecture en continue des capteurs, iii) et finalement être capable d’intégrer un moteur de script dans une application. Lorsque nous avons commencé le développement de notre prototype, la plate-forme Android correspondait parfaitement à ces caractéristiques, contrairement aux systèmes d’exploitation iOS qui ne permettaient pas d’exécuter des processus en tâche de fond limitant ainsi le développement d’application de collecte opportuniste. Cependant, les récentes mise à jour de ce système d’exploitation fournissent désormais ce support, rendant portable notre système pour iOS. Par manque de temps, nous n’avons pas pu fournir un prototype complet sur ce système d’exploitation, mais nous avons fourni une preuve de faisabilité disponible en open source 4 . Le prototype Android proposé a été conçu pour être utilisé comme application autonome ou comme librairie. En tant qu’application autonome, l’application peut être 4. https://github.com/APISENSE/APISENSE-SDK-iOS 78téléchargée par des participants voulant évoluer dans le système en flashant un QR code publié sur le site internet APISENSE® 5 . Plus particulièrement, le prototype réalisé à été développé en utilisant la version 2.3 du SDK proposé par Android. L’ensemble des modules proposés par l’architecture est inclus dans un Service de haute priorité pour prévenir que le système ne supprime notre application lorsqu’il a besoin de mémoire. Pour l’exécution des scripts, nous utilisons Rhino 6 , un moteur d’exécution JavaScript pour Java, qui permet l’interopérabilité des deux langages. L’ensemble du code réalisé représente approximativement 30000 lignes de codes, incluant l’interface graphique et l’architecture de l’application et les façades développées. Dans la suite cette section, nous présentons plusieurs cas réels d’expériences, montrant la diversité des tâches de collecte qui peuvent être réalisées à l’aide notre interface de programmation. Nous comparons par la suite son expressivité avec les différentes approches proposées dans la littérature, et discutons du coût énergétique lié à l’exécution des tâches de collecte sur les dispositifs mobiles. 3.5.1 Quelques exemples de collectes Pour démontrer l’expressivité de l’interface de programmation proposée dans ce chapitre, nous avons implémenté quatre tâches de collecte différentes (cf. table 7). Chaque tâche de collecte est inspirée de l’état de l’art, et démontre différents aspects de APISENSE. Wifi/Blutooth Scanner Wifi/Blutooth Scanner est une application opportuniste, montrant une interaction avec les capteurs Wi-Fi et Bluetooth d’un dispositif. Le listing 3.4 illustre le script implémentant cette application. L’objectif du script est de collecter, toutes les minutes, les points d’accès WIFI et les périphériques Bluetooth d’un utilisateur mobile. Dans le script, nous enregistrons une fonction de rappel aux façades $wifi et $bluetooth responsables des interactions avec ces capteurs, et nous configurons les capteurs pour qu’ils effectuent une nouvelle recherche toutes les minutes (period:"1 min"). La 5. http://www.apisense.fr 6. http://www.mozilla.org/rhino 79Application Capteurs Description Wifi-Blutooth Scanner Réseaux Application opportuniste. Collecte périodiquement les périphériques Bluetooth et Wi-Fi. Citoyen Journaliste GPS + Questionnaire Application participative. Demande à l’utilisateur de prendre une photo lorsqu’il se situe dans une zone géographique. Qualité Réseau Réseau + Questionnaire + Télé- phone Combinaison d’une application opportuniste et participatif.pour corréler la qualité d’une communication en fonction de la qualité du signal GSM. Exploiter des capteurs externes Bluetooth Communication avec un robot Lego Mindstorms NXT Inférence Conxtuelle Accéléromètre + Questionnaire Intégration d’une machine d’apprentissage pour inférer l’activité d’un utilisateur. Table 7 – Exemples de tâches de collecte implémentées avec APISENSE. (*Lignes de code) fonction de rappel enregistrée collecte alors les résultats donnés par les capteurs pour les propager vers le serveur ($trace.add(event)). 1 $wifi.onScan({period : "1 min"},function(event){ 2 $trace.add(event) 3 }) 4 $bluetooth.onScan({period : "1 min"}, function(event){ 5 $trace.add(event) 6 }) Listing 3.4 – Tâche de collecte : Wifi/Bluetooth Scanner Nous décrivons dans l’exemple suivant un exemple de collecte participative. Le Citoyen Journaliste L’objectif de cette application est de montrer comment une tâche de collecte peut interagir avec un utilisateur. Le Citoyen Journaliste, présenté initialement en [29], demande aux utilisateurs mobiles de prendre une image dans une région géographique spécifique, et de la commenter. Le script présenté dans le listing 3.5, crée d’abord un questionnaire (ligne 1-3). En ligne 5 nous observons la position de l’utilisateur et définissons que la fonction enregistrée (ligne 6-8) doit être exécutée uniquement lorsque la position de l’utilisateur se trouve dans le polygone précis (ligne 8). La fonction enregistrée publie le questionnaire à l’utilisateur (ligne 6), et collecte les données pour les propager vers le serveur lorsque l’utilisateur aura répondu au questionnaire. 801 var survey = $survey.create(); 2 survey.image("Take a picture"); 3 survey.open("Add a comment"); 4 5 $location.onLocationChanged(function(event){ 6 $survey.publish(survey,function(content){ 7 $trace.add(content); 8 $task.finish(); 9 }); 10 },"&((lat >= 0)(lat <= 1)(lon >= 0)(lon <= 1))") Listing 3.5 – Tâche de collecte : Le Citoyen Journalist Qualité Réseau Dans cette application, inspirée de MyExperience [25], nous voulons étudier la corrélation entre la qualité du signal réseau et la qualité de la communication vocale. Dans cette application (cf. listing 3.6), nous voulons montrer deux nouvelles propriétés de notre interface de programmation qui sont i) sa capacité à pourvoir adapter la séquence des questions d’un questionnaire en fonction des premières réponses d’un utilisateur et ii) combiner une collecte opportuniste et participative Dans la première partie du script (ligne 1-6), nous collectons la force du signal réseau GSM lorsque l’utilisateur est en situation de mobilité. Afin d’effectuer un retour sur les données collectées, nous insérons un nouveau point dans la visualisation proposée (ligne 6). Dans la deuxième partie du script (ligne 8-14), nous définissons un questionnaire et ajoutons deux questions relatives à la qualité d’une communication vocale. La première question consiste à demander la qualité de sa communication vocale. La deuxième consiste à lui demander pourquoi le participant a considéré que la communication a été mauvaise. Nous définissons ensuite l’enchaînement des questions (ligne 15-18) qui consiste à proposer uniquement la deuxième question uniquement si l’utilisateur a répondu une réponse spécifique à la première question. Ensuite, nous proposons le questionnaire lorsque l’utilisateur a terminé une communication vocale. 1 $location.onLocationChanged(function(event){ 2 $trace.add({ 3 latlng : [event.latitude,event.longitute], 4 signal : $telephony.signalStrength() 5 }) 6 }) 7 818 var qualitySurvey = $survey.create() 9 qualitySurvey.close("q1", 10 "Quelle a été la qualité de votre communication ?", 11 ["Trés Mauvaise", "Mauvaise", "Moyenne", "Bonne", "Excellente"]) 12 qualitySurvey.close("q2", 13 "Quel a été le probléme ?", 14 ["écho", "grésillement", "voix coupé"]) 15 qualitySurvey.then("q1",function(response){ 16 if (response == "Trés Mauvaise") 17 return "q2" 18 }) 19 20 $phone.onCallFinish(function(event){ 21 $survey.publish(qualitySurvey, function(content){ 22 $trace.add({ 23 latlng : $location.lastLocation(), 24 signal : $telephony.signalStrength(), 25 content : content 26 }) 27 })} Listing 3.6 – Exemple d’application participative Exploiter des capteurs externes Figure 14 – Flux de données de l’expérience Manipulation de Lego NXT Dans cette expérience, nous montrons que notre interface de programmation peut également être utilisée pour interagir avec des capteurs externes, afin de collecter des données qui ne peuvent pas être initialement capturées avec les capteurs initialement inclus dans les dispositifs mobiles. Cette expérience exploite les capteurs intégrés d’un robot Lego Mindstorms NXT (c.-à-d. capteur de contact, d’ultrason, de température et de pression atmosphérique), et permet également d’interagir avec le moteur du robot afin d’en prendre le contrôle à partir de la tâche de collecte. 82Comme le montre la figure 14, l’expérience est composée de deux scripts : NXT.js et Task.js décris par le listing 3.7. Le rôle du premier script est de faire une abstraction avec les différentes fonctionnalités des robots NXT. Ce script communique avec la façade responsable de l’interface Bluetooth, pour établir une connexion avec le robot et le manipuler à distance. Ce script peut être ensuite intégré dans le script Task.js en tant que librairie (ligne 1). Dans cet exemple, nous établissons une connexion avec un robot NXT à proximité (ligne 8), et déclenchons les moteurs du robot pour le faire avancer. Nous réagissons également lorsque le robot rencontre un obstacle pour le faire changer de direction (ligne 11-13). Les lignes (15-22) permettent ensuite de collecter des données capturées par les capteurs du dispositif mobile (par ex. GPS) et des capteurs du robot NXT (c.-à-d. pression atmosphérique et température) lorsqu’il se déplace. 1 var nxt = require("NXT.js"); 2 3 var change_direction = function(){ 4 nxt.move_back() 5 nxt.turn_left({ ’angle’ : 45 * random(), ’duration’ : ’2s’}) 6 nxt.move_forward() 7 } 8 nxt.onConnect({’timeout’: ’30s’},function(){ 9 nxt.move_forward() 10 11 nxt.onTouch(function(){ 12 change_direction() 13 }) 14 15 $location.onLocationChanged({provider : ["network"]},function(event){ 16 $trace.add({ 17 latlng : [event.latitude,event.longitude], 18 pressure : nxt.pressure(), 19 temperature : nxt.temperature() 20 }) 21 }) 22 }) Listing 3.7 – Tâche de collecte : Manipulation de Lego NXT Inférence Contextuelle Dans cette dernière expérience, l’objectif est de montrer que APISENSE® peut également être utilisé pour rapidement prototype et valider empiriquement des algorithmes contextuels. Dans ce scénario, nous voulons mettre en place un modèle d’apprentissage permettant de reconnaître l’activité d’un utilisateur (c.-à-d. assis, debout, marche, courir, monter ou descendre des escaliers). L’idée générale de l’approche est d’observer 83les données transmises par le capteur d’accélération afin de déterminer l’activité de l’utilisateur. Le script décrit dans le listing 3.8 implémente l’algorithme initialement proposé en [37]. 1 var classes = ["walk","jog","stand", "sit", "up", "down"]; 2 var current = 0; var buffer = new Array(); 3 var model = weka.newModel(["avrX","avrY",...], classes); 4 var filter = "|(dx>"+delta+")(dy>"+delta+")(dz>"+delta+")"; 5 6 var input = $accelerometer.onChange(filter, 7 function(acc) { buffer.push(acc) }); 8 9 var learn = time.schedule({ period: ’5s’ }, function(t) { 10 if (model.learn(classes[current]) >= threshold) { 11 current++; 12 } 13 if (current < classes.length) { // Learning phase 14 input.suspend(); 15 var output = $dialog.display( 16 { message: "Select movement", spinner: classes }); 17 model.record(attributes(buffer), output); 18 sleep(’2s’); 19 buffer = new Array(); 20 input.resume(); 21 } else { // Exploitation phase 22 dialog.display({message: "Learning phase completed"}); 23 learn.cancel(); 24 model.setClassifier("NAIVE_BAYES"); 25 time.schedule({ period: ’5s’ }, function(t) { 26 trace.add({ 27 position: model.evaluate(attributes(buffer)), 28 stats: model.statistics() }); 29 buffer = new Array(); 30 } } }); Listing 3.8 – Tâche de collecte : Inférence Contextuelle. Le script se décompose en deux phases : i) une phase d’apprentissage et ii) une phase d’exploitation. Pour réaliser la phase d’apprentissage, nous avons intégré un algorithme d’apprentissage [44] implémenté en Java dans l’intergiciel mobile, et nous avons ajouté une façade pour utiliser ses fonctionnalités à partir du script. Durant la phase d’apprentissage, le script génère une boite de dialogue demandant à l’utilisateur de répéter des mouvements spécifiques. Lorsque l’utilisateur exécute les mouvements demandés, nous enregistrons les données d’accélérations selon les trois axes, et calculons des métriques (c.-à-d. moyenne, l’écart type, etc. ) sur les valeurs obtenues. Ces métriques sont ensuite insérées dans l’algorithme d’apprentissage et le mouvement qui à été effectué. Une fois que suffisamment de données ont été insérées dans le modèle d’apprentissage, le 84Predicted Class Acc (%) Walk Jog Stand Sit Up Down Walk 66 0 4 0 0 0 94,3 Jog 0 21 0 0 0 0 100 Stand 4 0 40 0 0 0 90,9 Sit 0 0 2 83 0 0 97,6 Up stair 0 0 0 0 22 0 100 Down stair 0 0 0 0 0 11 100 Table 8 – Tableau décrivant la qualité du système de classification script passe en phase d’exploitation. Dans cette phase, nous évaluons, toutes les cinq secondes, les métriques des données d’accélération dans le modèle d’apprentissage. Le résultat correspondant au mouvement de l’utilisateur et ensuite sauvegardé avec les statistiques du modèle obtenu pour les reporté sur le serveur. Le tableau 8 reporte la matrice de confusion décrivant la qualité du système de classification obtenue par un utilisateur durant cette expérience. La matrice illustre le nombre de mouvements effectués durant cette expérience, et la haute précision des prédictions obtenues pour chacun des mouvements. Discussion Dans cette sous-section, nous discutons de l’expressivité et la complexité des approches décrites dans l’état de l’art avec APISENSE®. Nous utilisons le nombre de lignes de code pour comparer la complexité avec deux applications de collecte couvrant les deux formes d’acquisition de données qui sont la collecte opportuniste (application Wifi-Bluetooth Scanner) et participative (application Citoyen Journaliste). Le tableau 9 présente le nombre de lignes de code nécessaires pour développer ces applications. Le symbole X signifie que l’application ne peut pas être exprimée et le symbole ? signifie que l’application est réalisable, mais que nous n’avons pas d’information sur le nombre de lignes de code nécessaire avec l’approche concernée. En terme de lignes de code, APISENSE® est beaucoup plus concis (4 lignes) que les approches utilisant le langage déclaratif XML pour concevoir une application. C’est la cas avec MyExperience (27 lignes) et Medusa (45 lignes) pour l’application Citoyen Journaliste. De plus ces deux dernières approches ne supportent la définition d’application de collecte purement opportuniste comme l’application Wifi-Blutooth 85Scanner. Même si la concision de notre code est à peu près similaire à Anonysense (7 lignes de code) et Pogo (6 lignes de code), notre approche comporte de nombreux avantages comparés à ces approches. Par apport à Anonysense, qui utilise un DSL pour le développement des applications, le langage JavaScript nous permet d’avoir une plus grande flexibilité pour concevoir des traitements plus complexes, et surtout nous permet de facilement réutiliser du code déjà existant, comme nous l’avons montré dans l’application présentée en sous-section (cf. 3.5.1). Par rapport à Pogo, utilisant également une interface de programmation basée sur JavaScript, notre interface de programmation supporte les tâches de collecte de données participative qui n’est pas possible avec l’interface proposée par Pogo. La seule approche proposée supportant la collecte opportuniste et participative est PRISM, qui propose le déploiement d’applications de collecte écrites en code natif. Cependant PRISM ne propose pas d’abstraction pour faciliter le développement de ses applications, nécessitant une expertise approfondie en développement mobile. L’application Citoyen Journaliste nécessite par exemple 330 lignes de code. En outre, le développement natif des applications les rend exclusives pour un OS mobile, demandant par conséquent d’étudier et développer une nouvelle version de l’application pour supporter l’hétérogénéité des OS disponible. Nous avons présenté dans cette section un ensemble d’applications réalisables avec APISENSE®. Nous pensons que APISENSE® propose un bon compromis entre toutes les approches proposée dans l’état de l’art, supportant la collecte opportuniste (application Wifi/Blutooth Scanner), participative (application Citoyen Journaliste), ou une combinaison des deux (application Qualité Réseau) tout en fournissant une abstraction complète des technologies mobiles. En proposant une interface de programmation au-dessus de JavaScript, APISENSE® permet également de définir des traitements complexes (application Inférence contextuelle), et faciliter la réutilisation de code déjà existant (application Exploiter des capteurs externes). Nous pensons que la réutilisation est un aspect fondamental pour le succès APISENSE®, favorisant son utilisation par de nombreux acteurs académiques ou industriels, avec des niveaux d’expertises différents dans la collecte de données. En effet, les experts du domaine peuvent proposer des modules ou algorithmes complexes, utilisant les capteurs des dispositifs pour inférer des informations de haut niveau (par ex. activité de l’utilisateur, mode de transport), ou encore utiliser intelligemment les différents capteurs pour réduire la consommation énergétique des applications de collecte dans un contexte spécifique [14]. Ces modules pourront être ensuite réutilisés par des utilisateurs non experts. Et finalement, l’utilisation de JavaScript permet également de supporter l’hétérogénéité des OS mobiles 86Wifi-Blutooth Scanner Citoyen Journaliste APISENSE 4 9 Medusa [55] X 45 MyExperience [25] X 27 Anonysense [62] 5 X Pogo [6] 4 X PRISM [16] ? 330 Table 9 – Comparaison de l’expressivité et du nombre de lignes de code pour s’affranchir d’étudier et développer une nouvelle application pour chaque OS disponible. 3.5.2 Coût énergétique d’une expérience de collecte Dans cette section, nous comparons la consommation énergétique de notre prototype réalisé sur Android avec Funf [1], une application présentée dans l’état de l’art APISENSE® ( section 2.3.1, page 34 ). Nous rappelons que Funf est un outil permettant de générer des applications natives Android à la carte. Pour réaliser cette expérience, nous avons exécuté chaque application durant 24 heures, sur un Nexus-S réinitialisée à une configuration par défaut, pour limiter le bruit qui peut être induit par d’autres applications. Chaque application est configurée pour collecter toutes les 10 minutes des informations de la batterie du dispositif mobile. Le résultat de cette expérience est illustré par la figure 15 Dans cette courbe, l’abscisse représente le temps, et l’ordonnée la tension en millivolt représentant le niveau de la batterie du dispositif. La tension d’un dispositif varie généralement entre 4200 millivolts, représentant 100% de niveau de batterie, et 3200 millivolts. Comparé à une application native (baseline), nous pouvons observer que le surcoût énergétique de notre prototype est faible comparé à une application native, et moins important que celui imposé par Funf. Bien que notre solution soit plus consommatrice qu’une application native, notre solution ne nécessite aucune expertise particulière de la plate-forme Android, et rend également transparent le déploiement de l’application et la propagation des données pour les développeurs. Comme la consommation énergétique dépend fortement de i) la nature de l’expé- rience, ii) du type de capteur utilisé et iii) du volume des données produit, nous avons réalisé une seconde expérience permettant d’estimer l’impact des différents capteurs 87 4100 4120 4140 4160 4180 4200 0 200 400 600 800 1000 1200 1400 Voltage (mV) Time (s) Android Native Application Funf Bee.sense Figure 15 – Impact d’APISENSE sur la consommation énergétique sur la consommation de la batterie (cf. figure 16). Pour cette expérience, nous avons développé trois scripts, qui ont été exécutés séparément sur trois dispositifs mobiles. Le premier script (APISENSE + Bluetooth), déclenche un scan toutes les minutes et collecte le niveau de la batterie aussi bien que le résultat du scan. Le second (APISENSE + GPS) collecte également toutes les minutes les données GPS tandis que le dernier script collecte des données relatives au point d’accès WIFI. Cette expérience démontre que même avec un stress important sur les capteurs, il est possible de collecter des données durant une journée normale de travail sans avoir à recharger le dispositif mobile (40% d’énergie consommée après 10 Heures d’activation du GPS). 3.6 conclusion Le développement d’applications mobiles dédiées à la collecte de données est un processus long et complexe. Généralement, afin de déployer l’application vers un grand nombre d’utilisateurs, plusieurs applications ont besoin d’être développées pour faire face à la diversité des plate-formes mobiles disponibles. D’autre part, ces applications doivent généralement prendre en compte des aspects non fonctionnels tels que la 88 0 20 40 60 80 100 0 100 200 300 400 500 Battery level (%) Time (min) APISENSE APISENSE + GPS APISENSE + Bluetooth APISENSE + WiFi Figure 16 – Impact des capteurs sur la consommation énergétique protection de la vie privée des utilisateurs ainsi que la consommation énergétique de ces applications. Dans ce chapitre, nous avons présenté notre approche pour diminuer le coût lié aux développements d’applications mobiles dédiées à la collecte de données. Plus particulièrement, nous avons présenté dans un premier temps une interface de programmation de haut niveau pour la définition d’une application de collecte. L’interface proposée a été conçue pour i) faire face à la diversité des applications de collecte (i.e. participative, opportuniste), ii) supporter l’hétérogénéité des plate-formes mobiles iii) tout en permettant de s’abstraire de la complexité liée au développement mobile. Nous avons ensuite présenté l’environnement mobile dédié aux utilisateurs en charge de l’exécution de l’interface proposée. Nous avons particulièrement présenté son architecture composée de quatre couches pour i) le déploiement et la propagation des données, ii) permettre aux utilisateurs de contrôler des les données collectées sur leurs dispositifs, iii) l’exécution des applications de collecte et iv) limiter la consommation énergétique liée à l’exécution d’une application de collecte. Dans le chapitre suivant, nous allons présenter l’environnement serveur de notre architecture. 894 C O L L E C T E R É PA RT I E D E D O N N É E S Sommaire 4.1 Introduction 91 4.2 Infrastructure répartie de traitement des données 92 4.3 Architecture du serveur central 94 4.3.1 L’enregistrement des participants 95 4.3.2 L’enregistrement des expériences de collecte 96 4.3.3 Déploiement des tâches de collecte 98 4.3.4 Gestion des nœuds de collecte 99 4.4 Architecture des noeuds de collecte 100 4.4.1 Modèle de caractèristiques d’une campagne de collecte 101 4.4.2 Création d’une nouvelle campagne 107 4.4.3 Intéraction entre les composants 110 4.4.4 Extension des nœuds de collecte 112 4.5 Campagne de collecte communautaire 113 4.5.1 Extension du modèle de programmation 116 4.5.2 Coordonner l’exécution des tâches de collecte 119 4.6 Conclusion 124 4.1 introduction L’objectif des travaux de cette thèse est de proposer une solution générique, facilitant le développement et le déploiement de campagnes de collecte de données à travers des dispositifs mobiles. Dans le chapitre précédent, nous avons présenté l’environnement mobile de APISENSE®, la plate-forme résultante des travaux de cette thèse. Nous avons proposé un modèle de programmation facilitant le développement d’applications mobiles dédiées à la collecte de données et un intergiciel déployé au préalable sur les dispositifs mobiles, dédié à leurs exécutions. 91Dans ce chapitre, nous présentons notre deuxième contribution concernant l’architecture et l’implémentation de l’environnement serveur de APISENSE®, responsable du déploiement des campagnes de collecte, de la persistance des données ainsi que leurs analyses. Ce chapitre adresse particulièrement deux défis introduit en début de manuscrit, qui sont la généralité de la plate-forme, concernant la capacité de la plate-forme à supporter une grande diversité de campagnes de collecte ainsi que son passage à l’échelle. structure du chapitre La suite du chapitre est organisée comme suit : en section 4.2, nous présentons une vue d’ensemble de l’architecture proposée, et discutons des bénéfices de cette architecture par rapport aux solutions de l’état de l’art. Dans les sections 4.3 et 4.4, nous présentons en détail l’architecture des différentes entités logicielles de APISENSE®, ainsi que les méthodes de conceptions et de modélisations utilisées. Dans le chapitre 4.5, nous proposons une optimisation améliorant le passage à l’échelle du système avant de conclure en section 4.6. 4.2 infrastructure répartie de traitement des données Avant de présenter en détail l’architecture proposée dans ce chapitre, nous présentons ici une vue globale de la plate-forme APISENSE®. La figure 17 donne un aperçu simpli- fié des différentes entités logicielles qui la composent, et leurs principales interactions. L’architecture est principalement composée de trois parties distinctes : un ensemble de nœuds de collecte (DataGathering Node), un serveur central (Central Server) et un ensemble de nœuds mobiles avec une application dédiée installée au préalable par les participants. Nous avons déjà présenté les noeuds mobiles dans le chapitre précédent (cf. 3.4, page 68 ). APISENSE® adopte une architecture décentralisée, où le serveur central est assumé comme le tiers de confiance de la plate-forme. Plus particulièrement, le serveur central est responsable du déploiement des tâches de collecte soumises par les nœuds de collecte, vers les nœuds mobiles du système. Afin de fournir un déploiement adapté (par ex. zone géographique, type de dispositif mobile), le serveur central a besoin de maintenir à jour un ensemble d’informations, sur les dispositifs mobiles disponibles pour exécuter des tâches de collecte. Dans ce contexte, nous supposons que le serveur central est géré par un acteur de confiance, qui peut être une organisation publique, ou une structure de recherche. 92Figure 17 – Vue d’ensemble d’APISENSE® La gestion des campagnes de collecte est assurée par les nœuds de collecte, qui peuvent être dédiés à un ou plusieurs utilisateurs. Typiquement, la gestion d’une campagne de collecte comporte quatre phases : i) définir une tâche de collecte, ii) recruter un sous-ensemble de dispositifs mobiles, iii) assurer la persistances des données collectées (c.-à-d. dans une base de données) lors de l’exécution de la tâche iv), exploiter les données. Pour réaliser ces différentes étapes, un nœud de collecte propose un environnement fournissant un ensemble de services qui peuvent être entièrement configurés par les utilisateurs. La configuration consiste en la sélection de modules implémentant la logique dédiée à la réalisation d’une étape d’une campagne de collecte. Dans ce cadre, les modules proposés peuvent implémenter différentes stratégies selon la nature de la campagne. Par exemple, la phase de collecte peut inclure un modèle particulier d’anonymisation des données pour assurer la confidentialité des participants. Ce choix de conception, séparant les préoccupations du déploiement ainsi que la collecte et l’analyse des données, nous permet de rompre avec le syndrome de l’enfermement propriétaire. Premièrement, en offrant la possibilité aux utilisateurs de déployer leurs nœuds de collecte sur l’infrastructure de leur choix, leur permettant 93ainsi de garder un contrôle total sur les données collectées durant leurs campagnes. Les nœuds de collecte peuvent ainsi être déployés vers une infrastructure publique ou privée, en fonction des préoccupations éthiques ou légales en rapport avec le stockage des données. De plus, les nœuds de collecte des utilisateurs sont complètement isolés les uns des autres, améliorant la sécurité et la disponibilité de leurs environnements, permettant d’effectuer des traitements lourds sur les données collectées sans affecter les autres instances. Et finalement, en gardant une entité centrale (c.-à-d. le serveur central), cela permet aux nouveaux utilisateurs de bénéficier d’un ensemble de participants déjà disponibles pour exécuter leurs tâches de collecte, s’affranchissant ainsi d’une longue période de recrutement. Après avoir présenté une vue globale de la plate-forme APISENSE®, nous présentons dans la suite de ce chapitre l’architecture et les services fournis par le serveur central (cf. section 4.3), ainsi que les nœuds de collecte (cf. section 4.4). 4.3 architecture du serveur central Comme nous l’avons présenté dans la section précédente, APISENSE® est une plate-forme répartie dédiée aux déploiements et à l’exécution de campagnes de collectes de données. Afin de fournir une plate-forme modulaire, facilement extensible et configurable, APISENSE® est une plate-forme orientée service, utilisant un modèle à composants logiciels pour modéliser les différentes applications serveur qui la composent. Plus spécifiquement, APISENSE® est basée sur le modèle SCA [46], un standard initié par le consortium OASIS, dédié à la modélisation d’architectures tout en étant indépendant des langages de programmation, des protocoles de communication, des langages de description d’interface et des propriétés non fonctionnelles. La figure 18 illustre le modèle SCA du serveur central. Dans SCA, les bases des constructions sont les composants logiciels, qui peuvent offrir des services, ou solliciter d’autres composants via des références. Les services ainsi que les références peuvent être connectés à l’aide de fils (wire en anglais). SCA spécifie un modèle à composants hiérarchiques, laissant la possibilité d’implémenter un composant par un langage de programmation, ou par un ensemble de sous composants. Dans le dernier cas, ces composants sont appelés composite. Afin de supporter l’interaction entre des services distants, SCA spécifie la notion de communication distante (binding), permettant de décrire 94le protocole que le client devra utiliser pour invoquer un service. Dans l’architecture SCA proposée, les composants ParticipantFrontend, GatheringNodeFrontend ScientistFrontend et représentent les points d’entrés pour les différents acteurs qui interagissent avec le serveur central. Ces composants exposent leurs services en tant que ressource REST, accessibles via le protocole HTTP. Plus particulièrement, ces composants fournissent quatre types services nécessaires au fonctionnement du système, dédié à : L’enregistrement des participants : ce service (participant registration) est accessible par les dispositifs mobiles, permettant l’enregistrement d’un nouveau participant volontaire pour exécuter de nouvelles tâches de collecte. L’enregistrement des expériences de collecte : ce service (deploy scripts) est accessible par les nœuds de collecte, et permet aux utilisateurs d’enregistrer de nouvelles expériences de collecte. Le déploiement des expériences de collecte : ces services (list experiment, download script, recruit participants) assurent la propagation des expériences vers les terminaux mobiles. La gestion des nœuds de collecte : ces services (user registration, deploy data gathering node, downloads modules) représentent les points d’entré dans le système pour les utilisateurs voulant créer et configurer un nœud de collecte. Nous présentons dans la suite de cette section les services fournis par ces composants. 4.3.1 L’enregistrement des participants L’enregistrement des participants permet d’informer le serveur central de la présence et de la disponibilité des participants pour exécuter des tâches de collecte. Ce service, fourni par le composant DeploymentService, est invoqué par les nœuds mobiles lors de leurs installations sur les terminaux mobiles des participants. L’inscription inclut des informations statiques sur la configuration matérielle des terminaux des participants, ainsi que des informations confidentielles. Les informations matérielles comprennent le type du terminal (par ex. smartphone, tablette), le système d’exploitation utilisé (par ex. Android, iOS) ainsi que l’ensemble des capteurs embarqués dans le terminal. Les informations confidentielles comprennent par défaut le nom, le prénom et une adresse électronique valide. Cependant, le participant a la possibilité de raffiner ces informations, volontairement, en indiquant des lieux géographiques — à gros grain (par ex. pays, région ou ville) — où il évolue, son statut ainsi que son âge. Ces informations sont ensuite stockées dans une base de données, et serviront 95Figure 18 – Architecture SCA du serveur central lors de la phase de déploiement. Pour des raisons de confidentialité, elles pourront être accessibles uniquement par le serveur central, c’est-à-dire qu’elles ne seront pas accessibles par les nœuds de collecte du système. 4.3.2 L’enregistrement des expériences de collecte Accessible par les nœuds de collecte du système, ce service, fourni par le composant Recruitment, permet l’enregistrement d’une expérience de collecte auprès du serveur central. Cette enregistrement comprend deux catégories d’éléments. La première correspond a un ensemble de fichiers JavaScript définissant la tâche de collecte (cf. section 3.3, page 59 ). La deuxième catégorie définit les propriétés de l’expérience et également ses exigences en matière de déploiement. Ces propriétés sont définies par un ensemble de clés/valeurs utilisant le formalisme JSON. Comme le montre le tableau 10, trois catégories de propriétés sont actuellement supportées : global : définit principalement des informations générales sur l’expérience de collecte. Ces propriétés ne sont pas interprétées par le serveur central, mais 96propriété nom description global name Nom de l’expérience description Description du but de la collecte de données version Version de l’expérience de collecte privacy Description du modèle de protection de la vie privée incentive Description du modèle de récompense nodeurl URL du nœud de collecte de collecte recruitment sensors Liste des capteurs utilisées par la tâche de collecte max_numbers Nombre maximum de participants admis dans l’expé- rience de collecte area Zone globale de collecte (par ex. pays, région, ville) platform Liste de plate-formes mobiles context area Liste de zone géographique. period Liste de période journalière Table 10 – Propriétés définissant une expérience de collecte permettent d’informer les participants sur les objectifs de l’expérience (description), le modèle de confidentialité (privacy) et de récompense (incentive). recruit : permet de définir les participants autorisés à participer à une expérience de collecte. Ces propriétés permettent de limiter le nombre de participants impliqué dans l’expérience (max_numbers), de sélectionner des participants évoluant dans un lieu géographique (area) — à gros grains (par ex. pays, région ou ville) —, disposant d’un terminal ayant les capteurs nécessaires pour l’exécution de la tâche de collecte (sensors) et disposant d’une plate-forme mobile spécifique (platform). context : permet de spécifier le contexte d’exécution de la tâche de collecte une fois propagée vers les terminaux mobiles. Dans ce cadre, les propriétés permettent de spécifier une liste de zones géographiques (area) — région circulaire définie par les coordonnées du centre et un rayon exprimé en mètres —, et une liste de périodes journalières (period) dans lesquelles l’expérience doit s’exécuter. Ces propriétés seront ensuite interprétées par les nœuds mobiles, qui seront responsables de déclencher ou de stopper l’exécution de la tâche de collecte (cf. section 3.4.2, page 72 ). 974.3.3 Déploiement des tâches de collecte Une fois l’expérience enregistrée, deux stratégies principales peuvent être considérées pour propager les tâches de collecte vers les nœuds mobiles des participants [16]. La première approche (push-based) consiste à déployer automatiquement l’expérience de collecte auprès des utilisateurs mobiles. Dans la deuxième (pull-based), le nœud mobile télécharge la tâche de collecte après une action volontaire du participant, ou en effectuant une requête périodiquement vers le serveur pour voir si une nouvelle expérience est disponible [62]. Dans ce cadre le serveur central supportent ces deux approches pour la propagation des tâches de collecte. Approche pull-based La première approche (pull-based) est supportée par les composants Pull, DeploymentService et PropertyMatcher. Dans un premier temps, les participants peuvent accéder au service proposé par le Pull, via leur dispositif mobile, pour récupérer une liste d’expériences mises à disposition par les utilisateurs. Dans ce cadre, le PropertyMatcher détermine les expériences accessibles pour le participant, en faisant la correspondance entre les propriétés de recrutement des expériences, et des informations partagées par le participant lors de son inscription. Des informations générales sont fournies pour chaque expérience accessible, permettant au participant de visualiser le but de l’expérience de collecte, du modèle de confidentialité et de récompense ainsi que les capteurs utilisés lors de son exécution. À partir de ces informations, le participant a alors la possibilité de s’enregistrer à une expérience. Lors de la souscription, un identifiant anonyme est alors généré. Cet identifiant est ensuite envoyé au nœud de collecte ayant initié l’expérience et à l’agent mobile, pour l’avertir d’un nouveau recrutement dans l’expérience. Dans ce cadre, l’identifiant anonyme servira pour toutes les communications entre les nœuds de collecte et les participants, comme lors de la propagation des données. Cela permet en effet aux participants de ne pas révéler leurs identités réelles lors des interactions avec les nœuds de collecte, assurant ainsi une première couche d’anonymisation. Une fois la souscription terminée, l’agent mobile peut alors télécharger la tâche de collecte associée et déclencher son exécution. Approche push-based La deuxième approche (push-based) est supportée par les composants Push, et également par le composant PropertyMatcher. Dans ce cadre, le Push fournit un service, 98accessible par les nœuds de collecte, pour pousser directement une tâche de collecte vers les agents mobiles des participants. Ce processus comprend deux étapes. La première consiste à envoyer un message vers les agents mobiles acceptant ce mode de déploiement, et correspondant aux propriétés de l’expérience. La deuxième étape est ensuite similaire à l’approche présentée ci-dessus, c’est-à-dire composée de la phase de souscription et de téléchargement de la tâche de collecte. Pour établir ce type de propagation, il est nécessaire de supporter des communications dans le sens serveur vers terminaux mobiles. Typiquement, ce type de communication peut être effectué en utilisant des services dédiés, proposés par les fournisseurs des OS mobiles tels que GCM (Google Cloud Messaging) pour Android ou APNs (Apple Push Notification service) pour iOS. Dans ce contexte, le composant PushService est en charge de l’interaction avec ces services pour envoyer des messages vers les terminaux mobiles selon l’OS mobile visé. Indépendamment de l’approche utilisée, le composant Push permet également aux nœuds de collecte de propager des messages aux utilisateurs mobiles s’étant inscrits à leurs expériences. Ces messages peuvent être propagés soit à un participant en particulier, ou alors à l’ensemble des participants ayant souscrits à l’expérience. Deux types de messages peuvent être transmis : update : Message indiquant la disponibilité d’une nouvelle mise à jour de l’expérience. Dans ce cadre, ce message déclenchera le téléchargement de la nouvelle version de l’expérience par les nœuds mobiles. Cela permet de rapidement adapter le comportement de l’expérience une fois déployée. notification : Ces messages permettent aux utilisateurs de notifier l’état d’avancement de l’expérience en cours, en partageant des statistiques globales des données collectées avec tous les participants. 4.3.4 Gestion des nœuds de collecte Les derniers services présentés sont responsables de la création et de la configuration des nœuds de collecte. Un utilisateur voulant évoluer dans APISENSE®, peut se connecter au service géré par le composant DataGatheringRepository via une interface web, et déclencher le téléchargement de leur propre nœud de collecte. Celui-ci pourra ensuite être déployé vers une infrastructure publique ou privée, selon les exigences des utilisateurs. 99Un nœud de collecte peut être téléchargé suivant deux formats : 1. En tant qu’image virtuelle pré-configurée, permettant son déploiement au-dessus d’un environnement virtualisé. Dans ce cadre, l’image virtuelle comprend toute la pile logicielle nécessaire au bon fonctionnement du nœud de collecte. Plus particulièrement, elle est composée d’une distribution Linux, d’une machine virtuelle Java (JVM), d’une base de données MongoDb 1 pour le stockage des données, et FraSCAti responsable de l’exécution des composants SCA du nœud de collecte. 2. En tant qu’archive web (.war), permettant son déploiement directement au-dessus d’un serveur d’application (c.-à-d. Apache Tomcat). Le service fourni par le ComponentRepository propose un ensemble de composants modulaires, dédiés à la configuration d’un nœud de collecte. Les utilisateurs peuvent accéder à ce service via leur nœud de collecte nouvellement déployé, pour télécharger et assembler des composants dans leur nœud de collecte en fonction de la nature des expériences qu’ils veulent mener. Nous présentons ce point plus en détail dans la section suivante. 4.4 architecture des noeuds de collecte Dans la section précédente, nous avons présenté l’architecture et les services fournis par le serveur central de la plate-forme APISENSE®. Dans ce chapitre, nous présentons l’architecture des nœuds de collecte, et plus particulièrement comment nous tirons profit du modèle SCA pour fournir des nœuds de collecte facilement configurables. Les nœuds de collecte sont les entités logicielles de notre système responsables de la gestion des campagnes de collecte des utilisateurs. Nous rappelons qu’une campagne est essentiellement composée de quatre étapes qui consiste : 1. à définir une tâche de collecte via une interface de programmation dédiée, 2. à publier la tâche de collecte auprès du serveur central pour le recrutement des participants, 3. à assurer la persistance des données collectées par les dispositifs, 4. et finalement à analyser et exploiter les données collectées Par ailleurs, une expérience peut également comporter un modèle de protection de la vie privée des participants, ainsi qu’un modèle de récompense. 1. https://www.mongodb.org 100Pour faire face à la diversité des expériences qui peuvent être menées, les nœuds de collecte peuvent être entièrement configurés selon la nature d’une expérience. Cette configuration consiste essentiellement à assembler un ensemble de composants SCA, où chaque composant est responsable de la logique fonctionnelle d’une étape d’une expérience. Dans ce contexte, plusieurs composants peuvent être dédiés à une même étape, représentant la partie variable d’une configuration. Pour guider les utilisateurs dans ce processus d’assemblage, nous avons adopté une approche basée sur l’ingénierie des Lignes de Produits Logiciels (LDPs) [12, 52] (en anglais SPL pour Software Product Line). Typiquement, l’idée est i) de définir un Modèle de Caractéristiques (MC) [32](en anglais FM pour Feature Model) qui capture les caractéristiques communes et les points de variabilité d’une configuration d’une expérience, ii) d’implémenter le MC comme un assemblage de composants SCA et de proposer le MC aux utilisateurs pour leurs permettre de sélectionner les composants selon la nature des expériences qu’ils veulent mener. Dans la suite de cette section, nous présentons le MC dédié à la configuration des expériences de collecte en sous-section 4.4.1, un exemple d’architecture SCA généré et leurs interactions permettant la réalisation d’une campagne de collecte, et nous finissons par présenter le mécanisme d’extension permettant d’adresser les exigences non anticipées. 4.4.1 Modèle de caractèristiques d’une campagne de collecte La notion de Modèle de Caractéristiques (MC), introduite par Kang et al. [32], est une technique de modélisation permettant la description d’un ensemble d’artéfacts réutilisables, qui peuvent être utilisés pour créer une famille de logiciels qui possède des caractéristiques communes, mais exhibant également des différences. Le MC représente ainsi l’ensemble des choix proposés à un utilisateur pour lui permettre de configurer un logiciel spécifique à ses besoins. Typiquement, un MC est spécifié sous forme d’arbre, dont les nœuds représentent les caractéristiques d’un logiciel et les arcs spécifient des liens de composition entre les caractéristiques. Trois catégories de caractéristique peuvent être définies : les caractéristiques obligatoires, les caractéristiques optionnelles et les caractéristiques alternatives. Additionnellement, des règles de composition peuvent être définies, établissant une 101relation entre les caractéristiques. Ces règles peuvent prendre deux formes i) une caractéristique qui nécessite la sélection d’une autre caractéristique (définissant une interdépendance entre les caractéristiques), et ii) la sélection d’une caractéristique peut exclure la sélection d’une autre. Dans notre contexte d’utilisation, nous utilisons cette technique pour modéliser les différents choix proposés aux utilisateurs pour leur permettre de configurer les services d’une campagne de collecte selon les spécificités de celle-ci. La figure 19 illustre le MC dédié à la configuration d’une campagne de collecte. Typiquement, le MC identifie principalement cinq points de variabilités pour i) configurer l’environnement de développement des tâches de collecte (SensingTask Description), ii) choisir un modèle de recrutement des utilisateurs (Recruitment), iii) choisir une série de traitements sur les données collectées avant leurs insertions dans la base de données (OnlineProcessing), iv) spécifier l’indexation des données dans la base de données (Collector), v) exposer des services au-dessus des données collectées (Service). Nous décrivons à présent brièvement ces différents points de variabilités et les caractéristiques actuellement supportées. Figure 19 – Modèle de caractéristiques d’une campagne de collecte 102SensingTask Description Ce premier point de variabilité permet aux utilisateurs de sélectionner l’interface web dédiée aux développements des tâches de collecte vue dans le chapitre précédent (cf. section 3.3). La première interface, définie par la caractéristique CodeEditor, propose un éditeur de code en ligne — avec coloration syntaxique, complétion de code, etc. — permettant le développement des tâches de collecte directement en JavaScript. La deuxième interface, définie par la caractéristique Form, quant à elle, fournit une interface web permettant le développement des tâches à partir d’un formulaire. Le formulaire permet principalement de spécifier le type de données à collecter (par ex. position, accéléromètre, périphérique Bluetooth) avec la fréquence de collecte pour chaque donnée (par ex. toutes les cinq minutes). Après validation du formulaire, un fichier JavaScript est généré à partir des choix effectués par l’utilisateur. Le formulaire permet de rendre accessible le développement des tâches pour des utilisateurs n’ayant aucune expertise en programmation. Cependant, le formulaire limite l’expressivité des tâches qui peuvent être développées, en définissant uniquement des tâches de collecte périodique de données. Nous prévoyons dans des travaux futurs de proposer des métaphores visuelles pour développer des tâches de collecte plus complexes, tout en permettant leur développement par des utilisateurs n’ayant aucune expertise en développement. Certains travaux ont déjà été proposés dans ce sens tels que Scratch [48, 58] ou Alice [15] ou plus récemment App Inventor 2 . Le principe de ces approches consiste à fournir un environnement intuitif, dans lequel on associe des composants visuellement pour définir le comportement d’une application. Recruitment Ce deuxième point de variabilité permet de sélectionner le modèle utilisé pour recruter un sous-ensemble de participants exécutant la tâche de collecte. Dans ce contexte, le recrutement consiste essentiellement à interagir avec les services du serveur central pour déployer la tâche de collecte et assurer sa mise à jour, définir un sous-ensemble de participants autorisés à l’exécuter et son contexte d’exécution. Les deux caractéristiques associées à ce point de variabilité (Individuel et Collaborative) permettent de faire face aux différentes échelles de collecte (cf. section 2.1.2) que sont la collecte personnelle et la collecte communautaire. La caractéristique Individuel propose un modèle simple de recrutement des participants dédié à la collecte personnelle de données, qui a généralement pour objectif de suivre l’activité d’un individu à travers le temps. Nous présentons plus en détail en 2. http://appinventor.mit.edu 103sous-section 4.4.4 ce modèle et les différentes interactions entre les nœuds mobiles, le serveur central et les nœuds de collecte nécessaires. La caractéristique Collaborative propose un modèle principalement dédié à la collecte communautaire de données, qui a généralement pour objectif de surveiller des phénomènes liés à l’environnement des participants (par ex. surveiller la qualité du signal réseau dans la ville de Paris). Nous décrirons plus en détail ce modèle dans la section 4.5. Online Processing Ce point de variabilité permet de définir un ensemble de traitements à effectuer sur les données collectées avant leurs insertions dans une base de données. Les traitements peuvent consister à calculer des statistiques globales sur les données collectées (caracté- ristique Statistique), calculer un modèle d’incitation pour récompenser les participants (point de variabilité Incentive), ou encore effectuer des traitements modifiant les données collectées pour assurer leurs confidentialités (point de variabilité Privacy). Incentive Ce point de variabilité définit le modèle de récompense de l’expérience de collecte. Typiquement, l’incitation peut prendre une grande variété de formes. Par exemple, ré- compenser les participants financièrement [41] pour les données partagées, ou transférer des mécanismes de jeux dans le contexte de la collection de données [69]. Généralement, un modèle de récompense a pour objectif d’augmenter la participation des utilisateurs, et de les motiver à partager des données plus pertinentes pour l’expérience. Actuellement, nous supportons un modèle de récompense [24] basé sur la quantité et la qualité des données partagée par des participants. Ce modèle est également utilisé dans des applications mobiles populaires telles que Waze 3 ou encore Foursquare 4 . Le modèle est basé sur le concept de récompense [69] qui peut prendre deux formes différentes. La première consiste à émuler une compétition, en effectuant un classement entre les participants. Dans ce cadre, le modèle peut être configuré par les utilisateurs, en attribuant des points selon le type de données partagées. Le deuxième permet d’attribuer des badges/trophées, en fonction du nombre de points remportés par les participants. 3. https://www.waze.com 4. https://foursquare.com 104Dans l’application mobile présentée dans le chapitre précédant, plusieurs mécanismes permettent aux participants de contrôler les données qui sont collectées par leur dispositif (cf. chapitre 3 sous-section 3.4.2, page 72 ). Ce mécanisme peut être utilisé par exemple par les participants pour empêcher l’application d’activer le GPS qui consomme beaucoup d’énergie. Dans ce cas, les utilisateurs peuvent contrebalancer l’énergie utilisée par les capteurs, et la sensibilité des données — d’un point de vue vie privée —, en attribuant plus de points selon les données collectées par les participants. Par exemple, le capteur GPS est bien connu pour fournir une grande précision pour déterminer la position d’un utilisateur, mais consomme beaucoup plus d’énergie que la géolocalisation GSM, moins précise. Dans ce contexte, pour inciter les participants à partager leurs capteurs GPS, plus de points peuvent être attribués aux données collectées par le GPS. Privacy Additionnellement, un modèle de confidentialité peut être intégré dans l’expérience de collecte. Dans ce cadre, les composants implémentant ces modèles sont responsables de l’assainissement des données reportées par les participants, avant leurs insertions dans la base de données. Actuellement nous supportons un modèle classique de perturbation [2], consistant à modifier les coordonnées spatiales et temporelles en y ajoutant une perturbation aléatoire. La perturbation est introduite par un bruit gaussien à l’intérieur d’une sphère de rayon r centré sur les coordonnées d’origine. Nous envisageons d’intégrer plusieurs modèles issus de l’état de l’art [11] tels que des modèles de dissimulation spatiale [64, 30, 62]. Collector Ce point de variabilité est responsable de la persistance ainsi que de l’indexation des données collectées dans une base de données. Actuellement, la persistance des données est effectuée avec la technologie MongoDB, une base de données non-relationnelle orientée documents. Dans notre cas d’utilisation, le principal bénéfice de cette technologie est de ne pas imposer un schéma spécifique pour sauvegarder les données. En effet, de nombreux systèmes [25, 22] utilisent des bases de données SQL qui nécessitent la définition de schéma statique pour structurer les données. Ce choix de conception limite alors la réutilisation du système nécessitant la sauvegarde de données ayant une structure non prévue dans le schéma défini au préalable. Dans ce cadre, MongoDB représente une technologie fournissant la flexibilité nécessaire pour faire face à l’hétérogénéité des données qui peuvent être collectées durant les expériences. 105Les données sont sérialisées sous la forme d’un tableau JSON. Dans ce cadre, l’utilisation du formalisme JSON fournit une grande flexibilité aux utilisateurs pour représenter les données, selon le type des capteurs impliqués dans la tâche de collecte. La structure des données est définie par les utilisateurs lors du développement de la tâche de collecte (cf. sous-section 3.3.3). Les métadonnées sont générées par l’application mobile, comportant l’identifiant unique de l’utilisateur — crée par le serveur central lors de l’enregistrement du participant dans l’expérience —, la version de la tâche de collecte ainsi que la date où les données ont été générées. Les utilisateurs ont également la possibilité de compléter ces méta-informations. Dans ce cadre, ces méta-informations peuvent être utilisées pour structurer les données dans la base de données, par exemple indexer les données par jour (caractéristique DateIndex), par utilisateur (caractéristique UserIndex) ou utiliser un index géographique (caractéristique GeoIndex) pour faciliter le traitement des données à caractère géographique. Service Le dernier point de variabilité permet de sélectionner des services responsables d’exposer les données après leurs sauvegardes dans la base de données. Actuellement, nous supportons des composants génériques qui permettent de fournir une interface web donnant un accès à la base de données (caractéristique Query), de visualiser des statistiques sur données collectées sous forme de graphe (caractéristique Chart), visualiser sous forme de carte (caractéristique Map) si l’indexation sélectionnée dans la partie précédente utilise un index géographique, ou alors d’exporter les données dans divers formats (point de variabilité Export) (c.-à-d. CSV, JSON, XML). Dans cette section, nous avons présenté notre approche pour permettre de faire à face à la diversité des campagnes de collecte qui peuvent être menées par les utilisateurs. Pour prendre en compte cette diversité, nous avons proposé de modéliser l’environnement responsable de la gestion d’une campagne comme une famille de produits à l’aide de Modèle de Caractéristique (MC). Le MC présenté permet de définir les points communs et également les différences relatives aux campagnes de collecte. Ces différences peuvent consister à utiliser différents modèles de confidentialité, de recrutement ou d’incitation selon la nature de l’expérience, choisir différentes façons pour développer les tâches de collecte selon le niveau de programmation des utilisateurs ou alors structurer et exposer les données collectées durant la campagne. Ainsi, le MC définit l’ensemble des choix présentés aux utilisateurs pour leur permettre de configurer leurs campagnes de collecte en fonction de leurs exigences. Dans la section 106suivante, nous décrivons comment un nœud de collecte génère un environnement assurant la gestion d’une campagne de collecte à partir des choix effectués par les utilisateurs et comment les utilisateurs peuvent étendre les nœuds de collecte pour faire face à des exigences non anticipées. 4.4.2 Création d’une nouvelle campagne Toutes les caractéristiques initialement introduites dans la section précédente sont associées à un composites SCA. La création d’une nouvelle campagne consiste donc à intégrer et à assembler dans l’architecture initiale du nœud de collecte (cf. figure 20) un ensemble de composite SCA. Dans ce cadre, le MC permet de spécifier l’ensemble des assemblages valides pour générer une nouvelle instance de campagne de collecte. Une fois déployé, un nœud de collecte (cf. figure 20) est composé de quatre composants génériques, dédiés à la création d’une nouvelle campagne : ExperimentManager, WebManager, ModuleManager et le ReconfigurationManager. Figure 20 – Architecture initiale d’un nœud de collecte Le point d’entrée de cette architecture est le composant ExperimentManager. Ce composant est responsable du déclenchement de la génération d’une nouvelle campagne. Pour lancer cette génération, ce dernier composant a besoin de trois informations : i) le nom de la campagne de collecte, ii) une description de l’objectif de la collecte, iii) et l’ensemble des caractéristiques sélectionnées dans le MC par les utilisateurs. La 107création d’une nouvelle campagne peut également s’effectuer à partir d’une interface web fournie par le composant WebManager. La figure 21 montre une vision simplifiée de la génération d’une nouvelle campagne. Figure 21 – Processus de génération d’une architecture SCA Une fois la sélection validée, en fonction des différentes contraintes exprimées dans le MC, le composant ExperimentManager procède alors aux téléchargements des différents composites associés aux caractéristiques sélectionnées, auprès du serveur central via le composant ModuleLibrary. Une fois les composites téléchargés, le composant ExperimentManager exploite alors les capacités d’introspection du moteur d’exécution SCA via le composant ReconfigurationManager pour instancier les composites téléchargés dans l’architecture du nœud de collecte. Par exemple, la figure 22 illustre une nouvelle instance générée à partir de la sélection des caractéristiques suivantes : CodeEditor, Individuel, Badge, Pertubation, userIndex, Query, Export-KML. Cette nouvelle instance expose ainsi de nouveaux services permettant 108Figure 22 – Architecture SCA d’une campagne de collecte 109d’éditer une tâche de collecte associée à la campagne (composant SensingTask :CodeEditor), de déployer cette tâche auprès du serveur central afin de recruter un ensemble de participants (composant Recruitement :Individuel), d’anonymiser et de sauvegarder les données collectées par les participants (composant Privacy :Perturbation et Collector :UserIndex), configurer le mécanisme de récompense (composant Incentive :Ranking) et finalement exploiter les données collecter (composant Service :Query et Service :Export :KML). Nous présentons de manière plus détaillée dans la section suivante comment ces composants interagissent entre eux lors d’une campagne de collecte configurée avec un modèle de recrutement Individuel. L’exécution d’une campagne communautaire sera décrite en section 4.5. 4.4.3 Intéraction entre les composants Après avoir présenté les différents composants logiciels formant le serveur central et les nœuds de collecte de APISENSE®, nous présentons dans cette sous-section leurs interactions. La figure 23 montre un diagramme de séquence illustrant les différents messages échangés entre les acteurs du système (c.-à-d. utilisateurs et participants) et les composants de APISENSE®, lors de l’exécution d’une campagne de collecte personnelle. Comme le montre le diagramme, la réalisation d’une campagne de collecte comporte trois phases : la création de la campagne de collecte (phase 1), le déploiement d’une tâche de collecte vers les dispositifs mobiles des participants (phase 2) et la propagation des données vers un nœud de collecte. (phase 3). phase 1 - création d’une campagne de collecte La création d’une nouvelle campagne de collecte est initiée par un utilisateur à partir de son nœud de collecte. La création de la campagne consiste à sélectionner un ensemble de caractéristiques, appartenant au MC, définissant la configuration de la campagne de collecte. À partir d’une configuration valide, le composant ExperimentManager télécharge les composants SCA associés aux caractéristiques auprès du serveur central et génère une nouvelle instance de la campagne (cf. figure 22). La nouvelle instance est un composite SCA, constitué d’un ensemble de composants qui exposent automatiquement de nouveaux services permettant le développement de la tâche de collecte (composant SensingTask), de la publier (composant Recruitment), de reporter les données collectées par les dispositifs mobiles (composant DataHandler) et de récupérer les données collectées (composant Query). 110Figure 23 – Interaction des composants APISENSE® 111phase 2 - déploiement de la tâche de collecte Une fois les services de la nouvelle campagne de collecte exposés, les utilisateurs peuvent alors développer la tâche de collecte associée à la campagne de collecte via le composant SensingTask, configurer les propriétés de déploiement de la tâche de collecte (cf. section 4.3.2) et la publier auprès du serveur central via le composant Deployment. Une fois publiée, le composant Recruitment du serveur central analyse les propriétés de la tâche de collecte et notifie tous les participants, correspondant à ces propriétés, de la disponibilité d’une nouvelle tâche de collecte est disponible. Les participants volontaires peuvent alors s’y inscrire. Dans ce cas, le dispositif mobile télécharge la tâche de collecte et l’identifiant anonyme généré lors de l’inscription qui est également partagé avec le composant ExperimentManager du nœud de collecte. Une fois téléchargée, la tâche de collecte est alors exécutée sur le dispositif mobile. phase 3 - propagation des données La dernière phase consiste à reporter les données collectées durant l’exécution de la tâche de collecte. Les données sont directement reportées auprès du composant DataHandler du nœud de collecte ayant initié la tâche de collecte. Lors de la propagation des données, l’identifiant anonyme est également envoyé, permettant au nœud de collecte de vérifier si les données proviennent bien d’un utilisateur inscrit à l’expérience. Si l’identifiant est valide, le composant DataHandler fait appel au composant Privacy qui est responsable de l’assainissement des données, avant leur sauvegarde et leur indexation dans la base de données via le composant Collector. Les utilisateurs peuvent alors accéder aux données sauvegardées, exporter les données collectées, et également retourner à la phase 2 afin de modifier le comportement de la tâche de collecte en fonction des résultats observés. Nous venons de décrire l’ensemble des interactions des composants APISENSE® permettant la réalisation d’une campagne de collecte de données. La section suivante présente le mécanisme d’extension de APISENSE® permettant le développement et l’intégration de nouveau composant dans la plate-forme. 4.4.4 Extension des nœuds de collecte En définissant un nœud de collecte comme une application SCA, nous bénéficions aussi de sa modularité pour facilement étendre la plate-forme. Dans cette sous-section, nous présentons comment de nouveaux services peuvent être ajoutés à un nœud de 112collecte. L’ajout d’un nouveau service est effectué à partir d’une archive ZIP, que nous appellerons une contribution. Comme le montre l’exemple illustré par la figure 24, une contribution contient la description d’une caractéristique, associée à un composite SCA, ainsi que l’ensemble des artéfacts implémentant le composite (c.-à-d. code compilé, scripts). La contribution présentée vise donc à ajouter un nouveau service responsable d’exporter les données collectées sous le format KML 5 , un format d’encodage utilisant le formalisme XML destiné à la gestion de l’affichage de données géospatiales dans les systèmes d’information géographique. Dans ce cadre, le premier élément vise à définir la contribution comme une caracté- ristique s’inscrivant dans le MC général présenté en sous-section 4.4.1. La description de la caractéristique définit donc le nœud parent (c.-à-d. caractéristique Export dans l’exemple), identifiant un nouveau point de variabilité, les caractéristiques requises, et le composite SCA associé. Dans cet exemple, le composite définit un nouveau service (c.-à-d. export service), exposé comme une ressource REST. Afin de récupérer les données collectées, le composant déclare une référence vers un composant fournissant un service de requête vers la base de données. Et finalement, le composant, déclare son implémentation comme étant une implémentation en Java. Les nœuds de collecte et le serveur central fournissent un service dédié aux déploiements de nouvelles contributions. Dans ce cadre, un utilisateur peut déployer une contribution directement dans son nœud de collecte, ou directement sur le serveur central pour la partager avec les autres utilisateurs du système. 4.5 campagne de collecte communautaire Dans la section précédente, nous avons présenté les principaux composants des nœuds de collecte et plus particulièrement comment ces composants peuvent être assemblés pour créer des services dédiés à une campagne de collecte spécifique. Nous avons également présenté le premier modèle de recrutement Individuel, où le recrutement est basé uniquement sur les propriétés des participants. Dans cette section, nous décrivons le modèle de recrutement Communautaire. Ce type de campagne, également appelé public sensing dans la littérature [33], consiste à collecter continuellement des données relatives à l’environnement des participants (par ex. bruit ambiant, qualité réseaux, pollution de l’air) dans une zone géographique [47, 63, 50]. 5. https://developers.google.com/kml/documentation 113Figure 24 – Exemple d’extension : Export des données au format KML 114Typiquement, une approche couramment utilisée dans ce type de campagne consiste à impliquer un maximum de dispositifs mobiles dans la collecte de données. Cependant, ces dispositifs collectent périodiquement (c.-à-d. toutes les x secondes) ces données environnementales sans prendre en considération si un autre nœud mobile placé à proximité collecte les mêmes données [27]. Cette approche naïve peut s’avérer inef- ficace principalement pour deux raisons. La première est qu’elle peut impliquer la remontée d’une grande quantité de données similaires, en particulier en milieu urbain ou une forte concentration d’utilisateurs (c.-à-d. situés à proximité) peuvent collecter simultanément ces données identiques. Cela demande par conséquent beaucoup plus de ressources côté serveur pour stocker ces données et les analyser. La seconde est qu’elle implique également une grande perte énergétique des appareils mobiles qui collectent ces données similaires. Récemment, Sheng et al. [59] ont montré qu’effectuer une collaboration entre les dispositifs, en fonction d’un objectif de couverture de la zone à observer, pouvait radicalement diminuer l’énergie consommée par l’ensemble des dispositifs, et par conséquent diminuer également le volume de données transmises sur le serveur. Dans ce cas, les objectifs de couverture définissent uniquement la quantité de données nécessaire pour la campagne, permettant de faire un compromis entre la quantité des données collectées, et le coût énergétique liée à leurs acquisitions. Pour effectuer la collaboration, cette approche fais l’hypothèse que les trajets de chaque appareil mobile est connue à l’avance. À partir de ces trajets, l’algorithme proposé dans cette approche permet d’assimiler les tâches de collecte uniquement aux mobiles capables de couvrir les objectifs de couvertures définis au préalable . Cependant, faire l’hypothèse que la mobilité de chaque appareil mobile est connue à l’avance peut être difficilement appliqué en déploiement réel, dû à la difficulté de prédire les trajectoires des participants [60]. Dans ce contexte, nous présentons dans cette section un modèle de recrutement collaboratif, permettant de coordonner l’exécution des tâches de collecte sans avoir une connaissance au préalable de la mobilité des participants. Le modèle proposé a pour objectif dans un premier temps de diminuer la consommation énergétique globale de tous les dispositifs impliqués dans la campagne, et également de diminuer la quantité de données propagées vers le nœud de collecte. Dans notre architecture, ce modèle est assuré par le composant associé à la caractéristique Collaboration du MC présentée en sous-section 4.4.1. Pour assurer la coordination des tâches, le composant se base sur des propriétés de couverture géographique et temporelle décrites par les utilisateurs, leur permettant de définir seulement la quantité de données nécessaires pour leur 115campagne. Pour définir ces propriétés, ainsi que différentes exigences en relation avec leur campagne, nous proposons une interface de programmation complémentaire à celle présentée dans le chapitre précédent (cf. section 3.3). Dans la suite de cette section, nous présentons tout d’abord l’interface de programmation proposée suivie d’un exemple de campagne de collecte développée avec cette interface. Nous présentons par la suite les différents processus assurant l’exécution ainsi que la coordination des ces campagnes de collecte. 4.5.1 Extension du modèle de programmation Dans cette section, nous présentons l’interface de programmation dédié à la définition de campagne de collecte de données communautaire. La table 11 illustre les principales fonctions proposées par cette interface. Phase Méthode Description Collecte sense(callback : function()) Enregistrement d’une tâche de collecte Recrutement accept(function()) Définition des dispositifs autorisés à exécuter une tâche ranking(function(users)) Classement des dispositifs prioritaires pour l’exécution de la tâche Couverture geoCoverage(bound : Array, coverage : String) Définition des propriétés de couverture géographique timeCoverage(during : Number, every : Number) Définition des propriétés de couverture temporelle duplicate(n : Number) Nombre de dispositifs attribués à une tâche selon les propriétés de couverture. Table 11 – Interface de programmation dédiée à la définition des campagnes de collecte communautaires. Typiquement, la définition d’une campagne de collecte communautaire comprend trois phases : collecte, recrutement, couverture. collecte : La première phase consiste à enregistrer la tâche de collecte qui sera distribuée auprès des nœuds mobiles. La tâche de collecte décrit les données qui doivent être collectées et reportées par les nœuds mobiles (cf. section 3.3, page 59 ). L’enregistrement de celle-ci est effectué en insérant une fonction de rappel 116à la méthode sense. Cette tâche sera ensuite exécutée par les nœuds mobiles lorsqu’ils seront assignés à celle-ci. recrutement : La deuxième phase consiste à définir la stratégie de recrutement des nœuds mobiles. Cette phase permet de filtrer les nœuds mobiles, ou d’en privilégier certains en fonction de leur contexte lors de l’attribution de la tâche de collecte. Par exemple, cela permet de baser le recrutement sur certains attributs (par ex. type de connexion réseaux, vitesse de déplacement), ou de privilégier les nœuds mobiles ayant le niveau de batterie le plus élevé. Le filtrage des nœuds mobiles consiste à enregistrer une fonction de rappel à la méthode accept. Cette fonction sera exécutée par les nœuds mobiles avant l’attribution de la tâche de collecte à un ou plusieurs nœuds. Cette fonction a pour objectif d’observer le contexte du nœud mobile, et définir si celui-ci est autorisé à exécuter la tâche. Dans ce cas, cette fonction doit retourner une liste de propriétés (par ex. niveau de batterie, vitesse de déplacement, qualité du signal réseau), dans le cas contraire, elle doit retourner une valeur nulle. La méthode ranking permet de privilégier certains nœuds mobiles pour exécuter une tâche de collecte, basée sur les propriétés retournées par la méthode accept. couverture : La troisième phase permet de définir les objectifs de couverture temporelle et géographique de la campagne de collecte. Cela permet par exemple de faire un compromis entre le coût énergétique utilisé par l’ensemble de nœuds mobiles, et la quantité de données reportées pendant la campagne. L’objectif de couverture temporelle peut être défini par la méthode timeCoverage, qui prend deux paramètres. Ces deux paramètres permettent de spécifier pendant combien de temps la tâche de collecte doit être exécutée et à quelle fréquence (par ex. exécuter la tâche pendant 30 minutes toutes les heures). L’objectif de couverture géographique peut être défini par la méthode geoCoverage, qui prend également deux paramètres. Ces paramètres permettent de spécifier la zone géographique globale de la campagne et à quelle granularité la tâche de collecte doit être distribuée (par ex. exécuter la tâche dans la ville de Paris tous les 500 mètres). La méthode duplicate permet de définir le nombre de dispositifs attribués à la tâche de collecte en fonction des propriétés de couvertures. Exemple d’application Afin de mieux illustrer le modèle de programmation proposé, nous présentons ici un exemple de campagne de collecte de données. Nous utiliserons également cet exemple comme un fil conducteur tout au long de cette section. Dans cette campagne, décrites par le listing 4.1, nous voulons mettre en place une collecte de 117données permettant d’élaborer une cartographie représentant la qualité des réseaux GSM en fonction des opérateurs des réseaux mobiles dans la ville de Paris. La première phase consiste à enregistrer la tâche de collecte de cette campagne (ligne 2-9). La tâche de collecte consiste à exécuter 10 Ping (Packet INternet Groper) réseaux à une machine distante particulière lorsque le participant a changé de position (ligne 3), et à collecté la latence moyenne des requêtes effectuées (ligne 7), la position de l’utilisateur (ligne 6) ainsi que son opérateur de réseau mobile (ligne 5). La deuxième phase consiste à définir la stratégie de recrutement des utilisateurs. Dans cette phase, nous voulons recruter uniquement les participants disposant d’une connexion de données mobiles (ligne 13). Pour les participants ayant ce type de connexion, nous renvoyons le niveau actuel de leur batterie pour pouvoir privilé- gier l’attribution de la tâches de collecte au participant disposant du niveau de batterie le plus élevé (ligne 18-20). Dans le cas contraire, le participant n’est pas autorisé à exécuter la tâche de collecte. Dans la troisième phase, nous définissons les propriétés de couverture pour optimiser l’énergie utilisée par l’ensemble des dispositifs mobile, et minimiser la quantité de données reportées sur le serveur. Pour cela, nous définissons que la tâche de collecte doit être exécutée au maximum par deux participants (ligne 25) répartis tous les cinqcents mètres dans la ville de Paris (ligne 23), et que la tâche doit être exécutée pendant trente minutes toutes les heures (ligne 24). 1 // phase 1 : définition de la tâche de collecte 2 sense(function() { 3 $location.onLocationChanged(function(event) { 4 $trace.add({ 5 operator : $telephony.operator(), 6 loc: [event.latitude, event.longitude], 7 latency : $network.ping(10,"http://...").average}); 8 })} 9 }) 10 11 // phase 2 : définition de la stratégie de recrutement 12 accept(function(){ 13 if (network.connectionType() != "WIFI"){ 14 15 return {battery : $battery.level()} 16 }else return undefined 17 }) 18 ranking(function(users){ 19 return users.sort("battery").select(); 20 }) 21 22 //phase 3 : définition des objectifs de couverture 11823 geoCoverage([[50.614291,3.13282],[50.604159,3.15239]],"500 m") 24 timeCoverage("30 min","1 H") 25 duplicate(2) Listing 4.1 – Tâche de collecte : Observer la qualité réseau Dans cette section, nous avons présenté le modèle de programmation proposé pour définir des campagnes de collecte supportant la collecte collaborative de données. Nous décrivons dans la suite de cette section comment ces campagnes sont exécutées par les nœuds de collecte. 4.5.2 Coordonner l’exécution des tâches de collecte Dans cette section, nous décrivons le modèle et les algorithmes mis en œuvre pour supporter la coordination des tâches de collecte en fonction des propriétés de couvertures géographique et temporelle. Le principal défi qui doit être adressé pour mettre en œuvre une coordination optimisée est de permettre au nœud de collecte d’avoir une vision aussi précise que possible de la réparation géographique des nœuds mobiles disponibles. Cependant, en utilisant une approche naïve qui consisterait à reporter continuellement la position des dispositifs mobiles vers le serveur ne seraient pas efficace pour plusieurs raisons. Premièrement, cela pourrait engendrer un trafic trop important de messages échangés entre les nœuds mobiles et le serveur, spécialement si de nombreux mobiles sont impliqués dans la campagne. Deuxièmement, cela impliquerait une trop grande consommation énergique des nœuds mobiles, dû à l’activation constante de capteur comme le GPS. Et finalement, classifier les nœuds mobiles en fonction de leur distance les uns par rapport aux autres, en utilisant des algorithmes de clustering [31] par example, entraînerait un surcharge du serveur, spécialement si cette classification doit être effectuée en permanence sur un grand volume de données. Pour adresser ce défi, nous avons adopté pour une approche de virtualisation de capteur, initialement proposée dans les réseaux de capteurs (WSNs). [10]. Typiquement, la virtualisation consiste à rajouter une couche logicielle abstraite, appelée couche virtuelle, composée d’un ensemble de capteurs virtuels, superposée à une couche physique. Un capteur virtuel est une entité logicielle autonome, responsable de gérer le flux de messages entre le serveur et un groupe de capteurs caractérisés par des propriétés communes (par ex. zone géographique, type de capteurs). Dans notre approche, l’idée 119principale est de diviser la zone globale de collecte en plusieurs zone géographiques en fonction des propriétés de couverture géographique de la campagne de collecte. Pour chaque zone, nous attribuons un capteur virtuel qui sera responsable de coordonner l’exécution des tâches entre les nœuds mobiles situé dans sa zone. Dans ce contexte, les nœuds mobiles ont uniquement besoin de partager leur position lorsqu’ils entrent ou sortent de la zone gérée par un capteur virtuel. Le composant responsable de l’exécution des campagnes de collecte communautaire et de la gestion des capteurs virtuels est le composite Recruitment :Collaborative (cf. figure 25). Ce composant est associé à la caractéristique Collaborative du point de variabilité Recruitement dans le modèle de caractéristiques présenté en sous-section 4.4.1. Figure 25 – Composant SCA responsable du recrutement collaboratif Ce composite est constitué des trois composants : i) ScriptEngine responsable de l’exécution du script JavaScript définissant la campagne de collecte, ii) VSManager responsable de la création et la gestion des capteurs virtuels et iii) Deployment responsable d’interagir avec le serveur central pour déployer les scripts auprès des nœuds mobiles. L’exécution d’une campagne communautaire comprend trois phases : i) la phase de génération des capteurs virtuels, ii) la phase de connexion des nœuds mobiles avec les capteurs virtuels, iii) et la phase de coordination de l’exécution des tâches de collecte. Nous décrivons à présent l’ensemble de ces étapes. Phase 1 : Génération des capteurs virtuels L’objectif ici est de générer un ensemble de capteurs virtuels responsables de coordonner l’exécution des tâches de collecte entre les nœuds mobiles. La génération de ces capteurs virtuels est assurée par le composant VSManager. Chaque capteur virtuel est caractérisé par une propriété définissant la zone géographique incluse dans la zone 120globale de collecte des données. La génération de ces capteurs est effectuée à partir de la méthode geoCoverage(bound,coverage) de l’interface de programmation, définissant la zone géographique globale de la collecte (paramètre bound), et la taille de la zone gérée par un capteur virtuel (paramètre coverage). À partir de ces paramètres, le composant VSManager génère et instancie un ensemble de capteurs virtuels, et les distribue pour couvrir l’intégralité de la zone globale de collecte (cf. figure 26). Typiquement, un capteur virtuel est un composite SCA disposant de deux services : composant RegistrationService et CoordinationService. Le premier service est dédié à l’enregistrement des nœuds mobiles. Ce service est exposé en tant que ressource REST, accessible à partir d’une URL générée à partir de la zone géographique dont il est responsable. Dans ce cas, les nœuds mobiles sont responsables de s’enregistrer auprès du capteur virtuel en fonction de leur position. Le deuxième service est responsable d’attribuer une tâche de collecte à un ou plusieurs nœuds mobiles qui se sont enregistrés au préalable. Nous détaillons ces différents points dans les section suivantes. Figure 26 – Distribution des capteurs virtuels Phase 2 : Connexion des appareils mobiles et des capteurs virtuels La deuxième phase consiste à établir une connexion entre les nœuds mobiles et les capteurs virtuels. Pour établir cette connexion, les nœuds mobiles ont tout d’abord besoin de télécharger la tâche de collecte auprès du serveur central. Le déploiement de la tâche de collecte vers le serveur central, assurée par le composant DeploymentService, 121suit le même procédé qui celui présenté en sous-section 4.4.4. Comme le montre la figure 26, la tâche de collecte comporte deux fichiers JavaScript : sense.js correspondant au code JavaScript responsable de la collecte des données (ligne 3-8 dans l’exemple décrit par le listing 4.1), et VSmonitoring.js. Dans un premier temps, seulement le fichier VSmonitoring.js est exécuté. Ce dernier script télécharge dans un premier temps l’ensemble des propriétés des capteurs virtuels générés (c.-à-d. zone géographique et l’URL du service d’enregistrement). À partir de ces propriétés, ce script observe continuellement la position du nœud mobile pour déterminer la présence du nœud mobile se situe dans une zone gérée par un capteur virtuel, et est responsable de l’enregistrement et du dé-enregistrement auprès du capteur virtuel associé. En ce qui concerne la surveillance de la position du nœud mobile, nous utilisons un algorithme couramment utilisé dans la littérature pour déterminer si un dispositif se trouve dans une zone spécifique, tout en minimisant le coût énergétique. Typiquement, l’idée principale derrière est i) d’utiliser alternativement les différents mécanismes permettant de déterminer la position d’un utilisateur — entre le GPS fournissant une grande précision, mais consommant beaucoup d’énergie, et le réseau qui, au contraire, consomme moins d’énergie, mais est beaucoup moins précis —, ii) et la fréquence d’échantillonnage en fonction de la distance entre l’utilisateur et le capteur virtuel le plus proche de sa position actuelle. Phase 3 : Coordonner l’exécution des tâches de collecte Dans cette section, nous présentons l’algorithme utilisé par les capteurs virtuel pour coordonner l’exécution des tâches de collecte entre les nœuds mobiles enregistrés auprès d’un capteur virtuel. Le principal défi dans cette partie est de faire face à la connectivité imprévisible des nœuds mobiles. En effet, on ne peut pas partir du postula que tous les nœuds enregistrés sont réellement disponibles pour exécuter une tâche. De nombreux phénomènes peuvent empêcher les nœuds mobiles d’avertir un capteur virtuel qu’ils ne sont plus disponibles, comme la perte d’un signal réseau, un épuisement complet de la batterie ou tout simplement l’extinction du téléphone mobile par le participant. Pour prendre en considération ces phénomènes, l’idée principale de notre approche consiste à dupliquer le nombre de nœuds mobiles assignés à une tâche de collecte, et à intégrer une phase de demande d’exécution afin d’éviter d’avoir à assigner une tâche à un nœud qui n’a pas annulé son enregistrement au capteur virtuel. 122L’algorithme (cf. algorithme 1) est déclenché périodiquement en fonction des propriétés de couverture temporelle qui peuvent être définies par l’interface de programmation avec la méthode geoCoverage(duration,every). Algorithm 1 Algorithme de coordination des tâches de collecte Require: connectedDevices : List of connected devices activeDevices : List of activated devices t : Time threshold Task(tstart,tend) : Temporal properties of the sensing task duplicate : Maximum number of devices to assign the sensing task if (size(activeDevices) < duplicate) then candidates ⇐ connectedDevices − activeDevices if notEmpty(candidates) then availableCandidates ⇐  broadcastTaskRequestEvent(candidates) repeat receive(Device(id, n)) add(availableCandidates,Device(id, properties)) until timeout t is reached for (i = 0 → (size(activeDevices) − duplicate))) do device ⇐ ranking(availableCandidates) activeDevices ⇐ device + activeDevices availableCandidates ⇐ availableCandidates − device broadcastTaskExecutionRequest(device, tstart, tstop) end for end if end if L’algorithme vérifie tout d’abord si le nombre de dispositifs mobile déjà assigné à une tâche (size(activeDevice)) est inférieur à la propriété de duplication. Dans ce cas, nous définissons une liste candidate comme un ensemble de dispositifs connectés et n’exécutant pas actuellement une tâche de collecte. Pour tous les candidats, un message leur est envoyées avec la fonction de recrutement définie par l’interface de programmation (ligne 12-17 dans l’exemple du listing 4.1), — dans notre exemple, nous voulons recruter uniquement les nœuds mobiles disposant d’une connexion GSM —. Le capteur virtuel attend ensuite un temps t la réponse des dispositifs mobiles. Les nœuds correspondant à la méthode de recrutement répondent ensuite au capteur virtuel avec un ensemble de propriétés indiquant leurs états actuels (par ex. niveau de 123batterie, type de connexion de données). Ces nœuds sont ensuite ajoutés à une liste indiquant leurs disponibilités pour exécuter la tâche de collecte. Ces nœuds sont ensuite classifiés par la méthode ranking. Cette méthode correspond à celle définie par l’interface de programmation (ligne 18-20 du listing 4.1), permettant de privilégier certains nœuds par rapport à leurs propriétés. Dans notre exemple, nous privilégions les noeuds mobiles disposant du niveau de batterie le plus élevé. À la fin du processus, un nouveau message est envoyé aux nœuds mobiles leur demandant d’exécuter la tâche de collecte. Les noeuds mobiles recevant ce message démarrent l’exécution de la tâche de collecte jusqu’à la date définie par tend ou lorsque les nœuds quittent de la zone gérée par le capteur virtuel. Cela permet de réattribuer la tâche de collecte à un autre nœud. À la fin de l’exécution, toutes les données collectées sont ensuite propagées directement sur le nœud de collecte. 4.6 conclusion APISENSE® propose un environnement facilitant la gestion de campagnes de collecte de données. Pour supporter une grande diversité de campagne de collecte, nous avons proposé un modèle permettant de configurer un environnement serveur (c.-à-d. honey) responsable de l’exécution d’une campagne de collecte. Ainsi, ce modèle est utilisé pour configurer les services d’un nœud de collecte en fonction des spécificités des campagnes de collecte. Cette configuration comprends cinq points : i) configurer l’environnement de développement des tâches de collecte, ii) choisir un modèle de recrutement des participants, iii) choisir une série de traitements sur les données collectées avant leur insertion dans la base de données (par ex. anonymisation des données), iv) spécifier l’indexation des données dans la base de données, v) exposer des services pour exploiter les données collectées. À partir de ce modèle, un nœud de collecte peut être ensuite généré et déployé par les utilisateurs vers une infrastructure qui peut être publique ou privée selon la nature des données collectées. Cela leur permet de garder un contrôle total sur l’infrastructure hébergeant les données collectées durant leurs campagnes. APISENSE® se distingue également par son architecture décentralisée, permettant d’améliorer le passage à l’échelle du système. Son architecture est ainsi composée d’un ensemble de nœuds de collecte organisé autour du serveur central. Concernant le serveur central, son principal objectif est d’assurer le déploiement des tâches de 124collecte soumises par les nœuds de collecte vers les participants de la plate-forme qui se sont enregistrée au préalable. Ce procédé a principalement deux avantages. Le premier est d’assurer une première couche d’anonymat des participants, dans le sens où tous les nœuds de collecte ne peuvent pas déployer les tâches de collecte sans passer par le serveur central. Le deuxième permet aux nouveaux utilisateurs de bénéficier d’un ensemble de participants déjà disponibles pour exécuter des tâches de collecte, leur évitant ainsi une longue période de recrutement. Finalement, nous avons proposé une extension de APISENSE® dédiée à l’optimisation de l’exécution de campagne de collecte communautaire. L’optimisation proposée permet de coordonner l’exécution des tâches de collecte entre les dispositifs mobiles en fonction de propriétés de couvertures géographique et temporelle. Principalement, cette optimisation a pour objectif dans un premier temps de diminuer la consommation énergétique globale de tous les dispositifs impliqués dans la campagne, et également de diminuer la quantité de données propagées vers le nœud de collecte. La description des contributions de ce manuscrit est à présent terminée. Dans les chapitres suivants, nous présentons les évaluations de la plate-forme APISENSE®. 125Troisième partie Évaluations 1275 P R AT I Q U E S C U LT U R E L L E S E T U S A G E S D E L’ I N F O RM AT I Q U E C O N N E C T É E Sommaire 5.1 Introduction 130 5.2 Contexte et objectif de l’étude PRACTIC 130 5.3 Développement de l’étude PRACTIC 131 5.3.1 Collecte opportuniste 132 5.3.2 Collecte participative 135 5.3.3 Retour utilisateur 136 5.3.4 Discussions 136 5.4 Déploiement de l’étude PRACTIC 139 5.4.1 Protocole du déploiement 139 5.4.2 Participation 140 5.5 Conclusion 143 Dans cette partie, nous présentons les évaluations de la plate-forme APISENSE® en deux chapitres. Dans le premier chapitre, nous présentons une campagne de collecte déployée auprès d’une centaine d’utilisateurs, réalisée au sein de l’étude PRATIC (Pratiques Culturelles et Usages de l’Informatique Connectée). Ce chapitre a pour objectif de montrer le gain en terme de coût de développement apporté par notre plate-forme, et également de montrer la faisabilité de notre approche dans un cas réel d’utilisation. Le deuxième chapitre évalue le passage à l’échelle de APISENSE® pour la réalisation de campagne de collecte communautaire. Nous évaluons notamment le gain du modèle de recrutement collaboratif, permettant de faire un compromis entre l’énergie consommée par les dispositifs mobiles et la quantité de données générées tout en gardant une bonne couverture de collecte. 1295.1 introduction Dans la partie précédente de ce manuscrit, nous avons présenté en intégralité APISENSE®, la plate-forme résultante des travaux de cette thèse. Comme nous l’avons déjà évoqué, le principal objectif de cette thèse est d’ouvrir l’accès du Mobile Crowd Sensing à de nombreux acteurs privés ou académiques, en leur permettant de facilement développer et déployer leurs campagnes de collecte de données. Dans ce chapitre, nous présentons une campagne réalisée au sein d’une étude sociologique nommée PRACTIC 1 (Pratiques Culturelles et Usages de l’Informatique Connectée), qui vise à comprendre l’usage des technologies numériques connectées en matière d’habitudes et de routines de consommations culturelle et médiatique. Cette étude a été réalisée par une équipe pluridisciplinaire, composée de deux ingénieurs en informatique pour le développement des scripts de collecte, et deux chercheurs en sciences de l’information et de la communication pour l’interprétation des données collectées. Par le biais de la description de cette étude, nous cherchons tout d’abord à montrer la faisabilité de notre approche pour être utilisée dans un cas réel d’utilisation, et plus particulièrement évaluer le gain en terme de cout de développement apporté par APISENSE®. 5.2 contexte et objectif de l’étude practic Le principe de l’étude PRACTIC est né de notre rencontre avec des chercheurs en sociologie, dans le cadre du projet de l’Observatoire Scientifique de l’Internet 2 initié par INRIA 3 . Un premier objectif de cette collaboration est de voir en quelle mesure les nouveaux mécanismes de collecte de données, comme le Mobile Crowd Sensing, peuvent augmenter les méthodes traditionnelles de la recherche numérique en sciences sociales. En effet, de nos jours, la nouvelle génération des terminaux intelligents comme les tablettes ou les smartphones sont fortement intégrés dans la vie sociale et culturelle des individus. Cette intégration représente de nouvelles opportunités pour les sciences sociales, qui peuvent ainsi collecter massivement et sur le long terme, des données comportementales des individus de manière non intrusive. De plus, cela nous a permis de confronter notre plate-forme à un déploiement réel, et d’être utilisée par des personnes tierces à notre équipe. 1. http ://beta.apisense.fr/practic 2. http ://metroscope.org/ 3. www.inira.fr 130L’étude PRACTIC est composée majoritaire de deux phases. La première est une phase de collecte de données auprès d’un ensemble de participants volontaires, combinant les collectes de données opportuniste et participative (c.-à-d. questionnaire). Dans le cadre de PRACTIC, la confrontation de la collecte opportuniste et participative permet de mesurer l’écart entre la représentation des individus sur l’utilisation de leur smartphone et leur pratique effective. La seconde phase comprend des traitements statistiques sur les données collectées qui aboutiront sur quelques entretiens individuels. Dans ce chapitre, nous décrivons uniquement la première phase de l’étude qui est directement en relation avec la plate-forme APISENSE®. Nous décrivons à présent le développement de cette phase de collecte. 5.3 développement de l’étude practic La phase de collecte a entièrement été développée par APISENSE®, en utilisant son modèle de programmation (cf. chapitre 3 section 3.3) pour la description des données collectées sur les environnements mobiles, et un nœud de collecte déployé sur un serveur privé pour la persistance des données. Cette phase a été développée par un Ingénieur Jeune Diplômé (IDJ) en informatique, intégré pour les besoins de l’étude, qui n’avait aucune compétence particulière en programmation mobile au début du développement. L’application PRACTIC a d’abord connu plusieurs phases de test auprès d’un sous ensemble de participants. Ces différentes itérations ont permis d’identifier certains bugs, et d’ajouter des fonctionnalités non anticipées qui ont permis de consolider APISENSE® et l’enquête. Durant cette phase de test, l’ingénieur en question été responsable de faire la transition entre les exigences des sociologues, et les capacités offertes par notre plate-forme. La figure 27 illustre les principales données collectées par l’application PRACTIC. Un aspect intéressant ici est qu’elle utilise un large éventail des fonctionnalités proposées par APISENSE®. La collecte de données comprend principalement trois parties différentes que sont la collecte opportuniste de données, la collecte participative et les retours utilisateurs, correspondant respectivement à plusieurs scripts de collecte. Nous décrivons à présent brièvement ces différents points, et comparons à la fin de cette section le gain en terme de coût de développement apporté par notre modèle de programmation. 131Figure 27 – Données collectées par l’étude PRACTIC 5.3.1 Collecte opportuniste La première partie vise à collecter la diversité des rythmes de vie ainsi que des usages sociaux ou culturels des dispositifs mobiles. Toutes ces données sont collectées automatiquement par l’application sans nécessiter une intervention des participants. Typiquement, trois types de données sont collectées : Contenu Mobile, Activité de l’utilisateur, et Contexte mobile. Chaque type de données correspond à un script de collecte spécifique. Nous présentons brièvement un exemple simplifié des scripts de collecte développés. Contenu Mobile Le contenu mobile (cf. listing 5.1) vise à identifier des profils culturels des participants en fonction du contenu de leur appareil mobile. Dans le cadre de PRACTIC, la dimension culturelle est vue à deux niveaux : le type des applications mobiles installées (c.-à-d. jeux,divertissement, communication), les genres musicaux des participants. Le listing 5.1 décrit le script de collecte associé. La première partie du script (ligne 1-6) est déclenchée une seule fois lors de la première exécution du script. Dans cette partie, un ensemble de méta-données est collecté comprenant la liste des applications installées (nom, date d’installation, catégorie), et celle des fichiers musicaux présents (nom, artiste, format d’encodage, taille en Ko). La deuxième partie vise à identifier les cycles d’installation et de désinstallation des applications. Cette partie est réalisée 132automatiquement lorsqu’un événement concernant l’installation ou la désinstallation est déclenchée par le système mobile. 1 $schedule.once(function(){ 2 // store media files meta-data 3 $trace.add($media.getAudioFiles()); 4 // store installed applications meta-data 5 $trace.add($app.getLaunchableApplications()); 6 }); 7 8 $app.onAppInstallEvent(function(app){ 9 // store new installed or uninstalled application meta-data 10 $trace.add(app); 11 }); Listing 5.1 – Collecte du contenu mobile Activité utilisateur Cette partie vise à collecter les différents rythmes de vie et d’usages des dispositifs mobiles. Les usages sont principalement séparés en deux catégories correspondant aux usages natifs des téléphones mobiles (c.-à-d. appels et SMS) et les nouveaux usages introduis par la nouvelle génération des terminaux intelligents. Le listing 5.2 décrit l’utilisation de la façade $phone permettant de collecter des données sur les appels et les SMS émis et reçus. Pour des raisons de confidentialité, le contenu des appels et des SMS ainsi que l’identifiant des correspondants ne sont pas accessibles à partir des scripts. Seules la durée des communications ainsi que la taille des SMS sont disponibles. 1 $phone.onCallCompleted(function(call){ $trace.add(call) }); 2 3 $phone.onSMS(function(sms){ $trace.add(sms) }) Listing 5.2 – Collecte des usages natifs des dispositifs mobile La deuxième catégorie, illustrée par le listing 5.4 identifie les sessions d’utilisation des dispositifs. Celles-ci comprennent les sessions générales d’utilisations (écran allumé et éteint) et les sessions d’utilisation des applications. L’identification des sessions générales peut être effectuée par le biais de la façade $screen permettant d’intercepter les événements liés à l’écran du dispositif (lignes 2 et 22). Une session commence lorsque l’événement onScreenOn est déclenché. À la suite de cet événement, le script vérifie toutes les secondes (ligne 5) l’application exécutée en premier plan du dispositif (ligne 6), et collecte une session applicative lorsque l’application détectée est différente de la précédente (lignes 7-20). La session générale se termine lorsque l’événement 133onScreenOff est déclenché, dans ce cas la vérification des applications exécutées en premier plan est annulée (ligne 30), et cela déclenche également une nouvelle collecte de données correspondant à la durée de la session générale (lignes 25-29). 1 var subscription,startSession,subscription,appName,startApp; 2 $screen.onScreenOn(function(screen){ 3 4 startSession = screen.time; 5 subscription = $schedule.every("1 s",function(event){ 6 var currentApp = $app.currentApplicationName(); 7 if (appName != currentApp){ 8 9 appName = currentApp; 10 startApp = event.time; 11 12 // store application session 13 $trace.add({ 14 event : "ApplicationSession", 15 start : startApp, 16 end : event.time, 17 name : appName 18 }); 19 }; 20 }); 21 }); 22 $screen.onScreenOff(function(event){ 23 24 // store screen session 25 $trace.add({ 26 event : "ScreenSession", 27 start : startSession, 28 end : event.time 29 }); 30 subscription.suspend(); 31 }); Listing 5.3 – Collecte des usages des applications mobile Contexte mobile Finalement, la dernière catégorie des données collectées permet de mettre en perspective l’utilisation des applications et leurs contextes (cf. listing 5.4). Cela permet d’identifier par exemple si certaines applications sont utilisées uniquement lorsque le participant se trouve à son domicile ou sur son lieu de travail,ou encore d’observer si la qualité du réseau ou le niveau de batterie influe sur l’utilisation de certaines applications. Cette catégorie comprend les cycles de chargement et le niveau de la batterie (lignes 10-12), le contexte réseau (ligne 7-9) constitué du type de connexion 134de données (c.-à-d. Wi-Fi, 3G/4G), et de la force du signal réseau GSM (lignes 1-6). Pour déterminer si l’utilisateur est en situation de mobilité, le choix a été fait de collecter uniquement les identifiants des antennes cellulaires, qui permettent d’avoir une approximation de la localisation du participant sans entraîner une consommation énergétique supplémentaire de l’application mobile [65]. 1 $telephony.onSignalStrengthChanged(function(signal){ 2 $trace.add({ 3 level : signal.level, 4 cellId : $telephony.cellId() 5 }); 6 }); 7 $network.onNetworkStateChange(function(networkEvent){ 8 $trace.add(networkEvent); 9 }); 10 $battery.onBatteryStateChange(function(batteryEvent){ 11 $trace.add(batteryEvent); 12 }); Listing 5.4 – Collecte des usages des applications mobiles 5.3.2 Collecte participative Le questionnaire vise à collecter des données déclaratives sur l’équipement, les usages et le rapport à la vie privée des participants. Il est composé de 152 questions, dont certaines ne sont pas obligatoires. Par exemple, dans la partie des usages, le fait de ne pas posséder une tablette par exemple permet de ne pas répondre à un sous-groupe de questions. Entre 20 et 30 minutes sont nécessaires pour répondre intégralement au questionnaire. Les questions sont organisées au sein de quatre grandes parties : à propos de vous (16 questions), équipements (36), pratiques culturelles et usage de l’informatique connectée (60) et publicité en ligne et privée (19). Le questionnaire peut être complété à tout moment par les participants à partir de leurs dispositifs. Le listing 5.5 montre une très brève partie du questionnaire développé. Typiquement, les réponses du questionnaire vont être croisées par les sociologues avec les données collectées automatiquement par l’application. 1 var survey = $survey.create("PRACTIC"); 2 // ... 3 var q88 = survey.close("Quel est le lecteur musical que vous utilisez le plus ?",[ 4 "Chaine Hi-Fi / Platine Vinyle", 5 "Baladeur/MP3", 1356 "Smartphone", 7 "L’ordinateur (musique enregistrée sur le disque dur ou CD)", 8 "La radio", 9 "La television (chaines musicales comme MTV)", 10 "Autre lecteur de musique" 11 ]); 12 var q88b = survey.open("Quel autre lecteur utilisez-vous ?"); 13 var q89 = survey.close("Quel est votre maniére d’écoute principale avec votre lecteur ?",[ 14 "Casque audio", 15 "Enceinte/Ampli", 16 "Sans rien" 17 ]); 18 q88.then(function(response){ 19 20 if (response == "Autre lecteur de musique"){ 21 return q88b; 22 } 23 else return q89; 24 }); Listing 5.5 – Extrait du questionnaire PRACTIC 5.3.3 Retour utilisateur La dernière partie des scripts de collecte vise à donner un aperçu aux participants des données collectées. Typiquement, l’objectif de cette partie est d’agir en toute transparence vis-à-vis des participants sur les données qui sont collectées sur leurs dispositifs, et d’apporter un aspect ludique à l’application. L’idée est de permettre aux participants de confronter leur perception de l’utilisation de leur dispositif avec leur usage réel. La figure 28 montre un exemple de retour utilisateur sur la durée totale d’utilisation de son appareil. Cette partie a été développée intégralement en HTML/JavaScript. 5.3.4 Discussions Dans cette section, nous avons décrit l’ensemble des scripts de collecte qui a été nécessaire dans le cas de l’étude PRACTIC. Nous allons maintenant identifier le gain apporté par APISENSE® pour le développement de ce cas d’étude. L’application mobile APISENSE®, responsable du téléchargement, de l’exécution des scripts et de la propagation des données collectées a été développée en utilisant la version 2.3 du SDK de Android. L’application APISENSE® fournit de nombreuses abstractions qui simplifient 136Figure 28 – Exemple de retour utilisateur PRACTIC le développement d’une application de collecte de données. La première permet tout d’abord d’avoir une abstraction complète du SDK Android pour accéder aux données fournies par Android, et intercepter les différents événements internes au dispositif mobile grâce aux façades. Le tableau 12 récapitule les façades qui ont été utilisées pour développer PRACTIC, et leur nombre de lignes de code Java qui ont été nécessaires à leur développement. Au total, ces façades comptent approximativement 6000 lignes de code. Pour les besoins de l’étude, en collaboration avec l’ingénieur responsable du développement de PRACTIC, nous avons dû intégrer deux nouvelles façades pour lister les fichiers musicaux (façade $media) et pour observer les évènements liés à l’écran d’un dispositif (façade $screen). Ces façades peuvent être à présent disponibles pour le développement de nouveaux scripts de collecte. L’application APISENSE® dispose également d’un ensemble de services responsables de l’exécution des scripts de collecte en tâche de fond,d’interagir avec le serveur central d’APISENSE® pour le téléchargement et de la mise à jour des scripts de collecte, d’interagir avec les nœuds de collecte des scientifiques pour propager automatiquement les données collectées, et de contrô- ler les ressources consommées par les scripts de collecte (cf. chapitre 3 section 3.4). Cette partie comporte approximativement plus de 20000 lignes de code. Pour finir, l’application mobile APISENSE® possède également une interface graphique générique destinée aux participants (6000 lignes de code). 137Façade Description LOC $survey Génération et publication d’un questionnaire 1277 $feedback Intégration de visualisation HTML/JavaScript 2144 $network Observation du contexte réseau 259 $telephony Observation du réseau cellulaire 400 $phone Observation des communications 600 $battery Observation des états de la batterie 158 $app Observation des applications 362 $trace Collecte et propagation des données 376 $screen (nouvelle) Observation de l’écran 235 $media (nouvelle) Liste du contenu 210 Table 12 – Façade utilisée pour les besoins de l’application PRACTIC La figure 29 met en évidence le gain en terme de lignes de codes obtenu grâce à APISENSE® par rapport aux scripts développés. Au total, seulement 7 % de codes spécifiques ont eu besoin d’être développés pour l’étude PRACTIC. Les principaux efforts de développement résident dans la description des 150 questions et leurs enchaînements (760 lignes) et dans les interfaces graphiques effectuant un retour sur les données obtenues (1600 lignes). Dans la section suivante, nous présentons le protocole de déploiement de l’application. Figure 29 – Gain en terme de lignes de code obtenu grâce à APISENSE® pour le développement de l’étude PRACTIC 1385.4 déploiement de l’étude practic Après avoir présenté dans son ensemble les scripts de collecte de l’étude PRACTIC, nous présentons dans cette section son protocole de déploiement et discutons de la participation à cette étude. 5.4.1 Protocole du déploiement Pour la mise en place de l’étude PRACTIC, un nœud de collecte a tout d’abord été déployé sur un serveur privé des scientifiques. Le nœud de collecte a été configuré pour utiliser un modèle de recrutement individuel, pour indexer les données collectées par utilisateur et pour utiliser un système de classement à point (cf. chapitre 4 section 4.4.1) afin de maximiser la participation des utilisateurs. Pour que les données collectées soient pleinement exploitables par les sociologues, ils ont besoin qu’elles soient collectées au minimum pendant 14 jours par participant, et que celui-ci ait répondu au questionnaire de l’enquête. Dans ce contexte, les points sont attribués de la manière suivante : • 50 points pour les participants ayant installé l’application sur une tablette et un smarpthone, remplis le questionnaire et ayant généré plus de 14 jours de données. • 20 points pour les participants qui ont installé sur un seul appareil (smartphone ou tablette), avec le questionnaire rempli et toujours un minimum de 14 jours de données générées. • 1 point par jour de données générées • 2 points si le questionnaire est rempli Des lots ont été prévus pour récompenser les meilleurs participants comprenant une tablette tactile, un smarpthone, une liseuse ainsi que des disques durs externes et des clés USB. Le nœud de collecte a également été utilisé pour le développement des scripts de collecte ainsi que leurs déploiements auprès d’un serveur central que nous avions au préalablement déployé sur un service Microsoft Azure 4 . Pour des raisons éthiques et légales, l’étude PRACTIC a été soumise et validée par la Commission National de l’Informatique et des Libertés 5 (CNIL). 4. http ://azure.microsoft.com/fr-fr/ 5. http://www.cnil.fr/ 139Les participants intéressés à participer à l’étude PRACTIC doivent tout d’abord télécharger et installer l’application mobile APISENSE® publiée sur le site internet APISENSE® 6 en flashant un QR code. À partir de l’application, les participants pourront alors s’enregistrer auprès de l’étude PRACTIC. L’enregistrement déclenchera automatiquement le téléchargement et l’exécution des scripts de collecte après la validation d’une charte de confidentialité. Un identifiant unique est généré et accordé à chaque participant lors de son inscription. Ce n’est qu’en acceptant de communiquer cet identi- fiant avec les chercheurs qu’ils pourront être identifiés. Nous présentons dans la suite de cette section le niveau de participation à PRACTIC, et discutons des premiers retours de l’expériences. 5.4.2 Participation L’étude PRACTIC s’est déroulée du 10 MARS au 19 Avril 2014. La figure 30 montre le nombre d’utilisateurs inscrits par jour, ainsi que l’accumulation du nombre d’inscriptions durant l’étude. Au total, 88 participants ont été recrutés durant l’étude. Figure 30 – Nombre d’inscriptions par jour à PRACTIC Un aspect intéressant des participants recrutés est la diversité de leurs équipements (cf. figure 31), ce qui nous a permis de tester APISENSE® sur 45 modèles de smartphones différents. Outre le nombre d’inscriptions, le succès de l’étude repose principalement sur le taux de participation des utilisateurs tout au long de l’étude. Pour que les données 6. http://www.apisense.fr 140Figure 31 – Diversité des équipements mobiles d’un participant soient exploitables par les chercheurs, il est nécessaire qu’elles aient été collectées au moins sur une période de 14 jours, et que celui-ci ait répondu au questionnaire de l’application. Figure 32 – Taux de participation à la collecte opportuniste 141Figure 33 – Taux de participation à la collecte participative et opportuniste Sur l’ensemble des participants, comme la montre la figure 32, 48 ont collecté des données plus de 14 jours, 21 de 4 à 13 jours, 13 de 1 à jour 6 qui n’ont collecté aucune donnée. Les participants ayant répondu au questionnaire sont au nombre de 25, et les participants ayant à la fois répondu au questionnaire et collecté au moins 14 jours de données sont au nombre de 12 (cf. figure 34). Ces derniers représentent les cas d’étude concrets pour les scientifiques. Bien que ce nombre soit inférieur à celui escompté au début de l’étude, un point positif des premiers résultats obtenus permet de valider que les dispositifs sont bien au cœur des pratiques de certains participants. La figure 34 par exemple représente le nombre de sessions applicatives, ainsi que leurs durées, sur une période de 40 jours Cette courbe met bien en évidence les différents rythmes des usages d’un participant en particulier, qui utilise son dispositif tout au long de la journée, et qui intensifie son utilisation en fin de journée. Figure 34 – Représentation des sessions d’allumage de l’écran du terminal d’un participant cumulées au cours de 40 jours 1425.5 conclusion Dans ce chapitre, nous avons présenté un cas réel de campagne de collecte de données développée et déployée avec APISENSE® au sein d’une étude sociologique. Nous avons montré que APISENSE® permettait réduire le temps de développement d’une campagne de collecte en proposant un modèle de programmation permettant de s’abstraire complètement des technologies mobiles. Dans le cas de cette étude, le modèle de programmation a permis d’économiser plus de 90% de code nécessaire à son développement. La campagne développée a été déployée auprès de 88 utilisateurs sur une période d’un mois et demi. 143É VA L U AT I O N D U M O D È L E C O L L A B O R AT I F 6 Sommaire 6.1 Introduction 145 6.2 Mise en place de l’expérience 145 6.3 Résultats 148 6.3.1 Quantité de données et couverture géographique 148 6.3.2 Consommation énergétique 151 6.4 Conclusion 154 6.1 introduction Dans ce chapitre, notre objectif est de montrer la validité du modèle de recrutement collaboratif présenté dans le chapitre 4 en section 4.5, page 113 qui permet de coordonner l’exécution des tâches de collecte entre les dispositifs mobiles. Nous rappelons que le but de cette coordination est dans un premier temps de répartir les charges énergétiques entre les dispositifs mobiles durant la campagne de collecte, puis dans un second temps de diminuer la quantité de données propagées vers les nœuds de collecte en limitant la propagation de données dupliquées. La validité du modèle est évaluée sur quatre critères : i) la quantité de données propagées sur les nœuds de collecte, ii) la quantité d’énergie utilisée par les dispositifs mobiles ainsi que iii) le surcoût induit par notre approche pour effectuer la coordination des tâches, iv) la couverture géographique des données obtenues. Pour valider notre modèle, nous avons mené une expérience et développé un environnement de simulation que nous détaillons dans la section suivante. 6.2 mise en place de l’expérience Pour cette évaluation, nous reprenons l’exemple de l’application présentée dans la section 4.5.1 page 116 qui est une version simplifiée d’une collecte de données exposée 145dans LiveLab [61]. L’objectif de cette application est d’utiliser les dispositifs mobiles pour mesurer la qualité des réseaux GSM en milieu urbain. Le listing 6.1 décrit la tâche de collecte associée à cette application qui consiste à exécuter 10 Pings réseaux (Packet INternet Groper) toutes les trente secondes et à collecter la latence moyenne des Pings effectués ainsi que la position du dispositif obtenue avec par GPS. 1 $location.onLocationChanged({period : "30s", provider : "GPS"},function(event) { 2 $trace.add({ 3 loc: [event.latitude, event.longitude], 4 latency : $network.ping(10,"http://...").average}); 5 })} Listing 6.1 – Tâche de collecte : Mesure de la latence réseau Pour évaluer notre approche, nous avons simulé le recrutement des dispositifs suivant un modèle où tous les dispositifs exécutent la tâche de collecte indépendamment les uns des autres, et suivant le modèle collaboratif, où les capteurs virtuels coordonnent l’exécution des tâches de collecte entre les dispositifs mobiles (cf. 4.5.2, page 119 ). Pour une évaluation réaliste et à grande échelle, nous utilisons des traces de mobilités réelles provenant de 10000 taxis équipés de GPS dans la ville de Pékin en Chine [67]. Ces données ont été collectées sur une période d’une semaine allant du 2 au 8 février 2008. Afin d’utiliser ces données, nous avons développé un simulateur illustré par la figure 35. Le simulateur comprend trois composants : un Manager, un ensemble d’Agents et un nœud de collecte (DataGathering Node). agents : Les agents sont responsables de générer le trafic réseau simulant les interactions entre les dispositifs mobiles et le nœud de collecte. Ces interactions sont simulées à partir d’un fichier de mobilité comprenant une série de tuples (date, latitude, longitude) représentant les déplacements d’un taxi à travers le temps. Pour l’expérience, nous avons implémenté deux types d’agents : i) les agents individuels et ii) les agents collaboratifs. Les agents individuels exécutent la tâche de collecte en continu tout au long de l’expérience, c’est-à-dire qu’ils collectent toutes les 30 secondes leur position selon le fichier de mobilité, et propagent l’ensemble des données collectées sur le nœud de collecte toutes les 5 minutes. Quant aux agents collaboratifs, ils s’enregistrent auprès des capteurs virtuels selon leur position à un instant t, et exécutent la tâche de collecte lorsqu’ils ont reçu une demande d’exécution de la part du capteur virtuel. Pour assurer une montée en charge du simulateur, les agents sont répartis auprès de plusieurs machines 146virtuelles hébergées sur la plate-forme Microsoft Windows Azure 1 . Des machines virtuelles de taille Small (A1) 2 sont utilisées, correspondant à un processeur à 1 coeur, 1,75 Go de mémoire et une carte réseau de 100 Mbit/s. datagathering node : Pour la simulation, nous avons déployé un nœud de collecte (cf. section 4.4, page 100 ) sur une machine virtuelle hébergée sur Microsoft Windows Azure. Une machine virtuelle de taille Medium (A2) est utilisée, correspondant à un processeur à 2 coeurs, 3,5 Go de mémoire et une carte réseau de 200 Mbit/s. manager : Ce dernier composant est responsable de répartir les fichiers de mobilité auprès des agents déployées sur les machines virtuelles, et de lancer le début de la simulation afin de synchroniser les agents. Figure 35 – Architecture du simulateur de traces de mobilité Pour les simulations présentées dans la suite de ce chapitre, nous utilisons les données du 3 février 2008 représentant la journée où le plus de données ont été produites. Les tâches de collecte sont déployées dans une zone de collecte de 10 km2 situés dans le centre-ville de Pékin, durant une durée de 30 minutes. 1. http://azure.microsoft.com 2. http://azure.microsoft.com/en-us/pricing/details/virtual-machines 1476.3 résultats Dans cette section, nous présentons les résultats obtenus à travers les différentes expériences menées grâce au simulateur développé. Nous discutons des résultats en fonction de la quantité, de la couverture géographique des données collectées ainsi que de l’énergie utilisée par les dispositifs mobiles durant les expériences et du surcoût engendré par notre approche. Pour évaluer les gains de notre modèle de recrutement, nous avons déployé, à travers le simulateur, la tâche de collecte présentée dans le listing 6.1 suivant trois modèles appelé individual, coll(1000 m), et coll(500 m). individual : dans ce modèle, les dispositifs exécutent la tâche de collecte indépendamment les uns des autres. Ils obtiennent une nouvelle position du GPS toutes les 30 secondes, et exécutent la tâche de collecte lorsque leur position se situe dans la zone de collecte définie. coll(1000 m) : dans ce modèle, l’exécution de la tâche de collecte est coordonnée par les capteurs virtuels déployés dans le nœud de collecte. L’objectif de couverture est fixé tous les 1000 mètres dans la zone de collecte avec 5 dispositifs attribués à la tâche (cf. section 4.5.1). coll(500 m) : ce modèle est identique au précédent sauf que nous avons fait varier l’objectif de couverture tous les 500 mètres dans la zone de collecte. Cela nous permet d’étudier l’impact de la couverture définie sur la quantité de données collectées et sur la consommation énergétique des dispositifs mobiles. 6.3.1 Quantité de données et couverture géographique Tout d’abord, nous comparons la quantité des données collectées. Les courbes illustrées par la figure 36 comparent la quantité de données collectées (en kilobyte) pour les trois tâches de collecte déployées en fonction du nombre de dispositifs. La première tâche, illustrée par la courbe individual, représente la quantité de données lorsque les dispositifs collectent individuellement la tâche de collecte. Les deux suivantes, illustrées par les courbes coll(1000 m) et coll(500 m) représentent les tâches de collecte déployées en utilisant le modèle collaboratif. Nous avons fait varier entre 500 et 10000 le nombre de dispositifs simulés durant cette expérience. Comme le montre cette figure, lorsqu’aucune collaboration n’est effectuée, la quantité de données générées augmente linéairement, allant jusqu’à 12000 KB de données produites pour 10000 dispositifs. En effectuant une collaboration, la quantité de données se stabilise autour des 6000 KB pour 148un objectif de couverture de 500 m2 et 2500 KB pour un objectif de 1000 m2 . Pour 10000 dispositifs, cela représente respectivement une diminution de 50% et 80% de quantité de données propagées vers le serveur. Ce gain s’explique, car lorsque suffisamment de dispositifs se trouvent dans une même zone (par ex. plus de 5 dispositifs dans une zone de 500 m2 pour la tâche coll(500 m)), le capteur virtuel associé à cette zone attribut seulement à 5 dispositifs la tâche de collecte, évitant ainsi aux autres dispositifs de la même zone d’exécuter la tâche de collecte. Figure 36 – Comparaison de la quantité de données collectées en fonction du nombre de dispositifs mobiles et de l’objectif de couverture géographique Cependant, pour valider notre approche, il est essentiel de comparer la quantité de données avec la couverture réellement obtenue. Pour cela, nous avons mené une deuxième expérience impliquant 10000 dispositifs mobiles, et nous avons observé la couverture géographique obtenue à travers différentes périodes de la journée par rapport à la quantité de données collectées. La couverture est définie par le pourcentage de zone couverte par les données collectées, soit 400 zones de 500 m2 dans la zone de collecte d’une surface de 10 Km2 . La figure 37 illustre le résultat de cette expérience. Dans cette figure, les courbes bleu et verte représentent respectivement la couverture obtenue par les approches individuelle (individual-SP) et collaborative (coll(500 m)- 149SP), et les colonnes rouge (individual-Data) et jaune (coll(500 m)-Data) la quantité de données collectées par ces deux approches. Comme le montre cette figure, la couverture des données obtenue varie tout au long de la journée, pour atteindre un pic à 17 H représentant une forte mobilité des taxis dans la zone de collecte. Ce que nous pouvons observer d’intéressant, c’est que les couvertures obtenues par ces deux approches sont relativement équivalentes, bien que la quantité de données collectées par l’approche collaborative soit toujours inférieure à celle de l’approche individuel. La différence des couvertures obtenues entre les deux approches est due à la mobilité des taxis. En effet, si un taxi se déplace à grande vitesse, celui-ci peut traverser une zone avant que le capteur virtuel associé n’est le temps de lui attribuer une tâche. Cependant, dans cette simulation, la perte de la couverture obtenue ne varie pas au delà des 2%. Figure 37 – Comparaison de la couverture géographique selon différentes périodes de la journée À travers ces deux expériences, nous avons montré que l’approche collaborative que nous avons proposée permet de diminuer la quantité de données propagées vers le serveur tout en gardant une couverture presque similaire à une approche classique. Nous allons maintenant évaluer les gains de cette approche sur la consommation énergétique des dispositifs mobiles. 1506.3.2 Consommation énergétique Pour évaluer l’énergie consommée par les dispositifs mobiles liée au trafic réseau et à l’acquisition de la position par le GPS, nous utilisons deux modèles énergétiques très référencés dans la littérature. Le premier modèle, proposé par Balasubramanian et al. [5], permet de déterminer l’énergie liée à la transmission de données par des réseaux sans fil. Dans le contexte de cette évaluation, nous assumons que toutes les données sont transmises par un réseau 3G. Ce modèle divise l’énergie consommée en trois parties. La première est liée à l’activation de l’interface de communication évaluée à 3,5 Joules. La deuxième est liée à la transmission des données évaluée à 0.025 Joule/KB. Et la dernière est liée au temps que l’interface de communication soit désactivée après la transmission des données. Ce temps est évalué à 12,5 secondes et l’interface consomme 0,62 Joule/s jusqu’à ce qu’elle soit désactivée. Dans le cadre où deux transmissions de données sont effectuées en dessous des 12,5 secondes, l’énergie consommée par cette dernière partie est négligée. Pour le deuxième modèle, nous utilisons celui proposé par Lin et al. [43], qui évalue l’énergie liée à l’acquisition périodique d’une position par le GPS à 1,4 Joules par position obtenue. Les courbes illustrées par la figure 38 comparent la consommation énergétique des trois tâches de collecte déployées dans la première expérience de la section précédente par rapport à la concentration de dispositifs mobiles dans la zone de collecte. L’énergie est donnée en Joule et correspond à la moyenne énergétique consommée par l’ensemble des dispositifs mobiles. Comme attendue, la consommation énergétique de la tâche individuelle (individual) est indépendante de la concentration des dispositifs mobiles, et reste constante autour des 600 Joules en moyenne par dispositif. En revanche, les tâches collaboratives (coll(1000 m) et coll(500 m)) bénéficient de cette concentration croissante en évitant de collecter des données non nécessaires pour atteindre les objectifs de couverture, et ainsi réduire la consommation énergétique moyenne par dispositif. Pour coll(1000 m), le gain sur la consommation énergétique des dispositifs varie entre 43% pour 500 dispositifs et 82% pour 10000 dispositifs, tandis que pour coll(500 m), ce gain varie entre 40% et 70%. Afin de mieux comprendre où le gain énergétique est effectué, les graphiques de la figure 39 montrent la répartition des charges énergétiques consommées durant l’expérience pour les trois tâches individual (a), coll(1000 m) (b) et coll(500 m) (c). Dans cette figure, la partie bleue (Localisation) des colonnes représente la consommation 151Figure 38 – Comparaison des moyennes de la consommation énergétique en fonction de la concentration de dispositifs mobiles dans la zone de collecte causée par l’acquisition d’une position par le GPS, la partie rouge (Sensing Task) à l’exécution des Pings réseaux (cf. listing 6.1 ligne 4) et la partie orange (VS Messages) aux communications avec les capteurs virtuels. Comme le montre cette figure, le gain de la collaboration sur la consommation énergétique est particulièrement liée à l’acquisition des positions par le GPS. En effet, dans cette approche, les dispositifs ont seulement besoin d’obtenir une position pour déterminer à quel capteur virtuel ils doivent s’enregistrer, permettant à ces dispositifs de réduire la fréquence de l’acquisition d’une nouvelle position si leur vitesse est relativement réduite ou en position statique (cf. section 4.5.2, page 121 ). Cela représente dans cette expérience un gain respectif de 86% et 80% pour les tâches coll(1000 m) et coll(500 m). Dans ce contexte, une grande perte énergétique du modèle de recrutement individuelle s’explique par le fait que même les dispositifs ne se situant pas dans la zone de collecte sont obligés de continuellement activer leur GPS afin de déterminer s’ils sont dans la zone étudiée ou non. En ce qui concerne l’énergie consommée par l’exécution des Pings réseaux, le gain reste limité lorsque peu de dispositifs sont impliqués dans l’expérience. Pour le modèle coll(1000 m), le gain est seulement de 4% et devient négatif pour coll(500 m). Ceci s’explique par le surcoût énergétique engendré par les communications des dispositifs avec les capteurs virtuels. Néanmoins, le gain énergétique s’accroît lorsque plus de dispositifs sont impliqués pour atteindre 81% pour coll(1000 m) et 55% pour le modèle coll(500 m). 152Figure 39 – Répartition des charges énergétiques suivant les approches : (a) individuelle, (b) collaborative avec une objectif de couverture de 1000 m 2 , (c) collaborative avec un objectif de couverture de 500 m2 153Comme attendu, ces chiffres montrent que le gain énergétique lié à la coordination des tâches varie selon la concentration des dispositifs mobiles dans la zone de collecte et également des objectifs de couvertures définies. Cependant cela révèle également les limitations du modèle évalué dans ce chapitre. En effet, dans le contexte où la concentration des dispositifs mobiles est trop faible pour permettre une coordination des tâches, notre modèle consommerait plus qu’un modèle classique à cause des communications nécessaires avec les capteurs virtuels. D’autre part, notre modèle reste limité si l’objectif de couverture nécessaire pour la campagne de collecte doit être très élevé (par ex. tous les 50 mètres). Cela engendrerait un trafic réseau trop important, car les dispositifs seraient sens cesse en train de communiquer avec les capteurs virtuels, spécialement dans un cas de forte mobilité. Dans ce contexte, la solution proposée ici reste principalement efficace pour les campagnes de collecte nécessitant une couverture géographique de collecte d’une centaine de mètres ou plus. Quelques exemples de ce type de campagnes sont la mesure de la qualité de l’air [19], ou la mesure de la qualité des réseaux sans fil comme présentés dans ce chapitre [61]. 6.4 conclusion Nous avons présenté dans ce chapitre l’évaluation du modèle de recrutement collaboratif proposé dans APISENSE®. Ce modèle s’appuie sur la forte concentration des dispositifs en milieu urbain pour coordonner l’exécution des tâches de collecte entre ces dispositifs selon un objectif de couverture géographique. Pour évaluer ce modèle, nous avons présenté plusieurs expériences basées sur des traces réelles de mobilités provenant de 10000 taxis. Par le biais des expériences menées, nous avons montré qu’en coordonnant l’exécution des tâches, le modèle proposé comporte principalement deux avantages par rapport à un modèle de recrutement où tous les dispositifs les exécutent de manière indépendante. Les expériences ont montré que notre approche permet dans un premier temps de diminuer la quantité de données propagée sur le serveur de plus de 50% lorsque 10000 dispositifs mobiles sont impliqués, tout en gardant une couverture géographique des données collectées similaire. Nous avons également montré que la coordination des tâches de collecte permettait de diminuer la consommation énergétique de ces dispositifs jusqu’à 70%. 154Dans le prochain chapitre, nous concluons en faisant un bilan des contributions présentées dans ce manuscrit, et discutons des perspectives de développements et de recherches issues des travaux de cette thèse. 155Quatrième partie Conclusion 1577 C O N C L U S I O N Sommaire 7.1 Rappel des motivations 159 7.2 Rappel des contributions 160 7.2.1 Collecte mobile de données 160 7.2.2 Collecte répartie de données 161 7.3 Perspectives 162 Ce chapitre, qui finalise la présentation faite au travers de ce manuscrit, s’organise de la manière suivante. La section 7.1 rappelle le contexte dans lequel se sont inscrits les travaux réalisés et la problématique qui en est à l’origine. La section 7.2 résume les contributions décrites dans ce manuscrit. Enfin la section 7.3 définit un ensemble de pistes de recherche et de développement en lien avec les travaux de cette thèse. 7.1 rappel des motivations Le Mobile crowdsensing est une nouvelle alternative exploitant la foule de terminaux intelligents déjà déployés à travers le monde pour la collecte massive de données environnementales ou comportementales de la population. Ces dernières années, ce type de collecte de données a suscité l’intérêt d’un grand nombre d’acteurs industriels et académiques dans des domaines tels que l’étude de la mobilité urbaine, la surveillance de l’environnement, la santé ou l’étude des comportements sociaux. Malgré le potentiel du Mobile crowdsensing, les campagnes de collecte réalisées impliquant un grand nombre d’utilisateurs mobiles sont rares et restent principalement développées par des experts. Ceci est particulièrement dû à l’absence de prise en compte d’aspects non fonctionnels des systèmes proposés dédiés au MCS. En effet, réaliser une campagne de collecte impliquant un grand nombre d’utilisateurs mobiles demande de faire face à de nombreux défis. Ces défis incluent la protection de la vie privée des utilisateurs, les ressources énergétiques limitées des terminaux mobiles, la 159mise en place de modèles de récompense et de déploiement adaptés pour recruter les utilisateurs les plus à même de collecter les données désirées, ainsi que de faire face à l’hétérogénéité des plate-formes mobiles disponibles (par ex. Android, iOS...). À ce jour, beaucoup d’efforts ont principalement portés sur la réalisation de systèmes monolithiques, difficilement réutilisable dans un contexte non anticipé. Ce manque d’approche réutilisable demande généralement de devoir réinventer la roue pour chaque nouveau système, entravant ainsi l’adoption du MCS pour de nombreux acteurs n’ayant pas les compétences, ni le temps de développer un système capable de répondre à leurs exigences. Dans cette thèse, nous avons cherché à réétudier les architectures des systèmes dédiés au MCS pour adresser les limitations actuelles liées au développement, au déploiement et à l’exécution d’une campagne de collecte de données. Les différentes contributions proposées sont articulées autour APISENSE®, la plate-forme résultante des travaux de cette thèse. APISENSE® propose un environnement distribué permettant de simplifier le développement et le déploiement de campagnes de collecte de données à travers des utilisateurs mobiles. Nous décrivons dans la section suivante un résumé des contributions décrites dans ce manuscrit. 7.2 rappel des contributions Dans cette section, nous synthétisons nos contributions présentées dans le chapitre 3 et le chapitre 4 au travers de l’implémentation de la plate-forme APISENSE®. 7.2.1 Collecte mobile de données Dans notre première contribution, nous avons tout d’abord proposé un modèle de programmation pour simplifier le développement de tâches de collecte de données (cf. chapitre 3 section 3.3, page 59 ). Pour concevoir ce modèle, nous avons tenu compte de trois propriétés qui sont la portabilité, la généralité, et l’accessibilité. En ce qui concerne la portabilité, nous avons basé notre modèle sur le langage de script JavaScript, qui est facilement exécutable sur de nombreux systèmes d’exploitation des dispositifs mobiles actuels. Pour l’accessibilité, nous avons proposé une interface de programmation simple et efficace fournissant une abstraction complète des technologies mobiles. Et pour la généralité, l’interface a été conçue pour supporter une grande variété d’activités de 160collecte, comprenant la collecte opportuniste et participative (cf. chapitre 2 section 2.1.2, page 26 ). Plus particulièrement, l’interface proposée permet de facilement écouter les changements d’état des capteurs mobiles pour la collecte de données opportuniste, d’interagir avec l’utilisateur mobile pour la collecte de données participative ainsi que définir les stratégies de propagation des données. Nous avons également présenté dans ce chapitre l’architecture de l’environnement mobile (cf. chapitre 3 section 3.4, page 68 ) assurant l’exécution des tâches de collecte. Cette architecture met principalement l’accent sur la sécurité et le respect de la confi- dentialité des participants. Pour atteindre cet objectif, tous les scripts sont exécutés dans un bac à sable dédié. Ainsi, cela nous permet de contrôler tous les accès des scripts vers les capteurs des dispositifs mobiles. Par le biais d’une interface graphique, nous laissons la possibilité aux utilisateurs mobiles de définir des contraintes empêchant toute activité de collecte non désirées. Ces contraintes sont classifiées en quatre catégories : temporelles, géographiques, de ressources consommées et de capteurs utilisés. 7.2.2 Collecte répartie de données Dans cette deuxième contribution, le défi adressé concerne la généralité de la plateforme pour concevoir une grande variété de campagnes de collecte ainsi que son passage à l’échelle. Pour supporter une grande diversité de campagnes de collecte, nous avons proposé un Modèle de Variabilité (MC) [32] (en anglais FM pour Feature Model), capturant les différentes configurations d’une application serveur responsable de la gestion des campagnes de collecte (cf. chapitre 4 section 4.4.1, page 101 ). Cette configuration réside en cinq points : i) configurer l’environnement de développement des tâches de collecte, ii) choisir un modèle de recrutement des participants, iii) choisir une série de traitements sur les données collectées avant leur insertion dans la base de données (par ex. anonymisation des données), iv) spécifier l’indexation des données dans la base de données, v) exposer des services pour exploiter les données collectées. Ce modèle est ensuite fourni aux utilisateurs pour leur permettre de définir des exigences selon la spécificité des campagnes qu’ils veulent mener. À partir des ces exigences, une application serveur (appelée nœud de collecte) est générée et configurée fournissant un environnement dédié à la gestion des campagnes de collecte des utilisateurs. En ce qui concerne le passage à l’échelle de la plate-forme, nous avons proposé une architecture décentralisée, séparant les préoccupations du déploiement ainsi que de la 161collecte et l’analyse des données (cf. chapitre 4 section 4.2, page 92 ). L’architecture résultante est composée d’un ensemble de nœuds de collecte et d’un serveur central. Dans cette architecture, le serveur central est responsable du déploiement des tâches de collecte soumises par les nœuds de collecte vers les participants de la plate-forme qui se sont enregistrés au préalable. Les nœuds de collecte, quant à eux, fournissent un environnement dédié permettant aux utilisateurs de développer de nouvelles tâches de collecte, de les déployer auprès du serveur central, et d’exploiter les données qui ont été collectées durant l’exécution des tâches de collecte. Ce procédé a principalement deux avantages. Le premier est d’assurer une première couche d’anonymat des participants, dans le sens où tous les nœuds de collecte ne peuvent pas déployer les tâches de collecte sans passer par le serveur central. Le deuxième permet aux nouveaux utilisateurs de bénéficier d’un ensemble de participants déjà disponibles pour exécuter des tâches de collecte, leur évitant ainsi une longue période de recrutement. Finalement, nous avons proposé une extension de APISENSE® dédiée à l’optimisation de l’exécution de campagne de collecte communautaire (cf. chapitre 4 section 4.5, page 113 ). L’optimisation proposée permet de coordonner l’exécution des tâches de collecte entre les dispositifs mobiles en fonction de propriétés de couvertures géographique et temporelle. Principalement, cette optimisation a pour objectif dans un premier temps de diminuer la consommation énergétique globale de tous les dispositifs impliqués dans la campagne, et également de diminuer la quantité de données propagées vers le nœud de collecte. 7.3 perspectives Dans cette section, nous présentons un ensemble de pistes de développement et de recherche en lien avec les travaux présentés dans cette thèse. Une première contribution au développement d’APISENSE® serait dans un premier temps de porter l’application mobile sur les divers systèmes d’exploitation mobiles disponibles sur le marché (par ex. iOS, Windows Mobile). Bien que nous avons effectué une preuve de concept de la portabilité de l’application mobile d’APISENSE® sur iOS, le prototype réalisé n’est pas encore opérationnel pour être déployé à grande échelle. 162Concernant la partie serveur de APISENSE®, plusieurs améliorations à court terme peuvent être envisagées. La première concerne la sécurité lors de la propagation des données des dispositifs vers les nœuds de collecte. En effet, actuellement l’emplacement du participant peut être déterminé en identifiant l’adresse IP du point d’accès utilisé pour propager les données, permettant potentiellement d’identifier son domicile même si les données en elles-mêmes ne permettent pas de révéler cette information. Dans ce contexte, une priorité serait d’utiliser des routeurs ou relais spécifiques (par ex. routeur oignon [18]) pour cacher l’adresse IP lors de la propagation des données. Une autre amélioration à court terme serait d’intégrer des outils de visualisation génériques permettant de rapidement explorer les données collectées à travers une Interface web. Par exemple, il serait intéressant d’établir des connexions entre les nœuds de collecte et des services tels que CartoDB 1 ou Google Fusion Tables 2 qui proposent ce type de fonctionnalité. Une autre amélioration serait de supporter le déploiement automatique des nœuds de collecte vers les infrastructures des utilisateurs. Cette tâche reste encore manuelle et peut demander une certaine expertise pour administrer le système responsable de leurs exécutions. Certains travaux dans notre équipe ont déjà été initiés dans ce sens [53, 54] et nous prévoyons de rapidement les intégrer dans APISENSE®. D’autres pistes de développement seraient d’implémenter les différents modèles de protection de la vie privée et de récompense proposés dans la littérature. Dans ce contexte, il serait intéressant de déployer des campagnes utilisant ces différents modèles sur des échantillons de participants, afin d’évaluer leurs impacts sur leurs participations. Nous pensons que APISENSE® peut être une plate-forme idéale pour permettre aux scientifiques travaillant sur ces problématiques pour les aider à mettre au point et valider leurs algorithmes. Bien que le modèle de programmation proposé dans cette thèse fournisse une abstraction complète des technologies mobiles, une expertise en programmation est quand même nécessaire pour le développement des tâches de collecte. Dans ce contexte, il pourrait être intéressant de proposer un niveau d’abstraction encore plus élevé ne nécessitant aucune expertise. Ce niveau d’abstraction peut s’appuyer par exemple sur certains travaux déjà existant comme App Inventor 3 ou Alice [15] qui proposent 1. http://cartodb.com 2. http://tables.googlelabs.com 3. http://appinventor.mit.edu 163des métaphores visuelles pour le développement des applications, ou encore sur le langage naturel. Dans ce contexte, le modèle de programmation que nous avons proposé pourrait être utilisé comme langage pivot avec ce nouveau niveau d’abstraction. Une autre perspective serait de mettre en place des métriques permettant d’évaluer la qualité des données collectées. Très peu de recherche ont encore été menées dans ce sens, bien que cela représente une problématique importante de ce type d’applications. En effet, de nombreux facteurs peuvent influer sur la qualité des données comme le type de matériel utilisé, la mobilité des utilisateurs, etc. En effet, sans connaître le niveau de fiabilité des données, il peut être très difficile de savoir si les données collectées sont représentatives du monde réel ou du comportement des participants. La mise en place de ces métriques pourrait également permettre de mettre en place de nouveaux modèles de recrutement des participants dans les campagnes de collecte. Dans ce contexte, selon les exigences de la campagne, les participants fournissant les données de plus grande qualité pourraient être privilégiés. Dans cette thèse, nous avons particulièrement investi sur le développement d’un système de collecte de données avec APISENSE®. Cependant, la collecte en elle même ne représente qu’une partie des futurs systèmes d’informations se basant sur le pouvoir de la foule pour atteindre une quantité massive de données. De nombreux défis doivent encore être relevés pour traiter ces données, en extraire des comportements complexes et diffuser des informations en temps réel à partir de leurs analyses [68]. Un cas d’utilisation que nous souhaitons investir est l’utilisation du Mobile crowdsensing pour élaborer un système de détection de tremblement de terre. Certaines initiatives ont déjà vu le jour comme le projet Quake-Catcher Network [13], qui permet de recueillir les données issues des capteurs de mouvement présents dans les disques durs des ordinateurs, transformant alors ceux-ci en sismographes. Comme mentionné par Faulkner et al. [23], cette approche peut être complétée en utilisant les accéléromètres intégrés dans les dispositifs mobiles qui peuvent fournir une mesure plus précise et plus complète de la distribution géographique des secousses lors d’un tremblement de terre. Cependant, développer un système fiable, capable d’analyser continuellement les données produites par des centaines de milliers de capteurs, extraire uniquement les informations pertinentes et propager une alerte sismique seulement en quelques secondes restent actuellement un véritable défi. 164B I B L I O G R A P H I E [1] Nadav Aharony, Wei Pan, Cory Ip, Inas Khayal, and Alex Pentland. Social fmri : Investigating and shaping social mechanisms in the real world. Pervasive and Mobile Computing, 7(6) :643–659, 2011. [2] Marc P Armstrong, Gerard Rushton, Dale L Zimmerman, et al. Geographically masking health data to preserve confidentiality. Statistics in medicine, 18(5) :497–525, 1999. [3] Patrick Baier, Frank Durr, and Kurt Rothermel. Psense : Reducing energy consumption in public sensing systems. In Advanced Information Networking and Applications (AINA),26th International Conference on, pages 136–143. IEEE, 2012. [4] Rajesh Krishna Balan, Khoa Xuan Nguyen, and Lingxiao Jiang. Real-time trip information service for a large taxi fleet. In Proceedings of the 9th international conference on Mobile systems, applications, and services, pages 99–112. ACM, 2011. [5] Niranjan Balasubramanian, Aruna Balasubramanian, and Arun Venkataramani. Energy consumption in mobile phones : a measurement study and implications for network applications. In Proceedings of the 9th conference on Internet measurement conference, pages 280–293. ACM, 2009. [6] Niels Brouwers and Koen Langendoen. Pogo, a middleware for mobile phone sensing. In Proceedings of the 13th International Middleware Conference, pages 21–40. Springer-Verlag New York, Inc., 2012. [7] J Burke, D Estrin, M Hansen, A Parker, N Ramanathan, S Reddy, and MB Srivastava. Participatory sensing. In In : Workshop on World-Sensor-Web (WSW’06) : Mobile Device Centric Sensor Networks and Applications, 2006. [8] Iacopo Carreras, Daniele Miorandi, Andrei Tamilin, Emmanuel R Ssebaggala, and Nicola Conci. Matador : Mobile task detector for context-aware crowd-sensing campaigns. In Pervasive Computing and Communications Workshops (PERCOM Workshops), International Conference on, pages 212–217. IEEE, 2013. 165[9] Guanling Chen, David Kotz, et al. A survey of context-aware mobile computing research. Technical report, Technical Report TR2000-381, Dept. of Computer Science, Dartmouth College, 2000. [10] NM Chowdhury and Raouf Boutaba. A survey of network virtualization. Computer Networks, 54(5) :862–876, 2010. [11] Delphine Christin, Andreas Reinhardt, Salil S Kanhere, and Matthias Hollick. A survey on privacy in mobile participatory sensing applications. Journal of Systems and Software, 84(11) :1928–1946, 2011. [12] Paul Clements and Linda Northrop. Software product lines : practices and patterns. 2002. [13] Elizabeth S Cochran, Jesse F Lawrence, Carl Christensen, and Ravi S Jakka. The quake-catcher network : Citizen science expanding seismic horizons. Seismological Research Letters, 80(1) :26–30, 2009. [14] Ionut Constandache, Shravan Gaonkar, Matt Sayler, Romit Roy Choudhury, and Landon Cox. Enloc : Energy-efficient localization for mobile phones. In INFOCOM, pages 2716–2720. IEEE, 2009. [15] Stephen Cooper, Wanda Dann, and Randy Pausch. Teaching objects-first in introductory computer science. In ACM SIGCSE Bulletin, volume 35, pages 191–195. ACM, 2003. [16] Tathagata Das, Prashanth Mohan, Venkata N Padmanabhan, Ramachandran Ramjee, and Asankhaya Sharma. Prism : platform for remote sensing using smartphones. In Proceedings of the 8th international conference on Mobile systems, applications, and services, pages 63–76. ACM, 2010. [17] Linda Deng and Landon P Cox. Livecompare : grocery bargain hunting through participatory sensing. In Proceedings of the 10th workshop on Mobile Computing Systems and Applications, page 4. ACM, 2009. [18] Roger Dingledine, Nick Mathewson, and Paul Syverson. Tor : The secondgeneration onion router. Technical report, DTIC Document, 2004. [19] Prabal Dutta, Paul M Aoki, Neil Kumar, Alan Mainwaring, Chris Myers, Wesley Willett, and Allison Woodruff. Common sense : participatory urban sensing using 166a network of handheld air quality monitors. In Proceedings of the 7th ACM conference on embedded networked sensor systems, pages 349–350. ACM, 2009. [20] Shane B Eisenman, Emiliano Miluzzo, Nicholas D Lane, Ronald A Peterson, GahngSeop Ahn, and Andrew T Campbell. Bikenet : A mobile sensing system for cyclist experience mapping. ACM Transactions on Sensor Networks (TOSN), 6(1) :6, 2009. [21] Patrick Th Eugster, Pascal A Felber, Rachid Guerraoui, and Anne-Marie Kermarrec. The many faces of publish/subscribe. ACM Computing Surveys (CSUR), 35(2) : 114–131, 2003. [22] Hossein Falaki, Ratul Mahajan, and Deborah Estrin. Systemsens : a tool for monitoring usage in smartphone research deployments. In Proceedings of the sixth international workshop on MobiArch, pages 25–30. ACM, 2011. [23] Matthew Faulkner, Michael Olson, Rishi Chandy, Jonathan Krause, K Mani Chandy, and Andreas Krause. The next big one : Detecting earthquakes and other rare events from community-based sensors. In Information Processing in Sensor Networks (IPSN), 2011 10th International Conference on, pages 13–24. IEEE, 2011. [24] Zachary Fitz-Walter and Dian Tjondronegoro. Exploring the opportunities and challenges of using mobile sensing for gamification. In Proceedings of the 13th International Conference on Ubiquitous Computing (UbiComp’11) : Workshop on Mobile Sensing, 2011. [25] Jon Froehlich, Mike Y Chen, Sunny Consolvo, Beverly Harrison, and James A Landay. Myexperience : a system for in situ tracing and capturing of user feedback on mobile phones. In Proceedings of the 5th international conference on Mobile systems, applications and services, pages 57–70. ACM, 2007. [26] Sébastien Gambs, Marc-Olivier Killijian, and Miguel Núñez del Prado Cortez. Show me how you move and i will tell you who you are. In Proceedings of the 3rd ACM SIGSPATIAL International Workshop on Security and Privacy in GIS and LBS, pages 34–41. ACM, 2010. [27] Raghu K Ganti, Fan Ye, and Hui Lei. Mobile crowdsensing : Current state and future challenges. Communications Magazine, IEEE, 49(11) :32–39, 2011. [28] Chunming Gao, Fanyu Kong, and Jindong Tan. Healthaware : Tackling obesity with health aware smart phone systems. In Robotics and Biomimetics (ROBIO), 2009 IEEE International Conference on, pages 1549–1554. IEEE, 2009. 167[29] Shravan Gaonkar, Jack Li, Romit Roy Choudhury, Landon Cox, and Al Schmidt. Micro-blog : sharing and querying content through mobile phones and social participation. In Proceedings of the 6th international conference on Mobile systems, applications, and services, pages 174–186. ACM, 2008. [30] Kuan Lun Huang, Salil S Kanhere, and Wen Hu. Preserving privacy in participatory sensing systems. Computer Communications, 33(11) :1266–1280, 2010. [31] Anil K Jain and Richard C Dubes. Algorithms for clustering data. Prentice-Hall, Inc., 1988. [32] Kyo C Kang, Sholom G Cohen, James A Hess, William E Novak, and A Spencer Peterson. Feature-oriented domain analysis (foda) feasibility study. Technical report, DTIC Document, 1990. [33] Wazir Zada Khan, Yang Xiang, Mohammed Y Aalsalem, and Quratulain Arshad. Mobile phone sensing systems : a survey. Communications Surveys & Tutorials, IEEE, 15(1) :402–427, 2013. [34] Donnie H Kim, Younghun Kim, Deborah Estrin, and Mani B Srivastava. Sensloc : sensing everyday places and paths using less energy. In Proceedings of the 8th ACM Conference on Embedded Networked Sensor Systems, pages 43–56. ACM, 2010. [35] Stephen F King and Paul Brown. Fix my street or else : using the internet to voice local public service concerns. In Proceedings of the 1st international conference on Theory and practice of electronic governance, pages 72–80. ACM, 2007. [36] John Krumm. A survey of computational location privacy. Personal and Ubiquitous Computing, 13(6) :391–399, 2009. [37] Jennifer R Kwapisz, Gary M Weiss, and Samuel A Moore. Activity recognition using cell phone accelerometers. ACM SigKDD Explorations Newsletter, 12(2) :74–82, 2011. [38] Nicholas D Lane, Shane B Eisenman, Mirco Musolesi, Emiliano Miluzzo, and Andrew T Campbell. Urban sensing systems : opportunistic or participatory ? In Proceedings of the 9th workshop on Mobile computing systems and applications, pages 11–16. ACM, 2008. 168[39] Nicholas D Lane, Emiliano Miluzzo, Hong Lu, Daniel Peebles, Tanzeem Choudhury, and Andrew T Campbell. A survey of mobile phone sensing. Communications Magazine, IEEE, 48(9) :140–150, 2010. [40] Juong-Sik Lee and Baik Hoh. Dynamic pricing incentive for participatory sensing. Pervasive and Mobile Computing, 6(6) :693–708, 2010. [41] Juong-Sik Lee and Baik Hoh. Sell your experiences : a market mechanism based incentive for participatory sensing. In Pervasive Computing and Communications (PerCom), 2010 IEEE International Conference on, pages 60–68. IEEE, 2010. [42] P Lilly. Mobile devices to outnumber global population by 2017. URL http ://tinyurl. com/pbodtus [Accessedon : 2013-08-06]. [43] Kaisen Lin, Aman Kansal, Dimitrios Lymberopoulos, and Feng Zhao. Energyaccuracy trade-off for continuous mobile device location. In Proceedings of the 8th international conference on Mobile systems, applications, and services, pages 285–298. ACM, 2010. [44] Pengfei Liu, Yanhua Chen, Wulei Tang, and Qiang Yue. Mobile weka as data mining tool on android. In Advances in Electrical Engineering and Automation, pages 75–80. Springer, 2012. [45] Hong Lu, Nicholas D Lane, Shane B Eisenman, and Andrew T Campbell. Bubblesensing : Binding sensing tasks to the physical world. Pervasive and Mobile Computing, 6(1) :58–71, 2010. [46] C Matthew MacKenzie, Ken Laskey, Francis McCabe, Peter F Brown, Rebekah Metz, and Booz Allen Hamilton. Reference model for service oriented architecture 1.0. OASIS Standard, 12, 2006. [47] Nicolas Maisonneuve, Matthias Stevens, Maria E Niessen, and Luc Steels. Noisetube : Measuring and mapping noise pollution with mobile phones. In Information Technologies in Environmental Engineering, pages 215–228. Springer, 2009. [48] David J Malan and Henry H Leitner. Scratch for budding computer scientists. ACM SIGCSE Bulletin, 39(1) :223–227, 2007. [49] Emiliano Miluzzo, Nicholas D Lane, Kristóf Fodor, Ronald Peterson, Hong Lu, Mirco Musolesi, Shane B Eisenman, Xiao Zheng, and Andrew T Campbell. Sensing meets mobile social networks : the design, implementation and evaluation of the 169cenceme application. In Proceedings of the 6th ACM conference on Embedded network sensor systems, pages 337–350. ACM, 2008. [50] Prashanth Mohan, Venkata N Padmanabhan, and Ramachandran Ramjee. Nericell : rich monitoring of road and traffic conditions using mobile smartphones. In Proceedings of the 6th ACM conference on Embedded network sensor systems, pages 323–336. ACM, 2008. [51] Min Mun, Sasank Reddy, Katie Shilton, Nathan Yau, Jeff Burke, Deborah Estrin, Mark Hansen, Eric Howard, Ruth West, and Péter Boda. Peir, the personal environmental impact report, as a platform for participatory sensing systems research. In Proceedings of the 7th international conference on Mobile systems, applications, and services, pages 55–68. ACM, 2009. [52] Klaus Pohl, Günter Böckle, and Frank Van Der Linden. Software product line engineering : foundations, principles, and techniques. Springer, 2005. [53] Clément Quinton, Romain Rouvoy, and Laurence Duchien. Leveraging feature models to configure virtual appliances. In Proceedings of the 2nd International Workshop on Cloud Computing Platforms, page 2. ACM, 2012. [54] Clément Quinton, Nicolas Haderer, Romain Rouvoy, and Laurence Duchien. Towards multi-cloud configurations using feature models and ontologies. In Proceedings of the 2013 international workshop on Multi-cloud applications and federated clouds, pages 21–26. ACM, 2013. [55] Moo-Ryong Ra, Bin Liu, Tom F La Porta, and Ramesh Govindan. Medusa : A programming framework for crowd-sensing applications. In Proceedings of the 10th international conference on Mobile systems, applications, and services, pages 337–350. ACM, 2012. [56] Kiran K Rachuri, Mirco Musolesi, Cecilia Mascolo, Peter J Rentfrow, Chris Longworth, and Andrius Aucinas. Emotionsense : a mobile phones based adaptive platform for experimental social psychology research. In Proceedings of the 12th ACM international conference on Ubiquitous computing, pages 281–290. ACM, 2010. [57] Sasank Reddy, Deborah Estrin, Mark Hansen, and Mani Srivastava. Examining micro-payments for participatory sensing data collections. In Proceedings of the 12th ACM international conference on Ubiquitous computing, pages 33–36. ACM, 2010. 170[58] Mitchel Resnick, John Maloney, Andrés Monroy-Hernández, Natalie Rusk, Evelyn Eastmond, Karen Brennan, Amon Millner, Eric Rosenbaum, Jay Silver, Brian Silverman, et al. Scratch : programming for all. Communications of the ACM, 52 (11) :60–67, 2009. [59] Xiang Sheng, Jian Tang, and Weiyi Zhang. Energy-efficient collaborative sensing with mobile phones. In INFOCOM, 2012 Proceedings IEEE, pages 1916–1924. IEEE, 2012. [60] Xiang Sheng, Xuejie Xiao, Jian Tang, and Guoliang Xue. Sensing as a service : A cloud computing system for mobile phone sensing. In Sensors, 2012 IEEE, pages 1–4. IEEE, 2012. [61] Clayton Shepard, Ahmad Rahmati, Chad Tossell, Lin Zhong, and Phillip Kortum. Livelab : measuring wireless networks and smartphone users in the field. ACM SIGMETRICS Performance Evaluation Review, 38(3) :15–20, 2011. [62] Minho Shin, Cory Cornelius, Dan Peebles, Apu Kapadia, David Kotz, and Nikos Triandopoulos. Anonysense : A system for anonymous opportunistic sensing. Pervasive and Mobile Computing, 7(1) :16–30, 2011. [63] Sebastian Sonntag, Lennart Schulte, and Jukka Manner. Mobile network measurements-it’s not all about signal strength. In Wireless Communications and Networking Conference (WCNC), 2013 IEEE, pages 4624–4629. IEEE, 2013. [64] Latanya Sweeney. k-anonymity : A model for protecting privacy. International Journal of Uncertainty, Fuzziness and Knowledge-Based Systems, 10(05) :557–570, 2002. [65] Emiliano Trevisani and Andrea Vitaletti. Cell-id location technique, limits and benefits : an experimental study. In Mobile Computing Systems and Applications (WMCSA). Sixth IEEE Workshop on, pages 51–60. IEEE, 2004. [66] Yu Xiao, Pieter Simoens, Padmanabhan Pillai, Kiryong Ha, and Mahadev Satyanarayanan. Lowering the barriers to large-scale mobile crowdsensing. In Proceedings of the 14th Workshop on Mobile Computing Systems and Applications, page 9. ACM, 2013. [67] Jing Yuan, Yu Zheng, Xing Xie, and Guangzhong Sun. Driving with knowledge from the physical world. In Proceedings of the 17th ACM SIGKDD international conference on Knowledge discovery and data mining, pages 316–324. ACM, 2011. 171[68] Arkady Zaslavsky, Charith Perera, and Dimitrios Georgakopoulos. Sensing as a service and big data. arXiv preprint arXiv :1301.0159, 2013. [69] Gabe Zichermann and Christopher Cunningham. Gamification by design : Implementing game mechanics in web and mobile apps. " O’Reilly Media, Inc.", 2011. 172173 Modélisation d’une architecture orientée service et basée composant pour une couche de Transport autonome, dynamique et hautement configurable Guillaume DUGUE To cite this version: Guillaume DUGUE. Mod´elisation d’une architecture orient´ee service et bas´ee composant pour une couche de Transport autonome, dynamique et hautement configurable. Networking and Internet Architecture. Institut National des Sciences Appliqu´ees de Toulouse (INSA Toulouse), 2014. French. HAL Id: tel-01079998 https://tel.archives-ouvertes.fr/tel-01079998 Submitted on 4 Nov 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THÈSE En vue de l’obtention du DOCTORAT DE L’UNIVERSITÉ DE TOULOUSE Délivré par : l’Institut National des Sciences Appliquées de Toulouse (INSA de Toulouse) Présentée et soutenue le 24/09/2014 par : ●✉✐❧❧❛✉♠❡ ❉✉❣✉é Modélisation d’une architecture orientée service et basée composant pour une couche de Transport autonome, dynamique et hautement configurable JURY Christian Fraboul Professeur Président du jury Abdelhamid Mellouk Professeur Rapporteur Philippe Roose Maître de conférence HDR Rapporteur Michaël Mrissa Maître de conférence Examinateur Nicolas Van Wambeke Ingénieur docteur Examinateur Christophe Chassot Professeur Directeur de thèse Khalil Drira Directeur de recherches Co-directeur de thèse Ernesto Exposito Maître de conférence HDR Invité École doctorale et spécialité : MITT : Domaine STIC : Réseaux, Télécoms, Systèmes et Architecture Unité de Recherche : Laboratoire d’Analyse et d’Architecture des Systèmes (UPR 8001) Directeur(s) de Thèse : Christophe Chassot et Khalil Drira Rapporteurs : Abdelhamid Mellouk et Philippe RooseRemerciements Les travaux présentés dans ce documents ont été réalisés au Laboratoire d’Analyse et d’Architecture des Systèmes du Centre National de la Recherche Scienti- fique (LAAS-CNRS), dont la direction a été successivement assurée par MM. R. Chatila, J.-L. Sanchez et J. Arlat que je tiens à remercier pour leur accueil. Mes remerciements vont aussi à M. F. Vernadat, initialement directeur du groupe Outils et logiciels pour la Communication (OLC), et à M. K. Drira, directeur de l’équipe Services et Architectures pour les Réseaux Avancés (SARA), structures au sein desquelles j’ai travaillé. Mes travaux ont été dirigés par MM. C. Chassot et K. Drira, que je tiens à remercier pour leurs retours et leurs conseils tout au long de ce travail. Leur expérience et leur accompagnement dans mes réflexions et mon évolution tant personnelle que professionnelle et scientifique m’ont été d’une grande aide. Les rapporteurs de ce document sont MM. A. Mellouk et P. Roose que je remercie d’avoir accepté cette charge. Je remercie les autres membres du jury, MM. M. Mrissa et N. Van Wambeke et particulièrement M. C. Fraboul qui a accepté d’en être le président. Je tiens à remercier aussi MM. C. Diop et M. Oulmahdi pour leur concours dans mes travaux, ainsi que M. N. Van Wambeke qui a toujours su être disponible en cas de besoin, dans la bonne humeur et ce même après plusieurs années. Je remercie également mes collègues, Silvia, Cédric, Lionel, Guillaume, Denis, Marc et tous les autres avec qui j’ai partagé les bons et moins bons moments et qui ont toujours su faire preuve de soutien dans cette aventure qu’eux aussi traversent ou ont traversé. Je tiens à exprimer également ma gratitude à Mme Garaïos dont le travail m’a permis d’avancer à pas de géant et sans lequel je ne pourrais pas être là où je suis aujourd’hui. Merci à mes amis et ma famille qui ont su faire preuve d’une présence sans faille, notamment mes parents qui ont su m’écouter chaque fois que j’en avais besoin, et Orélie qui m’a supporté avec courage pendant quatre années. Merci à tous car c’est à vous que je dois d’être arrivé jusque là !Résumé L’évolution des réseaux et des applications distribuées liée au développement massif de l’utilisation de l’Internet par le grand public a conduit à de nombreuses propositions, standardisées ou non, de nouveaux protocoles de Transport et à l’évolution des protocoles existants (TCP notamment), destinées à prendre en compte les nouveaux besoins en qualité de service (QoS) des applications et les caractéristiques nouvelles des réseaux sousjacents. Cependant, force est de constater que ces différentes propositions, quoi que pertinentes, ne se sont pas traduites dans les faits et que le protocole TCP reste ultra majoritairement utilisé en dépit de ses limites conceptuelles connues. Ainsi, alors que le contexte applicatif et réseau a évolué de façon extrêmement forte, les solutions protocolaires utilisées au niveau Transport restent sous optimales et conduisent à des performances moindres en termes de QoS, que celles auxquelles permettraient de prétendre les nouvelles solutions. Dans ce contexte, ce document analyse tout d’abord le pourquoi de ce constat en dégageant cinq points de problématique qui justifie la difficulté, et que nous exprimons en termes de complexité (d’utilisation), d’extensibilité, de configurabilité, de dépendance et de déploiement. Sur ces bases, et en réponse à la problématique générale, la contribution de cette thèse consiste non pas à proposer une nouvelle solution protocolaire pour le niveau Transport, mais à redéfinir l’architecture et le fonctionnement de la couche Transport et ses interactions avec les applications. Cette nouvelle couche Transport, que nous avons appelée Autonomic Transport Layer (ATL), vise à permettre l’intégration transparente de solutions protocolaires existantes et futures pour les niveaux supérieurs et inférieurs de la pile protocolaire tout en simplifiant son utilisation par une augmentation du taux d’abstraction du réseau (au sens large) du point de vue des développeurs d’applications. Afin de décharger ces derniers de la complexité d’utilisation des multiples solutions envisageables au niveau Transport, notre solution intègre des principes d’autonomie lui permettant une prise de décision du / des protocoles de Transport à invoquer sans intervention extérieure, et une dynamicité dans l’adaptation de la solution retenue en cours de communication afin de toujours délivrer le meilleur niveau de QoS aux applications quelles que soient les évolutions du contexte applicatif et réseau en cours de communication. Après un état de l’art confrontant les solutions actuelles aux points de problématique identifiés, ce document présente les principes fondamentaux de l’ATL, ainsi que son architecture globale suivant une méthodologie basée sur le formalisme UML 2.0. Deux cas d’utilisation fondamentaux sont ensuite introduits pour décrire l’ATL d’un point de vue comportemental. Finalement, nous présentons différents résultats de mesures de performances attestant de l’utilité d’une solution telle que l’ATL. iAbstract The massive development of Internet and its usage by the public and the subsequent evolution in networks and distributed applications lead to numerous proposals, standardized or not, of new Transport protocols and changes in existing ones (such as TCP) in order to take into account new arising Quality of Service (QoS) applicative needs and the new characteristics of underlying networks. However, no matter how relevant those new solutions are, they are not meeting the success they should because of TCP’s preponderance and overuse in spite of all its well known limits. Therefore, while applications and underlying networks have evolved tremendously, Transport protocols are becoming suboptimal and lead to lesser performances in terms of QoS than what one could expect from newer Transport solutions. In this context the present document analyses the reasons of this situations by indentifying five problematic points which we express in terms of complexity (of use), extensibility, configurability, dependence and deployment. Upon this basis, and trying to address the main problematic, this thesis contribution is not to propose yet another new Transport protocol but to redefine how the Transport Layer operates, its architecture and its interactions with applications. This new Transport Layer, which we call the Autonomic Transport Layer (ATL) aims for transparent integration of existing and future protocol solutions from the upper and lower layers’ point of view as long as simplifying its use by offering a better, wider network abstraction to application developers. To discharge them the complexity of use of the numerous solutions at the Transport level, our solutions integrates autonomy principles to give it decision power over the protocol(s) to instantiate without external intervention and dynamicity so as to be able to adapt the chosen solution during the communication so that it always delivers the best QoS level to applications whatever the contextual evolutions might be for applications or for the network. After a state of the art confronting the current solutions to the different problematic points we identified, this document presents the fundamental principles of the ATL and its global architecture described using UML 2.0. Two major use cases are then introduced to describe the ATL’s behavior. Finally we present several performance figures as evidence of the relevance of a solution such as the ATL. iiiTable des matières Table des matières 1 Table des figures 5 Liste des tableaux 7 Introduction générale 9 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Structure du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1 Contexte, Problématique, État de l’art et Positionnement 13 1.1 Contexte et Problématique . . . . . . . . . . . . . . . . . . . . . . . 14 1.1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.1.1.1 Évolution des réseaux . . . . . . . . . . . . . . . . 15 1.1.1.2 Évolution des terminaux . . . . . . . . . . . . . . . 17 1.1.1.3 Évolution des applications . . . . . . . . . . . . . . 17 1.1.1.4 Évolution des protocoles de Transport . . . . . . . 18 1.1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.1.2.1 Acteurs concernés . . . . . . . . . . . . . . . . . . 20 1.1.2.2 Problèmes soulevés . . . . . . . . . . . . . . . . . . 21 1.2 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.2.1 Protocoles de Transport . . . . . . . . . . . . . . . . . . . . 24 1.2.1.1 TCP . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.2.1.2 UDP . . . . . . . . . . . . . . . . . . . . . . . . . . 27 1.2.1.3 DCCP . . . . . . . . . . . . . . . . . . . . . . . . . 28 1.2.1.4 SCTP . . . . . . . . . . . . . . . . . . . . . . . . . 29 1.2.1.5 MPTCP . . . . . . . . . . . . . . . . . . . . . . . . 30 1.2.1.6 CTP . . . . . . . . . . . . . . . . . . . . . . . . . . 33 1.2.1.7 ETP . . . . . . . . . . . . . . . . . . . . . . . . . . 34 1.2.2 En résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 1Table des matières 1.3 Positionnement de la proposition . . . . . . . . . . . . . . . . . . . 38 1.3.1 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 1.3.2 Exigences générales de conception de l’ATL . . . . . . . . . 39 1.3.3 Paradigmes de conception relatifs à l’architecture de l’ATL . 39 1.3.3.1 Conception logicielle basée composants . . . . . . . 40 1.3.3.2 Conception logicielle orientée service . . . . . . . . 40 1.3.3.3 Autonomic Computing . . . . . . . . . . . . . . . . 40 1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2 Architecture de l’ATL 43 2.1 Exigences de conception et principes l’ATL . . . . . . . . . . . . . . 44 2.1.1 Exigences de conception de l’ATL . . . . . . . . . . . . . . . 44 2.1.2 Principes des solutions proposées en réponse aux exigences de conception de l’ATL . . . . . . . . . . . . . . . . . . . . . 46 2.1.3 Approches d’implantation de ces principes . . . . . . . . . . 48 2.1.3.1 Approche orientée services . . . . . . . . . . . . . . 48 2.1.3.2 Approche basée composants . . . . . . . . . . . . . 50 2.1.3.3 Approche autonomique . . . . . . . . . . . . . . . . 51 2.1.3.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . 51 2.1.4 Fonctionnalités de l’ATL . . . . . . . . . . . . . . . . . . . . 53 2.1.4.1 Fonction de gestion des services . . . . . . . . . . . 53 2.1.4.2 Fonction de gestion autonomique de la communication . . . . . . . . . . . . . . . . . . . . . . . . . 53 2.1.4.3 Fonction d’accueil, d’assemblage et de mise en œuvre des compositions . . . . . . . . . . . . . . . . . . . 54 2.2 Architecture de l’ATL . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.2.1 Cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . 54 2.2.2 Modèle d’architecture de l’ATL . . . . . . . . . . . . . . . . 57 2.2.2.1 Modèle général . . . . . . . . . . . . . . . . . . . . 58 2.2.3 Composants de base de l’ATL . . . . . . . . . . . . . . . . . 60 2.2.3.1 Le Flow . . . . . . . . . . . . . . . . . . . . . . . . 60 2.2.3.2 L’Autonomic Manager . . . . . . . . . . . . . . . . 62 2.2.3.3 Le Data Plan . . . . . . . . . . . . . . . . . . . . . 66 2.2.3.4 Intégrateur des services et base de connaissances . 68 2.2.4 Composants secondaires . . . . . . . . . . . . . . . . . . . . 69 2.2.4.1 Flow Creator . . . . . . . . . . . . . . . . . . . . . 69 2.2.4.2 Signalization Message Controler . . . . . . . . . . 69 2.2.4.3 Multiplexage-démultiplexage entre couche réseau et Flow . . . . . . . . . . . . . . . . . . . . . . . . 70 2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 2Table des matières 3 Description comportementale de l’ATL 73 3.1 Création d’un point d’accès au service de Transport . . . . . . . . . 74 3.1.1 Instanciation d’un Flow . . . . . . . . . . . . . . . . . . . . 74 3.1.2 Application cliente . . . . . . . . . . . . . . . . . . . . . . . 76 3.1.2.1 Application legacy . . . . . . . . . . . . . . . . . . 77 3.1.2.2 Application ATL-aware . . . . . . . . . . . . . . . 79 3.1.2.3 Application smart . . . . . . . . . . . . . . . . . . 80 3.1.3 Application serveur . . . . . . . . . . . . . . . . . . . . . . . 80 3.1.3.1 Application legacy . . . . . . . . . . . . . . . . . . 80 3.1.3.2 Application ATL-aware . . . . . . . . . . . . . . . 81 3.1.3.3 Application smart . . . . . . . . . . . . . . . . . . 81 3.1.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.2 Reconfiguration d’un Flow . . . . . . . . . . . . . . . . . . . . . . . 83 3.2.1 Déroulement d’une reconfiguration . . . . . . . . . . . . . . 83 3.2.1.1 Classification des cas de reconfiguration possibles . 83 3.2.1.2 Suivi du plan de reconfiguration . . . . . . . . . . . 84 3.2.1.3 Déroulement selon les cas . . . . . . . . . . . . . . 85 3.3 Traitement des retransmissions lors des transitions . . . . . . . . . . 88 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 4 Expérimentations et mesures 91 4.1 De la composabilité des protocoles . . . . . . . . . . . . . . . . . . . 92 4.1.1 But de l’expérience . . . . . . . . . . . . . . . . . . . . . . . 92 4.1.2 Description de l’expérience . . . . . . . . . . . . . . . . . . . 93 4.1.2.1 Choix de l’application . . . . . . . . . . . . . . . . 93 4.1.2.2 Micro-protocoles utilisés . . . . . . . . . . . . . . . 94 4.1.2.3 Simulation . . . . . . . . . . . . . . . . . . . . . . 95 4.1.3 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . 97 4.1.3.1 Comparaison des performances de MPTCP avec TCP et UDP . . . . . . . . . . . . . . . . . . . . . 97 4.1.3.2 Comparaison de MPTCP avec et sans mécanismes couplés . . . . . . . . . . . . . . . . . . . . . . . . 98 4.1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.2 De l’intérêt de l’adaptation dynamique . . . . . . . . . . . . . . . . 102 4.2.1 But de l’expérience . . . . . . . . . . . . . . . . . . . . . . . 103 4.2.2 Description de l’expérience . . . . . . . . . . . . . . . . . . . 103 4.2.2.1 Choix de l’application . . . . . . . . . . . . . . . . 103 4.2.2.2 Micro-protocoles . . . . . . . . . . . . . . . . . . . 103 4.2.2.3 Simulation . . . . . . . . . . . . . . . . . . . . . . 104 4.2.3 Analyse des résultats . . . . . . . . . . . . . . . . . . . . . . 104 4.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 3Table des matières 4.3 De l’overhead de la signalisation . . . . . . . . . . . . . . . . . . . . 106 4.3.1 But de l’expérience . . . . . . . . . . . . . . . . . . . . . . . 106 4.3.2 Description de l’expérience . . . . . . . . . . . . . . . . . . . 107 4.3.2.1 Plateforme de test . . . . . . . . . . . . . . . . . . 107 4.3.2.2 Protocoles de signalisation . . . . . . . . . . . . . . 108 4.3.2.3 Protocole expérimental . . . . . . . . . . . . . . . . 112 4.3.3 Résultats attendus . . . . . . . . . . . . . . . . . . . . . . . 114 4.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Conclusion générale 121 Rappel des contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 Flux collaboratifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 A Publications de l’auteur 125 A.1 Revue internationale avec actes et comité de lecture . . . . . . . . . 125 A.2 Conférences et workshop internationaux avec actes et comité de lecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Acronymes 127 Bibliographie 129 4Table des figures 1.1 L’environnement présente aujourd’hui des solutions multiples à des situations multiples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 1.2 Décomposition des fonctions de transport . . . . . . . . . . . . . . . . 31 1.3 Décomposition de MPTCP en sous-couches . . . . . . . . . . . . . . . 32 1.4 Organisation schématique d’ETP . . . . . . . . . . . . . . . . . . . . . 35 2.1 Cas d’utilisation impliquant les applications . . . . . . . . . . . . . . . 55 2.2 Cas d’utilisation impliquant les utilisateurs humains . . . . . . . . . . . 56 2.3 Diagramme de structure composite de premier niveau . . . . . . . . . . 59 2.4 Composition d’un Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 2.5 Organisation des fonctions de l’Autonomic Manager . . . . . . . . . . . 63 2.6 Caractéristiques du Touchpoint et lien avec l’Autonomic Manager . . . 64 2.7 La composition du Data Plan . . . . . . . . . . . . . . . . . . . . . . . 67 3.1 Une application de type aware ou smart ouvre un point d’accès au service de Transport via l’interface de contrôle de l’ATL . . . . . . . . 75 3.2 Diagramme de séquence de création d’un Flow . . . . . . . . . . . . . . 76 3.3 Instanciation d’un nouveau Flow . . . . . . . . . . . . . . . . . . . . . 77 3.4 Mécanisme de découverte de l’ATL . . . . . . . . . . . . . . . . . . . . 78 3.5 Suivi du plan de reconfiguration . . . . . . . . . . . . . . . . . . . . . . 86 4.1 La topologie du réseau simulé . . . . . . . . . . . . . . . . . . . . . . . 95 4.2 PNSR par image en utilisant MPTCP, scénario 4 . . . . . . . . . . . . 100 4.3 PNSR par image en utilisant MPTCP-PR, scénario 4 . . . . . . . . . . 101 4.4 PNSR par image en utilisant MPTCP-SD, scénario 4 . . . . . . . . . . 102 4.5 La topologie utilisée pour les tests . . . . . . . . . . . . . . . . . . . . . 107 4.6 Cas d’utilisation du protocole de synchronisation d’ETP . . . . . . . . 108 4.7 Diagramme de séquence du cas d’utilisation Distributed Sender Based . 110 4.8 Préparation à la reconfiguration . . . . . . . . . . . . . . . . . . . . . . 111 4.9 Caractéristiques des cinq environnements réseau et compositions associées113 4.10 Taux de pertes de l’environnement . . . . . . . . . . . . . . . . . . . . 115 4.11 Taux de pertes vu par le service de Transport . . . . . . . . . . . . . . 116 5Table des figures 4.12 Taux de pertes vu par le service sans système de reconfiguration . . . . 117 4.13 Délai induit par l’environnement . . . . . . . . . . . . . . . . . . . . . 118 4.14 Délai vu par le service . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 4.15 Délai vu par le service sans système de reconfiguration . . . . . . . . . 120 6Liste des tableaux 1.1 Résumé de la problématique . . . . . . . . . . . . . . . . . . . . . . . . 24 1.2 Résumé du problème d’extensibilité . . . . . . . . . . . . . . . . . . . . 37 1.3 Résumé du problème de configurabilité . . . . . . . . . . . . . . . . . . 37 1.4 Résumé du problème d’assujettissement . . . . . . . . . . . . . . . . . 37 1.5 Résumé du problème de déploiement . . . . . . . . . . . . . . . . . . . 38 2.1 Synthèse des problèmes, exigences, principes et approches de conception de l’ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.1 Résumé des scénarios 1 et 2 . . . . . . . . . . . . . . . . . . . . . . . . 96 4.2 Résumé des scénarios 3 à 5 . . . . . . . . . . . . . . . . . . . . . . . . . 96 4.3 Résumé des scénarios 6 et 7 . . . . . . . . . . . . . . . . . . . . . . . . 96 4.4 Les correspondances entre PNSR et MOS . . . . . . . . . . . . . . . . 97 4.5 PNSR moyen en dB des simulations 1 à 4 . . . . . . . . . . . . . . . . 97 4.6 PNSR moyen en dB des simulations 5 à 7 . . . . . . . . . . . . . . . . 98 4.7 Délai moyen en millisecondes des simulations 1 à 4 . . . . . . . . . . . 98 4.8 Délai moyen en millisecondes des simulations 5 à 7 . . . . . . . . . . . 98 4.9 Taux de pertes des simulations 1 à 4 . . . . . . . . . . . . . . . . . . . 98 4.10 Taux de pertes des simulations 5 à 7 . . . . . . . . . . . . . . . . . . . 99 4.11 Résumé des scénarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.12 PNSR en dB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 4.13 PNSR obtenu sans et avec adaptation dynamique . . . . . . . . . . . . 105 7Introduction générale Contexte L’évolution du paysage numérique au cours de la dernière décennie a été radicale à différents niveaux. L’ouverture au grand public de l’Internet et l’explosion de son utilisation qui a suivi, ont ainsi considérablement modifié l’utilisation qui est faite du réseau. Les applications multimédia et interactives sont aujourd’hui plébiscitées et ajoutent aux transferts de fichiers classiques ceux de flux audio et vidéo et plus généralement des échanges de données possédant des contraintes temporelles fortes comme les jeux en ligne. Ces nouvelles applications créent de nouveaux besoins sur le transfert des flux d’informations échangés qui ne sont plus correctement pris en compte par les solutions protocolaires traditionnelles. Parallèlement les terminaux ont également suivi une évolution drastique, multipliant en leur sein les interfaces d’accès au réseau et donnant accès à de grandes capacités de stockage ou de puissance de calcul, y compris sur des machines nomades ou mobiles. Les parcs de serveurs (ou datacenters) sont devenus communs et permettent aux utilisateurs humains un accès continu et en tout lieu à leurs données personnelles. Ces machines et les communications qu’elles établissent offrent de nouvelles perspectives et créent ainsi de nouveaux contextes de besoins (en de débit ou de temps de transfert par exemple) pour lesquelles les protocoles actuels ne sont pas prévus. Enfin, les réseaux eux-mêmes ont profondément évolué, et permettent dorénavant le nomadisme et la mobilité des terminaux de façon généralisée. Dans tous les domaines, que les réseaux soient locaux ou longue distance, avec ou sans fil, les capacités ont été décuplées. De nouveaux types de systèmes intermédiaires, appelés middleboxes, ont également été introduits, créant des situations inédites (le blocage de protocoles non reconnus par exemple) auxquelles ont à faire face les développeurs de solutions protocolaires. Dans ce contexte et historiquement, les protocoles de Transport traditionnels de l’Internet, tels que TCP et UDP, ont connu plusieurs évolutions et adaptations et de nouvelles solutions ont vu le jour comme DCCP, SCTP at plus récemment 9Introduction générale MPTCP. Le paysage des solutions protocolaires s’est donc densifié et complexifié, contribuant à créer un nouveau contexte auquel il s’agit aujourd’hui de faire face. Problématique Ce nouveau contexte crée plusieurs points problématiques, tant du point de vue du développement d’applications que de la création de nouvelles solutions protocolaires. Le développement d’applications se heurte à un choix large et complexe de solutions protocolaires au niveau Transport, requérant une expertise complète des protocoles existants, tant vis-à-vis du choix du protocole à utiliser que de sa confi- guration afin d’en faire une utilisation optimale. Le développeur d’applications doit donc, en plus d’effectuer les choix de la solution et de sa configuration, implémenter la gestion du protocole même au sein de son application. Du point de vue du développeur de protocoles, la création protocolaire se heurte à deux problèmes majeurs. Le premier concerne l’extensibilité des protocoles existants. Toutes les solutions existantes ne permettent pas la création d’extensions. Certaines ne sont pas assez utilisées pour motiver la création de nouvelles options. Créer entièrement une nouvelle solution n’est pas plus aisé : en effet, celle-ci doit déjà être implémentée dans les différents systèmes d’exploitation, afin de permettre son utilisation au sein des différentes applications, qui doivent donc être mises à jour. Les middleboxes créent également des freins à l’adoption de nouvelles solutions protocolaires. Ces systèmes intervenant au niveau Transport, les nouvelles solutions doivent donc y être implémentées sous peine de se voir bloquées. De ce constat global, nous dégageons cinq points de problématique limitant l’évolution du paysage protocolaire actuel au niveau Transport, relatifs : à la complexité de choix et d’utilisation des protocoles, à la configurabilité des protocoles, à leur extensibilité, à l’assujetissement des applications aux solutions protocolaires et au déploiement des nouveaux protocoles Nous proposons dans ce manuscrit d’adresser ces cinq points via la redéfinition de l’architecture et du fonctionnement de la couche Transport actuelle, dans le but d’offrir un point d’accès générique au service de Transport qui laisse à l’application le soin de préciser le service qu’elle désire et non la solution à utiliser. Dans l’approche proposée, la solution protocolaire retenue est choisie de manière dynamique et autonome afin de fournir le service désiré par composition potentielle de plusieurs solutions protocolaires. Le but est d’offrir une abstraction plus poussée du réseau au sens large en déchargeant le développeur d’application de responsabilités qui ne devraient pas lui incomber. Le choix dynamique et autonome des solutions de Transport permet également de simplifier le déploiement de nouvelles solutions, 10rendant leur intégration transparente et leur adoption automatique à mesure que le déploiement progresse. Les contributions de ce manuscrit posent les bases architecturales et comportementales d’une telle couche de Transport que nous appelons Autonomic Transport Layer (ATL). Structure du document Le présent document est divisé en quatre chapitres. Le premier chapitre expose en détails le contexte dans lequel s’inscrivent les travaux présentés avant d’expliquer plus avant les cinq points de problématiques identifiés. Un état de l’art des solutions de Transport est ensuite exposé, décrivant le fonctionnement de différents protocoles classiques comme TCP, UDP, DCCP ou SCTP, ainsi que des solutions plus récentes ou en cours d’étude comme MPTCP, CTP ou ETP. Chacun de ces protocoles est confronté aux différents points de la problématique. Nous en déduisons les limites des solutions actuelles qui nous mènent à introduire l’approche d’une architecture nouvelle pour la couche Transport, à la fois orientée services, basée composants et dotée de capacités d’autonomie vis-à-vis des choix de composition à entreprendre pour répondre aux besoins des applications actuelles, dites legacy, et de celles à venir, conscientes de l’ATL. Le deuxième chapitre décrit le modèle architectural de l’ATL, c’est-à-dire la structure composite et le rôle de chaque composant nécessaire au fonctionnement de l’ATL. Dans un premier temps, nous décrivons les objectifs de l’ATL ainsi que les grands principes régissant sa conception : ceux architectures orientées services et des architectures basée composants. Dans un second temps, nous décrivons les trois grands types de fonctionnalités que l’ATL doit prendre en charge dans ses actions de gestion, de contrôle et de données. Ces différents principes mis en place, nous décrivons, suivant une approche top/down, la structure des différents composants de l’ATL et le rôle de chacun. Le troisième chapitre reprend les éléments introduits dans le chapitre 2 et décrit leur comportement dans deux cas majeurs d’utilisation de l’ATL. Le premier cas est celui de l’ouverture d’un point d’accès au service de Transport. Celui-ci diffère en effet notablement de l’ouverture d’un point d’accès classique (tels que via les sockets TCP/UDP) et doit prendre en compte différents cas nouveaux introduits par la présence de l’ATL. Le second cas de figure concerne la reconfiguration dynamique du service de Transport. L’ATL offrant cette possibilité inédite, il est intéressant de décrire son déroulement afin d’en étudier par la suite les impacts sur la communication. Le quatrième chapitre présente trois études réalisées autour de l’ATL. La première, menée en simulation, vise à combiner un protocole existant avec des mé- 11Introduction générale canismes génériques externes afin d’observer le bénéfice retiré lors d’un transfert multimédia interactif. La deuxième, également menée en simulation, tend à véri- fier le bénéfice induit par le passage d’une telle combinaison à une autre en cours de communication, en fonction de l’évolution des conditions du réseau. Ces deux études tendent à prouver qu’un véritable apport peut être retiré d’un tel fonctionnement de la couche Transport, mais appuient l’intérêt d’une mise en œuvre autonome comme celle apportée par l’ATL. La troisième expérience tente d’observer le coût induit par la signalisation nécessaire à une reconfiguration en cours de communication. Finalement, nous terminons ce document par une conclusion générale qui ré- sume les points abordés et les contributions apportées. Elle introduit également des perspectives de travail futur afin de préciser le modèle architectural actuel et d’étudier certaines problématiques auxquelles il est nécessaire de répondre pour offrir, via les principes de l’ATL une solution performante et utilisée. 12CHAPITRE 1 Contexte, Problématique, État de l’art et Positionnement Ce chapitre présente le contexte dans lequel s’inscrit le travail décrit plus loin dans ce manuscrit. Dans la première partie, nous présentons tout d’abord l’évolution des réseaux en termes de technologies de transmissions — passage des technologies filaires aux technologies sans-fil nomades et mobiles, mais également des évolutions des terminaux qui ont vu leurs capacités augmenter, leurs types se diversifier avec l’apparition des appareils mobiles ou des capteurs, ainsi que l’apparition d’interfaces multiples, mêlant des technologies d’accès diverses sur un même appareil. Par la suite nous évoquons les différents types de services que peuvent requérir les applications en fonction de leurs besoins de communication, ainsi que l’apparition de nouveaux besoins dus à l’avènement du multimédia et des applications interactives. Finalement, nous voyons comment ces évolutions ont été adressées au niveau Transport de la pile protocolaire. Nous tirons ensuite de ce contexte cinq points de problématiques que nous nommons configurabilité, extensibilité, assujettissement, déploiement et complexité de choix. Ces cinq points servent par la suite à confronter les différentes solutions existant au niveau Transport dans la deuxième partie du chapitre. Au cours de cet état de l’art, les protocoles classiques que sont Transmission Control Protocol (TCP) et User Datagram Protocol (UDP) et des protocoles plus récents comme Datagram Congestion Control Protocol (DCCP) ou Stream Control Transmission Protocol (SCTP) sont présentés puis mis à l’épreuve face à ces différents points. Des lacunes et mérites de chacun nous décrivons dans la troisième partie la vision scientifique dans laquelle s’inscrivent les contributions scientifiques qui seront présentées dans les chapitres suivants : celle d’une couche de Transport orientée service et basée composant, offrant un meilleur degré d’abstraction du réseau du point de vue 131. Contexte, Problématique, État de l’art et Positionnement de l’application et permettant la gestion et l’optimisation du fonctionnement des protocoles de Transport sans intervention de cette dernière. Sommaire 1.1 Contexte et Problématique . . . . . . . . . . . . . . . . . . . . 14 1.1.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . 19 1.2 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 1.2.1 Protocoles de Transport . . . . . . . . . . . . . . . . . 24 1.2.2 En résumé . . . . . . . . . . . . . . . . . . . . . . . . . 37 1.3 Positionnement de la proposition . . . . . . . . . . . . . . . . . 38 1.3.1 Approche . . . . . . . . . . . . . . . . . . . . . . . . . 38 1.3.2 Exigences générales de conception de l’Autonomic Transport Layer (ATL) . . . . . . . . . . . . . . . . . . . . . 39 1.3.3 Paradigmes de conception relatifs à l’architecture de l’ATL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 1.1 Contexte et Problématique Cette première partie s’articule en deux sous-parties. La première présente le contexte dans lequel s’inscrivent nos travaux, en faisant l’état de l’évolution des réseaux et de leurs utilisations en quatre temps : tout d’abord du point de vue des technologies de transmission et de leur disparité, puis des terminaux utilisant ces technologies pour communiquer entre eux et de leur diversité ; ensuite, nous nous intéressons aux applications et à l’évolution de leurs besoins avant de terminer en évoquant la manière dont les protocoles de Transport ont tenté d’apporter une réponse à ces environnements variables et nouveaux. La seconde déduit de ce contexte les cinq points de problématique auxquels nous confrontons les différentes solutions de l’état de l’art dans la partie suivante. 1.1.1 Contexte Les réseaux informatiques ont pris une place prépondérante dans notre société, notamment Internet qui a profondément modifié, et modifie encore, le tissu économique et social à un niveau mondial. Tout ceci repose aujourd’hui sur des échanges de données à très grande vitesse, sur des distances de plusieurs centaines de kilomètres, très souvent traversant plusieurs continents, connectant des terminaux très divers. 141.1. Contexte et Problématique L’évolution observée depuis l’ouverture d’Internet au grand public a considé- rablement changé les usages qui sont faits du réseau. Le web notamment, a évolué de manière à permettre un accès simple à de nombreux usages encore trop mé- connus ou complexes et leur démocratisation a permis leur utilisation aujourd’hui massive. Ainsi, à l’utilisation des mails et de l’échange de fichiers, est venue s’additionner celle de l’audio, la vidéo ou les applications interactives, comme les jeux multi-joueurs en ligne ou les vidéoconférences. Les besoins d’hébergement liés au grand nombre d’utilisateurs ont entraîné la création de datacenters. Au sein de ces structures, des centaines de serveurs topologiquement proches doivent communiquer à très grande vitesse, organisés en grille. Le monde de la finance a automatisé certains de ses processus, créant le high frequency trading, des transactions financières à raison de plusieurs milliers par secondes. Ces situations sont des exemples d’une évolution qui a emmené le réseau bien loin de ce à quoi il ressemblait quelques dizaines d’années auparavant. La diversité des technologies réseaux, des terminaux et des types d’applications n’a jamais été aussi grande. Dans la suite de cette section, nous voyons l’évolution de ces trois domaines et nous évoquons comment les protocoles de Transport ont tenté de s’adapter à cette évolution. 1.1.1.1 Évolution des réseaux Le contexte traditionnel et historique des réseaux est bien évidemment celui des réseaux filaires. Les différentes machines sont reliées ensemble par des câbles sur lesquels transitent les signaux électriques représentant les données à transmettre. De nombreux protocoles se sont développés suivant ce principe. Dans le domaine des réseaux locaux, ou LAN (Local Area Network) le protocole Ethernet [IEE12a], qui s’est imposé comme incontournable, permettait initialement des capacités de 10 Mbps, permet aujourd’hui des capacités de 10 Gbps et cette capacité continue de croître. De plus, des déclinaisons de ce protocole ont été avancées afin de l’utiliser sur des réseaux métropolitains ou MAN (Metropolitan Area Network) et sur des réseaux longue distance ou WAN (Wide Area Network). En MAN ou en WAN, les technologies xDSL (Digital Subscriber Line), connues en France pour l’ADSL (Asynchronous DSL) [ITU99a] et l’ADSL2 [ITU99b] et bientôt l’arrivée du VDSL (Very high bit-rate DSL) [ITU11b] ont permis l’accès à haut débit à la majorité des foyers, cette augmentation étant supportée dans les cœurs de réseaux par l’utilisation de protocoles comme SDH [ITU07]. L’évolution des réseaux filaires a donc été caractérisée par une augmentation des débits et un nombre croissants d’utilisateurs. Tous les types de réseaux ont également connus des évolutions via des accès sans fil. Le WiFi [IEE12b], en constante évolution et permettant déjà des débits 151. Contexte, Problématique, État de l’art et Positionnement de plusieurs dizaines voire centaines de Mbps, en accès WLAN comme WMAN, est utilisé par de plus en plus d’appareils, fixes, nomades ou mobiles. Les réseaux WMAN et WWAN ont également eu leur lot de nouveautés, grâce au WiMaX ou aux évolutions toujours constantes des réseaux mobiles, comme la 3G (UMTS et HSPA), et déjà 4G (LTE), et bien sûr les réseaux satellites [ETS13]. Ces réseaux sans-fil introduisent de nouveaux défis, le médium étant partagé entre tous les utilisateurs et sensible au bruit électromagnétique, les causes de pertes de données seront plus diverses et certaines hypothèses valables sur les ré- seaux filaires deviennent caduques. Ce type de support permet également à l’utilisateur de devenir nomade ou mobile. Il peut alors se connecter au réseau successivement depuis des localisations géographiques différentes, voire se déplacer en cours de communication. Chacun se voit connecté de manière permanente et non plus ponctuelle, via un terminal ou un autre. Au fil du temps, différents éléments ont été introduits au sein du réseau afin d’en améliorer les performances ou de pallier des problèmes de sécurité. Certains de ces éléments brisent une notion capitale dans le modèle classique de la pile OSI : le caractère de bout en bout de la couche Transport. En effet, celle-ci est supposée n’être implémentée que sur les hôtes terminaux de la communication et non sur les éléments intermédiaires, ces derniers n’implémentant que les niveaux suivants : physique, liaison de données et réseau. Certains éléments intermédiaires, nommés middleboxes [Car02], rompent cette règle. En effet, celles-ci vont intervenir sur l’entête de niveau Transport, que ce soit de manière passive, en lecture uniquement, ou active, en la modifiant. Par exemple, les Network Address Translator (NAT) ont besoin d’utiliser le numéro de port pour fonctionner, et doivent donc avoir une compréhension des différents protocoles de Transport utilisés afin d’aller lire les valeurs dont ils ont besoin dans l’en-tête de Transport. Bien qu’intervenant de manière uniquement passive sur le niveau Transport, si le NAT n’implémente pas le protocole utilisé, la communication risque d’être rompue. De la même manière, les Performance Enhancement Proxies (PEP) interrompent, de manière transparente pour les hôtes d’extrémité, la communication. Dans le cas de TCP par exemple, ceux-ci répondent à la demande de connexion à la place de l’hôte terminal visé, se faisant passer pour celui-ci, coupant ainsi la connexion de niveau Transport en deux ou plusieurs tronçons distincts quand celle-ci n’est censée être composée que d’un seul. Comme pour les NAT, si un PEP n’a pas implémenté un certain protocole de Transport, tout trafic véhiculé par celui-ci sera interrompu par le PEP. 161.1. Contexte et Problématique 1.1.1.2 Évolution des terminaux Parallèlement aux réseaux les terminaux ont également subi une forte évolution ces dernières décennies. L’arrivée des réseaux nomades et mobiles a permis la création de terminaux portables et transportables, dont les smartphones et tablettes sont les plus récents exemples. Les stations de travail ont disparu au profit d’une convergence avec les ordinateurs personnels, permettant à tous d’avoir accès à une puissance de traitement honorable. Les capacités de stockage ont également fortement évolué. L’accessibilité accrue à ces ressources a créé une explosion de la demande en terme de contenus. Ainsi, afin d’y subvenir, de nombreux datacenters ont vu le jour à travers le monde, créant des organisations topologiques de machines inédites, véritables concentrations de serveurs aux capacités de stockage se comptant parfois en exaoctets, et aux capacités de calcul de plusieurs teraflops. Tout ceci crée un environnement aux caractéristiques très hétérogènes, certains terminaux possédant des débits plus importants que d’autres, des ressources en terme d’énergie, de stockage ou de puissance de calcul différentes. Un même terminal peut également voir ses caractéristiques changer en cours de communication, à cause de la charge de la batterie des terminaux mobiles, ou lorsque l’interface réseau utilisée change, la plupart des systèmes possédants aujourd’hui plusieurs interfaces, de nature différentes ou non. En effet, la plupart des smartphones possèdent au moins aujourd’hui des interfaces WiFi, Bluetooth et USB en plus de leur antenne téléphonique, celle-ci implémentant la plupart du temps des technologies 2G et 3G, voire 4G, quand ceux-ci ne disposent pas en plus du WiMaX. Les ordinateurs portables disposent presque tous d’une interface Ethernet et WiFi. La plupart des serveurs disposent aujourd’hui de plusieurs interfaces Ethernet. 1.1.1.3 Évolution des applications L’augmentation des performances des machines et des réseaux a permis l’avènement de nouvelles applications et l’amélioration des applications existantes. Cellesci font parfois preuve de besoins radicalement différents de ce que l’on connaissait. Aux applications traditionnelles sont en effet venues s’ajouter les applications multimédia et interactives. Les applications traditionnelles, principalement basées sur l’échange de fichiers, présentaient toutes les mêmes besoins d’ordre et fiabilité totaux dans le transfert de leur données. En effet, chaque octet doit arriver intact et dans l’ordre d’émission à l’application réceptrice afin que celle-ci puisse reconstituer à l’identique le fichier d’origine, qu’il s’agisse d’un envoi de mail, d’une page web, ou d’un transfert de fichier quelconque. Les applications multimédia quant à elles présentent des besoins différents. Par exemple, un streaming vidéo aura besoin d’ordre, mais la fiabilité n’a plus 171. Contexte, Problématique, État de l’art et Positionnement à être totale. Il n’y a en effet aucun besoin de retransmettre une image dont la date d’affichage est dépassée. Certaines données deviennent donc obsolètes avec le temps. De plus, les méthodes de compression actuelles différencient les images leur attribuant des importances différentes. Il est donc possible d’appliquer un traitement discriminant à l’intérieur d’un flux de données, contrairement à un transfert de fichier, où chaque octet a la même importance que les autres. Les applications interactives, mettant en relation plusieurs personnes, réagissant les unes par rapport aux actions des autres, créent encore plus de besoins inédits. Afin que les interactions entre les participants soient fluides, qu’il s’agisse de jeu vidéo ou de vidéoconférence, le délai de transit d’un participant à l’autre doit être suffisamment court pour qu’il ne soit pas perceptible. En effet, pour un jeu vidéo de tir par exemple, type FPS, l’expérience jeu serait ruinée si lorsque vous tirez sur votre adversaire, celui-ci est en réalité à un endroit différent de celui où vous le voyez sur votre écran. Dans une communication, les délais trop longs risquent, en plus de saccader la conversation, de créer des échos très désagréables. Dans [ITU11a], l’Union Internationale des Télécommunications (ITU-T) établit une classification générale et non exhaustive des applications de types audio, vidéo et données existantes en fonction de leur tolérance aux pertes de données lors des transmissions, et des délais de transmission admissibles. Celles-ci sont réparties selon : – leur tolérance ou intolérance aux pertes ; – les délais qu’elles peuvent supporter, et sont alors subdivisées en quatre catégories : – interactivité, – réactivité, – ponctualité, – non criticité du délai. Notons que certaines catégories sont apparues grâce à l’émergence des applications audio et vidéo, et que d’autres, telle la télécopie, plus tolérante par exemple qu’un transfert de fichiers, peut être satisfaite avec l’utilisation d’un service de Transport plus stricte que ce qu’elle requiert. On observe ainsi une évolution des catégories due non seulement à l’apparition de nouveaux types d’application, mais également à la précision de certaines distinctions qui pouvaient auparavant sembler superflues. 1.1.1.4 Évolution des protocoles de Transport Dans ces environnements très hétérogènes, la couche Transport du modèle OSI remplit un rôle particulier. En effet, elle a longtemps été la couche la plus haute implémentée dans la pile protocolaire (si on excepte la couche applicative), et donc en charge de faire le lien entre le réseau et les applications. Ainsi, il a semblé naturel 181.1. Contexte et Problématique d’introduire à ce niveau les modifications nécessaires à l’adaptation à ces nouveaux environnements. Si le paysage protocolaire de cette couche a longtemps été dominé par TCP [Pos81] et UDP [Pos80], des protocoles nouveaux ou des adaptations de protocoles existants ont été étudiés et standardisés, créant ainsi une multiplication des solutions, et une multiplication des API permettant de les utiliser. Ces nouveaux protocoles se concentrent principalement sur la réponse à apporter à une situation donnée, leur conception souvent monolithique n’accordant pas la possibilité de choisir les fonctionnalités à utiliser suivant les cas. Le choix traditionnel étant alors limité à un service total en utilisant TCP, ou nul en utilisant UDP. La responsabilité de ce choix est d’ailleurs toujours à la charge du développeur d’applications. En effet, la vision de la couche Transport aujourd’hui communément admise est celle d’une collection de protocoles disjoints les uns des autres, qui sont appelés par l’application désirant les utiliser. Il revient donc à celle-ci d’invoquer la méthode d’appel du protocole qu’elle souhaite utiliser. Cet appel est décidé en design time, c’est -à-dire que le développeur choisit le protocole qu’il juge le plus pertinent et implémente l’appel à ce protocole particulier dans son application. Cette manière de faire ne laisse aucune place à une utilisation du protocole basée sur une estimation du contexte au cas par cas, sauf à implémenter ce type de prise de décision au sein de l’application, et donc à lui faire endosser une responsabilité supplémentaire. L’invocation d’une solution de Transport se faisant par l’appel à un protocole particulier, c’est également au développeur que revient la charge d’estimer quel protocole satisfait le mieux le service qu’il souhaite. Il existe ici un besoin d’abstraction supplémentaire, le développeur devant faire lui même la correspondance entre service et solution protocolaire. La figure 1.1 résume les différents défis qui se présentent dans le réseau à l’heure actuelle. 1.1.2 Problématique Un environnement aussi évolutif crée différents problèmes, notamment celui de la complexité pour un développeur d’application de faire le bon choix de protocole mais aussi la complexité pour le développeur de protocoles d’intégrer une nouvelle solution au paysage existant. Dans cette section, nous commençons par présenter les différents acteurs concernés par la problématique, avant d’effectuer un tour d’horizon détaillé des différents points de celle-ci. Comme nous le verrons plus tard, certains points peuvent concerner plusieurs acteurs à la fois. 191. Contexte, Problématique, État de l’art et Positionnement Figure 1.1: L’environnement présente aujourd’hui des solutions multiples à des situations multiples 1.1.2.1 Acteurs concernés Trois types d’acteurs portant chacun un regard différent sur l’environnement sont identifiables : – le développeur d’applications ; – le développeur de protocoles ; – le développeur de système d’exploitation. Le souci du développeur d’applications est d’une part la simplicité d’utilisation du service, et d’autre part la conformité du service fourni par le protocole aux besoins de l’application qu’il développe. Il lui serait en effet contre-productif ou sous-optimal de devoir apprendre tous les rouages d’une solution pour l’utiliser pleinement, et d’apprendre ceci pour un nombre conséquent de solutions afin de faire des choix éclairés selon les situations. De même, il est difficilement concevable d’amener le développeur d’applications à réécrire toute ou partie de son application à l’avènement de chaque nouvelle solution au niveau Transport. Le développeur de protocoles se soucie de la capacité à faire adopter facilement son protocole ou son amélioration d’un protocole existant. En effet, une fois la solution développée, il faut qu’elle soit promue : 1. auprès des développeurs d’applications pour les convaincre de l’intérêt d’apprendre à utiliser la nouvelle solution ; 2. auprès des développeurs de systèmes d’exploitation pour les convaincre de 201.1. Contexte et Problématique l’intérêt d’intégrer la solution dans leur système ; 3. auprès des équipementiers pour les convaincre de l’utilité d’implémenter cette solution dans les différentes middleboxes qu’ils produisent. Le développeur système se soucie quant à lui de la facilité d’intégrer une nouvelle solution ou de mettre à jour une solution existante. Il souhaite en effet minimiser la réécriture de son code pour chaque opération d’ajout ou de mise à jour. 1.1.2.2 Problèmes soulevés Partant de l’évolution du contexte applicatif, machine et réseau, des réponses apportées au niveau Transport et des préoccupations des différents acteurs concernés, nous idendifions cinq points de problématique. Tel qu’évoqué précédemment, certains points concernent plusieurs acteurs. Problème de complexité (vis à vis de la connaissance, du choix et de l’utilisation des protocoles) La complexité des solutions protocolaires actuelle s’exprime à différents niveaux et permet de soulever trois problèmes, décrits ci-après. – Les protocoles de Transport sont de nature assez complexe de par leurs principes de fonctionnement, les techniques sur lesquelles sont basés leurs mé- canismes, et enfin leurs algorithmes. Cette complexité a en particulier un impact direct sur la QoS offerte, dont il est important d’avoir conscience lorsque l’on souhaite répondre à des besoins en QoS des applications. Par exemple, un mécanisme de contrôle de congestion basé fenêtre, tel que celui appliqué dans la version de base de TCP, induit une variation du débit et du délai, incompatible avec les besoins en débit constant et en délai borné des applications multimédia interactives. Le premier problème alors posé résulte du constat que cette complexité n’est, dans les faits, pas transparente aux développeurs d’applications : ceux-ci doivent avoir une connaissance fine du fonctionnement du protocole sous-jacent avant de pouvoir développer leurs applications. Ceci nécessite des connaissances fines pour des développeurs dont les protocoles de Transport n’est pas le domaine d’expertise. – Les protocoles de Transport sont également complexes dans leur utilisation. En effet, l’usage du service offert se fait via une interface de programmation (ou API pour Application Programming Interface), dont la maîtrise nécessite généralement des connaissances dans plusieurs domaines, notamment en programmation système. – Enfin, la multiplication des propositions de protocoles de Transport et d’API confronte le développeur d’applications à une troisième difficulté relevant du choix de la solution la mieux adaptée aux besoins de son application. 211. Contexte, Problématique, État de l’art et Positionnement Problème de dépendance (ou d’assujetissement) (de l’application au protocole invoqué) La complexité du choix du protocole n’est pas le seul problème qui résulte du caractère évolutif des solutions. En effet, ce choix s’effectue en design time, c’est à dire au moment de la conception de l’application. Ceci implique que l’application doit être écrite pour un protocole donné et s’y tenir pendant tout son cycle de vie. Le problème vient alors du fait que la solution protocolaire choisie peut ne plus être plus adaptée aux besoins de l’application, en raison de changement des contraintes réseau par exemple, ou suite à l’évolution des besoins de l’application. Notons que ce problème ne concerne pas uniquement les nouvelles solutions protocolaires, mais également toute migration d’une application vers une autre solution protocolaire. Ceci est dû au fait que son code est spécifique et ne peut fonctionner que sur cette solution, et tout changement de protocole doit impérativement passer par des modifications (à différentes échelles d’importance) du code de l’application. Cette dépendance aux protocoles, outre ses conséquences directes, est aussi en partie à l’origine des problèmes d’extensibilité et de déploiement décrits ci-après. Problème d’extensibilité (des solutions protocolaires existantes) Le problème d’extensibilité comporte plusieurs facettes. – L’intégration d’une nouvelle solution, ou la mise à jour d’une solution existante, pose un problème pour les développeurs de systèmes d’exploitation. En effet, toute modification protocolaire, impose des modifications dans les systèmes les hébergeant. Ceci concerne leur intégration dans les nouvelles versions du système, la mise à jour des versions antérieures ou la gestion de la compatibilité entre les deux. Ces implications expliquent la réticence des développeurs de systèmes d’exploitation vis à vis de l’adoption de nouvelles solutions, et conduit au constat que les environnements systèmes sont actuellement hétérogènes en termes de solutions de Transport supportées. – Du point de vue des développeurs de protocoles, le constat précédent constitue un véritable obstacle quant à leur volonté de développer de nouvelles solutions étant donné la probabilité importante de non acceptation par les systèmes, ou au mieux, au regard des délais importants dans l’intégration (généralement plusieurs années). – Du point de vue des développeurs d’applications, ces environnements hété- rogènes les conduisent eux-aussi à prendre des précautions quant à l’usage de nouvelles solutions, personne ne pouvant accepter que son application ait des problèmes de fonctionnement pour la simple raison qu’elle tourne au sein d’un système qui ne supporte pas le protocole de Transport désiré. En résumé, les développeurs d’applications attendent que les solutions de Trans- 221.1. Contexte et Problématique port soient largement déployées pour les utiliser, pendant que dans le même temps, les développeurs de systèmes d’exploitation attendent que ces solutions soient utilisées par les applications avant de les déployer. Ce cercle vicieux fait que le problème d’extensibilité constitue la cause principale du problème de déploiement décrit ciaprès. Problème de déploiement (des nouvelles solutions protocolaires) Le déploiement de nouvelles solutions est le problème le plus restreignant dans l’évolution de la couche Transport. Il regroupe les problèmes d’extensibilité et de dépendance au protocole, en plus du problème de l’acceptabilité par le réseau. – Tel que décrit précédemment, le problème d’extensibilité est à la source des difficultés d’adoption de nouvelles solutions par les systèmes, de leur utilisation par les applications, et en conséquence de leur développement lui-même. Vient ensuite le problème de dépendance des applications aux protocoles de Transport sous-jacents qui fait que toute modification de ces derniers impose des modifications pour les applications. – A ceci vient s’ajouter le problème d’acceptabilité par le réseau. En effet, les middleboxes, quelles que soient leurs fonctions, ont souvent des politiques de fonctionnement basées sur les types de protocoles et leurs contenu. Toute modification d’un protocole existant ou intégration d’un nouveau protocole impose la mise à jour de ces middleboxes afin qu’elles puissent reconnaître la nouveauté. Comme certaines d’entre elles ne laissent passer que certains protocoles, un nouveau protocole risquerait de ne pas pouvoir les franchir bien qu’ils soient supportés par les systèmes d’extrémité. Problème de configurabilité (des services offerts) Avec l’évolution des besoins en QoS des applications, les deux catégories de services offertes par les protocoles TCP et UDP sont devenues insuffisantes. Non seulement certaines applications se trouvent dans l’obligation d’utiliser des services non nécessaires induisant des quantités de données et des délais supplémentaires inutilement, mais aussi, certaines d’entre-elles peuvent voir la qualité de leurs service se dégrader à cause de ces services supplémentaires inutiles. La non configurabilité de ces protocoles qui fait que les applications sont obligés d’utiliser l’ensemble du service proposé dans son intégralité, a eu comme conséquence la complexification de la couche Transport par la création de nouveaux protocoles ne proposant aucun nouveau service, mais seulement des sous-ensembles des services des protocoles existants. 231. Contexte, Problématique, État de l’art et Positionnement Point de problématique Acteurs concernés Complexité Développeur d’applications Assujettissement Développeur d’applications Extensibilité Développeur d’OS, de protocoles et d’applications Déploiement Développeur de protocoles Configurabilité Développeur d’applications Table 1.1: Résumé de la problématique 1.2 État de l’art Dans cette section, nous présentons les solutions de niveau Transport existantes et les confrontons aux points de problématique identifiés précédemment. Certains de ces points ont cependant une portée globale et ne peuvent pas être étudiés ainsi au cas par cas. Le problème de complexité de choix, par exemple provient de la multiplicité des solutions qui seront évoquées dans la suite de cette section, et confronter chacune d’elle à ce problème aurait ainsi peu de sens. La multiplicité des solutions de Transport repose aussi bien sur le nombre de protocoles existants que le nombre de versions de ces protocoles, en particulier TCP, qui a évolué et a été adapté à de très nombreuses reprises. On observe que les protocoles les plus récents s’orientent vers une résolution partielle des problèmes observés, sans jamais totalement les adresser cependant. 1.2.1 Protocoles de Transport Comme la majorité du trafic utilise le protocole IP au niveau réseau, la plupart des protocoles de Transport utilisés sont ceux normalisés par l’IETF. Ces protocoles sont TCP, UDP, DCCP et SCTP, les deux premiers étant les plus utilisés car historiquement les premiers à avoir été créés. Ceux-ci offrent les deux types de services qui étaient utiles au moment de leur création. TCP propose un service garantissant un ordre et une fiabilité totaux sans garantie de délai, afin de permettre les transferts de fichiers, de mails et toutes les utilisations de ce type du réseau. UDP de son côté n’offre absolument aucune garantie et suffisait alors pour toutes les autres utilisations. 1.2.1.1 TCP TCP offre un service totalement fiable et ordonné, en se basant sur un contrôle des pertes et d’erreurs par l’envoi d’acquittements cumulatifs. Tout paquet perdu ou erroné sera ainsi non acquitté, l’émetteur du dit paquet sachant alors qu’il devra retransmettre le paquet erroné et tout paquet subséquent à celui-ci. Ce système 241.2. État de l’art induit nécessairement une augmentation du délai de transit d’un paquet : la perte étant non déterministe, le nombre de retransmissions possibles d’un paquet (et donc des suivants) n’est pas borné. TCP tente également de protéger le réseau grâce à son système de contrôle de congestion, visant à limiter la quantité de paquets à traiter par les routeurs en état de saturation, et donc à limiter les pertes. Ce système implique une diminution du taux d’envoi de paquets par TCP en cas de congestion, ce qui implique de fortes variations dans les délais et les débits. TCP a connu de nombreuses évolutions et adaptations au cours de son histoire. Les principales visent l’amélioration de son contrôle de congestion, que ce soit dans l’absolu ou dans certaines conditions particulières. D’autres concernent les options, comme les Selective Acknowledgement (SACK) [Mat96], permettant d’acquitter des messages correctement reçus malgré certains messages précédents manquants (ce que ne permet pas l’acquittement cumulatif) ou le multipath [For11] (cf. 1.2.1.5). Les différents contrôles de congestion de TCP sont nombreux. Certains sont voués à se remplacer les uns les autres, les suivants étant considérés comme des améliorations des précédents. TCP New Reno [Hen12], par exemple, est considéré aujourd’hui comme l’implémentation de référence du contrôle de congestion de TCP et vise à remplacer les versions précédentes qu’étaient TCP Tahoe et Reno. Si cette version est celle retenue par certains OS, notamment FreeBSD, de nouvelles versions « non canoniques »ont été implémentées dans Windows et Linux. Compound TCP [STBT08] est la version aujourd’hui utilisée sous Windows, bien qu’une version Linux ait été développée à l’université de Caltech mais non maintenue (ce patch est incompatible avec le noyau Linux à partir de la version 2.6.17). Elle est utilisée par défaut depuis Windows Vista et Windows Server 2008 bien que des mises à jour facultatives permettent de l’inclure dans Windows XP et Windows Server 2003. Tout comme TCP Vegas [BP95] ou FAST TCP [WJLH06], Compound se base sur le temps d’attente des paquets comme indication de congestion, et non sur les pertes. Dans sa version 2.6.8, Linux utilise par défaut Binary Increase Congestion control TCP (BIC TCP) [XHR04], puis, à partir de la version 2.6.19, son évolution, CUBIC TCP [HRX08]. CUBIC n’utilise plus les retours d’acquittement comme signal d’augmentation de sa fenêtre d’émission, mais au contraire le temps écoulé depuis le dernier évènement de congestion ce qui permet une croissance de la fenêtre beaucoup plus continue. Ces différentes versions de l’algorithme de contrôle de congestion de TCP visent, tout comme HighSpeed TCP [Flo03], à améliorer les performances du protocole sur les réseaux à forte bande passante et fort délai de transit, ou Long Fat Networks, tels que définis dans [Jac88]. D’autres versions visant à adresser des contextes spécifiques, tel que Data Cen- 251. Contexte, Problématique, État de l’art et Positionnement ter TCP [AGM+10], ont également été développées. Beaucoup de ces versions visent notamment les réseaux sans fil, parfois d’un type particulier. TCP Hybla [CF04] notamment, qui cible originellement les liens comportant des sections satellites, optimise le comportement de la fenêtre de congestion sur les chemins comportant un RTT important, en décorrélant l’impact du RTT sur la taille de la fenêtre de congestion. Malheureusement, ses améliorations étant basées sur le comportement observé de la fenêtre de congestion en milieu satellitaire, elles offrent des performances bien moindres sur des réseaux classiques, les hypothèses sur lesquelles elles sont construites n’étant pas vérifiées. Le cas des réseaux mobiles ajoute en plus les pertes dues au temps de handover, lors d’un passage d’une station de base à une autre. Ceci a pu être adressé par Freeze TCP [GMPG00], qui charge l’appareil mobile de signaler la proximité d’un handover en surveillant la puissance du signal reçu. Problème d’extensibilité. TCP prévoit un système d’options, grâce notamment à un champ d’en-tête dédié de longueur variable, permettant d’adjoindre des comportements supplémentaires. C’est ainsi qu’en plus de l’acquittement cumulatif, TCP peut gérer des acquittements sélectifs [Mat96] ou utiliser plusieurs interfaces de manière concurrentes [For11] (cf. 1.2.1.5). Cependant le caractère monolithique de TCP, c’est-à-dire la non dissociation des différentes fonctions de son service de base comme le contrôle de congestion, de flux, des pertes et d’erreurs, rend difficile l’insertion de services modifiés comme de la fiabilité partielle. Certaines options de ce type avaient cependant été introduites, comme les acquittements négatifs [Fox89] ou la gestion de l’ordre partiel [Con94], mais devant l’impopularité de leur déploiement, celles-ci ont été officiellement abandonnées [Egg11]. Problème de configurabilité. TCP offre un service totalement fiable et totalement ordonné. Sa structure monolithique ne donne pas la possibilité de choisir l’une ou l’autre de ces fonctionnalités, ou de ne les utiliser que de manière partielle. Dans une certaine mesure cependant, TCP est configurable. Certains comportements, comme la concaténation de paquets de petite taille [Nag84] peuvent être désactivés manuellement. Si certains peuvent être modifiés via l’API du protocole, d’autres nécessitent une intervention dans les paramètres du système et ne peuvent donc pas être pris en charge par l’application. Problème d’assujettissement. Les capacités d’autonomie de TCP sont limitées à la variation de certains de ses paramètres, comme sa fenêtre de congestion, en fonction de l’évolution du réseau. La modification d’autres paramètres tels que l’algorithme de calcul du Retransmission Time Out (RTO) doit être prise en charge 261.2. État de l’art par l’application ou l’administrateur du système, ce qui implique une surveillance du réseau et une gestion du protocole de leur part. TCP dépend donc d’une entité extérieure à la couche Transport pour effectuer certains ajustements ayant trait au contrôle de la communication, ou qui pourraient l’optimiser. Problème de déploiement. Par son caractère historique, TCP s’est imposé comme le protocole universel. Son déploiement ne pose donc aucun souci, chaque OS qui implémente la pile protocolaire IP intégrant une version de TCP. Il est également le protocole nécessairement implémenté dans les middleboxes présentes dans le réseau. TCP est aujourd’hui le seul protocole à pouvoir être utilisé partout, même s’il peut parfois être bloqué à cause de l’utilisation de certaines options. 1.2.1.2 UDP UDP n’offre aucune garantie d’ordre ni de fiabilité. De plus, il n’implémente aucun système de contrôle de congestion. Ceci permet de limiter les fluctuations de délai évoquées dans le cas de TCP. UDP est donc mieux adapté aux applications multimédia, mais énormément de pertes peuvent être à déplorer, limitant la qualité du flux. De plus, ne disposant d’aucun contrôle de congestion, il met le réseau en péril en risquant de congestionner les routeurs intermédiaires. Problème d’extensibilité. N’offrant aucune garantie, ajouter des fonctions à UDP est possible selon le plus large spectre qui soit, cependant UDP ne prévoit aucun mécanisme permettant d’étendre celles-ci. Ainsi, toute extension devra être prise en charge par l’application ou par une couche middleware, qui invoquera ellemême UDP. Les messages de niveau middleware seront alors encapsulés dans le datagramme UDP. On ne peut donc pas littéralement parler d’extensions d’UDP. Problème de configurabilité. UDP offre le service le plus simple qui soit : aucune garantie, aucun contrôle de congestion, il se contente de multiplexer l’accès des applications à la couche Transport (via les numéros de port). Les seuls paramètres configurables concernant le fonctionnement global d’UDP sur le système et ne sont pas accessibles par l’application ni ne modifient aucun mécanisme protocolaire. La configurabilité d’UDP est donc nulle. Problème d’assujettissement. UDP offrant un service sans aucune garantie, tout mécanisme supplémentaire, tel qu’un contrôle de congestion, un mécanisme de fiabilité ou d’ordre partiel ou total, doit être pris en charge et implémenté au niveau de l’application. 271. Contexte, Problématique, État de l’art et Positionnement Problème de déploiement. UDP est, comme TCP, présent sur la majorité voire la totalité du réseau. Il fait partie de la suite protocolaire IP et est donc implémenté dans tous les systèmes d’exploitation. Du point de vue des middleboxes, UDP est accepté dans une grande majorité, notamment car il est le protocole de Transport utilisé pour le Domain Name System (DNS). 1.2.1.3 DCCP DCCP [Kho06] vise à pallier les défauts d’UDP en offrant un service non fiable et non ordonné, mais avec contrôle de congestion. Le choix du contrôle de congestion est laissé à l’application. Celle-ci peut décider d’utiliser un contrôle de congestion « à la TCP »[Flo06a], l’algorithme TCP-Friendly Rate Control (TFRC) [Flo08, Flo06b] ou bien encore TFRC for Small Packets (TFRC-SP) [Flo07, Flo09]. DCCP est ainsi plus adapté que TCP pour les applications tolérantes aux pertes et au désordre, et plus adapté qu’UDP pour les transferts sur Internet. Problème d’extensibilité. Bien que DCCP inclue un champ « options » dans son en-tête, celles-ci ne servent pas, contrairement à TCP, à étendre ses fonctionnalités, mais à spécifier un certain nombre d’informations optionnelles selon le type de paquet, et selon le contrôle de congestion choisi. DCCP n’inclue donc pas nativement de mécanisme permettant l’extension de ses fonctionnalités, et du service offert. Problème de configurabilité. DCCP est un protocole qui entre parfaitement dans la catégorie des protocoles configurables. En effet, comme nous l’avons mentionné ci-dessus, DCCP offre la possibilité de pouvoir choisir l’algorithme de contrôle de congestion entre trois possibilités. Ce changement doit cependant être fait à un niveau système et n’est donc pas paramétrable de manière différenciée pour chaque application à ce jour. DCCP est donc un protocole configurable de manière statique, et avec certaines lourdeurs. En effet, un tel changement au niveau système ne peut s’effectuer qu’avec les droits administrateur sur la machine concernée, droits que ne possèdent pas forcément toutes les applications. De plus, dû au caractère global de cette modification, deux applications ayant un choix différent sur la question pourraient entrer en conflit et se gêner l’une l’autre dans la configuration du protocole. Problème d’assujettissement. DCCP présente sur ce point le même défaut qu’UDP. En effet, hormis le contrôle de congestion qui est à présent pris en charge par le protocole, tout mécanisme supplémentaire doit être implémenté et pris en charge par l’application afin d’être disponible. 281.2. État de l’art Problème de déploiement. DCCP est à l’heure actuelle face à un problème de déploiement considérable. Seules trois implémentations ont vu le jour. La première, dans le noyau Linux, ne dispose pas d’une API complète. La deuxième vise un haut degré de portabilité et la troisième concerne la plateforme d’implémentation Google Go. mais aucune de ces deux implémentations ne dispose d’une version stable ni n’a bénéficié d’une mise à jour récente. De ce fait, DCCP n’est utilisé par aucune application grand public, ou à grande échelle. Cette faible utilisation fait écho à son implémentation tout aussi rare dans les différentes middleboxes présentes dans le réseau. Il est à noter qu’une mise à jour de [Kho06] effectuée par [Phe12] offre à DCCP la capacité d’être encapsulé dans un datagramme UDP (nommé alors DCCP-UDP), et non plus directement dans un paquet IP, afin de permettre le passage à travers les différentes middleboxes, et principalement les NATs. Notons cependant que si cette méthode permet de faciliter la transition de DCCP-UDP à DCCP, elle ne modifie rien quant à la transition d’UDP vers DCCP (ou DCCP-UDP). 1.2.1.4 SCTP SCTP [Ste07] a été proposé afin de tirer parti de la multiplicité d’interfaces offertes par les terminaux modernes, et ainsi pallier certains problèmes notamment dus à la mobilité de ces terminaux. SCTP va en effet utiliser toutes les interfaces disponibles pour un même flux applicatif. On ne parle ainsi plus de connexion, mais d’association. Le protocole peut ainsi utiliser plusieurs interfaces au sein d’une même association et utiliser une interface en tant que back up, afin d’assurer la continuité de la communication si la connexion principale venait à être défaillante. Plusieurs extensions ont été ajoutées au protocole comme un système de fiabilité partielle [Ste04], ou sont aujourd’hui à l’étude, comme la possibilité d’utiliser les différents chemins d’une même association de manière concurrente [DBA13]. Problème d’extensibilité. SCTP inclue un système similaire à celui des options de TCP. En effet, un système de champ d’en-tête optionnel permettant la définition d’extensions est présent et a notamment permis l’introduction de la gestion de la fiabilité partielle au sein du protocole [Ste04]. Problème de configurabilité. SCTP possède différentes options configurables à deux niveaux : au niveau du système et au niveau du socket. Comme pour les pré- cédentes solutions, les configurations effectuées au niveau du système ne peuvent pas être réalisées par l’application, et concernent l’ensemble des associations SCTP. Celles-ci concernent notamment le calcul du Retransmission Time Out, ou la reconfiguration dynamique d’adresses. Les options modifiables au niveau du socket concernent les adresses primaires de l’association (celles utilisées comme chemin 291. Contexte, Problématique, État de l’art et Positionnement principal de communication), l’algorithme de Nagel, la fragmentation de paquets, ou la récupération d’informations de monitoring, ainsi que le contrôle de la fiabilité partielle. SCTP possède donc une composante fondamentale configurable, le système de fiabilité partiel. Celui-ci est activable au besoin mais cependant entièrement contrôlé par l’application qui doit elle-même décider du nombre maximum de retransmissions acceptables. De plus, bien qu’encore aujourd’hui à l’étude, on peut supposer qu’une extension d’utilisation concurrente des différents chemins d’une même association, sera également optionnelle et contrôlable par l’application. Problème d’assujettissement. SCTP présente une légère différence par rapport aux précédentes solutions, dû au fait que la fiabilité partielle est optionnelle. De ce fait, le développeur d’application est moins contraint dans l’utilisation qu’il fait du protocole, puisqu’il peut choisir tout ou partie du service présent. Cependant ce choix et sa gestion restent à l’initiative et à la charge de l’application, rendant le processus lourd. Problème de déploiement. S’il est moins important que pour DCCP, SCTP est également confronté à certains problèmes de déploiement. En effet, tous les systèmes d’exploitation ne l’intègrent pas en natif ce qui limite d’autant son utilisation. De plus, le service de base offert par SCTP étant redondant avec celui de TCP, peu de développeurs d’applications décident de se former à l’utilisation de ce nouveau protocole pour mettre à jour leur application, l’utilisation de TCP étant plus sûre. En effet, ce dernier est disponible partout et implémenté dans la totalité des middleboxes du marché, contrairement à SCTP, souvent bloqué. 1.2.1.5 Multipath TCP (MPTCP) MPTCP [For11] est une extension au protocole TCP traditionnel qui consiste à lui adjoindre la capacité à utiliser plusieurs interfaces simultanément, et de manière concurrente. L’initiative de créer ce working group à l’IETF découle des soucis d’adoption que rencontre SCTP depuis sa création. Ainsi, le projet MPTCP consiste à tirer parti des avantages induits par l’utilisation de toutes les interfaces d’une machine, concept dont l’intérêt à été prouvé avec SCTP, tout en acceptant le constat que seul TCP est accepté partout dans le réseau. MPTCP est conçu de manière à être utilisé de manière transparente par les applications et par le réseau, sans modification nécessaire de ces derniers. Cependant, des applications conscientes de la présence de MPTCP peuvent en tirer parti plus conséquemment. Étant une extension de TCP, MPTCP vise à fournir le même service d’ordre et de fiabilité totaux sans garantie de délai, tout en améliorant la résilience, notamment en mobilité (par l’utilisation de plusieurs chemins simultanément), et en améliorant 301.2. État de l’art également le débit, par addition des débits possibles sur chaque interface (l’objectif étant de toujours faire au moins aussi bien que TCP dans sa version classique). Problème d’extensibilité. MPTCP se base sur une décomposition de la couche Transport en sous-couches, idée proposée dans les travaux de Transport Next Generation (Tng) [FI08], en attribuant à une sous-couche supérieure les fonctions relatives à la sémantique applicative, et à une sous-couche inférieure celles relatives à la gestion du réseau, comme décrit sur la figure 1.2. Figure 1.2: Décomposition des fonctions de transport En se basant sur ce concept, MPTCP décompose la couche Transport comme sur la figure 1.3. En offrant ce cadre, MPTCP permet l’étude et l’intégration de fonctions étendues en fonction de leur orientation réseau ou sémantique applicative. Ainsi, peuton imaginer l’intégration de différents algorithmes de contrôle de congestion dédiés aux protocoles multi-chemins tels que proposés dans [DABR12], que l’on pourrait échanger selon les conditions du réseau et les besoins de l’application. De la même manière, la sous-couche sémantique pourrait accueillir des fonctions permettant de modifier le service offert MPTCP, y intégrant de la fiabilité ou de l’ordre partiels par exemple. Cependant, les fondations même de MPTCP reposent sur un ensemble de flux à ordre et fiabilité totaux, contraignant les modifications possibles du service offert. Ainsi, introduire une contrainte de délai impliquerait impérativement un impact sur le débit, ces deux grandeurs étant liées par l’usage de TCP. 311. Contexte, Problématique, État de l’art et Positionnement Figure 1.3: Décomposition de MPTCP en sous-couches Problème de configurabilité. MPTCP étant encore en cours de standardisation et d’implémentation, sa configurabilité n’est pas encore définitivement établie. Cependant, certaines extensions à l’API socket classique ont été préconisées dans [Sch13]. Ces extensions, nommées basic API, servent à des applications qui ont conscience de la présence sous-jacente de MPTCP. Celles-ci permettent d’activer ou de désactiver l’utilisation de MPTCP (et ainsi n’utiliser que TCP en version classique), ou de modifier l’ensemble des adresses, donc des interfaces, à utiliser dans la connexion MPTCP qu’elles emploient. D’autres options permettent de récupérer des informations propres à une connexion MPTCP, comme la liste des adresses utilisées par la connexion. Il est à noter que [Sch13] suggère dix extensions supplémentaires à l’API décrite afin de constituer une API avancée, permettant un contrôle plus poussé de l’application sur le protocole, par exemple en communiquant un profil décrivant les attentes de l’application en termes de performance, ou de caractéristiques concernant la communication (débit d’émission, délai interpaquets, etc.). Cette API avancée n’est à l’heure actuelle ni standardisée, ni à l’étude. Problème d’assujettissement. Tel que les RFCs le décrivent aujourd’hui, l’application ne peut qu’utiliser le service totalement fiable et totalement ordonné fourni par MPTCP. Bien que permettant l’introduction de mécanismes modifiant ce comportement, aucun n’est aujourd’hui en cours de standardisation, le protocole étant encore jeune. La gestion du protocole respecte le paradigme communément admis dévouant cette charge à l’application, et nécessitant donc une connaissance et une expertise de la part du développeur d’applications. 321.2. État de l’art Problème de déploiement. MPTCP présente de nombreuses forces concernant son déploiement et son adoption. Du point de vue du développeur d’applications, son avantage principal est d’être géré avant tout par le système, et ne nécessite donc aucune modification dans le code des applications pour être utilisé. MPTCP est donc d’ores et déjà compatible avec toute application utilisant TCP sans réclamer de mise à jour de celles-ci. Son utilisation la plus basique ne réclame pas de formation spécifique du développeur d’applications non plus, si tant est que celui-ci soit déjà familier avec l’utilisation de TCP. Du point de vue du réseau, MPTCP est vu par ce dernier comme plusieurs flux TCP, indépendants les uns des autres. Ainsi, la majorité des middleboxes laisseront-elles ces flux circuler sans encombre. Les quelques problèmes possibles proviendront essentiellement des middleboxes bloquant les options TCP inconnues (MPTCP se manifestant par une nouvelle valeur d’option dans l’en-tête des segments TCP), ainsi que celles modifiant les numéros de séquence, MPTCP mettant en place une correspondance entre les numéros de séquence de chaque flux, et un numéro de séquence applicatif. 1.2.1.6 CTP Introduit dans [BWH+07], Configurable Transport Protocol (CTP) est un protocole visant des capacités élevées en termes de configurabilité. CTP se base sur le principe de la composition de micro-protocoles introduits dans [Exp03]. Les microprotocoles représentent chacun une fonction de Transport de base, atomique. Leur composition permet ainsi la création d’un service de Transport à la carte en fonction des besoins de l’application. CTP fonctionne sur un principe évènementiel : chaque message arrivant dans le protocole déclenche une série d’évènements en fonction des informations contenues dans son en-tête. Chaque évènement informe un micro-protocole qu’il doit prendre le message en charge. Ceci permet de paralléliser les traitements lorsqu’ils sont indépendants les uns des autres. Problème d’extensibilité. Afin de permettre le déploiement de la composition adéquate de part et d’autre de la communication, CTP utilise un champ de 32bits, associant chacun à un micro-protocole particulier. Ainsi, bien que les auteurs appellent à la création de nouveaux micro-protocoles dans [BWH+07], CTP est limité à une collection ne dépassant pas les 32 micro-protocoles. Ce nombre, s’il est suffisant pour des services de Transport « classiques » risque de se révéler faible dès que l’on considère la possibilité d’utiliser plusieurs implémentations d’un même micro-protocole en fonction des situations, ou que l’on décide d’ajouter des micro-protocoles implémentant des fonctions plus exotiques, relatives à la Qualité de Service ou à la sécurité par exemple. 331. Contexte, Problématique, État de l’art et Positionnement Problème de configurabilité. CTP a été créé dans le but d’offrir une confi- gurabilité maximale. En effet, l’application peut choisir la composition de microprotocole qu’elle désire, et ainsi la dessiner selon ses besoins, sans devoir utiliser des services qui lui seraient inutiles, ou se résigner à implémenter elle-même ceux qui manquent, comme dans le cas des solutions monolithiques classiques. De plus, même si elle est limitée, l’extensibilité de CTP offre la possibilité d’ajouter des fonctions supplémentaires nécessaires à la satisfaction des besoins de l’application. CTP n’est cependant pas reconfigurable en cours de communication, forçant l’application à conserver le même service composite tout au long de celle-ci. Problème d’assujettissement. Le manque de configurabilité dynamique contraint donc l’application dans le service qu’elle décide à l’ouverture de connexion. Ce n’est cependant pas le seul point sur lequel l’application se retrouve assujettie à CTP. En effet, la gestion complète du protocole repose sur elle. C’est ainsi à elle de décider de la meilleure composition de micro-protocoles à utiliser. Il est d’ailleurs précisé que cette composition devra être établie par l’expérience, aucun système de décision n’étant présent pour épauler l’application dans son choix. Problème de déploiement. Cette dernière contrainte est un véritable frein à l’adoption de CTP. Plus encore que pour les solutions précédentes, le développeur d’applications doit apprendre en profondeur le fonctionnement du protocole pour être capable de l’utiliser. De plus, son fonctionnement différant fortement de celui des protocoles classiques, toute application souhaitant l’utiliser devra être mise à jour. Finalement, toutes les middleboxes devront également être capable de le prendre en charge, CTP n’étant pas conçu pour être transparent du point de vue du réseau. 1.2.1.7 ETP Développé au LAAS-CNRS, Enhanced Transport Protocol (ETP) est un framework pour la composition de protocoles de Transport composites. Tout comme CTP, il repose sur la composition de micro-protocoles créant ainsi des protocoles composites répondant aux besoins de l’application. ETP adopte une structure différente de celle de CTP, préférant une approche hybride entre organisation hié- rarchique, comme le modèle OSI, et le modèle évènementiel, sur lequel repose CTP. Cette organisation schématisé sur la figure 1.4 est articulée autour de cinq conteneurs : – Application Out (AppOut) ; – Application In (AppIn) ; – Protocol Out (ProtOut) ; – Protocol In (ProtIn) ; 341.2. État de l’art – Management. Chaque conteneur se destine à recevoir les différentes fonctions nécessaires au fonctionnement des différents micro-protocoles qui vont constituer le protocole. Ainsi, le conteneur de management va-t-il accueillir les fonctions de contrôle dudit micro-protocole. Ce conteneur adopte une approche évènementielle. Les fonctions qui y prennent place vont s’activer sur notifications d’évènements produites par les fonctions qui prendront place dans les autres conteneurs. Ces quatre autres conteneurs peuvent se diviser selon deux axes. Un axe vertical sépare d’un côté les conteneurs AppOut et ProtOut, et les conteneurs AppIn et ProtIn de l’autre, formant un plan de données en sortie d’une part, qui traitera les messages émis par l’application, et un plan de données en entrée, qui traitera les messages reçus à destination de l’application. Ils se divisent également selon un axe horizontal, regroupant les conteneurs AppOut et AppIn d’une part, et ProtOut et ProtIn d’autre part. Les premiers exécutent leurs fonctions au rythme des demandes d’émission et de réception de l’application. Les seconds exécutent les fonctions qu’ils hébergent au rythme auquel le réseau les accepte ou les transmet. Ces rythmes pouvant être très différents, des buffers font office de tampon entre les deux plans horizontaux (App et Prot) pour absorber cette différence. Ces quatre conteneurs s’organisent de manière hiérarchique. Les différentes fonctions qui y sont hébergées sont empilées selon un certain ordre, et s’exécuteront sur les différents messages dans cet ordre. Figure 1.4: Organisation schématique d’ETP 351. Contexte, Problématique, État de l’art et Positionnement Problème d’extensibilité. ETP prévoit la possibilité d’accueillir de nouveaux micro-protocoles. Ceux-ci sont désignés par un identifiant unique, rendant les possibilités d’extensions quasiment illimitées. Le système de synchronisation, contrairement à celui de CTP, n’est pas limité en place ce qui permet également cette extensibilité illimitée. Chaque micro-protocole pouvant adjoindre son ou ses champs d’en-tête personnalisés, cependant, le risque créé est celui d’un overhead important lors de l’utilisation de nombreux micro-protocoles dans le même protocole composite, risquant de provoquer de la fragmentation au niveau IP. Problème de configurabilité. ETP est configurable à l’initialisation et reconfigurable dynamiquement en cours de communication. Le déploiement de la nouvelle composition du protocole s’effectue en parallèle de l’ancienne, permettant ainsi le traitement d’éventuelles retransmissions ou de paquets encore en vol. Cette méthode s’accompagne cependant d’un coût en termes de ressources utilisées la rendant peu viable sur les terminaux limités, tels que des capteurs. La reconfiguration dynamique requiert de plus une signalisation propre induisant un certain overhead sur le réseau. Problème d’assujettissement. Les configurations d’ETP sont décidées par l’application, imposant au développeur d’applications de connaître les micro-protocoles qui s’offrent à lui mais également de décider de leur organisation hiérarchique au sein des conteneurs du plan de données. C’est également à l’application de commander les différentes reconfigurations en cours de communication, lui laissant la tâche de surveiller, en plus de ses propres besoins, si l’état du réseau réclame de modifier le service fournit par le protocole. Problème de déploiement. ETP repose techniquement au dessus d’UDP et est ainsi vu par le réseau comme la charge utile du protocole de Transport. ETP peut donc être accepté par le réseau où UDP l’est, c’est-à-dire quasiment partout. ETP doit cependant être utilisé par les développeurs qui sont contraints, pour ce faire, d’apprendre son utilisation. Proche de celle d’UDP, elle doit cependant être complétée en fournissant au protocole la composition de micro-protocoles à utiliser. C’est également au développeur d’applications de décider des changements de composition. Tout ceci fait peser un besoin en connaissance et une responsabilité supplémentaire sur le développeur d’application rendant improbable le déploiement d’ETP en pratique. 361.2. État de l’art 1.2.2 En résumé Les différents tableaux suivants résument les différents points exposés sur les différents protocoles. Protocole Extensibilité TCP Par options UDP Aucune DCCP Aucune SCTP Par options MPTCP Structure en couche pouvant accueillir des extensions CTP Limitée ETP Forte Table 1.2: Résumé du problème d’extensibilité Protocole Configurabilité TCP Limitée UDP Nulle DCCP Contrôle de congestion SCTP Limitée MPTCP Basique standardisée, étendue prévue CTP Totale ETP Totale Table 1.3: Résumé du problème de configurabilité Protocole Assujetissement TCP Service monolithique UDP Service monolithique DCCP Choix du CC à la charge de l’application SCTP Choix à la charge de l’application MPTCP Choix à la charge de l’application CTP Choix à la charge de l’application ETP Choix à la charge de l’application Table 1.4: Résumé du problème d’assujettissement L’abondance de ces différents paramètres nous place face au problème de la complexité des choix qu’ont à faire les développeurs d’applications. En effet, un 371. Contexte, Problématique, État de l’art et Positionnement Protocole Déploiement TCP Disponible partout UDP Disponible partout DCCP Faible SCTP Faible MPTCP A venir CTP Aucun ETP Aucun Table 1.5: Résumé du problème de déploiement protocole donné, même s’il est faiblement déployé, peut donner de meilleures performances dans un réseau fermé, non relié à Internet, qu’un protocole plus vastement déployé. Cependant, ceci peut mener à des complications si l’application devait finalement être portée sur un contexte de réseau plus ouvert, relié à Internet. Le choix que doit faire le développeur d’application, pour être éclairé, doit être basé sur une connaissance poussée des différents protocoles disponibles. Or la complexité de certains, standardisés parfois par une grande quantité de documents, rend cette tâche ardue, consommatrice de temps et réclamant un effort sur une expertise qui ne devrait pas relever du développement logiciel. Pour cette raison, et grâce à son omniprésence, TCP est souvent le choix fait par défaut, notamment car de plus en plus d’applications utilisent HTTP pour leur transferts, et que celuici repose sur TCP. Cependant, le service de TCP est faiblement configurable, et c’est alors à l’application de prendre en charge les modifications qu’elle souhaite voir appliquées. 1.3 Positionnement de la proposition Face aux limites des protocoles de Transport, la thèse soutenue dans ce mé- moire est celle d’une architecture innovante pour la couche Transport, nommée ATL, qui permet de répondre aux différents points de la problématique discutés précédemment. Cette section en présente l’approche, les exigences générales et les principes de conception retenus en conséquence. Les chapitres 2 et 3 sont dédiés à l’explicitation et aux détails de mise en œuvre de ces trois volets. 1.3.1 Approche L’objectif n’est pas de définir un nouveau protocole, mais de tirer partie de l’ensemble des solutions protocolaires (protocoles et mécanismes) existantes ou 381.3. Positionnement de la proposition à venir, par le biais d’un environnement d’intégration et de composition au sein d’une véritable couche Transport, dans le but de répondre au mieux aux besoins des applications en tenant compte des capacités du réseau et des systèmes terminaux. La proposition présentée dans ce document traite également des considérations de déploiement de l’ATL qui doit tenir compte, d’une part, du degré de conscience de l’ATL de la part des applications, et d’autre part, de la disponibilité de l’ATL dans les différents systèmes s’interconnectant. En d’autres termes, la mise en œuvre de l’ATL sur un hôte terminal ne doit pas conduire au besoin de réécrire les applications traditionnelles dites « legacy », développées en amont de l’ATL ; de même, le déploiement de l’ATL sur un hôte terminal doit permettre à ce dernier d’interagir avec un hôte sur lequel l’ATL n’est pas déployé, que ce soit en tant qu’initiateur (client) de la communication, ou en tant que serveur. 1.3.2 Exigences générales de conception de l’ATL Cette nouvelle architecture pour la couche Transport doit permettre de faciliter l’accès aux protocoles de Transport en abstrayant le développeur d’applications de la complexité relative au choix de protocole et à son utilisation. Cette couche vise également à permettre un accès à l’ensemble des services disponibles, ceci de façon hautement configurable et personnalisé en fonction du contexte applicatif, machine et réseau, brisant ainsi la dépendance classique entre applications et protocoles de Transport dans le but d’offrir davantage de souplesse au développement et à la maintenance des applications. L’un des objectifs de conception de l’ATL est qu’il dispose de capacités d’autonomie qui lui permettent de tenir compte en temps réel, dans ses choix de composition, des évolutions des besoins applicatifs et de l’état du réseau. Par ailleurs, l’architecture de l’ATL doit faciliter le développement, la mise à jour et l’intégration des nouvelles solutions protocolaires en exonérant les développeurs d’applications, de protocoles et de systèmes des conséquences liées à toute sorte de modification dans les protocoles de Transport. Enfin, l’ATL doit prendre en compte d’autres considérations relatives au dé- ploiement de ces nouvelles solutions. 1.3.3 Paradigmes de conception relatifs à l’architecture de l’ATL Pour répondre aux exigences de conception de l’ATL, quatre paradigmes de base ont été retenus, dont l’application sera décrite dans les chapitres 2 et 3 : – le paradigme associé aux architectures dites basées-composant ; – le paradigme associé aux architectures dites orientées-services ; 391. Contexte, Problématique, État de l’art et Positionnement – le paradigme de l’Autonomic Computing (AC) ; – la dimension sémantique. 1.3.3.1 Conception logicielle basée composants La notion de « basé composants »est un paradigme de conception logicielle qui vise à faciliter le développement des systèmes complexes en séparant ces derniers en un ensemble de composant élémentaires. La facilité vient du fait que la division du système le rend moins complexe et permet en plus de déléguer chaque composant à un groupe de développeurs appropriés. Par ailleurs, les composants étant développés séparément, ils peuvent être utilisés par plusieurs autres composants par le biais d’interfaces clairement définies. Cette capacité de réutilisation permet d’économiser du temps et de l’espace. Généralement, le recours au basé composant est à des fins d’optimisation. Cependant, dans le cas d’architectures extensibles, comme le cas des drivers systèmes par exemple, l’approche de conception logicielle basée composant est la seule solution pour assurer cette extensibilité. 1.3.3.2 Conception logicielle orientée service L’« orienté services »est un autre paradigme de conception logicielle qui permet une séparation nette entre le service offert et la façon avec laquelle il est offert (son implémentation). Cette séparation offre, d’une part, une abstraction complète en réduisant les interactions à l’interface du service. D’autre part, elle permet plus de souplesse à l’architecture quant à sa maintenance et son extensibilité. La gestion des services dans de telles architectures est, par exemple, effectuée en se basant sur des descriptions sémantiques des services et de leurs interfaces. 1.3.3.3 Autonomic Computing Le concept d’AC a été proposé par IBM pour faire face à la complexité croissante dans la gestion jusque-là manuelle des différentes facettes relevant des technologies de l’information, et en particulier des systèmes logiciels. Le principe est d’intégrer des capacités d’auto-gestion dans ces systèmes induisant une intervention minimale des utilisateurs. IBM a également proposé une architecture fonctionnelle basée sur un ensemble de composants et d’interfaces bien définies ainsi que d’un cahier des charges précis du comportement individuel et collectif attendu de la part des différents composants du système. Cette architecture, dont les points d’entrée et de sortie sont équivalents à des capteurs (sensors) et à des actionneurs (actuators) distingue quatre fonctions majeures : le monitorage du système auto-géré, l’analyse des données capturées et l’identification de symptômes, la planification des actions à entreprendre pour répondre à ces symptômes, et finalement la mise en œuvre de ces actions. Dans les grandes lignes, les actions entreprises 401.4. Conclusion peuvent relever de la configuration du système, de l’optimisation de ce système, de sa réparation ou encore de sa sécurisation. 1.4 Conclusion L’objectif général de ce chapitre était de présenter la problématique adressée dans notre travail de thèse et de positionner la proposition soutenue dans l’état de l’art des protocoles de Transport sous-jacents au transfert des applications distribuées dans l’Internet. Pour cela, nous avons tout d’abord présentés les évolutions de ces 20 dernières années du contexte de notre travail, constitué des réseaux supports de l’Internet, des applications distribuées et de leurs besoins, et enfin des terminaux sur lesquelles s’exécutent ces applications. Nous avons ensuite analysé les limites des protocoles de Transport face à ces évolutions, en identifiant cinq points durs de problématique : – problème de complexité de choix ; – problème d’extensibilité ; – problème de configurabilité ; – problème d’assujetissement ; – problème de déploiement ; auxquels nous avons confronté les différentes solutions de l’état de l’art selon trois points de vue : le développeur d’application, le développeur de système d’exploitation et le développeur de protocoles. Si certains de ces protocoles répondent à différents degrés à une partie de ces points, aucune ne les satisfait tous. Notamment, la complexité de choix et l’assujettissement ne sont adressés par aucune. La démonstration de ces limites nous a conduits à positionner notre proposition, l’ATL. L’ATL n’est pas une nouvelle proposition de protocole, mais une proposition d’architecture pour la couche Transport, orientée service et basée composants, créant une véritable abstraction du service sous-jacent. Les enjeux de l’ATL sont multiples et visent en particulier à soustraire le choix et la gestion du protocole de Transport utilisé au développeur d’applications, lui permettant ainsi de concentrer sa demande sur le service requis et non plus la solution protocolaire à mettre en place pour assurer ce service. L’ATL permet ainsi l’intégration transparente de nouveaux protocoles et mécanismes protocolaires sans intervention au niveau de l’application. Dans la suite de ce document, le chapitre 2 se focalise sur la définition des différents composants de l’ATL, à différents niveaux de description, leurs rôles, leur organisation et les échanges qu’ils effectuent entre eux. Le chapitre 3 se concentre ensuite sur la description comportementale de ces composants dans deux cas d’uti- 411. Contexte, Problématique, État de l’art et Positionnement lisation centraux : l’ouverture d’un point d’accès au service de Transport par une application, et la reconfiguration dynamique d’un service de Transport. 42CHAPITRE 2 Architecture de l’ATL Ce chapitre présente le modèle architectural (ou structurel) de l’ATL suivant le plan ci-dessous. Dans la première partie (section 2.1), nous détaillons les exigences de conception de l’ATL introduites au chapitre 1. Nous présentons ensuite les principes permettant d’y répondre et enfin les approches logicielles envisagées pour implanter ces principes. De l’exposé de ces approches, nous dégageons enfin les fonctionnalités attendues de l’ATL. La seconde partie du chapitre (section 2.2) présente le modèle architectural de l’ATL suivant le formalisme UML 2.0. Les cas d’utilisation de l’ATL sont tout d’abord introduits. Le modèle général de l’ATL est ensuite présenté. Vient enfin la présentation des différents composants de l’ATL distingués en composants de premier niveau et composants secondaires. La dernière partie (section 2.3) conclut le chapitre et introduit le chapitre 3, dédié à la description comportementale de l’ATL au travers de deux cas d’utilisation. Sommaire 2.1 Exigences de conception et principes l’ATL . . . . . . . . . . . 44 2.1.1 Exigences de conception de l’ATL . . . . . . . . . . . . 44 2.1.2 Principes des solutions proposées en réponse aux exigences de conception de l’ATL . . . . . . . . . . . . . . 46 2.1.3 Approches d’implantation de ces principes . . . . . . . 48 2.1.4 Fonctionnalités de l’ATL . . . . . . . . . . . . . . . . . 53 2.2 Architecture de l’ATL . . . . . . . . . . . . . . . . . . . . . . . 54 2.2.1 Cas d’utilisation . . . . . . . . . . . . . . . . . . . . . . 54 2.2.2 Modèle d’architecture de l’ATL . . . . . . . . . . . . . 57 432. Architecture de l’ATL 2.2.3 Composants de base de l’ATL . . . . . . . . . . . . . . 60 2.2.4 Composants secondaires . . . . . . . . . . . . . . . . . 69 2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 2.1 Exigences de conception et principes l’ATL Cette section présente les exigences de conception et les principes de l’ATL. Notons que cette section ne présente pas l’architecture de l’ATL, cette partie faisant l’objet de la section 2.2. 2.1.1 Exigences de conception de l’ATL Pour aborder les cinq points de la problématique énoncée au chapitre 1, l’ATL doit répondre à un certains nombre d’exigences que nous introduisons ci-après. Face à la complexité liée à la connaissance, au choix et à l’utilisation des solutions protocolaires, l’ATL doit permettre aux développeurs d’applications : – de se voir masquer la connaissance et la complexité du choix des solutions protocolaires à invoquer ; autrement dit, partant d’une spécification par le développeur d’application des caractéristiques du service souhaité, c’est à l’ATL que revient le choix de la solution protocolaire sous-jacente la plus adaptée ; notons que cette abstraction ne doit pas fermer la possibilité pour un développeur averti, d’effectuer par lui-même le choix de la solution protocolaire à mettre à œuvre ; – de se voir masquer la complexité d’utilisation des solutions protocolaires qui seront invoquées ; autrement dit, le développeur d’application doit disposer d’une Application Programming Interface (API) générique, lui permettant de caractériser le service souhaité, et non le protocole ; l’ATL doit cependant permettre la prise en compte des application existantes — applications dites legacy — traditionnellement basées sur TCP et UDP et sur les API correspondantes — il ne s’agit donc pas de réécrire ces applications — une API supplémentaire, permettant d’exprimer la solution protocolaire souhaitée, doit enfin être mise à disposition des développeurs avertis. Face au problème de dépendance des applications aux solutions protocolaires, l’ATL doit permettre une adaptation de la solution protocolaire retenue en réponse à une évolution du contexte machine/réseau, ou bien à une modification de l’expression du service requis par l’application. Cette adaptation consiste 442.1. Exigences de conception et principes l’ATL soit en la modification de certains des paramètres de la solution, soit en la modi- fication de la structure même de la solution, par exemple par remplacement d’un mécanisme protocolaire par un autre, plus adapté au nouveau contexte. – En réponse à une évolution du contexte machine/réseau, l’ATL doit donc être doté d’une capacité d’autonomie dans la prise de connaissance du contexte et de ces évolutions, en plus de celle liée au choix et à la mise en œuvre des solutions protocolaires à invoquer. – En réponse à une évolution des besoins applicatifs, la même capacité d’autonomie est requise de la part de l’ATL dans le choix et la mise en œuvre des adaptations de la solution protocolaire en cours. Vis à vis de la prise de connaissance de l’évolution des besoins applicatifs, l’ATL doit au moins offrir — via l’API générique — la possibilité aux développeurs d’applications de modifier les caractéristiques du service requis durant le temps d’exécution de l’application. Cette possibilité est donc offerte à des applications évoluées, conçues de sorte à pouvoir adapter leurs besoins aux variations du contexte considéré. Notons qu’idéalement, l’ATL pourrait être doté d’une capacité d’autonomie dans la prise de connaissance du contexte applicatif, et inférer par lui-même l’évolution des besoins applicatifs ; cette dernière possibilité n’a pas été considérée dans nos travaux et en constitue l’une des perspectives. Face au problème d’extensibilité des solutions protocolaires, lorsqu’apparaît une nouvelle version d’un protocole existant ou bien qu’émerge une nouvelle solution protocolaire — qu’il s’agisse d’un protocole ou d’un mécanisme, l’ATL doit permettre son intégration au sein de l’ensemble des services et solutions protocolaires qu’il gère déjà, en vue de la mise à disposition du service correspondant et de l’utilisation de la solution protocolaire. Face au problème de manque de configurabilité du service requis, c’est à dire la difficulté pour un développeur d’application de pouvoir requérir un service particulier plutôt que tous ceux imposés par les protocoles basés sur un principe de conception « monolithique » tels que TCP, l’ATL doit résoudre le problème grâce à la nature « composable » des différents protocoles et mécanismes protocolaires qu’il gère (chaque protocole pouvant se voir adjoindre des mécanismes externes), mais également par une connaissance complète de l’étendue de la configurabilité de chaque protocole et mécanisme protocolaire qu’elle peut instancier. Ceci permet un plus grand contrôle et une plus grande latitude dans les décisions concernant les services que l’ATL peut mettre en œuvre pour satisfaire les besoins des applications. Grâce à ces principes, l’ATL peut virtuellement configurer n’importe quel service à volonté, via les paramètres variables des composants 452. Architecture de l’ATL qu’elle instancie, ou par l’adjonction de mécanismes externes venant palier un manque. Face au problème d’acceptabilité des nouvelles solutions protocolaires, on observe les deux points suivants. – Le principal souci lié aux solutions nouvelles tient à leur capacité à être utilisées par les applications et à être acceptées par le réseau. En libérant l’application du choix de la solution protocolaire, l’ATL adresse ainsi le premier problème. Il doit par ailleurs être doté d’une capacité à choisir les solutions à instancier en fonction de l’environnement réseau — qui peut par exemple bloquer les flux non TCP via des middleboxe configurées à cet effet — pour répondre au problème d’acceptabilité par le réseau. – Le déploiement de L’ATL pose également un problème en lui-même dans la mesure où l’on ne doit pas imposer son déploiement sur toutes les machines, ni son utilisation par une application initialement conçues sur les bases de la couche Transport classique. La conception de l’ATL doit donc répondre à cette double exigence. 2.1.2 Principes des solutions proposées en réponse aux exigences de conception de l’ATL Afin de répondre aux différentes exigences précédentes, l’ATL a été conçu suivant certains principes que nous présentons ici. La mise en œuvre de ces principes est elle-même basée sur un ensemble de paradigmes de conception décrits dans la section 2.1.3. Premier principe : l’abstraction. Le principe d’abstraction est le principe clé de la solution que propose l’ATL. En effet, tout réside dans l’idée de séparer les détails d’implémentation et de gestion des solutions protocolaires, des applications qui vont en utiliser les services. Suivant ce principe, on limite les interactions entre les applications et la couche Transport à un ensemble d’interfaces génériques, ce qui a comme conséquence : – de libérer les développeurs d’applications du choix et de la difficulté d’utilisation des solutions protocolaires sous-jacentes, et répond donc au problème de la complexité protocolaire ; – de passer, du point de vue de l’application, d’un paradigme d’utilisation de protocoles à un paradigme d’utilisation de services, levant ainsi la dé- pendance des applications aux solutions protocolaires en leur permettant de pouvoir s’exécuter « au-dessus » de n’importe quel protocole offrant le service souhaité ; 462.1. Exigences de conception et principes l’ATL – d’effectuer des modifications sur les protocoles et les mécanismes protocolaires sans conséquence sur les applications, répondant ainsi — en tout ou partie — à l’objectif d’acceptabilité par les applications. Second principe : l’extensibilité. Le principe d’extensibilité réside dans la capacité de l’ATL à intégrer de nouvelles solutions protocolaires, ou à mettre à jour les solutions existantes sans aucune implication supplémentaire sur les applications ou les systèmes. Le principe d’abstraction de l’ATL répond aux besoins des applications, en ceci qu’il n’y aura aucune implication sur ces dernières si une modification se porte sur une solution. Concernant le besoin des développeurs de systèmes d’exploitation, l’architecture de l’ATL doit être telle que l’intégration de nouveaux composants impose uniquement des mises à jour de la base de connaissance de l’ATL, sans mise à jour des composants de gestion de l’ATL. Enfin, ces modifications, notamment celles conduisant à offrir de nouveaux services de Transport, doivent être communiquées de façon publique aux développeurs d’applications. Les mises à jour doivent ainsi être des opérations simples qui seront assurées par une entité de l’ATL que le développeur du protocole aura à invoquer pour que sa solution protocolaire soit prise en compte, en lui transmettant un certain nombre d’informations décrivant sa nouvelle solution. Troisième principe : la configurabilité. La configurabilité est un principe d’optimisation qui permet d’offrir à l’application l’ensemble de services dont elle a besoin et uniquement ceux-ci — c’est à dire sans service supplémentaire. Ce principe va à l’encontre du caractère monolithique de la plupart des protocoles de Transport existants qui impose aux applications tous les services pré-implantés. Cette configurabilité peut être assurée par l’ATL ou par le composant protocolaire lui-même. Dans le premier cas, l’ATL doit sélectionner et composer un ensemble optimal de composants qui offriront le service demandé par l’application. Dans le deuxième cas, l’ATL doit offrir, pour les composants qui sont à la base configurables — tels que ETP — un environnement dans lequel ils pourront conserver leur caractère configurable. Quatrième principe : l’autonomie. A l’instar de la configurabilité, l’autonomie est un principe d’optimisation qui permet à l’ATL de prendre des décisions en fonction des changements du contexte applicatif et réseau. La prise de décision est relative au choix de la composition « optimale » de protocoles/composants protocolaires en réponse à une requête de l’application, que ce soit au moment de 472. Architecture de l’ATL l’établissement de la connexion, ou durant la communication en cas de changement de contexte. Un changement de contexte se produit lorsque les besoins de l’application changent, par exemple lorsque celle-ci passe d’un type de fonctionnalité à un autre ou d’un type de donnée à un autre. Les changements de contexte peuvent aussi être liés au réseau : il peut s’agir d’une diminution ou d’une augmentation des paramètres réseau, tel que le débit, le délai, le taux de perte, ou encore l’apparition ou la disparition d’un problème de congestion ou le changement du type de réseau (Ethernet vers 3G par exemple). Dans toutes ces situations, aussi bien avant ou durant la communication, le principe d’autonomie est de permettre une adaptation de la solution protocolaire transparente pour l’application. 2.1.3 Approches d’implantation de ces principes La mise en œuvre des principes précédents repose sur un certain nombre de paradigmes de conception qui sont présentés dans cette section. 2.1.3.1 Approche orientée services L’approche orientée services vise principalement à séparer les services offerts de leur implémentation interne en réduisant les interactions entre l’application et ces derniers à une simple interface. Cette façon de faire offre une abstraction complète des solutions techniques utilisées, et constitue ainsi l’approche la plus importante de notre solution. L’objectif est de définir chaque protocole ou composant protocolaire par l’ensemble des services qu’il offre. Du point de vue de l’application, il n’y aura plus de notion de protocole de Transport, mais seulement de service de Transport, au sens où elle n’invoque plus un protocole particulier, tel que TCP ou UDP, mais un service particulier, par exemple un service orienté-connexion en mode flux d’octets avec garantie d’ordre et de fiabilité totale. Le choix du protocole et du ou des composants protocolaires qui assureront le service requis ne sera plus à la charge de l’application. Le principe de mise en œuvre repose sur la capacité de l’ATL à maintenir une liste des correspondances entre protocole ou composant protocolaire et service(s) correspondant(s) et, quand il reçoit une requête d’une application contenant une liste de services souhaités, à chercher dans la liste des correspondances la composition protocolaire la plus adaptée pour assurer l’ensemble des services. De cette façon, l’approche orientée services assure parfaitement le principe d’abstraction de l’ATL, et permet de répondre à plusieurs parties de la problématique : 482.1. Exigences de conception et principes l’ATL – en réduisant l’interface avec les applications à une liste de services accessibles, on élimine le problème de complexité relatif : – au choix du protocole de Transport, car celui-ci n’est plus de l’ordre des applications mais de l’ATL, – à l’usage de celui-ci car il n’y aura plus besoin de connaitre les détails relatifs au fonctionnement de chaque protocole ou mécanisme protocolaire comme cela se fait actuellement, l’application ayant simplement à connaitre l’ensemble des services offerts et à solliciter ceux qui lui conviennent ; – la séparation des détails techniques permet, par le biais des services, de lever la dépendance classique entre applications et protocoles et ce, sur deux plans : – tout d’abord, les applications ne seront plus écrites pour un protocole particulier mais pour un ensemble de services et peuvent donc être exécutées « au-dessus » de n’importe quelle solution protocolaire offrant les mêmes services, – ensuite, les modifications apportées aux composants protocolaires n’affecteront pas le fonctionnement des applications, puisque ces modifications ne leur seront pas visibles. La réponse au problème de dépendance permet ainsi de répondre à une partie du problème de l’extensibilité concernant les applications. Ceci signifie qu’il sera possible, avec une approche orientée services, d’ajouter ou de mettre à jour n’importe quelle solution protocolaire au sein de l’ATL sans aucune conséquence sur les applications. Pour les autres parties du problème d’extensibilité (i.e. concernant les développeurs de systèmes ou de protocoles), la solution nécessitera l’adoption d’approches complémentaires, tel que préconisé par la suite ; – Enfin, pour les protocoles qui sont à la base configurables (tels que ETP), l’approche orientée service permet de conserver leur configurabilité avec la possibilité de paramétrage des services. Chaque service peut disposer d’une liste de paramètres que l’on peut ou doit lui fournir à son invocation. Ceci concerne la configurabilité des services eux-mêmes, et pour ce qui est de la configurabilité de l’ensemble des services, c’est à dire le fait de choisir un sous ensemble des services offerts, ceci va de soit, puisque dans ce paradigme, il n’y a aucune différence entre les services offerts séparément par des composants indépendants et les services offerts séparément par un même composant. Conséquences en termes de besoins fonctionnels d’une approche orientée services. L’adoption d’une approche orientée services impose la mise en œuvre, au sein de la couche Transport, de fonctions supplémentaires relatives à la gestion des services. Ces fonctions concernent notamment : – l’intégration des nouveaux services incluant leur prise en compte par les 492. Architecture de l’ATL composants de gestion de l’ATL ; – l’association entre services et composants afin de facilement trouver quels sont les services fournis par chaque composant ; – la vérification de leurs disponibilité sur les hôtes locaux et distants. Ces différentes fonctions sont regroupées dans la fonctionnalité de gestion des services et seront déléguées à différents composants de l’architecture de l’ATL. Elles sont décrites plus en détails en section 2.1.4.1 de ce chapitre. 2.1.3.2 Approche basée composants L’approche basée composants concerne l’organisation interne des solutions protocolaires qui seront gérées par l’ATL. Le principe est de mettre chaque protocole ou composant protocolaire dans un composant logiciel indépendant offrant un ensemble de services via une interface propre. En séparant chaque protocole ou composant protocolaire en un composant logiciel indépendant, on facilite son intégration dans l’ATL. L’ajout à la bibliothèque de composants et la mise à jour de la base de connaissances de cette dernière constituent ainsi les seules étapes de l’installation d’un nouveau composant : – aucune partie du système d’exploitation ni de l’architecture de l’ATL ne sera à modifier ; cette souplesse assure une extensibilité complète de la couche Transport, et répond ainsi aux limitations d’extensibilité de la couche actuelle du point de vue des développeurs de système et de protocole ; – en conséquence, le développeur de protocole n’aura plus à se préoccuper de la prise en charge de son protocole par le système ; – en parallèle, en associant chaque composant à un ensemble de services, les mises à jour seront transparentes pour les applications ; de cette façon, nous répondons à l’ensemble des problèmes relatifs à l’extensibilité. Par ailleurs, la séparation des composants protocolaires permet d’offrir la possibilité de choisir et de composer au besoin les composants qui assureront un service donné, au sens où les applications ne seront plus obligées de fonctionner avec des services insuffisamment adéquats, comme c’est le cas avec l’architecture actuelle de la plupart des protocoles de Transport à caractère monolithique. Le principe de configurabilité est ainsi assuré. Enfin, cette approche permet la création de solutions protocolaires à granularité variable. La possibilité d’exprimer la dépendance d’un composant envers un autre ou envers un service assuré par un autre est capitale. Ainsi, un développeur souhaitant créer un mécanisme de contrôle des pertes et nécessitant un estampillage des paquets par un numéro de séquence pourra soit développer son propre estampillage, soit déclarer son composant protocolaire dépendant de l’utilisation d’un composant d’estampillage adéquat. 502.1. Exigences de conception et principes l’ATL Conséquences en termes de besoins fonctionnels d’une approche basée composants Les conséquences de l’approche basée composant concernent principalement leurs intégrations au sein de l’ATL. Les interfaces de ces composants doivent être définies de façon suffisamment générique pour qu’ils puissent être intégrés de façon transparente dans l’ATL, c’est-à-dire sans avoir à récrire le code de l’ATL. Enfin, celle-ci doit pouvoir les utiliser de façon séparée selon les besoins des applications. De plus, l’ATL doit les invoquer de façon indépendante et gérer les liens entre eux tout au long de la communication. 2.1.3.3 Approche autonomique L’autonomie de l’ATL vise à rendre transparent pour l’utilisateur humain les prises de décision relatives au choix des solutions protocolaires, à l’initiation de la communication ou en réponse à un changement du contexte du réseau. Ceci impose donc la capacité de l’ATL à trouver des compositions optimales pour satisfaire les applications en tenant compte de leurs besoins et de l’état du réseau. Dans une approche autonomique, cette prise en compte ne doit pas se limiter au moment de l’ouverture de connexion, mais doit être poursuivie tout au long de la communication pour s’adapter dynamiquement aux changement du contexte applicatif ou réseau, c’est-à-dire au changement des besoins applicatifs ou de l’état du réseau. Conséquences en termes de besoins fonctionnels d’une approche autonomique En conséquence, l’ATL doit, d’une part, effectuer une surveillance permanente du réseau afin d’en connaître l’état en temps réel, et éventuellement détecter tout changement conséquent. Par la suite l’ATL doit pouvoir trouver la composition protocolaire optimale pour le contexte courant (état du réseau et besoins des applications) à l’ouverture de la communication aussi bien qu’au cours de celle-ci. D’autre part, elle doit offrir aux applications la possibilité de pouvoir modifier leurs requêtes (services requis) durant la communication et ce sans interruption. Ces différentes fonctions sont regroupées au sein du composant gestionnaire de l’autonomie, l’Autonomic Manager, introduit en section 2.2.3.2 dans ce chapitre. 2.1.3.4 Synthèse Le tableau 2.1 fournit une vue synthétique des sections précédentes. 512. Architecture de l’ATL Problèmes Exigences de conception de l’ATL Principes de conception de l’ATL Approche logicielle d’implantation Complexité Masquer aux développeurs d’applications la connaissance et la complexité du choix des solutions protocolaires à invoquer. Masquer aux développeurs d’applications la complexité d’utilisation des solutions protocolaires qui seront invoquées. Abstraction Sémantique Approche orientée services Approche basée sémantique Dépendance Permettre une adaptation de la solution protocolaire retenue en ré- ponse à une évolution du contexte machine/réseau, ou bien à une modification de l’expression du service requis par l’application, c’est- à-dire : Abstraction Autonomie Approche autonomique – être doté d’une capacité d’autonomie dans la prise de connaissance du contexte et de ces évolutions, en plus de celle liée au choix et à la mise en œuvre des solutions protocolaires à invoquer ; – être doté d’une capacité d’autonomie dans le choix et la mise en œuvre des adaptations de la solution protocolaire en cours ; – offrir aux développeurs d’applications la possibilité de modifier les caractéristiques du service requis durant le temps d’exécution de l’application. Manque d’extensibilité Permettre son intégration au sein de son pool de services et de solutions protocolaires, en vue de la mise à disposition du service correspondant et de l’utilisation de la solution protocolaire. Extensibilité Approche basée composants Manque de configurabilité Gérer la nature composable des différents protocoles et mécanismes protocolaires, chaque protocole pouvant se voir adjoindre des mécanismes externes. Configurabilité Table 2.1: Synthèse des problèmes, exigences, principes et approches de conception de l’ATL 522.1. Exigences de conception et principes l’ATL 2.1.4 Fonctionnalités de l’ATL Cette section décrit l’ensemble des nouvelles fonctionnalités nécessaires pour mettre en œuvre les principes décrits précédemment. Ces fonctionnalités résultent directement des approches de conception de l’ATL, et sont introduites précédemment pour chacune des approches. Il s’agit en d’autres termes de toutes les fonctionnalités qui ne figurent pas dans l’approche traditionnelle de la couche et des protocoles de Transport, et qui permettent d’assurer la valeur ajoutée apportée par la nouvelle architecture de l’ATL. Ceci concerne principalement la gestion des services et l’autonomie. 2.1.4.1 Fonction de gestion des services La gestion des services est une fonctionnalité qui résulte de l’approche orientéeservices permettant de réduire la complexité de l’interface de l’ATL et d’assurer son extensibilité. Elle regroupe les tâches relatives à l’intégration de nouveaux composants protocolaires dans l’ATL et la correspondance entre ceux-ci et les services qu’ils offrent. La première tâche sera donc la constitution et le maintien de la liste des services au fur et à mesure que de nouveaux composants sont ajoutés à l’ATL. Ce rôle incombe à l’intégrateur de services. L’information sur la correspondance entre composants protocolaires et services offerts est ainsi intégrée dans la base de correspondance des composants et des services afin que les applications puissent les invoquer et que l’ATL puisse utiliser le nouveau composant lors des prochaines requêtes applicatives si nécessaire. Une fois les services stockés, les applications peuvent désormais les invoquer auprès de l’ATL. Pour ce faire, la base de correspondance des composants et des services permet sa consultation afin de retrouver les différents composants pouvant, seuls ou au sein d’un ensemble composite, assurer le service requis. 2.1.4.2 Fonction de gestion autonomique de la communication Cette fonctionnalité assure le caractère autonomique de l’ATL qui vise à décider du service composite initial à mettre en place et à adapter le comportement de celui-ci de façon autonome selon les variations du contexte réseau (changement du type du réseau ou de son état). Elle comporte quatre taches correspondant aux quatre parties de la boucle autonomique décrite un peu plus loin. La première tâche consiste à recueillir les informations utiles sur l’état du ré- seau. L’ATL doit donc disposer d’un service de monitoring du réseau, en souscrivant par exemple à un service externe ou en implantant le sien propre. Une fois ces informations recueillies (débit, délai, taux de perte . . . ), l’ATL doit les 532. Architecture de l’ATL analyser afin de détecter les variations et subséquemment le besoin éventuel d’un changement de la composition protocolaire courante. En cas de besoin d’un changement de composition, l’ATL doit revoir les composants sélectionnés pour chaque service et l’affiner, éventuellement une autre fois, afin de trouver pour chaque service le composant le plus adapté à l’état courant du réseau, en tenant compte de l’ensemble des paramètres de ces services pour lesquelles des information de surveillance ont été recueillies. 2.1.4.3 Fonction d’accueil, d’assemblage et de mise en œuvre des compositions L’ATL doit également permettre l’accueil des composants protocolaires utilisés dans la mise en place des différents services composite. Ainsi, si plusieurs implé- mentations peuvent être possibles, l’architecture doit prendre en compte le besoin d’une structure où prendra place cette composition et permettant son fonctionnement — en assurant notamment l’ordonnancement des messages à travers les différents composants, sa configuration, sa modification voire sa suppression. Les différents composants assurant ces fonctionnalités seront décrits en 2.7. 2.2 Architecture de l’ATL Cette section présente le modèle architectural de l’ATL ainsi que ses différents composants. Suivant une approche basée sur le formalisme UML 2.0, nous décrivons d’abord les cas d’utilisation de l’ATL (section 2.2.1). Nous présentons ensuite le modèle d’architecture de l’ATL et de ses principaux composants (section 2.2.3). Nous décrivons enfin les composants secondaires de l’ATL (section 2.2.4). 2.2.1 Cas d’utilisation L’architecture d’une solution telle que l’ATL doit être guidée par des cas d’utilisation faisant intervenir les différents acteurs du système. Ces acteurs peuvent être les utilisateurs du système ou d’autres éléments interagissant avec le système lors de son utilisation. Nous avons déjà évoqué les différents types d’applications utilisant l’ATL et de systèmes l’hébergeant. Ceux-ci donnent lieu aux cas d’utilisation de la figure 2.1. On peut voir sur ce diagramme que les applications représentent des acteurs primaires, placés à gauche du système, indiquant que ces acteurs sont les initiateurs des cas d’utilisations auxquels ils sont reliés. Le réseau, en revanche est un acteur secondaire. Il intervient dans la réalisation des cas d’utilisation auxquels il est relié, mais n’initie pas ces derniers. 542.2. Architecture de l’ATL Figure 2.1: Cas d’utilisation impliquant les applications Ce diagramme illustre également les prérogatives respectives des différents types d’applications. On y voit que les applications legacy ne peuvent qu’initier le cas d’utilisation « Transfer data » quand les applications aware et smart peuvent également exprimer les services à utiliser. Les applications smart peuvent également récupérer la responsabilité des choix normalement effectués par l’ATL dans la composition de composants protocolaires qui sera instanciée, via le cas d’utilisation « Select service ». Au delà des applications, l’ATL va également devoir offrir certains services aux utilisateurs humains. Ceux-ci peuvent être de plusieurs types et présentent des besoins différents, il s’agit : de l’utilisateur de la machine (ou utilisateur du système), de l’administrateur de la machine (ou administrateur du système) et du développeur de mécanismes protocolaires. Nous pouvons les voir sur le diagramme de cas d’utilisation de la figure 2.2. L’utilisateur du système doit pouvoir exprimer certaines préférences quant à l’utilisation des ressources disponibles sur sa machine. Ainsi la possibilité de modi- fier les politiques de prise de décision en fonction des différentes applications doit lui être offerte. Par exemple, l’utilisateur doit pouvoir exprimer qu’il veut que le 552. Architecture de l’ATL Figure 2.2: Cas d’utilisation impliquant les utilisateurs humains débit d’émission de son gestionnaire de téléchargement BitTorrent soit limité, afin de laisser une capacité plus importante pour le serveur web qui héberge son blog. L’administrateur du système doit également avoir la possibilité d’exercer ce genre de contrôle. Les préférences qu’il exprime doivent de plus avoir préséance sur celles exprimées par les utilisateurs du système. De plus, l’administrateur doit pouvoir aller modifier le comportement de l’ATL en influant sur les solutions que celle-ci peut instancier pour satisfaire les services requis par les applications. Un administrateur doit pouvoir interdire un protocole, ou en désactiver certaines options, modifier la connaissance qu’a l’ATL de ceux-ci afin que ses décisions futures soient conformes aux politiques de son entreprise. Par exemple, il doit pouvoir imposer d’utiliser un chiffrement via SSL au lieu de TLS, ou d’utiliser un contrôle de congestion basé sur TFRC et non sur TCP. Finalement, le dernier utilisateur humain est le développeur de composants protocolaires à intégrer à l’ATL. L’ATL doit en effet offrir les moyens pour pouvoir développer de nouveaux protocoles, de nouvelles implémentations pour tel ou tel mécanisme, et permettre leur intégration de manière transparente pour les autres acteurs. Les acteurs secondaires ont également un rôle important à jouer dans ces cas d’utilisation. Ceux-ci sont de deux types. Tout d’abord, les systèmes avec lesquels 562.2. Architecture de l’ATL on souhaite communiquer. Comme nous l’avons indiqué, ces systèmes peuvent être de deux types : les systèmes legacy qui ne disposent pas de l’ATL ; les systèmes ATL-enabled ou enabled qui en disposent. Il est capital qu’un système enabled soit capable d’initier une communication ou d’accepter une communication entrante avec un autre système enabled, bien évidemment, mais également avec un système legacy. Sans cette condition, l’adoption de l’ATL serait compromise car cela scinderait le parc informatique mondial en deux parties non interopérables. Ainsi, afin d’adapter son comportement au type de système avec lequel elle souhaite communiquer, l’ATL doit posséder un système de découverte de la présence de l’ATL sur le système distant. Le réseau constitue l’autre acteur secondaire, indispensable puisque c’est par lui que vont transiter les messages échangés entre les différentes instances de l’ATL. Comme indiqué dans le premier chapitre, celui-ci fait preuve aujourd’hui d’une grande hétérogénéité et d’une grande dynamicité au niveau de ses caractéristiques et de leurs variations au cours du temps. Les multiples technologies d’accès et la présence de différents types de middleboxes créent une variété de scénarios possibles. Le rôle de l’ATL sera de s’adapter à ces différents scénarios de manière à toujours satisfaire au mieux l’application, en fonction des préférences des utilisateurs et administrateurs, et des solutions mises à disposition par les développeurs, en tenant compte de la présence ou de l’absence d’une instance de l’ATL sur le système distant avec lequel s’établit la communication. Pour tenir compte des variations dans le réseau, l’ATL va devoir en permanence surveiller ses performances afin de prédire ou détecter les changements qui seront susceptibles d’induire une modification de la solution choisie afin de maintenir un service acceptable. 2.2.2 Modèle d’architecture de l’ATL En observant les protocoles classiques et l’architecture actuelle de l’Internet, les différents types de fonctionnalités intervenant dans une communication pour acheminer les données, contrôler cet acheminement, et gérer la communication, peuvent être répartis selon les trois plans suivants. – Le plan de données gère l’acheminement à proprement parler des données de l’utilisateur. C’est lui qui s’occupe de l’encapsulation des messages, ou du multiplexage vers les différentes applications par exemple. Les protocoles permettant l’encapsulation de données, tels que IP au niveau réseau de la pile protocolaire, sont des protocoles du plan de données. Ils offrent un service d’acheminement à un niveau supérieur le requérant. Le plan de données de l’ATL remplit ce même rôle. 572. Architecture de l’ATL – Les plans de contrôle et de gestion, qui assurent la prise en charge des deux autres types de fonctions. Au sein de l’ATL, le contrôle et la gestion servent tous deux à gérer la communication, mais à des échelles de temps différentes : les actions de contrôle sont des actions à portée temporelle réduite ou courte, à l’échelle du paquet ou de quelques RTT, comme la vérification de l’intégrité d’un paquet, ou la détection de pertes ; les actions de gestion portent sur des échelles de temps plus grandes, comme les modifications de tables de routage, ou des règles de sécurité. Nous pouvons remarquer que dans les protocoles existants, les actions de contrôles sont souvent prises en charge par le protocole du plan de données. TCP ou Ethernet vérifient par exemple eux-mêmes si les unités de données qu’ils reçoivent sont erronées ou non. A l’inverse, les actions de gestion sont généralement effectuées par des protocoles dédiés, comme les protocoles de routage, dont RIP, OSPF, ou BGP sont les représentants les plus connus ; d’autres protocoles connus sont également des protocoles prenant en charge des actions de gestion : ICMP, ARP, SNMP, etc. Notons que ces protocoles sont souvent indifféremment qualifiés de protocoles du plan de contrôle ou de protocole du plan de gestion. Le but ici n’est pas de savoir lequel des deux est juste afin de rétablir une classification claire des protocoles selon ces trois plans. Nous utilisons ce vocabulaire afin de distinguer non pas différents types de protocoles, mais différents types d’actions, et remarquons alors que les actions de transfert de données et de contrôle sont souvent gérées par un même protocole, quand les actions de gestion sont souvent gérées par un protocole dédié. Nous effectuons la même dichotomie au sein de l’ATL où une partie de l’architecture sera dédiée à l’exécution de la communication, donc au transfert de données et au contrôle de celui-ci, et où une seconde partie sera dédiée à la gestion de la communication, grâce à une relation constante avec la première et qui permettra d’influer sur celle-ci. Articulée autour de ces trois types de fonctions, l’architecture de l’ATL repose sur l’identification des besoins des utilisateurs exprimés via les cas d’utilisation précédents. De ces cas d’utilisations et des considérations exposées dans la section précédente, nous détaillons un premier niveau d’architecture composite de l’ATL (section 2.2.2.1). Les détails des composants de base de premier niveau sont présentés en section 2.2.3. 2.2.2.1 Modèle général Pour offrir les différents services présentés ci-dessus, l’architecture de l’ATL s’organise en plusieurs niveaux de composants, représentés sur la figure 2.3. On observe sur ce diagramme différents composants nécessaires au bon déroulement de la prise en charge des communications. Pour la gestion de la commu- 582.2. Architecture de l’ATL Figure 2.3: Diagramme de structure composite de premier niveau nication proprement dite, le composant plus important est le Flow, qui contient deux composants principaux : – l’Autonomic Manager qui s’occupe de la gestion autonomique de la communication avant et après l’établissement de la connexion ; – le Data Plan qui s’occupe de la communication proprement dite, en accueillant l’ensemble des composants protocolaires pour la communication, dénommée également « service composite », destinée à une communication particulière. On remarque que le Flow dispose de deux interfaces vers l’application : la première sert à l’échange de données entre l’application et le Flow ; la seconde est l’interface de contrôle, permettant à l’application d’exprimer ses besoins ainsi que ses contraintes concernant les décisions de l’ATL dans le cas d’une application smart. Chaque Flow est associé à un et un seul point d’accès au service de Transport. 592. Architecture de l’ATL Le nombre de Flow présents au sein du système est donc variable avec le temps, et peut également être nul si aucune application n’a ouvert de communication. Chaque Flow n’appartient qu’à une et une seule application, mais une application peut posséder plusieurs Flow si elle ouvre plusieurs points d’accès. Un serveur web, par exemple, aura un Flow ouvert par client visitant le site qu’il héberge. Le Flow est décrit plus avant en section 2.2.3.1. Avant que ne débute effectivement une communication, l’Autonomic Manager d’un Flow utilise la base des composants et des services pour décider de la composition adéquate selon les besoins de l’application et l’état du réseau. Cette base, commune à tous les Flow du système, recense tous les composants protocolaires disponibles et les services qui leur sont associés et permet aux Autonomic Manager de choisir parmi cet ensemble le service composite le mieux adapté. L’intégrateur de services permet l’installation de nouveaux composants au sein de l’ATL, notamment via la mise à jour de la base des composants et services. Notons que celle-ci peut également être modifiée par un utilisateur humain tel qu’un administrateur système ou par un logiciel de gestion hiérarchiquement supérieur. Le rôle du Flow Creator est l’instanciation des Flow lors de la création d’un TSAP. Le Signalization Message Controler est le composant responsable de la signalisation relative aux informations globales. Finalement, le multiplexeur-démultiplexeur réseau (Net Mx/Dmx) constitue l’interface entre les Flow et le réseau. Ces composants sont décrits dans la section 2.2.4 relative aux composants secondaires. On remarque que l’ATL dispose, en plus des interfaces avec l’application et de celle avec la couche réseau sous-jacente, d’une interface d’administration destinée aux utilisateurs humains, afin de leur permettre d’exprimer des préférences générales comme l’indique le diagramme de cas d’utilisation de la figure 2.2. C’est à travers celle-ci que les commandes des utilisateurs et des administrateurs sont intégrées dans l’ATL. C’est également grâce à elle que des programmes extérieurs peuvent venir administrer l’ATL le cas échéant. 2.2.3 Composants de base de l’ATL Cette section est consacrée à la description du composant principal de l’ATL : le Flow et ses sous-composants. Ce sont eux qui vont accueillir et gérer la composition de composants protocolaires instanciant la communication. 2.2.3.1 Le Flow Le composant principal de l’ATL est le Flow. Un Flow est mis à disposition d’une application pour chaque point d’accès qu’elle ouvre. La décomposition du Flow, illustrée sur la figure 2.4, fait apparaître deux composants principaux : le Data Plan et l’Autonomic Manager, dont les fonctions 602.2. Architecture de l’ATL permettent de distinguer la prise en charge des actions de type transfert de données et contrôle pris en charge par les composants protocolaires (Data Plan), et les actions de gestion du service composite (Autonomic Manager). Figure 2.4: Composition d’un Flow Le Flow dispose de plusieurs interfaces : – la première le relie à l’application et est composée d’une partie données, permettant l’échange de ces dernières, et d’une partie contrôle, comme introduit en section 2.2.2.1 : – la partie données est redirigée vers le Data Plan, – la partie contrôle est redirigée vers l’Autonomic Manager, afin de lui communiquer les différentes informations sur les services désirés et les diffé- rentes contraintes que l’application souhaite exprimer ; – la deuxième interface relie le Flow à la couche réseau par le biais du Data Plan afin de permettre l’échange de données utilisateurs encapsulées ou à 612. Architecture de l’ATL destination de l’application. Celle-ci est reliée directement à la couche réseau sous-jacente en sens descendant et à un démultiplexeur dans le sens montant (cf. 2.2.4.3). La liaison entre l’Autonomic Manager et le Data Plan est décrite dans la section 2.2.3.2. Notons enfin que l’Autonomic Manager est également relié au Flow Creator, décrit en 2.2.4.1, et au Signalization Message Controler, décrit en 2.2.4.2. 2.2.3.2 L’Autonomic Manager L’Autonomic Manager est un des composants internes majeur d’un Flow. Avant d’en décrire l’architecture fonctionnelle dans le cadre de l’ATL, nous introduisons tout d’abord ce concept tel que défini par IBM. État de l’art relatif au concept d’Autonomic Manager tel que défini par IBM IBM définit l’Autonomic Manager comme le composant permettant la gestion autonome d’une ressource. Dans le cas de l’ATL, la ressource s’avère être un service composite, une composition de protocoles et mécanismes protocolaires destinés à satisfaire les besoins de l’application. L’Autonomic Manager est composé d’une boucle de contrôle constituée de quatre fonctions, et d’une base de connaissance à laquelle ces quatre fonctions peuvent accéder. Ces quatre fonctions sont les suivantes. Le monitoring : Le but de cette fonction est la surveillance des informations d’état du système et leur pré-analyse afin de détecter des symptômes d’un comportement potentiellement anormal ou qui dériverait de l’état souhaité. L’analyse : La fonction d’analyse est invoquée par la fonction de monitoring lorsque cette dernière détecte un symptôme. Le symptôme est utilisé afin de modéliser l’état actuel du système qui est alors comparé à l’état souhaité. Si les deux modèles divergent, une alarme est alors levée pour avertir la fonction suivante. La planification : Lorsque la fonction d’analyse lève une alarme, la fonction de planification prend en charge la décision des actions à entreprendre pour modifier le système afin de refaire converger son état vers l’état souhaité. En résulte un plan de modification, discuté en 2.2.3.2, qui est communiqué à la dernière fonction de la boucle. L’exécution : Cette dernière fonction prend en charge les modifications décidées par la fonction de planification. La réalisation effective, l’orchestration et la synchronisation des différentes étapes du plan de modification sont à la charge de cette fonction. 622.2. Architecture de l’ATL Ces différentes fonctions s’organisent autour de la base de connaissances comme le montre la figure 2.5. Cette base de connaissance sera décrite plus loin en 2.2.3.4. Figure 2.5: Organisation des fonctions de l’Autonomic Manager La communication entre la ressource gérée et l’Autonomic Manager est assurée par une interface nommée Touchpoint et capable d’un comportement de type capteur (sensor)afin de récupérer des informations sur la ressource, et de type effecteur (effector) afin d’appliquer des modifications sur la ressource. La figure 2.6 représente les différentes interactions possibles entre l’Autonomic Manager et le Touchpoint dans les deux types de comportement. Application au sein de l’ATL Au sein d’un Flow, la liaison entre l’Autonomic Manager et le Data Plan — qui représente la ressourcée gérée — est illustrée figure 2.4. Cette liaison permet à la fonction de monitoring de l’Autonomic Manager de récupérer les informations fournies par les différents composants protocolaires, et à la fonction d’exécution d’aller modifier les paramètres de ces composants, ou de modifier la structure composite elle-même. Les décisions prises par la fonction de planification de l’Autonomic Manager peuvent avoir une portée locale ou répartie. Portée locale : les décisions de l’Autonomic Manager n’impactent que les composants de l’hôte sur lequel il se trouve. Celles-ci n’ont aucune influence sur le système distant ou la liaison entre les deux systèmes, et ne nécessitent 632. Architecture de l’ATL Figure 2.6: Caractéristiques du Touchpoint et lien avec l’Autonomic Manager donc pas d’intervention de ce dernier. Informer l’hôte distant de ces décisions n’est a priori pas nécessaire mais peut cependant présenter un intérêt dans certains cas. Portée répartie : les décisions de l’Autonomic Manager impactent les composants situés sur l’hôte distant ou la liaison entre les deux hôtes, et nécessitent une intervention de ce dernier. Une synchronisation des deux systèmes pouvant être nécessaire, la présence d’un protocole de signalisation la permettant est requise ; dans l’architecture de l’ATL, cette signalisation relève de la fonction d’exécution de la boucle de contrôle. Sur ce second point, notons qu’une signalisation sera également nécessaire au niveau de la fonction de monitoring afin de requérir des informations de l’hôte distant ou de lui en fournir, ainsi qu’au niveau de la fonction de planification afin d’établir des prises de décisions en collaboration avec l’hôte distant. Selon les cas, l’Autonomic Manager ne sera pas seul gestionnaire de la communication. En effet, si l’hôte distant possède également l’ATL, les deux Autonomic Manager (un par Flow) devront être en contact afin d’échanger certaines informations, comme précisé dans la partie Monitoring. 642.2. Architecture de l’ATL Pour la même raison, les prises de décisions doivent également pouvoir être partagées. Les deux Autonomic Manager vont avoir une double responsabilité. – Tout d’abord, ils vont gérer individuellement les modifications locales de leur service composite respectif. En effet, la décision de modifier tel ou tel paramètre, d’enlever ou ajouter tel ou tel composant protocolaire, leur incombe tant que cette modification est purement locale. Par exemple, modifier à la volée l’algorithme de calcul du RTO dans le bloc de service TCP d’un certain Channel ne requiert aucune action de la part de l’Autonomic Manager pair. – La seconde responsabilité est la prise de décision répartie. Il s’agit cette fois de gérer les modifications qui vont requérir des décisions sur chaque hôte. Les deux Autonomic Manager doivent donc être en communication, afin de se transmettre les informations de monitoring nécessaires ainsi que les consignes d’exécution. Dans une prise de décision répartie les Autonomic Manager peuvent s’organiser de différentes manières. Nous identifions ici trois hiérarchies possibles : collaborative, participative et subordinative. En mode collaboratif : les deux Autonomic Manager ont un poids égal dans la prise de décision. Chaque décision ou compromis doit donc faire consensus afin d’être appliqué. Ce mode peut-être envisagé lorsque les deux flux applicatifs sont de même importance, comme dans le cas par exemple, d’une vidéoconférence en pair à pair, ou chaque participant envoie un flux vidéo et un flux audio, souvent du même ordre de qualité. Notons que le cas d’une vidéoconférence centralisée sur serveur est différent : le serveur jouant le rôle de point d’échange central des données celui-ci aura un rôle plus important. En mode participatif : chaque Autonomic Manager peut proposer des modi- fications ou des actions sur la gestion de la communication, mais la décision finale revient à l’un des deux seulement. L’Autonomic Manager « participant » ne peut que faire des propositions qui devront être finalement approuvées par l’Autonomic Manager « décidant ». Dans ce mode, l’Autonomic Manager participant devient géré par l’Autonomic Manager décidant, sans pour autant perdre son intelligence. En mode subordinatif : un des Autonomic Manager se subordonne totalement à l’autre, c’est-à-dire que comme dans le cas précédent, il devient géré par l’Autonomic Manager pair à la différence cependant que l’Autonomic Manager subordonné abandonne toute intelligence concernant la gestion distribuée au profit de l’Autonomic Manager distant, ne devenant qu’un agent de monitoring et d’exécution de ce dernier. Ce mode peut être utile dans le cas où un des deux hôtes possède une très faible capacité de calcul (un capteur par exemple), ne pouvant ainsi pas prendre en charge plus que des décisions purement locales. 652. Architecture de l’ATL Plan de modification Une fois la décision prise sur les actions à entreprendre, le plan de modification contient la suite des actions à engager. Il décrit, point par point, quelles sont les modifications à faire, dans quel ordre, et si des conditions de transitions sont à respecter. La variété d’actions de reconfiguration possibles à entreprendre est a priori colossale, d’autant que celles-ci peuvent être spécifiques à certains composants protocolaires. Par exemple, la décision de désactiver l’algorithme de Nagel peut-être prise au sein de TCP ou de SCTP, mais n’a aucun sens dans le cas d’UDP. Si cet exemple représente une décision locale sans impact sur le pair distant de la communication, certaines reconfigurations nécessiteront par contre de synchroniser les deux Flow. Le déploiement ou le remplacement d’un ou plusieurs composants protocolaires par exemple, comme la transition de TCP vers DCCP, donne lieu à une évidente synchronisation. Le plan doit donc être organisé en étapes que chaque Autonomic Manager suivra à un rythme dépendant de leur organisation relative (cf. 2.2.3.2). Le plan mis à disposition de chacun peut différer. En effet, les actions à entreprendre ne sont pas forcément les mêmes sur chacun des deux Flow. Ainsi, chaque Autonomic Manager n’a besoin que de la connaissance de son propre plan. Ceux-ci acquièrent le dit plan par différents moyens selon la manière dont les décisions sont prises (cf. 2.2.3.2). En effet, si le mode retenu est la collaboration, chaque Autonomic Manager mettra en place son propre plan, via une négociation conjointe avec son pair. Dans le mode participatif ou subordinatif, l’Autonomic Manager maître est en charge de mettre le plan de chacun en place, puis le transmettre à son subordonné une fois ceci fait. 2.2.3.3 Le Data Plan Afin d’accueillir les instances des différents composants protocolaires, le composant géré par l’Autonomic Manager, le Data Plan, est composé de plusieurs élé- ments permettant l’assemblage et la manipulation de ceux-ci. Ces éléments sont représentés sur la figure 2.7. Le Channel Le composant principal du Data Plan est le Channel. C’est au sein de celui-ci que sera instancié le service composite qui aura la charge de gérer la communication. Un Channel n’est pas nécessairement unique. En effet, plusieurs Channel peuvent être instanciés au même moment, contenant des services composites différents, notamment dans certains scénarios de reconfiguration. Ainsi, chaque Channel possède un identifiant, permettant de savoir quel message doit être traité par quel Channel. Les composants prenant place dans le Channel sont les composants protocolaires. Tout service composite se compose d’un composant protocolaire de type protocole et d’autant de composants protocolaires de type micro-protocole que nécessaire. 662.2. Architecture de l’ATL Figure 2.7: La composition du Data Plan Ceci implique que les protocoles existants dans les systèmes actuels soient convertis en composants protocolaires pour être intégrés à l’ATL. Le cœur du protocole n’a pas à être modifié. Seule sa manière de communiquer avec le reste de la pile réseau du système doit être adaptée. Ainsi, au lieu d’être directement relié à l’application et au protocole de la couche réseau, le protocole de Transport devra récupérer les messages depuis les micro-protocoles situés au-dessus et audessous de lui dans le Channel dans lequel il prend place. Ceci peut être fait soit en reliant directement les interfaces de chaque composant protocolaire directement, soit en utilisant le Channel comme ordonnanceur. Celui-ci aurait alors la charge de faire transiter le message de composant en composant, récupérant ce dernier après chaque traitement pour le passer au suivant. 672. Architecture de l’ATL Multiplexeur-démultiplexeur Afin de permettre l’aiguillage entre les diffé- rents Channel, quand plusieurs sont présents, un multiplexeur-démultiplexeur prend position entre les Channel et l’interface vers l’application, et entre les Channel et l’interface vers le réseau. Ceux-ci effectuent leurs tâches grâce aux identifiants des différents Channel, qui ont été préalablement estampillés dans les messages. Buffers Lorsqu’un message arrive de l’application ou du réseau, il est placé dans un buffer en attendant d’être pris en charge par le multiplexeur-démultiplexeur qui l’aguillera vers le Channel adéquat. Ces buffers jouent le rôle de tampon entre l’application et les Channel ainsi qu’entre les Channel et le réseau, afin d’absorber les différences de rythme entre chaque couche. Ce sont également eux qui sont en charge d’estampiller chaque message entrant avec l’identifiant de Channel qui doit les traiter, puis de retirer l’estampille à la sortie du Data Plan, afin que celle-ci n’interfère pas avec les applications (principalement les applications legacy), avec le réseau (car on créerait alors une sorte de nouveau protocole, qui ne serait pas reconnu partout), et avec le système distant (principalement les systèmes legacy). Channel Manager Ce composant est le relais de l’Autonomic Manager au sein du Data Plan. C’est lui qui remonte les différentes informations de monitoring à l’Autonomic Manager, mais également qui gère les créations et les modifications de Channel selon les ordres de l’Autonomic Manager. Il possède également la capacité de mettre les multiplexeurs-démultiplexeurs en pause afin de geler la communication, et de notifier ceux-ci ainsi que les buffers des identifiants des nouveaux Channel, afin d’estampiller et d’aiguiller correctement les nouveaux messages, en fonction des Channel présents. 2.2.3.4 Intégrateur des services et base de connaissances La fonctionnalité de gestion des services (cf. 2.1.4.1) est notamment prise en charge par la base des composants et services et par l’intégrateur de services. Ceuxci permettent d’effectuer la correspondance entre services et composants protocolaires, ce qui peut impliquer le cas échéant une négociation avec l’hôte distant — si celui-ci dispose également de l’ATL. Correspondances entre services et composants La correspondance entre les composants protocolaires disponibles et les services qu’ils offrent est nécessaire pour la traduction des requêtes applicatives constituées de services, en solution protocolaire potentiellement composite permettant de satisfaire ces requêtes. Pour ce faire l’ATL dispose d’une base répertoriant ces services et comportant pour chaque composant protocolaire donné, la description du service qu’il offre. 682.2. Architecture de l’ATL L’Autonomic Manager de chaque Flow peut y effectuer une requête permettant de récupérer le ou les composants susceptibles de satisfaire tout ou partie des services requis — le cas d’un service partiellement couvert par un composant pouvant être pallié par sa composition avec un ou plusieurs autres fournissant les services manquants. L’intégration de nouveaux composants doit permettre leur utilisation immé- diate par les différentes applications, et donc par les différents Flow de l’ATL. Ainsi, le rôle de l’intégrateur est de maintenir la base des composants et services afin que chaque nouveau composant installé sur le système voit la description du service qu’il offre être mis à disposition des Autonomic Manager pour leurs prises de décision futures. 2.2.4 Composants secondaires 2.2.4.1 Flow Creator La création d’un Flow est effectuée par le Flow Creator. C’est lui qui reçoit les demandes de création, correspondant à l’ouverture des différents points d’accès au service de Transport, que ceux-ci soient ouverts par des applications legacy, aware ou smart. Il lui incombe donc d’intercepter les appels de méthodes classiques afin de rediriger leur prise en charge vers l’ATL, ce qui implique une modification de l’implémentation de l’API socket classique, de manière à ce que les applications legacy ne soient pas modifiées, mais appellent tout de même l’ATL (à leur insu) lors de l’ouverture de sockets. Cette API devra également être étendue afin de prendre en compte les spécificités des applications aware et smart. C’est lui également qui récupère les différentes informations passées par l’application à la création du point d’accès, comme le protocole de Transport désiré par les applications legacy ou les spécifications de besoins en qualité de service pour les applications aware ou smart, ainsi que d’éventuelles contraintes supplémentaires pour les applications smart. On voit directement sur la figure 2.3 que le Flow Creator est une nouvelle manière d’implémenter la partie Transport de l’API socket classique pour le cas des applications legacy et dans le contexte de l’ATL. Dans le cas des applications aware et smart, le Flow Creator est l’implémentation des nouvelles fonctionnalités des extensions d’API, ou de la nouvelle API, nécessaire au fonctionnement de ces nouveaux types d’applications. 2.2.4.2 Signalization Message Controler Le composant suivant présent sur la figure 2.3 est le Signalization Message Controler (SigMsgCtrlr). Ce composant est chargé de l’échange des messages de 692. Architecture de l’ATL gestion entre deux instances de l’ATL, concernant des informations sur l’état global de l’ATL sur l’hôte distant et non pas sur l’état d’un Flow en particulier. Si les deux systèmes impliqués dans une communication disposent de l’ATL, un Autonomic Manager désirant avoir une information sur l’ATL du système distant, comme par exemple la liste des services instanciables sur ce système, adressera cette requête à son Signalization Message Controler qui la reliera à celui du système distant. Si au contraire l’Autonomic Manager souhaite avoir une information concernant précisément le Flow distant auquel il est relié, telle que des informations de monitoring de la communication, il devra directement s’adresser à l’Autonomic Manager de ce Flow. C’est notamment le Signalization Message Controler qui aura la charge de découvrir si l’ATL est présente sur une machine distante à laquelle on souhaite se connecter. Afin d’économiser certaines ressources système et réseau ainsi que temporelles, ce composant peut embarquer des fonctions de cache, gardant en mémoire certaines des informations qu’il a déjà découvertes, afin de les distribuer à un Autonomic Manager les requérant sans avoir besoin qu’un message de requête ne parcourt le réseau. 2.2.4.3 Multiplexage-démultiplexage entre couche réseau et Flow Le dernier composant est un multiplexeur-démultiplexeur se situant entre les Flow et la couche réseau. Son rôle est de récupérer les différents messages provenant du réseau afin de les aiguiller vers le Flow adéquat. Pour une telle opération, les Flow doivent avoir un adressage leur permettant d’être différenciés au sein de la machine. Dans un premier temps nous voyons comment fonctionne ce type d’adressage dans les systèmes actuels avant de proposer une manière d’adresser les Flow de l’ATL. Adressage dans les systèmes actuels Sur un système legacy, un socket est identifié, en mode connecté, selon le flux auquel il appartient. Or un flux est défini par le quintuplet : (@IPsrc, @IPdest, protocole de Transport, portsrc, portdest). En mode non connecté, un socket est défini par le triplet (@IPdest, protocole de Transport, portdest). Le passage au protocole de Transport est assuré par la couche réseau. Le passage au socket est assuré alors par le protocole de Transport selon le numéro de port. Une fois le paquet arrivé sur le système hôte, l’identification locale réside donc dans le couple (protocole de Transport, portdest). Dans le cas de l’ATL cependant, tout message échangé entre deux Flow ne comporte pas toujours ces informations, comme les messages de gestion échangés entre Autonomic Manager par exemple. De plus, le service composite étant variable, le protocole utilisé dans celui-ci peut également varier, rendant obsolète le couple (protocole de Transport, portdest) pour l’identification d’un Flow dans l’ATL. 702.2. Architecture de l’ATL Adressage d’un Flow Un Flow est associé à un et un seul point d’accès au service de Transport, et réciproquement. Adresser un Flow revient donc à adresser le point d’accès associé. Un Flow comportant toujours un composant protocolaire de type protocole, et celui-ci utilisant alors un numéro de port, le couple (protocole de Transport, portdest) peut être utilisé par l’ATL pour aiguiller les paquets arrivant de la couche réseau vers le Flow correspondant. Cependant, lorsque l’Autonomic Manager n’a pas encore statué sur le protocole de Transport à utiliser, ni l’une ni l’autre des deux valeurs du couple précédemment cité n’est encore disponible. Pourtant, certains messages à destination du Flow peuvent déjà être émis et reçus, comme ceux permettant la négociation du service composite qui sera à instancier, négociation qui permettra à l’Autonomic Manager de décider du protocole de Transport à utiliser par la suite. Ceux-ci doivent disposer d’une information permettant leur identification et leur démultiplexage. Si l’application ouvrant le point d’accès est une application legacy, elle fournit comme à l’heure actuelle le protocole de Transport et le numéro de port avec lesquels elle souhaite travailler. Sinon, l’application doit fournir un identifiant traduisant le service qu’elle offre à travers ce point d’accès, suivant ainsi la construction orientée service de l’ATL. Un navigateur web pourra ainsi fournir comme identifiant CLTWEB, signifiant que le point d’accès venant d’être ouvert est destiné à être client d’une communication web (utilisant http). Le système y adjoint un numéro afin de différencier différents points d’accès ouverts et offrant le même service. Ainsi, un navigateur web souhaitant charger deux pages web simulatnément ouvrira deux points d’accès (un par page), identifiés CLTWEB par l’application, et complétés par le système en CLTWEB1 et CLTWEB2. Cet identifiant est associé automatiquement grâce à une table de traduction à un couple (protocole de Transport, portdest). Par exemple, un serveur web ouvrant un point d’accès le nommera avec l’identifiant SRVWEB, qui sera automatiquement associé au couple (tcp, 80). Si l’ATL est présente sur le système distant, alors les messages de négociation de la composition en provenance de celui-ci désignerons le Flow auquel ils sont destinés via les identifiants textuels. Sinon, on déduira que le Flow vers lequel diriger les messages entrant est celui dont le couple (protocole de Transport, no port) correspond à ce que contient le message ou on utilisera ce couple comme protocole de Transport à utiliser. Ceci sous-entend le besoin de standardiser certains identifiants textuels ainsi que leur correspondance au couple (protocole de Transport, portdest), comme sont à l’heure actuelle standardisés certains de ces couples pour des utilisations particulières. Le couple (tcp, 80) est par exemple standardisé pour les communications utilisant http. L’identifiant correspondant à ce couple ainsi que cette correspondance devront également être standardisés pour permettre la transition vers l’ATL 712. Architecture de l’ATL de manière transparente. 2.3 Conclusion Ce chapitre a présenté les différents composants qui forment la structure de l’ATL. Tout d’abord, nous avons détaillé les objectifs que doit remplir l’ATL et les paradigmes de conceptions employés pour les atteindre : la conception orientée service et basée composant. Les intérêts et impacts de ces deux approches ont été notamment abordés. Dans une seconde partie, nous avons décrit les trois types de fonctionnalités qui doivent être présentes au sein de l’ATL pour assurer le bon déroulement des communications. Ces fonctionnalités peuvent être du type données, contrôle ou gestion. Puis nous avons détaillé les différents composants permettant de mettre ceci en place, d’abord à un premier niveau de décomposition, puis plus en dé- tails dans le cas des composants dits primaires, ceux qui accueillent les flux de données, mais également les composants secondaires, permettant aux premiers de fonctionner correctement. Le chapitre suivant s’attarde sur les différents comportements dont font preuve ces composants dans deux cas particuliers : celui de l’ouverture d’un point d’accès au service de Transport par l’application, quel que soit son type — legacy, aware ou smart — et celui de la reconfiguration du service composite proposé par un Flow. 72CHAPITRE 3 Description comportementale de l’ATL : cas de la création et de la reconfiguration d’un service composite Le précédent chapitre a introduit et décrit la structure composite de l’ATL, en détaillant le rôle de chacun des composants dans le but de satisfaire les objectifs fixés à la fin du chapitre 1. Dans le présent chapitre, nous décrivons le comportement des différents élé- ments précédemment introduits dans deux cas particuliers : – la création d’un point d’accès au service de Transport ; – la reconfiguration d’un Flow. Ces deux situations revêtent une importance particulière. Le premier cas mérite d’être étudié car l’ouverture d’un point d’accès avec l’ATL diffère des solutions classiques. En effet ici, la liaison avec le protocole de Transport n’est pas directe. Pourtant, les applications legacy ne doivent pas sentir de différence afin de ne pas avoir à subir de mise à jour. De plus les applications aware et smart communiquent différemment avec la couche Transport que les applications legacy. Le second cas présente un intérêt car s’il n’est pas totalement nouveau, les problématiques de reconfiguration comportementale et structurelle, abordées en 3.2, sont ici déclinées dans le contexte de flux de données de Transport et présentent des particularités. Il s’agit de plus d’une fonctionnalité centrale de l’ATL sans laquelle ses objectifs ne seraient pas atteints. 733. Description comportementale de l’ATL La première partie du chapitre décrit le cas de l’ouverture d’un point d’accès au service de Transport, et la deuxième le cas de la reconfiguration. La troisième partie aborde les problèmes de traduction d’état dans le cadre des reconfigurations, à travers la problématique du traitement des messages nécessitant des retransmissions. Sommaire 3.1 Création d’un point d’accès au service de Transport . . . . . . 74 3.1.1 Instanciation d’un Flow . . . . . . . . . . . . . . . . . 74 3.1.2 Application cliente . . . . . . . . . . . . . . . . . . . . 76 3.1.3 Application serveur . . . . . . . . . . . . . . . . . . . . 80 3.1.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . 82 3.2 Reconfiguration d’un Flow . . . . . . . . . . . . . . . . . . . . 83 3.2.1 Déroulement d’une reconfiguration . . . . . . . . . . . 83 3.3 Traitement des retransmissions lors des transitions . . . . . . . 88 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 3.1 Création d’un point d’accès au service de Transport Cette section décrit le comportement de l’ATL dans les différents cas de figure possibles, selon le type de l’application — legacy, aware ou smart —, du système distant avec lequel on souhaite communiquer — legacy ou enabled — et selon que l’on se place du côté client (au sens initiateur) ou serveur de la communication. Une synhèse des différents cas de figure est ensuite proposée afin de simplifier le nombre de cas à prendre en compte. 3.1.1 Instanciation d’un Flow Parmi toutes les situations citées ci-dessus, certaines actions sont nécessaires dans tous les cas. Cette suite d’actions concerne l’instanciation effective du Flow afin qu’il puisse par la suite accueillir le service composite. En effet, que le système distant soit ATL-enabled ou legacy, que l’application demandant la création du TSAP soit legacy, ATL-aware ou smart, que l’on soit serveur ou client, les actions décrites ici seront toujours menées, et correspondent à la préparation du Flow. Nous appelons cette suite d’actions : comportement commun. Lorsque l’application effectue une demande de création d’un point d’accès au service de Transport (TSAP) comme dans le diagramme de la figure 3.1, elle utilise une méthode telle la méthode socket de l’API éponyme en C, ou le constructeur de 743.1. Création d’un point d’accès au service de Transport Figure 3.1: Une application de type aware ou smart ouvre un point d’accès au service de Transport via l’interface de contrôle de l’ATL la classe Socket en Java. Dans un système comportant l’ATL, ces appels à méthode de création, qu’elles proviennent des API classiques ou d’une API dédiée à l’ATL, doivent être récupérés par le Flow Creator. Celui-ci crée alors un nouveau Flow au sein de l’ATL, et le lie au TSAP. Dans le Flow sont instanciés un Autonomic Manager et un Data Plan, dédiés à ce Flow, comme décrit sur le diagramme de la figure 3.3. Une fois le Flow instancié, ainsi que son Data Plan et son Autonomic Manager, le Flow Creator communique à ce dernier les caractéristiques du service demandé par l’application. Celles-ci vont différer selon le type d’application : – Une application legacy communiquera le protocole de Transport qu’elle souhaite utiliser ainsi que le numéro de port utilisé sur le système serveur de la communication. – Une application aware communiquera les caractéristiques qu’elle souhaite voir respectées par le service ainsi que le nom du point d’accès dont elle 753. Description comportementale de l’ATL Figure 3.2: Diagramme de séquence de création d’un Flow demande la création (cf. 2.2.4.3). – Une application smart communiquera les mêmes informations qu’une application aware, ainsi qu’un certain nombre de contraintes supplémentaires, en imposant par exemple l’utilisation d’un certain protocole comme base de la composition protocolaire (cf. 2.2.1). Le Flow est alors prêt à accueillir un nouveau Channel comportant le service composite qui assurera la communication. 3.1.2 Application cliente Cette section décrit le comportement de l’ATL lorsque l’application est cliente de la connexion, c’est-à-dire qu’elle fournit à l’ATL l’adresse IP du système distant via une demande de connexion explicite — comme par exemple, pour une 763.1. Création d’un point d’accès au service de Transport Figure 3.3: Instanciation d’un nouveau Flow application legacy ouvrant un socket TCP — ou émet un message à destination du système distant — comme par exemple une application legacy utilisant UDP. 3.1.2.1 Application legacy Une application legacy doit pouvoir ouvrir un TSAP tel qu’elle l’a toujours fait, c’est-à-dire via une méthode faisant appel à l’API socket classique. Elle indique via cette méthode, le protocole de Transport ainsi que le numéro de port à utiliser. Cette méthode lui retourne ensuite ledit socket. Du point de vue de l’application, ce comportement ne doit pas être modifié. Après avoir effectué le comportement commun, l’Autonomic Manager doit, afin de décider du service composite à déployer, récupérer certaines informations. – Il connaît déjà le protocole qui lui a été demandé par l’application et peut en déduire une contrainte de décision (qui est de fait : « utiliser ce protocole ») et un type de Qualité de Service demandée (par exemple : « ordre et fiabilité totale » si TCP est demandé) ; – Ce service peut être suffisant. Cependant, il peut-être plus adéquat de le coupler à d’autres en fonction de l’évolution des conditions réseaux. – De plus, si le système hébergeant le serveur dispose de l’ATL, il peut avoir des desiderata ou des exigences quant aux composants protocolaires à utiliser pour implanter les services requis. En conséquence de quoi l’Autonomic 773. Description comportementale de l’ATL Manager doit savoir si le serveur auquel il compte se connecter dispose ou non de l’ATL également. L’application étant cliente, l’ATL dispose de l’adresse du serveur. Ainsi, l’Autonomic Manager va effectuer une demande de découverte de la présence de l’ATL sur le serveur grâce au Signalization Message Controler. Ce dernier va alors effectuer une requête auprès de son homologue sur l’ATL distante. La réponse, positive ou négative, sera alors transmise à l’Autonomic Manager requérant. Bien que d’autres solutions soient envisageables, une solution simple de mise en œuvre de la requête du Signalization Message Controler consiste à envoyer un paquet TCP de type SYN sur un port prévu à cet effet. La réception d’un SYNACK constituera alors une réponse positive, celle d’un RST une réponse négative. L’inconvénient majeur d’une telle solution consiste bien sûr en la réservation d’un numéro de port à cette utilisation. Son avantage principal, cependant, réside dans l’utilisation d’un paquet TCP, paquet qui ne sera filtré que par une minorité de middleboxes, permettant ainsi d’être compatible avec la quasi totalité du réseau existant. Quelle que soit la méthode d’implémentation retenue, la découverte doit être rapide. Un modèle simple de type requête/réponse serait alors à privilégier, limitant ainsi le temps de découverte à un RTT maximum, comme illustré sur la figure 3.4. Figure 3.4: Mécanisme de découverte de l’ATL 783.1. Création d’un point d’accès au service de Transport En cas de réponse négative (i.e. l’hôte distant ne dispose pas de l’ATL) l’Autonomic Manager doit décider seul d’un service composite utilisant le protocole requis par l’application. En effet, l’ATL n’étant pas présente sur le système distant, on peut conclure que le protocole que celui-ci utilisera est nécessairement celui demandé par l’application. Il est donc impératif de l’utiliser. Cependant, s’il le juge utile, l’Autonomic Manager peut décider d’ajouter certains mécanismes protocolaires locaux au service composite. En cas de réponse positive, l’Autonomic Manager va entrer en relation avec son pair distant sur le serveur, afin d’entamer une négociation avec celui-ci concernant la composition du service composite à mettre en place. Cette négociation concerne les composants protocolaires distribués, ceux-ci étant répartis sur les deux systèmes. Des mécanismes protocolaires locaux peuvent y être adjoints de chaque côté de la communication, si tant est que ceux-ci ne créent pas de conflit avec les composants distribués. Une fois le service composite décidé, l’Autonomic Manager va l’instancier en demandant la création d’un nouveau Channel au Channel Manager du Data Plan (cf. 3.1.1). 3.1.2.2 Application ATL-aware Une application ATL-aware ouvre un TSAP en passant la description de ses besoins en Qualité de Service (Quality of Service) (QoS) en paramètre, ainsi que le nom qu’il attribue au TSAP (cf. 2.2.4.3). Après instanciation d’un nouveau Flow, l’Autonomic Manager ne connaît que les besoins en terme de services requis par l’application ciente. Il ignore cependant sur quel protocole se baser pour répondre aux services requis. Cette question peut facilement être résolue en négociant la composition avec l’hôte distant. Ainsi : – l’Autonomic Manager va effectuer une demande de découverte au Signalization Message Controler, comme précédemment ; – tout comme dans le cas d’une application legacy, une réponse positive va donner lieu à une négociation basée sur les critères de services requis par l’application, et les éventuelles contraintes imposées par celles-ci ; – dans le cas d’une réponse négative, l’Autonomic Manager va décider d’un service composite basé sur le protocole de Transport obtenu via traduction du nom attribué au TSAP (cf. 2.2.4.3), et comportant éventuellement un ou plusieurs blocs de service locaux s’il le juge nécessaire. Dans l’exemple où un client web ATL-aware ouvre un TSAP, si le Signalization Message Controler retourne une réponse positive, les deux Autonomic Manager (i.e. : du Flow client et du Flow serveur) entamerons une négociation pouvant 793. Description comportementale de l’ATL aboutir à l’utilisation de différents protocoles comme TCP ou SCTP, cette décision pouvant différer d’une négociation à l’autre. Si le Signalization Message Controler retourne une réponse négative, l’Autonomic Manager traduit le nom du Flow, CLTWEB (cf. 2.2.4.3), en (tcp, 80), indiquant qu’il doit utiliser le protocole TCP sur le port 80. 3.1.2.3 Application smart Dans le cas d’une application smart, le comportement sera le même que précé- demment, pour une application ATL-aware, à ceci près que l’application a la possibilité d’indiquer des contraintes supplémentaires à l’Autonomic Manager dans ses prises de décisions. Toute situation ne pouvant aboutir à cause de ces contraintes devra alors être reportée à l’application. En effet, en imposant des contraintes supplémentaires, l’application reprend en charge certaines responsabilités qui seraient assumées par l’Autonomic Manager dans le cas d’une application ATL-aware. Par exemple, une application imposant le cryptage des communications en utilisant TLS [Die08] recevra une erreur si aucun composant ne prenant en charge ce protocole n’est disponible sur le système. 3.1.3 Application serveur Le comportement décrit ici recouvre les cas où l’application est le serveur de la communication, c’est-à-dire qu’elle ouvre un point d’accès disponible pour les connexions entrantes — comme pour un serveur utilisant TCP — ou des messages émis depuis d’autres systèmes distants — comme dans le cas d’une application UDP uniquement réceptrice. 3.1.3.1 Application legacy Après avoir instancié un nouveau Flow, et comme côté client, on doit tout d’abord savoir si le système distant dispose de l’ATL. Cependant, cette fois, on ne dispose pas de l’adresse du client. Ainsi, les deux cas de figures suivants se présentent. 1. Le client (distant) dispose de l’ATL. Celui-ci a émis une requête de découverte afin de savoir si le serveur dispose de l’ATL. Celle-ci est récupérée par le Signalization Message Controler qui y répond positivement. Par la suite, le client contacte l’Autonomic Manager du Flow adéquat sur le serveur pour négocier le service composite. Le Flow dans lequel se situe cet Autonomic Manager est désigné par le nom de service qu’aura spécifié l’application cliente à l’ouverture de son TSAP (cf. 3.1.2.1). 803.1. Création d’un point d’accès au service de Transport 2. Le client ne dispose pas de l’ATL. Le premier message en provenance de celui-ci est alors récupéré et analysé par le multiplexeur-démultiplexeur situé entre les Flow et la couche réseau afin de déterminer le protocole de Transport utilisé par le client. Celui-ci doit normalement être le même que celui que nous a imposé l’application serveur lorsqu’elle a ouvert le TSAP. Ce TSAP correspond alors à un Flow notamment identifié par ce protocole de Transport et par un certain numéro de port. Le message sera alors dirigé vers le Flow identifié par le protocole de Transport et le numéro de port utilisés dans son en-tête. Dans le premier cas, la négociation a été engagée par le client afin de décider la partie distribuée du service composite à instancier, sur laquelle bâtir également la partie locale le cas échéant. Dans le second, on peut directement décider d’une composition locale basée sur le protocole demandé. 3.1.3.2 Application ATL-aware Le comportement est ici similaire au cas précédent, à la différence que, comme côté client pour une application ATL-aware (cf. 3.1.2.2), on ne dispose que des besoins en terme de services de l’application. Si on reprend les deux cas précédents, qui s’appliquent également ici, on remarque que rien ne change dans le premier de ces cas, mais que dans le second, le Flow de l’application serveur ne dispose pas d’un couple (protocole de Transport, n o de port) pour l’identifier — l’application utilisant un nom de service comme décrit dans 2.2.4.3. Dans le premier cas, le Flow vers lequel diriger le message de négociation de l’Autonomic Manager du client a été déterminé par ce nom de service. Dans le second, on ne dispose que du couple (protocole de Transport, no de port destination). La correspondance avec le nom de service du Flow auquel diriger ce message se trouve alors dans la table de traduction introduite en 2.2.4.3. 3.1.3.3 Application smart Comme côté client, deux cas se présentent ici : 1. si l’application a imposé le protocole à utiliser, le comportement sera le même que pour une application legacy ; 2. sinon, le comportement sera le même que pour une application ATL-aware. L’observation de cette dichotomie simple dans le cas d’une application serveur donne lieu à la classification alternative décrite à la section 3.1.4. 813. Description comportementale de l’ATL 3.1.4 Synthèse On remarque dans les deux sections précédentes que le comportement de l’ATL à la création d’un point d’accès au service de Transport est conditionné à deux paramètres indépendants, et donne donc lieu à quatre cas. Ces deux paramètres sont : 1. la connaissance que le système a de l’adresse IP du système distant avec lequel communiquer : – une application cliente connaît l’adresse IP du système distant, – une application serveur ne la connaît pas ; 2. le fait que l’application impose ou non le protocole de Transport à utiliser : – une application legacy l’impose, – une application aware ne l’impose pas, – une application smart peut ou non l’imposer. Quel que soit le cas, la première action à effectuer est bien évidemment d’instancier un Flow grâce au Flow Creator. Par la suite, les actions à mener vont donc être les suivantes. On dispose de l’adresse IP du système distant. Dans ce cas, la première action à effectuer est de lancer la procédure de découverte de l’ATL sur le système distant via le Signalization Message Controler. Si la réponse est positive, on peut immédiatement entamer une procédure de négociation du service à mettre en place. Sinon l’Autonomic Manager doit décider d’une composition utilisant des mécanismes protocolaires locaux, basée sur le protocole de Transport déterminé : – par l’application si celle-ci nous l’a imposé (comme le ferait une application legacy) ; – grâce à la table de traduction si l’application a seulement nommé le point d’accès au service de Transport (comme le ferait une application aware). On ne dispose pas de l’adresse IP du système distant. Dans ce cas on doit adopter un comportement « serveur » et attendre un message entrant afin de connaître l’identité du pair de la communication. Soit le premier message reçu est un message de négociation de service, et le système distant dispose donc de l’ATL. On dirige ce message vers le Flow identifié par le nom correspondant au nom de service véhiculé dans le message. On peut alors poursuivre avec lui la négociation. Soit le message reçu est un message de données et on déduit alors que le système distant ne dispose pas de l’ATL. On dirige alors le message vers le Flow correspondant au couple (protocole de Transport, no de port) du message entrant car le Flow est ainsi identifié par l’application ou via la table de traduction. On peut alors décider d’une composition locale. 823.2. Reconfiguration d’un Flow Dans tous les cas, une fois ces étapes effectuées, on peut instancier la composition et démarrer la communication. 3.2 Reconfiguration d’un Flow Une fois le service composite instancié et la communication établie, les conditions dans lesquelles ce service travaille peuvent varier. Ainsi non seulement les objectifs de qualité de service de l’application peuvent être modifiés par celle-ci, mais l’environnement réseau est par nature dynamique et peut donner lieu à des modifications importantes de ses caractéristiques, ne permettant plus à un service donné d’atteindre les objectifs pour lesquels il a été choisi. Dans une telle situation, la solution réclame la reconfiguration, plus ou moins en profondeur, du dit service. On observe principalement deux types de reconfiguration. 1. La première, dite reconfiguration « comportementale », consiste à ne pas modifier le service composite dans sa structure, c’est-à-dire, dans le cas de l’ATL, conserver les mêmes composants protocolaires, mais interviendra sur les paramètres de ces derniers afin d’altérer leur fonctionnement. Ainsi, modifier la valeur maximum que peut prendre le Retransmission Time Out (RTO) dans TCP constitue un exemple de reconfiguration comportementale. 2. La seconde est une reconfiguration dite « structurelle ». Celle-ci implique que la structure du service composite va être modifiée par l’ajout, la suppression ou le remplacement d’un ou plusieurs composants protocolaires. On peut par exemple ainsi décider de ne plus utiliser SCTP au cours d’une communication pour le remplacer par MPTCP, car l’apparition de middleboxes bloquerait alors SCTP. Cette section aborde la problématique de la reconfiguration en décrivant le comportement de l’ATL pour mener à bien les différents cas. 3.2.1 Déroulement d’une reconfiguration 3.2.1.1 Classification des cas de reconfiguration possibles Il existe deux cas de reconfiguration : – comportementale, où l’on modifie un ou plusieurs paramètres uniquement ; – structurelle, où l’on va modifier la composition en changeant un ou plusieurs composants protocolaires, ceci selon deux possibilités : – l’ajout ou le retrait des composants protocolaires concernés, – le déploiement de la nouvelle composition dans un nouveau Channel si la précédente méthode est impossible. 833. Description comportementale de l’ATL Le choix de l’une ou l’autre de ces deux possibilités peut par exemple être influencé par la manière dont on souhaite traiter les messages à retransmettre (cf. 3.3). Dans le troisième cas ci-dessus deux méthodes peuvent être utilisées pour dé- ployer la nouvelle composition : séquentielle ou parallèle. – Avec la première méthode, on déploie le nouveau Channel séquentiellement dans le temps. C’est-à-dire que l’Autonomic Manager va d’abord devoir attendre que le Channel courant ait terminé son exécution avant de la détruire puis de déployer le nouveau Channel. – La seconde méthode consiste à déployer et démarrer la nouvelle composition alors que la précédente finit son travail. Ainsi, les nouveaux envois de données passent par la nouvelle composition pendant que les retransmissions passent par l’ancienne. Ces deux méthodes sont opposées sur deux points : l’overhead temporel et l’utilisation mémoire. – Sur les systèmes très contraints en ressources, la méthode parallèle peut s’avérer coûteuse. – Cependant, la première présente l’inconvénient de devoir attendre la fin du premier Channel avant de démarrer le suivant. Si le premier instancie un service composite dont le temps d’arrêt est non déterministe, le coût en temps peut rapidement devenir trop important. 3.2.1.2 Suivi du plan de reconfiguration Toute reconfiguration se déroule en une succession d’étapes définies par le plan d’exécution qui a été décidé par la fonction de planification des Autonomic Manager selon leur organisation. Certaines étapes du plan nécessitent une synchronisation des deux Flow pour être effectuées. Afin de permettre l’adaptation à une grande variété d’actions possibles et à venir, notamment due à l’importante multiplicité des composants protocolaires et des versions de ceux-ci que permet l’ATL, le protocole de synchronisation des actions doit être le plus simple possible, laissant au plan lui-même le soin d’encapsuler la complexité. Ce type de décomposition de la complexité est déjà utilisé depuis longtemps pour la gestion de réseaux avec le protocole SNMP, possédant un nombre réduit de commandes génériques, et permettant d’aller interroger des bases de données spécifiques et potentiellement complexes, les Management Information Base (MIB) [Pre02]. Selon un principe similaire, nous proposons ici les messages suivant pour le protocole : 843.2. Reconfiguration d’un Flow – setPlan, permettant à l’Autonomic Manager décisionnaire d’imposer le plan à l’autre ; – nextStep, permettant à l’Autonomic Manager décisionnaire d’ordonner le passage à la réalisation de l’étape suivante à l’autre Autonomic Manager, celui-ci étant bloqué en attendant cet ordre ; – stepAck, permettant à un Autonomic Manager d’informer la réalisation d’une étape à l’autre Autonomic Manager. Le but de ces messages est uniquement de permettre la synchronisation d’étapes interdépendantes. Dans le cas d’Autonomic Manager collaboratifs (cf. 2.2.3.2), le plan n’est pas imposé par un Autonomic Manager sur l’autre, il est décidé par consensus. De la même manière, aucun n’autorise l’autre à passer à l’étape suivante, chacun informe l’autre de son état d’avancement dans la réalisation, et s’auto-débloque lorsqu’il le juge approprié. Ainsi le protocole reste générique en n’encodant absolument aucune des commandes spécifiques aux différents composants protocolaires utilisables par une ATL ou l’autre. Ces commandes sont indiquées dans le plan de reconfiguration, à chaque étape. La commande nextStep du protocole de reconfiguration permet donc de passer à la commande suivante à exécuter, quelle que soit celle-ci. Le protocole de reconfiguration devient ainsi scalable vis-à-vis du nombre de composants protocolaires possibles. La figure 3.5 montre le déroulement d’une reconfiguration dans le cas où un des deux Autonomic Manager orchestre l’opération. 3.2.1.3 Déroulement selon les cas Nous allons ici décrire le déroulement de chacun des quatre cas de reconfiguration : 1. comportemental ; 2. par ajout ou retrait d’un composant protocolaire dans un Channel existant ; 3. par déploiement d’un nouveau Channel en série ; 4. par déploiement d’un nouveau Channel en parallèle. Reconfiguration comportementale Le processus de décision distribué entre les Autonomic Manager a statué pour une reconfiguration comportementale, c’est- à-dire pour la reconfiguration d’un ou plusieurs paramètres au sein d’un ou plusieurs composants protocolaires du Channel en cours d’exécution. C’est à ce processus de décision de décider si les actions à entreprendre sur ces différents paramètres doivent respecter un certain ordre d’exécution s’il y en a plusieurs, pour des raisons de dépendance par exemple. 853. Description comportementale de l’ATL Figure 3.5: Suivi du plan de reconfiguration Chaque paramètre sera modifié via l’invocation d’une méthode appropriée du Channel Manager. Celui-ci, sur cet ordre, invoque la procédure de modification correspondante publiée par le composant à modifier. Nous pouvons ici remarquer qu’une modification de paramètre du point de vue des Autonomic Manager peut aboutir à une reconfiguration structurelle interne du composant protocolaire ciblé. En effet, si le composant est lui même un ensemble composite, sa composition représente un de ses paramètres. Modifier celle-ci revient à modifier ce paramètre, sans modifier la structure protocolaire du Channel, du point de vue de l’ATL, même s’il s’agit, du point de vue du composant concerné, d’une restructuration interne. L’utilisation d’ETP comme protocole au sein du Channel est un exemple de cette situation. En effet, modifier la composition du service interne d’ETP s’effectue en changeant le fichier de description de composition de ce service, donc via un changement de paramètre, du point de vue de l’Autonomic Manager. Cette modification va cependant initier une procédure de reconfiguration au sein d’ETP, 863.2. Reconfiguration d’un Flow qui possède un tel système de synchronisation avec l’entité ETP distante. Cette reconfiguration prenant du temps, il peut être nécessaire d’attendre qu’elle soit terminée avant d’effectuer l’action de reconfiguration (de niveau ATL) suivante. Retrait/ajout d’un composant protocolaire au sein d’un Channel existant Afin de modifier la composition protocolaire d’un Channel, par ajout et/ou retrait d’un composant, il est nécessaire de mettre ce Channel en pause le temps d’effectuer la modification. La première opération à effectuer sera donc le gel des Channel, à commencer par le Channel émetteur de données, puis par le récepteur. Si les deux Channel émettent chacun, alors ils doivent mettre en pause leur capacité d’émission mais toujours être capables de recevoir des données. Pour cela, les Channel Manager ont la possibilité d’ordonner le gel de la transmission des messages depuis les buffers vers le Channel concerné aux multiplexeurs/démultiplexeurs du Data Plan. Ceux-ci vont alors cesser de transmettre les messages depuis les buffers vers les Channel, permettant à ceux-ci de vider les messages en cours de traitement. Par la suite, les Autonomic Manager vont retirer ou ajouter les différents composants protocolaires prévus, éventuellement de manière synchronisée, via une méthode d’ajout ou de retrait fournie par le Channel Manager. Celui-ci retire le composant protocolaire concerné, ou insère une nouvelle instance du composant protocolaire demandé à l’emplacement désiré. Ces modifications effectuées, les Autonomic Manager synchronisent le redémarrage des capacités réceptrices de leurs Channel, puis, par la suite, leurs capacités émettrices, par le déblocage de l’activité des multiplexeurs/démultiplexeurs. Déploiement d’un nouveau Channel en série Cette opération consiste à déployer un service composite au sein d’un nouveau Channel après avoir détruit le Channel actuellement en cours d’exécution. Tout d’abord, les deux Autonomic Manager synchronisent l’arrêt de leur Channel respectif, en mettant la communication en pause, comme précédemment. A ce moment, les Channel doivent terminer leurs envois et éventuelles retransmissions. Afin que cette étape ne s’éternise pas au détriment de la QoS demandée, il est important que l’Autonomic Manager puisse signifier un temps maximum d’attente au delà duquel la destruction du Channel est effectuée, travail terminé ou non. Ce temps doit donc être calculé en fonction de l’impact négatif causé par un arrêt prématuré du Channel, et indiquant le moment ou cet impact est plus faible que celui causé par l’attente de l’arrêt total de celui-ci. Une fois le travail du Channel terminé (ou le temps d’attente maximal atteint), celui-ci est détruit par le Channel Manager, qui le remplace ensuite par un nouveau Channel, contenant le nouveau service composite. De manière synchrone 873. Description comportementale de l’ATL à nouveau, les deux Autonomic Manager vont redémarrer la communication, les messages étant alors traités par le nouveau Channel. Déploiement d’un nouveau Channel en parallèle Cette opération similaire à la précédente, déploie le nouveau Channel et le démarre en parallèle de l’ancien qui finit son travail. Chaque Autonomic Manager doit synchroniser le numéro de séquence à partir duquel les messages doivent transiter par le nouveau Channel, par exemple en l’incluant dans le plan de reconfiguration. Si le nouveau Channel n’est pas encore déployé de chaque côté alors que ces messages doivent être envoyés, ils doivent être mis en tampon dans les buffers en attendant le démarrage du Channel. Les Autonomic Manager doivent en parallèle gérer la création du dit nouveau Channel, puis, de manière synchrone, le démarrer. Tout nouveau message dont le numéro de séquence est supérieur au numéro de séquence limite doit être traité par ce nouveau Channel. L’ancien Channel continue pendant ce temps d’effectuer son travail, et donc les éventuelles retransmissions. Une fois le travail de celui-ci effectué, il est détruit. 3.3 Traitement des retransmissions lors des transitions Toute reconfiguration réclame une certaine continuité dans le service fourni. Pour cela, le nouveau service déployé doit démarrer dans un état correspondant à celui du service qu’il remplace, au moment de la prise de relai de ce dernier. Nous allons illustrer cette problématique dans cette partie à travers l’exemple de la retransmission de messages, initialement émis avant la reconfiguration mais dont la retransmission devrait être effectuée après celle-ci. Pour ceci, nous caractérisons l’environnement à un instant donné par la paire E = {B, C} où B représente l’ensemble des besoins en qualité de service demandés par l’application, et C les contraintes imposées par le réseau. Afin de répondre à cet environnement, l’ATL va mettre en place un service S correspondant. Tous les messages doivent-ils cependant transiter par le même service ? Un message est émis avec les besoins de l’application au moment où celle-ci le soumet à l’émission, mais avec les contraintes du moment où il est réellement transféré au réseau. Ceci signifie que l’environnement donné pour un message est défini en deux temps : les besoins B au moment où l’application le soumet à l’ATL, et les contraintes C par la suite lorsque l’ATL le retire des buffers pour le faire transiter dans le Channel. Ainsi, si les besoins correspondant à ce message ne vont pas varier entre la transmission initiale et la retransmission du message, 883.3. Traitement des retransmissions lors des transitions les contraintes peuvent, elles, différer entre ces deux instants, les conditions du réseaux étant dynamiques. Cas d’une retransmission idéale Nous discutons ici de la solution idéale à adopter, dans le cas de systèmes sans limite de ressources et où les temps de reconfiguration sont négligeables. Du paragraphe précédent, on déduit que ce sont les raisons du changement d’environnement qui vont conditionner le service qui servira à retransmettre les messages le nécessitant. Bien sûr, les messages dont la première émission prend place après la reconfiguration, seront retransmis (si tant est que le nouveau service le prévoit) par le nouveau service. Seuls sont concernés les messages initialement transmis par l’ancien service. Changement de besoins Avant reconfiguration, nous nous trouvons dans la situation E1 = {B1, C1}. Le changement de besoins modifie donc l’environnement en E2 = {B2, C1} les contraintes n’ayant pas changé. Les messages ayant été initialement transmis par le service S1, répondant à l’environnement E1, ont donc été soumis à l’émission par l’application durant l’environnement E1. Les besoins qui leur sont associés sont donc les besoins B1. Les contraintes n’ayant pas changé et étant toujours C1, ces messages, au moment de leur émissions correspondront toujours à l’environnement E1. Ils devraient donc dans l’idéal être retransmis avec l’ancien service, S1. Ceci est possible dans l’idéal, car le système, n’ayant pas de limite de ressources, peut déployer S2 en parallèle de S1. Changement de contraintes Avant reconfiguration, nous nous trouvons dans la situation E1 = {B1, C1}. Le changement de contraintes modifie donc l’environnement en E2 = {B1, C2} les besoins n’ayant pas changé. Les messages ayant été initialement transmis par le service S1, répondant à l’environnement E1, ont donc été soumis à l’émission par l’application durant l’environnement E1. Les besoins qui leur sont associés sont donc les besoins B1. Les besoins n’ayant pas changé et étant toujours B1, ces messages, au moment de leur émissions correspondront maintenant à l’environnement E2. Ils devraient donc dans l’idéal être retransmis avec l’ancien service, S2. On peut donc dans ce cas opter pour une reconfiguration par modification du service en place, le transformant de S1 à S2, l’ancien service n’ayant plus d’utilité. Changement de besoins et de contraintes Nous ne considérons ici que le changement de besoins et de contraintes peut-être simultané. Dans les faits, il peut 893. Description comportementale de l’ATL être considéré comme tel à cause de la latence induite par la fonction de Monitoring. Avant reconfiguration, nous nous trouvons dans la situation E1 = {B1, C1}. Le changement de situation modifie donc l’environnement en E2 = {B2, C2} les besoins et les contraintes ayant changé. Les messages ayant été initialement transmis par le service S1, répondant à l’environnement E1, ont donc été soumis à l’émission par l’application durant l’environnement E1. Les besoins qui leur sont associés sont donc les besoins B1. Les contraintes ont cette fois changé et sont à présent C2 ainsi ces messages, au moment de leur émission correspondront toujours à un environnement E3 = {B1, C2} pour lequel il n’existe pas de service. Ils devraient donc dans l’idéal être retransmis avec un service, S3 temporaire uniquement dédié à leur retransmission. Ceci est possible dans l’idéal, car le système, n’ayant pas de limite de ressources, peut déployer S3 en parallèle de S2 et détruire S1, devenu inutile, ou modifier ce dernier en S3 si possible. Considérations sur les cas réels Bien évidemment, les systèmes possèdent des limites et les temps de reconfiguration selon les réseaux considérés, ne pourront pas toujours être vus comme négligeables. Ainsi, ces trois solutions sont une simple base sur laquelle construire des prises de décisions plus poussées, prenant en compte des variables plus complexes. En effet, si le déploiement de deux services en parallèle est impossible, que faire de ces messages ? Doit-on les envoyer avec le nouveau service, et donc avec un service n’étant pas forcément parfaitement approprié ? Ou doit-on considérer leur retransmission d’une importance moindre dans le nouveau contexte et l’abandonner, tout en détruisant l’ancien service ? Ces questions ne sont que quelques exemples de la complexité de la question de la prise de décisions, centrale dans un système comme l’ATL. Ce thème de la décision réclame à lui seul un étude ultérieure poussée et exhaustive. 3.4 Conclusion Dans ce chapitre nous avons présenté le comportement des différents composants de l’ATL dans deux cas particuliers : l’ouverture d’un point d’accès et la reconfiguration d’un service au sein d’un Flow. Ceci nous a permis de mettre en lumière différents cas possibles en fonction des systèmes, des applications et des choix faits ou faisables par l’ATL, offrant ainsi tout un panel de solutions pour répondre à un maximum de situations. Nous avons ensuite, à travers l’exemple de la retransmission de messages, illustré la problématique de la transition d’un service à un autre et levé des interrogations concernant la complexité du système de décision que réclame un système tel que l’ATL. 90CHAPITRE 4 Expérimentations et mesures Dans ce chapitre, nous détaillons des expériences en simulation et émulation qui ont permis la mise en évidence de l’intérêt d’une solution tel que l’ATL, ainsi que son coût potentiel. Dans une première partie, nous décrivons une simulation dans laquelle nous combinons MPTCP avec différents mécanismes de fiabilité partielle afin de tirer partie des capacités multi-chemins du protocole à des fins d’amélioration d’une transmission vidéo. Cette simulation nous permet ainsi de confirmer l’intérêt de combiner un protocole donné avec des mécanismes externes afin de moduler le service offert par celui-ci. Dans une deuxième partie, nous décrivons une simulation dans laquelle un changement d’environnement survient en milieu de communication — une transmission vidéo — à laquelle le système réagit en modifiant la composition protocolaire, basée sur MPTCP. Les résultats sont ensuite comparés au cas témoin où la composition protocolaire reste inchangée, afin de montrer le bénéfice induit. Enfin, la troisième partie de ce chapitre présente une illustration du coût d’une solution telle que l’ATL, en étudiant le cas du protocole de synchronisation d’ETP, dont les similitudes architecturales avec l’ATL ont été montrées au chapitre 2. Sommaire 4.1 De la composabilité des protocoles . . . . . . . . . . . . . . . . 92 4.1.1 But de l’expérience . . . . . . . . . . . . . . . . . . . . 92 4.1.2 Description de l’expérience . . . . . . . . . . . . . . . . 93 4.1.3 Analyse des résultats . . . . . . . . . . . . . . . . . . . 97 4.1.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 101 4.2 De l’intérêt de l’adaptation dynamique . . . . . . . . . . . . . 102 4.2.1 But de l’expérience . . . . . . . . . . . . . . . . . . . . 103 914. Expérimentations et mesures 4.2.2 Description de l’expérience . . . . . . . . . . . . . . . . 103 4.2.3 Analyse des résultats . . . . . . . . . . . . . . . . . . . 104 4.2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 105 4.3 De l’overhead de la signalisation . . . . . . . . . . . . . . . . . 106 4.3.1 But de l’expérience . . . . . . . . . . . . . . . . . . . . 106 4.3.2 Description de l’expérience . . . . . . . . . . . . . . . . 107 4.3.3 Résultats attendus . . . . . . . . . . . . . . . . . . . . 114 4.3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . 116 4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 4.1 De la composabilité des protocoles Cette section du chapitre propose d’étudier l’intérêt de coupler protocoles existants et micro-protocoles afin de permettre une meilleure satisfaction des besoins en qualités de service de l’application, par rapport à l’utilisation du protocole seul. Pour ceci nous prenons l’exemple d’une application de streaming vidéo communiquant via un réseau de type 3G sur des terminaux comportant plusieurs interfaces. Afin d’en tirer parti, nous utilisons un protocole multi-domicilié, MPTCP, et le composons avec des mécanismes de fiabilité partielle. 4.1.1 But de l’expérience Le but de cette expérience est de démontrer l’intérêt de coupler des mécanismes protocolaires dédiés à certaines tâches, et génériques, afin d’être réutilisables, avec des protocoles standards. Le but n’est pas d’étudier l’efficacité d’une composition de tels mécanismes avec un protocole comme le fait l’ATL, par rapport à une inté- gration d’un mécanisme au sein d’un protocole particulier, mais d’étudier l’intérêt d’un tel couplage, quelle que soit la méthode retenue. MPTCP utilise les différentes interfaces présentes sur le système, de manière concurrente, afin d’augmenter la capacité réseau disponible et réduire le délai de transmission car, étant basé sur TCP, celui-ci est lié à cette capacité. Cependant, pour cette même raison, le service offert par MPTCP est parfaitement fiable et parfaitement ordonné, rendant ainsi ses avantages moins intéressants pour des applications de type streaming multimédia, qui peuvent tolérer une certaine quantité de pertes. Le but de cette expérience est de démontrer l’intérêt de combiner des microprotocoles de fiabilité partielle avec MPTCP, afin de tirer parti de ses avantages tout en améliorant la qualité de service envers des applications pour lesquelles ce protocole ne serait pas totalement adéquat. 924.1. De la composabilité des protocoles Le caractère générique, c’est-à-dire indépendant d’un protocole particulier, de ces micro-protocoles leur permet d’être associé à d’autres protocoles, potentiellement en cours de communication (cf. 4.2). Ceci permet ainsi de mettre en évidence l’utilité de l’ATL, afin de gérer ce type de situation de manière autonome. L’expérience est menée en simulation, grâce au simulateur ns-2. 4.1.2 Description de l’expérience 4.1.2.1 Choix de l’application L’application choisie est une application de vidéo interactive basée sur le codec H.264. Ce type d’application tolère un certain niveau de perte d’information, mais requiert un délai de transit borné : les paquets dont le délai dépasse 400 ms seront considérés comme obsolètes et inutiles. Pour simuler cette application, nous utilisons une vidéo de 400 images, encodées en YUV au format QCIF, soit une résolution de 176x144. La vidéo dure 13,6 s et est émise à un rythme de 30 images par seconde. Du côté du récepteur, l’adaptation effectuée consiste à écarter les paquets dont le délai a dépassé les 400 ms. La vidéo, encodée en H.264, est composée d’images de type I, P ou B. Images I : Ces images sont autonomes. Elles peuvent être décodées indépendamment des autres. Images P : Ces images encodent uniquement les informations qui ont été modi- fiées au sein de l’image par rapport à l’image I ou P précédente qu’elle prend pour référence. Ainsi, si une image I, ou P, est perdue, toutes les images P successives qui en dépendent seront mal décodées, provoquant des erreurs d’affichage. Images B : Ces images se basent sur le même principe que les images P mais utilisent en référence une image I ou P précédente et une image I ou P suivante. Ces images sont donc fortement dépendantes du décodage correct des autres images du flux. Ainsi, toutes les images ne revêtent pas la même importance au sein du flux vidéo. La perte d’une image B sera moins pénalisante que la perte d’une image P, elle-même moins handicapante que la perte d’une image I. Notons également que selon les choix à l’encodage de la vidéo, certaines images B peuvent également servir de référence, introduisant ainsi une hiérarchie à quatre niveaux et non plus trois. L’utilisation d’une interface spécifique de type IPMH permet l’assignation de différents niveaux de priorité à chaque message applicatif, permettant à MPTCP et aux micro-protocoles de différencier le traitement qui sera appliqué à chacun. 934. Expérimentations et mesures 4.1.2.2 Micro-protocoles utilisés Pour réaliser cette simulation, les mécanismes suivants ont été implémentés dans ns-2, au sein du modèle ns-2 de MPTCP, recommandé par le working group MPTCP de l’IETF [Nis]. Chacun de ces micro-protocoles implémente un concept de fiabilité partielle dans le but d’améliorer le délai de transit afin de correspondre aux exigences de l’application, en tirant parti de la tolérance aux pertes de celle-ci. Adaptation à l’émission : le Selective Discarding Le Selective Discarding a été introduit dans [LBL89] et permet une adaptation du flux à l’émission. Ce mécanisme consiste à éliminer les paquets de moindre importance lorsque le réseau est saturé. Grâce à l’interface, MPTCP peut récupérer les informations relatives à la priorité de chaque type d’image. En utilisant cette information, notre implémentation du Selective Discarding écarte systématiquement les images de type B avant leur émission, car ce sont les images les moins importantes. Nous nous attendons ainsi à avoir une qualité de service améliorée, car le non-envoi d’un paquet conduit à moins de congestion et donc de perte sur le réseau et également à un délai moindre pour les images I et P, qui sont les images les plus importantes pour le décodage de la vidéo du côté du récepteur. Adaptation à la réception : le Time-Constrained Partial Reliability L’autre implémentation réalisée du concept de fiabilité partielle intègre l’aspect temporel de la contrainte. Puisque MPTCP utilise plusieurs chemins pour accroître la capacité réseau disponible, le risque de paquets arrivant dans le désordre s’en trouve augmenté, ces chemins possédant des caractéristiques différentes. MPTCP offrant un service d’ordre total, celui-ci place en buffers les messages arrivant dans le désordre jusqu’à réception des paquets manquants, afin de délivrer le tout dans l’ordre à l’application. Ces paquets en attente peuvent devenir obsolètes à cause de l’attente des paquets en retard, alors qu’ils sont disponibles et pourraient être utiles à l’application. Ainsi, le mécanisme a pour but que ces paquets soient délivrés avant leur obsolescence, considérant les paquets en retard comme perdus et à présent inutiles, en acquittant leur perte auprès de l’émetteur. L’implémentation proposée calcule à tout instant le délai de transit applicatif des paquets dans les buffers de réception de l’hôte puits de la communication, c’est-à-dire le délai écoulé depuis leur soumission à l’émission par l’application émettrice. Lorsque ce délai se rapproche des 400 ms de délai maximum, les paquets concernés sont délivrés à l’application et les paquets manquants, considérés à présent obsolètes, sont déclarés perdus et acquittés auprès de l’émetteur, comme si ceux-ci avaient été correctement reçus. Ainsi, l’émetteur les croyant arrivés à 944.1. De la composabilité des protocoles destination ne les réémettra pas. Si ceux-ci arrivent par la suite, ils seront tout simplement écartés. Notons que la simulation permet d’éluder la question de la synchronisation des deux hôtes. En expérimentation réelles, celle-ci devrait être prise en compte via des solutions comme NTP [Mil10] ou toute autre solution offrant une précision appropriée. Le caractère du mécanisme protocolaire resterait alors local, mais sa dépendance envers un tel système de synchronisation, par nature distribué, rendrait la composition protocolaire globalement distribuée. Rappelons enfin que le but de cette expérience est d’étudier le couplage de mécanismes protocolaires avec un protocole standard, et non l’étude du mécanisme en lui-même. 4.1.2.3 Simulation Les deux mécanismes précédents permettent trois combinaisons : 1. MPTCP-SD qui couple MPTCP au Selective Discarding ; 2. MPTCP-PR qui couple MPTCP à la Time-Constrained Partial Reliability. 3. MPTCP-PR-SD qui couple MPTCP à la Time-Constrained Partial Reliability et au Selective Discarding. Chacune d’elles a été testée sur l’environnement conseillé par le working group MPTCP. Celui-ci est représenté figure 4.1. Figure 4.1: La topologie du réseau simulé La source, abrégée S, représente le système hébergeant l’application émettrice de données, et le puits, abrégé P, le système hébergeant l’application réceptrice. Les machines r1 à r4 sont des routeurs intermédiaires. Nous disposons ainsi de deux chemins distincts utilisables par MPTCP. Ces chemins sont donc : – S, a, r1, b, r3, c, P ; – S, d, r2, e, r4, f, P. 954. Expérimentations et mesures Afin d’évaluer les performances des différentes combinaisons de mécanismes avec MPTCP, nous simulons un transfert vidéo entre S et P. Les capacités des liens d’accès a, d, c et f ont été fixés soit à 1,8 Mbps, soit à 3,6 Mbps et les liens du cœur de réseau, b et e, sont fixés à 1 Mbps ou 0,5 Mbps. Ces valeurs ont été choisies proches de débits théoriques utilisables sur des liens WWAN HSDPA. Elles ont également été choisies afin de créer des situations dans lesquelles MPTCP devra réagir à un manque de capacité. Aucun trafic concurrent n’est injecté dans le réseau simulé. Les délais des différents liens ont été fixés à 5 ms ou 10 ms. Sept scénarios ont été définis, et sont résumés dans les tableaux 4.1 à 4.3. 1 2 a et c 3,6 Mbps; 10 ms 3,6 Mbps; 10 ms b et e 1 Mbps; 5 ms 1 Mbps; 5 ms d et f 3,6 Mbps; 10 ms 1,8 Mbps; 10 ms Congestion faible faible Table 4.1: Résumé des scénarios 1 et 2 3 4 5 a et c 3,6 Mbps; 5 ms 1,8 Mbps; 5 ms 1,8 Mbps; 10 ms b et e 0,5 Mbps; 5 ms 1 Mbps; 5 ms 0,5 Mbps; 5 ms d et f 3,6 Mbps; 5 ms 1,8 Mbps; 5 ms 1,8 Mbps; 10 ms Congestion moyenne moyenne moyenne Table 4.2: Résumé des scénarios 3 à 5 6 7 a et c 3,6 Mbps; 10 ms 1,8 Mbps; 10 ms b et e 0,5 Mbps; 5 ms 0,5 Mbps; 5 ms d et f 3,6 Mbps; 10 ms 1,8 Mbps; 10 ms Congestion forte forte Table 4.3: Résumé des scénarios 6 et 7 Métrique d’évaluation La qualité est évaluée selon un calcul par image du Peak Signal to Noise Ratio (PNSR). Nous utlisons Evalvid [KRW03], un ensemble d’outils permettant dévaluer la qualité d’une transmission vidéo sur réseaux réels ou simulés. Evalvid permet notamment la mesure de différents paramètres de QoS 964.1. De la composabilité des protocoles tels que le taux de perte ou le délai de bout en bout. Il existe une correspondance entre le PNSR et une autre métrique d’évaluation vidéo, subjective celle-ci, le Mean Opinion Score (MOS), résumée dans le tableau 4.4. PNSR (dB) MOS > 37 Excellent 31 à 37 Bon 25 à 31 Moyen 20 à 25 Faible < 20 Pauvre Table 4.4: Les correspondances entre PNSR et MOS 4.1.3 Analyse des résultats 4.1.3.1 Comparaison des performances de MPTCP avec TCP et UDP Dans cette partie, nous comparons la qualité vidéo, caractérisée par le PNSR, lorsque la transmission est effectuée avec MPTCP et lorsqu’elle est effectuée TCP ou avec UDP. Les calculs du PNSR sont effectués après réception des données et rejet de celles ayant un délai de transmission applicatif supérieur à 400 ms. Les tableaux 4.5 et 4.6 montrent les bénéfices engendrés sur le PNSR par l’utilisation de MPTCP. On peut remarquer que pour UDP et TCP, la colonne 2 est vide : comme deux chemins avec des caractéristiques différentes sont utilisés par MPTCP, la comparaison avec UDP ou TCP, tous deux mono-chemins, pour ces caractéristiques est effectuée dans les cas 1 et 5. Ces chemins sont utilisés dans les simulations 1 et 4 pour TCP et UDP. Le PNSR pour TCP est parfois à 0 dB car tous les paquets, dans ces situations, ont dépassé le délai maximum de 400 ms et ont ainsi été rejetés car considérés comme obsolètes. Scénario 1 2 3 4 UDP 13,98 14 4,27 TCP 4,66 4,64 0 MPTCP 24,96 25,59 22,88 22,51 Table 4.5: PNSR moyen en dB des simulations 1 à 4 Les tableaux 4.7 et 4.8 montrent que le délai est également globalement réduit grâce à l’utilisation de MPTCP. Les tableaux 4.9 et 4.10 montrent quant à eux l’apport de MPTCP sur le taux de pertes pour chaque type d’image. 974. Expérimentations et mesures Scénario 5 6 7 UDP 4,26 4,25 4,13 TCP 0 0 0 MPTCP 23,05 19,15 17,14 Table 4.6: PNSR moyen en dB des simulations 5 à 7 Scénario 1 2 3 4 UDP 432 475 474 TCP 419 481 465 MPTCP 334 346 296 358 Table 4.7: Délai moyen en millisecondes des simulations 1 à 4 Scénario 5 6 7 UDP 516 575 616 TCP 527 581 629 MPTCP 319 403 428 Table 4.8: Délai moyen en millisecondes des simulations 5 à 7 Scénario 1 2 3 4 I UDP 95,5 95,5 100 TCP 100 100 100 MPTCP 55,5 57,7 77,7 60 P UDP 71,9 73,03 92,13 TCP 23,59 23,59 100 MPTCP 6 5,61 14,6 11,2 B UDP 72,93 73,3 87,59 TCP 0,75 14,41 100 MPTCP 7,8 6,3 6,3 5,6 Table 4.9: Taux de pertes des simulations 1 à 4 4.1.3.2 Comparaison de MPTCP avec et sans mécanismes couplés Nous allons à présent comparer la qualité de la vidéo reçu via un transfert utilisant MPTCP et utilisant les différentes combinaisons de mécanismes : – MPTCP-SD ; – MPTCP-PR. La comparaison a été effectuée dans le cadre du scénario 4 décrit dans le tableaux 4.2. 984.1. De la composabilité des protocoles Scénario 5 6 7 I UDP 100 100 100 TCP 100 100 100 MPTCP 55,5 80 82,2 P UDP 89,88 93,25 96,62 TCP 100 100 100 MPTCP 11,2 15,7 16,8 B UDP 86,09 91,72 95,86 TCP 100 100 100 MPTCP 1,12 19,17 7,1 Table 4.10: Taux de pertes des simulations 5 à 7 Si les résultats décrits 4.1.3 nous ont permis d’évaluer les bénéfices de MPTCP par rapport à TCP ou UDP, nous pouvons remarquer sur la figure 4.2 que le PNSR moyen pour MPTCP est de 22,5 dB, montrant que la qualité moyenne de la vidéo n’est pas suffisante pour une utilisation confortable. En effet, le tableau 4.4 montre que le PNSR doit être supérieur à 25 dB pour avoir une qualité vidéo satisfaisante. On remarque également sur la figure 4.2 que le PNSR descend sous 22,5 dB pendant un temps prolongé, avant l’image no 200 et aux alentours de l’image no 300. Ces résultats se confirment à la visualisation de la vidéo reconstituée après réception, et motivent l’étude de la combinaison de MPTCP avec les mécanismes précédemment introduits. Les figures 4.3 et 4.4 montrent le PNSR image par image pour l’utilisation de MPTCP-PR et MPTCP-SD respectivement, dans le contexte du scénario 4. Nous remarquons immédiatement sur la figure 4.3 que le PNSR moyen obtenu est meilleur que celui observé avec MPTCP seul. En effet, celui-ci atteint à présent 24,74 dB. Cette moyenne est cependant toujours sous la barre des 25 dB, bien que proche. Nous pouvons cependant remarquer que plusieurs fois la vidéo reconstituée s’approche d’un PNSR de 35 db, ce qui est un très bon score. Malheureusement nous notons également des performances réduites durant la seconde moitié de la vidéo (entre la 230e et la 340e image). Ceci peut s’expliquer par la perte d’informations importantes, telle qu’une image I, déclarée perdue alors que celle-ci pouvait encore être utile, non plus pour son affichage, mais pour servir de référence pour des images P et B ultérieures. Ceci pourrait être amélioré en permettant un plus grand paramétrage du mécanisme, afin de moduler la date d’obsolescence en fonction du type de l’image, et non plus utiliser une date fixe. Malgré ce léger écueil, et bien que la différence dans les chiffres puisse sembler mineure (10 %), l’amélioration est nettement visible au visionnage et on s’approche d’une utilisation confortable. 994. Expérimentations et mesures Figure 4.2: PNSR par image en utilisant MPTCP, scénario 4 La figure 4.4 représente l’évolution du PNSR par image avec utilisation de MPTCP-SD. On voit ici que le PNSR moyen dépasse 25 dB, avec une valeur de 26,04 dB. Les oscillations sont dues au fait qu’à chaque image B, le PNSR chute, en raison du rejet systématique de celle-ci. Cependant, celui-ci étant plus élevé pour les images P et I, la moyenne s’en trouve relevée. Notons malgré tout une chute du PNSR aux alentours de la 200e image. Celleci est due à la perte d’une image I ou P servant donc de référence à plusieurs images qui la suivent. Celles-ci, ne pouvant se baser sur la bonne référence, seront décodées et affichées incorrectement, créant des différences trop fortes avec la vidéo d’origine, traduites par ce creux dans la courbe. 1004.1. De la composabilité des protocoles Figure 4.3: PNSR par image en utilisant MPTCP-PR, scénario 4 4.1.4 Conclusion L’expérience présente a permis de démontrer les gains en Qualité de Service que l’on peut obtenir via la combinaison de protocoles avec des mécanismes externes. Ces bénéfices pourraient encore être améliorés, notamment par l’optimisation des mécanismes, en permettant un paramétrage plus fin de ceux-ci par exemple. En effet, ici le Selective Discarding rejette systématiquement toute image de type B. Le même mécanisme pourrait être amélioré en permettant de modifier le taux de rejet pour chaque type d’image indépendamment ou en fonction des relations de dépendance d’une image à l’autre. Un paramétrage plus fin, cependant, requerrait une adaptation dynamique afin de pouvoir tirer au mieux parti de celui-ci. Ces décisions et adaptations ne peuvent pas être requises de la part de l’utilisateur, ni de l’application. En effet, cellesci sont trop complexes, et réclament une connaissance poussée du réseau et des protocoles. L’ATL pourrait cependant, parfaitement remplir ce rôle. La section 1014. Expérimentations et mesures Figure 4.4: PNSR par image en utilisant MPTCP-SD, scénario 4 suivante étudie ce type d’adaptation dynamique. 4.2 De l’intérêt de l’adaptation dynamique Dans cette deuxième partie, nous nous intéressons à l’effet de l’adaptation dynamique de la composition protocolaire, c’est-à-dire sa modification en cours de communication. Pour ceci, nous utilisons le même contexte que l’expérimentation précédente, en utilisant un nouveau mécanisme pour MPTCP : un load balancer chargé de répartir les paquets à envoyer sur les différents chemins possibles, en fonction de la priorité des messages et de la qualité de chaque chemin. 1024.2. De l’intérêt de l’adaptation dynamique 4.2.1 But de l’expérience Le but de cette expérience est de démontrer l’intérêt de procéder à des modi- fications structurelles de la composition protocolaire en cours de communication. En effet, les adaptations comportementales, i.e. les modifications de paramètres, existent déjà dans les protocoles actuels. par exemple, TCP adapte la taille de ses fenêtres de contrôle de congestion et de contrôle de flux, en fonction de l’état de congestion du réseau, et de la saturation du système récepteur des données. Ici, nous nous intéressons à l’adjonction d’un nouveau mécanisme à une composition protocolaire existante. Contrairement à la section 4.1, le mécanisme est pensé pour les protocoles multi-domiciliés. Ceci n’est pas contradictoire vis-à-vis de l’ATL. En effet, celle-ci est pensée pour accueillir des composants pouvant avoir des conditions de dépendance envers d’autres composants. Comme pour la section 4.1, l’expérience est réalisée en simulation, grâce au simulateur ns-2. 4.2.2 Description de l’expérience 4.2.2.1 Choix de l’application L’application choisie est la même que pour l’expérience précédente. Sa description peut donc être trouvée en 4.1.2.1. 4.2.2.2 Micro-protocoles Le mécanisme implémenté ici est un load-balancer, ou répartiteur de charge. Dans le contexte des protocoles multi-domiciliés, son rôle est de répartir les paquets sur les différents chemins. Dans MPTCP, il est appelé packet scheduler. Notre implémentation de ce répartiteur se base, comme pour les mécanismes précédents, sur la différence de priorité des différentes images. Notre implémentation va donc diriger les paquets sur l’un ou l’autre chemin en fonction de l’importance de chacun. Le but étant toujours de faire en sorte que les images les plus importantes aient le plus de chances d’arriver intactes à destination, le répartiteur va diriger les paquets vers le chemin le plus sûr pour les plus importants, et le moins sûr pour les moins importants. La notion de chemin sûr est ici à préciser. Celle-ci implique bien évidemment un monitoring du réseau constant permettant une modélisation de chaque chemin. Afin de définir ensuite le plus sûr, il faut décider selon quelles caractéristiques un chemin sera qualifié de sûr : son taux de congestion, sa capacité, son délai de transit. . . La répartition doit ensuite être décidée entre les différents niveaux de priorité qui peuvent être plus ou moins nombreux que le nombre de chemins. Un para- 1034. Expérimentations et mesures métrage plus fin peut même permettre de faire passer un certain pourcentage de chaque priorité sur chaque chemin. Dans notre implémentation et pour cette expérience, les images I et P sont dirigées vers le meilleur chemin, les images B vers le moins bon. 4.2.2.3 Simulation L’environnement réseau employé est le même qu’en 4.1 et est donc représenté sur la figure 4.1. De même, nous utilisons le PNSR comme mesure de la qualité de service. Deux environnements différents ont été définis. ils sont résumés dans le tableau 4.11. 1 2 a et c 1,8 Mbps; 10 ms 1 Mbps; 10 ms b et e 1 Mbps; 5 ms 1 Mbps; 5 ms d et f 3,6 Mbps; 10 ms 3,6 Mbps; 10 ms Table 4.11: Résumé des scénarios Pour chacun de ces scénarios, nous avons simuler le transfert de la vidéo en utilisant MPTCP et MPTCP couplé à notre load-balancer, indiqué si après MPTCPLB, afin de déterminer quelle composition obtient les meilleures performances pour chaque environnement. Dans un second temps, nous avons effectué la simulation du transfert avec modification de l’environnement. A mi-chemin du transfert, l’environnement change de 1 vers 2, et la composition protocolaire s’adapte en conséquence. Nous pouvons ainsi déterminer l’apport de la reconfiguration dynamique par rapport à un transfert qui emploierait le même protocole de bout en bout, comme c’est le cas actuellement. 4.2.3 Analyse des résultats La première série de simulation compare MPTCP et MPTCP-LB sur chacun des deux environnements. Le tableau 4.12 résume ces résultats. Simulation 1 2 MPTCP 25,59 21,75 MPTCP-LB 24,56 24,20 Table 4.12: PNSR en dB 1044.2. De l’intérêt de l’adaptation dynamique Nous pouvons voir que sur le premier environnement, le PNSR obtenu avec MPTCP est meilleur que ce lui obtenu avec MPTCP-LB. En effet, les deux chemins étant très similaires, le répartiteur de charge ne peut exprimer pleinement son potentiel, et la répartition classique effectuée par MPTCP mène à de meilleurs résultats. Cependant, dans le second environnement, nous pouvons remarquer que les bénéfices du load-balancer peuvent s’exprimer, en raison de la grande dissimilarité des chemins. Ces résultats nous poussent à nous poser la question suivante : quels bénéfices pourrait-on tirer de l’activation dynamique du load-balancer selon la différence de caractéristiques entre les chemins ? Cette simulation reprend les caractéristiques de l’environnement no 1 puis, au milieu du transfert, change les conditions pour celles de l’environnement no 2. Dans cet environnement changeant, nous effectuons deux simulations. La première avec MPTCP seul, et la seconde en intégrant dynamiquement notre répartiteur de charge lors du changement d’environnement, celui-ci donnant de meilleures performances globales dans ces nouvelles conditions. Les résultats obtenus sont indiqués dans le tableau 4.13. Simulation MPTCP seul MPTCP puis MPTCP-LB PNSR 21,77 22,56 Table 4.13: PNSR obtenu sans et avec adaptation dynamique Nous pouvons remarquer une amélioration de 0,79 dB grâce à l’intégration dynamique du load-balancer. Cette valeur amène les commentaires suivants. 1. Ce bénéfice, si petit soit-il, est-il significatif, particulièrement pour un PNSR d’environ 21 dB? En effet, en dessous de 25 dB la qualité vidéo doit être améliorée. Cependant, le visionnage de la vidéo nous permet déjà d’observer une amélioration. 2. Ces améliorations sont obtenues dans le cas idéal où le changement de composition protocolaire s’effectue sans délai par rapport au changement d’environnement. Le problème du coût de cette adaptation en conditions réelles se pose donc et doit être évalué. 4.2.4 Conclusion Dans cette section, l’expérience menée a permis de mettre en évidence les bé- néfices qui peuvent être apportés par une adaptation dynamique de la composition protocolaire vis-à-vis du contexte. Ces bénéfices sont cependant à mettre en perspective du déroulement de la simulation : en effet celle-ci met en place un cas 1054. Expérimentations et mesures idéal dans lequel le temps d’adaptation au contexte est nul. Les bénéfices seront probablement donc moindres en situation réelle. Le paramétrage du mécanisme utilisé ici, cependant, et comme dans la section 4.1, devrait pouvoir être modifiable, afin de décider quelle proportion de chaque type d’image doit passer par chaque chemin. La décision de recomposition et le paramétrage doivent alors être pris en charge par un système de décision et de gestion autonome tel que l’ATL. Celui-ci devra également, dans ses décisions, prendre en compte les modifications de performances induites par le temps de reconfiguration. La section suivante s’intéresse aux temps de reconfiguration. 4.3 De l’overhead de la signalisation La troisième partie de ce chapitre étudie le coût de la signalisation sur le déroulement de la communication. En effet parmi les différentes fonctionnalités de l’ATL, certaines requièrent une synchronisation entre les deux pairs de la communication. Afin d’accomplir cette synchronisation, il est nécessaire d’avoir des échanges de messages de contrôle entre les Autonomic Manager. Cette section tente d’évaluer l’impact des échanges de signalisation liés à la reconfiguration comme décrite en section 3.2. 4.3.1 But de l’expérience Cette expérience a pour but de déterminer le coût induit par les besoins en signalisation. Pour ce faire, nous utilisons ETP comme framework de composition protocolaire. En effet, la structure d’ETP étant proche de celle de l’ATL, ce dernier pouvant être vu comme un Data Plan d’un point de vu structurel, son protocole de signalisation pour la négociation initiale et la recomposition dynamique peut être utilisé comme base de réflexion sur le coût de ces actions. En effet, la simple adjonction d’un Autonomic Manager à ETP permettrait de lui conférer toutes les caractéristique d’un Flow comme l’accueil et la composition de composants protocolaires ou le multiplexage de plusieurs Channel. ETP est capable d’accueillir des composants appelés Processing Modules. Ceuxci sont une décomposition des micro-protocoles qui prennent place au sein du framework. Afin de déployer les compositions à mettre en place, ETP intègre un protocole de synchronisation permettant aux deux entités pairs de négocier la composition à mettre en place. Afin de permettre sa reconfiguration dynamique, ETP intègre un système de déploiement correspondant au schéma de reconfiguration structurelle en parallèle décrit en 3.2.1.3. Celui-ci est accompagné d’une variation du protocole de synchronisation initiale permettant la reconfiguration. 1064.3. De l’overhead de la signalisation Nous utilisons donc ETP comme base de réflexion sur le coût de la signalisation dans le cadre de l’ATL, celle-ci étant proche structurellement nous permettant d’avoir une évaluation du coût de la signalisation liée à la reconfiguration. 4.3.2 Description de l’expérience 4.3.2.1 Plateforme de test L’expérience est ici réalisée en émulation, sur la plateforme laasNetExp hé- bergée au LAAS-CNRS. Celle-ci implémente une topologie représentée en figure 4.5. Figure 4.5: La topologie utilisée pour les tests L’accès aux différents systèmes se fait via la machine pong1. Celle-ci peut ensuite commander les différents hôtes présents sur le réseau via le réseau de commande 10.107.2.0. L’hôte pong2 accueille l’application source de données et pong4 l’application puits. Ces deux applications communiquent via les interfaces adressées 10.108.2.2 pour pong2 et 10.109.2.4 pour pong4, et à travers pong3, jouant le rôle de routeur et instanciant un émulateur de réseaux, netem. Celui-ci permet de modifier le comportement aux interfaces du système, afin de mettre en place un délai, un taux de perte, des duplications et les lois de probabilité régissant l’apparition de ces évènements. 1074. Expérimentations et mesures Les définitions de ces paramètres et leur modification dynamique, ainsi que les démarrages des applications puits et source sont centralisés sur pong1, qui utilise le réseau de commande pour effectuer ces actions. 4.3.2.2 Protocoles de signalisation ETP possède deux protocoles de signalisation pour la gestion structurelle de la composition protocolaire. Le premier est utilisé pour la synchronisation initiale et le second pour la reconfiguration. Synchronisation Cas d’utilisation Le protocole de synchronisation tient compte de plusieurs paramètres. Afin de l’établir, plusieurs cas d’utilisation ont été définis et sont représentés sur la figure 4.6. Figure 4.6: Cas d’utilisation du protocole de synchronisation d’ETP ETP ne possède pas de notion de client ou de serveur. A la place, la différence de comportement s’effectue en fonction du rôle de l’application en tant qu’émetteur ou récepteur de données. Ce caractère est identifiable par les options utilisées à 1084.3. De l’overhead de la signalisation l’ouverture du socket ETP. En effet, une application désirant émettre des données devra indiquer l’adresse IP à laquelle elle souhaite envoyer ces données. L’application est alors identifiée comme émettrice par ETP. Afin de simplifier la modélisation du protocole de synchronisation, nous considérons la communication comme unidirectionnelle. Une application source, uniquement émettrice de données, souhaite envoyer des messages à une application puits, uniquement réceptrice. Le second paramètre important est celui du caractère local ou distribué de la composition protocolaire. La composition qui est échangée entre deux entités ETP, est détaillée et précise exactement quel Processing Module doit prendre place dans quel conteneur, et à quel niveau de la pile de module hébergée par ce conteneur. Avec ETP, l’application a la charge de la gestion du protocole. C’est donc elle qui doit définir cette composition de Processing Modules. Ainsi, une application souhaitant un service de Transport n’assurant que le minimum, à l’instar d’UDP, demandera une composition vide, n’instanciant aucun micro-protocole et donc aucun module. Une telle composition est donc considérée comme nulle. Dans le cas contraire, deux cas peuvent se poser. En effet, certains micro-protocoles nécessitent l’instanciation de Processing Modules de part et d’autre de la communication, et sont dits distribués. D’autres en revanche ne nécessitent de module que sur l’émetteur, ou sur le récepteur, et sont dits locaux. Si une composition comporte au moins un micro-protocole distribué, celle-ci est également dite distribuée. Un système d’acquittement sélectif est un exemple d’un tel micro-protocole. En effet, les acquittements ont besoin d’être envoyés par le récepteur et traités par l’émetteur, impliquant un besoin de modules de chaque côté de la communication. Si une composition ne comporte que des micro-protocoles locaux, celle-ci est dite locale également. Un traffic shaper n’utilisant aucune information explicitement donnée par le récepteur est un exemple de micro-protocole local. Les sept cas d’utilisation représentés sur la figure 4.6 prennent en compte les combinaisons de ces différents paramètres afin de déterminer le comportement du protocole. Cette liste ne se veut pas exhaustive, l’hypothèse d’une communication unidirectionnelle étant déjà restrictive, mais a pour but d’offrir une réflexion suffisamment complète permettant de dériver les autres cas de ceux présents ici. Nous présentons le cas Distributed Sender Based utilisé dans cette expérience. En effet, comme décrit en 4.3.2.3, la présente expérience est basée sur une précé- dente étude dans laquelle ce type de déploiement est le plus adapté. Composition distribuée à la source, nulle au puits Le diagramme de la figure 4.7 décrit les échanges de messages entre les entités source et puits de la 1094. Expérimentations et mesures Figure 4.7: Diagramme de séquence du cas d’utilisation Distributed Sender Based communication, lorsque la source prévoit l’utilisation d’une composition distribuée et le puits d’une composition nulle. A la création du socket ETP, l’application source renseigne le protocole sur les coordonnées du puits et lui passe la composition micro-protocolaire à utiliser. Celleci est analysée par ETP et s’avère être distribuée, donc doit être communiquée à l’entité réceptrice. Cette dernière est prête à recevoir des messages. En effet lorsque l’application puits a ouvert son socket, celle-ci a précisé l’utilisation d’une composition nulle. L’entité ETP réceptrice est donc immédiatement disponible. L’entité ETP émettrice va ainsi envoyer une proposition contenant la composition distribuée. L’entité réceptrice la déploie immédiatement après réception. En effet, cette dernière n’ayant aucune composition déployée peut déployer celle demandée sans conflit avec une composition déjà existante. Après déploiement, celui-ci est acquitté auprès de l’émetteur, qui effectue à son tour le déploiement. En effet, si le récepteur avait eu un conflit entre la proposition de l’émetteur et sa propre composition, il aurait dû effectuer une contre-proposition. Attendre la ré- ponse du récepteur avant déploiement permet ainsi d’éviter un double déploiement par l’émetteur en cas de contre-proposition de la part du récepteur. 1104.3. De l’overhead de la signalisation Une fois la composition instanciée de chaque côté, la communication peut commencer. Reconfiguration La reconfiguration au sein d’ETP utilise le protocole de synchronisation existant. Ce denier se déclenche lors de la demande d’émission du premier message. Le but du protocole de reconfiguration est donc de préparer ETP à effectuer une seconde synchronisation, c’est-à-dire, comme évoqué précé- demment, de préparer un déploiement en parallèle d’une nouvelle composition. La figure 4.8 montre le déroulement de cet échange. Figure 4.8: Préparation à la reconfiguration L’échange se fait en deux temps. Lorsqu’une application, qu’il s’agisse de la source ou du puits, décide de changer la composition utilisée, l’entitée ETP associée envoie à son pair un message indiquant qu’il doit se préparer à un changement de configuration. Une fois la nouvelle composition prête à être mise en place, un acquittement est envoyé vers l’initiateur de l’échange qui peut se préparer à son tour. 1114. Expérimentations et mesures Par la suite, une synchronisation sera effectuée dans le cadre de cette nouvelle structure d’accueil, qui instanciera la nouvelle composition en parallèle de la précédente. Estimation du temps de synchronisation D’après les spécifications précé- dentes, on peut établir une première estimation du temps de synchronisation en fonction du RTT, donc du délai du réseau. Dans le cas d’étude décrit en 4.3.2.2, on remarque que l’échange se compose uniquement d’un message de proposition et de son acquittement, créant donc un RTT de délai. De plus, chaque système doit déployer la composition. Le système récepteur, cependant, effectue son dé- ploiement entre la réception de la composition et l’émission de son acquittement ce qui, en toute rigueur, l’inclue dans le RTT. Enfin nous admettons que les temps de déploiement sur chacun des hôtes sont équivalents car : – les systèmes utilisés dans le cadre de cette expérience sont les mêmes ; – le temps de déploiement est supposé être court, voire négligeable, face au délai du réseau. Le temps de synchronisation est donc estimé à : Ts = RT T + Td (4.1) où Ts représente le temps de synchronisation et Td le temps de déploiement d’une composition sur un système. Une reconfiguration demande tout d’abord sa préparation, décrite en 4.3.2.2, puis une synchronisation de la nouvelle composition. Le temps d’une reconfiguration sera donc : Tr = Tp + Ts (4.2) où Tr est le temps de reconfiguration total et Tp est le temps préparation. Or : Tp = RT T (4.3) ce qui nous permet de conclure que le temps total de reconfiguration Tr devrait s’exprimer ainsi : Tr = 2RT T + Td (4.4) 4.3.2.3 Protocole expérimental L’expérience réalisée est basée sur des mesures réalisées dans [VW09]. Un transfert de cinq minutes est réalisé, entre une application source située sur la machine 1124.3. De l’overhead de la signalisation pong2 et une application puits située sur pong4, via pong3, émulant le réseau. Ce transfert doit respecter les objectifs de qualité de service suivant : – délai maximum de 150 ms; – taux de pertes maximum de 10 %. Durant ce transfert, chaque minute, les taux de pertes et délai de l’environnement réseau sont modifiés. Les travaux réalisés dans [VW09] associent à chaque environnement, une composition protocolaire pour ETP ayant la plus forte probabilité de respecter ces objectifs en qualité de service. La succession de contextes réseau et les compositions associées sont résumées sur la figure 4.9. Figure 4.9: Caractéristiques des cinq environnements réseau et compositions associées Description des compositions EMPTY : La composition EMPTY représente une composition « vide », ce qui dans le cas spécifique d’ETP correspond à offrir un service équivalent à celui d’UDP. SACK-FR : Le Selective Acknowledgement with Full Reliability (SACK-FR), est un mécanisme de contrôle des pertes par acquittements sélectifs, équivalent à l’option SACK utilisée par le protocole TCP [Mat96]. Le mécanisme SACK disponible dans ETP permet un paramétrage du taux de pertes maximum acceptable. Nous l’utilisons ici avec une tolérance de 0 %, interdisant donc toute perte. A-EC : L’Autonomic Error Control (A-EC) adjoint un gestionnaire autonome au SACK permettant de modifier à la volée la tolérance aux pertes en fonction d’un double objectif de taux de pertes maximum d’une part et de délai de transit maximum d’autre part, tentant d’équilibrer au mieux ces deux critères. TFRC : Le mécanisme TFRC, pour TCP Friendly Rate Control, offre une implémentation pour ETP de l’algorithme TFRC [Flo08]. 1134. Expérimentations et mesures Le premier environnement, par exemple, est caractérisé par un taux de perte de 5 % et un délai de transit de 10 ms. La composition associée est une composition vide, les caractéristiques du réseau étant conformes aux objectifs en qualité de service. Après la première minute de simulation, l’environnement est modifié avec un taux de perte de 10 % et un délai de transit de 100 ms. La composition associée est alors l’A-EC, un système de reprise des pertes basé sur des acquittements sélectifs à fiabilité partielle. L’expérience originale considérait la reconfiguration comme immédiate, les deux compositions étant déployées en même temps sur chaque système. Cependant, un temps de monitoring et de décision de 5 s était déjà présent, seul le déploiement de ces décisions étant alors considéré comme immédiat. Le but de notre expérience est d’introduire le protocole de reconfiguration, afin de prendre en compte le temps de reconfiguration Tr effectif et de mesurer son impact sur les performances. 4.3.3 Résultats attendus Les résultats attendus par l’expérience ont été extrapolés à partir des résultats originaux. Pendant le temps de monitoring de l’expérience originale, l’ancien service continue de fonctionner sur le nouvel environnement. Nous avons appliqué une régression sur ce laps de temps, et l’avons étendu durant Tr après le monitoring. Taux de pertes La première métrique observée est le taux de pertes. Celuici a été mesuré au niveau de l’environnement réseau, et au dessus du service de Transport. Ainsi, nous pouvons observer l’impact du système de reconfiguration sur les performances du système. La figure 4.10 montre l’évolution du taux de pertes mesuré au niveau du réseau tout au long de l’expérience. On remarquera sur la courbe 4.11 que le taux de pertes observé reste globalement sous la barre demandée des 10 %. L’introduction du système de reconfiguration ne modifie d’ailleurs que partiellement les résultats obtenus lors de l’expérience originale, comme observé sur la courbe 4.12. En effet seul un court pic de pertes supplémentaire lors de la dernière recon- figuration est introduit dans les nouveaux résultats. Celui-ci semble être un effet de bord de notre méthode de prédiction, dû à l’application de la régression sur l’échelon observé vers 230 s, et ne devrait donc pas apparaître en situation réelle. Délai La seconde métrique observée est le délai de transit des paquets. Comme pour le taux de pertes, celui-ci a été mesuré au niveau de l’environnement et du service de Transport afin d’observer l’impact du système de reconfiguration sur les performances. 1144.3. De l’overhead de la signalisation Figure 4.10: Taux de pertes de l’environnement Comme pour le taux de pertes, le délai est peu impacté par le système de reconfiguration. Les prévisions de résultats de la courbe 4.14 n’indiquent en effet aucune différence par rapport aux résultats de l’expérience originale vus sur la courbe 4.15. Analyse Ces résultats étaient prévisibles. En effet, l’expérience originale pré- voyait un temps de monitoring et de prise de décision assez long de 5 s, devant lequel les 200 ms de déploiement maximum du système de reconfiguration sont faibles. L’overhead induit est donc négligeable. Un temps de reconfiguration total long comme celui-ci est cependant acceptable du point de vue de l’ATL. En effet, une telle reconfiguration n’aura lieu qu’initiée par l’Autonomic Manager. Or, les décisions de ce dernier ont trait à la gestion de la communication, le contrôle étant laissé à la charge des composants protocolaires ; les actions de gestion sont de plus entreprises avec une granularité temporelle longue. L’impact sur les performances, induit par cette reconfiguration sera donc 1154. Expérimentations et mesures Figure 4.11: Taux de pertes vu par le service de Transport suffisamment espacé dans le temps pour limiter la dégradation moyenne à long terme de la communication. 4.3.4 Conclusion Dans cette section nous avons observé le comportement du protocole de synchronisation d’ETP dont les caractéristiques structurelles sont proches de l’ATL. Celui-ci nous permet d’observer une tendance des dégradations de performances induites dans des systèmes tels que l’ATL. Bien que les résultats soient prometteurs, ceux-ci devront être testés sur un prototype réel, et étendus afin d’observer plus en détails les relations entre temps de reconfiguration et fréquence de reconfiguration, les variations en fonction de type d’environnement ou l’impact des caractéristiques du réseau sur une reconfiguration donnée. Ce type d’observations nous permettra alors d’enrichir la connaissance des Autonomic Manager de l’ATL afin de leur permettre un choix plus fin dans les multiples décisions auxquelles ils auront à faire face. En effet, les décisions prises 1164.4. Conclusion Figure 4.12: Taux de pertes vu par le service sans système de reconfiguration dans un contexte idéal peuvent avoir à être modifiées en fonction du contexte réel. L’étude des relations entre les différentes métriques et les différentes situations permettront de prendre ces cas en compte. 4.4 Conclusion Ce chapitre a montré par l’expérience l’intérêt que peut avoir un système tel que l’ATL. La première partie se base sur MPTCP pour montrer l’intérêt de composer des micro-protocoles avec des protocoles existants afin d’élargir le service offert par ces derniers sans nécessairement les modifier. Elle a en outre permis de mettre en avant le besoin d’autonomie dans la prise de décisions concernant la configuration et le paramétrage de chaque composant, celui-ci se révélant bien trop lourd pour l’utilisateur ou l’administrateur au cas par cas. La deuxième partie étend la première en introduisant le concept d’adaptation structurelle dynamique. En effet, ici la composition protocolaire change en cours 1174. Expérimentations et mesures Figure 4.13: Délai induit par l’environnement de communication pour s’adapter aux variations de l’environnement. Les gains tirés de cette adaptation étant positifs, nous remarquons tout de même que de tels changements sont complexes et doivent se faire sans intervention extérieure à la couche de Transport, ce qui implique à nouveau un besoin d’autonomie. La troisième partie se concentre sur le coût d’un système de reconfiguration. En effet, un système comme l’ATL doit disposer d’un protocole de signalisation adéquat permettant la reconfiguration dynamique. L’expérience ayant été soumise à des difficultés, les résultats présentés sont déduits du modèle théorique du coût du protocole de signalisation. On observe que ces résultats sont acceptables et permettent de respecter la qualité de service demandée par l’application. Des expériences plus poussées seront nécessaires sur un prototype concret de l’ATL, afin notamment d’observer les limites de celui-ci ainsi que les améliorations à y apporter. Celles-ci devront être complètes et poussées afin d’observer les effets de toutes les interactions possibles des multiples paramètres pouvant varier dans un système de cette complexité. 1184.4. Conclusion Figure 4.14: Délai vu par le service 1194. Expérimentations et mesures Figure 4.15: Délai vu par le service sans système de reconfiguration 120Conclusion générale Rappel des contributions La thèse soutenue dans ce manuscrit part du constat que l’évolution majeure de l’Internet, de ses applications, des équipements terminaux et des réseaux physiques sous jacents, ont conduit à une multiplication des propositions d’évolution ou d’adaptation des protocoles de Transport. Le chapitre 1 a décrit ce contexte et en a déduit cinq points de problématique relatifs à la complexité de choix et d’utilisation des protocoles, à la configurabilité des protocoles, à l’extensibilité des protocoles, à l’assujetissement des applications aux solutions protocolaires et au déploiement de nouveaux protocoles. Ces différents problèmes nous ont ensuite conduits à analyser les limites des solutions de Transport actuelles face au contexte moderne et de poser les bases d’une redéfinition de la couche Transport, l’Autonomic Transport Layer (ATL). L’approche soutenue est que cette dernière doit offrir aux applications supportées des points d’accès génériques leur permettant de requérir des services et non des solutions protocolaires. Les services requis sont ensuite réalisés via une composition protocolaire dont le choix revient à l’ATL de manière autonome et dynamique. Une telle couche Transport de ce type permet également l’intégration progressive et transparente de nouvelles solutions protocolaires ainsi que la combinaison de plusieurs mécanismes en un seul service composite afin de satisfaire le plus finement possible les souhaits exprimés par l’application. Le chapitre 2 a posé les bases de la structure de l’ATL. Tout d’abord, nous avons posé les objectifs du système et les paradigmes des architectures orientées service et basées composants sur lesquels reposent la construction de l’ATL. Nous avons ensuite défini une classification concernant les types d’actions à considérer (gestion, contrôle et données), les applications à prendre en compte (legacy, ATLaware et smart) et les systèmes avec lesquels interagir (legacy et ATL-enabled). Ces classifications nous ont contraint dans la construction de l’ATL pour à aboutir une solution complète pouvant s’intégrer de manière transparente dans le paysage actuel tout en permettant une évolution future souple. Le rôle des différents com- 121Conclusion générale posants constituant l’ATL ainsi que leur organisation les uns par rapport aux autres ont finalement été décrits. Le chapitre 3 a complété la description établie dans le chapitre 2 en détaillant le comportement des différents éléments de l’ATL dans deux cas d’utilisations particuliers. Le premier cas d’utilisation concerne l’ouverture d’un point d’accès au service de Transport. Ce type d’action diffère de l’ouverture d’un socket classique. Il doit en effet prendre en compte le fait que l’application l’effectuant ainsi que l’application distante à contacter peuvent être legacy, ATL-aware ou smart et que cette dernière peut être hébergée sur un système legacy ou ATL-enabled. Nous avons décrit les différentes phases de découverte et de négociation des services qui doivent avoir lieu pour mettre en place le service composite adéquat. Dans le second cas d’utilisation, nous avons décrit le comportement de l’ATL lors d’un changement de contexte en cours de communication. Le redéploiement du service composite durant le transfert des données pose en effet des problèmes de continuité du service rendu et du coût de ce changement. Nous avons clos le chapitre par des considérations sur la traduction de l’état de l’ancien service vers le nouveau en prenant l’exemple de la problématique de retransmission des messages initialement émis avant une reconfiguration. Le chapitre 4 a présenté différents résultats obtenus au cours d’expériences menées en simulation et en émulation. La première expérience, menée en simulation, a combiné Multipath TCP (MPTCP) à des mécanismes génériques orientées QoS afin d’améliorer la qualité d’un transfert vidéo interactif en altérant le comportement du protocole sans modifier l’implémentation de celui-ci. Par cette expérience, nous avons cherché à démontrer l’intérêt de l’utilisation de services composites utilisant des mécanismes génériques avec des protocoles traditionnels. Les résultats étant prometteurs, nous avons poursuivi ce travail par de nouvelles simulations portant sur l’adaptation dynamique de tels services. Le but était ici de montrer le gain perçu par le changement de composition en réponse aux changements de conditions réseaux en cours de communication. Les gains induits nous ont amené à nous interroger sur le coût induit par la signalisation inhérente à de telles actions. La troisième expérience a tenté d’établir une estimation de ce coût en observant l’impact du protocole de synchronisation utilisé dans le contexte d’une implémentation d’un protocole (ETP) aux principes proches de l’ATL. Cette étude a permis de conclure que ce coût était négligeable face à la fréquence faible de mise en œuvre des actions de gestion pour lesquelles cette signalisation est nécessaire. Perspectives De nombreuses perspectives de travail peuvent être envisagées à partir du travail décrit dans ce document. Nous les décrivons ci-après. 122Flux collaboratifs La première possibilité d’extension de ce travail consiste à l’intégrer dans la problématique des flux collaboratifs. Ce concept consiste à établir une hiérarchie d’importance dans les différents flux au sein d’une machine voire d’un réseau que plusieurs flux partagent, afin que chacun se fixe potentiellement une borne supé- rieure sur différents critères de qualité de service. Prenons l’exemple d’un réseau local domestique sur lequel un ordinateur de bureau télécharge via BitTorrent la dernière version d’un système Linux pendant qu’un ordinateur de salon diffuse un film obtenu en vidéo à la demande sur un service de streaming. Actuellement, le risque est que les différents flux BitTorrent non seulement saturent le flux entrant de l’ordinateur qui effectue le téléchargement, mais saturent également l’accès Internet de tout le réseau domestique, dégradant du même coup le visionnage en streaming. Le fait d’utiliser le paradigme de l’Autonomic Computing pour gérer chaque flux permet d’exposer une interface de contrôle similaire à celle exposée par le Touchpoint afin de diriger l’Autonomic Manager (cf. 2.2.3.2). Cette interface, notamment utilisée par les applications smart ou les applications de gestion réservées aux utilisateurs et administrateurs du système, permettrait également à un Autonomic Manager hiérarchiquement supérieur d’exprimer des préférences découlant d’une priorisation des flux sur la machine mais également sur le réseau. D’une telle utilisation de cette interface découlerait alors une répartition automatique des ressources réseau afin de donner la priorité à certains flux sur les différents critères de qualité de service. Dans notre exemple, le téléchargement pourrait automatiquement se limiter afin de permettre aux autres applications s’exécutant sur l’ordinateur d’avoir accès au réseau, mais également au flux vidéo d’être diffusé sans accroc. On peut également imaginer que de telles mesures puissent être mises en œuvre par des Autonomic Manager dont la responsabilité se porte sur la gestion de l’énergie du système, par exemple. M2M Le LAAS-CNRS et notamment le groupe SARA, travaille sur les problé- matiques de communication entre objets intelligents, en particulier dans le contexte du machine to machine, ou M2M, dans lequel la problématique des flux collaboratifs peut s’avérer prometteuse. En effet un réseau domestique faisant cohabiter des systèmes tels que les ordinateurs actuels, des capteurs et des robots, pourrait avantageusement tirer parti d’une répartition dynamique des ressources selon les flux. 123Conclusion générale Implémentation Dans le chapitre 4 nous avons mentionné l’absence de prototype de l’ATL comme première limite aux expérimentations possibles. Cette limite doit être levée. Un travail de précision du modèle dans une optique d’implémentation est obligatoire et prioritaire si nous voulons faire de l’ATL un projet sur lequel mener des études approfondies sur des problématiques complexes. Ce travail doit respecter deux objectifs. Le premier est un objectif de recherche. L’implémentation de l’ATL doit respecter son caractère modulable afin de permettre l’étude séparée de chacune de ses fonctionnalités et son influence sur les autres sans modification de ces dernières. Ainsi, l’étude de la prise de décision de la fonction de Planning au sein de l’Autonomic Manager pourrait être menée en parallèle de celle sur le Monitoring, chaque étude ne modifiant que la fonctionnalité sur laquelle elle porte sans devoir se préoccuper de l’autre. Le second objectif porte sur les performances et l’adoption du modèle. En effet, afin que celui-ci gagne en visibilité et qu’il suscite l’intérêt dans la communauté internationale, l’implémentation du modèle doit être faite de manière réaliste. Le prototype doit donc être spécifié et implémenté dans le but d’intégrer parfaitement un système d’exploitation comme un projet de production et pas uniquement d’étude. Motiver l’intérêt et l’adoption permettra d’ouvrir ce projet et favorisera la collaboration avec d’autres équipes ce qui lui apportera un poids supplémentaire et multipliera les études à son sujet. Décision et sécurité La prise de décision et la sécurité de l’ATL sont les deux études principales à mener. Nous avons vu au sein de ce document que le nombre de paramètres qui doivent être pris en compte dans les décisions de chaque Autonomic Manager peut être important. Une étude poussée sur l’incidence de ces paramètres sur les performances s’avère ainsi pertinente. Le système et l’algorithme de décision en lui-même, sujets non abordés dans le présent document, sont également des points indispensables à étudier et définir afin de donner une réalité à l’ATL. La sécurité représente l’autre point essentiel. Si l’ATL veut devenir un modèle valable, elle ne peut se permettre de représenter une faille dans un système d’exploitation. La sécurisation de l’architecture et des échanges qu’elle effectue ainsi que sa tolérance aux fautes représentent donc deux axes d’étude majeurs qui doivent être pris en compte afin de permettre à l’ATL d’évoluer et devenir un modèle dont la réalisation et l’intégration dans le paysage informatique se concrétiseraient. 124ANNEXE A Publications de l’auteur A.1 Revue internationale avec actes et comité de lecture [1] C. Diop, G. Dugué, C. Chassot, E. Exposito, and J. Gomez. Qosaware and autonomic-oriented multipath tcp extensions for mobile and multimedia applications. International Journal of Pervasive Computing and Communications, 8(4) :306–328, 2012. A.2 Conférences et workshop internationaux avec actes et comité de lecture [2] C. Diop, G. Dugué, C. Chassot, and E. Exposito. Qos-aware multipath-tcp extensions for mobile and multimedia applications. In 10th International Conferences on Advances in Mobile Computing and Multimedia (MoMM 2011), MoMM ’11, pages 139–146, New York, NY, USA, 2011. ACM. [3] C. Diop, G. Dugué, C. Chassot, and E. Exposito. Qos-oriented mptcp extensions for multimedia multi-homed systems. In 2nd International Workshop on Protocols and Applications with Multi-Homing Support (PAMS 2012), WAINA ’12, pages 1119–1124, Washington, DC, USA, 2012. IEEE Computer Society. [4] G. Dugué, C. Diop, C. Chassot, and E. Exposito. Towards autonomic multipath transport for infotainment-like systems. In 3rd IEEE 125A. Publications de l’auteur International Workshop on Smart Communications in Network Technologies (SaCoNeT 2012), pages 6453–6457, June 2012. [5] C. Diop, J. Gomez-Montalvo, G. Dugué, C. Chassot, and E. Exposito. Towards a semantic and mptcp-based autonomic transport protocol for mobile and multimedia applications. In 3rd International Conference on Multimedia Computing and Systems, May 10-12, 2012 (ICMCS 2012), pages 496–501, May 2012. [6] G. Dugué, M. Oulmahdi, and C. Chassot. Design principles of a service-oriented and component-based autonomic transport layer. In 4th Track on Adaptive and Reconfigurable Service-oriented and component-based Applications and Architectures, June 2014. [7] M. Oulmahdi, G. Dugué, and C. Chassot. Towards a service-oriented and component-based transport layer. In IEEE 5th International Conference on Smart Communications in Network Technologies (SaCoNeT 2014), June 2014. 126Acronymes A-EC Autonomic Error Control. AC Autonomic Computing. API Application Programming Interface. ATL Autonomic Transport Layer. CTP Configurable Transport Protocol. DCCP Datagram Congestion Control Protocol. ETP Enhanced Transport Protocol. MPTCP Multipath TCP. PNSR Peak Signal to Noise Ratio. QoS Qualité de Service (Quality of Service). SACK Selective Acknowledgement. SACK-FR Selective Acknowledgement with Full Reliability. SCTP Stream Control Transmission Protocol. TCP Transmission Control Protocol. Tng Transport Next Generation. UDP User Datagram Protocol. 127Bibliographie [AGM+10] Mohammad Alizadeh, Albert Greenberg, David A. Maltz, Jitendra Padhye, Parveen Patel, Balaji Prabhakar, Sudipta Sengupta, and Murari Sridharan. Data center tcp (dctcp). SIGCOMM Comput. Commun. Rev., 40(4) :63–74, August 2010. [BP95] L.S. Brakmo and L.L. Peterson. Tcp vegas : end to end congestion avoidance on a global internet. Selected Areas in Communications, IEEE Journal on, 13(8) :1465–1480, 1995. [BWH+07] Patrick G. Bridges, Gary T. Wong, Matti Hiltunen, Richard D. Schlichting, and Matthew J. Barrick. A configurable and extensible transport protocol. IEEE/ACM Trans. Netw., 15(6) :1254–1265, December 2007. [Car02] B. Carpenter. Middleboxes : Taxonomy and Issues. RFC 3234, RFC Editor, February 2002. [CF04] Carlo Caini and Rosario Firrincieli. Tcp hybla : a tcp enhancement for heterogeneous networks. INTERNATIONAL JOURNAL OF SATELLITE COMMUNICATIONS AND NETWORKING, 22, 2004. [Con94] Connolly, T. and Amer, P. and Conrad, P. An Extension to TCP : Partial Order Service. RFC 1693, RFC Editor, November 1994. Obsoleted by RFC 6247. [DABR12] Thomas Dreibholz, Hakim Adhari, Martin Becke, and Erwin Paul Rathgeb. Simulation and Experimental Evaluation of Multipath Congestion Control Strategies. In Proceedings of the 2nd International Workshop on Protocols and Applications with Multi-Homing Support (PAMS), Fukuoka/Japan, March 2012. ISBN 978-0-7695-4652-0. [DBA13] Thomas Dreibholz, Martin Becke, and Hakim Adhari. SCTP Socket API Extensions for Concurrent Multipath Transfer. Internet Draft Version 06, IETF, Network Working Group, July 2013. draft-dreibholztsvwg-sctpsocket-multipath-06.txt, work in progress. 129Bibliographie [Die08] Dierks, T. and Rescorla, E. The Transport Layer Security (TLS) Protocol Version 1.2. RFC 5246, RFC Editor, August 2008. [Egg11] Eggert, L. Moving the Undeployed TCP Extensions RFC 1072, RFC 1106, RFC 1110, RFC 1145, RFC 1146, RFC 1379, RFC 1644, and RFC 1693 to Historic Status. RFC 6247, RFC Editor, May 2011. [ETS13] ETSI. Digital video broadcasting (dvb) ; second generation framing structure, channel coding and modulation systems for broadcasting, interactive services, news gathering and other broadband satellite applications (dvb-s2). Technical report, European Telecommunications Standards Institute, March 2013. [Exp03] Ernesto Exposito. Specification and implementation of a QoS oriented transport protocol for multimedia applications. PhD thesis, Université de Toulouse, Institut National Polytechnique de Toulouse, 2003. [FI08] Bryan Ford and Janardhan Iyengar. Breaking up the transport logjam. In In HOTNETS, 2008. [Flo03] Floyd, S. HighSpeed TCP for Large Congestion Windows. RFC 3649, RFC Editor, December 2003. [Flo06a] Floyd, S. and Kohler, E. Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 2 : TCP-like Congestion Control. RFC 4341, RFC Editor, March 2006. [Flo06b] Floyd, S. and Kohler, E. and Padhye, J. Profile for Datagram Congestion Control Protocol (DCCP) Congestion Control ID 3 : TCPFriendly Rate Control (TFRC). RFC 4342, RFC Editor, March 2006. [Flo07] Floyd, S. and Kohler, E. TCP Friendly Rate Control (TFRC) : The Small-Packet (SP) Variant. RFC 4828, RFC Editor, April 2007. [Flo08] Floyd, S. and Handley, M. and Padhye, J. and Widmer, J. TCP Friendly Rate Control (TFRC) : Protocol Specification. RFC 5348, RFC Editor, September 2008. [Flo09] Floyd, S. and Kohler, E. Profile for Datagram Congestion Control Protocol (DCCP) Congestion ID 4 : TCP-Friendly Rate Control for Small Packets (TFRC-SP). RFC 5622, RFC Editor, August 2009. [For11] Ford, A. and Raiciu, C. and Handley, M. and Barre, S. and Iyengar, J. Architectural Guidelines for Multipath TCP Development. RFC 6182, RFC Editor, March 2011. [Fox89] Fox, R. TCP Big Window and Nak Options. RFC 1106, RFC Editor, June 1989. Obsoleted by RFC 6247. 130Bibliographie [GMPG00] T. Goff, J. Moronski, D.S. Phatak, and V. Gupta. Freeze-tcp : a true end-to-end tcp enhancement mechanism for mobile environments. In INFOCOM 2000. Nineteenth Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings. IEEE, volume 3, pages 1537–1545 vol.3, 2000. [Hen12] Henderson, T. and Floyd, S. and Gurtov, A. and Nishida, Y. The NewReno Modification to TCP’s Fast Recovery Algorithm. RFC 6582, RFC Editor, April 2012. [HRX08] Sangtae Ha, Injong Rhee, and Lisong Xu. Cubic : a new tcp-friendly high-speed tcp variant. SIGOPS Oper. Syst. Rev., 42(5) :64–74, July 2008. [IEE12a] IEEE. Ieee standard for ethernet. IEEE Std 802.3-2012 (Revision to IEEE Std 802.3-2008), pages 1–0, 2012. [IEE12b] IEEE. Ieee standard for information technology – telecommunications and information exchange between systems local and metropolitan area networks – specific requirements part 11 : Wireless lan medium access control (mac) and physical layer (phy) specifications. IEEE Std 802.11- 2012 (Revision of IEEE Std 802.11-2007), pages 1–2793, 2012. [ITU99a] ITU. G.992.1 : Asymmetric digital subscriber line (adsl) transceivers. Technical report, International Telecommunication Union, July 1999. [ITU99b] ITU. G.992.2 : Splitterless asymmetric digital subscriber line (adsl) transceivers. Technical report, International Telecommunication Union, July 1999. [ITU07] ITU. G.707 : Network node interface for the synchronous digital hierarchy (sdh). Technical report, International Telecommunication Union, January 2007. [ITU11a] ITU. G.1010 : End-user multimedia qos categories. Technical report, International Telecommunication Union, January 2011. [ITU11b] ITU. G.993.2 : Very high speed digital subscriber line transceivers 2 (vdsl2). Technical report, International Telecommunication Union, December 2011. [Jac88] Jacobson, V. and Braden, A. TCP Extensions for Long-Delay Paths. RFC 1072, RFC Editor, October 1988. Obsoleted by RFC 1323, RFC 2018, RFC 6247. [Kho06] Kholer, E. and Handley, M. and Floyd, S. Datagram Congestion Control Protocol (DCCP). RFC 4340, RFC Editor, March 2006. 131Bibliographie [KRW03] Jirka Klaue, Berthold Rathke, and Adam Wolisz. Evalvid - a framework for video transmission and quality evaluation. In In Proc. of the 13th International Conference on Modelling Techniques and Tools for Computer Performance Evaluation, pages 255–272, 2003. [LBL89] M.M. Lara-Barron and G.B. Lockhart. Selective discarding procedure for improved tolerance to missing voice packets. Electronics Letters, 25(19) :1269–1271, Sept 1989. [Mat96] Mathis, M. and Mahdavi, J. and Floyd, S. and Romanow, A. TCP Selective Acknowledgment Options. RFC 2018, RFC Editor, October 1996. [Mil10] Mills, D. and Martin, J. and Burbank, J. and Kasch, W. Network Time Protocol Version 4 : Protocol and Algorithms Specification. RFC 5905, RFC Editor, June 2010. [Nag84] J. Nagel. Congestion Control in IP/TCP Internetworks. RFC 896, RFC Editor, January 1984. [Nis] Yoshifumi Nishida. Ns2 implementation for mtcp. https://code. google.com/p/multipath-tcp/. [Phe12] Phelan, T. and Fairhurst, G. and Perkins, C. DCCP-UDP : A Datagram Congestion Control Protocol UDP Encapsulation for NAT Traversal. RFC 6773, RFC Editor, November 2012. [Pos80] J. Postel. User Datagram Protocol. RFC 768, RFC Editor, August 1980. [Pos81] J. Postel. Transmission Control Protocol. RFC 793, RFC Editor, September 1981. [Pre02] Presuhn, R. and Case, J. and McCloghrie, K. and Rose, M. and Waldbusser, S. Management Information Base (MIB) for the Simple Network Management Protocol (SNMP). RFC 3418, RFC Editor, December 2002. [Sch13] Scharf, M. and Ford, A. Multipath TCP (MPTCP) Application Interface Considerations. RFC 6897, RFC Editor, March 2013. [STBT08] M. Sridharan, K. Tan, D. Bansal, and D. Thaler. Compound TCP : A New TCP Congestion Control for High-Speed and Long Distance Networks. Internet Draft Version 02, IETF, Network Working Group, November 2008. draft-sridharan-tcpm-ctcp-02.txt, expired. 132Bibliographie [Ste04] Stewart, R. and Ramalho, M. and Xie, Q. and Tuexen, M. and Conrad, P. Stream Control Transmission Protocol (SCTP) Partial Reliability Extension. RFC 3758, RFC Editor, May 2004. [Ste07] Stewart, R. and Ed. Stream Control Transmission Protocol. RFC 4960, RFC Editor, September 2007. [VW09] Nicolas Van Wambeke. Une approche pour la composition autonome de services de communication orientés QoS. PhD thesis, Université de Toulouse, 2009. [WJLH06] D.X. Wei, Cheng Jin, S.H. Low, and S. Hegde. Fast tcp : Motivation, architecture, algorithms, performance. Networking, IEEE/ACM Transactions on, 14(6) :1246–1259, 2006. [XHR04] Lisong Xu, K. Harfoush, and Injong Rhee. Binary increase congestion control (bic) for fast long-distance networks. In INFOCOM 2004. Twenty-third AnnualJoint Conference of the IEEE Computer and Communications Societies, volume 4, pages 2514–2524 vol.4, 2004. 133 Gestion de la variabilit´e et automatisation des processus de d´eveloppement logiciel Emmanuelle Rouill´e To cite this version: Emmanuelle Rouill´e. Gestion de la variabilit´e et automatisation des processus de d´eveloppement logiciel. Software Engineering. Universit´e Rennes 1, 2014. French. . HAL Id: tel-01061129 https://tel.archives-ouvertes.fr/tel-01061129 Submitted on 5 Sep 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.ANNÉE 2014 THÈSE / UNIVERSITÉ DE RENNES 1 sous le sceau de l’Université Européenne de Bretagne pour le grade de DOCTEUR DE L’UNIVERSITÉ DE RENNES 1 Mention : Informatique École doctorale Matisse présentée par Emmanuelle ROUILLÉ préparée à l’unité de recherche IRISA – UMR6074 Institut de Recherche en Informatique et Systèmes Aléatoires Gestion de la variabilité et automatisation des processus de développement logiciel Thèse soutenue à Rennes le 16 avril 2014 devant le jury composé de : Marie-Pierre GERVAIS Professeur à l’Université de Paris Ouest Nanterre La Défense / Présidente Pierre-Alain MULLER Professeur à l’Université de Haute-Alsace / Rapporteur Bernard COULETTE Professeur à l’Université de Toulouse II - Le Mirail / Rapporteur Reda BENDRAOU Maître de Conférence à l’Université Pierre et Marie Curie / Examinateur Benoit COMBEMALE Maître de Conférence à l’Université de Rennes 1 / Examinateur Olivier BARAIS Maître de Conférence à l’Université de Rennes 1 / Examinateur David TOUZET Architecte logiciel chez Sodifrance / Examinateur Jean-Marc JÉZÉQUEL Professeur à l’Université de Rennes 1 / Directeur de thèseRemerciements Je remercie le Professeur Bernard Coulette et le Professeur Pierre-Alain Muller d’avoir rapporté ce manuscrit, ainsi que pour leurs retours ayant permis de l’améliorer. Je les remercie également d’avoir fait partie de mon jury de thèse. Je remercie le Professeur Marie-Pierre Gervais d’avoir accepté de présider à ma soutenance, et je remercie le Docteur Reda Bendraou d’avoir examiné mes travaux. Merci à Jean-Marc Jézéquel d’avoir dirigé et également permis cette thèse. Un grand merci à Benoît Combemale, Olivier Barais, David Touzet, et à travers ce dernier Sodifrance, pour m’avoir encadrée, pour leur disponibilité, leur investissement et les nombreux conseils qu’ils m’ont prodigués. Merci à tous les collègues de DiverSE et de Sodifrance pour les discussions intéressantes et tous les bons moments partagés ensemble. Enfin, merci à ma famille, Clément, mes parents, pour leur présence et leur soutien.Résumé De nombreux outils ont été proposés par la communauté du génie logiciel afin de faire face à la complexité des logiciels et des projets de développement logiciel. À titre d’illustration, les systèmes de contrôle de version permettent de gérer les difficultés liées au travail collaboratif et géographiquement distribué, les outils de compilation, de test ou d’intégration continue supportent les méthodes de développement agiles, les IDE (Integrated Development Environments) permettent d’intégrer les différentes technologies utilisées sur un projet, etc. Ces outils sont d’autant plus nombreux qu’il en existent des version différentes, afin de satisfaire les besoins spécifiques à chaque projet. Par exemple des IDE différents peuvent être utilisés en fonction du langage de programmation utilisé. L’utilisation de tous ces outils est cependant à l’origine de nombreuses tâches manuelles répétitives, sources d’erreurs et coûteuses en temps. L’automatisation de ces tâches est un moyen de gagner en productivité. Mais la difficulté est de réutiliser des automatisations de tâches manuelles répétitives. En effet, toutes les automatisations ne sont pas forcément utiles pour tous les projets et elles peuvent avoir des dépendances avec d’autres tâches réalisées pendant un projet. De plus, une automatisation peut être utilisée dans des cas différents, c’est-à-dire dans des projets différents ou à des moments différents d’un même projet. Les défis sont donc de déterminer les projets et les moments d’un projet pour lesquels une automatisation doit être réutilisée, ainsi que de créer des automatisations réutilisables à travers leurs différents cas d’utilisation. Afin de répondre à ces défis, la contribution principale de cette thèse est une approche pilotant la réutilisation des automatisations de tâches manuelles répétitives par les processus de développement logiciel, où un processus de développement logiciel décrit les étapes à réaliser pour mener à bien un projet de développement logiciel. Cette approche consiste à capitaliser sur un ensemble de processus et à réutiliser des processus de cet ensemble en fonction des exigences des projets. Elle s’appuie sur une première sous-contribution, à savoir une approche permettant de réutiliser les processus indépendamment du formalisme utilisé pour les définir. L’approche principale consiste également à lier des automatisations de tâches manuelles répétitives aux étapes d’un ensemble de processus qu’elles automatisent. Ce lien permet de savoir quelles automatisations utiliser pour un projet donné et quand. L’approche principale s’appuie également sur une deuxième sous-contribution, à savoir une méthodologie fournissant un support à la création d’automatisations réutilisables à travers leurs différents cas d’utilisation. Dans cette méthodologie, le lien entre les processus et les automatisations est utilisé afin d’expliciter les différents cas d’utilisation de ces dernières et de créer des automatisations réutilisables. Afin de démontrer la faisabilité de l’approche proposée dans cette thèse, nous proposons un outillage la supportant. Cet outillage a été appliqué a deux cas d’utilisation : une famille de processus industriels de développement Java ainsi qu’une famille de processus consistant à définir et outiller un langage de modélisation.Table des matières 1 Introduction 5 1.1 La prolifération des outils de développement logiciel . . . . . . . . . . . 5 1.2 Le défi : réutiliser des automatisations de tâches manuelles récurrentes . 6 1.3 Contributions de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.4 Contexte de réalisation de la thèse . . . . . . . . . . . . . . . . . . . . . . 8 1.5 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 I Contexte scientifique 11 2 Background 15 2.1 L’ingénierie dirigée par les modèles (IDM) . . . . . . . . . . . . . . . . . 15 2.2 Les processus de développement logiciel . . . . . . . . . . . . . . . . . . 17 2.2.1 Introduction aux processus de développement logiciel . . . . . . 17 2.2.2 Modélisation des processus de développement logiciel avec SPEM 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.3 L’ingénierie des lignes de produits logiciels . . . . . . . . . . . . . . . . . 23 2.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.3.2 CVL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3 État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus 35 3.1 Support à la réutilisation des processus sans spécification de leur variabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.1.1 Identification du processus correspondant à un projet . . . . . . . 38 3.1.2 Réutilisation de processus définis en extension . . . . . . . . . . . 40 3.1.3 Les patrons de processus . . . . . . . . . . . . . . . . . . . . . . . 40 3.2 Ingénierie des lignes de processus . . . . . . . . . . . . . . . . . . . . . . 42 3.2.1 Utilisation des mécanismes d’un langage . . . . . . . . . . . . . . 43 3.2.2 Extension d’un langage de modélisation de processus . . . . . . . 44 3.2.2.1 Utilisation de processus agrégats . . . . . . . . . . . . . 44 3.2.2.2 Modification d’un processus de base . . . . . . . . . . . 46 12 TABLE DES MATIÈRES 3.2.2.3 Spécification des points de variation et des variantes d’un processus . . . . . . . . . . . . . . . . . . . . . . . . 47 3.2.2.4 Configuration de processus par composition . . . . . . . 49 3.2.2.5 Association de plusieurs techniques . . . . . . . . . . . . 50 3.2.3 Transformation en une structure pivot . . . . . . . . . . . . . . . . 50 3.2.4 Spécification de la variabilité sans réutilisation automatique . . . 51 3.2.5 Synthèse sur l’ingénierie des lignes de processus . . . . . . . . . . 52 3.3 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 II Automatisation des tâches manuelles récurrentes pilotée par les processus de développement logiciel 63 4 Gestion de la variabilité dans les processus 67 4.1 Exemple illustratif : une famille de processus de métamodélisation . . . 67 4.2 Approche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.2.1 Définition de la ligne de processus de développement logiciel . . 72 4.2.1.1 Méthodologie pour la modélisation des éléments de processus (étape 1) . . . . . . . . . . . . . . . . . . . . . . 72 4.2.1.2 Spécification de la variabilité des exigences des projets (étape 2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.2.1.3 Liaison entre les exigences des projets et les processus (étape 3) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.2.2 Dérivation d’un processus en fonction des exigences d’un projet 78 4.2.2.1 Résolution de la variabilité des exigences des projets (étape 4) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.2.2.2 Dérivation automatique de processus (étape 5) . . . . . 78 4.2.3 Exécution d’un processus résolu . . . . . . . . . . . . . . . . . . . 79 4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.3.1 Capacité de CVL à gérer la variabilité des processus en fonction de la variabilité des exigences des projets . . . . . . . . . . . . . . 80 4.3.2 Indépendance de CVL vis-à-vis des métamodèles de processus . 80 4.3.3 Validité du modèle de processus résolu . . . . . . . . . . . . . . . 80 4.3.4 Extension possible à la méthodologie pour modéliser le processus de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84 5 Création de composants d’automatisation réutilisables 85 5.1 Exemple illustratif : automatisation de la configuration de l’espace de travail local d’un développeur . . . . . . . . . . . . . . . . . . . . . . . . . 85 5.2 La méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5.2.1 Définition d’une ligne de processus de développement logiciel (étape 1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.2.1.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . 90TABLE DES MATIÈRES 3 5.2.1.2 Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.2.2 Spécification des composants d’automatisation (étape 2) . . . . . 91 5.2.2.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . 91 5.2.2.2 Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.2.3 Liaison entre les CA et leurs contextes d’utilisation (étape 3) . . . 92 5.2.3.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . 92 5.2.3.2 Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.2.4 Conception des composants d’automatisation (étape 4) . . . . . . 93 5.2.4.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . 93 5.2.4.2 Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.2.5 Implémentation des composants d’automatisation (étape 5) . . . 95 5.2.5.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . . 95 5.2.5.2 Illustration . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.3.1 Bénéfices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.3.2 Une limitation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.3.3 Un inconvénient . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.4 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 III Outillage et application 101 6 Outil pour la gestion de la variabilité et l’automatisation des processus 105 6.1 Exemples de tâches manuelles récurrentes . . . . . . . . . . . . . . . . . . 105 6.2 Vue générale de l’outil . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 6.2.1 Définition d’une ligne de processus . . . . . . . . . . . . . . . . . 109 6.2.2 Définition des CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 6.2.3 Dérivation d’un processus en fonction des exigences d’un projet 111 6.2.4 Automatisation de l’exécution des processus . . . . . . . . . . . . 112 6.3 Implémentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 6.3.1 Les modeleurs de VAM et de VRM . . . . . . . . . . . . . . . . . . 113 6.3.2 Les modeleurs de CA abstraits et de liaisons . . . . . . . . . . . . 115 6.3.3 Le framework support à l’implémentation des CA . . . . . . . . . . 117 6.3.3.1 Liaison entre un CA et le plug-in Eclipse l’implémentant 118 6.3.3.2 Exécution générique des plug-in Eclipse implémentant les CA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.3.3.3 Gestion de l’accès aux informations contextuelles . . . . 119 6.3.4 L’assistant à la résolution de la variabilité . . . . . . . . . . . . . . 122 6.3.5 Le moteur de dérivation CVL . . . . . . . . . . . . . . . . . . . . . 124 6.3.6 L’interpréteur de processus . . . . . . . . . . . . . . . . . . . . . . 126 6.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 6.4.1 Recommandations . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 6.4.2 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 6.5 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1304 TABLE DES MATIÈRES 7 Applications de l’approche 133 7.1 Application sur une famille de processus de métamodélisation . . . . . . 133 7.2 Application sur une famille de processus de développement web Java . 139 7.3 Synthèse et discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 8 Conclusion et perspectives 149 8.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 8.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 8.2.1 Perspectives industrielles . . . . . . . . . . . . . . . . . . . . . . . 151 8.2.1.1 Utilisation de T4VASP quel que soit le cas d’application 151 8.2.1.2 Limitation des erreurs . . . . . . . . . . . . . . . . . . . . 151 8.2.1.3 Suppression des redondances dans le modèle de CA abstraits et de liaisons . . . . . . . . . . . . . . . . . . . . 152 8.2.2 Perspectives de recherche à court terme . . . . . . . . . . . . . . . 153 8.2.3 Perspectives de recherche à long terme . . . . . . . . . . . . . . . 153 8.2.3.1 Gestion de la variabilité des processus au moment de leur l’exécution . . . . . . . . . . . . . . . . . . . . . . . . 153 8.2.3.2 Amélioration de la réutilisation des CA . . . . . . . . . . 154 Appendices 155 A Extrait des modèles et CA de la famille de processus de métamodélisation 157 B Extrait des modèles et CA de la famille de processus de développement web Java 163 Bibliographie 169 Liste des figures 179 Liste des tables 183 Liste des publications 185Chapitre 1 Introduction 1.1 La prolifération des outils de développement logiciel La variabilité et l’évolution des exigences d’un projet de développement logiciel sont connues comme une des sources principales de complexité de l’activité de création logiciel [TI93, JMD04, Mar03]. En outre, les projets de développement logiciel sont de plus en plus réalisés de manière collaborative [HMR06], dans un contexte géographiquement distribué [CBHB07], et dans un contexte de globalisation faisant collaborer un ensemble d’entreprises au sein d’un même projet. Ces caractéristiques apportent une complexité accidentelle supplémentaire à la problématique du développement logiciel. Un des objectifs du génie logiciel est de conserver l’intelligibilité du processus de construction et de maintenance de ces applications. Dans ce cadre, de nombreux outils sont apparus afin de gérer, voire automatiser, une partie de cette complexité. Cependant, de part le nombre d’acteurs intervenant dans la construction d’un logiciel et leurs multiples préoccupations, il existe maintenant un écosystème riche et lui-même complexe lié à la problématique de développement logiciel. Parmi ces outils, sans être exhaustifs, nous pouvons citer : – des systèmes de contrôle de version (SVN, Git...) qui permettent de gérer les difficultés liées au travail collaboratif et géographiquement distribué, – des outils de compilation (Maven, Ant, PDE...) qui permettent de gérer les problé- matiques d’intégration de composants ou de librairies réutilisables au moment de la construction d’un logiciel complexe, – des outils d’analyse statique comme PMD, Findbugs ou Sonar qui aident à amé- liorer la qualité du logiciel, – des outils de support à l’exécution des différents types de test logiciel (JUnit, Selenium, Quality Center...), – des environnements de développement intégrés (IDE, Integrated Development Environment) permettant d’intégrer les différentes technologies utilisées sur un projet (langages, outils, frameworks, librairies...), – des outils d’intégration continue permettant d’automatiser une partie de l’orchestration de la problématique de production logicielle. 56 Introduction La forte variabilité des exigences entre différents projets logiciels motive l’existence d’outils différents prenant en compte des préoccupations similaires, mais chacun avec des spécificités permettant de répondre au mieux aux exigences des différents projets. Ceci permet de comprendre le nombre d’outils existants et l’utopie de viser l’émergence d’un unique outil. Ainsi, certaines équipes de développement font le choix de l’IDE Visual Studio pour développer des applications Windows afin de profiter de toutes les facilités proposées par Microsoft pour ce faire, alors que si l’application à développer a des contraintes d’indépendance vis-à-vis du système d’exploitation sur lequel elle sera déployée, une équipe de développement pourra préférer l’IDE Eclipse pour faire du développement en Java. L’utilisation de tous ces outils est généralement bénéfique au bon fonctionnement d’un projet mais elle engendre aussi un ensemble de tâches d’ingénierie logicielle qui sont réalisées manuellement par les équipes de développement. Utiliser ces différents outils peut impliquer de devoir s’en procurer une version, de devoir les installer, les configurer, ou encore les mettre à jour. Par exemple, un développeur utilisant un IDE peut être amené à installer les librairies et les plug-ins nécessaires pour un projet, ainsi qu’à configurer ces derniers. Ces tâches sont de plus récurrentes dans le sens où elles peuvent avoir lieu plusieurs fois pendant un même projet mais aussi qu’elles se répètent d’un projet à l’autre, toujours dans un contexte différent. Par exemple, dans un projet, chaque développeur doit installer un IDE conforme aux exigences de ce projet. Nous appelons dans cette thèse ces tâches répétitives et réalisées manuellement des Tâches Manuelles Récurrentes (TMR). Ces TMR, bien qu’étant toujours similaires, doivent prendre en compte le contexte particulier dans lequel elles sont réalisées. Elles se révèlent être coûteuses en temps et sources d’erreurs pour les équipes de développement [RCB+11]. 1.2 Le défi : réutiliser des automatisations de tâches manuelles récurrentes L’automatisation des TMR liées à l’utilisation des outils de développement logiciel doit permettre de gagner en productivité. Cela doit aussi permettre d’éviter les erreurs humaines inhérentes à toute activité répétitive. Cependant, l’intérêt de la mise en place d’une telle automatisation est limité si les automatisations de TMR ne sont pas réutilisées, au sein d’un même projet mais également d’un projet à l’autre. Or, la réutilisation d’automatisations de TMR est un exercice difficile pour les trois raisons suivantes : 1. Bien qu’une automatisation de TMR puisse être utile pour différents projets, toutes les automatisations de TMR ne sont pas forcément utiles pour chaque projet. La difficulté est donc de déterminer quelles automatisations de TMR réutiliser pour un projet donné. 2. Une automatisation de TMR pouvant avoir des dépendances avec d’autres tâches d’un projet, une difficulté supplémentaire est de déterminer à quels moments d’un projet utiliser une automatisation de TMR.Contributions de la thèse 7 3. La problématique du niveau de généralisation est aussi un problème complexe. Comment déterminer qu’une automatisation de TMR utile pour des projets différents, ou à des moments différents d’un même projet, soit bien réutilisable à travers ces différents cas d’utilisation ? 1.3 Contributions de la thèse Afin de répondre aux défis précédemment énoncés, la contribution de cette thèse est de piloter l’automatisation des TMR liées à l’utilisation des outils de développement logiciel par les processus de développement logiciel. Un processus de développement logiciel correspond à l’ensemble des activités d’ingénierie logicielle requises pour transformer les exigences d’un utilisateur en logiciel [Hum88]. La mise en œuvre de cette contribution s’appuie sur la définition d’une famille de processus de développement logiciel et sur la réutilisation des processus de cette famille en fonction des exigences des projets. Des formalismes différents pouvant être utilisés pour définir les processus de développement logiciel en fonction des exigences des utilisateurs [Zam01], nous proposons une approche (première sous-contribution) permettant de réutiliser les processus indépendamment du langage utilisé pour les définir. Cette approche repose sur l’ingénierie des lignes de produits [PBL05] (où ici les produits sont des processus de développement logiciel) afin de gérer la variabilité dans les processus. La mise en œuvre de la contribution consiste également à lier des automatisations de TMR aux unités de travail d’une famille de processus qu’elles automatisent. Une même automatisation de TMR peut être liée à des unités de travail différentes, appartenant ou non à un même processus. Nous proposons donc une méthodologie (deuxième sous-contribution) fournissant un support à la création d’automatisations de TMR qui soient réutilisables pour toutes les unités de travail auxquelles elles sont liées. L’idée consiste à utiliser le lien entre les automatisations de TMR et la famille de processus pour identifier ces différentes unités de travail. Cette information est ensuite utilisée afin d’implémenter des automatisations réutilisables pour toutes ces unités de travail. Lors de la réalisation d’un processus d’une famille, le lien entre les processus et les automatisations de TMR est utilisé afin de savoir quelles automatisations exécuter pour un projet donné et quand. Pour réaliser cette contribution, nous nous appuyons sur l’IDM (Ingénierie Dirigée par les Modèles) [JCV12] qui offre les outils et méthodes nécessaires pour obtenir une représentation holistique et abstraite des différentes préoccupations (exigences, variabilité et processus) et raisonner de manière uniforme au travers de celles-ci. Afin de valider notre contribution, nous avons développé un outillage supportant sa mise en œuvre. La validation de la contribution a été démontrée sur une famille de processus industriels de développement web Java issue de la société Sodifrance, ainsi que sur une famille de processus consistant à définir et outiller un langage de modélisation.8 Introduction 1.4 Contexte de réalisation de la thèse Cette thèse s’est déroulée dans le cadre d’un contrat Cifre avec la société Sodifrance. Cela nous a permis d’appréhender concrètement la difficulté majeure à laquelle sont confrontées les ESN (Entreprises de Services du Numérique) du secteur du tertiaire. En effet, afin de faire face à la concurrence, ces sociétés sont dans une situation paradoxale où elles doivent réduire leur coûts et temps de développement, tout en garantissant la qualité des produits livrés au client. C’est d’ailleurs cette difficulté qui justifie ces travaux de thèse. Ceux-ci s’inscrivent en effet dans une démarche d’augmentation de la productivité des équipes de développement de Sodifrance. Bénéficier d’une collaboration industrielle a également fait ressortir les exigences principales auxquelles des travaux de recherche doivent répondre pour être utilisés dans l’industrie : être pertinents, outillés et validés. Des travaux de recherche n’ont en effet d’intérêt pour une entreprise que s’ils apportent une solution à des problèmes rencontrés par cette entreprise. Le coût de production élevé de l’outillage support à des travaux de recherche peut de plus empêcher l’adoption d’une approche. D’autre part, les contraintes fi- nancières auxquelles sont souvent confrontées les entreprises peuvent être un frein à l’adoption d’une approche qui n’a pas fait ses preuves. Ce sont ces exigences qui ont permis d’orienter la réalisation de ces travaux de thèse et de déterminer les améliorations à leur apporter. Enfin, la collaboration avec Sodifrance nous a permis d’avoir accès à des cas concrets de projets de développement, à partir desquels nous avons pu concevoir, réaliser et appliquer les contributions de cette thèse. 1.5 Plan de la thèse Cette thèse s’organise en trois parties principales, qui sont le contexte scientifique (partie I), les contributions (partie II) et la validation des travaux de thèse (partie III). Le contexte scientifique (partie I) s’organise en deux chapitres. Le chapitre 2 introduit l’environnement scientifique sur lequel s’appuient ces travaux de thèse. Plus précisément, il introduit l’IDM, les processus de développement logiciel, ainsi que l’ingénierie des lignes de produits logiciels. Il introduit également SPEM et CVL, deux langages de l’OMG permettant respectivement de définir des processus de développement logiciel et de mettre en œuvre l’ingénierie des lignes de produits. Le chapitre 3, traite de l’état de l’art sur la réutilisation d’automatisations de TMR. Cet état de l’art porte plus particulièrement sur les approches permettant de savoir quand réutiliser des automatisations de TMR et permettant de développer des composants logiciels réutilisables. La contribution de la thèse, le pilotage de l’automatisation des TMR par les processus de développement logiciel, est présentée dans la partie II. Les sous-contributions de la thèse sont détaillées dans deux chapitres. Le chapitre 4 présente la première sous-contribution, à savoir notre approche permettant de réutiliser les processus de développement logiciel en fonction des exigences des projets et indépendamment du langage utilisé pour définir ces processus. Le chapitre 5 détaille la deuxième sous-Plan de la thèse 9 contribution, une méthodologie fournissant un support à la création d’automatisations de TMR réutilisables dans tous leurs cas d’utilisation. La validation des travaux de thèse (partie III) comprend deux chapitres. Dans le chapitre 6, nous présentons l’outillage support aux contributions de cette thèse. Dans le chapitre 7, nous appliquons cet outillage à une famille de processus consistant à définir et outiller un langage de modélisation ainsi qu’à une famille de processus de développement web Java issue de Sodifrance. Enfin, nous concluons et présentons nos perspectives de travail dans le chapitre 8.10 IntroductionPremière partie Contexte scientifique 1113 Dans cette partie, nous commençons par présenter dans le chapitre 2 les diffé- rents champs de recherche sur lesquels nous nous appuyons dans cette thèse. Nous présentons ensuite dans le chapitre 3 l’état de l’art de cette thèse.14Chapitre 2 Background Nous présentons dans ce chapitre les différents champs de recherche sur lesquels nous nous appuyons dans cette thèse. Nous commençons par présenter, dans la section 2.1, l’IDM (Ingénierie Dirigée par les Modèles), que nous utilisons pour mettre en œuvre les contributions de cette thèse. Nous présentons ensuite, dans la section 2.2, les processus de développement logiciel, ainsi que l’ingénierie des lignes de produits logiciels dans la section 2.3. En plus d’introduire, dans les sections 2.2 et 2.3, les concepts relatifs aux processus de développement logiciel et à l’ingénierie des lignes de produits, nous montrons comment l’IDM s’applique à ces domaines. Enfin, nous faisons une synthèse de ce chapitre dans la section 2.4. 2.1 L’ingénierie dirigée par les modèles (IDM) La séparation des préoccupations [Dij82] est un moyen de gérer la complexité des logiciels. En effet, il est plus simple et efficace pour l’esprit humain de résoudre un problème complexe en le décomposant en sous-problèmes de complexité moindre plutôt que de considérer le problème complexe dans son ensemble. L’IDM [JCV12] est un moyen de mettre en œuvre la séparation des préoccupations, en s’appuyant sur le principe de l’abstraction. En effet, le principe général de l’IDM est d’utiliser une représentation simplifiée d’un aspect du monde réel (c’est-à-dire un modèle) dans un objectif donné, en s’abstrayant des détails qui n’ont pas de rapport avec cet aspect. Dans le domaine de l’ingénierie logicielle, chaque aspect d’un système logiciel peut donc être représenté par un modèle. Ce modèle est lui-même exprimé avec un langage de modélisation généraliste tel qu’UML [OMG11b, OMG11c] ou avec un langage de modélisation dédié à un domaine métier particulier. L’intérêt de ces langages est qu’ils soient plus simples à appréhender pour des humains que les langages de programmation classiques (Java, C#, ...) ou que le langage machine. Un modèle peut alors être vu comme un support plus adapté pour des humains pour exprimer un aspect particulier d’un logiciel ainsi que pour réfléchir et communiquer sur cet aspect. Une problématique clé de l’IDM est également de rendre les modèles opération- 1516 Background nels. Cependant, à cette fin, ceux-ci doivent être interprétables par des machines. Le langage dans lequel ils sont exprimés doit donc être clairement défini. Comme tout langage informatique, un langage de modélisation est caractérisé par sa syntaxe abstraite, sa syntaxe concrète et sa sémantique [JCV12]. La syntaxe abstraite est la syntaxe manipulée par l’ordinateur. Dans le contexte des langages de modélisation, elle sert généralement de base à la définition de la syntaxe concrète et de la sémantique. La syntaxe concrète est la syntaxe manipulée par l’utilisateur du langage à l’aide d’un éditeur. Elle comprend des éléments syntaxiques dont le but est de faciliter l’utilisation d’un langage pour des humains. Elle associe des représentations pour chacun des élé- ments de la syntaxe abstraite. Il est tout à fait possible de définir des syntaxes concrètes différentes pour une même syntaxe abstraite, en fonction des besoins. La sémantique d’un langage de modélisation est définie en associant un sens à chacun des éléments de la syntaxe abstraite. Il est également possible de définir des sémantiques différentes pour une même syntaxe abstraite, en fonction des besoins (ex : vérification, simulation, compilation, etc.). Dans le domaine de l’IDM, la syntaxe abstraite peut prendre la forme d’un modèle, appelé métamodèle. On dit d’un modèle m qu’il est conforme à un métamodèle mm si chaque élément de m est une instance d’un élément de mm [Guy13]. Cependant, face à la prolifération des métamodèles, le besoin est apparu de les unifier avec un langage de description commun, afin de les rendre compatibles entre eux et de pouvoir définir des outils capables de les manipuler de manière générique. L’OMG a donc proposé un langage de description des métamodèles, qui prend lui aussi la forme d’un modèle : le métamétamodèle MOF (Meta-Object Facility) [OMG06]. La particularité du métamétamodèle est qu’il se définit lui-même, limitant ainsi le nombre de niveaux de modélisation. Quand le métamétamodèle MOF ne permet pas d’exprimer toutes les propriétés d’un métamodèle, il est possible d’utiliser un langage de contrainte, tel qu’OCL (Object Constraint Language) [OMG10], afin d’exprimer ces propriétés. Dans la pratique, l’utilisation de modèles de manière opérationnelle peut prendre plusieurs formes. Nous ne présentons ici que celles qui sont pertinentes pour la compréhension de cette thèse. Ainsi, les modèles peuvent être utilisés directement comme le système logiciel final à produire, en les exécutant tout comme il est possible d’exé- cuter n’importe quel programme informatique. Deux méthodes existent pour exécuter des modèles : l’interprétation et la compilation. L’interprétation consiste à analyser chaque élément d’un modèle et à l’exécuter en fonction de sa sémantique. La compilation consiste à transformer un modèle conforme à un langage en un modèle ou du texte conforme à un autre langage, et ensuite à exécuter le modèle ou le texte obtenu après transformation. Il existe à ce jour de nombreux outils support à l’IDM. Dans cette thèse, nous utilisons EMF (Eclipse Modeling Framework) [SBPM09], un framework de l’environnement de développement Eclipse 1 , afin de définir des métamodèles, de générer des éditeurs arborescents permettant de créer des modèles conformes à ces métamodèles, ainsi que de manipuler ces modèles et métamodèles en Java. EMF s’appuie sur le langage de 1. http://www.eclipse.orgLes processus de développement logiciel 17 métamodélisation Ecore [BSE03], qui est similaire au MOF. Nous faisons également référence dans cette thèse à l’utilisation d’UML afin de définir des langages de modé- lisation dédiés à un domaine métier particulier. Le mécanisme de profil UML permet en effet d’étendre UML de façon générique. Plus précisément, il permet d’ajouter de nouveaux concepts propre à un domaine métier particulier, de définir leurs propriétés, de spécifier des contraintes sur ces concepts et également de leur associer une repré- sentation graphique. Un profil est définit principalement à l’aide de stéréotypes, où un stéréotype définit un nouveau concept, mais toujours sous la forme d’une extension d’un élément UML. Un stéréotype peut avoir des propriétés ainsi qu’une représentation graphique. Des contraintes (telles que des contraintes OCL) peuvent également être définies sur ce stéréotype. 2.2 Les processus de développement logiciel 2.2.1 Introduction aux processus de développement logiciel Un processus de développement logiciel correspond à l’ensemble des activités d’ingénierie logicielle requises pour transformer les exigences d’un utilisateur en logiciel [Hum88]. La maîtrise de ces processus est un enjeu crucial pour les entreprises qui développent des logiciels. Pour preuve, le CMM (Capability Maturity Model) [Ins95] est une méthodologie qui se base sur l’amélioration des processus de développement logiciel afin d’améliorer la qualité des logiciels produits, tout en réduisant les coûts et les temps de production [HZG+97, Dio93]. La maîtrise des processus de développement logiciel passe, entre autres, par l’utilisation de formalisations de processus afin de supporter leur exécution [Ost87, Ins95]. L’exécution d’un processus de développement logiciel consiste en la réalisation des différentes unités de travail définies par ce processus, dans l’ordre dans lequel elles sont définies [Ben07]. Des méthodes 2 de développement logiciel, telles que les méthodes de développement en cascade [Roy87] ou en spirale [Boe88], ont dans un premier temps été proposées afin de définir les processus de développement logiciel. Ces méthodes donnent une vue générale des activités à accomplir pour mener à bien un projet de développement logiciel. Mais leur principale limitation est qu’elles ne fournissent pas assez de détails pour guider la réalisation concrète de ces activités [CKO92]. La notion de modèle de processus est alors apparue afin de faire face à cette limitation, où un modèle de processus capture de manière plus détaillée les informations nécessaires pour guider la réalisation d’un projet. Ces modèles de processus sont exprimés selon un langage de modélisation de processus de développement logiciel. Il existe à ce jour plusieurs langages de modélisation de processus de développement logiciel, comme SPEM [OMG08], xSPEM [BCCG07], Little-JIL [Wis06], UML4SPM [BGB06], ou encore SEMDM [ISO07]. Nous présentons plus en détails un de ces langages, SPEM, en section 2.2.2. 2. Une méthode définit comment mettre en œuvre des unités de travail et des artéfacts qui servent à la définition de processus de développement logiciel [HIMT96].18 Background Figure 2.1 – Modèle conceptuel de SPEM Un modèle de processus peut ensuite servir à guider l’exécution d’un processus. En effet, le modèle de processus peut être utilisé comme support de communication entre les différents membres d’une équipe [Ost87, Ins95]. Un modèle de processus peut aussi être utilisé comme un programme qu’il est possible d’exécuter [Ost87], afin d’automatiser les étapes de l’exécution du processus qui peuvent l’être [RGC04]. Des outils supportant l’exécution de langages de modélisation de processus ont ainsi vu le jour, comme Wilos 3 pour SPEM, Juliette [CLM+99, CLS+00] pour Little-JIL, ainsi qu’un compilateur et un interpréteur [Ben07] pour UML4SPM. 2.2.2 Modélisation des processus de développement logiciel avec SPEM 2.0 SPEM 2.0 (Software & Systems Process Engineering Metamodel) [OMG08] est le standard de l’OMG dédié à la modélisation des processus logiciels et systèmes. Il vise à offrir un cadre conceptuel pour modéliser, échanger, documenter, gérer et présenter les processus et méthodes. Les concepts de SPEM 2.0 sont décrits par un métamodèle qui repose sur l’idée qu’un processus de développement est une collaboration entre des entités actives et abstraites, les rôles, qui représentent un ensemble de compétences et qui effectuent des opérations, les activités, sur des entités concrètes et réelles, les produits. Les différents rôles agissent les uns par rapport aux autres ou collaborent en échangeant des produits et en déclenchant l’exécution de certaines activités. Ce modèle conceptuel est synthétisé sur la figure 2.1. La particularité de SPEM 2.0 est qu’il sépare les aspects contenus et données relatifs aux méthodologies de développement, de leurs possibles instanciations dans un projet particulier. Ainsi, pour pleinement exploiter ce framework, la première étape devrait être de définir toutes les phases, activités, produits, rôles, guides, outils, etc., qui peuvent composer une méthode pour ensuite, dans une deuxième étape, choisir en fonction du contexte et du projet, le contenu de la méthode appropriée pour l’utiliser dans la définition du processus. SPEM 2.0 est défini sous la forme d’un métamodèle MOF [OMG06] qui s’appuie sur les spécifications UML 2.0 Infrastructure [OMG11b] et UML 2.0 Diagram Defini- 3. www.wilos.ups-tlse.frLes processus de développement logiciel 19 Figure 2.2 – Structure du métamodèle de SPEM 2.0 [OMG08] tion [OMG12]. De UML 2.0 Infrastructure, il réutilise les concepts de base tels que Classifier ou Package. Aucun concept de UML 2.0 Superstructure [OMG11c] n’est réutilisé. Le standard est défini également sous la forme d’un profil UML où chaque élément du métamodèle de SPEM 2.0 est défini comme un stéréotype de UML 2.0 Superstructure. Le métamodèle de SPEM 2.0 est composé de sept paquetages liés avec le mécanisme «merge» [OMG11b], chaque paquetage traitant d’un aspect particulier (cf. figure 2.2). Le paquetage Core introduit les classes et les abstractions qui définissent les fondations pour tous les autres paquetages. La structure de décomposition de ce paquetage est la classe WorkDefinition, qui généralise toutes les activités de travail de SPEM 2.0. Le paquetage ProcessStructure définit les éléments permettant de représenter les modèles de processus. Cependant, la possibilité de documenter textuellement ces élé- ments (c.-à-d. ajouter les propriétés décrivant chaque élément) n’est pas fournie dans ce paquetage mais dans ManagedContent, qui définit les concepts pour gérer les descriptions textuelles des éléments de processus. Des exemples de ces concepts sont les classes ContentDescription et Guidance. Le paquetage MethodContent définit les concepts de base pour spécifier le contenu de méthodes basiques. Le paquetage ProcessWithMethod regroupe l’ensemble des éléments requis pour intégrer les processus définis avec les concepts du paquetage ProcessStructure, selon les contenus définis avec les concepts du paquetage MethodContent. Le paquetage MethodPlugin offre les mécanismes pour gérer et réutiliser des bibliothèques de contenus de méthode et processus. Ceci est assuré grâce aux concepts MethodLibrary et MethodPlugin. Une instance de MethodLibrary est un conteneur pour tout élément SPEM 2.0. C’est donc l’élément racine d’un modèle SPEM 2.0. Une instance de MethodPlugin est plus particulièrement un conteneur pour des contenus de méthodes et des processus. Enfin, le paquetage ProcessBehavior offre le moyen de lier un élément de procédé SPEM 2.0 avec un comportement externe comme des diagrammes d’activités UML 2.0 ou des modèles BPMN (Business Process Modeling Notation) [OMG11a].20 Background Figure 2.3 – Extraits de certains paquetages du métamodèle de SPEM 2.0 La figure 2.3 détaille le contenu des paquetages Core, MethodContent, ProcessStructure et ProcessWithMethod qui est utile pour la compréhension de la suite de cette thèse. Le paquetage MethodContent contient des éléments de contenu de méthode (MethodContentElement), tels que des définitions de rôles (RoleDefinition), qui réalisent des définitions de tâches (TaskDefinition) en utilisant des définitions d’outils (ToolDefinition). Une définition de tâche a des définitions de produits de travail (WorkProductDefinition) en tant qu’entrées et sorties. Le paquetage ProcessStructure définit des éléments de processus appartenant à une structure de décomposition (BreakdownElement). Parmi ces éléments de processus sont définis des produits de travail (WorkProductUse), des rôles (RoleUse), et également des éléments représentant un travail (WorkBreakdownElement). Parmi les éléments représentant un travail, une activité (Activity) est un conteneur pour d’autres éléments de processus appartenant à une structure de décomposition. Le paquetage ProcessWithMethod spécifie qu’un produit de travail se base sur une définition de produit de travail et qu’un rôle se base sur une définition de rôle. Il spécifie également un nouveau type d’élément de processus représentant un travail, la tâche (TaskUse), qui se base sur une définition de tâche. Une tâche est réalisée par un rôle, et c’est la classe ProcessPerformer qui fait le lien entre les deux. Une tâche a également des produits de travail en entrée et en sortie, et c’est un paramètre (classe ProcessParameter du paquetage ProcessStructure) qui permet de faire le lien entre une tâche et ses entrées et sorties. Le paquetage Core contient entre autres une classe ParameterDirectionKind, qui permet de définir si un produit de travail est une entrée (in) ou une sortie (out) d’un travail.Les processus de développement logiciel 21 Figure 2.4 – Syntaxe concrète de SPEM 2.0 et des diagrammes d’activités SPEM 2.0 définit également un plug-in de base, sous la forme d’une instance de MethodPlugin. Ce plug-in définit un type particulier d’activité, le processus (DeliveryProcess), qui correspond à l’approche complète pour réaliser un type de projet particulier. Un processus définit donc la séquence d’activités à réaliser pour mener à bien un projet de développement logiciel, tandis qu’une activité définit la séquence de tâches à effectuer pour réaliser cette activité. Étant donné qu’en SPEM 2.0 les tâches et les activités sont des actions (Action) UML 2.0 stéréotypées, il est possible d’utiliser les diagrammes d’activités UML 2.0 pour modéliser une séquence d’activités ou de tâches. En UML 2.0, une action, un flot de contrôle (ControlFlow), un nœud initial (InitialNode), un nœud final (ActivityFinalNode), un nœud de jointure (JoinNode), un nœud de parallélisation (ForkNode) et un nœud de décision (DecisionNode) sont des sous-types de nœud d’activité (ActivityNode). Un flot de contrôle représente l’enchaînement de deux nœuds d’activité, où un nœud d’activité source est suivi par un nœud d’activité cible. La condition d’un flot de contrôle, quand elle existe, spécifie à quelle condition ce flot de contrôle est navigable. Les nœuds initiaux et finaux spécifient respectivement le début et la fin d’un enchaînement d’activités ou de tâches. Un nœud de parallélisation divise un flot de contrôle en plusieurs flots de contrôle navigables simultanément. Un nœud de jointure fusionne plusieurs flots de contrôle en un seul. Un nœud de décision divise un flot de contrôle en plusieurs flots de contrôle alternatifs. La figure 2.4 illustre la syntaxe concrète que nous utilisons dans cette thèse pour représenter des processus SPEM 2.0 ainsi que des diagrammes d’activités. Pour terminer, nous illustrons l’utilisation de SPEM 2.0 en modélisant un exemple de processus simplifié de développement d’une application Java. Ce processus (cf. fi- gure 2.5) commence avec l’activité spécifier, durant laquelle un expert fonctionnel produit un document définissant les spécifications techniques et fonctionnelles de l’application à développer, en fonction des exigences d’un projet. L’activité spécifier est suivie par l’activité développer, pendant laquelle un développeur code manuellement l’application. Lors de l’activité tester suivante, un testeur vérifie que l’application en cours de dé- veloppement est bien conforme aux spécifications. Si cette activité révèle des erreurs, celles-ci doivent être corrigées, ce qui se traduit dans le processus par un retour à l’activité de développement. S’il n’y a pas d’erreur, le processus se termine par l’activité mettre en production, qui consiste à déployer l’application sur l’environnement du client. Dans le cas de cet exemple, l’activité de développement consiste en la création et la22 Background modification de projets Eclipse, comme illustré par la figure 2.6. Les tâches créer premier projet Eclipse, créer projet Eclipse, modifier projets Eclipse ainsi que le produit de travail projet(s) Eclipse font respectivement référence aux éléments de contenu de méthode de même nom de la figure 2.7. Figure 2.5 – Un processus simplifié de développement Java Figure 2.6 – Détail de l’activité de développement du processus de la figure 2.5L’ingénierie des lignes de produits logiciels 23 Figure 2.7 – Éléments de contenu de méthode du processus simplifié de développement Java de la figure 2.5 2.3 L’ingénierie des lignes de produits logiciels 2.3.1 Introduction Une ligne de produits logiciels, ou famille de produits logiciels, est un ensemble de produits logiciels partageant des caractéristiques communes et développés à partir d’un ensemble commun d’artéfacts [CN01]. L’ingénierie des lignes de produits logiciels [WL99, CN01, PBL05] permet la réutilisation d’artéfacts logiciels pour créer un nouveau produit logiciel, plutôt que de développer ce produit à partir de rien [Kru92]. Elle s’appuie sur l’identification de la variabilité et des parties communes d’une ligne de produits afin de réutiliser ces parties communes. L’ingénierie des lignes de produits logiciels apporte des bénéfices en termes de réduction des coûts et des temps de développement ainsi qu’en termes d’amélioration de la qualité des produits logiciels. Afin de permettre la réutilisation des artéfacts logiciels, l’ingénierie des lignes de produits logiciels s’appuie sur deux processus : l’ingénierie de domaine et l’ingénierie d’application [PBL05]. Le processus d’ingénierie de domaine consiste à identifier la variabilité et les parties communes d’une ligne de produits, ainsi qu’à développer les artéfacts communs aux produits de la ligne, en vue de leur réutilisation. Les artéfacts partagés par plusieurs produits ne sont définis qu’une seule fois, afin d’assurer leur réutilisation et d’en faciliter la maintenance [Kru06]. Le processus d’ingénierie d’application, aussi appelé processus de dérivation d’un produit logiciel, consiste à développer un produit logiciel spécifique à partir de la réutilisation des artéfacts développés pendant le processus d’ingénierie de domaine. Il s’appuie sur une phase de résolution de la variabilité, qui consiste à définir la configuration de produit souhaitée en spécifiant la valeur de chaque partie variable de la ligne de produits. On distingue deux types de variabilité : variabilité positive et variabilité néga-24 Background Figure 2.8 – Principe général de CVL, issu de la spécification de CVL 4 tive [VG07]. La variabilité positive consiste, durant le processus d’ingénierie de domaine, à ne définir que les artéfacts communs à tous les produits d’une famille. Les artéfacts spécifiques à un produit sont quant à eux créés au moment de la dérivation de ce produit, en fonction de sa spécification. Au contraire, la variabilité négative consiste, durant le processus d’ingénierie de domaine, à définir tous les artéfacts nécessaires à la définition des produits d’une famille. Lors de la dérivation d’un produit, les artéfacts ne correspondant pas à ce produit ne sont donc pas sélectionnés. Plusieurs approches s’appuient sur l’IDM afin de mettre en œuvre les concepts de l’ingénierie des lignes de produits logiciels [Jéz12]. L’IDM est ainsi utilisée pour définir des lignes produits et pour dériver des produits de ces lignes de produits. Nous présentons plus en détails une de ces approches, CVL [FHMP+11], dans la section suivante. 2.3.2 CVL CVL (Common Variability Language) 4 [FHMP+11], un standard de l’OMG en cours de spécification, est un langage de modélisation qui permet de spécifier et de résoudre de la variabilité sur n’importe quel modèle dont le métamodèle est conforme au MOF. Comme illustré en figure 2.8, CVL propose de définir un modèle de base (base model), qui est une instance de n’importe quel métamodèle conforme au MOF. Ce modèle de base contient les éléments de modèle nécessaires à la définition des différents produits d’une famille. CVL fournit également des constructions pour capturer la variabilité (VAM, Variability Abstraction Model) entre les différents produits d’une famille. Le VAM peut être comparé à un BFM (Basic Feature Model) [KCH+90], dans le sens où 4. La spécification complète de CVL peut être trouvée sur le wiki de CVL, à l’adresse http://www. omgwiki.org/variability/doku.php.L’ingénierie des lignes de produits logiciels 25 tout comme un BFM, il permet d’expliciter les différences et les similitudes entre les caractéristiques de produits logiciels d’une même famille. CVL fournit aussi des constructions pour définir la réalisation de cette variabilité sur le modèle de base (VRM, Variability Realization Model). Le VRM permet d’expliciter le lien entre le VAM et les éléments du modèle de base. Plus précisément, le VRM spécifie quels sont les éléments de modèle de base qui sont impactés par la variabilité définie dans le VAM et comment ces éléments de modèle sont impactés. En d’autres termes, le VRM spécifie comment dériver un produit du modèle de base, en fonction de la variabilité spécifiée dans le VAM. Enfin, CVL fournit des constructions permettant de résoudre la variabilité définie dans le VAM, afin de sélectionner une configuration du modèle de base (RM, Resolution Model). Le VAM, le VRM et le RM contiennent les informations nécessaires à la dérivation, à partir du modèle de base, d’un modèle résolu (resolved model), c’est-à-dire sans variabilité. Le modèle résolu est alors une autre instance du métamodèle auquel le modèle de base est conforme. Dans la suite, nous présentons les trois parties du métamodèle de CVL (abstraction de la variabilité, réalisation de la variabilité et résolution de la variabilité). Nous dé- taillons plus particulièrement les éléments du métamodèle de CVL qui seront utilisés pour illustrer la suite de cette thèse. Cependant, tous les éléments du métamodèle de CVL peuvent être utilisés pour mettre en œuvre ces travaux de thèse, en fonction des spécificités de chaque cas. Figure 2.9 – Extrait de la partie abstraction de la variabilité du métamodèle de CVL La figure 2.9 présente un extrait de la partie abstraction de la variabilité du métamodèle de CVL. Cette partie permet de définir de la variabilité à l’aide de spécifications de variabilité (VSpec). Une spécification de variabilité peut être un choix (Choice), c’est- à-dire une caractéristique qui appartiendra ou non au modèle résolu selon que ce choix sera résolu positivement ou négativement (c’est-à-dire selon que le choix sera sélectionné ou non). Une spécification de variabilité est également un conteneur pour26 Background d’autres spécifications de variabilité, qui sont alors ses enfants (child). Ces enfants peuvent être résolus à vrai seulement si leur parent (parent) est résolu à vrai. Une spécification de variabilité a aussi une multiplicité de groupe (groupMultiplicity) qui définit les nombres minimum et maximum (attributs lower et upper de la classe MultiplicityInterval) d’enfants directs qui peuvent être résolus positivement. La multiplicité de groupe permet donc d’exprimer si des spécifications de variabilité ayant le même parent direct sont mutuellement exclusives ou non. Si un choix est impliqué par son parent (attribut isImpliedByParent à vrai), alors il doit forcément être sélectionné si son parent l’est. L’implication par le parent permet donc d’exprimer qu’une spécification de variabilité enfant est optionnelle ou obligatoire. CVL fournit également le concept de dérivation de spécification de variabilité (VSpecDerivation), qui spécifie que la résolution d’une spécification de variabilité (identifiée par la référence derivedVSpec) est dérivée (c’est-à-dire calculée) de la résolution d’autres spécifications de variabilité. De ce fait, un RM ne définit pas de résolution pour une spécification de variabilité dont la résolution est dérivée. Un type particulier de dérivation de spécification de variabilité est la dérivation de choix (ChoiceDerivation), qui s’applique à un choix, identifié par la référence derivedChoice. Une dérivation de choix est associée à une contrainte de dérivation (Constraint) via la référence derivingConstraint. C’est cette contrainte de dérivation qui définit comment la résolution d’un choix est dérivée de la résolution d’autres spécifications de variabilité. Cette contrainte peut par exemple être exprimée à l’aide d’un langage de contrainte tel qu’OCL. Figure 2.10 – Exemple VAM spécifiant la variabilité d’un site d’achat en ligne À titre d’illustration (cf. figure 2.10), nous utilisons un VAM pour spécifier la variabilité d’un site d’achat en ligne. Les choix CVL permettent de spécifier les différentesL’ingénierie des lignes de produits logiciels 27 caractéristiques que peut avoir un tel site (paiement, catalogue, langue, recherche, sécurité, etc.). L’implication par le parent permet de spécifier les caractéristiques obligatoires (paiement, catalogue, langue, sécurité) et optionnelles (recherche, internationalisation). Une multiplicité de groupe dont la borne supérieure vaut 1 spécifie que des choix enfants sont mutuellement exclusifs (élevé et standard), tandis qu’une borne supérieure valant plus de 1 spécifie que plusieurs choix enfants peuvent appartenir à une même confi- guration de produit (par exemple français et anglais). La résolution du choix internationalisation est dérivée de la résolution des choix français et anglais. Plus précisément, un mécanisme d’internationalisation est utilisé pour développer un site d’achat en ligne si celui-ci doit être disponible dans les deux langues. Figure 2.11 – Extrait de la partie réalisation de la variabilité du métamodèle de CVL La figure 2.11 illustre un extrait de la partie réalisation de la variabilité du métamodèle de CVL. Le concept principal de cette partie réalisation de la variabilité est celui de point de variation (VariationPoint). Un point de variation est une opération à effectuer sur le modèle de base afin de dériver un modèle résolu. Un point de variation est effectué sur le modèle de base lorsque la spécification de variabilité qui lui est associée (bindingVSpecs) est résolue positivement. CVL définit différents types de points de variation. Parmi eux, un point de variation de choix (ChoiceVariationPoint) est un point de variation associé à une spécification de variabilité de type choix. Un point de variation de choix s’applique donc lorsque le choix associé (bindingChoice) est sélectionné. Différents types de points de variation de choix existent. Parmi eux, une substitution d’objet (ObjectSubstitution) remplace un objet du modèle de base, l’objet placement (placementObject), par un autre objet du modèle de base, l’objet remplaçant (replacementObject), et supprime l’objet placement. Une substitution de fin de lien (LinkEndSubstitution) assigne une nouvelle valeur à un lien du modèle de base. Ce lien est identifié par le nom de la référence qu’il instancie (linkEndIdentifier) ainsi que par l’objet qui contient ce lien (link). La nouvelle28 Background valeur à affecter au lien est un objet désigné par la référence replacementObject associée à la classe LinkEndSubstitution. Une existence d’objet (ObjectExistence) spécifie qu’un objet optionnel (optionalObject) du modèle de base existera toujours dans le modèle résolu. L’objet optionnel est supprimé du modèle de base (et donc du modèle résolu) si le choix associé au point de variation qui le contient n’est pas sélectionné. Ainsi, l’existence d’objet s’exécute en variabilité négative. Cela signifie qu’il n’est pas possible de créer des objets dans le modèle résolu. Si un objet appartient au modèle résolu, c’est forcément qu’il était défini dans le modèle de base. Il est uniquement possible de supprimer des objets du modèle de base pour qu’ils n’appartiennent pas à un modèle résolu. Au contraire, la variabilité positive signifie qu’il est possible de créer des objets au moment de la dérivation. Un pointeur de lien (LinkHandle) et un pointeur d’objet (ObjectHandle) permettent de référencer un objet du modèle de base via leur attribut MOFRef, qui correspond à l’URI de l’objet à référencer. Figure 2.12 – VRM de l’exemple de site d’achat en ligne Comme illustré par la figure 2.12, un VRM associé à l’exemple de site d’achat enL’ingénierie des lignes de produits logiciels 29 ligne spécifie que si le choix carte de crédit est sélectionné, alors, dans un modèle de base, la classe ClasseC doit référencer la classe ClasseD au lieu de la classe ClasseB. Si le choix recherche n’est pas sélectionné, alors la classe ClasseA du modèle de base appartiendra au modèle résolu. Enfin, si le choix standard est sélectionné, alors la classe ClasseE sera substituée par la classe ClasseH dans le modèle résolu. Figure 2.13 – Extrait de la partie résolution de la variabilité du métamodèle de CVL La figure 2.13 présente un extrait de la partie résolution de la variabilité du métamodèle de CVL. Le concept central de cette partie est celui de résolution de spécification de variabilité (VSpecResolution), qui résout une spécification de variabilité identifiée par la référence resolvedVSpec. Un type particulier de résolution de spécification de variabilité est la résolution de choix (ChoiceResolution), qui résout un choix identifié par la référence resolvedChoice. L’attribut decision d’une résolution de choix permet d’indiquer la valeur de résolution d’un choix. Un choix est en effet sélectionné ou non selon que cet attribut vaut vrai ou faux. Figure 2.14 – Exemple de RM résolvant le VAM de la figure 2.10 Le RM présenté en figure 2.14 résout la variabilité du VAM de la figure 2.10. Tous les choix sont sélectionnés sauf les choix recherche et standard. En conséquence, les substitutions de fin de lien et d’objet du VRM de la figure 2.12 sont appliquées au modèle de base afin de dériver le modèle résolu (figure 2.15), tandis que l’existence d’objet n’est pas appliquée. Dans le modèle résolu, la classe ClasseA n’existe donc pas,30 Background Figure 2.15 – Modèle résolu obtenu en fonction des modèles des figures 2.10, 2.12 et 2.14 la classe ClasseC référence la classe ClasseD au lieu de la classe ClasseB et la classe ClasseE a été substituée par la classe ClasseH. CVL propose également d’autres concepts permettant de gérer la variabilité, dont nous ne nous servirons pas pour illustrer la suite de cette thèse, bien qu’ils puissent être utilisés pour mettre en œuvre ces travaux. Nous en donnons un aperçu dans la suite de cette section. Il existe ainsi d’autres types de point de variation de choix. Parmi eux, l’affectation d’attribut permet d’assigner une nouvelle valeur à un attribut. L’existence de lien et l’existence d’attribut, de manière similaire à l’existence d’objet, permettent respectivement de spécifier l’existence d’un lien ou de la valeur d’un attribut. La figure 2.16 illustre un exemple d’utilisation de ces trois points de variation. Lorsque le choix choix 1 est sélectionné, alors la classe ClasseB est renommée en ClasseZ, le nom de la classe ClasseC existe et cette dernière hérite de ClasseZ (cf. figure 2.17). À l’inverse, lorsque le choix choix 1 n’est pas sélectionné, la classe ClasseB n’est pas renommée et le nom de la classe ClasseC est supprimé ainsi que la relation d’héritage (cf. figure 2.18). CVL permet également à ses utilisateurs de définir leurs propres points de variation, appelés points de variation opaques, en définissant des transformations d’un modèle vers un autre modèle. CVL définit aussi des points de variation paramétrables, tels que la substitution de fin de lien paramétrable, l’affectation d’attribut paramétrable et la substitution d’objet paramétrable. Ceux-ci se comportent comme leurs homologues non paramétrables, à la différence qu’une valeur à assigner ou un objet remplaçant ne sont spécifiés qu’au moment de la résolution, dans le RM. Cela est utile lorsqu’un élément du modèle de base a des variantes qui ne sont pas connues au moment de l’édition du VRM. Un point de variation paramétrable est relié à un type de spécification particulier, la variable. La valeur assignée à une variable est affectée au moment de la résolution, en utilisant un type de résolution de spécification de variabilité particulier, l’affectation de valeur à une variable. CVL propose également un point de variation dit répétable, la substitution de fragment. Exécutée une seule fois, la substitution de fragment remplace un fragment du modèle de base par un autre. Lorsqu’elle est répétée, une substitution de fragment crée une nouvelle instance du fragment remplaçant à chaque répétition. CVL définit un type de spécification de variabilité et un type de résolution de spécification de variabilité spécifiques au point de variation répétable, respectivement le classificateur de variabilité et l’instance de variabilité. Le classificateur de variabilité permet de spécifier deL’ingénierie des lignes de produits logiciels 31 Figure 2.16 – Exemple de définition d’affectation d’attribut, d’existence de lien et d’existence d’attribut Figure 2.17 – Modèle résolu obtenu lorsque le choix de la figure 2.16 est sélectionné Figure 2.18 – Modèle résolu obtenu lorsque le choix de la figure 2.16 n’est pas sélectionné la variabilité sur le nombre d’instances d’un fragment du modèle de base, tandis que l’instance de variabilité permet de déterminer ce nombre d’instances. Des exemples de VAM, VRM et modèle de base sont présentés en figure 2.19 afin d’illustrer une substitution de fragment. Si une instance de variabilité résout le classificateur de variabilité mon classificateur de variabilité, alors le fragment constitué des classes ClasseB et ClasseC est remplacé par le fragment constitué des classes ClasseD et ClasseE (cf. figure 2.20). Ce dernier est dupliqué si deux instances de variabilité résolvent mon classificateur de variabilité (cf. figure 2.21). Aucune substitution de fragment n’a lieu si aucune instance de variabilité ne résout mon classificateur de variabilité. Un autre type de point de variation introduit par CVL est le point de variation32 Background Figure 2.19 – Exemple de VAM, VRM et modèle de base pour une substitution de fragment Figure 2.20 – Modèle résolu obtenu lorsque le classificateur de variabilité de la fi- gure 2.19 est résolu par une seule instance de variabilité Figure 2.21 – Modèle résolu obtenu lorsque le classificateur de variabilité de la fi- gure 2.19 est résolu par deux instances de variabilité composite. Ce type de point de variation manipule des conteneurs, qui sont des objets du modèle de base contenant d’autres éléments de modèle, et sur lesquels de la variabilité est spécifiée. Comme illustré par la figure 2.22, le point de variation composite permet de cloner un conteneur (le paquetage paquetage configurable sur la figure), de résoudre la variabilité de chaque clone (paquetages une configuration du paquetage configurable etSynthèse 33 une autre configuration du paquetage configurable sur la figure), et de rediriger vers ces clones les liens des éléments du modèle de base qui les utilisent (paquetages paquetage 1 et paquetage 2 sur la figure). Ce type de point de variation est utile lorsqu’un conteneur est utilisé plusieurs fois dans un même modèle, mais que les différentes utilisations de cet objet requièrent des résolutions différentes de sa variabilité. CVL définit également un type de spécification de variabilité ainsi qu’un type de résolution de spécification de variabilité spécifiques à l’utilisation des points de variation composites, à savoir la spécification de variabilité composite et la configuration de variabilité. La spécification de variabilité composite, qui est un conteneur pour d’autres spécifications de variabilité, permet de spécifier de la variabilité au niveau du contenu d’un élément du modèle de base. La configuration de variabilité permet quant à elle de résoudre cette variabilité. Figure 2.22 – Illustration du principe du point de variation composite Enfin, CVL permet l’expression de contraintes transversales, c’est-à-dire de contraintes sur la résolution de spécifications de variabilité qui n’ont pas de relation de parent à enfant. Pour ce faire, CVL fournit le moyen d’exprimer des contraintes en utilisant la logique du premier ordre (incluant les quantificateurs universel et existentiel), ainsi que des contraintes arithmétiques. 2.4 Synthèse Nous avons présenté dans ce chapitre les différents champs de recherche sur lesquels nous nous appuyons dans cette thèse, à savoir l’IDM, les processus de développement logiciel et l’ingénierie des lignes de produits logiciels. Il est à noter que ces trois champs sont également très dynamiques dans le domaine de la recherche puisqu’ils ont leurs propres conférences (International Conference on Model Driven Engineering Languages and Systems, International Conference on Software and Systems Processes34 Background et International Software Product Line Conference) et qu’ils sont largement utilisés dans l’industrie [Nor08, HWRK11, Ins13]. Nous avons également présenté un langage de modélisation de processus de développement logiciel, SPEM 2.0, ainsi que CVL, un langage de modélisation permettant de spécifier et de résoudre de la variabilité sur des modèles. Dans cette thèse, nous proposons de lier des automatisations de TMR (Tâches Manuelles Récurrentes) à des processus de développement logiciel. Nous utilisons ensuite ce lien pour savoir : – quelles automatisations de TMR réutiliser pour un projet donné (en nous appuyant sur la réutilisation des processus de développement logiciel en fonction des exigences des projets), – à quels moments d’un projet les réutiliser – et pour identifier les différents cas d’utilisation de chaque automatisation de TMR et ainsi créer des automatisations de TMR qui soient réutilisables à travers ces différents cas d’utilisation. L’IDM nous offre pour ce faire deux langages de modélisation spécifiques à deux préoccupations distinctes : SPEM 2.0 et CVL. SPEM 2.0 nous permet de définir les processus de développement logiciel et nous l’avons choisi car c’est un standard de l’OMG. Il est cependant tout à fait possible d’utiliser un autre langage de modélisation de processus de développement logiciel pour mettre en œuvre l’approche proposée dans cette thèse, en fonction des besoins d’un groupe d’utilisateurs. CVL nous permet de réutiliser les processus de développement logiciel. Il a l’avantage d’appliquer les principes de l’ingénierie des lignes de produits de logiciel et de pouvoir être utilisé quel que soit le langage de modélisation de processus utilisé pour peu qu’il soit conforme au MOF. L’IDM nous offre de plus des outils (par exemple EMF) permettant l’implémentation de SPEM 2.0 et de CVL et la création de nouveaux langages de modélisation, tel qu’un langage spécifique aux automatisations de TMR. Enfin, l’utilisation d’un même métamétamodèle pour différents langages de modélisation permet de créer des liens entre ces langages. Il nous est ainsi possible de tisser les liens nécessaires dans le contexte de cette thèse, à savoir entre gestion de la variabilité et processus et entre processus et automatisations de TMR.Chapitre 3 État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus L’automatisation des TMR (Tâches Manuelles Récurrentes) liées à l’utilisation des outils de développement logiciel n’a qu’un intérêt limité si les mêmes automatisations de TMR sont re-développées pour chaque projet. La réutilisation d’automatisations de TMR amène cependant trois difficultés principales. La première est de savoir pour quels projets réutiliser une automatisation de TMR. En effet, une même automatisation de TMR peut être utile pour des projets différents, mais elle n’est pas forcément utile pour tous les projets. De plus, comme une automatisation de TMR peut avoir des dépendances avec d’autres tâches d’un projet, la deuxième difficulté est de déterminer à quels moments d’un projet utiliser une automatisation de TMR. La troisième difficulté est de s’assurer qu’une automatisation de TMR utile pour des projets différents, ou utile à des moments différents d’un même projet, soit bien réutilisable à travers ses différents cas d’utilisation. La difficulté est donc d’identifier le bon niveau de généricité d’une automatisation de TMR. Une méthodologie est proposée par Sadovykh et Abherve [SA09] afin de supporter l’exécution de processus SPEM. Elle consiste à définir un processus SPEM et à le transformer en un processus BPEL [OAS07] afin de l’exécuter. L’apport principal de cette méthodologie est que le processus BPEL obtenu par transformation est directement exécutable. Pour ce faire, la méthodologie consiste à assigner au processus SPEM, avant sa transformation, les informations nécessaires pour le rendre exécutable (ressources humaines concrètes associées aux rôles, nombre des itérations et durée des tâches). Durant l’exécution du processus BPEL, les TMR sont automatisées à l’aide de services web, qui sont reliés aux unités de travail du processus BPEL et sont appelés au moment de l’exécution de ces unités de travail. Le lien entre les services web (similaires à des automatisations de TMR) et les unités de travail du processus qu’ils automatisent permet donc de savoir quand lancer ces services web au cours d’un projet. Mais la limite de cette méthodologie est qu’elle ne propose pas de support à la sélection des 3536État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus automatisations de TMR à réutiliser pour un projet donné. Si des automatisations de TMR sont liées à des processus de développement logiciel, alors réutiliser un processus de développement logiciel pour un projet donné permet de connaître les automatisations de TMR à réutiliser pour ce projet. Or, réutiliser les processus de développement logiciel est un exercice difficile. En effet, la variabilité au niveau des exigences des projets est la source d’un nombre de processus trop élevé pour qu’un humain puisse tous les connaître et savoir quand les réutiliser [Rom05, CDCC+13]. De nombreuses approches sont donc apparues afin d’apporter un support à la réutilisation des processus de développement logiciel. Figure 3.1 – Représentation en extension des processus d’une famille [LS07] Dans le cadre de cette thèse, nous fixons certaines exigences qu’une telle approche doit satisfaire. Premièrement, elle doit permettre de définir un ensemble de processus et de dériver automatiquement un processus de cet ensemble, afin de permettre la réutilisation des processus. Deuxièmement, l’approche doit permettre de définir les différents processus à réutiliser en intention, c’est-à-dire en factorisant leurs parties communes, afin d’en faciliter la maintenance et de permettre leur réutilisation [RMvdT09, HBR10, KY12]. Plus précisément, la définition en intention de processus consiste à ne définir qu’une seule fois une partie commune à plusieurs processus et à y faire référence pour l’utiliser. À l’inverse, la définition en extension de processusSupport à la réutilisation des processus sans spécification de leur variabilité 37 consiste à les définir entièrement et indépendamment les uns des autres, en dupliquant leurs parties communes d’un processus à l’autre (mais pas nécessairement au sein d’un même processus puisque les flots de contrôle sont souvent utilisés pour retourner à une partie d’un processus). La figure 3.1, issue de [LS07], illustre la représentation en extension de différents processus d’une même famille. On remarque que ces processus partagent des parties communes qui sont dupliquées (par exemple la tâche T1). Cela pose des problèmes de maintenance car lorsqu’une de ces parties évolue, elle doit être mise à jour dans tous les processus auxquels elle appartient, ce qui est source d’erreurs et coûteux en temps. Cela limite de plus la réutilisation de fragments de processus. Troisièmement, une approche supportant la réutilisation des processus doit pouvoir s’appliquer quel que soit le formalisme utilisé pour définir les processus, afin que les utilisateurs de cette approche puissent utiliser le formalisme qui satisfait le mieux leurs exigences [Mee10, WKK+11, KY12]. Cela permet à un groupe d’utilisateurs de pouvoir changer de formalisme de définition de processus, mais cela permet également que l’approche puisse être utilisable par des groupes d’utilisateurs utilisant des formalismes différents. En plus de nous intéresser aux approches traitant de la réutilisation des processus de développement logiciel, nous nous intéressons aux approches traitant de la réutilisation des processus métiers, où un processus métier correspond à l’ensemble des tâches permettant de créer un résultat de valeur pour un client [Ham96]. En effet, un processus de développement logiciel est également un processus métier [Ben07]. De la même manière, comme un workflow, c’est-à-dire une automatisation partielle ou totale d’un processus métier [(WF99], peut être considéré comme un processus mé- tier [Ben07, LRvdADM13], et que les diagrammes d’activités UML sont parfois utilisés pour capturer les processus métiers [LRvdADM13], nous incluons dans cet état de l’art les approches traitant de la réutilisation des workflows et des diagrammes d’activités. Nous présentons les approches supportant la réutilisation de processus dans la suite de ce chapitre et nous les évaluons en fonction des exigences précédemment définies. La section 3.1 présente des approches apportant un support à la réutilisation des processus sans traiter de la spécification de leur variabilité. La section 3.2 porte sur les approches s’appuyant sur l’ingénierie des lignes de processus [Rom05] afin de réutiliser les processus, où l’ingénierie des lignes de processus est une activité similaire à l’ingénierie des lignes de produits mais où le produit est un processus. Nous faisons la synthèse de ces approches en section 3.3. 3.1 Support à la réutilisation des processus sans spécification de leur variabilité Nous présentons dans cette section des approches offrant des mécanismes pour supporter la réutilisation des processus sans pour autant permettre de spécifier leur variabilité. La section 3.1.1 traite des approches permettant d’identifier le processus correspondant le mieux à un projet. La section 3.1.2 présente des approches permettant de réutiliser des processus définis en extension. Enfin, la section 3.1.3 aborde les patrons38État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus de processus. 3.1.1 Identification du processus correspondant à un projet Les approches suivantes permettent d’identifier à quels types de projets correspondent quels types de processus, afin de faciliter le choix d’un processus pour un projet donné. Elles sont toutes assez abstraites pour pouvoir être appliquées quel que soit le formalisme de définition de processus utilisé. L’approche Promote (Process Models Taxonomy for Enlightening choices) [CDCC+13] définit un ensemble de caractéristiques de processus de développement logiciel et propose une classification de processus existants en fonction de ces caractéristiques. Les processus sont caractérisés selon 6 axes principaux : i) le cycle, c’est-à-dire la granularité des itérations, la durée du cycle de vie, les incréments, etc., ii) la collaboration, c’est-à- dire les différents types de relations qui existent entre les intervenants sur un projet iii) les artéfacts, c’est-à-dire les types de livrables qui doivent être produits, iv) l’utilisation recommandée, c’est-à-dire dans quels contextes un processus est le plus adapté, v) le niveau de maturité du processus, et vi) la flexibilité, c’est-à-dire la capacité du processus à être adapté. Cependant, Promote ne propose pas de mécanisme permettant d’obtenir un processus correspondant à un projet dans un formalisme permettant son exécution. D’autre part, la problématique de la définition d’une famille de processus en intention est en dehors des objectifs de cette approche. D’autres approches, en plus de proposer des caractéristiques pour définir les processus et les projets, proposent un support à la sélection du processus correspondant le mieux à un projet. Ainsi, l’approche de Pérez et al. [PEM95] propose une méthodologie permettant d’évaluer l’efficacité d’un processus pour un projet donnée, en fonction de leurs caractéristiques respectives. L’approche d’Alexander et Davis [AD91] fournit quant à elle une méthode permettant de déterminer le processus qui correspond le mieux à un projet donné, toujours en fonction des critères des processus et de ce projet. L’approche de Sharon et al. [SdSSB+10] propose un framework supportant la sélection du processus correspondant le mieux à un projet donné. Mais ces approches ne traitent pas de la définition d’une famille de processus et de la dérivation d’un processus de cette famille en fonction des exigences des projets. Comme résumé dans le tableau 3.1, les approches présentées ici, bien qu’indépendantes du formalisme utilisé pour définir les processus, ne fournissent pas tous les mécanismes nécessaires à la réutilisation des processus de développement logiciel. La définition en intention d’un ensemble de processus n’est de plus pas traitée par ces approches.Support à la réutilisation des processus sans spécification de leur variabilité 39 Approche Concepts proposés Apports réutilisation processus Limites réutilisation processus Déf. des pro- cessus en in- tention Indépendante du formalisme pour définir les processus Promote [CDCC+13] Caractéristiques de processus et classification de processus en fct. de ces caractéristiques Identification du pro- cessus correspondant à un projet Obtention d’un pro- cessus exécutable non oui Pérez et al. [PEM95] Méthodologie pour évaluer l’effica- cité d’un processus pour un projet donné Identification du pro- cessus correspondant à un projet Déf. d’une famille de processus et dériva- tion d’un processus non oui Alexander et Davis [AD91] Méthode pour déterminer le proces- sus qui correspond le mieux à un projet Identification du pro- cessus correspondant à un projet Déf. d’une famille de processus et dériva- tion d’un processus non oui Sharon et al. [SdSSB+10] Framework supportant la sélection du processus correspondant le mieux à un projet Identification du pro- cessus correspondant à un projet Déf. d’une famille de processus et dériva- tion d’un processus non oui Table 3.1 – Évaluation des approches permettant d’identifier le processus correspondant le mieux à un projet40État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus 3.1.2 Réutilisation de processus définis en extension D’autres approches permettent quant à elles de définir un ensemble de processus et de réutiliser des processus de cet ensemble. L’approche de Lu et Sadiq [LS07] permet l’extraction d’un processus depuis un ensemble de processus capturés dans un dépôt, en fonction des caractéristiques de ce processus. Elle définit pour ce faire une mesure de similarité, qui permet de déterminer quel est le processus du dépôt qui est le plus proche d’un ensemble de caractéristiques. Cette approche est cependant dépendante du formalisme utilisé pour définir les processus. En effet, la définition de la mesure de similarité dépend de la sémantique des éléments à comparer. De plus, l’approche est définie pour un formalisme de processus particulier et devrait donc être adaptée pour pouvoir être utilisée avec un formalisme différent. L’approche de Song et Osterweil [SO98] applique le principe de la programmation des processus [Ost87] à la méthodologie de conception logicielle BOOD (Booch Object Oriented Design Methodology) [Boo91]. Le principe de la programmation des processus suggère que les processus soient considérés comme des logiciels et soient donc conçus, développés et exécutés comme tels. Il est assez générique pour pouvoir être utilisé quel que soit le langage de modélisation de processus. BOOD est considérée comme étant l’architecture d’un processus de conception. Des processus de conception plus détaillés sont élaborés à partir de cette méthodologie puis exécutés, à l’aide du prototype DebusBooch. Celui-ci permet entre autres de sélectionner un processus de conception logiciel depuis une famille de tels processus. Il apporte de plus un support à cette sélection en fournissant des informations sur la nature des différents processus et des étapes qui les composent. Bien que permettant la réutilisation des processus, les deux approches précédentes ne proposent pas de mécanismes permettant de définir un ensemble de processus en intention, comme résumé dans le tableau 3.2. À défaut d’un tel mécanisme, les processus sont donc définis en extension. 3.1.3 Les patrons de processus Un patron de processus, ou composant de processus, est un fragment de processus réutilisable [GLKD98, ABC96, Amb99]. De nombreuses approches proposent des patrons de processus (par exemple [VDATHKB03, RHEdA05, KR10, BnCCG11, KYSR09, IMCH+07]). Ceux-ci peuvent être définis à des niveaux d’abstraction diffé- rents. Des patrons généraux devront donc être adaptés à un contexte particulier pour pouvoir être réutilisés, tandis que des patrons plus détaillés pourront être réutilisés tels quels [GLKD98, ABC96, GM05, Amb99]. Certains langages de modélisation de processus, comme SPEM 2.0 ou Little-JIL [Wis06], permettent quant à eux de définir des patrons de processus et de les intégrer à un processus. D’autre part, plusieurs approches proposent de définir des processus par réutilisation et composition de patrons de processus [GLKD98, ABC96, Zhu03, PS05, BBM05]. Elles fournissent les mécanismes nécessaires à la définition et à la composition de ces patrons. Mais, dans toutes les précédentes approches, la sélection et la composition de patrons de processus, ouSupport à la réutilisation des processus sans spécification de leur variabilité 41 Approche Concepts proposés Apports réutilisation processus Limites réutilisation processus Déf. des processus en intention Indépendante du formalisme pour définir les processus Lu et Sadiq [LS07] Extraction d’un dépôt du processus le plus proche d’un ensemble de caractéristiques Définition d’un ensemble de processus et réutilisation des processus de cet ensemble aucune non non Song et Osterweil [SO98] Application du principe de la programmation des processus à BOOD Définition d’un ensemble de processus et réutilisation des processus de cet ensemble aucune non oui Table 3.2 – Évaluation des approches de Lu et Sadiq [LS07] et Song et Osterweil [SO98] leur intégration à un processus, restent manuelles. D’autres approches apportent donc un support à la réutilisation de patrons de processus. L’outil Intelligent Workflow Designer [IMCH+07] permet la modélisation de processus métiers basée sur la réutilisation de patrons de workflows. Au moment de la modélisation d’un processus, il analyse ce processus et propose des patrons à appliquer, parmi un ensemble de patrons prédéfinis. Mais la modélisation d’un processus reste en grande partie manuelle. Un processus doit d’ailleurs être modélisé manuellement une première fois avant d’être analysé en vue de détecter les patrons qui pourraient être appliqués. L’outil ne permet pas de définir un ensemble de processus en intention et l’indépendance vis-à-vis des langages de modélisation de processus n’est pas traitée. L’approche Design by Selection [ASKW11] permet également la réutilisation de composants de processus durant la modélisation d’un processus. Un processus est dans un premier modélisé manuellement et l’approche permet de définir manuellement les parties de ce processus pour lesquelles un composant doit être réutilisé. Ces parties sont alors utilisées pour faire des requêtes sur un dépôt de composants de processus, afin de récupérer un ensemble de composants pouvant correspondre à une partie de processus. La sélection d’un composant parmi l’ensemble retourné est elle aussi manuelle, même si l’approche offre un support à cette sélection en classant les composants proposés en fonction de leur pertinence. Là encore une partie de la définition des processus reste manuelle et leur réutilisation n’est donc pas complètement automatisée. L’approche est assez abstraite pour pouvoir être appliquée indépendamment d’un langage de modélisation de processus. Mais son implémentation dépend quant à elle d’un tel langage. Cette approche ne traite pas non plus de la définition de processus42État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus en intention. L’outil CAT (Composition Analysis Tool) [KSG04] assiste un utilisateur dans la défi- nition de workflows basée sur la réutilisation de composants. CAT analyse un workflow en cours de définition et suggère des actions possibles à la personne en charge de cette définition (par exemple des ajouts ou des suppressions de composants) et s’assure que le workflow produit est correct (par exemple en vérifiant que des flots de contrôle de sont pas inconsistants avec la description d’un composant). La définition de processus reste là encore en grande partie manuelle et la spécification de processus en intention ainsi que l’indépendance vis-à-vis des langages de modélisation de processus ne sont pas abordées. Aldin [Ald10] propose une méthodologie pour l’extraction de patrons de processus métiers depuis un ensemble de processus et la réutilisation de ces patrons lors de la modélisation d’un nouveau processus métier. Un patron de processus est sélectionné en fonction des exigences correspondant à un problème métier. Il est ensuite adapté à un problème métier spécifique puis intégré au processus correspondant à ce problème métier. Cette méthodologie est assez générique pour pouvoir être appliquée quel que soit le langage de modélisation de processus utilisé. En revanche, rien n’est proposé afin d’automatiser la réutilisation des patrons de processus. La spécification en intention d’un ensemble de processus n’est pas non plus abordée. Comme résumé dans le tableau 3.3, plusieurs approches apportent un support à la réutilisation de patrons de processus, mais la définition d’un processus reste en grande partie manuelle. Ces approches ne permettent pas de capturer un ensemble de processus et d’en dériver automatiquement un processus. D’autres approches permettent quant à elles de réutiliser automatiquement un processus dont la définition s’appuie sur des patrons de processus [AB12, Ist13, BDKK04, FPLPdL01]. Nous les présentons plus en détails dans la section 3.2. 3.2 Ingénierie des lignes de processus D’autres approches s’appuient sur l’ingénierie des lignes de processus [Rom05] afin de réutiliser les processus. L’ingénierie des lignes de processus est une activité similaire à l’ingénierie des lignes de produits, mais où le produit est un processus. Les approches existantes définissent une ligne de processus en spécifiant les différents processus d’une famille ainsi que leurs parties variables et communes [Ter09]. Une ligne de processus est donc définie en intention et non en extension. Ainsi, lorsqu’une partie commune à plusieurs processus évolue, celle-ci n’est mise à jour qu’une seule fois. Il est possible de réutiliser un processus d’une famille en le dérivant de la ligne de processus. Les approches existantes s’appuient sur l’IDM afin de définir une ligne de processus et d’en dériver un processus. Nous détaillons ces approches dans la suite de cette section.Ingénierie des lignes de processus 43 Approche Concepts proposés Apports réutilisation processus Limites réutilisation processus Déf. des processus en intention Indépendante du formalisme pour définir les processus Intelligent Workflow Designer [IMCH+07] proposition de patrons à réutiliser réutilisation de patrons de workflows déf. de processus en partie manuelle non non Design by Selection [ASKW11] proposition de patrons à réutiliser réutilisation de composants de processus déf. de processus en partie manuelle non non CAT [KSG04] proposition de patrons à réutiliser réutilisation de composants de workflows déf. de processus en partie manuelle non non Aldin [Ald10] méthodologie pour la dé- couverte et la réutilisation de patrons de processus réutilisation de patrons de processus déf. de processus et réutilisation de patrons manuelles non oui Table 3.3 – Évaluation des approches apportant un support à la réutilisation de patrons de processus, mais sans permettre la réutilisation automatique de processus 3.2.1 Utilisation des mécanismes d’un langage Deux approches, d’Alegría et al. [HABQO11] et d’Alegría et Bastarrica [AB12], gèrent la variabilité des processus de développement logiciel en s’appuyant sur les mécanismes de variabilité fournis par SPEM 2.0. SPEM 2.0 offre en effet des mécanismes permettant de spécifier qu’un élément de processus est optionnel, d’ajouter des propriétés à un élément ou d’étendre ou de remplacer les propriétés d’un élément. Il permet également de définir des patrons de processus, que l’approche d’Alegría et Bastarrica permet de réutiliser automatiquement lors de la dérivation d’un processus. Cependant, ces mécanismes sont spécifiés directement dans le métamodèle de SPEM 2.0 et aucun moyen permettant de les découpler de ce métamodèle n’est proposé. En conséquence, réutiliser ces mécanismes avec un autre langage de modé- lisation de processus implique, en plus de devoir adapter ces mécanismes, de devoir modifier le métamodèle de cet autre langage.44État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus 3.2.2 Extension d’un langage de modélisation de processus Les approches de cette catégorie étendent un langage de modélisation de processus existant avec des concepts permettant de gérer la variabilité. Cependant, la plupart d’entre elles ne propose pas de mécanisme permettant d’appliquer ces concepts à un langage sans le modifier. Celles qui le font proposent quant à elles des concepts qui doivent être adaptés pour pouvoir être réutilisés avec des langages de modélisation de processus autres que celui pour lequel ils ont été initialement définis. 3.2.2.1 Utilisation de processus agrégats Figure 3.2 – Un exemple de modèle de processus agrégat [HBR10] Afin de gérer la variabilité des processus, certaines approches s’appuient sur des modèles de processus agrégats [RMvdT09]. Un processus agrégat capture les différents processus d’une famille en les combinat dans un même et unique processus à l’aide de mécanismes spécifiques à la modélisation d’un flot d’unités de travail (nœuds de décision, de jointure, de parallélisation, flots de contrôle, etc.) [KL07, RvdA07]. Par exemple, la figure 3.2 illustre un processus agrégat qui capture les différents processus d’une famille en utilisant des nœuds de décision. Néanmoins, un simple modèle de processus agrégat n’offre pas de support à la réutilisation des processus [GvdAJV07, RvdA07, HBR10]. Par exemple, il n’est pas possible de distinguer les nœuds de décision représentant des choix qui doivent être faits au moment de l’exé- cution d’un processus de ceux qui dénotent des processus différents [HBR10]. Il n’est pas non plus possible de distinguer les éléments de processus optionnels [RvdA07]. Les approches existantes proposent donc d’étendre un langage de modélisation de processus avec des mécanismes permettant d’expliciter la variabilité dans un modèle de processus agrégat, et elles offrent un support à la sélection et à la dérivation d’un processus de ce processus agrégat. Selon les approches, un processus peut ainsi être dérivé par sélection ou omission d’éléments du processus agrégat, par adaptation des éléments du processus agrégat à des exigences particulières, par ajout d’éléments spécifiques à un cas particulier, ou par instanciation (c’est-à-dire en fournissant une implémentation à un concept abstrait). Aucun moyen n’est cependant proposé afin d’étendre un langage de modélisation de processus sans le modifier. Nous présentons ces approches dans la suite de cette partie, en détaillant plus particulièrement les extensions qu’elles proposent. L’approche KobrA (KOmponenten BasieRte Anwendungsentwicklung, allemand pourIngénierie des lignes de processus 45 développement d’applications basé sur les composants) [ABM00] intègre l’ingénierie des lignes de produits logiciels et l’ingénierie logicielle basée sur les composants [Crn02]. Dans ce cadre, elle propose une notation afin de distinguer dans un processus agrégat les nœuds de décision dénotant des processus différents de ceux dénotant des choix à faire au moment de l’exécution d’un processus. L’approche Superimposed Variants [CA05] s’appuie sur les BFM (Basic Feature Model) [KCH+90] afin de gérer la variabilité de modèles et permet de faire le lien entre les BFM et les modèles desquels ils spécifient la variabilité. Cette approche étend un langage de modélisation avec des mécanismes permettant d’associer à des éléments de modèle i) des informations déterminant dans quels cas ces éléments sont sélectionnés et ii) des méta-expressions, qui spécifient comment configurer les propriétés d’un élé- ment en fonction de ses différents cas d’utilisation. Cette approche n’est pas spécifique à la gestion de la variabilité dans les processus mais est appliquée à des modèles de processus agrégats définis à l’aide de diagrammes d’activité UML 2.0. D’autres approches permettent de configurer des modèles de processus référence, où un processus de référence est un processus général qui définit les bonnes pratiques recommandées dans un domaine particulier [FL03, Fra99]. Dans ces approches, les modèles de processus de référence sont définis comme des modèles agrégats, bien que rien n’impose qu’un modèle de référence soit un modèle agrégat [Tho05]. Ainsi, l’approche C-EPC (Configurable Event-driven Process Chain) [RvdA07] permet de configurer les processus de référence définis à l’aide du langage de modélisation de processus EPC [Sch00]. Celui-ci est étendu avec des mécanismes permettant de spé- cifier qu’une unité de travail est optionnelle, qu’un connecteur (c’est-à-dire un nœud de décision, de jointure ou de parallélisation) peut être remplacé par un connecteur qui restreint son comportement, ou qu’au moment de la dérivation un seul des flots de contrôle navigables à l’issue d’un nœud de décision pourra être sélectionné. C-EPC propose également d’étendre EPC avec des mécanismes permettant d’exprimer des contraintes entre les résolutions d’éléments de modèle variables (implication, exclusion, etc.). L’approche C-iEPC (Configurable integrated EPC) [RDH+08, LRDtHM11] étend EPC avec les concepts de rôle et d’objet (où la notion d’objet est similaire à la notion de produit de travail) et avec des mécanismes permettant de spécifier que des rôles ou des objets sont optionnels, alternatifs, ainsi que le nombre minimal et maximal de rôles ou d’objets qui peuvent être sélectionnés. L’approche aEPC (Aggregate EPC) [RMvdT09] permet de déterminer les cas d’utilisation des éléments d’un processus de référence. Pour ce faire, elle étend le langage de modélisation de processus utilisé avec des mécanismes permettant d’associer aux éléments d’un modèle de processus de référence des informations déterminant dans quels cas ces éléments sont sélectionnés. L’approche Configurative Process Modeling [BDK07] étudie l’applicabilité des mécanismes utilisés pour configurer des modèles de processus de référence aux méthodes d’ingénierie logicielle. Dans ce contexte, elle propose d’étendre le formalisme utilisé pour définir une méthode logicielle avec des mécanismes permettant i) d’associer aux éléments d’une méthode des informations déterminant dans quels cas ces éléments46État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus sont sélectionnés, ii) de définir qu’un élément d’une méthode est abstrait et doit être instancié au moment de la dérivation et iii) d’associer à un élément d’une méthode des informations aidant à l’adapter aux exigences d’un projet. L’approche ADOM (Application-based DOmain Modeling) [RBSS09, RBSS10] permet de définir la variabilité d’un modèle de processus de référence, d’en dériver un processus spécifique et de vérifier qu’un processus spécifique appartient bien à la famille de processus capturée par le modèle de référence. Un processus peut être dérivé en adaptant les éléments du modèle de processus agrégat ou en lui ajoutant des éléments, en plus de pouvoir sélectionner ou omettre des éléments du processus agrégat. ADOM étend un langage de modélisation de processus avec les concepts d’indicateur de multiplicité et de classificateur de modèle de référence. Un indicateur de multiplicité permet de spécifier qu’un élément du modèle de processus de référence est optionnel, obligatoire, qu’il a des variantes et combien. Un classificateur de modèle de référence permet de spécifier à quel élément du modèle de processus de référence un élément d’un modèle de processus résolu correspond. Il permet de vérifier qu’un processus appartient bien à la famille de processus capturée par le modèle de processus de référence. L’approche Configurable Workflow [GvdAJVLR08] se concentre sur la configuration de modèles de workflows, afin de permettre la production de modèles directement exécutables. Elle propose d’étendre les unités de travail d’un langage de modélisation de workflows avec des ports d’entrée et de sortie, où un port est un endroit connectant un flot de contrôle à une unité de travail. La configuration d’un modèle de processus de référence consiste à définir si un port est activé, bloqué ou caché. Cela permet de spécifier les parties d’un workflow qui peuvent être exécutées. 3.2.2.2 Modification d’un processus de base Une limitation des approches qui s’appuient sur les modèles de processus agrégats est que lorsque les processus à capturer sont complexes et nombreux, alors le processus agrégat devient illisible et difficile à créer et à maintenir [HBR10, DB10]. Afin de faire face à cette difficulté, l’approche Provop (PROcess Variants by OPtions) [HBR10] propose de modéliser un processus de base (qui peut être un processus de référence, un processus d’une famille, le processus commun à tous les processus d’une famille, etc.) et de définir les opérations à appliquer à ce processus afin d’en dériver les différents processus d’une famille. Des points d’ajustement sont utilisés pour spécifier les parties du processus de base auxquelles des opérations sont appliquées. Cependant, aucun mécanisme n’est proposé pour définir des points d’ajustement sans modifier le langage de modélisation de processus utilisé. L’approche proposée par Mosser et Blay-Fornarino [MBF13] supporte l’évolution automatique de modèles de processus métiers, c’est-à-dire la modification automatique de modèles de processus métiers afin qu’ils soient conformes aux changements apportés à un domaine métier. Cette approche supporte également la détection d’interférences entre les évolutions apportées à un processus métier, où une interférence est une interaction entre des évolutions qui engendre un comportement non souhaité d’une ou plusieurs de ces évolutions. Une évolution est apportée à un modèle de processusIngénierie des lignes de processus 47 métier en lui composant un fragment de processus. À cette fin, le métamodèle ADORE (Activity meta-moDel supOrting oRchestration Evolution) est proposé. Il permet de définir des processus métiers, des fragments de processus ainsi que les endroits d’un processus où ces fragments peuvent être intégrés. Mais aucun mécanisme n’est proposé afin de pouvoir définir des fragments de processus ainsi que leurs points d’intégration sans modifier le langage de modélisation de processus utilisé. 3.2.2.3 Spécification des points de variation et des variantes d’un processus Plusieurs approches définissent une ligne de processus en modélisant le processus commun à tous les processus d’une famille et en spécifiant quelles sont les parties de ce processus qui varient (points de variation) et leurs différentes valeurs (variantes). Contrairement aux processus agrégats, les différents processus d’une famille ne sont pas tous intégrées dans un même processus en utilisant les mécanismes spécifiques à la modélisation d’un flot d’unités de travail. La figure 3.3 illustre un exemple de définition de points de variation et de variantes sur un modèle de processus. Elle illustre que l’unité de travail P2 est en fait un point de variation ayant pour variantes les unités de travail A1 à An. Un processus d’une famille est dérivé en remplaçant chaque point de variation par une variante, sélectionnée en fonction des exigences d’un projet. Les approches existantes étendent donc un langage de modélisation de processus avec des mécanismes permettant de définir des points de variation et des variantes. Figure 3.3 – Exemple de définition de points de variation et de variantes sur un modèle de processus [MHY08] Ainsi, l’approche vSPEM [MRGP08] étend SPEM 2.0 avec des mécanismes de variabilité évalués empiriquement comme plus compréhensibles que ceux proposés par SPEM 2.0 [MRGPM11]. Ces mécanismes permettent de définir que des activités, des produits de travail, des rôles ou des tâches sont des points de variation. Ils permettent également de définir les variantes associées à chaque point de variation ainsi que des relations de dépendance (inclusion et exclusion) entre points de variation et variantes. L’approche de Kulkarni et Barat [KB10] étend le langage de modélisation de processus BPMN (Business Process Model and Notation) [OMG11a] afin de gérer la variabilité48État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus dans les modèles de processus BPMN. L’extension proposée permet de spécifier qu’une activité ou qu’un évènement sont des points de variation, quelles sont leurs variantes, et de sélectionner les variantes à affecter aux points de variation. L’approche de Nguyen et al. [NCH11] gère la variabilité dans des services définis par des processus métiers. Elle s’attache en particulier à gérer les dépendances de variabilité entre un service et les services qui le compose. Afin de gérer la variabilité de services, elle étend BPMN avec des concepts permettant de définir des points de variation sur le séquencement d’activités, ainsi que sur les données et messages échangés par ces activités. Ces concepts permettent également de spécifier les variantes d’un point de variation ainsi que le nombre minimum et maximum de variantes qui peuvent être sélectionnées pour chaque point de variation. Trois approches, PESOA (Process Family Engineering in Service-Oriented Applications) [PSWW05], BPFM (Business Process Family Model) [MHY08] et celle proposée par Ripon et al. [RTM10], s’appuient sur les stéréotypes UML afin de spécifier la variabilité de processus capturés dans des diagrammes d’activités UML. L’approche PESOA identifie les mécanismes de variabilité pertinents pour la gestion de la variabilité dans les processus, parmi un ensemble de mécanismes existants (paramétrage, extension, remplacement, omission, ajout, etc.), et les applique aux processus. Dans ce contexte, elle propose des stéréotypes permettant de spécifier qu’une unité de travail est un point de variation, quelles sont ses variantes, si une variante peut être utilisée par défaut, si des variantes sont mutuellement exclusives et si une unité de travail est optionnelle. L’approche PESOA propose également d’utiliser les mêmes stéréotypes pour spécifier la variabilité de processus modélisés avec BPMN. Pour cela, elle propose d’étendre BPMN avec le concept de stéréotype. L’approche BPFM consiste à analyser la variabilité d’un processus métier à diffé- rents niveaux d’abstraction afin d’identifier les points de variation et les variantes de ce processus. Afin de spécifier ces derniers, elle propose des stéréotypes permettant de définir qu’une activité est optionnelle ou obligatoire, qu’elle a des variantes, le nombre minimum et maximum de variantes d’une activité qui peuvent être sélectionnées, ainsi que les dépendances entre les points de variation et les variantes. Ces stéréotypes permettent également de spécifier de la variabilité au niveau des flots de contrôle. Il est aussi possible de spécifier si de nouvelles variantes peuvent être définies au moment de la résolution. L’approche proposée par Ripon et al. se concentre sur la gestion de la variabilité dans les modèles de domaine, qui définissent les aspects conceptuels d’un système. Elle propose un stéréotype afin de spécifier les éléments d’un modèle UML qui ont des variantes. Les éléments marqués avec ce stéréotype sont également marqués avec des valeurs taguées, afin d’identifier quelles sont leurs variantes et quelles décisions un ingénieur doit prendre pour résoudre la variabilité de ces éléments. Cette approche est appliquée sur des diagrammes d’activité UML. Deux approches, l’une proposée par Ternité [Ter09] et l’autre par Ciuksys et Caplinskas [CC07], fournissent un métamodèle permettant de définir une ligne de processus. Le métamodèle proposé par Ternité permet de définir que des éléments de processus sont optionnels, obligatoires, ou alternatifs. Le métamodèle proposé parIngénierie des lignes de processus 49 Ciuksys et Caplinskas permet de spécifier de la variabilité uniquement sur des activités. Il permet de définir qu’une activité est un point de variation, quelles sont ses variantes ainsi que les dépendances entre ses variantes. Les deux métamodèles offrent également des concepts permettant de résoudre la variabilité et de spécifier les opé- rations à réaliser sur la ligne de processus afin d’en dériver un processus. Mais afin d’être concrètement utilisés, ces métamodèles doivent être spécialisés en fonction du langage de modélisation de processus. Plus précisément, les éléments d’un langage de modélisation de processus sur lesquels spécifier de la variabilité doivent hériter de certains des concepts proposés par ces métamodèles. L’approche proposée par Acher et al. [ACG+12] permet de gérer la variabilité des services qui composent un workflow, où un service est un composant qui automatise une activité de ce workflow. Des BFM sont utilisés afin de spécifier la variabilité des services. Afin de lier ces BFM aux services dont ils spécifient la variabilité, chaque service est augmenté avec un identifiant unique. Toutes les approches précédentes sont cependant dépendantes du langage de modélisation de processus utilisé. En effet, afin d’être appliquées, elles nécessitent toutes d’étendre ce langage, mais aucune approche ne propose de mécanisme permettant de réaliser cette extension sans modifier ce langage. L’approche ABIS (Adaptive Business Process Modeling in the Internet of Services) [WKK+11] introduit quant à elle des constructions pour gérer la variabilité dans des processus BPMN, mais sans modifier le métamodèle BPMN. En effet, ces constructions sont instanciées dans un fichier XML différent du fichier dans lequel sont définis les processus BPMN. Ces constructions permettent de définir de la variabilité au niveau d’une activité BPMN ou au niveau d’un attribut d’un élément de modèle BPMN. Des fragments de processus spécifient les différentes valeurs que peut prendre chaque activité variable. Des constructions sont également proposées afin de spécifier comment connecter un fragment de processus à un processus sur lequel de la variabilité est définie. Mais cette approche est dépendante de BPMN, puisque les constructions proposées doivent être adaptées pour être utilisées avec un autre langage de modélisation de processus. Par exemple, il faut définir une correspondance entre les éléments de modèle BPMN et ceux de l’autre langage pour savoir comment réutiliser les constructions proposées par ABIS. 3.2.2.4 Configuration de processus par composition L’approche proposée par Istoan [Ist13] permet de gérer la variabilité sur les aspects comportementaux d’un produit logiciel, alors que les approches actuelles se concentrent plutôt sur la gestion de la variabilité au niveau de la structure de produits logiciels. Le comportement d’un produit logiciel est défini à l’aide d’un processus mé- tier. L’approche proposée permet de définir un ensemble de fragments de processus et de composer ces fragments pour dériver le processus correspondant à un produit logiciel spécifique. Le concept d’interface est introduit afin de spécifier les éléments d’un fragment de processus qui peuvent être connectés avec d’autres fragments de processus et comment ces éléments peuvent être connectés. Cependant, aucun moyen n’est50État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus proposé afin de pouvoir définir des interfaces sans modifier le langage de modélisation de processus utilisé. 3.2.2.5 Association de plusieurs techniques L’approche Configurative Process Modeling [BDKK04] permet de créer différentes vues d’un même modèle de processus afin de ne garder que les informations qui sont pertinentes pour un groupe d’utilisateurs. Mais certains des mécanismes proposés par cette approche peuvent également être utilisés afin de configurer des modèles de processus agrégats. Ainsi, cette approche permet d’associer des termes à des élé- ments d’un modèle afin de spécifier dans quels cas ceux-ci peuvent être sélectionnés. De plus, l’approche Configurative Process Modeling a été étendue afin de permettre la configuration de processus par agrégation (c’est-à-dire par composition de fragments de processus), par instanciation (c’est-à-dire affectation d’une valeur concrète à un concept abstrait) ou par spécialisation (ajout, suppression ou modification d’éléments de modèle) [BDK07]. Cependant, pour être mis en œuvre ces mécanismes requièrent d’étendre le langage de modélisation de processus utilisé, afin de pouvoir associer à des éléments de modèles des informations concernant leurs cas d’utilisation ou afin de pouvoir définir quels sont les éléments qui peuvent être instanciés, spécialisés ou composés avec d’autres éléments. Là encore, aucun moyen n’est proposé afin de réaliser cette extension sans modifier le langage de modélisation de processus utilisé. 3.2.3 Transformation en une structure pivot Les approches de cette catégorie transforment les modèles de processus en des structures pivot sur lesquelles sont définis des mécanismes permettant de définir et de résoudre la variabilité. Une fois la variabilité résolue sur la structure pivot, une transformation de cette structure vers le métamodèle de processus utilisé permet d’obtenir un processus résolu. Les mécanismes nécessaires à la gestion de la variabilité ne sont donc plus couplés aux langages de modélisation de processus. L’approche GV2BPMN (Goal-Oriented Variability Analysis toBPMN) [SCS10] propose de transformer les modèles de processus en des modèles de buts [YLL+08], afin de faciliter la sélection d’un processus d’une famille. Un modèle de buts permet en effet de capturer les différents objectifs qu’un système doit atteindre, ainsi que la variabilité entre ces objectifs. Cette approche permet de gérer la variabilité au niveau du séquencement des unités de travail d’une famille de processus. L’approche de Meerkamm [Mee10] permet de gérer la variabilité au niveau des ressources nécessaires à la réalisation d’une unité de travail, en plus de la variabilité au niveau du séquencement de ces unités de travail. Elle permet de plus de différencier les variantes de processus (qui correspondent à des processus différents d’une même famille) des alternatives, c’est-à-dire des choix qui sont faits au moment de l’exécution d’un processus. Cette approche propose de transformer les modèles de processus en une structure arborescente qui permet de capturer à la fois les unités de travail et leurs ressources, et qui permet de gérer leur variabilité.Ingénierie des lignes de processus 51 L’approche de Kumar et Yao [KY12] permet de gérer la variabilité au niveau du sé- quencement des unités de travail d’un processus et au niveau des ressources liées à ces unités de travail. Elle permet également de découpler la logique métier des processus afin d’éviter la modification des processus lorsque la logique métier change. De plus, elle propose des techniques pour faciliter la recherche et la récupération de variantes de processus stockées dans un dépôt. Afin de gérer la variabilité des processus tout en les découplant de la logique métier, cette approche consiste à appliquer des opérations de modification à un processus afin d’en dériver des variantes. La logique métier est donc capturée dans ces opérations. Ainsi, lorsque cette logique métier change, seules les opérations sont modifiées et pas les processus. Afin que les opérations de modifi- cations puissent être réutilisées quel que soit langage de modélisation de processus, celles-ci sont définies sur une structure arborescente en laquelle sont transformés les modèles de processus. Mais ces approches restent tout de même dépendantes des langages de modélisation de processus. En effet, elles nécessitent la définition d’une transformation pour chaque langage de modélisation de processus. 3.2.4 Spécification de la variabilité sans réutilisation automatique Pour terminer, nous présentons des approches se concentrant sur la spécification de la variabilité d’une famille de processus, mais ne permettant pas la réutilisation automatique des processus de cette famille. L’approche de Razavian et Khosravi [RK08] permet de modéliser la variabilité dans les processus métiers en utilisant UML. Pour ce faire, un profil UML est proposé afin de modéliser la variabilité dans des diagrammes d’activité UML. Ce profil propose plusieurs stéréotypes permettant de spécifier la variabilité au niveau des activités, des flots de contrôle, des données consommées et produites par les activités et des magasins de données (éléments utilisés pour persister les données). Deux types de variabilité peuvent être spécifiés : l’optionnalité et les alternatives. Cette approche ne propose cependant pas de mécanisme permettant de résoudre la variabilité et de dériver un processus en fonction de cette résolution de variabilité. De plus, aucun mécanisme n’est proposé afin de pouvoir appliquer les concepts proposés pour spécifier la variabilité sans modifier le langage de modélisation de processus utilisé. L’approche de Simmonds et Bastarrica [SB11] investigue l’utilisation des BFM et des OVM (Orthogonal Variability Model) [PBL05] afin de spécifier la variabilité des processus. Les BFM sont indépendants du langage de modélisation de processus utilisé. Cependant, ils ne fournissent pas de mécanisme permettant de faire le lien avec les modèles de processus, ce qui empêche de pouvoir dériver un processus en fonction de la résolution de la variabilité spécifiée par le BFM. Les OVM fournissent quant à eux un mécanisme permettant de faire le lien avec un modèle de processus. Mais celui-ci implique de modifier le langage de modélisation de processus utilisé. En effet, afin de pouvoir définir de la variabilité sur les éléments de ce langage, ceux-ci doivent hériter de certains des éléments des OVM. D’autre part, les OVM ne fournissent pas de mécanisme pour dériver un processus.52État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus Afin de faciliter la maintenance d’une famille de processus, l’approche de Derguech et Bhiri [DB10] consiste en l’utilisation d’une structure arborescente afin de définir une famille de processus et propose un support pour mettre à jour cette structure. Les nœuds de la structure arborescente sont des fragments de processus. Lorsqu’un nœud a des enfants, cela signifie que ce nœud est un point de variation et les enfants représentent les différentes variantes de ce point de variation. Cependant, l’aspect sélection et dérivation d’un processus de cette structure arborescente n’est pas traité par cette approche. De plus, aucun mécanisme n’est proposé afin de permettre l’utilisation de cette structure indépendamment du langage de modélisation de processus utilisé. Les travaux de Simidchieva et al. [SCO07] caractérisent ce que devrait comprendre une famille de processus et introduisent une approche formelle pour définir une famille de processus en fonction de cette caractérisation. L’approche consiste à modéliser un processus de base ainsi que les éléments de processus nécessaires à la création d’autres variantes de ce processus. Une variante particulière de processus est obtenue en augmentant le processus de base à l’aide de ces éléments de processus, sélectionnés en fonction d’une spécification de buts de processus. La notion de spécification de buts de processus est proche de la notion d’exigences de projet. Cette approche est assez abstraite pour être indépendante du formalisme utilisé pour définir les processus. Cependant, elle ne fournit pas de mécanisme concret permettant d’obtenir le processus correspondant aux exigences d’un projet. Fiorini et al. [FPLPdL01] proposent une architecture de réutilisation de processus, qui permet d’organiser et de décrire des processus et de les réutiliser. Cette architecture comprend un framework de processus, qui est ici un processus capturant les différents processus d’un domaine. Certaines parties de ce framework peuvent s’appuyer sur des processus standards (par exemple CMM [Ins95]) ou des patrons de processus capturés dans un dépôt. À ce framework sont associées des directives de réutilisation, qui définissent les activités du framework qui sont obligatoires, optionnelles, celles qui doivent être spécialisées, leur contenu... Une activité peut par exemple être spécialisée en utilisant un patron de processus du dépôt, récupéré à l’aide d’une recherche par mots clés. Mais malgré ces directives, la configuration du framework reste manuelle. Il est également possible de récupérer des patrons de processus pour les réutiliser indépendamment du framework. L’architecture est assez abstraite pour être utilisée avec des langages de modélisation de processus différents. 3.2.5 Synthèse sur l’ingénierie des lignes de processus Les approches s’appuyant sur l’ingénierie des lignes de processus afin de réutiliser les processus de développement logiciel sont, à notre connaissance, dépendantes du langage de modélisation utilisé pour définir les processus de la ligne, comme résumé par le tableau 3.4. En effet, certaines utilisent les concepts natifs d’un tel langage pour gérer la variabilité d’une famille de processus. D’autres approches étendent un langage de modélisation de processus existant avec des concepts permettant de gérer la variabilité. Cependant, dans ces deux cas, il peut être nécessaire d’adapter ces concepts pour les utiliser avec un autre langage de modélisation de processus. De plus, la plu-Ingénierie des lignes de processus 53 part de ces approches ne propose pas de mécanisme permettant d’utiliser ces concepts sans modifier un langage de modélisation de processus. Or, la modification d’un tel langage implique que les outils qui lui sont spécifiques (ex : modeleurs) deviennent inutilisables à moins d’être eux-aussi adaptés. D’autres approches résolvent partiellement le problème de la dépendance vis-à-vis du langage de modélisation de processus en transformant les modèles de processus en des structures pivot permettant de gérer la variabilité. Ces approches sont cependant également dépendantes du langage de modélisation de processus. En effet, une transformation doit être définie pour chaque langage. Enfin, quelques approches se concentrent uniquement sur l’aspect spécifi- cation de la variabilité, et certaines d’entre elles sont indépendantes des langages de modélisation de processus. Mais ces approches ne permettent pas la réutilisation automatique des processus dont la variabilité a été spécifiée.54Approche Concepts proposés Apports réutilisation processus Limites État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus réutili- sation processus Déf. des processus en intention Indépendante du formalisme pour définir les processus SPEM 2.0, d’après Alegría et al. [HABQO11] et Alegría et Bastarrica [AB12] Utilisation de SPEM 2.0 Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non KobrA [ABM00] Extension d’un langage de modélisation de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Superimposed Variants [CA05] Extension d’un lan- gage de modélisation de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non C-EPC [RvdA07] Extension d’EPC Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non C-iEPC [RDH+08, LRDtHM11] Extension d’EPC Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non aEPC [RMvdT09] Extension d’EPC Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Configurative Process Modeling [BDK07] Extension d’un langage permettant de définir des mé- thodes d’ingénierie logicielle Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui nonIngénierie des lignes de processus 55 Approche Concepts proposés Apports réutilisation processus Limites réutili- sation processus Déf. des proces- sus en intention Indépendante du formalisme pour définir les processus ADOM [RBSS09, RBSS10] Extension d’un lan- gage de modélisa- tion de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Configurable Workflow [GvdAJVLR08] Extension d’un lan- gage de modélisa- tion de workflows Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Provop (PROcess Variants by OP- tions) [HBR10] Extension d’un lan- gage de modélisa- tion de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non ADORE [MBF13] Extension d’un lan- gage de modélisa- tion de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non vSPEM [MRGP08] Extension de SPEM 2.0 Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Kulkarni et Barat [KB10] Extension de BPMN Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Nguyen et al. [NCH11] Extension de BPMN Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non PESOA [PSWW05] profil UML Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non56Approche Concepts proposés Apports réutilisation processus Limites État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus réutili- sation processus Déf. des processus en intention Indépendante du formalisme pour définir les processus BPFM [MHY08] profil UML Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Ripon et al. [RTM10] profil UML Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Ternité [Ter09] Métamodèle Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Ciuksys et Caplinskas [CC07] Métamodèle Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Acher et al. [ACG+12] Extension des services qui composant un workflow Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non ABIS [WKK+11] Extension de BPMN Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Istoan [Ist13] Extension d’un langage de modélisation de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Configurative Process Modeling [BDK07] Extension d’un langage de modélisation de processus Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui nonIngénierie des lignes de processus 57 Approche Concepts proposés Apports réutilisation processus Limites réutili- sation processus Déf. des proces- sus en intention Indépendante du formalisme pour définir les processus GV2BPMN [SCS10] Transformation de modèles de proces- sus en modèles de buts Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Meerkamm [Mee10] Transformation des modèles de proces- sus en une structure arborescente Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Kumar et Yao [KY12] Transformation d’un processus en une structure arborescente Déf. d’un ensemble de processus et réutilisation des processus de cet ensemble aucune oui non Razavian et Khosravi [RK08] profil UML pour spécifier la variabi- lité dans les dia- grammes d’activités spécification de la variabilité des processus résolution de la va- riabilité, dériva- tion de processus oui non Simmonds et Bas- tarrica [SB11] BFM et OVM pour spécifier la variabi- lité des processus spécification de la variabilité des processus dérivation de proces- sus oui oui BFM, non OVM58Approche Concepts proposés Apports réutilisation processus Limites État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus réutili- sation processus Déf. des processus en intention Indépendante du formalisme pour définir les processus Derguech et Bhiri [DB10] Structure arborescente pour définir une famille de processus spécification de la variabilité des processus résolution de la variabilité, dérivation de processus oui non Simidchieva et al. [SCO07] Caractérisation du contenu d’une famille de processus et approche pour définir une telle famille spécification de la variabilité des processus dérivation de processus oui oui Fiorini et al. [FPLPdL01] Architecture de réutilisation de processus spécification de la variabilité des processus dérivation de processus oui oui Table 3.4 – Évaluation des approches s’appuyant sur l’ingénierie des lignes de processusSynthèse 59 3.3 Synthèse L’approche de Sadovykh et Abherve permet de savoir à quels moments d’un projet réutiliser des automatisations de TMR. Cette approche ne permet cependant pas de savoir pour quels projets réutiliser des automatisations de TMR. Une solution consiste donc à réutiliser les processus de développement logiciel afin de réutiliser les automatisations de TMR qui leurs sont liées. Parmi les approches supportant la réutilisation des processus de développement logiciel, certaines ne sont pas suffisantes pour mettre en œuvre cette réutilisation. D’autres approches permettent effectivement de réutiliser les processus de développement logiciel. Cependant, soit celles-ci ne proposent pas de mécanisme pour définir les processus en intention, soit elles sont dépendantes du langage de modélisation de processus utilisé. Le tableau 3.5 résume dans quelle catégorie se trouve chaque approche supportant la réutilisation des processus. En conclusion, aucune des approches existantes ne permet de définir un ensemble de processus en intention et de dériver un processus de cet ensemble, tout en étant indépendante du formalisme utilisé pour définir les processus. De plus, aucune approche ne traite la problématique de l’automatisation des processus de développement logiciel réutilisés, ce qui est loin d’être trivial. En effet, les contraintes d’un projet peuvent imposer de commencer l’exécution d’un processus alors que toutes les exigences de ce projet ne sont pas encore déterminées. Par exemple, afin de gagner du temps, il est possible de commencer l’exécution d’un processus de développement d’une application web Java (par exemple en écrivant les spécifications fonctionnelles) alors que le framework pour l’IHM de l’application à développer (par exemple Struts, JSF, Flex ou GWT) n’est pas encore choisi. Mais comment exécuter un processus s’il n’est que partiellement défini à cause des exigences non déterminées ? Approche Suffisante 1pour la réutilisation de processus Définition des processus en intention Indépendante du formalisme pour définir les processus Promote [CDCC+13] non non oui Pérez et al. [PEM95] non non oui Alexander et Davis [AD91] non non oui Sharon et al. [SdSSB+10] non non oui Lu et Sadiq [LS07] oui non non Song et Osterweil [SO98] oui non oui Intelligent Workflow Designer [IMCH+07] non non non Design by Selection [ASKW11] non non non CAT [KSG04] non non non60État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus Approche Suffisante 1pour la réutilisation de processus Définition des processus en intention Indépendante du formalisme pour définir les processus Aldin [Ald10] non non oui SPEM 2.0, d’après Alegría et al. [HABQO11] et Alegría et Bastarrica [AB12] oui oui non KobrA [ABM00] oui oui non C-EPC [RvdA07] oui oui non C-iEPC [RDH+08, LRDtHM11] oui oui non aEPC [RMvdT09] oui oui non Configurative Process Modeling [BDK07] oui oui non Superimposed Variants [CA05] oui oui non ADOM [RBSS09, RBSS10] oui oui non Configurable Work- flow [GvdAJVLR08] oui oui non Provop (PROcess Variants by OPtions) [HBR10] oui oui non vSPEM [MRGP08] oui oui non Kulkarni et Barat [KB10] oui oui non Nguyen et al. [NCH11] oui oui non PESOA [PSWW05] oui oui non BPFM [MHY08] oui oui non Ripon et al. [RTM10] oui oui non Ternité [Ter09] oui oui non Ciuksys et Caplinskas [CC07] oui oui non Acher et al. [ACG+12] oui oui non ABIS [WKK+11] oui oui non Configurative Process Modeling [BDK07] oui oui non Istoan [Ist13] oui oui nonSynthèse 61 Approche Suffisante 1pour la réutilisation de processus Définition des processus en intention Indépendante du formalisme pour définir les processus ADORE [MBF13] oui oui non GV2BPMN [SCS10] oui oui non Meerkamm [Mee10] oui oui non Kumar et Yao [KY12] oui oui non Razavian et Khosravi [RK08] non oui non Simmonds et Bastarrica [SB11] non oui oui BFM, non OVM Derguech et Bhiri [DB10] non oui non Simidchieva et al. [SCO07] non oui oui Fiorini et al. [FPLPdL01] non oui oui Table 3.5 – Évaluation de l’ensemble des approches supportant la réutilisation des processus Concernant la capacité des automatisations de TMR à être réutilisées à travers leurs différents cas d’utilisation, certaines approches supportent le développement de composants logiciels réutilisables. Par exemple, l’ingénierie des lignes de produits logiciels [PBL05] s’appuie sur la spécification de la variabilité de produits logiciels afin de produire des artéfacts de développement réutilisables. Plusieurs approches permettent d’implémenter des artéfacts réutilisables, comme par exemple la programmation orientée objet [Cox85], la programmation orientée aspect [CB05] ou encore l’ingénierie logicielle basée sur les composants [Crn02]. Mais pour être appliquées ces approches requièrent toutes au préalable d’avoir identifié la variabilité des artéfacts de développement, ce qu’elles ne permettent pas de faire. Des approches permettent quant à elle d’identifier la variabilité de composants logiciels. FORM (Feature-Oriented Reuse Method) [KKL+98] est une méthodologie mettant en œuvre l’ingénierie des lignes de produits logiciels. À ce titre, elle supporte la conception et le développement d’architectures et de composants réutilisables, et le développement de produits logiciels à partir de ces artéfacts. FORM fournit des directives permettant d’identifier la variabilité des artéfacts de développement qui réalisent des produits logiciels, en fonction de la spécification de la variabilité de ces produits logiciels. Un BFM est utilisé pour spécifier la variabilité d’un produit logiciel et l’identification de la variabilité d’un composant logiciel est basée sur l’analyse de la hiérarchie du BFM. Un exemple de directive proposée par FORM est que la hiérarchie des composants qui réalisent un produit logiciel correspond en grande partie à la 1. Comme défini page 36, une approche est suffisante pour la réutilisation de processus si elle permet de définir un ensemble de processus et de dériver un processus de cet ensemble.62État de l’art : de la réutilisation d’automatisations de TMR à la réutilisation de processus hiérarchie du BFM. L’approche de Lee et Kang [LK04] étend l’approche FORM et s’appuie sur l’analyse des dépendances opérationnelles entre les caractéristiques capturées par le BFM (c’est- à-dire lorsque la réalisation d’une caractéristique dépend de la réalisation d’autres caractéristiques) afin d’identifier la variabilité d’un composant logiciel. Un exemple de directive proposée par cette approche est que des caractéristiques alternatives peuvent implémenter une interface commune. L’approche de Lee et al. [LKCC00] étend elle aussi l’approche FORM afin d’identi- fier des objets réutilisables pour l’implémentation de composants à partir de l’analyse d’un BFM. Un exemple de directive est que des catégories d’objets peuvent être dé- duites de catégories de caractéristiques. Dans le cas de l’application de ces approches à des automatisations de TMR qui réalisent des processus de développement logiciel, le BFM spécifierait la variabilité d’une famille de processus et les automatisations de TMR seraient les composants logiciels dont la variabilité doit être identifiée. Cependant, il ne serait pas possible de réutiliser les directives proposées par ces approches telles qu’elles sont. En effet, chaque caractéristique du BFM (correspondant dans ce cas à un fragment de processus) n’est pas systématiquement réalisée par une automatisation de TMR. Ces approches ne sont donc pas adaptées pour identifier la variabilité d’automatisations de TMR. Une autre méthode permet d’identifier les parties réutilisables d’un composant en identifiant les parties communes entre les variantes des points de variation de ce composant [ZXD05]. Mais cette méthode requière au préalable d’avoir identifié les points de variation et les variantes d’un composant. Cette méthode permet donc d’aller plus loin dans l’identification de la variabilité d’un composant, mais ne peut pas être appliquée si des parties variables et communes d’un composant n’ont pas déjà été identifiées. En conclusion, il manque une approche permettant de réutiliser les processus de développement logiciel qui soit à la fois indépendante du langage de modélisation de processus utilisé, qui offre les mécanismes nécessaires à la définition en intention d’un ensemble de processus, et qui intègre réutilisation et automatisation des processus. Il manque également une approche permettant d’identifier la variabilité d’automatisations de TMR.Deuxième partie Automatisation des tâches manuelles récurrentes pilotée par les processus de développement logiciel 6365 Les travaux présentés dans cette partie ont fait l’objet d’une publication : Emmanuelle Rouillé, Benoît Combemale, Olivier Barais, David Touzet and Jean-Marc Jézéquel. Integrating Software Process Reuse and Automation. In Proceedings of the 20th Asia-Pacific Software Engineering Conference, APSEC ’13, 2013 [RCB+13b]. Nous présentons dans cette partie la contribution principale de cette thèse, à savoir notre approche pilotant la réutilisation d’automatisations de TMR (Tâches Manuelles Récurrentes) par les processus de développement logiciel. La figure 3.4 illustre le principe général de cette approche. Figure 3.4 – Principe général de la contribution principale La réutilisation des automatisations de TMR consiste dans notre approche à réutiliser les processus de développement logiciel auxquels ces automatisations sont liées. Notre approche s’appuie sur l’ingénierie des lignes de processus afin de réutiliser les processus de développement logiciel. Une ligne de processus est définie en intention et un processus peut être réutilisé en le dérivant de cette ligne, en fonction des exigences des projets. L’ingénierie des lignes de processus permet non seulement de réutiliser les processus de développement logiciel, mais également tous les fragments de processus communs à plusieurs processus, puisque ceux-ci sont factorisés (définition en intention). De plus, la définition en intention d’une famille de processus permet d’en faciliter66 la maintenance, puisque les fragments de processus communs à plusieurs processus ne sont mis à jour qu’une seule fois en cas d’évolution. D’autres part, comme des langages de modélisation de processus de développement logiciel différents sont utilisés en fonction des exigences des utilisateurs [Zam01], nous proposons, dans le chapitre 4, une approche permettant de gérer la variabilité dans les processus de développement logiciel qui est indépendante du langage de modélisation de processus utilisé. Les TMR à automatiser étant des tâches réalisées par ordinateur, nous utilisons des composants logiciels afin de les automatiser. Dans la suite de cette thèse, nous appelons composants d’automatisation (CA) un composant logiciel automatisant une TMR. Ces CA sont reliés aux unités de travail (tâches, activités...) des processus de la ligne de processus qu’ils automatisent. Cependant, un CA peut être lié à des unités de travail différentes, appartenant ou non à un même processus, ce qui peut induire de la variabilité au niveau de ce CA. Par exemple, un CA qui met du code source sous contrôle de version peut être utilisé lors de projets différents, pour lesquels le dépôt distant sur lequel partager le code source n’est pas le même. Nous proposons donc, dans le chapitre 5, une méthodologie fournissant un support à la création de CA qui soient réutilisables pour toutes les unités de travail auxquelles ils sont liés. Un processus dérivé de la ligne de processus est automatisé en lançant au fur et à mesure de son exécution les CA qui lui sont liés. Le lien entre ces CA et les unités de travail du processus qu’ils automatisent permet de savoir à quel moment de l’exécution du processus exécuter les différents CA.Chapitre 4 Gestion de la variabilité dans les processus Nous présentons dans ce chapitre notre approche permettant de gérer la variabilité dans les processus de développement logiciel indépendamment du langage utilisé pour les définir. Nous commençons par introduire dans la section 4.1 l’exemple dont nous nous servons pour illustrer cette approche. La section 4.2 détaille ensuite l’approche en elle-même. Nous discutons cette approche dans la section 4.3 et nous en faisons la synthèse dans la section 4.4. Les travaux présentés dans ce chapitre ont fait l’objet d’une publication : Emmanuelle Rouillé, Benoît Combemale, Olivier Barais, David Touzet and Jean-Marc Jézéquel. Leveraging CVL to Manage Variability in Software Process Lines. In Proceedings of the 19th Asia-Pacific Software Engineering Conference, APSEC ’12, pages 148-157, 2012 [RCB+12]. 4.1 Exemple illustratif : une famille de processus de métamodélisation Nous introduisons dans cette section un exemple de famille de processus, que nous utilisons ensuite pour illustrer l’approche proposée dans ce chapitre. Il s’agit d’une famille simplifiée de processus de métamodélisation, issue de l’équipe de recherche Triskell 1 , au sein de laquelle cette thèse a été réalisée. Un processus de métamodélisation consiste à définir et outiller un langage de modélisation spécifique à l’expression d’une préoccupation particulière, en tirant parti pour ce faire des concepts et outils 1. http://triskell.irisa.fr/ 6768 Gestion de la variabilité dans les processus Figure 4.1 – Flot de tâches de l’exemple illustratif de processus de métamodélisation Figure 4.2 – Ressources de l’exemple illustratif de processus de métamodélisation du domaine de l’IDM. Un tel langage permet de mettre en œuvre la séparation des préoccupations et ainsi maîtriser la complexité des systèmes logiciels [JCV12]. Nous introduisons d’abord un exemple simplifié de processus de métamodélisation, illustré par les figures 4.1 et 4.2. Plus précisément, la figure 4.1 illustre le flot de tâches de ce processus, tandis que la figure 4.2 illustre les ressources (outils, entrées et sorties) quiApproche 69 entrent en jeu lors de la réalisation de ces tâches. Nous détaillons ensuite des exemples de variantes de ce processus. L’exemple de processus de métamodélisation présenté ici est un processus itératif qui commence avec la définition d’un métamodèle. Des tâches parallèles suivent la définition de ce métamodèle : définition d’un éditeur textuel et d’un éditeur arborescent permettant la création de modèles conformes au métamodèle, définition d’un vérificateur permettant de vérifier qu’un modèle est bien conforme à son métamodèle, définition d’un interpréteur et définition d’un compilateur. L’outil utilisé pour définir le métamodèle et l’éditeur arborescent est EMF 2 . L’outil XText 3 est utilisé pour définir l’éditeur textuel. L’outil utilisé pour définir le vérificateur, l’interpréteur et le compilateur est Kermeta 4 , un environnement de métamodélisation. L’interpréteur est mis sous contrôle de version en utilisant SVN. Il existe des variantes de ce processus de métamodélisation. Par exemple, en fonction des exigences des projets, les tâches de définition d’un éditeur textuel ou arborescent, d’un interpréteur, d’un compilateur et d’un vérificateur peuvent ne pas avoir lieu. D’autre part, toujours selon les exigences des projets, l’outil EMFText 5 peut être utilisé à la place de XText et Git peut remplacer SVN. 4.2 Approche Des langages de modélisation de processus différents peuvent être utilisés en fonction des exigences de leurs utilisateurs. Il est donc intéressant, à des fins de réutilisation, d’avoir une approche permettant de gérer la variabilité dans les processus qui soit indépendante de ces langages. Par indépendante nous entendons qu’une approche n’ait pas à être adaptée pour être utilisée avec des langages de modélisation de processus différents et qu’elle ne nécessite pas non plus de modifier ces langages. Cela permet de pouvoir réutiliser à la fois l’approche et les langages de modélisation de processus, ainsi que les outils associés. Nous avons vu en section 2.3.2 que CVL était un langage permettant de spécifier et de résoudre de la variabilité sur des modèles, quel que soit leur métamodèle pour peu qu’il se conforme au MOF. Nous utilisons donc ici CVL afin de gérer la variabilité dans les processus de développement logiciel indépendamment de leur langage de modélisation. Nous présentons dans ce chapitre notre approche, appelée CVL4SP (CVL for Software Processes). Il s’agit de la première sous-contribution de cette thèse. La figure 4.3 illustre la partie de la contribution principale que nous détaillons ici. 2. http://www.eclipse.org/modeling/emf/ 3. http://www.eclipse.org/Xtext/ 4. http://www.kermeta.org/ 5. http://www.emftext.org70 Gestion de la variabilité dans les processus Figure 4.3 – Partie de la contribution principale réalisée par CVL4SP Figure 4.4 – Apperçu de l’approche consistant à utiliser CVL pour gérer la variabilité dans les processus de développement logicielApproche 71 Figure 4.5 – Processus de l’approche consistant à utiliser CVL pour gérer la variabilité dans les processus de développement logiciel72 Gestion de la variabilité dans les processus Comme illustré par la figure 4.4, le principe général de CVL4SP consiste à utiliser le VAM (Variability Abstraction Model, cf. section 2.3.2) de CVL afin de capturer la variabilité des exigences des projets. Nous utilisons le modèle de base de CVL afin de capturer les éléments de processus nécessaires pour définir la famille de processus attendue. Ce modèle de base devient alors un modèle de processus de base. Grâce au VRM (Variability Realization Model, cf. section 2.3.2) de CVL, nous faisons le lien entre la variabilité des exigences des projets capturée dans le VAM et les éléments de processus du modèle de processus de base. Plus précisément, nous utilisons le VRM afin de définir comment dériver un processus du modèle de processus de base en fonction des exigences des projets. Nous utilisons le RM (Resolution Model, cf. section 2.3.2) afin de sélectionner les exigences pour un projet donné. Enfin, le modèle résolu de CVL contient le processus dérivé du modèle de processus de base en fonction des exigences sélectionnées dans le RM. On parle alors de modèle de processus résolu. Notre approche préserve la séparation entre les exigences des projets et les processus, puisque les aspects exigences et processus sont définis dans des modèles distincts (le VAM et le modèle de processus de base), qui ne sont pas liés directement l’un à l’autre mais par l’intermédiaire du VRM. Cela permet donc de pouvoir réutiliser et faire évoluer les aspects exigences et processus indépendamment l’un de l’autre. De plus, en capturant dans le VAM la variabilité des exigences des projets et non la variabilité des processus, notre approche permet de relier directement les exigences des projets aux processus, en évitant une couche intermédiaire de définition de la variabilité des processus. La figure 4.5 présente le processus de notre approche. Elle implique deux rôles : un expert processus, qui connaît les différents processus d’une entreprise ainsi que leurs contextes d’utilisation, et un utilisateur d’une ligne de processus, qui est impliqué dans un projet et a besoin d’un processus spécifique à ce projet. L’expert processus capture la variabilité des exigences des projets et fait le lien entre ces exigences et une ligne de processus (étapes 1 à 3). Ensuite, l’utilisateur de cette ligne de processus lance la dérivation automatique d’un processus (de cette ligne) en fonction des exigences d’un projet spécifique (étapes 4 et 5). Les étapes 4 et 5 ont lieu à chaque fois qu’un utilisateur d’une ligne de processus souhaite dériver un processus. L’expert processus et l’utilisateur d’une ligne de processus utilisent l’outillage associé à CVL pour réaliser les étapes 2 à 5. N’importe quel langage de modélisation de processus de développement logiciel peut être utilisé pour réaliser l’étape 1. Nous détaillons dans la suite de cette section les différentes étapes de notre approche. Nous les illustrons à l’aide de l’exemple illustratif introduit dans la section 4.1. 4.2.1 Définition de la ligne de processus de développement logiciel 4.2.1.1 Méthodologie pour la modélisation des éléments de processus (étape 1) Approche L’expert processus modélise ici les éléments de processus requis pour définir la famille de processus attendue. Dans un premier temps, l’expert processus modélise, dans un modèle de processusApproche 73 de base, le processus de l’entreprise le plus souvent utilisé. Nous ne traitons pas dans cette thèse de la manière de déterminer le processus le plus souvent utilisé. Ensuite, l’expert processus modélise tous les autres éléments de processus qui n’appartiennent pas au processus le plus souvent utilisé et qui sont requis pour créer des variantes de ce processus. Dans la suite, nous appellerons ces éléments de processus des éléments de processus externes. Ces éléments de processus externes sont ajoutés au modèle contenant le processus le plus souvent utilisé (c’est-à-dire le modèle de processus de base), mais sans les relier à ce processus. Même si plusieurs processus utilisent un même élément de processus externe, celui-ci n’est modélisé qu’une seule fois dans le modèle de processus de base, afin de respecter la définition en intention de processus. De ce fait, quand un élément de processus commun à plusieurs processus évolue, il ne faut le mettre à jour qu’une seule fois. Quand différents processus utilisent un même élément de processus externe, ils peuvent requérir différentes valeurs pour les propriétés de cet élément de processus externe. Dans ce cas, dans le modèle de processus de base, l’expert processus affecte aux propriétés de cet élément de processus les valeurs correspondant au processus le plus utilisé parmi les processus qui utilisent cet élément de processus externe. Nous détaillons maintenant comment notre méthodologie s’applique dans le cas de la modélisation avec SPEM 2.0. L’expert processus commence par modéliser les éléments de contenu de méthode qui serviront à définir le processus le plus souvent utilisé ainsi que les éléments de processus externes. L’expert processus modélise ensuite le processus le plus souvent utilisé ainsi que les éléments de processus externes dans différentes activités représentant des processus. De cette manière, il n’y a pas d’opération à effectuer sur le modèle de processus de base pour dériver le processus le plus souvent utilisé. En effet, en SPEM 2.0, un processus décrivant le cycle de vie complet d’un projet est décrit dans un type d’activité particulier, le processus. De cette manière, le processus le plus souvent utilisé est déjà décrit dans ce type d’activité. Il est possible de modéliser le processus de base différemment. Par exemple, toutes les variantes de processus peuvent être modélisées dans le même processus en utilisant des branchements conditionnels. Il est également possible de modéliser des éléments de processus sans modéliser les relations entre eux et de les composer au moment de la dérivation. Une autre possibilité est de modéliser le processus commun à tous les processus d’une famille ainsi que les éléments de processus qui varient, sans les relier au processus commun. Par rapport à ces autres approches, notre méthodologie permet à un humain de visualiser directement au moins un processus d’une famille, qui plus est le processus le plus souvent utilisé de cette famille. Illustration Nous détaillons maintenant le modèle de processus de base dans le cas de l’exemple illustratif de la famille de processus de métamodélisation. La figure 4.6 illustre les éléments de contenu de méthode de la famille de processus de métamodélisation. La définition de tâche définir métamodèle produit en sortie la définition de produit de travail métamodèle et requiert l’utilisation de l’outil EMF. Les définitions de tâche définir éditeur arborescent, définir éditeur textuel, définir vérificateur, définir compilateur et définir interpréteur prennent en entrée la définition de produit de travail métamodèle, et74 Gestion de la variabilité dans les processus produisent respectivement en sortie les définitions de produit de travail éditeur arborescent, éditeur textuel, vérificateur, compilateur et interpréteur. Comme pour les éléments de processus externes, on ne modélise que les propriétés correspondant au processus le plus utilisé qui utilise ces éléments de contenu de méthode. Ainsi, la définition de tâche définir éditeur textuel utilise la définition d’outil XText et non pas la définition d’outil EMFText, et la définition de tâche définir interpréteur utilise la définition d’outil SVN et non pas Git. Figure 4.6 – Eléments de contenu de méthode de l’exemple illustratif Comme illustré par la figure 4.7, le processus le plus utilisé de la famille de processus de métamodélisation consiste uniquement en la définition d’un métamodèle et d’un éditeur arborescent. Figure 4.7 – Processus le plus souvent utilisé de l’exemple illustratif La figure 4.8 illustre les fragments de processus représentant les éléments de processus externes de la famille de processus de métamodélisation. Ces éléments de processusApproche 75 externes sont les tâches définir éditeur textuel, définir vérificateur, définir interpréteur et définir compilateur, avec leurs produits de travail respectifs (éditeur textuel, vérificateur, interpréteur et compilateur). Les éléments de processus externes comprennent également un nœud de jointure et un nœud de parallélisation, ainsi que les flots de contrôle nécessaires à la dérivation de processus de métamodélisation autres que celui qui est le plus utilisé. Figure 4.8 – Eléments de processus externes de l’exemple illustratif 4.2.1.2 Spécification de la variabilité des exigences des projets (étape 2) Approche Dans la seconde partie de notre approche, l’expert processus s’appuie sur le VAM de CVL afin de spécifier la variabilité des exigences des projets. Illustration La figure 4.9 présente un extrait du VAM des exigences des différents projets de métamodélisation de l’exemple illustratif. On y voit que les définitions d’un interpréteur, d’un compilateur, d’un vérificateur, d’un éditeur arborescent ainsi que d’un éditeur textuel (respectivement représentées par les choix interpréteur, compilateur, vérificateur, éditeur arborescent et éditeur textuel) sont des tâches optionnelles. La définition d’un éditeur textuel peut être réalisée soit avec l’outil XText soit avec l’outil EMFText (respectivement représentés par les choix XText et EMFText). L’utilisation d’un SCV (Système de Contrôle de Version), représenté par le choix SCV, est obligatoire, et il s’agit soit de SVN, soit de Git (respectivement représentés par les choix SVN et Git). Ce VAM contient également des choix dont la résolution est dérivée (éditeur textuel parallèle, vérificateur parallèle, compilateur parallèle, interpréteur parallèle, éditeur arborescent parallèle et parallélisation). Le choix parallélisation est automatiquement sélectionné lorqu’au moins deux tâches optionnelles de la famille de processus de métamodélisation sont sélectionnées. Chacun des choix éditeur textuel parallèle, vérifi- cateur parallèle, compilateur parallèle, interpréteur parallèle et éditeur arborescent parallèle est76 Gestion de la variabilité dans les processus automatiquement sélectionné si le choix parallélisation est sélectionné et si le choix de nom correspondant (c’est-à-dire éditeur textuel pour éditeur textuel parallèle, vérificateur pour vérificateur parallèle, ...) est également sélectionné. Ces choix dont la résolution est dérivée ne reflètent pas la variabilité au niveau des exigences des projets. Nous allons voir par la suite qu’ils sont utiles pour savoir quelles opérations effectuer sur le modèle de processus de base afin de dériver un processus. Figure 4.9 – Extrait du VAM de l’exemple illustratif 4.2.1.3 Liaison entre les exigences des projets et les processus (étape 3) Approche Dans la troisième étape de notre approche, l’expert processus définit dans un VRM la liaison entre la variabilité des exigences des projets (définie à l’étape 2 dans le VAM) et les processus (définis à l’étape 1 dans le modèle de processus de base). Le VRM spécifie comment dériver un processus du modèle de processus de base en fonction des exigences des projets. Illustration La figure 4.10 représente un extrait du VRM de l’exemple illustratif suffisant pour dériver un processus de métamodélisation avec définition d’un éditeur arborescent et d’un interpréteur. Pour des raisons de lisibilité, nous avons scindé ce VRM en deux dans les sous-figures 4.10(a) et 4.10(b). Dans la sous-figure 4.10(a), l’activité métamodélisation représente le processus le plus souvent utilisé. La première série d’opérations consiste à mettre dans ce processus les éléments de processus externes dont on a besoin pour dériver un processus en fonction des exigences. Ainsi, si le choix interpréteur est sélectionné, alors il faut mettre la tâche définir interpréteur, ses flots de contrôle entrants et sortants, ainsi que le produit de travail interpréteur dans l’activité métamodélisation. Si le choix parallélisation est sélectionné, cela signifie qu’au moins deux tâches optionnelles auront été sélectionnées et donc que le processus dérivé contiendra de la parallélisation car les tâches optionnelles sont exécutées en parallèle dans notre exemple. Il faut donc, dans ce cas, mettre le nœud de parallélisation, son flot de contrôle entrant, le nœud de jointure et son flot de contrôle sortant dans l’activité métamodélisation. Détaillons maintenant la sous-figure 4.10(b). Si le choix parallélisation est sélectionné,Approche 77 alors la source du flot de contrôle entrant du nœud de parallélisation doit être affectée à la tâche définir métamodèle. Le flot de contrôle sortant du nœud de jointure doit de plus être affecté au nœud de décision. Si le choix éditeur arborescent parallèle est sélectionné, cela signifie que le processus dérivé contiendra des tâches parallèles, et que la tâche définir éditeur arborescent en fera partie. Il faut donc, dans ce cas, affecter la source du flot de contrôle entrant de la tâche définir éditeur arborescent au nœud de parallélisation et il faut affecter la cible du flot de contrôle sortant de la tâche définir éditeur arborescent au nœud de jointure. De manière similaire, si le choix interpréteur parallèle est sélectionné, alors il faut affecter la source du flot de contrôle entrant de la tâche définir interpréteur au nœud de parallélisation et il faut affecter la cible du flot de contrôle sortant de la tâche définir interpréteur au nœud de jointure. Enfin, si l’outil Git est sélectionné (choix Git sélectionné), alors il faut remplacer l’outil SVN par l’outil Git. (a) Première partie du VRM (b) Deuxième partie du VRM Figure 4.10 – Extrait du VRM de l’exemple illustratif78 Gestion de la variabilité dans les processus 4.2.2 Dérivation d’un processus en fonction des exigences d’un projet 4.2.2.1 Résolution de la variabilité des exigences des projets (étape 4) Approche Un utilisateur de la ligne de processus précédemment définie résout la variabilité des exigences des projets. Il sélectionne pour ce faire dans le RM de CVL les exigences pour un projet donné, parmi les exigences spécifiées dans le VAM. Illustration La figure 4.11 présente un extrait du RM pour un processus de métamodélisation, avec uniquement éditeur arborescent, interpréteur et SVN comme choix sélectionnés. Les choix dérivés sont automatiquement résolus en fonction de la résolution des autres choix. Ici, seuls les choix dérivés parallélisation, interpreteur parallèle et éditeur arborescent parallèle sont sélectionnés. Figure 4.11 – Extrait du RM de l’exemple illustratif 4.2.2.2 Dérivation automatique de processus (étape 5) Approche La dernière étape de notre approche consiste à dériver automatiquement le processus correspondant aux exigences d’un projet donné. Dans ce but, nous utilisons le moteur de dérivation de CVL afin de permettre à l’utilisateur de la ligne de processus de dériver un modèle de processus depuis le modèle de processus de base (étape 1), en fonction i) des exigences sélectionnées dans le RM (étape 4), et ii) de la réalisation de la variabilité capturée dans le VRM (étape 3). Cette étape produit un modèle de processus résolu. Si un projet a des besoins spécifiques qui ne se retrouvent pas dans d’autres projets, alors l’utilisateur de la ligne de processus peut adapter manuellement le modèle de processus résolu à ces besoins, à l’issue de la dérivation automatique de ce modèle de processus. En effet, il n’est pas utile de capitaliser des besoins spécifiques à un projet dans une ligne de processus si ces besoins ne se retrouvent pas dans d’autres projets. Illustration Comme illustré par la figure 4.12, le processus résolu correspondant au RM de la figure 4.11 est un processus de métamodélisation avec les étapes de définitionApproche 79 d’un métamodèle, d’un éditeur arborescent, d’un interpréteur, et avec le SCV SVN. Figure 4.12 – Modèle de processus résolu 4.2.3 Exécution d’un processus résolu La difficulté au moment de l’exécution d’un processus dérivé d’une ligne de processus réside dans le fait qu’en fonction des contraintes d’un projet, ce processus peut être exécuté alors que sa variabilité n’est que partiellement résolue. Par exemple, afin de gagner du temps, il est possible de démarrer l’exécution d’un processus de développement d’une application web en Java (par exemple en écrivant les spécifications fonctionnelles) alors que le framework pour l’IHM de l’application à développer (par exemple Struts 6, JSF 7 (Java Server Faces), Flex 8 ou GWT 9 (Google Web Toolkit)) n’a pas encore été choisi. Dans ce cas, l’automatisation de l’exécution du processus peut donner lieu à des erreurs à cause de la variabilité non résolue. En effet, si une partie d’un processus contient de la variabilité non résolue, alors : – soit cette partie de processus est dans un état où elle n’est pas exécutable par un outil, car elle possède des éléments considérés comme invalides par cet outil (par exemple un flot de contrôle qui ne pointe vers rien) ; – soit cette partie est dans un état exécutable, mais qui ne correspond pas à l’état dans lequel elle aurait dû être si la variabilité avait été résolue. Dans ce cas, le résultat de l’exécution ne sera pas celui attendu. Afin de gérer les cas où la variabilité du processus en cours d’exécution n’est que partiellement résolue, notre approche consiste à demander à l’acteur courant du processus de résoudre la variabilité d’un fragment de processus dont la variabilité n’est que partiellement résolue au moment de l’exécution de ce fragment. 6. http://struts.apache.org/ 7. http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html 8. http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html 9. http://www.gwtproject.org/80 Gestion de la variabilité dans les processus 4.3 Discussion Nous discutons dans cette section de la capacité de CVL à gérer la variabilité des processus en fonction de la variabilité des exigences des projets (section 4.3.1), de l’indépendance de CVL vis-à-vis des métamodèle de processus (section 4.3.2), de la validité du modèle de processus résolu (section 4.3.3), ainsi que des extensions possibles à la méthodologie proposée pour définir le modèle de processus de base (section 4.3.4). 4.3.1 Capacité de CVL à gérer la variabilité des processus en fonction de la variabilité des exigences des projets Selon notre approche, le VAM capture la variabilité des exigences des projets, tandis que le VRM spécifie le lien entre cette variabilité des exigences et le modèle de processus de base. Le VRM permet de refléter directement la variabilité des exigences des projets sur les processus. Ces trois modèles (VAM, VRM et modèle de processus de base) constituent donc la définition d’une ligne de processus de développement logiciel. CVL permet ensuite à un utilisateur de cette ligne de processus i) de sélectionner les exigences pour un projet donné dans un RM et ii) de dériver automatiquement un modèle de processus depuis le modèle de processus de base en fonction de ce RM. CVL permet donc bien de gérer la variabilité des processus de développement logiciel en fonction de la variabilité des exigences des projets. 4.3.2 Indépendance de CVL vis-à-vis des métamodèles de processus Actuellement, le seul lien entre CVL et les modèles métiers pour lesquels il permet de gérer la variabilité est fait par l’intermédiaire des points de variation, qui permettent de faire des références aux éléments du modèle de base. Ces références sont faiblement couplées aux éléments du modèle de base. En effet, CVL utilise une chaîne de caractères dans les éléments de modèle de type ObjectHandle et LinkHandle pour référencer les éléments du modèle de base. Dans son état actuel, CVL est donc bien indépendant du langage sur lequel il s’applique. Nous allons cependant voir dans la section suivante que le couplage faible entre CVL et les langages sur lesquels il s’applique peut être à l’origine d’erreurs dans le modèle de processus résolu. 4.3.3 Validité du modèle de processus résolu Nous avons observé que l’opérateur de dérivation de CVL pouvait produire un modèle de processus résolu invalide (c’est-à-dire non conforme à son métamodèle), alors que les VAM, VRM et RM sont valides. Dans la suite de cette section, nous identifions les sources possibles de cette invalidité, et nous les classifions en fonction de la manière de les éviter. Le premier type d’erreur que nous avons observé concerne les affectations (affectation d’attribut, paramétrable ou non) ou les substitutions (substitution de fin de lien,Discussion 81 substitution de fin de lien paramétrable, substitution d’objet, substitution d’objet paramétrable, substitution de fragment) qui ne respectent pas la compatibilité de type avec le modèle de base. Ces erreurs constituent la première catégorie que nous avons identifiée. Elles ont lieu parce que CVL ne contraint pas la spécification du VRM en fonction du métamodèle auquel il s’applique. L’expression de contraintes génériques sur le métamodèle de CVL permettrait d’assurer la validité du VRM par rapport au métamodèle du modèle auquel il s’applique. Par exemple, le problème de compatibilité de type mentionné plus haut dans le contexte d’une substitution de fin de lien pourrait être évité en utilisant la contrainte suivante exprimée avec OCL (Object Constraint Language) [OMG10] sur le métamodèle de CVL : 1 c on t e x t LinkEndSubstitution inv: 2 -- où ’find ’ résoud l’URI d’un élément de modèle , ’getRef ’ retourne la référence , dont le nom est passé en paramètre , de l’élément de modèle sur lequel est appelée la fonction , ’OclType ’ retourne le type de l’élément de modèle sur lequel il est appelé et ’isOfType ’ retourne vrai si le type sur lequel il s’applique est du même type que le type passé en paramètre. 3 find(self. replacementObject .MOFRef).OclType.isOfType(find(self.link.MOFRef). getRef(self. linkEndIdentifier ).OclType) Cette contrainte spécifie en effet que dans le cas d’une substitution de fin de lien, l’objet correspondant à la nouvelle valeur d’un lien doit être du même type que la référence que ce lien instancie. Le second type d’erreur concerne le non-respect de la multiplicité d’une référence. Par exemple, lorsqu’une référence avec une borne inférieure n et une borne supérieure p est instanciée par m liens, avec m < n ou m > p. Cela a lieu lorsqu’une substitution de fin de lien ou une substitution de fin de lien paramétrable (une existence de lien) crée (supprime) un lien, rendant ainsi le nombre de liens instanciant une référence supérieur (inférieur) à sa borne supérieure (inférieure). Cela a également lieu durant une substitution de fragment, car CVL permet de créer et de supprimer des liens entrants et sortants au fragment remplaçant et à ses copies, sans assurer le respect de la multiplicité des références dont ces liens sont instances. Finalement, ce type d’erreur peut aussi arriver lors de l’exécution d’un point de variation composite, quand le conteneur du conteneur configurable ne peut pas contenir une nouvelle instance du conteneur configurable. Afin de prévenir ce type d’erreur, certaines contraintes doivent être respectées au moment de la dérivation. Un nouveau lien ne doit pouvoir être instance d’une référence dont la borne supérieure est strictement supérieure à un que si le nombre de liens qui sont déjà instances de cette référence est strictement plus petit que la borne supérieure de cette référence. Un lien peut être supprimé seulement si la référence dont il est instance avant sa suppression a un nombre de liens strictement supérieur à sa borne inférieure. Un fragment de processus peut être dupliqué seulement si ses liens entrants peuvent également être dupliqués tout en assurant le respect de la multiplicité des références dont ils sont instances. Un point de variation composite peut être exécuté seulement si le conteneur du conteneur configurable peut contenir un conteneur configurable de plus. Le troisième type d’erreur concerne le non-respect des propriétés d’un métamodèle82 Gestion de la variabilité dans les processus capturées à l’aide d’un langage de contraintes. Ce type d’erreur peut apparaître à la suite de l’exécution de n’importe quel type de point de variation. Les second et troisième types d’erreur constituent la seconde catégorie d’erreurs que nous avons identifiée. Ces erreurs sont possibles parce que CVL ne contraint pas la spécification du VRM en fonction du modèle de base auquel il s’applique et en fonction du métamodèle de ce modèle de base. Une solution pour assurer les contraintes des second et troisième types d’erreur serait un outil générique d’analyse statique qui vérifierait avant la dérivation si ces contraintes sont satisfaites. Par générique, nous entendons indépendant du métamodèle du modèle de processus de base. Il est possible d’implémenter un tel outil en raisonnant sur le métamétamodèle MOF, commun à tous les modèles de processus de base, et non pas sur un métamodèle particulier. Si ces contraintes ne sont pas satisfaites, l’outil informerait alors l’utilisateur de la ligne de processus de la contrainte qui a été violée et du point de variation ayant introduit cette violation. L’expert processus et l’utilisateur de la ligne de processus devraient alors corriger l’erreur pour pouvoir commencer la dérivation. La quatrième erreur apparaît quand le modèle de processus résolu est bien conforme à son métamodèle, mais est sémantiquement inconsistant. Un modèle de processus peut être sémantiquement inconsistant dans deux cas : soit lorsque ce modèle est trop permissif vis-à-vis d’un métier spécifique, soit lorsque ce modèle est incohérent. La figure 4.13 illustre le cas d’un modèle incohérent. En SPEM 2.0, une séquence de travail spécifie les dépendances au moment de l’exécution d’activités. Ici, la séquence de travail de type finishToFinish signifie que l’activité B peut finir quand l’activité A est terminée. La séquence de travail finishToStart signifie que l’activité B peut commencer quand l’activité A est terminée. Ici la séquence de travail de type fi- nishToFinish est inutile car elle est automatiquement respectée si la séquence de travail de type finishToStart l’est. Afin d’éviter ce problème, on doit s’assurer qu’il n’y a pas d’inconsistances au niveau de la sémantique dans le modèle de processus résolu. Figure 4.13 – Séquence de travail sur-spécifiée Ce quatrième type d’erreur constitue la troisième catégorie que nous avons identi- fiée. L’origine de ces erreurs est l’utilisation d’un métamodèle de processus non adapté à un domaine métier ou permettant la création de modèles incohérents. Comme CVL ne contraint pas la spécification du VRM en fonction du modèle de base et de son mé- tamodèle, les erreurs de la troisième catégories peuvent avoir lieu. Cependant, dans ce cas, les erreurs sont spécifiques à un métamodèle et ne peuvent pas être généralisées. Nous proposons deux solutions pour éviter ces erreurs. L’une préserve l’indépendance vis-à-vis du métamodèle de processus, l’autre non. La première solution serait de modifier le métamodèle du modèle de processus résolu afin qu’il ne permette plus de définir des instances incohérentes et qu’il satisfasse les contraintes d’un domaine mé- tier spécifique. La deuxième solution serait d’implémenter un moteur de dérivationDiscussion 83 spécifique au métamodèle de processus utilisé (ici SPEM). Il assurerait que durant la dérivation des contraintes spécifiques à ce métamodèle soient satisfaites, en plus d’effectuer les mêmes opérations que le moteur de dérivation générique de CVL. Dans le cas où une contrainte spécifique au métamodèle ne serait pas respectée, le moteur de dérivation informerait l’utilisateur de la ligne de processus de l’étape de dérivation qui a introduit cette erreur et de la contrainte qui a été violée. Le choix entre la première et la deuxième solution dépend de leur coût de mise en œuvre. En effet, dans le cas de la première solution, la modification du métamodèle de processus implique de modifier les outils le supportant (éditeurs, compilateurs, interpréteurs...). En contrepartie, on peut continuer à utiliser le moteur de dérivation générique de CVL. Cette solution pré- serve donc l’indépendance de CVL vis-à-vis du langage de modélisation de processus utilisé. La deuxième solution, étant donné qu’elle n’implique pas de modifier le métamodèle de processus, n’implique pas non plus de mettre à jour les outils supportant ce métamodèle. Elle impose en revanche de définir un moteur de dérivation spécifique à un métamodèle de processus, lorsque celui-ci n’est pas parfaitement adapté à un mé- tier ou lorsqu’il permet la création d’instances incohérentes. Il incombe donc à chaque utilisateur de CVL de déterminer la solution qui lui convient le mieux, en fonction de ses ressources et des erreurs qu’il souhaite éviter. En conclusion, même s’il est actuellement possible de dériver un modèle de processus résolu invalide, cela ne remet pas en cause l’indépendance actuelle de CVL vis-à-vis du métamodèle du modèle de base et du modèle résolu, et il existe des solutions à ce problème qui préservent cette indépendance. 4.3.4 Extension possible à la méthodologie pour modéliser le processus de base La modélisation des éléments de processus externes peut conduire à des modèles qui ne sont pas conformes à leur métamodèle. En effet, comme les éléments de processus externes sont modélisés indépendamment d’un processus, certains ne respectent pas toutes les contraintes imposées par leur métamodèle. Par exemple, le modèle de la figure 4.8 n’est pas conforme au métamodèle des diagrammes d’activité UML. En effet, tous les flots de contrôle n’ont pas forcément à la fois une source et une cible, alors que le métamodèle des diagrammes d’activité UML l’impose. Puisque certains modeleurs de processus (par exemple, SPEM-Designer 10) ne permettent pas de modéliser des éléments de processus invalides, l’application de la méthodologie que nous proposons pour définir le modèle de processus de base peut se révéler difficile. Nous proposons donc d’utiliser des approches (par exemple [RBJ07]) permettant de générer des élé- ments de modèles en fonction de contraintes prédéfinies afin de gérer ce cas. Il serait ainsi possible de générer les éléments de modèles que les modeleurs ne permettent pas de modéliser, et également de générer les éléments de modèles manquants pour les rendre valides. Ces éléments de modèle générés ne seraient bien entendu pas utilisés pour dériver des processus de la ligne de processus. 10. http://marketplace.eclipse.org/content/spem-designer-helios-version84 Gestion de la variabilité dans les processus 4.4 Synthèse Nous avons proposé dans ce chapitre une approche permettant de gérer la variabilité des processus de développement logiciel en fonction des exigences des projets, et ce quel que soit le langage de modélisation de processus utilisé pour peu qu’il se conforme au MOF. Notre approche s’appuie sur CVL afin de spécifier et de résoudre la variabilité dans les processus. Nous avons fait le choix de CVL car il préserve la séparation des préoccupations entre l’aspect gestion de la variabilité et l’aspect métier dont on souhaite gérer la variabilité. Il est donc possible de réutiliser les concepts et outils spécifiques à ces aspects, sans qu’ils soient impactés par des préoccupations externes. D’autre part, bien que CVL permette actuellement de dériver des modèles résolus invalides, il existe des solutions permettant de prévenir ce problème. Ces solutions ont également l’avantage de préserver l’indépendance vis-à-vis du domaine métier dont la variabilité est gérée. De plus, CVL permet de définir en intention les différents processus d’une famille. Il permet en effet, dans le modèle de processus de base, de ne définir qu’une seule fois les éléments de processus communs à plusieurs processus, et il fournit des mécanismes permettant d’intégrer ces éléments à un processus au moment de la dérivation. Cela facilite la maintenance d’une famille de processus puisque les redondances entre les différents processus sont évitées. Cela facilite également la réutilisation des fragments de processus communs à plusieurs processus d’une famille. D’autre part, notre approche préserve la séparation entre exigences et processus et elle permet de refléter directement la variabilité des exigences sur les processus, plutôt que de passer par une couche intermédiaire définissant la variabilité des processus. Enfin, la méthodologie que nous proposons pour définir le modèle de processus de base a l’avantage d’expliciter le processus d’une famille qui est le plus souvent utilisé.Chapitre 5 Création de composants d’automatisation réutilisables Nous avons vu au début de cette partie que la réutilisation des CA (Composants d’Automatisation, c’est-à-dire composants logiciels automatisant des TMR) était réalisée via la réutilisation des processus de développement logiciel auxquels ces CA sont liés. Chaque CA peut être lié à des processus différents ou à des unités de travail différentes d’un même processus, constituant ainsi des cas d’utilisation différents d’un CA. Nous présentons donc dans ce chapitre notre méthodologie fournissant un support à la création de CA réutilisables à travers tous leurs cas d’utilisation. Nous commençons par introduire, dans la section 5.1, l’exemple dont nous nous servirons pour illustrer cette méthodologie, qui est elle-même détaillée dans la section 5.2. Nous discutons cette méthodologie dans la section 5.3 et nous en faisons la synthèse dans la section 5.4. Les travaux présentés dans ce chapitre ont fait l’objet d’une publication : Emmanuelle Rouillé, Benoît Combemale, Olivier Barais, David Touzet and Jean-Marc Jézéquel. Improving Reusability in Software Process Lines. In Proceedings of the 39th Euromicro Conference on Software Engineering and Advanced Applications, SEAA ’13, pages 90-94, 2013 [RCB+13a]. 5.1 Exemple illustratif : automatisation de la configuration de l’espace de travail local d’un développeur Nous présentons dans cette section l’exemple dont nous nous servirons pour illustrer la méthodologie fournissant un support à la création de CA réutilisables. Il s’agit d’un script PowerShell qui automatise la configuration de l’espace de travail local d’un 8586 Création de composants d’automatisation réutilisables développeur. Ce script est utilisé pendant les projets de développement Java de l’entreprise Sodifrance. Il est exécuté au début de l’activité de développement par chaque développeur du projet. Il est également exécuté à chaque fois qu’un nouveau développeur intègre un projet de développement Java dont l’activité de développement est déjà commencée. La figure 5.1 montre un extrait de ce script PowerShell, sur lequel notre méthodologie n’a pas encore été appliquée (c’est-à-dire que le script est configuré pour être utilisé avec un projet particulier). Il prend en paramètre (ligne 1) le chemin de l’espace de travail local d’un développeur (wsPath), ainsi que les URL des dépôts contenant le code source de l’application en cours de développement (sourceUrl) et le code de build (buildUrl). Le code de build correspond à des ressources, autres que le code source, utiles à la configuration de l’espace de travail local d’un développeur. Le script automatise les étapes suivantes : 1. import, en utilisant SVN, du code source (ligne 10) et du code de build (ligne 13), 2. compilation Maven des projets Java et alimentation initiale du dépôt Maven local si nécessaire (ligne 18), 3. configuration Maven des projets Eclipse (ligne 19), 4. configuration Maven de l’espace de travail Eclipse (ligne 20), 5. import Buckminster des projets dans l’espace de travail Eclipse (à partir de la ligne 23). 5.2 La méthodologie Nous constatons que les CA peuvent contenir de la variabilité. En effet, un même CA peut être lié à des unités de travail différentes appartenant à un même processus, représentant alors des contextes d’utilisation différents de ce CA. Par exemple, dans le cas d’un processus de métamodélisation comprenant des étapes de définition d’un mé- tamodèle, d’un éditeur textuel et d’un éditeur arborescent, un CA pourrait automatiser la mise sous contrôle de version de code source lors de toutes ces étapes. De plus, une même unité de travail peut varier en fonction des exigences d’un projet (par exemple utilisation de Git au lieu de SVN), créant ainsi encore plus de contextes d’utilisation différents d’un CA. La variabilité au niveau des contextes d’utilisation d’un CA crée, quant à elle, de la variabilité au niveau des CA eux-mêmes. Par exemple, l’implémentation d’un CA qui fait de la mise sous contrôle de version sera différente selon le SCV utilisé, ou selon l’adresse du dépôt distant utilisé. Une difficulté supplémentaire concernant la réutilisation des CA est donc d’identifier les parties d’un CA qui varient et celles qui ne varient pas (c’est-à-dire identifier le niveau de réutilisation d’un CA), afin ensuite d’être capable d’implémenter des CA qui soient réutilisables à travers leurs différents contextes d’utilisation (en utilisant par exemple des mécanismes tels que le paramétrage, la modularisation...). Pour ce faire, nous présentons dans cette partie une méthodologie permettant d’améliorer l’identification du niveau de réutilisation de CA. Nous appelons cette méthodologie M4RAC (Methodology for Reusable Automation Components). Elle constitue la deuxième sous-contribution de cette thèse. La figure 5.2La méthodologie 87 1 Param ([ string] $wsPath , [string] $sourceUrl , [string] $buildUrl ) 2 3 # Variable settings 4 $sourcePath = $wsPath + "/ source" 5 $buildPath = $wsPath + "/ build" 6 7 [...] 8 9 # Checkout of source code from URL $sourceUrl to folder $sourcePath 10 svn checkout $sourceUrl $sourcePath 11 12 # Checkout of build code from URL $buildUrl to folder $buildPath 13 svn checkout $buildUrl $buildPath 14 15 # Run Maven commands to compile and configure Eclipse projects and to configure the workspace 16 $sourcePom = $sourcePath + "/ pom.xml" 17 [...] 18 mvn compile -f $sourcePom 19 mvn eclipse:eclipse -f $sourcePom 20 Invoke - Expression (" mvn -D eclipse. workspace =" + $wsPath + " eclipse:configure - workspace ") 21 22 # Run Buckminster commands to import projects into the workspace 23 $buckyBuild = $buildPath + "/ buckybuild . properties " 24 [...] 25 $cQueryFile = $buildPath + "/ org.eclipse. buckminster . myproject .build/ buckminster / myproject -build.cquery" 26 buckminster import --properties $buckyBuild -data $wsPath $cQueryFile 27 [...] Figure 5.1 – Extrait d’un script PowerShell qui automatise la configuration de l’espace de travail d’un développeur illustre la partie de la contribution principale que nous détaillons ici, tandis que la figure 5.3 montre le processus de la méthodologie. Nous expliquons plus en détails ce processus dans la suite de cette section.88 Création de composants d’automatisation réutilisables Figure 5.2 – Partie de la contribution principale réalisée par M4RACLa méthodologie 89 Figure 5.3 – Vue générale de M4RAC90 Création de composants d’automatisation réutilisables Figure 5.4 – Première étape de M4RAC Figure 5.5 – Exemple simplifié de ligne de processus de développement Java 5.2.1 Définition d’une ligne de processus de développement logiciel (étape 1) 5.2.1.1 Méthodologie La première étape de M4RAC, illustrée par la figure 5.4, implique comme rôle un expert processus, tout comme pour CVL4SP (chapitre 4). Cet expert processus définit une ligne de processus de développement logiciel en utilisant CVL4SP. 5.2.1.2 Illustration La figure 5.5 montre un exemple simplifié de ligne de processus de développement Java. Dans le modèle de processus de base (à droite sur la figure 5.5), le processus le plus souvent utilisé est composé des tâches spécifier, développer et tester, et les outils SVN et Maven servent à réaliser la tâche développer. Le modèle de processus de base contient également un élément de processus externe, l’outil Git. Le VAM (à gaucheLa méthodologie 91 Figure 5.6 – Deuxième étape de M4RAC sur la figure 5.5) spécifie qu’un SCV (correspondant sur la figure au choix SCV) est obligatoirement utilisé pendant un projet de développement Java (correspondant sur la figure au choix développement Java), et que ce SCV peut être soit Git (correspondant sur la figure au choix Git) soit SVN (correspondant sur la figure au choix SVN). Le VRM, au centre de la figure 5.5, spécifie quant à lui que si Git est choisi comme SCV, alors, dans le modèle de processus de base, l’outil SVN doit être remplacé par l’outil Git. 5.2.2 Spécification des composants d’automatisation (étape 2) 5.2.2.1 Méthodologie La figure 5.6 met en évidence la deuxième étape de M4RAC. Cette étape implique comme rôle un architecte, c’est-à-dire une personne ayant l’expérience et le recul nécessaire pour identifier des TMR qui gagneraient à être automatisées, et capable de concevoir des CA automatisant ces TMR. Lors de la deuxième étape de M4RAC, l’architecte spécifie les CA abstraits qui sont utiles pour l’entreprise dans laquelle il travaille, à l’aide d’un modeleur de CA abstraits. Un CA abstrait est une définition conceptuelle d’un CA, où l’architecte spécifie uniquement qu’un CA existe et ce qu’il automatise, sans rentrer dans les détails de conception et d’implémentation. Durant cette étape, l’architecte ne se préoccupe pas de l’identification du niveau de réutilisation de ces CA, ni de leur conception et de leur implémentation. Il se préoccupe uniquement de la spécification, de manière abstraite, des CA existants ainsi que des CA futurs. Il détermine les CA futurs en identifiant les TMR qui gagneraient à être automatisées, et en supposant dans un premier temps que chacune de ces tâches sera automatisée par un CA.92 Création de composants d’automatisation réutilisables Figure 5.7 – Troisième étape de M4RAC 5.2.2.2 Illustration Un exemple de CA spécifié à l’issue de la deuxième étape de M4RAC est le CA dont le but est de configurer l’espace de travail local d’un développeur. 5.2.3 Liaison entre les CA et leurs contextes d’utilisation (étape 3) 5.2.3.1 Méthodologie Au moment de la troisième étape de M4RAC, mise en évidence par la figure 5.7, l’architecte modélise les liens entre les CA abstraits (spécifiés à l’étape 2) et les unités de travail (par exemple les tâches) de la ligne de processus qu’ils contribuent à automatiser. Il utilise pour ce faire un modeleur de liaisons, où ici le terme liaisons dé- signe les liens entre les CA et les unités de travail qu’ils automatisent. Si plusieurs CA contribuent à automatiser une même unité de travail, alors la liaison spécifie l’ordre dans lequel ces CA doivent s’exécuter. Si une unité de travail varie, alors la liaison spécifie quelle variante de cette unité de travail un CA contribue à automatiser. On considère qu’une unité de travail varie soit si l’unité de travail elle-même varie, soit si ce sont les éléments de modèle directement reliés à cette unité de travail (ex : outils, rôles, produits de travail, flots de contrôle) qui varient. Finalement, la liaison spécifie si un CA contribue à automatiser l’initialisation, l’exécution ou la finalisation d’une unité de travail. Définir une initialisation (une finalisation) pour une unité de travail est utile car cela permet d’empêcher l’oubli de cette initialisation (finalisation). En effet, l’initialisation (finalisation) est dans ce cas fortement couplée à l’unité de travail qu’elle initialise (finalise). Ce n’est pas le cas quand l’initialisation (la finalisation) est remplacée par une unité de travail qui a lieu avant (après) l’unité de travail initialisée (finalisée). Cette étape permet donc d’identifier les contextes d’utilisation des CA. Plus pré- cisément, ce sont les unités de travail liées à un CA, leurs ressources (c’est-à-dire lesLa méthodologie 93 Figure 5.8 – Liaison entre le CA configurant l’espace de travail d’un développeur et la ligne de processus de la figure 5.5 outils, les rôles et les produits de travail), leurs itérations et leur séquencement qui définissent les contextes d’utilisation des CA. En effet, les variantes des unités de travail qu’un CA automatise sont ses contextes d’utilisation. Et c’est la spécification des variantes de ressources, itérations et séquencement associés à une unité de travail qui définit quelle variante d’unité de travail est considérée. De plus, nous verrons dans la prochaine partie de cette thèse que les unités de travail et leurs ressources fournissent les données (par exemple l’URL d’un dépôt) requises pour exécuter les CA. 5.2.3.2 Illustration La figure 5.8 illustre la liaison entre le CA configurant l’espace de travail local d’un développeur et la ligne de processus de la figure 5.5. Le CA configurant l’espace de travail local d’un développeur contribue à l’automatisation de l’initialisation de toutes les variantes (c’est-à-dire en utilisant Git ou SVN) de la tâche développer. Cela permet donc d’identifier que ce CA a deux contextes d’utilisation : l’un lorsque SVN est utilisé comme SCV, et l’autre lorsque c’est Git qui est utilisé à la place de SVN. 5.2.4 Conception des composants d’automatisation (étape 4) 5.2.4.1 Méthodologie Lors de la quatrième étape deM4RAC, mise en évidence par la figure 5.9, l’architecte conçoit les CA spécifiés de manière abstraite à l’étape 2. Pendant cette étape, le modèle de liaisons permet d’améliorer l’identification du niveau de réutilisation des CA. En effet, en réfléchissant à comment concevoir un CA de manière à ce qu’il soit réutilisable à travers ses différents contextes d’utilisation, l’architecte est capable de déterminer son niveau de réutilisation, c’est-à-dire les parties de ce CA qui varient et celles qui ne varient pas. Une fois cette information établie, l’architecte conçoit des CA réutilisables en s’appuyant sur des mécanismes tels que le paramétrage ou la modularisation. En concevant les CA, l’architecte peut se rendre compte que le modèle de liaisons est incorrect. Par exemple, un CA peut contenir des parties inutiles pour certains de ses contextes d’utilisation. Il sera donc, dans ce cas, plus judicieux de diviser ce CA en plusieurs CA afin de pouvoir sélectionner uniquement les parties de ce CA utiles94 Création de composants d’automatisation réutilisables Figure 5.9 – Quatrième étape de M4RAC pour chaque contexte d’utilisation. Dans ce cas, l’architecte revient à l’étape 3 afin de corriger le modèle de liaisons. 5.2.4.2 Illustration Comme abordé dans la section 5.1, la configuration de l’espace de travail local d’un développeur se compose de 5 étapes : 1. import du code source et du code de build depuis un dépôt distant, 2. compilation Maven des projets Java et alimentation initiale du dépôt Maven local si nécessaire, 3. configuration Maven des projets Eclipse, 4. configuration Maven de l’espace de travail Eclipse, 5. import Buckminster des projets dans l’espace de travail Eclipse. Le CA configurant l’espace de travail local d’un développeur doit donc réaliser ces 5 étapes. Or, l’étape 3 de M4RAC a permis de déterminer que ce CA pouvait être utilisé dans deux contextes différents : avec Git ou avec SVN. Cela permet donc de déterminer le niveau de réutilisation de ce CA, à savoir que ses parties dépendantes d’un SCV (étape 1 de la configuration de l’espace de travail local d’un développeur) peuvent varier tandis que les autres non (étapes 2 à 5 de la configuration de l’espace de travail local d’un développeur). L’architecte doit donc assurer que l’étape 1 soit découplée des étapes 2 à 5 de la configuration de l’espace de travail local d’un développeur, de manière à pouvoir réutiliser les étapes 2 à 5 indépendamment du SCV. Une manière de réaliser ce découplage est d’avoir trois CA : deux CA réalisant l’étape 1, l’un avec SVN (CA 1) et l’autre avec Git (CA 2), et un CA réalisant les étapes 2 à 5 (CA 3). L’initialisation de la tâche de développement serait alors effectuée par l’exécution des CA 1 puis 3 lorsque le SCV est SVN, et par l’exécution des CA 2 puis 3 lorsque leLa méthodologie 95 SCV est Git. Le modèle de liaisons réalisé lors de l’étape précédente de M4RAC est également mis à jour, afin de refléter cette conception, comme illustré par la figure 5.10. Figure 5.10 – Liaisons entre les CA permettant de configurer l’espace de travail d’un développeur et la ligne de processus de la figure 5.5 5.2.5 Implémentation des composants d’automatisation (étape 5) 5.2.5.1 Méthodologie Figure 5.11 – Cinquième étape de M4RAC Finalement, lors de la dernière étape de M4RAC, mise en évidence par la figure 5.11,96 Création de composants d’automatisation réutilisables un développeur implémente les CA en fonction de leur conception (étape 4 deM4RAC). 5.2.5.2 Illustration Le script PowerShell de la figure 5.1 correspond à une implémentation de la confi- guration de l’espace de travail local d’un développeur, dans le cas où SVN est utilisé comme SCV. Il sert de base à la création des trois CA conçus lors de l’étape 4 de M4RAC. Les scripts des figures 5.12, 5.13 et 5.14 correspondent respectivement à l’implémentation des CA 1, 2 et 3 identifiés précédemment. 1 Param ([ string] $wsPath , [string] $sourceUrl , [string] $buildUrl ) 2 3 # Variable settings 4 $sourcePath = $wsPath + "/ source" 5 $buildPath = $wsPath + "/ build" 6 7 [...] 8 9 # Checkout of source code from URL $sourceUrl to folder $sourcePath 10 svn checkout $sourceUrl $sourcePath 11 12 # Checkout of build code from URL $buildUrl to folder $buildPath 13 svn checkout $buildUrl $buildPath Figure 5.12 – Extrait du CA automatisant l’étape 1 de la configuration de l’espace de travail d’un développeur, avec SVN 1 Param ([ string] $wsPath , [string] $sourceUrl , [string] $buildUrl ) 2 3 # Variable settings 4 $sourcePath = $wsPath + "/ source" 5 $buildPath = $wsPath + "/ build" 6 7 [...] 8 9 # Checkout of source code from URL $sourceUrl to folder $sourcePath 10 git clone $sourceUrl $sourcePath 11 12 # Checkout of build code from URL $buildUrl to folder $buildPath 13 git clone $buildUrl $buildPath Figure 5.13 – Extrait du CA automatisant l’étape 1 de la configuration de l’espace de travail d’un développeur, avec Git 5.3 Discussion Nous discutons dans cette partie M4RAC. Cette discussion porte sur ses bénéfices, ses limitations, ainsi que ses inconvénients.Discussion 97 1 Param ([ string] $wsPath) 2 3 # Variable settings 4 $sourcePath = $wsPath + "/ source" 5 $buildPath = $wsPath + "/ build" 6 7 # Run Maven commands to compile and configure Eclipse projects and to configure the workspace 8 $sourcePom = $sourcePath + "/ pom.xml" 9 [...] 10 mvn compile -f $sourcePom 11 mvn eclipse:eclipse -f $sourcePom 12 Invoke - Expression (" mvn -D eclipse. workspace =" + $wsPath + " eclipse:configure - workspace ") 13 14 # Run Buckminster commands to import projects into the workspace 15 $buckyBuild = $buildPath + "/ buckybuild . properties " 16 [...] 17 $cQueryFile = $buildPath + "/ org.eclipse. buckminster . myproject .build/ buckminster / myproject -build.cquery" 18 buckminster import --properties $buckyBuild -data $wsPath $cQueryFile 19 [...] Figure 5.14 – Extrait du CA automatisant les étapes 2 à 5 de la configuration de l’espace de travail d’un développeur 5.3.1 Bénéfices Notre méthodologie fournit deux bénéfices principaux pour identifier le niveau de réutilisation de CA. Le premier bénéfice de notre méthodologie est qu’elle aide l’architecte à identifier les différents contextes d’utilisation des CA. C’est parce qu’elle permet de spécifier les différents contextes d’utilisation des CA. En effet, chez Sodifrance, nous avons répertorié au moins 512 processus de développement Java possibles en pratique, identifiés suite à l’interview d’un chef de projet. Il est bien sûr impossible pour un humain d’avoir en tête ces différents processus et les différents contextes d’utilisation de tous les CA. Le second bénéfice de notre méthodologie est qu’elle empêche l’architecte de considérer de la variabilité inutile. Cela prévient donc la conception et l’implémentation de CA inutiles. Le fait que M4RAC permette d’expliciter la variabilité des processus ainsi que les contextes d’utilisation des CA est la raison de ce bénéfice. Par exemple, dans le cas d’un CA en charge d’automatiser la mise sous contrôle de version du code source d’un projet, l’architecte pourrait concevoir trois variantes de ce CA : une utilisant CVS, une autre utilisant SVN et encore une autre utilisant Git. En effet, l’architecte pourrait déjà avoir utilisé ces trois SCV sur des projets différents. Cependant, l’architecte pourrait ne pas être au courant que CVS n’est plus utilisé (dans l’hypothèse où il est possible de déterminer que c’est le cas). Dans ce cas, implémenter un CA automatisant la mise sous contrôle de version du code source d’un projet en utilisant CVS serait une perte de temps. En revanche, si CVS n’est plus utilisé, alors il n’apparaîtra pas dans la ligne de processus comme un SCV possible. De ce fait, en appliquant notre méthodologie,98 Création de composants d’automatisation réutilisables l’architecte aurait réalisé que CVS n’était plus utilisé. Il n’aurait alors pas conçu un CA inutile. 5.3.2 Une limitation Une limitation de notre méthodologie est que son efficacité dépend des langages utilisés pour définir la ligne de processus. En effet, si ces langages ne permettent pas de capturer certaines informations concernant les contextes d’utilisation des CA (par exemple certains métamodèles de processus ne permettent pas de capturer une définition d’outil), alors l’architecte ne peut dans ce cas pas s’appuyer sur la ligne de processus pour identifier tous les contextes d’utilisation des CA. L’architecte ne peut alors s’appuyer que sur sa propre connaissance pour identifier les contextes d’utilisation qui ne sont pas capturés par la ligne de processus. Ceci est moins efficace que de s’appuyer sur la ligne de processus. En effet, l’architecte peut oublier des contextes d’utilisation ou peut considérer des contextes d’utilisation inutiles. 5.3.3 Un inconvénient Un inconvénient de M4RAC est qu’il est difficile d’identifier les contextes d’utilisation des CA. En effet, avec la définition en intention des processus, il est difficile pour un humain de visualiser explicitement chacun des processus de la ligne. Par exemple, l’architecte peut avoir des difficultés à visualiser ce qui se passe avant et après une variante d’unité de travail, et donc il peut avoir des difficultés à déterminer à quelles unités de travail il est pertinent d’associer un CA. La définition de processus en extension n’est pas une solution satisfaisante à ce problème. En effet, plus le nombre de processus est élevé, plus il est tout aussi difficile pour un humain d’identifier les différents contextes d’utilisation des CA. Une solution serait d’avoir un outil support à l’identification des contextes d’utilisation des CA (étape 3 de M4RAC). Celui-ci pourrait par exemple calculer et afficher les différents processus d’une famille en fonction de leur spécification en intention, et afficher également les CA associés aux unités de travail de ces différents processus, au fur et à mesure de leur association. Afin de limiter le nombre de processus affichés, une idée serait de définir des contextes d’utilisation de CA similaires, et donc de n’afficher qu’un seul de ces contextes. De plus, cet outil pourrait vérifier la consistance entre des pré et post-conditions associées aux CA, afin de détecter d’éventuelles erreurs au moment de l’association d’un CA à une unité de travail. 5.4 Synthèse Nous avons proposé, dans ce chapitre, une méthodologie qui permet d’améliorer l’identification du niveau de réutilisation d’un CA. Le principe de cette méthodologie consiste à lier chaque CA aux unités de travail qu’il contribue à automatiser dans une ligne de processus. Cela permet d’identifier les différents contextes d’utilisation de chacun de ces CA. Ensuite, en réfléchissant à la conception d’un CA afin qu’il soitSynthèse 99 réutilisable à travers ses différents contextes d’utilisation, il est possible d’identifier le niveau de réutilisation de ce CA. Cette méthodologie permet d’expliciter les différents contextes d’utilisation d’un CA. De ce fait, cela permet à l’architecte en charge de la conception des CA de ne pas oublier certains contextes d’utilisation et de ne pas prendre en compte des contextes d’utilisation inutiles. Une limitation de cette méthodologie en revanche est que son efficacité dépend des langages utilisés pour définir la ligne de processus. En effet, les contextes d’utilisation que la ligne de processus peut capturer dépendent des informations que les langages utilisés pour définir la ligne de processus permettent de capturer. D’autre part, avoir un outil permettant d’expliciter les différents processus d’une ligne ainsi que les CA déjà associés à ces processus aiderait l’architecte à identifier les contextes d’utilisation des CA.100 Création de composants d’automatisation réutilisablesTroisième partie Outillage et application 101103 Dans cette partie, nous commençons par présenter dans le chapitre 6 l’outil que nous avons développé afin de démontrer la faisabilité de l’approche proposée dans cette thèse. Ensuite, dans le chapitre 7, nous appliquons cet outil à une famille de processus de métamodélisation ainsi qu’à une famille de processus de développement web Java issue de Sodifrance.104Chapitre 6 Outil pour la gestion de la variabilité et l’automatisation des processus Ce chapitre traite de l’outil développé comme support à l’approche proposée dans cette thèse. Nous commençons par introduire, en section 6.1, l’exemple dont nous nous servons pour présenter cet outil. La vue générale de l’outil est présentée en section 6.2 et son implémentation est décrite en section 6.3. Nous présentons, dans la section 6.4, des éléments de méthodologie relatifs à l’utilisation de l’outil, ainsi que des extensions possibles. Enfin, nous faisons la synthèse de ce chapitre dans la section 6.5. 6.1 Exemples de tâches manuelles récurrentes Cette section introduit les exemples de TMR (Tâches Manuelles Récurrentes) utilisés pour illustrer l’utilisation de l’outil développé dans cette thèse. Ces TMR, issues de l’exécution de processus de la famille des processus de métamodélisation (présentée dans la section 4.1), gagneraient à être automatisées. Elles correspondent à la manière de réaliser des processus de métamodélisation dans l’équipe de recherche Triskell. Il existe d’autres manières de réaliser des processus de métamodélisation qui ne sont pas traitées ici (utilisation d’un outil autre que Kermeta, utilisation différente d’EMFText, etc.). TMR Unité de travail pendant laquelle la TMR a lieu Étape de l’unité de travail Itération Création projet EMF et fichier Ecore vide déf. métamodèle initialisation première Validation métamodèle déf. métamodèle finalisation toutes 105106 Outil pour la gestion de la variabilité et l’automatisation des processus TMR Unité de travail pendant laquelle la TMR a lieu Étape de l’unité de travail Itération Création fichier contenant la syntaxe concrète du métamodèle déf. éditeur arborescent initialisation première Mise à jour fichier contenant la syntaxe concrète du métamodèle déf. éditeur arborescent initialisation à partir de la seconde Génération éditeur arborescent déf. éditeur arborescent finalisation toutes Génération syntaxe textuelle déf. éditeur textuel avec EMFText initialisation première Génération éditeur textuel déf. éditeur textuel avec EMFText finalisation toutes Création projet XText déf. éditeur textuel avec XText initialisation première Génération éditeur textuel déf. éditeur textuel avec XText finalisation toutes Création projet Kermeta initilisé avec un appel à une fonction Kermeta qui vérifie qu’un modèle respecte bien les contraintes définies sur son métamodèle déf. vérificateur initialisation première Création projet Kermeta et application patron de conception interpréteur au métamodèle déf. interpréteur initialisation première Application patron de conception interpréteur aux nouvelles métaclasses du métamodèle déf. interpréteur initialisation à partir de la seconde Mise sous contrôle de version interpréteur déf. interpréteur finalisation première Propagation, sur un dépôt partagé, du code source de l’interpré- teur déf. interpréteur finalisation toutes Création projet Kermeta et application patron de conception visiteur au métamodèle déf. compilateur initialisation première Application patron de conception visiteur aux nouvelles métaclasses du métamodèle déf. compilateur initialisation à partir de la seconde Table 6.1 – Exemples de TMR réalisées durant un processus de métamodélisationExemples de tâches manuelles récurrentes 107 Nous avons identifié 16 exemples de TMR. Le tableau 6.1 les répertorie et précise pour chacune d’elle l’unité de travail, son étape (initialisation, exécution ou finalisation), ainsi que l’itération de processus concernées. Deux TMR sont liées à la définition d’un métamodèle. La première consiste à créer un projet EMF ainsi qu’un fichier Ecore vide, qui contiendra plus tard la définition d’un métamodèle. Cette TMR a lieu au moment de l’initialisation de la définition d’un métamodèle, lors de la première itération. La seconde TMR consiste à valider un métamodèle et a lieu au moment de la finalisation de la définition d’un métamodèle, à chaque itération. Trois autres TMR sont liées à la définition d’un éditeur arborescent. Celle-ci est initialisée par la création d’un fichier destiné à contenir la syntaxe concrète du mé- tamodèle, lors de la première itération. La mise à jour de ce fichier a lieu lors des itérations suivantes, toujours à l’initialisation. À chaque itération, la définition d’un éditeur arborescent est finalisée par la génération de l’éditeur en lui-même. Quatre TMR sont liées à la définition d’un éditeur textuel. Si celui-ci est défini avec EMFText, alors, dans le cadre de cet exemple, la TMR consistant à générer la syntaxe textuelle est réalisée à l’initialisation, lors de la première itération. Si l’éditeur textuel est défini avec XText, alors la TMR consistant à créer un projet XText est réalisée, à l’initialisation et lors de la première itération également. Dans les deux cas, la définition d’un éditeur textuel se termine par la TMR consistant à générer l’éditeur en lui-même. Une TMR concerne la définition d’un vérificateur. Elle consiste à créer un projet Kermeta et à l’initialiser avec un appel à une fonction Kermeta vérifiant qu’un modèle respecte bien les contraintes définies sur son métamodèle. Elle a lieu au moment de l’initialisation, lors de la première itération. Quatre TMR concernent la définition d’un interpréteur. Au moment de l’initialisation, lors de la première itération, une TMR crée un projet Kermeta et applique le patron de conception interpréteur à chaque méta-classe du métamodèle. Lors des itérations suivantes, la définition d’un interpréteur est initialisée par une TMR appliquant le patron de conception interpréteur seulement aux nouvelles méta-classes du métamodèle. Le cas des méta-classes du métamodèle supprimées ou modifiées n’est pas traité dans cet exemple. Lors de la première itération, la définition d’un interpréteur est finalisée par la TMR consistant à mettre l’interpréteur sous contrôle de version. De plus, à chaque itération, une TMR de propagation du code de l’interpréteur sur un dépôt distant a également lieu au moment de la finalisation. Enfin, deux TMR sont liées à la définition d’un compilateur. La première consiste à créer un projet Kermeta et à appliquer le patron de conception visiteur à chaque métaclasse du métamodèle. Elle initialise la définition d’un compilateur et n’a lieu que lors de la première itération. La deuxième TMR applique le patron de conception visiteur seulement aux nouvelles méta-classes du métamodèle. Elle initialise la définition d’un compilateur à partir de la deuxième itération. Tout comme pour la définition d’un interpréteur, le cas des méta-classes du métamodèle supprimées ou modifiées n’est pas non plus traité dans cet exemple. D’autres TMR non spécifiques au processus de métamodélisation, comme la confi- guration de l’environnement de développement, la configuration de l’environnement108 Outil pour la gestion de la variabilité et l’automatisation des processus d’intégration continue ou la configuration du schéma de compilation, peuvent également être réalisées dans ce contexte. 6.2 Vue générale de l’outil Figure 6.1 – Vue générale de l’architecture de T4VASP T4VASP (Tool for Variability management and Automation of Software Processes) est l’outil que nous avons développé pour valider l’approche proposée dans cette thèse . La figure 6.1 illustre ses composants : – un modeleur de VAM (Variability Abstraction Model, modèle spécifiant la variabilité (section 2.3.2 et chapitre 4)), – un modeleur de VRM (Variability Realization Model, modèle définissant comment dériver un modèle résolu du modèle de base, en fonction de la résolution de la variabilité (section 2.3.2 et chapitre 4)), – un assistant à la résolution de la variabilité, – un moteur de dérivation CVL,Vue générale de l’outil 109 – un modeleur de CA (Composants d’Automatisation, composants logiciels automatisant des TMR (partie II)) abstraits, – un modeleur de liaisons, – un framework supportant l’implémentation des CA – et un interpréteur de processus. Les modeleurs de VAM et de VRM permettent respectivement de produire des VAM et des VRM. L’assistant à la résolution de la variabilité permet de résoudre la variabilité d’un VAM (donc permet de sélectionner les exigences pour un projet particulier) et produit un RM (Resolution Model, modèle permettant de résoudre la variabilité définie dans un VAM (section 2.3.2 et chapitre 4)). Le moteur de dérivation de CVL permet de dériver un modèle de processus résolu, en fonction d’un modèle de processus de base, d’un VRM et d’un RM. Le modèle de processus de base est produit à l’aide d’un modeleur de processus SPEM que nous réutilisons. Le modeleur de CA abstraits permet, comme son nom l’indique, de spécifier des CA abstraits, qui sont des définitions conceptuelles de CA (cf. section 5.2.2). Le modeleur de liaisons permet quant à lui de lier les CA abstraits i) aux unités de travail qu’ils contribuent à automatiser dans une ligne de processus et ii) à leur implémentation. Le framework support à l’implémentation des CA offre un cadre technique pour l’implémentation des CA. Enfin, l’interpréteur de processus permet d’exécuter un processus (obtenu par dérivation d’une ligne de processus), et de lancer au fur et à mesure de son exécution les CA qui l’automatisent. Nous détaillons ces composants dans la suite de cette section, en les présentant en fonction des parties de l’approche de cette thèse qu’ils supportent. 6.2.1 Définition d’une ligne de processus Les modeleurs de VAM et de VRM supportent la définition d’une ligne de processus de développement logiciel, comme illustré par la figure 6.2. L’implémentation de ces modeleurs consiste à développer des éditeurs permettant de créer des VAM et des VRM conformes au métamodèle de la spécification de CVL. Des modeleurs autorisant la définition de VAM et de VRM dans des modèles distincts ont de plus l’avantage de permettre la réutilisation de ces modèles indépendamment les uns des autres. Ce besoin apparaît par exemple lorsqu’une même ligne de processus est définie avec deux langages de modélisation de processus différents, suite par exemple à un changement de modeleur dans l’entreprise. Dans ce cas, le même VAM est réutilisé pour spécifier la variabilité de la ligne de processus, quel que soit le langage de modélisation de processus utilisé, alors que des VRM différents sont utilisés pour chaque langage de modélisation de processus. 6.2.2 Définition des CA Le modeleur de CA abstraits, le modeleur de liaisons ainsi que le framework support à l’implémentation des CA contribuent à la définition des CA. Plus précisément, ils contribuent à la spécification de CA abstraits, à leur liaison à la ligne de processus et à leur implémentation. La figure 6.3 illustre la partie de l’approche proposée dans cette110 Outil pour la gestion de la variabilité et l’automatisation des processus Figure 6.2 – Partie de l’approche supportée par les modeleurs de VAM et de VRM Figure 6.3 – Partie de l’approche supportée par les modeleurs de CA abstraits et de liaisons et le framework support à l’implémentation des CAVue générale de l’outil 111 thèse qui est supportée par ces composants. Le modeleur de liaisons permet de lier des CA abstraits (spécifiés à l’aide du modeleur de CA abstraits) aux unités de travail d’une ligne de processus qu’ils contribuent à automatiser. Le modeleur de liaisons permet également de lier les CA abstraits à leur implémentation. Lorsque plusieurs CA contribuent à l’automatisation d’une même unité de travail, ce modeleur doit permettre de spécifier l’ordre dans lequel ces CA doivent s’exécuter. Le modeleur de liaisons doit également permettre de spécifier si un CA contribue à automatiser l’initialisation, l’exécution ou la finalisation d’une unité de travail. Le framework support à l’implémentation des CA permet premièrement aux CA d’accéder à des informations contextuelles nécessaires à leur exécution. Pour s’exécuter, les CA ont en effet besoin d’avoir accès à des informations spécifiques à leur contexte d’utilisation, c’est-à-dire à des informations contextuelles. Par exemple, un CA qui met du code source sous contrôle de version doit avoir accès à l’URL du dépôt distant sur lequel partager ce code source. Selon le langage de modélisation utilisé pour définir la ligne de processus, ces informations contextuelles peuvent, ou non, être capturées dans la ligne de processus (et donc dans le modèle de processus résolu). Par exemple, en SPEM 2.0, il n’est pas possible de capturer l’URL d’un dépôt distant. En effet, même si cette information peut, par exemple, être capturée en utilisant une recommandation (Guidance), elle ne serait pas typée comme étant une information relative à l’URL d’un dépôt distant et ne pourrait donc pas être traitée comme telle par un outil recherchant des informations contextuelles. Il est donc nécessaire d’avoir un mécanisme permettant aux CA d’accéder aux informations contextuelles, qu’elles soient ou non capturées dans le modèle de processus résolu. Le framework support à l’implémentation des CA permet également d’exécuter les CA de manière générique. En effet, l’interpréteur de processus doit pouvoir être réutilisé indépendamment des CA. Or, il n’est pas possible de déterminer à l’avance un ensemble fini de CA puisque i) il n’est pas possible de prévoir toutes les évolutions qui peuvent être apportées à une famille de processus et ii) il n’est pas possible d’avoir une vision exhaustive de toutes les familles de processus existantes. Il est donc nécessaire de pouvoir, au fur et à mesure de l’exécution de processus, lancer l’exécution des CA de manière générique. Par ceci nous entendons plus précisément que le framework doit permettre de lancer automatiquement l’exécution des CA, quels qu’ils soient. 6.2.3 Dérivation d’un processus en fonction des exigences d’un projet L’assistant à la résolution de la variabilité et le moteur de dérivation CVL supportent la dérivation d’un processus de la ligne de processus en fonction des exigences d’un projet, comme illustré par la figure 6.4. L’assistant à la résolution de la variabilité offre un support à la résolution de la variabilité, étape pouvant s’avérer fastidieuse et source d’erreurs. En effet, dans le VAM, la non séparation des préoccupations entre les spécifications de variabilité nécessitant une résolution manuelle et celles dont la résolution est dérivée (c’est-à-dire calculée automatiquement en fonction de la résolution d’autres spécifications de variabilité) peut compliquer la résolution de la variabilité112 Outil pour la gestion de la variabilité et l’automatisation des processus Figure 6.4 – Partie de l’approche supportée par l’assistant à la résolution de la variabilité et le moteur de dérivation CVL pour un humain. De plus, plus le nombre de contraintes entre des spécifications de variabilité du VAM sera important, plus il sera difficile pour un humain de les prendre en compte. D’autre part, un humain peut toujours faire des erreurs conduisant au nonrespect de la spécification de CVL. L’assistant à la résolution de la variabilité apporte donc un support i) en mettant en œuvre la séparation des préoccupations entre les spé- cifications de variabilité nécessitant une résolution manuelle et celles dont la résolution est dérivée, ii) en forçant le respect des contraintes entre les différentes spécifications de variabilité, et iii) en assurant le respect de la spécification de CVL. Le moteur de dérivation CVL, quant à lui, dérive un processus de la ligne de processus conformément à la spécification de CVL. Afin de créer le modèle de processus résolu, il applique donc sur le modèle de processus de base les points de variation dont les spécifications de variabilité ont été résolues positivement. 6.2.4 Automatisation de l’exécution des processus L’interpréteur de processus supporte l’automatisation de l’exécution des processus, comme illustré par la figure 6.5. Il exécute un processus résolu en fonction de la sé- mantique du langage de modélisation de processus utilisé. De plus, pour chaque unité de travail de ce processus, il lance, s’il y a lieu, l’exécution des CA associés. D’autre part, comme la réalisation de certaines unités de travail est manuelle [Ben07], l’interpréteur de processus informe l’acteur courant du processus lorsqu’une intervention manuelle est requise, afin d’assurer le bon déroulement de l’exécution. Enfin, commeImplémentation 113 Figure 6.5 – Partie de l’approche supportée par l’interpréteur de processus le processus à exécuter peut contenir de la variabilité non encore résolue, l’interpréteur de processus permet de résoudre cette variabilité au moment de l’exécution. 6.3 Implémentation Les composants de T4VASP sont implémentés en Java, sous la forme de plugins Eclipse. Nous détaillons dans la suite de cette section comment nous les avons implémentés. 6.3.1 Les modeleurs de VAM et de VRM Les modeleurs de VAM et de VRM correspondent chacun à un éditeur arborescent généré par défaut avec EMF, sur la base de fichiers Ecore capturant les parties du métamodèle de CVL relatives au VAM et au VRM. Les figures 6.6 et 6.7 illustrent respectivement des extraits du VAM et du VRM de l’exemple illustratif de famille de processus de métamodélisation, édités avec les modeleurs générés. L’extrait de VAM de la figure 6.6 comporte un choix sans enfant (Choice checker), un choix avec enfants (Choice version control system), ainsi qu’un choix dont la résolution est dérivée (Choice parallelization). Les enfants du choix version control system sont les choix SVN et Git. Ils sont mutuellement exclusifs, comme indiqué par la multiplicité de groupe valant 1 (Multiplicity Interval 1), élément spécifiant qu’un seul choix enfant peut être sélectionné. L’extrait de VRM de la figure 6.7 contient deux points de variation, qui sont des114 Outil pour la gestion de la variabilité et l’automatisation des processus Figure 6.6 – Extrait du VAM de l’exemple illustratif de la famille de processus de modélisation, édité avec le modeleur de VAM Figure 6.7 – Extrait du VRM de l’exemple illustratif de la famille de processus de modélisation, édité avec le modeleur de VRM Figure 6.8 – Propriétés de l’existence d’objet tree editor de la figure 6.7 opérations à appliquer au modèle de base pour en dériver un modèle résolu (cf. section 2.3.2) : une substitution d’objet (Object Substitution replace SVN by Git) et une existence d’objet (Object Existence tree editor). Chacun de ces points de variation impacte des objets et des liens (Object Handle SVN, Object Handle Git, Object Handle tree editor definition). Les modeleurs de VAM et de VRM ne font pas apparaître toutes les propriétés de chaque élément de modèle dans la vue arborescente. Par exemple, l’extrait de VRM de la figure 6.7 ne fait pas apparaître la spécification de variabilité associée à chaque point de variation. Les modeleurs de VAM et de VRM offrent donc en plus une vue exhaustive des propriétés de chaque élément de modèle, à travers laquelle elles peuvent être éditées. La figure 6.8 illustre les propriétés de l’existence d’objet tree editor de la figure 6.7. Cette figure permet de constater que la variabilité de spécification associée à l’existence d’objet tree editor est le choix tree editor (les propriétés Binding Choice et Binding Vspec ont pour valeur Choice tree editor).Implémentation 115 6.3.2 Les modeleurs de CA abstraits et de liaisons Figure 6.9 – Métamodèle de CA abstraits et de liaisons Dans cette thèse, les modèles de CA abstraits et de liaisons sont définis dans un même modèle, à l’aide d’un modeleur commun. Nous appelons ce dernier le modeleur de CA abstraits et de liaisons. Afin de développer ce modeleur, nous avons utilisé EMF pour définir son métamodèle sous-jacent, le métamodèle de CA abstraits et de liaisons (cf. figure 6.9), et pour générer l’éditeur arborescent correspondant à ce métamodèle, c’est-à-dire le modeleur de CA abstraits et de liaisons en lui-même. Dans le métamodèle de CA abstraits et de liaisons, une liste de CA (ACL, pour Automation Component List) automatise une unité de travail (AutoWU). L’intérêt de la classe ACL est de pouvoir réutiliser une liste d’AC. Les références onStart, onDo et onEnd entre une liste de CA et une unité de travail automatisée spécifient respectivement si la liste de CA automatise l’initialisation, l’execution ou la finalisation de l’unité de travail. Une liste de CA définit un ensemble de CA abstraits (AC, pour Automation Component). Une unité de travail automatisée référence une unité de travail de la ligne de processus via un pointeur d’unité de travail (WUHandle) et son attribut MOFRef, qui correspond à l’URI de l’unité de travail dans la ligne de processus. Si une unité de travail varie, une condition de variante (référence variantCondition) spécifie de quelle variante il s’agit. Des pré-conditions (référence preConditions) et post-conditions (référence PostCond) spécifient respectivement le contexte requis pour exécuter un CA et les résultats attendus de l’exécution d’un CA. La condition de variante ainsi que les pré et post conditions sont des conditions (Condition) exprimées à l’aide d’une expression OCL [OMG10] (OCLExpr). La figure 6.10 illustre un extrait du modèle de CA abstraits et de liaisons de l’exemple illustratif, représenté sous forme de diagramme d’objets et non édité avec le modeleur de CA abstraits et de liaisons. Il comprend deux unités de travail automatisées (NewInterpGit et NewInterpSVN), qui sont deux variantes de la tâche de définition116 Outil pour la gestion de la variabilité et l’automatisation des processus Figure 6.10 – Diagramme d’objets représentant un extrait du modèle de CA abstraits et de liaisons de l’exemple illustratif d’un interpréteur (référencée par le pointeur d’unité de travail InterpDef). La condition de variante NoInterpGit (NoInterpSVN) spécifie que l’unité de travail automatisée NewInterpGit (NewInterpSVN) correspond à la tâche de définition de l’interpréteur lors de la première itération du processus et avec Git (SVN) comme SCV (Système de Contrôle de Version). La liste de CA InitInterp initialise cette tâche en créant un projet Kermeta (CA NewKermetaProject) et en générant le patron de conception interpréteur pour chaque métaclasse du métamodèle (CA GeneInterp). La finalisation de cette tâche consiste à mettre le code de l’interpréteur sous contrôle de version. La liste de CA EndInterpGit (EndInterpSVN) réalise cette mise sous contrôle de version via le CA VersionProjectGit (respectivement VersionProjectSVN) quand le SCV est Git (respectivement SVN). La pré-condition ExistMM spécifie que le CA GeneInterp requière l’existence du métamodèle pour son exécution. Une action (Action) permet de lier un CA abstrait à son implémentation. Le métamodèle de CA abstraits et de liaisons définit différents types d’actions : action Kermeta (KermetaAction) et action Java Eclipse (JEclipseAction). Ils définissent la technologie utilisée pour implémenter les CA. Il est bien sûr possible d’ajouter de nouveaux types d’actions (Shell, Groovy,...) en fonction des besoins pour un cas d’application. L’implémentation d’une action Java Eclipse (respectivement d’une action Kermeta) est écrite dans un plug-in Eclipse (respectivement dans l’expression, identifiée par l’at-Implémentation 117 tribut expr, de cette action Kermeta). C’est l’identifiant de l’action Java Eclipse qui permet de faire le lien avec le plug-in Eclipse implémentant cette action, comme nous allons le voir dans la section suivante. Figure 6.11 – Extrait du modèle de CA abstraits et de liaisons de l’exemple illustratif de la famille de processus de modélisation, édité avec le modeleur de CA abstraits et de liaisons La figure 6.11 illustre un extrait du modèle de CA abstraits et de liaisons de l’exemple illustratif de famille de processus de métamodélisation, édité avec le modeleur de CA abstraits et de liaisons. À noter également que cet exrait est différent de celui de la figure 6.10. Cet extrait contient quatre éléments de modèle : une action Java Eclipse (Java Eclipse Action subclipse configuration), un pointeur d’unité de travail (Work Unit Handle metamodel definition), un CA (Primitive AC Create empty EMF project) et une liste de CA (ACL put under version control). 6.3.3 Le framework support à l’implémentation des CA Figure 6.12 – Composants du framework Comme illustré par la figure 6.12, le framework se compose : – du plug-in javaimplementationsupport, qui permet de faire le lien entre un CA et le plug-in Eclipse l’implémentant et qui permet également d’exécuter de manière générique ce plug-in Eclipse, – du plug-in contextualinformationdeclaration, qui permet aux CA de déclarer les informations contextuelles dont ils ont besoin pour s’exécuter, – d’un gestionnaire d’informations contextuelles, dont le but est de trouver la valeur des informations contextuelles. Nous détaillons ces trois composants dans la suite de cette section.118 Outil pour la gestion de la variabilité et l’automatisation des processus 6.3.3.1 Liaison entre un CA et le plug-in Eclipse l’implémentant Le plug-in javaimplementationsupport permet de faire le lien entre un CA spécifié dans le modèle de CA abstraits et de liaisons et le plug-in Eclipse l’implémentant. Ce plug-in fournit en effet un point d’extension, appelé activityautomationregistry, auprès duquel doit s’enregistrer un plug-in Eclipse implémentant un CA. Au moment de cet enregistrement, le lien entre un plug-in Eclipse et un CA est réalisé en spécifiant l’identifiant de l’action Java Eclipse correspondant à ce CA. La figure 6.13 illustre un exemple de déclaration de l’action Java Eclipse implémentée par un plug-in. Sur la partie droite de cette figure se trouvent les informations à renseigner au moment de l’enregistrement auprès du point d’extension activityautomationregistry. L’action Java Eclipse implémentée est déclarée en mettant son identifiant dans le champ action. Figure 6.13 – Enregistrement auprès du point d’extension activityautomationregistry 6.3.3.2 Exécution générique des plug-in Eclipse implémentant les CA Afin de pouvoir lancer de manière générique l’exécution des CA implémentés en Java avec des plug-ins Eclipse, le plug-in javaimplementationsupport fournit une interface, appelée ActivityAutomation, qui doit être implémentée par chaque plug-in. L’implémentation de cette interface consiste à implémenter une méthode run(). C’est cette méthode qui est appelée pour lancer l’exécution d’un CA. Le corps de cette mé- thode doit donc contenir l’implémentation d’un CA. Pour pouvoir appeler la méthode run() de cette interface, il est nécessaire, pour des raisons techniques, de préciser quelle est la classe (d’un plug-in Eclipse correspondant à l’implémentation d’un CA) qui implémente cette méthode. Encore une fois, cette information est fournie au moment de l’enregistrement auprès du point d’extension activityautomationregistry du plug-in correspondant à l’implémentation d’un CA. La figure 6.13 illustre également un exemple de déclaration d’une classe implémentant l’interface ActivityAutomation. Le nom de cette classe est spécifié dans le champ class dans la liste des informations à renseigner au moment de l’enregistrement auprès du point d’extension activityautomationregistry. Toujours afin de pouvoir lancer les CA de manière générique, l’interpréteur de processus doit pouvoir les instancier de manière générique. Chaque classe implémentant l’interface ActivityAutomation doit donc avoir un constructeur Java par défaut.Implémentation 119 6.3.3.3 Gestion de l’accès aux informations contextuelles Chaque CA déclare la liste des informations contextuelles nécessaires à son exé- cution en s’enregistrant auprès du point d’extension parameterregistry, fournit par le plug-in contextualinformationdeclaration. Le gestionnaire d’informations contextuelles se charge d’affecter des valeurs aux informations contextuelles déclarées par les CA. Comme illustré par la figure 6.14, si une information contextuelle peut être capturée par le modèle du processus en cours d’exécution, alors le gestionnaire récupère sa valeur dans ce modèle. Sinon, il la récupère dans un modèle de contexte, qui contient un ensemble de clés/valeurs associant une information contextuelle à sa valeur. L’interpréteur de processus crée un modèle de contexte pour chaque exécution de processus. Si une information contextuelle n’est dans aucun modèle, alors le gestionnaire la demande à l’acteur courant du processus et la sauve dans le modèle de contexte afin qu’elle puisse être réutilisée. Le gestionnaire n’a pas besoin de sauver une information contextuelle dans le modèle du processus en cours d’exécution. En effet, si une information contextuelle pouvant être capturée par le modèle de processus ne l’est pas, alors il s’agit d’un cas de variabilité non résolue qui est traité par l’interpréteur de processus. Au moment de la déclaration des informations contextuelles nécessaires à l’exécution d’un CA, il est possible de spécifier qu’une information est confidentielle. Dans ce cas, cette information n’apparait pas en clair si elle est saisie par l’acteur courant. Figure 6.14 – Comportement du gestionnaire d’informations contextuelles Lorsqu’un CA est réutilisé plusieurs fois dans un même processus, mais avec des120 Outil pour la gestion de la variabilité et l’automatisation des processus artéfacts différents, alors les informations contextuelles liées à ces artéfacts, qui ne peuvent pas être capturées dans le modèle de processus, sont à demander à l’acteur courant, tant qu’elles n’ont pas été écrites dans le modèle de contexte. Par exemple, un CA qui crée un projet Kermeta a besoin pour s’exécuter du nom du projet Kermeta à créer. Or, ce nom sera différent pour chaque projet à créer. Le gestionnaire d’informations contextuelles devra donc demander à chaque fois le nom du projet à créer à l’acteur courant. Cependant, lorsqu’une information contextuelle spécifique à un artéfact est réutilisée par un CA, il faut pouvoir la différencier d’une information contextuelle capturant le même type d’information mais spécifique à un autre artéfact. Par exemple, il faut pouvoir différencier les noms de deux projets Kermeta. Ce problème ne se pose pas avec les informations contextuelles pouvant être capturées dans le modèle de processus. Il est en effet dans ce cas possible de les différencier car elles sont liées à des artéfacts différents. Des CA différents sont utilisés pour demander des informations contextuelles qui doivent être différenciées. Par exemple, dans le cas de la création de projets Kermeta, chaque projet a son propre CA. Chaque CA déclare l’information contextuelle correspondant au nom du projet à créer avec une clé spécifique, afin que celle-ci puisse être différenciée des autres clés dans le modèle de contexte. Afin d’éviter les redondances entre les CA, les traitements métiers qui leur sont communs (par exemple la création d’un projet) sont factorisés dans une même fonction, prenant en paramètres les informations contextuelles spécifiques à chaque CA. Cette manière de gérer les informations contextuelles ne fonctionne que si tous les cas d’utilisation d’un CA sont connus au moment de la définition des CA. Cela n’est pas toujours le cas. Par exemple, lors d’un processus de développement Java, plusieurs projets Java peuvent être créés mais leur nombre n’est souvent pas connu à l’avance. Il n’est donc pas possible de créer autant de CA mettant un projet Java sous contrôle de version que de projets Java. Dans ce cas, un seul CA est créé pour automatiser une TMR particulière. Il demande à l’acteur courant les informations contextuelles spécifiques à des artéfacts et non encore sauvées dans le modèle de contexte. Il écrase l’ancienne valeur de l’information contextuelle dans le modèle de contexte si elle existe, et sinon il crée un nouveau couple clé/valeur. Cette deuxième manière de gérer les informations contextuelles ne fonctionne que si l’ancienne valeur d’une information contextuelle n’est plus utilisée. Dans le cas contraire, une information contextuelle est toujours demandée à l’acteur courant sans jamais la sauver dans le modèle de contexte. Cette dernière manière de gérer les informations contextuelles implique de solliciter plusieurs fois l’acteur courant pour lui demander la même chose, ce qui est source d’erreurs. Nous ne la réservons donc que pour les cas où les deux premières manières de procéder ne sont pas adéquates. Le gestionnaire d’informations contextuelles doit être en mesure de déterminer si i) une information n’est à demander à l’acteur courant que si elle n’est pas déjà dans le modèle de contexte, ii) une information est à demander à l’acteur courant et son ancienne valeur doit être écrasée dans le modèle de contexte, ou iii) une information est demandée à l’acteur courant sans sauvegarde dans le modèle de contexte. À cette fin, les CA, lorsqu’ils déclarent les informations contextuelles nécessaires à leur exécution,Implémentation 121 spécifient comment chaque information doit être traitée. Afin que l’acteur courant puisse se concentrer sur la réalisation d’autres tâches pendant que les CA s’exécutent, il est nécessaire qu’il n’ait pas à donner des informations contextuelles aux CA au fur et à mesure de leur exécution. Aussi, le gestionnaire récupère les valeurs de toutes les informations contextuelles nécessaires à l’exécution d’une liste de CA au début de l’exécution de cette liste. Le principal intérêt du gestionnaire d’informations contextuelles est qu’il découple l’accès aux informations contextuelles de l’implémentation des CA. Cela permet de rendre les CA plus réutilisables. En effet, l’accès aux informations contextuelles (et donc le gestionnaire d’informations contextuelles) dépend du langage de modélisation de processus utilisé, puisque selon ce langage une information contextuelle est récupérée dans le modèle du processus en cours d’exécution ou dans le modèle de contexte. Gérer l’accès aux informations contextuelles directement dans l’implémentation des CA aurait donc rendu ces CA dépendant du langage de modélisation de processus utilisé. Figure 6.15 – Extrait du modèle de contexte d’un processus de métamodélisation avec contrôle de version Figure 6.16 – Exemple de déclaration par un CA d’informations contextuelles La figure 6.15 illustre un extrait du modèle de contexte d’un processus de métamodélisation avec contrôle de version. Ce modèle de contexte contient la clé url of the remote repository, qui correspond à l’URL du dépôt distant sur lequel partager des ressources. À cette clé est associée la valeur file :///C :/Users/erouille/depotsvn. La figure 6.16 illustre un exemple de déclaration par un CA des informations contextuelles nécessaires à son exécution. Il s’agit ici d’un CA qui connecte l’espace de travail Eclipse d’un acteur courant du processus à un nouveau dépôt SVN distant. Ce CA a besoin pour s’exécuter de trois informations contextuelles : l’URL du dépôt SVN distant (url of the remote repository), le nom d’utilisateur (username to connect to the remote repository) et le mot de passe (password to connect to the remote repository) de122 Outil pour la gestion de la variabilité et l’automatisation des processus Figure 6.17 – Exemple de demande d’informations contextuelles à l’acteur courant du processus l’acteur courant. Cette dernière information est ici déclarée comme confidentielle. La figure 6.17 illustre la demande de ces informations contextuelles à l’acteur courant d’un processus de métamodélisation de l’exemple illustratif. Cette demande a lieu au moment de la finalisation de la définition d’un interpréteur. Pour rappel, la finalisation de la définition d’un interpréteur consiste à mettre cet interpréteur sous contrôle de version. Plus précisément, la mise sous contrôle de version d’un interpréteur consiste à connecter l’espace de travail Eclipse du développeur de l’interpréteur à un dépôt SVN distant, puis à exporter sur ce dépôt le projet Kermeta contenant le code source de l’interpréteur. Les informations contextuelles demandées ne peuvent pas être capturées dans un modèle de processus SPEM et n’ont pas déjà été sauvées dans le modèle de contexte à ce stade de l’exécution du processus. 6.3.4 L’assistant à la résolution de la variabilité L’assistant à la résolution de la variabilité que nous avons développé parcourt un VAM et pour chaque spécification de variabilité de ce VAM dont la résolution n’est pas dérivée, il demande à l’utilisateur de la ligne de processus de résoudre la variabilité via une interface. La manière de résoudre la variabilité qui est proposée dans l’interface dépend du type de spécification de variabilité, afin d’assurer le respect de la spécification de CVL. Par exemple, pour faire un choix, l’utilisateur de la ligne de processus ne peut que donner une réponse booléenne en sélectionnant ou non une case à cocher. De plus, la résolution de certaines spécifications de variabilité peut être forcée afin d’assurer le respect des contraintes entre les spécifications de variabilité du VAM. Par exemple, si un choix est obligatoire il est automatiquement sélectionné et l’utilisateur de la ligne de processus ne peut pas modifier cette résolution. Si deux choix sont mutuellement exclusifs alors l’interface ne permet de sélectionner qu’un seul de ces deux choix. Si des choix peuvent être combinés, l’interface permet alors deImplémentation 123 sélectionner plusieurs de ces choix. L’assistant à la résolution de la variabilité crée dans un RM les résolutions de spécifications de variabilité (VSpecResolution, section 2.3.2). L’utilisateur de la ligne de processus a également la possibilité de passer la résolution d’une spécification de variabilité, dans le cas où la variabilité ne peut pas être résolue tout de suite. Dans ce cas, les résolutions de spécification de variabilité associées ne sont pas créées dans le RM. Figure 6.18 – Utilisation de l’assistant à la résolution de la variabilité avec l’exemple illustratif de famille de processus de métamodélisation La figure 6.18 illustre l’utilisation de l’assistant à la résolution de la variabilité avec l’exemple illustratif de famille de processus de métamodélisation. Cet assistant permet à un utilisateur de la ligne de processus de résoudre la variabilité du VAM de la famille de processus de métamodélisation (cf. figure 4.9 pour un extrait de ce VAM) en résolvant les choix tree editor, compiler, interpreter, checker, textual editor, XText, EMFText, SVN et Git. Le choix version control system étant obligatoire, il est déjà sélectionné et il n’est pas possible de changer cette résolution. Les choix tree editor, compiler, interpreter, checker et textual editor n’étant pas mutuellement exclusifs, des cases à cocher sont utilisées pour les résoudre. Comme les choix XText et EMFText d’une part et SVN et Git d’autre part sont mutuellement exclusifs, des boutons radio sont utilisés pour les résoudre. Il est possible de passer la résolution de la variabilité d’un choix en cochant la case skip the resolution of this variability specification associée à ce choix.124 Outil pour la gestion de la variabilité et l’automatisation des processus 6.3.5 Le moteur de dérivation CVL Figure 6.19 – Comportement du moteur de dérivation CVL Nous décrivons ici le fonctionnement du moteur de dérivation CVL que nous avons implémenté dans le cadre de cette thèse. Comme illustré par la figure 6.19, pour chaque résolution de choix d’un RM, le moteur de dérivation CVL trouve le choix correspondant dans le VAM. Ensuite, le moteur de dérivation CVL trouve les points de variation qui sont associés à ce choix. Si le choix est sélectionné, ces points de variation sont exécutés conformément à la sémantique définie dans la spécification de CVL. Le cas échéant, les objets optionnels associés à des points de variation de type ObjectExistence sont supprimés. Les points de variation s’exécutent sur une copie du modèle de processus de base, afin de créer un modèle de processus résolu sans écraser le modèle de processus de base.Implémentation 125 Figure 6.20 – Comportement de l’interpréteur de processus126 Outil pour la gestion de la variabilité et l’automatisation des processus 6.3.6 L’interpréteur de processus Nous détaillons maintenant l’interpréteur de processus développé dans le cadre de cette thèse. Son fonctionnement est illustré par la figure 6.20. Lors de son lancement, l’interpréteur de processus commence par afficher dans une vue spécifique, la vue processus, les différentes unités de travail qui composent le processus à exécuter. L’interpréteur de processus démarre ensuite l’exécution du processus, en fonction de la sémantique des diagrammes d’activités UML 2. Cependant, avant l’exécution d’un élément de processus, l’interpréteur de processus détermine si de la variabilité non ré- solue est associée à cet élément de processus. Si c’est le cas, l’interpréteur de processus appelle l’assistant à la résolution de la variabilité avec en paramètre les spécifications de variabilité non résolues associées à l’élément de processus courant, afin que l’acteur courant du processus résolve cette variabilité. Une fois la variabilité résolue, l’interpréteur met à jour le processus en cours d’exécution en fonction de la résolution de la variabilité, et met également à jour la vue processus. Pour mettre à jour le processus en cours d’exécution, l’interpréteur exécute sur ce processus les points de variation associés aux spécifications de variabilité qui viennent d’être résolues positivement. Figure 6.21 – Détection de variabilité non résolue Pour déterminer si de la variabilité non résolue est associée à un élément de processus, l’interpréteur cherche dans le VRM si des points de variation référencent cet élément de processus. Si de tels points de variation existent, l’interpréteur vérifie dans le RM si les spécifications de variabilité associées à ces points de variation sont toutes résolues. Si tel n’est pas le cas, cela signifie que de la variabilité n’est pas résolue. La figure 6.21 illustre la détection de variabilité non résolue par l’interpréteur. Si l’élément de processus à exécuter est une unité de travail, alors l’interpréteur affiche dans la vue processus l’étape (initialisation, exécution, finalisation) de cette unité de travail qui peut être lancée. L’ordre entre les étapes d’une unité de travail est respecté. C’est-à-dire qu’une étape peut être lancée seulement si les étapes précédentes ont été réalisées. Par exemple, la finalisation ne peut être lancée que si l’exécution a déjàImplémentation 127 été réalisée. De plus, une initialisation ou une finalisation ne peut être lancée que si elle est automatisée, alors qu’une exécution peut être lancée qu’elle soit automatisée ou manuelle. Lorsque la finalisation d’une unité de travail est terminée (ou son exécution si elle n’a pas de finalisation), l’interpréteur de processus exécute les éléments de processus qui suivent cette unité de travail dans le processus. C’est l’acteur courant qui lance l’initialisation, l’exécution ou la finalisation d’une unité de travail. Cela lui permet de suivre l’exécution du processus. Ainsi, s’il a une tâche manuelle à réaliser pour participer à l’exécution du processus, il saura où l’exécution en est rendue et donc ce qui a déjà été fait et qu’il n’a pas à refaire. L’initialisation ou la finalisation d’une unité de travail consiste à lancer automatiquement l’exécution de la liste de CA associée. L’exécution d’une unité de travail consiste à faire de même lorsque celle-ci est automatisée. Sinon, l’interpréteur informe l’acteur courant qu’il doit réaliser l’exécution manuellement et attend que ce soit fait avant de continuer l’exécution du processus. Lancer l’exécution d’une liste de CA consiste à lancer l’exécution de ses CA, dans leur ordre de définition. Pour lancer l’exé- cution d’un CA associé à une action Kermeta, l’interpréteur appelle une fonction qui évalue dynamiquement l’expression de cette action. Pour lancer l’exécution d’un CA associé à une action Java Eclipse, l’interpréteur trouve le plug-in qui est relié à cette action et appelle la méthode run() de la classe implémentant le CA. Si une unité de travail est optionnelle, l’interpréteur de processus offre à l’acteur courant la possibilité de passer l’exécution de cette unité de travail. Attention, ici nous considérons une unité de travail qui est optionnelle dans un processus résolu, ce qui dénote donc de la variabilité au moment de l’exécution du processus (et non au moment de sa conception), tout comme les nœuds de décision par exemple. L’interpréteur de processus capture également les traces d’exécution de processus, afin de savoir quelle est l’itération de processus en cours et par quels flots de contrôle une unité de travail est accédée ou quittée. L’exécution de certains CA dépend en effet de ce qui se passe avant ou après l’unité de travail qu’ils automatisent. Par exemple, dans le cas de la famille de processus de métamodélisation, le CA créant un nouveau projet Kermeta au début de la tâche de définition d’un interpréteur ne s’exécute que lors de la première itération du processus. La figure 6.22 illustre la vue processus d’une variante de processus de métamodélisation comprenant les tâches de définition d’un métamodèle, d’un éditeur arborescent, d’un interpréteur, d’un compilateur et d’un vérificateur. Chacune de ces tâches a des boutons on start, on do, done, on end et skip. Ces boutons permettent de lancer l’initialisation d’une unité de travail (on start), de lancer l’exécution d’une unité de travail (on do), de signaler que l’exécution manuelle d’une unité de travail est terminée (done), de lancer la finalisation d’une unité de travail (on end) et de passer l’exécution d’une unité de travail lorsque celle-ci est optionnelle (skip). Sur la figure 6.22, l’exécution du processus vient juste de démarrer. Aussi, seule l’initialisation de la tâche de définition d’un métamodèle, ici automatisée, peut être lancée. En effet, sur la figure 6.22 seul le bouton on start lié à cette tâche est actif, les autres étant grisés.128 Outil pour la gestion de la variabilité et l’automatisation des processus Figure 6.22 – Vue processus d’une variante de processus de métamodélisation 6.4 Discussion Nous énonçons dans cette partie des recommandations pour implémenter les CA et les relier à leurs contextes d’utilisation (section 6.4.1), puis nous abordons les extensions possibles à T4VASP (section 6.4.2). 6.4.1 Recommandations Lorsque la ligne de processus spécifie qu’un outil peut être substitué par un autre, alors, dans l’implémentation des CA, les parties qui dépendent de cet outil doivent être découplées des parties qui n’en dépendent pas. Cela permet de pouvoir réutiliser ces dernières lorsque l’outil est remplacé. Dans le modèle de CA abstraits et de liaisons, l’architecte doit spécifier pour quels séquencements et pour quelles itérations d’une unité de travail des CA sont appropriés, si les CA dépendent de ces séquencements et de ces itérations. En effet, la variabilité de ce qui se passe avant ou après une unité de travail (entre les différentes variantes d’un processus ou au sein d’une même variante de processus) peut impliquer de la variabilité au niveau des CA qui automatisent cette unité de travail. Des CA peuvent donc être requis, inutiles ou inutilisables en fonction de ce qui se passe avant ouDiscussion 129 après une unité de travail. De plus, une unité de travail peut varier en fonction de ses itérations. Par exemple, la première itération d’une unité de travail peut consister à créer des artéfacts, tandis que les itérations suivantes consistent à modifier ces derniers. Cela peut impliquer des variations des CA qui automatisent cette unité de travail ainsi que des CA automatisant les unités de travail précédentes et suivantes. 6.4.2 Extensions Actuellement, T4VASP fonctionne uniquement dans un environnement local. Or, plusieurs personnes peuvent participer à la réalisation d’un processus de développement logiciel, chacune avec son propre poste informatique. Il est donc important que l’automatisation de l’exécution d’un processus puisse se faire dans un environnement distribué. Une extension serait donc que T4VASP devienne une application client-serveur, et que l’exécution d’un processus soit centralisée sur la partie serveur, tandis que les automatisations des TMR s’exécuteraient sur les postes clients. Ainsi, plusieurs personnes pourraient partager l’exécution d’un même processus. L’interpréteur de processus ne permet actuellement pas à l’acteur courant du processus de lancer l’initialisation ou la finalisation d’une unité de travail si ces initialisations et finalisations ne sont pas automatisées. En effet, comme SPEM 2.0 ne permet pas de définir d’initialisation et de finalisation à une unité de travail, l’interpréteur ne peut pas savoir si une unité de travail a une initialisation ou une finalisation, à moins que celle-ci soit automatisée car cela est dans ce cas spécifié dans le modèle de CA abstraits et de liaisons. Si une initialisation ou une finalisation n’est pas spécifiée elle peut être omise par l’acteur courant du processus. Lorsqu’une unité de travail a une initialisation ou une finalisation manuelle, la seule manière de le spécifier en SPEM 2.0 est de faire précéder (suivre) cette unité de travail par une autre unité de travail consistant en l’initialisation (la finalisation). Par exemple, si l’unité de travail U1 a une initialisation manuelle, cela pourra apparaître dans un modèle de processus SPEM 2.0 en faisant précéder U1 d’une unité de travail U0 consistant à réaliser l’initialisation. Mais l’inconvénient de cette solution est que les initialisations et les finalisations ne sont pas fortement couplées aux unités de travail qu’elles initialisent ou finalisent. Il est donc possible pour un humain d’omettre l’initialisation ou la finalisation d’une unité de travail lors de sa réutilisation. Par exemple lors de la création d’un nouveau modèle de processus contenant l’unité de travail U1 précédente, la personne en charge de la modélisation peut omettre de faire précéder U1 de U0. Une extension à T4VASP serait donc de faire évoluer le métamodèle de CA abstraits et de liaisons de manière à pouvoir spécifier qu’une initialisation ou une finalisation est manuelle. Dans le cas où une initialisation, exécution ou finalisation d’unité de travail est composée à la fois d’étapes automatisées et manuelles, l’outillage actuel impose de dé- finir dans le modèle de processus les unités de travail à un niveau de granularité plus fin, de sorte qu’une initialisation, exécution ou finalisation soit complètement manuelle ou complètement automatisée. L’outillage actuel ne prend en effet pas en compte les initialisations, exécutions ou finalisations partiellement automatisées. Ainsi, si l’exé- cution d’une unité de travail U1 consiste par exemple à réaliser trois actions, A1, A2130 Outil pour la gestion de la variabilité et l’automatisation des processus et A3, avec A1 et A3 automatisées et A2 manuelle, alors dans le modèle de processus U1 devra être décomposée en trois unités de travail, consistant respectivement en la réalisation des actions A1, A2 et A3. Si les actions A1 et A3 peuvent être considérées comme les initialisations et finalisations respectives de A2, une autre solution serait de définir A1 comme initialisation de U1, A2 comme exécution de U1 et A3 comme finalisation. Cela conduit à des définitions de processus plus détaillées. Afin de satisfaire le cas où les utilisateurs d’un modèle de processus préfèrent une définition plus abstraite, une extension à T4VASP serait de faire évoluer le métamodèle de CA abstraits et de liaisons de manière à pouvoir spécifier des listes d’AC qui soient entrecoupées de tâches manuelles et ainsi pouvoir gérer les initialisations, exécutions ou finalisations partiellement automatisées. 6.5 Synthèse Nous avons présenté dans ce chapitre T4VASP, l’outil support à l’approche proposée dans cette thèse. T4VASP se compose de 8 composants : un modeleur de VAM, un modeleur de VRM, un assistant à la résolution de la variabilité, un moteur de dérivation CVL, un modeleur de CA abstraits et de liaisons, un framework supportant l’implémentation des CA ainsi qu’un interpréteur de processus. T4VASP permet de définir une ligne de processus, de lier des CA à cette ligne de processus, de dériver automatiquement un processus de la ligne de processus en fonction des exigences d’un projet et d’automatiser l’exécution d’un processus. Il permet de plus de prendre en charge la variabilité non résolue au fur et à mesure de l’exécution d’un processus. T4VASP offre également des avantages dans la manière dont il met en œuvre l’approche proposée. Ainsi, au moment de la liaison des CA à la ligne de processus, T4VASP permet à l’architecte de spécifier l’étape (initialisation, exécution ou finalisation) d’une unité de travail qu’une liste de CA automatise, ainsi que l’ordre d’exécution de ces CA. Cela permet de définir plus finement l’automatisation des processus et également d’assurer que les initialisations et finalisations des unités de travail ne sont pas omises. T4VASP offre de plus un support à la résolution de la variabilité, i) en abstrayant le VAM des informations non pertinentes pour la personne en charge de la résolution de la variabilité, ii) en forçant le respect des contraintes entre les spécifications de variabilité et iii) en assurant le respect de la spécification de CVL. Au moment de l’exé- cution d’un processus, T4VASP offre un mécanisme permettant de lancer les CA qui automatisent ce processus de manière générique, ce qui en fait un outil indépendant des CA associés à une ligne de processus. De plus, les CA peuvent avoir accès aux informations contextuelles dont ils ont besoin pour s’exécuter, y compris celles qui ne peuvent pas être capturées par le modèle du processus en cours d’exécution. En effet, T4VASP demande ces informations contextuelles à l’acteur courant du processus et les sauvegarde dans un modèle contexte. Toutefois, afin que l’acteur courant du processus puisse se concentrer sur d’autres tâches pendant l’exécution d’une liste de CA, toutes les informations contextuelles nécessaires sont demandées au début de l’exécution de la liste. Pendant l’exécution d’un processus, T4VASP informe l’acteurSynthèse 131 courant du processus lorsque des interventions manuelles sont requises de sa part, afin d’assurer le bon déroulement de l’exécution. Enfin, T4VASP permet à l’acteur courant du processus de suivre l’exécution du processus, car c’est cet acteur courant qui lance les initialisations, exécutions et finalisations des unités de travail. Nous avons également identifié plusieurs extensions à T4VASP. Ainsi, faire évoluer T4VASP vers une application client-serveur permettrait l’exécution de processus en environnements distribués, ce qui correspond à la majorité des contextes de réalisation de projets de développement logiciel. D’autre part, spécifier, dans le modèle de CA abstraits et de liaisons, qu’une initialisation ou une finalisation d’unité de travail est manuelle permettrait que l’acteur courant d’un processus puisse les lancer même si elles ne sont pas automatisées. Enfin, en faisant évoluer le métamodèle de CA abstraits et de liaisons de manière à pouvoir spécifier que des listes d’AC sont entrecoupées de tâches manuelles, les utilisateurs d’un modèle de processus auraient la liberté de le définir au niveau d’abstraction qui leur convient le mieux. Ils pourraient en effet définir des unités de travail composées à la fois de tâches manuelles et automatisées. Nous avons actuellement implémenté uniquement les fonctionnalités de T4VASP dont nous avions besoin pour pouvoir l’utiliser avec les cas d’application présentés dans le chapitre suivant. Afin d’assurer que T4VASP soit utilisable quel que soit le cas d’application, il reste donc à implémenter les fonctionnalités suivantes : – prise en compte de l’ensemble de CVL par l’assistant à la résolution de la variabilité et par le moteur de dérivation, – évaluation dynamique des expressions Kermeta, – évaluation des conditions (liées aux AC ou aux unités de travail automatisées) définies dans un modèle de CA abstraits et de liaisons, – découplage de l’accès aux informations contextuelles de l’implémentation des CA, – résolution de la variabilité à l’exécution. Nous évaluons le degré de maturité de T4VASP au niveau TRL (Technology Readiness Level) 2, où le TRL est une mesure permettant d’évaluer la maturité d’une technologie [oD11]. Au niveau TRL 2, les concepts et des applications d’une technologie ont été définis, mais la technologie n’est pas encore prête à être utilisée sur n’importe quel cas d’application. Le code source de T4VASP peut être consulté à l’adresse suivante : https: //github.com/emmanuellerouille/T4VASP/tree/master/source_code.132 Outil pour la gestion de la variabilité et l’automatisation des processusChapitre 7 Applications de l’approche À ce jour, T4VASP a été appliqué à deux cas : la famille de processus de métamodé- lisation qui sert d’exemple illustratif tout au long de cette thèse, ainsi qu’une famille simplifiée de processus de développement web Java issue de Sodifrance. Pour ce faire, nous avons pour chacun de ces deux cas défini une ligne de processus de développement logiciel en nous appuyant sur CVL4SP (section 4.2). Nous avons donc spécifié dans un VAM la variabilité au niveau des exigences des projets, défini un modèle de processus de base afin de capturer les éléments de modèle nécessaires à la création des différents processus de la famille, et défini un VRM afin de spécifier comment dériver un processus résolu du modèle de processus de base en fonction des exigences des projets. Nous avons utilisé l’outil SPEM-Designer pour modéliser les processus de base. Nous avons ensuite identifié et implémenté des CA pour chaque cas d’application en suivant M4RAC (section 5.2). Nous avons pour ce faire créé un modèle de CA abstraits et de liaisons pour chacuns des deux cas d’application. Toujours pour chacun des deux cas, un modèle de processus résolu a été dérivé en fonction d’une sélection d’exigences. Ce modèle de processus a ensuite été exécuté, et les CA qui lui sont liés ont été lancés au fur et à mesure de cette exécution. Nous détaillons dans la suite de ce chapitre les deux cas d’application. Les sections 7.1 et 7.2 présentent respectivement l’application à la famille de processus de métamodélisation et l’application à la famille de processus de développement web Java. 7.1 Application sur une famille de processus de métamodélisation Nous appliquons dans cette section T4VASP à une famille de processus de métamodélisation, issue de l’équipe de recherche Triskell. Il s’agit de la famille qui a servi d’exemple illustratif à CVL4SP et T4VASP. Nous invitons donc le lecteur à se référer aux sections 4.1 et 6.1 pour une description complète de cette famille de processus et des tâches qui ont lieu durant l’exécution des processus de cette famille et qui gagneraient à être automatisées. 133134 Applications de l’approche Le VAM de la famille de processus de métamodélisation contient 39 éléments de modèle. Ce VAM permet de capturer les exigences de 128 projets différents, chacun ayant un processus différent. Le modèle de processus de base ainsi que le VRM de la famille de processus de métamodélisation contiennent quant à eux respectivement 134 et 123 éléments de modèle. Le VAM, le modèle de processus de base, ainsi que le VRM forment donc une ligne de processus permettant de capturer 128 processus différents. Le modèle de CA abstraits et de liaisons contient 27 éléments de modèle. Nous avons implémenté 10 CA en Java : 1. un CA permettant de créer un nouveau projet EMF avec un nouveau fichier Ecore vide, 2. un CA permettant de valider un métamodèle Ecore, 3. un CA permettant de générer un éditeur arborescent, 4. un CA permettant de créer un nouveau projet XText, 5. un CA permettant de créer un nouveau projet Kermeta et de l’initialiser avec un appel à une fonction Kermeta qui vérifie qu’un modèle respecte bien les contraintes définies sur son métamodèle, 6. un CA permettant de créer un nouveau projet Kermeta et de l’initialiser avec la génération du patron de conception interpréteur pour chaque méta-classe d’un métamodèle, 7. un CA permettant de créer un nouveau projet Kermeta et de l’initialiser avec la génération du patron de conception visiteur pour chaque méta-classe d’un métamodèle, 8. un CA permettant de connecter un espace de travail Eclipse à un dépôt SVN distant, 9. un CA permettant de mettre un projet sous contrôle de version, 10. un CA permettant de propager avec SVN du code source vers un dépôt distant. Le CA 1 initialise la définition d’un métamodèle. Il a besoin de deux informations contextuelles pour s’exécuter : le nom du projet EMF et le nom du fichier Ecore. Le gestionnaire d’informations contextuelles les demande à l’acteur courant du processus puis les sauvegarde dans le modèle de contexte. Le CA 2 finalise la définition d’un métamodèle et le CA 3 exécute la tâche de définition d’un éditeur arborescent. Ces deux CA ont besoin pour cela des deux mêmes informations contextuelles : le nom du projet EMF et du fichier Ecore contenant la définition du métamodèle. Le gestionnaire d’informations contextuelles trouve ces informations dans le modèle de contexte, où elles ont été préalablement écrites. Le CA 4 initialise la définition d’un éditeur textuel, lorsque celle-ci est réalisée avec l’outil XText. Ce CA utilise l’information contextuelle correspondant au nom du projet EMF contenant la définition du métamodèle. Cette information est récupérée dans le modèle de contexte par le gestionnaire d’informations contextuelles. Ce CA nécessite également une autre information contextuelle pour s’exécuter, à savoir leApplication sur une famille de processus de métamodélisation 135 Figure 7.1 – Point d’entrée du CA permettant de générer un éditeur arborescent nom du projet XText à créer. Le gestionnaire d’informations contextuelles demande cette information à l’acteur courant du processus. Les CA 5, 6 et 7 initialisent respectivement les tâches de définition d’un vérificateur, d’un interpréteur et d’un compilateur. Ils ont besoin tous les trois pour s’exécuter du nom du projet Kermeta à créer, ainsi que du nom du projet EMF et du fichier Ecore contenant la définition du métamodèle. Le gestionnaire d’informations contextuelles demande le nom du projet à créer à l’acteur courant du processus et récupère dans le modèle de contexte le nom du projet EMF et du fichier Ecore contenant la définition du métamodèle. La création d’un projet Kermeta est commune à ces trois CA et n’est pas factorisée dans son propre CA. En effet, les initialisations des projets Kermeta (appel à une fonction Kermeta vérifiant qu’un modèle respecte bien les contraintes définies sur son métamodèle et génération du patron de conception interpréteur ou compilateur) ont besoin pour s’exécuter de connaître le nom du projet à initialiser, qui est différent dans les trois cas. Il faut donc pouvoir différencier les noms des projets Kermeta. De plus, le nom d’un projet Kermeta ne peut pas être écrasé dans le modèle de contexte car il est réutilisé dans le cas de l’interpréteur pour sa mise sous contrôle de version (et l’information pourrait être écrasée avant que la mise sous contrôle de version n’ait lieu car les tâches de définition d’un interpréteur, d’un compilateur et d’un vérificateur s’exécutent en parallèle). Nous avons vu, dans la section 6.3.3, que dans ce cas des CA différents automatisent la même TMR, mais en demandant chacun des informations contextuelles spécifiques aux artéfacts qu’ils impactent. Les CA 8, 9 et 10 finalisent la tâche de définition d’un interpréteur. Le CA 8 a besoin pour s’exécuter de l’URL d’un dépôt SVN distant, ainsi que d’un nom d’utilisateur et d’un mot de passe pour se connecter à ce dépôt distant. Le gestionnaire d’informations contextuelles demande ces trois informations à l’acteur courant du processus. Les CA 9 et 10 ont besoin pour s’exécuter du nom du projet dont le contrôle de version doit être géré (ici le projet Kermeta contenant le code source de l’interpréteur). Le CA 9 a de plus besoin de connaître l’URL du dépôt SVN distant. Le gestionnaire d’informations contextuelles récupère toutes ces informations dans le modèle de contexte. Ici,136 Applications de l’approche Figure 7.2 – Méthode run de la classe GenerateTreeEditor, appelée par la méthode run de la figure 7.1 l’automatisation de la propagation avec SVN du code source vers un dépôt distant est mise dans son propre CA (ici le 10), afin de pouvoir la réutiliser indépendamment des CA 8 et 9. En effet, la première fois que la tâche de définition d’un interpréteur a lieu, il faut, lors de sa finalisation, exécuter les CA 8, 9 et 10, alors que les fois suivantes, seul le CA 10 doit être exécuté. Nous avons implémenté l’automatisation de la connexion d’un workspace Eclipse à un dépôt SVN distant et la mise d’un projet sous contrôle de version, dans des CA séparés, les CA 8 et 9, afin de séparer les préoccupations. Les figures 7.1 à 7.4 présentent des extraits de code des CA. C’est la méthode run de la figure 7.1 qui est appelée pour exécuter le CA 3, qui permet de générer un éditeur arborescent. Cette méthode fait elle-même appel à la méthode run de la figure 7.1, qui contient le code générant l’éditeur arborescent. Dans un premier temps (lignes 53 à 83) les noms du projet EMF et du fichier Ecore contenant la définition du métamodèle sont récupérés dans le modèle de contexte. Rappelons à cette occasion que commeApplication sur une famille de processus de métamodélisation 137 Figure 7.3 – Point d’entrée du CA initialisant la tâche de définition d’un interpréteur indiqué en section 6.5, le découplage de l’accès aux informations contextuelles de l’implémentation du CA, grâce au gestionnaire d’informations contextuelles, n’a pas encore été implémenté. Le code restant (de la ligne 83 à la fin) permet quant à lui de générer l’éditeur arborescent, en fonction du nom du projet EMF et du fichier Ecore précédemment récupérés. La méthode run de la figure 7.3 est appelée pour exécuter le CA 6, qui crée un nouveau projet Kermeta et l’initialise avec la génération du patron de conception interpréteur. Cette méthode appelle la méthode run de la figure 7.4. Cette dernière méthode commence par créer un nouveau projet Kermeta (lignes 59 à 67), puis elle appelle la méthode generateInterpreter (ligne 69). Cette dernière génère dans le projet Kermeta nouvellement créé le patron interpréteur pour chaque métaclasse d’un métamodèle, dont le nom du projet EMF et du fichier Ecore correspondant sont récupérés dans le modèle de contexte (cf. lignes 75 à 79). Le début de la méthode generateInterpreter est présenté à partir de la ligne 72. Pour résoudre la variabilité, au maximum 7 choix sont à faire dans ce cas. Il faut en effet déterminer si un interpréteur, un compilateur, un éditeur textuel, un éditeur arborescent ou un vérificateur sont requis pour un projet donné. Dans le cas ou un interpréteur (respectivement un éditeur textuel) est requis, la personne en charge de la résolution de la variabilité doit également déterminer si c’est l’outil SVN ou Git (respectivement XText ou EMFText) doit être utilisé. Dans le cadre de ce cas d’application, nous avons sélectionné un interpréteur, un compilateur, un éditeur arborescent ainsi qu’un vérificateur. Nous avons également sélectionné l’outil SVN comme SCV. La figure 7.5 illustre le processus résolu correspondant.138 Applications de l’approche Figure 7.4 – Extrait des méthodes permettant l’initialisation d’un interpréteur Kermeta Une démonstration du cas d’application de la famille de processus de métamodélisation peut être visualisée à l’adresse suivante : http://youtu.be/NYZT5cA5-cY. Les modèles ainsi que les CA relatifs à ce cas d’utilisation peuvent être consultés sur le dépôt SVN suivant : http://t4vasp.googlecode.com/svn/trunk/application_ metamodeling_process_line. Nous en présentons un extrait dans l’annexe A.Application sur une famille de processus de développement web Java 139 Figure 7.5 – Modèle de processus résolu du cas d’application de la famille de processus de métamodélisation 7.2 Application sur une famille de processus de développement web Java Nous présentons dans cette section l’application de T4VASP à une famille simplifiée de processus de développement d’une application web en Java, issue de Sodifrance. Nous commençons par présenter cette famille. Pour ce faire, nous introduisons d’abord un exemple simplifié de processus de développement web Java, illustré dans la figure 7.6. Nous détaillons ensuite des exemples de variantes de ce processus ainsi que les TMR qui ont lieu durant l’exécution des processus de cette famille et qui gagneraient à être automatisées. La sous-figure 7.6(a) montre le flot d’activités du processus de développement web Java illustré dans la figure 7.6, ainsi que les produits de travail consommés et produits par ces activités. L’exemple de processus de développement web Java présenté commence avec l’activité spécifier. Durant cette activité, un client produit un document définissant les spécifications techniques et fonctionnelles de l’application à développer, en fonction des exigences d’un projet. Vient ensuite l’activité développer, qui consiste à coder manuellement l’application à développer. L’activité tester suit, durant laquelle des développeurs testent l’application en cours de développement. Si cette activité révèle des erreurs dans le code de l’application, celles-ci doivent être corrigées, ce qui se traduit dans le processus par un retour à l’activité de développement. S’il n’y a pas d’erreurs, le processus se termine par l’activité mettre en140 Applications de l’approche (a) Flot d’activités et produits de travail associés (b) Détail de l’activité développer (c) Outils utilisés pendant l’activité développer Figure 7.6 – Un exemple simplifié de processus de développement web Java production, qui consiste à déployer l’application sur l’environnement du client. La sous-figure 7.6(b) détaille l’activité de développement. Celle-ci consiste, dans le cas de cet exemple, en la création et la modification de projets Eclipse. La sous-Application sur une famille de processus de développement web Java 141 figure 7.6(c) détaille les outils utilisés lors de l’activité de développement. L’environnement de développement est Eclipse, le SCV est SVN, le serveur web est Tomcat 1 , la base de données est MySQL 2 , le framework pour l’IHM web est Struts 3 et l’outil de compilation est Maven 4 . Il existe des variantes de ce processus, dont quelques exemples sont présentés dans ce paragraphe. Ainsi, si le client fournit les spécifications dans un langage interprétable par un ordinateur (par exemple UML 2), alors une activité de génération de code a lieu avant l’activité de développement. L’activité de génération de code consiste à générer le code Java qui est similaire pour toutes les entités de l’application à développer. Lorsque l’activité de génération de code a lieu, alors l’activité de développement consiste juste à rajouter manuellement le code qui n’a pas pu être généré. L’activité de mise en production peut également prendre des formes différentes. En effet, pendant cette activité, selon les exigences du client, la livraison de l’application peut se faire en livrant uniquement le code source de l’application, en livrant uniquement le code compilé de l’application, en livrant les deux (code source et code compilé), ou un ingénieur de Sodifrance peut aller chez le client pour installer lui-même l’application. Les exigences des projets peuvent également motiver l’utilisation d’outils autres que ceux présentés dans la sous-figure 7.6(c). Par exemple, une base de données Oracle 5 ou Postgresql 6 peut être utilisée à la place de la base de données MySQL, et il peut même ne pas y avoir de base de données s’il n’y a pas de donnée à persister. De même, Ant 7 peut être utilisé à la place de Maven, et un framework autre que Struts peut être utilisé pour l’IHM web, tel que JSF 8 (Java Server Faces), Flex 9 ou GWT 10 (Google Web Toolkit). Des TMR qui gagneraient à être automatisées ont lieu durant l’exécution des processus de cette famille. Nous en présentons ici quelques exemples. Ainsi, lors de l’initialisation de l’activité développer, chaque développeur et architecte doit configurer son environnement de travail Eclipse. Cette configuration consiste, entre autres, à installer les plug-ins Eclipse WTP 11 et Subclipse 12 (plug-ins permettant respectivement d’utiliser Tomcat et SVN dans Eclipse), à créer dans l’environnement de travail Eclipse un nouveau serveur Tomcat et à connecter l’espace de travail Eclipse à un dépôt SVN distant. Lors de l’initialisation de l’activité de développement, un architecte est de plus en charge de créer un nouveau dossier sur ce dépôt distant, qui contiendra le code de l’application à développer. La création d’un projet Eclipse se termine toujours par sa 1. http://tomcat.apache.org/ 2. http://www.mysql.com/ 3. http://struts.apache.org/ 4. http://maven.apache.org/ 5. http://www.oracle.com/us/products/database/overview/index.html 6. http://www.postgresql.org/ 7. http://ant.apache.org/ 8. http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html 9. http://www.oracle.com/technetwork/java/javaee/javaserverfaces-139869.html 10. http://www.gwtproject.org/ 11. http://www.eclipse.org/webtools/ 12. http://subclipse.tigris.org/142 Applications de l’approche mise sous contrôle de version, puis par sa propagation vers le dépôt SVN distant. En particulier, seules les sources contenues par ce projet doivent être mises sous contrôle de version, et pas les fichiers binaires contenant le code Java compilé, afin d’éviter de stocker des données inutiles sur le dépôt distant. La modification d’un projet Eclipse se termine toujours par la propagation des modifications sur le dépôt SVN distant. Le VAM de la famille de processus de développement web Java contient 27 élé- ments de modèle. Ce VAM permet de capturer les exigences de 512 projets différents, chacun ayant un processus différent. Le modèle de processus de base ainsi que le VRM de la famille de processus de développement web Java contiennent quant à eux respectivement 100 et 44 éléments de modèle. Le VAM, le modèle de processus de base ainsi que le VRM forment donc une ligne de processus capturant 512 processus différents. Le modèle de CA abstraits et de liaisons contient 25 éléments de modèle. Nous avons implémenté 9 CA en Java : 1. un CA permettant d’installer le plug-in Eclipse WTP, 2. un CA permettant d’installer le plug-in Eclipse Subclipse, 3. un CA permettant de redémarrer Eclipse, 4. un CA permettant de créer un nouveau serveur Tomcat, 5. un CA permettant de connecter un espace de travail Eclipse à un dépôt SVN distant, 6. un CA permettant de créer un nouveau dossier sur un dépôt SVN distant, 7. un CA permettant de mettre un projet Eclipse sous contrôle de version avec SVN (ce CA ne met sous contrôle de version que les sources, pas les fichiers binaires), 8. un CA permettant de propager avec SVN le code source d’un projet Eclipse spécifique vers un dépôt distant, 9. un CA permettant de propager vers un dépôt SVN distant particulier le code source de tous les projets Eclipse partagés sur ce dépôt, lorsque ceux-ci ont subit des modifications. Les CA 1 à 6 initialisent l’activité de développement. Le CA 1 a besoin pour s’exécuter du chemin, sur le poste local d’un développeur ou d’un architecte, de l’environnement Eclipse sur lequel installer le plug-in WTP. Le gestionnaire d’informations contextuelles demande cette information à l’acteur courant du processus et la sauvegarde dans le modèle de contexte. Le CA 2 a besoin pour s’exécuter de la même information contextuelle, que le gestionnaire d’informations contextuelles trouve donc dans le modèle de contexte. L’intérêt du CA 3 est de déployer dans l’environnement Eclipse les plug-ins nouvellement installés. Ce CA, tout comme le CA 4, n’a pas besoin d’informations contextuelles pour s’exécuter. Le CA 5 a besoin de trois informations contextuelles pour s’exécuter : l’URL d’un dépôt SVN distant, ainsi qu’un nom d’utilisateur et un mot de passe pour se connecter à ce dépôt distant. Le gestionnaire d’informations contextuelles demande ces trois informations à l’acteur courant du processus. Afin d’exécuter le CA 6, le gestionnaire d’informations contextuelles demande à un architecte le nom du dossier à créer sur le dépôt distant et récupère dansApplication sur une famille de processus de développement web Java 143 le modèle de contexte l’URL de ce dépôt distant. Afin de séparer les préoccupations, nous avons implémenté dans des CA différents (à savoir les CA 1 à 6) l’automatisation de l’installation des plug-ins WTP et Subclipse, le redémarrage d’Eclipse, la création d’un nouveau serveur Tomcat, la connection d’un espace de travail Eclipse à un dépôt SVN distant et la création d’un nouveau dossier sur un dépôt SVN distant. Les CA 7 et 8 finalisent la tâche de création d’un nouveau projet Eclipse. Le CA 7 a besoin de deux informations contextuelles pour s’exécuter : le nom du projet Eclipse à mettre sous contrôle de version et l’URL du dépôt distant. Le gestionnaire d’informations contextuelles demande la première information à l’acteur courant du processus, à chaque fois que le CA 7 est appelé, et sauve l’information dans le modèle de contexte en écrasant son ancienne valeur si elle existe. Cette information est en effet différente pour chaque projet, les projets à créer ne sont pas forcément connus à l’avance (il n’est donc pas possible de créer un CA spécifique à chaque projet) et l’information n’est pas réutilisée après l’exécution des CA 7 et 8 (le fait qu’elle soit écrasée ne pose donc pas de problème). Toujours pour le CA 7, le gestionnaire d’informations contextuelles récupère l’URL du dépôt distant dans le modèle de contexte. Pour le CA 8, le gestionnaire d’informations contextuelles récupère dans le modèle de contexte le nom du projet Eclipse à mettre sous contrôle de version. Nous avons implémenté dans deux CA différents (les CA 7 et 8) l’automatisation de la mise sous contrôle de version d’un projet Eclipse et la propagation de ce projet vers un dépôt SVN distant afin de séparer les préoccupations. Figure 7.7 – Code du CA permettant d’installer le plug-in Eclipse Subclipse Enfin, le CA 9 finalise la tâche de modification de projets Eclipse. Il a besoin pour144 Applications de l’approche Figure 7.8 – Code du CA créant un nouveau serveur Tomcat s’exécuter de l’URL du dépôt SVN distant. Le gestionnaire d’informations contextuelles récupère cette information dans le modèle de contexte. Les figures 7.7 et 7.8 présentent l’implémentation des CA 2 et 4 respectivement.Synthèse et discussion 145 L’implémentation du CA 2 consiste à exécuter une commande Windows installant, sur un environnement Eclipse,les archives Java relatives au plug-in Subclipse. L’implémentation du CA 4 consiste quant à elle à créer et sauvegarder un serveur Tomcat et une configuration associée. Pour résoudre la variabilité, la personne en charge de cette résolution doit faire au maximum 7 choix : déterminer le SCV, si une base de données est utilisée, et si oui de quel type de base de données il s’agit, le framework pour l’IHM, l’outil de compilation, si une partie du code est générée et le mode de livraison. Pour ce cas d’application nous avons sélectionné un processus avec SVN comme SCV, MySQL comme base de données, Struts comme framework pour l’IHM, Maven comme outil de compilation, sans génération de code, et avec livraison à la fois du code source et du code compilé. Le processus résolu correspondant est donc le même que celui de la figure 7.6. Une démonstration du cas d’application de la famille de processus de développement web Java peut être visualisée à l’adresse suivante : http://youtu.be/71shRD6ax9k. Les modèles ainsi que les CA relatifs à ce cas d’utilisation peuvent être consultés sur le dépôt SVN suivant : http://t4vasp.googlecode.com/svn/trunk/application_java_ development_process_line. Nous en présentons un extrait dans l’annexe B. 7.3 Synthèse et discussion Ces applications montrent que notre approche permet de gérer la variabilité et d’automatiser des exemples réels de processus, qui ont de nombreuses variantes ainsi que de nombreuses tâches récurrentes qui gagnent à être automatisées. Le tableau 7.1 récapitule le nombre d’éléments de modèle et de CA nécessaires à la réalisation de chacun des deux cas d’application. Cas d’application nb élts processus de base nb élts VAM nb élts VRM nb élts modèle CA abstraits et liaisons nb CA nb processus dans la famille Famille processus métamodélisation 134 39 123 27 10 128 Famille processus développement web Java 100 27 44 25 9 512 Table 7.1 – Tableau récapitulatif du nombre d’éléments de modèle et de CA pour chaque cas d’application Ces applications ont également permis d’observer des points forts de notre approche. Premièrement, pour les deux cas d’application, la modélisation des familles146 Applications de l’approche de processus avec CVL4SP s’est révélée être plus économique, en termes de nombre d’éléments à modéliser, que la modélisation en extension de ces familles. En effet, pour la famille de processus de métamodélisation, la ligne de processus est constituée de 296 éléments de modèle et capture 128 processus différents. La modélisation en extension de ces 128 processus aurait nécessité au moins 5248 éléments de modèle. En effet, la variante de processus de métamodélisation qui contient le moins d’éléments de modèle est celle qui consiste uniquement en la définition d’un métamodèle, et dans ce cas 41 éléments de processus sont nécessaires pour modéliser cette variante. Dans le cas de la famille de processus de développement web Java, la ligne de processus est constituée de 171 éléments de modèle et elle capture 512 processus différents. La modélisation en extension de ces 512 processus aurait nécessité au moins 41472 éléments de modèle. En effet, les variantes de processus qui contiennent le moins d’éléments de modèle sont celles sans génération de code et sans base de données, indépendamment des outils utilisés pour le SCV, l’IHM et la compilation, et indépendamment du mode de livraison considéré. Dans ce cas, 81 éléments de processus sont nécessaires pour modéliser une telle variante. Si, dans les deux cas d’application, la modélisation avec CVL4SP des familles de processus s’est révélée être plus économique que leur modélisation en extension, c’est parce que les familles sont modélisées en intention, et qu’assez d’éléments sont communs aux processus de chaque famille pour que leur factorisation permette de faire des économies de modélisation, même si cette factorisation implique de devoir modéliser plus d’éléments pour spécifier comment dériver un processus de la famille. D’une manière générale, quel que soit le cas d’application, plus les processus d’une famille ont d’éléments en commun, plus leur modélisation en intention permettra de réduire le nombre d’éléments à modéliser par rapport à la modélisation en extension. Le deuxième point fort observé est que l’automatisation des TMR permet de réduire l’occurrence des erreurs humaines. Par exemple, lors de la mise sous contrôle de version d’un projet Java Eclipse avec Subclipse, les fichiers binaires sont également ajoutés au contrôle de version par défaut. Il arrive que les personnes en charge de la mise sous contrôle de version d’un projet Java Eclipse oublient de retirer ces fichiers binaires du contrôle de version, ce qui n’arrive plus une fois que cette tâche est automatisée. Un troisième point fort observé lors de ces applications est que l’automatisation des TMR permet de gagner du temps lorsqu’une personne en charge de la réalisation d’une tâche ne sait pas comment la réaliser. En effet, l’automatisation d’une TMR permet à cette personne d’éviter de passer du temps à se former à la réalisation de cette tâche. Ces applications ont aussi permis de mettre en évidence une faiblesse de l’approche proposée dans cette thèse. Ainsi, M4RAC ne s’applique qu’au niveau d’une famille de processus, et ne permet donc pas d’améliorer la réutilisation de CA entre familles. Par exemple, les CA permettant de connecter un espace de travail Eclipse à un dépôt SVN distant, de mettre un projet sous contrôle de version et de propager du code source vers un dépôt distant sont communs aux deux cas d’application présentés dans ce chapitre. Or, comme M4RAC ne s’applique que sur un seul cas d’application à la fois, elle ne permet pas d’identifier le niveau de réutilisation de ces CA afin qu’ils soient réutilisables pour les deux cas d’application. Élargir M4RAC à l’ensemble des famillesSynthèse et discussion 147 de processus d’une entreprise permettrait de surmonter cette limitation.148 Applications de l’approche8 Conclusion et perspectives Dans ce chapitre, nous faisons le bilan des contributions cette thèse (section 8.1) et nous discutons les perspectives ouvertes par ces contributions (section 8.2). 8.1 Conclusion La complexité des logiciels et des projets de développement logiciel amène une multiplication des outils de développement logiciel afin de faire face à cette complexité. Par exemple, les systèmes de contrôle de version permettent de gérer les difficultés liées au travail collaboratif et géographiquement distribué, les outils de compilation, de test ou d’intégration continue supportent les méthodes de développement agiles, les IDE permettent d’intégrer les différentes technologies utilisées sur un projet, etc. De plus, des versions différentes de ces outils existent afin de satisfaire les besoins spécifiques à chaque projet, ce qui augmente le nombre d’outils existant. L’utilisation de tous ces outils est cependant à l’origine de nombreuses TMR (Tâches Manuelles Récurrentes), sources d’erreurs et coûteuses en temps. L’automatisation des TMR permet de réduire les erreurs liées à leur réalisation et donc le temps passé à corriger ces erreurs. La réutilisation des automatisations de TMR permet quant à elle de réduire le temps passé à les définir. Mais cette réutilisation est difficile. En effet, une automatisation de TMR n’étant pas forcément utile pour tous les projets et pouvant avoir des dépendances avec d’autres tâches, pour quels projets et à quels moments d’un projet réutiliser une automatisation de TMR ? De plus, une automatisation de TMR pouvant être utile dans des projets différents, ou à des moments différents d’un même projet, comment s’assurer qu’elle soit bien réutilisable à travers ses différents cas d’utilisation ? Dans la littérature, il n’y a, à notre connaissance, pas d’approche permettant à la fois de savoir pour quels projets réutiliser des automatisations de TMR et à quels moments d’un projet les réutiliser. De plus, même s’il existe des approches centrées sur la conception et le développement de composants logiciels réutilisables, celles-ci ne sont pas adaptées au cas des automatisations de TMR. En effet, elles sont spécifiques aux composants logiciel réalisant des produits logiciels et supposent que chaque caracté- 149150 Conclusion et perspectives ristique d’un produit logiciel est réalisée par un composant. Or, toutes les étapes d’un processus ne sont pas forcément réalisées par des automatisations de TMR. Afin de surmonter ces limitations, nous proposons dans cette thèse une approche pilotant l’automatisation des TMR par les processus de développement logiciel. Elle s’appuie sur une première sous-contribution, CVL4SP, afin de définir en intention une ligne de processus et d’en dériver un processus en fonction des exigences d’un projet. Des composants automatisant des TMR (CA) sont liés aux unités de travail de la ligne de processus qu’ils automatisent. L’approche proposée s’appuie sur une deuxième sous-contribution, M4RAC, afin d’améliorer la réutilisation de ces CA à travers les différentes unités de travail qu’ils automatisent. Un processus dérivé de la ligne de processus est automatisé en lançant, au fur et à mesure de son exécution, les CA qui lui sont liés. La réutilisation des CA passe donc par la réutilisation des processus de développement logiciel, le lien entre eux permettant de savoir pour quels projets et à quels moments d’un projet réutiliser ces CA. D’autre part, certaines contraintes de projet impliquant de commencer l’exécution d’un processus alors que sa variabilité n’est que partiellement résolue, l’approche proposée permet de résoudre de la variabilité lors de l’exécution d’un processus. Cela permet d’assurer le bon déroulement de l’exécution d’un processus même lorsque sa variabilité n’est que partiellement résolue. CVL4SP s’appuie sur CVL afin de gérer la variabilité des processus de développement logiciel. Le point fort de CVL4SP, en comparaison des autres approches gérant la variabilité dans les processus, est son indépendance vis-à-vis du formalisme utilisé pour définir les processus. M4RAC améliore l’identification du niveau de réutilisation des CA, c’est-à-dire des parties de ces CA qui varient et qui ne varient pas. Cette information est nécessaire à la création de CA réutilisables à travers leurs différents cas d’utilisation. M4RAC s’appuie sur le lien entre la ligne de processus et les CA afin d’identifier les différents contextes d’utilisation de ces derniers. Ce sont ces différents contextes d’utilisation qui guident l’identification du niveau de réutilisation d’un CA. L’avantage principal de M4RAC est qu’elle explicite les différents contextes d’utilisation de chaque CA, ce qui permet de ne pas en oublier et de ne pas prendre en compte des contextes d’utilisation inutiles. Afin de démontrer la faisabilité de notre approche, nous avons développé un outil la supportant : T4VASP. Il a été appliqué à deux cas d’utilisation, à savoir une famille de processus de métamodélisation et une famille de processus de développement web Java issue de Sodifrance. T4VASP permet de définir en intention une ligne de processus, de lui lier des CA, d’en dériver un processus en fonction des exigences d’un projet, d’automatiser l’exécution de ce processus et de résoudre sa variabilité non résolue au moment de son exécution. 8.2 Perspectives Les contributions de cette cette thèse ouvrent plusieurs perspectives de travail. Certaines sont d’ordre industriel, tandis que d’autres sont des pistes de recherche àPerspectives 151 investiguer à court et long terme. 8.2.1 Perspectives industrielles Nous présentons ici différents axes de travail afin de permettre l’utilisation de T4VASP dans un contexte industriel. 8.2.1.1 Utilisation de T4VASP quel que soit le cas d’application T4VASP ne fonctionne actuellement que dans un environnement local. Or, les projets de développement logiciel requièrent souvent l’intervention de plusieurs personnes, chacune ayant son propre poste de travail. Aussi, faire évoluer T4VASP vers une application client-serveur permettrait de l’utiliser en environnements distribués. Nous n’avons implémenté que les fonctionnalités de T4VASP permettant de l’utiliser avec les deux cas d’applications présentés dans cette thèse. L’implémentation des fonctionnalités restantes de T4VASP permettrait donc de pouvoir l’utiliser quel que soit le cas d’application. Les fonctionnalités non encore implémentées portent sur la prise en compte exhaustive de CVL par l’assistant à la résolution de la variabilité et par le moteur de dérivation, l’évaluation dynamique des expressions Kermeta, l’évaluation des conditions définies dans un modèle de CA abstraits et de liaisons, le découplage de l’accès aux informations contextuelles de l’implémentation des CA et la résolution de la variabilité à l’exécution. Nous avons vu dans la section 4.3.4 que la modélisation des éléments de processus externes pouvait se révéler difficile lorsqu’ils ne respectent pas toutes les contraintes définies sur leur métamodèle et que le modeleur utilisé ne permet pas de modéliser des éléments invalides. L’ajout à T4VASP d’un composant permettant de générer automatiquement ces éléments, ainsi que les éléments de modèle manquants pour les rendre valides, permettrait de faire face à cette difficulté. 8.2.1.2 Limitation des erreurs T4VASP ne permet actuellement pas à l’acteur courant du processus de lancer des initialisations ou des finalisations d’unités de travail lorsqu’elles ne sont pas automatisées. Elles sont alors traitées par l’interpréteur de processus comme si elles n’existaient pas. L’acteur courant du processus peut donc omettre de les réaliser. La solution idéale serait de pouvoir spécifier dans le modèle de processus qu’une unité de travail a une initialisation ou une finalisation, qu’elle soit manuelle ou non. Cela permettrait à l’interpréteur de processus de différencier les cas où une initialisation ou finalisation est manuelle de ceux où il n’y en a pas. Cependant, tous les langages de modélisation de processus ne permettent pas de définir qu’une unité de travail a une initialisation ou une finalisation. Une autre solution serait donc d’étendre le métamodèle de CA abstraits et de liaisons, afin que celui-ci permette de spécifier si une initialisation ou une finalisation d’unité de travail est manuelle. Cette extension pourrait prendre la forme d’une action spécifique qui serait une action manuelle. Cela permettrait que152 Conclusion et perspectives les unités de travail ayant des initialisations et finalisations manuelles soient traitées différemment de celles n’en ayant pas. CVL permet actuellement de dériver des modèles de processus résolus invalides, alors que le modèle de processus de base, le modèle d’abstraction de la variabilité (VAM), le modèle de réalisation de la variabilité (VRM) ainsi que le modèle de résolution de la variabilité (RM) sont valides. Pour rappel, nous avons identifié trois catégories d’erreurs qui rendent le modèle de processus résolu invalide. La première catégorie concerne les erreurs liées au non-respect de la compatibilité de type lorsqu’une nouvelle valeur est assignée à une instance de propriété. La deuxième catégorie englobe les erreurs liées au non-respect de la multiplicité d’une référence ou des contraintes définies sur le métamodèle du modèle de processus résolu. La troisième catégorie concerne les erreurs sémantiques, c’est-à-dire quand le modèle du processus résolu est bien conforme à son métamodèle, mais qu’il est trop permissif pour un métier donné ou qu’il contient des incohérences. Contraindre l’application des points de variation de CVL (opération à appliquer au modèle de base pour dériver un modèle résolu), à l’aide de contraintes exprimées de manière générique sur le métamodèle de CVL, permettrait d’éviter les erreurs de la première catégorie. Un outil générique d’analyse statique, qui assurerait que le modèle de processus résolu respecte bien les contraintes définies sur son métamodèle, permettrait d’éviter les erreurs de la deuxième caté- gorie. La modification du métamodèle de processus utilisé permettrait d’éviter les erreurs de la troisième catégorie. Cependant, dans les cas où cette modification s’avère trop coûteuse, un moteur de dérivation spécifique aux besoins d’un métier particulier permettrait de restreindre ce que le modèle de processus résolu peut capturer. Un outil vérifiant la consistance des pré et post conditions associées aux CA, ainsi qu’aux unités de travail qu’ils automatisent, permettrait quant à lui de s’assurer qu’un modèle de CA abstraits et de liaisons est correct. 8.2.1.3 Suppression des redondances dans le modèle de CA abstraits et de liaisons Dans le modèle de CA abstraits et de liaisons, il est actuellement nécessaire de spécifier quelle variante d’unité de travail chaque liste de CA automatise. Lorsque des variantes différentes d’une unité de travail sont automatisées par des listes différentes de CA, cela implique de définir plusieurs fois des éléments de modèle référençant la même unité de travail, en spécifiant à chaque fois à l’aide de conditions quelle est la variante de cette unité de travail. Afin de supprimer ces redondances, CVL pourrait être utilisé pour créer le modèle de CA abstraits et de liaisons correspondant à un modèle de processus résolu, en fonction des exigences d’un projet. Dans le modèle de CA abstraits et de liaisons, seule l’unité de travail automatisée par un CA serait spécifiée, sans préciser de quelle variante il s’agit. Une fois les exigences d’un projet définies, le modèle de CA abstraits et de liaisons serait transformé afin qu’il ne reste que les listes de CA correspondant aux variantes d’unités de travail qui sont dans le modèle de processus résolu.Perspectives 153 8.2.2 Perspectives de recherche à court terme En plus de l’application de notre approche à une famille de processus industriels (cf. section 7.2), une expérimentation, réalisée elle aussi dans un contexte industriel, permettrait de déterminer dans quelle proportion notre approche permet de réduire les temps de développement. Cette expérimentation pourrait consister à comparer le temps passé par un ensemble d’utilisateurs à réaliser un processus de développement logiciel manuellement et en utilisant l’approche et l’outillage de cette thèse. De plus, l’élaboration de l’approche proposée dans cette thèse ainsi que la conception et le dé- veloppement de l’outillage support et des CA implique un investissement en terme de temps. Les résultats de l’expérimentation permettraient donc de déterminer combien de processus de développement logiciel il est nécessaire d’automatiser en suivant notre approche pour obtenir un retour sur investissement. Cette information serait utile pour déterminer dans quels cas il est rentable d’appliquer notre approche. 8.2.3 Perspectives de recherche à long terme Nous abordons dans cette section les perspectives de recherche afin de gérer également la variabilité des processus qui a lieu pendant leur exécution et afin d’améliorer la réutilisation des CA. 8.2.3.1 Gestion de la variabilité des processus au moment de leur l’exécution Un processus en cours d’exécution peut avoir besoin d’être adapté à cause de changements au niveau de son environnement d’exécution ou de l’organisation d’une entreprise, parce que certaines parties d’un processus dépendent de l’exécution de parties amont, ou encore à cause des spécificités d’un projet [BFG93]. Étendre l’approche actuellement proposée dans cette thèse afin qu’elle permette de mettre à jour automatiquement le modèle du processus en cours d’exécution en fonction de certains évènements permettrait de répondre à ce besoin. Les travaux de Morin [Mor10], qui permettent de reconfigurer dynamiquement des modèles en réponse aux changements dans leur environnement d’exécution, pourraient être réutilisés à cette fin. Il faudrait également que les différents artéfacts de développement liés au processus en cours d’exécution soient adaptés, tout en assurant leur cohérence [DO04]. Pour ce faire, une piste serait de réutiliser les travaux de Fouquet [Fou13], qui permettent de piloter à partir des modèles la reconfiguration dynamique de composants dans un environnement distribué. La présence d’activités plus opportunes que celles définies par le processus peut justifier un besoin de déviation vis-à-vis de ce processus lors de son exécution [Vis90]. La difficulté est ici de dévier d’un processus tout en continuant à utiliser de manière cohérente les parties de ce processus qui restent pertinentes pour le projet [DO04]. Une piste de recherche serait donc d’étendre l’approche proposée dans cette thèse afin qu’elle permette de dévier du processus en cours d’exécution. À cette fin, les travaux de Kabbaj et al. [KLC08] pourraient être réutilisés. Ceux-ci permettent de détecter154 Conclusion et perspectives les déviations vis-à-vis d’un processus au moment de son exécution et de gérer ces déviations en les acceptant ou en les refusant. 8.2.3.2 Amélioration de la réutilisation des CA M4RAC ne s’appliquant qu’au niveau d’une famille de processus, elle ne permet pas d’améliorer la réutilisation de CA entre familles de processus. Étendre M4RAC, de manière à ce qu’elle s’applique à un ensemble de familles de processus, permettrait d’améliorer la réutilisation des CA entre familles de processus. Nous avons identifié une première directive pour implémenter les CA afin d’amé- liorer leur réutilisation : lorsque la ligne de processus spécifie qu’un outil peut être substitué par un autre, alors, dans l’implémentation d’un CA, les parties qui dépendent de cet outil doivent être découplées des parties qui n’en dépendent pas. Une perspective de travail serait d’identifier des recommandations supplémentaires pour implémenter les CA, afin d’améliorer encore leur capacité à être réutilisés. Il est difficile pour un humain d’identifier les contextes d’utilisation des CA, à cause de la définition en intention de processus, mais également à cause du nombre important de processus. En effet, il est dans ce cas difficile pour un humain de visualiser explicitement chacun des processus de la ligne et aussi de les intégrer mentalement. Un outil offrant un support à l’identification des contextes d’utilisation des CA serait une solution à ce problème. Il pourrait expliciter les différents processus d’une famille définie en intention, ainsi que les CA déjà associés à ces processus. Afin de limiter le nombre de processus affichés, il pourrait s’appuyer sur une définition de contextes d’utilisation de CA similaires, et donc n’afficher qu’un seul de ces contextes. La vérifi- cation de la consistance entre les pré et post-conditions associées aux CA permettrait quant à elle de détecter d’éventuelles erreurs au moment de l’association d’un CA à une unité de travail.Appendices 155Annexe A Extrait des modèles et CA de la famille de processus de métamodélisation Nous présentons dans cette annexe un extrait des modèles et des CA relatifs au cas d’application de la famille de processus de métamodélisation (cf. section 7.1). Un extrait du VAM de cette famille est illustré en figure A.1. Les choix tree editor, compiler, interpreter, checker, textual editor, EMFText, XText, version control system, SVN et Git doivent être résolus manuellement. De plus, les choix SVN et Git, tout comme les choix EMFText et XText, sont mutuellement exclusifs. La résolution des autres choix est quant à elle dérivée. Seul le choix version control system est obligatoire (propriété Is Implied By Parent à vrai). Dans le VRM, dont un extrait est présenté en figure A.2, les propriétés associées à la substitution de fin de lien compiler creation into metamodeling activity indiquent que la tâche de définition d’un compilateur est intégrée au processus le plus souvent utilisé (cf. figure 4.7) lorsque le choix compiler est sélectionné. Cette tâche est identifiée par le pointeur d’objet compiler creation et appartient initialement aux éléments de processus externes du modèle de processus de base (cf. figure 4.8). Les propriétés associées à la substitution de fin de lien Fork into metamodeling activity indiquent quant à elles que le nœud de parallélisation appartenant aux éléments de processus externes du modèle de processus de base est intégré au processus le plus souvent utilisé dès lors que des tâches sont exécutées en parallèle (choix parallelization résolu positivement). Le nœud de parallélisation est identifié par le pointeur d’objet Fork et le processus le plus souvent utilisé est représenté par l’activité Metamodeling Activity. La figure A.3 illustre un extrait du modèle de liaisons de la famille de processus de métamodélisation. Les propriétés des pointeurs d’unités de travail (éléments de type WorkUnitHandle sur la figure) spécifient quelles sont les étapes (initialisation, exécution, finalisation) de ces unités de travail qui sont automatisées, et par quels CA. Ainsi, l’initialisation et la finalisation de la définition d’un métamodèle sont respectivement automatisées par un CA créant un projet EMF vide (Primitive AC Create empty EMF 157158 Extrait des modèles et CA de la famille de processus de métamodélisation Figure A.1 – Extrait du VAM de la famille de processus de métamodélisation project) et par un CA validant le métamodèle créé (Primitive AC validate EMF model). L’exécution de la définition d’un éditeur arborescent est automatisée par un CA gé- nérant cet éditeur (Primitive AC generate tree editor). Les initialisations des définitions d’un compilateur, d’un interpréteur et d’un vérificateur sont automatisées par des CA créant et initialisant un projet Kermeta (Primitive AC create Kermeta compiler, Primitive AC create Kermeta interpreter, Primitive AC create Kermeta checker). Enfin, la finalisation de la définition d’un interpréteur est automatisée par une liste de CA (ACL put under version control, constituée des CA subclipse configuration, share project SVN et commit project SVN) mettant cet interpréteur sous contrôle de version. Tous les CA sont im-159 Figure A.2 – Extrait du VRM de la famille de processus de métamodélisation plémentés par des actions Java Eclipse. Parmi elles, l’action CreateEmptyEMFProject est implémentée par la classe CreateEmptyEMFProjectActivityAutomation, comme illustré par la figure A.4. La méthode run de cette classe lance deux assistants Eclipse (cf. figure A.5). Le premier demande à l’acteur courant le nom du nouveau projet EMF, sauve cette information dans le modèle de contexte et crée le nouveau projet EMF. Le deuxième réalise la même séquence d’étapes concernant le fichier Ecore contenant le métamodèle. Pour terminer, un extrait du RM est illustré par la figure A.6. Les propriétés des résolutions de choix tree editor, SVN et Git indiquent que les choix du même nom sont respectivement résolus à vrai, vrai et faux.160 Extrait des modèles et CA de la famille de processus de métamodélisation Figure A.3 – Extrait du modèle de liaisons de la famille de processus de métamodélisation161 Figure A.4 – Déclaration de la classe implémentant l’action Java Eclipse CreateEmptyEMFProject Figure A.5 – Code de la classe CreateEmptyEMFProjectActivityAutomation162 Extrait des modèles et CA de la famille de processus de métamodélisation Figure A.6 – Extrait du RM du cas d’application de la famille de processus de métamodélisation de la section 7.1Annexe B Extrait des modèles et CA de la famille de processus de développement web Java Nous présentons dans cette annexe un extrait des modèles et des CA relatifs au cas d’application de la famille de processus de développement web Java (cf. section 7.2). Figure B.1 – Extrait du VAM de la famille de processus de développement web Java 163164 Extrait des modèles et CA de la famille de processus de développement web Java Le VAM de cette famille, dont un extrait est illustré par la figure B.1, comporte 22 choix. Leur résolution est manuelle et ils permettent de déterminer le SCV, la base de données, le framework pour l’IHM web, l’outil de compilation, si une étape de génération de code intervient avant le développement manuel, ainsi que le mode de livraison. La figure B.2 illustre un extrait du VRM. La substitution d’objet SVN replaced by Git spécifie que l’outil SVN (référencé par le pointeur d’objet SVN) est remplacé par l’outil Git (référencé par le pointeur d’objet Git) lorsque le choix Git est sélectionné. L’existence d’objet MySQL spécifie que l’outil MySQL existe dans le modèle de processus résolu lorsque le choix MySQL est sélectionné. Sinon, cet outil est supprimé. La substitution d’objet MySQL replaced by Oracle spécifie quant à elle que l’outil MySQL est remplacé par l’outil Oracle lorsque le choix Oracle est sélectionné. Un extrait du modèle de liaisons est illustré par la figure B.3. Le pointeur d’unité de travail development spécifie que l’initialisation de l’activité de développement (Activity development) est automatisée par la liste de CA development initialization. Celle-ci permet : – d’installer les plug-ins WTP (Primitive AC install wtp) et Subclipse (Primitive AC install subclipse), – de rédémarrer Eclipse (Primitive AC restart), – d’initialiser un serveur Tomcat (Primitive AC new Tomcat server), – de connecter un espace de travail Eclipse à un nouveau dépôt SVN (Primitive AC subclipse configuration) – et de créer un nouveau dossier sur ce dépôt SVN (Primitive AC create directory on remote repository). Les pointeurs d’unité de travail project creation et first project creation spécifient que les tâches de création de projets (Task Use project creation et Task Use first project creation) sont finalisées par une liste d’AC (ACL share and commit project with SVN) mettant ce projet sous contrôle de version (Primitive AC share project with SVN) et propageant son contenu sur un dépôt distant (commit project with SVN). Le pointeur d’unité de travail projects modification spécifie que la tâche de modification de projets (Task Use projects modification) est finalisée par un CA propageant les modifications apportées sur un dépôt distant (Primitive AC commit the modified projects). Comme pour le cas d’application précédent, tous les CA sont implémentés par des actions Java Eclipse. Parmi elles, l’action Java Eclipse install wtp a pour identifiant installwtp. Comme illustré par les figures B.4 et B.5, cette action est implémentée par la classe InstallWTP et nécessite comme information contextuelle le chemin de l’environnement Eclipse sur lequel installer le plug-in. La méthode run de cette classe lance l’exécution d’une commande Windows installant, sur un environnement Eclipse, les archives Java relatives au plug-in WTP (cf. figure B.6). Enfin, la figure B.7 illustre un extrait du RM. Les propriétés des résolutions de choix SCV, SVN, Git et code generation indiquent que les choix du même nom sont respectivement résolus à vrai, vrai, faux et faux.165 Figure B.2 – Extrait du VRM de la famille de processus de développement web Java166 Extrait des modèles et CA de la famille de processus de développement web Java Figure B.3 – Extrait du modèle de liaisons de la famille de processus de développement web Java Figure B.4 – Déclaration de la classe implémentant l’action Java Eclipse install wtp167 Figure B.5 – Information contextuelle du CA installant le plug-in WTP Figure B.6 – Code de la classe InstallWTP168 Extrait des modèles et CA de la famille de processus de développement web Java Figure B.7 – Extrait du RM du cas d’application de la famille de processus de développement web Java de la section 7.2Bibliographie [AB12] J.A.H. Alegría and M.C. Bastarrica. Building Software Process Lines with CASPER. In ICSSP, pages 170–179, 2012. [ABC96] D. Avrilionis, N. Belkhatir, and P.-Y. Cunin. A unified framework for software process enactment and improvement. In ICSP, pages 102–111, 1996. [ABM00] C. Atkinson, J. Bayer, and D. Muthig. Component-Based Product Line Development : The KobrA Approach. In SPLC, pages 289–309, 2000. [ACG+12] M. Acher, P. Collet, A. Gaignard, P. Lahire, J. Montagnat, and R. France. ComposingMultiple Variability Artifacts to Assemble CoherentWork- flows. Software Quality Journal, 20(3-4) :689–734, 2012. [AD91] L.C. Alexander and A.M. Davis. Criteria for Selecting Software Process Models. In COMPSAC, pages 521–528, 1991. [Ald10] L. Aldin. Semantic Discovery and Reuse of Business Process Patterns. PhD thesis, School of Information Systems, Computing and Mathematics Brunel University, 2010. [Amb99] S. W. Ambler. More Process Patterns Delivering Large-Scale Systems Using Object Technology. Cambridge University Press, 1999. [ASKW11] A. Awad, S. Sakr, M. Kunze, and M. Weske. Design by Selection : A Reuse-Based Approach for Business Process Modeling. In ER, pages 332–345, 2011. [BBM05] J. Bhuta, B. Boehm, and S. Meyers. Process Elements : Components of Software Process Architectures. In SPW, pages 332–346, 2005. [BCCG07] R. Bendraou, B. Combemale, X. Cregut, and M.-P. Gervais. Definition of an Executable SPEM 2.0. In APSEC, pages 390–397, 2007. [BDK07] J. Becker, P. Delfmann, and R. Knackstedt. Adaptive Reference Modeling : Integrating Configurative and Generic Adaptation Techniques for Information Models. In RM, pages 27–58, 2007. [BDKK04] P. Becker, J. Delfmann, A. Dreiling, R. Knackstedt, and D. Kuropka. Configurative Process Modeling - Outlining an Approach to Increased Business Process Model Usability. In IRMA, pages 615–619, 2004. 169170 BIBLIOGRAPHIE [Ben07] R. Bendraou. UML4SPM : Un Langage De Modélisation De Procédés De Développement Logiciel Exécutable Et Orienté Modèle. PhD thesis, Université Pierre & Marie Curie - Paris VI, 2007. [BFG93] S.C. Bandinelli, A. Fuggetta, and C. Ghezzi. Software Process Model Evolution in the SPADE Environment. IEEE TSE, 19(12) :1128–1144, 1993. [BGB06] R. Bendraou, M.-P. Gervais, and X. Blanc. UML4SPM : An Executable Software Process Modeling Language Providing High-Level Abstractions. In EDOC, pages 297–306, 2006. [BnCCG11] S. J. Bolaños Castro, R. G. Crespo, and V. H. M. García. Patterns of Software Development Process. IJIMAI, 1(4) :33–40, 2011. [Boe88] B.W. Boehm. A Spiral Model of Software Development and Enhancement. Computer, 21(5) :61–72, 1988. [Boo91] G. Booch. Object Oriented Design : With Applications. Benjamin/- Cummings Publishing Company, 1991. [BSE03] F. Budinsky, D. Steinberg, and R. Ellersick. Eclipse Modeling Framework : A Developer’s Guide. Addison-Wesley Professional, 2003. [CA05] K. Czarnecki and M. Antkiewicz. Mapping Features to Models : A Template Approach Based on Superimposed Variants. InGPCE, pages 422–437, 2005. [CB05] S. Clarke and E. Baniassad. Aspect-Oriented Analysis and Design : The Theme Approach. Addison-Wesley, 2005. [CBHB07] M. Cataldo, M. Bass, J.D. Herbsleb, and L. Bass. On Coordination Mechanisms in Global Software Development. In ICGSE, pages 71– 80, 2007. [CC07] D. Ciuksys and A. Caplinskas. Reusing Ontological Knowledge about Business Processes in IS Engineering : Process Configuration Problem. Informatica, 18(4) :585–602, 2007. [CDCC+13] E. Céret, S. Dupuy-Chessa, G. Calvary, A. Front, and D. Rieu. A Taxonomy of Design Methods Process Models. Information and Software Technology, 55(5) :795 – 821, 2013. [CKO92] B. Curtis, M. I. Kellner, and J. Over. Process Modeling. Commun. ACM, 35(9) :75–90, 1992. [CLM+99] A. G. Cass, B. S. Lerner, E. K. McCall, L. J. Osterweil, and A. Wise. Logically Central, Physically Distributed Control in a Process Runtime Environment. Technical Report 99-65, University of Massachusetts at Amherst, 1999. [CLS+00] A. G. Cass, B. S. Lerner, S. M. Sutton, Jr., E. K. McCall, A. Wise, and L. J. Osterweil. Little-JIL/Juliette : A Process Definition Language and Interpreter. In ICSE, pages 754–757, 2000.BIBLIOGRAPHIE 171 [CN01] P. Clements and L. Northrop. Software Product Lines : Practices and Patterns. Addison-Wesley Longman Publishing Co., Inc., 2001. [Cox85] B.J. Cox. Object Oriented Programming. Addison-Wesley,Reading, MA, 1985. [Crn02] I. Crnkovic. Building Reliable Component-Based Software Systems. Artech House, Inc., 2002. [DB10] W. Derguech and S. Bhiri. Reuse-Oriented Business Process Modelling Based on a Hierarchical Structure. In BPM, pages 301–313, 2010. [Dij82] E. W. Dijkstra. On the Role of Scientific Thought. In Selected Writings on Computing : A Personal Perspective, pages 60–66. Springer-Verlag, 1982. [Dio93] R. Dion. Process Improvement and the Corporate Balance Sheet. IEEE Software, 10(4) :28–35, 1993. [DO04] J.-C. Derniame and F. Oquendo. Key Issues and New Challenges in Software Process Technology. UPGrade, The European Journal for the Informatics Professional, 5(5) :11–16, 2004. [FHMP+11] F. Fleurey, Ø. Haugen, B. Møller-Pedersen, A. Svendsen, and X. Zhang. Standardizing Variability - Challenges and Solutions. In SDL Forum, pages 233–246, 2011. [FL03] P. Fettke and P. Loos. Classification of reference models : a methodology and its application. Information Systems and e-Business Management, 1(1) :35–53, 2003. [Fou13] F. Fouquet. Kevoree : Model@Runtime pour le développement continu de systèmes adaptatifs distribués hétérogènes. PhD thesis, University of Rennes 1, 2013. [FPLPdL01] S. T. Fiorini, J. C. S. Prado Leite, and C. J. Pereira de Lucena. Process Reuse Architecture. In CAiSE, pages 284–298, 2001. [Fra99] U. Frank. Conceptual Modelling as the Core of the Information Systems Discipline – Perspectives and Epistemological Challenges. In AMCIS, pages 695–697, 1999. [GLKD98] K. Gary, T. Lindquist, H. Koehnemann, and J.-C. Derniame. Component-based Software Process Support. In ASE, pages 196–199, 1998. [GM05] R. J. Glushko and T. S. McGrath. Document Engineering : Analyzing And Designing Documents For Business Informatics & Web Services. MIT Press, 2005. [Guy13] C. Guy. Facilités de typage pour l’ingénierie des langages. PhD thesis, Université de Rennes 1, 2013. [GvdAJV07] F. Gottschalk, W. M. P. van der Aalst, and M. H. Jansen-Vullers. SAP WebFlow Made Configurable : Unifying Workflow Templates into a Configurable Model. In BPM, pages 262–270, 2007.172 BIBLIOGRAPHIE [GvdAJVLR08] F. Gottschalk, W. M.P. van der Aalst, M. H. Jansen-Vullers, and M. La Rosa. Configurable Workflow Models. Cooperative Information Systems, 17(2) :177–221, 2008. [HABQO11] J.A. Hurtado Alegría, M.C. Bastarrica, A. Quispe, and S.F. Ochoa. An MDE Approach to Software Process Tailoring. In ICSSP, pages 43–52, 2011. [Ham96] Michael Hammer. Beyond Reengineering : How the Process-Centered Organization is Changing Our Work and Our Lives. Harper Collins Publishers, 1996. [HBR10] A. Hallerbach, T. Bauer, and M. Reichert. Capturing Variability in Business Process Models : the Provop Approach. Software Maintenance, 22(67) :519–546, 2010. [HIMT96] N. Hanakawa, H. Iida, K.-i. Matsumoto, and K. Torii. A Framework of Generating Software Process Including Milestones for ObjectOriented Development Method. In APSEC, pages 120–130, 1996. [HMR06] J. D. Herbsleb, A. Mockus, and J. A. Roberts. Collaboration in Software Engineering Projects : A Theory of Coordination. In ICIS, 2006. [Hum88] W. S. Humphrey. The Software Engineering Process : Definition and Scope. SIGSOFT Softw. Eng. Notes, 14(4) :82–83, 1988. [HWRK11] J. Hutchinson, J. Whittle, M. Rouncefield, and S. Kristoffersen. Empirical Assessment of MDE in Industry. In ICSE, pages 471–480, 2011. [HZG+97] J. Herbsleb, D. Zubrow, D. Goldenson, W. Hayes, and M. Paulk. Software Quality and the Capability Maturity Model. Commun. ACM, 40(6) :30–40, 1997. [IMCH+07] C. Iochpe, C. Ming Chiao, G. Hess, G. Nascimento, L. Thom, and M. Reichert. Towards an intelligent workflow designer based on the reuse of workflow patterns. In WBPM, 2007. [Ins95] Software Engineering Institute. The Capability Maturity Model : Guidelines for Improving the Software Process. Addison-Wesley, 1995. [Ins13] CMMI Institute. Maturity Profile Reports, September 2013. [ISO07] ISO/IEC. ISO/IEC 24744 :2007 Software Engineering – Metamodel for Development Methodologies, 2007. [Ist13] P. Istoan. Methodology for the derivation of product behaviour in a Software Product Line. PhD thesis, University of Rennes 1 and University of Luxembourg, 2013. [JCV12] J.-M. Jézéquel, B. Combemale, and D. Vojtisek. Ingénierie Dirigée par les Modèles : des concepts à la pratique... Ellipses, 2012. [Jéz12] J.-M. Jézéquel. Model-Driven Engineering for Software Product Lines. ISRN Software Engineering, 2012(2012), 2012.BIBLIOGRAPHIE 173 [JMD04] T. Javed, M. Maqsood, and Q. S. Durrani. A Study to Investigate the Impact of Requirements Instability on Software Defects. SIGSOFT Softw. Eng. Notes, 29(3) :1–7, 2004. [KB10] V. Kulkarni and S. Barat. Business Process Families Using ModelDriven Techniques. In BPM, pages 314–325, 2010. [KCH+90] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Technical report, Carnegie-Mellon University Soft. Eng. Institute, 1990. [KKL+98] C. K. Kang, S. Kim, J. Lee, K. Kim, E. Shin, and M. Huh. FORM : A Feature-Oriented Reuse Method with Domain-Specific Reference Architectures. Annals of Software Engineering, 5 :143–168, 1998. [KL07] B. Korherr and B. List. A UML 2 Profile for Variability Models and their Dependency to Business Processes. In DEXA, pages 829–834, 2007. [KLC08] M. Kabbaj, R. Lbath, and B. Coulette. A Deviation Management System for Handling Software Process Enactment Evolution. In ICSP, pages 186–197, 2008. [KR10] M. Khaari and R. Ramsin. Process Patterns for Aspect-Oriented Software Development. In ECBS, pages 241–250, 2010. [Kru92] C. W. Krueger. Software Reuse. ACM Comput. Surv., 24(2) :131–183, 1992. [Kru06] C. W. Krueger. Introduction to the Emerging Practice of Software Product Line Development. Methods and Tools, 14(3) :3–15, 2006. [KSG04] J. Kim, M. Spraragen, and Y. Gil. An Intelligent Assistant for Interactive Workflow Composition. In IUI, pages 125–131, 2004. [KY12] A. Kumar and W. Yao. Design and management of flexible process variants using templates and rules. Comput. Ind., 63(2) :112–130, 2012. [KYSR09] E. Kouroshfar, H. Yaghoubi Shahir, and R. Ramsin. Process Patterns for Component-Based Software Development. In CBSE, pages 54–68, 2009. [LK04] K. Lee and K. Kang. Feature Dependency Analysis for Product Line Component Design. In ICSR, pages 69–85, 2004. [LKCC00] K. Lee, K. C. Kang, W. Chae, and B. W. Choi. Featured-Based Approach to Object-Oriented Engineering of Applications for Reuse. Softw. Pract. Exper., 30(9) :1025–1046, 2000. [LRDtHM11] M. La Rosa, M. Dumas, A. H.M. ter Hofstede, and J. Mendling. Configurable Multi-Perspective Business Process Models. Information Systems : Databases : Their Creation, Management and Utilization, 36(2) :313–340, 2011.174 BIBLIOGRAPHIE [LRvdADM13] M. La Rosa,W.M.P. van der Aalst,M. Dumas, and F. P.Milani. Business Process Variability Modeling : A Survey. ACM Computing Surveys, 2013. [LS07] R. Lu and S. Sadiq. On the Discovery of Preferred Work Practice Through Business Process Variants. In ER, pages 165–180, 2007. [Mar03] R. C. Martin. Agile Software Development : Principles, Patterns, and Practices. Prentice Hall/Pearson Education, 2003. [MBF13] S. Mosser and M. Blay-Fornarino. "Adore", a Logical Meta-model Supporting Business Process Evolution. Sci. Comput. Program., 78(8) :1035–1054, 2013. [Mee10] S. Meerkamm. Configuration of Multi-perspectives Variants. In BPM, pages 277–288, 2010. [MHY08] M. Moon, M. Hong, and K. Yeom. Two-Level Variability Analysis for Business Process with Reusability and Extensibility. In COMPSAC, pages 263–270, 2008. [Mor10] B. Morin. Leveraging Models from Design-time to Runtime to Support Dynamic Variability. PhD thesis, University of Rennes 1, 2010. [MRGP08] T. Martínez-Ruiz, F. García, and M. Piattini. Towards a SPEM v2.0 Extension to Define Process Lines Variability Mechanisms. In SERA, pages 115–130, 2008. [MRGPM11] T. Martínez-Ruiz, F. García, M. Piattini, and J. Münch. Modelling Software Process Variability : an Empirical Study. IET Software, 5(2) :172– 187, 2011. [NCH11] T. Nguyen, A. Colman, and J. Han. Modeling and Managing Variability in Process-Based Service Compositions. In ICSOC, pages 404–420, 2011. [Nor08] L. Northrop. Software Product Lines Essentials, 2008. [OAS07] OASIS. Web Services Business Process Execution Language Version 2.0, 2007. [oD11] United States Department of Defense. Technology Readiness Assessment (TRA) Guidance, 2011. [OMG06] OMG. Meta Object Facility (MOF) 2.0 Core Specification, 2006. [OMG08] OMG. Software and Systems Process Engineering Metamodel Speci- fication (SPEM) Version 2, 2008. [OMG10] OMG. Documents associated with Object Constraint Language, Version 2.2, 2010. [OMG11a] OMG. Documents Associated with Business Process Model and Notation (BPMN) Version 2.0, 2011. [OMG11b] OMG. OMG Unified Modeling Language (OMG UML), Infrastructure Version 2.4.1, 2011.BIBLIOGRAPHIE 175 [OMG11c] OMG. OMG Unified Modeling Language (OMG UML), Superstructure Version 2.4.1, 2011. [OMG12] OMG. Diagram Definition (DD) Version 1.0, 2012. [Ost87] L. Osterweil. Software Processes are Software Too. In ICSE, pages 2–13, 1987. [PBL05] K. Pohl, G. Böckle, and F. J. van der Linden. Software Product Line Engineering : Foundations, Principles and Techniques. Springer, 2005. [PEM95] G. Pérez, K. Emam, and N. H. Madhavji. Customising Software Process Models. In SPT, pages 70–78, 1995. [PS05] V. Pankratius and W. Stucky. A Formal Foundation for Workflow Composition, Workflow View Definition, and Workflow Normalization Based on Petri Nets. In APCCM, pages 79–88, 2005. [PSWW05] F. Puhlmann, A. Schnieders, J. Weiland, and M. Weske. Variability Mechanisms for Process Models. Technical report, PESOA-Report TR 17/2005, Process Family Engineering in Service-Oriented Applications (PESOA), 2005. [RBJ07] R. Ramos, O. Barais, and J.M. Jézéquel. Matching Model-Snippets. In MoDELS 07, pages 121–135, 2007. [RBSS09] I. Reinhartz-Berger, P. Soffer, and A. Sturm. Organisational reference models : Supporting an adequate design of local business processes. International Journal of Business Process Integration and Management, 4(2) :134–149, 2009. [RBSS10] I. Reinhartz-Berger, P. Soffer, and A. Sturm. Extending the Adaptability of Reference Models. IEEE Transactions on Systems, Man and Cybernetics, Part A : Systems and Humans, 40(5) :1045–1056, 2010. [RCB+11] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Bridging the Gap between Software Process and Software Development. In IDM, pages 103–108, 2011. [RCB+12] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Leveraging CVL to Manage Variability in Software Process Lines. In APSEC, pages 148–157, 2012. [RCB+13a] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Improving Reusability in Software Process Lines. In SEAA, pages 90–94, 2013. [RCB+13b] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Integrating Software Process Reuse and Automation. In APSEC, pages 380–387, 2013. [RDH+08] M. Rosa, M. Dumas, A. H. Hofstede, J. Mendling, and F. Gottschalk. Beyond Control-Flow : Extending Business Process Configuration to Roles and Objects. In ER, pages 199–215, 2008.176 BIBLIOGRAPHIE [RGC04] F. Ruiz-Gonzalez and G. Canfora. Software Process : Characteristics, Technology and Environments. UPGrade, The European Journal for the Informatics Professional, 5(5) :6–10, 2004. [RHEdA05] N. Russell, A. H. M. Hofstede, D. Edmond, and W. M. P. der Aalst. Workflow Data Patterns : Identification, Representation and Tool Support. In ER, pages 353–368, 2005. [RK08] M. Razavian and R. Khosravi. Modeling Variability in Business Process Models Using UML. In ITNG, pages 82–87, 2008. [RMvdT09] H. A. Reijers, R. S. Mans, and R. A. van der Toorn. Improved Model Management with Aggregated Business Process Models. Data Knowledge Engineering, 168(2) :221–243, 2009. [Rom05] H. D. Rombach. Integrated Software Process and Product Lines. In ISPW, pages 83–90, 2005. [Roy87] W. W. Royce. Managing the Development of Large Software Systems : Concepts and Techniques. In ICSE, pages 328–338, 1987. [RTM10] S. H. Ripon, K. H. Talukder, and M. K. I. Molla. Modelling Variability for System Families. Malaysian Journal of Computer Science, 16(1) :37– 46, 2010. [RvdA07] M. Rosemann and W. M. P. van der Aalst. A Configurable Reference Modelling Language. Information Systems, 32(1) :1–23, 2007. [SA09] A. Sadovykh and A. Abherve. MDE Project Execution Support via SPEM Process Enactment. In MDTPI, 2009. [SB11] J. Simmonds and M. C. Bastarrica. Modeling Variability in Software Process Lines. Technical report, Universidad de Chile, 2011. [SBPM09] D. Steinberg, F. Budinsky, M Paternostro, and E. Merks. EMF : Eclipse Modeling Framework 2.0. Addison-Wesley Professional, 2009. [Sch00] A.-W. Scheer. Aris-Business Process Modeling. Springer-Verlag New York, Inc., 2000. [SCO07] B. I. Simidchieva, L. A. Clarke, and L. J. Osterweil. Representing Process Variation with a Process Family. In ICSP, pages 109–120, 2007. [SCS10] E. Santos, J. Castro, and O. Sánchez, J.and Pastor. A Goal-Oriented Approach for Variability in BPMN. In WER, pages 17–28, 2010. [SdSSB+10] I. Sharon, M. dos Santos Soares, J. Barjis, J. van den Berg, and J. L. M. Vrancken. A Decision Framework for Selecting a Suitable Software Development Process. In ICEIS, pages 34–43, 2010. [SO98] X. Song and L. J. Osterweil. Engineering Software Design Processes to Guide Process Execution. IEEE Transactions on Software Engineering, 24(9) :759–775, 1998.BIBLIOGRAPHIE 177 [Ter09] T. Ternité. Process Lines : A Product Line Approach Designed for Process Model Development. In SEAA, pages 173–180, 2009. [Tho05] O. Thomas. Understanding the Term Reference Model in Information Systems Research : History, Literature Analysis and Explanation. In BPM, pages 484–496, 2005. [TI93] T. Tamai and A. Itou. Requirements and Design Change in LargeScale Software Development : Analysis from the Viewpoint of Process Backtracking. In ICSE, pages 167–176, 1993. [VDATHKB03] W. M. P. Van Der Aalst, A. H. M. Ter Hofstede, B. Kiepuszewski, and A. P. Barros. Workflow Patterns. Distrib. Parallel Databases, 14(1) :5– 51, 2003. [VG07] M. Voelter and I. Groher. Product Line Implementation using AspectOriented and Model-Driven Software Development. In SPLC, pages 233–242, 2007. [Vis90] W. Visser. More or Less Following a Plan During Design : Opportunistic Deviations in Specification. International Journal of Man-Machine Studies, 33(3) :247–278, 1990. [(WF99] WorkFlow Managment Coalition (WFMC). Terminology & Glossary, Document Number WFMC-TC-1011, 1999. [Wis06] A. Wise. Little-jil 1.5 language report. Technical Report UM-CS-2006- 51, Department of Computer Science, University of Massachusetts, Amherst, MA, 2006. [WKK+11] M. Weidmann, F. Koetter, M. Kintz, D. Schleicher, and R. Mietzner. Adaptive Business Process Modeling in the Internet of Services (ABIS). In ICIW, pages 29–34, 2011. [WL99] D. M. Weiss and C. T. R. Lai. Software Product-Line Engineering : A Family-Based Software Development Process. Addison-Wesley Professional, 1999. [YLL+08] Y. Yu, A. Lapouchnian, S. Liaskos, J. Mylopoulos, and J. C.S.P. Leite. From Goals to High-Variability Software Design. In ISMIS, pages 1–16, 2008. [Zam01] K. Z. Zamli. Process Modeling Languages : A Literature Review. Malaysian Journal of Computer Science, 14(2) :26–37, 2001. [Zhu03] H. Zhuge. Component-based workflow systems development. Decision Support Systems, 35(4) :517 – 536, 2003. [ZXD05] W. Zhongjie, X. Xiaofei, and Z. Dechen. A Component Optimization Design Method Based on Variation Point Decomposition. In SERA, pages 399–406, 2005.178 BIBLIOGRAPHIEListe des figures 2.1 Modèle conceptuel de SPEM . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.2 Structure du métamodèle de SPEM 2.0 [OMG08] . . . . . . . . . . . . . . 19 2.3 Extraits de certains paquetages du métamodèle de SPEM 2.0 . . . . . . . 20 2.4 Syntaxe concrète de SPEM 2.0 et des diagrammes d’activités . . . . . . . 21 2.5 Un processus simplifié de développement Java . . . . . . . . . . . . . . . 22 2.6 Détail de l’activité de développement du processus de la figure 2.5 . . . 22 2.7 Éléments de contenu de méthode du processus simplifié de développement Java de la figure 2.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.8 Principe général de CVL, issu de la spécification de CVL 4 . . . . . . . . 24 2.9 Extrait de la partie abstraction de la variabilité du métamodèle de CVL . 25 2.10 Exemple VAM spécifiant la variabilité d’un site d’achat en ligne . . . . . 26 2.11 Extrait de la partie réalisation de la variabilité du métamodèle de CVL . 27 2.12 VRM de l’exemple de site d’achat en ligne . . . . . . . . . . . . . . . . . . 28 2.13 Extrait de la partie résolution de la variabilité du métamodèle de CVL . 29 2.14 Exemple de RM résolvant le VAM de la figure 2.10 . . . . . . . . . . . . . 29 2.15 Modèle résolu obtenu en fonction des modèles des figures 2.10, 2.12 et 2.14 30 2.16 Exemple de définition d’affectation d’attribut, d’existence de lien et d’existence d’attribut . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.17 Modèle résolu obtenu lorsque le choix de la figure 2.16 est sélectionné . 31 2.18 Modèle résolu obtenu lorsque le choix de la figure 2.16 n’est pas sélectionné 31 2.19 Exemple de VAM, VRM et modèle de base pour une substitution de fragment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.20 Modèle résolu obtenu lorsque le classificateur de variabilité de la fi- gure 2.19 est résolu par une seule instance de variabilité . . . . . . . . . . 32 2.21 Modèle résolu obtenu lorsque le classificateur de variabilité de la fi- gure 2.19 est résolu par deux instances de variabilité . . . . . . . . . . . . 32 2.22 Illustration du principe du point de variation composite . . . . . . . . . 33 3.1 Représentation en extension des processus d’une famille [LS07] . . . . . 36 3.2 Un exemple de modèle de processus agrégat [HBR10] . . . . . . . . . . . 44 3.3 Exemple de définition de points de variation et de variantes sur un modèle de processus [MHY08] . . . . . . . . . . . . . . . . . . . . . . . . 47 3.4 Principe général de la contribution principale . . . . . . . . . . . . . . . . 65 4.1 Flot de tâches de l’exemple illustratif de processus de métamodélisation 68 179180 LISTE DES FIGURES 4.2 Ressources de l’exemple illustratif de processus de métamodélisation . . 68 4.3 Partie de la contribution principale réalisée par CVL4SP . . . . . . . . . . 70 4.4 Apperçu de l’approche consistant à utiliser CVL pour gérer la variabilité dans les processus de développement logiciel . . . . . . . . . . . . . . . . 70 4.5 Processus de l’approche consistant à utiliser CVL pour gérer la variabilité dans les processus de développement logiciel . . . . . . . . . . . . . 71 4.6 Eléments de contenu de méthode de l’exemple illustratif . . . . . . . . . 74 4.7 Processus le plus souvent utilisé de l’exemple illustratif . . . . . . . . . . 74 4.8 Eléments de processus externes de l’exemple illustratif . . . . . . . . . . 75 4.9 Extrait du VAM de l’exemple illustratif . . . . . . . . . . . . . . . . . . . 76 4.10 Extrait du VRM de l’exemple illustratif . . . . . . . . . . . . . . . . . . . 77 4.11 Extrait du RM de l’exemple illustratif . . . . . . . . . . . . . . . . . . . . 78 4.12 Modèle de processus résolu . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.13 Séquence de travail sur-spécifiée . . . . . . . . . . . . . . . . . . . . . . . 82 5.1 Extrait d’un script PowerShell qui automatise la configuration de l’espace de travail d’un développeur . . . . . . . . . . . . . . . . . . . . . . . 87 5.2 Partie de la contribution principale réalisée par M4RAC . . . . . . . . . . 88 5.3 Vue générale de M4RAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.4 Première étape de M4RAC . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 5.5 Exemple simplifié de ligne de processus de développement Java . . . . . 90 5.6 Deuxième étape de M4RAC . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.7 Troisième étape de M4RAC . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.8 Liaison entre le CA configurant l’espace de travail d’un développeur et la ligne de processus de la figure 5.5 . . . . . . . . . . . . . . . . . . . . . 93 5.9 Quatrième étape de M4RAC . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.10 Liaisons entre les CA permettant de configurer l’espace de travail d’un développeur et la ligne de processus de la figure 5.5 . . . . . . . . . . . . 95 5.11 Cinquième étape de M4RAC . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.12 Extrait du CA automatisant l’étape 1 de la configuration de l’espace de travail d’un développeur, avec SVN . . . . . . . . . . . . . . . . . . . . . 96 5.13 Extrait du CA automatisant l’étape 1 de la configuration de l’espace de travail d’un développeur, avec Git . . . . . . . . . . . . . . . . . . . . . . 96 5.14 Extrait du CA automatisant les étapes 2 à 5 de la configuration de l’espace de travail d’un développeur . . . . . . . . . . . . . . . . . . . . . 97 6.1 Vue générale de l’architecture de T4VASP . . . . . . . . . . . . . . . . . . 108 6.2 Partie de l’approche supportée par les modeleurs de VAM et de VRM . . 110 6.3 Partie de l’approche supportée par les modeleurs de CA abstraits et de liaisons et le framework support à l’implémentation des CA . . . . . . . . 110 6.4 Partie de l’approche supportée par l’assistant à la résolution de la variabilité et le moteur de dérivation CVL . . . . . . . . . . . . . . . . . . . . . 112 6.5 Partie de l’approche supportée par l’interpréteur de processus . . . . . . 113LISTE DES FIGURES 181 6.6 Extrait du VAM de l’exemple illustratif de la famille de processus de modélisation, édité avec le modeleur de VAM . . . . . . . . . . . . . . . . 114 6.7 Extrait du VRM de l’exemple illustratif de la famille de processus de modélisation, édité avec le modeleur de VRM . . . . . . . . . . . . . . . . 114 6.8 Propriétés de l’existence d’objet tree editor de la figure 6.7 . . . . . . . . . 114 6.9 Métamodèle de CA abstraits et de liaisons . . . . . . . . . . . . . . . . . . 115 6.10 Diagramme d’objets représentant un extrait du modèle de CA abstraits et de liaisons de l’exemple illustratif . . . . . . . . . . . . . . . . . . . . . 116 6.11 Extrait du modèle de CA abstraits et de liaisons de l’exemple illustratif de la famille de processus de modélisation, édité avec le modeleur de CA abstraits et de liaisons . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.12 Composants du framework . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.13 Enregistrement auprès du point d’extension activityautomationregistry . . 118 6.14 Comportement du gestionnaire d’informations contextuelles . . . . . . . 119 6.15 Extrait du modèle de contexte d’un processus de métamodélisation avec contrôle de version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.16 Exemple de déclaration par un CA d’informations contextuelles . . . . . 121 6.17 Exemple de demande d’informations contextuelles à l’acteur courant du processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122 6.18 Utilisation de l’assistant à la résolution de la variabilité avec l’exemple illustratif de famille de processus de métamodélisation . . . . . . . . . . 123 6.19 Comportement du moteur de dérivation CVL . . . . . . . . . . . . . . . . 124 6.20 Comportement de l’interpréteur de processus . . . . . . . . . . . . . . . . 125 6.21 Détection de variabilité non résolue . . . . . . . . . . . . . . . . . . . . . 126 6.22 Vue processus d’une variante de processus de métamodélisation . . . . . 128 7.1 Point d’entrée du CA permettant de générer un éditeur arborescent . . . 135 7.2 Méthode run de la classe GenerateTreeEditor, appelée par la méthode run de la figure 7.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 7.3 Point d’entrée du CA initialisant la tâche de définition d’un interpréteur 137 7.4 Extrait des méthodes permettant l’initialisation d’un interpréteur Kermeta138 7.5 Modèle de processus résolu du cas d’application de la famille de processus de métamodélisation . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.6 Un exemple simplifié de processus de développement web Java . . . . . 140 7.7 Code du CA permettant d’installer le plug-in Eclipse Subclipse . . . . . 143 7.8 Code du CA créant un nouveau serveur Tomcat . . . . . . . . . . . . . . 144 A.1 Extrait du VAM de la famille de processus de métamodélisation . . . . . 158 A.2 Extrait du VRM de la famille de processus de métamodélisation . . . . . 159 A.3 Extrait du modèle de liaisons de la famille de processus de métamodé- lisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 A.4 Déclaration de la classe implémentant l’action Java Eclipse CreateEmptyEMFProject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 A.5 Code de la classe CreateEmptyEMFProjectActivityAutomation . . . . . 161182 LISTE DES FIGURES A.6 Extrait du RM du cas d’application de la famille de processus de métamodélisation de la section 7.1 . . . . . . . . . . . . . . . . . . . . . . . . . 162 B.1 Extrait du VAM de la famille de processus de développement web Java . 163 B.2 Extrait du VRM de la famille de processus de développement web Java . 165 B.3 Extrait du modèle de liaisons de la famille de processus de développement web Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 B.4 Déclaration de la classe implémentant l’action Java Eclipse install wtp . . 166 B.5 Information contextuelle du CA installant le plug-in WTP . . . . . . . . 167 B.6 Code de la classe InstallWTP . . . . . . . . . . . . . . . . . . . . . . . . . 167 B.7 Extrait du RM du cas d’application de la famille de processus de développement web Java de la section 7.2 . . . . . . . . . . . . . . . . . . . . . 168Liste des tables 3.1 Évaluation des approches permettant d’identifier le processus correspondant le mieux à un projet . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2 Évaluation des approches de Lu et Sadiq [LS07] et Song et Osterweil [SO98] 41 3.3 Évaluation des approches apportant un support à la réutilisation de patrons de processus, mais sans permettre la réutilisation automatique de processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 3.4 Évaluation des approches s’appuyant sur l’ingénierie des lignes de processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.5 Évaluation de l’ensemble des approches supportant la réutilisation des processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.1 Exemples de TMR réalisées durant un processus de métamodélisation . 106 7.1 Tableau récapitulatif du nombre d’éléments de modèle et de CA pour chaque cas d’application . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 183184 LISTE DES TABLESListe des publications [RCB+11] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Bridging the Gap between Software Process and Software Development. In IDM, pages 103–108, 2011. [RCB+12] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Leveraging CVL to Manage Variability in Software Process Lines. In APSEC, pages 148–157, 2012. [RCB+13a] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Improving Reusability in Software Process Lines. In SEAA, pages 90–94, 2013. [RCB+13b] E. Rouillé, B. Combemale, O. Barais, D. Touzet, and J.-M. Jézéquel. Integrating Software Process Reuse and Automation. In APSEC, pages 380–387, 2013. 185Résumé De nombreux outils existent afin de faire face à la complexité des logiciels et des projets de développement logiciel. Leur utilisation est cependant à l’origine de tâches manuelles répétitives, sources d’erreurs et coûteuses en temps. L’automatisation de ces tâches permet de gagner en productivité. Mais la difficulté est de déterminer quand une automatisation de tâche manuelle répétitive doit être réutilisée, ainsi que de créer des automatisations réutilisables à travers leurs différents cas d’utilisation. Nous proposons donc une approche outillée pilotant la réutilisation des automatisations de tâches manuelles répétitives par les processus de développement logiciel, où un processus de développement logiciel décrit les étapes à réaliser pour mener à bien un projet de développement logiciel. Cette approche consiste à capitaliser sur un ensemble de processus et à réutiliser des processus de cet ensemble en fonction des exigences des projets, indépendamment du formalisme utilisé pour définir les processus. Des automatisations de tâches manuelles répétitives sont liées aux étapes des processus qu’elles automatisent. Ce lien permet de savoir quelles automatisations utiliser pour un projet donné et quand. Il permet également d’expliciter les différents cas d’utilisation de chaque automatisation. Cette information est utilisée afin de créer des automatisations réutilisables à travers leurs différents cas d’utilisation. L’approche ainsi que l’outillage associé ont été appliqués sur une famille de processus industriels de développement Java ainsi que sur une famille de processus consistant à définir et outiller un langage de modélisation. Abstract Many tools have been developped in order to manage the complexity of the software and of the software development projects. However, using these tools is the source of manual recurrent tasks that are error prone and time consuming. Automating these tasks enables to improve the productivity. But the difficulties are i) to determine when the automation of a manual recurrent task must be used, and ii) to create automations that are reusable across their different use cases. We propose a tool-supported approach that drives the reuse of the automations of the manual recurrent tasks by software processes. A software process defines the sequence of steps to perform in order to realize a software engineering project. This approche consists of capitalizing on a set of software processes and of reusing processes from this set according to projects’ requirements and independently of the formalism used to define the processes. The automations of the manual recurrent tasks are bound to the processes’ steps they automate. This binding enables to know which automations to reuse for a specific project and when to reuse these automations during the project. This binding also enables to explicit the different use cases of each automation. We use this information to create automations that are reusable across their different use cases. We applied this tool-supported approach on a family of Java development processes coming from the industry as well as on a family of processes consisting of designing and implementing a modeling language. Faciliter le d´eveloppement des applications de robotique Selma Kchir To cite this version: Selma Kchir. Faciliter le d´eveloppement des applications de robotique. Robotics. Universit´e Pierre et Marie Curie - Paris VI, 2014. French. . HAL Id: tel-01071062 https://tel.archives-ouvertes.fr/tel-01071062 Submitted on 3 Oct 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.Thèse de doctorat de l’Université Pierre & Marie Curie Spécialité Informatique Ecole Doctorale Informatique, Télécommunications et Électronique (Paris) Présentée par Selma Kchir Pour obtenir le grade de DOCTEUR de l’UNIVERSITÉ PIERRE ET MARIE CURIE Sujet de la thèse Faciliter le développement des applications de robotique Date de soutenance: le 26/06/2014 Devant le jury composé de: M.Xavier Blanc Professeur à l’Université Bordeaux 1 Examinateur M.Noury Bouraqadi Maître de conférences HDR à l’Ecole des mînes de Douai Rapporteur M.Jacques Malenfant Professeur à l’Université Pierre et Marie Curie Examinateur M.Bernard Pottier Professeur à l’Université de Bretagne Occidentale Examinateur M.Amar Ramdane-Chérif Professeur à l’Université de Versailles Saint Quentin en Yvelines Rapporteur M.Serge Stinckwich Maître de conférences à l’Université Caen Co-Encadrant M.Tewfik Ziadi Maître de conférences à l’Université Pierre et Marie Curie Co-Encadrant M.Mikal Ziane Maître de conférences HDR à l’Université Paris Descartes DirecteurTable des matières Table des figures vii Liste des tableaux xi Introduction générale 1 1 Contexte et problèmatique . . . . . . . . . . . . . . . . . . . . . . . . 1 2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 I Etat de l’art 5 La variabilité dans le domaine de la robotique 7 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3 La variabilité dans le domaine de la robotique . . . . . . . . . . . . . 9 3.1 La variabilité des capteurs . . . . . . . . . . . . . . . . . . . . 9 3.2 La variabilité des effecteurs . . . . . . . . . . . . . . . . . . . 11 3.3 La variabilité dans les architectures de robotique . . . . . . . . 12 3.3.1 Les architectures délibératives . . . . . . . . . . . . . 12 3.3.2 Les architectures réactives . . . . . . . . . . . . . . . 13 3.3.3 Les architectures hybrides . . . . . . . . . . . . . . . 15 3.4 La variabilité dans les algorithmes de robotique . . . . . . . . 15 4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 iTable des matières Les middleware de robotique 19 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1 Player . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.1 Description . . . . . . . . . . . . . . . . . . . . . . . 20 2.1.2 Les abstractions du matériel dans Player . . . . . . . 21 2.1.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 22 2.2 Robot Operating System (ROS) . . . . . . . . . . . . . . . . . 23 2.2.1 Description . . . . . . . . . . . . . . . . . . . . . . . 23 2.2.2 Les abstractions du matériel dans ROS . . . . . . . . 24 2.2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 24 2.3 Middleware for Robots (MIRO) . . . . . . . . . . . . . . . . . 25 2.3.1 Description . . . . . . . . . . . . . . . . . . . . . . . 25 2.3.2 Les abstractions du matériel dans MIRO . . . . . . . 27 2.3.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 28 2.4 Python Robotics (PyRo) . . . . . . . . . . . . . . . . . . . . . 29 2.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . 29 2.4.2 Les abstractions du matériel dans PyRo . . . . . . . 29 2.4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . 30 3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Langages de modélisations spécifiques à la robotique 33 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2 Langages de Modélisation Spécifiques aux domaines (DSML) . . . . . 34 2.1 Les techniques d’ingénierie dirigée par les modèles . . . . . . . 35 2.1.1 Les niveaux de modélisation . . . . . . . . . . . . . . 36 2.1.2 Les transformations . . . . . . . . . . . . . . . . . . 38 3 Cycle de vie d’un DSML . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.1 Analyse du domaine . . . . . . . . . . . . . . . . . . . . . . . 40 3.1.1 Les ontologies . . . . . . . . . . . . . . . . . . . . . . 41 3.2 Conception des DSML . . . . . . . . . . . . . . . . . . . . . . 42 3.2.1 Définition de la syntaxe abstraite . . . . . . . . . . . 42 3.2.2 Définition de la syntaxe concrète . . . . . . . . . . . 44 iiTable des matières 3.3 Intégration des plateformes : Transformations et Génération de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.4 Utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 4 Les DSML pour la robotique . . . . . . . . . . . . . . . . . . . . . . . 46 4.1 Exigences des langages de domaine pour la robotique . . . . . 46 4.2 Travaux existants . . . . . . . . . . . . . . . . . . . . . . . . . 47 4.2.1 BRICS Component Model (BCM) . . . . . . . . . . 48 4.2.2 Open Robot Controller Computer Aided Design (ORCCAD) . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.2.3 SmartSoft . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2.4 The 3 View Component Meta-Model (V3CMM) . . . 53 4.2.5 GenoM3 . . . . . . . . . . . . . . . . . . . . . . . . . 55 4.2.6 Robot Technology Component (RTC) . . . . . . . . 56 4.3 Synthèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 II Contributions 61 Robotic Modeling Language (RobotML) 63 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 2 Vue d’ensemble sur le cycle de vie de RobotML . . . . . . . . . . . . 65 3 Analyse du domaine . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4 Conception de RobotML . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.1 Syntaxe abstraite . . . . . . . . . . . . . . . . . . . . . . . . . 69 4.1.1 Le modèle de domaine RobotML : méta-modèle . . . 71 4.1.2 Le profil RobotML . . . . . . . . . . . . . . . . . . . 80 4.2 Syntaxe concrète : L’éditeur graphique de RobotML . . . . . . 82 5 Intégration du middleware OROCOS : génération de code . . . . . . 84 5.1 Génération du squelette d’un composant . . . . . . . . . . . . 85 5.2 Génération de la communication entre les composants . . . . . 86 5.3 Génération du comportement d’un composant . . . . . . . . . 87 6 Utilisation : chaîne d’outillage RobotML . . . . . . . . . . . . . . . . 90 7 Validation et Expérimentations . . . . . . . . . . . . . . . . . . . . . 91 7.1 Scénario de l’AIROARP . . . . . . . . . . . . . . . . . . . . . 92 iiiTable des matières 7.2 Conception du scénario avec RobotML . . . . . . . . . . . . . 92 7.3 Génération de code vers OROCOS . . . . . . . . . . . . . . . 94 8 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique 99 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99 2 Approche pour la gestion de la variabilité dans les algorithmes de robotique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 2.1 Identification des abstractions . . . . . . . . . . . . . . . . . . 101 2.2 Identification de l’algorithme générique . . . . . . . . . . . . . 103 2.3 Organisation de l’implantation . . . . . . . . . . . . . . . . . . 104 2.3.1 Implantation des abstractions non algorithmiques . . 105 2.3.2 Implantation des abstractions algorithmiques et de l’algorithme générique . . . . . . . . . . . . . . . . . 106 3 Application sur la famille d’algorithmes Bug . . . . . . . . . . . . . . 108 3.1 La famille d’algorithmes Bug . . . . . . . . . . . . . . . . . . . 108 3.1.1 Bug1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 3.1.2 Bug2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 3.1.3 Alg1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 3.1.4 Alg2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 3.1.5 DistBug . . . . . . . . . . . . . . . . . . . . . . . . . 112 3.1.6 TangentBug . . . . . . . . . . . . . . . . . . . . . . . 114 3.2 Identification des abstractions de la famille Bug . . . . . . . . 114 3.3 Identification de l’algorithme générique de la famille Bug . . . 121 3.4 Organisation de l’implantation de la famille Bug . . . . . . . . 122 3.5 Expérimentations et Validation . . . . . . . . . . . . . . . . . 124 3.5.1 Environnement de simulation : Stage-ROS . . . . . . 125 3.5.2 Configurations des environnements et des capteurs . 126 3.5.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . 127 4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129 Conclusion générale et perspectives 131 ivTable des matières Références bibliographiques 135 vTable des figures viTable des figures I.1 Architecture verticale - paradigme hiérarchique (adaptée de [1]) . . 13 I.2 Architecture de subsomption . . . . . . . . . . . . . . . . . . . . . 15 II.3 Communication entre les noeuds ROS . . . . . . . . . . . . . . . . 24 II.4 Le regroupement des capteurs dans PyRO . . . . . . . . . . . . . . 30 III.5 Les différents niveaux de modélisation . . . . . . . . . . . . . . . . 36 III.6 Les artefacts du DSL - extrait de [2] . . . . . . . . . . . . . . . . . 44 III.7 Intégration des plateformes - basé sur [2] . . . . . . . . . . . . . . . 45 III.8 Les concepts de l’OMG appliqués à l’approche BCM - (tiré de [3]) . 48 III.9 Le méta-modèle CPC - (tiré de [3]) . . . . . . . . . . . . . . . . . . 50 III.10 Le méta-modèle RT extrait du méta-modèle d’ORCCAD - (tiré de [4]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 III.11 Le méta-modèle de SmartSoft - (tiré de [5]) . . . . . . . . . . . . . 52 III.12 Méta-modèle V3CMM - tiré de [6] . . . . . . . . . . . . . . . . . . 54 III.13 Architecture de Genom3 . . . . . . . . . . . . . . . . . . . . . . . . 55 III.14 Composant RTC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 IV.15 Classification des systèmes dans l’ontologie (extrait de [7]) . . . . . 67 IV.16 Intéraction entre les systèmes dans l’ontologie (extrait de [7]) . . . 68 IV.17 La classe Information dans l’ontologie (extrait de [7]) . . . . . . . . 68 IV.18 RobotML Domain Model . . . . . . . . . . . . . . . . . . . . . . 71 IV.19 RoboticArchitecture Package . . . . . . . . . . . . . . . . . . . . . 72 IV.20 La méta-classe Property . . . . . . . . . . . . . . . . . . . . . . . . 73 viiTable des figures IV.21 Le package RoboticSystem . . . . . . . . . . . . . . . . . . . . . . . 73 IV.22 RobotML Data Types . . . . . . . . . . . . . . . . . . . . . . . . 74 IV.23 physicalData . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 IV.24 Types composés de RobotML . . . . . . . . . . . . . . . . . . . . . 75 IV.25 Types primitifs de RobotML . . . . . . . . . . . . . . . . . . . . . 75 IV.26 Intégration des geometry_msgs de ROS à RobotML . . . . . . . . 76 IV.27 Le package Platform . . . . . . . . . . . . . . . . . . . . . . . . . . 77 IV.28 Le package Deployment . . . . . . . . . . . . . . . . . . . . . . . . 77 IV.29 Le package RoboticBehavior . . . . . . . . . . . . . . . . . . . . . . 78 IV.30 Le package FSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 IV.31 Les mécanismes de communication . . . . . . . . . . . . . . . . . . 80 IV.32 Extrait de la partie Architecture : Stéréotypes extensions de la méta-classe Class d’UML . . . . . . . . . . . . . . . . . . . . . . . 81 IV.33 Extrait de la partie communication : Stéréotypes extensions de la méta-classe Port d’UML . . . . . . . . . . . . . . . . . . . . . . . . 82 IV.34 Extrait de la partie Control : Stéréotypes extensions des métaclasses du méta-modèle d’UML . . . . . . . . . . . . . . . . . . . . 82 IV.35 À gauche, les icônes attachées aux stéréotypes, à droite la palette montrant les différentes icônes . . . . . . . . . . . . . . . . . . . . . 83 IV.36 Environnement de modélisation de RobotML . . . . . . . . . . . . 84 IV.37 Génération de code avec OROCOS . . . . . . . . . . . . . . . . . . 90 IV.38 Etapes de modélisation en utilisant RobotML . . . . . . . . . . . . 91 IV.39 Modèle des types de données AIR OARP . . . . . . . . . . . . . . 93 IV.40 Les interfaces du scénario AIR OARP . . . . . . . . . . . . . . . . 94 IV.41 Le composant AvionicSystem . . . . . . . . . . . . . . . . . . . . . 94 IV.42 Le composant CameraSystem . . . . . . . . . . . . . . . . . . . . . 95 IV.43 Modèle du scénario AIR OARP . . . . . . . . . . . . . . . . . . . . 95 V.44 Implantation des abstractions non algorithmiques : adaptateurs . . 106 V.45 Application du pattern Bridge . . . . . . . . . . . . . . . . . . . . . 107 V.46 Application du pattern Template Method . . . . . . . . . . . . . . 108 viiiTable des figures V.47 Le contournement d’obstacle : (1) le robot à droite doit tourner à droite pour se rapprocher de l’obstacle et réduire l’écart entre la distance de sécurité et sa distance actuelle par rapport à l’obstacle. (2) le robot à gauche doit tourner à gauche pour s’éloigner de l’obstacle et réduire l’écart entre la distance de sécurité et sa distance actuelle par rapport à l’obstacle . . . . . . . . . . . . . . . . . . . . 117 V.48 La détection d’obstacle devant, à gauche et à droite du robot avec des capteurs de distance . . . . . . . . . . . . . . . . . . . . . . . . 117 V.49 Exemple de getDistanceRight : la distance retournée est la moyenne des distances détectées parmi tous les rayons émanant du capteur droit du robot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 V.50 Extrait du digramme de classe de la famille Bug . . . . . . . . . . . 124 V.51 Architecture de l’application correspondant à Bug1 . . . . . . . . . 125 V.52 Environnement1 : but inatteignable . . . . . . . . . . . . . . . . . . 126 V.53 Environnement2 : Environnement avec un seul obstacle . . . . . . . 126 V.54 Environnement3 : Environnement avec plusieurs obstacles . . . . . 127 ixListe des tableaux xListe des tableaux I.1 Classification des capteurs inspirée de [8] et de [9] . . . . . . . . . . 10 II.2 Exemple de sensor messages de ROS . . . . . . . . . . . . . . . . . 25 II.3 à gauche le code écrit en fonction du capteur Laser, à droite le code après sa modification avec les Infrarouges . . . . . . . . . . . . . . 26 III.4 Comparaison entre les DSML pour la robotique existants . . . . . . 60 IV.5 Correspondance entre OWL et UML . . . . . . . . . . . . . . . . . 70 IV.6 Correspondance entre le DSL Architecture et les concepts d’OROCOS 86 IV.7 Correspondance entre le DSL Communication et les concepts d’OROCOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 IV.8 Correspondance entre le DSL Communication et les concepts d’OROCOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 IV.9 Correspondance entre le DSL Contrôle et les concepts d’OROCOS . 88 xiIntroduction générale 1 Contexte et problèmatique Les roboticiens sont confrontés à plusieurs difficultés pour le développement de leurs applications en raison de l’hétérogénéïté des concepts de la robotique. En effet, dans le cas de la robotique mobile les roboticiens doivent maîtriser les détails liés aux moyens de locomotion du robot, à sa morphologie ainsi qu’à ses capteurs. De plus, la variabilité du matériel rend les applications de robotique fragiles : un changement du matériel dans une application déjà développée impliquerait la réécriture du code de celle-ci. Il faudrait alors découpler le code de l’application à travers des abstractions de haut niveau afin de la rendre plus stable vis-à-vis des changements du matériel. Pour répondre à ce constat de variabilité du matériel, certains middleware de robotique tels que ROS [10], MIRO [11], PyRO [12] et Player [13] ont proposé des abstractions du matériel pour permettre une montée en niveau d’abstractions par rapport aux détails du matériel. Ces dernières permettent d’encapsuler des données spécifiques au matériel afin de fournir des données de plus haut niveau. Cependant, ces abstractions restent de bas niveau et ne permettent pas une isolation de certains changements dans le matériel. Il serait alors plus simple pour les roboticiens de manipuler, à travers des outils, des concepts qu’ils ont l’habitude d’utiliser et qui soient de plus haut niveau que ceux proposés par les middleware. Dans cette optique qui vise à définir des abstractions de haut niveau pour les applications de robotique et à faciliter leur développement, les langages de modélisation spécifiques au domaine (en anglais DSML : Domain Specific Modeling Language) offrent à travers des notations appropriées et des abstractions, une puissance expressive axée sur, et généralement limitée à, un domaine particulier [14]. 1Introduction générale Ces abstractions sont définies par les experts du domaine d’application réduisant ainsi le fossé sémantique entre les développeurs et les experts du domaine afin de faciliter le développement des applications du domaine. L’utilisation de l’ingénierie dirigée par les modèles (IDM) (en anglais Model Driven Engineering (MDE)) [15] dans ce contexte permettrait de gérer les problèmes de dé- pendance de bas niveau (c.-à-d. variabilité du matériel et des plateformes) à travers des modèles stables basés sur des abstractions du domaine. De plus, la génération automatique de code à partir de ces modèles vers plusieurs plateformes cibles offrirait un gain de temps et une facilité pour le développement des applications de robotique. Plusieurs DSML pour la robotique ont été définis tels que BCM [3], SmartSoft [16] et ORCCAD [4] mais ils s’intéressent essentiellement aux aspects qui relèvent de l’architecture d’une application (architecture à base de composants) et à la communication entre ses composants. Les abstractions utilisées dans ces DSML sont insuffisantes car elles ne permettent pas de représenter tous les concepts d’une application tels qu’ils sont manipulés par les roboticiens. Par ailleurs, ils ne définissent pas d’abstractions pour le matériel. Il faudrait alors convenir d’un ensemble d’abstractions stables qui permettraient de représenter les concepts d’une application de robotique afin de faciliter son développement et garantir son indépendance par rapport aux plateformes cibles. Ces concepts peuvent être des concepts de haut niveau comme ceux proposés par les DSML. Cependant ces derniers manquent souvent de sémantique opérationnelle car ils représentent souvent des concepts généraux du domaine. Il faudrait alors défi- nir des abstractions de haut niveau qui permettent , indépendamment du matériel utilisé, d’obtenir des informations sur l’environnement du robot et de définir des actions de haut niveau d’une part et d’encapsuler les détails algorithmiques d’une application d’une autre part. 2 Contributions Cette thèse tente d’apporter des solutions aux problèmes présentés précédemment. Dans cette optique, nous avons contribué au développement d’un DSML pour la robotique (RobotML) dans le cadre d’un projet ANR, appelé PROTEUS. Les abstractions fournies par RobotML se basent sur une ontologie du domaine de la 2Introduction générale robotique basée sur les connaissances des experts du domaine. Des outils ont été dé- veloppés autour de RobotML permettant la modélisation de scénarios de robotique et une génération automatique de code vers une ou plusieurs plateformes cibles. – Il devient alors facile pour un expert en robotique et même pour des simples utilisateurs débutants en robotique de représenter les scénarios de leurs applications. – Les modèles représentés avec RobotML sont stables et indépendants des plateformes cibles. – La génération de code à partir de RobotML se fait vers une ou plusieurs plateformes hétérogènes (c.-à-d. simulateurs ou robots réels d’une part et middleware d’une autre part) et permet d’obtenir une application compilable ainsi que les artefacts nécessaires pour son exécution. Cependant, les expériementations basées sur RobotML ont montré que les abstractions du domaine définies dans l’ontologie sont insuffisantes. En effet, les abstractions de l’ontologie sont basées sur les connaissances du domaine et non pas sur plusieurs itérations appliquées sur des exemples concrets. Par conséquent, elles manquent de sémantique opérationnelle et sont trop générales pour pouvoir être utilisées pour la définition d’abstractions du matériel par exemple. Il faudrait alors partir d’exemples concrets et appliquer une approche complémentaire pour enrichir les abstractions du domaine avec des abstractions a posteriori. Nous avons donc proposé une approche qui, à partir de la description d’une tâche de robotique et des hypothèses sur l’environnement et sur les capacités du robot, produit : – un ensemble d’abstractions non algorithmiques représentant des requêtes sur l’environnement y compris le robot ou des actions de haut niveau ; – un ensemble d’abstractions algorithmiques représentant un ensemble d’instructions permettant de réaliser une sous-tâche de la tâche à développer ; – un algorithme générique configurable défini en fonction de ces abstractions. Ainsi, l’impact du changement du matériel et des stratégies définies dans les soustâches n’est pas très important. Il suffit d’adapter l’implantation de ces abstractions sans avoir à modifier l’algorithme générique. 3Introduction générale 3 Plan de la thèse Cette thèse s’organise comme suit : Le chapitre 1 présente tout d’abord le contexte de ce travail : la variabilité dans le domaine de la robotique. Nous pré- senterons les différentes catégories des capteurs, des effecteurs, des architectures de robotique et des algorithmes de robotique. Nous dresserons ensuite dans le chapitre 2 un état de l’art sur les abstractions proposées par certains des middlewares de robotique existants pour répondre au problème de la variabilité du matériel. Nous présenterons ensuite dans le chapitre 3 les DSML de robotique proposés pour faciliter le développement des applications de robotique et garantir leur indépendance par rapport aux plateformes cibles. Nous présenterons notre DSML pour la robotique (RobotML) ainsi que la génération de code vers un middleware de robotique (OROCOS) et un scénario que nous avons utilisé pour la validation de nos travaux dans le chapitre 4. Notre approche pour la définition des abstractions pertinentes et d’un algorithme générique à partir de la description d’une tâche de robotique ainsi que son application sur une famille d’algorithmes de navigation sera présentée dans le chapitre 5. Nous concluerons cette thèse par un rappel de nos contributions et des discussions sur les perspectives. 4Première partie Etat de l’art 5La variabilité dans le domaine de la robotique 1 Introduction La robotique mobile désigne l’étude des robots à base mobile qui, par opposition aux robots marcheurs, aux robots manipulateurs ou encore aux robots aériens, sont des robots ayant pour moyen de locomotion des roues. Les définitions du terme robot dans la littérature sont diverses, quelquefois très générales comme la définition de Brady [17] ”[...] une connexion intelligente entre la perception et l’action”. Arkin [1], quant à lui, a donné une définition plus spécifique ”Un robot intelligent mobile est une machine capable d’extraire des informations sur son environnement et d’utiliser les connaissances sur son monde afin de se déplacer de manière significative et en toute sécurité”. Par sa définition, Arkin explique qu’il existe une connexion entre la perception et l’action ; deux concepts fondamentaux en robotique qui varient d’un robot à l’autre. Cette connexion n’est autre que le système de contrôle du robot qui définit un ensemble de fonctions permettant au robot d’atteindre le but de sa mission. La perception, l’action et le système de contrôle forment une application de robotique. On peut parler alors de plusieurs types de variabilités : la variabilité liée à la perception, à l’action et au contrôle du robot qui concerne les aspects architecturaux d’une application. Dans ce chapitre, nous nous proposons de présenter les concepts de la robotique que nous allons utiliser tout au long de cette thèse ainsi que les principaux types de variabilité en robotique. 7Chapitre I. La variabilité dans le domaine de la robotique 2 Définitions En raison de la diversité des définitions présentes dans la littérature, nous nous proposons dans cette section de présenter les définitions des concepts que nous utiliserons tout au long de cette thèse. Nous nous plaçons dans le contexte de la robotique mobile non humanoïde où les robots sont équipés de capteurs et d’effecteurs afin d’intéragir avec leur environnement. Definition 1 (Robot mobile autonome). Un robot mobile autonome est un robot intelligent capable d’exécuter une tâche sans l’intervention des humains, il est capable de percevoir l’état de son environnement et de se déplacer dans celui-ci afin d’accomplir une tâche particulière (définition adaptée de la définition d’Arkin [1]). Definition 2 (Perception). La perception est l’extraction d’informations sensorielles, à partir des capteurs, indiquant l’état du robot dans son environnement. Definition 3 (Action). L’action est l’interprétation des données sensorielles ou de directives envoyées par le système de contrôle du robot en commandes envoyées aux effecteurs du robot. Definition 4 (Tâche). Une tâche est constituée d’un ensemble d’actions permettant au robot d’accomplir un but ou un sous-but. Definition 5 (Planification). La planification est l’analyse d’une séquence d’actions primitives afin de réduire l’écart entre l’état actuel du robot et le but qu’il doit atteindre. (définition adaptée de Nilsson [18] et du paradigme General Problem Solver [19]). Definition 6 (Système de contrôle). Le système de contrôle du robot est le système responsable de coordonner les parties perception et action du robot afin de réaliser une tâche particulière. Definition 7 (Paradigme). Un paradigme est une philosophie ou un ensemble d’hypothèses et/ou de techniques qui caractérisent une approche pour une classe de problèmes [20]. Definition 8 (Architecture). Une architecture de robotique est une discipline consracrée à la conception de robots hautement spécifiques et individuels à partir d’une collection de modules logiciels communs [1]. Une architecture est un pattern pour l’implémentation d’un paradigme [20]. 8I.3 La variabilité dans le domaine de la robotique Definition 9 (Middleware). Un middleware est une couche d’abstraction entre le système d’exploitation et l’application [21]. Definition 10 (Variabilité). La variabilité désigne l’étendue des différentes catégories que peut prendre un concept. En robotique, on trouve de la variabilité dans les capteurs, dans les effecteurs, dans les algorithmes, dans les architectures, etc. 3 La variabilité dans le domaine de la robotique Dans cette section, nous présentons la variabilité dans les concepts présentés dans la section précédente. La variabilité désigne la diversité des catégories ou des classifications pour un concept donné (une tâche, un capteur, un effecteur, un environnement, etc). 3.1 La variabilité des capteurs La perception, comme nous l’avons définie précédemment, est l’extraction d’informations de l’environnement du robot à travers ses capteurs. Le choix des capteurs dépend de la nature des informations dont le robot a besoin pour accomplir sa tâche. Les capteurs sont des dispositifs qui répondent à un signal ou à un stimulus. Un stimulus est une quantité, une propriété ou une condition détectée et convertie en un signal électrique [22]. À la différence des transducteurs qui convertissent un type d’énergie en un autre type d’énergie, les capteurs convertissent une énergie en un signal électrique. Dans la littérature, les capteurs sont généralement regroupés selon deux principales catégories : proprioceptifs ou exteroceptifs. – Les capteurs proprioceptifs mesurent l’état interne du robot. Comme par exemple, la vitesse du moteur, le niveau de batterie, etc. – Les capteurs exteroceptifs récupèrent les informations à partir de l’environnement du robot. Par exemple, l’intensité de la lumière, une mesure de distance, etc. Les capteurs sont également classés relativement à la nature de leur fonctionnement : – Les capteurs passifs mesurent l’énergie présente dans l’environnement, par exemple les microphones, les sondes de température, etc. – Les capteurs actifs émettent une énergie dans l’environnement et mesurent la réaction de l’environnement à celle-ci. 9Chapitre I. La variabilité dans le domaine de la robotique Une autre classification des capteurs dans la littérature dépend des données que les capteurs peuvent mesurer (stimulus), leurs spécifications, le mécanisme de conversion qu’ils utilisent et le matériel à partir duquel ils sont conçus [22]. Par exemple dans le cas des capteurs à portée (appelés aussi capteurs à rayons), nous notons une variabilité par rapport à la portée des capteurs, aux nombres de rayons, à la largeur du (ou des) rayons dont ils disposent, au champs de vision (Field of view) des capteurs, etc. Classification Capteurs Type Capteurs de localisation GPS exteroceptif actif Odométrie proprioceptif actif Capteurs à rayons Laser exteroceptif actif Infrarouge exteroceptif actif Ultrasonic exteroceptif actif Capteurs basés sur la vision Caméra exteroceptif passif Capteurs Moteur/Roues encodeurs inductifs proprioceptif passif Capteurs tactiles Bumpers, Contact switches exteroceptif passif Table I.1 – Classification des capteurs inspirée de [8] et de [9] Le tableau I.1 montre quelques exemples de capteurs proprioceptifs et exteroceptifs. Typiquement, le cas du GPS et de l’odométrie qui tous deux, servent à la localisation du robot mais ne sont pas de la même nature. La localisation consiste à indiquer la position du robot et son orientation. – l’Odométrie : Les roues motrices d’un robot sont habituellement associées à un servomoteur. Celui-ci est équipé d’un dispositif de mesure de rotation, il s’agit d’un capteur proprioceptif appelé odomètre. L’odométrie est le moyen de localisation le plus simple qui permet d’estimer la position d’un robot mobile en mouvement. À une position donnée correspondent une multitude d’orientations possibles du robot. L’orientation du robot ne peut s’obtenir qu’en connaissant son orientation de départ ainsi que son évolution sur sa trajectoire. L’utilisation de l’odométrie est basée sur l’hypothèse de roue sans glissement (contrainte non holonomique que nous présenterons dans la section suivante) et sur la supposition que les paramètres géométriques du robot sont parfaitement connus. 10I.3 La variabilité dans le domaine de la robotique – Global Positionning System (GPS) : est un système de géolocalisation qui effectue des émissions synchronisées dans le temps à des satellites. A l’aide des messages émis aux satellites, le récepteur peut calculer sa position. Le principe de calcul de la position s’appuye sur le principe de la triangulation (calcul de la distance par rapport à 3 satellites). Néanmoins, des imprécisions de la mesure du temps peuvent se produire résultant du décalage entre les horloges des satellites (très précises) et les horloges des récepteurs (moins précises). Un quatrième satellite est donc nécessaire afin d’assurer la robustesse de la mesure. Le GPS permet une localisation approximative (à quelques mètres près). En robotique, une méthode différentielle est utilisée pour obtenir des résultats plus précis. La localisation se fait alors à l’aide de deux récepteurs dont l’un est statique et positionné avec précision dans l’environnement. La précision devient alors meilleure. L’utilisation du GPS impose la navigation à l’extérieur en raison de la présence de satellites. Les applications de robotique sont implémentées en fonction des capteurs qu’elles utilisent. La variabilité des capteurs rend ces applications fragiles aux changements du matériel. D’un point de vue conceptuel, séparer l’acquisition des données du traitement de celles-ci est une étape importante pour assurer la pérennité et la consistence des applications de robotique. 3.2 La variabilité des effecteurs Un robot agit sur son environnement à travers ses effecteurs. Dans la littérature, un effecteur (appelé aussi actionneur), à l’opposé d’un capteur, convertit un signal électrique en une énergie non électrique ou un phénomène physique [22]. Par exemple, un moteur convertit un signal en une action mécanique. L’étude détaillée des effecteurs, qui relève à la fois de la cinématique, de la mécanique et l’électronique ne sera pas présentée ici. Nous nous intéresserons dans cette section aux mouvements des robots mobiles. Les robots mobiles sont généralement équipés par des roues. Chaque roue contribue au mouvement du robot et impose des contraintes sur le mouvement de celui-ci. Par conséquent, les contraintes définies sur les roues combinent les contraintes définies sur chaque roue individuelle [8]. Les mouvements des robots sont traditionnellement classés en deux catégories : les robots holonomes et les robots non-holonomes [23]. 11Chapitre I. La variabilité dans le domaine de la robotique Les robots de type holonomes n’ont pas de restriction sur le déplacement contrairement aux robots de type non-holonomes qui possèdent des contraintes cinématiques sur leurs mouvements. Lorsque le contact entre le robot et le sol est ponctuel et que les roues sont indéfomables, celà se traduit mathématiquement par une vitesse nulle entre le sol et la roue. Il s’agit de contraintes de roue sans glissement. Ces contraintes sont des contraintes non holonomes. L’existence de contraintes non-holonomes implique que le robot ne peut pas effectuer certains mouvements instantanément, il doit manoeuvrer. Les robots mobiles à roues sont typiquement des systèmes nonholonomes. Cette contrainte représente aussi une variabilité car la vitesse de rotation ou d’avancement des effecteurs diffère non seulement selon l’environnement dans lequel se trouve le robot mais aussi selon le chemin que ce dernier doit suivre. De même que pour les capteurs, les applications de robotique sont généralement écrites en fonction des effecteurs du robot. Par conséquent, un découplage du code de l’application des détails des effecteurs du robot rendrait les applications résistantes aux changements des robots plus généralement et des effecteurs plus particulièrement. 3.3 La variabilité dans les architectures de robotique Le but de choisir une architecture de robotique est de rendre la programmation d’un robot plus facile, plus flexible et plus sûre [24]. Les architectures de robotique permettent de définir la façon dont le robot doit agir de façon à satisfaire le but de sa mission. Dans cette section, nous présentons les différentes architectures définies dans la littérature. 3.3.1 Les architectures délibératives Les architectures de robotique ont apparu à la fin des années 60 avec le paradigme hiérarchique (sense-plan-act) [18] (perception - planification - action) : le robot pense d’abord puis agit. La perception dans ce cas consiste à la traduction des informations sensorielles et cognitives en un modèle du monde [18, 25, 26]. À partir de ce modèle, le planificateur détermine quelles sont les actions à effectuer et renvoie les commandes à exécuter aux effecteurs. Le schéma de cette architecture est donné par la figure I.1. Parmi les architectures hiérarchiques/délibératives, 12I.3 La variabilité dans le domaine de la robotique nous citons NASREM (The NASA Standard Reference Model for Telerobot Control System) [27] développée par la NASA au milieu des années 80. Figure I.1 – Architecture verticale - paradigme hiérarchique (adaptée de [1]) L’architecture délibérative a été adoptée dans les applications de robotique jusqu’au milieu des années 80 lorsqu’il a été constaté que le processus de planification est un processus complexe et non adapté à un environnement dynamique. En effet, le robot reste bloqué jusqu’à la réception des directives du module de planification. De plus, l’exécution d’un plan sans la prise en compte des changements qui peuvent surgir dans l’environnement rend cette architecture non adaptée à un environnement dynamique. C’est pour cette raison que les architectures réactives ont ensuite été définies afin de répondre aux situations où le robot doit agir rapidement. 3.3.2 Les architectures réactives À l’opposé du paradigme Sense-Plan-Act, les architectures réactives s’appuient sur le paradigme réactif Sense-Act (Perception - Action) : le robot ne pense pas mais agit. Un système réactif associe étroitement la perception à l’action sans l’utilisation de représentations abstraites ou d’historique du temps [1]. Le robot ne se base plus sur le modèle de son monde mais uniquement sur des collections de conditions/actions définies à partir des données des capteurs. Cette architecture est adaptée aux environnements où le robot doit agir rapidement, typiquement dans le cas des environnements dynamiques. Les architectures basées sur le comportement ont également été définies pour pallier aux problèmes des paradigmes hiérarchiques. Ces architectures sont souvent confondues avec les architectures réactives dans la littérature, notamment dans [28]. Cette confusion découle de l’utilisation des architectures basées sur le comportement de comportements réactifs dans la plupart des cas (même si la définition d’un comportement est plus sophistiquée que la définition d’une action dans les architectures réactives [29]). Un comportement est défini comme une activité primitive [30] 13Chapitre I. La variabilité dans le domaine de la robotique qui prend en entrée les données des capteurs et retourne une action à effectuer (principe de stimulus/réponse). Il peut être exprimé avec un triplet (S, R, β) où S est le stimulus, R est la réponse et β est le lien S− > R [1]. La définition et l’extraction de ces comportements ont fait l’objet de plusieurs travaux et plusieurs approches ont été définies notamment l’approche éthologique (basée sur l’observation des comportements des animaux) [30, 31], l’approche guidée par les expérimentations (consistant à définir un comportement basique et à ajouter d’autres comportements ou à raffiner les comportements définis) [32] et l’approche dirigée par les buts, etc. Afin d’assember les comportements, plusieurs approches ont été définies dont l’approche compétitive. Dans l’approche compétitive, on distingue 3 approches différentes : – La coordination basée sur la priorité [33] : Le système d’arbitrage sélectionne la réponse envoyée par le comportement ayant la priorité la plus élevée. – La coordination basée sur le vote [34] : Chaque comportement retourne un vote à une réponse et la réponse ayant le plus de votes est exécutée. – La coordination basée sur la sélection des actions [35] : Tous les comportements retournent leurs réponses à l’arbitre qui se charge de sélectionner la réponse majoritaire. Parmi les architectures basées sur le comportement, l’architecture de subsomption(subsumption architecture), proposée par Brooks [30, 32, 33] vers la fin des années 80 est une architecture purement réactive. C’est une architecture incrémentale bottom-up (du bas vers le haut) allant du comportement le plus basique (placé en bas) vers le comportement ayant le degré de compétence le plus élevé (placé en haut). Chaque comportement est modulaire et est représenté par une machine à états finis. L’architecture de subsomption s’appuye sur la notion de parallélisme, elle permet l’exécution simultanée de plusieurs comportements qui interrogent les mêmes capteurs et agissent sur les mêmes effecteurs. Le mécanisme de coordination utilisé est un mécanisme compétitif ayant un système d’arbitrage basé sur la priorité à travers l’inhibition et la suppression comme le montre la figure I.2. Un comportement peut supprimer les sorties d’un autre comportement (cercle avec un S), dans ce cas le comportement dominant remplace les sorties de l’autre comportement par ses propores commandes. Un comportement peut également inhiber (cercle avec un I) les sorties d’un autre comportement en les bloquant. L’architecture de subsomption ne permet pas l’utilisation de comportements indépendants. En effet, il y a une dépendance entre les comportements qui permet de 14I.3 La variabilité dans le domaine de la robotique Figure I.2 – Architecture de subsomption savoir comment les placer dans l’architecture (toujours en suivant un ordre de priorité). Malgré leurs avantages, les architectures basées sur le comportement ne sont pas adaptées à tous les types d’environnements. Il est difficile d’avoir la localisation du robot dans le modèle de son monde et ses connaissances par rapport à son monde sont limitées voire inexistantes [1]. 3.3.3 Les architectures hybrides L’architecture hybride a ensuite été définie afin de combiner les meilleurs aspects de l’architecture délibérative et de celle basée sur le comportement en utilisant le paradigme Plan, Sense-Act (Plannification, Perception-Action). La plannification est effectuée en une étape, la perception et l’action sont effectuées ensemble. L’architecture hybride comporte un système réactif pour le contrôle de bas niveau et un système délibératif de haut niveau pour la prise de décisions. L’architecture hybride a émergé au début des années 90 avec l’architecture AuRA [36] [37] (Autonomous Robot Architecture). Chaque application de robotique utilise une architecture particulière. Dans certains systèmes existants, il est difficile de comprendre l’architecture utilisée. En effet, l’architecture et l’implémentation spécifique au domaine (à la plateforme, au langage, etc.) sont souvent liées brouillant ainsi le style architectural utilisé [24]. Il est donc important de séparer l’architecture des détails de l’implémentation afin de garantir la modularité des composants architecturaux. 3.4 La variabilité dans les algorithmes de robotique Un autre type de variabilité concerne les algorithmes. Elle est souvent relative aux différentes variantes d’une famille d’algorithmes. Prenons le cas d’une tâche de navigation. La navigation est l’une des capacités les plus importantes des robots 15Chapitre I. La variabilité dans le domaine de la robotique mobiles. Le problème de la navigation consiste principalement à trouver un chemin sans collision pour se déplacer d’un point donné vers un autre point ou tout simplement à explorer un environnement tout en évitant les obstacles présents dans celui-ci. Il existe une grande variété de travaux permettant d’aborder le problème de la navigation. D’une façon générale, on peut distinguer deux types de navigation : – La navigation dans un environnement connu (avec un modèle du monde). Le robot dispose du modèle de son monde et planifie par conséquent les actions à exécuter pour se déplacer dans celui-ci. On retrouve alors le paradigme hié- rarchique ou le paradigme hybride. – La navigation dans un environnement inconnu. Elle consiste à appliquer un ensemble de comportements réactifs dont on estime que l’enchaînement peut permettre au robot d’atteindre son but. Par exemple, le contournement d’obstacle, la poursuite de chemin, etc. La navigation requiert des fonctionnalités que le robot doit être capable d’effectuer notamment, la localisation (qui permet au robot de se positionner dans son environnement s’il dispose du modèle de celui-ci ou par rapport à son but ou à sa position de départ) et l’évitement d’obstacles. Il existe diverses stratégies pour l’évitement d’obstacles. Ces obstacles peuvent être de formes inconnues et placés de façon arbitraire dans l’environnement du robot. Ainsi, même avec un ensemble d’hypothèses très simplifiées comme le cas de la famille Bug [38] (voir section 3.1 - chapitre 5), qui comporte environ vingt variantes, il n’est pas évident de comprendre ces algorithmes ou même de les comparer entre eux afin de décider quel algorithme est le plus efficace dans un environnement donné. Si nous pouvions utiliser une seule implémentation d’un algorithme, la comparaison entre les variantes de cet algorithme devient simple et significative. 4 Conclusion Nous avons présenté dans ce chapitre les principaux concepts de la robotique. Nous avons vu également les différents types de variabilité en robotique. Cette variabilité a un impact sur les applications de robotique les rendant ainsi – difficiles à développer car le roboticien doit maîtriser les détails des capteurs, des effecteurs et de la tâche qu’il doit développer. 16I.4 Conclusion – fragiles car elles sont dépendantes des détails de bas niveau du matériel donc le changement de matériel a un impact important sur le code de l’application. – difficiles à comprendre car elles sont confondues avec les détails d’implé- mentation des plateformes sous lesquelles elles sont développées. Nous verrons dans le chapitre suivant comment certains middleware ont tenté de pallier la dépendance des applications de robotique au matériel en proposant des abstractions du matériel. 17Chapitre I. La variabilité dans le domaine de la robotique 18Les middleware de robotique 1 Introduction Nous avons présenté dans le chapitre précédent la variabilité dans les concepts qui composent une application de robotique. Cette variabilité, notamment la variabilité du matériel, a orienté la conception de certains middleware de robotique pour (1) simplifier le processus de développement de ces applications (2) rendre ces applications indépendantes des détails du matériel (3) assurer la connexion entre les différents modules d’une application distribuée. Bakken [39] définit un middleware comme étant : “[...] une classe de technologies logicielles conçues pour aider à la gestion de la complexité et l’hétérogénéïté dans les systèmes distribués [...] Il fournit des abstractions de plus haut niveau que les APIs (Application Programming Interfaces) comme les sockets (fournies par le système d’exploitation)”. Des études détaillées qui présentent les middleware de robotique, leurs architectures ainsi que leurs propriétés peuvent être trouvées dans [21, 40, 41]. Dans ce chapitre, nous ne présenterons pas l’aspect communication des middleware mais nous nous intéresserons particulièrement à l’abstraction du matériel dans les middlewares de robotique pour la gestion de la variabilité de bas niveau. Nous présentons la description de certains des middlewares les plus utilisés en robotique : Player [13, 42], ROS [10, 43], MIRO [11] et PyRo [12, 44] ainsi que les abstractions du matériel qu’ils proposent et une discussion sur l’impact du changement du matériel illustrée sur un exemple d’évitement d’obstacles. 19Chapitre II. Les middleware de robotique 2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel Selon [21, 41], idéalement les middleware de robotique devraient permettre la communication et l’interopérabilité des modules robotiques. Ces derniers étant implantés par des développeurs différents, il est difficile de les faire interagir entre eux. Un middleware doit donc supporter l’intégration des composants et des dispositifs de bas niveau du robot, assurer une utilisation efficace des ressources disponibles et supporter l’intégration avec les autres systèmes. Comme nous l’avons mentionné précédemment, les aspects qui relèvent de la communication et des systèmes distribués ne font pas l’objet de ce travail. Nous nous intéressons essentiellement à la gestion de la variabilité du matériel. Certains middleware de robotique ont défini des données abstraites afin d’encapsuler les détails spécifiques au matériel utilisé. Dans cette section, nous présentons pour chaque middleware sa description, les abstractions du matériel proposées dans celui-ci ainsi qu’une discussion qui montre l’impact du changement du matériel sur un exemple d’évitement d’obstacles. 2.1 Player 2.1.1 Description Le but de Player [13, 42] consiste à permettre l’exécution des mêmes applications aussi bien en simulation que sur des robots réels. Il fournit un framework de développement supportant différents périphériques matériels 1 , des services communs requis pas les applications robotiques et transfère un contrôleur de la simulation à des robots réels avec le minimum d’effort possible [21]. Un programme client communique avec Player, qui s’exécute sur le robot, à l’aide d’une connexion de socket TCP pour le transfert de données. Player contient trois modèles : – Le modèle dispositif (Character device). Les character devices sont des dispositifs qui fournissent et consomment des flots de données au fil du temps. C’est typiquement le cas des capteurs et des effecteurs. L’interface Character device définit des opérations (open, close, read, write, etc.) pour l’accès et le contrôle des capteurs et des effecteurs. 1. http://playerstage.sourceforge.net/doc/Player-2.1.0/player/supported_ hardware.html 20II.2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel – Le modèle Interface/Pilote (Interface/Driver ) : Le modèle interface/driver regroupe les dispositifs selon des fonctionnalités logiques de façon à ce que les dispositifs capables d’effectuer la même fonctionnalité apparaissent d’une fa- çon similaire à l’utilisateur. – Le modèle Client/serveur : Player supporte plusieurs connexions clientes aux dispositifs, créant ainsi des nouvelles possibilités pour la perception et le contrôle collaboratif. 2.1.2 Les abstractions du matériel dans Player Les abstractions du matériel résident dans le modèle Interface/Driver. L’interface est une spécification du contenu des flots de données. Elle fournit un ensemble de messages communs à une certaine classe de dispositifs indépendamment de la plateforme utilisée. Le code qui implémente l’interface et qui convertit le format natif des commandes de l’API de communication en commandes requises par l’interface et inversement est appelé driver. Le modèle Character device relie les flots en entrée du programme aux données des capteurs et les flots de sortie aux commandes des effecteurs. Les drivers sont spéci- fiques aux dispositifs ou à une famille de dispositifs d’un même “vendeur”. Player sépare les fonctionnalités logiques des détails d’implémentation des dispositifs. On peut dire alors que Interface correspond à la notion de classe abstraite regroupant l’ensemble des fonctionnalités d’un type spécifique de capteurs ou d’actionneurs et que Driver est une classe concrète. /* Request and change the device ’s configuration . */ typedef struct player_ranger_config { double min_angle ; /** Start angle of scans [ rad ]. May be unfilled . */ double max_angle ; /** End angle of scans [ rad ]. May be unfilled . */ double angular_res ; /** Scan resolution [ rad ]. May be unfilled . */ double min_range ; /** Minimum range [m ]. */ double max_range ; /** Maximum range [m ]. May be unfilled . */ double range_res ; /** Range resolution [m ]. May be unfilled . */ double frequency ; /** Scanning frequency [ Hz ]. May be unfilled . */ } player_ranger_config_t ; /* The ranger device position , orientation and size . */ typedef struct player_ranger_geom { player_pose3d_t pose ; /** Device centre pose in robot CS [m , m , m , rad , rad , rad ]. */ player_bbox3d_t size ; /** Size of the device [m , m , m ]. */ uint32_t element_poses_count ; /** Number of individual elements that make up the device . */ player_pose3d_t * element_poses ; /** Pose of each individual element that makes up the device ( in device CS ). */ uint32_t element_sizes_count ; /** Number of individual elements that make up the device . */ player_bbox3d_t * element_sizes ; /** Size of each individual element that makes up the device . */ } player_ranger_geom_t ; Listing II.1 – Extrait de l’Interface RangeSensor de Player 21Chapitre II. Les middleware de robotique L’interface Ranger (voir le listing II.1) fournit une API commune aux capteurs de distance. Les attributs min_angle, max_angle, angular_res, min_range, max_angle, range_res et frequency de la structure player_ranger_config permettent de configurer un capteur de distance donné. La structure player_ranger_geom permet de spécifier la géométrie du capteur à configurer. Dans ce qui suit, nous discuterons l’impact du changement du capteur de distance dans un algorithme d’évitement d’obstacles écrit avec Player. 2.1.3 Discussion Le listing II.2 est un exemple d’algorithme d’évitement d’obstacles founi avec Player et programmé en C++ avec un capteur Sonar. Dans cet exemple, le robot avance dans son environnement. Si sa distance par rapport à l’obstacle le plus proche est inférieure à really_min_front_dist (lignes 9-13) il fait demi-tour sinon si cette distance est inférieure à min_front_dist (lignes 14-17), il s’arrête (ligne 27). Supposons maintenant que l’on veuille remplacer dans cet exemple le capteur Sonar par un capteur Laser. Il faudrait remplacer SonarProxy par LaserProxy et décomposer ensuite les rayons contenus dans l’angle de perception du capteur Laser (si leur nombre le permet) en 5 sous-ensembles afin de regrouper les rayons du capteur Laser et les traiter comme les rayons du Sonar. Cela éviterait de modifier le code. 1 PlayerClient robot ( gHostname , gPort ); 2 Position2dProxy pp (& robot , gIndex ); 3 SonarProxy sp (& robot , gIndex ); 4 pp . SetMotorEnable ( true ); 5 double newspeed = 0.0 f , newturnrate = 0.0 f; 6 for (;;) { 7 robot . Read (); 8 avoid = 0; newspeed = 0.200; 9 if ( avoid == 0) { 10 if (( sp [2] < really_min_front_dist ) || ( sp [3] < really_min_front_dist ) || 11 ( sp [4] < really_min_front_dist ) || ( sp [5] < really_min_front_dist )){ 12 avoid = 50; newspeed = -0.100; 13 } 14 else if (( sp [2] < min_front_dist ) || ( sp [3] < min_front_dist ) || 15 ( sp [4] < min_front_dist ) || ( sp [5] < min_front_dist )){ 16 newspeed = 0; avoid = 50; 17 } 18 } 19 if ( avoid > 0){ 20 if (( sp [0] + sp [1]) < ( sp [6] + sp [7])) 21 newturnrate = dtor ( -30); 22 else 23 newturnrate = dtor (30); 24 avoid - -; 25 } 26 else 27 newturnrate = 0; 28 pp . SetSpeed (2 * newspeed , newturnrate ); 29 } Listing II.2 – Evitement d’obstacle avec Sonar 22II.2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel Cependant cette nouvelle décomposition dépendra de la position des capteurs sur le robot, du nombre de rayons du Laser, etc. Par conséquent, le remplacement d’un capteur par un autre impliquerait une modification du code existant car celui-ci reste écrit en fonction des données de bas niveau du Sonar. En effet, les abstractions de Player sont fournies pour certaines plateformes de robotique mais elles restent de bas niveau [45] : c’est encore au système de contrôle du robot d’interpréter les nombres retournés par les capteurs et envoyés aux effecteurs. Il faudrait encapsuler ces détails de bas niveau afin de séparer les responsabilités liées au traitement des données de celles liées à leur acquisition ou à leur exécution. Cela permettrait de faciliter le développement des applications et de pouvoir gérer les changements éventuels de matériel dans l’application. 2.2 Robot Operating System (ROS) 2.2.1 Description L’un des middlewares les plus communément utilisé dans la communauté robotique de nos jours est ROS [10, 43]. Il supporte l’intégration de modules logiciels indépendants distribués, appelés noeuds (ROS nodes). ROS fournit un ensemble d’outils qui permettent de packager et de déployer (à travers les notions de package et de stack) les applications de robotique. Il fournit également un nombre important de librairies qui implémentent des drivers de capteurs (par exemple : Hokuyo Scanning range finder, Sharp IR range finder, etc) permettant ainsi d’encapsuler les données spécifiques et de fournir certaines fonctionnalités pour les robots (par exemple ROS navigation stack). Les noeuds ROS sont des blocks de code et sont implémentés dans des classes C++ ou Python. Un système ROS est un graphe composé d’un ensemble de noeuds qui communiquent entre eux à travers des messages. Ces messages sont échangés avec le mécanisme Publish/Subscribe de manière asynchrone à travers un bus de communication appelé ROS-Topic [46]. Chaque topic est typpé par le type du message ROS publié dessus. La figure II.3 montre le mécanisme de communication entre 2 noeuds. En dépit de ses nombreux avantages, ROS ne gère pas l’aspect temps-réel, il délègue cet aspect à des middlewares tiers comme OROCOS [47]. Les Topics ROS permettent la communication entre ces 2 middleware. 23Chapitre II. Les middleware de robotique Figure II.3 – Communication entre les noeuds ROS 2.2.2 Les abstractions du matériel dans ROS Les messages ROS [48] sont des structures de données comportant des attributs typpés. L’une des bibliothèques des messages ROS, appelée sensor_msgs, est dé- diée aux capteurs communément utilisés. Ces messages regroupent les propriétés définies pour chaque type de capteurs. Nous citons par exemple les messages sensor_msgs/LaserScan pour les capteurs Laser, les messages sensor_msgs/CameraInfo pour les caméras, les messages sensor_msgs/Range pour les capteurs Infrarouge, etc. En utilisant ces messages, le code de l’application ne dépend pas d’un modèle de capteurs particulier ayant une configuration particulière mais dépend uniquement du type du capteur. Le tableau II.2 montre les deux messages sensor_msgs/LaserScan et sensor_msgs/Range qui sont des capteurs de distance à rayons dont les propriétés diffèrent. Pour le message LaserScan, le header signifie le temps d’acquisition du premier rayon Laser alors que pour le Range, le header signifie le temps d’acquisition de la distance du rayon Infrarouge. Pour le message LaserScan, il est important de spécifier les attributs angles min et max de début et de fin du scan ainsi que l’attribut angle_increment qui indique la distance angulaire entre les mesures. Pour le message Range, il faut spécifier l’attribut filed_of_view qui représente la taille de l’arc où la distance est valide. Ensuite, dans les deux messages, on peut spécifier min_range et max_range qui définissent les valeurs minimales et maximales qui peuvent être perçues. 2.2.3 Discussion Afin de tester les abstractions proposées par ROS, nous avons programmé un code très simple d’un composant d’évitement d’obstacles sous OROCOS qui est un framework temps-réel à base de composants C++ [47] que nous détaillerons dans la section 5. Cet exemple a été développé en fonction d’un capteur Laser en utilisant 24II.2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel Sensor_msgs/LaserScan.msg Sensor_msgs/Range.msg Header header Header header float32 angle_min uint8 ULTRASOUND=0 float32 angle_max uint8 INFRARED=1 float32 angle_increment uint8 radiation_type float32 time_increment float32 field_of_view float32 scan_time float32 min_range float32 range_min float32 max_range float32 range_max float32 range float32[] ranges float32[] intensities Table II.2 – Exemple de sensor messages de ROS le topic ROS Sensor_msg : :LaserScan. Le principe est simple, si les capteurs droits du robot détectent un obstacle, le robot tourne à gauche. Si les capteurs gauches du robot détectent un obstacle, le robot tourne à droite et s’il n’y a pas d’obstacle le robot avance. Maintenant supposons que l’on veuille réutiliser ce code pour un robot disposant de 2 capteurs Infrarouges. Il faut alors adapter le code pour récupérer les informations des 2 capteurs infrarouges et faire le même traitement de données. Le listing II.3 montre les 2 codes avec Laser et Infrarouge. Le code en gris est le code qui n’a pas été modifié. Le code en bleu représente le code à modifier pour le composant écrit en fonction du capteur Laser et le code en rouge est le code qui a été modifié pour tenir compte des capteurs Infrarouges. L’impact du changement au niveau d’un composant n’est pas très important car l’exemple que nous avons pris est très simple. Imaginons maintenant une application comportant plusieurs composants qui intéragissent entre eux. Il faudrait alors faire des modifications au sein des composants et au niveau des composants avec lesquels ils intéragissent. Ces abstractions sont alors de bas niveau. Il faudrait définir des abstractions qui soient plus indépendantes des caractéristiques du matériel utilisé. 2.3 Middleware for Robots (MIRO) 2.3.1 Description Le but de MIRO est de fournir un framework général pour le développement des applications de robotique [11]. Ce but a été défini après le développement de plusieurs applications sous différentes plateformes de robotique, avec différents langages de programmation et pour différents robots mobiles lorsque les développeurs 25Chapitre II. Les middleware de robotique Capteur Laser Capteurs Infrarouge #include #include #include #include //include Orocos libraries //include Orocos libraries using namespace std ; using namespace std ; using namespace RTT ; using namespace RTT ; class AvoidObstaclesWithLaserScanRobot : class AvoidObstaclesWithIR : public RTT : :TaskContext{ public RTT : :TaskContext{ private : private : InputPortinport ; InputPortinport_infrared_left ; InputPortinport_infrared_rightt ; OutputPort OutputPort public : public : AvoidObstaclesWithLaserScanRobot AvoidObstaclesWithIRRobot (const std : :string& name) : (const std : :string& name) : TaskContext(name), TaskContext(name), inport("laser_in"), inport_infrared_left("infrared_left_in"), inport_infrared_right("infrared_right_in"), outport("twist_out") { outport("twist_out") { ports()->addPort(inport) ; ports()->addPort(inport_infrared_left) ; ports()->addPort(inport_infrared_right) ; ports()->addPort(outport) ; ports()->addPort(outport) ; } } AvoidObstaclesWithLaserScanRobot() {} AvoidObstaclesWithIRRobot() {} } ; } ; private : private : void updateHook() { void updateHook() { sensor_msgs : :LaserScan msg ; sensor_msgs : :Range msg_infrared_left ; sensor_msgs : :Range msg_infrared_right ; geometry_msgs : :Twist cmd ; geometry_msgs : :Twist cmd ; double midA, midB ; double ir_left = -1.0, ir_right = -1.0 ; if (NewData == inport.read(msg)) { if (NewData == inport_infrared_left.read(msg_infrared_left)) ir_left = msg_infrared_left.range ; if(NewData == inport_infrared_right.read(msg_infrared_right)) ir_right = msg_infrared_right.range ; bool halt = false ; bool halt = false ; for (int i = msg.angle_min ; i <= msg.angle_max ; i++) { if ( ((ir_left > msg_infrared_left.min_range) if(msg.ranges[i] < msg.range_max) { && (ir_left < msg_infrared_left.max_range)) || ((ir_right > msg_infrared_right.min_range) && (ir_right < msg_infrared_right.max_range)) ) { halt = true ; halt = true ; break ; } } } if (halt) { if (halt) { midA = std : :accumulate(msg.ranges.begin(),msg.ranges.end()-45, 0) ; midB = std : :accumulate(msg.ranges.begin()+45,msg.ranges.end(), 0) ; if (midA > midB){ cmd.angular.z = -1 ; } if(ir_left > ir_right) { cmd.angular.z = -1 ; } else { cmd.angular.z = 1 ; } else { cmd.angular.z = 1 ; } } } else { else { cmd.linear.x = 1 ; cmd.linear.x = 1 ; outport.write(cmd) ;} outport.write(cmd) ; } } } } ORO_CREATE_COMPONENT(AvoidObstaclesWithLaserScanRobot) ORO_CREATE_COMPONENT(AvoidObstaclesWithIR) Table II.3 – à gauche le code écrit en fonction du capteur Laser, à droite le code après sa modification avec les Infrarouges ont réalisé l’importance de la définition d’un framework général pour éviter de réimplémenter les mêmes applications si on change de robot. MIRO a été conçu et implé- menté en utilisant l’approche orientée objet ainsi que l’architecture du middleware CORBA (Common Object Request Broker Architecture) [49] qui permet d’assurer la communication entre les différents modules du robot et entre plusieurs robots. L’architecture de MIRO est composée de trois couches : – Une couche dispositif (device layer). – Une couche service (service layer). – La classe framework MIRO (MIRO framework class) qui fournit un ensemble 26II.2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel de modules fonctionnels fréquemment utilisés en robotique comme la localisation, la plannification de chemin, etc. 2.3.2 Les abstractions du matériel dans MIRO Le framework MIRO contient trois couches dont deux qui permettent d’abstraire le matériel utilisé. La couche dispositif encapsule les messages de communication de bas niveau (liés au bus de communication, etc.) dans des appels de méthodes pour l’invocation des services demandés. Cette couche fournit une interface pour les capteurs et les actionneurs d’un robot. Ces derniers sont définis comme des objets qui peuvent être interrogés et controlés par leurs méthodes. La couche dispositif est dépendante des détails des robots et de la plateforme. La couche service fournit des abstractions de services pour les capteurs et les actionneurs à travers l’interface de définition CORBA (CORBA Interface Description Language : IDL) et implémente ensuite ces services d’une manière indépendante des plateformes. L’interface RangeSensor_IDL définie dans le langage IDL permet d’abstraire les données de Laser et de l’infrarouge II.3. 1 interface RangeSensor 2 { 3 /** 4 * The specific sensor is either masked out or didn ’t provide usefull data . 5 */ 6 const long INVALID_RANGE = -2; 7 /** 8 * The scan value is bigger than the maximum distance the range 9 * sensor can measure . 10 */ 11 const long HORIZON_RANGE = -1; 12 //! The range sensor does not send events 13 const long NONE_PUSHING = 0; 14 //! The range sensor sends a full scan with its events ( @ref RangeScanEventIDL ). 15 const long FULL = 1; 16 //! The range sensor sends one sensor group scan with its events ( @ref RangeGroupEventIDL ). 17 const long GROUPWISE = 2; 18 //! The range sensor sends a bunch of sensor readings with its events ( @ref RangeBunchEventIDL ). 19 const long BUNCHWISE = 3; 20 //! Query the layout of a range sensor type . 21 ScanDescriptionIDL getScanDescription (); 22 //! Query a range sensor group . 23 RangeGroupEventIDL getGroup ( in unsigned long id ) raises ( EOutOfBounds ); 24 //! Wait and query a range sensor group . 25 RangeGroupEventIDL getWaitGroup ( in unsigned long id ) raises ( EOutOfBounds , ETimeOut ); 26 //! Query a range sensor . 27 RangeScanEventIDL getFullScan (); 28 //! Wait and query a range sensor . 29 RangeScanEventIDL getWaitFullScan () raises ( ETimeOut ); 30 }; Listing II.3 – Interface RangeSensor_IDL de MIRO 27Chapitre II. Les middleware de robotique 2.3.3 Discussion Le listing II.4 montre un exemple présenté dans les travaux de Krüger et al. [50] programmé en Python en utilisant les interfaces fournies par MIRO. Dans cet exemple, le robot est équipé par des capteurs sonar. Il avance jusqu’à ce que l’obstacle le plus proche détecté soit plus proche que 3000 millimètres, dans ce cas il s’arrête. 1 import pyMiro 2 sonar = pyMiro . getSonar () 3 loko = pyMiro . getMotion () 4 while (1): 5 scan = sonar . getFullScan () 6 front_scan = scan . range [0] 7 if min ( front_scan ) <3000: 8 loko . limp () 9 else : 10 loko . setLRVelocity (50 ,50) Listing II.4 – Evitement d’obstacle avec les abstractions de MIRO L’abstraction getFullScan() (ligne 5) est définie dans l’interface RangeSensor présentée dans la section précédente. L’abstraction limp() est définie dans une interface appelée Motion afin d’abstraire les mouvements des effecteurs, elle représente un arrêt passif (c.-à-d. le robot ne s’arrête pas complètement). Le retour d’expérience de Krüger et al. dans [50] sur l’utilisation de MIRO montre qu’on peut intégrer des nouveaux capteurs à MIRO en implémentant les interfaces fournies mais n’évoque pas le changement de capteur dans les applications existantes. Supposons maintenant que l’on veuille réutiliser ce même code mais avec un capteur Laser. On peut remplacer getSonar() (ligne 2) par getLaser(), scan.rang[0] (ligne 6) par l’identifiant du rayon Laser placé à l’avant du robot et le code fonctionnerait. Cependant, il faut tenir compte de la portée du rayon Laser, de sa position s’il est placé à gauche du centre du robot par exemple, etc. On peut dire que les abstractions de MIRO permettent une intégration de nouveaux capteurs en supposant qu’il remplit toutes les hypothèses sur les besoins du code. Cette intégration implique l’adaptation du code existant et donc des changements qui peuvent être assez importants. En revanche, il faudrait modifier les paramètres spécifiques à la portée du capteur par exemple. Typiquement dans ce cas, 3000 mm est la distance à partir de laquelle le robot doit s’arrêter. Si la portée du nouveau capteur est inférieure à 3000 millimètres, il faut modifier ce paramètre. Plus les tests sont importants, plus les paramètres à modifier le seront aussi. Ces changements ont un impact sur la visibilité du code car les détails de bas niveau seront confondus avec les détails d’implémentation et ceux 28II.2 La gestion de la variabilité dans les middleware de robotique : abstraction du matériel de l’algorithme. Si on prend maintenant un autre exemple où on voudrait utiliser des capteurs tactiles, il faut réécrire tout le code et implémenter les abstractions d’une nouvelle interface. Il faudrait alors encapsuler toutes les données de bas niveau à travers des abstractions de plus haut niveau sous forme de requêtes sur l’environnement par exemple. 2.4 Python Robotics (PyRo) 2.4.1 Description PyRo [12, 44] est un environnement de développement de robotique en Python qui permet aux étudiants et aux chercheurs d’explorer différents thèmes en robotique indépendamment des robots utilisés. Il a été intégré à plusieurs cours académiques car il offre un support simple pour les étudiants pour le développement des applications de robotique. Le but de PyRo est de faciliter le développement des applications de robotique et d’assurer leur portabilité, sans la modification du code, à travers des abstractions de haut niveau qui encapsulent les détails de bas niveau. PyRo est composé d’un ensemble de classes Python qui encapsulent les détails de bas niveau. Les utilisateurs programment leurs applications en utilisant une API. Cette dernière est implémentée avec une hiérarchie orientée objet offrant ainsi une couche d’abstraction. 2.4.2 Les abstractions du matériel dans PyRo Les abstractions du matériel définies dans PyRo sont les suivantes : – Range sensors : Indépendamment du capteur utilisé, cette interface définit des abstractions pour les capteurs Laser, Infratouge et Sonar. – Robot units : L’unité de la distance retournée par les capteurs peut être en mètres ou en millimètres ou simplement une valeur numérique où les grandes valeurs indiquent un espace libre et les petites valeurs indiquent la présence d’un obstacle proche. Robot unit est une nouvelle unité de mesure qui unifie toutes les autres. – Sensor groups regroupe les capteurs selon leur emplacement. L’utilisateur n’aura plus à se soucier du nombre de capteur disponibles mais utilisera sim- 29Chapitre II. Les middleware de robotique plement des abstractions du type : front, frontleft, left, etc. comme le montre la figure II.4. Les abstractions proposées sont les suivantes : front-all pour tous les capteurs avant du robot, front pour les capteurs placés à l’avant du robot, front-left pour les capteurs à l’avant gauche, front-right pour les capteurs placés à l’avant droit du robot. De la même façon, les abstractions back, back-right et back-left sont définies par rapport à l’arrière du robot. Figure II.4 – Le regroupement des capteurs dans PyRO – Motion control : définit des abstractions pour les commandes des effecteurs : move(translate, rotate) et motors(leftpower, rightpower) – Devices : Permet d’introduire des nouveaux dispositifs qui n’ont pas encore été pris en charge. 2.4.3 Discussion PyRo propose des abstractions pour le matériel sous forme d’actions de plus haut niveau que les commandes spécifiques envoyées au robot et de regroupement de capteurs selon leurs positions. Prenons maintenant un exemple défini en fonction de ces abstractions (voir listing II.5). Cet exemple représente une tâche d’évitement d’obstacle très simple, si un obstacle est rencontré à gauche le robot tourne à droite, si un obstacle est rencontré à droite le robot tourne à gauche et s’il n’y a pas d’obstacle, le robot avance. 1 # i f a p p r o ac h ing an o b s t a c l e on t h e l e f t s i d e 2 # t u rn r i g h t 3 # e l s e i f a p p r o ac h ing an o b s t a c l e on t h e r i g h t s i d e 4 # t u rn l e f t 30II.3 Conclusion 5 # e l s e go f o rw a r d 6 from pyro . b r ai n import Brain 7 c l a s s Avoid ( Brain ) : 8 def s t e p ( s e l f ) : 9 s a f e Di s t a n c e = 1 # in Robot Un i t s 10 # i f a p p r o ac h ing an o b s t a c l e on t h e l e f t s i d e , t u rn r i g h t 11 i f min ( s e l f . g e t ( ’ r o b o t / r an ge / f r o n t −l e f t / v al u e ’ ) ) < s a f e Di s t a n c e : 12 s e l f . r o b o t . move ( 0 , −0. 3 ) 13 #e l s e i f a p p r o ac h ing an o b s t a c l e on t h e r i g h t s i d e , t u rn l e f t 14 e l i f min ( s e l f . g e t ( ’ r o b o t / r an ge / f r o n t −r i g h t / v al u e ’ ) ) < s a f e Di s t a n c e : 15 s e l f . r o b o t . move ( 0 , 0 . 3 ) 16 #e l s e go f o rw a r d 17 e l s e : 18 r o b o t . move ( 0 . 5 , 0 ) Listing II.5 – Evitement d’obstacle programmé avec PyRo extrait de [12] Le code présenté est très simple grâce aux abstractions proposées, il nécessite des connaissances sur la vitesse du robot (ligne 13), son angle de rotation (ligne 10) et sur les valeurs retournées par les capteurs. La fonction min (lignes 6 et 9) est une fonction Python permettant de retourner le minimum des valeurs lues à partir des capteurs. Ce code peut être utilisé pour tout robot équipé de capteurs à rayons avant gauche et avant droit. Supposons maintenant que l’on veuille réutiliser ce même code mais avec des capteurs tactiles, il faut modifier alors les conditions sur les valeurs des capteurs et sur leurs positions. Par conséquent, bien que ces abstractions soient de plus haut niveau que les capteurs en permettant de les regrouper et de ne pas se soucier du nombre de rayons, elles restent insuffisantes. En effet, elles ne permettent pas de fournir des informations de haut niveau sur l’environnement car elles sont spécifiques à la position des capteurs et ne font que des regroupements de ces derniers. Il faudrait définir des abstractions de plus haut niveau afin de garantir une indépendance par rapport à la position des capteurs en fournissant des informations sur l’environnement du robot. 3 Conclusion Une étude complète des middleware de robotique existants est présentée dans [21] montrant les particularités de chaque middleware et les avantages de son utili- 31Chapitre II. Les middleware de robotique sation. Dans ce chapitre, nous avons présenté certains des middleware de robotique qui traitent l’aspect abstraction du matériel. Nous avons vu que ces abstractions sont insuffisantes car elles restent de bas niveau et n’isolent pas bien de certains changements sur les capteurs. En effet, le traitement des données des capteurs reste confondu avec les détails d’implantation de l’application. Ces abstractions ne permettent pas d’encapsuler les détails de bas niveau et de faciliter le développement des applications de robotique. De plus, les middleware ne traitent pas les aspects qui concernent la variabilité algorithmique. Afin de faciliter le développement de ces applications, il faudrait permettre aux roboticiens de manipuler des concepts qu’ils ont l’habitude d’utiliser pour le développement de leurs applications. Ces concepts peuvent être des concepts de haut niveau du domaine comme ceux proposés par les DSML (langage de modélisation spécifiques au domaine). Cependant, les concepts proposés par les DSML manquent souvent de sémantique opérationnelle. Il faudrait alors définir des abstractions de haut niveau qui permettent d’obtenir des informations sur l’environnement du robot et de définir des actions de haut niveau d’une part et d’encapsuler les détails algorithmiques d’autre part. ne sont autres que les concepts du domaine. Les techniques de l’ingénierie dirigiée par les modèles ont été appliquées dans ce contexte afin de définir ce qui est appelé les DSML (langage de modélisation spécifique). Dans le chapitre suivant, nous présentons les différentes phases de création d’un DSML. Nous présenterons ensuite les DSML pour la robotique existants. 32Langages de modélisations spécifiques à la robotique 1 Introduction La définition des applications de robotique est souvent considérée comme un processus complexe car ceci requiert une expertise du domaine (matériel utilisé, tâche à programmer, etc.) ainsi qu’une expertise en développement (plateforme, architecture, etc.). Nous avons présenté dans le premier chapitre la variabilité dans la robotique mobile. Les middleware ont essayé de pallier le problème de la variabilité du matériel en introduisant des abstractions qui restent toutefois de bas niveau comme nous l’avons vu dans le chapitre précédent. D’autre part, chaque middleware s’appuie sur un protocole de communication qui lui est propre ou qui s’appuie sur le standard CORBA. Par conséquent, un problème de portabilité d’un middleware vers un autre a été constaté en plus de la difficulté de faire interopérer les applications entre elles. L’une des priorités pour la communauté robotique consiste alors à définir des abstractions communes pour garantir l’indépendance des applications des middleware, assurer leur portabilité et ainsi optimiser le processus de développement. Afin de répondre à cet objectif, il faudrait tout d’abord réduire le fossé sémantique entre les développeurs et les roboticiens en utilisant un langage commun compré- hensible par les roboticiens d’un côté et par les développeurs d’un autre côté. Ce langage commun est appelé langage spécifique à un domaine ou langage dédié (DSL : domain specific language), il doit répondre au besoin de définir des spécialisations du domaine étudié [51]. Les langages de modélisation spécifiques au domaine (DSML : Domain Specific Mo- 33Chapitre III. Langages de modélisations spécifiques à la robotique deling Language) sont des DSL basés sur les modèles qui visent à définir des abstractions de haut niveau et à accélérer le processus du développement à travers l’utilisation des modèles. Ils permettent une meilleure compréhension des systèmes représentés ainsi qu’une accessibilité au développement des applications pour les roboticiens à travers des notations appropriées du domaine. Dans ce chapitre, nous commençons par une présentation générale des DSML et des techniques d’ingénierie dirigée pas les modèles. Nous présentons ensuite le cycle de vie d’un DSML puis les DSML existants pour la robotique. 2 Langages de Modélisation Spécifiques aux domaines (DSML) Un DSL est un langage de programmation ou un langage de spécification qui offre, à travers des notations appropriées et des abstractions, une puissance expressive axée sur, et généralement limitée à, un domaine particulier [14]. Les DSL sont souvent des langages déclaratifs, ils peuvent par conséquent être considérés comme des langages de spécification aussi bien que des langages de programmation [14]. Le développement d’un DSL requiert une expertise du domaine auquel il est dédié ainsi qu’une expertise en développement des langages [52]. L’un des objectifs principaux d’un DSL consiste à réduire l’ambiguïté de la terminologie et le fossé sémantique entre les experts du domaine d’application et les développeurs et ainsi convenir d’un ensemble d’abstractions communes pour un domaine particulier. Par conséquent, les experts du domaine doivent être mis au centre du développement du DSL [53]. Idéalement, un DSL apporterait plusieurs avantages aux développeurs ainsi qu’aux experts du domaine auquel il est dédié. Plusieurs travaux soulignent ces avantages, notamment Kieburtz et al. [54] qui ont réalisé une comparaison entre deux approches dans le cadre d’une étude empirique. La première consistait au développement d’une application en utilisant un ensemble de templates fournissant des fonctionnalités et des types génériques et la deuxième était l’utilisation d’un générateur de templates à partir d’un DSL. Ils ont constaté que l’utilisation de la deuxième approche améliorait considérablement la productivité des développeurs, la fiabilité de l’application et garantissait une facilité d’utilisation offrant ainsi un outil de réflexion et de communication ([55], page 41) aussi bien pour les développeurs que pour les ex- 34III.2 Langages de Modélisation Spécifiques aux domaines (DSML) perts du domaine. Grâce à cette facilité d’utilisation, les experts du domaine peuvent comprendre les programmes définis avec le DSL, les modifier et même les développer eux-même [14]. D’après Van Deursen [56], l’utilisation des DSLs renforcerait également la maintenance des applications et assurerait leur portabilité. Idéalement, un DSL devrait être réutilisable [57] dans le sens où l’on peut réutiliser les connaissances capitalisées du domaine afin de définir plusieurs programmes différents. Cette réutilisabilité découle également de l’indépendance des DSL des plateformes cibles ([55], page 43) car lors de la conception d’un DSL, une séparation des reponsabilités est réalisée entre les notations du domaine et les détails d’implémentations liés aux plateformes. En dépit de tous ces avantages, les DSLs présentent certaines limites comme par exemple, un coût non négligeable de conception, d’implémentation et d’apprentissage pour leur utilisation [14]. Un DSL bien défini apporterait alors des solutions aux limites constatées. Les DSL sont souvent définis comme des langages de modélisation spécifiques au domaine (DSML) qui incluent une infrastructure pour des transformations automatiques à partir de modèles vers un code source et des artefacts [2]. Les techniques de l’ingénierie dirigée par les modèles permettent la conception des DSML. Dans la section suivante nous présentons ces techniques. 2.1 Les techniques d’ingénierie dirigée par les modèles L’Ingénierie Dirigée par les Modèles (IDM) ou Model Driven Engineering (MDE) [15] répond au besoin de définir des abstractions du domaine en plaçant les modèles au centre du développement logiciel. Un modèle est une représentation simplifiée d’un système destiné à améliorer notre capacité à comprendre, prévoir et éventuellement contrôler le comportement de ce système [58]. Nous pouvons dire, par exemple, qu’une carte géographique est un modèle. L’interprétation de cette carte diffère d’une personne à une autre en l’absence de légende. Nous devons donc définir une légende standard pour cette carte afin de pouvoir l’interpréter de manière unique. C’est de cette même façon que nous pouvons définir le lien entre les modèles et les méta-modèles. Un méta-modéle (niveau M2 de la figure III.5) est un langage dont l’interprétation est unique car il définit les concepts d’un domaine particulier et il est lui-même conforme à un méta-méta- 35Chapitre III. Langages de modélisations spécifiques à la robotique Figure III.5 – Les différents niveaux de modélisation modèle (MOF : Meta Object Facility) (niveau M3 de la figure III.5). Les modèles (niveau M1 de la figure III.5), instances du méta-modèle, respectent donc les notations du domaine et contiennent une combinaison particulière de ses concepts. L’OMG (Object Management Group) est un consortium d’industriels et de chercheurs dont l’objectif est d’établir des standards permettant de résoudre les problèmes d’interopérabilité des systèmes d’infomation [59]. L’architecture proposée par l’OMG pour les différents niveaux de modélisation est présentée dans la figure III.5. La MDE est une généralisation de l’approche MDA (Model Driven Architecture), proposée et soutenue par l’OMG. La MDA applique la séparation des préoccupations qui consiste à élaborer des modèles métier (indépendants des détails techniques des plateformes) et des modèles spécifiques aux plateformes (pour la partie technique d’une plateforme). L’avantage le plus important qu’offre MDA est la pérennité des modèles indépendants des plateformes grâce à la modélisation des spécifications mé- tier. Dans ce qui suit nous présentons les différents niveaux de modélisation en MDA et les transformations entre ces modèles ainsi que les outils dédiés à la modélisation et aux transformations. 2.1.1 Les niveaux de modélisation Trois niveaux de modélisation interviennent en MDA : – Les Modèles Indépendants des Plateformes (PIM : Platform Independent Model). Ces modèles sont proches des contraintes et des considérations des experts du domaine et permettent de représenter la structure et les opérations 36III.2 Langages de Modélisation Spécifiques aux domaines (DSML) du système et ce, d’un point de vue indépendant des plateformes. – Les Modèle Spécifiques aux Plateformes (PSM : Platform Specific Model). Ces modèles résultent d’une association du PIM aux détails techniques d’une plateforme donnée. À partir du PSM le code vers la plateforme cible est généré. – Les Modèles de Description des Plateformes (PDM : Platform Description Model). Ces modèles permettent de spécifier la façon dont les fonctionnalités de la plateforme sont implémentées. Ils spécifient également comment ces fonctionnalités sont utilisées. Un PIM est conforme à un méta-modèle indépendant des plateformes et un PSM est conforme à un méta-modèle représentant les concepts d’une plateforme spéci- fique. Nous allons maintenant présenter les différents outils permettant de réaliser les différents niveaux de modélisation notamment les méta-modèles et les modèles. 2.1.1.1 Outils Le projet de modélisation d’Eclipse (EMP) [60] offre une multitude d’outils dédiés au développement dirigé par les modèles. Une partie de l’EMP comprend EMF (Eclipse Modeling Framework) qui permet la définition de métamodèles sous forme de fichiers Ecore. Une instance d’un méta-modèle est un modèle défini sous forme de fichier XMI. Papyrus [61] est un outil d’édition graphique de modèles, basé sur l’environnement Eclipse EMF, pour UML2 [62]. Conformément à son objectif principal, il met en œuvre la spécification standard complète de UML2 notamment les diagrammes de structure (c.-à-d. diagramme de classe, diagramme de déploiement, etc.), les diagrammes de comportement (c.-à-d. le diagramme d’activités, diagramme de machine à états) et les diagrammes d’intéraction (c.-à-d. diagramme de séquence, etc.). Papyrus est également conforme au standard graphique DI (Diagram Interchange) qui permet d’échanger les données graphiques. Papyrus fournit aussi un support large pour les profils UML [63]. Ces derniers permettent d’étendre UML afin de l’adapter à plusieurs domaines d’applications. Dans le cadre du projet PROTEUS, nous avons utilisé Papyrus afin de définir un éditeur graphique permettant de modéliser des scénarios de robotique en utilisant les concepts du domaine. Afin d’avoir une application exécutable vers une plateforme cible à partir des diffé- rents modèles présentés précédemment, des transformations sont définies pour transformer les modèles en code exécutable. Nous les présentons dans la section suivante. 37Chapitre III. Langages de modélisations spécifiques à la robotique 2.1.2 Les transformations MDA passe par la transformation respective de ses modèles afin d’obtenir une application exécutable à partir de ces derniers. Ces transformations sont effectuées : – du PIM vers le PSM (de modèle vers modèle) : pour établir les liens entre les concepts généraux et les concepts spécifiques aux plateformes ; – du PSM vers du code (de modèle vers texte) : pour obtenir du code exécutable correspondant au modèle spécifique à la plateforme d’exécution. Théoriquement, il faudrait que le PDM intervienne dans les transformations de PIM vers PSM pour spécifier les fonctionnalités relatives à la plateforme utilisée. Cependant, pour la définition des transformations, il faudrait au préalable définir des méta-modèles du PIM, du PDM et du PSM. La définition des méta-modèles du PIM et du PSM ne pose pas de problème particulier. En revanche, le méta-modèle du PDM n’est actuellement pas réalisable car il devrait permettre de construire des modèles de toutes les plateformes et vu que ces dernières sont différentes, il n’existe pas de nos jours de solution à ce problème. Les transformations existantes se résument alors à des transformations du PIM vers le PSM (de modèle vers modèle) et du PSM vers le code (de modèle vers texte). Plusieurs outils sont proposés pour réaliser ces transformations. Nous les présentons dans la section suivante. 2.1.2.1 Outils Les outils disponibles aujourd’hui basés sur les techniques d’ingénierie dirigée par les modèles permettent de construire des méta-modèles, des modèles et leurs équivalents en XMI (XML Metadata Interchange) [64] ou en UML facilement manipulables par les outils de génération de code assurant ainsi la géné- ration de code vers multiples et diverses plateformes cibles. Une plateforme cible est une plateforme constituée de ressources logicielles et matérielles servant de support d’exécution à l’application générée. Nous soulignons la différence entre un outil de génération de code et un générateur de code. Un outil de génération de code est un compilateur qui permet de définir des règles de transformations entre le DSL et la plateforme cible tandis qu’un générateur de code est un programme qui établit des règles de transformations entre le DSL et la plateforme cible. Le générateur de code est implémenté avec un outil de génération de code. Il existe plusieurs outils de génération de code, certains de modèle vers modèle 38III.3 Cycle de vie d’un DSML comme Epsilon [65], Kermeta [66] et d’autres, de modèle vers texte, comme Acceleo [67] et TOM-EMF [68]. Acceleo permet de définir des transformations de Modèle vers Texte (approche MDA) et supporte les standards de modélisation comme UML, XMI, etc.. La syntaxe mise en oeuvre par Acceleo se base sur des templates qui contiennent des informations tirées sur les modèles en entrée (à travers des requêtes) et leur associent le code à générer à travers des conditions et des boucles. Dans le cadre de cette thèse et du projet ANR PROTEUS, nous utiliserons Acceleo comme outil de génération de code. Dans la section suivante, nous présentons les différentes étapes de conception d’un DSML. 3 Cycle de vie d’un DSML Avant de concevoir un DSML, plusieurs questions doivent être soulevées : – Par qui sera conçu le DSML ? – Pour qui sera conçu le DSML ? – Quels sont les concepts du domaine qui doivent être représentés et comment les représenter ? Ces questions permettent d’orienter les choix de conception d’un DSML afin de ré- duire le coût en terme de maintenance et de développement et garantir ainsi des solutions aux problèmes existants. La création d’un DSML est un processus itératif. Un DSML se base souvent sur une compréhension limitée et simple du domaine, puis évolue progressivement avec l’intervention des experts du domaine. Nous pouvons distinguer sans ambiguïté quatre phases qui déterminent le cycle de vie d’un DSL. Tout d’abord, une phase d’analyse du domaine afin d’identifier les abstractions appropriées. Une abstraction est un concept. Ce concept fait partie du domaine modélisé et représente une entité abstraite ou concrète dans ce domaine [69]. L’analyse du domaine est succédée d’une phase de conception afin de représenter ces abstractions puis d’une phase d’intégration des plateformes. La dernière phase est enfin l’utilisation du DSL [14]. 39Chapitre III. Langages de modélisations spécifiques à la robotique 3.1 Analyse du domaine Les deux premières questions présentées précédemment doivent être traitées dans la phase de l’analyse du domaine. L’étape de l’analyse du domaine consiste à rassembler les connaissances du domaine et à les regrouper en notions sémantiques et en opérations. La modélisation des domaines, désignée par l’ingénierie des domaines (Domain engineering) [70], est un aspect de l’ingénierie logicielle introduit afin de pallier les problèmes de réutilisabilité. L’ingénierie des domaines peut être utilisée afin de construire des librairies réutilisables pour les DSLs [14]. Selon l’utilisateur final de l’application, l’identification des concepts du domaine peut varier. Prenons par exemple le cas de la robotique mobile. Pour un expert en robotique, les concepts relevant du contrôle, de la communication, de la perception, de l’action et de l’environnment réel du robot ou de la simulation définissent les concepts de base de la robotique mobile. Un développeur, quant à lui, traitera les aspects techniques liés à la programmation et à l’architecture logicielle des plateformes de robotique (langages à base de composants, langages orientés objets, etc.). La délimitation du domaine est un processus qui pourrait être conflictuel s’il n’est pas clairement défini. Simos et al. [71] ont distingué deux catégories d’utilisation du domaine : – Le domaine comme étant un “monde réel” : Ceci désigne le domaine du monde où le travail final va être réalisé. On retrouve cette vision du domaine en intelligence artificielle, en génie cognitif ou encore en programmation orientée objet (OO). L’analyse du domaine en OO traduit souvent l’analyse du domaine en une description orientée-objet des entités et des transactions dans le monde réel. Cette description forme une base pour l’implantation d’un système qui supporte ces activités du monde réel. En d’autres termes, cette théorie se base souvent sur le principe que les experts d’un domaine ne prêtent pas beaucoup d’importance à l’aspect logiciel d’une application. – Le domaine comme étant un “ensemble de systèmes” : Cette définition du domaine se base sur la théorie de l’analyse du domaine orientée par la réutilisabilité. Par opposition au domaine en tant que monde réel, les systèmes sont eux même l’objet de l’étude du domaine dans cette catégorie. Le domaine est défini comme une famille ou un ensemble de systèmes incluant des fonctionnalités communes dans un domaine particulier. La modélisation des similarités 40III.3 Cycle de vie d’un DSML et des variabilités à travers les systèmes existants dans le domaine est la base de cette définition du domaine. Dans certains cas, les concepts d’un DSL en général et d’un DSML en particulier peuvent être extraits à partir d’un système existant et les abstractions du domaine peuvent être dérivées directement à partir de ce système existant. Si l’architecture du système existant est documentée en utilisant un langage de modélisation graphique par exemple, cette architecture peut être une source valuable pour l’obtention des abstractions du domaine [2]. Parmi les approches de modélisation des domaines, nous citons l’analyse de domaine orientée par les features (FODA : Feature Oriented Domain Analysis) [72] et les ontologies [73]. 3.1.1 Les ontologies L’ontologie est une approche de modélisation des domaines qui vise à fournir une compréhension des éléments d’un domaine particulier. Elle permet de représenter des bases de connaissances qui offrent un contenu sémantique réutilisable et accessible depuis diverses applications. Elle définit des concepts ainsi que leur signification et les relations entre eux pour représenter un domaine de connaissances. Une ontologie doit être exprimée suivant une syntaxe donnée, associée à une interprétation donnée. Le langage OWL (Ontology Web Language) est l’un des langages qui permettent de représenter les ontologies. Nous le présentons dans ce qui suit. 3.1.1.1 Le langage OWL (Ontology Web Language) Le langage OWL est un langage pour la représentation des ontologies Web. Il est compatible avec le Web sémantique ce qui permet aux utilisateurs de donner une définition formelle aux termes qu’ils créent. Ainsi les machines peuvent raisonner sur ces termes. La terminologie de OWL se base essentiellement sur espaces de nommages (namespace), les classes et les propriétés. Un namespace est un conteneur qui fournit le contexte du contenu d’un fichier OWL. Une classe encapsule la signification d’un concept. Des hiérarchies de classes peuvent être créées en déclarant qu’une classe peut être une sous-classe (subClassOf) d’une autre classe. Une propriété décrit une association entre les classes. Une hiérarchie de propriétés peut également être créée en précisant qu’une propriété est une sous propriété d’une autre propriété (Property :IsA). Une composition générique des pro- 41Chapitre III. Langages de modélisations spécifiques à la robotique priétés est exprimée avec le mode clé Property :hasA, cela veut dire qu’une propriété peut s’appliquer à d’autres propriétés. Dans le cadre du projet ANR PROTEUS qui a défini le contexte de cette thèse, nous nous baserons sur une ontologie existante du domaine de la robotique mobile, développée dans le cadre de ce projet, afin d’extraire les abstractions du domaine appropriées pour notre DSML : RobotML. L’ontologie de RobotML sera présentée dans la section 3 du chapitre 5. 3.2 Conception des DSML Dans cette section, nous tentons de répondre à la troisième question sur l’extraction des abstractions pertinentes du domaine et leur représentation. La conception d’un DSML doit permettre une définition non ambigûe d’abstractions de haut niveau représentant les concepts identifiés à partir de l’analyse du domaine. Ces abstractions doivent être indépendants des détails des plateformes (middleware) et doivent représenter les concepts du domaine. La conception d’un DSL passe par deux étapes importantes qui sont la définition de la syntaxe abstraite et la définition de la syntaxe concrète ([55], p.175). À ces deux étapes peut s’ajouter la définition de la sémantique de la syntaxe abstraite. Dans cette section nous présentons ces différentes étapes. 3.2.1 Définition de la syntaxe abstraite La syntaxe abstraite d’un DSML peut être définie de deux façons principales qui peuvent être complémentaires. La première façon consiste à définir le modèle du domaine sous forme d’un méta-modèle représentant les abstractions du domaine et les relations entre elles. La deuxième façon consiste à étendre les concepts d’UML sous forme d’un profil afin de les adapter aux abstractions identifiées dans le métamodèle. Dans cette section nous présentons donc le modèle de domaine en tant que méta-modèle ainsi que les profils UML. 3.2.1.1 Modèle du domaine : Méta-modèle La syntaxe abstraite appelée aussi modèle du domaine regroupe les concepts du domaine cible du DSL, leurs propriétés et les relations entre eux dans un modèle du domaine. Le modèle du domaine formalise les connaissances du domaine et doit être validé par les experts du domaine. Les éléments du DSL peuvent aussi avoir une sémantique. La définition de cette 42III.3 Cycle de vie d’un DSML dernière n’est pas une étape indispensable pour la conception d’un DSL. La sémantique peut être statique ou dynamique. Dans le premier cas, elle permet de définir la sémantique qui ne peut pas être exprimée directement au niveau du modèle du domaine comme par exemple les éléments invariants et les relation entre eux. Quant à la sémantique dynamique, elle permet de définir les effets comportementaux ré- sultant de l’utilisation des éléments du DSL. Elle définit également la façon dont les éléments du DSL doivent intéragir à l’exécution. Le comportement peut être exprimé de différentes façons allant de modèles de flots de contrôle de haut niveau en passant par des modèles de comportements plus détaillés jusqu’à une spécification textuelle précise. Dans le cas des DSML, le modèle du domaine est défini comme un PIM qui représente les concepts du domaine. Des modèles spécifiques aux plateformes peuvent aussi être définis afin de représenter les concepts des plateformes cibles du DSML. Ces modèles, si définis, interviendront dans l’étape intégration des plateformes des DSML. 3.2.1.2 Profil UML Un profil étend les concepts d’UML afin de les adapter à un domaine d’application. L’extension d’UML à travers les profils passe par trois concepts principaux [63] : – Stereotype : Un stéréotype étend une méta-classe existante du méta-modèle UML pour en changer la sémantique. Un stéréotype peut posséder des propriétés (tagged value) et être sujet à des contraintes. Un stéréotype est une extension limitée d’une méta-classe, on ne peut pas définir un stéréotype sans définir le lien vers la méta-classe qu’il étend. UML permet egalement d’associer à chaque stéréotype sa propre notation sous forme d’une icône et/ou un cadre (shape) pour le distinguer graphiquement du concept qu’il étend. – Tagged Value : Ce sont des propriétés des stéréotypes qui offrent un moyen de spécifier les caractéristiques du concept UML étendu. Une propriété a un type qui appartient impérativement à UML sinon il doit être défini et annexé au profil. – Constraint On peut définir des contraintes sur le méta-modèle UML afin de le spécialiser. Ces contraintes sont définies avec le langage OCL (Object Constraint Language). Le profil UML sert de support pour la définition d’un éditeur graphique qui va utiliser les différentes icônes associées aux stéréotypes par exemple. Il est également possible 43Chapitre III. Langages de modélisations spécifiques à la robotique Figure III.6 – Les artefacts du DSL - extrait de [2] de vérifier les contraintes sur l’association et la composition des différents éléments proposés à travers cet éditeur et de valider ainsi les modèles réalisés. Dans la section suivante, nous précisions en quoi consiste la définition de la syntaxe concrète d’un DSML. 3.2.2 Définition de la syntaxe concrète La syntaxe concrète est une interface à travers laquelle sont représentées les abstractions définies dans la syntaxe abstraite [2]. Chaque DSL peut avoir plusieurs syntaxes concrètes : graphique et textuelle. Pour un DSML, la syntaxe concrète est présentée sous forme graphique. Elle est représentée à travers des outils permettant à l’utilisateur de créer des modèles qui représentent une combinaison particulière des éléments de la syntaxe abstraite. La définition de la syntaxe concrète est une étape importante du point de vue de l’utilisateur final du DSML. La figure III.6 résume les différents artefacts intervenant dans la conception d’un DSL. Un DSL correspond à un domaine, il possède une syntaxe abstraite qui peut avoir une sémantique statique ou (et) dynamique (que nous ne détaillerons pas car nous ne traitons pas ces parties dans cette thèse). Un DSL a une ou plusieurs syntaxes concrètes qui correspondent à cette syntaxe abstraite. Dans le cadre du projet PROTEUS, Papyrus a été utilisé pour la définition de la syntaxe concrète de notre DSML. Un fois que le modèle du domaine et la syntaxe concrète sont définis, il faut 44III.3 Cycle de vie d’un DSML Figure III.7 – Intégration des plateformes - basé sur [2] définir des règles de transformations qui permettront de faire le lien entre le modèle du domaine et les concepts des plateformes cibles. 3.3 Intégration des plateformes : Transformations et Géné- ration de code Comme nous l’avons indiqué précédemment, l’intégration des plateformes vient compléter la phase de conception en faisant le lien entre les concepts du domaine et les concepts des plateformes. Cette phase est aussi appelée phase d’implémentation ; elle consiste à mettre en place un compilateur qui traduit les programmes du DSL en une séquence d’appels de librairies [14]. Des transformations sont définies pour transformer les modèles définis à l’aide de la syntaxe concrète du DSML vers d’autres modèles ou vers un langage de programmation (correspondant à une plateforme cible) comme le montre la figure III.7. Il existe alors deux types de transformations : – De modèle vers modèle : elles consistent à convertir un modèle en un autre modèle du même système. – De modèle vers texte : elles consistent à convertir un modèle en code qui lui correspond. 45Chapitre III. Langages de modélisations spécifiques à la robotique 3.4 Utilisation L’étape d’utilisation consiste à représenter les programmes souhaités par l’utilisateur final et à les compiler [14]. Dans notre cas, cette étape consiste à modéliser le système souhaité et à générer le code correspondant. Le code doit être compilable et exécutable sur la ou les plateformes cibles. L’utilisation d’un DSL ne se restreint pas seulement à la modélisation et la génération de code. On peut faire également des analyses sur les modèles pour valider les fonctionnalités du système dès les premières phases de conception. 4 Les DSML pour la robotique Dans cette section, nous présentons tout d’abord les exigences que doivent respecter les DSML pour la robotique, nous présenterons ensuite les travaux qui ont adopté les techniques d’ingénierie dirigée par les modèles comme solution aux problèmes constatés dans le développement des applications de robotique et nous conclurons par une synthèse de ces travaux. 4.1 Exigences des langages de domaine pour la robotique En plus des caractéristiques des DSL présentées précédemment, idéalement un DSL pour la robotique respecterait les caractéristiques suivantes [74]. 1. Facilité d’utilisation. L’utilisation du DSL devrait être non seulement à la portée des experts en programmation mais aussi à la portée des experts en robotique et idéalement à la portée de simples utilisateurs de logiciels de robotique. 2. Spécification d’une architecture à base de composants. En supposant que la majorité des plateformes de robotique sont actuellement basées sur une architecture à base de composants, le DSL devrait permettre la spécification d’architectures à base de composants de systèmes de robotique autonomes. 3. Spécification des comportements des composants. Le DSL doit permettre la spécification des différents types de contrôle des composants. Il devrait être possible d’exprimer le contrôle sous forme algorithmique ou sous forme de machine à états finis. 46III.4 Les DSML pour la robotique 4. Neutralité vis à vis des architectures de robotique. Le DSL ne devrait pas imposer une architecture de robotique particulière : délibérative, hybride, réactive ou basée sur le comportement (voir section 3.3). 5. Plusieurs plateformes cibles hétérogènes. Les composants de l’application devraient être indépendants des plateformes cibles et devraient pouvoir s’exécuter sur des robots réels ou des simulateurs. De plus, il devrait être possible de déployer certains composants générés à partir du DSL sur une plateforme et les autres composants sur une autre plateforme. 6. Indépendance vis à vis des plateformes cibles. Même si l’indépendance par rapport aux plateformes cibles est difficile à réaliser, le DSL devrait être aussi indépendant que possible des spécificités des platesformes d’exécution. 7. Prise en charge de l’évolution des plateformes La génération de code doit être aussi agile que possible de façon à ce que si les plateformes cibles évoluent, l’impact de leur évolution n’affecte pas énormèment le code des générateurs. De plus, idéalement, si des nouvelles plateformes sont ajoutées, elles pourraient réutiliser les transformations déjà définies. 8. Evolution du DSL. Idéalement, il devrait être possible de changer au moins certains aspects du DSL sans avoir à construire une nouvelle implémentation. L’évolution du DSL peut faire partie du processus du développement. En effet, si le processus de développement du DSL est itératif, les concepts du domaine sont adaptés ou renommés selon les besoins des plateformes et des applications. Une autre façon de gérer l’évolution des DSL consisterait de partir d’exemples concrets pour la définition des concepts du DSL, la génération de code, etc. De cette façon, le DSL conçu permettra le développement de ces applications. 9. Abstractions du matériel Idéalement, le DSL offrirait un ensemble d’abstractions du matériel sous forme de librairies afin de rendre les modèles définis indépendants du matériel du robot en plus d’être indépendant des plateformes. 4.2 Travaux existants De nos jours, ils n’existe pas énormément de travaux qui mettent en oeuvre les techniques de l’ingénierie dirigée par les modèles pour la conception des DSLs pour la robotique. Certains travaux, notamment [75] et [76] ont appliqué ces techniques dans le cadre de l’étude d’un robot particulier ou d’une architecture de robotique 47Chapitre III. Langages de modélisations spécifiques à la robotique Figure III.8 – Les concepts de l’OMG appliqués à l’approche BCM - (tiré de [3]) particulière. Dans cette section, nous nous intéressons aux travaux qui ont défini des DSML en traitant les aspects de la variabilité en robotique (à travers des abstractions) et leur indépendance des plateformes cibles. 4.2.1 BRICS Component Model (BCM) 4.2.1.1 Description BRICS [77] est un projet européen qui vise à structurer et à formaliser le processus de développement des applications robotiques en fournissant des outils, des modèles et des librairies permettant d’accélérer le processus de développement. BRICS s’appuie sur les techniques d’ingénierie dirigée par les modèles afin de fournir un modèle appelé BCM (BRICS Component Model) [3] indépendant des plateformes à partir duquel une génération automatique de code est réalisée vers des plateformes de robotique (voir figure III.8). Le niveau M3 repré- sente le méta-méta-modèle Ecore. Il s’ensuit un méta-modèle minimal et général de composants, indépendant des plateformes, de niveau M2 appelé CPC (Component Port Connector). Au même niveau, des méta-modèles spécifiques aux plateformes ROS et OROCOS sont définis. Au niveau M1, on retrouve des modèles instances 48III.4 Les DSML pour la robotique des méta-modèles du niveau M2. Le méta-modèle CPC est spécialisé par les modèles des plateformes comme ROS et OROCOS. BRIDE [78] est le générateur de code qui assure les transformations de modèle vers modèle (du modèle instance du méta-modèle général vers le modèle instance du méta-modèle spécifique à la plateforme cible) ainsi que des transformations modèle vers texte (du modèle instance du méta-modèle spécifique à la plateforme cible vers la plateforme cible). Le méta-modèle CPC est présenté dans la figure III.9, il spécifie qu’un System peut avoir plusieurs connecteur(s) (méta-classe Connector) et des composants (métaclasse Component). Un composant peut avoir des ports (méta-classe Port), une ou plusieurs propriétés (Property) et des sous-composants. Les abstractions représentées dans ce méta-modèle reflètent l’architecture des plateformes cibles (c.-à-d. une architecture à base de composants) mais ne sont pas représentatives des concepts du domaine. En dehors du BCM, le projet BRICS propose une séparation des pré- occupations entre les composants de différentes natures à travers les 5Cs : – Computation : C’est la fonctionnalité responsable de l’accès aux données en lecture ou en écriture entre les différents composants, de leurs synchronisation et de leurs traitements. – Coordination : Cette fonctionnalité détermine comment les composants d’un système doivent travailler ensemble. Elle détermine le rôle d’un composant dans un système. – Composition : C’est la fonctionnalité qui permet de définir des composants composites. – Communication : Se charge de l’envoi de données aux composants de computation. – Configuration : Cette fonctionnalité permet de configurer les composants de communication et de computation. Cependant, cette architecture n’a pas été intégrée au BCM car les auteurs argumentent que cette distinction n’est pas effectuée au niveau des plateformes cibles. 4.2.1.2 Discussion Le BCM permet une représentation de modèles à bases de composants et une génération automatique de squelettes de code vers ROS et OROCOS. Cependant, les abstractions du domaine ne sont pas représentées et la distinction entre les différentes natures des composants (c.-à-d. contrôle et matériel) 49Chapitre III. Langages de modélisations spécifiques à la robotique Figure III.9 – Le méta-modèle CPC - (tiré de [3]) d’une application de robotique n’a pas été intégrée au BCM. Les aspects comportementaux des composants notamment, les machines à états finis et les algorithmes ne sont pas représentés dans le BCM. De plus, la génération de code est effectuée vers une et une seule plateforme cible à la fois ; la génération de code vers plusieurs plateformes cibles hétérogènes n’est pas supportée. L’évolution du BCM n’est pas envisageable éventuellement pour une intégration des 5Cs car il n’y aurait pas de correspondance avec les plateformes cibles [3]. 4.2.2 Open Robot Controller Computer Aided Design (ORCCAD) 4.2.2.1 Description ORCCAD est un framework pour la spécification de la partie contrôle et commande d’un système de robotique [79, 80] destiné aux applications de robotique temps-réel. Le but d’ORCCAD consiste à fournir un ensemble d’outils qui permettent d’aider l’utilisateur tout au long du processus de conception, de vérification et de développement de son application. Cet ensemble d’outils, appelé CASE (Computer Aided Software Engineering), a été défini en utilisant les outils du projet de modélisation d’Eclipse [60] qui se basent sur les techniques d’ingénierie dirigée par les modèles. L’approche ORCCAD utilise deux niveaux d’abstractions : un niveau fonctionnel et un niveau de contrôle [4]. Le niveau fonctionnel permet de représenter les tâches élémentaires du robot (Robot Task (RT)). Celles-ci sont décrites sous forme de comportements spécifiés dans des fichiers source écrits en ESTEREL [81] (voir figure III.10). Le niveau de contrôle (Robot Procedure (RP)) décrit ensuite la composition 50III.4 Les DSML pour la robotique Figure III.10 – Le méta-modèle RT extrait du méta-modèle d’ORCCAD - (tiré de [4]) hiérarchique des RTs. Les abstractions utilisées sont suffisament de haut niveau pour ne pas être spécifiques à une plateforme particulière et pour représenter les aspects temps-réel requis pour une application de robotique. A partir des modèles réalisés avec l’éditeur graphique d’ORCCAD (instance du méta-modèle dont une partie a été présentée précédemment), le générateur de code fournit du code C++, à partir des RTs et RPs, ainsi que le glue code qui permet de les connecter avec le système d’exploitation utilisé. 4.2.2.2 Discussion Malgré les avantages d’utilisation d’ORCCAD notamment la généricité de ses modèles et leur indépendance des détails des plateformes cibles, ORCCAD ne définit pas des abstractions du matériel et ne prend pas en charge la génération de code vers d’autres plateformes cibles de robotique. L’une des solutions possibles pour assurer la prise en charge de l’hétérogénéïté des plateformes consisterait à mettre en oeuvre un générateur de code à partir du code C++ généré vers d’autres plateformes. De plus, ces middlewares doivent prendre en charge l’aspect temps-réel, il n’est donc pas possible de générer du code vers des middlewares tel que ROS qui ne prend pas en compte cet aspect. 4.2.3 SmartSoft 4.2.3.1 Description SmartSoft [82][83] est un framework qui offre un ensemble de patterns de communication générique qui permettent l’assemblage et la composi- 51Chapitre III. Langages de modélisations spécifiques à la robotique tion des composants grâce à des interfaces structurées et consistantes correspondant à une sémantique bien définie. Ces interfaces sont basées sur des services de communication standard (client/server, master/slave, publish/subscribe, request/response, etc.). Le modèle de composants comporte également un automate générique qui gère le cycle de vie d’un composant [84]. Figure III.11 – Le méta-modèle de SmartSoft - (tiré de [5]) Le modèle de composants SmartSoft et ses mécanismes de communication ont été définis dans un méta-modèle appelé SmartMars (Modeling and Analysis of Robotic Systems) [16]. Les patterns de communication produisent différents modes de communication comme la communication dans une seule direction ou l’intéraction request/response. Par exemple, le pattern send est un mode de communication Client/Serveur dans une seule direction. Le pattern Query est un mode de communication Client/Serveur qui utilise l’intéraction request/response. Ces concepts sont représentés dans le méta-modèle SmartMars à travers les méta-classes QueryPattern, PushNewestPattern, ClientServerPort, MasterSlavePort, et CommunicationObject. Deux types de méta-modèles sont définis dans le méta-modèle SmartMars (voir fi- gure III.11) : un méta-modèle indépendant des plateformes représentant les patterns de communication de SmartSoft ainsi que la structure générale des composants et 52III.4 Les DSML pour la robotique leur cycle de vie et un méta-modèle spécifique aux plateformes permettant de spéci- fier les informations relatives à la plateforme choisie (méta-classes PSM-Connector, PSM-Target et PSM-NS dans la figure III.11). Le méta-modèle SmartMars a été implémenté sous forme de profil UML constituant ainsi une base de développement pour un outil intégré à Eclipse appelé SmartMDSD (Model Driven Software Design). SmartMDSD offre une chaîne d’outillage de la modélisation jusqu’à la génération de code (vers CORBA et ACE). 4.2.3.2 Discussion SmartSoft permet la modélisation à base de composants des applications de robotique indépendamment des plateformes cibles et permet également une spécification claire et concise des concepts de communication entre les différents composants définis. Les patterns de communication exprimés sont stables et ont été utilisés en robotique depuis plus de dix ans. Le méta-modèle de SmartSoft permet aussi de représenter le cycle de vie d’un composant à l’aide d’un automate où les états initialisent le composant, l’exécutent et peuvent indiquer l’échec de son exécution. Cependant, il n’y a pas de disctinction entre la nature des composants utilisés. En d’autres termes, on ne sait pas si ces composants sont matériel ou logiciels. Par conséquent, la prise en charge de plusieurs plateformes cibles hétérogènes n’est pas possible (c.-à-d. si on souhaite générer du code vers un simulateur et un middleware). De plus, les abstractions du domaine ne sont pas suffisantes car il n’est pas possible d’exprimer les abstractions du matériel par exemple. Concernant l’évolution des plateformes cibles et du méta-modèle, ces points n’ont pas été abordés dans les travaux de SmartSoft. 4.2.4 The 3 View Component Meta-Model (V3CMM) 4.2.4.1 Description V3CMM [6] s’appuie sur les concepts de l’OMG afin de fournir un méta-modèle indépendant des plateformes pour la conception des applications de robotique à base de composants. Ses principales caractéristiques sont la simplicité et l’économie des concepts d’un côté et la réutilisabilité des composants de l’autre. V3CMM utilise certains concepts d’UML afin d’offrir trois vues principales : (1) une vue structurelle pour la description de la structure des composants et de la communication entre eux (2) une vue de coordination décrivant le comportement de chaque composant sous forme de machine à états finis (en réutilisant les concepts 53Chapitre III. Langages de modélisations spécifiques à la robotique Figure III.12 – Méta-modèle V3CMM - tiré de [6] d’UML) (3) une vue algorithmique pour la description de l’algorithme de chaque composant selon l’état dans lequel il se trouve (qui reprend une représentation simplifiée du diagramme d’activités d’UML). Un extrait de ce méta-modèle est présenté dans la figure III.12. Une chaîne d’outillage a été développée avec les outils de modélisation d’Eclipse permettant ainsi la génération de code en deux étapes. Tout d’abord des transformations de modèle-vers-modèle sont définies entre un modèle instance du méta-modèle V3CMM et un modèle instance du méta-modèle représentant les concepts de la programmation orientée objets. Puis, à partir du deuxième modèle, des transformations de modèle vers texte sont définies vers le langage ADA. 4.2.4.2 Discussion Il est à noter que même si V3CMM ne contient pas les concepts de la robotique, il a été testé et essentiellement utilisé en robotique et dans le domaine des réseaux de capteurs sans fils [85] et d’autres domaines comme la domotique. Actuellement, V3CMM a été étendu afin de permettre la spécification des contraintes temps-réel. Des éditeurs textuels avec une validation de modèle V3CMM ainsi que plusieurs implémentations vers différents frameworks cibles. Cependant, V3CMM ne fait pas distinction entre les composants matériel et logiciel d’une application. Ainsi, il n’est pas possible de générer du code vers plusieurs pla- 54III.4 Les DSML pour la robotique Figure III.13 – Architecture de Genom3 teformes cibles hétérogènes. De plus, il n’est pas possible d’exprimer les abstractions du matériel de haut niveau. L’évolution du méta-modèle et des plateformes cibles n’a pas été abordée dans les travaux V3CMM. 4.2.5 GenoM3 4.2.5.1 Description GenoM3 [86] a été défini dans le but d’assurer l’indépendance des composants logiciels d’une application des middleware de robotique. L’idée principale consiste à découpler la structure des composants de leurs noyaux algorithmiques. Cette idée a été réalisée en mettant en oeuvre un template par middleware pour la définition des squelettes des composants dans celui-ci. Ce template est organisé sous forme d’un fichier source. En plus de ce template, un DSL textuel a été défini permettant la description des composants et de leurs fonctionnalités, notamment les ports, les types de données, les services, les opérations (définies sous forme de codels [87]) et le contexte d’éxécution (task ou thread), sous forme de spécification formelle (voir figure III.13). Un interpréteur se charge ensuite d’instancier les composants à partir de leurs descriptions conformément au template du middleware choisi. Du code exécutable est alors généré correspondant aux composants décrits. 55Chapitre III. Langages de modélisations spécifiques à la robotique Figure III.14 – Composant RTC 4.2.5.2 Discussion À travers plusieurs études de cas, il a été prouvé que l’indépendance des plateformes est garantie à travers l’utilisation de GenoM3 [88]. Cependant, l’architecture d’une application doit être conforme à la structure des templates définis et la spécification formelle des composants n’est pas au même niveau d’abstraction que les méta-modèles. La transformation sous forme de template de composants ne correspond pas aux meilleures pratiques du développement dirigé par les modèles [16] (MDSD : Model Driven Software Development). De plus, la génération de code vers des plateformes hétérogènes n’est pas prise en charge. De plus l’aspect abstraction des données du matériel n’est pas pris en charge. 4.2.6 Robot Technology Component (RTC) 4.2.6.1 Description OpenRTC [89] a été conçu par l’OMG afin de proposer un standard pour la robotique. Plusieurs plateformes se basent sur le standard RTC et utilisent son modèle de composants comme OpROS [90–92] et RTM [93]. Un RTC est une représentation logique du matériel et/ou d’une entité logicielle qui fournit des fonctionnalités et des services souvent utilisés. RTC étend les fonctionnalités des composants proposés par UML et s’appuie sur les technologies de la MDA pour proposer un modèle indépendant des plateformes exprimé en UML et composé de trois parties : – Lightweight RTC : un modèle basique contenant la définition de concepts simples comme composant et port comme le montre la figure III.14. Il dé- finit des interfaces avec des abstractions et des stéréotypes. – Execution semantics : C’est une extension du modèle basique (Lightweight RTC) qui supporte les patrons de conception critiques de communication utilisés en robotique. 56III.4 Les DSML pour la robotique – Introspection : Une API qui permet d’examiner les composants, leurs ports et leurs connexions à l’exécution. Trois modèles spécifiques aux plateformes (PSM) ont ensuite été définis dans le langage IDL (Interface Definition Language) de l’OMG et ont été proposés afin de spécifier les mécanismes de communication : – Local : indique que les composants communiquent entre eux et qu’ils sont placés dans le même réseau. – Lightweight CCM (Corba Component Model) Les composants sont distribués et communiquent via l’interface CCM-based middleware. – CORBA Les composants sont distribués et communiquent via CORBA. En plus des composants LightWeight RTC, RTC définit trois autres types de composants : – Le traitement des flots de données (Data flow processing/Periodic sampled data processing) : correpond à l’exécution de type périodique. Les composants de type flots de données sont exécutés périodiquement. Un composant de ce type peut aussi être un composant composite contenant d’autre composants de flots de données. De cette façon, le traitement de données peut être décomposé de manière hiérarchique. – Le traitement Stimulus/Réponse appelé également traitement de données asynchrone. Les applications utilisant ce type de composant doivent généralement réagir aux changements qui surgissent dans l’environnement du robot. Le comportement est représenté sous forme de machine à états finis (FSM). Lorsqu’un événement est signalé, la FSM change d’état en exécutant l’action associée à la transition par laquelle elle est passée. – Modes d’opération : fournit un support pour les applications qui doivent naviguer entre différentes implémentations de la même fonctionnalité. 4.2.6.2 Discussion Le modèle de composant RTC est considéré comme une spé- cification avancée proposée par l’OMG dans le domaine de la robotique. Ce modèle a servi de standard pour beaucoup de plateformes de robotique : RTM (Robot Technology Middleware) [93], OPRoS [90], GostaiRTC [94], etc. Cependant, la spécification de RTC est fortement influencée par des architectures qui se basent sur un échange de flots de données. Par conséquent, le modèle de composant RTC est influencé par un automate interne fortement lié à un modèle d’activités à l’intérieur d’un composant. Il ne permet pas la spécification de plusieurs 57Chapitre III. Langages de modélisations spécifiques à la robotique tâches à l’intérieur d’un composant. De plus, les composants de natures différentes ne sont pas distingués, il n’est pas donc pas possible de générer du code vers plusieurs plateformes hétérogènes. L’évolution du DSL et des plateformes cibles n’a pas été abordée pour le modèle RTC. Par ailleurs, les abstractions du matériel ne sont pas prises en charge. 4.3 Synthèse Les DSML existants pour la robotique répondent partiellement aux exigences présentées précédemment comme le montre le tableau III.4. BCM [3], SmartSoft [16], V3CMM [6], GenoM3 [86] et RTC [89] permettent la représentation d’une architecture à base de composants contrairement à ORCCAD [4] qui spécifie plutôt le niveau fonctionnel (Robot Task) et le niveau contrôle (Robot Procedure) d’une application. L’indépendance par rapport aux plateformes cibles a été respectée dans les DSML existants soit à travers des modèles indépendant des plateformes comme le cas de BCM, SmartSoft, V3CMM, ORCCAD et RTC ou à travers des templates comme le cas de GenoM3. Concernant la neutralité vis-à-vis des architectures de robotique elle est également gérée dans les travaux existants vu qu’aucun concept spécifique à une architecture particulière n’est spécifié. En revanche, la génération de code vers plusieurs plateformes cibles hétérogènes (c.-à-d. simulateur et middleware ou plusieurs middleware), la prise en charge de l’évolution des plateformes cibles, l’évolution du DSL ainsi que la représentation des abstractions du matériel ne sont pas actuellement prises en charge dans les travaux existants. 5 Conclusion Dans ce chapitre, nous avons présenté les DSML et leur cycle de vie. Nous avons ensuite étudié les travaux existants mettant en oeuvre les techniques d’ingénierie dirigée par les modèles afin de répondre aux problèmes constatés dans le développement des applications de robotique dûs à la variabilité du matériel, des algorithmes et des middleware et permettre ainsi une facilité d’utilisation, de développement et de réutilisabilité des applications. Nous avons vu que ces travaux ne gèrent pas l’hétérogénéïté des plateformes cibles. La distinction entre les composants matériel et les composants logiciels n’est pas 58III.5 Conclusion effectuée au niveau de la modélisation. De plus, les abstractions du domaine définies sont insuffisantes car elles sont très générales, elles sont souvent basées sur l’architecture des plateformes cibles (architecture à base de composants). SmartSort se distingue par la stabilité des patterns de communication qu’il propose et donc par des abstractions pour la communication basées sur une expertise du domaine. Certes ces DSML traitent le problème de l’indépendance par rapport aux plateformes cibles mais il devrait être possible de manipuler les concepts de robotique tels qu’ils sont utilisés par les roboticiens en fixant tout d’abord une terminologie du domaine définie par des roboticiens. De plus, il devrait être possible de générer du code vers plusieurs plateformes supportant ou non les aspects temps-réels. Dans le chapitre suivant, nous présentons notre DSML pour la robotique : RobotML et les solutions que nous proposons afin de répondre aux exigences présentées dans ce chapitre. 59Chapitre III. Langages de modélisations spécifiques à la robotique Caractéristiques V3CMM [6] SmartSoft [16] ORCCAD [ 4] BCM [3] Ge noM3 [86] RTC [89] Facilité d’utilisation Oui Oui Oui Oui Oui Oui Spécification d’une Oui Oui Non Oui Oui Oui architecture à base de composants Spécification du Oui Non Oui Non Oui Oui comportement des composants Indépendance des Oui Oui Oui Oui Oui Oui plateformes cibles Neutralité vis-à-vis Oui Oui Oui Oui Oui Oui des architectures de robotique Plusieurs plateformes Non Non Non Non Non Non cibles hétérogènes Prise en charge Non Non Non Non Non Non de l’évolution des plateformes Evolution du DSL Non Non Non Non Non Non Abstractions Non Non Non Non Non Non du matériel Table III.4 – Comparaison entre les DSML pour la robotique existants 60Deuxième partie Contributions 61Robotic Modeling Language (RobotML) 1 Introduction Notre étude des travaux existants a montré que les concepts utilisés dans les DSML de robotique actuels sont insuffisants pour représenter tous les aspects d’une application de robotique. D’une part les DSML existants se concentrent sur la repré- sentation de la partie architecturale ou (et) celle de contrôle et de communication d’une application en utilisant des modèles à base de composants généralistes qui ne se basent pas sur des abstractions du domaine. Par conséquent, ces abstractions ne permettent pas la gestion de la variabilité du matériel ou l’expression de données abstraites. De plus les travaux existants ne prennent pas en charge plusieurs plateformes cibles hétérogènes (de natures différentes : simulateurs et middlewares). Afin de faciliter le développement des applications de robotique, il devrait être possible pour un roboticien de pouvoir manipuler des concepts qu’il a l’habitude d’utiliser à travers des modèles et des outils qui leurs sont associés. Ces concepts peuvent être extraits à partir de systèmes existants telles que les ontologies qui représentent des bases de connaissance du domaine. Il devrait aussi être possible d’exprimer le comportement d’un composant à un niveau plus abstrait que le code à travers des automates par exemple. Enfin, les concepts d’un DSML devraient être suffisamment génériques pour prendre en charger plusieurs plateformes cibles hétérogènes. Nous avons ainsi contribué au développement d’un DSML pour la robotique : RobotML qui offre un langage axé sur des abstractions du domaine permettant tout d’abord de réduire le fossé sémantique entre les roboticiens et les développeurs. Ces abstractions sont basées sur une ontologie du domaine définie par des experts de 63Chapitre IV. Robotic Modeling Language (RobotML) robotique. De plus, RobotML offre une chaîne d’outillage allant de la modélisation de scénarios de robotique jusqu’à la génération de code vers plusieurs plateformes cibles hétérogènes facilitant ainsi le développement des applications de robotique. Les composants de différentes natures sont distingués dans RobotML. Par exemple, on distingue les composants matériels des composants de contrôle et des composants de déploiement. RobotML permet : – la spécification de l’architecture d’un système de robotique : composants de contrôle, composants matériel, leurs ports et les types de données qu’ils s’échangent. – la spécification de la communication entre les composants à travers des ports de flots de données ou des ports de service. Il est également possible de préciser le type de communication entre les composants (synchrone ou asynchrone). – la spécification du comportement des composants de l’architecture du système à travers des machines à états ou des algorithmes. – la spécification d’un plan de déploiement qui permet de définir plusieurs plateformes cibles hétérogènes (simulateurs et middleware). RobotML a été développé dans le cadre du projet ANR PROTEUS (Plateforme pour la Robotique Organisant les Transferts Entre Utilisateurs et Scientifiques) [95]. PROTEUS compte quinze partenaires notamment, DASSAULT Aviation [96], ECA [97], CEA [98], GOSTAI [99], Intempora [100], THALES [101], LASMEA [102], TOSA [103], GREYC [104], INRIA [105], ONERA [106], PRISME [107], EFFIDENCE [108], WIFIBOT [109] et enfin le LIP6 [110] au sein duquel cette thèse a été réalisée. Notre contribution dans le cadre du projet PROTEUS a consisté à participation aux différentes phases de développement de RobotML et à la définition des parties contrôle et communication de RobotML. De plus, nous avons défini un générateur de code à partir de RobotML vers le middleware OROCOS. Dans ce chapitre, nous décrivons le cycle de vie de RobotML et sa chaîne d’outillage. Nous présenterons enfin un exemple de scénario défini avec RobotML. 64IV.2 Vue d’ensemble sur le cycle de vie de RobotML 2 Vue d’ensemble sur le cycle de vie de RobotML Comme nous l’avons présenté dans le chapitre 3, le cycle de vie d’un DSML comporte quatre phases : l’analyse du domaine, la conception, l’intégration des plateformes cibles à travers la définition de générateurs de code et enfin l’utilisation. Pour effectuer l’Analyse du domaine, nous nous sommes basés sur un état de l’art sur les middleware, les simulateurs et les DSL existants pour la robotique. Cet état de l’art a permis d’identifier certaines exigences notamment l’indépendance par rapport aux plateformes cibles (middleware et simulateurs) et la représentation d’une architecture à base de composants. Ces dernières, combinées avec les concepts du domaine fournis par une ontologie de la robotique mobile définie dans le cadre du projet PROTEUS, ont permis de délimiter le domaine d’application (c.-à-d. la robotique mobile) et d’extraire de l’ontologie les abstractions dont les roboticiens ont besoin pour la définition de leurs applications. Après cette étape d’analyse du domaine arrive l’étape de Conception où l’on identi- fie la syntaxe abstraite ainsi qu’une syntaxe concrète qui s’articule autour de cette syntaxe abstraite afin de fournir un éditeur graphique permettant de manipuler les concepts du domaine. Plusieurs générateurs de code ont ensuite été implantés afin d’établir des règles de transformations à partir de ces abstractions vers les plateformes cibles. Enfin, la phase d’utilisation de RobotML consiste à tester toute la chaîne d’outillage de la modélisation vers la génération de code. 3 Analyse du domaine L’analyse du domaine pour la définition de notre DSML se base sur une ontologie de la robotique mobile définie dans le cadre du projet PROTEUS [7] ainsi que sur l’état de l’art des simulateurs et des middleware robotique. Une ontologie est une représentation formelle des connaissances décrivant un domaine donné [111]. L’ontologie de PROTEUS a été construite à partir de la connaissance des experts en robotique dans différents sous-domaines. Leur expertise porte sur les domaines suivants : commande, contrôle, perception, navigation, localisation, contrôle du trafic, optimisation, planification et simulation. Afin de partager leurs connaissances, des experts du domaine partenaires du projet PROTEUS, se sont réunis pour décrire des scénarios et pour exprimer leurs connaissances et leurs besoins dans la robotique 65Chapitre IV. Robotic Modeling Language (RobotML) mobile autonome. À partir de ces réunions, les exigences de l’ontologie ont été défi- nies. Ces exigences concernent la modélisation de la mécanique et des composants électroniques ainsi que des architectures de contrôle, les systèmes, les simulateurs, etc. Ces exigences incluent également la modélisation d’un robot donné ainsi que le suivi de son évolution (comportement) pendant l’exécution de son scénario. Comme il faut modéliser le comportement du robot, il est nécessaire de modéliser son environnement et sa mission. L’ontologie a été définie autour du concept System. Ce dernier représente une entité ayant des intéractions, il peut être considéré comme un composant au sens du génie logiciel. Un System est défini comme un bloc qui déclenche des intéractions et est impacté par les intéractions des autres systèmes. Le choix d’une représentation d’une telle architecture a pour but de permettre la définition des composants, de leurs comportements et des différents échanges de données entre eux. Ainsi, le code final généré à partir du DSML (dont les concepts sont extraits de l’ontologie) pourra correspondre aux concepts architecturaux utilisés par les plateformes cibles. L’ontologie de PROTEUS a été décrite avec le langage OWL que nous avons pré- senté dans la section 3.1.1.1 et est organisée de manière modulaire où les modules sont définis comme une spécialisation du module principal (le Kernel). Certains modules permettent de spécifier les classes décrivant les System, leurs ports et leurs caractéristiques. D’autres modules servent à décrire l’environnement du robot, les outils de simulation utilisés pour tester les solutions ou encore les expérimentations (validation, vérification, tests). La figure IV.15 montre la classification des différents systèmes (System) définis par l’ontologie. Comme nous l’avons dit un System est une entité ou une unité logique qui réalise une intéraction, il peut lui même comporter d’autres Systems dans ce cas, il s’agit d’un CompositeSystem. Les PhysicalObject, Software et AtomicSystem sont des Systems. Un PhysicalObject décrit toutes les entités physiques dans un scénario de robotique. Il peut être un Hardware (c.-à-d. horloge, effecteur, un bus de communication ou encore un capteur) sur lequel le Software s’exécute. Un PhysicalObject peut également être un Agent capable d’agir comme les robots (Robot) et les humains (Human). La figure IV.16 montre la relation entre les différentes Systems. Une Interaction est un concept abstrait utilisé pour décrire les intéractions entre les Systems. Elle s’effectue à travers des Ports qui représentent des interfaces pour les entrées/sor- 66IV.3 Analyse du domaine Figure IV.15 – Classification des systèmes dans l’ontologie (extrait de [7]) ties entre les Systems. Un System possède un état et un modèle d’évolution. Un EvolutionModel représente la propriété intrinsèque d’un composant d’évoluer à travers le temps. Deux types spécifiques d’EvolutionModel sont distingués mais ne sont pas représentés dans cette figure : Algorithm et StateMachine. Un Algorithm est une méthode pour la résolution d’un problème sous forme d’une séquence d’instructions. Une machine à états est définie par des transitions, des événements et s’appuie sur des états (State) pour indiquer l’évolution d’un système à travers des états. Les données échangées entre les différents Systems sont représentées dans le module Information (voir figure IV.17). Une Information est directement ou indirectement liée à une intéraction. Le lien direct indique qu’une intéraction transmet des informations. Le lien indirect indique qu’une intéraction possède un protocole qui contient des informations. Une Abstraction est une Information qui n’est pas directement interprétée par la machine. Contrairement aux abstractions, Data est une information directement interprétée par la machine. Une spécification de Data qui n’est pas représentée sur cette figure est PhysicalData ; elle désigne un objet mathématique-algébrique ayant une unité physique associée. 67Chapitre IV. Robotic Modeling Language (RobotML) Figure IV.16 – Intéraction entre les systèmes dans l’ontologie (extrait de [7]) Figure IV.17 – La classe Information dans l’ontologie (extrait de [7]) Les classes de l’ontologie représentant les concepts du domaine peuvent être reprises, modifiées ou supprimées dans le DSML. Par exemple, Interaction permet de définir un lien entre deux Systems mais n’est pas assez explicite. Nous l’avons remplacé dans le modèle du domaine par les concepts Port et Connector pour cap- 68IV.4 Conception de RobotML turer les propriétés d’une intéraction. Le principal avantage de cette démarche est de pouvoir réutiliser les bases de connaissance des experts du domaine pour enrichir le DSML [112]. L’ontologie constitue le point d’entrée du modèle du domaine de RobotML. Dans le projet PROTEUS, le but de la définition de l’ontolgie dépasse la représentation des concepts du domaine. L’une des ambitions de son utilisation consiste à normaliser le domaine de la robotique mobile. Cet objectif n’est pas encore atteint car les abstractions définies dans l’ontologie sont basées sur les connaissances des roboticiens comme nous l’avons présenté précédemment ou sur des descriptions de scénarios qu’ils souhaitent représenter et non pas sur des exemples concrets. On ne sait donc pas comment implanter certaines de ces abstractions. Dans la section suivante nous présentons la conception de RobotML qui se base sur les concepts de l’ontologie pour représenter les abstractions du domaine. 4 Conception de RobotML La conception de RobotML est passée par les étapes suivantes : 1. Extraction des abstractions du domaine à partir de l’ontologie : Les exigences d’un langage de domaine pour la robotique présentées dans la section 4.1 du chapitre 3. sont extraites de l’ontologie d’une part et de l’état de l’art sur les simulateurs et les middleware d’une autre part. 2. Représentation de ces abstractions dans un modèle du domaine sous forme d’un méta-modèle puis dans un profil qui étend les concepts d’UML pour les adapter aux concepts du domaine. 3. Après la vérification et la validation de la syntaxe abstraite, définition de la syntaxe concrète sous forme d’un éditeur graphique basé sur le profil UML. Dans cette section nous présentons toutes ces étapes. 4.1 Syntaxe abstraite Le DSML doit correspondre aux concepts du domaine provenant de l’ontologie. Ceci constitue la première exigence du DSML afin d’utiliser une terminologie défi- nie par les experts du domaine de la robotique. À partir de l’ontolgie, les concepts 69Chapitre IV. Robotic Modeling Language (RobotML) spécifiques aux domaines sont alors extraits. Ces concepts sont filtrés pour n’en retenir que ceux dont on a besoin pour la définition d’une application de robotique : l’architecture (les composants, leurs ports, les types de données), la communication entre les composants ainsi que leurs comportements. La syntaxe abstraite de RobotML a d’abord été représentée dans un modèle du domaine (méta-modèle) puis dans un profil qui étend les concepts d’UML pour les adapter aux concepts du domaine. Les concepts du modèle du domaine ont généralement le même nom que ceux de l’ontologie sauf si ces derniers ne sont pas assez explicites comme le cas du concept Interaction que nous avons remplacé par les concepts Port et Connector. Étant donné que l’on souhaiterait que notre DSML supporte plusieurs plateformes cibles hétérogènes, les concepts du DSML sont également extraits à partir d’un état de l’art sur les simulateurs et les middlewares. Deux stratégies simples sont possibles pour extraire les concepts correspondant à plusieurs plateformes : faire l’union ou l’intersection des concepts de ces plateformes. Autrement il faudrait réaliser un travail considérable de factorisation et de construction de nouvelles abstractions ce qui n’a pas été possible dans Proteus malheureusement. Si nous choisissons l’intersection des concepts identifiés dans les plateformes, on imposerait des restrictions et les concepts de certaines plateformes ne pourraient pas être représentés. Si nous choisissons l’union, nous couvrons les concepts existants et aussi, il sera plus facile de supporter des nouvelles plateformes. Nous avons alors choisi l’union des concepts identifiés dans les plateformes. Cependant, le DSML devient ainsi plus complexe que les plateformes cibles et il est possible que des concepts ne soient pas traduisibles sur certaines plateformes Le tableau IV.5 montre la correspondance entre les concepts utilisés pour définir l’ontologie en OWL (voir section 3.1.1.1 et les concepts d’UML que nous avons utilisés pour représenter notre modèle de domaine. Classe OWL Concepts d’UML Concept Class subClassOf Inheritence Property Association, Attribute Property :IsA Inheritence Property :HasA Composition Cardinality Multiplicity Table IV.5 – Correspondance entre OWL et UML 70IV.4 Conception de RobotML Dans ce qui suit nous présentons notre modèle de domaine ainsi que le profil UML. 4.1.1 Le modèle de domaine RobotML : méta-modèle L’objectif principal de notre DSML consiste à permettre aux roboticiens de manipuler les concepts dont ils ont l’habitude d’utiliser pour la définition de leurs applications. Nous avons distingué trois parties dans notre modèle de domaine : la partie architecture, la partie communication et la partie contrôle. Cette distinction découle des principales parties à définir pour une application de robotique. La figure IV.18 montre une vue globale des principaux packages du modèle du domaine RobotML : Figure IV.18 – RobotML Domain Model – Le package RoboticArchitecture regroupe les concepts architecturaux et structurels qui définissent une application de robotique. Ce package représente la partie Architecture. – Le package RoboticBehavior permet de définir le comportement d’un composant d’une application de robotique à travers une machine à états finis ou des algorithmes. Ce package représente la partie Control. – Le package RoboticCommunications définit la communication entre les composants à travers des ports et des connecteurs. Ce package représente la partie Communication. – Le package Deployment permet de spécifier les propriétés relatives au déploiement des composants en représentant les plateformes cibles (middleware ou 71Chapitre IV. Robotic Modeling Language (RobotML) simultaurs) vers lesquelles le code des composants sera généré. 4.1.1.1 La partie Architecture Cette partie représente les concepts qui permettent de définir l’architecture d’un scénario de robotique sous forme d’un modèle à base de composants ayant des propriétés, des ports et des types. La partie Architecture comporte six packages comme le montre la figure IV.19 : le package RoboticSystem, le package SystemEnvironment, le package DataType, le package RoboticMission, le package Platform et le package Deployment que nous détaillerons dans ce qui suit. Figure IV.19 – RoboticArchitecture Package 1. Le package Robotic System (voir Figure IV.21). La méta-classe System représente un composant ayant une activité (attribut activity) et qui peut être local ou non (attribut native). Cet attribut permet d’indiquer si un composant qui satisfait le même rôle existe déjà localement sur la machine. Les attributs libraryPath et LibraryComponentName sont respectivement le chemin et le nom de ce composant existant qu’on peut associer au composant représenté. Un System a une ou plusieurs propriétés (Property), un ou plusieurs ports (Port) et des connecteurs (Connector) qui permettent de relier les ports entre eux. La méta-classe Property est soit une propriété d’un système dans le sens attribut (méta-classe BasicProperty de la figure IV.20) soit une partie d’un système (méta-classe Part de la figure IV.20). 72IV.4 Conception de RobotML Figure IV.20 – La méta-classe Property La méta-classe Port sera développée dans la partie Communication. Un System a un comportement exprimé à travers la méta-classe Evolution Model que nous détaillerons dans la partie Control. Un RoboticSystem est un System permettant de représenter un composant concret, il a une position et une orientation. La méta-classe SensorSystem représente les capteurs, l’attribut frequency est la fréquence de chargement des données des capteurs. La métaclasse ActuatorSystem représente les effecteurs. Ces deux méta-classes sont spécialisées dans d’autres types de capteurs et d’effecteurs spécifiques que nous ne présenterons pas car nous nous intéressons uniquement aux concepts du DSML et non aux détails spécifiques des capteurs et des effecteurs. Figure IV.21 – Le package RoboticSystem 73Chapitre IV. Robotic Modeling Language (RobotML) 2. Le package SystemEnvironment. Ce package définit les concepts de l’environnement où le robot évolue. Cette représentation permet de définir les environnements de simulation par exemple. 3. Le package DataType. Ce package permet de spécifier les types de données qui vont être utilisés par les ports, les propriétés, etc. (voir figure IV.22). Figure IV.22 – RobotML Data Types Un data type peut être : – une donnée physique Physical Data : Ce type représente une unité mathé- matique associée à un objet physique. Cet object mathématique peut être considéré comme une abstraction d’une donnée physique. On trouve par exemple les types Distance, Angle, Acceleration comme le montre la figure IV.23. La sémantique exacte de ces types est gérée ensuite par l’utilisateur. En effet, au niveau du DSML, ces types n’ont pas de sémantique opérationnelle. Par exemple, le type distance peut désigner une distance par rapport à un obstacle ou une distance de sécurité, etc. Figure IV.23 – physicalData 74IV.4 Conception de RobotML – un type composé ComposedData. C’est un type qui représente des données communes à des objets du domaine de la robotique. Comme par exemple GPS, Image, etc. (voir figure IV.24). Figure IV.24 – Types composés de RobotML – un type primitif PrimitiveData comme par exemple le type bool, int, char, etc. (voir figure IV.25). – une collection c.-à-d. listes, tables de hashage, séquences, etc. – un timestamped data qui associe un horodateur à une donnée pour connaître son évolution au fil du de l’exécution (si elle reste valide, etc.). Figure IV.25 – Types primitifs de RobotML Étant donné que le middleware ROS a été intégré à la plupart des plateformes cibles de RobotML (OROCOS, RT-Maps, etc.), nous avons également défini une librairie basée sur les types ROS afin de faciliter leur utilisation par les uti- 75Chapitre IV. Robotic Modeling Language (RobotML) lisateurs de RobotML. Ces types sont représentés comme des DataType comme le montre la figure IV.26 où les geometry_msgs de ROS sont représentés. Figure IV.26 – Intégration des geometry_msgs de ROS à RobotML 4. Le package Robotic Mission. Ce package décrit les concepts qui sont requis pour la définition d’une mission opérationnelle et qui sont utilisés par les composants de l’architecture qui réalisent cette mission. Ce package est typiquement utilisé pour la représentation des scénarios. 5. Le package Platform (voir figure IV.27). Il définit les plateformes qui représentent l’environnement d’exécution. La méta-classe Platform peut être un middleware (méta-classe RoboticMiddleware) ou un simulateur (RoboticSimulator). L’attribut RoboticMiddlewareKind est typpé par une énumération où les noms des middleware pris en charge par le DSML sont spécifiés. Aucune propriété des middleware n’est représentée. Le choix d’un middleware servira uniquement au déploiement. De même pour la méta-classe RoboticSimulator qui est spécialisée en trois méta-classes où il y a seulement besoin de spécifier la configuration souhaitée de l’exécution (temps-réel ou non, valeur de la gravité, etc.) selon le simulateur choisi. 6. Le package Deployment permet l’allocation d’un composant (méta-classe System) vers une plateforme (méta-classe Platform) comme le montre la figure IV.28. 76IV.4 Conception de RobotML Figure IV.27 – Le package Platform Figure IV.28 – Le package Deployment Pour résumer, à partir de la partie architecture, il est possible de représenter le squelette d’un composant : ses ports, les types de ses ports ainsi que ses propriétés. Un composant peut être un composant matériel (capteur ou effecteur) ou un composant de contrôle. Dans la section suivante, nous présentons la partie control qui permet de spécifier le comportement d’un composant. 4.1.1.2 La partie Contrôle Cette partie du DSML est la partie responsable de la spécification du comportement des composants de contrôle d’un système de robotique. Nous allons maintenant expliquer quel contrôle nous souhaitons exprimer : – Le contrôle à boucle fermée (Feedback control) : Dans ce cas le système doit avoir un retour (une connaissance) sur son état après l’exécution d’une commande. 77Chapitre IV. Robotic Modeling Language (RobotML) – Le contrôle à boucle ouverte (open loop control) : Dans ce cas le système ne récupère pas les informations sur son état après l’exécution d’une commande. On retrouve ces boucles de contrôle dans les architectures que nous avons présentées dans la section 3.3 du chapitre 1. Si l’architecture est réactive, le principe est celui de Stimulus/Réponse. Il y a donc une action qui est définie suite à un état dans lequel se trouve le robot. Si l’architecture est basée sur le comportement, il devrait être possible de suivre l’évolution des comportements du robot et de les activer/dé- sactiver. Si l’architecture est hybride ou délibérative, le contrôle se base sur un plan. Il devrait alors être possible de représenter l’état du robot dans son plan. Le contrôle peut alors être exprimé comme un automate qui permet l’expression des instructions d’un composant à un niveau plus abstrait que le code. Pour commencer, l’utilisateur peut spécifier un automate où les états par lesquels le robot pourrait passer sont représentés. Il faudrait ensuite spécifier quels sont tous les états possibles à partir d’un état donné et sous quelle condition la transition entre ces états est déclenchée. Si le contrôle se base sur une boucle ouverte, la transition d’un état à un autre est déclenchée directement à partir du premier état. En revanche lorsqu’il s’agit d’une boucle fermée, la transition est déclenchée selon le retour de la commande exécutée. La figure IV.29 montre une vue globale des packages qui interviennent pour la définition de la partie comportementale d’un composant. Le comportement des composants est défini sous forme de machines à états finis (FSM) ou avec des algorithmes. Figure IV.29 – Le package RoboticBehavior La figure IV.30 donne une vue détaillée sur le package FSM. Evolution Model, conformément à sa description dans l’ontologie, est utilisé pour décrire le cycle de vie ou le comportement d’un composant (System). La méta-classe FSM hérite de 78IV.4 Conception de RobotML la méta-classe EvolutionModel. Une FSM est un automate composé d’états et de transitions. Ce package est fortement inspiré de la spécification des machines à états du méta-modèle d’UML. Les états représentent les actions que le robot doit effectuer. Nous distinguons les états initiaux des étaux finaux dans les FSMs. L’état initial Initial State est le premier état visité lorsqu’une FSM est exécutée, il est typiquement utilisé pour effectuer les initialisations requises pour la FSM. L’état final Final State indique que l’exécution de la FSM est terminée. Les transitions (Transition) forment des liens entre les états de la FSM. Une transition a un état source incoming et un état destination outgoing. Une transition peut aussi avoir une GuardCondition et un évènement (Event). Les états et les transitions sont composés de FSM Activities spécifiant les actions à exécuter (méta-classe Effect) pendant un état ou lors d’une transition donnée. Figure IV.30 – Le package FSM Dans la section suivante, nous présentons la communication entre les différents composants d’une application. 4.1.1.3 La partie communication Cette partie doit permettre la spécification de la communication entre les composants à travers des ports et des connecteurs. Nous nous sommes inspirés des mécanismes de communication utilisés dans SmartSoft [82] et nous les avons adapté aux concepts décrits par l’ontologie. La communication est réalisée à travers un échange synchrone ou asynchrone de données ou des appels de service. La figure IV.31 décrit les ports d’un composant. La méta-classe Port représente un point d’intéraction du système. On distingue deux sortes de ports : 79Chapitre IV. Robotic Modeling Language (RobotML) – Les ports de données DataFlowPort qui permettent la communication à travers des flots de données entre les composants. La méta-classe DataFlowPort a pour type un DataType et possède un attribut direction = {In, Out, InOut} qui spécifie le sens de l’échange de données et un attribut bufferSize qui définit la taille du buffer où les données sont enregistrées. La direction des ports est l’un des exemples de l’union des concepts des plateformes cibles que nous avons évoqué lorsque nous avions parlé de l’extraction des abstractions pertinentes dans le DSML. En effet, la direction InOut n’est pas présente dans toutes les plateformes cibles. Cependant, interdire sa représentation au niveau du DSML engendrerait des contraintes pour l’utilisation des plateformes qui prennent en charge ce concept. – Les ports de service ServicePort qui sont spécifiques à la communication client/serveur. La méta-classe ServicePort a un attribut serviceKind qui indique si le port est fourni ou requis. Un ServicePort a pour type une interface qui définit un ensemble d’opérations abstraites. La méta-classe CommunicationPolicy spécifie le type de communication utilisé (attribut synchronizationPolicy= {Synchrone/Asynchrone}) et la stratégie employée par le buffer (attribut strategyPolicy= {FIFO, LIFO}). Figure IV.31 – Les mécanismes de communication 4.1.2 Le profil RobotML Le profil RobotML définit des extensions des méta-classes du méta-modèle UML afin de les adapter aux concepts identifiés dans le modèle de domaine RobotML. 80IV.4 Conception de RobotML L’objectif de notre démarche est de pouvoir définir un éditeur graphique avec Papyrus [61] qui se base sur le profil RobotML et qui permet de manipuler les concepts identifiés à travers des modèles de scénarios de robotique. Pour définir le profil, les abstractions identifiées dans les parties représentées dans le modèle de domaine RobotML ont été reprises pour étendre les méta-classes d’UML. Le profil comporte alors trois parties principales conformément au modèle de domaine RobotML : architecture, communication et contrôle. Dans la partie architecture du profil, la méta-classe System et toutes les méta-classes qui la spécialisent sont transformées en stéréotypes qui étendent la méta-classe Class du méta-modèle UML comme le montre la figure IV.32. Les propriétés des métaclasses de RobotML comme par exemple les méta-classes RoboticSystem, Robot et Software sont transformées en tagged values des stéréotypes RoboticSystem, Robot et Software du profil. Figure IV.32 – Extrait de la partie Architecture : Stéréotypes extensions de la métaclasse Class d’UML Concernant la partie communication, la méta-classe Port du modèle de domaine RobotML et toutes les classes qui la spécialisent sont également transformées en stéréotypes qui étendent la méta-classe Port du méta-modèle UML comme le montre la figure IV.33. Les propriétés des méta-classes ServicePort et DataFlowPort du modèle de domaine RobotML sont définies comme des tagged values des stéréotypes ServicePort et DataFlowPort du profil. De la même façon, les méta-classes de RobotML représentant les aspects qui relèvent du contrôle ont été représentés à travers des stéréotypes qui étendent les méta-classes définissant les machines à états dans le méta-modèle UML (State, Transition, etc.) comme le montre la figure IV.34 pour les stéréotypes State et Transition. Concernant la méta-classe Algorithm de RobotML, elle est définie comme un stéréotype qui étend la méta-classe Operation du méta-modèle UML. 81Chapitre IV. Robotic Modeling Language (RobotML) Figure IV.33 – Extrait de la partie communication : Stéréotypes extensions de la métaclasse Port d’UML Figure IV.34 – Extrait de la partie Control : Stéréotypes extensions des méta-classes du méta-modèle d’UML Chaque stéréotype du profil que nous défini peut avoir une icône associée pour sa représentation graphique. Nous allons présenter dans ce qui suit l’éditeur graphique de RobotML. 4.2 Syntaxe concrète : L’éditeur graphique de RobotML L’éditeur graphique de RobotML a été conçu en utilisant l’outil Papyrus [61]. Afin de définir l’éditeur graphique, des icônes peuvent être rattachées graphiquement aux stéréotypes du profil de RobotML. Selon la sémantique d’utilisation l’une des icônes est affichée. La partie gauche de la figure IV.35 montre les icônes attachées aux stéréotypes SensorSystem, ActuatorSystem, DataFlowPort et ServicePort. Ces icônes sont ensuite représentées dans la palette (partie droite de la figure). Les stéréotypes SensorSystem, ActuatorSystem ont une seule icône attachée qui représente un capteur ou un effecteur. Le stéréotype DataFlowPort a trois icônes attachées, chacune 82IV.4 Conception de RobotML correspond à un type de DataFlowPort selon la direction utilisée {In, Out, InOut}. Le stéréotype ServicePort n’a que deux états possibles {Required, Provided}, chacun d’entre eux a une icône qui lui correspond. Figure IV.35 – À gauche, les icônes attachées aux stéréotypes, à droite la palette montrant les différentes icônes En plus des icônes, il est possible d’associer un ensemble de stéréotypes à des diagrammes dédiés à une représentation d’une partie du modèle. Plusieurs diagrammes sont proposés comme le montre la figure IV.36. Le model Explorer contient les élé- ments du modèle représentés à travers les différents diagrammes. Le diagramme de définition des composants permet de représenter les composants d’une application ainsi que les capteurs et les effecteurs. Le diagramme de machine à états et la palette qui lui est associé contient les concepts State, Final State, Initial State et Transition. La vue Properties permet de spécifier les propriétés des éléments du modèle. À partir des modèles représentés avec cet éditeur graphique on peut générer du code exécutable vers une ou plusieurs plateformes cibles. La section suivante présente la génération de code vers le middleware OROCOS. 83Chapitre IV. Robotic Modeling Language (RobotML) Figure IV.36 – Environnement de modélisation de RobotML 5 Intégration du middleware OROCOS : génération de code Les concepts de RobotML étant définis à partir de l’état de l’art sur les middlewares et les simulateurs et d’une ontologie de la robotique, regroupent l’union des concepts identifiés dans les plateformes cibles ainsi que des abstractions du domaine. Par exemple, les ports d’entrée sortie présentés précédemment : le concept InOutPort n’est pas présent dans toutes les plateformes. Nous l’avons représenté dans le modèle du domaine car nous avons fait le choix de ne pas imposer de restrictions sur les concepts des plateformes. Ainsi il est possible de représenter les plateformes qui utilisent ce concept. La génération de code permet de founir à partir d’un modèle de scénario une application exécutable facilitant ainsi le développement des applications de robotique. Les plateformes cibles des générateurs peuvent évoluer mais les abstractions que nous avons utilisées sont suffisamment stables pour supporter cette évolution à court terme. En d’autres termes, le développement des générateurs de code définis à partir de RobotML est un processus plus rapide que l’évolution des plateformes cibles. Bruyninckx et al. [3] ont argumenté le fait qu’ils ne pouvaient pas intégrer leur approche de la séparation des responsabilités à leur méta-modèle (voir figure III.8) par le fait que les plateformes cibles se basaient sur des architectures stables qui ne vont pas évoluer vers d’autres architectures. Ainsi, la définition des générateurs de code faciliterait le développement des appli- 84IV.5 Intégration du middleware OROCOS : génération de code cations de robotique et permettrait d’accélérer le processus de développement. La première étape pour l’intégration des plateformes cibles est d’établir des règles de correspondance entre les éléments du DSML et les plateformes cibles. Grâce au respect de RobotML des exigences du domaine et de celles des middleware et des simulateurs de robotique, il est possible d’établir des règles de transformations à partir de RobotML vers plusieurs plateformes hétérogènes. Dans le cadre du projet PROTEUS, plusieurs générateurs de code ont été réalisés vers : OROCOS-RTT[47], RTMaps[113], Urbi [114] et Arrocam [115] et les simulateurs MORSE [116] et CycabTK [117]. Notre approche se base sur les techniques de la MDA présentées précédemment à l’exception que notre PSM est le code. Nous utilisons une API commune implantée qui permet d’interroger les éléments du modèle. En se basant sur cette API commune, chaque générateur définit les règles de transformation vers sa plateforme cible en utilisant l’outil Acceleo [67]. Le middleware ROS a joué un rôle important dans le développement des générateurs de code. Étant donné qu’il a été intégré aux plateformes cibles prises en charge par RobotML, nous utilisons les topics ROS pour l’échange des données entre les composants générés vers des plateformes hétérogènes. Nous présentons dans cette section le générateur de code OROCOS-RTT qui définit des transformations de modèle vers texte à partir de RobotML. Le générateur de code a été implanté en utilisant Acceleo. OROCOS (Open RObot COntrol Software) est un framework temps-réel à base de composants C++ [47], appelé aussi OROCOS-RTT (Real-Time Toolkit) pour son aspect temps-réel. Les composants OROCOS intéragissent par un échange de données, d’évènements ou de services à travers des ports. L’échange de données est effectué par des data flow ports d’entrée/sortie, les événements indiquent un changement dans le système et l’échange de services est effectué à travers des simples appels de méthodes. Les composants OROCOS peuvent être définis sous forme de machine à états finis hiérarchiques. 5.1 Génération du squelette d’un composant Le tableau IV.6 montre la correspondance entre les concepts du DSL architecture décrivant les concepts relavant de la structure globale d’un composant et les 85Chapitre IV. Robotic Modeling Language (RobotML) Concepts de RobotML concepts d’OROCOS Property Task Context Attribute Attribute Port – Primitive DataType C++ types Composed DataType Data structure Interface Abstract class Attribute Attribute Interface Operation Virtual Method Operation Operation Parameter Parameter Table IV.6 – Correspondance entre le DSL Architecture et les concepts d’OROCOS concepts d’OROCOS. Les composants OROCOS héritent de l’interface TaskContext et possèdent des propriétés et des threads d’exécution. Concernant les interfaces, elles sont géné- rées comme des classes abstraites ayant des méthodes virtuelles. Ces méthodes sont Concernant les Data Types, les Primitive DataTypes sont transformés en types C++. Concernant les types ComposedDataTypes ils sont générés comme des structures de données. 5.2 Génération de la communication entre les composants Concepts de RobotML concepts d’OROCOS Data Flow Port direction {In} Input Port Data Flow Port direction {Out} Output Port Service Port {Provided } this->provides(Operation) Service Port {Required} this->requires(OperationCaller) Table IV.7 – Correspondance entre le DSL Communication et les concepts d’OROCOS Les composants échangent les données et les appels de service à travers des ports de données (DataFlowPort) et des ports de service (ServicePort). Selon leurs directions, les ports de données sont transformés en InputPort ou en OutputPort comme le montre le tableau IV.7. Les ports de service, quant à eux, sont transformés en ServicePort qui fournissent ou requièrent une opération. Si le service est requis, le composant fait appel à l’opération définie dans l’interface à travers le mot clé OperationCaller en précisant le type de l’opération et ses paramètres. Dans le cas contraire (c.-à-d. si le service est fourni), le composant implémente l’opération en 86IV.5 Intégration du middleware OROCOS : génération de code question et indique qu’il la fournit en utilisant la méthode provides. L’échange de données à travers les composants est effectué à travers des ports de données. RobotML fournit un ensemble de types communément utilisés en robotique (Composed DataType) sous forme de bibliothèques. Ces bibliothèques permettent de réutiliser ces types sans avoir à les redéfinir à chaque fois. Selon la nature de ces composants et le plan de déploiement, les types de ces ports sont générés : – Si le composant est un composant de contrôle (System) et est connecté à d’autres composants de contrôle déployés sous le même middleware alors les types de ses ports sont les types indiqués dans le modèle. – Si le composant est un composant de contrôle et est connecté à un autre composant déployé sous un autre middleware alors le type de ses ports est traduit en type ROS. – Si le composant est un composant matériel (c.-à-d. capteur ou effecteur) alors les types de ses ports seront traduits en types ROS. – Si le composant est composant de contrôle et est connecté à un composant matériel alors les types de ses ports seront traduits en types ROS. Les bibliothèques définissant les types utilisés par les propriétés ou les ports d’un composant sont automatiquement importées dans le fichier source du composant. La connexion entre les composants est configurée dans un script OPS (OROCOS Program Script) qui permet la spécification de la périodicité, du type de communication entre les composants (ROS ou CORBA) comme le montre le tableau IV.8. Le plan de déploiement intervient également pour cette configuration. Une distinction est effectuée entre la communication inter-composants du même middleware (mot clé connectPeers) pour indiquer que la communication va s’appuyer sur CORBA. Autrement, le mot clé stream est utilisé pour spécifier que la connexion se fait entre des composants de natures différentes et que ROS sera utilisé. 5.3 Génération du comportement d’un composant Chaque composant a un comportement décrit en utilisant une machine à états finis (FSM) ou un algorithme. Les FSMs peuvent être définies grâce au package rFSM 2 intégré à OROCOS. Il permet la définition de scripts en Lua [118] puis de 2. http://people.mech.kuleuven.be/~mklotzbucher/rfsm/README.html#sec-1 87Chapitre IV. Robotic Modeling Language (RobotML) Concepts de RobotML Fichier OPS Communication Policy setActivity("ComponentA", period, priority, scheduler) setActivity("ComponentB", period, priority, scheduler) loadComponent("ComponentA", "A") loadComponent("ComponentB", "B") Connector var connPolicy x ; (composants homogènes) x.type = DATA ; //DATA = 0, BUFFER = 1 x.size = 1 ; //size of the buffer x.lock_policy = LOCK_FREE ; //UNSYNC = 0, LOCKED = 1, LOCK_FREE = 2 x.transport = 3 ; //ROS = 3 stream("componentA", x) Connector connectPeers("ComponentA", "ComponentB") (composants hétérogènes) Table IV.8 – Correspondance entre le DSL Communication et les concepts d’OROCOS les charger par les composants OROCOS. La tableau IV.9 décrit la correspondance entre les concepts de RTT-Lua et les concepts de RobotML. Concepts de RobotML concepts d’OROCOS State Machine StateMachine Initial State initial state{ entry{} run{} exit{}} Final State final state{ entry{} run{} exit{}} State state{ entry{} run{} exit{}} Transition rfsm.transition {src="InitialState", tgt="state1" Event ,events{} Guard ,guard=function() end Effect ,effect=function() end } Table IV.9 – Correspondance entre le DSL Contrôle et les concepts d’OROCOS La correspondance entre les états est triviale. Les gardes et les effets sur les transitions sont des fonctions dont le corps est défini par l’utilisateur à travers un stéréotype d’UML appelé OpaqueBehavior. À la génération, ces fonctions sont capturées à partir du modèle et injectées à la place de la balise . Un exemple de requête permettant de récupérer les transitions définies dans une machine à 88IV.5 Intégration du middleware OROCOS : génération de code états du modèle est donné dans le listing IV.6. Cette requête retourne un ensemble de transition (sequence(Transition) et fait appel à la fonction getTransitions(org.eclipse.uml2.uml.StateMachine) du template Acceleo FSMQueries. [ query public getTransitions ( sm : StateMachine ) : Sequence ( Transition ) = invoke ( ’ org . eclipse . robotml . generators . acceleo . mmqueries . FSMQueries ’ , ’ getTransitions ( org . eclipse . uml2 . uml . StateMachine ) ’ , Sequence { sm }) /] Listing IV.6 – Requête pour récupérer les transitions d’une machine à états D’autres requêtes sont également utilisées pour générer le code d’une machine à états. Un extrait d’un tempate Acceleo définissant les règles de transformation pour chaque requête sur les transitions, leurs gardes et leurs effets sont présentées dans listing IV.7. Pour chaque transition on récupère à partir des triggers qui lui sont associés les guards et les opérations qui leur sont associés (lignes 13 - 23) ainsi que les effets (lignes 24 - 34). 1 [ l e t t r a n s i t i o n s : S equ en c e (RobotML : : T r a n s i t i o n ) = g e t T r a n s i t i o n s ( fsm ) ] 2 [ fo r ( t r a n s i t i o n : RobotML : : T r a n s i t i o n | t r a n s i t i o n s ) ] 3 r fsm . t r a n s i t i o n { s r c=" 4 ␣␣␣␣ ␣ [ t r a n s i t i o n . b a s e_T r a n s i t i o n . s o u r c e . name / ] " , 5 t g t=" [ t r a n s i t i o n . b a s e_T r a n s i t i o n . t a r g e t . name / ] " 6 [ i f ( h a s T r i g g e r s ( t r a n s i t i o n . b a s e_T r a n s i t i o n ) ) ] 7 , e v e n t s={ 8 [ fo r ( t r i g : T r i g g e r | t r a n s i t i o n . b a s e_T r a n s i t i o n . t r i g g e r ) ] 9 ’ [ t r i g . name / ] ’ 10 [ / fo r ] 11 } 12 [ / i f ] 13 [ i f ( t r a n s i t i o n . guard <> nu l l ) ] 14 [ l e t guard : RobotML : : A lgor ithm = t r a n s i t i o n . guard ] 15 , guard=f u n c t i o n ( ) 16 [ l e t op : Op e r a t i on = g e tA s s o c i a t e dO p e r a t i o n ( guard . bas e_Op erat ion ) ] 17 [ fo r ( o : OpaqueBehav ior | g etOp erat ionM ethod ( op ) ) ] 18 [ o . _body / ] 19 [ / fo r ] 20 [ / l e t ] 21 end 22 [ / l e t ] 23 [ / i f ] 24 [ i f ( t r a n s i t i o n . e f f e c t <> nu l l ) ] 25 [ l e t e f f e c t : RobotML : : A lgor ithm = t r a n s i t i o n . e f f e c t ] 26 , e f f e c t=f u n c t i o n ( ) 27 [ l e t op : Op e r a t i on = g e tA s s o c i a t e dO p e r a t i o n ( e f f e c t . bas e_Op erat ion ) ] 28 [ fo r ( o : OpaqueBehav ior | g etOp erat ionM ethod ( op ) ) ] 29 [ o . _body / ] 30 [ / fo r ] 31 [ / l e t ] 32 end 33 [ / l e t ] 34 [ / i f ] 35 } , 36 [ / fo r ] 37 [ / l e t ] Listing IV.7 – Template de génération des transitions des machines à états vers OROCOS 89Chapitre IV. Robotic Modeling Language (RobotML) Nous avons implanté des templates définissant des règles de transformation pour tous les éléments du modèle vers du code OROCOS. Le but du générateur OROCOS consiste à fournir une application compilable et exécutable. Pour ce faire, un ensemble d’artefacts est également généré notamment : – un fichier makefile – un fichier CMakeLists.txt spécifiant le chemin des composants à charger pour l’application ainsi leurs noms. – un fichier manifest.xml spécifiant les librairies à importer pour l’application. Pour résumer, le générateur de code OROCOS prend en entrée le modèle représenté avec les outils de RobotML et fournit un ensemble de fichiers correspondants aux concepts de notre DSML comme le montre la figure IV.37. Figure IV.37 – Génération de code avec OROCOS 6 Utilisation : chaîne d’outillage RobotML Afin de valider notre DSML sur des exemples industriels, plusieurs scénarios (appelées challenges) ont été proposés dans le cadre du projet PROTEUS. RobotML fournit une chaîne d’outillage pour le développement des applications de robotique allant de la modélisation jusqu’à la génération de code et le déploiement vers des simulateurs ou des robots réels. L’utilisateur de RobotML commence par modéliser sa mission en représentant les types de données et les interfaces, les composants de contrôle et matériels, ainsi que 90IV.7 Validation et Expérimentations les connexions entre eux. Une fois le modèle validé, l’utilisateur définit un plan de déploiement qui consiste en un ensemble de middlewares et/ou de simulateurs inter-connectés pour former une plateforme d’exécution pour l’application finale. Chacun des composants définis doit être alloué vers une plateforme cible d’un modèle de déploiement. Typiquement, le système de contrôle du robot modélisé est généré vers un ou plusieurs middleware (selon le plan de déploiement défini). Quant aux capteurs, aux actionneurs et à l’environnement du robot, ils sont générés vers le simulateur choisi. De plus, l’utilisateur a la possibilité de réutiliser des composants déjà existants sur la plateforme qu’il souhaite en spécifiant leur chemin et leur nom. Dans ce cas, pour ce composant, seule sa connexion avec le reste des composants est générée. L’utilisateur peut maintenant générer du code exécutable à partir du plan de déploiement qu’il a défini. Figure IV.38 – Etapes de modélisation en utilisant RobotML 7 Validation et Expérimentations Pour réaliser la validation de RobotML et de la génération de code vers OROCOS, nous avons choisi d’utiliser l’un des scénarios proposés dans le cadre du projet 91Chapitre IV. Robotic Modeling Language (RobotML) PROTEUS par l’ONERA 3 appelé le scénario aérien (AIR OARP). 7.1 Scénario de l’AIROARP Le scénario Air OARP considère le problème de la planification pour la perception et la perception pour la planification d’un véhicule aérien sans pilote. Le sujet de recherche adressé par Air OARP concerne les questions en matière de planification de mouvement pour la recherche et le suivi d’une cible. La plateforme ReSSac sera utilisée afin de réaliser les différentes expérimentations de site Caylus. Le site Caylus est une zone rurale et légèrement urbanisée. La zone comprend des routes, des pistes, des arbres et des bâtiments. Certains bâtiments comme les granges et les hangars ont de grandes portes ouvertes. Certains intrus peuvent tenter de traverser la zone, de se cacher dans cette zone ou tenter de s’échapper quand ils sont détectés. L’objectif pourrait être alors de détecter, reconnaître, identifier, localiser et suivre les intrus. La surveillance d’une zone est incluse dans un carré avec 400 mètres de long bord et est réalisée en utilisant un véhicule aérien sans pilote (UAV). Quand un intrus est reconnu dans le domaine d’un appareil photo, l’objectif peut être de le garder dans le domaine aussi longtemps que possible. Dans la section suivante, nous montrons la modélisation de ce scénario avec RobotML. 7.2 Conception du scénario avec RobotML Nous commençons tout d’abord par présenter les différents types de données nécessaires pour ce scénario (voir figure IV.39). Le type State est un type utilisateur qui est défini par un numéro de phase, un compteur de trames, une altitude en baromètre, la vélocité et d’autres attributs qui spécifient l’état dans lequel se trouve le robot. Le type Image est un type utilisateur qui désigne l’image d’une caméra. Il est défini par une largeur, une longueur, un nombre de pixels et un attribut qui indique si cette image a une couleur ou non. Le type Waypoint est un type utilisateur qui indique les propriétés d’un point cible. Ce point a des coordonnées en 3 dimensions (m_x, m_y, m_z). Ce type permet aussi d’indiquer la direction que doit prendre le robot pour atteindre ce point ainsi que la vitesse d’approche pour aller à ce point. 3. http://www.onera.fr/ 92IV.7 Validation et Expérimentations Le type Way est un type qui spécifie le chemin du robot. Enfin, les types primitifs Double, bool, unsigned et char sont représentés. Figure IV.39 – Modèle des types de données AIR OARP Après les types des données, les interfaces ont été représentées avec RobotML (voir figure IV.40). L’interface ObcInterface est l’interface qui définit les actions du robot (par exemple : move, goTo, track et l’évolution de sa trajectoire dans son environnement (par exemple wayPointadd, wayPush, obstacleAdd). L’interface CameraInterface définit les opérations relatives aux images perçues par la caméra du robot (par exemple setBrighteness, setGain, etc.). Après avoir défini les types et les interfaces qui définissent les services que les composants vont s’échanger, les composants de l’application sont maintenant repré- sentés. Le composant Obc du package AvionicSystem prend en entrée les informations des capteurs de localisation afin de récupérer les informations sur l’état du robot en implémentant les opérations de l’interface ObcInterface. Le composant m_talc_cam_driv (voir figure IV.42) est un driver qui transforme les données physiques envoyées par la caméra en données de type Image (le type utilisateur défini). Ce composant implémente aussi les opérations de l’interface CameraInterface. Ces deux composants envoient ensuite l’état du robot et l’image perçue au composant RMaxControlSystem qui va décider de l’action à effectuer. Les opérations des 93Chapitre IV. Robotic Modeling Language (RobotML) Figure IV.40 – Les interfaces du scénario AIR OARP Figure IV.41 – Le composant AvionicSystem deux interfaces ObcInterface et CameraInterface sont des services requis par le composant de contrôle principal RMaxControlSystem. Dans la section suivante, nous présenterons la génération de code vers le middleware OROCOS. 7.3 Génération de code vers OROCOS La génération de code comme nous l’avons présentée précédemment permet de générer pour chaque concept de RobotML le code associé. Les interfaces et les types de données ont été traduits en structures de données définissant leurs propriétés et leurs opérations. Les composants représentés ont été traduits en composants OROCOS. Les interactions entre eux sont tranduites par des propriétés au niveau des fichiers de configuration ainsi qu’au niveau des ports. Enfin pour le composant de contrôle RMaxControlSystem, nous avons généré une 94IV.8 Discussion Figure IV.42 – Le composant CameraSystem Figure IV.43 – Modèle du scénario AIR OARP machine à états finis. Les résultats de cette génération de code sont disponibles sur la page 4. 8 Discussion L’objectif principal de RobotML est de fournir aux roboticiens un langage dédié qui facilite le développement de leurs applications et qui répond aux exigences du domaine. Dans ce contexte, un ensemble d’exigences a été défini dans 4.1. RobotML a apporté une réponse à ces exigences : 1. Facilité d’utilisation. Grâce à RobotML, les utilisateurs du DSL peuvent modéliser leurs applications sans avoir à connaître ou à maîtriser les lanagages 4. https://github.com/RobotML/RobotML-documentation/blob/master/ RobotMLCodeGenerators/OROCOSGenerator/index.rst 95Chapitre IV. Robotic Modeling Language (RobotML) de programmation des plateformes de robotique. En effet, les détails des plateformes sont masqués pour les utilisateurs du DSL et les concepts utilisés dans RobotML sont basés sur une ontologie définie par des experts de la robotique. 2. Spécification d’une architecture à base de composants. L’architecture utilisée est une architecture à base de composants de contrôle et matériels. 3. Spécification des comportements des composants. RobotML permet la spécification du comportement des composants à travers des machines à états finis ou des algorithmes. 4. Neutralité vis à vis des architectures de robotique. La plupart des plateformes de robotique sont basées sur une architecture à base de composants. C’est pour cette raison que RobotML n’est spécifique à aucune autre architecture (délibérative, réactive ou hybride). N’importe quelle architecture peut donc être définie avec RobotML. 5. Plusieurs plateformes cibles hétérogènes. En raison de la distinction de la nature des composants au niveau de la modélisation (matériel ou contrôle) et de la possibilité de spécifier un plan de déploiement, il est possible de gé- nérer du code vers plusieurs plateformes hétérogènes. Lorsqu’il s’agit de faire interopérer ces plateformes hétérogènes (c.-à-d. : un middleware et un simulateur ou plusieurs middlewares) la communication s’appuie sur les messages ROS (automatiquement pris en charge par les composants générés) en raison de son intégration dans la plupart des plateformes de robotique actuelles. 6. Indépendance vis à vis des plateformes cibles. Grâce à l’ontologie du domaine, les concepts de RobotML sont abstraits et se basent sur la terminologie du domaine. Cependant, ces concepts correspondent aussi aux plateformes cibles sans être spécifiques à une plateforme particulière. Il n’y a pas de restriction imposée par une plateforme. 7. Prise en charge de l’évolution des plateformes Etant donné que le DSML est indépendant des détails des plateformes cibles, l’évolution des plateformes cibles n’affecte pas le modèle de domaine RobotML. Cette évolution pourrait cependant avoir un impact sur les générateurs. Notons quand même que le temps de développement des générateurs est moins important que l’évolution des plateformes cibles). 96IV.9 Conclusion 8. Evolution du DSL. RobotML est défini de manière itérative à partir d’exemples exécutables. Cette approche a été combinée avec une approche complémentaire top-down à partir d’une ontologie du domaine de la robotique définissant des concepts précis. L’évolution du DSL est considérée comme un processus intégré et incrémental au processus du développement. Dans certains cas, une absence de correspondance entre le modèle de domaine et les plateformes cibles a été constaté. Dans ce cas, ce concept est ajouté au DSL et des nouvelles règles de transformation sont définies pour la génération de code. Par exemple, nous avons constaté que l’utilisateur doit être capable de spécifier la taille du buffer pour l’échange de données entre les composants au niveau de la modélisation. Un nouvel attribut a alors été ajouté à la méta-classe CommunicationPolicy de RobotML. 9. Abstraction du matériel Les types Physical Data permettent de définir des abstractions à partir du matériel. Cependant, ils représentent des abstractions générales et n’ayant pas de sémantique précise. C’est pour cette raison qu’ils ont été définis au niveau du modèle du domaine et pas implémentés dans la syntaxe concrète de RobotML. La validation de RobotML et du générateur de code OROCOS a été effectuée sur le scénario AIR OARP que nous présenterons dans le chapitre suivant. 9 Conclusion Nous avons présenté dans ce chapitre notre DSML pour la robotique : RobotML. Les concepts de RobotML sont des concepts du domaine définis par des experts en robotique. Nous avons montré que ces concepts nous ont permis de représenter des scénarios de robotique indépendamment des plateformes d’exécution (middleware et simulateurs). RobotML offre également un ensemble d’outils qui visent à faciliter le développement des applications de robotique. Nous avons vu également que le modèle de domaine RobotML propose des types abtraits, extraits de l’ontologie, appelés PhysicalData afin d’abstraire les données des capteurs (voir IV.23). Cependant, ces types n’ont pas de sémantique d’utilisation précise car ce sont des abstractions a priori qui n’ont pas été définies à partir d’exemples concrets. Il faudrait établir un certain nombre d’itérations à partir d’exemples concrets afin de 97Chapitre IV. Robotic Modeling Language (RobotML) convenir d’un ensemble d’abstractions ayant une sémantique bien définie et pouvoir les intégrer éventuellement à l’ontologie. Par conséquent, les méta-classes de PhysicalData n’ont pas été étendues par le profil UML et ne sont donc pas visibles pour le moment pour les utilisateurs de RobotML. Nous nous proposons alors dans le chapitre suivant de présenter une démarche, qui pourrait compléter l’ontologie, avec des abstractions définies a posteriori (c.-à- d. après une étude détaillée d’un exemple de tâche de robotique). 98Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique 1 Introduction Les roboticiens sont confrontés à plusieurs difficultés pour le développement de leurs applications. La principale difficulté concerne la maîtrise des détails du matériel du robot. En effet, l’implantation d’une tâche de robotique requiert des informations sur les moyens de locomotion du robot, sa morphologie et ses capteurs. Implanter une tâche de robotique qui marcherait pour tous les moyens de locomotion et qui tiendrait compte des entrées de tous les capteurs est un processus très complexe [45]. Il faudrait au moins utiliser des abstractions comme celles proposées par les middleware ou celles proposées par l’ontologie de RobotML. Cependant, les abstractions proposées par les middleware sont de bas niveau. Il est très difficile de les appliquer dans le cas où l’on souhaite développer une application pour un robot de forme inconnue, dont les capteurs sont inconnus et où les moyens de locomotion le sont aussi. En effet, toutes ces informations doivent être connues afin de calculer les données des capteurs et exécuter les mouvements du robot [45]. D’autre part, les abstractions proposées par l’ontologie du domaine représentent des concepts du domaine [69] définis a priori et non à partir d’exemples concrets. Par conséquent, ces abstractions sont insuffisantes et n’ont pas de sémantique opérationnelle précise à savoir qu’on ne sait pas forcément comment les implanter dans un programme. 99Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique Une autre difficulté peut être soulevée lorsqu’il s’agit d’une tâche de robotique où plusieurs stratégies visent à atteindre un même objectif en se basant sur les mêmes hypothèses sont définies comme la famille de navigation Bug [38]. Il s’agit alors de variabilité algorithmique. Il est difficile de comparer les variantes d’une famille ou même de les comprendre car elles sont proposées par différents auteurs dans la littérature et sont souvent implantées sous différentes plateformes. Si on pouvait définir un algorithme générique pour les variantes d’une famille d’algorithmes, il serait plus facile de les comprendre, de les implanter et plus significatif de les comparer entre elles. À notre connaissance, très peu de travaux se sont intéressés à la gestion de ce type de variabilité. Brugali et al. [119] ont proposé une ligne de produits logicielle pour la gestion de la variabilité au sein des tâches de robotique telles que la localisation, la navigation et l’évitement d’obstacles. Cependant, leurs composants sont interdépendants. En d’autres termes, ils sont spécifiques à un type de capteur en particulier : le capteur Laser. Leur implantation se base sur des messages ROS ce qui reste spécifique aux types fournis par ce middleware. Afin de faciliter le développement des applications de robotique et les rendre résistantes aux différents types de variabilité cités précédemment, il faudrait alors définir des abstractions qui soient : 1. de plus haut niveau que celles proposées par les middleware : qui encapsulent les mesures et les données retournées par les capteurs et les commandes spé- cifiques des effecteurs 2. plus précises que celles proposées par l’ontologie : elles doivent avoir une sé- mantique opérationnelle Ces abstractions masqueraient alors les détails non algorithmiques et pourraient varier indépendamment des algorithmes. Concernant les détails algorithmiques dans le cas où il s’agit d’une famille d’algorithmes, il faudrait également définir des abstractions qui masquent la variabilité au sein d’une même famille. Dans cette optique, nous proposons une approche top-down qui, à partir de la description d’une tâche de robotique et des hypothèses sur l’environnement et sur les capacités du robot, produit : – un ensemble d’abstractions non algorithmiques ainsi que des abstractions algorithmiques 100V.2 Approche pour la gestion de la variabilité dans les algorithmes de robotique – un algorithme générique défini en fonction de ces abstractions L’intervention d’un expert de robotique est requise pour l’identification de ces abstractions et leur combinaison pour définir un algorithme générique de façon analogue à un planificateur. Les hypothèses définies sur les capacités du robot ne doivent pas être liées à des capteurs ni à des effecteurs spécifiques. Elles doivent plutôt se baser sur les données requises par l’algorithme. L’expert définit donc des abstractions comme étant des requêtes sur l’environnement et des actions de plus haut niveau que les commandes spécifiques aux effecteurs. Dans ce chapitre, nous présentons notre approche pour l’identification de ces abstractions et d’un algorithme générique défini en fonction de ces dernières. Nous proposerons ensuite une démarche pour implanter les abstractions ainsi que l’algorithme générique. Nous appliquerons ensuite notre approche sur une famille d’algorithmes de navigation appelée Bug [38]. 2 Approche pour la gestion de la variabilité dans les algorithmes de robotique À partir d’une tâche de robotique, notre approche permet de produire un algorithme générique configurable en fonction d’un ensemble d’abstractions qui masquent les détails du matériel et les détails algorithmiques. Une fois l’algorithme générique défini, nous proposons une démarche pour l’implantation de ces abstractions et de l’algorithme générique de façon à faire varier l’implantation de ces abstractions sans avoir à modifier l’implantation de l’algorithme générique. Nous présentons dans cette section les différentes étapes de notre approche. 2.1 Identification des abstractions La forme des robots varie d’un robot à l’autre ce qui affecte le fonctionnement des capteurs surtout s’ils sont placés sur celui-ci comme les capteurs à rayons (range sensors). Le nombre, la nature et la position de ces capteurs varient aussi d’un robot à l’autre. Un capteur Laser a un angle de perception, les Infrarouges ont des rayons de perception, etc. Les capteurs tactiles ont un autre mode de fonctionnement mais permettent d’indiquer par exemple si un obstacle est détecté tout comme les cap- 101Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique teurs à rayons mais avec un mode de fonctionnement différent. Nous avons vu que certains middleware ont défini des interfaces pour les range sensors par exemple. Leurs abstractions sont liées aux types des capteurs. Nous avons mentionné précédemment que les abstractions que nous voulons définir sont de plus haut niveau que celles proposées par les middleware et ont une sémantique par rapport à celles proposées par l’ontologie du domaine et donc RobotML. Les abstractions dans ce travail permettent d’encapsuler les détails impertinents dans l’algorithme représentant la tâche à développer. Nous distinguons deux types d’abstractions : algorithmiques et non algorithmiques, nos définitions sont les suivantes : Definition 11 (Abstraction non algorithmique). Une abstraction non algorithmique est soit une requête qui retourne des informations sur l’environnement y compris le robot soit une action de haut niveau que le robot doit effectuer. Definition 12 (Abstraction algorithmique). Une abstraction algorithmique est liée à la tâche à développer. Elle peut encapsuler un ensemble d’instructions permettant de réaliser une sous-tâche ou des détails liés aux variantes d’un algorithme lorsqu’il s’agit d’une famille d’algorithmes. Les abstractions non algorithmiques sont des abstractions qu’on peut capitaliser car elles sont indépendantes des détails algorithmiques d’une tâche. Les abstractions algorithmiques, quant à elles, peuvent dépendre des abstractions non algorithmiques mais restent spécifiques à la tâche à développer. Lorsqu’il s’agit d’abstractions non algorithmiques, on peut distinguer deux cas : 1. L’abstraction est une requête sur l’environnement y compris le robot. Dans ce cas, cette requête indique par exemple si le robot est face à un obstacle, s’il perçoit de la lumière, etc. Les paramètres de configuration de cette requête sont spécifiés au niveau de leur implantation. 2. L’abstraction est une action de haut niveau permettant au robot d’agir dans son environnement. Cette action peut être simple comme l’action avancer ou composée d’actions simples comme suivre un obstacle dans une direction donnée. Les variables permettant de spécifier la vitesse ou la direction que doit suivre une action sont passées en paramètres à celle-ci. 102V.2 Approche pour la gestion de la variabilité dans les algorithmes de robotique Concernant les abstraction algorithmiques, elles sont de plus haut niveau que les abstractions non algorithmiques. Elles font appel à des actions et à des requêtes sur l’environnement afin d’effectuer une sous-tâche de la tâche à implanter. De notre point de vue, l’identification des abstractions ne nécessite pas de connaissances approfondies des capteurs ou des effecteurs physiques d’un robot particulier comme la démarche adoptée par les middleware. Cette étape requiert une connaissance de la tâche à développer d’où l’intervention d’un expert du domaine. Notre approche s’appuie sur la description d’une tâche de robotique ce qui permet de définir des hypothèses sur l’environnement et sur les capacités que doit avoir un robot pour qu’il puisse exécuter cette tâche. À partir de la description d’une tâche, un expert en robotique peut identifier des fonctionnalités que le robot doit effectuer en se basant par exemple sur une démarche dirigée par les buts. Ces fonctionnalités font appel à des actions, lancent des requêtes sur l’environnement et effectuent des traitements sur les données récupérées afin de se rapprocher de l’état but de la tâche à réaliser. Les requêtes sur l’environnment définissent par conséquent la catégorie des capteurs à utiliser. Par exemple, dans une tâche de navigation, l’une des fonctionnalités du robot consiste à éviter les obstacles rencontrés. Il faut que le robot soit capable de détecter cet obstacle. On peut donc définir des hypothèses sur les capacités du robot à indiquer la présence d’un obstacle dans son champs de perception. Ces requêtes pourront ensuite être appliquées sur des capteurs de distance ou de contact par exemple. Concernant les actions de haut niveau, elles sont également liées à la description de la tâche. Si par exemple le robot doit avancer ou tourner dans un environnement terreste, il doit être équipé par des roues. Nous pouvons alors définir des hypothèses sur les moyens de locomotion requis pour l’accomplissement des actions. Une fois ces abstractions identifiées, l’expert du domaine combine ensuite les abstractions algorithmiques et les abstractions non algorithmiques afin de définir un algorithme générique. 2.2 Identification de l’algorithme générique Dans cette étape, un expert en robotique organise les abstractions identifiées précédemment. Un algorithme générique est une séquence d’instructions qui utilisent les abstractions non algorithmiques et les abstractions algorithmiques. Cette 103Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique combinaison se fait sous forme d’algorithme ou sous forme de machine à états finis représentant la tâche étudiée. Étant donné que les abstractions définissent des hypothèses sur les capacités du robot à percevoir ou à agir dans son environnement, l’algorithme générique reste stable pour une catégorie de robots. De cette façon, on peut faire varier les implantations des abstractions sans avoir à modifier l’algorithme générique. Pour une tâche de robotique donnée, on ne peut pas définir un algorithme générique qui restera stable pour toutes les catégories des capteurs et des effecteurs car il faut que ces derniers correspondent aux hypothèses définies sur les abstractions. Pour résumer, notre approche comporte deux étapes principales : 1. L’identification des abstractions 2. La définition de l’algorithme générique Dans ces deux étapes, un expert de robotique doit intervenir afin de combiner les abstractions ou les valider. Ainsi, les abstractions obtenues seront extraites à partir d’exemples concrets et pourront être réutilisées. Nous verrons dans la section suivante comment ces abstractions doivent être organisées au niveau de l’implantation. 2.3 Organisation de l’implantation L’algorithme générique défini en fonction des abstractions est complètement indé- pendant des détails des capteurs, des effecteurs et des middleware. Aucune propriété spécifique à un middleware ne doit être utilisée au sein de l’application qui implante l’algorithme générique (c.-à-d. protocole de communication, types spécifiques, etc.). On voudrait maintenant organiser l’implantation des abstractions non algorithmiques et des abstractions algorithmiques. Une abstraction a une sémantique opérationnelle bien définie. Elle peut avoir un type de retour, dans ce cas, le type de retour est un type abstrait (c.-à-d. indépendant des types retournés par le matériel et des types fournis par les middleware). Un type abstrait désigne un type primitif (booléen, entier, réel, etc.) ou un type de données ayant des propriétés dont les types sont primitifs. Par exemple, le type Point est un type abstrait. Il est caractérisé par trois coordonnées x, y et z de types réels. Comme nous l’avons défini précédemment, les abstractions algorithmiques sont de plus haut niveau que les abstractions non algorithmiques et dépendent généralement de celles-ci. Il est donc essentiel des faire varier les abstractions non algorithmiques 104V.2 Approche pour la gestion de la variabilité dans les algorithmes de robotique indépendamment des abstractions algorithmiques afin d’éviter les situations où on pourrait avoir une explosion combinatoire. Dans ce qui suit, nous présentons d’abord l’implantation des abstractions non algorithmiques puis l’implantation des abstractions algorithmiques et de l’algorithme générique. 2.3.1 Implantation des abstractions non algorithmiques Afin d’implanter les abstractions non algorithmiques, il faudrait tout d’abord rassembler les abstractions qui se basent sur le (ou les) même(s) capteur(s) physique(s) ou qui agissent sur le (ou les) même(s) effecteur(s) physique(s). Pour ce faire, nous nous proposons d’utiliser des adaptateurs des capteurs qui implantent les abstractions basées sur un ou plusieurs capteurs. L’implantation des abstractions au sein des adaptateurs permettra de convertir les données physiques capturées par les capteurs en données de types abstraits séparant ainsi l’acquisition des données de leurs traitements. Un adaptateur de capteur peut prendre en entrée différents capteurs pour calculer la donnée requise en sortie, dans ce cas il s’agit d’un adaptateur mixte. De la même façon, nous utiliserons des adaptateurs pour les effecteurs qui permettent d’implanter les actions du robot. L’implantation des actions consiste à spécifier les commandes que les effecteurs doivent exécuter. Pour résumer, les adaptateurs permettent d’implanter les abstractions du matériel en convertissant les données physiques en données abstraites ou en convertissant les actions en commandes spécifiques comme le montre la figure V.44. Notons que les adaptateurs sont les seules parties de l’application qui sont spé- cifiques aux capteurs et aux effecteurs physiques. Au niveau de l’implantation, il faut spécifier certains paramètres de configuration du matériel utilisé. Les seules informations requises par le code de l’application sont les abstractions. Il ne doit pas y avoir de lien permanent entre un adaptateur et le code de l’application. Ce lien ne doit être spécifié qu’au niveau de la configuration de l’application (c.-à-d. au niveau du déploiement) afin de rendre l’application la plus indépendante possible des détails du matériel et de permettre une flexibilité pour les changements de ce dernier. La fréquence d’exécution des composants, la nature des données requises (avec ou sans Buffer par exemple), le mécanisme de transport en particulier et plus généra- 105Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique Figure V.44 – Implantation des abstractions non algorithmiques : adaptateurs lement les paramètres de configuration sont délégués aux middleware. Chacun a un moyen de configuration propre à lui donc cette partie n’est pas spécifiée au niveau de l’implantation des abstractions mais au niveau du déploiement. Le design pattern Bridge [120] permet de séparer les abstractions de leurs implantations dans différentes hiérarchies de classes. Les abstractions sont définies dans une interface correspondant aux opérations qui doivent être fournies adaptateurs. Les adaptateurs implantent ensuite ces opérations comme le montre la figure V.45. L’avantage de cette approche est que le changement des implantations n’affecte pas le reste du code de l’application. De plus, les changements dans l’implantation des abstractions n’ont aucun impact sur le code de l’application. 2.3.2 Implantation des abstractions algorithmiques et de l’algorithme générique Prenons maintenant le cas d’une famille d’algorithmes qui a plusieurs variantes. Il faudrait alors définir des abstractions algorithmiques en plus des abstractions non algorithmiques. 106V.2 Approche pour la gestion de la variabilité dans les algorithmes de robotique Figure V.45 – Application du pattern Bridge Nous devons séparer l’implantation des abstractions non algorithmiques de l’implantation des abstractions algorithmiques. Afin d’organiser l’implantation de ces abstractions, nous nous proposons d’utiliser le design pattern Template Method. Le design pattern Template Method (TM) [120] permet la définition d’un squelette d’algorithme comme une template méthode d’une classe abstraite. Cette méthode n’est autre que l’algorithme générique identifié dans l’étape précédente. Les points de variations parmi les variantes d’une famille d’algorithmes sont définis en tant que méthodes abstraites, spécialisées dans chaque sous-classe. Les parties invariantes de l’algorithme sont implantées dans la classe abstraite en tant que méthodes concrètes. Les instructions qui existent dans certaines variantes et pas dans d’autres sont défi- nies en tant que hook methods (avec un corps vide dans la classe abstraite mais qui peut être spécialisé dans les sous-classes) de la classe abstraite. Par conséquent, Chaque variante de l’algorithme est implantée comme une sousclasse de la classe abstraite et les méthodes abstraites correspondant aux variabilités algorithmiques sont implantées dans chaque sous-classe comme le montre la figure V.46. Pour résumer, l’organisation de l’implantation combine les deux design pattern Bride et Template Method afin de séparer les abstractions non algorithmiques de celles algorithmiques. 107Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique Figure V.46 – Application du pattern Template Method 3 Application sur la famille d’algorithmes Bug En raison de la variabilité constatée dans les algorithmes de navigation, nous nous sommes intéressés à la famille de navigation Bug [38] où l’environnement du robot est inconnu mais la position du but est connue. Dans cette section, nous commençons d’abord par présenter la famille Bug, nous présenterons par la suite l’application de notre approche sur cette famille. 3.1 La famille d’algorithmes Bug Bug est une famille d’algorithmes de navigation dans un environnement inconnu. Le robot doit se déplacer de sa position de départ vers son but tout en évitant les obstacles sur son chemin vers celui-ci. Dans la famille Bug, le robot contourne les obstacles qu’il rencontre suivant diffé- rentes stratégies. Certains comportements du robot sont réactifs, par exemple, si un obstacle est détecté, le robot contourne l’obstacle. Si le but est atteint, le robot s’arrête, etc. D’autres comportements s’appuient sur des calculs un peu plus élaborés. Par exemple, le contournement de l’obstacle rencontré consiste à maintenir une distance de sécurité par rapport à celui-ci et à chercher un point potentiel pour quitter cet obstacle. Dans ce qui suit, nous donnons une description des algorithmes Bug. 1. Hypothèses sur l’Environnement : Environnement inconnu 2 dimensions : – Un obstacle est un chemin fermé de longueur finie et d’épaisseur non nulle (car l’une des variantes de cette famille utilise l’épaisseur des obstacles dans ses hypothèses). 108V.3 Application sur la famille d’algorithmes Bug – Il existe un nombre fini d’obstacles dans l’environnement 2. Hypothèses sur le robot : (a) Forme : Le robot est un point. (b) Perception : – capacité de détecter les obstacles : capteurs tactiles ou à rayons selon les algorithmes. – localisation parfaite. (c) Action : – s’orienter vers le but. – avancer vers le but. – contourner un obstacle. – s’arrêter. (d) Notations – Données en entrée : qstart, qgoal ; où qstart et qgoal sont respectivement la position de départ et du but du robot – Variables : – q i H , appelé hitPoint dans la littérature, est le point de rencontre d’un obstacle. – q i L , appelé leavePoint dans la littérature, est le point à partir duquel le robot peut quitter l’obstacle rencontré et se dirige de nouveau vers son but. – x est la position courante du robot – distance est la distance par rapport à l’obstacle le plus proche – distM inT oGoal est la distance euclidienne minimale du robot jusqu’au but. – Step épaisseur minimale d’un obstacle. – F = r(θ) est la distance perçue le long d’un rayon r émanant du centre du robot à un angle θ où θ est la direction du but. – direction est la direction du contournement d’obstacle du robot : dans le sens des aiguilles d’une montre (clockwise) ; contre les sens des aiguilles d’une montre (counter-clockwise). – dreach est la distance minimale parmi tous les points perçus par le robot. 109Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique – df ollowed est la distance minimale parmi tous les points autour d’un obstacle et le but. Nous présentons dans les sections suivantes six algorithmes de la famille Bug : Bug1, Bug2, Alg1, Alg2, DistBug et TangentBug. 3.1.1 Bug1 L’algorithme Bug1 [38, 121] est le premier algorithme proposé dans la famille Bug. La description de Bug1 est donnée dans l’algorithme 1. Bug1 se base sur des capteurs tactiles pour la détection d’obstacles. Lorsque le robot rencontre un obstacle, il contourne l’obstacle à gauche (en le maintenant à sa droite) tout en cherchant le point ayant la distance euclidienne minimale par rapport au but. Il effectue un tour complet autour de l’obstacle pour identifier le point optimal. Une fois ce point identifié, il y retourne et reprend son chemin vers le but. Si le but est inatteignable alors le robot s’arrête et termine sa mission. Algorithm 1: Bug1 pseudo-code [38, 121] Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles Input : Position de départ (qstart), Position du but (qgoal) Initialisation: Point q 0 L ← qstart ; int i ← 1 ; (1) A partir de q i L avancer vers le but jusqu’à ce que l’une de ces conditions soient satisfaites : qgoal atteint, Stop. Un obstacle est rencontré, i ← i + 1, q i H ← x, aller à l’étape (2). (2) Contourner l’obstacle à gauche tout en cherchant un point y autour de l’obstacle tel que : deuclidian (y, qgoal) est minimale. Si y trouvé, q i L ← y, enregistrer le chemin de q i H vers q i L S’arrêter lorsque q i H est rencontré de nouveau. Suivre le chemin le plus court pour retourner à q i L Si but inatteignable, retourner échec Sinon retourner à l’étape (1). 3.1.2 Bug2 La description de Bug2 est donnée dans l’algorithme 2. Bug2 a été défini initialement en utilisant des capteurs tactiles. Dans Bug2 [121], lorsque le robot rencontre un obstacle, il le contourne à gauche et ne le quitte que s’il trouve un point sur une 110V.3 Application sur la famille d’algorithmes Bug ligne imaginaire appelée M-line passant par son point de départ et le but. Lorsque ce point est trouvé, le robot vérifie que ce point est plus proche que le point où il a rencontré l’obstacle et si le but est atteignable à partir de celui-ci. Si ces conditions sont satisfaites, le robot s’oriente vers son but et continue son chemin vers celui-ci sinon si aucun point correspondant à ces conditions n’est identifié, l’algorithme indique que le but est inatteignable, le robot s’arrête et termine sa mission. Algorithm 2: Bug2 pseudo-code [38, 121] Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles Input : Position de départ (qstart), Position du but (qgoal) Initialisation: Point q 0 L ← qstart ; int i ← 1 ; (1) A partir de q i L avancer vers le but en suivant la ligne (qstart,qgoal) jusqu’à ce que l’une de ces conditions soient satisfaites : qgoal atteint, Stop. Un obstacle est rencontré, i ← i + 1, q i H ← x, aller à l’étape (2). (2) Contourner l’obstacle à gauche jusqu’à ce que : (A) q i H rencontré de nouveau, retourner échec (B) un nouveau point y est trouvé sur la ligne (qstart, qgoal) tel que y est plus proche du but que q i H Si but atteignable à partir de y, q i L ← x, retourner à l’étape (1) Sinon d(q i H, qgoal) ← d(x, qgoal), continuer à contourner l’obstacle. 3.1.3 Alg1 Alg1 [122, 123] est une extension de Bug2. Sa description est donnée dans l’algorithme 3. Comme Bug1 et Bug2, Alg1 a été défini dans la littérature avec des capteurs tactiles. À la différence de Bug2, Alg1 enregistre tous les hit points et les leave points qu’il a rencontré sur la M-line. L’identification d’un leave point dans Alg1 est similaire à celle dans Bug2 (c.-à-d. un leave point est un point sur la M-line plus proche que tous les points déjà visités). Dans Alg1, lorsque le robot rencontre un ancien point visité, il retourne au dernier hit point. Une fois le dernier hit point atteint, il contourne l’obstacle dans la direction contraire à sa direction initiale (c.-à-d. contournement à droite) toujours à la recherche d’un leave point potentiel. 111Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique Algorithm 3: Alg1 pseudo-code [122] Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles Input : Position de départ (qstart), Position du but (qgoal) Initialisation: Point q 0 L ← qstart ; int i ← 1 ; (1) A partir de q i L avancer vers le but en suivant la ligne (qstart,qgoal) jusqu’à ce que l’une de ces conditions soient satisfaites : qgoal atteint, Stop. Un obstacle est rencontré, i ← i + 1, q i H ← x, aller à l’étape (2). (2) Contourner l’obstacle à gauche jusqu’à ce que : (A) q i H rencontré de nouveau, retourner échec (B) un nouveau point y est trouvé sur la ligne (qstart, qgoal) tel que y est plus proche du but que q i H et le but est atteignable à partir de y, q i L ← x, retourner à l’étape (1). (C) q j H ou q j L rencontré tel que (j < i), retourner à q i H et à partir de q i H contourner l’obstacle à gauche. Cette règle ne peut pas être répétée avant qu’un nouveau q i L soit défini. 3.1.4 Alg2 Alg2 [124] est une extension de Alg1. Sa description est donnée dans l’algorithme 4. Alg2 se base aussi sur des capteurs tactiles. Le robot ne se base plus sur la condition de la M-line pour quitter l’obstacle rencontré mais sur une nouvelle condition qui consiste à trouver le premier point ayant la distance minimale par rapport au but et à partir duquel le but est atteignable. Le robot peut quitter l’obstacle sur ce point et continue son chemin vers le but. 3.1.5 DistBug Dans DitBug [125], le robot utilise une nouvelle donnée introduite par l’utilisateur ainsi que des capteurs de distance. Cette donnée est l’épaisseur minimale du mur d’un obstacle appelée STEP. Le robot utilise ses capteurs de distance et l’épaisseur minimale des obstacles présents dans l’environnement pour trouver un point qui est plus proche du but, à une valeur STEP près, que tous les points déjà visités. La description de DistBug est présentée dans l’algorithme 5. 112V.3 Application sur la famille d’algorithmes Bug Algorithm 4: Alg2 pseudo-code [124] Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles Input : Position de départ (qstart), Position du but (qgoal) Initialisation: Point q 0 L ← qstart ; int i ← 1 ; double distM inT oGoal ← deuclidian (qstart, qgoal) (1) A partir de q i L avancer vers le but en suivant la ligne (qstart,qgoal) en mettant à jour distM inT oGoal si deuclidian (x, qgoal) < distM inT oGoal, jusqu’à ce que l’une de ces conditions soient satisfaites : qgoal atteint, Stop. Un obstacle est rencontré, i ← i + 1, q i H ← x, aller à l’étape (2). (2) Contourner l’obstacle à gauche, vérifier si deuclidian (x, qgoal) < distM inT oGoal, si oui alors distM inT oGoal ← deuclidian (x, qgoal) jusqu’à ce que : (A) q i H rencontré de nouveau, retourner échec (B) un nouveau point y est trouvé tel que deuclidian (y, qgoal) < distM inT oGoal et le but est atteignable à partir de y, q i L ← y, retourner à l’étape (1). (C) q j H ou q j L rencontré tel que (j < i), retourner à q i H et à partir de q i H contourner l’obstacle à gauche. Cette règle ne peut pas être répétée avant qu’un nouveau q i L soit défini. Algorithm 5: DistBug pseudo-code [125] Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles Input : Position de départ (qstart), Position du but (qgoal) Initialisation: Point q 0 L ← qstart ; int i ← 1 ; double distM inT oGoal ← deuclidian (qstart, qgoal) ; double Step ← userData (1) A partir de q i L avancer vers le but en mettant à jour distM inT oGoal si deuclidian (x, qgoal) < distM inT oGoal, jusqu’à ce que l’une de ces conditions soient satisfaites : qgoal atteint, Stop. Un obstacle est rencontré, i ← i + 1, q i H ← x, aller à l’étape (2). (2) Contourner l’obstacle à gauche, vérifier si deuclidian (x, qgoal) < distM inT oGoal, si oui alors distM inT oGoal ← deuclidian (x, qgoal) jusqu’à ce que : (A) q i H rencontré de nouveau, retourner échec (B) deuclidian (x, qgoal) - F <= 0, c-à-d que le but est visible à partir de x, q i L ← x, retourner à l’étape (1). (C) deuclidian (x, qgoal) - F <= distM inT oGoal- Step alors q i L ← x, retourner à l’étape (1). 113Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique 3.1.6 TangentBug L’algorithme Tangent Bug [126] (voir algorithme 6) requiert l’utilisation de capteurs de distance. À partir de n’importe quelle position, le robot doit récupérer sa distance par rapport à l’obstacle le plus proche le long d’un rayon r émanant du centre du robot à un angle θ [] tel que : distance = ϕ(x, θ) = min α∈[O,∞) d(x, x + α   cos θ sin θ  ) (V.1) tel que x + α   cos θ sin θ   ∈ ∪iBoundary(Oi) (V.2) Cette distance permet au robot de calculer les points discontinuités autour d’un obstacle. Les points de discontinuité sont des points situés sur l’obstacle détectés par les rayons des capteurs du robot et dont la valeur de la distance indique u’un intervalle de valeurs est fini et qu’un autre intervalle a commencé. Pour chaque point de discontinuité, l’algorithme calcule la distance heuristique qui est égale à la distance du robot vers un point de discontinuité et de ce point de discontinuité vers le but : dheuristic = d(x, Pi) + d(Pi , qgoal); où x est la position courante du robot comme défini plus haut et Pi est un point de discontinuité. À chaque itération, le robot cherche le point ayant la distance heuristique minimale parmi tous les points de discontinuité et se dirige vers ce point. À partir de ce point, le robot commence à effectuer le contournement d’obstacle en gardant la même direction que celle qu’il a suivi pour aller à ce point. Il calcule maintenant les deux distances dreach et df ollowed et s’arrête lorsque dreach < df ollowed pour se diriger vers son but de nouveau. 3.2 Identification des abstractions de la famille Bug Les algorithmes Bug sont très similaires fondamentalement mais diffèrent dans certains points. Il existe deux comportements principaux dans les algos de Bug : éviter les obstacles (obstacle avoidance) et se diriger vers le but (motion to goal). 1. Le comportement Motion-to-Goal. Le robot s’oriente vers son but et avance en suivant la direction qui le mène vers celui-ci. Selon les algorithmes, 114V.3 Application sur la famille d’algorithmes Bug Algorithm 6: TangentBug pseudo-code [126] Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles Input : Position de départ (qstart), Position du but (qgoal) Initialisation: Point q 0 L ← qstart ; int i ← 1 ; double distM inT oGoal ← deuclidian (qstart, qgoal) (1) A partir de q i L avancer vers le but, jusqu’à ce que l’une de ces conditions soient satisfaites : qgoal atteint, Stop. Un obstacle est rencontré, i ← i + 1, q i H ← x, aller à l’étape (2). (2) Calculer points de discontinuités autour de l’obstacle rencontré. Parmi les points de discontinuité, chercher le point ayant la distance heuristique minimale et la direction vers ce dernier. Le robot se déplace jusqu’à ce point jusqu’à ce que la distance heuristique ne diminue plus. Contourner l’obstacle dans la même direction, jusqu’à ce que : (A) q i H rencontré de nouveau, retourner échec (B) dreach < df ollowed, q i L ← y, retourner à l’étape (1). Motion-To-Goal peut être trivial ou avec un enregistrement de données qui seront utiles pour le reste de l’algorithme comme le cas de l’algorithme DistBug présenté précédemment par exemple. En effet, dans DistBug le robot doit avancer vers son but en mettant à jour sa distance euclidienne minimale par rapport au but. Cette variable sera utilisée dans la suite de l’algorithme lorsque le robot rencontrera un obstacle pour identifier le meilleur point qui lui permettra de quitter cet obstacle. Nous retrouvons le comportement trivial de Motion-To-Goal dans tous les algorithmes de Bug où il faut que le robot avance simplement vers son but. Le robot s’arrête, quitte ce mode et bascule vers le mode Obstacle-Avoidance dès qu’un obstacle est détecté. 2. Le mode Obstacle-Avoidance : Contrairement à Motion-To-Goal, ObstacleAvoidance est différent d’un algorithme à l’autre mais se base sur les mêmes étapes pour l’identification d’un leave point. Dans tous les algorithmes de Bug, lorsqu’un obstacle est détecté, le robot enregistre sa position courante et calcule dans certains cas des données supplémentaires qu’il va utiliser tout au long de l’algorithme. En effet, étant donné que l’environnement inconnu, la position du robot permet de savoir s’il a atteint la position de son but en calculant la distance euclidienne par rapport à celui-ci. D’autre part, sa po- 115Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique sition est utile lorsqu’il s’agit de retenir la position d’un point par lequel il est passé. Après l’enregistrement des données, le robot contourne l’obstacle jusqu’à ce que la condition d’évitement d’obstacle définie par l’algorithme soit satisfaite (c.-à-d. leave point identifié) ou lorsque l’algorithme indique que le but est inatteignable. Si la condition de l’algorithme est satisfaite, le robot se dirige vers le leave point identifié, et reprend son chemin vers le but en rebasculant vers le comportement Motion-To-Goal. Le robot change de comportement si un obstacle est détecté ou si un point potentiel (c.-à-d. leave Point) qui permet de quitter l’obstacle a été identifié. L’identification de ce point potentiel représente le point de variabilité principal des algorithmes de Bug. La description informelle de Bug cache la variabilité algorithmique et celle du matériel. La variabilité du matériel a un impact sur la détection d’obstacles et sur la localisation en raison de leurs dépendances des capteurs du robot utilisé. Quant à la variabilité algorithmique, elle est liée à l’identification d’un leave point pour quitter l’obstacle rencontré. En se basant sur une démarche dirigée par les buts et sur une étude détaillée des algorithmes de Bug, on a identifié les abstractions suivantes : – Motion-To-Goal : Le robot doit pouvoir se positionner face à son but et être capable d’avancer vers celui-ci : faceGoal(Point qgoal), goAhead(double speed) – Le robot s’arrête : halt() – La détection d’obstacle sur le chemin du robot : bool obstacleInFrontOfTheRobot() interroge sur les capteurs sur la présence d’un obstacle en face du robot. – La position courante : Point getPosition() – Le contournement d’obstacles consiste à suivre une direction (clockwise ou counter-clockwise) en réduisant l’écart entre la distance du robot par rapport au mur suivi et la distance de sécurité comme le montre la figure V.47. Cette abstraction est appelée wallFollowing(bool direction). – double getSafeDistance() indique la distance minimale que le robot doit maintenir par rapport à l’obstacle rencontré. – obstacleOnTheRight(), bool obstacleOnTheLeft() permettent de situer l’obstacle le plus proche détecté à gauche ou à droite du robot. Imaginons le cas où les capteurs situés à gauche détectent un obstacle et les capteurs droits 116V.3 Application sur la famille d’algorithmes Bug Figure V.47 – Le contournement d’obstacle : (1) le robot à droite doit tourner à droite pour se rapprocher de l’obstacle et réduire l’écart entre la distance de sécurité et sa distance actuelle par rapport à l’obstacle. (2) le robot à gauche doit tourner à gauche pour s’éloigner de l’obstacle et réduire l’écart entre la distance de sécurité et sa distance actuelle par rapport à l’obstacle détectent un obstacle, il est important de savoir de quel coté se trouve l’obstacle le plus proche. Ces abstractions ne sont pas spécifiques aux capteurs à rayons. Vu qu’elles se présentent sous forme de requêtes qui ne sont pas spécifiques à un type particulier elle peut aussi bien être utilisée pour des capteurs tactiles que pour des capteurs à rayons. Par exemple dans le cas des capteurs à rayons, elles désignent les cadrans à droite et à gauche du robot sur la figure V.48. Ces cadrans peuvent varier selon les champs de vision des capteurs et leurs portées. Cette figure représente le cas où le robot est un point. Figure V.48 – La détection d’obstacle devant, à gauche et à droite du robot avec des capteurs de distance – double getRightDistance(), double getLeftDistance() : afin de maintenir une distance de sécurité par rapport au mur qui représente l’obstacle, nous devons savoir quelle est la distance par rapport à l’obstacle le 117Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique plus proche à gauche ou à droite (selon la direction suivie) comme le montre la figure V.49. La distance retournée est la moyenne des distances détectées par les rayons du capteur gauche (ou droit) du robot par rapport à l’obstacle le plus proche. Figure V.49 – Exemple de getDistanceRight : la distance retournée est la moyenne des distances détectées parmi tous les rayons émanant du capteur droit du robot – Trouver un leave Point : identifyLeavePoint(bool direction, Point robotPosition, Point goalPosition). La recherche d’un leave point consiste à contourner l’obstacle tout en vérifiant les conditions définies par l’algorithme pour l’identification de celui-ci. La stratégie d’évitement d’obstacle peut se baser sur une décision locale (choisir le premier point qui répond aux conditions de l’algorithme) ou une décision globale (choisir le point parmi tous les points visités qui répond au mieux aux conditions de l’algorithme). Par consé- quent, nous avons identifié une abstraction qui sera appliquée à chaque point visité autour de l’obstacle et qui varie d’un algorithme à un autre : findLeavePoint(Point robotPosition, Point hitPoint, Point goalPosition). Les données enregistrées varient aussi d’un algorithme à l’autre, dans certains algorithmes on n’enregistre que le point de rencontre de l’obstacle. Dans d’autres, on enregistre les points perçus par le robot ayant une distance heuristique minimale. C’est pour cette raison qu’on a identifié l’abstraction computeData(Point RobotPos) Le code de identifyLeavePoint est donné dans l’algorithme 7. Algorithm 7: Identify leavePoint method identifyLeavePoint(Bool direction, P oint robotP os, P oint goalP os){ computeData(robotPos) ; wallFollowing(direction) ; findLeavePoint(robotPos, getLastHitPoint()) ; } 118V.3 Application sur la famille d’algorithmes Bug – Leave point identifié : bool isLeavePointFound() indique si un leave point a été identifié. – Recherche Complète bool researchComplete(Point robotPosition, Point hitPoint, Point goalPosition) : Dans le cas où la stratégie appliquée se base sur une décision locale, la recherche est terminée se traduit par l’identification d’un leave point qui répond aux conditions de l’algorithme. En d’autres termes, research complete est équivalent à leavePointidentified dans le cas d’une décision locale. Lorsqu’il s’agit d’une décision globale, la recherche n’est terminée que lorsque le robot a effectué un tour complet autour de l’obstacle afin d’être sûr qu’il a identifié le meilleur point qui répond aux conditions de l’algorithme. – Aller au leave point goToPoint(Point leavePoint) : Une fois le leave point identifié, le robot se dirige vers celui-ci. Ceci constitue un point de variation parmi les algorithmes car le robot peut par exemple suivre le chemin le plus court pour aller vers ce point ou appliquer d’autres stratégies. – but inatteignable : Cette condition est vérifiée si aucun leave point n’a été identifié après que le robot ait effectué un tour complet autour de l’obstacle rencontré (not isleavePointFound() and completeCycleAroundObstacle(Point robotPosition,Point hitPoint)). – but atteint : Selon le but de l’algorithme, nous définission une marge d’erreur qui indique si le robot doit atteindre son but ou s’il doit s’arrêter peu avant de l’atteindre : bool goalReached(Point robotPosition, Point goalPosition, double err). Ces abstractions combinent les abstractions algorithmiques et les abstractions non algorithmiques. Nous pouvons alors les classifier comme suit : 1. Abstractions non algorithmiques : les paramètres de configuration des capteurs sont définis au niveau du déploiement et les caractéristiques spécifiques comme par exemple le nombre de rayons des capteurs, leurs portée, etc. sont spéci- fiées au niveau des adaptateurs. Etant donné que le robot est considéré comme un point dans les hypothèses de la famille Bug, nous n’allons pas prendre en compte la position des capteurs sur le robot mais simplement de leur emplacement (devant, derrière, à gauche ou à droite) en supposant qu’ils sont placés au même niveau que la plateforme du robot. Les abstractions non algorithmiques sont classées dans 2 sous-catégories : – Abstractions non algorithmiques en tant que requêtes sur l’environnement 119Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique nécessitant des capteurs à rayons : – double getSafeDistance() – double getLeftDistance() – double getRightDistance() Nous avons vu que ces abstractions servent au contournement d’obstacle. Elles permettent de retourner la distance à gauche ou à droite du robot par rapport à l’obstacle le plus proche. C’est pour cette raison que nous avons besoin de capteurs à rayons pour pouvoir les implanter et faire des regroupements des rayons des capteurs. – Abstractions non algorithmiques en tant que requêtes générales : – bool obstacleInFrontOfTheRobot() – bool obstacleOnTheLeft() – bool obstacleOnTheRight() Ces abstractions interrogent les capteurs afin de savoir s’il y a un obstacle devant, à droite ou à gauche du robot. Concrètement ces abstractions pourrait être utilisées pour des capteurs à rayons aussi bien que pour des capteurs tactiles ou même pour d’autres types de capteurs tant qu’ils sont capables de founir ces informations. Il n’y a donc aucune contrainte sur ces abstractions qui requiert un type de capteurs particulier. – Abstractions non algorithmiques en tant qu’actions de haut niveau : – halt() – faceGoal(Point goalPosition) – goAhead(double speed) – turnRight(double translation, double angle) – turnLeft(double translation, double angle) – goToPoint(Point leavePoint) – motionToGoal() 2. Abstractions algorithmiques : – righHand() – leftHand() – wallFollowing(bool direction) – identifyLeavePoint(bool direction, Point robotPosition, Point goalPosition) – findLeavePoint(Point robotPosition, Point hitPoint, Point goalPosition) – bool isLeavePointFound() – bool researchComplete(Point robotPosition, Point hitPoint, Point goalPosi- 120V.3 Application sur la famille d’algorithmes Bug tion) – bool completeCycleAroundObstacle(Point robotPosition,Point hitPoint) – goalReached(Point robotPosition, Point goalPosition, double err) 3.3 Identification de l’algorithme générique de la famille Bug L’algorithme générique est une combinaison des abstractions identifiées dans la section précédente comme une séquence d’instructions. Notre algorithme générique est presenté dans l’algorithme 8. Algorithm 8: Algorithme générique de la famille Bug Sensors : Une méthode de localisation parfaite. Un capteur de détection d’obstacles input : Position of Start (qstart), Position of Target (qgoal) Initialisation: robotPos ← getPosition() ; direction ← getDirection() ; if goalReached(robotPos) then EXIT_SUCCESS ; end else if obstacleInFrontOfTheRobot() == true then identifyLeavePoint (direction, robotPos, goalPos); if leavePointFound() && researchComplete(robotPos, getHitPoint(), qgoal) then goToPoint(getLeavePoint()); faceGoal() ; end else if completeCycleAroundObstacle(robotPos, getHitPoint()) && !leavePointFound() then EXIT_FAILURE ; end end else motionToGoal() ; end 121Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique 3.4 Organisation de l’implantation de la famille Bug Comme nous l’avons mentionné précédemment, le design pattern Template Method permet de gérer le problème de la variabilité en proposant de définir les sé- quences d’un algorithme dans une template méthode d’une classe abstraite écrite en fonction d’abstractions qui seront implantées dans les sous classes de celle-ci. D’autre part, le design pattern Bridge permet de séparer les abstractions de leur implantation dans différentes hiérarchies de classes. Chaque variante de l’algorithme est alors implantée dans une sous-classe de la classe abstraite. Quant aux abstractions du matériel, elles sont définies dans des interfaces et implantées par la suite par les adaptateurs correspondant aux capteurs virtuels et aux effecteurs virtuels. Nous avons besoin d’un adaptateur de capteurs qui va implanter les abstractions suivantes : – double getSafeDistance() – bool obstacleInFrontOfTheRobot() – bool obstacleOnTheLeft() – bool obstacleOnTheRight() – double getLeftDistance() – double getRightDistance() Cet adaptateur peut prendre en entrée des données d’un ou de plusieurs capteurs physiques capables de founir les informations dont on a besoin. Les paramètres de configuration des capteurs sont définis au sein de ces adaptateurs. De plus, nous avons besoin d’un adaptateur pour les effecteurs du robot qui va implanter les abstractions suivantes : – halt() – faceGoal(Point q_goal) – goAhead(double speed) – turnRight(double translation, double angle) – turnLeft(double translation, double angle) Prenons maintenant le cas d’un adaptateur Laser ayant un angle de perception de 180° et une portée de 2 mètres. Il faut arriver à extraire les informations de ce capteur afin de les adapter aux besoins des requêtes sur l’environnement. Nous avons alors défini une fonction propre à l’adaptateur appelée getDistanceSensors() qui s’occupe de regrouper les rayons en se basant sur leur nombre et leurs positions (voir 122V.3 Application sur la famille d’algorithmes Bug listing V.8). 1 vector LaserAdapter :: getDistanceSensors (){ 2 sensor_msgs :: LaserScan msg ; 3 vector rays ; 4 laser_port . read ( msg ); 5 int j = 18; 6 int nbRays = samples / nb_sensors ; 7 for(int i =0; i < nb_sensors ; i ++){ 8 rays . push_back ( std :: accumulate ( msg . ranges . begin ()+ j - nbRays , 9 msg . ranges . begin ()+ j , 0)); 10 j = j + nbRays ; 11 } 12 return rays ; 13 } Listing V.8 – implantation de getDistanceSensors() Les autres abstractions implantées dans cet adaptateur utilisent alors ce nouveau regroupement des rayons du capteur afin de renvoyer le résultat de la requête. Par exemple l’implantation de obstacleOnTheLeft() (listing V.9) qui indique si l’obstacle le plus proche est situé à gauche du robot utilise ce regroupement des rayons donné par la fonction getDistanceSensors(). 1 bool LaserAdapter :: obstacleOnTheLeft (){ 2 sensor_msgs :: LaserScan msg ; 3 vector rays = getDistanceSensors (); 4 double sensorLeft = rays [4]; 5 double sensorLeftFront = rays [3]; 6 double sensorRightFront = rays [1]; 7 double sensorRight = rays [0]; 8 9 return ( sensorRight + sensorRightFront > 10 sensorLeft + sensorLeftFront ); 11 } Listing V.9 – implantation de l’abstraction obstacleOnTheLeft() L’architecture de notre application est présentée dans la figure V.50. 123Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique Figure V.50 – Extrait du digramme de classe de la famille Bug parler de l’implantion de main droite et main gauche : réduire l’écart pour maintenir le mur à droite ou à gauche. Mettre figure mur et orientation robot Les sources correspondant aux différentes variantes des algorithmes sont disponibles sur https://github.com/SelmaKchir/BugAlgorithms. 3.5 Expérimentations et Validation Nous avons choisi d’implanter notre application sous OROCOS en utilisant une architecture à base de composants. La classe abstraite BugAlgorithm contient la template method représentant l’algorithme générique. Chaque variante de la famille Bug est un composant OROCOS qui implante les méthodes abstraites et qui peut implanter les hook méthodes de la classe abstraite. Des interfaces correspondant aux abstractions du matériel sont également définies afin de préciser les services qui doivent être fournis par les adaptateurs. Chaque adaptateur est un composant OROCOS lié à un composant matériel (capteur ou actionneur). Aucun détail spécifique au matériel n’est présenté dans le code de l’application. Les composants sont déployés dans des libraries OROCOS et les liens entre les composants de contrôle et les composants matériels ne sont spécifiés qu’au niveau de 124V.3 Application sur la famille d’algorithmes Bug l’exécution à travers un fichier de configuration. Cela garantit une indépendance par rapport aux détails de bas niveau. L’architecture d’une application correspondant à la variante Bug1 de la famille Bug est présentée dans la figure V.51. Plusieurs études Figure V.51 – Architecture de l’application correspondant à Bug1 comparatives sur les performances des variantes de la famille Bug ont été réalisées dans [127]. Dans cette section, notre objectif n’est pas de comparer ces variantes mais de prouver que chaque variante de Bug peut être implantée avec notre algorithme générique. Les six variantes présentées précédemment : Bug1 [38], Bug2 [121], Alg1 [122], Alg2 [124], DistBug [125] et TangentBug [126] ont été correctement implantées à partir de notre algorithme générique sous OROCOS. 3.5.1 Environnement de simulation : Stage-ROS Stage est un environnement de simulation deux dimensions qui fait partie de l’outil de simulation Player/Stage. Il fournit des modèles simples de plusieurs dispositifs. Stage a été intégré à ROS afin de permettre la simulation de programmes développés dans ce middleware ou développés dans d’autres middleware intégrés à ROS. Le noeud stageros simule un monde défini dans un fichier .world, qui contient les détails des capteurs, des robots et des obstacles dans le monde simulé. Stageros étant un noeud de ROS, il est possible de le faire communiquer avec d’autres middleware intégrés à ROS comme OROCOS. Nous pouvons ainsi simuler notre application implantée avec OROCOS avec Stage en passant pas les messages ROS pour l’intéraction avec les capteurs et les effecteurs physiques du robot simulé. 125Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique 3.5.2 Configurations des environnements et des capteurs La simulation a été réalisée au sein de trois environnements. Le premier environnement présenté dans la figure V.52 nous permet de tester si le robot est capable d’atteindre son but et si l’abstraction goalIsReachable() fonctionne correctement. Figure V.52 – Environnement1 : but inatteignable Le second environnement présenté dans la figure V.53 est un environnement de simulation simple avec un seul obstacle. Le but de l’utilisation de cet environnement est de tester simplement le contournement d’obstacle et la capacité du robot d’identifier un point pour le quitter. Nous ne pouvons pas distinguer le comportement du robot dans les algorithmes Bug2 et Alg1 à travers cet environnement car le robot ne revisite pas de points qu’il a déjà visités. Figure V.53 – Environnement2 : Environnement avec un seul obstacle 126V.3 Application sur la famille d’algorithmes Bug Nous avons alors défini un troisième environnement V.54 pour pouvoir distinguer les trajectoires d’exécution du robot dans les environnement Bug2 et Alg1 et dans les autres algorithmes. Concernant les capteurs, nous avons utilisé deux configurations de robots : le preFigure V.54 – Environnement3 : Environnement avec plusieurs obstacles mier avec un capteur Laser et le deuxième avec trois capteurs infrarouges. La première configuration a été effectuée en utilisant un capteur Laser ayant un angle de perception de 180 degré et dont les rayons de cet angle ont une portée variant de 0.02 mètres et allant jusqu’à 4 mètres. Pour la localisation, nous avons utilisé un GPS (en supposant que l’environnement de simulation est à l’extérieur). La deuxième configuration a été réalisée en utilisant trois capteurs infrarouges placés sur l’avant, sur la gauche et sur la droite du robot par rapport à son axe central. Ces capteurs ont un champs de vision (Field Of View) de 26 degré et une portée qui va jusqu’à 2 mètres. Afin de valider notre démarche nous avons testé nos algorithmes avec deux configurations différentes dans ces trois environnements. 3.5.3 Résultats Les résultats de simulation montrent une différence de trajectoire entre la première et la deuxième configuration. En effet, la trajectoire suivie par le robot ayant un capteur Laser est différente de celle suivie par le robot ayant les capteurs infrarouges. Ceci est dû au temps d’interprétation des données et aux configurations différentes. Cependant dans tous les cas le robot termine sa mission et ar- 127Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique rive à atteindre son but. Concernant les différents algorithmes, ils sont correctement exécutés dans ces trois environnements. Les résultats de simulation sont disponibles sur le lien : https://github.com/SelmaKchir/BugAlgorithms/wiki/ Implementing-Bug-Algorithms-variants 4 Discussion Nous avons démontré que les abstractions identifiées permettent d’être réutilisées indépendamment du robot utilisé grâce à l’utilisation des adaptateurs des capteurs et des effecteurs. Ces abstractions ont une sémantique car elles ont été définies à partir pour une tâche de robotique. Si nous souhaitons ajouter une nouvelle variante de la famille Bug, il faut implanter les abstractions algorithmiques, les abstractions non algorithmiques quant à elles ne doivent pas forcément être implantées s’il n’y a pas de changement de robot. Dans le cas contraire, il faut ajouter un adaptateur pour les abstractions non algorithmiques. Concernant les requêtes sur l’environnement, nous avons distingué des requêtes générales indépendantes de la classe des capteurs utilisés (range, tactiles, etc.) et des requêtes spécifiques aux capteurs à rayons. Si nous souhaitons supporter les capteurs tactiles par exemple, il faudrait alors changer l’implantation de l’abstraction wallFollowing vu qu’elle utilisait les abstractions getLeftDistance(), getRightDistance(), getSafeDistance() qui s’appuient sur les capteurs à rayons. Les abstractions algorithmiques résistent aux variations non algorithmiques. En effet, si on prend l’exemple de l’abstraction identifyLeavePoint (voir algorithme 7), même si on change la façon de contourner l’obstacle et les capteurs qu’on veut utiliser, l’implantation de cette abstraction reste inchangée. Nous avons besoin d’enregistrer plus de données donc on peut les ajouter au niveau de l’implantation de cette variante... L’ajout est alors facile, il suffit de comprendre l’algorithme et de l’intégrer. L’algorithme générique, quant à lui, est stable, il n’y a pas de changement à faire au sein de l’algorithme générique si on veut ajouter une nouvelle variante ou un nouveau matériel. 128V.5 Conclusion 5 Conclusion Dans ce chapitre, nous avons proposé une approche qui permet de produire des abstractions algorithmiques, des abstractions non algorithmiques et un algorithme générique défini en fonction de ces dernières. Nous avons présenté également comment implanter ces abstractions de façon à les faire varier dans l’application sans avoir à modifier l’algorithme générique et sans qu’il n’y ait d’explosion combinatoire. En effet, nous avons séparé l’implantation des abstractions non algorithmiques de celles algorithmiques étant donné que ces dernières sont de plus haut niveau et sont spécifiques à la tâche qu’on veut implanter. Cependant, l’inconvénient d’une telle approche est qu’il faudrait définir autant d’adaptateurs que de capteurs ou d’effecteurs physiques. Afin d’assurer la réutilisabilité de ces abstractions, on pourrait enrichir notre démarche par une librairie d’adaptateurs qui convertissent les données à partir de dispositifs physiques vers les abstractions requises (dans le cas des capteurs) ou inversement (dans le cas des effecteurs). Cette librairie pourrait compléter l’ontologie du domaine proposée dans le cadre du projet PROTEUS en apportant une sémantique aux abstractions définies. 129Chapitre V. Approche Top-down pour la gestion de la variabilité dans les algorithmes de robotique 130Conclusion générale et perspectives Le projet PROTEUS a constitué le contexte général de cette thèse dont l’objectif principal est de faciliter le développement des applications de robotique et les rendre résistantes vis-à-vis aux changements des détails de bas niveau. Ce travail de thèse a alors consisté à : 1. Choisir des abstractions indépendantes des plateformes de robotique mobile pour représenter le contrôle et la communication d’une application ; 2. traduire les abstractions de RobotML vers le middleware OROCOS à travers un générateur de code ; 3. proposer une démarche descendante pour rendre les algorithmes résistants aux changements des détails de bas niveau. Afin de faciliter le développement des applications de robotique, il faudrait permettre aux roboticiens de manipuler des concepts qu’ils ont l’habitude d’utiliser pour le développement de leurs applications. Pour ce faire et afin de traiter le point (1) présenté ci-dessus, nous avons étudié les différents concepts utilisés en robotique. Pour l’aspect contrôle, nous permettons la modélisation de plusieurs types de contrôle (à boucle fermée ou à boucle ouverte) à travers des machines à états finis. Pour l’aspect communication, nous permettons la spécification d’un échange de données synchrone ou asynchrone entre les composants d’une application ainsi que la communication à travers des services. Les abstractions de RobotML sont proposées à travers un éditeur graphique offrant ainsi une facilité d’utilisation aux roboticiens et même à des simples utilisateurs qui ne sont pas experts en robotique. À partir des modèles représentés avec l’éditeur graphique de RobotML, nous générons le code correspondant vers la plateforme OROCOS. Nous arrivons alors au point (2) ci-dessus. Cette contribution a 131Conclusion générale et perspectives consisté à l’élaboration de règles de transformations des abstractions de RobotML vers les concepts d’OROCOS. La génération de code permet d’accélérer le processus de développement d’une application. En effet, le temps passé dans la phase de conception d’une application avec RobotML est largement inférieur au temps passé à développer une application à partir de zéro. Cette contribution a été validée sur un scénario aérien proposé par l’ONERA. Les abstractions proposées par RobotML sont des abstractions de haut niveau du domaine qui permettent de spécifier les aspects généraux d’une application de robotique : architecture, contrôle et communication. Cependant, elles ne permettent pas de gérer la variabilité liée aux détails de bas niveau des capteurs et des effecteurs d’une part. D’autre part, elles ne permettent pas d’encapsuler les détails algorithmiques d’une application car elles manquent de sémantique opérationnelle. En effet, l’approche adoptée pour la définition des abstractions est une approche qui se base sur les connaissances du domaine pour l’identification des abstractions. Le dernier volet des travaux de cette thèse a été alors de proposer une approche qui permet de définir des abstractions ayant une sémantique opérationnelle. Nous sommes partis de la description d’une tâche de robotique afin d’identifier ce que nous avons appelés des abstractions non algorithmiques et des abstractions algorithmiques. Les abstractions non algorithmiques concernent essentiellement le matériel et se présentent sous forme de requêtes sur l’environnement ou des actions de haut niveau. Les abstractions algorithmiques sont de plus haut niveau que les abstractions non algorithmiques, elles encapsulent les détails algorithmiques relatifs à une sous-tâche de robotique et utilisent les abstractions non algorithmiques. Un expert de robotique combine ensuite ces abstractions afin de définir un algorithmique générique qui résiste aux changements de bas niveau ainsi qu’aux variations algorithmiques. Notre approche a été validée sur une famille d’algorithmes de navigation appelée Bug [38]. Nous avons fait varier les capteurs utilisés ainsi que les stratégies proposées par six variantes de cette famille et nous avons démontré que l’algorithme générique reste inchangé malgré ces variations. Une perspective immédiate de nos travaux serait d’enrichir les abstractions de RobotML avec une librairie d’abstractions contenant celles que nous avons identifiées pour une famille de navigation. Ainsi, il devient possible au niveau de la modélisation d’utiliser des abstractions qu’on sait comment implanter. Une deuxième perspective 132Conclusion générale et perspectives consiste à appliquer notre approche sur une autre étude de cas afin d’identifier davantage d’abstractions. L’implantation de notre approche pour la définition d’un algorithme générique en fonction d’abstractions ayant une sémantique opérationnelle se base sur les patrons de conception Template Method et Bridge. Il n’est pas encore possible avec notre approche de définir des contraintes sur les algorithmes comme par exemple les capteurs requis qui peuvent être des capteurs de distance dans certains cas. Une perspective possible serait d’utiliser les lignes de produits algorithmiques dans ce contexte afin de définir des contraintes sur l’association entre les capteurs requis pour des abstractions algorithmiques particulières. Une ébauche de cette perspective a été réalisée dans le cadre de cette thèse mais les résultats sont insuffisants pour être présentés dans ce travail. Une perspective de recherche à long terme des travaux de cette thèse serait de s’intéresser à un autre sous-domaine de la robotique comme par exemple les robots manipulateurs. À partir de notre expérience avec RobotML, nous pouvons savoir quelles sont les abstractions qui peuvent être réutilisées et celles qu’il faut ajouter afin de faciliter le développement de ce sous-domaine. 133Conclusion générale et perspectives 134Références bibliographiques [1] Ronald C. Arkin. Behavior Based Robotics (Intelligent Robotics and Autonomous Agents). The MIT Press (1998). vii, 7, 8, 13, 14, 15 [2] Mark Strembeck and Uwe Zdun. An approach for the systematic development of domain-specific languages. Softw. Pract. Exper. 39(15), 1253–1292 October (2009). vii, 35, 41, 44, 45 [3] Herman Bruyninckx, Markus Klotzbücher, Nico Hochgeschwender, Gerhard Kraetzschmar, Luca Gherardi, and Davide Brugali. The brics component model : a model-based development paradigm for complex robotics software systems. In Proceedings of the 28th Annual ACM Symposium on Applied Computing, SAC ’13, pages 1758–1764, New York, NY, USA (2013). ACM. vii, 2, 48, 50, 58, 60, 84 [4] Soraya Arias, Florine Boudin, Roger Pissard-Gibollet, and Daniel Simon. ORCCAD, robot controller model and its support using Eclipse Modeling tools. In 5th National Conference on Control Architecture of Robots, Douai, France May (2010). vii, 2, 50, 51, 58, 60 [5] Smartsoft metamodel. http://www.program-transformation.org/pub/ GPCE11/ConferenceProgram/slides-gpce11-steck.pdf. vii, 52 [6] Diego Alonso, Cristina Vicente-Chicote, Francisco Ortiz, Juan Pastor, and Barbara Alvarez. V3CMM : a 3-View Component MetaModel for Model-Driven Robotic Software Development. Journal of Software Engineering for Robotics 1(1), 3–17 (2010). vii, 53, 54, 58, 60 [7] Saadia Dhouib, Nicolas Du Lac, Jean-Loup Farges, Sebastien Gerard, Miniar Hemaissia-Jeannin, Juan Lahera-Perez, Stephane Millet, Bruno Patin, and Serge Stinckwich. Control architecture 135Références bibliographiques concepts and properties of an ontology devoted to exchanges in mobile robotics. In 6th National Conference on Control Architectures of Robots (2011). vii, 65, 67, 68 [8] Roland Siegwart and Illah R. Nourbakhsh. Introduction to Autonomous Mobile Robots. Bradford Company, Scituate, MA, USA (2004). xi, 10, 11 [9] Henrik I. Christensen and Gregory D. Hager. Sensing and estimation. In Bruno Siciliano and Oussama Khatib, editors, Springer Handbook of Robotics, pages 87–107. Springer (2008). xi, 10 [10] Morgan Quigley, Ken Conley, Brian P. Gerkey, Josh Faust, Tully Foote, Jeremy Leibs, Rob Wheeler, and Andrew Y. Ng. Ros : an open-source robot operating system. In ICRA Workshop on Open Source Software (2009). 1, 19, 23 [11] H. Utz, S. Sablatnog, S. Enderle, and G. Kraetzschmar. Miro - middleware for mobile robot applications. Robotics and Automation, IEEE Transactions on 18(4), 493–497 (2002). 1, 19, 25 [12] Douglas Blank, Deepak Kumar, Lisa Meeden, and Holly Yanco. Pyro : A python-based versatile programming environment for teaching robotics. J. Educ. Resour. Comput. 4(3) December (2003). 1, 19, 29, 31 [13] Toby H. J. Collett and Bruce A. Macdonald. Player 2.0 : Toward a practical robot programming framework. In in Proc. of the Australasian Conference on Robotics and Automation (ACRA (2005). 1, 19, 20 [14] Arie van Deursen, Paul Klint, and Joost Visser. Domain-specific languages : an annotated bibliography. SIGPLAN Not. 35(6), 26–36 June (2000). 1, 34, 35, 39, 40, 45, 46 [15] Jean Bézivin. On the unification power of models. Software and Systems Modeling 4(2), 171–188 (2005). 2, 35 [16] Christian Schlegel, Andreas Steck, and Alex Lotz. Model-driven software development in robotics : Communication patterns as key for a robotics component model. Introduction to Modern Robotics (2012). 2, 52, 56, 58, 60 [17] Michael Brady. Artificial intelligence and robotics. Artif. Intell. 26(1) apr (1985). 7 [18] Nils J. Nilsson. A mobius automation : an application of artificial intelligence techniques. In Proceedings of the 1st international joint conference 136Références bibliographiques on Artificial intelligence, IJCAI’69, pages 509–520, San Francisco, CA, USA (1969). Morgan Kaufmann Publishers Inc. 8, 12 [19] Allen Newell, J. C. Shaw, and Herbert A. Simon. Report on a general problem-solving program. In IFIP Congress, pages 256–264 (1959). 8 [20] Robin R. Murphy. Introduction to AI Robotics. MIT Press, Cambridge, MA, USA, 1st edition (2000). 8 [21] A. Elkady and T. Sobh. Robotics middleware : A comprehensive literature survey and attribute-based bibliography. Journal of Robotics 2012 (2012). 9, 19, 20, 31 [22] Jacob Fraden. Handbook of Modern Sensors : Physics, Designs, and Applications (Handbook of Modern Sensors). SpringerVerlag (2003). 9, 10, 11 [23] J.P. Laumond, S. Sekhavat, and F. Lamiraux. Robot motion planning and control chapter Guidelines in nonholonomic motion planning for mobile robots, pages 1–53. Lectures. Notes in Control and Information Sciences 229. Springer, N.ISBN 3-540-76219-1 (1998). 11 [24] David Kortenkamp and Reid G. Simmons. Robotic systems architectures and programming. In Springer Handbook of Robotics, pages 187–206. (2008). 12, 15 [25] Georges Giralt, Raja Chatila, and Marc Vaisset. An integrated navigation and motion control system for autonomous multisensory mobile robots. In IngemarJ. Cox and GordonT. Wilfong, editors, Autonomous Robot Vehicles, pages 420–443. Springer New York (1990). 12 [26] R. Chatila and J. Laumond. Position referencing and consistent world modeling for mobile robots. , 2, pages 138–145 (1985). 12 [27] James S. Albus, Harry G. McCain, and Ronald Lumia. Nasa/nbs standard reference model for telerobot control system architecture (nasrem). (1989). 13 [28] Ronald C. Arkin and Ronald Arkin. Reactive robotic systems, (1995). 13 [29] Maja J. Mataric. Behavior-based control : Examples from navigation, learning, and group behavior. Journal of Experimental and Theoretical Artificial Intelligence 9, 323–336 (1997). 13 [30] Jonathan Connell. A colony architecture for an artificial creature. Technical report, Cambridge, MA, USA (1989). 13, 14 137Références bibliographiques [31] David Zeltzer and Michael B. Johnson. Motor planning : An architecture for specifying and controlling the behaviour of virtual actors. The Journal of Visualization and Computer Animation 2(2), 74–80 (1991). 14 [32] R.A. Brooks. A robot that walks ; emergent behaviors from a carefully evolved network. In Robotics and Automation, 1989. Proceedings., 1989 IEEE International Conference on, pages 692–4+2 vol.2 (1989). 14 [33] Rodney A. Brooks. A robust layered control system for a mobile robot. IEEE Journal of Robotics and Automation 2(10) (1986). 14 [34] Julio Rosenblatt. Damn : A distributed architecture for mobile navigation - thesis summary. In Journal of Experimental and Theoretical Artificial Intelligence, pages 339–360. AAAI Press (1995). 14 [35] Pattie Maes. The dynamics of action selection. In Proceedings of the 11th international joint conference on Artificial intelligence - Volume 2, IJCAI’89, pages 991–997, San Francisco, CA, USA (1989). Morgan Kaufmann Publishers Inc. 14 [36] Ronald C. Arkin. Path planning for a vision-based autonomous robot. Technical report, Amherst, MA, USA (1986). 15 [37] Ronald Craig Arkin. Towards cosmopolitan robots : intelligent navigation in extended man-made environments. Thèse de Doctorat, (1987). AAI8805889. 15 [38] Vladimir J. Lumelsky and Alexander A. Stepanov. Effect of uncertainty on continuous path planning for an autonomous vehicle. , 23, pages 1616 –1621 dec. (1984). 16, 100, 101, 108, 110, 111, 125, 132 [39] David Bakken. Middleware. Encyclopedia of Distributed Computing (2001). 19 [40] James Kramer and Matthias Scheutz. Development environments for autonomous mobile robots : A survey. Auton. Robots 22(2), 101–132 feb (2007). 19 [41] N. Mohamed, J. Al-Jaroodi, and I. Jawhar. Middleware for robotics : A survey. In Robotics, Automation and Mechatronics, 2008 IEEE Conference on, pages 736–742 (2008). 19, 20 [42] Richard T. Vaughan, Brian P. Gerkey, and Andrew Howard. On device abstractions for portable, reusable robot code. In Proc. of the IEEE/RSJ Intl. Conf. on Intelligent Robots and Systems (IROS), page 2121–2427, Las Vegas, Nevada (2003). 19, 20 138Références bibliographiques [43] ROS : Robot-Operating System. http://www.ros.org/. 19, 23 [44] PYRO : Python Robotics. http://pyrorobotics.com/. 19, 29 [45] William D. Smart. Is a Common Middleware for Robotics Possible ? In IEEE/RSJ Int. Conf. on Intelligent Robots and Systems (IROS’07) Workshop on Measures and Procedures for the Evaluation of Robot Architectures and Middleware November (2007). 23, 99 [46] ROS - Topics. http://wiki.ros.org/Topics. 23 [47] RTT : Real-Time Toolkit. http://www.orocos.org/rtt. 23, 24, 85 [48] ROS - Messages. http://wiki.ros.org/Messages. 24 [49] Corba. http://www.corba.org/. 26 [50] N. Sünderhauf R. Baumgartl P. Protzel D. Krüger, I. Lil. Using and extending the miro middleware for autonomous robots. In Towards Autonomous Robotic Systems (TAROS), Guildford, September 2006. (2006). 28 [51] Michael Jackson. Specializing in software engineering. IEEE Softw. 16(6), 120–121,119 November (1999). 33 [52] Marjan Mernik, Jan Heering, and Anthony M. Sloane. When and how to develop domain-specific languages. ACM Comput. Surv. 37(4), 316–344 December (2005). 34 [53] Diomidis Spinellis. Notable design patterns for domain-specific languages, (2001). 34 [54] Richard B. Kieburtz, Laura McKinney, Jeffrey M. Bell, James Hook, Alex Kotov, Jeffrey Lewis, Dino P. Oliva, Tim Sheard, Ira Smith, and Lisa Walton. A software engineering experiment in software component generation. In Proceedings of the 18th international conference on Software engineering, ICSE ’96, pages 542–552, Washington, DC, USA (1996). IEEE Computer Society. 34 [55] Markus Voelter, Sebastian Benz, Christian Dietrich, Birgit Engelmann, Mats Helander, Lennart C. L. Kats, Eelco Visser, and Guido Wachsmuth. DSL Engineering - Designing, Implementing and Using Domain-Specific Languages. dslbook.org (2013). 34, 35, 42 [56] Arie van Deursen and Paul Klint. Little languages : little maintenance. Journal of Software Maintenance 10(2), 75–92 March (1998). 35 139Références bibliographiques [57] David A. Ladd and Christopher J. Ramming. Two Application languages in software production. In VHLLS’94 : Proceedings of the USENIX 1994 Very High Level Languages Symposium Proceedings on USENIX 1994 Very High Level Languages Symposium Proceedings, page 10, Berkeley, CA, USA (1994). USENIX Association. 35 [58] Francis Neelamkavil. Computer simulation and modelling. John Wiley & Sons, Inc., New York, NY, USA (1987). 35 [59] Omg. http://www.omg.org/. 36 [60] Richard C. Gronback. Eclipse Modeling Project : A Domain-Specific Language (DSL) Toolkit. Addison-Wesley Professional, 1 edition (2009). 37, 50 [61] Papyrus. http://www.eclipse.org/papyrus/. 37, 81, 82 [62] Uml. http://www.uml.org/. 37 [63] L. Fuentes-Fernández and A. Vallecillo-Moreno. An Introduction to UML Profiles. UPGRADE, European Journal for the Informatics Professional 5(2), 5–13 April (2004). 37, 43 [64] OMG MOF 2 XMI Mapping Specification, Version 2.4.1, August (2011). 38 [65] Epsilon. http://www.eclipse.org/epsilon/. 39 [66] Kermeta. http://www.kermeta.org/overview/model_transformation. 39 [67] Acceleo. http://www.eclipse.org/acceleo/. 39, 85 [68] Tom-emf. http://tom.loria.fr/wiki/index.php5/Documentation:EMF. 39 [69] Paul Oldfield. Domain modelling, (2002). 39, 99 [70] G. Arango. Domain analysis : from art form to engineering discipline. In Proceedings of the 5th international workshop on Software specification and design, IWSSD ’89, pages 152–159, New York, NY, USA (1989). ACM. 40 [71] Mark A. Simos. Organization domain modeling (odm) : Formalizing the core domain modeling life cycle, (1996). 40 [72] K. C. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S. Peterson. Feature-oriented domain analysis (foda) feasibility study. Technical report Carnegie-Mellon University Software Engineering Institute November (1990). 41 [73] Nicola Guarino. Formal ontology and information systems. pages 3–15. IOS Press (1998). 41 140Références bibliographiques [74] Saadia Dhouib, Selma Kchir, Serge Stinckwich, Tewfik Ziadi, and Mikal Ziane. Robotml, a domain-specific language to design, simulate and deploy robotic applications. , 7628, pages 149–160. Springer Berlin Heidelberg (2012). 46 [75] Piotr Trojanek. Model-driven engineering approach to design and implementation of robot control system. CoRR abs/1302.5085 (2013). 47 [76] Xavier Blanc, Jérôme Delatour, and Tewfik Ziadi. Benefits of the MDE approach for the development of embedded and robotic systems. In Proceedings of the 2nd National Workshop on “Control Architectures of Robots : from models to execution on distributed control architectures” (CAR 2007) (2007). 47 [77] Brics. http://www.best-of-robotics.org/. 48 [78] Bride. http://www.best-of-robotics.org/bride/. 49 [79] D. Simon, B. Espiau, K. Kapellos, and R. Pissard-Gibollet. Orccad : software engineering for real-time robotics. a technical insight. Robotica 15(1), 111–115 January (1997). 50 [80] D. Simon, R. Pissard-Gibollet, and S. Arias. Orccad, a framework for safe robot control design and implementation. In 1st National Workshop on Control Architectures of Robots : software approaches and issues CAR’06, Montpellier (2006). 50 [81] Gerard Berry, Georges Gonthier, Ard Berry Georges Gonthier, and Place Sophie Laltte. The esterel synchronous programming language : Design, semantics, implementation, (1992). 50 [82] Christian Schlegel. Communication Patterns as Key Towards Component-Based Robotics. International Journal of Advanced Robotic Systems 3(1), 49–54 March (2006). 51, 79 [83] Smartsoft reference implementation. http://smart-robotics. sourceforge.net/. 51 [84] C. Schlegel, A. Lotz, and A. Steck. Smartsoft : The state management of a component. Technical report Hochschule Ulm January (2011). 52 [85] Cristina Vicente-Chicote, Fernando Losilla, Bárbara Álvarez, Andrés Iborra, and Pedro Sánchez. Applying mde to the development of flexible and reusable wireless sensor networks. Int. J. Cooperative Inf. Syst. 16(3/4), 393–412 (2007). 54 141Références bibliographiques [86] Genom3. http://homepages.laas.fr/mallet/soft/architecture/ genom3/. 55, 58, 60 [87] S. Fleury, M. Herrb, and R. Chatila. Genom : a tool for the speci- fication and the implementation of operating modules in a distributed robot architecture. , 2, pages 842–849 vol.2 (1997). 55 [88] Anthony Mallet, Cédric Pasteur, Matthieu Herrb, Séverin Lemaignan, and François Felix Ingrand. Genom3 : Building middlewareindependent robotic components. In ICRA, pages 4627–4632. IEEE (2010). 56 [89] Robotic Technology Component (RTC), August (2012). 56, 58, 60 [90] Byoungyoul Song, Seugwoog Jung, Choulsoo Jang, and Sunghoon Kim. An introduction to robot component model for opros (open platform for robotic services). (2008). 56, 57 [91] Choulsoo Jang, Byoungyoul Song, Seungwoog Jung, Sunghoon Kim, Byeongcheol Choi, Hyo-Young Lee, and Cheol-Hoon Lee. A development of software component framework for robotic services. Convergence Information Technology, International Conference on 0, 1–6 (2009). 56 [92] Mi-sook Kim and Hong Seong Park. Open platform for ubiquitous robotic services. In Proceedings of the 2012 ACM Conference on Ubiquitous Computing, UbiComp ’12, pages 892–893, New York, NY, USA (2012). ACM. 56 [93] N. Ando, T. Suehiro, K. Kitagaki, T. Kotoku, and Woo-Keun Yoon. RT-middleware : distributed component middleware for RT (robot technology). In 2005 IEEE/RSJ International Conference on Intelligent Robots and Systems, pages 3933–3938. IEEE (2005). 56, 57 [94] Gostai rtc. http://www.gostai.com/products/rtc/. 57 [95] Proteus. http://www.anr-proteus.fr/. 64 [96] Dassault aviation. http://www.dassault-aviation.com/fr/. 64 [97] ECA : Etudes et Constructions Aéronotiques. http://www.eca-robotics. com/. 64 [98] CEA : Commissariat de l’Energie Atomique. http://www.cea.fr/. 64 [99] GOSTAI. http://www.gostai.com/. 64 [100] Intempora. http://www.intempora.com/. 64 142Références bibliographiques [101] Thales. https://www.thalesgroup.com/fr. 64 [102] Lasmea. http://tims.isima.fr/lasmea.php. 64 [103] Thales optronoique sa. https://www.thalesgroup.com/fr/worldwide/ defense/notre-offre-forces-terrestres-c4isr/optronique. 64 [104] Greyc. https://www.greyc.fr/. 64 [105] Inria. http://www.inria.fr/. 64 [106] Onera. http://www.onera.fr/. 64 [107] Prisme. http://www.univ-orleans.fr/prisme. 64 [108] Effidence. http://effistore.effidence.com/. 64 [109] Wifibot. http://www.wifibot.com/. 64 [110] Lip6 : Laboratoire d’Informatique de Paris 6. http://www.lip6.fr. 64 [111] Thomas R. Gruber. Toward principles for the design of ontologies used for knowledge sharing. Int. J. Hum.-Comput. Stud. 43(5-6), 907–928 dec (1995). 65 [112] Gaëlle Lortal, Saadia Dhouib, and Sébastien Gérard. Integrating ontological domain knowledge into a robotic DSL. In Proceedings of the 2010 international conference on Models in software engineering, MODELS’10, Berlin, Heidelberg (2011). Springer-Verlag. 69 [113] RTMAPS : Real-Time, Multisensor, Advanced, Prototyping Software. http: //www.intempora.com/rtmaps4/rtmaps-software/overview.html. 85 [114] URBI : Universal Real-time Behavior Interface. http://www.urbiforge. org/. 85 [115] Arrocam. http://effistore.effidence.com/. 85 [116] Morse. http://www.openrobots.org/wiki/morse/. 85 [117] Cycabtk. http://cycabtk.gforge.inria.fr/. 85 [118] Rtt-lua. http://www.orocos.org/wiki/orocos/toolchain/luacookbook. 87 [119] Davide Brugali, Luca Gherardi, A. Biziak, Andrea Luzzana, and Alexey Zakharov. A Reuse-Oriented Development Process for ComponentBased Robotic Systems. , 7628, pages 361–374. Springer (2012). 100 143Références bibliographiques [120] Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Design Patterns : Elements of reusable object-oriented software. AddisonWesley Publishing (1995). 106, 107 [121] V. Lumelsky and A. Stepanov. Dynamic path planning for a mobile automaton with limited information on the environment. Automatic Control, IEEE Transactions on 31(11), 1058 – 1063 nov (1986). 110, 111, 125 [122] H. Noborio, K. Fujimura, and Y. Horiuchi. A comparative study of sensor-based path-planning algorithms in an unknown maze. , 2, pages 909 –916 vol.2 (2000). 111, 112, 125 [123] A. Sankaranarayanan and M. Vidyasagar. A new path planning algorithm for moving a point object amidst unknown obstacles in a plane. In Robotics and Automation, 1990. Proceedings., 1990 IEEE International Conference on, pages 1930 –1936 vol.3 may (1990). 111 [124] A. Sankaranarayanar and M. Vidyasagar. Path planning for moving a point object amidst unknown obstacles in a plane : a new algorithm and a general theory for algorithm development. In Decision and Control, 1990., Proceedings of the 29th IEEE Conference on, pages 1111 –1119 vol.2 dec (1990). 112, 113, 125 [125] Ishay Kamon. Sensory based motion planning with global proofs. In In Proceedings of the IROS95, pages 435–440 (1995). 112, 113, 125 [126] Ishay Kamon, Elon Rimon, and Ehud Rivlin. Tangentbug : A rangesensor-based navigation algorithm. The International Journal of Robotics Research 17(9), 934–953 September (1998). 114, 115, 125 [127] James Ng and Thomas Bräunl. Performance comparison of bug navigation algorithms. J. Intell. Robotics Syst. 50(1), 73–84 September (2007). 125 144Résumé L’un des challenges des roboticiens consiste à gérer un grand nombre de variabilités. Ces dernières concernent les concepts liés au matériel et aux logiciels du domaine de la robotique. Par conséquent, le développement des applications de robotique est une tâche complexe. Non seulement, elle requiert la maîtrise des détails de bas niveau du matériel et du logiciel mais aussi le changement du matériel utilisé dans une application entraînerait la réécriture du code de celle-ci. L’utilisation de l’ingénierie dirigée par les modèles dans ce contexte est une voie prometteuse pour (1) gérer les problèmes de dépendance de bas niveau des applications des détails de bas niveau à travers des modèles stables et (2) faciliter le développement des applications à travers une génération automatique de code vers des plateformes cibles. Les langages de modélisation spécifiques aux domaines mettent en oeuvre les techniques de l’ingénierie dirigée par les modèles afin de représenter les concepts du domaine et permettre aux experts de celui-ci de manipuler des concepts qu’ils ont l’habitude d’utiliser. Cependant, ces concepts ne sont pas suffisants pour représenter tous les aspects d’une application car ils très généraux. Il faudrait alors s’appuyer sur une démarche pour extraire des abstractions à partir de cas d’utilisations concrets et ainsi définir des abstractions ayant une sémantique opérationnelle. Le travail de cette thèse s’articule autour de deux axes principaux. Le premier axe concerne la contribution à la conception d’un langage de modélisation spécifique au domaine de la robotique mobile (RobotML). Nous extrayons à partir d’une ontologie du domaine les concepts que les roboticiens ont l’habitude d’utiliser pour la définition de leurs applications. Ces concepts sont ensuite représentés à travers une interface graphique permettant la représentation de modèles afin d’assurer une facilité d’utilisation pour les utilisateurs de RobotML. On offre ainsi la possibilité aux roboticiens de représenter leurs scénarios dans des modèles stables et indépendants des plateformes cibles à travers des concepts qu’ils ont l’habitude de manipuler. Une génération de code automatique à partir de ces modèles est ensuite possible vers une ou plusieurs plateformes cibles. Cette contribution est validée par la mise en oeuvre d’un scénario aérien dans un environnement inconnu proposé par l’ONERA. Le deuxième axe de cette thèse tente de définir une approche pour rendre les algorithmes résistants aux changements des détails de ba niveau. Notre approche prend en entrée la description d’une tâche de robotique et qui produit : – un ensemble d’abstractions non algorithmiques représentant des requêtes sur l’environnment y compris le robot ou des actions de haut niveau ; – un ensemble d’abstractions algorithmiques encapsulant un ensemble d’instructions permettant de réaliser une sous-tâche de la tâche étudiée ; – un algorithme générique configurable défini en fonction de ces abstractions. Ainsi, l’impact du changement du matériel et des stratégies définies dans les sous-tâches n’est pas très important. Il suffit d’adapter l’implantation de ces abstractions sans avoir à modifier l’algorithme générique. Cette approche est validée sur six variantes d’une famille d’algorithmes de navigation appelée Bug.Abstract One of the challenges of robotics is to manage a large number of variability. The latter concerns the concepts related to hardware and software in the field of robotics. Therefore, the development of robotic applications is a complex task. Not only it requires mastery of low-level details of the hardware and software but also if we change the used hardware in an application, this would impact the code. The use of model-driven engineering in this context is a promising way to (1) manage low-level dependency problems through stable models and (2) facilitate the development of applications through automatic code generation to target platforms . Domain Specific Modeling Languages implement the model driven engineering technologies to represent the domain concepts and enable experts to manipulate concepts they are used to use. However, these concepts are not sufficient to represent all aspects of an application because they are very general. We would then use an approach to extract abstractions from concrete use cases and thus define abstractions with an operational semantics . The work of this thesis focuses on two main axes. The first concerns the contribution to the design of a domain specific modeling language for mobile robots (RobotML). We extract from a domain ontology concepts that roboticists have used to use to define their applications. These concepts are then represented through a graphical interface representation model to ensure ease of use for RobotML users. An automatic code generation from these models can then be performed to one or more target platforms. This contribution is enabled by setting implement an air scenario, in an unknown environment, proposed by ONERA. The second focus of this thesis attempts to define an approach to make the algorithms resistant to the change of low-level details. Our approach takes as input a description of a task and produces robotic : – a set of non-algorithmic abstractions representing queries on environnment (including robot) or high-level actions ; – a set of algorithmic abstractions encapsulating a set of instructions to perform a sub-task of the studied task ; – a generic configurable algorithm defined according to these abstractions. Thus, the impact of changing hardware and strategies defined in the sub-tasks is not very important. Simply adapt the implementation of these abstractions without changing the generic algorithm. This approach is validated on six variants of a navigation algorithms family called Bug. M´eta-mod´elisation du Comportement d’un Mod`ele de Processus : Une D´emarche de Construction d’un Moteur d’Ex´ecution Sana Mallouli To cite this version: Sana Mallouli. M´eta-mod´elisation du Comportement d’un Mod`ele de Processus : Une D´emarche de Construction d’un Moteur d’Ex´ecution. Modeling and Simulation. Universit´e Panth´eon-Sorbonne - Paris I, 2014. French. HAL Id: tel-01061466 https://tel.archives-ouvertes.fr/tel-01061466 Submitted on 6 Sep 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.DE L’UNIVERSITE PARIS 1 DOCTEUR DE L’UNIVERSITE PARIS 1 Méta-modélisation du Comportement d’un Une Démarche de Construction d Soutenue le 25/07 Slimane Corine Samira Carine SOUVEYET Saïd ASSAR THESE DE DOCTORAT DE L’UNIVERSITE PARIS 1 PANTHEON – SORBONNE Réalisée par : Sana Damak Mallouli Pour l’obtention du titre de : CTEUR DE L’UNIVERSITE PARIS 1 PANTHEON Spécialité : INFORMATIQUE modélisation du Comportement d’un Modè Une Démarche de Construction d’un Moteur d’Exécution Soutenue le 25/07/2014 devant le jury composé de : Slimane HAMMOUDI Membre du jury Corine CAUVET Rapporteur amira SI SAID Rapporteur Carine SOUVEYET Directeur de thèse Saïd ASSAR Encadrant de thèse SORBONNE PANTHEON – SORBONNE Modèle de Processus : Moteur d’Exécution devant le jury composé de : de thèseii iii Remerciements iv Remerciements Comme toute thèse, cette recherche a été ponctuée de nombreux moments d’enthousiasme et de joie, mais également de nombreuses périodes de doute et de découragement. L’achèvement de ce travail n’aurait pas été possible sans la précieuse contribution de nombreuses personnes que je veux remercier ici. Je souhaiterais tout d’abord adresser mes sincères remerciements à la directrice de cette thèse Madame Carine Souveyet, Professeur à l’université Paris1 Panthéon-Sorbonne, pour la confiance qu’elle m’a accordée en acceptant de diriger cette thèse, puis pour m'avoir guidée, encouragée et conseillée, tout au long de ce travail de recherche. Je la remercie infiniment pour m’avoir fait bénéficier de sa grande compétence, de sa rigueur intellectuelle et de ces précieux conseils. Je tiens également à exprimer ma plus vive reconnaissance à mon encadrant de recherche Mr Saïd Assar, Maitre de conférences à Institut Mines Telecom -Telecom Ecole de Management. Il m’a encouragée par ses orientations sans cesser d’être une grande source de motivation et d’enthousiasme. Je le remercie sincèrement pour sa disponibilité, sa persévérance, et ses encouragements continus. Je tiens à le remercier également pour ses qualités humaines d’écoute et son soutien moral pendant les moments difficiles. Je remercie Madame Corine Cauvet, Professeur à l’université Aix-Marseille 3, et Madame Samira Si-Saïd Cherfi, Maître de conférences, HDR à la Conservatoire National des Arts et Métiers (CNAM) Paris, qui ont eu la gentillesse d’accepter le rôle de rapporteur de cette thèse. Elles ont contribué par leurs nombreuses remarques et suggestions à améliorer la qualité de ce mémoire, et je leur en suis très reconnaissante. Je remercie également Mr Slimane Hammoudi, Professeur ESEO, HDR à l’Université d’Angers d’avoir accepté de présider le jury de cette thèse. Je remercie chaleureusement, Madame Colette Rolland, Professeur Emérite à l’Université de Paris 1 Panthéon – Sorbonne, pour la confiance qu’elle m’a témoignée en m’accueillant dans son équipe. Mes remerciements vont également à Mr Camille Salinesi, Professeur - Directeur du Centre de Recherche en Informatique à l’Université de Paris 1 Panthéon – Sorbonne. Je tiens aussi à mentionner le plaisir que j'ai eu à travailler au sein du CRI (Centre de Recherche Informatique) et j'en remercie ici tous les membres pour leurs amitiés et leurs encouragements. Une pensée particulière va à Amina, Assia, Adrian, Ali, Bénédicte, Camille, Carine, Charlotte, Daniel, Elena, Ghazalleh, Hela, Ines, Islem, Kahina, Manuele, Saïd, Salma, Selmine, Raul, Rawia et Rebbeca. Ces années de thèses resteront ancrées dans ma mémoire comme une période très enrichissante de ma vie. Cet aboutissement ne pouvait se réaliser sans être associé au soutien Remerciements v des personnes les plus proches de moi. Merci à mes parents et mes grands parents pour l’affection qu’ils m’ont toujours manifestée et pour leur soutien lors des moments les plus difficiles de cette thèse même quand je suis loin d’eux. Merci à mes adorables sœurs Olfa et Wafa pour leur amour inconditionnel et leur bonne humeur. Merci infiniment à ma bellefamille, à mes proches et à mes amis notamment ma tante Souad et Faten pour leurs encouragements continus. L’affection qu’ils m’ont apportée durant ces années m’a aidée à garder le moral haut et à achever ma thèse. Je garde pour la fin un remerciement particulier pour mon mari, Wissam. Je le remercie du fond du cœur de m’avoir aidée, soutenue, encouragée et surtout aimée. Ces dernières années n’ont pas été très simples, il m’a supportée dans les moments les plus difficiles et m’a aidée à retrouver le sourire pendant les périodes de doute. Pour finir, je souhaiterais dédier ce travail à tous ceux que j’aime. Qu’ils y trouvent ici l’expression de ma profonde affection et de mes plus sincères remerciements. Sana Résumé vi Résumé De nos jours, le nombre de langages de modélisation ne cesse d’augmenter en raison de différentes exigences et contextes (par exemple les langages spécifiques au domaine). Pour être utilisés, ces langages ont besoin d'outils pour réaliser différentes fonctionnalités comme l'édition, la transformation, la validation et l'exécution de modèles conformes à ces langages. La construction de ces outils est un enjeu et un objectif important aussi bien dans la communauté du génie logiciel que celle des Systèmes d’Information. C’est une tâche nontriviale qui fait appel à des approches différentes parmi lesquelles l’utilisation des environnements méta-CASE et des langages de méta-programmation. Par rapport à une approche ad-hoc, les méta-CASE définissent un support outillé et une démarche basée sur la méta-modélisation. Ils apportent des améliorations significatives à la problématique de construction d’outils. Néanmoins, des limitations majeures persistent, notamment pour les langages de modélisation des processus, à cause de la complexité de l’expression de la sémantique opérationnelle d’un modèle de processus et la capture de la logique d’exécution de celui-ci. La construction de ces outils selon une approche ad-hoc engendre un coût élevé, des risques d’erreurs et des problèmes de maintenabilité et de portabilité. En outre, un outil d’exécution de modèle doit satisfaire un critère d’interactivité avec son environnement d’exécution. Cet aspect n’est pas suffisamment pris en compte dans les travaux de recherche actuels sur la spécification des langages de modélisation. Pour répondre à cette problématique, nous proposons dans cette thèse une démarche dirigée par les modèles qui permet de dériver l’architecture d’un moteur d’exécution à partir de la spécification conceptuelle d’un langage de modélisation de processus. Cette spécification repose sur une méta-modélisation élargie qui intègre l’expression de la sémantique d’exécution d’un méta-modèle de processus. Elle est composée, d’une part, d’une structure à deux niveaux d’abstraction qui permet de représenter de manière générique les modèles à exécuter et les instances générées lors de leur exécution. D’autre part, cette spécification est complétée par une représentation déclarative et graphique du comportement du méta-modèle de processus. Pour cette représentation, nous avons choisi un formalisme orienté événement qui reflète la vision systémique et les différentes interactions du modèle de processus avec son environnement. Finalement, afin d’exploiter la sémantique d’exécution, nous proposons des règles de transformation permettant de dériver l’architecture technique d’un outil d’exécution sous une forme standard pour pouvoir l’implémenter dans un environnement de génération de code existant, le code généré correspondra à l’outil d’exécution souhaité. La démarche proposée a été appliquée dans le cas d’un modèle de processus intentionnel appelé Map. Cette application a permis d’explorer la faisabilité de la proposition et d’évaluer la qualité de la spécification de l’outil d’exécution obtenue par rapport aux exigences fixées. La pertinence de notre proposition est qu’elle permet de guider l’ingénieur dans le processus de spécification et de construction d’un outil d’exécution tout en minimisant l’effort de programmation. De plus, en appliquant les étapes de la démarche proposée, nous sommes en mesure de fournir un outil d’exécution d’une certaine qualité ; à savoir un outil interagissant avec son environnement, facilement maintenable et à moindre coût. Abstract vii Abstract Nowadays, the number of modeling languages is increasing due to different requirements and contexts (e.g., domain-specific languages). These languages require appropriate tools to support them by achieving various functionalities such as editing, transforming, validating and implementing models that conform to these languages. The construction of such tools constitutes a challenging goal for both software engineering and information systems communities. This non obvious task is involves different approaches such as meta-CASE and meta-programming languages. Unlike ad-hoc approach, meta-CASE environments define software tools and metamodeling based approaches to improve tools construction. However, major limitations still exist, in particular for process modeling languages, due to the complexity of expressing process model operational semantics and capturing its execution logics. These limitations commonly lead to a manual construction of tools which is labor-intensive, error-prone and poses maintainability and portability issues. Besides, a process model execution tool should satisfy the criterion of interactivity with its environment. This aspect is not sufficiently taken into account in actual research works on the specification of modeling languages. To address this problem, we propose in this thesis a model driven approach to derive the software architecture of an enactment engine from the conceptual specification of the process modeling language. This specification relies on an enlarged meta-modeling approach that includes the expression of the execution semantics of a process meta-model. It consists of a structural specification incorporating both concepts structures and instances that are generated during execution. This specificaiton is completed by a declarative and graphical representation of the process behavioural meta-model. For this representation, an eventoriented paradigm is adopted to reflect the dynamic vision and the different interactions of the process model with its environment. Finally, transformation rules are proposed in order to obtain an enactment engine architecture in an object-oriented form. The enactment engine will be obtained by implementing the object-oriented architecture in an existing code-generation environment. The proposed approach has been applied to the case of an intentional process model called “Map”. This application case aims at evaluating the feasibility of the proposed approach and assessing the quality of the derived enactment engine in regard with initial requirements. The proposed approach is relevant, since on one hand, it allows better guidance for engineers during the specification of the modeling language and the implementation of an enactment tool, and on the other hand, it minimizes programming efforts. In addition, by applying the different steps of the proposed approach, we are able to guarantee a certain quality of the enactment tool ensuring interactivity, maintainability and development low cost. Table des matières Table des matières REMERCIEMENTS .................................................................................................................................... IV RESUME ...................................................................................................................................................... VI ABSTRACT .................................................................................................................................................. VII TABLE DES MATIÈRES ......................................................................................................................... VIII TABLE DES FIGURES .............................................................................................................................. XI TABLE DES TABLEAUX ......................................................................................................................... XV CHAPITRE 1 : INTRODUCTION ......................................................................................................................... 13 1.1. LES OUTILS CASE ................................................................................................................................... 13 1.2. L’IDM ET L’INGENIERIE DES LANGAGES ........................................................................................................ 14 1.3. META-CASE, INGENIERIE DES METHODES ET CAME ...................................................................................... 15 1.4. META-MODELES ET SEMANTIQUE D’EXECUTION ............................................................................................ 17 1.5. CONSTATS ET PROBLEMATIQUE .................................................................................................................. 19 1.6. OBJECTIF DE LA THESE .............................................................................................................................. 19 1.7. DEMARCHE DE RECHERCHE SUIVIE DANS CETTE THESE ..................................................................................... 20 1.8. APERÇU DE LA SOLUTION PROPOSEE ............................................................................................................ 21 1.9. PLAN DE LA THESE ................................................................................................................................... 23 CHAPITRE 2 : PROJET EXPLORATOIRE ............................................................................................................. 25 2.1. INTRODUCTION ....................................................................................................................................... 25 2.2. MOTIVATION POUR LE PROJET EXPLORATOIRE ............................................................................................... 25 2.2.1. Un outil d’exécution pour le Map .................................................................................................. 25 2.2.2. Exploration de la nouvelle technologie méta-CASE ....................................................................... 26 2.3. METHODOLOGIE DE L’EXPERIMENTATION ..................................................................................................... 26 2.4. DESCRIPTION DU PROJET EXPLORATOIRE ...................................................................................................... 28 2.4.1. L’approche d’évaluation du projet exploratoire ............................................................................ 28 2.4.2. L’outil MetaEdit+ ........................................................................................................................... 28 2.4.3. Le modèle de processus : Map....................................................................................................... 31 2.4.4. La sémantique opérationnelle du modèle Map ............................................................................. 32 2.4.5. Le cas d’application : La méthode CREWS l’Ecritoire ..................................................................... 34 2.4.6. Le développement du prototype ................................................................................................... 39 2.5. LES RESULTATS DE L’EXPERIMENTATION ....................................................................................................... 46 2.5.1. Le méta-modèle de produit ........................................................................................................... 46 2.5.2. Le méta-modèle de processus ....................................................................................................... 47 2.5.3. Le moteur d’exécution de la carte de CREWS L’Ecritoire ............................................................... 48 2.6. EVALUATION DE L’EXPERIMENTATION .......................................................................................................... 51 2.6.1. Les critères d’évaluation ................................................................................................................ 51 2.6.2. Les résultats de l’évaluation .......................................................................................................... 52 2.6.3. Exigences fondamentales pour une méta-modélisation des processus dans les outils méta-CASE 53 2.7. CONCLUSION .......................................................................................................................................... 54 CHAPITRE 3 : ETAT DE L’ART ........................................................................................................................... 56 3.1. EXEMPLES INTRODUCTIFS .......................................................................................................................... 56 3.2. PRESENTATION DES CONCEPTS ................................................................................................................... 58 3.2.1. La construction des outils .............................................................................................................. 58 3.2.2. L’ingénierie des méthodes ............................................................................................................. 59 3.2.3. Les méta-outils et les CAME .......................................................................................................... 60 3.2.4. La méta-modélisation .................................................................................................................... 61 3.2.5. Les langages de méta-modélisation .............................................................................................. 63 3.3. DE L’EXECUTION DES PROGRAMMES VERS L’EXECUTABILITE DES MODELES ........................................................... 64 3.3.1. Quelques définitions ...................................................................................................................... 64Table des matières ix 3.3.2. L’exécutabilité des modèles ........................................................................................................... 68 3.3.3. L’expression de l’exécutabilité des modèles .................................................................................. 69 3.4. EXEMPLES DE LANGAGES DE META-MODELISATION ........................................................................................ 70 3.4.1. Meta Object Facility (MOF) ........................................................................................................... 70 3.4.2. Ecore .............................................................................................................................................. 71 3.4.3. GOPRR ........................................................................................................................................... 73 3.4.4. Synthèse sur les langages de méta-modélisation .......................................................................... 75 3.5. LES APPROCHES DE CONSTRUCTION D’OUTILS D’EXECUTION DE MODELES ........................................................... 75 3.5.1. Approche ad-hoc ........................................................................................................................... 75 3.5.2. Eclipse Modeling Framework (EMF) .............................................................................................. 76 3.5.3. Méta-programmation avec Kermeta ............................................................................................ 77 3.5.4. Spécification de systèmes industriels avec TOPCASED .................................................................. 79 3.5.5. Exécution des processus d’ingénierie avec UML4SPM .................................................................. 80 3.5.6. Méta-modélisation et génération de code avec MetaEdit+ .......................................................... 81 3.5.7. Méta-modélisation déclarative avec Concept Base ...................................................................... 82 3.5.8. Méta-modélisation et grammaire des attributs avec JastAdd et JastEMF .................................... 84 3.5.9. Ingénierie des méthodes basée sur l’IDM avec Moskitt4ME ......................................................... 85 3.6. NOTRE GRILLE DE COMPARAISON................................................................................................................ 86 3.6.1. Les critères de comparaison .......................................................................................................... 86 3.6.2. Le tableau de comparaison ........................................................................................................... 89 3.7. ANALYSE DE L’ETUDE COMPARATIVE ........................................................................................................... 93 3.8. CONCLUSION .......................................................................................................................................... 93 CHAPITRE 4 : PROPOSITION D’UNE DEMARCHE IDM POUR LA CONSTRUCTION D’OUTILS D’EXECUTION ....... 95 4.1. INTRODUCTION ....................................................................................................................................... 95 4.2. UNE APPROCHE IDM POUR L’INGENIERIE D’OUTILS D’EXECUTION ..................................................................... 97 4.3. UNE VUE DETAILLEE DE LA DEMARCHE PROPOSEE ........................................................................................... 98 4.3.1. La 1ère étape : La spécification structurelle du méta-modèle de processus ................................... 99 4.3.2. La 2ème étape : Compléter la spécification structurelle par une spécification du comportement du méta-modèle ............................................................................................................................................. 102 4.3.3. La 3ème étape : Transformation pour obtenir une architecture orientée objet de l’outil d’exécution 103 4.4. ETAPE 1 : LA SPECIFICATION STRUCTURELLE DU META-MODELE DE PROCESSUS .................................................. 104 4.4.1. Le méta-modèle de diagramme de classes ................................................................................. 105 4.4.2. Exemple d’un diagramme de classes UML .................................................................................. 105 4.5. ETAPE 2 : LA SPECIFICATION GRAPHIQUE DE LA SEMANTIQUE D’EXECUTION ...................................................... 108 4.5.1. Pourquoi le modèle Remora ? ..................................................................................................... 108 4.5.2. Le modèle événementiel .............................................................................................................. 109 4.5.3. Le schéma dynamique de la sémantique opérationnelle du Méta-Modèle de Processus ........... 126 4.6. ETAPE 3: TRANSFORMATION DU MODELE COMPORTEMENTAL VERS UN MODELE OBJET TECHNIQUE STANDARD ........ 129 4.6.1. Formalisation des schémas d’entrée et de sortie pour la transformation ................................... 130 4.6.2. La dérivation de l’architecture objet de l’outil d’exécution à partir de la sémantique opérationnelle ............................................................................................................................................ 134 4.6.3. Les principes de la gestion événementielle.................................................................................. 134 4.6.4. Règle n°1 : Cas d’un événement interne ...................................................................................... 137 4.6.5. Règle n°2: Cas d’un événement externe avec réception d’un message ....................................... 144 4.6.6. Règle n°3 : Cas d’une opération externe vers un acteur externe ................................................. 149 4.6.7. Règles spécifiques à EngineContext ............................................................................................ 155 4.7. ADAPTATION DE LA SPECIFICATION OO DE L’ARCHITECTURE DE L’OUTIL A UNE PLATEFORME CIBLE ......................... 157 4.8. L’ORIGINALITE DE NOTRE PROPOSITION ...................................................................................................... 158 4.9. CONCLUSION ........................................................................................................................................ 159 CHAPITRE 5 : APPLICATION DE LA DEMARCHE AU CAS DU MAP ET VALIDATION.......................................... 160 5.1. INTRODUCTION ..................................................................................................................................... 160 5.2. ETAPE 1 : COMPLETER LE META-MODELE DU MAP PAR LA STRUCTURE DES INSTANCES ........................................ 162 5.2.1. La structure des concepts du méta-modèle Map ........................................................................ 162 5.2.2. La spécification structurelle à deux niveaux relative au méta-modèle Map ............................... 163Table des matières x 5.3. ETAPE 2 : COMPLETER LA SPECIFICATION A 2 NIVEAUX PAR L’EXPRESSION DE LA SEMANTIQUE D’EXECUTION ........... 167 5.3.1. La démarche suivie pour l’élaboration du schéma dynamique ................................................... 167 5.3.2. Le schéma dynamique relatif au méta-modèle du Map .............................................................. 168 5.4. ETAPE 3 : TRANSFORMATION DES SPECIFICATIONS VERS UNE ARCHITECTURE ORIENTE OBJET DU MOTEUR D’EXECUTION 172 5.4.1. Exemple d’application de la règle n°1 ......................................................................................... 173 5.4.2. Exemple d’application de la règle n°2 ......................................................................................... 175 5.4.3. Exemple d’application de la règle n°3 ......................................................................................... 176 5.4.4. Exemple d’applications des transformations relatives à la structure à 2 niveaux et à l’acces aux données 179 5.5. EVALUATION DE LA DEMARCHE ................................................................................................................ 180 5.6. CONCLUSION ........................................................................................................................................ 182 CHAPITRE 6 : CONCLUSION ET PERSPECTIVES ............................................................................................... 184 6.1. CONCLUSION ........................................................................................................................................ 184 6.1.1. Rappel de la problématique ........................................................................................................ 184 6.1.2. Bilan du travail réalisé ................................................................................................................. 185 6.2. PERSPECTIVES ....................................................................................................................................... 187 BIBLIOGRAPHIE .................................................................................................................................... 189 ANNEXES ................................................................................................................................................. 199 ANNEXE 1: LISTE DES FONCTIONS DU SCRIPT SCRIPT1_MAP_PROCESS ........................................................ 199 ANNEXE 2: LISTE DES JOINTURES DU SCRIPT SCRIPT4_MAP_LINKS .............................................................. 200 ANNEXE 3: PROCÉDURE FOREACH .STRATEGY, SCRIPT SCRIPT5_MAP_INIT .................................................. 200 ANNEXE 4: PROCÉDURE FOREACH .INTENTION, SCRIPT SCRIPT5_MAP_INIT ................................................ 200 ANNEXE 5: PROCESSUS DU CALCUL DES CANDIDATES .................................................................................. 201 ANNEXE 6: INITIAL GOAL IDENTIFICATION STRATEGY .................................................................................. 205 ANNEXE 7: L’INTERFACE DE LA STRATEGIE « FREE PROSE » PERMETTANT A L’UTILISATEUR DE SAISIR SON SCENARIO. .................................................................................................................................................... 206 ANNEXE 8: L’INTERFACE DE LA STRATEGIE « SCENARIO PREDEFINED STRUCTURE » QUI PERMET DE CHOISIR UN SCENARIO PREDEFINIE............................................................................................................................ 206 ANNEXE 9: L’INTERFACE DE LA STRATEGIE « MANUAL » : QUI PERMET A L’UTILISATEUR DE CONCEPTUALISER SON SCENARIO DE MANIERE MANUELLE. ..................................................................................................... 207 ANNEXE 10: SPECIFICATION EVENEMENTIELLE EN XML DE L’EXEMPLE DU WORKFLOW ............................... 207 ANNEXE 11 : L’ARCHITECTURE OO DU MOTEUR D’EXECUTION DU MAP ...................................................... 211 Table des figures Table des figures Figure 1. Les fonctionnalités d’un outil CASE dans l’ingénierie des SI ................................. 13 Figure 2. Les fonctionnalités d’un outil méta-CASE ............................................................... 16 Figure 3. Exemple de conception d’un CASE pour le modèle E/R avec l’outil MetaEdit+ .... 16 Figure 4. Schéma générique pour un moteur d’exécution ....................................................... 18 Figure 5. Les étapes de la démarche de recherche suivie ......................................................... 20 Figure 6. Aperçu de l’approche ................................................................................................ 21 Figure 7. Interface graphique principale de l’outil MetaEdit+................................................. 29 Figure 8. L’interface de l’éditeur d’objet dans MetaEdit+ ....................................................... 30 Figure 9. Extrait d’une carte de conception d’un schéma de classes ....................................... 31 Figure 10. Le méta-modèle du Map ......................................................................................... 32 Figure 11. Un exemple d’une carte Map .................................................................................. 33 Figure 12. Une illustration des sections candidates ................................................................. 33 Figure 13. Map de CREWS l’Ecritoire .................................................................................... 35 Figure 14. La structure d’un fragment de besoin ..................................................................... 37 Figure 15. Les deux niveaux d’abstraction de la structure du produit et d’un processus (Edme, 2005) ............................................................................................................................ 37 Figure 16. Relation entre parties du produit construit et réalisations d’intentions. ................. 38 Figure 17. Aperçu de la méta-démarche suivie dans le projet avec MetaEdit+ ....................... 39 Figure 18. Représentation de l’architecture de l’outil d’exécution ......................................... 40 Figure 19. Base de données générée pour notre moteur d’exécution ....................................... 43 Figure 20. Le méta-modèle de produit : formalisme Entité/Relation exprimé en GOPRR ..... 47 Figure 21. Le méta-modèle statique du formalisme de carte Map défini avec GOPRR .......... 47 Figure 22. Le modèle du processus CREWS L’Ecritoire défini dans l’outil CASE cible ....... 48 Figure 23. La structure de la DB du moteur du Map ............................................................... 49 Figure 24. Interface Graphique du Moteur d’exécution ........................................................... 49 Figure 25. Un extrait du méta-modèle SPEM (SPEM, 2008) .................................................. 57 Figure 26. Méta-modèle de workflow (Hollingsworth, 1996) ................................................. 58 Figure 27. Le croisement des préoccupations des deux communautés SI et GL ..................... 59 Figure 28. Environnement CAME ........................................................................................... 61 Figure 29. Notions de base de la méta-modélisation ............................................................... 62 Figure 30. Les concepts principaux de MOF 1.4 (Blanc, 2005) .............................................. 71 Figure 31. Les concepts du méta-modèle Ecore ..................................................................... 72 Figure 32. Les concepts du langage GOPRR ........................................................................... 74 Figure 33. Architecture d’EMF ................................................................................................ 76 Figure 34. Méta-modèle de Kermeta (Zoé et al., 2009) ........................................................... 77 Figure 35. Définition d’une opération en Kermeta (sémantique opérationnelle) .................... 79 Figure 36. Vue globale du méta-modèle UML4SPM (Bendraou, 2007) ................................. 80 Figure 37. Architecture générale de MetaEdit+ (Kelly et al., 1996) ........................................ 82 Figure 38. Éditeur graphique de l’outil ConceptBase : un exemple d’instanciation du modèle ‘entité-association’ en 4 niveaux d’abstraction ........................................................................ 83 Figure 39. Aperçu de l’approche moskitt4ME (Cervera et al., 2012) ...................................... 85 Figure 40. La grille de comparaison des méta-outils ............................................................... 86 Figure 41. Un aperçu de la démarche proposée ....................................................................... 96 Figure 42. Le synopsis de notre proposition pour la construction d’outils d’exécution .......... 97 Figure 43. La vue détaillée de notre proposition ...................................................................... 98 Figure 44. Le principe de dérivation de la structure d’instances à partir de la structure des concepts .................................................................................................................................. 100Table des figures xii Figure 45. La sémantique d’exécution par rapport aux niveaux d’abstraction d’un modèle de processus ................................................................................................................................ 100 Figure 46. L’expression explicite de la sémantique d’exécution grâce au modèle événementiel ................................................................................................................................................ 102 Figure 47. Le méta-modèle de diagramme de classes UML (Blanc, 2005) ........................... 105 Figure 48. Le diagramme de classes simplifié du méta-modèle de Workflow ...................... 106 Figure 49. L’architecture à deux niveaux du méta-modèle de Workflow ............................. 107 Figure 50. Le modèle d’événement Remora .......................................................................... 109 Figure 51. La structure du concept Objet ............................................................................... 110 Figure 52. La structure du concept Opération ........................................................................ 110 Figure 53. Le modèle événementiel et sa représentation graphique ...................................... 112 Figure 54. La forme graphique de la structure du concept Evénements ................................ 113 Figure 55. La forme textuelle de la structure du concept d’Evénement ................................ 113 Figure 56. La structure d’un événement interne. ................................................................... 114 Figure 57. Un exemple d’événement interne ......................................................................... 114 Figure 58. La représentation textuelle de l’exemple d’un événement interne ....................... 115 Figure 59. La structure d’un événement externe .................................................................... 115 Figure 60. La structure du concept Message .......................................................................... 116 Figure 61. Un exemple d’événement externe ......................................................................... 116 Figure 62. La représentation textuelle de l’exemple d’un événement externe ....................... 116 Figure 63. La structure du concept Acteur ............................................................................. 117 Figure 64. La forme textuelle de la structure du concept Acteur ........................................... 117 Figure 65. La structure du concept Opération-Externe .......................................................... 118 Figure 66. La forme textuelle de la structure du concept Opération-Externe ........................ 118 Figure 67. Un exemple illustrant les acteurs du workflow et leurs interactions avec l’outil . 119 Figure 68. Un exemple illustratif du concept Acteur ............................................................. 120 Figure 69. La structure d’un Trigger ...................................................................................... 121 Figure 70. Forme textuelle de la structure d’un Trigger ........................................................ 122 Figure 71. Les deux concepts Condition et Facteur ............................................................... 122 Figure 72. Un exemple d’un Facteur ...................................................................................... 122 Figure 73. Un exemple d’un trigger extrait du modèle dynamique de workflow .................. 123 Figure 74. Un exemple illustratif d’un Trigger ...................................................................... 124 Figure 75. La structure du modèle Remora étendu en format XML graphique ..................... 125 Figure 76. Le schéma dynamique du méta-modèle de Workflow (exemple simplifié) ......... 127 Figure 77. Un extrait de la spécification en XML du schéma dynamique de workflow ....... 128 Figure 78. La 3ème étape de la proposition: La transformation ............................................... 129 Figure 79. La relation entre le méta-modèle UML et le méta-modèle événementiel ............ 130 Figure 80. Le méta-modèle source de la transformation ........................................................ 131 Figure 81. Les documents XML qui représentent les entrées de l’étape de transformation .. 131 Figure 82. Le méta-modèle cible de la transformation .......................................................... 132 Figure 83. Les trois situations de comportement possibles dans un modèle événementiel ... 133 Figure 84. Le principe de gestion d’une interaction interne .................................................. 135 Figure 85. Le principe de gestion d’une interaction formalisée dans un événement externe 136 Figure 86. Le principe de gestion d’une interaction externe avec message sortant ............... 136 Figure 87. Schéma d’un événement interne ........................................................................... 137 Figure 88. La règle de transformation n°1 : cas d’un événement interne .............................. 140 Figure 89. Un exemple générique pour la construction des objets observés et objets dynamiques ............................................................................................................................. 140 Figure 90. Le diagramme de séquence pour la création des objets relatifs à un événement interne ..................................................................................................................................... 141Table des figures xiii Figure 91. Le diagramme de séquence pour l’exécution d’un événement interne ................. 141 Figure 92. Un extrait du diagramme de classes de workflow après application de la règle n°1 ................................................................................................................................................ 142 Figure 93. Le diagramme de séquence pour la création des objets correspondant à l’événement interne EV5 du workflow .................................................................................. 143 Figure 94. Le diagramme de séquence pour l’exécution de l’événement interne EV5 du workflow ................................................................................................................................ 143 Figure 95. Le schéma d’un événement externe : action provenant d’un acteur ..................... 144 Figure 96. Les règles de transformation dans le cas d’un événement externe ....................... 146 Figure 97. Extrait du diagramme de séquence pour la création des objets suite à l’arrivée d’un événement externe .................................................................................................................. 147 Figure 98. Le diagramme de séquence pour l’exécution d’un événement externe ................ 147 Figure 99. Un extrait du diagramme de classes de workflow obtenu par l’application de la règle n°2 ................................................................................................................................. 148 Figure 100. Extrait du diagramme de séquence obtenu par l’application de la règle n°2 pour l’initialisation de l’événement externe EV1 du modèle de workflow ................................... 148 Figure 101. Le diagramme de séquence pour l’exécution de l’événement externe EV1 du modèle de workflow ............................................................................................................... 149 Figure 102. Le schéma d’une opération externe .................................................................... 149 Figure 103. La règle n°3 pour la transformation d’une opération externe (Cas1) ................ 151 Figure 104. Extrait du diagramme de séquence pour la création des objets lors d’une opération externe (Cas1) ........................................................................................................................ 151 Figure 105. Le diagramme de séquence relatif à l’exécution d’une opération externe (Cas 1) ................................................................................................................................................ 152 Figure 106. La règle n°3 pour la transformation d’une opération externe (Cas2) ................ 153 Figure 107. Extrait du diagramme de séquence pour la création des objets lors d’une opération externe (Cas2) ........................................................................................................................ 153 Figure 108. Le diagramme de séquence relatif à l’exécution d’une opération externe (Cas 2) ................................................................................................................................................ 153 Figure 109. Un extrait du diagramme de classes de workflow après application de la règle n°3 : Exemple de l’opération externe déclenchée par l’événement EV2 .......................... 154 Figure 110. Un extrait du diagramme de séquence pour l’opération externe NotifierAffectation dans l’exemple du workflow ............................................................................... 154 Figure 111. Un exemple de diagramme de séquence relatif àl’exécution d’une opération externe (Cas1) ........................................................................................................................ 155 Figure 112. Les classes et les diagrammes générés par l’application de la règle R12 pour la gestion des liens de référence entre les classes de la structure à deux niveaux ..................... 156 Figure 113. Règle de transformation pour la gestion des classes du niveau « type » et du niveau « instance » ................................................................................................................. 157 Figure 114. Variable de classe et méthode de classe de la classe globale EngineContext ..... 157 Figure 115. Une vue globale de l’application de la démarche proposée dans le cas du Map 160 Figure 116. Les étapes de la démarche proposée appliquées dans le cas du Map ................. 161 Figure 117. Le diagramme de classes du méta-modèle du Map (M2) ................................. 162 Figure 118. Le principe de dérivation de la structure des instances pour le cas du Map ....... 163 Figure 119. La spécification à deux niveaux (concept-type et instances) duméta-modèle Map ................................................................................................................................................ 164 Figure 120. Le diagramme de séquence du méta-modèle Map .............................................. 166 Figure 121. La démarche suivie pour l’élaboration du schéma dynamique ........................... 167 Figure 122. Les modules qui interagissent avec le moteur d’exécution ................................ 170 Figure 123. Le schéma dynamique du Map en utilisant le formalisme Remora étendu ........ 170Table des figures xiv Figure 124. Le résultat de l’application de la règle de transformation n°1 au modèle Map .. 173 Figure 125. Le diagramme de séquence résultant de l’application de la règle n°1 : Exemple d’initialisation des objets pour l’événement interne EV6 du modèle Map ............................ 174 Figure 126. Le diagramme de séquence résultant de l’application de la règle n°1 : Exemple d’exécution de l’événement interne EV6 du modèle Map ..................................................... 174 Figure 127. La structure des classes obtenue par l’application de la règle de transformation n°2 au Map ............................................................................................................................. 175 Figure 128. Un extrait du diagramme de séquence résultant de l’application de la règle n°2 : Exemple d’initialisation pour l’événement externe EV1 du Map .......................................... 176 Figure 129. Le diagramme de séquence résultant de l’application de la règle n°2 : Exemple d’exécution de l’événement externe EV1 du Map ................................................................. 176 Figure 130. Les classes résultant de l’application de la règle de transformation n°3 au modèle Map ......................................................................................................................................... 177 Figure 131. Un extrait du diagramme de séquence relatif à l’application de la règle n°3 pour l’initialisation d’une opération externe : Exemple EV12 du Map ......................................... 178 Figure 132. Un extrait du diagramme de séquence relatif à l’application de la règle n°3 pour l’exécution d’une opération externe : Exemple EV12 du Map .............................................. 178 Figure 133. Exemple d’application des règles relatives à la gestion de la structure à deux niveaux ................................................................................................................................... 179 Figure 134. La Classe globale EngineContext relative au Map ............................................. 180 Figure 135. Le principe de transformation de modèle en IDM .............................................. 188 Table des tableaux Table des tableaux Tableau 1. Les intentions de la carte de CREWS L’Ecritoire .................................................. 35 Tableau 2. Les stratégies de la carte de CREWS L’Ecritoire .................................................. 35 Tableau 3. Les sections de la carte de CREWS L’Ecritoire ..................................................... 36 Tableau 4. Récapitulatif des tables de la Base de données ...................................................... 44 Tableau 5. Les critères d’évaluation ........................................................................................ 52 Tableau 6. Les résultats de l’évaluation du projet .................................................................... 52 Tableau 7. Comparaison entre langage de modélisation et langages de programmation (Kleppe, 2008) .......................................................................................................................... 65 Tableau 8. Le domaine des valeurs des attributs d’état dans le modèle Map ........................ 165 Tableau 9 . La liste des opérations de la structure des instances ........................................... 165 Tableau 10. La liste des événements du schéma dynamique du méta-modèle Map ............. 168 Tableau 11. La liste des messages du schéma dynamique du méta-modèle Map .................. 169 Tableau 12. Le tableau comparatif pour évaluation de la démarche proposée ...................... 181Chapitre 1 : Introduction 13 CHAPITRE 1 : INTRODUCTION 1.1. Les Outils CASE La complexité croissante des systèmes d’information (SI) rend le développement des SI lourd et coûteux (Giraudin, 2007). Afin de maitriser cette complexité, différentes techniques et approches sont proposées par l’ingénierie des SI (ISI). Le but des outils connus sous le nom d’Ateliers de Génie Logiciel (CASE en anglais pour Computer-Aided Software Engineering) est d’assister et d’aider l’ingénieur à concevoir et développer des SI (Fuggetta, 1993) grâce à un ensemble de fonctionnalités permettant d'alléger le travail de l’ingénieur et aussi d'introduire l'automatisation dans la mise en œuvre d’une méthode d’ingénierie (Figure 1). Figure 1. Les fonctionnalités d’un outil CASE dans l’ingénierie des SI Comme exemples d’outil CASE, on peut citer StarUML1 , Power AMC2 , WebRatio3 , NetBeans4 , Rational Rose5 , Eclipse6 . Ces outils proposent diverses fonctionnalités avec des niveaux de sophistication variables, et ne couvrent pas forcément les mêmes phases du cycle de vie d’un système. Une distinction courante est entre upper- et lower-CASE (Fuggetta, 1993). Un upper-CASE est dédié aux phases d'analyse et de conception et il est généralement associé à une méthode d’ingénierie de SI. Il inclut des interfaces graphiques pour éditer les spécifications d’un système et des dictionnaires de données pour les stocker, des fonctions pour gérer la documentation, des moyens de contrôle de qualité et de correction de schémas. Un lower-CASE est destiné aux phases d’implémentation avec des éditeurs syntaxiques, des librairies de programmes, des compilateurs, des générateur d'interfaces homme/machine, ou encore des outils pour la mise au point de programmes et la configuration des codes sources. La distinction entre lower- et upper-CASE s’estompe lorsque l’outil intègre des fonctionnalités de génération de code et de transformation de modèle, c’est ce que préconise l’ingénierie dirigée par les modèles. 1 http://staruml.sourceforge.net/en/ 2 http://wikipedia.org/wiki/PowerAMC 3 http://www.webratio.com/ 4 https://netbeans.org/ 5 http://www.ibm.com/developerworks/rational/products/rose/ 6 Eclipse : http://www.eclipse.org/ Ingénieur SI Spécification du Edition système Validation Exécution ou simulation OutilCASE Transformation ou génération de code Application Langage de modélisation Utilisateur finalChapitre 1 : Introduction 14 1.2. L’IDM et l’ingénierie des langages Les outils CASE jouent un rôle important dans l’ingénierie dirigée par les modèles (IDM ou MDE7 ). En effet, l’IDM place les modèles au centre du processus d’ingénierie des systèmes, et grâce à des outils logiciels adéquats, attribue aux modèles une fonction productive par opposition au rôle contemplatif8 habituel (Favre, 2006). Cette production s’effectue à travers des transformations, pour aller vers une génération automatique – ou semi automatique – de logiciels pour des plateformes d’implémentation cibles. Avec le développement de l’IDM, la construction des outils CASE est devenue un enjeu et un objectif important. C’est une tâche non-triviale qui fait appel à la définition de langages de modélisation et à l’implémentation de fonctionnalités non seulement de transformation et de génération de code mais aussi de test, vérification et exécution. Elle soulève des questionnements multiples : Quelle architecture pour l’outil? Quelles fonctionnalités à fournir? Est ce qu’on cherche à développer un générateur de code, un moteur d’exécution ou simplement un éditeur de modèles? Comment implémenter chacune de ces fonctionnalités? Comment garantir certaines propriétés de l’outil telles que la portabilité (en cas d’évolution de la plateforme sur laquelle s’exécute l’outil), la maintenabilité (en cas d’évolution des langages de modélisation), ou la réutilisabilité (en cas de développement de nouveaux langages)? Enfin, quelles méthodes et quels (méta-) outils pour concevoir, spécifier et implémenter ces outils? Pour traiter ces problématiques, en plus de l’IDM, un domaine de recherche complémentaire a émergé : l’ingénierie des langages pour le génie logiciel9 (Kleppe, 2009), (Favre et al., 2009). Il est à l’intersection de multiples thématiques de l’ingénierie des SI et du génie logiciel telles que la modélisation conceptuelle et la transformation de modèles, l’ingénierie des méthodes, la méta-modélisation, les outils méta-CASE, les langages spécifiques au domaine (ou DSM10) ou encore la compilation et les langages de programmation. La problématique des langages pour le génie logiciel dépasse le cadre restreint des langages de programmation (tels que C ou Java). Les langages de génie logiciel sont des artéfacts au cœur du développement de différents domaines d’ingénierie informatique. Ils sont conçus et développés pour résoudre une problématique générique de représentation de systèmes (UML, XML), ou des problématiques plus spécifiques telles que l’exécution des processus à base de services web (BPEL11), l’ingénierie des besoins (i*12 , Tropos13) ou la modélisation des processus d’ingénierie (SPEM14). La spécification de tels langages, et surtout la construction d’outils pour les accompagner, sont au cœur du sujet de cette thèse. 7 MDE: Model-Driven Engineering 8 (un modèle contemplatif est utilisé pour représenter graphiquement une spécification conceptuelle ou bien pour la documentation et la compréhension d’un projet 9 SLE: Software Language Engineering 10 DSM: Domain Specific Modeling 11 BPEL: Business Process Execution Language 12 i*: http://www.cs.toronto.edu/km/istar/ 13 Tropos: http://www.troposproject.org/ 14 SPEM: Software Process Engineering Metamodel Chapitre 1 : Introduction 15 1.3. Méta-CASE, ingénierie des méthodes et CAME Apparue dans les années 1990, l’objectif de la technologie méta-CASE est de faciliter et accélérer la conception et le développement d'outils CASE dédiés à une méthode d’ingénierie particulière (Alderson, 1991) (Smolander et al., 1991). Alors que la méthode est prédéfinie dans un outil CASE, les outils méta-CASE permettent la personnalisation et la construction de méthodes d’ingénierie afin de les adapter aux besoins spécifiques des ingénieurs (Kelly et Smolander, 1996) (Assar et al., 2012). La technologie méta-CASE introduit un niveau d’architecture supplémentaire pour la spécification de la méthode que l’ingénieur souhaite outiller. Alors qu’une méthode comporte des « produits » (tout livrable ou artéfact produit par l’application de la méthode) et des « processus » (des cheminements suivis pour aboutir aux produits) (Olle, 1988), il est fréquent dans la littérature des méta-CASE qu’une méthode soit restreinte à sa composante « produit ». C’est le cas notamment dans les premières publications de l’outil MetaEdit+ par exemple (Smolander et al., 1991) (Kelly et al., 1996), où par la suite, c’est la spécificité du « produit » pour un domaine qui est mise en avant (Kelly et Tolvanen, 2008) (Kelly et al., 2013). L’ingénierie des méthodes a grandement contribué à expliciter l’importance du processus dans la description d’une méthode (Brinkkemper et al., 1996). Et c’est dans le domaine des environnements de génie logiciel centrés processus (PCSE15 ou PSEE16) que plusieurs langages ont été proposés pour modéliser et spécifier les processus d’ingénierie logiciel (Fuggetta, 1996) (Zamli and Lee, 2001)(Arbaoui et al., 2002). Le terme CAME17 a été introduit pour désigner des outils logiciels semblables aux méta-CASE, la différence se situant surtout au niveau de la finalité : pour un méta-CASE, c’est la génération d’un outil spécifique (pour un langage de modélisation de produit) ; pour un CAME, c’est la spécification d’une méthode avec les deux perspectives « produit » et « processus » (Heym et Österle, 1993) (Saeki, 2003). Ces deux termes sont souvent semblables sinon identiques étant donné que la spécification d’une méthode nécessite la construction d’un outil correspondant. L’outil MetaEdit+ est ainsi mentionné dans la littérature en tant que méta-CASE pour l’outillage des DSM, mais aussi en tant qu’environnement CAME pour outiller des méthodes (Kelly et Tolvanen, 2008) (Niknafs and Ramsin, 2008) (Kelly et al., 2013). Le niveau d’architecture supplémentaire qu’introduit les méta-CASE et les CAME inclut, d’une part, des langages de modélisation et de méta-modélisation pour la méta-spécification d’une méthode, et d’autre part, des fonctionnalités pour la construction (ou génération semiautomatique) d’un outil CASE à partir de cette méta-spécification. Le langage de métamodélisation sert à définir les méta-modèles de la méthode, c'est-à-dire les méta-modèles de produit et de processus. Un méta-modèle de produit contient les concepts, les règles et les notations graphiques du langage de modélisation des produits dans une méthode donnée. Par exemple, un méta-modèle d’UML (ou de BPMN18 respectivement) spécifie des concepts tels que ‘classe’ et ‘héritage’ (ou ‘tâche’ et ‘événement’ respect.) et des liens entre ces concepts. 15 PCSE: Process Centred Software Engineering 16 PSEE: Process-centred Software Engineering Environments 17 CAME: Computer Aided Method Engineering 18 Business Process Modeling Notation Chapitre 1 : Introduction 16 Figure 2. Les fonctionnalités d’un outil méta-CASE L’ingénieur outil utilise le langage de méta-modélisation pour définir les méta-modèles de la méthode pour laquelle il souhaite construire un outil CASE (Figure 2). Pour la perspective « produit », cette méta-définition doit couvrir les trois facettes fondamentales d’un langage de modélisation : la syntaxe abstraite19 (les concepts et les liens entre ces concepts), la syntaxe concrète (la forme extérieure – graphique ou textuelle – des concepts et des liens) et la sémantique (le sens attribué à ces concepts). Figure 3. Exemple de conception d’un CASE pour le modèle E/R avec l’outil MetaEdit+ Dans l’outil MetaEdit+ (Kelly and Smolander, 1996) par exemple, la méta-spécification s’exprime avec le langage de méta-modélisation GOPRR 20. Un outil CASE cible dérivé à partir de cette méta-spécification comporte par défaut des fonctionnalités d’édition de modèle. 19 La syntaxe abstraite est généralement définie, en IDM, sous la forme d’un ensemble de classes et un modèle issu du langage est un ensemble d’objets, instances de ces classes. 20 GOPRR: Graph, Object, Property, Relationship, Role Ingénieur outil Méta-Spécification Du langage de modélisation Edition Validation Outil méta-CASE Langage de méta- modélisation Ingénieur SI ? Personnalisation ou dérivation de l’outil Exécution ou simulation Outil CASE Générer Méta-modèle E/R en GOPRR Scripts en MERL Éditeur de modèles E/R SQL Créer le script à partir du MM E/RChapitre 1 : Introduction 17 Le méta-modèle peut être complété par des scripts écrits dans un méta-langage spécifique (MERL). Ces scripts, qui incluent des commandes de navigation dans les instances des métamodèles, peuvent décrire un comportement permettant à l’outil CASE cible d’avoir une fonctionnalité de génération de code. La figure 3 illustre cette démarche pour construire un outil de modélisation à base de la notation Entité/Relation. Le générateur de code implémente les règles de transformation de structure du type « une entité devient une table » ou « une association de cardinalité 1- N devient une clé étrangère ». Alors que la phase de méta-modélisation se fait d’une manière déclarative et avec des outils graphiques, le processus de construction du générateur de code est de nature algorithmique à l’aide de simple éditeur de texte. Dans ces scripts séquentiels organisés en modules non paramétrés, l’ingénieur méthode utilise sa connaissance implicite de la sémantique des méta-modèles manipulés pour définir le générateur de code. 1.4. Méta-modèles et sémantique d’exécution Généralement, la pratique de la méta-modélisation consiste à spécifier des méta-modèles contemplatifs qui reflètent l’aspect statique des modèles. L’aspect statique d’un modèle représente l’ensemble des concepts qui ont servi à décrire ce modèle ainsi que les liens entre ces concepts (Jeusfeld et al., 2009). On utilise aussi le terme aspect structurel. L’aspect dynamique complète l’aspect statique et renseigne sur la manière avec laquelle les instances des concepts vont intéragir lors de l’exécution du méta-modèle. Cela revient à décrire le comportement dynamique des instances des concepts, c'est-à-dire la sémantique d’exécution du modèle. Selon le langage de méta-modélisation utilisé, un méta-modèle contemplatif peut être complété par la spécification de certaines contraintes. En utilisant UML par exemple pour construire un (méta-) diagramme de classes, il est possible de compléter cette spécification avec des contraintes exprimées avec le langage OCL. Pour un langage de modélisation de processus (tels que XPDL21, BPMN ou SPEM), la méta-modélisation telle qu’elle vient d’être illustrée avec l’outil MetaEdit+, se restreint à décrire la syntaxe abstraite des concepts qui correspond à l’aspect statique (ou structurel) de ces concepts, et ne prend pas en compte la sémantique des concepts. Par exemple, un méta-modèle de BPMN représente un « produit » avec des objets et des propriétés (les concepts), des relations et des rôles (les liens entre ces concepts). Tandis que la sémantique d’un modèle de processus BPMN correspond à un certain comportement dans un environnement d’exécution donné. Ce comportement peut être assuré par un moteur d’exécution qui interprète les instances du modèle de processus, interagit avec l’environnement et fournit un résultat qui varie en fonction de cette interaction (Figure 4). 21 XML Process Definition Language Chapitre 1 : Introduction 18 Figure 4. Schéma générique pour un moteur d’exécution Pour exécuter un processus, il est en effet souvent nécessaire de communiquer et d’interagir avec d’autres acteurs humains et/ou agents logiciels afin de déléguer des tâches ou de recevoir des éléments indispensables pour continuer l’exécution (un fragment de produit, une décision, un choix, etc.). Par ailleurs, l’évocation de l’exécution d’un modèle de processus est généralement faite à l’aide du terme anglo-saxon « enactment » pour souligner la différence qu’il y a entre « exécuter un programme » et « énacter un processus » et mettre en œuvre l’aspect distribué, coopératif et parfois asynchrone d’un processus. L’expression de la sémantique des langages est une problématique connue et bien développée depuis plusieurs décennies dans le domaine de la compilation et des langages de programmation. Les techniques les plus probantes s’appuient sur la grammaire des attributs (Knuth, 1968), (Paakki, 1995). Pour les langages de modélisation, l’intérêt pour l’expression explicite de la sémantique est assez récent (Harel and Rumpe, 2004). L’intérêt pour l’expression de la sémantique des modèles va de pair avec la question de comment rendre exécutable un modèle, à priori contemplatif, décrit à l’aide d’un méta-langage (Muller et al., 2005). La direction suivie pour résoudre ces problèmes cherche à enrichir les langages et environnements de méta-modélisation pour permettre l’expression explicite et adéquate de la sémantique d’un langage de modélisation. Dans (Paige et al., 2006) par exemple, il est proposé d’enrichir le méta-méta-modèle MOF22 avec un langage d’action qui permettra de programmer des « méta-méthodes » rattachées aux méta-classes d’un méta-diagramme MOF. 22 MOF : Meta Object Facility, formalism de méta-modélisation proposé par l’OMG (http://www.omg.org/mof/) Moteur d’exécution Spécifique à un métamodèle de processus Entrée Environnement du moteur d’exécution Modèle de processus Produit résultant de l’exécution du processus BD Acteur externe Application externe Sortie Interactions Evénements externes Agir Réagir Agir RéagirChapitre 1 : Introduction 19 1.5. Constats et problématique Nous constatons qu’aujourd’hui, par rapport à l’approche ad-hoc, les environnements méta-CASE définissent des démarches basées sur la méta-modélisation, et qui apportent des améliorations significatives aux problématiques de spécification d’un langage de modélisation et de construction d’outils correspondants. Néanmoins, trois limitations majeures persistent: • D’une part, la méta-modélisation est fortement orientée « produit » ; d’un point de vue d’ingénierie de méthode, la spécification du processus méthodologique est complexe, difficile, sinon impossible, à capturer et à énacter. Les tentatives de l’environnement MetaEdit+ dans ce sens par exemple (Koskinen et Marttiin, 1998) n’ont finalement pas été retenues dans l’outil commercialisé par la suite par l’entreprise MetaCASE23 . • D’autre part, cette spécification des « produits » n’en capture que la syntaxe abstraite et une partie réduite de la sémantique sous forme de contraintes. Si le produit est un modèle de processus, et si l’ingénieur méthode souhaite exécuter ces processus, et cherche à obtenir un moteur d’exécution de ces modèles, la construction d’un tel moteur se fait manuellement. Elle nécessite une connaissance en programmation et un effort supplémentaire de la part de l’ingénieur. De plus, cette implémentation artisanale entraine des difficultés de maintenance du moteur d’exécution car toute évolution des modèles oblige l’ingénieur outil à propager les changements dans le code (les scripts Merl dans le cas de MetaEdit+). • Enfin, la spécification du modèle de processus n’integre pas l’aspect interactif avec des acteurs externes ce qui implque que l’outil d’exécution associé ne va pas satisfaire des contraintes en termes d’interactivité avec l’environnement d’exécution. 1.6. Objectif de la thèse Notre objectif est de proposer une approche de spécification de langage de modélisation de processus et de construction d’outils d’exécution de modèles permettant de satisfaire les contraintes suivantes : • Cette approche doit offrir un support de méta-modélisation avec une prise en compte claire et explicite de la sémantique d’exécution du modèle et un formalisme graphique pour une représentation visuelle de cette spécification. • L’approche devra comporter une démarche et des techniques pour exploiter la sémantique d’exécution du méta-modèle de processus afin d’en dériver de manière systématique une architecture d’un moteur d’exécution qui satisfait des contraintes de maintenabilité et de portabilité. • La spécification du modèle de processus doit interagir avec son environnement pour que le moteur d’exécution associé à ce modèle puisse avoir ce critère d’interactivité. • Cette approche doit être suffisamment générique pour pouvoir être appliquée sur n’importe quel modèle de processus. 23 http://www.metacase.com Chapitre 1 : Introduction 20 1.7. Démarche de recherche suivie dans cette thèse La démarche de recherche de la thèse est schématisée à la Figure 5. La première étape est un projet exploratoire que nous avons mené pour acquérir une expérience pratique dans le développement d’un outil par méta-modélisation. Ce projet à été réalisé dans le cadre d’un co-encadrement d’un Master Recherche pour explorer une technologie méta-CASE pour le développement d’outil d’exécution pour un modèle de processus intentionnel (Harrous, 2011) et dont une synthèse des résultats a été publiée dans (Mallouli, 2013). A l’issue de ce projet exploratoire, nous avons déterminé un ensemble de constats qui ont permis de fixer des exigences précises pour répondre à notre problématique. La seconde étape de notre recherche est une synthèse de l’état de l’art concernant l’exécutabilité des modèles, la construction d’outils ainsi que les langages et outils de métamodélisation. Cette étape a été réalisée en parallèle avec un co-encadrement de deux mémoires de Master Recherche pour étudier et comparer les langages et les outils de métamodélisation (Souag, 2010) (Zaidi, 2010). A la fin de l’étude de l’état de l’art, nous avons réalisé une comparaison entre différentes approches de construction d’outils en se basant sur des critères définis à la lumière des exigences fixées lors de la première étape. Figure 5. Les étapes de la démarche de recherche suivie La troisième étape correspond à l’élaboration de la solution que nous proposons. Les principales idées de notre démarche consistent à élargir le périmètre d’expression d’un métamodèle en y ajoutant la spécification de sa sémantique d’exécution, et à introduire plus d’automatisation dans le processus de construction d’outils grâce à l’exploitation des spécifications du niveau « méta ». Etat de l’art
Étudier de manière approfondie différentes approches
Rebondir sur les constats du projet exploratoire
En se basant sur ces constats, définir un ensemble de critères pour comparer différentes approches Projet exploratoire
Obtenir les premiers constats en se basant sur un cas pratique de construction d’outil
Définir des exigences à satisfaire dans la solution à partir de ces constats Elaborer une solution de spécification d’outils d’exécution
Compléter le méta-modèle de processus pour prendre en compte la sémantique d’exécution en faisant appel à une notation événementielle.
Exploiter la spécification de la sémantique d’exécution pour obtenir un outil d’exécution.
Définir des règles de transformation pour obtenir une architecture technique d’un outil d’exécution. 1 2 3Chapitre 1 : Introduction 21 1.8. Aperçu de la solution proposée Contrairement aux approches classiques, qui se basent sur la structure d’un méta-modèle puis définissent la sémantique d’exécution directement dans le code ou sous forme de scripts attachés aux éléments statiques, notre démarche utilise un formalisme soigneusement choisi pour la spécification de la sémantique d’exécution, ce qui facilite la génération de l’architecture d’un outil d’exécution. Notre solution comporte trois étapes schématisées à la Figure 6 : • La première étape définit le méta-modèle structurel du langage de modélisation. • La seconde étape définit la sémantique d’exécution du modèle à travers un méta-modèle de comportement. Pour ce faire, il faut au préalable compléter le méta-modèle structurel en introduisant un second niveau de représentation qui correspond aux instances du métamodèle. Ce second niveau est nécessaire pour l’expression de la sémantique d’exécution ; en effet, celle-ci s’exprime en manipulant les instances du méta-modèle au moment de l’exécution d’un modèle afin d’extraire l’instance intéressante à un instant t précis. • La troisième étape applique des règles de transformation pour dériver une architecture d’outil d’exécution à partir de la spécification conceptuelle. Figure 6. Aperçu de l’approche Pour spécifier le comportement du modèle et sa sémantique d’exécution, nous adoptons une persepctive «systémique» du modèle de comportement et introduisons une notation basée sur les événements (Assar et al., 2011). La vision systémique préconise de voir le comportement d’un système selon un schéma où l’action est un stimulus externe de l’environnement du système et la réaction est l’activité que le système déclenche en réponse. Concrètement, notre approche consiste à introduire de nouveaux concepts (Evénement, Acteur, Transition, Trigger) dans le langage de méta-modélisation. Ces concepts serviront à spécifier le comportement dynamique des structures définies au niveau des métamodèles. De cette manière, la spécification de la sémantique d’exécution du modèle intègre Spécification structurelle à deux niveaux Schéma dynamique Spécification de la sémantique d’exécution du méta-modèle Architecture Orientée Objet de l’outil d’exécution Métamodélisation Structure statique des modèles de processus en fonction d’un MMP Structure des Processus (instances) Perspective Comportement Perspective Données Perspective Traitements UML Formalisme orienté événement Formalisme OO Ingénieur basées sur les patrons PublishSubscribe UML Formalisme OO Etape3 Etape2 Etape1 Règles de TransformationChapitre 1 : Introduction 22 une représentation des éléments de l’environnement du processus dans lequel le modèle s’exécutera ainsi que les éléments échangés avec lui. La sémantique d’exécution est ainsi exprimée à travers un schéma graphique. Cette expression de la sémantique d’exécution est de nature opérationnelle, elle montre l’interprétation du modèle par un outil d’exécution qui gère les événements, assure les interactions avec l’environnement et contrôle l’interprétation du modèle. Cette sémantique opérationnelle peut de ce fait être traduite en une architecture d’outil logiciel à l’aide d’une technique de type « par traduction » (Combemale et al., 2006). Nous élaborons donc un ensemble de règles pour transformer la spécification conceptuelle en une spécification exécutable. En raison de la nature dynamique et interactive du modèle de comportement, nous choisissons le patron publication/abonnement (publish/subscribe) comme modèle cible d’implémentation du concept d’événement au niveau conceptuel. Dans ce modèle, les abonnés (des agents ou composants logiciels) manifestent leur intérêt pour un événement, et sont automatiquement notifiés de toute occurrence de cet événement (Eugster et al., 2003). Une occurrence d’événement est donc propagée de manière synchrone ou asynchrone à tous les abonnés qui sont inscrits à cet événement. Les abonnés réagissent àla notification d’un événement par le déclenchement d’un traitement spécifié dans une méthode particulière. En appliquant un ensemble de règles de transformation, la spécification conceptuelle permet de dériver l’architecture d’un outil logiciel directement implémentable. Notre solution présente deux contributions majeures: • Un apport conceptuel qui consiste à capturer la sémantique opérationnelle du métamodèle avec une vision systémique et l’exprimer à travers des concepts événementiels. • Une démarche par méta-modélisation qui exploite les méta-modèles conceptuels pour arriver à la phase d’implémentation avec une architecture exécutable en appliquant de manière systématique des règles de transformation. L’originalité de ce travail se résume dans les points suivants : • L’approche suivie est de type « méta-démarche » et permet de guider l’ingénieur dans le processus de spécification et de construction d’un outil d’exécution. • Dans la partie spécification conceptuelle, le comportement de l’outil d’exécution à construire est représenté par un modèle orienté événement, Le modèle de comportement choisi est fondé sur le paradigme systémique, Ce modèle est largement utilisé en SI et il est bien adapté aux outils d’exécution qui sont en complète interaction avec leur environnement. • Dans la partie implémentation de cette démarche, une approche par transformation, du niveau conceptuel vers le niveau technique, des concepts liés au comportement, est appliquée afin de générer une architecture d’un outil d’exécution de manière méthodique à partir de la spécification conceptuelle. Cette approche favorise les critères de maintenabilité, de portabilité et de minimisation de coût. Langage de mashup pour l’int´egration autonomique de services de donn´ees dans des environements dynamiques Mohamad Othman-Abdallah To cite this version: Mohamad Othman-Abdallah. Langage de mashup pour l’int´egration autonomique de services de donn´ees dans des environements dynamiques. Databases. Universit´e de Grenoble, 2014. French. HAL Id: tel-01011470 https://tel.archives-ouvertes.fr/tel-01011470 Submitted on 26 Jun 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THÈSE Pour obtenir le grade de DOCTEUR DE L’UNIVERSITÉ DE GRENOBLE Spécialité : Informatique Arrêté ministériel : 7 août 2006 Présentée par Mohamad OTHMAN ABDALLAH Thèse dirigée par Christine COLLET et Co-encadrée par Genoveva VARGAS-SOLAR préparée au sein du Laboratoire d’Informatique de Grenoble dans l'École Doctorale de Mathématiques, Sciences et Technologies de l'Information et de l'Informatique MELQART : un système d’exécution de mashups avec disponibilité de données Thèse soutenue publiquement le 24 février 2014, devant le jury composé de : Mme, Chirine GHEDIRA GUEGAN Professeur, IAE Lyon, Rapporteur Mme, Parisa GHODOUS Professeur, Université Claude Bernard Lyon 1, Rapporteur M. Omar BOUCELMA Professeur, Université d’Aix Marseille, Examinateur Mme Christine COLLET Professeur, Grenoble INP, Directeur de thèse Mme Genoveva VARGAS-SOLAR Chargé de recherche, CNRS, Co-encadrant1 REMERCIEMENTS Je tiens à remercier : Madame Cherine Ghedira Guegan, Professeur à l’IAE de Lyon, et Madame Parisa Ghodous, Professeur à l’Université Claude Bernard Lyon 1, de leur intérêt pour mon travail et pour avoir accepté de l’évaluer. Monsieur Omar Boucelma, Professeur à l’Université d’Aix-Marseille, pour avoir accepté d’examiner mon travail et de faire partie du jury de cette thèse. Madame Christine Collet, Professeur à Grenoble INP et responsable de l’équipe HADAS au LIG, pour avoir assuré la direction de cette thèse, et pour la confiance qu’elle m’a témoignée. Ce manuscrit doit beaucoup à ses suggestions et ses relectures attentives. Madame Genoveva Vargas-Solar, Chargé de recherche au CNRS, pour avoir assuré le coencadrement de cette thèse, et pour ses conseils avisés qui m’ont permis d’avancer vers des résultats meilleurs. Monsieur José Luis Zechinelli Martini, professeur à l’Universidad de las Americas à Puebla, Mexique, pour m’avoir accueilli dans son équipe lors de mes séjours scientifiques au Mexique. Les membres de l’équipe HADAS pour leur soutien tout au long de la réalisation de cette thèse. Un merci particulier à Noha pour son encouragement continu et à Mustafa pour sa participation active dans mes démarches administratives pour soutenir cette thèse. Je remercie, également, mes collègues du bureau pour les riches discussions que nous avons partagées. Mes remerciements vont naturellement à Mireille et aux familles Khalaf, Bibent, Messmer et Suc pour leur amitié, leur gentillesse et pour les moments agréables passés ensemble. Je tiens aussi à remercier Fatin, Sherine, Omar, Timo et Jordi pour leurs constants encouragements et pour avoir su me réconforter dans des moments difficiles. Je ne saurai terminer sans adresser tous mes remerciements à ma famille dont la confiance et le soutien n’ont jamais fait défaut.3 TABLE%DES%MATIERES CHAPITRE)1)INTRODUCTION..............................................................................................11 1.1 Contexte......................................................................................................................11 1.2 Problématique ............................................................................................................12 1.3 Objectif!et!approche ...................................................................................................13 1.4 Organisation!du!document .........................................................................................14 CHAPITRE)2)MASHUPS)ET)DISPONILBILITE)DE)DONNEES)SUR)LE)WEB ................................15 2.1 Modèles!de!Mashups..................................................................................................15 2.1.1 Modèles!de!données.............................................................................................16 2.1.2 Opérateur!de!données..........................................................................................17 2.1.3 Mashlet.................................................................................................................18 2.1.4 Wiring ...................................................................................................................19 2.1.5 Mashup .................................................................................................................19 2.1.6 Modèle!relationnel!de!mashups...........................................................................20 2.1.7 Modèle!de!Hoyer ..................................................................................................21 2.1.8 Modèle!de!mashups!MACE...................................................................................22 2.2 Systèmes!d’exécution!de!mashups.............................................................................22 2.2.1 Architecture!générale ...........................................................................................22 2.2.2 Déploiement .........................................................................................................24 2.3 Disponibilité!de!données!fraiches!sur!le!web..............................................................26 2.3.1 Mesure!de!la!disponibilité!de!données!dans!les!mashups....................................26 2.3.2 Rafraichissement!de!données!des!mashups.........................................................27 2.3.3 Disponibilité!de!données!par!la!réplication ..........................................................28 2.3.4 Disponibilité!de!données!par!le!cache ..................................................................29 2.4 Conclusion...................................................................................................................32 CHAPITRE)3)MODELE)DE MASHUPS ...................................................................................33 3.1 Données!de!mashups..................................................................................................34 3.1.1 Types!de!données.................................................................................................!34 3.1.2 Instances!des!types...............................................................................................35 3.1.3 Types!et!valeurs!d’instances.................................................................................38 3.1.4 Opérations!sur!les!instances.................................................................................38 3.2 Activité ........................................................................................................................39 3.2.1 Activités!basiques .................................................................................................!39 3.2.2 Activités!composites.............................................................................................44 3.2.3 Définition!du!domaine!des!activités!O..................................................................47 3.3 Mashlet .......................................................................................................................47 3.4 Wiring..........................................................................................................................49 3.5 Mashup .......................................................................................................................51 3.6 Conclusion...................................................................................................................534 CHAPITRE)4)EXECUTION DE)MASHUPS)AVEC)DISPONIBILITE)DE)DONNEES .........................55 4.1 Exécution!d’un!mashup...............................................................................................56 4.1.1 Exécution!d’une!activité........................................................................................57 4.1.2 Exécution!d’un!mashlet ........................................................................................62 4.1.3 Exécution!d’un!wiring ...........................................................................................62 4.2 Disponibilité!des!données!dans!les!mashups..............................................................63 4.2.1 Organisation!de!données!du!Store.......................................................................65 4.2.2 Gestion!du!Store...................................................................................................66 4.2.3 Remplacement!de!données..................................................................................68 4.2.4 Rafraichissement!de!données...............................................................................70 4.2.5 Exécution!d’un!nœud!Retrieve++ .........................................................................74 4.3 Conclusion...................................................................................................................75 CHAPITRE)5)IMPLANTATION)DE)MELQART ........................................................................77 5.1 Architecture!du!système .............................................................................................78 5.2 Valeurs!complexes ......................................................................................................80 5.3 Activité ........................................................................................................................81 5.3.1 Activités!basiques .................................................................................................!82 5.3.2 Activités!composites.............................................................................................86 5.4 Mashlet .......................................................................................................................93 5.5 Wiring..........................................................................................................................94 5.6 Mashup .......................................................................................................................94 5.7 Item.............................................................................................................................96 5.8 Store............................................................................................................................97 5.9 ReplacementManager.................................................................................................!97 5.10 FreshnessManager....................................................................................................98 5.11 Interaction!des!mashups!avec!le!Store ...................................................................100 5.12 Validation................................................................................................................101 5.12.1 ItineraryPlanner................................................................................................102 5.12.2 MyDashboard ...................................................................................................104 5.12.3 Execution!des!instances!des!mashups..............................................................105 5.13 Conclusion...............................................................................................................105 CHAPITRE)6)CONCLUSION)................................................................................................)107 6.1 Contribution!et!bilan.................................................................................................!107 6.2 Perspectives..............................................................................................................108 BIBLIOGRAPHIE ...............................................................................................................111 ANNEXE)A :))SYSTEMES)D’EXECUTION)DE)MASHUPS)ETUDIES..........................................119 ANNEXE)B :))SYNTAXE)DE)JSON........................................................................................1235 LISTE%DES%TABLEAUX Tableau!1 :!Modèle!de!données!des!mashups!dans!les!outils/modèles!étudiés...................................................17 Tableau!2 :!Opérateurs!proposés!dans!les!outils!étudiés......................................................................................18 Tableau!3 :!Gestion!de!wirings!dans!les outils!étudiés..........................................................................................19 Tableau!4 :!Protocoles!d'accès!aux!données!des!fournisseurs!dans!les!outils!de!mashups!étudiés.....................23 Tableau!5 :!Coût!des!opérations!dans!différentes!structures!de!données............................................................74 Tableau!6 :!Durées!des!vies!des!données du!mashup!ItineraryPlanner..............................................................103 Tableau!7 :!Durées!des!vies!des!données!du!mashup!MyDashboard .................................................................!1057 LISTE DES"FIGURES Figure!1!:!Le!mashup!ItineraryPlanner ..................................................................................................................12 Figure!2!:!Logique!applicative!de!mashup!ItineraryPlanner..................................................................................13 Figure!3 :!Échange!de!données!entre!les!mashlets!Map!et!Weather!défini!par!un!wiring....................................19 Figure!4!:!Modèle!de!mashups!de!Hoyer...............................................................................................................21 Figure!5!:!Les!composants!d'une!architecture!générale!d'un!système!d'exécution!de!mashups..........................23 Figure!6:!Diagra .........................................................................................................................................................!! mme!de!déploiement!des!composants!d'un!système!d’exécution!de!mashups!(côté!client)...............................24 Figure!7!:!Diagramme!de!communication!illustrant!le!fonctionnement!d'un!mashup!exécuté!côté!Client..........25 Figure!8!:!Diagramme!de!déploiement!des!composants!d'un!système!d’exécution!de!mashups!(côté!serveur)!.!25 Figure!9!:!Diagramme!de!communication!illustrant!le!fonctionnement!d'un!mashup!exécuté!côté!serveur.......26 Figure!10 :!Architecture!du!cache!distribué!proposé!dans![91] ............................................................................30 Figure!11 :!Pile!de!concepts!de!mashups ..............................................................................................................34 Figure!12!:!Représentation!graphique!d'une!activité ............................................................................................39 Figure!13!:!Représentation!graphique!d'une!activité!Sequence ............................................................................45 Figure!14!:!Représentation!graphique!d’un!exemple!d’une!activité!Sequence .....................................................45 Figure!15!:!Représentation!graphique!d'une!activité!Foreach ..............................................................................46 Figure!16!:!Représentation!graphique!d’un!exemple!d’une!activité!Foreach .......................................................46 Figure!17!:!Représentation!graphique!d'une!activité!Parallel ...............................................................................47 Figure!18!:!Représentation!graphique!d'un!mashlet.............................................................................................48 Figure!19!:!Représentation!graphique!du!mashlet!Map........................................................................................48 Figure!20!:!Représentation!graphique!du!mashlet!Weather.................................................................................49 Figure!21!:!Représentation!graphique!d'un!wiring................................................................................................50 Figure!22!:!Représentation!graphique!du!wiring!entre!les!mashlets!Map!et!Weather.........................................51 Figure!23!:!Représentation!graphique!du!mashup!ItineraryPlanner.....................................................................52 Figure!24!:!Diagramme!d’activité!UML!de!l’exécution!d’un!mashup ....................................................................56 Figure!25!:!Graphe!du!mashup!ItineraryPlanner...................................................................................................57 Figure!26!:!Exécution!du!mashup!ItineraryPlanner ...............................................................................................58 Figure!27!:!Arbre!de!l’activité!du!wiring!Map2Weather .......................................................................................58 Figure!28!:!Exécution!du!mashup!ItineraryPlanner ...............................................................................................59 Figure!29!:!Composition!d'un!nœud!d'une!activité!basique..................................................................................598 Figure!30!:!Diagramme!d’activité!UML!du!processus!d’exécution!d'une!activité!basique ....................................60 Figure!31!:!Diagramme!de!communication!entre!le!nœud!Retrieve et!le!fournisseur!de!données ......................60 Figure!32 :!Arbre!de!nœuds!d’une!activité!Sequence ...........................................................................................61 Figure!33!:!diagramme!d’activité!UML!du!processus!d’exécution!d'une!activité!Sequence..................................61 Figure!34 :!Diagramme!d’activité!UML!de!l’exécution!d’un!mashlet ....................................................................62 Figure!35!:!Diagramme!d’activité!UML!de!l’exécution!d’un!wiring .......................................................................63 Figure!36!:!Diagramme!de!communication!UML!entre!le!nœud!Retrieve++,!le!fournisseur!de!données!et!le Store .......................................................................................................................................................................63 Figure!37 :!Exécution!d’un!mashup!avec!disponibilité!de!données.......................................................................64 Figure!38!:!Représentation!du!Store .....................................................................................................................66 Figure!39!:!Utilisation!des!fonctionnalités!de!gestion!du!Store dans!l’exécution!d’un!nœud!Retrieve++.............67 Figure!40!:!Utilisation!de!la!fonction!makeroom dans!l’exécution!d’un!nœud!Retrieve++ ..................................68 Figure!41 :!Rafraichissement!des!items.................................................................................................................70 Figure!42!:!Exécution!d'un!nœud!Retrieve++ ........................................................................................................75 Figure!43!:!Approche!de!MELQART!pour!la!création!et!l’exécution!des!mashups................................................78 Figure!44 :!Interaction!des!utilisateurs!avec!MELQART.........................................................................................78 Figure!45!:!Architecture!de!MELQART...................................................................................................................79 Figure!46!:!Classe!Activity......................................................................................................................................82 Figure!47!:!Les!classes!des!activités!basiques........................................................................................................83 Figure!48!:!Les!classes!des!activités!composites....................................................................................................87 Figure!49 :!Exécution!de!la!méthode!run()!d’une!instance!de!la!classe!Sequence................................................88 Figure!50!:!Exécution!de!la!méthode!run()!d'une!instance!de!WOEIDCitySeq ......................................................89 Figure!51 :!Exécution!de!la!méthode!run()!d’une!instance!de!la!classe!Foreach...................................................90 Figure!52!:!Exécution!de!la!méthode!run()!d’une!instance!de!CitiesListForeach ..................................................91 Figure!53!:!Interactions!entre!une!activité!Parallel!et!ses!soushactivités ..............................................................92 Figure!54!:!Classe!Mashlet.....................................................................................................................................93 Figure!55!:!Interaction!entre!une!instance!de!Mashlet!et!son!activité..................................................................93 Figure!56!:!Classe!Wiring .......................................................................................................................................94 Figure!57!:!Classe!Mashup.....................................................................................................................................95 Figure!58!:!Classe!Item ..........................................................................................................................................96 Figure!59!:!Instance!de!la!classe!Item....................................................................................................................96 Figure!60!:!Classe!Store .........................................................................................................................................97 Figure!61!:!La!classe!ReplacementManager ..........................................................................................................98 Figure!62!:!La!classe!FreshnessManager ...............................................................................................................99 Figure!63!:!Exécution!de!la!méthode!run()!de!l'activité!Retrieve!avec!utilisation!du!Store ................................101 Figure!64!:!Résultats!du!mashup!ItinerayPlanner!pour!l’itinéraire!de!Grenoble!à!Paris .....................................103 Figure!65!:!Résultats!du!mashup!MyDashboard!avec!Grenoble!comme!paramètre!en!entrée. .........................104 Figure!66!:!Chronologie!des!exécutions ..............................................................................................................1069 Figure!67!:!Sources!de!données!dans!Montage...................................................................................................119 Figure!68!:!Construction!de!mashlets!dans!Yahoo!!Pipes....................................................................................120 Figure!69!:!Architecture!de!MSS..........................................................................................................................122 Figure!70!:!Syntaxe!de!JSON................................................................................................................................12311 Chapitre!1 INTRODUCTION 1.1 Contexte A l'origine, le terme mashup désigne un morceau musical hybride composé d’échantillons de musique issus de chansons différentes. Par analogie, en Informatique, un mashup est une application web qui combine des ressources (données, fonctionnalités etc.) provenant de sources hétérogènes. Ces ressources sont agrégées pour former un résultat affiché dans des composants appelés mashlets, comme iGoogle1 . Une des premières définitions des mashups apparaît en 2006 dans [1] : “Mashups are an exciting genre of interactive Web applications that draw upon content retrieved from external data sources to create entirely new and innovative services”. Les mashups sont utilisés dans différents domaines comme la biologie [2], la santé [3], l’électroménager [4], la formation en ligne (E-learning) [5][6] et la gestion des documents en entreprise [7]. Exemple de mashup Supposons qu'Alice veuille planifier un voyage de Grenoble à Paris et qu'elle veuille déterminer l'itinéraire qu'elle va prendre, ainsi que les prévisions météorologiques dans les villes de passage. Comme le voyage est long, Alice aura faim à l’arrivée. Elle voudrait choisir un restaurant parmi une liste de restaurants proposés ayant une moyenne de notes supérieure à 3 sur 5. Au lieu de contacter des services sur le Web de manière séparée, Alice veut exprimer ses besoins d’une manière globale et avoir les réponses de différents services sur une même page Web. Pour cela, Alice a recours à un mashup qui combine des données issues des services disponibles sur le web comme Google maps et Yahoo météo et Google Places. Le mashup est composé de trois mashlets affichant l’itinéraire, les conditions météorologiques et la liste de restaurants. Dans ce document, nous nous référons à ce mashup sous le nom d’ItineraryPlanner (illustré dans la Figure 1). Nous avons choisi ce scénario parce qu’il intègre des données de nature hétérogènes : dynamiques et multimédia où l’on prend en considération des données spatiales comme dans [8][9]. Un mashup fonctionne selon une logique applicative. Les deux points clés de cette logique applicative sont les services de données et la coordination des appels des services. Les services font office de fournisseurs des données par des appels des méthodes. La coordination sert à coordonner la récupération et la transformation de données afin de pouvoir les échanger entre les composants du mashup. Les fonctions de gestion de données qui en ressortent sont : 1 http://www.google.fr/ig, Google a mis fin à ce service en novembre 2013.12 Figure'1':'Le'mashup'ItineraryPlanner • La récupération de données : o À partir des services de données en appelant des méthodes exportées par ces services, par exemple obtenir l’itinéraire entre Grenoble et Paris sollicité depuis le service Google maps. o En interagissant avec les utilisateurs à travers des interfaces fournies par le mashup : par exemple, entrer la ville de départ et la destination. • La transformation de données récupérées pour les afficher de manière agrégée ou adaptée au dispositif utilisé pour les visualiser. Il s’agit de mettre en place cette transformation au sein et entre les mashlets. • L’échange de données : les données transformées peuvent servir comme entrée pour appeler d’autres services. Par exemple, les villes de passage dans l’itinéraire obtenu de Google maps, sont envoyées à Yahoo! Weather pour obtenir les informations sur les conditions météorologiques dans ces villes. La Figure 2 présente la logique applicative du mashup ItineraryPlanner définie avec l’outil Yahoo! Pipes [10]. Le mashlet Map s’adresse à Google maps pour récupérer l’itinéraire, ceci est suivi par une transformation pour récupérer les villes intermédiaires et les mettre dans le bon format pour les envoyer d’une manière itérative à Yahoo! Weather pour récupérer la météo. Les coordonnées de la ville d’arrivée sont récupérées par le mashlet Restaurants pour récupérer une liste de restaurants auprès du service Google Places. Cette gestion de données s’appuie sur une hypothèse forte et que nous adoptons : les interfaces des services ont des paramètres d’entrée/sortie typés selon un modèle de données de mashups. Ceci revient à considérer qu’il y a un mapping implicite entre les modèles des données sous-jacents aux services et le modèle de données propre aux mashups. 1.2 Problématique Les travaux existants, sur les mashups, se sont intéressés principalement à leur fonctionnement et aux différentes manières de les construire [11][12][13][14], aux domaines de leur utilisation et à l’interaction avec les utilisateurs [15][16][17]. Dans cette thèse nous nous intéressons à la gestion de données dans les mashups et plus particulièrement à la disponibilité des données fraîches dans les mashups. Améliorer la disponibilité des données au sein d’un mashup se définit à travers les aspects suivants : 13 Figure'2':'Logique'applicative'de'mashup'ItineraryPlanner • La continuité d’accès aux données même si le service est inaccessible. • La gestion de la fraîcheur de données du mashup. Ces données sont de nature dynamique et une mauvaise stratégie de mise à jour peut engendrer des mashups avec des données périmées. • Éviter de récupérer la même donnée plusieurs fois. L’approfondissement de ces problèmes nous a amené à nous poser différentes questions : • Quelles sont les données dont on a besoin pour le bon fonctionnement du mashup ? et comment les identifier dans les résultats des appels services ? • Comment retrouver ces données ? • Comment garder la fraicheur de ces données ? 1.3 Objectif)et)approche L’objectif de cette thèse est de proposer une approche pour améliorer la disponibilité des données des mashups qui garantit : • L’accès aux données même si le service est indisponible pour maintenir un mashup en état de fonctionnement. • La fraicheur de données et pour cela il faut prendre en compte la durée entre deux appels qui doit faire l’objet d’un compromis entre les caractéristiques du service et les besoins de l’utilisateur. • Un partage de données entre les mashups et les mashlets. Ce partage permet d’augmenter la probabilité de disponibilité de données.14 Pour atteindre cet objectif, nous proposons MELQART 2 un système d’exécution de mashups avec un mécanisme de disponibilité de données. Notre contribution inclut : • Une étude de l’état de l’art présentant une analyse des modèles de mashups existants et de leurs concepts ainsi que les travaux existants sur les systèmes d’exécution des mashups et sur la disponibilité et la fraicheur de données du web. L’étude de ces travaux constitue une base à partir de laquelle nous proposons notre approche pour améliorer la disponibilité des données des mashups. • La définition d’un modèle de mashups qui s’appuie sur les modèles de valeurs complexes [19]. Ce modèle permet de spécifier les caractéristiques de la disponibilité de données. Les concepts de ce modèle sont illustrés avec notre scénario ItineraryPlanner. • La définition du principe d’exécution de mashups selon le modèle de mashup proposé. Nous améliorons la disponibilité et la fraicheur des données du mashup par des fonctionnalités orthogonales à son processus d’exécution. Ces fonctionnalités prennent en charge la gestion et le rafraichissement de données 1.4 Organisation)du)document Le reste du document est organisé comme suit : • Le Chapitre 2 présente les concepts et les modèles des mashups (aspect statique des mashups) et étudie l’architecture générale des systèmes d’exécution de mashups existants (aspect dynamique des mashups). Ensuite, il s’intéresse à la disponibilité des données fraiches sur le web et aux solutions logicielles possibles pour la garantir. • Le Chapitre 3 présente les concepts de notre modèle de mashup. Parmi eux nous retrouvons les données, les mashlets etc. • Le Chapitre 4 commence par introduire les principaux éléments de l’exécution d’un mashup. Ensuite, il décrit notre proposition pour assurer la disponibilité de données lors de l’exécution des mashups et son intégration au processus d’exécution de mashups. Cette solution est à base de fonctions que nous associons d’une façon orthogonale au processus d’exécution de mashups. • Le Chapitre 5 décrit l’implantation et la validation d’un prototype de MELQART. Il commence par présenter l’architecture du système et l’implantation des concepts de notre modèle de mashups et des fonctionnalité proposées pour améliorer la disponibilité de données fraiches des mashups. L’implantation est décrite avec les diagrammes de classes et de séquence de la notation UML. Ensuite le chapitre présente la validation de notre implantation avec l’exécution de plusieurs instances de deux scenarios de mashups. • Le Chapitre 6 récapitule les principaux éléments de notre contribution et présente des orientations définissant la perspective de notre travail afin de l’améliorer et le consolider. 2 Dans la mythologie phénicienne, Melqart [18] signifie le roi (melk) de la cité (qart). Il est le dieu et protecteur de Tyr et de ses activités commerciales. Il accompagna les navigateurs phéniciens dans leur colonisation de la Méditerranée. Il est assimilé à Héraclès dans la mythologie gréco-romaine.15 Chapitre!2 MASHUPS%ET DISPONILBILITE+DE+DONNEES#SUR# LE#WEB Ce chapitre présente les travaux existants dans les domaines des mashups (modèles et systèmes d’exécution de mashups) et de la disponibilité et la fraicheur de données du web. L’étude de ces travaux constitue une base à partir de laquelle nous proposons notre approche pour améliorer la disponibilité des données des mashups. Le chapitre est organisé de la manière suivante : la section 2.1 présente les concepts et les modèles des mashups (aspect statique des mashups). La section 2.2 étudie l’architecture générale des systèmes d’exécution de mashups existants (aspect dynamique des mashups). Ensuite, la section 2.3 s’intéresse à la disponibilité des données fraiches sur le web et aux solutions logicielles possibles pour la garantir. Enfin, la section 2.4 conclut le chapitre. 2.1 Modèles)de)Mashups Cette section décrit les modèles existants de mashups. Nous avons constaté qu’il y a peu de travaux qui ont proposé des modèles de mashups (ceci est dû à l’apparition récente de cette notion de mashups) et que la plupart se sont focalisés sur les outils de création et d’exécution de mashups et leur fonctionnement. L’étude des modèles et des outils proposés (cf. Annexe A) nous a permis d’identifier les concepts nécessaires pour décrire un mashup. Donnée, Operateur, Mashlet, Wiring et Mashup. Un mashlet affiche des données définies selon un certain modèle de données. Elles sont récupérées auprès des fournisseurs de données. Des opérateurs décrivent la manipulation de ces données. Un mashup est un ensemble de mashlets qui échangent des données via des wirings. Dans le scenario ItineraryPlanner, introduit dans le Chapitre 1, ces concepts se présentent comme suit : • Les données sont récupérées depuis des fournisseurs de données : Google maps, Yahoo! Weather et Google Places. • Les opérateurs décrivent le traitement de ces données. • Les mashlets (Map, Weather, Restaurants) constituent les composants qui affichent les résultats. • Deux wirings décrivent le transfert de la liste de villes de passage de Map vers Weather, et celui des coordonnées de la ville d’arrivée de Map vers Restaurants). • Le mashup ItineraryPlanner est constitué des mashlets Map, Weather, Restaurants et des wirings sous-jacents.16 Ces concepts sont présentés dans les sous-sections 2.1.1 à 2.1.5. Ensuite les sous-sections 2.1.6, 2.1.7 et 2.1.8 présentent des modèles de mashups étudiés dans l’état de l’art. 2.1.1 Modèles)de)données Les données des mashups peuvent être définies selon différents modèles de données3 . Dans cette sous-section, nous présentons les modèles de données utilisées dans les modèles et les outils de mashups étudiés. • Le modèle relationnel [21] fut introduit pour pallier aux lacunes du modèle hiérarchique et du modèle réseau, comme la redondance et la rigidité. Il permet d’assurer une indépendance de données et d’améliorer les langages de requête. Il est basé sur les concepts de la théorie des relations. Le modèle relationnel de données est adopté dans le modèle relationnel de mashups [3] (cf. sous-section 2.1.6). Les auteurs y considèrent, également, que toutes les données (provenant de fournisseurs externes ou manipulées au sein des mashups) sont décrites selon le modèle relationnel. Ce choix de modélisation de données est justifié par les bases mathématiques du modèle relationnel. • Les modèles orientés objet furent proposés pour rapprocher les bases de données aux langages de programmation. Certains travaux ont focalisé sur l’intégration des caractéristiques de persistance et de transactions, présentes dans les SGBDs, aux langages de programmation orientées-objet. Tandis que d’autres ont focalisé sur l’intégration des caractéristiques de l’orienté-objet aux SGBDs comme l’encapsulation, la hiérarchie des classes ou l’attachement dynamique (dynamic binding). Ces travaux ont contribué au développement de SGBDs objets comme O2 [22] et SAMOS [23]. Un groupe ODMG (Object Data Management Group) fut crée. Il est responsable de la définition de standards pour les bases de données objets [24] dont le langage OQL (Object Query Language). Le modèle orienté-objet fut adopté par l’outil Popfly [25] de Microsoft. Ce choix est justifié par une proximité recherchée des langages de programmation. Nous n’avons pas pu étudier et tester cet outil, parce que Microsoft y a arrêté son développement avant le début des travaux sur cette thèse. • Les modèles de données semi-structurées sont basés sur une organisation de données dans des structures d’arbres étiquetées ou des graphes et des langages de requêtes pour accéder et modifier les données [26][27]. Les modèles de données semi-structurées sont utilisés pour décrire des données sans schéma explicite. Dans les modèles de données structurés, on distingue entre le type de données (schéma) et les données mêmes. Cependant, cette distinction est estompée dans les modèles de données semi-structurées : on parle de données auto-décrites [27]. Les données semi-structurées le plus répandues sont des données XML. La richesse d’XML provient des langages associés comme XPath, XQuery, XSLT qui facilitent la manipulation des données XML. Le Tableau 1 indique les modèles de données manipulées dans les modèles et les outils de création et d’exécution de mashups étudiés. Nous constatons que la plupart des outils de mashups utilisent des modèles à base d’XML pour représenter les données manipulées. Ceci est justifié par le fait que la plupart des données du web sont décrites avec XML. 3 Un modèle de données fournit les moyens pour (1) spécifier des structures de données, (2) définir un ensemble de contraintes associées à ces structures et (3) et les manipuler [20]. 17 Modèle de données Outil/Modèles de mashups Relationnel Modèle relationnel de mashups [3] Orientés-objet Popfly [25] Semi-structurées Montage [28] (XML), Yahoo! Pipes [10] (flux RSS), Intel MashMaker [29] (RDF), EMML/Presto [30] (XML), MSS [31] (XML), WSO2 Application Server [32] (XML) Tableau'1':'Modèle'de'données'des'mashups'dans'les'outils/modèles'étudiés 2.1.2 Opérateur)de)données Un opérateur de données est modélisé avec une fonction qui manipule des données en entrée pour en produire d’autres en sortie. Les principaux opérateurs de données, pour les différents modèles, sont la jointure, le filtrage, le tri, la troncature, le comptage, l’élimination de doublons etc. Certains fournisseurs de données (Wikipédia, Craiglist4 etc.) n’exposent pas leurs contenus via des méthodes exportées. Ainsi, certains outils offrent des opérateurs décrivant l’extraction des données avec la technique du web scraping 5 [1][33]. Les données extraites sont décrites selon le modèle de données adopté dans le mashup. Par exemple, le mashup HousingMaps6 a recours à cette technique pour extraire les annonces depuis le site Craiglist. Le Tableau 2 indique la nature des opérateurs définis dans les outils de création et d’exécution de mashups étudiés. Nous constatons que les outils, qui s’adressent à des utilisateurs sans compétence en programmation (comme Montage, Intel MashMaker), proposent peu d’opérateurs, offrant ainsi une moindre complexité pour construire un mashup. D’autre part, certains outils nécessitent des compétences en programmation comme WSO2 Mashup Server. Les outils Yahoo ! Pipes et Presto offrent des opérateurs similaires pour manipuler les données. Le modèle relationnel de mashups ne propose pas d’opérateurs pour manipuler les données ; Ils font partie des perspectives évoquées par les auteurs. L’outil MSS propose un langage de manipulation de données : Mashup Service Query Langage (MSQL). Celui-ci est basé sur le langage SQL et il est enrichi avec des opérateurs exécutant des tâches spécifiques interprétées selon une ontologie propre à MSS (par exemple, « trouver des maisons », « trouver des vols »). Modèle relationnel de mashups • Récupération de données par appel de services. • Ce modèle ne propose pas d’opérateurs pour manipuler les données. A l’heure actuelle, les données récupérées sont rendues en entier. Néanmoins, les auteurs proposent, dans leur perspective, d’enrichir le modèle avec des opérateurs de manipulation de données. (cf. soussection 2.1.6) Montage Récupération de flux RSS. 4 Craiglist est un site web américain de petites annonces 5 Un web scraper est un programme qui extrait des données depuis un site web dans le but de les exploiter. 6 http://www.housingmaps.com/18 Yahoo! Pipes L'ensemble des opérateurs de Yahoo! Pipes comprend : • Les opérateurs de récupération de données : depuis des services REST ou bien des flux RSS. • Les opérateurs de transformation de données (tri, filtrage, élimination de doublons, troncature, inverser une liste, l’extraction de données) • les opérateurs arithmétiques • les opérateurs sur les expressions régulières. Intel MashMaker Les données sont manipulées avec des formules comme dans les feuilles de calcul. WSO2 Mashup Server Les opérations sont définies avec un code JavaScript. EMML/Presto L'ensemble des opérateurs de EMML / Presto : • Les opérateurs de récupération de données : depuis des services REST, SOAP ou bien des flux RSS ou bien par le web scraping. • Les opérateurs de transformation de données (jointure, tri, filtrage, élimination de doublons, troncature, inverser une liste, extraction de données). • Des opérateurs définis par encapsulation de code JavaScript, XQuery. MSS L’ensemble des opérateurs de MSS comprend : • Des opérateurs qui réalisent des tâches que nous retrouvons dans le langage SQL comme la sélection, la jointure. • Des opérateurs exécutant des tâches spécifiques interprétées selon l’ontologie de MSS (par exemple, « trouver des maisons », « trouver des vols »). Tableau'2':'Opérateurs'proposés'dans'les'outils'étudiés 2.1.3 Mashlet Un mashlet est un composant graphique qui affiche des données sous la forme d’un widget. Il récupère des données auprès de fournisseurs de données, il les manipule avec des opérateurs de données et il les retourne en sortie. Les données produites sont alors visualisées graphiquement. Par exemple, le mashup ItineraryPlanner (défini dans le Chapitre 1) contient trois mashlets : le premier « Map » permet l'affichage de l'itinéraire entre deux villes sur une carte, le deuxième « Weather » se charge d’afficher les informations météorologiques dans les principales villes sur cet itinéraire et le troisième « Restaurants » affiche une liste de restaurants dans la ville d’arrivée. Cette définition n’est pas unique. Elle est générale et couvre les différents points de vue des modèles et les outils étudiés. En effet certains utilisent des terminologies différentes pour désigner ce concept et d’autres ne couvrent pas tous les aspects mentionnées : • Dans [3][34], un mashlet est un composant qui a des données en entrée et en sortie. Il interroge des sources des données, utilise des services web externes et définit la coordination entre ces composants. Il peut intégrer une représentation graphique de ses données.19 • Dans [35][36][37], ce concept est décrit avec le terme largement connu : widget. Un widget est une interface graphique affichant des informations récupérées auprès d’une source de données externe. • Dans [32][38][10][39], les auteurs utilisent même le terme mashup pour désigner ce concept. Un mashup est une application qui combine des données provenant de différentes sources. La combinaison est réalisée par le moyen d’un flot de données. • Enfin, dans [40], les auteurs séparent l’aspect combinaison de données et l’aspect visualisation. Ils désignent la combinaison de données sous le nom de mashup alors que le terme mashlet désigne la visualisation de ces données. 2.1.4 Wiring) Un wiring définit un échange de données entre deux mashlets [35][14][41]. Par exemple, dans le mashup ItineraryPlanner, un wiring (cf. Figure 3) est nécessaire pour envoyer les données des villes de passage depuis le mashlet « Map » au mashlet « Weather ». Dans [34][42], les auteurs intègrent ce concept dans leur outil sans y donner un nom. On parle de navigation entre mashlets. Dans [3], les auteurs intègrent le principe d’échange de données entre mashlet, mais sans lui donner de nom. Figure'3':'Échange'de'données'entre'les'mashlets'Map'et'Weather'défini'par'un'wiring Le Tableau 3 indique les modèles/outils qui permettent de définir des wirings entre les mashlets. Nous constatons que le principe d’échange de données entre les mashlets (définition de wirings) n’est pas omniprésent dans les modèles/outils de mashups étudiées. Par exemple dans iGoogle, les mashlets ne communiquent pas entre eux ; ainsi avec ce genre d’outil, nous ne pouvons pas modéliser le mashup ItineraryPlanner. Ce constat souligne l’hétérogénéité des visions de ce qu’est un mashup. Ceci est dû à l’apparition récente de cette notion de mashups Modèles/Outils intégrant le concept Wiring Modèle relationnel de mashups, Intel MashMaker, WSO2 Mashup Server, Presto Modèles/Outils ne prenant pas en charge le concept Wiring Montage, Yahoo ! Pipes Tableau'3':'Gestion'de'wirings'dans'les'outils'étudiés 2.1.5 Mashup Dans les travaux étudiés, nous avons constaté qu’un mashup est défini sous-différentes terminologies. Dans [31][36], il est défini en tant que technologie émergente qui consiste en la 20 création d’applications ad hoc par des utilisateurs finaux. Dans [1][43][37], un mashup est défini en tant qu’un nouveau type d’applications web qui permettent de combiner de données issues de différents sources. Dans [44], un mashup est défini en tant qu’une approche de développement d’applications qui permet à des utilisateurs finaux de combiner des données provenant de différentes sources. Dans ces définitions, le terme récurrent est application et l’idée sous-jacente est la combinaison de données provenant de différentes sources. Dans les modèles/outils qui intègrent le principe de transfert de données entre mashlets (définition de wirings, voit sous-section 2.1.4), un mashup est vu comme un ensemble de mashlets et de wirings qui coordonnent ces mashlets. Alors que dans les modèles/outils qui n’intègrent pas la définition de wiring, un mashup est vu comme un ensemble de mashlets seulement. Par exemple, le mashup ItineraryPlanner prend en entrée des paramètres indiquant les villes de départ et d’arrivé et un tarif moyen pour les restaurants. Il contient les trois mashlets « Map », « Weather » et « Restaurants ». Il contient aussi deux wirings : le premier pour transférer les villes de passages depuis le mashlet « Map » vers le mashlet « Weather » et le deuxième pour transférer les coordonnées géographiques du lieu d’arrivé depuis le mashlet « Map » vers le mashlet « Restaurants ». Comme indiqué dans la sous-section 2.1.3, le concept de mashlet est parfois désigné avec le terme mashup dans certains modèles/outils. Ceux ci emploient le terme « dashboard » pour faire référence au mashup (en tant qu’ensemble de mashlets). 2.1.6 Modèle)relationnel)de)mashups Dans [3], les auteurs introduisent un modèle relationnel pour définir les mashups de données. Le modèle est basé sur les relations. Ce choix de modélisation est justifié par les bases mathématiques du modèle relationnel. Un mashlet est défini comme un ensemble de relations. Celles ci sont classifiées comme suit : • Relations internes : elles sont utilisées pour contenir des données propres au mashlet et non exposées à d’autres mashlets. • Relations entrée/sortie : elles sont utilisées pour définir l’interface du mashlet via laquelle il interagit avec l’utilisateur et d’autres mashlets. • Relations de service : elles représentent des web services que le mashlet peut importer. L’interaction entre ces relations est définie par des règles actives (du style Datalog [45][46]). Par exemple, soit un mashlet !"#$ dont les relations sont liées par la règle active suivante : !!"# !"#, !"#$%%$, !"# ∶ − !!" ! , !!"#$! !, !"# , !"!"" !"#, !"#$%%$, !"# !!" est une relation qui représente un formulaire où l’utilisateur entre le nom d’une maladie !. La relation locale !!"#$! !, !"# fournit les noms des médecins spécialistes dans le traitement de la maladie !. Soit le service web !"!"" !"#, !"#$%%$, !"# qui fournit l’adresse, et le numéro de téléphone pour un médecin identifié par son nom. La relation !!"# !"#, !"#$%%$, !"# affiche le résultat contenant les noms des médecins, leurs adresses ainsi que leurs numéros de téléphones. 21 Dans le même esprit, les interactions entre mashlets (sans mention du terme wiring) peuvent être décrites avec des règles actives. Soit un mashlet !"#$%& qui affiche les adresses des médecins sur une carte. Il importe la relation de sortie du mashlet !"#$ via la règle active suivante7 : !"#$%&. !"#!" !, !, !"# ∶ − !"#$. !!"# !"#, !"#$%%$, !"# , !""#$%&'!"" !"#$%!", !, ! L’adresse, donnée par la relation !"#$. !!"# !"#, !"#$%%$, !"# , est convertie en coordonnées géographiques ! et ! via le service web !""#$%&'!"". Un mashup est vu comme un réseau de mashlets qui interagissent entre eux. Les auteurs évoquent le besoin éventuel de manipuler les données (filtrage tri etc.). Pour répondre à ce besoin, ils proposent, dans une perspective ultérieure, la possibilité d’enrichir les règles actives avec des fonctions de manipulation de données ou de déléguer ces fonctionnalités à des services web. 2.1.7 Modèle)de)Hoyer Dans [37], les auteurs proposent un modèle des concepts de mashups. Il est fait avec un digramme de classes de la notation UML (Figure 4 8 ). Ils y introduisent la notion d’usage qui correspond à l’autorisation de l’utilisation d’une ressource ou d’un mashlet (widget) par une certaine personne (client) contre certaines conditions et certains frais. Les « pipings » correspondent aux opérateurs d’agrégation de données. Un wiring y est défini comme étant un moyen de communication entre deux widgets avec des paramètres de mapping indiquant les connections entre les entrées et les sorties des widgets. Figure'4':'Modèle'de'mashups'de'Hoyer 7 Une relation ! d’un mashlet ! est notée !. ! 8 Image obtenue de [37]. 22 2.1.8 Modèle)de)mashups)MACE MACE [39] est une plateforme de cache pour les mashups. Les auteurs y intègrent une proposition d’un modèle de mashups. Un mashup9 (1) récupère des données depuis des sources différentes, (2) les manipules et (3) les retournes à l’utilisateur final. !"#$% = !"! , !"! , … , !"!!! représente l’ensemble de mashups définis dans la plateforme de mashups à un moment donnée. La plateforme de mashup inclut un ensemble de classes d’opérateurs décrivant la manipulation des données comme le tri, le filtrage, l’élimination de doublons, la troncature, la jointure, le comptage, l’extraction de données. Les auteurs introduisent deux classes d’opérateurs décrivant la récupération de données depuis une source externe (fetch) et la livraison du résultat (dispatch). !"#$% = !"! , !"! , … , !"!!! dénote l’ensemble de classes d’opérateurs disponibles dans la plateforme de mashups. Chaque classe d’opérateur définit sa propre signature. Un mashup comprend un ensemble d’instances d’opérateurs de !"#$%. Cet ensemble contient un ou plusieurs instances de l’opérateur fetch et une seule instance de l’opérateur dispatch. Un mashup est modélisé avec une structure d’arbre. Chaque nœud correspond à une instance d’opérateur. Le nœud racine correspond à l’instance de l’opérateur dispatch et les nœuds feuilles correspondent aux instances de l’opérateur fetch. La valeur de la sortie de l’instance d’opérateur d’un nœud est l’entrée (ou une des entrées) de l’instance d’opérateur du nœud parent. Les mashups, vus comme des arbres, peuvent partager les données provenant des mêmes sources. Ainsi l’ensemble des mashups forme des graphes orientés acycliques (Directed Acyclic Graphs DAGs). 2.2 Systèmes)d’exécution)de)mashups Cette section présente les composants d’une architecture générale des systèmes d’exécution de mashups (sous-section 2.2.1). Ensuite, elle présente les manières de déploiement de ces composants (sous-section 2.2.2). La présentation est accompagnée d’un positionnement des systèmes d’exécution des outils étudiés par rapport à l’architecture et au déploiement des composants. 2.2.1 Architecture)générale La Figure 5 présente l’architecture générale, d’un système d’exécution de mashups, déduite à partir de nos lectures des travaux existants. D’un point de vue architectural, les systèmes d’exécution de mashups mettent en jeu plusieurs composants disjoints qui interagissent entre eux pour réaliser l’exécution des mashups. Tous ces composants ne sont pas présents dans toutes les architectures : • Les fournisseurs de données (Providers) sont des composants autonomes que l’on peut interroger (Invoke) à l’aide d’une requête ayant un ou plusieurs paramètres. L’interrogation de ces fournisseurs se fait selon un protocole d’accès. Ils ne font pas partie des systèmes de mashups. Cependant, nous les évoquons pour illustrer et comparer les capacités des outils étudiés à interagir avec des fournisseurs hétérogènes. Le Tableau 4 indique les protocoles 9 Notons que cette définition correspond au concept mashlet présenté à la sous-section 2.1.3 où nous avons souligné que dans certains modèles/outils le concept de mashlet est parfois désigné avec le terme mashup.23 d'accès aux données des fournisseurs pris en charge dans les outils de mashups étudiés. Pour un outil de mashup, plus le nombre de protocoles d’accès pris en charge est grand, plus le choix offert de fournisseurs de données est large lors de la création de mashups. Montage Yahoo ! Pipes Intel MashMaker WSO2 Mashup Server Presto MSS REST10 REST, HTTP11 HTTP REST, SOAP12, HTTP REST, SOAP, HTTP SOAP Tableau'4':'Protocoles'd'accès'aux'données'des'fournisseurs'dans'les'outils'de'mashups'étudiés • Le Catalog est un composant optionnel qui n’est pas présent dans tous les outils de mashups. Il enregistre les mashlets et les mashups crées et les mets à disposition des utilisateurs des mashups Tous les outils d’exécution de mashups étudiés intègrent le composant Store sauf MSS où l’utilisateur doit définir son besoin sans avoir recourir à un tel composant. • Le composant MashupGUI, généralement un navigateur web, constitue l’interface via laquelle l’utilisateur choisit un mashup depuis le Catalog et demande son exécution au composant MashupEngine. • Le composant MashupEngine est responsable de l’exécution des mashups. Il interagit avec les composants Providers afin de récupérer des données. o Dans les outils Montage (comme dans iGoogle), le composant retourne ces données directement à l’utilisateur (via le composant MashupGUI). o Dans les autres outils étudiés, ce composant manipule ces données et coordonne les exécutions des mashlets et des wirings des mashups. Il contient un buffer qui offre les outils pour le stockage temporaire de données en cours de traitement. Le résultat est retourné au composant MashupGUI. Figure'5':'Les'composants'd'une'architecture'générale'd'un'système'd'exécution'de'mashups 10 http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm 11 http://www.w3.org/Protocols/rfc2616/rfc2616.html 12 http://www.w3.org/TR/soap/24 2.2.2 Déploiement L’amélioration de la disponibilité de données des mashups est impactée par les choix faits au niveau du déploiement des composants présentés dans la sous-section 2.2.1. En effet, sa portée est limitée à l’endroit où les mashups sont exécutés. D’un point de vue du déploiement, les systèmes d’exécution de mashups sont classés en 2 catégories [47][48][49][11] : les systèmes où les mashups sont exécutés côté serveur (server-side mashup) et les systèmes où les mashups sont exécutés côté client (client-side mashup). (a) Côté(client Dans un mashup exécuté côté client (client-side mashup) la récupération et la manipulation de données se produisent chez le client, généralement dans un navigateur Web. La Figure 6 présente le diagramme de déploiement dans un environnement où les mashups sont exécutés côté client. On y remarque que le composant responsable de l’exécution des mashups est déployé sur la machine de l’utilisateur final. Ce choix de déploiement est adopté par l’outil Intel MashMaker [50]. Celui ci fonctionne en tant qu’une extension de navigateur web qui manipule de données contenues dans des pages web. Figure'6:'Diagramme'de'déploiement'des'composants'd'un'système'd’exécution'de'mashups'(côté'client)' La Figure 7 présente le diagramme de communication13 illustrant le fonctionnement d’un mashup exécuté côté client : 1. L’utilisateur lance le mashup via l’interface graphique (MashupGUI). Ainsi l’interface envoie une requête au serveur des mashups (MashupsServer) pour demander le code source du mashup des paramètres donnés. 2. Le code source du mashup est chargé sur la machine de l’utilisateur. Ce code comprend un script JavaScript qui contient des requêtes pour la récupération des contenus des services de données. 3. La machine du client envoie des demandes de récupération de données auprès des fournisseurs de données (Service). 4. Les fournisseurs de données retournent les données demandées. 5. Les données récupérées sont agrégées pour produire le résultat du mashup. Pour des raisons de sécurité, les navigateurs appliquent la politique « Same Origin Policy 14 » : interdisant, dans une page web, la communication entre le client et plusieurs serveurs 13 Dans la norme UML 1, le diagramme de communication s’appelait diagramme de collaboration. 14 http://www.w3.org/Security/wiki/Same_Origin_Policy Mashup User Machine Mashups Server Store& MashupGUI& MashupEngine&25 (cross-domain communication) 15 . Pour cela la plupart de outils de mashups étudiés privilégient l’exécution des mashups sur un serveur dédié et non sur les machines des clients. Figure'7':'Diagramme'de'communication'illustrant'le'fonctionnement'd'un'mashup'exécuté'côté'Client (b) Côté(serveur Dans un mashup exécuté côté serveur (server-side mashup) la récupération et la manipulation de données se produisent sur le server de mashups. La Figure 8 présente le diagramme de déploiement dans un environnement où les mashups sont exécutés côté serveur. On y remarque que le composant responsable de l’exécution des mashups est déployé sur un serveur de mashups. Ce choix de déploiement est adopté par la plupart de systèmes d’exécutions de mashups étudiés. Plusieurs raisons justifient ce choix : la politique Same Origin Policy ne s’applique pas dans ce cas (voir sous-section 2.2.2(a)) . Ce choix permet d’alléger la quantité de données envoyées au client. Le serveur peut gérer les messages d’erreur des fournisseurs des données avant de retourner un résultat au client. Figure'8':'Diagramme'de'déploiement'des'composants'd'un'système'd’exécution'de'mashups'(côté'serveur) La Figure 9 présente le diagramme de communication illustrant le fonctionnement d’un mashup exécuté côté serveur : 1. L’utilisateur lance le mashup via l’interface graphique (MashupGUI). Ainsi l’interface envoie une requête au serveur des mashups pour exécuter le mashup avec des paramètres donnés. 15 Récemment, HTML5 [51] inclut dans ses spécification une caractéristique Cross-Site XMLHttpRequest autorisant la communication du client avec plusieurs serveurs. :"User"Machine" :"Mashups"server" :"Service"" 1 : Récupération du code source du mashup 2 : code source du mashup 3 : demande de données 4 : données demandées 5 : agrégation de données Mashup User Machine Mashups Server MashupEngine, Store, MashupGUI,26 2. Le serveur de mashups (MashupsServer) envoie des demandes de récupération de données auprès des fournisseurs de données (Service). 3. Les fournisseurs de données retournent les données demandées. 4. Les données récupérées sont agrégées pour produire le résultat du mashup. 5. Le résultat du mashup est retourné à l’interface graphique. Figure'9':'Diagramme'de'communication'illustrant'le'fonctionnement'd'un'mashup'exécuté'côté'serveur 2.3 Disponibilité)de)données fraiches)sur)le)web La disponibilité désigne le fait de pouvoir être rapidement utilisé, d'être à la disposition de quelqu'un. En informatique, la disponibilité de données (data availability) signifie avoir les données obtenues et accessibles à n’importe quel moment [52][53][54]. La fraicheur caractérise l’état de ce qui est frais. En informatique, la fraicheur de données (data freshness) signifie que les données qu’un utilisateur a à disposition sont les mêmes que celles qui peuvent être fournies par le fournisseur de service au même moment [55][56][57]. Cette section étudie la disponibilité de données fraiches sur le web et en particulier dans les mashups. Lors de notre étude de l’état de l’art nous avons constaté que, bien qu’il existe des études qui ont identifié la disponibilité et la fraicheur de données comme des qualités à prendre en compte pour les mashups, il n’existe pas de travaux qui ont proposé des solutions pour garantir la disponibilité des données fraiches dans les mashups. Nous avons identifié (1) des travaux proposant des formules pour mesurer les qualités de la disponibilité et de la fraicheur de données dans les mashups et (2) d’autres travaux proposant des solutions pour améliorer la disponibilité des donnés sur le web. Généralement, la disponibilité de données est garantie et améliorée par différentes solutions logicielles [58][54] comme la réplication [59][60][61] ou le cache [62][63]. Ces solutions peuvent être accompagnées d’une solution orthogonale matérielle qui consiste en la redondance du matériel au niveau des fournisseurs des données [64][65][66]. 2.3.1 Mesure)de)la)disponibilité)de)données)dans)les)mashups) Dans les mashups, la disponibilité des données correspond à la capacité du mashup à fournir les données attendues par l’utilisateur. La disponibilité des données d’un mashup est :"Mashups"server" :"Service"" 1 : lancer l’exécution du mashup 5 : résultat du mashup 2 : demande des 3 : données données demandées :"MashupGUI 4 : agrégation de données 27 relative à la disponibilité de données des fournisseurs. L’exécution d’un mashup peut souffrir d'une indisponibilité des données qui pourrait être causée par de nombreux facteurs : • L’indisponibilité des fournisseurs de données. • La déconnexion du client. • Des limitations d'accès possibles, telles que les licences d’utilisation des services. En fonction du contexte d'utilisation, on peut considérer ces limitations comme des restrictions diminuant la qualité des fournisseurs ou une décision nécessaire pour prévenir la surcharge des fournisseurs qui peut diminuer leur disponibilité. Dans [67], les auteurs présentent cette qualité sous le nom la complétude des données. (data completeness). Celle ci fait référence à la capacité d'un mashup de produire toutes les valeurs de données attendues. Elle est évaluée en estimant le rapport entre la quantité de données récupérées !"# et la quantité de données attendues !"# : ! = !"# !"# D’autre part, les auteurs définissent la disponibilité d’un mashup comme étant la possibilité de fournir les données d’au moins un des mashlets. Ainsi elle est exprimée selon la formule suivante : !"#$% = 1 − (1 − !"#$%! ) ! !!! Dans cette formule, la valeur de !"#$% vaut 0 (non disponible) ou 1 (disponible). !"#$%! désigne la disponibilité d’un mashlet ! du mashup. Si les données d’un des mashlets sont disponibles (i.e. ∃! !"#$%! = 1) alors le produit dans la formule est nul et le mashup est considéré disponible ( !"#$% = 1 − 0 = 1 ). Inversement, si les données de tous les mashlets sont non disponibles (i.e. ∀!, !"#$%! = 0) alors le produit dans la formule vaut 1 et toutes le mashup est non disponible (!"#$% = 1 − 1 = 0). 2.3.2 Rafraichissement)de)données)des)mashups Dans certains cas, le mashup a besoin que les données soient générées et mises à jour en permanence (par exemple, marchés boursiers ou données météorologiques). Un grand nombre de décisions stratégiques, en particulier dans les entreprises, sont généralement faites selon les derniers états ou valeurs des données. Il est donc important qu'un système de mashups propage les mises à jour des sources de données pour les utilisateurs concernés. Dans [68], les auteurs définissent la qualité de la fraicheur d’une donnée sous le terme Timeliness. Elle est mesurée avec la formule suivante : !"#$%"&$'' = !"# 0, 1 − !"##$%!& !"#$%&#&' ! Dans cette formule, l’exposant ! est un facteur qui permet de contrôler la sensibilité de la valeur de la fraicheur au rapport !"##$%!& !"#$%&#&' . La valeur de ! dépend du contexte et elle est fixée d’une façon subjective et elle est sujette d’un jugement de celui qui analyse les données. Dans cette formule la valeur de !"#$%"&$'' varie de 0 à 1. La valeur de !"##$%!& exprime l’âge de la donnée alors que la valeur de !"#$%&#&' exprime la durée de vie fixée pour la donnée selon le contexte. Les données fraiches sont ceux dont le rapport !"##$%!& !"#$%&#&' est inférieur à 1. 28 Dans [67], les auteurs expriment dans une formule la qualité de la fraicheur d’un mashup par rapports aux valeurs du paramètre !"#$%"&$'' des données du mashups. La formule est la suivante : !"#$%"&$''!"#!!" = ! !"#$%"&$'!! , … , !"#$%"&$''! Où ! peut être la fonction maximum, minimum ou moyenne. Elle est définit en fonction du contexte par celui qui analyse les données. La fraicheur des données du web est assurée par un mécanisme de rafraîchissement des données. Il peut être fait suivant deux stratégies [69][70] : pull et push. À l'heure actuelle, les systèmes d’exécution de mashup n’implantent que la stratégie pull. La valeur de la fréquence de récupération est statique. Il y a deux stratégies pour gérer les intervalles de rafraichissement dans les systèmes d’exécution de mashups [69] : • Stratégie globale : Dans cette stratégie l’intervalle de rafraichissement est le même pour toutes les données. il est fixé par le système d’exécution de mashup ou l’utilisateur final. Ce choix est adopté dans : o Yahoo! Pipes : une heure selon [69]. o Popfly : l’intervalle dépend de la fréquence du chargement de la page par l’utilisateur final. o Intel MashMaker : l’intervalle est fixé par défaut par le système d’exécution du mashup. Cependant l’utilisateur final peut demander le rafraichissement d’une page. • Stratégie locale : Dans cette stratégie, un intervalle spécifique de rafraichissement est affecté à chaque source de données. Cette stratégie est adoptée par Damia [38] où les auteurs supposent les valeurs des intervalles de rafraichissement sont indiquées par les fournisseurs de données. 2.3.3 Disponibilité)de)données)par)la)réplication La réplication de données est la création de copies multiples (nœuds de réplication) des données avec l’objectif d’améliorer leur disponibilité et leur fiabilité et d’améliorer les performances d’accès à ces données [61][59]. La plupart des travaux visant à améliorer la disponibilité de données sont basés sur un processus de réplication. Malgré ces avantages, la réplication a un coût qui consiste en le maintien de la cohérence entre les copies d’une même donnée. D’où la naissance d’un compromis entre deux contradictions majeures : assurer la cohérences des copies toute en conservant des QoS de performance. Chaque copie de données est accompagnée de la copie du système d’interrogation sous-jacent. Une politique de réplication fait référence à l’algorithme gérant les différentes copies d’une même donnée [71]. Il existe deux stratégies de propagation des mises à jour : la stratégie impatiente (eager replication) [72]. et la stratégie paresseuse (lazy replication) [73]. Dans le premier cas, la mise à jour est appliquée sur toutes les copies en même temps, au sein d’une même transaction (le nœud traitant la transaction envoie des messages aux autres nœuds avant de procéder au commit). Alors que dans le second cas, la mise à jour est appliquée à une seule copie par la transaction originelle. Elle est propagée de manière asynchrone vers les autres copies. Dans [74], les auteurs proposent d’améliorer la disponibilité des bases de données en adaptant la stratégie impatiente. Ce choix est justifié par la possibilité de détection de conflits avant la fin de la transaction ce qui augmente le niveau de cohérence entre les nœuds. Leur proposition d’adaptation vise à réduire les messages (qui correspondent à des mises à jour) entre les nœuds. Pour cela ils proposent de transférer ces messages au sein d’une même transaction et ceci une fois les opérations de lecture en cours sont terminées.29 Dans [75], les auteurs proposent d’améliorer la disponibilité de données en adaptant la stratégie paresseuse. Ce choix est justifié par la rapidité de traitement des transactions. Normalement dans un processus de réplication, les opérations doivent être exécutées toutes dans le même ordre. Dans leur contribution, les auteurs décrivent un type d’opérations pouvant ne pas respecter l’ordre d’exécution donnant lieu à des meilleurs performance ceci sans altérer la cohérence des nœuds. Ils proposent trois types d’opérations (avec des exemples des opérations sur un système de messagerie, où les données sont répliquées) : • Opérations causales : l’exécution de l’une affecte l’exécution de l’autre. Par exemple : l’envoie et la lecture de messages. o Opérations forcées : elles sont ordonnées entre elles mais pas forcement par rapport aux autres opérations. Par exemple : l’ajout et la suppression d’un contact. o Opérations immédiates : elles sont exécutées en ordre par rapport à toutes les autres opérations. Par exemple : la suppression multiple. • Opérations non causales : elles n’ont aucune dépendance. Par exemple : la lecture d’un message m1 et celle d’un autre m2. Dans [61], les auteurs étudient les approches de la propagation des messages entre les nœuds afin d’assurer la disponibilité de données : • Dans l’approche de la réplication passive primaire-sauvegarde (Primary-Backup), un nœud est désigné comme étant primaire. Il reçoit la requête (d’interrogation ou de mise à jour) d’un client, l’exécute et propage le résultat aux autres nœuds (backup). Ces derniers interviennent en cas de défaillance au niveau de la copie primaire. L’avantage de cette approche est d’assurer que toutes les copies sont dans le même état. • Dans l’approche réplication active ou en chaine (Chain Replication), le client soumet sa requête à un des nœuds, cette requête est propagée en chaine d’un nœud à un autre. Chaque nœud exécute la requête et le dernier nœud transmet le résultat au client. L’avantage de cette approche est que n’importe quel nœud peut être interrogé. 2.3.4 Disponibilité)de)données)par)le)cache L’utilisation de caches de données sur le réseau Internet a suscité l’attention de différents travaux de recherche dans différents domaines : données du web [76][63][77], les systèmes de gestion de bases de données [78][79][80], les entrepôts de données [81][82][83] ainsi que les moteurs de recherche [84][85][86]. Dans [63], les auteurs ont dressé les avantages de l’utilisation du cache. Parmi ces avantages, nous trouvons l’amélioration de la disponibilité de données en cas d’une défaillance au niveau du fournisseur ou du réseau. Dans [58], les auteurs proposent une solution pour améliorer la disponibilité de données scientifiques utilisées par des chercheurs pour procéder à des calculs. Ils proposent d’utiliser les espaces disque disponibles sur leurs ordinateurs de bureau (au sein d’un réseau local LAN) pour cacher les données récupérées depuis des sources externes. Chaque ordinateur est considéré comme un nœud. Un de ces nœuds maintient des informations sur l’état des autres nœuds, la distribution des données cachées sur les nœuds et les informations sur la récupération des données (URI, protocoles de récupération etc. Le cache de données pour les services web a été étudié dans différents travaux. Dans [87], les auteurs proposent une architecture de progiciels pour cacher les réponses XML des web services. Dans [88], les auteurs estiment que la description WSDL des services web manque d’informations pour mettre en place un mécanisme de cache. Ils proposent une version étendue de WSDL pour définir les données qui doivent être cachées. Dans [89], les auteurs constatent que les 30 réponses XML des services web nécessitent une analyse (avec l’interface DOM par exemple) avant d’être exploitées. Ainsi, ils proposent de cacher le résultat de l’analyse (arbre DOM). D’autres travaux se sont intéressés au cache des résultats de services web dans les environnements mobiles où le cache permet de maintenir l’accès aux données même en cas de perte de connexion avec les fournisseurs des données. Dans [90], les auteurs présente une implantation d’un cache sur un dispositif mobile afin d’assurer la disponibilité de données en cas de déconnexion. Ils présentent ensuite des défis à traiter dans ce domaine : • Développer la sémantique des opérations offertes par le web service. Ces opérations sont hétérogènes. Il faut au moins (1) pouvoir identifier si une opération exécute une mise à jour, (2) savoir si des données obsolètes d’une opération restent acceptables pour l’utilisateur. • Maintenir la cohérence du cache. pendant la déconnexion du dispositif mobile, la cohérence ne peut pas être garantie fortement. En plus il faut prendre en compte des opérations des mises à jours qui affectent la cohérence de données dans le cache. Par exemple, supposons que le cache contient une liste de contacts. La demande de suppression d’un contact affecte la cohérence de la liste stockée dans le cache. Ainsi il faudrait mener des études qui permettent au cache de pouvoir invalider des données suite à l’exécution d’autres requêtes. • Étudier l’expérience de l’utilisateur, pour évaluer l’impact de la solution proposée. • En cas de déconnexion, comment le cache doit réagir lorsqu’il reçoit une nouvelle requête. Les auteurs proposent comment idée, d’étudier la possibilité d’une réponse par défaut adaptée à chaque requête. • Étudier et proposer des mécanismes de préchargement de données afin d’améliorer la disponibilité des données. Dans [91], les auteurs proposent un cache distribué pour améliorer la disponibilité des données dans les environnements mobiles. Les données sont cachées sur des terminaux mobiles. Chacun de ces terminaux met son cache à disposition des autres terminaux. L’architecture (cf. Figure 1016) du cache est basée sur l’attribution de rôles aux terminaux mobiles : Figure'10 :'Architecture'du'cache'distribué'proposé'dans'[91] • Nœuds de cache (Caching Nodes CNs) : ils stockent les résultats des requêtes. 16 Figure obtenue de [91]31 • Répertoires de requêtes (Request Directories RDs) : pour une requête donnée, ils indiquent les nœuds de cache qui contiennent sont résultat. • Les nœuds interrogateurs (Requesting Nodes RNs) : ce sont les terminaux qui émettent les requêtes et qui pourraient devenir ensuite des nœuds de cache s’ils sont amenés à stocker le résultat de la requête (au cas où aucun des autres nœuds de cache ne contient le résultat). • Proxys des caches (Proxy Caches PCs) : ils font office d’intermédiaires entre les nœud interrogateurs qui soumettent les requêtes et les autres terminaux et les fournisseurs de données. Cette proposition impose une bonne disponibilité matérielle des proxys des caches qui constituent un point central pour assurer la communication entre les terminaux et même avec les fournisseurs de données. En plus, ses bénéfices dépendent de la connectivité des terminaux mobiles. Les auteurs n’aborde pas dans leur proposition les problèmes liées aux remplacement et le rafraichissement des données du cache. Dans [92], les auteurs proposent un cache de navigateur associé à iMashup [93] : un outil de création de mashups exécutés côté client. Le cache sert à stocker, sur la machine de l’utilisateur, les données récupérées depuis les fournisseurs de données externes. Une entrée du cache a une durée de vie adaptative !. Celle ci est inversement proportionnelle à la fréquence d’accès à cette donnée, et proportionnelle au nombre de succès de cache lors de la demande d’accès. Elle est définie avec les formules suivantes : !"#$ = ! !×!!"_!"#$% ! !" si !"#$ > ! alors ! = !"#$ sinon ! = ! ℎ!"_!"#$% correspond au nombre des succès de cache avec un poids ! (dans l’implantation ! = 1000). ! !" est une fonction croissante par rapport à la fréquence d’accès !". Cette formule indique que pour une entrée du cache, (1) plus le nombre de succès de cache est élevé plus il faut augmenter la durée de vie, et (2) et plus la fréquence d’accès à une donnée est élevée, plus il faut diminuer la durée de vie. Dans [39], les auteurs présentent MACE un système de cache pour les données des mashups. Ils proposent un modèle de mashups (cf. sous-section 2.1.8), où chaque mashup est vu comme un arbre dont les nœuds sont des opérateurs (similaire à un « pipe » dans Yahoo! Pipes). Un arbre peut être commun à plusieurs mashups ou utilisé comme un sous-arbre dans un arbre d’un autre mashup. Les auteurs y intègrent un cache qui sélectionne dynamiquement le nœud dont les données produites doivent être cachées. Chaque nœud ! possède (1) une valeur de coût associée !"! qui correspond à la latence de son exécution et une valeur de coût cumulatif !!"! qui représente la somme définie par la formule suivante : !!"! = !"! + !"! ! !"# !" !"#$% !"#$ !" ! Le choix du nœud à cacher prend en compte la fréquence d’exécution du nœud et la fréquence des mises à jour : il est plus intéressant de cacher les données du nœud qui est le plus fréquemment exécuté et qui demande le moins de mises à jour. La différence de fréquence d’exécution entre les nœuds d’un même arbre vient du fait qu’un nœud (et ses nœuds fils) peut faire partie d’un autre arbre. Ainsi le nœud ! choisi est celui qui maximise la valeur de l’expression !"#! = !"!×!!"! − !"!×!!"! où !"! et !"! dénotent respectivement la fréquence d’exécution et la fréquence de mise à jour du nœud !. Si le cache ne peut pas contenir, dans son espace libre, les données produites par le nœud, alors les données d’un autre nœud (le suivant qui maximise 32 l’expression du !"# ) sont choisies pour être cachées. Les auteurs n’aborde pas dans leur proposition les problèmes liées aux remplacement et le rafraichissement des données du cache. 2.4 Conclusion Nous avons dressé un état de l’art des travaux sur les modèles des mashups, les systèmes d’exécution de mashups et leurs architectures ainsi que la disponibilité de données fraiches sur le web. L’étude des modèles et de certains outils de création de mashups nous a permis d’identifier les concepts nécessaires pour décrire un mashup. Nous avons remarqué que dans ces travaux, la définition du mashup n’est pas la même : certains ont défini le mashup comme étant un ensemble de mashlets alors que d’autres ont restreint la définition d’un mashup à un mashlet. D’un autre côté les outils de création de mashups qui permettent l’échange de données entre les mashlets, définissent les wirings comme des simples intermédiaires qui permettent le transfert de données. Nous trouvons que cette conception de wiring est pauvre. Ceux ci peuvent être enrichis pour permettre d’effectuer un mapping de données lors du transfert entre le mashlet envoyeur et le mashlet receveur : ceci rend le mashlet receveur indépendant du format de données envoyées par le mashlet envoyeur. En plus, nous trouvons que ces modèles n’intègrent pas la spécification des caractéristiques de la disponibilité de données dans les mashups. Lors de analyse des approches existantes pour améliorer la disponibilité de données sur le web, nous avons identifiée des solutions à base de réplication et à base de cache. Ces solutions sont difficilement applicables dans le contexte de mashups. En effet, la réplication doit être mise en place au niveau des fournisseurs de données qui sont autonomes ou bien au niveau du client de ces fournisseurs : le système d’exécution des mashups. Or, dans ce cas, il faut répliquer des données hétérogènes avec des systèmes d’interrogations spécifiques à ces données. Dans le contexte des mashups, les fournisseurs de données ne sont pas connus à l’avance (avant la création des mashups), ainsi pour chaque nouveau fournisseur identifié, il faut lui demander l’accès à ses données internes et à son systèmes d’interrogation pour les répliquer, ce que nous considérons comme non garanti. D’autre part, les solutions à base de cache sont adaptées à des applications construites par des développeurs : le choix des politiques de cache sont faites par des développeurs : ils décident quelles données et à quelles étapes de la composition des services il faut cacher. Or de telles décisions ne doivent pas être laissées aux constructeurs des mashups qui ont souvent des compétences limitées en programmation et ne maitrisent pas les aspects non fonctionnels de l’environnement de construction des mashups. Bien que la plateforme MACE propose de cacher les données des mashups, cependant le fonctionnement du cache est défini avec l’objectif de diminuer la latence de l’exécution des mashups et non pour assurer la disponibilité des données des mashups. D’autre part nous trouvons que dans la solution de cache de [92] l’estimation d’une durée de vie adaptative ne prend pas prendre en compte des facteurs comme l’ancienne valeur de la durée de vie, la date du dernier accès à la donnée et la comparaison d’une donnée récupérée à celle existante en cache. Dans toutes ces solutions il manque la prise en compte de la fraicheur de données. Dans le Chapitre 3, nous proposons un modèle de mashup basé sur les modèles de valeurs complexes [19]. Ce modèle nous permettra de spécifier les caractéristiques de la disponibilité de données dans le Chapitre 4. 33 Chapitre!3 MODELE%DE%MASHUPS Ce chapitre présente les concepts de notre modèle de mashups : Donnée, Activité, Mashlet, Wiring, et Mashup. Une activité peut être basique ou composite. Une activité basique décrit une tâche spécifique permettant d’accomplir un traitement de données (le filtrage, la projection, l’extraction, l’élimination de doublons, le tri, l’union). Ces activités sont coordonnées par des activités composites (Sequence, Foreach, Parallel). Les mashlets affichent des données produites par des activités. Tandis que les wirings définissent le flot de données entre les mashlets. Ils peuvent aussi, décrire le traitement des données nécessaire pour les délivrer sous le bon format aux mashlets destinataires. L’ensemble de ces concepts décrit des composants qui constituent des mashups. Dans le mashup ItineraryPlanner, présenté dans le Chapitre 1 (cf. Figure 1), ces concepts se présentent comme suit : • Les données sont : o récupérées depuis des services (fournisseurs de données : Google Maps, Yahoo! Weather et Google Places). Ces services sont autonomes et indépendants des mashups. o ou saisies par l’utilisateur (viles de départ de et de destination)… o ou traitées et échangés entre les mashlets (villes de passages sur l’itinéraire). • Les activités qui décrivent le traitement de ces données (extraction de données, filtrage…). • Les mashlets (Map, Weather, Restaurants) constituent les composants qui affichent les résultats produits par des activités sous-jacentes. Ces composants sont réutilisables. C’est à dire un mashlet peut être utilisé dans la définition de différents mashups. • Le transfert des données entre les mashlets se fait via des wirings (la liste de villes de passage de Map vers Weather, les coordonnées de la ville d’arrivée de Map vers Restaurants). Les wirings procèdent à la manipulation des données transférées afin de les livrer dans le bon format. • Le mashup ItineraryPlanner est constitué des mashlets Map, Weather, Restaurants et des wirings qui définissent le flot de données entre ces mashlets. La Figure 11 présente les concepts Mashup, Mashlet, Wiring et Activités sous la forme d’une pile. Chaque mashlet et wiring est associé à une activité (basique ou composite). Un mashlet est réutilisable : il peut faire partie de plusieurs mashups. Un wiring appartient au mashup qui contient les mashlets sous-jacents. 34 Figure'11 :'Pile'de'concepts'de'mashups Le chapitre est organisé comme suit. La section 3.1 présente la caractérisation des données des mashups. Les concepts Activités, Mashlet, Wiring, Mashup sont décrit respectivement dans les sections 3.2 à 3.5. Ces concepts sont illustrés avec des exemples décrivant le mashup ItineraryPlanner présenté dans le Chapitre 1. Enfin la section 3.6 conclut ce chapitre. 3.1 Données)de)mashups Nous avons besoin d’une représentation de données qui permet l’homogénéisation de données de mashups. Pour cela, nous adoptons une caractérisation de données basée sur les valeurs complexes. 3.1.1 Types)de)données Un domaine est un ensemble fini de valeurs. Nous considérons les domaines prédéfinies des chaines de caractères !, des booléens !, des entiers ℤ, des entiers naturels ℕ,! et! des! réels!ℝ.! Nous définissons le domaine des noms de types ! = !! , !! , … ⊆ ! et celui des noms des instances ! = !! ,!! , … ⊆ ! avec ! ∩ ! = ∅. Un type de valeurs complexes ! dénoté !, est défini par une paire ! ∶ !"#, où A est le nom du type (A ∈ !) et !"# est sa définition. Nous considérons les fonctions !"#$ et !"# pour accéder respectivement aux composants de la paire. Par exemple pour le type !"#$"%&!'%" ∶ ℤ , Mashups Mashlets / Wirings Activités m1# m3# m2# Mashup Mashlet Activité w1# m1 m2# m3# m2# Wiring consomme w1# Données Donnée est associé à 35 !"#$ !"#$"%&!'%" ∶ ℤ retourne !"#$"%&!'%" et !"# !"#$"%&!'%" ∶ ℤ retourne ℤ. Le nom est unique et il est utilisé pour référencer le type. L’ensemble ! de types de données est défini par les règles suivantes : • Si ! est un domaine alors ! ∶ ! est un type atomique. • Si ! est un type alors ! ∶ ! est un type liste. • Si !! ,!! , … ,!! sont des types tels que ∀ !,! !"#$ (!! ) ≠ !"#$ (!! )alors ! ∶ !! ,!! , … ,!! est un type tuple. Chaque !! est un type caractérisant un attribut de nom !"#$ (!! ). • Si !! ,!! , … ,!!,!!, … !! sont des types tels que ∀ !,! !"#$ (!! ) ≠ !"#$ (!! ), alors ! ∶ !!× !!× …× !! → !!× …×!! est un type fonction17. Pour ! ∈ 1. . ! , !! est un type paramètre d’entrée de nom !a!" !! . Pour ! ∈ !. . ! , !! est un type paramètre paramètre de sortie de nom !"#$ !! . Dans la suite de ce document, lorsque nous introduisons un type, dans un souci de simplification, nous pourrons omettre le nom du type. Cette simplification s’applique également aux paramètres des types fonction. Notons que l’ensemble de types ! est lui même un domaine. 3.1.2 Instances)des)types ! dénote l’ensemble des instances de type !. Cet ensemble est défini par induction de la manière suivante : • ! ∶ ! = ! ∶ ! ! ∈ ! . Les valeurs du domaine ! sont connues. • ! ∶ ! = ! ∶ !! , … , !! | ! ∈ ℕ !" ∀ 1 ≤ ! ≤ !, !! ∈ ! . • Pour un type tuple ! ∶ !! ,!! , … ,!! où !!est de la forme !! : d!"! , ! ∶ !! ,!! , … ,!! = ! ∶ !! : !! , !! : !! , … , !!: !! | ∀ ! ∈ 1. . ! , !! ∶ !! ∈ !! . • ! ∶ !!× !!× …×!! → !!× …×!! = !| ! !"# !"# !"#$%&"n !"#$ !" !"#$%&'() !"# !!× !!× …×!! → !!× …×!! . Nous définissons le domaine !"#" incluant toutes les instances possibles et le domaine !"#$%&'#( incluant toutes les instances possibles de type fonction. !"#" = ! !∈! !"#$%&'#( = ! ! !"# !" !"#$ !"#$%&"# !"#$%&'#( ⊂ !"#" Nommage des instances Chaque instance ! ∶ ! d’un type ! ∈ ! peut être nommée comme suit : ! = ! ∶ !. Où ! ∈ ! est le nom de l’instance. Exemples : La suite présente des exemples de types et instances utilisés dans le mashup ItineraryPlanner décrit dans le Chapitre 1 (cf. Figure 1). 17 Dans notre modèle, une fonction possède plusieurs paramètres de sortie ; ce type de fonctions a été introduit par Maurice Fréchet dans ses travaux sur l’analyse fonctionnelle.36 Le service Yahoo! Weather retourne la météo d’une localisation décrite sous format WOEID18 . Par exemple l’instance !"#$% ∶ 12724717 correspond à la localisation de la ville de Grenoble. Elle est de type !"#$% ∶ ℕ. Le type !"#$%& ∶ !"#$% ∶ ℕ décrit une liste de localisations de villes décrites sous format WOEID. Par exemple l’instance !"#$%& ∶ !"#$% ∶ 12724717, !"#$%: 12724728, !"#$% ∶ 12726958, woeid ∶ 20068148, !"#$% ∶ 20068141 correspond à la liste de localisations des villes de passage entre Grenoble et Paris dans ItineraryPlanner et décrites sous format WOEID. !"#$%&!%'$ ∶ !"#$ ∶ !, !"#$%&'%() ∶ !, !"!"#$$ ∶ !, !"#$%& ∶ ℝ décrit le type tuple !"#$%&!%'$ avec les attributs : le nom du restaurant, sa spécialité, son adresse et sa note. L’expression !"#$ = !"#$%&!%'$ ∶ 〈!"#$:"!"#1", !"#$%&'%():"!"#$ç!!"#", !""#$%% ∶ "!"1", !"#$%& ∶ 4.5〉 définit une instance de ce type nommée !"#$. L’itinéraire entre deux villes est décrit dans un type tuple, nommé routes19, donnée ci dessous. On y retrouve par exemple les attributs suivants : • Un tuple nommé legs (manches). Il contient des attributs indiquant la distance, la durée totale, les adresses départ et d’arrivée de l’itinéraire et les étapes (steps) de l’itinéraire sous la forme d’une liste. • Chaque étape contient des informations sur sa distance (distance), durée (duration), points de départ et d’arrivée (start_location et end_location) des instructions (html_instructions). Chacune est décrite sous la forme d’une chaine de caractère. routes : 〈 bounds : 〈 northeast : 〈 lat : ℝ, lng : ℝ 〉, southwest : 〈 lat : ℝ, lng : ℝ 〉 〉, copyrights : !, legs :!〈! distance : 〈 text : !, value : ℝ 〉, duration : 〈 text : !, value : ℝ 〉, end_address : !, end_location : 〈 lat : ℝ, lng : ℝ 〉, start_address : !, 18 Un identifiant WOEID (Where on Earth IDentifier) est un identifiant de référence assigné par Yahoo! Pour identifier des points géographiques sur la terre. 19 La définition du type routes est basée sur la structure du document JSON renvoyé par le service Google Maps37 start_location : 〈 lat : ℝ, lng : ℝ 〉, steps : [ step : 〈 distance : 〈 text : !, value : ℝ 〉, duration : 〈 text : !, value : ℝ 〉, end_location : 〈 lat : ℝ, lng : ℝ 〉, html_instructions : !, polyline : 〈 points : ! 〉, start_location : 〈 lat : ℝ, lng : ℝ 〉, travel_mode : ! 〉 ] 〉 〉 L’exemple suivant présente une partie d’une instance20 de ce type donnant l’itinéraire entre Grenoble et Paris, nommé !"#$%&'. !"#$%&' = routes : 〈 bounds : 〈 northeast : 〈 lat : 48.857240, lng : 5.724690000000001 〉, southwest : 〈 lat : 45.18839000000001, lng : 2.306130 〉 〉, copyrights : "Données cartographiques ©2012 GeoBasis-DE/BKG (©2009), Google", legs :!〈! distance : 〈 text : "574 km", value : 573623 〉, duration : 〈 text : "5 heures 21 minutes", value : 19284 〉, end_address : "Paris, France", 20 Le tuple !"!"#$% est similaire à l’objet JSON obtenu par invocation du service Google Maps : http://maps.googleapis.com/maps/api/directions/json?origin=Grenoble&destination=Paris&senso r=false&38 end_location : 〈 lat : 48.857240, lng : 2.35260 〉, start_address : "Grenoble, France", start_location : 〈 lat : 45.18839000000001, lng : 5.724690000000001 〉, steps : [ step : 〈 distance : 〈 text : "92 m", value : 92 〉, duration : 〈 text : "1 minute", value : 7 〉, end_location : 〈 lat : 45.188890, lng : 5.725610000000001 〉, html_instructions : "Prendre la direction \u003cb\u003enordest\u003c/b\u003e sur \u003cb\u003ePl. Victor Hugo\u003c/b\u003e vers \u003cb\u003eRue Paul Bert\u003c/b\u003e", polyline : 〈 points : "mzxrGib}a@g@gA{@oB" 〉, start_location : 〈 lat : 45.18839000000001, lng : 5.724690000000001 〉, travel_mode : "DRIVING" 〉, step : 〈…〉, …… ], 〉, …… 〉 3.1.3 Types)et)valeurs)d’instances Pour accéder aux types et aux valeurs des instances de la forme ! ∶ !"#$%, nous définissons les fonctions !"#$ et !"# de la manière suivante : • !"#$ ! ∶ !"#$% = !. Nous rappelons qu’un type ! ∶ !"# est référencé par son nom et qu’il est possible d’inférer le type ! ∶ !"# à partir de !. • !"# ! ∶ !"#$% = !"#$%. Par exemple, si ! dénote !"#$%& ∶ !"#$% ∶ 12724717, !"#$% ∶ 12724728, !"#$% ∶ 12724752, !"#$% ∶ 12726960, !"#$% ∶ 582081 , nous avons : • !"#$ ! = !"#$%& • !"# ! = !"#$% ∶ 12724717, !"#$% ∶ 12724728, !"#$% ∶ 12724752, !"#$% ∶ 12726960, !"!"# ∶ 582081 3.1.4 Opérations)sur)les)instances Chaque type possède un ensemble d’opérations qui définit le comportement de ses instances. Toute opération est d’un type fonction ∈ !"#$%&'#( , en considérant qu’elle a pour paramètres de types !! ,!! , … ,!! et pour signature !× !!× !!× …×!! → !!. Pour une instance ! de ! et 39 des instances !! ∈ !! , nous adoptons une notation pointée : !. !" !! , … , !! pour designer l’appel de l’opération !" sur l’instance ! avec les instances !! en paramètres d’entrée. Parmi les opérations sur les types, nous retrouvons des opérations qui définissent les relations d’ordre entre les instances d’un type ! comme !"##, !"#$%#", !"##$%&'()!, !"##$%&'()!, !"#$%#"!"#$%&' et !"#$%. Les types de ces opérations sont de la forme !×! → !. Ces opérations comparent les instances selon une des stratégies définies dans [94][95] : • Identité d’instance : comparer les identificateurs des instances. • Comparaison superficielle : comparer les valeurs des instances. • Isomorphisme (comparaison structurelle) : égalité si les structures sont isomorphes. • Comparaison profonde : comparer les valeurs des feuilles des instances. Nous définissons également l’opération !"#$%ℎ qui, pour une instance ! de type liste, retourne sa taille. Le type de !"#$%ℎ est de la forme ! → ℕ . L’appel de l’opération se fait avec la notation !. !"#$%ℎ (). Nous considérons aussi l’opération !"#$%& définie sur tous les types fonction pour réaliser l’exécution de leurs instances. Pour une fonction !, l’opération !"#$%& l’exécute avec des valeurs des paramètres données dans une liste d’instances. Elle retourne la valeur du paramètre de sortie correspondante de la fonction !. Elle est de type !"#$%&'#(× !"#$% ∶ !"#" → !"#" . Fonction !"#$%&'()* Nous définissons la fonction !"#$%&'()* qui pour chaque type retourne la liste des opérations qui définissent le comportement de ses instances. Elle est de type ! → !"#$%&'#( . 3.2 Activité Une activité consomme et produit des données. Elle peut être basique ou composite. Une activité basique décrit une tâche spécifique permettant d’accomplir un traitement de données. Une activité composite permet de coordonner les activités qu’elles soient basiques ou composites. La représentation graphique d’une activité est donnée dans la Figure 12. Figure'12 :'Représentation'graphique'd'une'activité Une activité est de type fonction. Nous considérons le domaine des activités ! ⊂ !"#$%&'#(. Notons que, dans notre modèle, certaines fonctions ne sont pas forcement des activités. Comme les fonctions définissant le comportement des instances d’un type : elle sont définies en tant qu’opérations (sous-section 3.1.4). 3.2.1 Activités)basiques Nous considérons un ensemble fini d’activités basiques comme l’extraction (Extract), le filtrage (Filter), l’élimination de doublons (Unique), le tri (Sort), l’union (Union) et l’annexe (Append). Ces activités sont présentées dans les sous-sections 3.2.1.1 à 3.2.1.6. 40 Les fournisseurs de données exportent des méthodes représentées par des activités. Des exemples de ces activités sont donnés au cours du chapitre lors du déroulement du scénario ItineraryPlanner. 3.2.1.1 Extract Une activité Extract retourne une valeur composante d’une instance ! d’un certain type !. Le résultat est construit à partir d’un chemin d’accès !"#ℎ. • Notation : !!"#! ! L’expression du chemin d’accès !"#ℎ est construite avec la règle suivante : !"#ℎ ∶= ! !. !"#ℎ ! ! ! ! . !"#ℎ Où ! y désigne le nom d’un type tandis que ! est un entier naturel. Validité du chemin par rapport à un type Pour un type ! donné, nous définissons !"#ℎ! ! comme étant l’ensemble des expressions de chemins d’accès !"!ℎ valides par rapport à !. Cet ensemble est définit comme suit : 1. Si !"#$ ! = ! alors !"#ℎ = ! ∈ !"#ℎ! ! . 2. Si ! est de la forme ! ∶ … , ! ! : !"#! , … et !"#ℎ′ ∈ !"#ℎ! ! ! : !"#! . alors !"#ℎ = !. !"#ℎ′ ∈ !"#ℎ! ! . 3. Si ! est de la forme ! ∶ ! ∶ !"# alors !"#ℎ = ! ! ∈ !"#ℎ! ! . 4. Si ! est de la forme ! ∶ ! ∶ !"# et !"#ℎ′ ∈ !"#ℎ! ! ∶ !"# , alors !"#ℎ = ! ! . !"#ℎ′ ∈ !"#ℎ! ! . • Type de l’activité : ! ∶ ! → !′ • Sémantique de l’activité : !!"#! ! est défini comme suit La valeur de !!"#! ! est donnée par les règles suivantes : 1. Si !"#$ ! = ! et !"#ℎ = ! alors !!"#! ! = !. 2. Si ! = ! ∶ … , ! ! : ! ! , … et !"#ℎ = !. !′ alors !!"#! ! = ! ! ∶ ! ! . Cette valeur est désignée avec la notation !. ! ! . 3. Si ! = ! ∶ … , ! ! : ! ! , … et !"#ℎ = !. ! ! . !"#ℎ′ alors !!"#! ! = !! ! .!"#! ! ! ! ∶ ! ! . Cette valeur est désignée avec la notation !. ! ! . !"#ℎ ! . 4. Si ! = ! ∶ ! ∶ !! , … , ! ∶ !! , … , ! ∶ !! et !"#ℎ = ! ! alors !!"#! ! = ! ∶ !! . Cette valeur est désignée avec la notation ! ! . 5. Si ! = ! ∶ ! ∶ !! , … , ! ∶ !! , … , ! ∶ !! et !"#ℎ = ! ! . !"#ℎ′ alors !!"#! ! = !!"#! ! ! ∶ !! . Cette valeur est désignée avec la notation ! ! . !"#ℎ ! . Exemple !!"#$%&.!"#$.!!"#$ ! .!"#$.!"#$"_!"#$%&"' !"#$%&' = !"#$"_!"#$%&"' ∶ !"# ∶ 45,18839000000001, !"# ∶ 5.724690000000001 . Cette valeur est désignée avec la notation !"#$%&'. !"#$. !"#$! 0 . !"#$. !"#$"_!"#$%&"!. Et !"#$%&' est l’instance du type !"#$%, tous les deux définis dans la sous-section 3.1.2. 41 3.2.1.2 Filter Une activité Filter prend en entrée une liste ! d’instances de ! de la forme ! ∶ ! ∶ !! , … , ! ∶ !! . Elle sélectionne les éléments de ! vérifiant une condition !"#$. Elle produit comme résultat une sous-liste de !. • Notation : !!"#$ ! • Type de l’activité : ! ∶ ! → ! L’expression de !"#$ est définie comme suit : Nous commençons par définir les termes avec les règles suivantes : ! Les valeurs constantes ! des instances ! ∶ ! sont des termes constants. Par extension, les termes constants dénotent aussi leurs valeurs. ! Si ! est un chemin d’accès alors ! est un terme (chemin). ! Si ! est une fonction d’arité n et que !1 … !" sont des termes alors ! (!1 … !") est un terme (fonction). Nous définissons des conditions basiques (basic conditions bcond) sur les termes (!1 et !2) avec les règles suivantes : !"#$% ∶= !1 ! !2 ! ∶= = ≠ < > ≤ ≥ ∈ ⊂ ⊆ Les opérateurs ensemblistes et de comparaisons doivent être compatibles avec les valeurs des termes. En plus, pour faciliter le calcul de la valeur booléenne d’une condition, nous définissons l’interprétation d’un terme !, par rapport à une instance !, dénoté ! !comme suit : ! Pour les termes constants !, ! ! = ! ! Pour les termes chemins !, ! ! = !!, !!, … , !! !" !!"#! ! !"# !"# !"#$% !" !" !"#$% ! ∶ ! ∶ !!, ! ∶ !! … , ! ∶ !! !"# !! ! !"#$# Dans le deuxième cas, le chemin d’accès aboutit à une valeur atomique dont la valeur est utilisée comme opérande de la condition. ! L’interprétation d’un terme fonction ! (!! … !!) par rapport à une instance ! est la valeur de l’instance résultat de l’application de la fonction ! sur les interprétations des termes !! … !! par rapport à ! : !(!! … !!) ! = !"# ! !! ! , … , !! ! . Une condition basique de la forme !1!"2 est considérée comme étant interprétable par rapport à un type ! si !1 et !2 sont interprétables par rapport à !. Une instance ! de ! satisfait cette condition basique, si !! !!!! !est vrai. Dans ce cas, nous notons ! ⊨ !!!!! . L’expression !"#$ est définie avec la grammaire ci dessous. !"#$ ∶= !"#$% ¬ !"#$ !"#$ ∧ !"#$ !"#$ ∨ !"#$ !"#$ !"#$% !!"ℎ !"#$% ∶= ∀ ∃42 Où !"#ℎ est un chemin d’accès qui identifie une liste et dont la grammaire est définie dans la sous-section 3.2.1.1. • Sémantique de l’activité !!"#$ ! = ! ∶ ! ∶ !! , … , ! ∶ !! ∀! ∈ !, ! , ! ∶ !! est présente dans ! et ! ∶ !! ⊨ !"#$ Satisfiabilité des expressions de filtrage La satisfiabilité des conditions de filtrage par rapport à une instance ! est définie avec les règles suivantes : 1. ! ⊨ ¬!"#$ si ! ⊨ !"#$ est faux. 2. ! ⊨ !"#$! ∧ !"#$! si ! ⊨ !"#$! et ! ⊨ !"#$! 3. ! ⊨ !"#$! ∨ !"#$! si ! ⊨ !"#$! ou ! ⊨ !"#$! 4. ! ⊨ !"#$ ∀ !"#ℎ!"# si pour chaque !! ∈ !"# !!"#!!"# ! , !! ⊨ !"#$ et !!"#!!"# ! est une liste 5. ! ⊨ !"#$ ∃ !"#ℎ!"# si pour un certain !! ∈ !"# !!"#!!"# ! , !! ⊨ !"#$ et !!"#!!"# ! est une liste Exemple Soit l’instance liste suivante : ! = !"#$%&!%'$# ∶ ∶ !"#$%&!%'$ ∶ !"#$ ∶ "!"#1", !"#$%&'%() ∶ "!"#$ç!"#$", !""#$%% ∶ "!"1", !"#$%& ∶ 4.5 , !"#$%&!%'$ ∶ !"#$ ∶ "!"#2", !"#$%&'%() ∶ "!"#$!%&&%", !""#$%% ∶ "!"2", !"#$%& ∶ 4 , !"#$%&!%'$ ∶ !!"# ∶ "!"#3", !"#$%&'%() ∶ "!"#$%$"&'", !""#$%% ∶ "!"3", !"#$%& ∶ 4.1 , !"#$%&!%'$ ∶ !"#$ ∶ "!"#4", !"#$%&'%() ∶ "!"#$%"&'(", !""#$%% ∶ "!"4", !"#$%& ∶ 3.6 L’expression !"#$%&!"# = !!"#$%&!%'$.!"#$%&!! ! produit : ! = !"#$%&!%'$# ∶ !"#$%&!%'$ ∶ !"#$ ∶ "!"#1", !"#$%&'%() ∶ "!"#$ç!"#$", !""#$%% ∶ "!"1", !"#$%& ∶ 4.5 !"#$%&!%'$ ∶ !"#$ ∶ "!"#2", !"#$%&'%() ∶ "!"#$!%&&%", !""#$%% ∶ "!"2", !"#$%& ∶ 4 , !"#$%&!%'$ ∶ !"#$ ∶ "!"#3", !"#$%&'%() ∶ "!"#$%$"&'", !""#$%% ∶ "!"3", !"#$%& ∶ 4.1 Lors de l’évaluation de !"#$%&'%(, la condition !"#$%&!%'$. !"#$%& ≥ 4 est évaluée sur tous les éléments de !. Nous traçons son évaluation sur le premier élément !! = !"#$%&!%'$ ∶ !"#$ ∶ "!"#1", !"#$%&'%() ∶ "!"#$ç!"#$", !!!"#$$ ∶ "!"1", !"#$%& ∶ 4.5 : !! ⊨ !"#$%&!%'$. !"#$%& ≥ 4 si !"#$%&!%'$. !"#$%&!! ≥ 4 !!. Nous avons !"#$%&!%'$. !"#$%&!! = !"# !!"#$%&!%'$.!"#$%& !! = !"# !"#$%& ∶ 4.5 = 4.5 (deuxième cas). Nous avons également 4 !! = 4 (premier cas). Donc !"#$%&!%'$. !"#$%&!! ≥ 4 !! est vraie. Ainsi !! vérifie la condition de filtrage de !"#$%&'%(. 43 3.2.1.3 Unique Une activité Unique prend en entrée une instance !, de type liste, contenant des instances !! d’un certain type !. Pour un chemin d’accès !"#ℎ ∈ !"#ℎ! ! 21 , Elle retourne une liste avec les doublons éliminés. • Notation : ! !"#! ! • Type de l’activité : ! ∶ ! → ! • Sémantique de l’activité : ! !"#! ! = !! , … !! tel que : o ∀!, !! ∈ ! ∄!! ,! ≠ ! !!"#! !! . !"#$% !!"#! !! si une opération d’égalité !"#$% est définie sur le type sous-jacent. o Sinon ! !"#! ! = ! Exemple Soit la liste d’instances ci dessous. Elle indique les villes intermédiaires entre Grenoble et Paris sous format WOEID22 . ! = !"#$%& ∶ !"#$% ∶ 12724717, !"#$% ∶ 12724717, !"#$% ∶ 12724717, !"#$% ∶ 12724728, !"#$% ∶ 12724728, !"#$% ∶ 12726958, !"#$% ∶ 12726958, !"#$% ∶ 20068148, !"#$% ∶ 20068141, !"#$% ∶ 20068141 L’expression !"#$!%&'()* ! = ! !"#$% ! retourne l’instance suivante : !"#$%& ∶ [!"#$% ∶ 12724717, !"#$% ∶ 12724728, !"#$% ∶ 12726958, !"#$% ∶ 20068148, !"#$% ∶ 20068141] 3.2.1.4 Sort Nous considérons le domaine !"#$" = "!"#$%&'%(","!"#$"%!&%'" . Une activité Sort prend en entrée une instance !, de type liste, contenant des instances !! d’un certain type ! et une instance ! de type atomique défini sur le domaine !"#$". Pour un chemin d’accès !"#ℎ ∈ !"#ℎ! ! 23 , Elle retourne une liste avec les valeurs !! ordonnées d’une manière croissante ou décroissante selon la valeur de !. • Notation : !!"#! !, ! • Type de l’activité : ! ∶ ! ×!"#$" → ! • Sémantique de l’activité : !!"#! !, ! = !! , … , !! tel que ∀!, !! ∈ ! et : o ∀! ≤ ! < !. !"#$%ℎ() ∈ ℕ, nous avons !! . !"##$%&'()! !! si ! = "!"#$%&'%(" et une opération !"##$%&'()! est définie sur le type sous-jacent. o ∀! ≤ ! < !. !"#$%ℎ() ∈ ℕ, nous avons !! . !"##$%&'()! !! si ! = "!"#$"%!&%'" et une opération !"##$%&'()! est définie sur le type sous-jacent. o Sinon !!"#! !, ! = !. 21 !"#ℎ est un chemin d’accès dont la grammaire est définie dans la sous-section 3.2.1.1. 22 La présence de doublons est due au fait de la présence de plusieurs étapes de l’itinéraire dans la même ville. 23 !"#ℎ est un chemin d’accès dont la grammaire est définie dans la sous-section 3.2.1.1. 44 Exemple L’expression !"#$%&' = !!"#$%&!%'$.!"#$%& !,"!"#$%&'%(" 24 retourne la liste suivante : !"#$%&!%'$# ∶ !"#$%&!%'$ ∶ !"#$ ∶ "!"#1", !"#$%&'%() ∶ "!"#$ç!"#$", !""#$%% ∶ "!"1", !"#$%& ∶ 4.5 , !"#$%&!%!" ∶ !"#$ ∶ "!"#3", !"#$%&'%() ∶ "!"#$%$"&'", !""#$%% ∶ "!"3", !"#$%& ∶ 4.1 , !"#$%&!%'$ ∶ !"#$ ∶ "!"#2", !"#$%&'%() ∶ "!"#$!%&&%", !""#$%% ∶ "!"2", !"#$%& ∶ 4 3.2.1.5 Append Une activité Append prend en entrée deux instances ! et ! de type liste contenant des instances de même type !. Elle retourne une liste qui est le résultat de l’union des deux listes. • Notation : ! ∪ ! • Type de l’activité : ∪∶ ! × ! → ! • Sémantique de l’activité : ! ∶ !! … !! ∪ ! ∶ !! … !! = ! ∶ !! … !!, !! … !! 3.2.1.6 Concatenate Une activité Concatenate prend en entrée deux instances ! et ! de type tuple. Elle retourne un tuple ayant les attributs de ! et !. • Notation : !⨁! • Type de l’activité : ⨁ ∶ ! ∶ !! , … , !! ×! ∶ !! , … , !! → !_! ∶ !! , … , !!, !! , … , !! Il est nécessaire que !"#$ !! ≠ !"#$ !! pour chaque ! et !. • Sémantique de l’activité : Pour un tuple ! de la forme ! ∶ !! ∶ !! , … , !! ∶ !! et un tuple ! de la forme ! ∶ !! ∶ !! , … , !! ∶ !! , nous avons : !⨁! = !_! ∶ !! ∶ !! , … , !! ∶ !!, !! ∶ !! , … , !! ∶ !! . 3.2.2 Activités)composites Les activités que nous venons de présenter permettent de manipuler les instances de données dans les mashups. La coordination de ces activités définit l’ordre de leur exécution. Elle est définie avec des activités composites qui sont de type fonction. Nous considérons les activités composites suivantes25 : Sequence, Foreach et Parallel. 3.2.2.1 Sequence Une activité Sequence est définie à partir de deux ou plusieurs activités !"#! , !"#! , … !"#! ∈ ! considérées comme des sous-activités de l’activité Sequence. • Notation : ≫ !"#!,!"#!,…!"#! • Type de l’activité : ≫∶ !!× !!× …×!! → !′!× !′!× …×!′ ! • Sémantique de l’activité : o ≫ !"#!,!"#!,…!"#! !! , … , !! = !"#! … !"#! !"#! !! , … , !! o !"#! est de type !!× !!× …×!! → !!.!× …×!!.! o ∀ 2 ≤ ! ≤ !, !"#! est de type ! !!! .!× …×! !!! .! → !!.!× …×!!.! o !"#! est de type ! !!! .!× …×! !!! .! → !′!× !′!× …×!′ ! 24 ! est la liste obtenue par filtrage dans la sous-section 3.2.1.2. 25 Le modèle peut être enrichi avec d’autres activités composites dans le futur selon les besoins qui peuvent apparaître. 45 Représentation graphique La Figure 13 donne la représentation graphique d’une activité Sequence ayant deux sousactivités. Figure'13 :'Représentation'graphique'd'une'activité'Sequence Exemple : Soit le fournisseur de données Google Places qui offre une activité !"#$"%#&'(&)# de type !"#$%&' ∶ !"# ∶ ℕ, !"# ∶ ℕ → !"#$%&!%'$# ∶ !"#$%&!%'$ Nous définissons une activité Sequence !"#$%"#$&'(&)$# = ≫ !"#$"%#&'(&)#,!"#$%&'%(,!"#$%&' . Elle est de type ≫ ∶ !"#_!"#$%&"' ∶ !"# ∶ ℕ, !"# ∶ ℕ → !"#$%&!%'$# ∶ !!"#$%&$'# . L’activité !"#$"%#&'(&)# récupère la liste de restaurants présents près du point géographique défini par le paramètre d’entrée !"#$%&' . Ensuite l’activité !"#$%&'%( (définie dans la sous-section 3.2.1.2) sélectionne les restaurants dont la note est supérieure à 4. Enfin l’activité !"#$%&' (définie dans la sous-section 3.2.1.4) trie la liste des restaurants selon la valeur de la note par ordre croissant. La représentation graphique de cette activité est donnée dans la Figure 14. Figure'14 :'Représentation'graphique'd’un'exemple'd’une'activité'Sequence 3.2.2.2 Foreach Une activité Foreach prend en entrée une instance de type liste. Elle est définie à partir d’une activité !"# ∈ ! considérée comme une sous-activité de l’activité Foreach. • Notation : ∞ !"# • Type de l’activité : ∞ ∶ ! → !′ • Sémantique de l’activité : ∞ !"# ! = !"# ! 1 , !"# ! 2 , … , !"# ! ! tel que !"# est de type ! → !′ L’activité exécute itérativement sa sous-activité sur les éléments de la liste ! retourne dans une liste les résultats des exécutions. L’exécution s’arrête avec la dernière exécution de la sousactivité sur le dernier élément de la liste !. act1% act2% Sequence46 Représentation graphique La Figure 15 présente une représentation graphique d’une activité Foreach et de sa sousactivité. La discontinuité des flèches représente le découpage le l’entrée de Foreach en valeurs et leur transmission à la sous-activité. Figure'15 :'Représentation'graphique'd'une'activité'Foreach Exemple : Soit le fournisseur de données Yahoo! Weather qui offre une activité !"#$"%#ℎ!! de type !"#$% ∶ ℕ → ! , où ! est un type décrivant des données météorologiques d’une certain ville identifiée par son identifiant !"#$%. Nous définissons une activité Foreach !"#"$%&$'#ℎ!" = ∞ !"#$"%#!!" . Elle est de type ∞ ∶ !"#$%& ∶ !"#$% ∶ ℕ → !"#"$%& ∶ ! . Elle retourne les données météorologiques des villes passées en entrée. Elle est représentée graphiquement dans la Figure 16. Figure'16 :'Représentation'graphique'd’un'exemple'd’une'activité'Foreach 3.2.2.3 Parallel Une activité Parallel est définie à partir de deux ou plusieurs activités !"#! , !"#! , … !"#! ∈ ! considérées comme des sous-activités de l’activité Parallel. • Notation : ∥ !"#!,!"#!,…!"#! • Type de l’activité : ∥∶ !!× !!× …×!! → !!.!× … × !!.!×!!.!× …×!!.!× … ×!!.!× … ×!!.! • Sémantique de l’activité : !"#! est de type !!× …×!! → !!.!× …× !!.! où 1 ≤ ! ≤ ! ≤ ! !"#! est de type !!× …×!! → !!.!× …×!!.! où 1 ≤ ! ≤ ! ≤ ! … !"#! est de type !!× …×!! → !!.!× …×!!.! où 1 ≤ ! ≤ ! ≤ ! ∥ !"#!,!"#!,…!"#! !! , … , !! = !"#! !! , … , !! , !"#! !!, … , !! , … , !"#! !! , … , !! Représentation graphique La Figure 17 donne la représentation graphique d’une activité Parallel et de ses sousactivités. act$ Foreach getWeather Foreach47 Figure'17 :'Représentation'graphique'd'une'activité'Parallel 3.2.3 Définition)du)domaine)des)activités)! Le domaine des activités ! ⊂ !"#$%&'#( est construit avec les règles suivantes : • Si ! est une activité proposée par un fournisseur de données, alors ! ∈ !. • Si ! est une activité Extract de type ! ∶ ! → !′ , alors ! ∈ !. • Si ! est une activité Filter, de type ! ∶ ! → ! , alors ! ∈ !. • Si ! est une activité Unique de type ! ∶ ! → ! , alors ! ∈ !. • Si ! est une activité Sort de type ! ∶ ! ×!"#$" → ! , alors ! ∈ !. • Si ! est une activité Append, de type ∪∶ ! × ! → ! , alors ! ∈ !. • Si ! est une activité Concatenate, de type ∶ ! ∶ !! , … , !! ⨁! ∶ !! , … , !! → !_! ∶ !! , … , !!, !! , … , !! , alors ! ∈ !. • Si !! , !! , … , !! ∈ !, alors l’activité Sequence ≫ !!,!!,…,!! ∈ !. • Si ! ∈ !, alors l’activité Foreach ∞ ! ∈ !. C • Si !"#! , !"#! , … !"#! ∈ !, alors l’activité Parallel ∥ !"#!,!"#!,…!"#! ∈ !. Dans ces règles, !, !′,!! , … , !!, !! , … , !! sont des types quelconques qui appartiennent à !. Le domaine ! est extensible : il peut être enrichi dans le futur selon les besoins qui peuvent apparaître. 3.3 Mashlet Un mashlet est une entité réutilisable d’un mashup. Il affiche des données sous la forme d’un widget. Ces données sont produites par une activité. Le type !"#ℎ!"# est définit comme suit : !"#ℎ!"# ∶ !"#$%&'(#)& ∶ !! ,!! , … ,!! , !"#$"#%&$' ∶ !! , !"#$%$#& ∶ ! . Une instance de !"#ℎ!"# définit les types des entrées et des sorties et l’activité qui exécute le traitement de données. Pour chaque instance ! de !"#ℎ!"#, !"#$%$#& est une fonction de type !!× !!× …×!! → !! . !"é!"#$%&' !"#ℎ!"# = !"# ∶ !"#, !"#$"! • !"# est une opération de type !"#ℎ!"# → ! ∶ ∅ . • !"#$"! est une opération de type !"#ℎ!"# → ! ∶ ∅ . act2 act1 Parallel actn … 48 La Figure 18 montre la représentation graphique d’un mashlet avec son activité. L’entrée et la sortie du mashlet sont liées à l’entrée et la sortie de l’activité. Figure'18 :'Représentation'graphique'd'un'mashlet Exemple Soit le fournisseur de données Google maps qui offre une activité !"#$%&#" de type26 !"#$%! ∶ !"#$" ∶ !, !"# ∶ ! → !"#$%& . Dans le mashup ItineraryPlanner, le mashlet !"# reçoit en entrée une donnée contenant une ville de départ et une ville de destination. L’activité sous-jacente est !"#$%&#"' qui récupère l’itinéraire du fournisseur de données Google Maps. !"# = !"#ℎ!"# ∶ !"#$%&'(#)& ∶ !"#$%& ∶ !"#$" ∶ !, !"# ∶ ! , !"#$"#%&$' ∶ !"#$%& , !"#$%$#& ∶ !"#$%&#"' . La représentation graphique de ce mashlet est donnée dans la Figure 19. Figure'19 :'Représentation'graphique'du'mashlet'Map Dans le mashup ItineraryPlanner, le mashlet !"#$ℎ!" reçoit en entrée la liste de localisations des villes de passage sur la route. L’activité sous-jacente est l’activité Foreach !"#"$%&$'#ℎ!" (définie dans la sous-section 3.2.2.2) qui pour chaque ville, récupère les données météorologiques (activité !"#$"%#ℎ!") depuis le fournisseur de donnée Yahoo! Weather. !"#$ℎ!" = !"#ℎ!"# ∶ !"#$%&'(#)& ∶ !"#$%& ∶ !"#$% ∶ ℕ , !"#!"#$%!& ∶ !"#"$%& ∶ ! , !"#$%$#& ∶ !"#"$%&$'#ℎ!" La représentation graphique de ce mashlet est donnée dans la Figure 20. 26 Nous rappelons qu’un type peut être référencé par son nom. Ce qui est le cas de l’utilisation du type !"#$%& ici et dont la définition est donnée à la page 3. Mashlet Ac#vity( input output Map Mashlet getRoutes(49 Figure'20 :'Représentation'graphique'du'mashlet'Weather 3.4 Wiring Un wiring est une entité du mashup qui décrit le flot de données entre deux mashlets. Dans notre modèle, les wirings ne décrivent pas qu’un simple transfert de données entre mashlets : ils peuvent aussi, intégrer une transformation des données pour les délivrer sous le bon format aux mashlets destinataires. Cette transformation définie avec une activité sous-jacente. Un wiring est représenté par un type tuple : !"#"$% ∶ !"#$%&'#( ∶ ! , !"#$"#%&$' ∶ !′ , !"#$"% ∶ !"#ℎ!"# , !"#"$%"! ∶ !"#ℎ!"# , !"#$%$#& ∶ ! . Une instance de !"#"$% définit les types des entrées et des sorties, les mashlets envoyeur (!"#$"%) et receveur (!"#"$%"!) et l’activité qui exécute le traitement de données. Pour chaque instance ! de !"#"$%, nous avons : • L’entrée du wiring est du même type que la sortie de l’instance de !"#ℎ!"# définie dans l’attribut !"#$"% : !"# !. !"#$%&'#( = !"# !"# !. !"#$"% . !"#$"#%&$' • !"#$%$#& est une fonction de type ! → !′ . !"é!"#$%&' !"#"$% = !"# ∶ !"#$ℎ, !"#, !"#$%&'ℎ • !"#$ℎ est une opération de type !"#"$% → ! ∶ ∅ . • !"# est une opération de type !"#"$% → ! ∶ ∅ . • !"#$%&'ℎ est une opération de type !"#"$% → ! ∶ ∅ . Le comportement d’un Wiring est décrit comme suit : il (1) prend les données (!"#$ℎ) en entrée du mashlet envoyeur, (2) les manipule (!!"), en exécutant un processus de transformation de données (défini par l’attribut !"#$%$#& ), pour (3) envoyer le résultat (!"#$%&'ℎ) en sortie au mashlet receveur. La Figure 21 montre la représentation graphique d’un wiring avec son activité. L’entrée et la sortie du wiring sont liées à l’entrée et la sortie de l’activité. getWeather( Weather Mashlet Foreach50 Figure'21 :'Représentation'graphique'd'un'wiring Exemple Dans le mashup ItineraryPlanner, un wiring est nécessaire pour transmettre les villes de passages du mashlet !"# au mashlet !"#$ℎ!". Cependant, dans le mashlet !"#, une ville est décrite comme une paire de longitude et de latitude. D’un autre côté, le mashlet !"#$ℎ!" nécessite qu’une ville soit représentée par un identifiant WOEID. Pour cela le wiring doit procéder à une transformation entre les deux formats. La Figure 22 présente la représentation graphique du wiring !"#2!"#$ℎ!" entre les mashlets !"# et !"#$ℎ!". Soit un fournisseur de données qui offre une activité !"#$%&'( de type !"#$%&' ∶ !"# ∶ ℝ, !"# ∶ ℝ → !"#$% ∶ ℕ . 1. Le wiring prend en entrée la sortie du mashlet !"# : l’itinéraire entre les deux villes de type !"#$%&. L’activité (définie dans l’attribut !"#$%$#&) commence par extraire les villes de passage des étapes de l’itinéraire. Dans la Figure 22, pour des raisons d’espace, nous représentons cette tâche avec une seule activité ExtractRouteCities qui est une activité Sequence. Elle est composée comme suit : a. L’activité !"#$%&#'#!() est une fonction dont la signature est !"#$%& → !"#$!. Le chemin d’accès correspondant est !"#ℎ = !"#$%&. !"#$. !"#$!. Elle retourne la liste des étapes. b. Pour chaque étape de type !"#$. Il faut extraire les coordonnées géographiques du point de départ avec l’activité !"#$%&#'(#) dont la signature est !"#$ → !"#$!_!"#$%&"'. Le chemin d’accès correspondant est !"#ℎ = !"#$. !"#$"_!"#$%&"'. c. Une activité Foreach permet d’extraire les points géographiques de toutes les villes étapes : !"#$%&#'(#(!) = ∞ !"#$%&#'(#) d. Une activité Sequence permet de coordonner les activités : !"#$%&#'()#!*+#+!, = ≫ !"#$%&#'#!(), !"#$%&#'(#(!) 2. Pour chaque paire (longitude, latitude) un service est appelé pour récupérer les différentes descriptions géographiques du lieu (activité !"#$%"&' ). L’identifiant WOEID en est extrait (activité !"#$%&#'()*+ ). Ces activités sont coordonnées avec des activités Sequence et Foreach : !"#$%&'""( = ∞ ≫ !"#$%"&', !"#$%&#'()!" 3. Ensuite, il faut éliminer les doublons27 avec l’activité Unique !"#$!%&'()* décrite dans la soussection 3.2.1.3. 4. Les activités !"#$%&#'()!"#$!$"%, !"#$%& et !"#$!%&'()* sont coordonnées avec une activité Sequence !"#2!"#$ℎ!"#$% = ≫ !"#$%&#'()#!*+#+!,,!"#$%&'""(,!"#$!%&'()* En sortie le wiring !"#2!"#$ℎ!" transmet au mashlet !"#$ℎ!" la liste de localisations des villes décrites sous le format WOEID. Il est modélisé ainsi : !"#2!"#$ℎ!" = !"#"$% ∶ !"#$%&'#( ∶ !"#$%& , !"#$"#%&$' ∶ !"#$%& ∶ !"#$% ∶ ℕ , !"#$"! ∶ !"#, !"#"$%"! ∶ !"#$ℎ!", !"#$%$#& ∶ !"#2!"#$ℎ!"#$% . 27 La présence de doublons est due au fait de la présence de plusieurs étapes de l’itinéraire dans la même ville. Wiring Ac#vity( input output 51 Figure'22 :'Représentation'graphique'du wiring'entre'les'mashlets'Map'et'Weather 3.5 Mashup Un mashup est un ensemble de mashlets et de wirings. Les wirings définissent le flot de données entre les mashlets du mashup. Un mashup définit les types des ses paramètres d’entrées !"#$%&'(#)&, l’ensemble de ses mashlets !"#ℎ!"#$ et de ses wirings !"#"$%&. Il définit également un ensemble de propriétés comme la fréquence d’exécution du mashup, la définition des durées de vie (fixées en nombre d’heures, etc.) des données caractérisées par les noms de leurs types. Il est représenté par un type tuple28 : !"#ℎ!" ∶ 〈!"#$%&'!"#$ ∶ !! ,!! , … ,!! , !"#ℎ!"#$ ∶ !"#ℎ!"# , !"#"$%& ∶ !"#"$% , !"#!$"%&$' ∶ !"#$%#&'( ∶ ℕ, !!"# ∶ !"#"$$%&'( ∶ !"#"$%&'(")' ∶ !,!!" ∶ ℕ 〉 Une instance de !"#ℎ!" définit les types des entrées du mashup, les mashlets et les wirings qui constituent le mashup. !"é!"#$%&' !"#ℎ!" = !"# ∶ !"#$%&'ℎ!"#$%&, !"# !"# et !"#$%&'ℎ!"#$%& sont des opérations de type est !"#ℎ!" → ! ∶ ∅ . Le mashup ItineraryPlanner présenté dans le Chapitre 1 est défini de la façon suivante : !"#$%&'&()*'$$%& = !"#ℎ!" ∶ !"#$%&'(#)& ∶ !"#$" ∶ !, !"# ∶ ! , !"#ℎ!"#$ ∶ !"#, !"#$ℎ!", !"#$%&!%'$# , !"#"$%& ∶ !"#2!"#$ℎ!", !"#2!"#$%&'%($ , !"#!$"%&$' ∶ !"#$%#&'( ∶ 4,!!"# ∶ !"#"$$%&'( ∶ !"#"$%&!"#$! ∶ "!"#$%",!!" ∶ 720 , !"#"$$%&'( ∶ !"#"$%&'(")' ∶ "!"#$ℎ!"",!!" ∶ 6 , !"#"$$%&'( ∶ !"#"$%&'(")' ∶ "!"#$%",!!" ∶ 720 , . Où le mashlet !"#$%&'%($# et le wiring !"#2!"#$!"#!$% sont définis d’une manière similaire que les autres mashlets et wirings définis dans les sections précédentes. Ils sont explicités dans la Figure 23. Celle ci montre la représentation graphique de tous les composants du mashup !"#$%&'&()*'$$%&. Les mashlets !"# et !"#$ℎ!" et le wiring !"#2!"#$ℎ!" furent exposés dans les sections précédentes de ce chapitre. Dans cette figure, nous montrons aussi le mashlet !"#$%&!%'$# qui fournit la liste des restaurants dans la ville de destination. L’attribut !"#$%$#& correspondant est l’activité !"#$%"#$&'(&)$# présentée dans la sous-section 3.2.2.1. Un wiring !"#2!"#$%&'%($ est nécessaire pour transférer la paire (longitude, latitude) de la ville de destination depuis le mashlet !"# vers le mashlet !"#$%&!%'$# (via une activité Extract). 28 Nous rappelons que ! est le domaine des noms de types défini dans la sous-section 3.1.1 Extract Route+ Ci.es+ Foreach Map2Weather Wiring Extract WOEID+ Sequence getWOEID+ Sequence Unique WOEID+52 Figure'23 :'Représentation'graphique'du'mashup'ItineraryPlanner53 3.6 Conclusion Ce chapitre a présenté les concepts de notre modèle de mashup. Nous avons adopté un modèle de données basé sur les valeurs complexes. Des activités basiques décrivent la manipulation des données de mashups (le filtrage, la projection, l’extraction, l’élimination de doublons, le tri, l’union et l’annexe). Elle sont coordonnées par des activités composites (Sequence, Foreach, Parallel). Les activités sont utilisées par des mashlet et des wirings. Les mashlets affichent des données produites par des activités tandis que les wirings coordonnent l’exécution des mashlets. Dans notre modèle, les wirings ne décrivent pas qu’un transfert de données entre mashlets. Ils peuvent aussi, décrire le traitement des données pour les délivrer sous le bon format aux mashlets destinataires. Ces concepts décrivent des entités qui forment des mashups. Chacun de ces concepts était illustré par une représentation graphique qui sert dans la description des activités et de la coordination des mashlets. Les composants du mashup ItineraryPlanner ont été définis selon les concepts du modèle présenté et ils ont été illustrés selon la représentation graphique proposée.55 Chapitre!4 EXECUTION)DE)MASHUPS)AVEC%DISPONIBILITE% DE#DONNEES Ce chapitre présente le processus d’exécution de mashups avec disponibilité de données. L’exécution d’un mashup repose sur la disponibilité de données. Celle ci peut être réduite ou altérée à cause d'une panne au niveau du fournisseur de données ou d’une restriction de nombre de requêtes imposée par ce dernier. Ceci entraîne le dysfonctionnement du mashup. Nous avons constaté dans le Chapitre 2 que les techniques actuelles de disponibilité de données ne sont pas adaptées à des applications comme les mashups. Nous avons constaté, également, que parmi le peu de travaux qui se sont intéressés à la disponibilité des données des mashups, le problème de la fraicheur des données disponibles n’est pas abordé. Pour cela nous proposons un processus pour assurer la disponibilité de données. Ce processus permet également (1) de définir les données dont la disponibilité n’est plus à assurer et (2) d’assurer la fraicheur de données rendues disponibles. Le scénario ItineraryPlanner est utilisé comme exemple pour illustrer le processus d’exécution de mashups. Nous rappelons qu’il affiche l’itinéraire entre deux villes (mashlet !"#), les données météorologiques dans les villes de passage (mashlet !"#$ℎ!") et une liste de restaurants situés dans la ville d’arrivée (mashlet !"#$%&!%'$#). Les wirings !"#2!"#$ℎ!! et !"#2!"#$%&'%($# définissent le flot de données entre les mashlets. Des activités définissent le traitement des données dans les mashlets et les wirings. Le chapitre est organisé comme suit : la section 4.1 présente les principaux éléments de l’exécution d’un mashup. Ensuite, la section 4.2 décrit notre proposition pour assurer la disponibilité de données lors de l’exécution des mashups. Cette solution est à base de fonctions que nous introduisons d’une façon orthogonale au processus d’exécution de mashups. Elles permettent d’améliorer la disponibilité des données de mashups et d’assurer leur fraicheur. Enfin, la section 4.3 conclut ce chapitre.56 4.1 Exécution d’un)mashup Un mashup est vu comme une instance du modèle décrit dans le Chapitre 3. L’exécution d’un mashup (cf. Figure 24) déclenche les exécutions de mashlets et de wirings sous-jacents. Figure'24 :'Diagramme'd’activité UML'de'l’exécution'd’un'mashup57 Ces exécutions partagent leurs données à travers un espace mémoire (privée au mashup). Celui ci est partagé en lecture et en écriture. Ainsi les mashlets, les wirings et les activités d’un mashup partagent leurs données par des lectures et des écritures concurrentes. Le contenu de cet espace est supprimé, une fois l’exécution du mashup achevée. L’ordre des exécutions des mashlets et des wirings est représenté à travers un graphe dirigé qui constitue le plan d’exécution du mashup appelé graphe de mashup. Les nœuds de ce graphe correspondent aux wirings et mashlets du mashup. Un graphe de mashup est un quadruple !, !, !, !"#$" , où : • ! est un ensemble de nœuds mashlets. • ! est un ensemble de nœuds wirings. • ! ⊂ !×! ∪ !×! est un ensemble d’arcs construits ainsi : ∀ ! ∈ !, ∃ !! , !! ∈ ! tel que !! , ! , !, !! ∈ !. • !"#$" ⊆ ! est un ensemble de nœuds de départ. Par exemple, le graphe du mashup ItineraryPlanner est donné dans la Figure 25. Figure'25 :'Graphe'du'mashup'ItineraryPlanner L’exécution du mashup utilise le graphe pour réaliser l’exécution des mashlets et des wirings le composant, par exécution des activités correspondantes (voir sous-sections 4.1.2 et 4.1.3). Le graphe est parcouru de manière classique : un nœud est visité si tous ses prédécesseurs ont déjà été visités. La Figure 26 donne une vision globale de l’exécution du mashup ItineraryPlanner. Les numéros, dans le graphe, indiquent un ordre possible, des exécutions des nœuds, défini lors du parcours du graphe. Chaque exécution d’un nœud (mashlet et wiring) du graphe déclenche l’exécution de l’activité correspondante (cf. sous-sections 4.1.1 à 4.1.3). Les sections suivantes décrivent les processus d’exécution de mashlets et de wirings. Comme ces deux processus exécutent tous les deux des activités, nous commençons par préciser l’exécution de ces activités. 4.1.1 Exécution)d’une)activité Une activité est représentée sous la forme d’un arbre. Les feuilles d’un arbre d’activités correspondent à des activités basiques, alors que les nœuds intermédiaires correspondent à des activités composites (cf. le modèle de mashups Chapitre 3). Un arbre d’activité est définie comme suit : mashlet( Weather wiring map2Restaurants mashlet( Map mashlet( Restaurants wiring map2weather(58 • Soit ! l’ensemble des activités basiques et ℭ celui des activités composites • Un arbre est constitué : o Soit d’une feuille ! ∈ ! o Soit d’une racine ! ∈ ℭ et d’un ou plusieurs arbres disjoints s! , … , s! appelés arbres fils. On le note !, s! , … , s! . Figure'26 :'Exécution'du'mashup'ItineraryPlanner Par exemple, l’arbre de l’activité du wiring !"#2!"#$ℎ!" (cf. section 3.4) est représenté dans la Figure 27. Cette activité extrait (séquence d’activités Extract) les villes de passages sous format (longitude, latitude). Ensuite pour chaque ville (boucle Foreach) un service est appelé (via le nœud Retrieve) pour procéder à la conversion en format WOEID. Ensuite, la valeur entière est extraite (Extract). Enfin les doublons sont éliminés (Unique). Figure'27 :'Arbre'de'l’activité du'wiring'!"#$%&"'(&) Exécution du graphe : parcours des nœuds mashlet( Weather wiring map2Restaurants mashlet( Map mashlet( Restaurants wiring map2weather( 1 2 3 4 5 Map Mashlet getRoutes( getWeather( Weather Mashlet Foreach Sequence' Sequence' Retrieve' Foreach' Unique' Sequence' Extract' Foreach' Extract' Extract'59 L’exécution de l’activité consiste à parcourir l’arbre selon une stratégie en profondeur préfixe [96]. C’est un parcours récursif qui lors de la visite d’un nœud n, continue la visite en parcourant les sous-arbres de gauche à droite. L’exécution d’activités est une phase commune aux processus d’exécutions de mashlets et de wirings. La Figure 28 présente le processus d’exécution du mashup ItineraryPlanner tout en prenant en compte la représentation des arbres d’activités. Figure'28 :'Exécution'du mashup ItineraryPlanner' Chaque nœud possède son propre tampon. Celui ci stocke les adresses des valeurs entrée/sortie de l’activité sous-jacentes. Ces valeurs sont stockées dans l’espace mémoire partagé. Dans la suite de cette sous-section, nous allons décrire le nœud d’une activité basique et à titre d’exemple celui de l’arbre de l’activité composite Sequence. 4.1.1.1 Activité basique Une activité basique est représentée par un nœud feuille (Figure 29) dans un arbre d’activités. Le nœud contient les paramètres de l’activité sous-jacente, par exemple : condition de filtrage, expressions de chemins d’accès. Figure'29 :'Composition'd'un'nœud'd'une'activité'basique L’exécution d’une activité basique (cf. Figure 30) commence par la lecture de la valeur de l’entrée de l’activité. Celle ci est écrite dans la mémoire partagée et son adresse est indiquée dans Exécution du graphe : parcours des nœuds Retrieve' Mashlet Map Foreach' Retrieve Mashlet Weather entrée& sor)e& Tampon Nom de l’activité Paramètres de l’activité 60 le tampon de l’activité. La deuxième phase correspond à l’exécution de l’opération sous-jacente : filtrage extraction, élimination de doublons… Ces opérations sont proposées dans la plupart des langages de d’interrogation de données. Enfin le résultat de l’exécution est écrit dans la mémoire partagée à l’adresse indiqué dans le tampon de l’activité. Figure'30 :'Diagramme'd’activité'UML'du'processus'd’exécution'd'une'activité'basique Cas(des(activités(proposées(par(des(fournisseurs(de(données Nous introduisons le nœud de type Retrieve (cf. le diagramme de communication de la Figure 31) pour lancer l’exécution une activité proposée par un fournisseur de données et indiquée dans les paramètres du nœud. Figure'31 :'Diagramme'de'communication'entre'le'nœud'Retrieve et'le'fournisseur'de'données L’exécution d’un nœud Retrieve envoie les valeurs des paramètres d’entrée (écrites dans le champ « entrée ») d’une activité proposée par un fournisseur de données et demande son exécution. Le résultat reçu est stocké dans l’espace mémoire partagé. L’adresse de ce résultat est indiquée dans le champ « sortie » du tampon du nœud. 4.1.1.2 Activité)Sequence Pour une activité Sequence ≫ !"#!,!"#!,…!"#! , l’arbre de nœuds correspondant est présenté dans la Figure 32, où « Nœud 1 », « Nœud 2 », … et « Nœud n » sont les nœuds représentant les arbres correspondants aux sous-activités !"#! , !"#! , …, et !"#!. Les nœuds échangent les adresses des données stockées dans la mémoire partagée. Retrieve 1 : Valeurs des Paramètres d’entrée 2 : Résultat61 Figure'32 :'Arbre'de'nœuds'd’une'activité'Sequence L’exécution d’une activité Sequence (cf. Figure 33) déclenche l’exécution de ses sousactivités d’une façon séquentielle. Pour chaque sous-activité, elle (1) commence par écrire l’adresse de l’entrée dans le tampon. Pour la première sous-activité, l’entrée correspond à celle de l’activité Sequence alors que pour chacune des autres sous-activités, elle correspond à la sortie de la sousactivité précédente. Ensuite elle (2) déclenche l’exécution de la sous-activité. Enfin (3), elle récupère l’adresse de la sortie pour l’écrire dans le champ « entrée » du tampon de la sous-activité suivante. La valeur du champ « sortie » du tampon de la dernière sous-activité est écrite dans le champ « sortie » du tampon du nœud parent. Figure'33 :'diagramme'd’activité UML du'processus'd’exécution'd'une'activité'Sequence Valeur'de'l’input' de'Sequence Valeur'de'l’output' du'nœud'1'(input' du'nœud'2)' Valeur'de'l’output' du'nœud(n71)' (input'du'nœud'n)' Valeur'de'l’output' de'Sequence Valeur'de'l’output' du'nœud'2'(input' du'nœud'3)' Mémoire partagée Nœud 1 Input' Output' Nœud n Sequence Input' Output' Input' Output' Nœud 2 Input' Output' … 62 4.1.2 Exécution)d’un)mashlet La Figure 34 présente les phases du processus d’exécution d’un mashlet et montre qu’il déclenche principalement l’exécution de l’activité sous-jacente et la génération d’une visualisation définissant l’affichage graphique de la sortie du mashlet. Chaque mashlet possède son propre tampon. Celui ci stocke les adresses des valeurs de ses entrée/sortie. Ces valeurs sont stockées dans l’espace mémoire du processus exécutant le mashup. Les valeurs des entrées de certains mashlets sont connues dès le début de l’exécution du mashup comme les villes de départ et d’arrivée dans le mashlet !"# du le mashup ItineraryPlanner. Les adresses de ces valeurs sont écrites dans le tampon du mashlet avant le parcours du graphe. C’est le processus exécutant le mashup qui s’occupe de cette tâche. Les valeurs des entrées d’autres mashlets sont connues au cours de l’exécution du mashup (parcours du graphe) et transférées par des wirings (voir sous-section 4.1.3) : par exemple, la liste de villes de passages comme entrée du mashlet !"#$ℎ!" obtenue via le wiring !"#2!"#$ℎ!". Les premières phases du processus d’exécution d’un mashlet correspondent au transfert de l’adresse de l’entrée du mashlet à son activité sous-jacente ainsi qu’à l’exécution de cette activité d’activités (cf. sous-section 4.1.1). Ensuite, l’adresse de la sortie de l’activité est écrite dans le tampon du mashlet. Cette adresse peut être lue par des wirings afin qu’ils accèdent à la donnée, la manipuler, et la transférer à d’autres mashlets : par exemple les données de l’itinéraire du mashlet !"# sont manipulées par le wiring !"#2!"#$ℎ!" afin de transférer la liste de villes de passage au mashlet !"#$ℎ!". Enfin, la dernière phase consiste en la génération d’une visualisation graphique de ces données. Cette visualisation est affichée sur le terminal de l’utilisateur sous la forme d’un widget. Figure'34 :'Diagramme'd’activité UML'de'l’exécution'd’un'mashlet 4.1.3 Exécution)d’un)wiring Le processus d’exécution d’un wiring est constitué de trois phases (cf. Figure 35). La première phase consiste en la récupération de l’adresse de la valeur de la sortie du mashlet envoyeur : par exemple le wiring !"#2!"#$ℎ!" récupère l’adresse des les données de l’itinéraire 63 depuis le tampon du mashlet !"#. La deuxième phase correspond à l’exécution de l’activité correspondante. Enfin, lors de la phase de Livraison, les données produites à la fin de la phase précédente sont livrées au mashlet receveur (écriture de l’adresse dans le tampon du mashlet) : par exemple le wiring !"#2!"#$ℎ!" écrit l’adresse de la liste de villes de passage dans le tampon du mashlet !"#$ℎ!". Figure'35 :'Diagramme'd’activité'UML'de'l’exécution'd’un'wiring 4.2 Disponibilité)des)données)dans)les)mashups Nous proposons une approche pour assurer la disponibilité de données récupérées auprès des fournisseurs de données. Ces données sont stockées dans une structure que nous nommons !"#$%. Nous introduisons dans l’arbre d’activités une nouvelle famille de nœuds : Retrieve++. A la différence d’un nœud Retrieve, un nœud Retrieve++ vérifie la présence des données recherchées dans le !"#$% avant de lancer l’exécution de l’activité sous-jacente proposée par un fournisseur de données. Le processus proposé permet de rendre, disponibles, les données récupérées. Ce processus est illustré dans la Figure 36. Figure'36':'Diagramme'de'communication UML entre'le'nœud'Retrieve++,'le'fournisseur'de'données'et' le !"#$% La Figure 37 qui donne une vision globale de la phase d’exécution du mashup ItineraryPlanner avec intégration du processus de disponibilité de donnée. 64 Figure'37 :'Exécution'd’un'mashup'avec'disponibilité'de'données Dans cette section, nous présentons un diagramme d’activité décrivant le processus d’exécution d’un nœud Retrieve++. Ce diagramme est présenté dans plusieurs figures (Figure 39, Figure 40 et Figure 42). Il est dans un premier temps minimaliste. Ensuite, il sera enrichi tout au long de cette section lors de la présentation des fonctionnalités du processus de disponibilité de données. Il s’intègre au diagramme de la Figure 24, en faisant partie du processus de l’exécution des activités. Lorsque le !"#$% devient saturé (capacité maximale atteinte), une partie des données est supprimée pour libérer de l’espace et pouvoir stocker des nouvelles données. Les données des mashups sont dynamiques et ont une durée de vie limitée. Pour cela ces données doivent être rafraichies en anticipant les nouvelles demandes de récupération lors d’une exécution ultérieure d’un mashup. Ainsi, notre processus de disponibilité est basé sur des fonctions de gestion, de remplacement et de rafraichissement de données du !"#$% (sous-sections 4.2.2, 4.2.3 et 4.2.4). Celui ci est administré par un administrateur qui doit faire certains choix au niveau des fonctions du !"#$%. Ces choix seront explicités au cours des sous-sections qui suivent. Ces fonctions sont orthogonales par rapport au processus d’exécution de mashups réalisé par un moteur de mashups. La section 4.2.5 récapitule le processus d’exécution d’un nœud Retrieve++ avec exploitation du !"#$% et des fonctions associées. Comme ces fonctions opèrent sur des données rendues disponibles, nous commençons par préciser l’organisation de ces données.65 4.2.1 Organisation)de)données du)!"#$% Les données sont organisées, au sein du !"#$%, sous la forme d’items. Un item est un tuple qui possède les attributs « id » et « object ». Il est identifié avec la valeur de son attribut « id ». Dans le contexte des mashups, l’attribut « id » correspond à une activité et les valeurs de ses paramètres d’entrée (sous la forme d’une liste de valeurs) alors que l’attribut « objet » correspond à la valeur du paramètre de sortie produite par l’exécution de l’activité. Un item maintient, de plus, d’autres informations nécessaires pour assurer les fonctions comme le remplacement et le rafraichissement des données. Il est représenté par un tuple : !"#$ ∶ 〈!" ∶ 〈!"#$%$#& ∶ !, !"#$%& ∶ [!"#$% ∶ !"#"]〉, !"#$%& ∶ !"#",!!" ∶ ℕ, !""#$$%& ∶ ℕ, !"#$ℎ!"#$ ∶ !"#$, !"#$%!&' ∶ !"#$, !"#$%&&'## ∶ !"#$, !"#$%&' ∶ ℕ〉. où : • !"#$29 est une définition de type définie comme suit : !"#$%& ∶ 1,2, … 60 , ℎ!"# ∶ 1,2, … 24 , !"#$ℎ ∶ 1,2, … 12 , !"# ∶ 1,2, … 31 , !"#$ ∶ ℕ . • accessNb de type entier, il indique le nombre d’accès à item. • ttl de type entier, il indique la durée de vie de l’item (en nombre d’heures). • birthDate indique la date de création de l’item. • expireOn indique la date d’expiration de l’item. • lastAccess indique la date du dernier accès à l’item. • latency indique le temps mis pour récupérée les données depuis le fournisseur. !"#$%&'()* !"#$ = !"# ∶ !"#!"$ℎ, !"#$%!&'(, !"#$%&''( où : • Pour une instance ! de type !"#$, l’opération !"#!"$ℎ exécute l’opération !. !". !"#$%$#& avec les valeurs des paramètres indiquées par !. !". !"#$%&. Elle écrit le résultat de l’opération dans !. !"#$%&. Ensuite elle retourne un booléen indiquant le bon déroulement de l’opération. o Type de !"#!"$ℎ : !"#$ → ! o Sémantique : l’appel de !. !"#!"$ℎ() exécute l’instruction suivante30 : !. !"#$%& = !"!"#$ !. !". !"#$%$#&, !. !". !"#$%& • Pour une instance ! de type !"#$, l’opération !"#$%!&'( vérifie si la donnée enregistrée dans ! est encore fraiche. o Type de !"#$%!&'( : !"#$ → ! o Sémantique : l’appel de !. !"#$%!&'(() retourne !. !"#$%!&' < !"#() • Pour une instance ! de type !"#$ , l’opération !"#$%&''( permet de modifier la valeur de l’attribut « ttl » de ! et de lui affecter une valeur passée en entrée. La fonction retourne un booléen indiquant le bon déroulement du processus d’ajustement. o Type de !"#$%&''(: !"#$×!"#$$% ∶ ℕ → ! o Sémantique : l’appel de !. !"#$%&''( !!"#$" exécute l’instruction suivante : !.!!" = !!"#$". où !!"#$! est une instance du type du paramètre d’entrée d’!"#$%&''(. La durée de vie d’un item peut être modifiée au cours du temps. Ce point sera expliqué dans la sous-section 4.2.4.2 lors de la description du processus de rafraichissement des items. 29 Nous considérons la fonction !"#() qui retourne une instance de !"#$ correspondante à l’instant courant. 30 Nous rappelons que !"#$%& est une opération définie sur tous les types fonction pour réaliser l’exécution de leurs instances (cf. sous-section 3.1.4) 66 Exemple Nous considérons !"#$%&'($%) une instance de !"#$ . Elle correspond à la donnée !"#$%&' (cf. sous-section 3.1.2) et récupérée avec l’activité !"#$%&#"' définie dans la section 3.3. Elle est définie comme suit : !"#$%&'($%) = !"#$ ∶ 〈!" ∶ !"#$%$#& ∶ !"#$%&#"', !"#$%& ∶ !"#$% ∶ Grenoble, !"#$% ∶ Paris , !"#$%& ∶ !"#$%&', !!" ∶ 720, !""#$$%& ∶ 8, !"#$ℎ!"#$ ∶ !"#$%& ∶ 05, ℎ!"# ∶ 15 !"#$ℎ ∶ 11, !"# ∶ 1, !"#$ ∶ 2012 , !"#$%!&' ∶ !"#$%& ∶ 05, ℎ!"# ∶ 15 !"#$ℎ ∶ 12, !"# ∶ 1, !"#$ ∶ 2012 , !"#$%&&'## ∶ !"#$%& ∶ 30, ℎ!"# ∶ 7 !"#$ℎ ∶ 11, !"# ∶ 10, !"#$ ∶ 2012 , !"#$%&' ∶ 1000〉 La Figure 38 montre la représentation graphique de !"#$% contenant des items pour différents mashups. Le premier ItineraryPlanner et d’autres mashups à la iGoogle contenant des mashlets dont certains affichent la météo de la ville de résidence des utilisateurs. Les différents mashlets météo partagent leurs items. Figure'38 :'Représentation'du'!"#$% 4.2.2 Gestion)du)!"#$% La gestion du !"#$% se fait par des fonctions qui permettent d’ajouter, de supprimer et de rechercher des items. Elles sont définies comme suit : 4.2.2.1 Ajout)d’un)item Nous définissons la fonction !"#$. Elle crée une instance d’!"#$ dont les valeurs des attributs « id » « objet » et « ttl » sont passées en paramètre. La valeur de l’attribut « accessNb » est initialisée à 1. Les valeurs des attributs « birthDate » est « lastAccess » sont initialisées à la date courante. Et la valeur de l’attribut « expireOn » est calculée à partir de la date courante et la valeur de l’attribut « ttl ». Ensuite l’instance créée est ajoutée au !"#$%. La fonction retourne un booléen indiquant le bon/mauvais déroulement du processus. • Type de !"#$ : !" ∶ 〈!"#$%$#& ∶ !, !"#$%& ∶ [!"#$% ∶ !"#"] 〉, !"#$%& ∶ !"#",!!" ∶ ℕ → ! • Sémantique : Pour !"#$ !"#$%, !"#$%&,!!"#$" : o !"#$%"& = !"#$ ∶ !" ∶ !"#$%, !"#$%& ∶ !"#$%&,!!" ∶ !!"#$", !""#$$%& ∶ 1, !"#$ℎ!"#$ ∶ !"#(), !"#$%!&' ∶ !"#() + !!"#$", !"#$%&&'## ∶ !"#() Grenoble( Lyon( Road2( Paris( Weather1( Lyon( Weather2( Grenoble Weather3( entry( item( item( item( item( item( item( entry( item( Grenoble( Paris( Road1(67 o !"#$% = !"#$% + !!"#$!% o !"#$%, !"#$%&,!!"#$" sont respectivement des instances de type des paramètres d’entrée de !"#$ : !", !"#$%&,!!". 4.2.2.2 Suppression)d’un)item Nous définissons la fonction !"#$"%. Elle prend en entrée la valeur de l’attribut « id » d’une instance ! d’!"#$ présente dans !"#$%. La fonction permet de supprimer ! du !"#$%. Elle retourne un booléen indiquant le bon déroulement du processus de suppression. • Type de !"#$"% : !" ∶ !"#$%$#& ∶ !, !"#$%& ∶ !"#$% ∶ !"#" → ! • Sémantique : Pour !"#$"% !"#$% où !"#$% est une instance du type du paramètre d’entrée de !"#$"% : !". !"#$% = !"#$% − ! !. !" = !"#$% 4.2.2.3 Recherche)d’un)item Nous définissons la fonction !""#$%. Elle prend en entrée une valeur possible !"#$% de l’attribut « id » du type !"#$. La fonction vérifie si une instance ! d’!"#$ (avec !. !" = !"#$%) est présente dans !"#$% et dans ce cas elle la retourne en sortie. • Type de !""#$%: !" ∶ !"#$%$#& ∶ !, !"#$%& ∶ !"#$% ∶ !"#" → !"#$ • Sémantique : !""#$% !"#$% = ! ! ∈ !"#$% !" !. !" = !"#$% La Figure 39 présente l’utilisation des fonctions !""#$% et !"#$ dans le processus d’exécution d’un nœud Retrieve++ afin de (1) rechercher des données au sein du !"#$% avant de les récupérer auprès du fournisseur de données et (2) d’ajouter les données récupérées dans le !"#$% pour une utilisation ultérieure. Rappelons que le diagramme présenté dans la figure est une version minimaliste du processus d’exécution du nœud Retrieve++ et qu’elle sera enrichie toute au long de la section 4.2. Figure'39 :'Utilisation'des'fonctionnalités'de'gestion'du'!"#$% dans'l’exécution'd’un'nœud'Retrieve++68 4.2.3 Remplacement)de)données Le remplacement des items dans le !"#$% se fait selon une politique de remplacement. Celle-ci détermine les items devant être supprimés du !"#$% pour libérer de la place pour pouvoir stocker des nouveaux items. Elle vise à maximiser les avantages de l’utilisation du !"#$%. Nous définissons la fonction !"#$%&&!. Elle libère du !"#$% un espace dont la taille est égale ou supérieure à une valeur donnée !"#$%ℎ. Elle retourne une valeur booléenne indiquant si l’opération s’est bien exécutée ou pas. • Type de la fonction : !"#$%ℎ ∶ ℕ → ! . • Sémantique de la fonction : • Pour !"#$%&&! ! avec ! ∈ ℕ : o Taille des données dans le !"#$% avant l’exécution = ! o Taille des données dans le !"#$% après l’exécution = ! − ! La Figure 40 présente l’utilisation de la fonction !"#$%&&! dans le processus d’exécution d’un nœud Retrieve++ afin de libérer de l’espace lorsque le !"#$% devient saturé. Figure'40':'Utilisation'de'la'fonction'!"#$%&&! dans'l’exécution'd’un'nœud'Retrieve++ Le remplacement se fait selon plusieurs facteurs (sous-section 4.2.3.1) qui sont pondérés dans une formule de poids d’item (sous-section 4.2.3.2). 69 4.2.3.1 Facteurs)de)la)politique)de)remplacement La plupart des politiques de remplacement existantes (comme FIFO, LIFO, LRU (Last Recently Used), MRU (Most Recenty Used) …) sont basées sur le moment d’ajout et d’accès à une données. D’autres politiques sont basées sur des facteurs comme : • La taille des données : en effet, il est plus intéressant de supprimer des items de grande taille pour laisser la place à plusieurs items de petite taille. • La latence du fournisseur des données : en effet, il est plus intéressant de garder les items dont la récupération est plus lente. Ces facteurs sont présents en tant qu’attributs dans la définition du type !"#$. Les valeurs de certains sont déterminées lors de la création de l’item (voir la fonction !"#$ dans la sous-section 4.2.2.1) alors que les valeurs d’autres attributs évoluent avec le temps comme le nombre d’accès et la date du dernier accès à l’item. Dans le contexte des mashups les données sont dynamiques, elles ont une durée de validité déterminée dont il faut tenir compte. Les facteurs à prendre en compte sont • La durée de vie restante pour un item. En effet, il est plus intéressant de garder un item i1 dont la durée de vie restante est supérieure à celle d’un item i2. Pour un item i du !"#$% ce facteur est calculé avec la formule : !. !"#$%!&' − !"#() • Le nombre d’accès à un item i en prenant en compte son âge (calculé avec la formule !"#() − !. !"#$ℎ!"#$). En effet, il est plus intéressant de maintenir dans le !"#$% un item i1 pour lequel il y a eu 10 accès en une heure qu’un item i2 pour laquelle il y a eu 20 accès en 24 heures. Ce facteur est calculé avec la formule : !.!""#$$%& !"#()!!.!"#$!!"#$ 4.2.3.2 Le)poids)d’un)item La politique de remplacement associe un poids à chaque item présent dans le !"#$%. Le poids d’un item définit la probabilité que cet item soit accédé dans le futur. Les items dont les poids sont les moins élevés, sont retenus pour être évincés lors du processus de remplacement. L’expression du poids est définie par une formule algébrique ayant comme variables des facteurs de remplacement de données. Une politique de remplacement choisie peut être adaptative : la formule correspondante contient des paramètres (coefficients ou exposants) de poids pour favoriser des facteurs par rapport à d’autres. Ces paramètres sont modifiables par l’administrateur du !"#$%. Une politique de remplacement adaptative peut donc être définie par la formule suivante : !"!"# = !. !" + !. !" ! + ! !"# + ! !"# Où : • LT : durée de vie restante avant expiration. • A : âge de l’item. • AN : nombre d’accès à l’item. • Lat : latence de la récupération de la donnée. • Len : taille de l’item. • !, !, ! et ! sont des coefficients attachés aux facteurs de la politique remplacement de données pour définir leurs poids. 70 Le type de fonctions de poids est !"#$%#!&ℎ! ∶ !"#$ → !"#$ℎ! ∶ ℝ . Une fonction de ce type permet de définir le poids (selon une formule déterminée) d’une instance de !"#$ donnée en entrée. Lors de l’éviction des données (par appel de la fonction !"#$%&&!), les instances, dont les poids sont les moins élevés, seront supprimées. Cette fonction peut être modifiée au cours du temps. Ceci donne à la fonction de remplacement une caractéristique d’adaptabilité. 4.2.4 Rafraichissement)de)données Intuitivement, lorsqu’un item du !"#$% expire, il doit émettre une notification pour demander sa mise à jour. Ce processus nécessite d’associer à chaque item un mécanisme (thread) pour surveiller sa date d’expiration. Or le !"#$% est amené à stocker, au minimum, des milliers d’items. Techniquement, ceci revient à lancer autant de threads. Nous considérons que cette solution n’est pas optimale (gourmande en ressources) et donc nous l’écartons. Nous proposons un processus de rafraichissement où les items doivent être parcourus périodiquement, pour mettre à jour ceux qui sont périmés. Pour éviter de parcourir tous les items, nous proposons de stocker des références aux items du !"#$% dans une structure de données ordonnée : !"#$%&#'% (cf. Figure 4131 et la sous-section 4.2.4.3). Figure'41 :'Rafraichissement'des'items Les éléments de !"#$%&#'% sont des instances de type !"#$%#&. Chacune de ces instances contient une référence à un item du !"#$% et sa date d’expiration. L’ordre de ces instances dans !"#$%&#'% est défini selon la date d’expiration. Le type !"#$%#& est défini comme suit : !"#$%#& ∶ !"# ∶ !, !"#$%&'()! ∶ !"#$ où ! est l’ensemble des références des instances de type !"#$. !"#$%&'()* !"#$%#& = !"#$#"% où l’opération !"#$#"% est de type !"#$ ∶ !!"#$"% → !"#$"# ∶ !"#$ . Pour une instance ! de !"#$%#& , !. !"#$#"% retourne l’item référencé par la référence !. !". La fréquence de rafraichissement ainsi que la gestion des durées de vie des items seront étudiées dans les sous-sections 4.2.4.1 et 4.2.4.2. Ensuite, le choix de la structure de données de 31 La représentation graphique linéaire de !"#$%&#'% est indépendante de la structure de données choisie. ItemsRefs ir1 ir2 ir3 ir4 ir5 … d1 < d2 < d3 < d4 < … ! !" !" !"#$% !"#$%& !" !"#$%"# !""è! < ! !!" 10 !"#$# Où ! et ! sont des seuils définis par l’administrateur du !"#$%. (b) Item valide Si l’item est jugé encore valide, ceci constitue une justification pour considérer que la valeur de TTL est sous-estimée et qu’il faut l’augmenter. L’incrément est calculé par une fonction !"# en fonction de la valeur actuelle de TTL et des données statistiques comme le nombre d’accès à l’item, la date du dernier accès. !"# est de type !"#$$" ∶ ℕ, !" ∶ ℕ, !" ∶ !"#$ → !"#$%&%"' ∶ ℕ . Plus (1) le nombre d’accès est grand (plus grand qu’un seuil donné), ou (2) plus le temps écoulé depuis la dernière date d’accès est petit (plus petit qu’une durée donnée) alors plus l’incrément doit être petit. Et inversement, plus le nombre d’accès est petit et le temps écoulé depuis la dernière date d’accès est grand, plus l’incrément doit être grand. Ce choix est justifié par le souci de maintenir le plus possible la fraicheur (ajout d’un petit incrément) des données qui sont fréquemment ou récemment demandées. La valeur de TTL peut être incrémentée jusqu’à une valeur maximale !!"# . Ce seuil constitue une limite supérieure des valeurs TTL des items pour éviter le risque de la présence des données périmées dans le !"#$% pour longtemps. Ainsi la valeur de TTL est définie selon la formule suivante : 73 !!" = !"# !!"#, !!" + !"# !!", !", !" Où : • !!" est la valeur actuelle de la durée de vie de l’item. • !" est le nombre d’accès à l’item. • !" est la date du dernier accès à l’item. Par exemple, un incrément peut être défini selon la formule suivante : !"# !!", !", !" = !!" 10 !" !" > ! !" !" !"#!" !"#$%& !" !"#$%"# !""è! < ! !!" 2 !"#$# Où ! et ! sont des seuils définis par l’administrateur du !"#$%. 4.2.4.3 Choix)de)la)structure)de)données de)!"#$%&#'% Le choix de la structure de !"#$%&#'% peut se faire entre différentes structures comme un tableau ordonné, une liste chainée ordonnée, un arbre binaire ou un arbre rouge-noire. Pour des détails à propos de ces structures, le lecteur est invité à consulter la référence [96]. Pour toutes ces structures, La recherche d’un objet (instance de !"#$%#&) à partir de la valeur de l’attribut !"# nécessite le parcours séquentiel du tableau (Complexité ! (!)). Ceci est dû au fait que les objets sont triés par rapport à la date d’expiration de l’item référencé et non pas par rapport à la référence de l’item. Dans un tableau ordonné, les objets sont accédés par leurs indices. Les coûts de l’insertion et la suppression d’un objet sont linéaires par rapport à la taille du tableau. Dans une liste chainée, les objets sont arrangés linéairement. Les coûts de l’insertion et la suppression d’un objet sont linéaires par rapport à la taille de la liste. Dans un arbre binaire de recherche les coûts de l’insertion et de la suppression dépendent de la profondeur de l’arbre. Chacun est de l’ordre ! (ℎ) sur un arbre de profondeur maximale ℎ. Les coûts peuvent aller de ! (lg ! ) dans les cas les plus favorables (arbres binaires complets) jusqu’à ! (!) dans les cas les plus défavorable (arbre constituée d’une chaine linéaire de n nœuds). Un arbre rouge-noir est un type particulier d’arbre binaire de recherche. Chaque nœud est coloré (rouge ou noire) selon les règles suivantes : • La racine et les feuilles sont noires. • Si un nœud est rouge alors ses deux nœuds fils sont noirs. • Pour tout nœud, les chemins reliant ce nœud à des feuilles contiennent le même nombre de nœuds noirs. La coloration garantie qu’aucun des chemins allant de la racine aux feuilles n’est plus de deux fois plus long que n’importe quel autre, ce qui rend l’arbre approximativement équilibré. Les coûts de l’insertion et la suppression d’un objet sont de l’ordre logarithmique (Complexité ! (lg ! )). Le Tableau 5 dresse la complexité des opérations d’insertion, de suppression et de recherche dans différentes structures. Nous constatons que l’arbre rouge-noir offre de meilleures performances en ce qui concerne l’insertion et la suppression de nouveaux objets.74 Insertion/suppression Recherche Tableau !(!) !(!) Liste chainée !(!) !(!) Arbre binaire !(ℎ) !(!) Arbre rouge-noir !(lg (!)) !(!) Tableau'5':'Coût'des'opérations'dans'différentes'structures'de'données32 Cette comparaison nous permet de choisir l’arbre rouge-noir comme structure de données pour stocker les références des items du !"#$%. Nous définissons le type arbre rouge noir comme suit : • Si ! est un type alors ! ∶ ! ∈ ! est un type arbre rouge noir nommé !. Ses nœuds sont des instances du type !. • Pour un type arbre rouge noir ! ∶ ! , ! ∶ ! = ! ∶ ! ! ∈ ! ∪ ! × ! ∶ ! × ! ∶ ! . !"#$%&'()*(! ∶ ⌊!⌋) = {!"#$%&, !"#"$", !""#$%, !"#$%&", !"#$"%#&ℎ!"#, !"#$%!ℎ!"ℎ!"#} 4.2.5 Exécution d’un)nœud)Retrieve++)) L’interaction entre le mashup et le !"#$% se déroule lors de l’exécution des nœuds Retrieve++. Elle se fait en exploitant les fonctions associées au !"#$%. Elle est illustrée dans le diagramme d’activité de la notation UML dans la Figure 42. L’interaction se déroule comme suit : • Vérifier (avec la fonction !""#$%) si un item du !"#$% contient la donnée recherchée. o Si l’item existe : " S’il est périmé, il est rafraichi et sa durée de vie est ajustée selon la stratégie TTL incrémental décrite dans la sous-section 4.2.4.2 " Dans tous les cas, la donnée qu’il contient est prise comme résultat de l’exécution du nœud Retrieve++. o Sinon : " La donnée est récupérée directement auprès du fournisseur. Et elle est prise comme résultat de l’exécution du nœud Retrieve++. " Si le Store est plein, des items sont supprimés avec la fonction !"#$%&&! . La suppression se fait selon une formule de remplacement comme celle définie dans la sous-section 4.2.3.2. " Un nouvel item, contenant la donnée récupérée, est crée et ajouté au !"#$% avec la fonction !"#$. Nous rappelons que, parallèlement à ce processus, le !"#$% est parcouru périodiquement pour rafraichir les items périmés d’une façon proactive sans attendre l’arrivé d’une nouvelle 32 n fait référence au nombre des éléments dans la structure tandis que h fait référence à la hauteur de l’arbre (profondeur maximale d’une branche)75 demande d’accès aux items. Ce processus prend en compte des formules de rafraichissement comme celles définies dans la sous-section 4.2.4. Figure'42 :'Exécution'd'un'nœud'Retrieve++ 4.3 Conclusion Dans ce chapitre, nous avons présenté les phases du processus d’exécution d’un mashup. et notre solution pour améliorer la disponibilité de données fraiches des mashups. Celle ci est à base de fonctions orthogonales au processus d’exécution des mashups. Dans une première section, nous avons décrit la représentation d’un mashup sous la forme d’un graphe dont le parcours permet de coordonner l’exécution des mashlets et des wirings du mashup. Nous avons décrit les phases des processus d’exécution des mashlets et des wirings et de leurs activités sous-jacentes.76 Dans une deuxième section, Nous avons présenté des fonctions permettant d’améliorer la disponibilité des données récupérées auprès des fournisseurs de données. Ces données sont rendues disponibles dans un !"#$%. Pour cela, nous avons décrit l’organisation du contenu du !"#$% en un ensemble d’items. Nous avons ensuite décrit la gestion de ce contenu et les fonctions qui y sont relatives : ajouter, modifier, supprimer et rechercher des items. Ensuite, nous avons décrit les fonctions de remplacement et de rafraichissement des items. Pour le remplacement des items, nous avons dressé une liste de facteurs entrant en jeu lors de la définition de la politique de remplacement dans le contexte des mashups. Le rafraichissement des items est exécuté d’une façon incrémentale. Nous avons adopté une stratégie adaptative pour la définition des durées de vie des items ainsi nous avons adapté la stratégie TTL incrémental au contexte des mashups. Enfin nous avons illustré, avec des diagrammes d’activité de la notation UML, le processus d’exécution d’un nœud Retrieve++ avec l’exploitation du Store et des fonctions associées.77 Chapitre!5 IMPLANTATION)DE)MELQART L’implantation de MELQART consiste en la séparation et l’abstraction des concepts des mashups ainsi que des gestionnaires de cache implantant les fonctionnalités proposées pour améliorer la disponibilité des données des mashups. Ceux ci sont définis avec des classes abstraites avec des signatures d’opérations (Figure 43). Cette abstraction permet de représenter l’interdépendance entre les composants en terme d’opérations fournies et utilisées par les classes. Ainsi la modification de l’implantation d’une opération n’affecte pas les classes qui l’utilisent. Les concepts des mashups sont définis par des classes abstraites et concrètes par les programmeurs de MELQART. Lors de la définition de mashups, les classes abstraites sont spécialisées par des classes concrètes. Des instances de ces classes permettent d’obtenir des mashups. Nous avons utilisé le canevas de cache ACS [62]. Il est à base de gestionnaires ; chaque gestionnaire est un composant réalisant une fonctionnalité spécifique (gestion de données, remplacement de données etc.). Dans MELQART, nous avons adapté ces gestionnaires au contexte des mashups et nous avons introduit un gestionnaire de rafraichissement. Les gestionnaires de remplacement et de rafraichissement MELQART sont spécifiés par des classes abstraites. Leurs comportements sont spécialisés par des classes concrètes. Par exemple définir des gestionnaires de remplacement, chacun ayant sa propre politique de remplacement. Des instances de ces classes permettent de faire fonctionner un cache pour stocker les données des instances de mashups. Elles sont manipulées par des administrateurs de MELQART qui peuvent contrôler le cache : augmenter sa taille, le vider, ou changer de politique de remplacement. Le chapitre est organisé comme suit : l’architecture du système est présentée dans la section 5.1. L’implantation des concepts de notre modèle de mashups et l’adaptation des gestionnaires d’ACS sont présentées dans les sections 5.2 à 5.11. L’implantation est décrite avec les diagrammes de classes et de séquence de la notation UML. Dans la section 5.12, nous avons validé notre implantation avec l’exécution de plusieurs instances de deux scenarios de mashups. Enfin, la section 5.13 conclut ce chapitre.78 Figure'43 :'Approche'de'MELQART'pour'la'création'et'l’exécution'des'mashups 5.1 Architecture)du)système L’interaction avec le système MELQART se fait selon une architecture client-serveur (cf. Figure 44). Les mashups sont exécutés côté serveur et les résultats sont affichés sur les machines des utilisateurs (clients). Ainsi, deux utilisateurs peuvent demander l’exécution d’un même mashup. Figure'44 :'Interaction'des'utilisateurs'avec'MELQART La Figure 45 présente les composants de MELQART : MashupEngine, Mashup, Mashlet, Wiring, Activity, Store, ReplacementManager et FreshnessManager. Il interagit avec des composants externes qui représentent les fournisseurs de données : Services. Un fournisseur de donnée (Service) est un composant autonome que l’on peut interroger (Invoke) par le biais des activités qu’il propose. L’exécution d’un mashup est accomplie par le spécialiser Instancier Concepts de MELQART Définitions de mashups et des gestionnaires du cache Exécution des instances des mashups et du cache Classes abstraites/concrètes Classes concrètes Objets Ac#vity( Mashup( Wiring I#neraryPlanner Classe abstraite Classe concrète Objet Mashlet( Légendes : Data( Ac#vity( Ac#vity( Item( Replacement( Manager( Freshness Manager( Store(79 composant MashupEngine. Celui ci exécute les composants Mashup, Mashlet, Wiring! et Activity33. Il contient un buffer qui offre les outils pour le stockage temporaire de données en cours de traitement. Il interagit avec les composants Services afin de les interroger et récupérer des données. Il interagit également avec le composant Store qui stocke des résultats des activités de fournisseurs de données. Dans notre implantation, les fonctions du composant MashupEngine sont assurées par le moteur d’exécution d’Eclipse (notre environnement de développement). Figure'45 :'Architecture'de'MELQART Le composant Store est un cache. Il fournit les opérations de base permettant l’ajout (bind), la suppression (unbind) et la recherche de données (lookup). Il interagit avec le gestionnaire de remplacement (ReplacementManager). Celui ci définit les données qu’il faut supprimer pour laisser de la place à des nouvelles données. Le Store interagit également avec le gestionnaire de rafraichissement (FreshnessManager) qui vise à maintenir la fraicheur des données dans le cache. Le fonctionnement des ces composants est défini en prenant en compte le caractère dynamique des données des mashups comme décrit dans le Chapitre 4. 33 Il existe différents composants activité (Filter, Extract…). Dans cette section, nous nous y référons sous le nom générique Activity80 Dans notre implantation le cache est déployé sur le serveur d’exécution des mashups. Néanmoins, il peut très bien être déployé aussi sur un autre serveur et ceci sans affecter le principe de son fonctionnement. Nous exploitons le Store pour stocker les résultats des activités proposées par des fournisseurs de données. Ceci permet d’assurer (1) leur disponibilité même en cas de défaillance d’un des fournisseurs et (2) leur partage entre différents mashlets de différents mashups, et ceci avant de les manipuler. 5.2 Valeurs)complexes Les données consommées par les mashups sont disponibles sur le web ou saisies par l’utilisateur en entrée. Les données du web sont récupérées chez des fournisseurs de données (des services web) et chacune est identifiée par un URI (Universal Resource Identifier). Les récupérations des données se font via des appels de méthodes REST. Nous adoptons la notation JSON34 pour représenter les données. En effet, les types des valeurs complexes sont compatibles avec la notation JSON35. En principe, les objets JSON peuvent représenter les valeurs complexes de type tuple. Alors que les tableaux JSON peuvent représenter les valeurs complexes de type liste ou ensemble. Ce choix n’écarte pas les données décrites sous format XML ou un autre langage de la même famille. En effet une donnée décrite sous XML peut très bien être convertie en donnée JSON et vice versa. Dans notre environnement, nous utilisons la librairie36 de référence JSON de Java pour implanter les valeurs complexes. Classe JSONObject Nous considérons la classe JSONObject37 pour implanter les données des mashups. Cette classe est offerte par la librairie de référence JSON de Java. Elle contient des méthodes qui permettent de lire les valeurs des attributs, d’ajouter et modifier des attributs. Représentation)des)valeurs)complexes)via)JSON La représentation des valeurs complexes via JSON peut être faite avec l’ensemble de règles suivantes : 1. Une valeur complexe de type tuple de la forme ! ∶ !! ∶ !! , … , !! ∶ !! est représentée par deux objets JSON imbriqués de la forme "!" ∶ "!! " ∶ !! , … ,"!!" ∶ !! . 2. Une valeur complexe de type liste de la forme ! ∶ !′ ∶ !! , … , !′ ∶ !! est représentée par un tableau d’objets JSON imbriqué lui même dans un objet JSON de la forme "!" ∶ "!′" ∶ !! , … , "!′" ∶ !! . 3. Une valeur complexe de type ensemble de la forme ! ∶ !′ ∶ !! , … , !′ ∶ !! est représentée par un tableau d’objets JSON imbriqué lui même dans un objet JSON de la forme "!" ∶ "!′" ∶ !! , … , "!′" ∶ !! . Étant donné que les valeurs JSON n’ont pas de nom associé, à l’exception des valeurs contenues dans des objets, nous utilisons un objet JSON englobant pour spécifier les noms des valeurs complexes (tuples, listes, ensembles). Bien que ce choix puisse paraître encombrant pour 34 http://www.json.org/json-fr.html 35 La syntaxe de JSON est présentée dans l’Annexe B 36 http://www.json.org/java/ 37 http://www.json.org/javadoc/org/json/JSONObject.html81 une écriture manuelle des données JSON, il ne représente pas un problème pour une implantation de données par programmation. Exemple La valeur complexe !"#$%&!%'$# ∶ !"#$%&!%'$ ∶ !"#$ ∶ "!"#4", !"#$%&'%() ∶ "!"#$!%&&%", !""#$%% ∶ "!"1", !"#$%& ∶ 3.5 , !"#$%!"#$% ∶ !"#$ ∶ "!"#1", !"#$%&'%() ∶ "!"#$ç!"#$", !""#$%% ∶ "!"2", !"#$%& ∶ 4.5 , !"#$%&!%'$ ∶ !"#$ ∶ "!"#2", !"#$%&'%() ∶ "!"#$%$"&'", !""#$%% ∶ "!"3", !"#$%& ∶ 4 , !"#$%!"#$% ∶ !"#$ ∶ "!"#3", !"#$%&'%() ∶ "!"#$%"&'(", !""#$%% ∶ "!"4", !"#$%& ∶ 3.3 peut être représentée avec l’objet JSON suivant : {"restaurants" : [ { "restaurant" : { "name" : "nom4", "speciality" : "italienne", "address" : "ad1", "rating" :3.5 }, { "restaurant" : { "name" : "nom1", "speciality" : "française", "address" : "ad2", "rating " :4.5 }, { "restaurant" : { "name" : "nom2", "speciality" : "libanaise", "address" : "ad3", "rating " :4 }, { "restaurant" : { "name" : "nom3", "speciality" : "japonaise", "address" : "ad4", "rating " :3.3 } ], } 5.3 Activité Les activités sont implantées en tant que classes. La classe Activity (Figure 46), est une classe abstraite : elle ne peut pas être instanciée directement. Deux associations avec la classe JSONObject spécifient qu’une instance de la classe Activity consomme une instance de la classe JSONObject en entrée (input) et en produit une autre en sortie (output) de type JSONObject. 82 Figure'46 :'Classe'Activity La classe Activity contient une méthode abstraite run(). Les classes filles spécialisent le fonctionnement de cette méthode. Celle ci définit le traitement que l’activité doit opérer pour produire la sortie. Une activité peut être basique ou composite. Une activité basique exécute une opération alors qu’une activité composite coordonne l’exécution de certaines activités qu’elles soient basiques ou composites. 5.3.1 Activités)basiques Dans notre modèle, Nous avons considéré un ensemble fini d’activités basiques pour le filtrage (Filter), l’extraction (Extract), le tri (Sort), la récupération de données (RetrievePP) et l’élimination de doublons (Unique). L’implantation de chacune de ces activités est faite avec une classe portant le même nom. Ces classes sont données dans la Figure 47. Elles étendent la classe Activity, et spécialisent le fonctionnement de la méthode run(). Elles sont abstraites et chacune possèdent des méthodes abstraites. Celles ci sont spécialisées par des classes filles qui sont définies lors de l’implantation des mashups. Dans les sous-sections suivantes, nous présentons (1) les classes de ces activités basiques, (2) comment elles spécialisent la méthode run() et (3) illustrer comment elle peuvent être étendues (définition de classes filles) pour l’implantation du mashup ItineraryPlanner. Des instances de ces classes sont présentées dans la sous-section 5.3.2 qui définit la coordination des activités (illustrant ainsi comment ces instances peuvent interagir entre elles).83 Figure'47 :'Les'classes'des'activités'basiques 5.3.1.1 RetrievePP La classe RetrievePP contient un attribut uri de type chaine de caractères, un attribut isJSON de type booléen et un attribut ttl de type entier. Elle contient également deux méthodes abstraites buildURI() et defineFormat(). Une instance de la classe RetrievePP récupère une donnée (1) du Store si celle ci s’y trouve elle y est, ou (2) du web auprès d’un fournisseur de données avec la méthode run(). La donnée récupérée est retournée en sortie. Cette donnée est identifiée par l’attribut uri. L’activité prend en entrée une donnée dont la valeur intervient dans la construction de l’URI via la méthode buildURI(). L’attribut ttl (Time To Live) de type entier, définit la durée de vie de la donnée récupérée auprès du fournisseur des données. Sa valeur est fixée par le constructeur du mashup pour chaque classe fille de la classe Retrieve. La valeur dépend de la nature des données récupérées. Le fonctionnement de la méthode run() est décrit dans la soussection 5.11 décrivant l’interaction entre les mashups et le Store. La méthode defineFormat() définit la valeur de l’attribut isJSON. Celui ci indique si la donnée récupérée est sous format JSON (isJSON = true) ou sous format XML (isJSON = false). Dans ce dernier la méthode run() convertit la donnée dans un format JSON. Les classes filles spécialisent le fonctionnement des méthodes buildURI() et defineFormat(). Par exemple, lors de l’implantation du mashup ItineraryPlanner, le constructeur définit une classe concrète RouteRetrieve qui étend la classe Retrieve. Cette classe spécialise le fonctionnement des deux méthodes. buildURI() définit l’URI pour la récupération de l’itinéraire entre deux villes alors que defineFormat() indique que la donnée récupérée est sous format JSON. Le fonctionnement de ces méthodes est le suivant : 84 void buildURI() { depart = input.departure ; destination = input.destination ; this.uri = "http://maps.googleapis.com/maps/api/directions/json?origin="+departure+"&des tination="+destination+"&sensor=false" ; } void defineFormat () { this.isJSON = true ; } 5.3.1.2 Filter La classe Filter contient les méthodes abstraites check(JSONObject value) et extractArray(). Une instance de la classe Filter prend en entrée une instance de JSONObject contenant un tableau d’objets JSON. Celui ci est extrait avec la méthode extractArray(). La méthode run() retourne le tableau des objets qui vérifient une certaine condition. La vérification de la condition est exécutée par la méthode check(JSONObject value). Elle se fait, éventuellement, par rapport à des valeurs contenues dans l’entrée de l’activité. La méthode run() est décrite dans le pseudo-code suivant : void run() { JSONArray valuesArray = this.extractArray() ; JSONArray resultArray; for (int i=1 ; i< valuesArray.length() ; i++) { value = valuesArray[i] ; if (check(value)) then resultArray.put(value) ; } JSONObject output = {“result” : resultArray} ; this.output = output ; } Les classes filles spécialisent le fonctionnement des méthodes extractArray() et check(). Par exemple, lors de la définition du mashup ItineraryPlanner, le constructeur définit une classe concrète RestaurantFilter. L’entrée de l’activité contient la liste de restaurants sous la forme d’un tableau JSON et la note minimale pour les restaurants recherchés (“ratingMin”) Les méthodes extractArray() et check() sont décrites avec le pseudo-code suivant : JSONArray extractArray() { JSONArray valuesArray = this.input.getJSONArray(“restaurants”) ; return valuesArray ; } Boolean check(JSONObject value) { If (value.getInt((“rating”) >= this.input.getInt(“ratingMin”)) then return true ; else return false ; } 85 5.3.1.3 Unique La classe Unique contient les méthodes abstraites extractValue(JSONObject o) et extractArray(). Une instance de la classe Unique prend en entrée une instance de JSONObject contenant un tableau d’objets JSON. Celui ci est extrait avec la méthode extractArray(). La méthode run() élimine les doublons parmi les objets de ce tableau. L’élimination des doublons se fait selon des valeurs contenues dans les objets et désignées par un même chemin d’accès. La méthode extractValue (JSONObject o) retourne la valeur contenue dans l’objet o sous la forme d’une chaine de caractère. La méthode run() est décrite dans le pseudo-code suivant : void run() { JSONArray objectArray = this.extractArray() ; JSONArray resultArray; String[] objKeys for (int i=1 ; i< objectArray.length() ; i++) { obj = objectArray [i] ; if ( ! objKeys.contains(extractValue(obj))) then resultArray.put(obj) ; } JSONObject output = {“result” : resultArray} ; this.output = output ; } Les classes filles spécialisent le fonctionnement des méthodes extractArray() et extractValue(JSONObject o). Par exemple dans le mashup ItineraryPlanner, la liste de villes (sous format WOEID) de passage entre les villes de départ et de destinations contient des doublons qu’il faut éliminer. Pour cela, le constructeur définit une classe concrète UniqueWOEID qui étend la classe Unique. Le fonctionnement des méthodes extractArray() et extractValue(JSONObject o) de cette classe est décrit avec les pseudo-codes suivants : JSONArray extractArray() { JSONArray valuesArray = this.input.getJSONArray(“result”) ; return valuesArray ; } String extractValue(JSONObject o) { int woeid = o.getInt(“woeid”) ; return String(woeid) ; } 5.3.1.4 Extract La classe Extract contient la méthode abstraite path(). Une instance de la classe Extract prend en entrée une ressource, et retourne dans un objet JSON la valeur indiquée par la méthode path(). La méthode run() est décrite dans le pseudo-code suivant : void run() { this.output = this.path() } 86 Les classes filles spécialisent le fonctionnement de la méthode path(). Par exemple, lors de l’implantation du mashup ItineraryPlanner, le constructeur du mashup définit une classe concrète StepsExtractor qui étend la classe Extract. La méthode path(), de cette classe, extrait les étapes de l’itinéraire. Elle est décrite avec le pseudo-code suivant : JSONObject path() { JSONArray steps = this.input.getJSONArray("routes").getJSONObject(0). getJSONArray("legs").getJSONObject(0).getJSONArray("steps") return {"steps" : steps} ; } 5.3.1.5 Sort La classe Sort contient un attribut ascending de type booléen et les méthodes abstraites extractArray() et compare(JSONObject o1, JSONObject o2). Une instance de la classe Sort prend en entrée une ressource contenant un tableau d’objets JSON. Celui ci est extrait avec la méthode extractArray(). La méthode run() trie les objets que le tableau contient. Le tri se fait selon une relation d’ordre définie par la méthode compare() qui défini la relation d’ordre entre deux objets. Le tri des objets peut être ascendant ou descendant selon la valeur de l’attribut ascending. Les classes filles spécialisent le fonctionnement des méthodes extractArray et compare. La méthode run() est décrite par le pseudo-code suivant : void run() { JSONArray objectArray = this.extractArray() ; JSONArray resultArray; resultArray = sort(objectArray) ;38 } 5.3.2 Activités)composites Les classes des activités composites sont données dans la Figure 48. Elles étendent la classe Activity, et spécialisent le fonctionnement de la méthode run(). Dans les sous-sections suivantes, nous présentons les classes permettant de décrire des activités composites, et comment elles spécialisent la méthode run(). Nous présentons également des classes concrètes définies lors la phase de l’implantation du mashup ItineraryPlanner. Ensuite nous allons montrer comment des instances de ces classes interagissent entre elles. 38 Nous considérons que la méthode sort(JSONArray a) implante un des algorithmes de tri proposés dans l’état de l’art [97]. 87 Figure'48 :'Les'classes'des'activités'composites 5.3.2.1 Sequence La classe Sequence est une clase concrète en association avec la classe Activity. Cette association indique qu’une instance de la classe Sequence contient un ensemble ordonné d’activités appelées sous-activités (Sub-activities). L’exécution d’une instance iseq (Figure 49) de la classe Sequence (ayant deux sousactivités) lance l’exécution des sous-activités séquentiellement. Chacune des sous-activités transmet sa sortie à la sous-activité suivante. La dernière sous–activité transmet sa sortie à la sortie de iseq. La méthode run() de l’activité Sequence correspond donc au pseudo-code suivant : run() { Activity a = this.sub-activities[0] ; a.input = this.input ; a.run() ; for (int i=1 ; i ready ; this.setMashletsInputs() ; //ajouter les mashlets, prêts à l’exécution, à ready ready = prepareMashup() ; while (not ready.empty()){ object o = ready.pop() ; if type(o) = Mashlet { o.run() ; foreach w in o.wiringAfter do { notify (w) ; ready.put(w) ; } } else {// o est de type Wiring o.run() ; Mashlet m = o.receiver ; notify (m) ; ready.put(m) ; } } 96 5.7 Item La classe Item est présentée dans la Figure 58. Elle contient les attributs uri de type chaine de caractère, result de type JSONObject et des attributs donnant des informations statistiques : Figure'58 :'Classe Item • accessNb de type entier, il indique le nombre d’accès à l’item. • ttl de type entier, il indique la durée de vie de l’item. • birthDate de type Date, il indique la date de création de l’item. • expireOn de type Date, il indique la date d’expiration de l’item. • lastAccess de type Date, indique la date du dernier accès à l’item. La classe contient également trois méthodes : la première refresh() permet de rafraichir la valeur de l’attribut result en récupérant les données depuis le fournisseur via la valeur de l’attribut uri. Alors que la seconde adjustTTL(ttl : Integer) permet de modifier la durée de vie ttl d’un item au sein du cache. Enfin, la méthode isExpired() indique si la donnée enregistrée dans l’attribut result est périmée ou pas. La Figure 59 montre un exemple d’une instance de la classe. Elle correspond au document JSON routeGP défini dans l’Annexe B et récupéré avec l’uri uriGP où : uriGP = "http://maps.googleapis.com/maps/api/directions/json?origin="+departure+"&des tination="+destination+"&sensor=false" Figure'59 :'Instance'de'la'classe'Item :Item% accessNb = 8 birthDate = 1-11-12 ttl = 30 days expireOn = 30-1-13 lastAcess = 30-11-12 result = routeGP uri = uriGP 97 5.8 Store Les fonctionnalités de gestion des items sont définies dans la classe Store (Figure 60). Celle ci est en association avec la classe Item. Cette association indique qu’une instance de la classe Store contient un ensemble d’items. Elle contient un attribut length de type entier définissant la capacité du !"#$%. La classe Store contient aussi les méthodes lookup(uri : String), bind(uri : String, result : JSONObject, ttl : Integer) et unbind(uri : String). • La méthode lookup(uri : String) permet de vérifier l’existence d’un item, ayant l’identifiant uri, au sein du Store. Le résultat de cette méthode est l’item correspondant, s’il est présent, ou null sinon. Si l’item est périmé, la méthode demande au gestionnaire de rafraichissement de le rafraichir avant de le retourner. • La méthode bind(uri : String, result : JSONObject, ttl : Integer) permet de construire un item ayant l’identifiant uri, la donnée result et une durée de vie ttl. Et elle ajoute cet item au Store. • La méthode unbind(uri : String) permet de supprimer du Store l’item dont l’identifiant possède la valeur de uri. Figure'60 :'Classe'Store La classe Store est spécifiée avec un patron de conception41 singleton : c’est à dire que son instanciation est restreinte à un seul objet. En effet, dans notre architecture, il y a un seul cache pour stocker les données provenant des services de données. Lors de la poursuite de ces travaux pour les étendre aux caches distribués pour les mashups, le patron de conception singleton sera écarté. Pour s’assurer de l’unicité de l’instance, dans la représentation de diagramme de classes dans la notation UML, les constructeurs de la classe sont définis avec une visibilité privée. Pour permettre l’accès à l’instance unique on crée une méthode getInstance() qui permet de la créer, si elle n’existe pas encore, et de la retourner. 5.9 ReplacementManager La classe ReplacementManager est présentée dans la Figure 61. Elle implante les méthodes de l’interface ReplacementManager de ACS. Comme dans des implantations fournies 41 Un patron de conception (design pattern) est la description d’un problème logiciel et des éléments d’une solution à ce problème [98]98 dans ACS, La méthode addForReplacement ajoute une référence à l’item dans une liste ordonnée gérant les items éligibles lors d’un remplacement. L’ordre des éléments est défini selon les poids des items42. Les deux méthodes addForReplacement et adjustForReplacement réalisent des actions pour mettre à jour le poids de l’item utilisé par la politique de remplacement. La classe ReplacementManager est abstraite : elle contient une méthode abstraite itemWeight(Item e). Celle ci est spécialisée par des classes filles. Son objectif est de définir le poids de l’item. Lors de l’éviction des données, les items, dont les poids sont les moins élevés, seront supprimées. Les coefficients de la formule de poids sont définis comme des attributs des classes filles et sont modifiables avec des méthodes setter. La possibilité de modifier ces attributs donne au gestionnaire une caractéristique d’adaptabilité. La classe ReplacementManager est en association avec la classe Store. Cette association indique que l’instance unique de Store possède une instance de ReplacementManager pour gérer la politique de remplacement dans MELQART. Figure'61 :'La'classe'ReplacementManager 5.10 FreshnessManager La Figure 62 présente la classe FreshnessManager. Elle possède les attributs refreshFresq, ttlMin, ttlMax et itemsRefs et les méthodes run(), addForFreshness(), removeForFreshness() et les méthodes abstraites defineRefreshFreq(), increment() et decrement(). 42 Dans l’implantation des classes d’ACS, les items (entrées de cache) sont ordonnés selon une donnée temporelle.99 Figure'62 :'La'classe'FreshnessManager La classe FreshnessManager est en association avec la classe Store qui précise que l’instance unique de Store possède une instance de FreshnessManager pour gérer le rafraichissement des items. La méthode defineRefreshFreq est une méthode abstraite. Elle est spécialisée par des classes filles de la classe FreshnessManager. Elle définit la valeur de l’attribut refreshFreq. Celui ci indique la fréquence d’exécution de la méthode run(). Tandis que l’attribut itemsRefs est de type arbre rouge et noir. Les attributs ttlMin et ttlMax définissent les valeurs minimales et maximales que peuvent avoir les durées de vies des items !!"# et !!"#. Les méthodes increment et decrement sont des méthodes abstraites. Elles sont spécialisées par des classes filles de la classe FreshnessManager. Elles définissent les valeurs à ajouter à (ou à retirer de la valeur de TTL d’un item. Elles prennent en paramètres : la valeur de TTL, le nombre d’accès à l’item et la date du dernier accès à l’entrés. Par exemple, une classe fille de FreshnessManager peut implanter les méthodes increment et decrement selon les formules définies dans les sous-sections 4.2.4.2(a) et 4.2.4.2(b). Les paramètres !, !, ! !" ! sont alors définis dans des attributs. Ils sont modifiables par des méthodes setter. La méthode addForFreshness est appelée par le Store pour signaler au gestionnaire de rafraichissement l’ajout d’un nouvel item au Store (par le biais de la méthode bind). Une référence à cet item est ajoutée dans itemsRefs. La méthode removeForFreshness prend en comme paramètre un identifiant d’un item. Elle est invoquée par le Store pour signaler au gestionnaire de rafraichissement la suppression de l’item correspondant depuis le Store (par le biais de la méthode unbind). La référence correspondante est supprimée depuis itemsRefs. La méthode processItem prend en paramètres un item dont la durée de vie est expirée. Elle exécute le processus de rafraichissement selon la stratégie TTL incrémental définie dans la sous-section 4.2.4.2. La méthode run() parcourt les premiers éléments de la liste ordonnée itemsRefs et les met à jour. Elle est lancée périodiquement, selon la valeur de l’attribut refreshFreq. Elle fonctionne selon le pseudo code suivant : 100 run() { int i = 0 ; Item it= itemsRefs[i].getItem() ; while (it.isExpired() == true) { processItem(it) ; i++ ; it= itemsRefs[i].getItem ; } } 5.11 Interaction)des)mashups)avec)le)Store L’interaction entre les mashups et le Store se déroule au niveau des activités de type RetrievePP. La méthode run() fait appel aux méthodes de la classe Store. L’exécution de la méthode est illustrée dans le diagramme de séquence de la Figure 63. Elle commence par construire l’uri, et vérifier si le Store contient un item ayant un identifiant la valeur de l’attribut uri (avec la méthode lookup(uri)) et si oui, Elle retourne le résultat stocké dans le Store. Sinon, elle récupère les données auprès du fournisseur, les convertit en format JSON si nécessaire et les stocke dans le Store (bind(uri, result, ttl)). Nous rappelons que la méthode lookup vérifie l’état de l’item avant de la retourner : si elle est déjà périmée, la méthode demande au gestionnaire de rafraichissement de rafraichir l’item (avec la méthode processItem()). La méthode run() de la classe RetrievePP est décrite avec le pseudo-code suivant void run() { this.buildURI() ; Store st= Store.getInstance() ; Item it = st.lookup(this.uri) ; if (it != null) { this.output = it.getResult(); } else { String data= getData(uri) ; // conversion du résultat en JSON if ( this.isJSON()){ this.output = new JSONObject(data) } else { this.output = XML.toJSONObject(data) } st.bind(this.uri, this.output, this.ttl) ; } } 101 Figure'63 :'Exécution'de'la'méthode'run()'de'l'activité'Retrieve'avec'utilisation'du'Store 5.12 Validation Cette section présente la validation de notre contribution. Elle a pour objectif de démontrer que les fonctionnalités que nous avons proposées et implantées avec un cache adapté au contexte des mashups répondent au problème de la non disponibilité de données dans les mashups. Nous avons implanté un prototype de MELQART avec le langage Java dans un environnement Eclipse43 . Le cache de données de mashups storeM est implanté en tant qu’une instance de la classe Store. Il associée à toutes les instances de mashups avec une taille de 1000 items (dans ACS, le prototype de cache est implanté avec un gestionnaire de taille de cache basé 43 http://www.eclipse.org/ 102 sur le nombre des items). Nous avons associé à storeM des gestionnaires de remplacement et de rafraichissement rm et fm exécutant les politiques données en exemple dans le Chapitre 4. La fréquence de rafraichissement est fixée à deux heures. Nous soulignons que l’objectif de cette validation n’est pas de démontrer que telle politique (de remplacement ou de rafraichissement) est meilleure qu’une autre ou de trouver la meilleur politique (de remplacement ou de rafraichissement). Pour valider notre implantation, nous avons défini deux scenarios de mashups ItineraryPlanner (sous-section 5.12.1) et MyDashboard (sous-section 5.12.2). L’exécution de plusieurs instances de ces mashups pour valider notre approche et notre implantation. Nous ne nous sommes pas intéressé à la visualisation des données. En effet, la visualisation ne constitue pas un aspect nécessaire de la validation de notre approche pour améliorer la disponibilité de données dans les mashups. Les données des mashlets sont présentées sous la forme d’objets JSON dans des widgets. 5.12.1ItineraryPlanner Nous avons implanté le mashup ItineraryPlanner avec les mashlets Map et Weather. Ce mashup a servi de scenario pour illustrer notre approche. Son fonctionnement fut décrit tout au long de ce document. Le corps de la méthode defineMashupComponents() de la classe ItineraryPlanner et définissant la logique applicative du mashup est présenté dans le code JAVA commenté suivant : public void defineMashupComponents() { ////Mashlet Map RetrievePP rt = new RouteRetrieve(); Mashlet map = new Mashlet("map",rt); this.addMashlet(map.getName(),map); ////Mashlet Weather WeatherRetrieve wr = new WeatherRetrieve(); WeatherExtractor extractWeatherAct = new WeatherExtractor(); // Sequence Sequence weatherSeq = new Sequence(); weatherSeq.addActivity(wr); weatherSeq.addActivity(extractWeatherAct); // Foreach CitiesWeatherForeach itpWeatherForeach = new CitiesWeatherForeach(); itpWeatherForeach.setSubActivity(weatherSeq); Mashlet weather = new Mashlet("weather", itpWeatherForeach); this.addMashlet(weather.getName(),weather); ////Wiring Map2Wiring //extraction des villes de passage StepsExtractor stepsExtO = new StepsExtractor(); // conversion au format WOEID RetrieveWOEIDPlace rw = new RetrieveWOEIDPlace(); WoeidPlaceExtractor woeidExtractorAct = new WoeidPlaceExtractor(); Sequence woeidSeq = new Sequence(); woeidSeq.addActivity(rw); woeidSeq.addActivity(woeidExtractorAct); CitiesListForeach citiesListForeachAct = new CitiesListForeach(); citiesListForeachAct.setSubActivity(woeidSeq); // élimination des doublons WOEID UniqueWOEID uniqueWOEIDAct = new UniqueWOEID(); // mise en séquence Sequence stepsSeq = new Sequence();103 stepsSeq.addActivity(stepsExtO); stepsSeq.addActivity(citiesListForeachAct); stepsSeq.addActivity(uniqueWOEIDAct); Wiring map2weather = new Wiring("map2weather", map,weather, stepsSeq); this.addWiring(map2weather.getName(), map2weather); } La Figure 64 présente les résultats du mashup pour un itinéraire allant de Grenoble jusqu’à Paris. Figure'64 :'Résultats'du'mashup'ItinerayPlanner'pour l’itinéraire'de'Grenoble'à'Paris Le mashup a deux entrées : la ville de départ et la ville d’arrivées. Toutes les deux sont de type chaine de caractères. Les données, du mashlet maps, proviennent du service Google maps44 . Alors que les données du mashlet weather proviennent du service Yahoo! Weather45. Un mapping est nécessaire pour transformer les descriptions des villes de passage du format (longitude, latitude) au format WOEID. Ce mapping est fait via le service Yahoo! BOSS Geo Services46. Le Tableau 6 donne les durées de vie que nous avons estimées pour les données récupérées de chaque service. Fournisseur des données Durée de vie des données Google maps 30 jours Yahoo! Weather 5 heures Yahoo! Boss 60 jours Tableau'6':'Durées'des'vies'des'données'du'mashup'ItineraryPlanner 44 https://developers.google.com/maps/documentation/directions/ 45 http://developer.yahoo.com/weather/ 46 http://developer.yahoo.com/boss/geo/104 5.12.2MyDashboard Le deuxième mashup est nommé MyDashboard. Il contient deux mashlets. Un mashlet « Weather » qui donne la météo pour une ville saisie par l’utilisateur et un Mashlet « Programmes TV » qui affichent les programmes TV de différentes chaines de la soirée. Le corps de la méthode defineMashupComponents() de la classe MyDashboard et définissant la logique applicative du mashup définissant son implantation est présenté dans le code JAVA commenté suivant : public void defineMashupComponents() { ////Mashlet Weahter RetrieveWOEIDPlace rwc = new RetrieveWOEIDPlace(); WoeidPlaceExtractor ewc = new WoeidPlaceExtractor(); WeatherRetrieve wr = new WeatherRetrieve(); Sequence ws = new Sequence(); ws.addActivity(rwc); ws.addActivity(ewc); ws.addActivity(wr); Mashlet weather = new Mashlet("weather",ws); this.addMashlet(weather.getName(),weather); ////Mashlet TV TVProgRetrieve tvp = new TVProgRetrieve(); Mashlet myprg = new Mashlet("myprg",tvp); this.addMashlet(myprg.getName(),myprg); } La Figure 64 présente les résultats du mashup MyDashboard avec Grenoble comme paramètre en entrée. Figure'65 :'Résultats'du'mashup'MyDashboard'avec'Grenoble'comme'paramètre'en'entrée. Le mashup possède une seule entrée : la ville de l’utilisateur de type chaine de caractères. Les données du mashlet « Programmes TV » proviennent d’un flux RSS47. Alors que les données du 47 http://feeds.feedburner.com/programme-television105 mashlet « Weather » proviennent du service Yahoo! Weather. Un mapping est nécessaire pour transformer la description de la ville de l’utilisateur du format « nom de ville » au format WOEID. Ce mapping est fait via le service Yahoo! GeoPlanet48. Le Tableau 7 donne les durées de vie que nous avons estimées pour les données récupérées de chaque service. Fournisseur des données Durée de vie des données Flux TV 1 jour Yahoo! Weather 5 heures Yahoo! GeoPlanet 60 jours Tableau'7':'Durées'des'vies'des'données'du'mashup'MyDashboard 5.12.3Execution)des)instances)des)mashups Nous avons crée plusieurs instances des mashups ItineraryPlanner et MyDashboard, que nous avons lancées avec plusieurs valeurs en paramètres d’entrée (cf. Figure 66). Les exécutions se sont terminées correctement et ont retourné les résultats attendus. Par injection d’impressions de traces dans le code, nous avons pu observer la gestion des données des mashups. Les données produites par les activités de type RetrievePP sont bien stockées dans le Store. Ces données sont récupérées directement du Store, lors d’une exécution ultérieure des mêmes activités avec les mêmes valeurs de paramètres d’entrées. Ceci fut observé également avec la rapidité d’exécution des mashups et l’obtention rapide des résultats. En plus, ce qui est le plus important est le fait de pouvoir accéder aux données du Store pour exécuter des instances de mashups même en cas de rupture de communication avec les fournisseurs de données (simulée par une déconnexion de la machine du réseau) ce qui valide notre approche implantée avec un cache pour garantir la disponibilité des données dans les mashups. Le gestionnaire de remplacement évinçait les items jugés les moins importantes par la politique de remplacement choisie. Le gestionnaire de rafraichissement s’est lancé périodiquement pour vérifier l’état de validités des items. Ainsi, les items, correspondant aux données provenant du service Yahoo! Weather, furent mises à jour pendant la journée de test. En plus, lorsque nous avons lancé le mashup ItineraryPlanner, à un moment où les données météorologiques étaient périmées dans le Store (avant le déclenchement du processus périodique de rafraichissement), le Store demandait au gestionnaire de rafraichissement de rafraichir les items avant de les retourner. 5.13 Conclusion Ce chapitre a présenté l’implantation d’un prototype de MELQART notre système d’exécution de mashups avec disponibilité de données. L’architecture du système fut présentée en premier. Ensuite, nous avons présenté l’implantation des concepts de mashups et des fonctionnalités proposées pour améliorer la disponibilité de données. Pour implanter ces fonctionnalités, Nous avons adapté des gestionnaires d’ACS au contexte des mashups et nous avons introduit le gestionnaire de rafraichissement. La validation de notre implantation nous a montré que les dites fonctionnalités implantées via un cache constituent une solution crédible pour garantir la disponibilité de données dans les mashups. 48 http://developer.yahoo.com/geo/geoplanet/guide/index.html 106 Figure'66 :'Chronologie'des'exécutions t0 • Exécu&on)d’I&neraryPlanner) entre)Grenoble)et)Paris.)) • Récupéra&on)de)données) depuis)les)fournisseurs) t1 • Exécu&on)d’I&neraryPlanner) entre)Grenoble)et)Paris.)) • Récupéra&on)de)données) depuis)le)Store) • Exécu&on)de)MyDashboard) avec)Grenoble)comme)ville.)) • Récupéra&on)des)données) météorologiques)depuis)le) Store) t2 t0+2h • Les)données)météo) récupérées)lors)de)la) première)exécu&on) sont)périmées) • Exécu&ons)successives)des) instances)des)mashups)avec) différentes)entrées,)avec) interrup&on)de)connexion) t0+4h t0+5h • Lancement)du)processus)de) rafraichissement) • Rien)à)rafraichir) t0+5h10 t0+6h • Exécu&on)d’I&neraryPlanner) entre)Grenoble)et)Paris.)) • Récupéra&on)des)données)de) l’i&néraire)depuis)le)Store.) • Récupéra&on)des)données) météorologiques)depuis)le) fournisseur)) • Rafraichissement)des)données) et)adapta&on)de)la)durée)de)vie) des)données)météorologiques) • Exécu&ons)successives)des) instances)des)mashups.) • Le)processus)de)remplacement) se)déclenchait)afin)de)libérer)de) l’espace)dans)le)Store • Lancement)du)processus)de) rafraichissement) • Rafraichissement)des) données)météorologiques) récupérées)entre)t0)et)t0+1h)107 Chapitre!6 CONCLUSION L’objectif de ce travail était d’améliorer la disponibilité de données fraiches dans les mashups. Nous avons proposé MELQART : un système d’exécution de mashups avec une solution pour améliorer la disponibilité et la fraicheur de données des mashups. Dans la suite nous soulignons nos contributions et les perspectives de notre travail. 6.1 Contribution)et)bilan La première contribution de ce travail est un état de l’art sur les modèles des mashups, les systèmes d’exécution de mashups et leurs architectures ainsi que la disponibilité de données fraiches sur le web. Nous avons observé qu’il y a peu de travaux qui proposent des modèles de mashups et que ceux qui existent ne sont pas suffisamment riches pour spécifier les caractéristiques de la disponibilité de données. Nous avons également constaté que les techniques actuelles de disponibilité de données ne sont pas adaptées à des applications comme les mashups. Enfin, parmi le peu de travaux qui se sont intéressés à la disponibilité des données des mashups, le problème de la fraicheur des données disponibles n’est pas abordé. Nous avons en conséquence proposé MELQART : un système d’exécution de mashups avec une solution pour améliorer la disponibilité et la fraicheur de données des mashups. Cette solution propose des fonctionnalités orthogonales au processus d’exécution de mashups pour améliorer la disponibilité de données récupérées auprès des fournisseurs de données. Dans la suite de cette section, nous présentons nos conclusions au regard de nos contributions dans le cadre de MELQART. Nous avons défini un modèle de description de mashups basé sur les valeurs complexes. Des activités basiques décrivent la manipulation des données de mashups (le filtrage, la projection, l’extraction, l’élimination de doublons, le tri, l’union et l’annexe). Ces activités sont coordonnées par des activités composites (Séquence, Foreach, Parallel). Le modèle peut être enrichi avec d’autres activités dans le futur selon les besoins qui peuvent apparaître. Elles sont utilisées par des mashlet et des wirings. Les mashlets affichent des données produites par les activités tandis que les wirings coordonnent l’exécution des mashlets. Dans notre modèle, les wirings ne décrivent pas qu’un transfert de données entre mashlets comme c’est le cas dans les modèles existants. Ils peuvent aussi, décrire le traitement des données pour les délivrer sous le bon format aux mashlets destinataires. Notre modèle permet également de spécifier les caractéristiques de la disponibilité et de la fraicheur de données. 108 Nous avons présenté les phases du processus d’exécution d’un mashup et notre solution pour améliorer la disponibilité de données fraiches des mashups. Celle ci est à base de fonctions orthogonales au processus d’exécution des mashups. Ce processus est basé sur la représentation d’un mashup sous la forme d’un graphe dont le parcours permet de coordonner l’exécution des mashlets et des wirings du mashup. Nous avons décrit les phases des processus d’exécution des mashlets et des wirings et de leurs activités sous-jacentes. Des fonctionnalités permettant l’améliorer la disponibilité des données récupérées auprès des fournisseurs de données et d’assurer leur fraicheur. Les données sont rendues disponibles dans un !"#$%. Pour cela, nous avons décrit l’organisation du contenu du !"#$% en un ensemble d’items. Nous avons ensuite décrit la gestion de ce contenu et les fonctions qui y sont relatives : ajouter, modifier, supprimer et rechercher des items. Ensuite, nous avons décrit les fonctions de remplacement et de rafraichissement des items. Pour le remplacement des items, nous avons dressé une liste de facteurs entrant en jeu lors de la définition de la politique de remplacement dans le contexte des mashups. Le rafraichissement des items est exécuté d’une façon incrémentale. Nous avons adopté une stratégie adaptative pour la définition des durées de vie des items ainsi nous avons adapté la stratégie TTL incrémental au contexte des mashups. Nous avons implanté les concepts de mashups et les fonctionnalités proposées pour améliorer la disponibilité de données. Pour implanter ces fonctionnalités, Nous avons adapté des gestionnaires d’ACS au contexte des mashups et nous y avons introduit le gestionnaire de rafraichissement. La validation de notre implantation, via des tests sur l’exécution de deux scénarios de mashups, nous a montré que les dites fonctionnalités implantées via un cache constituent une solution crédible pour garantir la disponibilité de données dans les mashups. 6.2 Perspectives Les travaux réalisés dans cette thèse ne sont que le premier pas vers la définition d’un environnement pour la construction et l’exécution de mashups. Des nouveaux défis et améliorations doivent être traités. Les points qui nous apparaissent intéressants pour la suite sont : • Définir un langage déclaratif permettant à un utilisateur final de définir son mashup. Ce langage peut être aussi bien textuel que graphique. Ceci constitue une amélioration apportée à MELQART en vue d’une évolution vers un environnement de définition et d’exécution de mashups. Actuellement, la définition d’un langage de mashups fait partie des projets RedShine49 et Clever50 . • Considérer le cas de figure où les données du !"#$% sont périmées et qu’il est impossible de les rafraichir (dans le cas de rupture de connexion avec le fournisseur de données correspondant). Ceci implique la mise en œuvre d’un traitement d’exceptions et des actions pour palier ces exceptions en assurant un fonctionnement du mashup même détérioré. Une solution possible peut inclure la recherche d’un autre fournisseur de données offrant des données contenant l’information recherchée. Ceci nécessite la mise en place d’un processus de mapping de données pour récupérer des données décrites selon le même format. Ce travail a été démarré dans le cadre des projets Clever et e-Cloudss51 et dans un des scénarios de validation de la thèse de Javier Espinosa [99]. Ils implantent des stratégies simples de rafraîchissement. Ils doivent évoluer pour prendre en considération des stratégies adaptatives, modifiables et tenant compte des besoins de l’utilisateur. 49 http://red-shine.imag.fr/ 50 http://clever.imag.fr 51 http://e-cloudss.imag.fr/109 • Mettre en cache les résultats de certaines activités intermédiaires dans un arbre d’activités. Toutefois, pour cela, il faut prendre en considération plusieurs facteurs pour choisir l’activité ; comme le nombre d’exécutions (cette différence entre activités d’un arbre provient de la possibilité de qu’une activité peut faire partie de deux arbres ou plus), l’espace restant dans le !"#$% etc. • Mettre des données en cache sur la machine du client. Le cache, en question, pourrait être utilisé pour stocker les données des mashlets d’un mashup. Ces données sont produites sur le serveur de MELQART et envoyées à l’utilisateur. Cacher ces données permet d’assurer leur disponibilité même en cas d’une déconnexion de la machine du client. • Considérer le cas des données récupérées avec un mécanisme de pagination ou les données récupérées en continue sous la forme d’un flux. Dans ce cas Comment réorganiser le !"#$% ? Comment le gérer ? Et Comment réadapter les fonctionnalités de disponibilités de données ? • Étudier et procéder à l’amélioration d’autres qualités de services QoS. Il existe déjà des travaux comme [100][101] qui ont traité le problème de la confidentialité des données (data privacy). D’autres propriétés QoS pour la gestion des mashups et des données ont été identifiées dans [67][102][103][33][104]. Parmi ces propriétés, nous retrouvons, la sécurité des données (data security), la précision des données (data accuracy) et l’utilisabilité de la présentation (presentation usability). o La sécurité réfère aux stratégies qui assurent la sureté d’un mashup et de ses données. Comment s’assurer de l’intégrité des données : le fait que les données ne subissent aucune altération ou déformation lors du transfert des données entre les fournisseurs et le mashup ? Comment gérer les données confidentielles dans une application où les données sont mélangées ? o La précisons des données réfère à l'exactitude et la cohérence des données du mashup par rapport au monde. La précision est mesurée comme la proximité des données récupérées aux données correctes (dans le monde réelle). La précision des données d’un mashup dépend de la précision des fournisseurs de données. Dans [67], la précision des données est exprimée comme étant la probabilité que les donnés soient correctes : ! !"" = 1 − !(!"") Où !(!"") est la probabilité qu’une erreur se produise. L’erreur de précision peut se produire pour différentes raisons, telles que les fautes de frappe, la représentation erronée ou mises à jour manquantes. Comment un système d’exécution de mashups peut vérifier l’exactitude des données récupérées ? Comment détecter si un service de données n’est plus maintenu à jour par ses propriétaires ? Et comment réagir dans ce cas ? o L’utilisabilité de la présentation est une propriété qui caractérise l’expérience de l’utilisateur. Les mêmes attributs de l’utilisabilité de présentation, définis pour les pages web [105][106], peuvent être pris en compte pour l’utilisabilité de la présentation des mashups. En particulier la compréhension du fonctionnement (learnability) et la compréhension du contenu (understandability) et l’attractivité de la présentation (attractiveness). Dans le cas des mashups, est ce qu’il faut revoir ces attributs ? Quelles stratégies faut il mettre en place pour aider le constructeur de mashups à construire des mashups respectant ces attributs ? • Etudier la prise en compte des préférences de l’utilisateur. Dans [107], les auteurs proposent un système de mashups avec la prise en compte des préférences de l’utilisateur liées aux informations qu’il recherche (par exemple : préférer le moins cher etc.). Nous pensons qu’il faut également développer une étude sur les préférences de l’utilisateur en matière de qualités de service du mashup comme la sécurité, la fraicheur, la précision des données. • Étudier la répartition de la charge de l’exécution des mashups entre le serveur de MELQART et sur la machine de l’utilisateur. Comment repartir les tâches ? Et dans ce cas, la machine du client peut être faible en ressources (capacité de calcul mémoire, énergie), ainsi il faut mettre une place une stratégie d’optimisation d’exécution des mashups. Cette stratégie doit prendre en 110 considération l’ordre des exécutions des activités et le choix des algorithmes pour l’exécution des opérations de manipulation de données.111 BIBLIOGRAPHIE [1] D. Merrill, “Mashups: The new breed of Web app,” IBM Corporation, CT316, Aug. 2006. [2] F. Belleau, M.-A. Nolin, N. Tourigny, P. Rigault, and J. Morissette, “Bio2RDF: Towards a mashup to build bioinformatics knowledge systems,” Journal of Biomedical Informatics, vol. 41, no. 5, pp. 706–716, Oct. 2008. [3] S. Abiteboul, O. Greenshpan, and T. Milo, “Modeling the mashup space,” in Proceeding of the 10th ACM workshop on Web information and data management, Napa Valley, California, USA, 2008, pp. 87–94. [4] Ke Xu, Meina Song, and Xiaoqi Zhang, “Home Appliance Mashup System Based on Web Service,” in Service Sciences (ICSS), 2010 International Conference on, 2010, pp. 94–98. [5] C. Safran, D. Helic, and C. Gütl, “E-Learning practices and Web 2.0,” presented at the Proc. of the 10th International Conference of Interactive computer aided learning (ICL 2007), Villach Austria, 2007. [6] M. Eisenstadt, “Does Elearning Have To Be So Awful? (Time to Mashup or Shutup),” in Advanced Learning Technologies, 2007. ICALT 2007. Seventh IEEE International Conference on, 2007, pp. 6 –10. [7] N. Schuster, C. Zirpins, M. Schwuchow, S. Battle, and S. Tai, “The MoSaiC model and architecture for service-oriented enterprise document mashups,” in Proceedings of the 3rd and 4th International Workshop on Web APIs and Services Mashups, New York, NY, USA, 2010, pp. 5:1–5:8. [8] M. Essid, Y. Lassoued, and O. Boucelma, “Processing Mediated Geographic Queries: a Space Partitioning Approach,” in The European Information Society, S. I. Fabrikant and M. Wachowicz, Eds. Springer Berlin Heidelberg, 2007, pp. 303–315. [9] O. Boucelma, “Spatial Data Integration on the Web: Issues and Solutions,” presented at the MoMM, 2006, pp. 5–6. [10] “Pipes: Rewire the web.” [Online]. Available: http://pipes.yahoo.com/pipes/. [Accessed: 12- Jan-2011]. [11] Jin Yu, B. Benatallah, F. Casati, and F. Daniel, “Understanding Mashup Development,” Internet Computing, IEEE, vol. 12, no. 5, pp. 44–52, 2008. [12] H. Chen, B. Lu, Y. Ni, G. Xie, C. Zhou, J. Mi, and Z. Wu, “Mashup by surfing a web of data APIs,” Proc. VLDB Endow., vol. 2, no. 2, pp. 1602–1605, 2009. [13] E. M. Maximilien, A. Ranabahu, and K. Gomadam, “An Online Platform for Web APIs and 112 Service Mashups,” Internet Computing, IEEE, vol. 12, no. 5, pp. 32–43, 2008. [14] E. M. Maximilien, H. Wilkinson, N. Desai, and S. Tai, “A Domain-Specific Language for Web APIs and Services Mashups,” in Proceedings of the 5th international conference on ServiceOriented Computing, Vienna, Austria, 2007, pp. 13–26. [15] Nan Zang and M. B. Rosson, “Playing with information: How end users think about and integrate dynamic data,” in Visual Languages and Human-Centric Computing, 2009. VL/HCC 2009. IEEE Symposium on, 2009, pp. 85–92. [16] R. Ennals and D. Gay, “User-friendly functional programming for web mashups,” in Proceedings of the 12th ACM SIGPLAN international conference on Functional programming, Freiburg, Germany, 2007, pp. 223–234. [17] J. Lin, J. Wong, J. Nichols, A. Cypher, and T. A. Lau, “End-user programming of mashups with vegemite,” in Proceedings of the 13th international conference on Intelligent user interfaces, Sanibel Island, Florida, USA, 2009, pp. 97–106. [18] E. Acquaro, V. Manferto de Fabianis, and L. Cohen, Les Phéniciens trésors d’une civilisation ancienne. Vercelli (Italie); Paris: White Star, 2009. [19] S. Abiteboul and C. Beeri, “The power of languages for the manipulation of complex values,” The VLDB Journal, vol. 4, no. 4, pp. 727–794, Oct. 1995. [20] S. Abiteboul, R. Hull, and V. Vianu, Eds., Foundations of Databases: The Logical Level, 1st ed. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1995. [21] E. F. Codd, “A relational model of data for large shared data banks,” Commun. ACM, vol. 13, no. 6, pp. 377–387, juin 1970. [22] F. Bancilhon, “The O2 object-oriented database system,” in Proceedings of the 1992 ACM SIGMOD international conference on Management of data, New York, NY, USA, 1992, pp. 7–7. [23] K. R. Dittrich, H. Fritschi, S. Gatziu, A. Geppert, and A. Vaduva, “SAMOS in hindsight: experiences in building an active object-oriented DBMS,” Inf. Syst., vol. 28, no. 5, pp. 369– 392, juillet 2003. [24] R. G. G. Cattell, D. K. Barry, M. D. Berler, J. Eastman, D. Jordan, C. Russel, O. Schadow, T. Stanienda, and F. Velez, The Object Data Satandard: ODMG 3.0. Morgan Kaufmann, 2000. [25] E. Griffin, Foundations of Popfly: Rapid Mashup Development. Apress, 2008. [26] S. Abiteboul, P. Buneman, and D. Suciu, Data on the Web: From Relations to Semistructured Data and Xml. Morgan Kaufmann, 2000. [27] S. Abiteboul, I. Manolescu, P. Rigaux, M.-C. Rousset, and P. Senellart, Web Data Management. Cambridge University Press, 2011. [28] C. R. Anderson and E. Horvitz, “Web montage: a dynamic personalized start page,” in Proceedings of the 11th international conference on World Wide Web, New York, NY, USA, 2002, pp. 704–712. [29] R. J. Ennals and M. N. Garofalakis, “MashMaker: mashups for the masses,” in Proceedings of the 2007 ACM SIGMOD international conference on Management of data, Beijing, China, 113 2007, pp. 1116–1118. [30] “JackBe.com - Real-Time Intelligence Solutions | Presto.” [Online]. Available: http://www.jackbe.com/products/. [Accessed: 12-Jan-2011]. [31] A. Bouguettaya, S. Nepal, W. Sherchan, Xuan Zhou, J. Wu, Shiping Chen, Dongxi Liu, L. Li, Hongbing Wang, and Xumin Liu, “End-to-End Service Support for Mashups,” Services Computing, IEEE Transactions on, vol. 3, no. 3, pp. 250–263, 2010. [32] “Mashup Server by WSO2 - Open Source Mashup Server for easy Web service composition and aggregation using JavaScript | WSO2.” [Online]. Available: http://wso2.com/products/mashup-server/. [Accessed: 12-Jan-2012]. [33] J. Palfrey and U. Gasser, “Case Study: Mashups Interoperability and eInnovation,” University of St. Gallen, 2007. [34] D. Deutch, O. Greenshpan, and T. Milo, “Navigating through Mashed-up Applications with COMPASS,” in Data Engineering (ICDE), 2010 IEEE 26th International Conference on, 2010, pp. 1117–1120. [35] V. Hoyer and M. Fischer, “Market Overview of Enterprise Mashup Tools,” in ServiceOriented Computing – ICSOC 2008, 2008, pp. 708–721. [36] Amin Andjomshoaa, G. Bader, and A. M. Tjoa, “Exploiting Mashup Architecture in Business Use Cases,” presented at the NBIS 2009, Indianapolis, USA, 2009. [37] V. Hoyer and K. Stanoevska-Slabeva, “Towards a Reference Model for Grassroots Enterprise Mashup Environmentd,” in Proceedings of the 17th European Conference on Information Systems (ECIS 2009), Verona, Italy, 2009, p. 10. [38] M. Altinel, P. Brown, S. Cline, R. Kartha, E. Louie, V. Markl, L. Mau, Y.-H. Ng, D. Simmen, and A. Singh, “Damia: a data mashup fabric for intranet applications,” in Proceedings of the 33rd international conference on Very large data bases, Vienna, Austria, 2007, pp. 1370– 1373. [39] L. Ramaswamy, J. A Miller, and O. Al-Haj Hassan, “The MACE Approach for Caching Mashups,” International Journal of Web Services Research, vol. 7, no. 4, pp. 64–88, 2010. [40] J. Crupi, “A Business Guide to Enterprise Mashups,” JackeBe Corporation, 2008. [41] V. Hoyer and K. Stanoevska-Slabeva, “Generic Business Model Types for Enterprise Mashup Intermediaries,” Value Creation in E-Business Management, 2009. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-03132-8_1. [Accessed: 11-Dec-2009]. [42] D. Deutch, O. Greenshpan, and T. Milo, “Navigating in complex mashed-up applications,” Proc. VLDB Endow., vol. 3, pp. 320–329, Sep. 2010. [43] A. Thor, D. Aumueller, and E. Rahm, “Data Integration Support for Mashups,” 2007. [44] G. Di Lorenzo, H. Hacid, H. Paik, and B. Benatallah, “Data integration in mashups,” SIGMOD Rec., vol. 38, no. 1, pp. 59–66, Jun. 2009. [45] N. Bidoit, Bases de données déductives: présentation de Datalog. Armand Colin, 1991. [46] P. G. Kolaitis and M. Y. Vardi, On the Expressive Power of Datalog: Tools and a Case Study. 114 University of California, Santa Cruz, Computer Research Laboratory, 1990. [47] E. Ort, S. Brydon, and M. Balser, “Mashup Styles, Part 1: Server-Side Mashups,” Oracle, 2007. [48] E. Ort, S. Brydon, and M. Balser, “Mashup Styles, Part 2: Client-Side Mashups in the Java EE Platform,” Oracle, 2007. [49] A. Koschmider, V. Torres, and V. Pelechano, “Elucidating the Mashup Hype: Definition, Challenges, Methodical Guide and Tools for Mashups,” in 2nd Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web in conjunction with the 18th International World Wide Web Conference, Madrid, 2009. [50] R. Ennals, E. Brewer, M. Garofalakis, M. Shadle, and P. Gandhi, “Intel Mash Maker: join the web,” SIGMOD Rec., vol. 36, no. 4, pp. 27–33, 2007. [51] S. Aghaee and C. Pautasso, “Mashup development with HTML5,” in Proceedings of the 3rd and 4th International Workshop on Web APIs and Services Mashups, New York, NY, USA, 2010, pp. 10:1–10:8. [52] K. Pfeil, “Data Security and Data Availability in the Administrative Authority,” Microsoft TechNet. [53] F. Piedad and M. W. Hawkins, High Availability: Design, Techniques, and Processes, 1st ed. Prentice Hall, 2000. [54] E. Marcus and H. Stern, Blueprints for High Availability. Wiley, 2003. [55] V. Peralta, “Data freshness and data accuracy: A state of the art,” Instituto de Computación, Facultad de Ingeniería, Universidad de la República, URUGUAY, 2006. [56] M. Bouzeghoub, “A framework for analysis of data freshness,” in Proceedings of the 2004 international workshop on Information quality in information systems, New York, NY, USA, 2004, pp. 59–67. [57] B. Shin, “An Exploratory Investigation of System Success Factors in Data Warehousing,” Journal of the Association for Information Systems, vol. 4, no. 1, Aug. 2003. [58] X. Ma, S. S. Vazhkudai, and Z. Zhang, “Improving Data Availability for Better Access Performance: A Study on Caching Scientific Data on Distributed Desktop Workstations,” J Grid Computing, vol. 7, no. 4, pp. 419–438, Dec. 2009. [59] S. Drapeau, “RS2.7 : un Canvas Adaptable de Services de Duplication,” Institut National Polytechnique De Grenoble, Grenoble, 2003. [60] R. van Renesse and R. Guerraoui, “Replication,” B. Charron-Bost, F. Pedone, and A. Schiper, Eds. Berlin, Heidelberg: Springer-Verlag, 2010, pp. 19–40. [61] R. van Renesse and R. Guerraoui, “Replication Techniques for Availability,” in Replication, B. Charron-Bost, F. Pedone, and A. Schiper, Eds. Springer Berlin Heidelberg, 2010, pp. 19–40. [62] L. D’Orazio, “Caches adaptables et applications aux systèmes de gestion de données répartis à grande échelle,” Grenoble INP, 2007. [63] J. Wang, “A survey of web caching schemes for the Internet,” SIGCOMM Comput. 115 Commun. Rev., vol. 29, no. 5, pp. 36–46, Oct. 1999. [64] K. S. Ahluwalia and A. Jain, “High availability design patterns,” in Proceedings of the 2006 conference on Pattern languages of programs, New York, NY, USA, 2006, pp. 19:1–19:9. [65] G. Attiya and Y. Hamam, “Reliability oriented task allocation in heterogeneous distributed computing systems,” in Ninth International Symposium on Computers and Communications, 2004. Proceedings. ISCC 2004, 2004, vol. 1, pp. 68 – 73 Vol.1. [66] N. R. May, H. W. Schmidt, and I. E. Thomas, “Service Redundancy Strategies in ServiceOriented Architectures,” in Proceedings of the 2009 35th Euromicro Conference on Software Engineering and Advanced Applications, Washington, DC, USA, 2009, pp. 383– 387. [67] C. Cappiello, F. Daniel, M. Matera, and C. Pautasso, “Information Quality in Mashups,” Internet Computing, IEEE, vol. 14, no. 4, pp. 14–22, 2010. [68] D. Ballou, R. Wang, H. Pazer, and G. K. Tayi, “Modeling Information Manufacturing Systems to Determine Information Product Quality,” Manage. Sci., vol. 44, no. 4, pp. 462–484, avril 1998. [69] G. Di Lorenzo, H. Hacid, H. Paik, and B. Benatallah, “Mashups for Data Integration: An Analysis,” UNSW-CSE, 0810, 2008. [70] M. Bhide, P. Deolasee, A. Katkar, A. Panchbudhe, K. Ramamritham, and P. Shenoy, “Adaptive Push-Pull: Disseminating Dynamic Web Data,” IEEE Trans. Comput., vol. 51, no. 6, pp. 652–668, juin 2002. [71] G. Soundararajan, C. Amza, and A. Goel, “Database replication policies for dynamic content applications,” SIGOPS Oper. Syst. Rev., vol. 40, no. 4, pp. 89–102, avril 2006. [72] P. A. Bernstein, V. Hadzilacos, and N. Goodman, Concurrency control and recovery in database systems. Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc., 1987. [73] C. Pu and A. Leff, “Replica control in distributed systems: as asynchronous approach,” in Proceedings of the 1991 ACM SIGMOD international conference on Management of data, New York, NY, USA, 1991, pp. 377–386. [74] B. Kemme and G. Alonso, “A new approach to developing and implementing eager database replication protocols,” ACM Trans. Database Syst., vol. 25, no. 3, pp. 333–379, Sep. 2000. [75] R. Ladin, B. Liskov, L. Shrira, and S. Ghemawat, “Providing high availability using lazy replication,” ACM Trans. Comput. Syst., vol. 10, no. 4, pp. 360–391, Nov. 1992. [76] M.-K. Liu, F.-Y. Wang, and D. Zeng, “Web caching: A way to improve web QoS,” Journal of Computer Science and Technology, vol. 19, no. 2, pp. 113–127, 2004. [77] J. Yin, L. Alvisi, M. Dahlin, and A. Iyengar, “Engineering web cache consistency,” ACM Trans. Internet Technol., vol. 2, no. 3, pp. 224–259, août 2002. [78] Y. Ahmad, O. Kennedy, C. Koch, and M. Nikolic, “DBToaster: higher-order delta processing for dynamic, frequently fresh views,” Proc. VLDB Endow., vol. 5, no. 10, pp. 968–979, juin 2012.116 [79] M. Altinel, C. Bornhövd, S. Krishnamurthy, C. Mohan, H. Pirahesh, and B. Reinwald, “Cache tables: paving the way for an adaptive database cache,” in Proceedings of the 29th international conference on Very large data bases - Volume 29, 2003, pp. 718–729. [80] A. Labrinidis and N. Roussopoulos, “Exploring the tradeoff between performance and data freshness in database-driven Web servers,” The VLDB Journal, vol. 13, no. 3, pp. 240–255, Sep. 2004. [81] P. Scheuermann, J. Shim, and R. Vingralek, “WATCHMAN: A Data Warehouse Intelligent Cache Manager,” in Proceedings of the 22th International Conference on Very Large Data Bases, San Francisco, CA, USA, 1996, pp. 51–62. [82] Y. Kotidis and N. Roussopoulos, “DynaMat: a dynamic view management system for data warehouses,” SIGMOD Rec., vol. 28, no. 2, pp. 371–382, juin 1999. [83] W. Ye, N. Gu, G. Yang, and Z. Liu, “Extended derivation cube based view materialization selection in distributed data warehouse,” in Proceedings of the 6th international conference on Advances in Web-Age Information Management, Berlin, Heidelberg, 2005, pp. 245–256. [84] I. S. Altingovde, R. Ozcan, B. B. Cambazoglu, and Ö. Ulusoy, “Second chance: a hybrid approach for dynamic result caching in search engines,” in Proceedings of the 33rd European conference on Advances in information retrieval, Berlin, Heidelberg, 2011, pp. 510–516. [85] B. B. Cambazoglu, F. P. Junqueira, V. Plachouras, S. Banachowski, B. Cui, S. Lim, and B. Bridge, “A refreshing perspective of search engine caching,” in Proceedings of the 19th international conference on World wide web, New York, NY, USA, 2010, pp. 181–190. [86] Sadiye Alici, I. S. Altingovde, R. Ozcan, B. B. Cambazoglu, and Ö. Ulusoy, “Adaptive timeto-live strategies for query result caching in web search engines,” in Proceedings of the 34th European conference on Advances in Information Retrieval, Berlin, Heidelberg, 2012, pp. 401–412. [87] J. Tatemura, O. Po, A. Sawires, D. Agrawal, and K. S. Candan, “WReX: a scalable middleware architecture to enable XML caching for web-services,” in Proceedings of the ACM/IFIP/USENIX 2005 International Conference on Middleware, New York, NY, USA, 2005, pp. 124–143. [88] V. Ramasubramanian and D. B. Terry, “Caching of XML Web Services for Disconnected Operation,” Microsoft Research, 2002. [89] T. Takase and M. Tatsubori, “Efficient Web services response caching by selecting optimal data representation,” in 24th International Conference on Distributed Computing Systems, 2004. Proceedings, 2004, pp. 188 – 197. [90] D. D. Terry and V. Ramasubramanian, “Caching XML Web Services for Mobility,” Queue, vol. 1, no. 3, pp. 70–78, mai 2003. [91] H. Artail and H. Al-Asadi, “A Cooperative and Adaptive System for Caching Web Service Responses in MANETs,” in International Conference on Web Services, 2006. ICWS ’06, 2006, pp. 339 –346. [92] J. Huang, X. Liu, Q. Zhao, J. Ma, and G. Huang, “A browser-based framework for data cache in Web-delivered service composition,” in 2010 IEEE International Conference on Service-117 Oriented Computing and Applications (SOCA), 2010, pp. 1–8. [93] Qi Zhao, Gang Huang, Jiyu Huang, Xuanzhe Liu, and Hong Mei, “A Web-Based Mashup Environment for On-the-Fly Service Composition,” in Service-Oriented System Engineering, 2008. SOSE ’08. IEEE International Symposium on, 2008, pp. 32–37. [94] P. Grogono and P. Santas, “Equality in Object Oriented Languages,” presented at the EastEurOOPe’93, 1993. [95] P. Grogono and M. Sakkinen, “Copying and Comparing: Problems and Solutions,” in ECOOP 2000 — Object-Oriented Programming, E. Bertino, Ed. Springer Berlin Heidelberg, 2000, pp. 226–250. [96] T. H. Cormen, C. E. Leiserson, R. L. Rivest, and C. Stein, Introduction To Algorithms, 3rd Edition, 3rd Revised ed. Cambridge, Massachusetts - London, England: The MIT Press, 2009. [97] V. Estivill-Castro and D. Wood, “A survey of adaptive sorting algorithms,” ACM Comput. Surv., vol. 24, no. 4, pp. 441–476, décembre 1992. [98] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. USA: Addison-Wesley, 1994. [99] J. Espinosa-Oviedo, “Coordination fiable de services de données à base de politiques actives,” de Grenoble, 2013. [100] M. Barhamgi, D. Benslimane, C. Ghedira, A. N. Benharkat, and A. L. Gancarski, “PPPDM - a privacy-preserving platform for data mashup,” International Journal of Grid and Utility Computing, vol. 3, no. 2/3, p. 175, 2012. [101] R. Hasan, M. Winslett, R. Conlan, B. Slesinsky, and N. Ramani, “Please Permit Me: Stateless Delegated Authorization in Mashups,” in Computer Security Applications Conference, 2008. ACSAC 2008. Annual, 2008, pp. 182, 173. [102] C. Cappiello, F. Daniel, and M. Matera, “A Quality Model for Mashup Components,” in Web Engineering, 2009, pp. 236–250. [103] A. Koschmider, V. Hoyer, and A. Giessmann, “Quality metrics for mashups,” in Proceedings of the 2010 Annual Research Conference of the South African Institute of Computer Scientists and Information Technologists, New York, NY, USA, 2010, pp. 376–380. [104] A. Portilla, V. Hernandez-Baruch, G. Vargas-Solar, J.-L. Zechinelli-Martini, and C. Collet, “Building reliable services based mashups,” presented at the IV Jornadas CienfificoTécnicas en Servicios WEB y SOA (JSWEB 2008), Sevilla, Spain, 2008. [105] C. Calero, J. Ruiz, and M. Piattini, “A Web Metrics Survey Using WQM,” in Web Engineering, vol. 3140, N. Koch, P. Fraternali, and M. Wirsing, Eds. Springer Berlin / Heidelberg, 2004, pp. 766–766. [106] M. Matera, F. Rizzo, and G. Carughi, “Web Usability: Principles and Evaluation Methods,” in Web Engineering, E. Mendes and N. Mosley, Eds. Springer Berlin Heidelberg, 2006, pp. 143–180. [107] S. Amdouni, D. Benslimane, M. Barhamgi, A. Hadjali, R. Faiz, and P. Ghodous, “A Preference-aware Query Model for Data Web Services,” in Proceedings of the 31st International Conference on Conceptual Modeling, Berlin, Heidelberg, 2012, pp. 409–422.118 [108] O. Beletski, “End User Mashup Programming Environments,” in T-111.5550 Seminar on Multimedia, 2008. [109] “Microsoft Research FUSE Labs - Project Montage.” [Online]. Available: http://fuse.microsoft.com/page/montage. [Accessed: 27-Jun-2012]. [110] R. Ennals, E. Brewer, M. Garofalakis, M. Shadle, and P. Gandhi, “Intel Mash Maker: join the web,” SIGMOD Rec., vol. 36, no. 4, pp. 27–33, 2007. [111] D. E. Simmen, M. Altinel, V. Markl, S. Padmanabhan, and A. Singh, “Damia: data mashups for intranet applications,” in Proceedings of the 2008 ACM SIGMOD international conference on Management of data - SIGMOD ’08, Vancouver, Canada, 2008, p. 1171.119 ANNEXE$A : SYSTEMES D’EXECUTION)DE)MASHUPS ETUDIES Pendant ces dernières années, plusieurs environnements de création de mashups ont vu le jour. Chacun de ces environnements offre un ensemble de fonctionnalités et caractéristiques qui répondent à des besoins spécifiques d’un certain public. Ainsi, certains environnements sont dédiés aux constructeurs novices, alors que d’autres s’adressent aux développeurs. Dans cette section, nous présentons une sélection d’environnements de création et d’exécution de mashups. Pour des études poussées sur ces outils, le lecteur peut se référer à [35][11][108]. Montage Montage [109] est un outil de création de mashups développé par Microsoft. Il permet aux utilisateurs novices de créer des pages web personnalisées, qui peuvent afficher des données provenant de différentes sources, comme le montre la Figure 6752: vidéos, flux RSS, images, tweets … Figure'67 :'Sources'de'données'dans'Montage Le contenu est disposé sur la page sous la forme d’une grille. Celle-ci peut être décomposée horizontalement et verticalement. Chaque rectangle de la grille représente un mashlet et affiche les données choisies par l’utilisateur. Il n’y a aucune communication entre les mashlets. 52 La figure est scindée en deux, pour une raison d’espace.120 Yahoo!)Pipes Yahoo! Pipes [10] permet aux utilisateurs d’agréger des données provenant de différents sources comme des flux ou des pages web via un éditeur graphique, comme le montre la Figure 68. Figure'68 :'Construction'de'mashlets'dans'Yahoo!'Pipes Il est principalement destiné aux utilisateurs ayant quelques notions de programmation. En effet, les mashups sont créés via un mécanisme de glisser-déposer. Un « Pipe » est un ensemble de modules connectés. Un module correspond à un opérateur qui exécute une tâche spécifique. L'ensemble des opérateurs disponibles comprend les opérateurs de transformation de données (tri, filtrage ...), les opérateurs de contrôle (boucle), les opérateurs arithmétiques (comptage…) et les opérateurs sur les expressions régulières. Intel)MashMaker MashMaker [110][16][29] est un outil de construction de mashups proposé par Intel en version bêta, mis hors service en 2011. Il est fourni sous la forme d’une extension pour les navigateurs Firefox et Internet Explorer. L’outil offre des fonctionnalités qui permettent de personnaliser des pages web en ajoutant des informations supplémentaires et des widgets. L’utilisateur peut définir des extracteurs (scrapers) pour extraire des données des pages web. Les données extraites sont organisées sous la forme d’une structure arborescente qui peut être lue et enrichie par d’autres widgets. Les mashups sont construits par un mécanisme de copier-coller de widgets (qui affichent des données extraites d’autres sites) et par l’ajout de widgets qui exécutent des requêtes de transformations de données.121 WSO2)Mashup)Server WSO2 Mashup Server [32] est une plateforme open source qui est dédiée aux développeurs. Elle offre un environnement pour créer, déployer et exécuter les mashups. La plateforme est basée sur les technologies XML et JavaScript. Elle permet d’agréger des données issues de différentes sources comme les pages web, les services web, les flux ou les bases de données. Le résultat peut être exposé sous la forme d’un flux, d’un service web, d’une page web, ou d’un widget à ajouter dans iGoogle. Damia Damia [38][111] est un outil de construction de mashups proposé par IBM. Il permet d’agréger des données issues de différentes sources comme Notes, Excel, des pages web, … Les données sont agrégées par le moyen d’opérateurs comme l’union, le tri, le filtrage. La création du mashup se fait au sein d’un navigateur. Comme dans Yahoo! Pipes, le constructeur glisse les sources et les opérateurs et les branches via des connecteurs. Presto)Enterprise)Mashups Presto Enterprise Mashups [40] est une plateforme de création de mashups proposée par JackBe Corporation. La plateforme est dédiée à la création de mashups d’entreprises. Elle permet d’agréger des données issues de sources internes et d’autres issues de sources externes. La plateforme fournit également des outils pour définir les échanges entre mashlets ainsi que l’interface graphique du mashup et des mashlets. L’agrégation de données peut se faire soit d’une manière graphique, soit par programmation. Dans le premier cas, la construction est similaire à celle de Yahoo! Pipes, et se fait dans un navigateur web. Dans le second cas, le développeur est amené à écrire son code en langage EMML, via une extension Eclipse : Presto Mashup Studio. La plateforme fournit également des extensions qui permettent d’importer des données et/ou d’exporter les mashlets vers d’autres plateformes comme : • Microsoft SharePoint • Des produits Oracles. • Des terminaux mobiles • Des portails • Des fichiers Excel Mashup)Service)System Mashup Service System MSS [31] est une plateforme conçue pour les utilisateurs novices, qui leur permet de construire des mashups personnalisés qui répondent à des besoins spécifiques. Comme illustré dans la Figure 69, les données sont accessibles via des services. Ces services sont décrits selon un certain modèle sémantique de services (basé sur une certaine ontologie définie par « une communauté »), qui permet d’avoir un raisonnement automatique sur les services. L'utilisateur est invité à exprimer ses besoins, qui sont traduits en requêtes MSQL (Mashup Service Query Language, langage de type SQL). MSS recherche alors, automatiquement, les services 122 appropriés et crée le mashup en composant automatiquement les services. Le mashup est exécuté et le résultat est retourné à l’utilisateur comme réponse à sa requête. Dans [107], les auteurs proposent une approche similaire. Elle est basée également sur une description sémantique des services web et de l’expression des besoins de l’utilisateur. Ils permettent de surcroit, à l’utilisateur d’exprimer des préférences dans sa requête. Celles ci sont prises en considération lors du calcul et du tri du résultat. Figure'69 :'Architecture'de'MSS 123 ANNEXE$B : SYNTAXE'DE'JSON La syntaxe de JSON est présentée dans la Figure 7053. JSON se base sur deux structures : les objets (une collection de paires nom : valeur) et les tableaux (une liste de valeurs ordonnées). Pratiquement tous les langages de programmation proposent ces structures de données sous une forme ou une autre. Les valeurs peuvent être atomiques de type chaine de caractère, nombre, booléen ou des objets ou des tableaux. Figure'70 :'Syntaxe'de'JSON 53 Images obtenues de http://www.json.org/json-fr.html124 Un objet JSON est représenté par un ensemble de paires nom : valeurs séparées par des virgules entre deux accolades. Par exemple une valeur de l’entrée du mashlet Map du mashup ItineraryPlanner peut être représentée par un l’objet JSON entreeMashup suivant : entreeMashup = {“depart” : “Grenoble”, “destination” : “Paris”, “note” : 4} Un tableau JSON est une liste de valeurs ordonnées séparées par des virgules et délimitées par deux crochets. Par exemple, la liste de valeurs de villes intermédiaires entre Grenoble et Paris sous format WOEID54 peut être représentée par le tableau JSON listeVilles suivant : listeVilles = [{"woeid":12724717}, {"woeid":12724728}, {"woeid":12724752}, {"woeid":12726960}, {"woeid":582081}, {"woeid":12726917}, {"woeid":12726920},{"woeid":12726958}, {"woeid":12723642}, {"woeid":12728226}, {"woeid":12728378}, {"woeid":12728381}, {"woeid":20068149}, {"woeid":20068148}, {"woeid":20068141}] Un document JSON est un objet JSON. Il peut être constitué d’imbrications d’un nombre non limité d’objets et tableaux [27]. L’itinéraire entre Grenoble et Paris est décrit par le document JSON routeGP dont une partie est donnée ci dessous. {"routes" : [ { "bounds" : { "northeast" : { "lat" : 48.857240, "lng" : 5.724690000000001 }, "southwest" : { "lat" : 45.18839000000001, "lng" : 2.306130 } }, "copyrights" : "Données cartographiques ©2012 GeoBasis-DE/BKG (©2009), Google", "legs" : [ { "distance" : { "text" : "574 km", "value" : 573623 }, "duration" : { "text" : "5 heures 21 minutes", "value" : 19284 }, "end_address" : "Paris, France", "end_location" : { "lat" : 48.857240, "lng" : 2.35260 }, "start_address" : "Grenoble, France", "start_location" : { "lat" : 45.18839000000001, "lng" : 5.724690000000001 }, 54 Un identifiant WOEID (Where on Earth IDentifier) est un identifiant de référence assigné par Yahoo! Pour identifier des points géographiques sur la terre. 125 "steps" : [ { "distance" : { "text" : "92 m", "value" : 92 }, "duration" : { "text" : "1 minute", "value" : 7 }, "end_location" : { "lat" : 45.188890, "lng" : 5.725610000000001 }, "html_instructions" : "Prendre la direction \u003cb\u003enord-est\u003c/b\u003e sur \u003cb\u003ePl. Victor Hugo\u003c/b\u003e vers \u003cb\u003eRue Paul Bert\u003c/b\u003e", "polyline" : { "points" : "mzxrGib}a@g@gA{@oB" }, "start_location" : { "lat" : 45.18839000000001, "lng" : 5.724690000000001 }, "travel_mode" : "DRIVING" …… } ], "status" : "OK" } L’accès à une valeur dans un tableau se fait classiquement par une notation indexée. Par exemple listeVilles[1] ={"woeid":12724717}. Tandis que l’accès à une valeur d’une paire d’un objet JSON se fait en indiquant le nom de la paire. Par exemple entreeMashup.depart = “Grenoble”. En combinant ces 2 notations, on peut spécifier des chemins d’accès à des valeurs à l’intérieur d’un document JSON. Par exemple, le chemin d’accès suivant : routeGP.routes[0].legs[0].steps[0].start_location permet d’accéder à la donnée qui représente les coordonnées géographiques du point de départ de la première étape de l’itinéraire. {"lat" : 45.18839000000001,"lng" : 5.724690000000001}. 127 128 Cette thèse présente MELQART, un système d’exécution de mashups avec disponibilité de données. Un mashup est une application web qui combine des données provenant de fournisseurs hétérogènes (web services). Ces données sont agrégées pour former un résultat homogène affiché dans des composants appelés mashlets. Les travaux dans le domaine des mashups, se sont principalement intéressés au fonctionnement des mashups, aux différents outils de construction et à leur utilisation et interaction avec les utilisateurs. Dans cette thèse, nous nous intéressons à la gestion de données dans les mashups et plus particulièrement à la disponibilité et la fraîcheur de ces données. L’amélioration de la disponibilité tient compte du caractère dynamique des données des mashups. Elle garantit (1) l’accès aux données même si le fournisseur est indisponible, (2) la fraicheur de ces données et (3) un partage de données entre les mashups afin d’augmenter la disponibilité de données. Pour cela nous avons défini un modèle de description de mashups permettant de spécifier les caractéristiques de la disponibilité des données. Le principe d’exécution de mashups est défini selon ce modèle en proposant d’améliorer la disponibilité et la fraicheur des données du mashup par des fonctionnalités orthogonales à son processus d’exécution. Le système MELQART implante ce principe et permet de valider notre approche à travers l’exécution de plusieurs instances de mashups dans des conditions aléatoires de rupture de communication avec les fournisseurs de données. Mots clés : Mashups, Web 2.0, services web, disponibilité de données, fraicheur de données --------------------------------------------------------------------------------------------------------------------------- This thesis presents MELQART: a mashup execution system that ensures data availability. A mashup is a Web application that application that combines data from heterogeneous provides (Web services). Data are aggregated for building a homogenous result visualized by components named mashlets. Previous works have mainly focused, on the definition of mashups and associated tools and on their use and interaction with users. In this thesis, we focus on mashups data management, and more specifically on fresh mashups data availability. Improving the data availability take into account the dynamic aspect of mashups data. It ensures (1) the access to the required data even if the provider is unavailable, (2) the freshness of these data and (3) the data sharing between mashups in order to avoid the multiple retrieval of the same data. For this purpose, we have defined a mashup description formal model, which allows the specification of data availability features. The mashups execution schema is defined according to this model with functionalities that improve availability and freshness of mashed-up data. These functionalities are orthogonal to the mashup execution process. The MELQART system implements our contribution and validates it by executing mashups instances with unpredictable situations of broken communications with data providers. Keywords : mashups, Web 2.0, web services, data availability, data freshness Mesure de la fragilit´e et d´etection de chutes pour le maintien `a domicile des personnes ˆag´ees Amandine Dubois To cite this version: Amandine Dubois. Mesure de la fragilit´e et d´etection de chutes pour le maintien `a domicile des personnes ˆag´ees. Artificial Intelligence. Universit´e de Lorraine, 2014. French. HAL Id: tel-01070972 https://tel.archives-ouvertes.fr/tel-01070972 Submitted on 2 Oct 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.D´epartement de formation doctorale en informatique Ecole doctorale IAEM Lorraine ´ Sciences et T´echnologies Mesure de la fragilit´e et d´etection de chutes pour le maintien `a domicile des personnes ˆag´ees THESE ` pr´esent´ee et soutenue publiquement le 15 septembre 2014 pour l’obtention du Doctorat de l’Universit´e de Lorraine (mention informatique) par Amandine Dubois Composition du jury Pr´esident : Jean Paysant Professeur `a la Facult´e de M´edecine de Nancy Rapporteurs : Philippe Lalanda Professeur `a l’Universit´e Joseph Fourier de Grenoble Jean-Louis Vercher Directeur de Recherche au CNRS `a Marseille Examinateurs : Jacques Demongeot Professeur `a l’Universit´e Joseph Fourier de Grenoble Jacques Duchˆene Professeur `a l’Universit´e de Technologie de Troyes Michel Vacher Ing´enieur de recherche au CNRS de Grenoble Directeur de th`ese : Fran¸cois Charpillet Directeur de recherche INRIA Laboratoire Lorrain de Recherche en Informatique et ses Applications — UMR 7503Mis en page avec la classe thesul.Remerciements Je tiens à remercier tout d’abord François Charpillet de m’avoir donné l’opportunité de faire une thèse en Informatique et de m’avoir accordé sa confiance. Je remercie également les membres de mon jury : monsieur Jean Paysant pour avoir présidé ce jury, messieurs Philippe Lalanda et Jean-Louis Vercher de m’avoir fait l’honneur de rapporter ce travail de thèse et messieurs Jacques Demongeot, Jacques Duchêne et Michel Vacher pour leurs remarques et leurs questions constructives. Merci également à Abdallah, Manel, Marion, Olivier et à tous ceux que j’ai pu côtoyer pendant ces trois ans, collègues de bureau, de couloir, de bâtiment, pour les discussions, leurs suggestions et surtout pour leur bonne humeur. Je remercie mes parents et mon frère qui m’ont toujours soutenue et encouragée et sans lesquels je ne serais pas parvenue à accomplir ce travail de thèse. Je remercie mes grands-parents pour avoir été les premiers « cobayes » et surtout pour m’avoir donné l’envie de travailler sur ce sujet. Je te remercie Cédric pour ton soutien permanent. iiiSommaire Table des figures xi Liste des tableaux xv Introduction 1 1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3 Approche proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Partie I Approches pour la mesure de la fragilité et la détection des chutes 9 Introduction 11 Chapitre 1 Panorama des approches pour l’analyse de la fragilité à l’hôpital 1.1 L’œil expert à travers les tests cliniques . . . . . . . . . . . . . . . . . . . . . 13 1.2 Outils d’analyse du mouvement . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.2.1 Systèmes avec capteurs embarqués sur la personne . . . . . . . . . . . 14 1.2.2 Systèmes sans capteur embarqué sur la personne . . . . . . . . . . . . 16 1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Chapitre 2 Panorama des systèmes de détection de chutes au domicile 2.1 Systèmes avec capteurs embarqués sur la personne . . . . . . . . . . . . . . . 19 iiiSommaire 2.1.1 Détecteurs de chutes automatiques . . . . . . . . . . . . . . . . . . . . 19 2.1.2 Systèmes d’alerte manuels . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2 Systèmes ambiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.1 Capteurs environnementaux : la télé-assistance . . . . . . . . . . . . . 21 2.2.2 Systèmes à base de caméra : la vidéo-vigilance . . . . . . . . . . . . . 22 2.2.3 Capteurs au sol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Conclusion 25 Partie II Algorithmes pour l’évaluation et la sécurisation au domicile 27 Introduction 29 Chapitre 3 Détecter et suivre une personne avec une caméra : état de l’art 3.1 Détection de la personne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 3.1.1 Détecteur de points d’intérêt . . . . . . . . . . . . . . . . . . . . . . . 34 3.1.2 Soustraction du fond . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.1.3 Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.1.4 Apprentissage supervisé . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2 Suivi de la personne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.1 Modèles d’objets animés . . . . . . . . . . . . . . . . . . . . . . . . . 35 Différentes représentations . . . . . . . . . . . . . . . . . . . . . . . . 35 Caractéristiques pour obtenir la représentation . . . . . . . . . . . . . 37 3.2.2 Suivi de l’objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Objet représenté par des points . . . . . . . . . . . . . . . . . . . . . . 38 Objet représenté par des formes géométriques . . . . . . . . . . . . . . 39 Objet représenté par sa silhouette . . . . . . . . . . . . . . . . . . . . 39 3.3 Caméra de profondeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Chapitre 4 Application à la détection et au suivi de personnes avec une caméra RGB-D 4.1 Détecter la personne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 iv4.1.1 Extraction et apprentissage du fond . . . . . . . . . . . . . . . . . . . 44 4.1.2 Extraction du sol et changement de repère . . . . . . . . . . . . . . . 44 Etape 1 : Redressement de la scène . . . . . . . . . . . . . . . . . . . 44 Etape 2 : Sélection des points bas . . . . . . . . . . . . . . . . . . . . 45 Etape 3 : Calcul de l’équation du sol . . . . . . . . . . . . . . . . . . . 45 Etape 4 : Construction du repère sol . . . . . . . . . . . . . . . . . . . 46 Projection d’un point dans le repère sol . . . . . . . . . . . . . . . . . 46 4.1.3 Extraction des points mobiles . . . . . . . . . . . . . . . . . . . . . . . 46 4.1.4 Extraction des objets mobiles . . . . . . . . . . . . . . . . . . . . . . . 47 4.1.5 Détection de la personne . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2 Suivre la personne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2.1 Représentation de la personne . . . . . . . . . . . . . . . . . . . . . . 49 4.2.2 Suivi du centre de masse . . . . . . . . . . . . . . . . . . . . . . . . . 51 Calcul du centre de masse . . . . . . . . . . . . . . . . . . . . . . . . . 51 Description de la trajectoire du centre de masse . . . . . . . . . . . . 51 Lissage de la trajectoire du centre de masse . . . . . . . . . . . . . . 52 Paramètres dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . 53 4.2.3 Suivi de la distribution verticale . . . . . . . . . . . . . . . . . . . . . 53 4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Chapitre 5 Mesurer à domicile les paramètres de la marche 5.1 Définition et description de la marche . . . . . . . . . . . . . . . . . . . . . . 58 5.1.1 Définition de la marche . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.1.2 Description du cycle de la marche . . . . . . . . . . . . . . . . . . . . 58 Phase d’appui . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Phase d’oscillation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 5.2 Indicateurs de l’analyse de la marche . . . . . . . . . . . . . . . . . . . . . . . 59 5.2.1 Paramètres spatio-temporels . . . . . . . . . . . . . . . . . . . . . . . 59 Principaux paramètres spatiaux . . . . . . . . . . . . . . . . . . . . . 59 Principaux paramètres temporels . . . . . . . . . . . . . . . . . . . . . 60 5.2.2 Paramètres cinématiques . . . . . . . . . . . . . . . . . . . . . . . . . 60 5.2.3 Paramètres dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Les forces de réaction du sol . . . . . . . . . . . . . . . . . . . . . . . 61 Pressions plantaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3 Sélection des indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.1 Troubles de la marche et risques de chute . . . . . . . . . . . . . . . . 64 vSommaire 5.3.2 Troubles de la marche et risques d’hospitalisation . . . . . . . . . . . 64 5.3.3 Troubles de la marche et troubles cognitifs . . . . . . . . . . . . . . . 64 5.4 Extraction des indicateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.4.1 Longueurs de pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.4.2 Cadence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.4.3 Vitesse de marche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.4.4 Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Chapitre 6 Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur 6.1 Approches pour détecter l’activité . . . . . . . . . . . . . . . . . . . . . . . . 70 6.1.1 Approches non paramétriques . . . . . . . . . . . . . . . . . . . . . . 70 6.1.2 Approches volumétriques . . . . . . . . . . . . . . . . . . . . . . . . . 70 6.1.3 Approches paramétriques . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.2 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.3 Proposition d’un modèle de l’activité . . . . . . . . . . . . . . . . . . . . . . . 73 6.3.1 Modèle avec fonction d’observation seule . . . . . . . . . . . . . . . . 74 Inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.3.2 Utilisation d’un MMC unique . . . . . . . . . . . . . . . . . . . . . . . 75 MMC à 8 états et 3 observations . . . . . . . . . . . . . . . . . . . . . 75 MMC à 9 états et 5 observations . . . . . . . . . . . . . . . . . . . . . 76 Inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.3.3 Utilisation de MMC combinés . . . . . . . . . . . . . . . . . . . . . . 79 Système de 8 MMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Système de 9 MMC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 Inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Conclusion 83 Partie III Evaluation du système 85 Introduction 87 viChapitre 7 Expérimentations pour l’analyse de la marche 7.1 Première évaluation du système . . . . . . . . . . . . . . . . . . . . . . . . . 89 7.1.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . . 89 7.1.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Angle de la caméra . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 Choix du filtre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.2 Évaluation globale du système . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.2.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . . 94 7.2.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Résultats basés sur l’erreur de chaque séquence . . . . . . . . . . . . . 96 Résultats basés sur la moyenne de chaque paramètre de la marche . . 96 7.3 Discussion et conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Chapitre 8 Expérimentations pour la reconnaissance d’activité 8.1 Cas de la personne entièrement visible . . . . . . . . . . . . . . . . . . . . . . 99 8.1.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . . 99 Protocole expérimental . . . . . . . . . . . . . . . . . . . . . . . . . . 99 Base d’apprentissage et base de test . . . . . . . . . . . . . . . . . . . 100 8.1.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Représentation des bonnes classifications et des fausses détections . . 102 Comparaison entre les algorithmes Forward-Backward et de Viterbi . 103 Modèle avec fonction d’observation seule . . . . . . . . . . . . . . . . 105 MMC à 8 états et 3 observations . . . . . . . . . . . . . . . . . . . . . 105 MMC à 9 états et 5 observations . . . . . . . . . . . . . . . . . . . . . 107 Système de 8 MMC à 2 états et 3 observations . . . . . . . . . . . . . 107 Système de 8 MMC à 3 états et 3 observations . . . . . . . . . . . . . 107 Système de 9 MMC à 2 états et 5 observations . . . . . . . . . . . . . 107 Système de 9 MMC à 3 états et 5 observations . . . . . . . . . . . . . 108 Résultats pour l’activité debout . . . . . . . . . . . . . . . . . . . . . 108 8.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 8.2 Cas de la personne partiellement visible . . . . . . . . . . . . . . . . . . . . . 109 8.2.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . . 109 8.2.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 8.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 viiSommaire Chapitre 9 Tests en situations réelles 9.1 Test de l’algorithme d’analyse de la marche . . . . . . . . . . . . . . . . . . . 115 9.2 Test de l’algorithme de détection d’activité . . . . . . . . . . . . . . . . . . . 116 9.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Conclusion 121 Partie IV Système pour le maintien à domicile 123 Introduction 125 Chapitre 10 Vers une implantation au domicile 10.1 Couplage des fonctionnalités actuelles du système . . . . . . . . . . . . . . . 127 10.2 Cartographie des habitudes dans l’environnement . . . . . . . . . . . . . . . . 129 10.2.1 Limitations du système et contraintes de l’environnement . . . . . . . 129 10.2.2 Détection des cas d’occlusions partielles de la personne . . . . . . . . 130 10.2.3 Cartographie des habitudes . . . . . . . . . . . . . . . . . . . . . . . . 133 10.2.4 Détection des anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . 134 10.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Chapitre 11 Autres perspectives d’utilisation du système 11.1 Différenciation des personnes . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 11.2 Couplage de plusieurs capteurs . . . . . . . . . . . . . . . . . . . . . . . . . . 138 11.3 Observance des patients . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 11.4 Prévention de certains troubles . . . . . . . . . . . . . . . . . . . . . . . . . . 139 11.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Conclusion 141 viiiConclusion générale et perspectives 143 Annexe 149 Annexe A Modèle de Markov caché 149 A.1 Définition des modèles de Markov cachés . . . . . . . . . . . . . . . . . . . . 149 A.1.1 Processus de Markov . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 A.1.2 Modèle de Markov caché . . . . . . . . . . . . . . . . . . . . . . . . . 150 A.2 Algorithmes d’apprentissage et d’inférence . . . . . . . . . . . . . . . . . . . . 150 A.2.1 Inférence pour le cas du MMC unique . . . . . . . . . . . . . . . . . . 150 Algorithme Forward-Backward . . . . . . . . . . . . . . . . . . . . . . 150 Algorithme de Viterbi . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 A.2.2 Apprentissage et inférence pour les systèmes de plusieurs MMC . . . . 155 Apprentissage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Inférence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156 Publications 157 Références 159 ixSommaire xTable des figures 1 Pyramide des âges en 2007 et 2060 selon une étude INSEE de 2010. . . . . . . . . 3 1.1 Représentation de la marche humaine en diagramme bâton par Marey. . . . . . . 14 1.2 Le système Walkmeterc est inspiré du locomètre de Bessou. . . . . . . . . . . . 15 1.3 Le tapis roulant instrumenté de la société Biometrics. . . . . . . . . . . . . . . . . 17 1.4 Le tapis actimètrique de la marque GaitRite. . . . . . . . . . . . . . . . . . . . . 17 2.1 Système d’alerte de Vitalbase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.2 Système de détection de chute de la société Vigilio. . . . . . . . . . . . . . . . . . 20 2.3 Système d’analyse du mouvement par le sol d’INRIA à Nancy. . . . . . . . . . . . 23 3 Vision pour la conception d’un système permettant le maintien à domicile des personnes âgées. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.1 Détection des points d’intérêts dans une scène. . . . . . . . . . . . . . . . . . . . 34 3.2 Différentes représentations de l’objet à suivre : (a) silhouette, (b) contour, (c) points, (d) centre géométrique, (e) ellipse, (f) rectangle, (g) plusieurs ellipses et (h) squelette. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 3.3 Détection des contours dans une scène. . . . . . . . . . . . . . . . . . . . . . . . . 37 3.4 Différentes hypothèses utilisées pour le suivi d’un objet : (a) proximité, (b) vitesse maximale, (c) mouvement similaire, (d) constance de la vitesse et de la direction, (e) rigidité de l’objet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 3.5 Transformation paramétrique d’une ellipse. . . . . . . . . . . . . . . . . . . . . . 39 3.6 Modèle d’apparence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.7 Le capteur Kinect de Microsoft. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 4.1 Étapes pour détecter la personne du fond et la suivre dans le temps. . . . . . . . 44 4.2 L’extraction du sol est représentée en rouge. . . . . . . . . . . . . . . . . . . . . 47 4.3 a) Les cases bleues représentent des points mobiles et les cases vertes les points appartenant au fond, b) le filtre érosion est appliqué, c) le filtre dilatation est appliqué. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.4 a) Les cases colorées représentent des points mobiles, b) l’algorithme assigne un nombre aux points mobiles, c) les points avec un nombre plus grand que ses voisins sont modifiés, d) le résultat final est atteint. . . . . . . . . . . . . . . . . . . . . 48 4.5 Déplacement horizontal théorique du centre de masse. . . . . . . . . . . . . . . . 50 4.6 Déplacement vertical théorique du centre de masse. . . . . . . . . . . . . . . . . 50 xiTable des figures 4.7 Déplacement du centre de masse extrait à partir de notre algorithme pour une personne marchant en ligne droite perpendiculairement à la caméra. La montée et la descente en début et fin de trajectoire correspondent aux entrées et sorties de la personne dans le champ de vision de la caméra. . . . . . . . . . . . . . . . . . . 51 4.8 Comparaison entre la trajectoire du centre de masse et le nombre de pixels mobiles appartenant à une personne. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 4.9 a) Courbe non lissée, b) courbe lissée avec le filtre passe-bas, c) courbe lissée avec le filtre de Kalman. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 4.10 Trajectoire de l’écart type vertical pour une personne qui marche. . . . . . . . . 54 4.11 Comparaison entre la trajectoire du point maximum filtrée et non filtrée pour une personne qui marche. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.1 Représentation du cycle de la marche selon Viel (2000). . . . . . . . . . . . . . . 58 5.2 Représentation des paramètres spatiaux. . . . . . . . . . . . . . . . . . . . . . . . 60 5.3 Représentation des paramètres cinématiques. . . . . . . . . . . . . . . . . . . . . 61 5.4 Représentation des forces exercées lorsqu’une personne marche. . . . . . . . . . . 62 5.5 Force de réaction du sol selon l’axe vertical (bleu), antéro-postérieur (vert) et média-latéral (rouge) lors d’un cycle de marche selon Kirtley. . . . . . . . . . . . 63 5.6 Trajectoire des pressions plantaires lors de la marche. . . . . . . . . . . . . . . . . 63 5.7 Correspondance entre le cycle de la marche et la trajectoire du centre de masse sur l’axe vertical. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.8 Extraction des paramètres de la marche à partir du centre de masse. . . . . . . . 67 6.1 Positionnement du problème de la reconnaissance d’activité au domicile. . . . . . 71 6.2 Représentation graphique d’une chaine de Markov cachée, avec Xt le processus Markovien caché et Ot la séquence d’observations correspondantes. . . . . . . . . 73 6.3 Modèle à 8 états avec fonction d’observation seule. . . . . . . . . . . . . . . . . . 75 6.4 MMC à 8 états avec des transitions définies manuellement. . . . . . . . . . . . . . 77 6.5 MMC à 9 états avec des transitions définies manuellement. . . . . . . . . . . . . . 78 6.6 Système de 8 MMC à deux états chacun. . . . . . . . . . . . . . . . . . . . . . . 80 6.7 Système de 9 MMC à deux états chacun. . . . . . . . . . . . . . . . . . . . . . . 81 7.1 Méthode utilisée comme référence pour mesurer les longueurs de pas. . . . . . . . 90 7.2 Positionnement des caméras : la plus basse avec un angle de 0˚ et la plus haute avec un angle de -27˚. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 7.3 Représentation des erreurs sur les longueurs de pas obtenues à partir d’une caméra avec un angle de -27˚ et avec un angle de 0˚. . . . . . . . . . . . . . . . . . . . . 92 7.4 Représentation des erreurs sur les longueurs de pas extraites à partir du filtre de Kalman et du filtre passe-bas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.5 Expérience comprenant un tapis actimètrique. . . . . . . . . . . . . . . . . . . . 95 7.6 En phase de double appui, de nombreux points mobiles sont détectés dans la partie basse de la silhouette quand le sujet porte une jupe. . . . . . . . . . . . . . . . . 98 7.7 Comparaison des oscillations de la trajectoire du centre de masse. . . . . . . . . . 98 8.1 Plan de l’appartement expérimental avec le positionnement de la caméra. . . . . 100 8.2 Suivi des situations, effectuées par un sujet, à différents pas de temps. . . . . . . 101 8.3 Différence dans l’analyse faite par les algorithmes Forward-Backward et de Viterbi, pour une séquence où la personne s’assoit puis monte sur une chaise. . . . . . . . 104 8.4 Comparaison d’une séquence où la personne s’assoit analysée par deux modèles. . 105 xii8.5 Sujet s’allongeant différemment de ce qui a été appris dans la base de donnée. . 106 8.6 Sujet s’asseyant différemment de ce qui a été appris dans la base de donnée. . . . 106 8.7 Suivi des situations où le sujet n’est pas entièrement visible à différents pas de temps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 8.8 Résultat de l’analyse avec le modèle à 9 états et 5 observations, pour une personne réalisant des demi-tours. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 9.1 Utilisation de notre système avec une patiente, lors de sa consultation à l’hôpital. 116 9.2 Représentation du centre de masse, sur l’axe vertical, de quatre personnes âgées. 117 9.3 Détection de l’activité « Marche », pour une personne de 81 ans marchant à son domicile. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 9.4 Représentation du centre de masse, sur l’axe vertical, pour différentes activités réalisées par une personne âgée de 81 ans. . . . . . . . . . . . . . . . . . . . . . . 118 10.1 Les différentes actions réalisées par l’algorithme selon l’état dans lequel se trouve la personne d’après le MMC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 10.2 Personne sortant du champ de vision et étant à moitié détectée. . . . . . . . . . 129 10.3 Courbes des vraisemblances pour différentes activités réalisées par un sujet entiè- rement et partiellement visible. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 10.4 Séquence dans laquelle le sujet réalise plusieurs activités. . . . . . . . . . . . . . . 133 10.5 Carte de l’environnement représentant les habitudes apprises d’une personne (en blanc : zones non explorées, en bleu : zones passives, en vert : zones actives et en rouge : zones se trouvant derrière un meuble). . . . . . . . . . . . . . . . . . . . 134 10.6 Carte de l’environnement sur laquelle est représentée la dernière position du centre de masse perçue par le système. . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 11.1 Proposition d’emplacement de plusieurs caméras permettant de couvrir tout un appartement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 11.2 Représentation du centre de masse, sur l’axe vertical, d’une personne de 90 ans ayant des problèmes d’équilibre . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 A.1 Exemple de modèle de Markov à deux états. . . . . . . . . . . . . . . . . . . . . . 149 A.2 Représentation graphique d’une chaine de Markov. . . . . . . . . . . . . . . . . . 150 A.3 Représentation graphique d’une chaine de Markov cachée, avec Xt le processus Markovien caché et Ot la séquence d’observations correspondantes. . . . . . . . . 150 A.4 Représentation du calcul αt+1(j = 1) par l’algorithme Forward pour un modèle à trois états. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 A.5 Représentation du calcul pour l’état βt(i = 1) par l’algorithme Backward pour un modèle à trois états. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153 A.6 Représentation du calcul δt(j = 1) et ψt(j = 1) par l’algorithme de Viterbi pour un modèle à trois états. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 A.7 Représentation du calcul de l’algorithme de Viterbi avec la rétro-propagation (en vert) pour quatre pas de temps successifs et trois états. . . . . . . . . . . . . . . . 154 xiiiTable des figures xivListe des tableaux 7.1 Comparaison des résultats, entre le tapis et la caméra, en fonction de l’angle de la caméra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 7.2 Précision des longueurs de pas fournies par l’algorithme, obtenues avec un filtre de Kalman et avec un filtre passe-bas (pour tous les pas, pour les pas « normaux » et pour les petits pas). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 7.3 Erreurs moyennes des longueurs (Long), cadences (Cad) et vitesses (Vit) pour chaque situation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 7.4 Comparaison des paramètres de la marche obtenus avec le tapis et avec notre algorithme utilisant la caméra. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 8.1 Classification des activités par l’algorithme selon le modèle utilisé. . . . . . . . . 103 8.2 Fausses détections effectuées par l’algorithme selon le modèle utilisé. . . . . . . . 104 8.3 Classification de l’activité « Debout » selon le modèle utilisé. . . . . . . . . . . . 108 8.4 Détection d’activité quand la personne n’est pas entièrement visible pour différents modèles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 xvListe des tableaux xviIntroduction 11. Contexte 1 Contexte L’un des sujets majeurs des prochaines années dans les pays développés sera le vieillissement de la population. En France, l’INSEE [Blanpain and Chardon, 2010] prévoit que le nombre de personnes de plus de 60 ans augmentera de 10,4 millions entre 2007 et 2060 pour atteindre le nombre de 23,6 millions de personnes en 2060, soit une hausse de 80 % en 53 ans. Le nombre de personnes de plus de 75 ans passera de 5,2 millions en 2007 à 11,9 millions en 2060. Quant aux personnes de plus de 85 ans, leur nombre passera de 1,3 à 5,4 millions. Ces chiffres sont représentés sur la pyramide des âges fournie par l’INSEE à la figure 1. Figure 1 – Pyramide des âges en 2007 et 2060 selon une étude INSEE de 2010. Une des conséquences de l’augmentation du vieillissement de la population est l’augmentation du nombre de personnes âgées dépendantes 1 . Selon l’INSEE en 2004, 1 200 000 personnes seraient dépendantes en 2040 contre 800 000 aujourd’hui. La problématique qui découle de ces chiffres est la prise en charge de ces personnes. En effet, le nombre d’instituts spécialisés ne devrait pas permettre de toutes les accueillir. Actuellement, les personnes ont tendance à rester au domicile. 92 % des plus de 75 ans vivent chez eux et 75 % pour les plus de 85 ans, soit pour des raisons liées au coût qu’implique un placement, ou soit parce que la personne elle-même préfère rester chez elle (80 % des personnes âgées souhaitent vivre le plus longtemps possible au domicile [Webe, 2006]). Le vieillissement de la population est donc un problème majeur et, partant de ce constat, cette thèse cherche à apporter une contribution au maintien à domicile des personnes âgées par des dispositifs technologiques. 1. La dépendance s’évalue en fonction de la capacité de la personne à accomplir les actes de la vie quotidienne. L’outil Aggir est une grille nationale évaluant le degré de dépendance chez les personnes âgées à partir des activités qu’elles peuvent effectuer seules comme s’habiller, se laver, etc. 32 Objectifs Notre objectif est de développer un dispositif simple et facile à installer, permettant de favoriser le maintien à domicile des personnes âgées. Il s’agit de proposer une démarche de prévention de l’aggravation de la fragilité de la personne et d’aider à la sécuriser chez elle. Pour savoir si la personne est en sécurité à son domicile, il est nécessaire de connaître son niveau d’autonomie, de savoir si la personne est fragile, si elle peut se débrouiller dans son logement (se faire à manger, se laver, etc.). Pour cela, l’idée est de développer un outil d’évaluation permettant de mesurer le risque initial et l’évolution du risque que prend la personne en restant chez elle. Ces mesures permettront alors de prendre des actions de prévention comme diriger la personne vers un médecin spécialisé, modifier son environnement pour le rendre plus sûr, adapter son traitement, etc. L’évaluation du degré d’autonomie peut se faire au quotidien en installant un système à domicile. Cette évaluation constitue une information supplémentaire à l’analyse faite par le médecin lors des consultations, car l’information recueillie au domicile constitue une mesure en milieu écologique forcément différente de l’évaluation qui peut être faite en milieu hospitalier. La sécurisation de la personne passe également par la mise en place de systèmes d’alerte, car maintenir les personnes âgées à domicile n’est pas sans risque. En effet, 61 % des accidents surviennent au domicile et 85 % de ces accidents sont dus aux chutes. La chute est la première cause de mortalité des plus de 65 ans provoquant chaque année 10 000 décès [Alexander et al., 1997]. Elle peut causer des blessures physiques comme des fractures (en particulier du col du fémur), des luxations, des plaies, etc. Les blessures physiques peuvent entraîner une hospitalisation prolongée, voire même le placement en institut (40 % des sujets âgés hospitalisés pour chute sont ensuite orientés vers une institution). Une cascade de complications psychologiques peut également survenir suite à la chute elle-même et/ou du fait d’être resté immobilisé au sol en état d’impuissance sans pouvoir se relever. En effet, près de 50 % des personnes ayant chuté ont besoin d’une aide pour se relever [Tinetti et al., 1993]. L’anxiété d’une deuxième chute peut entraîner chez les personnes une tendance à réduire leur mobilité et à minimiser leur activité [Gaxatte et al., 2011] (en limitant leur sortie et en restant plus souvent assise ou allongée). Cette inactivité provoque une perte d’autonomie. Des études ont montré que la perte d’autonomie pouvait directement être corrélée au temps passé au sol, 1h au sol provoque 10 % de perte d’autonomie, 3h, 30 %, 6h, 50 % et 12h, 70 %. La chute est un marqueur de fragilité et ses conséquences physiques et surtout psychologiques aggravent l’état de fragilité initiale de la personne. Cet engrenage est confirmé par des chiffres montrant que le nombre de récidives est très important : après une première chute le risque de retomber à nouveau est multiplié par vingt. Il est donc nécessaire, pour sécuriser la personne, d’être en mesure de détecter les chutes. Un tel détecteur pourrait permettre, d’une part, de limiter les conséquences physiques et psychologiques de la chute et, d’autre part, de mettre la personne en confiance pour ainsi ralentir les effets de l’inactivité (réduire l’effet engendré par le cercle vicieux). La détection précoce est cruciale, le fait d’obtenir une aide rapidement après une chute diminue le risque d’hospitalisation de 26 % et la mort de plus de 80 %. 3 Approche proposée 3.1 Problématique Dans ce travail de thèse, nous nous intéressons à développer un système couplant l’évaluation de la fragilité et la sécurisation de la personne à son domicile. Sécuriser la personne à son domicile implique de pouvoir détecter les éventuelles chutes, ou 43. Approche proposée comportements pouvant mener à une chute (comme monter sur une chaise), pour ainsi alerter des personnes extérieures et permettre d’agir au plus vite sur les conséquences physiques et psychologiques. La prise en charge rapide d’une personne ayant chuté limite l’aggravation de la perte d’autonomie. L’évaluation de la fragilité de la personne permet de mesurer sa capacité à être autonome à son domicile. Une personne est fragile, selon la définition de Fried et al. [Fried et al., 2001], si apparaît trois critères ou plus parmi les cinq suivants : une perte de poids involontaire, une faiblesse dans la force de préhension, une faible endurance, une vitesse de marche lente et une faible activité physique. La vitesse de marche diminuée et la faible activité sont les deux critères auxquels nous nous sommes intéressés pour l’évaluation de la fragilité. Notre approche vise à analyser les indicateurs de marche pour ainsi mesurer leur évolution au cours du temps et analyser l’activité de la personne pour pouvoir comptabiliser le temps passé à réaliser différentes activités. Par exemple, la perte d’autonomie, analysée à travers l’évaluation de l’activité de la personne, peut s’exprimer en fonction du temps passé debout comparé au temps passé assis et allongé sur un canapé ou un lit. Les changements d’habitudes sont également des indicateurs importants de l’évolution de la fragilité. Nous nous sommes fixé certaines contraintes pour développer un système permettant le maintien à domicile. Notamment, le système doit être basé sur une technologie réaliste, c’est-à-dire utilisable. Nous voulions, entre autres, développer des algorithmes qui puissent fonctionner sur des machines à bas coût. Pour cela, nous proposons des algorithmes simples et peu coûteux en temps de calcul et en mémoire, afin de pouvoir les insérer dans n’importe quelle machine. Pour être utilisable, l’équipement nécessaire ne doit pas être trop encombrant pour pouvoir être installé à domicile. La contrainte d’utilisation de capteurs ambiants, plutôt que de capteurs portés par la personne, a également été posée. L’idée est de laisser libre la personne sans qu’elle n’ait besoin de penser à porter le système ou à l’activer. Le choix final s’est donc porté sur le capteur Kinect de Microsoft qui est une caméra de profondeur à bas coût. 3.2 Contributions Dans l’organisation de ce mémoire, nous distinguons deux contributions. La première porte sur l’analyse du mouvement de la personne et la seconde sur l’analyse de l’activité. Ces deux contributions pourront permettre la conception d’un système d’évaluation et de sécurisation de la personne à son domicile. L’analyse du mouvement et la détection des activités d’une personne sont deux thèmes de recherche traités dans la littérature séparément, car chacun a ses propres difficultés faisant appel à des compétences différentes. Nous montrons dans cette thèse que les deux problématiques peuvent être abordées par l’analyse d’un ensemble de paramètres simples extraits d’images de profondeur. La partie I présente les systèmes existants pour d’un côté mesurer le degré de fragilité à l’hôpital et de l’autre détecter les chutes au domicile. En observant les systèmes existants et les contraintes que nous nous sommes fixées, nous expliquons les raisons pour lesquels nous avons choisi les caméras de profondeur pour développer le système. Dans une deuxième partie, nous présentons les différents algorithmes conçus à partir des informations obtenues avec la caméra. Nous y apportons, au chapitre 3, un état de l’art non exhaustif des méthodes utilisées en vision pour détecter et suivre une personne au cours du temps. Puis, au chapitre 4, nous développons nos algorithmes de détection et de suivi de la personne, fondés sur des méthodes simples que sont l’extraction de fond et le suivi de la silhouette de la personne. Ces algorithmes sont communs pour l’analyse de la marche et la détection d’activité. Plus précisément, les deux contributions sont fondées sur l’analyse des mêmes paramètres, ex- 5traits des images de profondeur fournies par la caméra, qui sont le centre de masse estimé de la personne et la distribution verticale des points de la silhouette. Nous développons dans deux chapitres distincts, les algorithmes propres à chacun des deux axes de recherche. Le chapitre 5 de ce mémoire présente les aspects concernant la marche des personnes. Ce chapitre introduit, dans un premier temps, un certain nombre de notions et de techniques, notamment dans le domaine médical, auxquelles nous faisons référence. Nous présentons les différents paramètres qu’il est possible d’analyser pour évaluer la marche d’une personne. Puis, nous présentons les paramètres que nous avons sélectionnés (longueur de pas, cadence et vitesse de marche) et les algorithmes d’extraction de ces paramètres. Cette contribution concerne la mesure de paramètres de la marche comme indicateur de l’évolution de la fragilité chez les personnes âgées. Le chapitre 6 de ce mémoire est consacré au développement d’un détecteur d’activité. Il repose sur l’utilisation du formalisme des modèles de Markov cachés, défini en annexe A. Dans ce chapitre, nous développons les différents modèles construits pour répondre au problème de la détection d’activité au domicile des personnes. La détection de l’activité apporte des informations à la fois pour la sécurisation et l’évaluation de la personne âgée. D’un côté, le travail présenté contribue à la problématique de sécurisation en détectant les chutes et les comportements anormaux. De l’autre, il contribue à la problématique d’évaluation de la perte d’autonomie permettant une analyse au long cours de l’évolution des habitudes de la personne. Les contributions des chapitres 5 et 6 sont ensuite évaluées indépendamment à la partie III de ce mémoire. Dans une première expérimentation en laboratoire nous montrons, sur des personnes jeunes, que la précision des paramètres de la marche extraits avec notre algorithme est similaire aux valeurs extraites d’un tapis actimètrique, pris comme mesure de référence. D’autres expérimentations en laboratoire ont permis de constater que certains modèles de Markov cachés fournissent une classification robuste des activités, aussi bien lorsque la personne est entièrement visible que partiellement visible. Des premiers tests ont également été effectués avec des personnes âgées en situation réelle (à l’hôpital et au domicile). Les résultats ont montré que, malgré la variabilité des trajectoires du centre de masse des sujets, l’extraction des paramètres de la marche et la reconnaissance des activités sont possibles. Enfin, la partie IV présente, dans un premier chapitre, l’association des deux contributions dans un système unique aidant à la sécurisation et à l’évaluation pour le maintien à domicile des personnes âgées. Plus précisément, nous intégrons l’algorithme de détection d’activité et celui de l’extraction des paramètres de la marche dans un seul système. Ainsi, selon l’activité détectée par l’algorithme, celui-ci enverra une alerte aux secours en cas de chute, comptabilisera le temps passé dans des activités passives (allongé ou assis) et actives (marcher ou être debout) ou analysera les paramètres de la marche quand la personne sera détectée comme marchant. Nous développons également une méthode pour cartographier les habitudes des personnes âgées, c’est-à-dire apprendre les habitudes les plus fréquentes dans les différentes zones du logement. Cela permettra de détecter les évolutions des habitudes de la personne et donc de détecter les anomalies. La carte est construite à partir de l’algorithme détectant les activités de la personne. La carte intègre aussi l’information concernant la vraisemblance permettant de distinguer les moments où la personne est entièrement ou partiellement visible. Dans le dernier chapitre, nous proposons d’autres perspectives pour le système. Nous pensons que ce système peut être utilisé avec d’autres objectifs que le maintien à domicile, comme différencier les personnes ou encore prévenir les troubles cognitifs et les risques d’hospitalisation. L’apport de ce travail de thèse se situe à la fois sur le plan méthodologique et technique. Sur le plan méthodologique, la particularité de ce travail est qu’il est guidé par l’approche expérimentale. Les différentes décisions ont été prises avec l’objectif de développer un système correspondant au « réalisme du terrain », qui une fois construit, pourrait être expérimenté au domicile des personnes 63. Approche proposée âgées. Cette nécessité de développer des approches expérimentées et évaluées, au regard des contraintes particulières que pose l’environnement d’une personne âgée, a eu des répercussions sur le plan technique et sur les choix pris pour concevoir le système. L’objectif visé était de construire un système simple en vue des expérimentations futures. Nous montrons donc qu’en utilisant des indicateurs simples, que sont la trajectoire du centre de masse de la personne et la distribution verticale des points de sa silhouette, extraits à partir d’algorithmes utilisés en vision, il est possible de créer un système à haut pouvoir de décision. A partir de ces deux indicateurs, il est possible de sécuriser la personne dans son environnement, en détectant ses chutes et ses comportements dangereux, et d’évaluer son degré de fragilité en analysant sa marche et ses activités. 78Première partie Approches pour la mesure de la fragilité et la détection des chutes 9Introduction Nous avons posé les objectifs de ce travail, à savoir développer un système permettant de détecter les chutes et de mesurer le degré de fragilité d’une personne. Dans cette première partie, nous recensons les différentes approches existantes pour traiter ces deux questions. Les systèmes détectant la chute et analysant la fragilité des personnes sont souvent conçus pour résoudre l’un ou l’autre des deux problèmes. C’est pourquoi, nous avons construit l’état de l’art en deux chapitres. Le premier chapitre présente les différentes approches pour évaluer le degré de fragilité d’une personne. Les dispositifs, décrits dans ce chapitre, sont des dispositifs utilisés dans le milieu mé- dical. Les médecins analysent la fragilité, notamment, à travers les paramètres de la marche et leur évolution. Certaines modifications sont facilement perceptibles à l’œil. Les tests cliniques peuvent alors être suffisants. Les tests cliniques sont les premiers outils des médecins pour analyser l’état général de la marche d’une personne. D’autres modifications de la marche requièrent des instruments de mesure, comme c’est souvent le cas pour évaluer les progrès réalisés en rééducation. Nous retrouvons des systèmes avec capteurs ou sans capteurs portés par la personne. Dans la catégorie des capteurs portés, les dispositifs sont nombreux, allant du simple accéléromètre au capteur plus évolué comme l’électromyographie, en passant par des systèmes de chaussures équipées de capteurs de pression ou encore des systèmes de caméras avec capteurs portés par les personnes. Les dispositifs, dans la catégorie des systèmes sans capteurs portés, sont les tapis roulants, les tapis actimètriques, ou encore les plateformes de force. Dans un deuxième chapitre, nous recensons les systèmes utilisés pour détecter la chute des personnes au domicile. Le découpage à l’intérieur de ce chapitre est effectué selon le type de capteurs utilisé : capteurs embarqués portés par la personne ou capteurs ambiants. Dans la catégorie des systèmes embarqués sur la personne, nous citons les capteurs tels que les accéléromètres ou les goniomètres. Concernant les systèmes ambiants, nous citons les capteurs environnementaux, comme les capteurs infrarouges de mouvement ou les détecteurs d’ouverture. Les systèmes à base de caméra appartiennent également à cette catégorie. Et enfin, plus récemment, des dispositifs placés au sol apparaissent. Chaque système décrit a plus ou moins d’avantages et d’inconvénients par rapport à ce que nous souhaitons développer. Les systèmes adaptés uniquement à une utilisation en cabinet médical (les systèmes à base de capteurs embarqués), fournissant peu d’information (comme les accéléromètres) ou encore ayant un prix élevé, ne correspondent pas à nos objectifs. 11Introduction 12Chapitre 1 Panorama des approches pour l’analyse de la fragilité à l’hôpital Sommaire 1.1 L’œil expert à travers les tests cliniques . . . . . . . . . . . . . . 13 1.2 Outils d’analyse du mouvement . . . . . . . . . . . . . . . . . . . 14 1.2.1 Systèmes avec capteurs embarqués sur la personne . . . . . . . . . 14 1.2.2 Systèmes sans capteur embarqué sur la personne . . . . . . . . . . . 16 1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 La fragilité des personnes est évaluée essentiellement par le corps médical à travers une analyse de leurs capacités motrices. Les médecins analysent la marche des personnes à travers des tests cliniques. Ils peuvent, également, utiliser des outils de mesure pour quantifier la marche. 1.1 L’œil expert à travers les tests cliniques L’analyse de la marche à travers l’œil humain est une méthode souvent utilisée dans le monde médical, car peu coûteuse. Les médecins observent une éventuelle pathologie ou fragilité chez les personnes âgées en s’aidant d’outils tels que la vidéo, le chronomètre, le mètre et les tests cliniques. De nombreux tests ont été mis en place pour aider l’évaluation faite par le médecin. Aucun consensus n’a été posé sur le choix des tests à effectuer. Le médecin peut donc choisir parmi un large échantillon de test. La liste suivante n’est pas exhaustive, mais elle permet de citer quelques tests couramment utilisés durant la consultation des patients en cabinet : — le test des « dix mètres de marche » où le médecin calcule le nombre de pas et/ou chronomètre le temps pour faire cette tâche ; — le test « up and go » où le médecin calcule le temps mis par la personne pour s’asseoir, se lever, marcher sur 3 m et revenir s’asseoir ; — le test de « durée de l’appui unipodal » où le médecin calcule le temps durant lequel la personne tient l’équilibre sur un pied sans se tenir ; — le test de la « vitesse de marche confortable » où le médecin calcule la vitesse du patient marchant « normalement » ; — le test de « Tinetti » permettant, à l’aide d’un questionnaire et de petits exercices, de juger de la qualité de la marche et de l’équilibre. 13Chapitre 1. Panorama des approches pour l’analyse de la fragilité à l’hôpital Figure 1.1 – Représentation de la marche humaine en diagramme bâton par Marey. Ces tests permettent de fournir une évaluation de la qualité de la marche et de l’équilibre de la personne pour ainsi évaluer son état. Chaque médecin peut avoir un regard différent sur les résultats. Pour pallier au manque d’objectivité, d’autres techniques existent. 1.2 Outils d’analyse du mouvement Les systèmes de mesure du mouvement sont utilisés dans divers domaines et pour divers objectifs. Ils peuvent être utilisés : — pour étudier la marche (normale ou pathologique) de la personne dans le domaine médical ou biomécanique ; — pour analyser le corps en activité dans le domaine du sport ; — pour étudier l’influence de différents dispositifs sur la marche en ergonomie ; — pour analyser la marche humanoïde dans le but de la comprendre et la reproduire dans le cadre de la robotique ; — pour simuler la marche et l’intégrer dans des personnages virtuels dans le domaine de l’animation et la simulation de synthèse. L’objectif commun des différents domaines est de quantifier la marche, de l’analyser dans un contexte spatio-temporel. Dès la renaissance, le sujet intéresse les scientifiques. Léonard de Vinci, Galilée et Newton analysaient déjà la marche. Mais le premier instrument de mesure naquit avec l’apparition de la chronophotographie. Cette technique consiste à prendre des photographies lors d’un mouvement pour le décomposer et le représenter sous la forme d’un diagramme de bâton comme illustré par la figure 1.1 [Marey, 1894]. En 1878 Eadweard Muybridge et en 1882 Étienne-Jules Marey utilisèrent les premiers cette technique. Muybridge analysa le mouvement du cheval et Marey le mouvement de l’oiseau en vol. Ces travaux ont constitué les prémisses du développement de nombreux outils de mesure du mouvement humain. Aujourd’hui, il existe de nombreux systèmes pour mesurer le mouvement. Nous les séparons en deux catégories : les systèmes nécessitant de placer des capteurs sur la personne et ceux sans capteurs embarqués. 1.2.1 Systèmes avec capteurs embarqués sur la personne Différents capteurs, à poser sur le corps de la personne, existent permettant de fournir plus ou moins d’indications sur la marche. Le capteur de plus bas niveau, car apportant peu d’information, est le podomètre, comptant simplement le nombre de pas effectués par la personne lorsqu’elle marche. Cet outil peut être utile également, en dehors du cabinet du médecin, pour mener des recherches. Par exemple, en 2002 Silva et al. [Silva et al., 2002] ont réalisé une étude 141.2. Outils d’analyse du mouvement Figure 1.2 – Le système Walkmeterc est inspiré du locomètre de Bessou. sur le nombre de pas par an effectués par des personnes et ont cherché des spécificités selon la catégorie de personne (homme, femme, personne obèse, etc.). Les capteurs de mouvements (les capteurs infrarouges passifs) fournissent également un seul indicateur qui est la vitesse de marche. Un exemple d’utilisation peut être donné avec l’étude en 2010 réalisée par Hagler et al. [Hagler et al., 2010]. Ils ont eu l’idée d’installer 4 capteurs infrarouges (PIR) au plafond du domicile des personnes âgées. Le but était d’observer un éventuel déclin à travers la vitesse de la marche et ainsi poursuivre l’analyse en dehors du cabinet du médecin . Le locomètre de Bessou est l’instrument représenté à la figure 1.2. Il est composé d’une boite de laquelle deux câbles sortent, pour être attachés aux deux talons. Ainsi, ce système fournit la mesure des déplacements longitudinaux des câbles. Plusieurs paramètres de la marche en sont déduits comme la longueur des pas, la fréquence du pas, la durée des appuis, etc. Ce système est limité par la longueur des câbles. Un exemple d’utilisation pour les personnes hémiplégiques est présenté dans l’article de Condouret et al. en 1987 [Condouret et al., 1987]. Il existe également des chaussures munies de capteurs de pression permettant de récupérer les positions spatio-temporelles des pieds. A partir de ces positions, des valeurs telles que la vitesse de marche, les longueurs de pas peuvent être calculées. Les accéléromètres, les gyroscopes ou les goniomètres ([Bourke et al., 2007], [Wu, 2000]) sont des capteurs posés sur la jambe de la personne. Ils permettent d’analyser la marche et plus précisément l’accélération du corps ou l’angle des différents segments de la jambe lors de la marche. Ces systèmes sont posés sur les parties molles de la jambe donc il est nécessaire de vérifier qu’ils ne bougent pas au cours de la séance. De plus, le positionnement de ces capteurs varie selon la personne qui les pose. Les systèmes optoélectroniques à marqueurs actifs s’insèrent dans cette catégorie (comme le système Selspot). La personne marche dans le champ de vision des caméras qui captent la lumière émise par les capteurs, posés sur la personne à différents endroits du corps. Cette technique permet d’obtenir très précisément les trajectoires spatiales et ainsi d’en déduire un certain nombre de paramètres comme les longueurs de pas, les angles des différents segments du corps, etc. Chaque capteur est alimenté par un câble, ce qui limite les déplacements de la personne. Il existe également des systèmes optoélectroniques à marqueurs passifs permettant aux capteurs de ne plus être reliés à des câbles d’alimentation. Les systèmes Vicon et Qualisys, par exemple, sont 15Chapitre 1. Panorama des approches pour l’analyse de la fragilité à l’hôpital des systèmes à marqueurs passifs. Ces systèmes consistent à positionner, en certains points clés du corps, des marqueurs réfléchissant un signal infrarouge émis par les caméras. Ainsi, la position 3D des différentes parties du corps est évaluée et permet, tout comme les systèmes à marqueurs actifs, de calculer les longueurs de pas, les durées, les angles entre les segments, etc. Les systèmes optoélectroniques restent des systèmes assez contraignants et coûteux. A chaque nouvelle installation du système, une phase de calibration est nécessaire pour définir un repère commun entre toutes les caméras et les renseigner sur leur position les unes par rapport aux autres. Comme tout système à capteurs embarqués, le positionnement des capteurs reste dépendant de leur pose et peut bouger au cours de la marche. De plus, certains capteurs peuvent durant la marche être occultés par les segments corporels. Pour analyser correctement le mouvement de la personne, six caméras au minimum sont généralement nécessaires. Ces dispositifs sont toutefois très utilisés dans différents secteurs, notamment en milieu hospitalier, pour la simulation de personnages virtuels, pour le sport, pour la biomécanique, etc. L’électromyographie (EMG) est un système permettant d’enregistrer l’activité électrique musculaire en positionnant des électrodes sur le corps ou à l’intérieur du corps sur les muscles à étudier. Cette technique est assez controversée, car l’activité électrique enregistrée peut provenir de l’activité de muscles voisins et non pas de celui que l’on cherche à analyser. 1.2.2 Systèmes sans capteur embarqué sur la personne Des systèmes sans capteurs embarqués sur la personne peuvent également être utilisés, la laissant libre lors de ses mouvements. Les plates-formes de force sont des outils sans capteurs embarqués sur la personne. Ces systèmes sont composés d’une simple plateforme (d’environ 60*60 cm) placée sur le parcours de marche. Ils permettent de mesurer les forces appliquées par le pied sur la plateforme lors de la marche. Les tapis roulants instrumentés (figure 1.3) constituent également des systèmes permettant d’analyser la marche. Ils sont constitués de plateformes de force. L’avantage, comparé à la simple plateforme de force, est que le tapis analyse un grand nombre de pas successifs. La personne marche au rythme imposé par le tapis. La vitesse de marche de la personne n’est donc pas naturelle et ne peut pas être prise en compte pour juger de la qualité de la marche. D’autres paramètres comme la longueur de pas et les forces du pied sur le tapis peuvent être analysés. Les tapis actimètriques (figure 1.4) permettent également d’enregistrer la pression plantaire exercée par le pied sur le tapis. La force appliquée par le pied est alors calculée, permettant de déduire des paramètres tels que la longueur de pas, la vitesse de marche, etc. Ce système laisse la personne libre de marcher mais il est limité par sa taille. Ce genre de tapis n’excède pas les 6 m de long. 1.3 Conclusion Le milieu hospitalier est le premier endroit où l’on retrouve des systèmes analysant le mouvement des personnes dans le but d’évaluer le degré de fragilité d’une personne. La plupart de ces outils sont coûteux et nécessitent une expertise technique forte pour leur mise en œuvre. C’est pourquoi, chaque institut développe ses propres protocoles d’analyse, suivant les outils qu’ils ont à leur disposition. 161.3. Conclusion Figure 1.3 – Le tapis roulant instrumenté de la société Biometrics. Figure 1.4 – Le tapis actimètrique de la marque GaitRite. 17Chapitre 1. Panorama des approches pour l’analyse de la fragilité à l’hôpital 18Chapitre 2 Panorama des systèmes de détection de chutes au domicile Sommaire 2.1 Systèmes avec capteurs embarqués sur la personne . . . . . . . 19 2.1.1 Détecteurs de chutes automatiques . . . . . . . . . . . . . . . . . . 19 2.1.2 Systèmes d’alerte manuels . . . . . . . . . . . . . . . . . . . . . . . 21 2.2 Systèmes ambiants . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.2.1 Capteurs environnementaux : la télé-assistance . . . . . . . . . . . . 21 2.2.2 Systèmes à base de caméra : la vidéo-vigilance . . . . . . . . . . . . 22 2.2.3 Capteurs au sol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Nous présentons dans ce chapitre les dispositifs existants pour détecter les chutes d’une personne. Le marché des systèmes de détection de chutes est un marché grandissant, principalement destiné à la surveillance au domicile des personnes. En recherche, le sujet de la détection de chutes est également très étudié. Nous avons regroupé les capteurs permettant de détecter les chutes en deux catégories, d’un côté les systèmes utilisant des capteurs à poser sur la personne et de l’autre les systèmes de capteurs ambiants. 2.1 Systèmes avec capteurs embarqués sur la personne La première catégorie regroupe les systèmes à base de capteurs portés sur la personne. L’avantage de ces dispositifs est que bien souvent ils peuvent fonctionner à domicile et à l’extérieur. 2.1.1 Détecteurs de chutes automatiques Les accéléromètres, les gyroscopes et les goniomètres sont des capteurs pouvant servir à détecter automatiquement les chutes des personnes âgées. Dans le domaine de la recherche, certains auteurs, comme Bourke et al. [Bourke et al., 2007] et Wu [Wu, 2000], les ont d’ailleurs utilisés avec l’objectif de tester leur efficacité à détecter les chutes. Leur idée était de positionner ces capteurs sur la personne et d’observer la vitesse de mouvement du corps lorsque la personne réalisait différentes activités. L’hypothèse est que la vitesse est différente quand une personne chute, en comparaison à d’autres activités comme s’asseoir ou s’allonger dans un canapé. 19Chapitre 2. Panorama des systèmes de détection de chutes au domicile Figure 2.1 – Système d’alerte de Vitalbase. Ces capteurs ont été évalués en recherche et aujourd’hui, dans le commerce, certains dispositifs intègrent ce genre de capteurs. Des industriels, tels que Telecom Design avec VitalBase, intègrent un accéléromètre dans un dispositif à positionner au niveau de la ceinture ou au poignet comme le montre la figure 2.1. Ce système permet de détecter la chute à travers la perte de verticalité, l’accélération, le choc de la chute et enfin l’absence de mouvement. Les chutes brutales peuvent être détectées mais pas les chutes molles. Pour éviter les fausses alarmes, une phase de vérification est intégrée au système. Lorsqu’une chute est détectée, le système se met à vibrer durant 26 secondes et la personne doit, durant cette période, réaliser un mouvement ample du bras. Ce geste permet de bloquer l’envoi de l’alerte. Le téléphone portable de l’entreprise suédoise Doro intègre également un accéléromètre. Ce téléphone détecte la chute à travers la perte de verticalité. Ce système de détection de chute doit être activé par la personne lorsqu’elle pense en avoir besoin, par exemple lorsqu’elle se retrouve seule dans son appartement. La société Vigilio a mis en place un dispositif, détectant les chutes, à base d’un capteur accéléromètrique à porter sur le torse de la personne (figure 2.2(a)). En cas de chute ou d’immobilisation prolongée (dans le cas des chutes molles par exemple), leur boitier (figure 2.2(b)) directement connecté à une ligne téléphonique pourra alerter automatiquement un numéro qui a été pré-enregistré. (a) Capteur accéléromètrique à porter sur le torse. (b) Boitier d’alerte. Figure 2.2 – Système de détection de chute de la société Vigilio. D’autres capteurs peuvent également être utilisés notamment des capteurs sensoriels pouvant détecter la perte de conscience des personnes. La société Vivago a intégré ces capteurs dans une montre. L’idée est de détecter la chute des personnes due à un malaise. En utilisant ces capteurs couplés aux capteurs de température cutanée, l’entreprise a mis au point un système de détection de l’état d’inconscience des personnes et d’alerte des secours. 202.2. Systèmes ambiants 2.1.2 Systèmes d’alerte manuels Dans le commerce, il existe également des systèmes ne détectant pas automatiquement la chute. Ces systèmes requièrent la participation de la personne. Les boutons d’alarmes, existant sous forme de collier ou bracelet à porter sur soi, jour et nuit, permettent à la personne d’appuyer dessus pour alerter d’une chute. La marque Intervox du groupe Legrand ou encore le groupe Biotel-Tunstall développent, entre autres, des médaillons à porter par la personne. L’idée est d’éviter les fausses alarmes et de permettre à la personne de se sentir rassurée d’avoir à tout moment un dispositif d’alerte. Ces dispositifs doivent être portés pour fonctionner. C’est la cause principale de leur manque d’efficacité, car les personnes ne les portent pas, soit parce qu’ils sont perçus comme stigmatisants soit parce que la personne oublie tout simplement de les porter. Des études ont aussi montré que ces dispositifs pouvait être inefficaces, même lorsqu’ils sont portés, car les personnes ne les utilisent pas forcément après une chute. Dans l’article de Wild et al. [Wild et al., 1981], les auteurs ont mené une étude sur les personnes âgées de plus de 65 ans durant un an. Dans cette expérience, ils ont formé deux groupes, un groupe de « chuteurs » (constitué de personnes ayant déjà chuté une fois) et un groupe contrôle. Parmi les neuf chuteurs ayant un système d’alerte, seulement deux ont réussi à l’utiliser pour alerter après être tombés, l’un a tenté mais n’a pas réussi à l’utiliser et les six derniers n’ont même pas tenté de l’utiliser. L’incapacité d’appuyer sur le bouton peut être due à la perte de connaissance de la personne ou à son état de choc. 2.2 Systèmes ambiants Cette catégorie de dispositif, basée sur des capteurs ambiants, ne fonctionne qu’à l’intérieur. Ces systèmes ont l’avantage de fonctionner automatiquement sans que la personne n’ait besoin de le déclencher. 2.2.1 Capteurs environnementaux : la télé-assistance Les capteurs environnementaux permettent de rendre compte de l’activité d’une personne dans son lieu de vie. On peut compter le nombre de fois où la personne ouvre le réfrigérateur, le nombre de fois où elle s’est assise, etc. Ces différentes informations permettent d’en déduire l’activité d’une personne. Par exemple, les capteurs peuvent indiquer qu’une personne est inactive depuis longtemps ce qui révèle un comportement anormal. Différents capteurs peuvent être utilisés. Les capteurs infrarouges de mouvement informent de la présence ou non d’une personne dans une pièce. Ainsi, il est possible de s’assurer que la personne est sortie de sa chambre au cours de la journée par exemple. Des détecteurs d’ouverture, posés dans des endroits tels que le réfrigérateur ou le robinet, permettent de s’assurer de l’utilisation des différents points d’intérêts. La marque Intervox propose toute une gamme de capteurs parmi lesquels figurent les capteurs de mouvements et d’ouverture. Le but est de définir des tranches horaires où la personne doit être aperçue dans telle pièce ou doit ouvrir tel point d’intérêt. En cas de non conformité avec les événements prédéfinis, une alerte est déclenchée. Senioralerte utilise également ce genre de capteurs (détecteurs de présence, d’ouverture, etc.). L’objectif de cette entreprise est d’apprendre les habitudes des personnes au cours du temps pour déceler des activités anormales. Ces systèmes, en cas de détection d’un éventuel problème, déclenchent une alerte qui sera envoyée aux proches ou à une assistance s’assurant auprès de la personne qu’un réel problème 21Chapitre 2. Panorama des systèmes de détection de chutes au domicile est apparu avant d’appeler les urgences. 2.2.2 Systèmes à base de caméra : la vidéo-vigilance Les systèmes à base de caméra sont plus intrusifs dans la conscience des gens que les capteurs environnementaux mais ils permettent d’obtenir plus d’informations. Notamment, même si certains capteurs peuvent déduire, suite à un ensemble d’événements, qu’une chute s’est produite, ils ne peuvent pas réellement l’identifier comme telle. Les systèmes à base de caméra peuvent intégrer des algorithmes analysant l’activité d’une personne et surtout des algorithmes détectant la chute, avec beaucoup plus de discernement que ne peuvent le faire les détecteurs classiques. Peu de systèmes de vidéo-vigilance sont commercialisés. En France, le système EDAO propose d’installer des caméras à domicile pour détecter les chutes des personnes en perte d’autonomie. Ce système semi-automatisé détecte des situations à risque (grâce à des algorithmes d’analyse) et prévient un opérateur qui, en visionnant les images, alerte ou non la famille ou les secours. Le sujet de la détection de l’activité et des chutes reste un sujet de recherche. Le but est de dé- velopper des algorithmes d’analyse de l’activité toujours plus performants, ne commettant aucune fausse alarme et détectant chaque situation de chute ([Jansen et al., 2007], [Rougier et al., 2011], [Nait-Charif and McKenna, 2004], [Auvinet et al., 2011b], [Anderson et al., 2009]). 2.2.3 Capteurs au sol L’intérêt de ces capteurs est qu’ils sont dissimulés, les personnes âgées peuvent donc les oublier plus facilement et ne pas se sentir surveillées en permanence. Le principe de ces capteurs posés au sol est qu’ils détectent les pressions plantaires exercées par les personnes. Ainsi, les algorithmes développés peuvent déduire certaines informations, savoir dans quelle pièce se trouve la personne au cours de la journée, s’assurer qu’elle ne soit pas allongée au sol, etc. En recherche, la thématique des sols « intelligents» commence à se développer. Rimminen et al. ([Rimminen et al., 2009], [Rimminen et al., 2010]) décrivent dans leurs deux articles une technique pour suivre la personne (en utilisant entre autres un filtre de Kalman) puis pour détecter les chutes (en utilisant notamment des chaines de Markov). Un appartement construit au sein d’INRIA à Nancy a été recouvert d’un réseau de capteurs au sol ([Pepin et al., 2009]). Le sol est composé de dalles, mesurant 60×60 cm, qui ont été construites sur mesure. 100 dalles ont été installées dans cet appartement comme le montre la figure 2.3(a). Chaque dalle est équipée d’un accéléromètre, d’un magnétomètre et de quatre jauges de contraintes (des capteurs de force) positionnées à chaque angle comme précisé à la figure 2.3(b). Les dalles peuvent envoyer un message par le réseau ZigBee à d’autres dalles. L’un des objectifs, comme dans le travail de Rimminen, est de pouvoir détecter la chute des personnes parmi d’autres activités de la vie quotidienne. Rimminen travaille sur un sol instrumenté fondé sur la mesure du champ électrique. Un certain nombre de dispositifs commerciaux commencent à voir le jour. Pour n’en citer que quelques uns, nous pouvons mentionner les dispositifs proposés par Tarkett, Elsi et le SensFloor de la société Futur-Shape. Ces systèmes sont encore un peu coûteux et sont réservés à des installations dans les établissements d’hébergement pour personnes âgées dépendantes (EHPAD) ou dans des constructions neuves. 2.3 Conclusion Les systèmes qui sont actuellement installés au domicile des personnes âgées détectent la chute ou les situations à risque. En dehors des boutons d’alerte, les systèmes de détection restent 222.3. Conclusion (a) Appartement avec un réseau de dalles au sol. (b) Dessous d’une dalle. Figure 2.3 – Système d’analyse du mouvement par le sol d’INRIA à Nancy. peu courants. 23Chapitre 2. Panorama des systèmes de détection de chutes au domicile 24Conclusion Dans cette partie, nous avons présenté un panorama des systèmes existant pour analyser la fragilité d’une personne et détecter sa chute. Ces deux fonctionnalités nous sont utiles pour développer un système de maintien des personnes âgées au domicile. Les approches pour évaluer le degré de fragilité d’une personne sont surtout développées en hôpital ou en laboratoire. L’évaluation de la fragilité est réalisée à travers l’analyse de la marche. Les tests cliniques sont la méthode la plus simple à mettre en place et donc la plus répandue dans le milieu hospitalier. Les systèmes avec capteurs embarqués et sans capteurs embarqués peuvent être des techniques assez coûteuses et encombrantes mais plus précises que les tests cliniques pour quantifier le mouvement. Ces dispositifs ne correspondent pas à nos objectifs puisqu’ils ne sont pas adaptés pour être utilisés au domicile des personnes âgées dans le cadre d’un usage quotidien. Les systèmes détectant la chute sont principalement conçus pour le domicile. Des capteurs à porter sur soi, comme des boutons d’alerte ou des bracelets détectant automatiquement la chute, existent mais sont peu utilisés, car ils sont stigmatisants pour les personnes. Des capteurs ambiants comme les capteurs environnementaux, les caméras ou les capteurs au sol sont conçus pour détecter automatiquement la chute au domicile. 25Conclusion 26Deuxième partie Algorithmes pour l’évaluation et la sécurisation au domicile 27Introduction Nous développons dans cette partie les différents algorithmes et modèles que nous avons conçus pour suivre une personne dans le temps et l’espace, analyser son activité et sa marche. Nous exposons tout d’abord une vision globale du système proposé. 1 Vision générale Nous exposons, ici, la vision que nous proposons d’un système pour favoriser le maintien à domicile des personnes âgées. L’architecture générale du dispositif est résumée par le schéma 3. L’objectif global est de sécuriser et d’évaluer la fragilité de la personne au quotidien à son domicile. Pour cela, nous prévoyons d’installer, dans chaque pièce de la maison, un capteur 3D couplé à un mini ordinateur de façon à traiter les données au domicile et ne pas transmettre d’images. Nous avons donc opté pour des algorithmes et modèles légers, ne nécessitant pas de gros calculs pour qu’ils puissent être implémentés dans des mini ordinateurs à bas coût et fonctionner en temps réel. A chaque information reçue du capteur, les algorithmes analysent la scène en détectant la personne et ses activités. Nous voulons identifier des activités de la vie quotidienne telles que s’asseoir, marcher, s’accroupir, se pencher, monter sur un obstacle (une chaise, une marche, etc.), s’allonger sur un lit ou sur un canapé, et des situations particulières comme chuter et être allongé au sol. Ainsi, à la fin de chaque journée, un bilan du temps d’activité et d’inactivité pourra être fait. Cet indicateur de l’évolution de la fragilité de la personne sera couplé à l’évaluation de l’évolution de sa marche. Les observations sur l’activité et la marche de la personne seront envoyées, selon le protocole de suivi, au médecin, à la famille et à la personne elle-même pour ainsi évaluer l’évolution jour après jour de son état. Le médecin pourra alors coupler ces informations avec les différents tests qu’il effectuera durant les consultations pour affiner son évaluation de la fragilité de la personne. D’une manière plus générale, le système pourrait apprendre les habitudes des personnes, comme l’heure à laquelle elle se réveille ou la vitesse à laquelle la personne marche. Ainsi, les changements d’habitudes pourront être utilisés comme des indicateurs de l’évolution de l’état général de la personne. La deuxième fonctionnalité du système serait de sécuriser la personne en alertant les secours en cas de chute. Le système pourrait également prévenir la famille en cas de détection de situations à risque telles que monter sur une chaise et s’accroupir, qui sont des activités pouvant conduire à une chute. 2 Choix des capteurs Dans l’introduction de ce mémoire, nous avons indiqué quelques contraintes à prendre en compte dans le développement de notre système, notamment, il doit être réaliste par son coût et reposer sur des capteurs ambiants pour ne pas perturber la personne. Les systèmes avec capteurs embarqués sur la personne, tels que les accéléromètres, n’ont donc pas été retenus. Les capteurs 29Introduction 500 550 600 650 700 750 800 850 900 950 1000 33.5 34 34.5 35 35.5 36 36.5 37 37.5 Y (mm) Temps (s) Walking Salle Chambre Salle de bains Cuisine Ambulance Figure 3 – Vision pour la conception d’un système permettant le maintien à domicile des personnes âgées. au sol ne sont également pas retenus, car, aujourd’hui, ils n’apportent pas encore de solution facile à adopter dans un environnement déjà existant. Les capteurs environnementaux et les caméras correspondent au besoin. Il est possible d’installer un réseau de capteurs environnementaux au domicile de la personne sans la gêner et avec un coût peu élevé. Mais l’information sortant de ces capteurs est insuffisante pour ce que nous voulons faire. Ils permettent de détecter un grand nombre d’événements, comme l’heure à laquelle la personne a ouvert le réfrigérateur ou le nombre de fois où elle s’est levée de son fauteuil. Nous ne pouvons pas, en revanche, avoir d’information sur la qualité de sa marche. De plus, ces capteurs ne peuvent pas différencier les personnes. Ils ne peuvent pas savoir si la personne ouvrant le robinet est la personne à suivre, le conjoint, les visiteurs ou encore le personnel soignant. Nous avons donc opté pour des caméras permettant, comme nous allons le montrer, aussi bien de détecter l’activité de la personne que d’analyser le degré de fragilité à travers l’évolution de sa marche. Les caméras RGB-Depth de Microsoft (les caméras Kinect) ont été choisies, car elles permettent de fournir une information de profondeur pour chaque objet en plus de l’image couleur. De plus, elles se trouvent facilement dans le commerce, sont à bas coût et fonctionnent la nuit. 3 Conception des algorithmes La détection d’activité et l’analyse de la marche, à l’aide de caméras, nécessitent de concevoir au préalable un modèle d’extraction des personnes efficace et fiable. Les pixels extraits doivent ensuite être représentés sous une forme compacte permettant de suivre l’évolution dans l’image de la personne. Suivre une personne au cours du temps soulève plusieurs questions. 30— Sous quelle forme représenter l’objet d’intérêt pour qu’il soit reconnu dans toutes les situations ? — A partir de quelles caractéristiques obtenir la représentation de l’objet ? — Comment extraire le ou les objets d’intérêts dans la scène ? — Quelle méthode est adaptée pour suivre l’objet au cours du temps ? Dans le premier chapitre, nous présentons les méthodes utilisées pour traiter un flux vidéo. De nombreux articles traitent de la question du suivi d’objets (Object tracking en anglais) dans une vidéo. La liste des méthodes, que nous présentons dans ce chapitre, n’est donc pas exhaustive. Nous nous concentrons sur les méthodes permettant de détecter et suivre une personne au domicile. Suivre une personne dans une scène au cours du temps est un défi, car cela soulève de nombreux problèmes. Les difficultés rencontrées peuvent être dues à ses mouvements, à ses changements d’apparence (changement d’habit par exemple), à sa propriété non rigide (une personne est différente assise ou debout), aux changements de la scène (une chaise qui a bougé), aux occlusions pouvant cacher partiellement ou totalement la personne ou encore aux mouvements de la caméra. Dans ce premier chapitre, nous présentons la particularité de la caméra que nous utilisons. Les méthodes en vision ont été construites pour des caméras couleur classiques. L’apparition de la caméra fournissant une information de profondeur permet de faciliter un certain nombre de traitements qui auparavant étaient moins robustes. Dans le deuxième chapitre, nous présentons les méthodes que nous avons implémentées pour détecter et suivre une personne. Nous présentons, tout d’abord, la méthode de soustraction du fond que nous avons identifiée comme peu coûteuse en temps de calcul et robuste si elle est faite à partir de l’image de profondeur renvoyée par la caméra. Puis, nous montrons qu’à travers cinq caractéristiques, extraites des images de profondeur, nous pouvons représenter une personne et la suivre au cours du temps. Ces cinq caractéristiques sont : le centre de masse, la vitesse verticale, la vitesse horizontale, la dispersion verticale et le point maximum. Ces caractéristiques ont été choisies, car elles sont faciles à extraire et peuvent être suivies en temps réel. Dans le troisième chapitre, nous abordons l’algorithme permettant l’analyse de la marche d’une personne. L’idée est d’observer au cours du temps les paramètres de la marche d’une personne, comme indicateur de l’évolution de sa fragilité. Dans un premier temps, nous allons définir et décrire la marche. Nous verrons, entre autres, les différentes phases qui caractérisent la marche humaine et les indicateurs permettant de l’analyser. Nous verrons comment une analyse de différents paramètres spatio-temporels (longueurs de pas, vitesse de marche, etc.), cinématiques (angles formés par les différentes parties du corps) et dynamiques (les forces de réaction du pied, etc.) permet de révéler en grande partie les capacités physiques d’une personne. Pour notre étude nous nous sommes restreint à la seule mesure des paramètres spatio-temporels. Pour extraire ces paramètres, nous nous basons sur le centre de masse de la personne et sur la détection des maxima locaux sur l’axe vertical. La précision des paramètres de la marche est évaluée au chapitre 7 de la prochaine partie. Le quatrième chapitre est consacré au développement d’un algorithme détectant l’activité d’une personne. Nous avons vu en introduction, l’importance de détecter au plus vite les chutes, pour éviter à la personne de rester au sol trop longtemps et pour diminuer le risque de séquelles physiques et psychologiques. La personne peut avoir peur de rechuter et, ainsi, minimise ses activités. En ce sens, la chute peut accélérer la perte d’autonomie. Cet axe de recherche a donc un double objectif. Il permet, d’un côté, de sécuriser la personne en détectant les chutes et les activités à risque, comme monter sur une chaise. Et, d’un autre côté, il permet d’évaluer le degré de fragilité de la personne et de prévenir la perte d’autonomie en détectant les comportements inhabituels, comme l’immobilité prolongée. Pour détecter l’activité d’une personne, nous avons choisi d’utiliser le formalisme des modèles de Markov cachés (MMC). Ce sont des modèles qui 31Introduction permettent d’estimer un état caché à partir d’une séquence d’observations. Nous les définissons plus largement en annexe A. Parmi les nombreuses méthodes de la littérature, les MMC ont été souvent utilisés dans le cas de la reconnaissance d’activité. Les taux de reconnaissance d’activité sont très importants avec ce type de méthodes. Cependant, bien souvent, les algorithmes utilisent un grand nombre de caractéristiques pour déterminer l’état caché. Notre objectif est de construire des modèles de Markov cachés en prenant des caractéristiques simples à extraire et peu nombreuses, tout en conservant un bon niveau de classification des activités. Les caractéristiques, que nous prenons en compte, sont la position du centre de masse, la vitesse verticale et horizontale du centre de masse, la dispersion verticale de la silhouette et le point le plus haut du corps. Nous construisons plusieurs modèles pouvant tous correspondre à notre problème. Les différences entre les différents modèles portent sur le nombre d’activités que le modèle peut dé- tecter (entre 8 et 9) et sur le nombre de caractéristiques pris en compte (entre 3 et 5). Nous avons également construit des modèles où nous fixons à la main certains paramètres et d’autres n’ayant pas de connaissance a priori. Nous avons voulu construire plusieurs modèles pour dé- terminer si, en prenant un nombre restreint de caractéristiques, le modèle peut discriminer les activités correctement ou s’il est nécessaire d’ajouter des caractéristiques pour augmenter le taux de bonnes classifications. L’évaluation expérimentale des résultats est présentée au chapitre 8 de la partie III. 32Chapitre 3 Détecter et suivre une personne avec une caméra : état de l’art Sommaire 3.1 Détection de la personne . . . . . . . . . . . . . . . . . . . . . . . 33 3.1.1 Détecteur de points d’intérêt . . . . . . . . . . . . . . . . . . . . . . 34 3.1.2 Soustraction du fond . . . . . . . . . . . . . . . . . . . . . . . . . . 34 3.1.3 Segmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.1.4 Apprentissage supervisé . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2 Suivi de la personne . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.1 Modèles d’objets animés . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2.2 Suivi de l’objet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 3.3 Caméra de profondeur . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Ce chapitre se base, entre autres, sur le livre de Russell et Norvig [Russell and Norvig, 2010] et sur une étude réalisée en 2006 par Alper Yilmaz et al. [Yilmaz et al., 2006] recensant et classifiant les différentes méthodes utilisées dans la littérature, pour détecter et suivre une personne. Toutes les méthodes en vision ne sont pas abordées dans ce chapitre. Cet état de l’art est centré sur l’extraction d’une personne d’une scène avec une caméra fixe localisée en intérieur. Les deux grandes étapes en « vision par ordinateur » sont développées dans deux sections séparées, dédiées à la détection d’objets animés et au suivi spatio-temporel de ces objets. Ensuite, nous abordons, dans une nouvelle section, la particularité du capteur de profondeur choisi qui, comme nous le verrons, simplifie fortement les traitements nécessaires à notre proposition. 3.1 Détection de la personne La difficulté ici est de détecter dans la scène, vue par la caméra, la présence ou l’absence d’objet d’intérêt (la personne). Bien souvent la détection requiert plusieurs images. L’utilisation de seulement deux images consécutives peut provoquer de fausses détections. Par exemple, l’algorithme peut considérer qu’il y a un objet mobile alors qu’il s’agit juste d’une variation de la luminosité ou d’une ombre sur les deux images. Dans l’état de l’art, plusieurs catégories de méthodes ont été proposées : 1. des méthodes détectant des points d’intérêts ; 33Chapitre 3. Détecter et suivre une personne avec une caméra : état de l’art 2. des méthodes d’extraction de fond ; 3. des méthodes de segmentation de l’image ; 4. des méthodes d’apprentissage supervisé. 3.1.1 Détecteur de points d’intérêt Le principe, ici, est de détecter des points d’intérêt dans l’image comme observé à la fi- gure 3.1(b). L’avantage de ces méthodes est qu’elles sont robustes aux changements de lumière et indépendantes du champ de vision de la caméra. Le principe repose sur l’extraction des parties saillantes des objets à partir des variations d’intensité. Le détecteur de Moravec [Moravec, 1979], le détecteur de Harris [Harris and Stephens, 1988] et le détecteur SIFT [Lowe, 2004] (Scaleinvariant feature transform) reposent sur ce principe. Ces détecteurs ont comme particularité d’être invariants aux mouvements de la caméra et des personnes. (a) Image d’origine. (b) Résultat du détecteur de Harris. Figure 3.1 – Détection des points d’intérêts dans une scène. 3.1.2 Soustraction du fond Les méthodes dans cette catégorie consistent à obtenir une représentation de la scène sur plusieurs images. Les objets mobiles recherchés sont détectés lorsque les images fournies par la caméra sont suffisamment différentes de la représentation du fond. Les méthodes fondées sur ce principe sont plus communément regroupées sous le terme de « soustraction de fond » et ont comme objectif de séparer les objets mobiles du fond. Deux méthodes sont couramment utilisées dans la littérature pour obtenir une représentation du fond, la méthode des moyennes mobiles (Running average en anglais) et le mélange de gaussiennes (Gaussian Mixture Model en anglais). Dans la méthode des moyennes mobiles, chaque valeur de pixel, la valeur correspondant à la couleur par exemple, est moyennée sur plusieurs images pour obtenir une représentation du fond. Les valeurs des pixels des nouvelles images sont alors comparées aux valeurs des pixels du fond appris pour identifier les pixels mobiles. Des cas d’utilisation peuvent être trouvés dans la littérature, notamment dans les articles de Jansen et al.[Jansen et al., 2007], de Gómez-Conde et al. [Gómez-Conde, 2011] et de Auvinet et al. [Auvinet et al., 2011b]. Dans la méthode de mélange de gaussiennes, la valeur de chaque pixel est modélisée par un mélange de gaussienne. Pour chaque pixel, les paramètres du modèle, 343.2. Suivi de la personne à savoir les moyennes et les variances, sont appris à partir des observations obtenues sur plusieurs images consécutives. Cette technique a été utilisée pour la première fois par Stauffer et al. [Stauffer and Grimson, 2000]. Une comparaison des deux techniques a été faite par Gómez-Conde et al. [Gómez-Conde, 2011]. La méthode des moyennes mobiles est plus facile à implémenter et moins gourmande en calcul. Mais dans leur article, ils ont remarqué que cette méthode est moins robuste aux changements de couleur que le mélange de gaussienne. 3.1.3 Segmentation La segmentation correspond au processus qui permet de découper l’image en régions de pixels similaires. Les pixels ont chacun des propriétés, par exemple une certaine couleur, luminosité et texture. Les pixels appartenant à un même objet ont des valeurs aux propriétés similaires. L’idée est de repérer les changements notables dans les valeurs prises par ses propriétés, pour ainsi découper l’image en région. Chaque région délimite les frontières entre les objets. Deux caté- gories de méthodes de segmentation existent, des méthodes détectant les frontières entre les objets [Martin et al., 2004] et des méthodes détectant les régions [Shi and Malik, 2000]. Quelle que soit la méthode utilisée pour segmenter, la sélection des propriétés pour réaliser le regroupement est à définir en amont. 3.1.4 Apprentissage supervisé L’idée est de regrouper en classe des échantillons aux caractéristiques similaires. Les nouveaux objets sont associés à la classe ayant les caractéristiques les plus proches. Le choix des caracté- ristiques est très important et doit permettre une bonne discrimination entre les classes. Cette méthode requiert un grand nombre d’exemples pour chaque classe. Pour classifier les objets, différentes méthodes d’apprentissage existent comme les réseaux de neurones [Rowley et al., 1998], adaptive boosting [Viola et al., 2003] (AdaBoost), les arbres de décision [Grewe and Kak, 1995] et SVM [Papageorgiou et al., 1998] (Support Vector Machines). 3.2 Suivi de la personne Après avoir localisé la personne dans la scène (grâce aux méthodes de la section précédente), l’étape suivante est de suivre sa position dans le temps et dans l’espace. Pour suivre une personne, la première et la deuxième question de l’introduction de cette partie doivent être résolues, à savoir, sous quelle forme la personne sera représentée pour être suivi et à partir de quelles caractéristiques récupérer cette représentation. Après avoir recensé les différentes façons de représenter l’objet d’intérêt, à savoir la personne, nous citerons quelques méthodes existantes pour le suivre selon la représentation choisie. 3.2.1 Modèles d’objets animés Différentes représentations Nous nous intéressons à la personne mais pour cette section, nous nous plaçons dans le cadre plus général de la représentation des objets. Les différentes manières de représenter l’objet d’intérêt peuvent être regroupées en deux catégories : les représentations fondées d’une part sur la forme de l’objet et, d’autre part, sur son apparence. 35Chapitre 3. Détecter et suivre une personne avec une caméra : état de l’art Concernant les représentations par rapport à la forme de la personne, certains auteurs la suivent à travers la silhouette (figure 3.2(a)) et les contours(figure 3.2(b)). La silhouette représentant la région à l’intérieur des contours. Le corps peut être représenté par des points (figure 3.2(c)) ou même par un seul point (figure 3.2(d)), par exemple, par le centre géométrique de la personne [Rougier et al., 2011]. Pour représenter la personne, certains l’englobent dans une forme géométrique primitive, comme une ellipse (figure 3.2(e)) ou un rectangle (figure 3.2(f)), couramment appelée un « blob ». Anderson [Anderson et al., 2006], Jansen et al. [Jansen et al., 2007] et Auvinet et al. [Auvinet et al., 2011b] utilisent des blobs pour représenter la totalité du corps humain. D’autres techniques existent permettant de représenter plus finement le corps en distinguant les différentes parties telles que le torse, les jambes, les bras, la tête ou les pieds (fi- gure 3.2(g)). Chaque partie du corps peut être modélisée à travers un cylindre ou une ellipse, comme Rougier et al. qui entourent la tête [Rougier and Meunier, 2010] et Deeb et al. qui s’inté- ressent à la tête et aux pieds [Deeb et al., 2012]. Une dernière méthode de représentation, fondée sur la forme du corps, est fondée sur l’extraction du squelette (figure 3.2(h)). Par exemple, Zhen-Peng Bian et al. [Bian et al., 2012] et Saboune [Saboune and Charpillet, 2005] extraient le squelette dans le but d’étudier les chutes des personnes âgées. (a) (b) (c) + (d) (e) (f) (g) (h) Figure 3.2 – Différentes représentations de l’objet à suivre : (a) silhouette, (b) contour, (c) points, (d) centre géométrique, (e) ellipse, (f) rectangle, (g) plusieurs ellipses et (h) squelette. L’apparence est ce qui caractérise la ressemblance d’un objet. Deux objets se ressemblent s’ils ont la même apparence. L’apparence de certains objets varie peu c’est le cas, par exemple, d’une balle de tennis. Tous les objets n’ont pas une apparence aussi stable. Par exemple, les tables peuvent varier selon leur forme, leur couleur, leur taille et leur angle de vue. Les méthodes utilisées doivent donc être adaptées à l’apparence de l’objet à suivre. Dans notre cas, l’apparence d’une personne peut varier selon la façon dont elle est habillée, sa position, sa posture ou encore son angle de vue. Ces différentes représentations peuvent être combinées. Bien souvent le choix de la représentation s’impose de lui-même selon l’objectif poursuivi. 363.2. Suivi de la personne Caractéristiques pour obtenir la représentation L’algorithme doit se fonder sur certaines caractéristiques faciles à identifier de l’objet pour obtenir une représentation efficace (qui peut être sous la forme d’une ellipse, d’un point, d’un squelette, etc.). Plusieurs caractéristiques de l’objet peuvent être prises en compte. Sa couleur Chaque pixel a trois valeurs, une pour le rouge, une pour le vert et une dernière pour le bleu. Ses bords ou ses contours Les contours sont les lignes dans l’image où la luminosité est modifiée. En cherchant les différences de luminosité, il est possible de détecter les contours et donc de détecter des éléments importants de l’image, comme illustré à la figure 3.3(b). (a) Image d’origine. (b) Résultat de l’extraction des contours. Figure 3.3 – Détection des contours dans une scène. Son flot optique Le flot optique d’un objet révèle le mouvement d’un objet d’une image sur l’autre. Des groupes de pixels se déplaçant à la même vitesse et dans la même direction pourront alors être regroupés et associés à un objet particulier. Sa texture La texture correspond au motif qui se répète sur la surface d’un objet et qui est perceptible visuellement. La texture doit être observée, non pas pour chaque pixel, mais par zone. Les caractéristiques retenues pour représenter un objet sont choisies généralement en fonction du domaine, de l’objectif et du contexte. Des méthodes existent pour sélectionner automatiquement les caractéristiques discriminantes de l’objet. Les méthodes d’analyse en composantes principales ou la méthode Adaboost [Tieu and Viola, 2004] sont de bons exemples de méthodes ayant fait leurs preuves. 3.2.2 Suivi de l’objet Le suivi d’un objet à travers une série d’images n’est pas un problème facile à résoudre, car plusieurs facteurs peuvent venir perturber le suivi comme les occlusions, les mauvaises détections de l’objet, les entrées et sorties du champ de vision de la caméra. La méthode, pour suivre un objet, dépend du choix pris pour représenter l’objet. La méthode ne sera pas la même si l’objet 37Chapitre 3. Détecter et suivre une personne avec une caméra : état de l’art est représenté par un ou des points, par une forme géométrique ou par sa silhouette, et en fonction des hypothèses faites sur sa dynamique. Objet représenté par des points Si l’objet est représenté à travers un ou plusieurs points, le principe de la méthode de suivi consiste à apparier les points d’une image aux points des images consécutives. Le problème consistant à faire correspondre les points, à travers plusieurs images, peut être résolu en utilisant une combinaison d’hypothèses : — la position de l’objet dans des images consécutives ne doit pas énormément varier (3.4(a)) ; — la vitesse de l’objet d’une image à l’autre n’excède pas un certain seuil, ce qui permet de supposer que le point à l’image t + 1 se trouvera dans un certain rayon comparé à l’image t (3.4(b)) ; — la direction et la vitesse de l’objet ne changent pas énormément sur une succession de plusieurs images (3.4(d)) ; — la vitesse des objets dans un petit voisinage est similaire (3.4(c)) ; — l’objet en 3 dimensions est rigide, ainsi la distance entre deux points d’un même objet restera la même à la prochaine image (3.4(e)). X O t t+1 X X (a) X O t t+1 X X (b) O t t+1 X X X O O O X (c) O t t+1 X X X t+2 X X X (d) O t t+1 X X t+2 X X O (e) Figure 3.4 – Différentes hypothèses utilisées pour le suivi d’un objet : (a) proximité, (b) vitesse maximale, (c) mouvement similaire, (d) constance de la vitesse et de la direction, (e) rigidité de l’objet. A partir de ces hypothèses, deux catégories de méthodes existent pour déterminer la correspondance entre les points de différentes images consécutives. Les approches déterministes consistent à évaluer et à minimiser un coût de correspondance entre les points de deux images consécutives. A chaque image, une solution unique est sélectionnée. Plusieurs auteurs traitent de ces approches. Nous pouvons citer en particulier Sethi et Jain [Sethi and Jain, 1987], Rangarajan et Shah [Rangarajan and Shah, 1991] et Veenman et al. [Veenman et al., 2001]. Les approches statistiques (ou bayésiennes) consistent à estimer, à l’aide d’une mesure de l’incertain, la posi- 383.2. Suivi de la personne tion future de l’objet. L’idée est de supposer que l’observation peut être bruitée, ce qui induit de l’incertitude. A chaque image, ces approches fournissent un ensemble de solutions plus ou moins probables. Le filtre de Kalman (décrit à la section 4.2.2) et les filtres particulaires sont des approches bayésiennes souvent utilisées pour résoudre le problème de suivi d’une personne. Objet représenté par des formes géométriques L’objectif est de suivre l’objet en calculant le mouvement d’une image à l’autre, des formes géométriques qui l’entourent. Les mouvements des formes géométriques sont généralement sous la forme de transformations, comme la translation, la rotation et l’application affine. Un exemple de transformation d’une ellipse est présenté à la figure 3.5. Figure 3.5 – Transformation paramétrique d’une ellipse. Deux catégories de méthodes peuvent résoudre le problème du suivi du mouvement des formes géométriques d’un objet. La première catégorie se fonde sur l’hypothèse que la forme d’un objet change peu au cours du temps. L’algorithme définit un modèle d’apparence de l’objet, lorsqu’il apparaît dans la scène et recherche, au cours du temps, l’emplacement de ce modèle dans les images, pour ainsi suivre l’objet. Un exemple de modèle d’apparence est montré à la figure 3.6 représentant les différentes parties du corps par des rectangles. Chaque rectangle a ses propres dimensions et une certaine position par rapport aux autres. Plusieurs algorithmes ont été développés pour coupler le modèle à un élément de l’image, comme celui de Comaniciu [Comaniciu, 2002] et Jepson et al. [Jepson et al., 2003]. L’autre catégorie de méthodes émet l’hypothèse que l’objet peut apparaître complètement différemment d’une vue à l’autre. Le modèle défini risque, dans ce cadre, de ne pas pouvoir correspondre à toutes les vues de l’objet et de ne pas le reconnaître dans une image, perdant alors son suivi. Le but est d’apprendre plusieurs vues de l’image avant de le suivre en direct, par exemple avec des SVM [Avidan, 2004]. Objet représenté par sa silhouette La représentation par silhouette permet de suivre plus finement certaines formes complexes, comme la main, la tête, les épaules, que la représentation par forme géométrique. L’idée est d’extraire pour chaque image la silhouette de l’objet. La silhouette sera alors couplée à un modèle représentant la forme de l’objet ou représentant le contour. La forme de l’objet peut être suivie de la même manière que le suivi de modèle d’apparence du paragraphe précédent. La silhouette et son modèle associé sont recherchés à chaque image. La méthode de suivi de contour consiste à déplacer itérativement le contour initial dans l’image précédente pour le faire correspondre à celui de la nouvelle image. Le suivi de contour nécessite d’avoir un recouvrement des régions de l’objet dans les deux images consécutives. 39Chapitre 3. Détecter et suivre une personne avec une caméra : état de l’art Figure 3.6 – Modèle d’apparence. 3.3 Caméra de profondeur La caméra que nous utilisons est la caméra Kinect de Microsoft, comme montré à la figure 3.7. Elle a la particularité d’être un capteur actif fonctionnant dans l’infrarouge qui reconstitue, même de nuit, la profondeur de chaque pixel. Ses caractéristiques sont les suivantes. Elle fournit 30 images par seconde. Son champ de vision est de 57˚à l’horizontale et 43˚à la verticale. La profondeur peut être reconstruite jusqu’à 8 m avec une précision de quelques centimètres qui se dégrade au-delà de 4 m. L’apparition de ce type de caméras simplifie les méthodes utilisées en vision. Les méthodes précédentes ont été développées pour des caméras fournissant une information d’intensité ou de couleur pour chaque pixel. La caméra de Microsoft, en plus de fournir l’information couleur, indique à quelle distance chaque pixel se trouve dans la scène par rapport à la caméra. Les caméras classiques ont l’inconvénient d’être dépendantes des changements de luminosité. Ainsi, la plupart des méthodes construites pour détecter les personnes sont conçues pour résoudre ce problème. La méthode de soustraction du fond, peu robuste avec des caméras classiques puisque le fond varie avec l’éclairage ambiant, est très efficace avec une image de profondeur [Shotton et al., 2013]. Caméra couleur Caméra profondeur Micro Moteur Figure 3.7 – Le capteur Kinect de Microsoft. Microsoft a développé ses propres algorithmes de détection et suivi de la personne. Leur algorithme a été pensé pour être appliqué aux jeux où la personne est face à la caméra puisqu’à 403.4. Conclusion l’origine cette caméra est un périphérique destiné à la console de jeux vidéo Xbox360. Ces algorithmes sont très robustes. L’algorithme est fondé sur le suivi d’un modèle de squelette. Le squelette continue d’être détecté, même si la personne est à moitié visible. Il repose sur une base d’apprentissage de 500 000 images. L’inconvénient de leur algorithme est qu’il fonctionne surtout si la personne est face à la caméra. De plus, si la personne est dans certaines positions, comme allongée au sol, leur algorithme ne détecte plus la personne. Il est peu robuste aux situations nouvelles n’appartenant pas à la base d’apprentissage. L’algorithme est propriétaire mais peut être utilisé via le SDK fourni par Microsoft. Nous avons fait le choix de ne pas utiliser le SDK de Microsoft pour développer une approche plus adaptée aux situations que nous souhaitons identifier tout en montrant que cet objectif peut être atteint par l’analyse de paramètres simples, sans passer par une reconstruction de la configuration 3D du squelette. 3.4 Conclusion L’un de nos objectifs, comme nous l’avons mentionné, est de développer un système peu coûteux. En d’autres termes, le système doit pouvoir être installé sur une machine à bas coût. Les algorithmes doivent être simples et réaliser le traitement en temps réel. Les méthodes comme l’extraction du squelette, par exemple, sont des méthodes très précises mais coûteuses en temps. Une des méthodes les plus classiques pour détecter la personne en temps réel, et que nous avons sélectionnée pour développer notre système, est l’apprentissage du fond. Cette méthode est considérée comme l’une des moins robustes. Mais aujourd’hui, avec l’apparition des caméras nous fournissant l’information de profondeur, la représentation du fond peut être construite sur la profondeur de chaque pixel et non plus uniquement sur la couleur, la rendant ainsi plus robuste, car n’étant plus dépendante des changements de lumière. Nous avons choisi, pour suivre l’objet, une représentation en points du corps de la personne qui a l’avantage d’être une méthode légère. 41Chapitre 3. Détecter et suivre une personne avec une caméra : état de l’art 42Chapitre 4 Application à la détection et au suivi de personnes avec une caméra RGB-D Sommaire 4.1 Détecter la personne . . . . . . . . . . . . . . . . . . . . . . . . . 43 4.1.1 Extraction et apprentissage du fond . . . . . . . . . . . . . . . . . . 44 4.1.2 Extraction du sol et changement de repère . . . . . . . . . . . . . . 44 4.1.3 Extraction des points mobiles . . . . . . . . . . . . . . . . . . . . . 46 4.1.4 Extraction des objets mobiles . . . . . . . . . . . . . . . . . . . . . 47 4.1.5 Détection de la personne . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2 Suivre la personne . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2.1 Représentation de la personne . . . . . . . . . . . . . . . . . . . . . 49 4.2.2 Suivi du centre de masse . . . . . . . . . . . . . . . . . . . . . . . . 51 4.2.3 Suivi de la distribution verticale . . . . . . . . . . . . . . . . . . . . 53 4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Dans ce chapitre, nous présentons les différentes étapes de traitement, allant de la détection de la personne, avec l’extraction des pixels mobiles, jusqu’au suivi d’une personne se déplaçant dans le champ de vision d’une caméra. Chaque étape de la détection et du suivi est schématisée sur la figure 4.1. Chaque encadré fait l’objet d’une sous section de ce chapitre. L’objectif final, de ce chapitre, est de suivre la personne à travers des paramètres simples à extraire. Nous avons choisi de suivre la personne à partir de son centre de masse et de la distribution verticale de sa silhouette. A partir de ces deux paramètres, nous pouvons déduire d’autres caractéristiques comme la vitesse verticale et la vitesse horizontale du centre de masse et le point maximum qui correspond au sommet du crâne lorsque la personne est debout. 4.1 Détecter la personne Il s’agit dans cette section de détecter la personne à partir de l’image de profondeur fournie par la caméra. Dans une image de profondeur, chaque pixel représente un point dans l’espace 3D donné dans le système de coordonnées de la caméra. Les points du plan image peuvent être projetés dans ce système de coordonnées grâce aux paramètres optiques de la caméra. Ces paramètres sont des données constructeur propres à chaque caméra. 43Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D Extraction fond Detection points mobiles Detection de la personne Regroupement en objet Detection personne à suivre Detection sol Extraction centre de masse Suivi de la personne Projection repère sol Extraction distribution verticale Figure 4.1 – Étapes pour détecter la personne du fond et la suivre dans le temps. 4.1.1 Extraction et apprentissage du fond La première étape pour détecter la personne dans le champ de vision de la caméra est d’identifier les éléments fixes de la scène, que nous appelons le fond, pour pouvoir en déduire, par soustraction, les points appartenant à la silhouette de la personne. Tout d’abord, chaque pixel F0(x, y) représentant la carte de profondeur du fond au temps t = 0 est initialisé avec une valeur arbitraire nommée M axV alue et fixée à 12 mètres. Ensuite la méthode running average [Gómez-Conde, 2011] est utilisée pour apprendre le fond en moyennant, à chaque pas de temps, les distances pour chaque point de l’image. L’utilisation d’un poids α permet de donner plus d’importance au passé. La formule de mise à jour est la suivante : Ft(x, y) = (1 − α)Ft−1(x, y) + αIt(x, y) avec F la matrice des distances cumulées, It(x, y) l’image courante et α le poids. Le poids α est fixé à 0,0001. Pour les points non reconstruits (comme dans le cas des surfaces réfléchissantes), la carte de profondeurs F n’est simplement pas mise à jour et reste égale à M axV alue de façon à permettre la détection des personnes devant les surfaces réfléchissantes. Cette méthode permet de traiter le problème du fond non stationnaire. Quand un objet (comme une chaise) est déplacé, le fond est progressivement mis à jour. Un certain temps est nécessaire pour apprendre le fond. Afin d’accélérer cet apprentissage, il est possible d’initialiser α à 1, pour le faire décroitre ensuite progressivement jusqu’à 0,0001. Hormis cette phase initiale d’apprentissage du fond, mise en place pour faciliter les expérimentations, le système s’adapte automatiquement aux changements dans la scène. 4.1.2 Extraction du sol et changement de repère L’objectif de cette étape est de permettre de faire, par la suite, des calculs indépendants de la position de la caméra. Les coordonnées 3D des points de l’image sont au départ calculées dans le système de coordonnées de la caméra dont l’origine est le centre optique. Afin d’être capable de mesurer le déplacement au sol de la personne et la hauteur des points extraits, nous souhaitons travailler dans un système de coordonnées aligné sur le sol. Pour effectuer ce changement de repère, nous avons besoin d’extraire le sol. Le système de coordonnées du sol est calculé juste après l’initialisation du fond, sans nécessiter l’utilisation d’une procédure de calibration spécifique. Etape 1 : Redressement de la scène Dans le repère de la caméra, nous désignons par X l’axe horizontal, Y l’axe vertical et Z la profondeur. Les points 3D du fond subissent tout d’abord une rotation autour de l’axe X en 444.1. Détecter la personne utilisant l’angle γ d’inclinaison de la caméra obtenu à partir de son accéléromètre. Cette première transformation permet d’avoir un axe y proche de la verticale. L’équation de redressement des points Pi est la suivante : P 0 i = RγPi avec Rγ =   1 0 0 0 cos(γ) −sin(γ) 0 sin(γ) sin(γ)   . Etape 2 : Sélection des points bas Un nombre arbitraire de points sont ensuite sélectionnés parmi les points les plus bas. L’hypothèse est que la majorité de ces points appartiennent au sol. Nous prenons ainsi les 15 000 points les plus bas qui serviront à calculer l’équation du plan du sol. Etape 3 : Calcul de l’équation du sol Le sol est assimilé à un plan d’équation ax+by+cz+d = 0 dont nous calculons les paramètres a, b, c et d avec la méthode des moindres carrés. En rappelant que l’axe y est proche de la verticale suite à l’étape 1, nous pouvons considérer que b est non nul puisque l’axe y n’appartient pas au plan. L’ensemble des coefficients de l’équation du plan étant définis à une constante multiplicative près nous pouvons fixer b = 1. Chaque point P 0 i sélectionné à l’étape 2 nous donne donc une équation du type : xia + zic + 1d = −yi . Le système d’équations surdimensionné Ax = B où A =   x1 z1 1 ... xN zN 1   , x =   a c d   et B =   −y1 ... −yN   peut être résolu avec la méthode des moindres carrés qui nous donne la solution x = (A T A) −1A T B minimisant le résidu r = B − Ax. 45Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D Etape 4 : Construction du repère sol Il s’agit enfin de construire le système de coordonnées du sol (Og, ~ux, ~uy, ~uz). Une origine arbitraire Og(0, y, 0) est définie telle que Og appartienne au plan calculé précédemment, ce qui nous donne : Og =   0 −d 0   . Un premier axe est construit également arbitrairement en prenant un second point sur le sol de coordonnées (1, yx, 0) ce qui nous donne le vecteur directeur ~ux = αx   1 −a 0   . L’axe Yg est défini par le vecteur normal au plan ~uy = αy   a 1 c   . L’axe Zg est enfin construit en faisant le produit vectoriel entre ux et uy : ~uz = αz(~ux ∧~uy), soit ~uz = αz   −ac −c a 2 + 1   . Les nombres αx, αy et αz sont des constantes de normalisation. Projection d’un point dans le repère sol Les points 3D P(x, y, z) peuvent, après rotation suivant l’angle γ comme montré à l’étape 1, être projetés dans le système de coordonnées du sol (Og, ~ux, ~uy, ~uz) en réalisant les produits scalaires entre le vecteur (OgP 0 ) et les vecteurs directeurs du repère. Les coordonnées P 00 de P dans le repère sol sont données par : P 00 =   1αx −aαx 0 aαy 1αy cαy acαz cαz (a 2 + 1)αz   (P 0 − Og) où P 0 = RγP. Un exemple d’extraction du sol est montré sur la figure 4.2. 4.1.3 Extraction des points mobiles Dans cette étape, nous cherchons à identifier les points mobiles de l’image, c’est-à-dire les points occupés par la personne. Pour cela, à chaque instant, le fond (l’image des distances du fond) est soustrait à l’image courante des distances, pour ne garder que les points ayant une distance plus courte dans l’image courante que dans l’image de fond. Pour éliminer le bruit, c’est-à-dire les points détectés comme mobiles mais ne l’étant pas, un filtre Erosion-Dilatation est utilisé. Tout d’abord l’étape d’érosion permet d’éliminer tous les points mobiles proches d’un point considéré comme appartenant au fond. Ainsi, tous les 464.1. Détecter la personne Figure 4.2 – L’extraction du sol est représentée en rouge. contours des objets seront éliminés et le bruit également. La figure 4.3a) est un exemple de représentation des points mobiles et fixes où sera appliqué le filtre Erosion-Dilatation. Sur cette figure les cases en bleu représentent les points détectés comme mobiles et les points en vert représentent le fond. Le filtre érosion est appliqué à la figure 4.3a). Le résultat est montré en figure 4.3b). Toutes les cases bleues, ayant une case verte dans leur voisinage, deviennent vertes. Dans l’exemple, un voisinage de taille 1 est sélectionné, c’est-à-dire seuls les points juxtaposés sont pris en compte. La deuxième étape est le filtre dilatation consistant à transformer tous les points du fond, proches des points mobiles, en des points mobiles. A la figure 4.3b) est appliqué le filtre dilatation permettant d’obtenir la figure 4.3c). Chaque case verte juxtaposée à une case bleue devient bleue. Cela permet aux objets mobiles de récupérer leurs contours. Dans notre algorithme la taille du voisinage est de 2. 4.1.4 Extraction des objets mobiles Dans cette section, l’objectif est de regrouper les points mobiles appartenant à un même objet, ainsi il sera possible de distinguer plusieurs objets dans une même scène. Pour cela, nous utilisons un étiquetage des composantes connexes [Suzuki et al., 2003]. Cette méthode consiste à affecter une étiquette (un nombre) différente à tous les points détectés comme mobiles. Dans la figure 4.4a), les cases colorées correspondent à des points détectés comme mobiles. Ainsi dans la figure 4.4b), l’algorithme assigne un nombre différent à chaque point mobile. Ensuite, la technique consiste à regarder pour chaque point p, si un de ses voisins a un nombre plus petit. Si ce cas est avéré, l’étiquette du voisin le plus petit est attribuée au point p. Cette opération est montrée à la figure 4.4c). Chaque point prend à l’étape t+2 le nombre le plus petit parmi ses voisins de l’étape t+1. Cette commande est répétée jusqu’à ce qu’il n’y ait plus de changement dans l’affectation des nombres aux points de l’image. La figure 4.4d) est la dernière étape de l’algorithme, car les étiquettes des points ne changent plus. Ainsi, tous les points ayant un même nombre seront regroupés comme étant un même objet mobile. Dans la figure 4.4d), l’algorithme a détecté deux objets différents, un objet avec les points portant le numéro 1 et un autre objet avec les points ayant le numéro 7. Cet algorithme pose la question du nombre de voisin à prendre en compte. Est-ce qu’il faut se limiter aux points juxtaposés de p ou alors déterminer un voisinage plus grand ? Un des problèmes, à ne considérer que les voisins juxtaposés du point (c’est-à-dire avec un voisinage de 47Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D Erosion Dilatation a) b) c) Figure 4.3 – a) Les cases bleues représentent des points mobiles et les cases vertes les points appartenant au fond, b) le filtre érosion est appliqué, c) le filtre dilatation est appliqué. 1 2 3 5 6 4 7 8 9 10 11 12 151413 1716 1819 1 2 3 5 6 4 7 8 9 10 11 12 151413 1716 1819 1 2 3 5 6 4 7 8 9 10 11 12 151413 1716 1819 1 2 3 5 6 4 7 8 9 10 11 12 151413 1716 1819 1 2 3 5 6 4 7 7 9 11 111413 1 2 3 5 6 4 7 8 9 10 11 12 151413 1716 1819 1 1 2 2 4 1 7 7 7 9 9 1111 1 2 3 5 6 4 7 8 9 10 11 12 151413 1716 1819 1 1 1 1 1 1 7 7 7 7 7 7 777 77 7 7 étape 1 étape n 2 étape 13 131314 a) b) d) c) Figure 4.4 – a) Les cases colorées représentent des points mobiles, b) l’algorithme assigne un nombre aux points mobiles, c) les points avec un nombre plus grand que ses voisins sont modifiés, d) le résultat final est atteint. 484.2. Suivre la personne taille 1), est qu’il est possible que certaines parties ne soient pas détectées comme appartenant au même objet. Par conséquent, la jambe ou le bras peut être identifié comme un objet et le reste du corps comme un autre objet. La seconde solution est de prendre un voisinage de taille plus importante. L’algorithme avec un voisinage de taille 2 considérera les points positionnés en p−2, p − 1, p + 1 et p + 2. La contrepartie est alors le risque d’intégrer des points n’appartenant pas à l’objet. Pour illustrer ces deux méthodes, nous pouvons donner l’exemple suivant. La figure 4.4 montre le cas où nous considérons seulement les points juxtaposés. Deux objets sont alors détectés en figure 4.4d). Un voisinage de taille 3 modifierait le résultat, les deux blocs de points mobiles seraient rassemblés en un seul objet. Après une analyse qualitative, en variant la taille du voisinage, un voisinage de 3 est sélectionné pour notre algorithme. 4.1.5 Détection de la personne Après l’étape précédente, l’algorithme est capable de fournir tous les groupes d’objets mobiles visibles dans la scène. Nous faisons l’hypothèse qu’il n’y a qu’une personne dans la scène. Donc parmi les objets mobiles se trouvent la personne à suivre et des objets qui ont été déplacés (tels qu’une chaise, une porte). Le groupe correspondant à la personne à suivre est récupéré en prenant le groupe ayant le nombre de points mobiles le plus important. Comme nous l’avons précisé précédemment, le fond ne cesse d’être appris ce qui permet aux objets déplacés de revenir dans le fond au bout d’un certain temps. Par contre, le même effet se produit si une personne reste inactive pendant un certain temps. Pour éviter que la personne n’intègre le fond, l’algorithme d’apprentissage du fond ne prend pas en compte les pixels détectés comme mobiles et appartenant à la personne suivie. 4.2 Suivre la personne L’objectif de cette étape est de décrire la méthode utilisée dans l’algorithme pour suivre la personne au cours du temps. Comme précisé au chapitre précédent, la méthode pour suivre une personne découle du choix pris pour la représenter. Nous introduisons dans cette section une partie concernant le choix de la représentation, pour ensuite décrire la méthode pour obtenir cette représentation au cours du temps. 4.2.1 Représentation de la personne Comme nous l’avons présenté dans le chapitre précédent, plusieurs représentations de la personne sont possibles, par des points, par un squelette, par une ellipse représentant la totalité du corps ou une pour chaque partie du corps, etc. Notre objectif était de trouver une représentation assez légère en temps de calcul pour que le suivi se fasse en temps réel. Les étapes précédentes de détection de la personne nous permettent d’obtenir une série de points 3D la composant. Nous n’avons pas besoin de suivre très précisément les différentes parties du corps, une analyse globale de la personne est suffisante. Nous pouvons réduire les paramètres à un ensemble d’éléments descriptifs de la distribution verticale du corps. Un intérêt majeur de travailler avec une représentation simple est qu’elle sera moins sujette à variations et donc robuste à la diversité des situations. Le suivi des déplacements du corps dans l’espace peut être une tâche assez complexe, car chaque partie du corps peut faire l’objet d’une analyse à part entière. L’article de Saunders et al. [Saunders et al., 1953] traite du sujet des déplacements du corps en mouvement. Selon eux, 49Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D l’analyse du corps en mouvement peut être réduite à la simple analyse du centre de masse en mouvement. Plus précisément, les déplacements horizontaux et verticaux du corps, lorsqu’une personne marche, peuvent être analysés en regardant les déplacements du centre de masse. La figure 4.5 et 4.6 représentent les déplacements horizontaux et verticaux du centre de masse quand une personne marche d’après l’article de Saunders et al.. Ces déplacements forment des courbes sinusoïdales d’une certaine amplitude. Ce sont ces mécanismes effectués ainsi qui permettent de minimiser la dépense énergétique au cours de la marche. Si les déplacements du centre de masse d’une personne ne respectent pas les formes et l’amplitude habituelle des courbes, la marche est alors dite pathologique. La trajectoire du centre de masse à elle seule permet de fournir de nombreuses informations sur le corps en mouvement. Figure 4.5 – Déplacement horizontal théorique du centre de masse. Figure 4.6 – Déplacement vertical théorique du centre de masse. Pour représenter le corps de la personne et le suivre au cours du temps, nous avons choisi de coupler l’analyse de la distribution verticale et de la trajectoire du centre de masse pour représenter le corps durant le cycle de déplacement. 504.2. Suivre la personne 4.2.2 Suivi du centre de masse Calcul du centre de masse Au début de cette étape, la personne à suivre est détectée. La personne extraite avec l’algorithme est composée d’un ensemble de points 3D. Dans notre algorithme le centre de masse est calculé comme étant un centre géométrique de la silhouette, il s’agit de l’emplacement moyen, de tous les éléments mobiles, calculé à partir de la formule suivante : Cm(x, y, z) = ( 1 N X i xi , 1 N X i yi , 1 N X i zi) où xi ,yi ,zi sont les coordonnées du i eme points 3D et N est le nombre de points mobiles. La trajectoire du centre de masse d’une personne marchant perpendiculairement à la caméra, obtenue avec notre méthode, est montrée à la figure 4.7. La trajectoire horizontale de la figure 4.7(b) est difficilement interprétable. La trajectoire verticale de la figure 4.7(a) est, en revanche, similaire à la courbe théorique sinusoïdale que Saunders et al. ont décrit et qui est représentée à la figure 4.6. De plus, Saunders et al. spécifient que l’amplitude bas-haut des déplacements du centre de masse est approximativement 1,08 pouce (soit 4,8 cm), ce qui correspond à peu près à l’amplitude trouvée avec nos courbes. 600 650 700 750 800 850 900 950 1000 1050 28 28.5 29 29.5 30 30.5 31 Y (mm) Temps (s) (a) Déplacement vertical du centre de masse. -2500 -2400 -2300 -2200 -2100 -2000 -1900 -1800 -1500 -1000 -500 0 500 1000 1500 Z (mm) X (mm) (b) Déplacement horizontal du centre de masse. Figure 4.7 – Déplacement du centre de masse extrait à partir de notre algorithme pour une personne marchant en ligne droite perpendiculairement à la caméra. La montée et la descente en début et fin de trajectoire correspondent aux entrées et sorties de la personne dans le champ de vision de la caméra. Description de la trajectoire du centre de masse L’amplitude de la courbe verticale du centre de masse est accentuée par un artefact lié aux occlusions périodiques faisant varier la répartition du nombre de points visibles appartenant à la personne. La figure 4.8(a) montre que les amplitudes de la courbe du centre de masse sur l’axe vertical sont dépendantes de la variation du nombre de pixels mobiles. Sur cette figure, les maxima locaux de la trajectoire du centre de masse, pour une personne marchant perpendiculairement à la caméra, correspondent aux instants où la personne a moins de pixels mobiles détectés. La raison est qu’à cet instant la personne est sur un pied d’appui et qu’une jambe est cachée par l’autre. Quand la personne est en double appui, les deux jambes sont visibles et il y a donc plus de pixels mobiles détectés dans la partie basse de la silhouette. 51Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D Ensuite la trajectoire du centre de masse, d’une personne marchant cette fois en direction de la caméra, a été tracée sur le même graphe que la courbe représentant le nombre de pixels mobiles. Le résultat est montré à la figure 4.8(b). Le nombre de pixels mobiles augmente de plus en plus parce que la personne s’approche de la caméra et occupe donc plus de place dans le champ de vision. La trajectoire du centre de masse s’élève lorsque la personne se rapproche de la caméra. Ceci est dû au fait que, la caméra étant positionnée en hauteur et plongeant vers le bas, la zone supérieure du corps de la personne est de plus en plus visible au fur et à mesure que la personne s’approche de la caméra. La trajectoire du centre de masse sur l’axe vertical forme une trajectoire sinusoïdale mais avec une amplitude plus petite comparée à la situation où la caméra est perpendiculaire à la personne comme à la figure 4.8(a). Dans le cas où la caméra est face à la personne, l’artefact du nombre de points mobiles n’intervient pas. Comme on peut le voir sur la figure 4.8(b), la dépendance entre nombre de points et maxima locaux sur la courbe du centre de masse n’est pas évidente. Ceci montre que l’artefact, dû aux occlusions de profil, amplifie le mouvement vertical du centre de masse mais n’est pas le seul facteur à l’origine de ce mouvement et, lorsque la caméra est de face, c’est bien le déplacement vertical de la personne qui est observé. 0.58 0.6 0.62 0.64 0.66 0.68 34 34.5 35 35.5 36 36.5 37 5000 10000 15000 20000 25000 Y Nombre de points Temps (s) Nombre de points Y (a) Une personne marche perpendiculairement à la caméra. 0.58 0.6 0.62 0.64 0.66 0.68 39 39.5 40 40.5 41 41.5 5000 10000 15000 20000 25000 Y Nombre de points Temps (s) Nombre de points Y (b) Une personne marche face à la caméra. Figure 4.8 – Comparaison entre la trajectoire du centre de masse et le nombre de pixels mobiles appartenant à une personne. Lissage de la trajectoire du centre de masse Les trajectoires, sur l’axe vertical du centre de masse que nous obtenons, sont filtrées. Deux méthodes pour filtrer la trajectoire ont été implémentées, un filtre passe-bas et un filtre de Kalman. Notre filtre passe-bas moyenne chaque centre de masse gt avec les deux centres de masse précédents gt−1, gt−2 et les deux centres suivants gt+1, gt+2. Cette méthode permet de filtrer la courbe. Le résultat du lissage de la courbe 4.9(a) avec le filtre passe-bas est montré à la figure 4.9(b). Le filtre de Kalman [Rabiner, 1989] est un cas particulier du filtre bayésien général, estimant l’état d’un système à partir d’une série d’observations bruitées. Dans notre cas, les observations sont les positions 3D du centre de masse. Le modèle est paramétré par, d’un côté, l’incertitude de la prédiction et, de l’autre, par l’incertitude de l’observation. Le bruit relatif R donné à l’observation, comparé au bruit de la prédiction Q, permet de définir l’inertie du filtre. Nous 524.2. Suivre la personne utilisons un filtre simple défini par : xt+1 = xt + Q gt = xt + R où gt représente l’observation à l’instant t (centre de masse calculé sur l’image t) et xt représente le résultat du filtre. Les bruits Q et R du filtre sont réglés manuellement. L’inférence est réalisée en deux étapes avec les équations de Kalman. Prédiction L’étape de prédiction permet d’estimer la position à l’instant t à partir des observations précédentes (des instants 1 à t − 1). xt|t−1 = F xt−1|t−1 Pt|t−1 = F Pt−1|t−1F T + Q Dans notre cas, la fonction de transition F est égale à la matrice identité. xt|t−1 représente l’état prédit sans prendre encore en compte l’observation à l’instant t et Pt|t−1 représente la covariance de la prédiction. Correction L’étape de correction consiste à mettre à jour la prédiction en prenant en compte l’observation à l’instant t. yt = gt − Hxt|t−1 St = HPt|t−1HT + R Kt = Pt|t−1HT S −1 t xt|t = xt|t−1 + Ktyt Pt|t = (I − KtH)Pt|t−1 . Dans notre cas, la fonction d’observation H est égale à la matrice identité. yt l’innovation, St la covariance de l’innovation et Kt le gain de Kalman sont des variables intermédiaires utilisées pour calculer l’état xt|t et la covariance Pt|t a posteriori en intégrant l’observation gt . Le résultat du lissage de la courbe 4.9(a) avec le filtre de Kalman est montré à la figure 4.9(c). La comparaison visuelle des deux filtres montre que le filtre de Kalman est moins sensible aux valeurs extrêmes. Paramètres dynamiques En plus de la position du centre géométrique, nous utilisons les paramètres représentatifs de son déplacement à savoir sa vitesse horizontale et verticale. 4.2.3 Suivi de la distribution verticale Pour compléter la représentation de la personne, nous ajoutons deux autres paramètres représentatifs de la distribution verticale qui sont l’écart type et le maximum des coordonnées verticales des points mobiles. 53Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D -1550 -1500 -1450 -1400 -1350 -1300 -1250 -1200 -1150 -1100 -1050 -1000 27.5 28 28.5 29 29.5 30 30.5 Y (mm) Temps (s) -1350 -1300 -1250 -1200 -1150 -1100 -1050 27.5 28 28.5 29 29.5 30 30.5 Y (mm) Temps (s) (a) (b) -1400 -1350 -1300 -1250 -1200 -1150 -1100 -1050 27.5 28 28.5 29 29.5 30 30.5 Y (mm) Temps (s) (c) Figure 4.9 – a) Courbe non lissée, b) courbe lissée avec le filtre passe-bas, c) courbe lissée avec le filtre de Kalman. L’écart type des coordonnées des points 3D mobiles, composant le corps de la personne est calculé sur l’axe y par la formule suivante : σy = sPN i=1 [yi − Cm(y)]2 N avec N le nombre de points composant le corps de la personne et Cm(y) la coordonnée sur l’axe y du centre de masse. Un exemple de variation de la distribution verticale pour une personne qui marche est illustré à la figure 4.10. 1.5 2 2.5 3 3.5 4 4.5 5 5.5 6 33.5 34 34.5 35 35.5 36 36.5 37 Ecart type Temps (s) Figure 4.10 – Trajectoire de l’écart type vertical pour une personne qui marche. 544.3. Conclusion Le point maximum des points mobiles sur l’axe vertical y est calculé par la formule suivante : Ymax = maxX N i=1 yi avec N le nombre de points composant le corps de la personne et yi la coordonnée sur l’axe y du point mobile i. Tout comme pour le centre de masse, la trajectoire du point maximum est lissée par un filtre de Kalman. La figure 4.11(a) représente la trajectoire du point maximum lorsqu’une personne marche et la figure 4.11(b) correspond à sa trajectoire filtrée. Nous pouvons voir que l’amplitude des oscillations du point maximum est moins grande que celle des oscillations du centre de masse représenté à la figure 4.7(a). 1250 1300 1350 1400 1450 1500 1550 1600 1650 1700 1750 33.5 34 34.5 35 35.5 36 36.5 37 Y (mm) Temps (s) (a) Trajectoire du point maximum sur l’axe vertical. 1250 1300 1350 1400 1450 1500 1550 1600 1650 1700 33.5 34 34.5 35 35.5 36 36.5 37 Y (mm) Temps (s) (b) Trajectoire du point maximum lissée sur l’axe vertical. Figure 4.11 – Comparaison entre la trajectoire du point maximum filtrée et non filtrée pour une personne qui marche. 4.3 Conclusion L’objectif pour détecter et suivre la personne était d’utiliser des algorithmes simples. Ainsi, notre méthode nous permet un suivi de la personne en temps réel. Nous avons opté pour une représentation de la personne à travers 5 paramètres faciles à extraire qui sont : — la position du centre de masse ; — la vitesse verticale du centre de masse ; — la vitesse horizontale du centre de masse ; — la dispersion verticale de la silhouette ; — le point maximum de la silhouette. Les traitements de plus haut niveau qui sont décrits par la suite (l’analyse des paramètres de la marche et la détection de l’activité d’une personne) se basent sur l’analyse d’un ou de l’ensemble de ces paramètres. 55Chapitre 4. Application à la détection et au suivi de personnes avec une caméra RGB-D 56Chapitre 5 Mesurer à domicile les paramètres de la marche Sommaire 5.1 Définition et description de la marche . . . . . . . . . . . . . . . 58 5.1.1 Définition de la marche . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.1.2 Description du cycle de la marche . . . . . . . . . . . . . . . . . . . 58 5.2 Indicateurs de l’analyse de la marche . . . . . . . . . . . . . . . . 59 5.2.1 Paramètres spatio-temporels . . . . . . . . . . . . . . . . . . . . . . 59 5.2.2 Paramètres cinématiques . . . . . . . . . . . . . . . . . . . . . . . . 60 5.2.3 Paramètres dynamiques . . . . . . . . . . . . . . . . . . . . . . . . 61 5.3 Sélection des indicateurs . . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.1 Troubles de la marche et risques de chute . . . . . . . . . . . . . . . 64 5.3.2 Troubles de la marche et risques d’hospitalisation . . . . . . . . . . 64 5.3.3 Troubles de la marche et troubles cognitifs . . . . . . . . . . . . . . 64 5.4 Extraction des indicateurs . . . . . . . . . . . . . . . . . . . . . . . 65 5.4.1 Longueurs de pas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 5.4.2 Cadence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.4.3 Vitesse de marche . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.4.4 Résultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 5.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 L’être humain effectue en moyenne 5 000 à 15 000 pas par jour soit 2 à 5 millions par an. La marche s’acquiert au travers d’un processus d’apprentissage qui est qualifié de difficile selon Viel [Viel, 2000]. L’apprentissage de la marche prend plusieurs années, pour être par la suite automatique. Le but pour les nouveaux apprenants est d’acquérir les différentes phases composant la marche, de maintenir leur équilibre et de s’adapter aux contraintes de l’environnement extérieur tout en réduisant le coût énergétique. L’objectif dans ce chapitre est de décrire ce qu’est la marche. Nous commençons par décrire la marche dans sa globalité en analysant les différentes phases qui la constituent. Puis une seconde section abordera la façon dont la marche peut être analysée en énumérant différents indicateurs utilisés pour la décrire. Cette section est inspirée des thèses de Gillet en 2004 [Gillet, 2004] et Fusco en 2008 [Fusco, 2008]. Après avoir brossé un panorama des indicateurs existants pour analyser la marche, nous proposons de sélectionner certains paramètres pertinents pour l’étude de la fragilité. Enfin, nous décrivons l’algorithme qui permet d’extraire ces paramètres. 57Chapitre 5. Mesurer à domicile les paramètres de la marche Figure 5.1 – Représentation du cycle de la marche selon Viel (2000). 5.1 Définition et description de la marche 5.1.1 Définition de la marche La marche humaine « normale » est définie par Perry[Perry and Davids, 1992] comme un phénomène complexe impliquant la coordination de mouvements de rotations des segments corporels pour maintenir l’équilibre du corps pendant son déplacement vers l’avant. Chaque être humain a sa propre façon de marcher, sa propre démarche. Malgré tout, la marche peut être découpée en séquences de mouvements cycliques, qui sont identifiables chez tous les humains, pour les deux sexes et âges confondus, et qui apparaissent à chaque pas. La description de la marche, ci-après, concerne la marche « normale », par opposition à la marche pathologique. 5.1.2 Description du cycle de la marche Un cycle de marche (une foulée) commence par le contact initial d’un pied au sol (par le talon) et se termine par le contact suivant du même pied (par le même talon). Le cycle de la marche est lui-même découpé en phases, permettant ainsi de poser les bases pour analyser la marche d’une personne. Selon le découpage de Viel [Viel, 2000], le cycle de marche est découpé principalement en deux phases, une phase d’appui et une phase d’oscillation comme illustré à la figure 5.1. La phase d’appui (droite ou gauche) dure 60 % du cycle et est définie comme la phase débutant lorsque le pied (droit ou gauche) est en contact avec le sol. La phase d’oscillation (droite ou gauche) dure 40 % du cycle et est définie comme la phase débutant lorsque la jambe (gauche ou droite), en l’air, se déplace vers l’avant et se termine lorsque le talon reprend contact avec le sol. Un découpage plus fin du cycle peut être donné à l’intérieur des phases d’appui et d’oscillation. 585.2. Indicateurs de l’analyse de la marche Phase d’appui Le double appui de réception Lors de cette phase, les deux pieds sont en contact avec le sol. Cette phase commence à 0 % du cycle avec le contact initial du talon sur le sol et se termine lorsque les orteils controlatéraux se soulèvent à 10 % du cycle. Le rôle de cette phase est de diriger le mouvement du corps vers l’avant et vers le côté lorsque le pied controlatéral quitte le sol. La phase d’appui unilatéral Après la phase de double appui de réception se produit la phase d’appui unilatéral qui dure environ 40 % du cycle. Lors de cette phase, un seul membre inférieur est en appui. La phase commence à 10 % du cycle avec le décollement des orteils controlatéraux et se termine à environ 50 % du cycle avec le contact du talon controlatéral. Cette période permet la progression du corps en avant par le pied en appui. Le double appui de propulsion Tout comme la phase de double appui de réception, les deux pieds sont en contact avec le sol. Cette phase commence lors du contact controlatéral à environ 50 % du cycle et se finit à 60 % du cycle avec le décollement des orteils du pied en appui. Le but de cette phase est de propulser le corps vers l’avant, grâce au transfert de poids vers la jambe controlatérale. Phase d’oscillation Durant cette phase, le membre oscillant ne décolle que très légèrement les orteils (1,29 cm) puis le talon frôle la surface du sol d’environ 1 cm. Habituellement, cette phase n’est pas dé- coupée plus finement. Nous pouvons tout de même noter que, lors de cette période, une phase d’accélération et une phase de décélération peuvent être distinguées. La phase d’accélération commence lorsque le pied décolle du sol et se termine lorsque les deux pieds se croisent. Ensuite une phase de décélération est observée dans laquelle le membre oscillant ralentit dans le but de préparer le prochain contact. 5.2 Indicateurs de l’analyse de la marche Pour analyser la marche d’une personne, différentes variables peuvent être prises en compte selon le but de l’analyse. Les indicateurs peuvent être regroupés selon trois catégories. 5.2.1 Paramètres spatio-temporels Tout d’abord, les paramètres spatio-temporels sont couramment étudiés, car ils informent sur les caractéristiques globales de la marche, c’est-à-dire qu’ils informent sur le déroulement de la marche dans le temps et l’espace. Les paramètres spatio-temporels ont la particularité de prendre des valeurs variables selon le sexe et l’âge de la personne. Principaux paramètres spatiaux Les paramètres souvent évalués sont la longueur du pas, la largeur du pas, la longueur et largeur d’enjambée et, l’angle du pas. Ces paramètres ont une définition parfois différente selon les articles. Il n’y a pas vraiment de consensus en analyse de la marche. Nous proposons ici des définitions inspirées de ce qui est le plus couramment proposé et nous reprenons également la thèse de Faivre de 2003 qui propose un lexique terminologique [Faivre, 2003]. 59Chapitre 5. Mesurer à domicile les paramètres de la marche La longueur du pas (droit pour notre exemple) correspond à la distance entre les deux talons lors du temps du double appui de réception (double appui de réception droit dans notre exemple). La largeur du pas est définie comme la distance entre la ligne de progression (ligne traversant tous les pas effectués par la personne) et le point médian du talon. L’enjambée correspond à la succession de deux pas. La longueur d’enjambée est alors définie comme la somme algébrique des longueurs de deux pas successifs. La largeur d’enjambée quant à elle est déterminée par la somme algébrique de la largeur de deux pas successifs. Ces paramètres sont exprimés en mètres. L’angle du pas, exprimé en degrés, correspond à l’angle formé entre la ligne de progression et le point médian du talon. Tous ces paramètres sont représentés à la figure 5.2. Longueur pas droit Longueur pas gauche Ligne de progression Longueur d'enjambée Largeur pas droit Angle pas Largeur pas gauche Largeur d'enjambée + + Figure 5.2 – Représentation des paramètres spatiaux. Principaux paramètres temporels Les paramètres souvent évalués sont la cadence (la fréquence), la vitesse de marche, le temps d’appui bipodal et unipodal (ou temps d’oscillation). Tout comme les paramètres spatiaux, les définitions de chaque terme ne sont pas des définitions « universelles ». La cadence correspond à la vitesse de marche en fonction du nombre de pas. Il s’agit de la fréquence à laquelle une personne marche. Le terme « fréquence » est d’ailleurs souvent employé à la place de « cadence ». La cadence est calculée comme le nombre de pas par minute ou par seconde. La vitesse de marche correspond à la relation mathématique entre la cadence (enjambées/min) et la longueur d’enjambée (en mètre). La vitesse de marche est exprimée en mètre par seconde. La formule est donc : Vitesse de marche = (Longueur × Cadence)/120 Bien souvent dans la réalité, la vitesse de marche est obtenue en chronométrant le temps mis par le sujet pour parcourir une distance donnée. Le temps d’appui bipodal est la durée moyenne des temps de double appui lors d’un cycle de la marche (pour rappel le cycle de marche correspond au moment entre le contact initial du talon et le contact suivant du même talon). Le temps d’appui unipodal est la durée moyenne du temps d’appui unilatéral lors d’un cycle de marche droit ou gauche. Ce temps est égal au temps d’oscillation du pied controlatéral. Les temps d’appui bipodal et unipodal sont exprimés en secondes ou en % du cycle de marche. 5.2.2 Paramètres cinématiques La deuxième catégorie correspond aux paramètres cinématiques qui sont des variables fré- quemment étudiées, car elles reflètent le mouvement des membres inférieurs au cours de la marche. 605.2. Indicateurs de l’analyse de la marche Il s’agit d’analyser l’aspect de la marche. Les paramètres correspondent aux angles permettant d’analyser la flexion de la cheville, la flexion du genou et la flexion de la hanche. La flexion de la cheville est analysée en observant l’angle formé entre le pied et le tibia (os du membre inférieur). La flexion du genou correspond à l’angle entre le tibia et le fémur (os de la cuisse). Et la flexion de la hanche représente l’angle formé entre le fémur et le bassin. Ces angles sont représentés à la figure 5.3. (a) Angle entre le pied et le tibia. (b) Angle entre le tibia et le fé- mur. (c) Angle entre le fémur et le bassin. Figure 5.3 – Représentation des paramètres cinématiques. 5.2.3 Paramètres dynamiques L’analyse dynamique constitue l’étude des forces et moments internes qui engendrent le mouvement. L’utilisation de la technique de l’électromyographie décrite dans la section 1.2.1 permet cette analyse. Mais celle-ci est invasive, elle requiert de poser des capteurs sur les muscles. Pour faciliter l’analyse dynamique, il est courant d’étudier les forces et les moments externes à travers l’analyse de l’interaction du pied avec le sol. Ainsi, les forces de réaction du sol et les pressions plantaires permettent une évaluation du pied. Les forces de réaction du sol Les forces de réaction du sol sont mesurées lors de la réception et la propulsion des pieds durant la marche. La force de réaction correspond à un vecteur se divisant selon trois axes d’après Kirtley [Kirtley, 2006], un axe vertical, antéro-postérieur et média-latéral. Composante verticale La composante verticale correspond à la force décrite à la figure 5.4(a). Il s’agit de la composante où les forces ont le plus d’amplitude. Lors d’un cycle de la marche, la courbe de cette composante évolue en forme de « M » comme représentée en bleue à la figure 5.5. Les deux pics de cette courbe représentent les phases de réception et de propulsion. Lors de la phase d’oscillation, le pied n’est plus en contact avec le sol donc la force de réaction est nulle. Composante antéro-postérieure La composante antéro-postérieure correspond à la force décrite à la figure 5.4(b). Deux phases sont identifiables sur la courbe formée par cette composante 61Chapitre 5. Mesurer à domicile les paramètres de la marche lors du cycle de la marche comme montré en vert à la figure 5.5. Lors de la phase de réception, la courbe est négative, le sujet freine, donc la force est exercée vers l’arrière. La deuxième phase, la phase de propulsion, est le moment où la courbe est positive, le sujet propulse son corps vers l’avant donc la force est exercée vers l’avant. Composante média-latérale La composante média-latérale, illustrée à la figure 5.4(c), correspond aux forces qui ont le moins d’amplitude. Toutefois il est possible de constater deux phases dans la forme de la courbe des forces, comme le montre en rouge la figure 5.5. Une phase de réception très courte où la force est orientée vers l’extérieur, vers l’axe latéral. Et une phase d’appui qui dure plus longtemps et où la force est orientée vers le centre, vers l’axe médian. (a) La force verticale. (b) La force antéro-postérieure. (c) La force média-latérale. Figure 5.4 – Représentation des forces exercées lorsqu’une personne marche. Pressions plantaires Les pressions plantaires correspondent aux points d’appui sur l’ensemble de la plante du pied lors du contact avec le sol. Les points d’appuis successifs lorsque le pied est en contact avec le sol sont représentés à la figure 5.6 et inspirés selon Allard en 1996 [Allard and Blanchi, 1996]. Tout d’abord les pressions débutent au niveau de l’extérieur du talon lorsque la personne pose son talon au sol. Ensuite, la trajectoire se poursuit sur le bord externe du pied, pour se propager vers toutes les têtes métatarsiennes et aboutir au niveau de la phalange distale de l’orteil. 5.3 Sélection des indicateurs Lorsqu’une personne vieillit, sa marche est modifiée. Plusieurs changements dans la marche des personnes âgées peuvent être cités, notamment une diminution de la vitesse de la marche [Guimaraes and Isaacs, 1980], une réduction des longueurs de pas ([Guimaraes and Isaacs, 1980], [Winter et al., 1990]), une augmentation du temps de double appui [Winter et al., 1990] et une plus grande variabilité de la marche [Guimaraes and Isaacs, 1980]. Ces modifications de la marche sont considérées comme « normales », car dues à l’avancée dans l’âge. Ce qui nous intéresse dans 625.3. Sélection des indicateurs 0 200 400 600 800 1000 -200 Force (N) 0 20 40 60 80 100 % cycle de la marche Figure 5.5 – Force de réaction du sol selon l’axe vertical (bleu), antéro-postérieur (vert) et média-latéral (rouge) lors d’un cycle de marche selon Kirtley. Figure 5.6 – Trajectoire des pressions plantaires lors de la marche. 63Chapitre 5. Mesurer à domicile les paramètres de la marche cette partie, concerne les changements « anormaux » de la marche, pouvant être des indicateurs d’une augmentation de la fragilité des personnes. Dans cette section, nous présentons des articles mettant en évidence une corrélation entre une détérioration de la santé de la personne et une évolution des indicateurs de sa marche. L’analyse de ces articles nous permettra de déterminer quels sont les indicateurs pouvant informer sur l’état d’une personne indépendamment de l’âge. 5.3.1 Troubles de la marche et risques de chute En 1980, Guimaraes et al. [Guimaraes and Isaacs, 1980] ont réalisé une étude sur l’analyse de la marche en comparant deux groupes, un groupe de 30 personnes hospitalisées pour cause de chute (sans blessure particulière) et un groupe de 22 personnes de même âge se trouvant à l’hôpital mais n’ayant pas subi de chute récente. L’étude a révélé que le groupe hospitalisé, pour cause de chute, avait une vitesse de marche réduite, de plus petite longueur et largeur de pas et une augmentation dans la variabilité des fréquences de pas. En 2001, Hausdorff et al. [Hausdorff et al., 2001] reprennent l’idée d’une dégradation des paramètres chez les personnes ayant chuté et testent l’hypothèse que la prévention des chutes est possible à partir de ces paramètres. Après un an d’expérimentation, ils ont montré que les variabilités de temps des foulées et les variabilités de temps d’oscillation sont associées à une augmentation du risque de chute dans le futur. Auvinet et al. [Auvinet et al., 2003] ont mis en place en 2003 une expérimentation où 53 sujets, dont 20 étaient considérés comme le groupe des « chuteurs », devaient marcher sur un parcours de 40 mètres. Ils ont alors pu montrer que la vitesse, la fréquence et les longueurs de pas avaient des valeurs réduites pour le groupe des « chuteurs ». L’irrégularité des longueurs de pas était considérée, dans leur étude, comme une variable fiable pour prévenir les chutes. 5.3.2 Troubles de la marche et risques d’hospitalisation D’autres articles montrent l’intérêt d’étudier les paramètres spatio-temporels pour leur corrélation avec le risque d’hospitalisation. En effet, l’analyse de la vitesse de la marche serait un bon indicateur pour prédire un risque d’hospitalisation et un déclin de la santé selon Studenskiet al. [Studenski et al., 2003]. Dans cet article, les auteurs montrent que 41 % des marcheurs lents (<0.6 m/s) sont hospitalisés au moins une fois par an, tandis que seulement 26 % des marcheurs intermédiaires (0.6-1.0 m/s) et 11 % des marcheurs rapides (>1.0 m/s) sont hospitalisés. 5.3.3 Troubles de la marche et troubles cognitifs Les troubles cognitifs les plus répondus chez les personnes âgées sont regroupés sous le terme de démence. La démence est une détérioration des fonctions cognitives, provoquant un changement dans la vie de la personne et une perte d’autonomie. Les démences couramment citées sont la maladie d’Alzheimer et la maladie de Parkinson. Les désordres liés à la marche sont plus répandus chez les personnes âgées ayant des démences que chez les sujets « normaux ». Iersel et al. [Van Iersel et al., 2004] ont comparé ces deux groupes de sujets et en ont déduit que les personnes avec des démences ont une vitesse de marche plus lente, des longueurs de pas plus petites et un temps de double appui plus grand que les sujets âgés sains. La vitesse de marche plus lente chez les personnes avec des démences est mise en évidence également dans l’article de Bramell-Risberg et al. [Bramell-Risberg et al., 2005]. Plusieurs études ont également déterminé qu’un dysfonctionnement mesuré par une vitesse de marche lente peut être un indicateur de déficits cognitifs précoces ([Holtzer et al., 2006], 645.4. Extraction des indicateurs [Kuo et al., 2007], [Waite et al., 2005]). Les déficits cognitifs sont définis comme une dégradation d’un ou des processus cognitifs mais sans provoquer de perte d’autonomie de la personne. Ce trouble peut éventuellement subvenir plusieurs années avant l’apparition des démences. En sachant que les personnes âgées atteintes de démence ou présentant un déficit cognitif précoce ont une marche altérée, en comparaison aux personnes âgées sans démence et sans déficit, d’autres chercheurs se sont intéressés à l’analyse des indicateurs de la marche pouvant permettre de prévenir une éventuelle apparition de démence ou déficit cognitif dans les mois ou années qui suivent. Bien que le principal signe de démence soit un déclin cognitif, plusieurs articles montrent que des désordres moteurs sont présents au premier stade de la maladie. Selon Camicioli et al. [Camicioli et al., 1998], une marche lente pourrait précéder des déficiences cognitives. Leur expérience consistait à évaluer 85 personnes âgées saines durant 3 ans. L’objectif était de déterminer les différences motrices entre les personnes sans problème cognitif et ceux développant des détériorations cognitives, durant 3 ans. Ils remarquèrent alors que les 18 sujets, développant des troubles cognitifs, avaient un ralentissement moteur (constat à travers le temps mis pour parcourir une certaine distance). Ces différentes études indiquent que l’analyse de la vitesse pourrait améliorer le diagnostic des problèmes cognitifs, en sachant particulièrement que 50 % des personnes affectées par la maladie d’alzheimer sont diagnostiquées et seulement 30 % au premier stade de la maladie ([Ferri et al., 2006], [Rimmer et al., 2005]). De plus, les sujets avec des démences chutent deux ou trois fois plus que les sujets sans déclin cognitif [Shaw, 2002]. 5.4 Extraction des indicateurs L’analyse des paramètres spatio-temporels s’avère être une approche intéressante pour évaluer l’état général d’une personne. Les paramètres auxquels nous allons nous intéresser sont la vitesse de marche, les longueurs de pas et la cadence. Ces paramètres sont extraits à partir des déplacements verticaux du centre de masse de la personne. Plus précisément, les paramètres sont extraits à partir de la courbe lissée (avec le filtre passe-bas ou le filtre de Kalman). 5.4.1 Longueurs de pas Comme nous l’avons déjà défini à la section 5.2.1, la longueur de pas, dans la littérature, correspond à la distance séparant les deux talons lors du double appui de réception. Notre méthode, pour récupérer la longueur de pas, consiste à chercher la position du pied d’appui. Le centre de masse est au plus haut au moment où il se trouve à la vertical du pied d’appui. La position du pied d’appui peut donc être estimée par la projection sur le sol du centre de masse au moment du point max sur la courbe, comme illustré par la figure 5.7. Dans notre cas, la longueur de pas est calculée comme la distance entre la projection de deux maxima locaux consécutifs de la trajectoire du centre de masse sur l’axe vertical. La distance est obtenue en calculant la distance euclidienne entre les deux points (A et B) en trois dimensions : da,b = p (xb − xa) 2 + (yb − ya) 2 + (zb − za) 2 L’extraction de la première longueur de pas est montrée à la figure 5.8. Nous exprimons les longueurs de pas en centimètres. 65Chapitre 5. Mesurer à domicile les paramètres de la marche 5.4.2 Cadence Nous calculons la cadence sur une séquence et non pas pour chaque pas. Pour calculer la cadence de l’ensemble des pas d’une séquence, nous appliquons la formule suivante : Cadence = N ( PN i=1 duree(i)) avec N le nombre de pas réalisés au cours de la séquence et duree(i) la durée du pas i. La cadence est exprimée ici en nombre de pas par seconde. La durée d’un pas est définie comme étant le temps entre le point de contact avec le sol d’un pied et le point de contact de l’autre pied (controlatéral). Pour obtenir la durée du pas, nous utilisons la même méthode que pour extraire les longueurs de pas. Le temps entre la projection de deux maxima locaux consécutifs sur la trajectoire du centre de masse sur l’axe vertical constitue la durée d’un pas. La durée d’un pas est exprimée en secondes. L’extraction de la durée du premier pas est montrée à la figure 5.8. 5.4.3 Vitesse de marche Les vitesses de marche moyenne et instantanée peuvent être calculées de la même façon. Dans la section 5.2.1, nous avions précisé que la vitesse de marche était souvent calculée en chronométrant le temps mis par le sujet pour parcourir une distance donnée. Nous reprenons cette idée pour extraire la vitesse moyenne. La vitesse de marche est calculée par la formule suivante : V itesse = PN i=1 longueur(i) PN i=1 duree(i) avec longueur(i) et duree(i) la longueur de pas (ici, exprimée en mètres) et la durée du pas i. Nous obtenons donc la vitesse de marche moyenne exprimée en mètre par seconde. L’extraction de la vitesse de la marche est montrée à la figure 5.8. Double Appui unilatéral droit appui Appui unilatéral gauche Double appui Double appui Déplacement vertical Figure 5.7 – Correspondance entre le cycle de la marche et la trajectoire du centre de masse sur l’axe vertical. 5.4.4 Résultat Lorsqu’une personne marche en ligne droite perpendiculairement à la caméra, nous obtenons entre 2 et 4 pas d’environ 50 à 60 cm selon les personnes. Les derniers pas de chaque séquence (une séquence correspond au moment où la personne traverse le champ de vision de la caméra 665.5. Conclusion -1600 -1550 -1500 -1450 -1400 -1350 -1300 -1250 -1200 -1150 -1100 7.5 8 8.5 9 9.5 10 10.5 11 Y (mm) Temps (s) Longueur du premier pas Vitesse de marche Durée du premier pas Figure 5.8 – Extraction des paramètres de la marche à partir du centre de masse. en entrant d’un côté et en sortant de l’autre) ne sont pas pris en compte. Les derniers pas correspondent aux moments où la personne sort du champ de vision de la caméra. Une fausse détection du pas peut se produire à proximité des bords de l’image. C’est pourquoi nous préférons enlever le dernier pas de chaque séquence lorsque la personne sort du champ de vision de la caméra. 5.5 Conclusion Ce chapitre nous a permis de poser les bases et les notions à connaître pour comprendre les différentes phases de la marche. Il liste, également, les différents paramètres existants pour analyser la marche de la personne. Les paramètres spatio-temporels représentent l’analyse des longueurs, cadences et vitesses de marche. Les paramètres cinématiques correspondent à l’analyse des angles formés par le pied, le genou et la hanche. Et les paramètres dynamiques étudient les forces de réaction au sol et les pressions plantaires. Les systèmes analysant la marche des personnes sont fondés sur l’analyse d’un ou de plusieurs de ces paramètres. Par exemple, les tapis actimètriques fournissent les paramètres spatio-temporels et les paramètres dynamiques, les accéléromètres, quant à eux, calculent les paramètres cinématiques. Nous avons également présenté, dans ce chapitre, différentes études mettant en évidence des liens entre troubles de la marche et dégradation de l’état de fragilité de la personne. D’après ces articles, l’analyse de la marche peut permettre de prévenir les chutes, les risques d’hospitalisation et les troubles cognitifs. La plupart des études concordent sur le fait que la longueur de pas, la cadence et la vitesse de marche sont des paramètres fiables pour étudier l’évolution de l’état de santé de la personne. Ainsi, nous avons présenté l’algorithme d’extraction de ces trois paramètres, à partir du centre de masse et de la détection des maxima locaux sur l’axe vertical. L’évaluation de la précision des paramètres extraits est présentée dans la prochaine partie. 67Chapitre 5. Mesurer à domicile les paramètres de la marche 68Chapitre 6 Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur Sommaire 6.1 Approches pour détecter l’activité . . . . . . . . . . . . . . . . . . 70 6.1.1 Approches non paramétriques . . . . . . . . . . . . . . . . . . . . . 70 6.1.2 Approches volumétriques . . . . . . . . . . . . . . . . . . . . . . . . 70 6.1.3 Approches paramétriques . . . . . . . . . . . . . . . . . . . . . . . . 71 6.2 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.3 Proposition d’un modèle de l’activité . . . . . . . . . . . . . . . . 73 6.3.1 Modèle avec fonction d’observation seule . . . . . . . . . . . . . . . 74 6.3.2 Utilisation d’un MMC unique . . . . . . . . . . . . . . . . . . . . . 75 6.3.3 Utilisation de MMC combinés . . . . . . . . . . . . . . . . . . . . . 79 6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 De nombreuses méthodes ont été développées dans le domaine de la reconnaissance d’activité. Les méthodes de reconnaissance d’activité peuvent être regroupées en trois catégories : les méthodes non paramétriques, les méthodes volumétriques et les méthodes paramétriques. En annexe A, nous présentons en particulier une méthode paramétrique, les modèles de Markov cachés (MMC), sur laquelle nous nous sommes basés pour construire nos modèles de détection d’activité. L’un des intérêts des MMC est de posséder de bonnes capacités de généralisation et donc d’être adaptée à nos contraintes. En effet, les données disponibles pour l’apprentissage sont nécessairement limitées et partiellement représentatives de la diversité des situations pouvant être rencontrées en situation réelle. Nous cherchons à déterminer l’activité d’une personne étant données les mesures que nous pouvons effectuer avec une caméra de profondeur. Cette activité est un état caché, que nous cherchons à déterminer à partir d’une séquence d’observations extraites des images de profondeur de la caméra RGB-D. Ces observations ont été choisies pour leur robustesse et la simplicité avec laquelle elles sont extraites des images de profondeur. Ces indicateurs sont cités au chapitre 4. Il s’agit du centre de masse de la personne, de ses vitesses verticale et horizontale, de la dispersion verticale du corps et du point le plus haut de la silhouette. Nous avons construit plusieurs modèles. Certains sont constitués d’un MMC unique, d’autres plus complexes requièrent plusieurs MMC, un par activité. Nous faisons varier le nombre d’observations et le nombre d’états afin de pouvoir, 69Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur ensuite, les comparer pour déterminer le modèle étant le plus pertinent. Cette comparaison est faite dans le chapitre 8. 6.1 Approches pour détecter l’activité Plusieurs études classifiant les méthodes de détection d’activités à partir d’images vidéo ont été réalisées ces dernières années. Les classifications réalisées sont différentes d’un article à l’autre car la reconnaissance d’activités est un large sujet. Ke et al. [Ke et al., 2013] propose ainsi un dé- coupage de la problématique sur trois niveaux, faisant apparaître les grandes étapes de l’analyse d’images, identifiant plusieurs catégories de problèmes en fonction des objectifs et enfin définissant des types d’applications. Les méthodes d’analyse d’images sont en effet liées au dispositif technique et à son environnement. Il faut par exemple prendre en compte les capacités de la caméra choisie, comme le type de capteur, l’ouverture de son champ de vision, la mobilité ou non de la caméra. La classification peut également être faite en fonction des méthodes d’analyse utilisées qui sont très nombreuses et peuvent s’étudier selon les différents niveaux de traitement de l’image et du flux vidéo. Les méthodes d’analyse dépendent en particulier de la complexité et du type des activités à reconnaitre. Les méthodes pour détecter qu’une personne lève les bras et se fait un thé ne sont, par exemple, pas les mêmes. Les moyens à mettre en œuvre dépendent enfin du contexte applicatif. Par exemple, la reconnaissance d’activités anormales ne requiert pas les mêmes méthodes si on s’intéresse aux activités dangereuses d’une personne dans le métro ou aux chutes des personnes âgées à leur domicile. Le regroupement des méthodes de reconnaissance d’activités peut donc se faire de nombreuses façons et il est par conséquent difficile d’être exhaustif. Ainsi, nous retrouvons dans la littérature des études se focalisant sur les mé- thodes appliquées à la surveillance [Valera and Velastin, 2005], sur la détection des activités des piétons [Enzweiler and Gavrila, 2009] ou encore proposant une classification selon la reconnaissance d’activités d’un groupe de personnes [Aggarwal and Ryoo, 2011]. Comme illustré par la fi- gure 6.1, nous nous intéressons plus spécifiquement à la reconnaissance d’activités simples, c’est à dire ne faisant pas intervenir une séquence longue d’événements, que nous cherchons à reconnaître à l’aide d’une caméra fixe, positionnée dans un environnement relativement peu maitrisé (l’intérieur d’un habitat, avec toute la diversité des aménagements possibles). Nous reprenons, pour positionner notre contribution, la classification réalisée par Turaga et al. [Turaga et al., 2008] qui regroupent les méthodes couramment utilisées pour la détection d’activités simples en trois catégories : les approches non paramétriques, volumétriques et paramétriques. 6.1.1 Approches non paramétriques Ces approches consistent à récupérer une série de caractéristiques à chaque image de la vidéo. Cela permet d’obtenir une séquence de caractéristiques qui sera alors comparée aux séquences de caractéristiques des exemples types qui ont été pré-enregistrés. L’exemple pré-enregistré le plus similaire est considéré comme représentatif de l’activité réalisée par la personne. Cette approche peut être utilisée pour des objets extraits en 2 ou 3 dimensions. 6.1.2 Approches volumétriques Ces approches consistent à analyser en un bloc l’enregistrement vidéo de l’activité réalisée par une personne. L’idée est d’analyser la séquence d’images en une seule fois et non pas image par image. A partir d’une séquence d’images, un volume en trois dimensions est créé à partir de l’ensemble des pixels appartenant à la personne. Chaque image constitue une coupe de ce 706.2. Positionnement Reconnaissance d'activités au domicile Caméra fixe Caméra mobile Plusieurs personnes Personne seule Activités simples Approches non paramétriques Approches volumétriques Approches paramétriques Activités complexes Figure 6.1 – Positionnement du problème de la reconnaissance d’activité au domicile. volume qui représente le trajet effectué par la personne durant la séquence. A partir de ce volume, des caractéristiques sont extraites. Ces caractéristiques peuvent ensuite être comparées aux caractéristiques des exemples pré-enregistrés. 6.1.3 Approches paramétriques Les approches paramétriques consistent à construire un modèle à partir d’hypothèses faites sur la dynamique de l’activité à reconnaitre. Les paramètres spécifiques d’une activité sont appris à partir d’une base d’exemple. Les séquences d’images à reconnaitre sont ensuite confrontées aux modèles des différentes activités. Le modèle le plus représentatif de la séquence permet d’identifier l’activité réalisée. 6.2 Positionnement L’objectif est de détecter les chutes et situations à risque mais aussi de reconnaitre des activités ou postures que peut prendre la personne dans la vie de tous les jours, en différenciant les activités où la personne est passive et celles où la personne est active. Les activités ont été choisies en s’inspirant des travaux de Noury et al. [Noury et al., 2007]. Dans cet article, les auteurs indiquent comment construire un système détectant les chutes. Notamment, ils précisent que pour détecter les chutes, il est nécessaire de confronter le système à des situations réalistes pouvant se confondre aux situations de chute, qui peuvent entraîner des faux positifs. Ils précisent qu’il ne suffit pas de comparer la chute à des activités telles que la marche, mais de prendre également des situations telles que se pencher ou s’accroupir. Ils énumèrent ainsi une liste d’activités à prendre 71Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur en compte pour détecter efficacement les chutes. Nous avons identifié les activités — à risque : chuter et être allongé au sol, monter sur un obstacle ; — passives : être assis, allongé sur un lit ou sur un canapé ; — actives : marcher, s’accroupir, se pencher, debout. Les approches non paramétriques et volumétriques requièrent un grand nombre d’exemples pour rendre la détection d’activité la plus fiable possible. Dans notre cas, nous sommes partis du principe que notre base de données ne peut pas être exhaustive. En effet, il est difficile d’enregistrer toutes les activités ou les postures qu’une personne peut réaliser au cours de la journée. Enregistrer les mouvements naturels et complètement réalistes d’une personne est très difficile à faire en situation de laboratoire. Nous ne disposons, par exemple, pas d’enregistrements de chutes réelles. De plus, une même activité peut se différencier par l’angle de vue de la caméra, l’endroit où elle est réalisée ou la façon qu’ont les personnes de la réaliser. Les personnes âgées peuvent se comporter différemment du fait de leurs capacités motrices plus ou moins conservées. Nous avons donc utilisé des modèles de Markov cachés qui font partie des approches paramétriques et qui ont de bonnes capacités de généralisation à partir d’une base de données restreinte. En plus de la question de la reconnaissance de l’activité, ces modèles permettent de traiter le problème de la segmentation des activités dans les séquences d’images, alors que les autres approches nécessitent de renseigner le début et la fin de l’activité. Dans la littérature, les articles traitant la détection d’activité à l’aide de méthodes paramé- triques utilisent généralement un grand nombre de paramètres extraits des images. Par exemple, dans l’article de Peursum et al. [Peursum et al., 2005], les auteurs décrivent leur méthode pour reconnaître l’action « imprimer » ou « préparer un thé » résultant d’une succession de 15 activités comme « marcher », « s’asseoir », etc. Pour reconnaître ces activités, ils se sont basés sur 10 caractéristiques à extraire de chaque image, comme la taille de la personne, la vitesse horizontale, la longueur du torse, l’angle du torse par rapport au sol, la longueur des mains, la longueur des jambes, etc. L’extraction de ces caractéristiques nécessite d’effectuer un certain nombre de traitements comme extraire la personne, localiser sa main, son torse, ses jambes et mesurer les angles au niveau des articulations. Comme pour le choix des états, les caractéristiques ont été choisies en se basant sur l’article de Noury et al. [Noury et al., 2007]. Les auteurs ont réalisé un état de l’art sur les méthodes utilisées pour développer un système de détection de chute. Ainsi, 4 approches sont couramment utilisées (séparément) pour détecter une chute d’une autre activité : — détecter la position allongée sur le sol ; — détecter l’impact du choc lorsque la personne se cogne au sol ou dans un obstacle, repré- senté par l’inversion de polarité du vecteur d’accélération dans la direction de la trajectoire ; — détecter un manque de mouvement ; — détecter la vitesse verticale, augmentant linéairement, due à l’accélération gravitationnelle lors de la chute. Chaque approche prise séparément peut provoquer des fausses détections. Notre idée est de coupler les sources d’informations pour établir une décision plus robuste et reconnaître des activités pouvant se ressembler (comme se pencher et s’accroupir). Nous avons repris l’idée qu’une chute se produit, lorsque le corps de la personne a une vitesse verticale qui augmente et que la personne se trouve allongée au sol. Pour obtenir ces informations, nous prenons en compte, dans un premier temps, trois caractéristiques, la vitesse verticale du centre de masse, la position du centre de masse et la dispersion verticale du corps de la personne (l’écart-type) sur l’axe vertical, auxquelles nous ajouterons ensuite la vitesse horizontale et la position de la tête. La vitesse verticale du centre de masse informe sur le déplacement du corps à chaque instant. La position 726.3. Proposition d’un modèle de l’activité du centre de masse permet de savoir si la personne est proche du sol. La distribution verticale du corps renseigne sur la forme du corps, ainsi il sera possible de distinguer des activités, comme s’allonger et s’accroupir, qui sont toutes deux des activités où la position du centre de masse est proche du sol et où la vitesse verticale est nulle, mais qui auront des dispersions verticales différentes. Nous proposons une approche nécessitant peu de caractéristiques pour reconnaître l’activité d’une personne tout en étant capable de généraliser à partir d’une base de données restreinte. En effet, la base de données sur laquelle nous travaillons est formée à partir de différentes situations réalisées par 28 sujets jeunes. Ces situations correspondent aux activités que nous voulons détecter. Plus d’informations sur la constitution de cette base est donnée au chapitre 8.1. Il s’agit de trouver un compromis minimisant la complexité du modèle et en particulier le nombre d’observations tout en garantissant une bonne robustesse dans la reconnaissance. Nous proposons plusieurs modèles dont les paramètres peuvent être ajustés par apprentissage mais avec relativement peu de données. Certains de ces modèles permettent de prendre en compte une connaissance de bon sens par la définition manuelle d’une partie des paramètres. Dans la suite de ce chapitre, nous présentons différents modèles d’activité que nous avons évalués. Il différent par le nombre d’activités modélisées, le nombre d’observations et par l’insertion ou non de connaissance a priori. Ces différents modèles sont proposés dans le but d’être ensuite évalués expérimentalement afin d’identifier le niveau de complexité permettant d’obtenir une reconnaissance précise des activités tout en étant suffisamment général pour permettre la reconnaissance de situations éloignées de la base d’apprentissage. 6.3 Proposition d’un modèle de l’activité Les modèles de Markov cachés (MMC) fournissent un cadre efficace pour modéliser des phé- nomènes ou processus régis par une dynamique d’états cachés. Seules des observations partielles sur le processus sont accessibles et les états peuvent être inférés avec une certaine probabilité à partir d’une séquence d’observations. La figure 6.2 illustre un MMC évoluant dans le temps avec Xt les états cachés, représentés en gris, et Ot les observations. Un MMC est défini formellement par : — un ensemble d’états ; — une matrice aij = P(Xt = j|Xt−1 = i) représentant toutes les probabilités de transition entre chaque paire d’états ; — une probabilité initiale πi = P(X0 = i) pour chaque état i, qui est la probabilité a priori que le système se trouve dans l’état i à t = 0 ; — une fonction d’observation bi(o) = P(Ot = o|Xt = i). Des algorithmes d’apprentissage et d’inférence bien connus sont présentés en annexe A. L’objectif est de construire un modèle permettant de reconnaître l’activité réalisée par la personne filmée. X0 O0 X1 O1 Xt Ot Figure 6.2 – Représentation graphique d’une chaine de Markov cachée, avec Xt le processus Markovien caché et Ot la séquence d’observations correspondantes. 73Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur Le modèle le plus simple que nous proposons est constitué d’un état par activité avec pour chaque état une distribution gaussienne formant la fonction d’observation. Les paramètres de ces distributions sont appris à partir de la base de données. Nous ajoutons ensuite à ce modèle de référence une fonction de transition définie manuellement qui nous permet d’injecter de la connaissance sur l’enchainement des activités. La fonction de transition est définie manuellement car nous ne disposons pas de données représentatives des enchainements possibles des situations que nous voulons reconnaitre. Cette seconde proposition prend donc la forme d’un MMC unique permettant de reconnaitre les différentes activités avec un état par activité. Enfin nous proposons d’utiliser plusieurs MMC, un MMC pour chaque activité dont les paramètres sont appris à partir de la base de données. Dans cette dernière proposition les transitions entre activités ne sont pas définies. Il n’y a donc pas de contraintes a priori sur les enchainements ce qui nous permet d’avoir un modèle plus général. 6.3.1 Modèle avec fonction d’observation seule Etats Le modèle contient 8 états correspondant à 8 activités qui sont : s’asseoir, marcher, s’accroupir, se pencher, monter sur un obstacle (une chaise, une marche, etc.), s’allonger sur un lit ou sur un canapé, chuter et être allongé au sol. Dans ce modèle, les activités « marcher » et « être debout » sont confondues. Observations Nous utilisons les caractéristiques suivantes : — la position du centre de masse sur l’axe vertical ; — la vitesse verticale du centre de masse ; — la dispersion verticale du corps de la personne (l’écart-type) sur l’axe vertical. La fonction d’observation, donnant la probabilité d’observer une valeur o dans l’état i, suit une loi normale multidimensionnelle pour chaque valeur de i : P(O = o|X = i) = 1 (2π)N/2|Σi | 1/2 e −1/2(o−µi) T Σ −1 i (o−µi) (6.1) avec Σi la matrice de covariance, µi la moyenne et N le nombre de dimensions (pour ce MMC le N est égal à 3, car il y a trois observations). Σi et µi sont calculés, pour chaque état i, par apprentissage à partir de la base de données. Après apprentissage, nous obtenons donc 8 lois normales, une pour chaque état. Conclusion Ce modèle sans transition est représenté à la figure 6.3. Sur cette figure, les huit carrés représentent les huit états de notre modèle. Les 8 états représentent les 8 activités réalisées par le sujet, détecté en vert par l’algorithme. Cette figure montre qu’aucune transition n’est définie entre les états. La décision de l’état dans lequel se trouve la personne repose, ici, essentiellement sur les observations. Inférence Pour réaliser l’inférence, l’état Xt le plus probable est donnée à chaque pas de temps en comparant les valeurs prises, pour l’observation ot, par les 8 distributions gaussiennes. Le calcul est le suivant : P(Xt = i|O = ot) = P(O = ot|Xt = i)P(Xt = i) P i P(O = ot|Xt = i)P(Xt = i) . 746.3. Proposition d’un modèle de l’activité Marche Assis Allongé Canapé Chute Allongé Sol Accroupi Monté Penché Figure 6.3 – Modèle à 8 états avec fonction d’observation seule. Nous n’avons pas considéré de différence a priori entre les états. La probabilité P(Xt = i) est donc uniforme pour toutes les valeurs de i et l’équation précédente se résume donc à : P(Xt = i|O = ot) = P(O = ot|Xt = i) P i P(O = ot|Xt = i) . 6.3.2 Utilisation d’un MMC unique Nous ajoutons à la proposition précédente, qui associe un état à chaque activité, une matrice de transition qui modélise l’enchainement dans le temps des activités. Nous obtenons donc un MMC représentant l’activité comme un processus dynamique partiellement observable. Nous proposons dans cette section un premier modèle à 8 états et un second à 9 états. Pour chaque modèle, nous définissons l’espace d’états (les activités à reconnaitre), la probabilité initiale qu’à le processus (l’activité) d’être dans un état donné, la dynamique (transition entre états) ainsi que les observations considérées. Dans ces modèles, la fonction d’observation est apprise à partir de la base de données. La matrice de transition est, quant à elle, définie manuellement. Nous partons en effet du principe qu’il n’est pas possible d’apprendre les transitions entre activités à partir d’une base de donnée constituée en laboratoire. Cette base de donnée, constituée à partir de situations jouées, ne peut pas être représentative de la diversité des enchainements d’activité d’une personne dans la vie de tous les jours. Il est en revanche possible d’injecter une connaissance a priori, de bon sens, par la définition manuelle des probabilités de transition. MMC à 8 états et 3 observations Etats Les états sont les mêmes que précédemment, à savoir : s’asseoir, marcher, s’accroupir, se pencher, monter sur un obstacle (une chaise, une marche, etc.), s’allonger sur un lit ou sur un canapé, chuter et être allongé au sol. Probabilités initiales Nous considérons qu’au début de l’analyse la personne peut se trouver dans n’importe quel état. Nous attribuons donc la même probabilité initiale pour chaque état, 75Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur soit 0,125. Matrice de transition L’activité est modélisée comme un processus stochastique. Les transitions entre les différents états expriment la dynamique de l’activité qui tient compte autant des contraintes biomécaniques que d’un a priori sur le comportement des personnes. Pour insérer les transitions possibles, nous avons fait plusieurs hypothèses. — La journée d’une personne âgée, à son domicile, peut être résumée en une succession de passages assis-debout. Nous définissons les transitions les plus probables comme étant celles qui mènent vers l’état « Marche ». — La personne marche (ou est debout) juste avant et après avoir effectué les activités « Accroupi », « Monté », « Penché », « Assis ». — Une personne ne peut pas directement passer de la position debout à allonger mais elle doit d’abord s’asseoir pour pouvoir s’allonger. — La probabilité d’aller dans l’état « Chute » est très faible comparée aux autres activités. — Une personne se trouvant allongée au sol est obligatoirement passée par l’état « Chute ». — Une fois au sol, la personne peut soit y rester soit, dans le cas où la personne est capable de se relever, passer directement à l’état « Marche » ou passer par l’état « Accroupi » qui lui permettra de passer par l’état « Marche » (ou être debout) par la suite. Le MMC construit sur la base de ces hypothèses est représenté à la figure 6.4. Les transitions correspondent aux flèches et les états aux rectangles. Nous définissons les probabilités relatives des différentes transitions sur une échelle à quatre niveaux : — pp, la plus petite probabilité de transition ; — p, une probabilité de transition faible ; — m, une probabilité de transition moyenne ; — C, la probabilité majoritaire correspondant au complément à 1 des autres probabilités sortantes de l’état. Observations Le modèle construit ici reprend les 3 mêmes observations que le précédent modèle, à savoir la position et la vitesse verticale du centre de masse et la distribution du corps sur l’axe vertical. La fonction d’observation est également conservée, elle suit une loi normale multidimensionnelle. Conclusion Avec la construction de ce MMC, nous injectons de la connaissance à travers la matrice de transition. MMC à 9 états et 5 observations Dans l’objectif de mesurer les paramètres de la marche d’une personne à son domicile et donc de pouvoir appliquer au domicile les résultats présentés au chapitre 5, il est important d’isoler précisément les moments où la personne se déplace. Cela implique de différencier l’activité « Marche » de l’activité « Debout ». Etats Dans ce nouveau modèle, nous ajoutons un état « Debout » aux huit états précédents. Probabilités initiales Comme pour les précédents modèles, nous attribuons une même probabilité de 1/9 à chaque état. 766.3. Proposition d’un modèle de l’activité Marche Assis Allongé Canapé Allongé Sol Accroupi Chute Monté Penché p C pp p pp p m C p C m C m p p C C m C m C m Figure 6.4 – MMC à 8 états avec des transitions définies manuellement. Matrice de transition Les transitions et les probabilités sont définies sur la base des mêmes hypothèses que celles du modèle précédent, en ajoutant : — l’état « Debout » précède et suit la plupart des activités. Seules les activités « Monté » et « Chute » peuvent être aussi précédées et suivies de l’état « Marche ». Le MMC construit sur la base de ces hypothèses est représenté à la figure 6.4. Les probabilités relatives des différentes transitions sont définies sur la même échelle à quatre niveaux que précédemment. Observation L’ajout de l’état « Debout » nécessite une augmentation du nombre d’observations. En effet, les trois observations précédentes ne suffisent pas à différencier les états « Debout » et « Marche ». Intuitivement, nous pouvons penser que la vitesse horizontale diffère entre les deux états. Nous ajoutons également la position verticale de la tête pour améliorer la robustesse du modèle. Ainsi, dans ce modèle nous insérons 5 observations : la position du centre de masse, la dispersion verticale du corps, la vitesse verticale et la vitesse horizontale du centre de masse et le point maximum du corps. La fonction d’observation suit toujours une loi normale multidimensionnelle avec cette fois un nombre de dimensions égal à 5 soit N = 5 dans la formule 6.1. Comme précédemment, à partir de la base de données, les moyennes µ des cinq observations et la covariance Σ sont calculées pour chacun des neuf états. Nous obtenons ici 9 lois normales. Conclusion Nous voulons ici démontrer que nous pouvons affiner les activités réalisées, notamment distinguer la personne active (marchant) de la personne statique. La contrepartie est d’augmenter la complexité du modèle en augmentant le nombre des observations en passant de 3 à 5. 77Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur Marche Debout Assis Allongé Canapé Chute Allongé Sol Accroupi Penché Monté p C pp pp p C p pp p p pp m C p C m C m p p p C C m p C m C m Figure 6.5 – MMC à 9 états avec des transitions définies manuellement. 786.3. Proposition d’un modèle de l’activité Inférence Pour savoir dans quel état se trouve la personne, nous avons implémenté les algorithmes Forward-Backward et de Viterbi, décrit en annexe A. En implémentant les deux algorithmes, les plus couramment utilisés avec les MMC, nous avons voulu savoir si des différences notables pouvaient apparaître dans la décision finale de l’état dans lequel se trouve la personne. La comparaison des deux algorithmes est présentée dans le chapitre 8 lors de la présentation des résultats de l’expérimentation. 6.3.3 Utilisation de MMC combinés Dans les modèles précédents, chaque activité correspondait à un état et nous obtenions donc un MMC à 8 ou 9 états selon le modèle. Avec l’approche multi-modèles, chaque activité correspond à un MMC, nous obtenons donc 8 ou 9 MMC selon le nombre d’activités à reconnaître. Une autre différence avec les modèles précédents est que nous n’insérons aucune connaissance a priori (ni transition, ni probabilité initiale). Comme dans le cas du modèle avec les observations seules, la dynamique entre les situations n’est pas prise en compte. Système de 8 MMC Etat Nous construisons deux types de systèmes de modèles. Ces deux systèmes de modèles sont identiques à la seule différence que l’un est constitué de 8 MMC à 2 états et l’autre à trois états chacun. Nous voulions ainsi tester l’influence qu’a le nombre d’état choisi. Probabilités initiales et matrice de transition Comme nous venons de le préciser, aucune connaissance n’est insérée dans ce modèle. Cela signifie que nous ne définissons pas manuellement les probabilités de transition et les probabilités initiales. Ces probabilités sont apprises automatiquement à partir de la base de données. Observations Les observations sont les mêmes que pour les MMC à 8 états, à savoir la position et la vitesse du centre de masse sur l’axe vertical et la distribution du corps sur l’axe vertical. Chacun des huit MMC se base sur ces trois observations. La fonction d’observation reste elle aussi inchangée, elle suit une loi normale multidimensionnelle. Les paramètres de cette loi normale sont calculés à partir de la base de données. Les paramètres sont appris pour chaque état des 8 MMC. Nous obtenons donc 16 ou 24 lois normales selon le modèle à deux ou trois états par MMC. Conclusion Le système des 8 MMC à deux états chacun et sans probabilité de transition est représenté à la figure 6.6. Nous appliquons à ces systèmes de modèle l’algorithme de BaumWelch permettant d’apprendre par lui-même les paramètres du MMC, à partir de la base de données. Les paramètres qui sont appris sont les probabilités de transition entre chaque état, les probabilités initiales et les lois normales pour chaque état. Le nombre d’états pour chacun des 8 MMC est le seul paramètre que nous déterminons à la main. Système de 9 MMC Etat Comme précédemment, nous construisons deux types de systèmes de modèles. C’est-à- dire que nous développons un système de 9 modèles à 2 états et un autre système à trois états chacun. 79Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur Accroupi Chute Allongé Sol Monté Marche Assis Penché Allongé Canapé Figure 6.6 – Système de 8 MMC à deux états chacun. Probabilités initiales et matrice de transition Comme précédemment aucune connaissance n’est insérée dans ce modèle. Cela signifie que les probabilités initiales et les matrices de transition sont apprises automatiquement à partir de la base de données. Observations Les observations sont les mêmes que pour les MMC à 9 états, à savoir la position et la vitesse du centre de masse sur l’axe vertical, la dispersion du corps sur l’axe vertical, la vitesse horizontale du centre de masse et la position du point maximum du corps. Chacun des neuf MMC se base sur ces cinq observations. La fonction d’observation reste elle aussi inchangée, elle suit une loi normale multidimensionnelle. Les paramètres de cette loi normale sont calculés à partir de la base de données. Les paramètres sont appris pour chaque état des 9 MMC. Nous obtenons donc 18 ou 27 lois normales selon le modèle à deux ou trois états par MMC. Conclusion Le système des 9 MMC à deux états chacun et sans probabilité de transition est représenté à la figure 6.7. Nous appliquons à ces systèmes de modèle, comme pour les 8 MMC, l’algorithme de Baum-Welch permettant d’apprendre par lui-même les paramètres du MMC à partir de la base de données. Les paramètres, qui sont appris, sont les probabilités de transition entre chaque état, les probabilités initiales et les lois normales pour chaque état. Le nombre d’états pour chacun des 9 MMC est donc le seul paramètre que nous déterminons à la main. Inférence Pour savoir dans quel état se trouve la personne, nous devons d’abord appliquer un algorithme d’apprentissage, avant d’utiliser les algorithmes d’inférence, comme décrit en annexe A. Nous avons donc utilisé l’algorithme de Baum-Welch pour apprendre les paramètres de chaque modèle à partir de la base de données que nous avons construite. L’inférence est réalisée, avec l’algorithme Forward, en calculant à chaque pas de temps la vraisemblance des différents modèles sur les 806.4. Conclusion Accroupi Chute Allongé Sol Monté Marche Assis Penché Debout Allongé Canapé Figure 6.7 – Système de 9 MMC à deux états chacun. dernières images de la séquence. L’activité la plus probable est celle qui correspond au modèle donnant la plus grande vraisemblance. 6.4 Conclusion Dans ce chapitre, nous avons présenté les différents modèles que nous avons construits pour reconnaître l’activité. Chaque modèle a des avantages et inconvénients. Certains modèles sont plus simples en ne prenant que trois observations (les modèles à 8 états ou 8 MMC combinés) mais ne font, par conséquent, pas la différence entre être debout et marcher (comme c’est le cas avec les modèles à 9 états ou 9 MMC combinés). Certains modèles n’ont pas de connaissance a priori et reposent sur un nombre plus grand de paramètres à apprendre, ce qui implique de travailler avec une base de données plus importante comparée aux modèles où l’on insère les paramètres manuellement en utilisant une connaissance humaine de l’enchainement des situations. Les résultats donnant les meilleurs taux de classification sont présentés dans le chapitre 8. 81Chapitre 6. Reconnaitre l’activité humaine en temps réel par l’analyse d’images de profondeur 82Conclusion Nous avons identifié la caméra de profondeur comme capteur répondant à nos besoins pour développer un système de maintien à domicile des personnes âgées. Un certain nombre de traitements sur le flux vidéo sont à effectuer pour, ensuite, pouvoir extraire de l’information de plus haut niveau, comme détecter l’activité ou analyser la marche d’une personne. Le premier chapitre nous a permis de présenter les différentes méthodes en vision pour détecter la personne et la suivre au cours du temps sur l’ensemble des images fournies par la caméra. L’état de l’art n’est pas exhaustif, mais nous avons identifié les méthodes utilisées pour détecter et suivre une seule personne en intérieur avec une caméra fixe. Le deuxième chapitre présente les algorithmes de détection de la personne et de suivi que nous avons développés. Nous avons opté pour des méthodes légères, ne nécessitant pas de temps de calcul importants pour que ces méthodes restent compatibles avec les objectifs de traitement bas coût et de temps réel, que nous nous sommes fixés. A partir des images de profondeur, fournies par la caméra, nous obtenons le fond par apprentissage, puis la silhouette de la personne est extraite par soustraction avec l’image de profondeur courante. La silhouette est représentée par un ensemble de points, dont sont extraits 5 paramètres : le centre de masse, la vitesse verticale et la vitesse horizontale du centre de masse, la dispersion verticale et le point maximum de la silhouette. L’algorithme d’analyse de la marche, développé dans le troisième chapitre, nous permettra d’évaluer le degré de fragilité de la personne en analysant l’évolution des paramètres de la marche spatio-temporels (longueurs, cadence, vitesse de marche). Cet algorithme est très simple, puisqu’il se base uniquement sur l’information du centre de masse et la détection des maxima locaux sur l’axe vertical. Ainsi, le système peut fournir, en temps réel, les paramètres de la marche de la personne suivie. Il sera alors possible d’observer des évolutions des paramètres de la marche au cours du temps, pour déterminer des éventuels risques de perte d’autonomie. Actuellement, les médecins observent certains de ces paramètres en consultation et évaluent l’évolution lors des visites suivantes. Le problème étant qu’entre chaque visite, il peut se passer quelques mois. Or, il serait possible d’effectuer une analyse quotidienne des paramètres de la marche en installant notre système au domicile des personnes. Ainsi, l’évaluation de la fragilité d’une personne pourrait être faite à partir d’un plus grand volume d’informations. Le quatrième chapitre est consacré à la présentation des algorithmes utilisés pour reconnaître l’activité d’une personne. Le but de cet axe de recherche est de sécuriser et évaluer la personne. Ainsi pour sécuriser la personne, nous voulons développer un système détectant la chute et les situations à risque telles que monter sur une chaise et s’accroupir, qui sont des activités pouvant conduire à une chute, en particulier chez les personnes âgées. Puis, pour évaluer la personne, nous voulons développer un système capable de déterminer si la personne réalise des activités actives, autres que s’asseoir et s’allonger. Ainsi, nous avons construit un algorithme qui identifie les activités suivantes : s’asseoir, marcher, s’accroupir, se pencher, monter sur un obstacle (une chaise, une marche, etc.), s’allonger sur un lit ou sur un canapé, chuter et être allongé au sol. 83Conclusion Parmi les méthodes existantes pour reconnaître les activités, nous avons choisi de développer un algorithme appartenant à la catégorie des méthodes paramétriques. L’une des difficultés, en reconnaissance d’activité, est la variabilité des données, du fait de la différence entre les personnes, de la façon qu’elles ont de réaliser les activités, de l’angle de vue de la caméra, etc. Nous avons choisi les modèles de Markov cachés qui ont de bonnes capacités de généralisation. Dans ce quatrième chapitre, nous avons présenté différents modèles que nous avons construits pour reconnaître l’activité. Nous avons proposé deux approches. La première utilise un modèle unique dans lequel une connaissance a priori est injectée par la définition de la matrice de transition. Dans la seconde, plusieurs modèles sont construits par apprentissage et les transitions entre activités ne sont pas modélisées. Nous avons fait varier la complexité des modèles en jouant sur le nombre d’activité à reconnaître et sur le nombre d’observations. Nous avons construit des modèles pour reconnaître 8 activités, utilisant 3 observations, la position et la vitesse verticale du centre de masse et la distribution verticale de la silhouette. Nous avons construit d’autres modèles reconnaissant 9 activités en ajoutant l’activité « Debout ». Ces modèles discriminent les 9 activités à partir de 5 observations, les trois mêmes que précédemment, en ajoutant la vitesse horizontale du centre de masse et le point le plus haut du corps. Dans le cas des systèmes de MMC, nous avons implémenté l’algorithme de Baum-Welch pour apprendre les paramètres des modèles, puis nous avons implémenté Forward pour inférer l’état dans lequel se trouve la personne. Dans le cas des MMC uniques, nous avons implémenté l’algorithme Forward-Backward et de Viterbi pour inférer l’état à partir de la séquence d’observation. Le point commun entre tous ces modèles est qu’ils sont fondés sur peu d’observations et que ces observations sont simples à extraire des images. Les différents modèles sont ensuite testés et comparés sur la base du nombre de bonnes classifications qu’ils effectuent. Les résultats sont présentés au chapitre 8. 84Troisième partie Evaluation du système 85Introduction Dans les deux chapitres précédents, nous avons présenté nos contributions à la reconnaissance d’activités et à l’analyse en milieu écologique des paramètres de la marche. Dans cette partie, nous en évaluons les performances. Plusieurs expérimentations sont mises en place. Les deux premiers chapitres présentent des expérimentations qui ont été menées dans un appartement expérimental avec des sujets jeunes. Le dernier chapitre présente quelques résultats obtenus avec des personnes âgées. Le premier chapitre décrit une expérimentation qui a été menée pour vérifier les performances du dispositif d’analyse de la marche que nous proposons, en comparaison avec les mesures fournies par un tapis actimètrique que nous considérons comme la vérité terrain. Dans cette expérimentation, nous testons la précision pour différentes situations, pouvant être rencontrées dans la réalité. Par exemple, nous avons demandé aux personnes de marcher perpendiculairement à la caméra, puis de face, ensuite nous leur avons demandé de faire des petits pas comme pourraient le faire des personnes âgées. Les résultats nous montrent que le système est précis lorsque la personne marche perpendiculairement à la caméra, et ce pour toutes les situations. Le deuxième chapitre teste l’algorithme de détection des activités. Nous avons constitué une base de données à partir de laquelle, une partie des séquences sont conservées pour que l’algorithme apprenne, automatiquement, les paramètres de chaque MMC. Nous évaluons, ensuite, les modèles sur la base du nombre de bonnes classifications des séquences restantes. Les modèles à 8 états ou 8 MMC donnent les meilleurs résultats sur des séquences proches de celles constituant la base d’apprentissage, avec la personne entièrement visible. Nous testons les capacités de gé- néralisation de l’algorithme avec une deuxième expérimentation. Nous présentons à l’algorithme des séquences où la personne n’est pas entièrement visible. Les résultats montrent que certains modèles sont robustes sur ces nouvelles séquences, ce qui est le cas pour le modèle à 9 états. Le dernier chapitre de cette partie présente des tests qui ont été effectués dans un hôpital et au domicile, avec des personnes âgées. 6 personnes âgées ont marché devant notre système. Il ne s’agit pas d’une réelle expérimentation mais de premiers tests pour lesquels nous n’avons effectué qu’une analyse qualitative des résultats. Concernant l’algorithme de la marche, les résultats montrent que, malgré l’irrégularité des trajectoires du centre de masse, comparées aux trajectoires que nous obtenions avec des sujets plus jeunes, l’algorithme réussit à extraire des paramètres de la marche. Concernant la détection des activités, seules quelques activités ont été testées. Parmi celles-ci, la marche, la position assise et la position penchée ont été reconnues. 87Introduction 88Chapitre 7 Expérimentations pour l’analyse de la marche Sommaire 7.1 Première évaluation du système . . . . . . . . . . . . . . . . . . . 89 7.1.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . 89 7.1.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 7.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 7.2 Évaluation globale du système . . . . . . . . . . . . . . . . . . . . 94 7.2.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . 94 7.2.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 7.3 Discussion et conclusion . . . . . . . . . . . . . . . . . . . . . . . . 97 L’expérimentation a pour but de tester la précision des paramètres de la marche fournis par notre algorithme, lorsqu’une personne marche dans le champ de vision de la caméra. Une première évaluation a tout d’abord été réalisée. L’objectif est de vérifier que l’algorithme est assez robuste pour commencer l’évaluation et de valider ou non certaines hypothèses. A la suite des résultats obtenus avec cette première évaluation, le protocole expérimental d’une seconde expérimentation a été construit. 7.1 Première évaluation du système Cette section présente la première évaluation basée sur le papier et l’encre et qui constitue notre référence pour évaluer la précision de l’algorithme à extraire les indicateurs de la marche. Nous présentons le protocole expérimental et les résultats. 7.1.1 Description de l’expérimentation 5 sujets sains ont intégré l’expérience dont une femme et quatre hommes, âgés de 20 à 53 ans. L’expérience consiste à placer, sur environ 4 m2 , du papier blanc au sol (figure 7.1(b)). Nous avons placé des tampons imbibés d’encre sur la pointe et le talon des chaussures du sujet, comme montré à la figure 7.1(a). Ainsi lorsque le sujet marche sur le papier, il le marque de ses pas. Des méthodes similaires de marquage sur le sol peuvent être trouvées dans la littérature. Notamment, Georges Gilles de la Tourette a utilisé une technique similaire pour enregistrer la marche [André et al., 2001]. Cette méthode a l’avantage d’être simple à mettre en place, peu 89Chapitre 7. Expérimentations pour l’analyse de la marche coûteuse et de ne nécessiter aucun équipement spécifique. Dans le cadre de l’expérience, la méthode « papier/encre » est considérée comme l’étalon permettant d’obtenir la vérité terrain. L’unique variable prise en compte dans cette étude est la longueur de pas. Pour obtenir les longueurs de pas, l’expérimentateur mesure manuellement la distance entre la marque du talon droit et celle du talon gauche sur le papier. Ces longueurs de pas sont alors comparées aux longueurs fournies par notre approche fondée sur une caméra RGB-D. (a) Tampons imbibés d’encre sous les chaussures. (b) Un sujet marche sur le papier et le marque. Figure 7.1 – Méthode utilisée comme référence pour mesurer les longueurs de pas. Le sujet marche perpendiculairement à la caméra. Sachant que les personnes âgées font des plus petits pas [Hageman and Blanke, 1986] que les sujets testés dans notre étude, nous évaluons la précision de l’algorithme en le sollicitant sur un large échantillon de longueurs de pas. Les sujets réalisent les deux situations suivantes : — marcher en ligne droite « normalement » ; — marcher en ligne droite en faisant des petits pas. Cette première évaluation a plusieurs objectifs : 1. évaluer si les résultats sont invariants à l’angle de la caméra, 2. évaluer la précision des mesures en fonction des différents algorithmes de filtrage choisis. Nous voulons savoir si l’angle de la caméra a une incidence sur les résultats. C’est pourquoi les sujets réalisent les deux situations citées précédemment deux fois, une fois avec un angle égal à -27˚ et l’autre à 0˚. Le placement de la caméra avec un angle à -27˚ correspond à la caméra positionnée en haut de la figure 7.2 et la caméra avec un angle à 0˚ correspond à la caméra positionnée en bas de la figure 7.2. Lors de l’expérience, une seule caméra enregistre à la fois. Nous voulons aussi tester la précision des longueurs de pas fournies par l’algorithme en fonction du filtre de lissage de la trajectoire du centre de masse sélectionné. A la section 4.2.2, deux méthodes de lissage des trajectoires ont été présentées, une méthode utilisant le filtre de Kalman et une autre utilisant un filtre passe-bas. Nous voulons savoir si la précision de l’extraction des maxima locaux, permettant d’obtenir les longueurs de pas, dépend du filtre utilisé. Pour tester la précision de notre algorithme, nous comparons les longueurs de pas fournies par le papier avec les longueurs fournies par l’algorithme utilisant soit le filtre de Kalman, soit le filtre passe-bas. 907.1. Première évaluation du système Figure 7.2 – Positionnement des caméras : la plus basse avec un angle de 0˚ et la plus haute avec un angle de -27˚. 7.1.2 Résultats Pour réaliser les différents tests statistiques et les graphes, nous avons utilisé le logiciel R (qui est un langage et un environnement pour les calculs statistiques). Angle de la caméra Afin de savoir si l’angle de la caméra modifie la qualité des résultats, les erreurs moyennes des longueurs de pas, obtenues quand la caméra a un angle à -27˚ et à 0˚, sont calculées. Plus précisément, nous calculons l’erreur entre les longueurs fournies par le papier et par notre algorithme selon l’angle de la caméra, pour chaque pas. L’erreur moyenne est calculée comme la moyenne sur toutes les erreurs, considérant d’un côté les données pour la caméra à -27˚ et de l’autre les données pour la caméra à 0˚. Les résultats sont montrés à la Table 7.1. L’erreur moyenne est donnée en centimètres et en pourcentages. Les erreurs moyennes sont similaires entre la caméra à -27˚ et à 0˚. Comme indiqué par la table, l’erreur moyenne avec l’angle à -27˚ est de 5,4 cm soit une erreur moyenne de 11,6 %. Ce résultat est proche de l’erreur moyenne de 5,2 cm, soit une erreur moyenne de 11,9 %, obtenue avec l’angle à 0˚. Un test statistique complète ces résultats, dans le but de savoir si les erreurs sur les longueurs de pas obtenues avec les deux angles sont significativement différentes. Avec un test de Student, pour deux échantillons indépendants, la p-value obtenue est de 0,4777. La p-value étant plus grande que 0, 05, nous ne pouvons pas en conclure qu’il existe une différence significative entre les résultats fournis par la caméra positionnée à -27˚ et celle positionnée à 0˚. Pour finir, le graphe, de la figure 7.3, montre que la variabilité des erreurs sur les longueurs de pas est la même pour l’angle à 0˚ que pour l’angle à -27˚. Cela est montré par la forme des deux boites à moustache. La conclusion, que nous pouvons faire, est que notre algorithme est robuste à l’angle de la caméra choisi. 91Chapitre 7. Expérimentations pour l’analyse de la marche Angle -27˚ Angle 0˚ Erreur moyenne (cm) 5,4 5,2 Erreur moyenne (%) 11,6 11,9 Nombre de pas 56 50 Table 7.1 – Comparaison des résultats, entre le tapis et la caméra, en fonction de l’angle de la caméra. Angle de 0° Angle de 27° -5 0 5 10 15 20 Erreur (cm) Figure 7.3 – Représentation des erreurs sur les longueurs de pas obtenues à partir d’une caméra avec un angle de -27˚ et avec un angle de 0˚. 927.1. Première évaluation du système Choix du filtre Dans cette partie, le système est évalué sur la précision des longueurs de pas qu’il fournit, en fonction du filtre de lissage de la trajectoire du centre de masse. La trajectoire qui est correctement filtrée, nous permet de localiser plus précisément les maxima locaux, et ainsi nous permet d’en déduire les longueurs de pas les plus justes. Nous voulons ainsi tester la précision des longueurs de pas lorsque l’algorithme utilise le filtre de Kalman et le filtre passe-bas. Suite à l’expérience effectuée sur 5 sujets, nous avons extrait les pas et selon le filtre utilisé, le filtre de Kalman ou le filtre passe-bas, nous obtenons des pas différents. 106 pas ont été récupérés en utilisant le filtre de Kalman, dont 39 sont de longueurs « normales » (supérieures à 50 cm) et 67 sont de « petites » longueurs (inférieures à 50 cm). 108 pas ont été récupéré en utilisant le filtre passe-bas dont 40 sont de longueurs « normales » et 68 sont de « petites » longueurs. Les erreurs entre les longueurs de pas fournies par le papier et par notre algorithme sont calculées pour chaque pas. L’erreur moyenne (en centimètres et en pourcentage) est calculée comme la moyenne sur toutes les erreurs, considérant toutes les données, ensuite considérant seulement les longueurs « normales » et finalement que les « petites » longueurs. Les résultats sont montrés à la Table 7.2. Les colonnes représentent la distinction entre les données, « Tous » signifie que tous les pas sont pris, « Normaux » signifie que tous les pas considérés comme « normaux » sont sélectionnés et « Petits » signifie que les petits pas sont analysés. Nous présentons les résultats pour le filtre de Kalman et pour le filtre passe-bas (noté « valeur filtre de Kalman | valeur filtre passe-bas » dans chaque case de la table). Cette table nous montre qu’il y a une différence entre l’erreur moyenne obtenue avec le filtre de Kalman et avec le filtre passe-bas. En effet, pour toutes les longueurs de pas, l’erreur moyenne pour le filtre de Kalman est 5,3 cm, soit 11,8 %, et pour le filtre passe-bas nous obtenons une erreur moyenne de 6,9 cm, soit 15,6 %. La décomposition des données en pas normaux et petit pas nous permet de constater que l’erreur moyenne sur la série de données est principalement due aux erreurs sur les petits pas. L’erreur moyenne, pour le filtre de Kalman, pour les petits pas est de 4, 7 cm, soit 12,8 % et pour les pas normaux, l’erreur est 6,4 cm, soit 10,0 %. L’erreur moyenne, avec le filtre passe-bas, pour les petits pas est de 6,5 cm, soit 18,0 % et pour les pas normaux, l’erreur est de 7,5 cm, soit 11,7 %. Les boites à moustaches de la figure 7.4 permettent d’observer la variabilité des données. Les médianes des deux filtres sont identiques (représentées par la barre du milieu dans la boite). Cependant, le filtre passe-bas ne lisse pas toujours les données correctement, ce qui provoque une erreur dans l’extraction des maxima locaux indiquée par les valeurs aberrantes de la figure. Les valeurs aberrantes sont représentées par les cercles en dehors de la boite à moustache. Tous Normaux Petits Erreur moyenne (cm) 5,3|6,9 6,4|7,5 4,7|6,5 Erreur moyenne (%) 11,8|15,6 10,0|11,7 12,8|18,0 Nombre de pas 106|108 39|40 67|68 Table 7.2 – Précision des longueurs de pas fournies par l’algorithme, obtenues avec un filtre de Kalman et avec un filtre passe-bas (pour tous les pas, pour les pas « normaux » et pour les petits pas). 93Chapitre 7. Expérimentations pour l’analyse de la marche Filtre passe-bas Filtre Kalman -10 0 10 20 30 40 20 30 40 Erreur (cm) Figure 7.4 – Représentation des erreurs sur les longueurs de pas extraites à partir du filtre de Kalman et du filtre passe-bas. 7.1.3 Conclusion Cette première expérience nous permet de conclure que la hauteur et l’angle de la caméra n’ont pas d’influence sur la précision des paramètres de la marche fournis par notre dispositif. Cette expérience nous permet également de constater qu’il est préférable de filtrer la trajectoire du centre de masse avec un filtre de Kalman. En effet, les longueurs de pas obtenues lorsque la trajectoire est filtrée par Kalman sont plus proches des valeurs réelles que les longueurs de pas obtenues lorsque la trajectoire est filtrée par un filtre passe-bas. 7.2 Évaluation globale du système Les résultats obtenus dans la première évaluation permettent de constater qu’une expérience plus importante peut être réalisée et surtout permet de construire le nouveau protocole expérimental en prenant en compte les hypothèses que nous venons de tester. 7.2.1 Description de l’expérimentation 11 sujets sains ont intégré l’expérience, dont quatre femmes et sept hommes, âgés de 22 à 53 ans. L’expérience consiste à marcher sur un tapis actimètrique (le tapis de la marque GAITRite) de 5 mètres de longueur, comme montré à la figure 7.5. L’utilisation du tapis est une méthode plus coûteuse que la méthode « papier/encre », mais l’avantage est que nous pouvons traiter plus de données, car l’obtention des paramètres de la marche est automatisée. De plus, la récupération des longueurs de pas, dans la première évaluation, pouvait comporter des erreurs, car cette tâche était effectuée manuellement. L’erreur de mesure avec le tapis est 1,27 cm, représentant la distance entre chaque capteur. Les paramètres de la marche obtenus avec le tapis sont comparés aux valeurs fournies par l’algorithme de la caméra. Dans cette expérience, les trois paramètres de la marche sont comparés : les longueurs de pas, la cadence et la vitesse de la marche. 947.2. Évaluation globale du système Figure 7.5 – Expérience comprenant un tapis actimètrique. La première évaluation permet de structurer la nouvelle expérimentation. Notamment, elle nous a permis de constater qu’il n’y avait pas de différence significative concernant la précision des longueurs de pas liée à l’angle de la caméra (entre un angle de -27˚et 0˚). Donc, dans cette nouvelle expérience, nous considérons cette hypothèse de l’angle de la caméra comme avérée et c’est pourquoi nous ne testons pas différents angles, mais gardons le même pour toute l’expérience. La caméra est positionnée en hauteur avec un angle de -27˚. De plus, la première évaluation a montré que le filtre de Kalman donnait une meilleure précision des longueurs de pas comparé au filtre passe-bas. Donc, nous analysons uniquement les paramètres extraits à partir du filtre de Kalman. Enfin, lorsque les longueurs de pas sur le papier ont été récupérées, le dernier pas n’était pas conservé, étant situé au bord de l’image à l’endroit où le sujet quitte le champ de vision de la caméra. Les derniers pas sont donc enlevés pour chaque séquence dans cette nouvelle expérience. Comme dans la première évaluation, pour tester un large échantillon de données, les sujets marchent normalement puis font des petits pas. Trois nouvelles situations sont ajoutées : — marcher avec une longue robe (allant jusqu’au pied et pour tous les sujets) pour savoir si les vêtements peuvent perturber l’extraction des paramètres de la marche ; — marcher face à la caméra, toutes les autres situations étant réalisées avec la caméra positionnée perpendiculairement aux sujets ; — marcher avec deux caméras observant la même scène pour savoir si l’interférence ne dé- grade pas la précision des résultats. Pour suivre une personne à son domicile nous avons en effet besoin de couvrir les différentes pièces avec plusieurs caméras. En plaçant dans une même pièce plusieurs caméras, il est probable qu’il y ait des recouvrements entre leurs champs de vision. Avec la dernière situation, nous voulons évaluer si dans cette zone commune les résultats sont dégradés, car la caméra RGB-D que nous utilisons est un capteur actif. Les 11 sujets réalisent les cinq situations trois fois pour permettre d’obtenir une base de données suffisantes en nombre de pas. 7.2.2 Résultats Les valeurs des longueurs de pas, de la cadence et de la vitesse de marche sont mesurées avec le tapis et avec notre dispositif pour chaque séquence. Nous traitons 165 séquences, composées chacune de 2 à 5 pas, selon les sujets et la situation analysée. Les résultats sont présentés, dans 95Chapitre 7. Expérimentations pour l’analyse de la marche un premier temps, à travers une analyse de l’erreur sur chaque séquence, puis à travers une étude évaluant la moyenne des paramètres de la marche. Résultats basés sur l’erreur de chaque séquence Les erreurs entre les moyennes des paramètres de la marche, fournies par le tapis et notre algorithme, sont calculées pour chaque séquence. Les séquences sont ensuite regroupées par situations et nous présentons l’erreur moyenne calculée pour chaque situation. La table 7.3 montre les résultats. Dans chaque case de la table, le premier chiffre correspond soit aux erreurs moyennes des longueurs de pas exprimées en centimètres, soit aux erreurs moyennes de la cadence exprimée en nombre de pas par seconde, soit aux erreurs moyennes des vitesses en mètre par seconde. Puis le deuxième chiffre correspond à l’écart-type de ces données et le troisième à l’erreur en pourcentage. Normal Petit Jupe 2 caméras Face Long (cm|σ|%) 2,5|1,6|3,7 1,9|1,7|4,7 2,7|1,8|4,6 3,8|2,8|5,5 9,0|9,5|12,5 Cad (Pas/s|σ|%) 0,09|0,08|6,2 0,10|0,08|6,7 0,06|0,07|3,9 0,09|0,06|6,0 0,14|0,13|8,8 Vit (m/s|σ|%) 0,04|0,02|3,7 0,02|0,01|3,3 0,04|0,02|4,4 0,02|0,02|2,0 0,11|0,09|10,0 Nombre de pas 50 94 61 44 34 Table 7.3 – Erreurs moyennes des longueurs (Long), cadences (Cad) et vitesses (Vit) pour chaque situation. Les erreurs moyennes des longueurs, concernant les situations « Normal », « Petit » et « Jupe », sont similaires avec une erreur moyenne de 3,7 % à 4,7 %, représentant une erreur de moins de 2,7 cm. L’erreur moyenne, pour la situation où il y a deux caméras, est un peu plus grande avec une erreur de 5,5 %. L’erreur moyenne des longueurs est extrêmement grande avec une valeur de 12,5 % pour la situation où la personne marche face à la caméra. Les erreurs concernant les cadences sont plus grandes, à part pour la situation « Jupe » qui conserve une erreur d’environ 3,9 %. Les erreurs moyennes pour « Normal », « Petit » et « 2 caméras » sont entre 6 % et 6,7 %. L’erreur moyenne pour la situation « Face » est la plus grande, avec une erreur de 8,8 %. Les erreurs commises pour les vitesses sont inférieurs aux erreurs des deux autres paramètres de la marche. Pour les situations « Normal », « Petit », « 2 caméras » et « Jupe », les erreurs moyenne vont de 2,0 % à 4,4 %. En revanche, l’erreur moyenne pour la situation « Face » est très grande, soit 10,0 %. Résultats basés sur la moyenne de chaque paramètre de la marche Une autre façon d’analyser les résultats est de calculer la moyenne, pour toutes les séquences d’une même situation, de chaque paramètres de la marche. Les résultats sont montrés à la table 7.4. Cette table représente toutes les moyennes et les écart-types (notés σ) calculés, pour chaque paramètre et chaque situation, à partir des mesures fournies par le tapis et par notre algorithme. Pour les longueurs de pas, nous pouvons voir qu’il n’y a pas de grosses différences entre les moyennes obtenues avec le tapis et avec notre algorithme quelque soit la situation. L’écart maximal, entre le tapis et la caméra, est de 2,2 cm, obtenu pour la situation où les personnes portaient une jupe. Les situations « Normal », « 2 caméras » et « Petit » sont celles pour 967.3. Discussion et conclusion Longueur(cm) Cadence(Pas/s) Vitesse(m/s) Situation Technique Moyenne | σ Moyenne | σ Moyenne | σ Pas normaux Tapis 67,6 | 7,11 1,53 | 0,15 1,09 | 0,12 Caméra 67,0 | 8,31 1,61 | 0,20 1,12 | 0,12 Petits pas Tapis 38,4 | 6,82 1,44 | 0,19 0,57 | 0,11 Caméra 38,3 | 9,09 1,51 | 0,24 0,59 | 0,12 Avec jupe Tapis 57,1 | 8,72 1,46 | 0,31 0,92 | 0,14 Caméra 59,3 | 9,93 1,49 | 0,31 0,96 | 0,13 Face caméra Tapis 68,1 | 7,18 1,64 | 0,13 1,13 | 0,16 Caméra 66,5 | 27,77 1,61 | 0,75 1,02 | 0,16 Deux caméras Tapis 66,9 | 6,91 1,55 | 0,13 1,10 | 0,16 Caméra 66,8 | 8,65 1,60 | 0,16 1,11 | 0,16 Table 7.4 – Comparaison des paramètres de la marche obtenus avec le tapis et avec notre algorithme utilisant la caméra. lesquelles les écarts entre les moyennes du tapis et de la caméra sont les plus faibles. Pour la situation « Face », nous obtenons une erreur de 1,6 cm, mais avec une très grande variabilité. L’écart entre l’écart-type pour le tapis et pour la caméra est de 20 cm. Pour la cadence, l’écart entre les moyennes du tapis et de la caméra n’excède pas une erreur de 0,08 pas par seconde. Concernant la vitesse de marche, l’erreur est plus importante pour la situation « Face » que pour les autres situations. Pour la situation « Face », l’écart entre les moyennes est de 0,11 m/s alors que dans les autres situations, elle n’excède pas 0,04 m/s. 7.3 Discussion et conclusion Une première évaluation nous a permis de constater que le système fournit des valeurs proches de la réalité. Nous en avons déduit qu’il était possible d’investir dans une expérimentation plus importante. Cette première évaluation nous a également permis de valider l’hypothèse que l’angle de la caméra n’a pas d’influence sur la précision des résultats. Aussi, elle nous a permis de remarquer que le lissage de la trajectoire du centre de masse avec le filtre de Kalman fournit une plus grande précision des longueurs de pas comparée à la précision obtenue avec le filtre passe-bas. La seconde évaluation avait pour but de tester la précision des paramètres de la marche, obtenue avec la caméra, dans diverses situations pouvant être rencontrées au domicile. Ainsi lorsque deux caméras ont le même champ de vision, les résultats sont légèrement dégradés, comparés à la situation où la personne marche devant une seule caméra. Nous avons constaté que l’habillement n’avait, apparemment, pas d’influence sur la précision des résultats obtenus. A la section 4.2.2, nous avons décrit que les oscillations de la trajectoire du centre de masse sont dues au mouvement du centre de masse de la personne, amplifié par un artefact lié aux occlusions de profil du corps. La situation où la personne porte une jupe renforce l’idée de l’existence d’un artefact. En effet, les oscillations de la trajectoire du centre de masse, de la personne portant une jupe, sont plus grandes que celles où la personne porte un pantalon, comme montré à la figure 7.7. Le nombre de points détectés en bas du corps de la personne est encore plus grand quand elle marche vêtue d’une jupe, en position de double appui comme le montre la figure 7.6. Le 97Chapitre 7. Expérimentations pour l’analyse de la marche phénomène de l’artefact explique également pourquoi beaucoup d’erreurs sont commises quand la personne marche face à la caméra. Quand la caméra est face à la personne, l’artefact n’est plus présent, rendant la trajectoire du centre de masse plus lisse. L’atténuation de l’amplitude des oscillations est également due à la position de la caméra qui se trouve en hauteur, avec un angle de -27˚comme nous l’avons déjà décrit à la section 4.2.2. La trajectoire étant plus lisse, des erreurs d’extraction des maxima locaux et, par conséquent, d’extraction des paramètres de la marche sont commises. Les résultats, de cette deuxième évaluation, nous montrent également que si l’on souhaite installer un système au domicile, analysant les paramètres de la marche, nous devons analyser les moyennes obtenues pour chaque paramètre, par exemple à la fin de la journée. Nous avons montré que les moyennes pour chaque paramètre sont justes et fidèles aux valeurs réelles et cela pour toutes les situations même celles où la personne marche face caméra. Figure 7.6 – En phase de double appui, de nombreux points mobiles sont détectés dans la partie basse de la silhouette quand le sujet porte une jupe. 500 550 600 650 700 750 800 850 900 950 1000 33.5 34 34.5 35 35.5 36 36.5 37 37.5 Y (mm) Temps (s) Walking (a) Trajectoire du centre de masse d’un sujet marchant avec une jupe. 600 650 700 750 800 850 900 950 1000 1050 1100 34 34.5 35 35.5 36 36.5 37 Y (mm) Temps (s) Walking (b) Trajectoire du centre de masse d’un sujet marchant avec un pantalon. Figure 7.7 – Comparaison des oscillations de la trajectoire du centre de masse. 98Chapitre 8 Expérimentations pour la reconnaissance d’activité Sommaire 8.1 Cas de la personne entièrement visible . . . . . . . . . . . . . . . 99 8.1.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . 99 8.1.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 8.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 8.2 Cas de la personne partiellement visible . . . . . . . . . . . . . . 109 8.2.1 Description de l’expérimentation . . . . . . . . . . . . . . . . . . . . 109 8.2.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 8.2.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 Nous présentons deux expérimentations qui ont pour but de tester la capacité des différents modèles de Markov cachés à reconnaître l’activité de la personne. Nous les comparons entre eux pour identifier celui reflétant au mieux la réalité. Cette comparaison est effectuée en prenant une unique base de données pour l’apprentissage contenant des situations où les personnes sont entièrement visibles. Dans la première expérimentation, nous testons les différents modèles de Markov cachés construits pour reconnaître l’activité sur des séquences où la personne est entiè- rement visible. Puis dans la seconde expérimentation, nous évaluons le comportement de chaque modèle construit, face aux situations où la personne n’est pas entièrement visible. Cette évaluation est nécessaire, car, même en plaçant les caméras de façon à maximiser la couverture de la pièce, il est fort probable que la personne ne soit pas entièrement visible dans certaines zones. 8.1 Cas de la personne entièrement visible 8.1.1 Description de l’expérimentation Protocole expérimental 28 sujets, âgés de 20 à 53 ans, ont participé à l’expérience, dont 8 femmes et 20 hommes. Cette expérience s’est déroulée dans l’appartement laboratoire du centre de Nancy. Les sujets ont réalisés 8 situations filmés par une caméra RGB-D posée dans un angle de l’appartement. Le plan de l’appartement, avec la position de la caméra, est montré à la figure 8.1. La table représentée sur la figure, en face de la caméra, a été retirée pour permettre la réalisation des différentes situations. Chaque situation correspondait à une activité. Il s’agit des activités de la 99Chapitre 8. Expérimentations pour la reconnaissance d’activité vie quotidienne que nous avons définies précédemment, lors de la construction des modèles de Markov cachés au chapitre 6. Pour rappel, ces activités sont : s’accroupir, se pencher, s’asseoir, marcher, chuter, être allongé au sol, monter sur un obstacle et s’allonger sur un canapé. Plus précisément, la consigne donnée aux sujets était : — pour la situation « Se pencher » : ramasser un stylo en pliant le moins possible les genoux ; — pour la situation « S’accroupir » : ramasser un stylo en pliant les genoux, pour ainsi être plus proche du sol à la différence de la situation « Se pencher » ; — pour la situation « S’asseoir » : s’asseoir sur une chaise ; — pour la situation « Marcher » : marcher une fois en ligne droite et une fois en réalisant un demi-tour dans le champ de vision de la caméra. Ces deux séquences ont été regroupées dans l’unique situation « Marcher » ; — pour les situations « Chuter » et « Allongé au sol » : chuter sur un matelas et rester allongé, enregistrés en une seule séquence qui a ensuite été découpée manuellement ; — pour la situation « Monter sur un obstacle » : réaliser deux séquences, une en montant sur une chaise et une autre en montant sur un marche pied. La réalisation de deux séquences a permis d’apprendre la situation « Monté sur un obstacle » pour plusieurs tailles d’obstacle ; — pour la situation « S’allonger sur un canapé » : s’allonger sur trois chaises mises côte à côte. Les éléments tels que la chaise, le marche pied, le matelas, le stylo, étaient placés au milieu du champ de vision de la caméra. Avant d’atteindre ces éléments et de pouvoir réaliser la situation demandée, les personnes devaient d’abord marcher. Ensuite, après avoir réalisé ce qui était demandé, les sujets devaient remarcher, pour sortir du champ de vision de la caméra. Chaque situation est illustrée à la figure 8.2, montrant ainsi les étapes réalisées. Figure 8.1 – Plan de l’appartement expérimental avec le positionnement de la caméra. Par la suite, nous avons demandé à des sujets d’effectuer une situation où il devait marcher, se tenir debout à un endroit de la pièce, puis se déplacer pour rester à nouveau debout en répétant cela environ 5 fois. Ainsi, nous obtenons l’activité « Debout » à différentes distances de la caméra. Base d’apprentissage et base de test Les situations effectuées par les 28 sujets permettent de construire une base de données contenant 229 séquences. Chaque séquence a été segmentée et étiquetée manuellement. La base de données est utilisée pour apprendre les paramètres des modèles de Markov cachés et également pour tester la capacité des modèles à détecter correctement les activités réalisées. 1008.1. Cas de la personne entièrement visible Se pencher S’accroupir S’asseoir Marcher Faire un demi-tour Chute+Allongé au sol Monter S’allonger sur un canapé Figure 8.2 – Suivi des situations, effectuées par un sujet, à différents pas de temps. 101Chapitre 8. Expérimentations pour la reconnaissance d’activité 185 séquences (soit 22 sujets) sont conservées pour l’apprentissage. Pour les modèles des sections 6.3.1 et 6.3.2, avec fonction d’observation seule et n’utilisant qu’un MMC, la moyenne de chaque paramètre (position verticale du centre de masse, sa vitesse verticale et la dispersion verticale du corps de la personne et pour certains modèles, la vitesse horizontale et le point maximum) et la covariance sont apprises à partir de cette base d’apprentissage. Elles sont également apprises pour chaque état du MMC, pour ainsi construire la fonction d’observation. Pour les modèles utilisant plusieurs MMC de la section 6.3.3, la matrice de transition, les probabilités initiales et la fonction d’observation (utilisant les moyennes et les covariances des trois ou cinq paramètres selon le modèle) sont apprises, pour chaque MMC, à partir de cette même base de données et ce grâce à l’algorithme de Baum-Welch. Les 44 séquences restantes (correspondant à 6 sujets) sont utilisées pour tester le modèle. Nous fournissons à l’algorithme ces 44 séquences et nous observons si celui-ci détecte correctement l’activité réalisée. Les résultats sont montrés à la section suivante. 8.1.2 Résultats Comme indiqué précédemment, 44 séquences sont données à chacun des modèles construits. Les algorithmes Forward-Backward et de Viterbi fournissent les classifications dans le cas des modèles à un seul MMC. La vraisemblance du modèle permet de classer les situations dans le cas de l’utilisation de plusieurs MMC. Représentation des bonnes classifications et des fausses détections Deux façons de représenter les résultats sont proposées pour évaluer les modèles, tout d’abord en observant les bonnes classifications puis en calculant le nombre de fausses détections. Bonnes classifications Tout d’abord, le tableau 8.1 indique le nombre de bonnes classifications pour chaque activité selon le modèle utilisé. Les différents modèles sont exprimés dans ce tableau par des abréviations dont la signification est la suivante : — « Modèle observations seules » correspond au modèle à 8 états avec la fonction d’observation seule de la section 6.3.1 ; — « 1MMC 3 observations » représente le MMC à 8 états avec matrice de transition, définie manuellement, et 3 observations décrit à la section 6.3.2 ; — « 1MMC 5 observations » représente le MMC à 9 états avec matrice de transition, définie manuellement, et 5 observations décrit à la section 6.3.2 ; — « 8MMC 2 états » et « 8MMC 3 états » correspondent au système de 8 MMC à 2 ou 3 états et 3 observations décrit à la section 6.3.3 ; — « 9MMC 2 états » et « 9MMC 3 états » correspondent au système de 9 MMC à 2 ou 3 états et 5 observations décrit à la section 6.3.3. Les colonnes représentent les différentes activités (« Acc » : Accroupi, « All » : Allongé sur un Canapé, « Ass » : Assis, « Chu » : Chute, « Sol » : Allongé au sol, « Mar » : Marche, « Mon » : Monté sur un obstacle, « Pen » : Penché, « Dem » : Demi-tour). Nous séparons l’activité « Marche » et « Demi-tour » dans le tableau mais toutes les deux doivent être reconnues comme « Marche » par l’algorithme pour être correctes. Dans chaque case du tableau, le premier chiffre (dans certain cas l’unique chiffre) correspond au nombre de bonnes classifications. Nous considérons comme « bonne classification » toutes les activités qui ont été réalisées dans une séquence et qui ont été détectées par l’algorithme avant la fin de l’activité. Par exemple, si une personne s’assoit et que l’algorithme détecte l’activité 1028.1. Cas de la personne entièrement visible « Assis » lorsque la personne se relève, nous considérons que l’algorithme n’a pas détecté la bonne activité, car il l’a détectée trop tard. Dans certains cas, un deuxième chiffre est présent dans la case, correspondant au nombre de fois, inclus dans le premier chiffre, où l’algorithme donne la bonne activité en insérant, toutefois, une autre activité non réalisée dans la séquence. Ainsi, nous comptons comme juste cette séquence dans le premier chiffre mais nous indiquons son erreur par le deuxième chiffre. Nous considérons qu’il s’agit d’une classification correcte, car bien souvent l’insertion d’activité, non réalisée dans la séquence, se produit dans les phases de transition entre deux activités réalisées par la personne. Par exemple, lorsque la personne s’assoit, ce qui nous intéresse est que l’algorithme détecte correctement « Assis » quand la personne est effectivement assise et non pas quand elle passe de debout à assise. Pour expliquer la deuxième case du tableau, la situation « S’allonger sur un canapé », analysée par le modèle avec la fonction d’observation seule, contient « 5 | 2 » signifiant que 5 séquences ont été correctement identifiées et que, parmi ces 5 séquences, une autre activité a été indiquée 2 fois avant que la bonne activité soit finalement détectée. La ligne « Total » du tableau indique le nombre total d’occurrences qui aurait dû être trouvé pour chaque activité. Par exemple, pour la deuxième case du modèle sans transition, l’algorithme a reconnu que la personne était dans la situation « Allongé Canapé » dans 5 séquences sur 6. Acc All Ass Chu Sol Mar Mon Pen Dem Modèle observations seules 6 | 6 5 | 2 5 | 5 6 | 5 6 5 6 2 4 | 1 1MMC 3 observations 6 5 5 6 6 5 6 2 5 1MMC 5 observations 6 5 6 6 6 5 6 2 5 8MMC 2 états 6 | 3 4 6 | 1 6 4 5 | 1 4 | 1 4 5 | 1 8MMC 3 états 6 5 5 6 6 5 5 2 5 9MMC 2 états 1 5 6 6 1 5 4 4 4 9MMC 3 états 6 3 6 6 0 5 1 0 4 Total 6 6 6 6 6 5 6 4 5 Table 8.1 – Classification des activités par l’algorithme selon le modèle utilisé. Le tableau 8.1 présente le nombre de fois où une séquence a été correctement détectée. Fausses détections La deuxième représentation est de créer un tableau indiquant, quant à lui, les fausses détections. Les résultats sont présentés, pour chaque modèle, dans le tableau 8.2. Par exemple, pour le modèle sans transition, l’algorithme commet 2 fausses détections en détectant « Assis », 9 pour « Chuter » et 3 pour « Pencher ». Nous considérons une fausse détection lorsque l’activité réalisée n’est à aucun moment détectée dans la séquence ou l’est trop tard. Les activités « Chute » et « Allongé au sol » sont considérées comme des cas particuliers. A chaque fois que l’algorithme indique l’état « Chute » ou « Allongé Sol » alors que ces activités n’ont pas été réalisées, nous considérons qu’il commet une fausse détection, même si l’algorithme donne finalement la bonne activité. L’idée est de considérer la détection d’une chute (ou être allongé au sol) comme une information très importante et commettre une fausse détection de ces activités est plus grave que de produire une fausse détection des autres activités. Comparaison entre les algorithmes Forward-Backward et de Viterbi Les algorithmes Forward-Backward et de Viterbi s’utilisent dans le cas du modèle sans transition, du MMC à 8 et 9 états avec matrice de transition. Dans les tableaux 8.1 et 8.2, les résultats 103Chapitre 8. Expérimentations pour la reconnaissance d’activité Acc All Ass Chu Sol Mar Mon Pen Modèle observations seules 0 0 2 9 0 0 0 3 1MMC 3 observations 1 0 2 0 0 0 0 1 1MMC 5 observations 1 0 1 1 0 0 0 0 8MMC 2 états 4 0 0 3 0 0 0 3 8MMC 3 états 2 0 2 0 0 0 0 1 9MMC 2 états 0 0 1 3 0 2 0 6 9MMC 3 états 13 0 0 3 0 0 0 0 Table 8.2 – Fausses détections effectuées par l’algorithme selon le modèle utilisé. des trois premières lignes concernent l’algorithme Forward-Backward. La distinction entre les deux algorithmes n’est pas présentée, car peu de différences existent au niveau des résultats. La seule différence (mais elle n’est de toute façon pas prise en compte dans les tableaux) se situe au niveau des « états de transition » comme montré à la figure 8.3. Celle-ci présente les résultats de l’analyse effectuée pour les deux algorithmes, avec le MMC à 8 états et 3 observations, à partir d’une même séquence. Dans cette séquence, le sujet devait s’asseoir et se lever sur une chaise sans marcher entre les deux situations. Forward-Backward infère correctement les bonnes activités comme le montre la figure 8.3(a). L’algorithme de Viterbi de la figure 8.3(b) fournit plus d’états. Pour passer de « Assis » à « Monté sur un obstacle », le sujet ne marche pas, or l’algorithme de Viterbi infère l’état « Marche ». Cette décision de l’algorithme de Viterbi n’est pas correcte, mais il a l’avantage de coller aux contraintes fournies par le MMC. Dans l’approche à un unique MMC, où la matrice de transition est définie manuellement, l’état « Marche » est défini comme précédent et suivant l’état « Assis ». Donc la figure 8.3(b) montre que l’algorithme de Viterbi passe par l’état « Marche » avant et après l’état « Monté sur un obstacle » respectant ainsi le modèle défini, même si le sujet ne marche pas.                          (a) Analyse par l’algorithme Forward-Backward.                            (b) Analyse par l’algorithme de Viterbi. Figure 8.3 – Différence dans l’analyse faite par les algorithmes Forward-Backward et de Viterbi, pour une séquence où la personne s’assoit puis monte sur une chaise. Pour la suite, les résultats seront donnés uniquement pour l’algorithme Forward-Backward, car nous préférons conserver l’algorithme qui colle aux situations réalisées plutôt que de conserver l’algorithme qui colle au modèle défini manuellement. 1048.1. Cas de la personne entièrement visible Modèle avec fonction d’observation seule D’après le tableau 8.1, le modèle sans matrice de transition, détecte toutes les activités correspondant à « Accroupi », « Chute », « Allongé au sol », « Marche » et « Monté sur un obstacle ». Pour l’activité « Allongé Canapé », « Assis » et « Demi-tour » l’algorithme manque une détection. Malgré une bonne détection des chutes, la performance de ce modèle est atténuée par le nombre important de fausses détections concernant les chutes comme montré à la Table 8.2. Pour chaque état nécessitant une descente du corps de la personne (par exemple « Assis », « Accroupi »), l’algorithme détecte une chute puis rectifie en donnant le bon état. Les bonnes classifications sont rarement données directement comme on peut le voir par la présence du deuxième chiffre, dans les cases de la première ligne du Tableau 8.1, indiquant que la décision est bruitée. C’est-à-dire que l’algorithme, avant de donner le bon état, donne d’autres états non atteints dans la réalité. Cela peut être constaté par la figure 8.4(b) représentant la trajectoire du centre de masse sur l’axe vertical et le déroulement des décisions de l’activité dans le temps, par le modèle avec fonction d’observation seule. La figure représente le centre de masse d’une personne s’asseyant et montre que l’algorithme hésite à plusieurs reprises avant de donner la bonne activité réalisée « Assis ». -1500 -1450 -1400 -1350 -1300 -1250 -1200 -1150 -1100 -1050 850 900 950 1000 1050 1100 1150 Y (mm) Temps (s) Walking Sitting Walking Sitting (a) Séquence analysée par le MMC à trois observations. -1500 -1450 -1400 -1350 -1300 -1250 -1200 -1150 -1100 -1050 850 900 950 1000 1050 1100 1150 Y (mm) Temps (s) Sitting Walking Going up Walking Going up Walking Going up Sitting Bending Falling Bending Squatting Sitting Squatting Sitting Squatting Walking Falling Sitting (b) Séqunce analysée par le modèle sans transition. Figure 8.4 – Comparaison d’une séquence où la personne s’assoit analysée par deux modèles. MMC à 8 états et 3 observations Les résultats pour le MMC avec une matrice de transition montrent que les activités « Accroupi », « Chute », « Allongé au sol », « Marche » (pour les séquences où la personne marche et où elle fait un demi-tour) et « Monté sur un obstacle » sont toutes reconnues par le modèle. L’activité « Penché » est l’activité la moins bien reconnue, seulement deux fois sur quatre. Cette activité est remplacée par l’état « Assis ». Cette information est renseignée par le tableau des fausses détections 8.2. Le modèle commet une erreur pour l’activité où la personne s’allonge sur un canapé en désignant cette activité comme étant l’état « Accroupi ». Cette erreur vient du fait que la personne ne s’allonge pas complètement sur le canapé mais s’appuie sur son coude comme le montre la figure 8.5 provoquant une situation différente de ce qui a été appris par le modèle. Le modèle ne reconnaît pas non plus une situation où la personne est assise. En réalité, l’algorithme indique correctement l’état « Assis » lors de la descente et la remontée de la personne mais lorsque celle-ci est assise, le modèle reconnaît cette situation comme étant l’état « Penché », comme illustré à la figure 8.6. Sur cette figure, nous pouvons comprendre l’erreur 105Chapitre 8. Expérimentations pour la reconnaissance d’activité qui a été commise du fait que la personne en s’asseyant a remonté sa jambe sur son autre jambe. Ainsi, la trajectoire du centre de masse est remontée correspondant, pour le modèle, à l’état « Penché ». Figure 8.5 – Sujet s’allongeant différemment de ce qui a été appris dans la base de donnée. 700 750 800 850 900 950 1000 1050 1100 29 30 31 32 33 34 35 36 37 38 39 Y (mm) Temps (s) Walking Sitting Bending Sitting Walking Figure 8.6 – Sujet s’asseyant différemment de ce qui a été appris dans la base de donnée. Ce modèle détecte les bonnes activités de façon similaire au modèle sans matrice de transition. De plus, il présente l’avantage de faire moins de fausses détections comme le montre le tableau 8.2 et aucune fausse détection concernant les chutes. Ce modèle diffère également du précédent par le fait qu’il donne la bonne activité sans hésiter avec d’autres états (ceci est démontré par l’absence du deuxième chiffre dans les cases du tableau 8.1). Cette différence entre les deux modèles peut être observée à la figure 8.4. Les deux figures représentent la trajectoire du centre de masse sur l’axe vertical pour une personne marchant puis s’asseyant et enfin marchant pour sortir du champ de vision de la caméra. Ces figures indiquent les détections, par l’algorithme, des états dans lesquels est passée la personne. La figure 8.4(b) montre que le modèle sans transition est plus bruité que le modèle avec matrice de transition représenté à la figure 8.4(a). Selon nos critères, la classification pour le modèle sans transition est correcte, puisqu’au final l’algorithme 1068.1. Cas de la personne entièrement visible indique l’état « Assis », mais la décision apparaît plus lentement comparé au modèle avec des transitions, qui lui n’hésite pas sur l’activité réalisée. MMC à 9 états et 5 observations Les résultats pour le MMC à 9 états montrent que la classification des activités est semblable au modèle précédent. Dans ce modèle, les situations « Assis » sont toutes reconnues. De plus, toutes les activités sont reconnues directement, sans hésitation avec une autre activité comme le montre l’absence du deuxième chiffre dans les cases du tableau 8.1. Le modèle à 9 états fait moins d’erreur au niveau des fausses détections que le précédent modèle à 8 états. Par contre, l’inconvénient est qu’il commet une fausse détection importante en donnant l’activité « Chute » à la place de l’état « Penché ». Système de 8 MMC à 2 états et 3 observations La reconnaissance d’activité est similaire aux autres modèles avec néanmoins les activités « Monté » et « Allongé Canapé » qui sont moins bien reconnues. Toutes les activités, où la personne se penche, sont ici reconnues. Les séquences où la personne « Chute » sont toutes reconnues, par contre l’activité « Allongé au sol » suivant la chute n’est pas toujours reconnue. La matrice de transition forçant le passage de « Chute » à « Allongé au sol » n’est plus présente dans ce modèle, cela permet de détecter l’état « Chute » sans forcément être suivi de l’état « Allongé au sol ». Remarquons que, dans certain cas les sujets se levaient directement après leur chute ne passant pas forcément par la situation « Allongé au sol ». Il y a un peu d’hésitation sur l’activité réalisée, la bonne classification ne se faisant pas toujours directement (comme on peut le voir avec la présence du deuxième chiffre du Tableau 8.1). Peu de fausses détections sont présentes ici, mais l’inconvénient est qu’il y a trois détections de « Chute » non pertinentes. Système de 8 MMC à 3 états et 3 observations Le nouveau modèle classifie correctement les activités. L’état « Penché » reste celui qui est le moins bien distingué. Les décisions de l’algorithme, concernant l’état dans lequel se trouve la personne, sont directes comme on peut le voir par l’absence d’un deuxième chiffre dans la ligne « 8MMC 3 états » du Tableau 8.1. La différence avec le précédent modèle se trouve également au niveau des fausses détections. L’algorithme ne commet aucune fausse détection concernant les chutes. De plus, peu d’erreurs sont commises en règle générale par ce modèle. Système de 9 MMC à 2 états et 5 observations Le tableau 8.1 montre que ce modèle classifie correctement les activités sauf pour deux états, « Accroupi » et « Allongé Sol ». Les situations « Allongé Sol » ne sont pas reconnues mais cela ne gêne pas la détection de l’état « Chute ». Ce modèle commet peu de fausses détections. Les erreurs proviennent surtout de l’état « Accroupi » qui n’est pas détecté. L’algorithme remplace toutes les situations où la personne s’accroupit par l’état « Chute » suivi de l’état « Penché ». 107Chapitre 8. Expérimentations pour la reconnaissance d’activité Système de 9 MMC à 3 états et 5 observations Ce modèle commet de nombreuses erreurs de classification notamment pour les états « Allongé Canapé », « Monté », « Allongé Sol » et « Penché ». Les états « Allongé Sol » et « Penché » ne sont d’ailleurs jamais reconnus. L’état « Penché » est confondu avec l’état « Accroupi ». L’état « Allongé Sol » n’est jamais reconnu mais cela n’empêche pas la chute d’être quant à elle détectée. Le modèle infère l’état « Accroupi » très souvent puisque 13 fausses détections ont été ré- pertoriées pour cet état. Le modèle commet également trois fausses détections concernant l’état « Chute ». Résultats pour l’activité debout Nous avons demandé à une personne de se tenir debout dans le but de savoir ce qu’infèrent les différents modèles. Le modèle à 9 états 5 observations et les systèmes de 9 MMC ont appris à différencier l’activité « Debout », donc il devrait la reconnaître. En revanche, les modèles à 8 états et les systèmes de 8 MMC n’ont pas eu, dans leur base d’apprentissage, une telle activité. Nous voulons ainsi connaître l’activité inférée, en pensant qu’ils vont la classifier comme étant l’activité « Marche ». Les résultats sont montrés à la table 8.3. Debout Modèle observations seules Marche 1MMC 3 observations Marche 1MMC 5 observations Debout 8MMC 2 états Marche 8MMC 3 états Marche 9MMC 2 états Assis 9MMC 3 états Accroupi Table 8.3 – Classification de l’activité « Debout » selon le modèle utilisé. Les résultats montrent que seul le modèle à 9 états et 5 observations détecte l’état « Debout ». La plupart des autres modèles infèrent l’état « Marche ». 8.1.3 Conclusion L’expérimentation nous a permis de comparer les différents modèles construits sur une même base de test. Les résultats nous permettent de savoir quels sont les modèles les plus justes. La classification réalisée par le modèle sans matrice de transition, après de nombreuses hésitations entre différents états, donne finalement de bons résultats. Mais ce modèle ne peut pas être conservé, car il fournit beaucoup de fausses détections concernant les chutes. Le modèle avec transitions à 8 états et 3 observations produit peu de fausses détections et surtout aucune concernant les chutes. La probabilité de transition d’aller dans l’état « Chute » a été définie manuellement comme très faible. Ainsi, l’observation doit être vraiment « forte » pour passer dans l’état « Chute » avec ce modèle. Le modèle réalise peu d’erreurs de classification. L’état le moins bien détecté est « Penché » en omettant 2 situations sur 4. Toutes les chutes sont détectées. Le modèle à 9 états et deux observations en plus des modèles précédents n’apporte pas de meilleurs résultats de classification. Au contraire, il commet une fausse détection concernant l’état « Chute », ce que ne faisait pas le modèle précédent. L’idée en combinant plusieurs modèles de Markov cachés est de 1088.2. Cas de la personne partiellement visible tester des modèles sans connaissance a priori. Le système de 8 MMC, appris par Baum-Welch, à 3 états et 3 observations s’avère le modèle s’approchant au mieux de la réalité. Ce modèle donne de bons résultats au niveau de la classification et c’est le seul parmi les systèmes de MMC à ne faire aucune fausse détection concernant les chutes. Pour développer un algorithme capable de détecter les activités de la personne au cours de la journée et de détecter ses chutes, nous avons besoin d’un modèle classifiant les bonnes activités et surtout un modèle effectuant peu de fausses détections. L’algorithme à un modèle de Markov caché à 8 états et celui utilisant le système de 8 MMC à trois états détectent toutes les chutes sans produire de fausse détection et classifient correctement les autres activités, ce qui correspond à nos attentes. Ces deux modèles sont équivalents au niveau des résultats, mais on préfère un modèle ayant appris par lui-même les différentes probabilités. En effet, le système de 8 MMC, n’étant pas contraint au niveau de la dynamique des situations, est plus général et correspond alors mieux aux situations non prévues qu’un modèle où nous avons inséré de la connaissance. Ces résultats nous montrent que les modèles à trois observations sont tout autant, voire plus justes que les modèles à cinq observations. Bien que nous ayons ajouté un état et qu’il est donc possible de distinguer l’état « Debout » avec 5 observations, la qualité de classification s’avère dégradée pour certains modèles. Donc, en ajoutant des états et des observations, nous ajoutons de la complexité et perdons au niveau précision des résultats. 8.2 Cas de la personne partiellement visible 8.2.1 Description de l’expérimentation Nous avons demandé à une personne d’effectuer des activités en étant cachée par des objets. Ces activités correspondent à celles utilisées pour construire les MMC. Les consignes pour réaliser ces neuf situations sont les suivantes : — la personne se penche derrière une table ; — la personne s’accroupit derrière une table ; — la personne s’assoit sur une chaise placée derrière une table ; — la personne marche derrière trois chaises posées l’une à côté de l’autre ; — la personne marche et réalise plusieurs demi-tours derrière les trois chaises ; — la personne chute et s’allonge au sol derrière une table ; — la personne s’allonge sur un canapé en posant un drap sur elle ; — la personne monte sur une chaise placée derrière une table ; — la personne reste debout derrière une table. Chaque situation est illustrée à la figure 8.7, montrant ainsi les étapes réalisées par le sujet à chaque séquence. La table correspond à une table à manger d’environ 80 cm de hauteur. Lorsque la personne chute, elle n’est donc plus visible. Dans le cas des autres situations, une partie du corps de la personne reste toujours visible. 8.2.2 Résultats Chaque situation, que devait réaliser le sujet, est analysée par les différents modèles construits. Nous avons regroupé dans la table 8.4 les activités inférées par chaque modèle à chaque situation. Les colonnes représentent les différentes activités réalisées par la personne (« Acc » : Accroupi, « Ass » : Assis, « Chu » : Chute, « Mar » : Marche, « Mo » : Monté sur un obstacle, « Pen » : Penché, « Dem » : Demi-tour, « All » : Allongé sur un canapé, « De » : Debout). Chaque case 109Chapitre 8. Expérimentations pour la reconnaissance d’activité Se pencher S’accroupir S’asseoir Marcher 1108.2. Cas de la personne partiellement visible Faire des demi-tours Chute+Allongé au sol S’allonger sur un canapé Monter Debout Figure 8.7 – Suivi des situations où le sujet n’est pas entièrement visible à différents pas de temps. 111Chapitre 8. Expérimentations pour la reconnaissance d’activité indique l’activité que le modèle a inféré. Les activités inscrites en vert correspondent aux bonnes classifications. Le précédent tableau 8.1 indiquait les bonnes classifications dans le cadre de situations semblables à celles contenues dans la base de données. Dans cette nouvelle table 8.4, les erreurs de classifications sont plus fréquentes, car il s’agit de situations nouvelles, non apprises, où la personne est à moitié visible par la caméra. Le tableau nous informe que l’activité « Monté » est l’activité la mieux détectée par presque tous les modèles. La situation « S’allonger sur un canapé », sous un drap, est particulière, car sa réalisation entraîne la modification du fond appris. Lorsque la personne s’allonge, elle prend le drap pour le mettre sur elle. Ce qui a pour conséquence de cacher son corps et de sortir le drap du fond appris. Comme nous pouvons le voir sur les images de la figure 8.7, le drap est détecté comme mobile. La plupart des modèles reconnaissent l’activité « Assis », qui précède et suit l’activité « Allongé Canapé ». Cependant l’activité « Allongé Canapé » en elle-même, lorsqu’elle est réalisée sous un drap, n’est pas reconnue. Le modèle commettant le moins d’erreurs de classification est le modèle à 9 états et 5 observations. De plus, dans la situation où la personne a réalisé plusieurs demi-tours derrière des chaises, ce modèle est le seul à indiquer les demi-tours comme le montre la figure 8.8. L’activité « Demi-tour » n’est pas contenue dans la base de donnée, mais le modèle à 9 états et 5 observations infère l’état « Debout » lorsque la personne tourne sur elle-même pour réaliser le demi-tour, puis infère l’état « Marche » entre chaque deux demi-tours. 800 850 900 950 1000 1050 1100 1150 1200 1250 1300 38 40 42 44 46 48 50 52 54 56 Y Temps (s) Walking Upright Walking Upright Walking Upright Walking Upright Walking Upright Walking Upright Walking (mm) Figure 8.8 – Résultat de l’analyse avec le modèle à 9 états et 5 observations, pour une personne réalisant des demi-tours. Pour l’ensemble des modèles, nous pouvons remarquer qu’il y a confusion entre les états « Accroupi », « Penché » et « Chute ». Ce problème peut être résolu en ajoutant la notion de temps. Par exemple, pour l’état « Accroupi » et « Penché » la personne reste très peu de temps dans ces activités alors que l’activité « Chute » correspond à une situation où la personne n’est plus visible durant une certaine période. 1128.2. Cas de la personne partiellement visible Acc Ass Chu Mar Mo Pen Modèle observations seules Acc Pen Acc Mon + Ma Mo Pe 1MMC 3 observations Chu + Acc Acc Chu Ma Mo Acc 1MMC 5 observations Chu + Acc Ass Chu Ma Mo Acc 8MMC 2 états Acc Acc Acc Acc Mo Acc 8MMC 3 états Acc Acc Acc Acc Mo Acc 9MMC 2 états Acc Ass Ass Ma Mo Acc 9MMC 3 états Acc Acc Acc Acc Acc Acc Dem All De Modèle observations seules Mo +Acc + Ma Acc Ma 1MMC 3 observations Ma Acc Acc + Ma 1MMC 5 observations De +Ma Acc De 8MMC 2 états Acc Acc Acc 8MMC 3 états Acc Acc Acc 9MMC 2 états Ma Acc Ass + Ma 9MMC 3 états Acc Acc Acc Table 8.4 – Détection d’activité quand la personne n’est pas entièrement visible pour différents modèles. 8.2.3 Conclusion Avec la première expérimentation pour la reconnaissance d’activité d’une personne entièrement visible, nous avions conclu que le modèle à 8 états 3 observations et le système de 8 MMC étaient ceux commettant le moins d’erreurs de classification et peu de fausses détections. Le modèle à 9 états et 5 observations avait l’avantage de distinguer l’activité « Debout » de « Marche ». Mais ce modèle ajoutait de la complexité, en ajoutant deux observations de plus que ceux à 8 états, sans pour autant donner de meilleurs résultats. Avec la deuxième expérimentation pour la reconnaissance d’activité d’une personne partiellement visible, nous avons montré que le modèle à 9 états et 5 observations est celui donnant les meilleurs résultats pour traiter les situations d’occlusion de la personne non apprises dans la base de données. Pour le domicile, nous pensons que ce modèle fournira les meilleures classifications. 113Chapitre 8. Expérimentations pour la reconnaissance d’activité 114Chapitre 9 Tests en situations réelles Sommaire 9.1 Test de l’algorithme d’analyse de la marche . . . . . . . . . . . . 115 9.2 Test de l’algorithme de détection d’activité . . . . . . . . . . . . 116 9.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 Une limite des expérimentations, décrites dans les deux chapitres précédents, est qu’elles ont été réalisées en laboratoire avec des sujets ne représentant pas la catégorie à laquelle cette thèse s’adresse. Ces expérimentations doivent être effectuées avec des sujets appropriés pour savoir si les résultats restent les mêmes. Dans ce chapitre, nous présentons des résultats de quelques tests effectués sur des personnes âgées. 9.1 Test de l’algorithme d’analyse de la marche 6 personnes âgées ont réalisé quelques séquences filmées par notre dispositif. Ces enregistrements ont été réalisés dans des milieux réels en dehors de l’appartement expérimental. Tout d’abord, nous avons demandé à deux personnes, à l’hôpital, de marcher devant notre système. Ces deux patientes, ayant des problèmes liés à la marche et à l’équilibre, sont venues pour réaliser un bilan médical avec un médecin. Les consultations durent une heure, pendant laquelle de nombreux tests cliniques sont effectués pour constituer un bilan de la fragilité de la personne. Un des tests cliniques réalisé était de marcher sur 10 mètres. Durant ce test, nous avons filmé ces deux personnes. La figure 9.1 montre la marche de l’une des deux personnes et la trajectoire de son centre de masse, sur l’axe vertical, avec les longueurs de pas détectées. Pour cette expérience, nous n’avons pas de système de référence. Nous ne savons donc pas si notre système fournit des paramètres de la marche justes par rapport à la réalité. Nous pouvons, uniquement, effectuer une analyse qualitative en observant que le système détecte, comme dans nos précédentes expérimentations effectuées sur les sujets jeunes, des oscillations et est capable d’extraire les paramètres de la marche. De plus, nous pouvons remarquer que les longueurs de pas détectées (68 cm, 53 cm et 55 cm) sont des mesures plausibles et que leur nombre est juste. Nous avons également filmé quatre personnes de plus de 80 ans, chez elles. Trois personnes sur quatre ont déjà chuté. Nous avons demandé aux personnes de marcher perpendiculairement à la caméra que nous avons posée dans le salon, sur des meubles hauts. Dans les quatre cas, les oscillations du centre de masse sont présentes comme nous pouvons le voir sur la figure 9.2. Cette figure présente les trajectoires du centre de masse, sur l’axe vertical, des quatre personnes. Les maxima des oscillations étant perceptibles, l’algorithme peut en déduire les paramètres de 115Chapitre 9. Tests en situations réelles Figure 9.1 – Utilisation de notre système avec une patiente, lors de sa consultation à l’hôpital. la marche. Nous n’avons, toutefois, pas de méthode de référence pour savoir si la localisation des oscillations permet de fournir les paramètres de la marche proche de la réalité. L’analyse qualitative nous permet de constater que la trajectoire du centre de masse la plus régulière, parmi les figures 9.2, appartient à la personne âgée n’ayant jamais chuté 9.2(a). Parmi les quatre personnes, une des personnes a d’importants problèmes d’équilibre. La personne a déjà chuté plusieurs fois. La trajectoire de son centre de masse, sur l’axe vertical, est représentée à la figure 9.2(d). Les oscillations sont moins régulières que ce que nous pouvons voir avec des personnes jeunes, mais la trajectoire reste sinusoïdale. Il est donc possible d’obtenir les paramètres de la marche. Une autre personne, de 84 ans ayant récemment chuté, a marché devant notre système. La trajectoire de son centre de masse, représentée à la figure 9.2(c), oscille peu. L’espacement des maxima indique une cadence plus lente que pour la personne représentée à la figure 9.2(a). Quand la personne a marché, nous avons pu voir qu’elle restait très droite. Pour finir, un des sujets a une jambe artificielle et a donc marché avec 2 cannes. Quand il marche, la jambe artificielle est peu soulevée du sol. La représentation de la trajectoire de son centre de masse est montré à la figure 9.2(b). Nous pouvons voir que, malgré les différentes façons de marcher, différentes de ce que nous pouvions avoir avec les sujets jeunes, le système fournit le même type de trajectoires, même si elles sont moins régulières avec les personnes âgées qu’avec les plus jeunes. 9.2 Test de l’algorithme de détection d’activité L’algorithme de détection d’activité fournit de bons résultats au niveau de la classification, comme nous l’avons vu au chapitre 8, sur des personnes jeunes. Nous avons testé l’algorithme pour quelques activités réalisées par des personnes âgées. Pour les précédentes situations où la personne marchait devant la caméra à leur domicile ou à l’hôpital, l’algorithme de détection d’activité a correctement classifié les personnes en train de marcher. Comme nous pouvons le voir à la figure 9.3, pour une personne, marchant à son domicile, l’algorithme indique qu’elle marche. Nous avons également testé la capacité de l’algorithme à détecter d’autres activités. Nous avons demandé à un des sujets de s’asseoir, de se pencher et de monter sur un marche pied. La figure 9.4 montre le résultat pour chacune des activités réalisées par le sujet. Chaque figure représente la trajectoire du centre de masse de la personne, sur l’axe vertical, avec l’évaluation par 1169.2. Test de l’algorithme de détection d’activité 550 600 650 700 750 800 850 900 34 34.5 35 35.5 36 36.5 37 37.5 38 Y (mm) Temps (s) (a) Marche d’une personne de 81 ans n’ayant jamais chuté. 500 550 600 650 700 750 800 850 900 950 36 37 38 39 40 41 42 43 44 45 Temps (s) Y (mm) (b) Marche d’une personne de 80 ans ayant une jambe artificielle. 450 500 550 600 650 700 750 800 850 900 55.5 56 56.5 57 57.5 58 58.5 59 59.5 60 Y (mm) Temps (s) (c) Marche d’une personne de 84 ans ayant chuté. 550 600 650 700 750 800 850 900 47 48 49 50 51 52 53 54 Y (mm) Temps (s) (d) Marche d’une personne de 90 ans ayant des problèmes d’équilibre. Figure 9.2 – Représentation du centre de masse, sur l’axe vertical, de quatre personnes âgées. Figure 9.3 – Détection de l’activité « Marche », pour une personne de 81 ans marchant à son domicile. 117Chapitre 9. Tests en situations réelles l’algorithme de l’état dans lequel se trouve la personne. Les situations où la personne s’assoit et où elle se penche sont correctement reconnues. Nous pouvons également constater que les phases où la personne marche avant et après la réalisation de l’activité « Assis » et « Penché » sont reconnues comme « Marche ». L’activité « Monté » n’est pas reconnue. La personne montait sur un marche pied de 13,5 cm. La personne a tout d’abord essayé de monter mais est retombée au sol très rapidement, n’arrivant pas à tenir sur le marche pied. Puis, elle est remontée et est restée immobile quelques secondes. La montée n’était peut être pas assez grande pour que l’algorithme la détecte. Dans la base de donnée, pour la situation « Monté », les personnes montaient sur une chaise et seulement 5 d’entre elles ont réalisé une deuxième séquence avec un marche pied. Nous pensons que les paramètres appris pour une chaise sont différents de ceux qui seraient appris pour un marche pied. C’est pourquoi la situation n’a pas été reconnue. 600 650 700 750 800 850 900 950 32 34 36 38 40 42 44 46 48 Y (mm) Temps (s) Walking Walking Sitting (a) Trajectoire du centre de masse pour une personne s’asseyant. 650 700 750 800 850 900 950 36 38 40 42 44 46 48 Y (mm) Walking Walking Sitting Sitting Sitting Walking Bending Temps (s) (b) Trajectoire du centre de masse pour une personne se penchant. 500 550 600 650 700 750 800 850 900 950 1000 30 35 40 45 50 55 60 65 Y (mm) Temps (s) Walking Sitting Walking (c) Trajectoire du centre de masse pour une personne montant sur un marche pied. Figure 9.4 – Représentation du centre de masse, sur l’axe vertical, pour différentes activités réalisées par une personne âgée de 81 ans. 9.3 Conclusion Les différents tests effectués avec des personnes âgées permettent de nous donner des premiers résultats de ce que nous pourrions obtenir si nous réalisions des expérimentations avec elles. Ainsi, nous pouvons constater que les trajectoires du centre de masse, sur l’axe vertical, sont plus irrégulières que ce que nous obtenions avec des personnes plus jeunes. Les courbes suivent, tout de même, une trajectoire sinusoïdale, ce qui nous permet d’extraire les paramètres de la marche. Toutefois, nous ne pouvons pas en conclure que les paramètres extraits sont précis, 1189.3. Conclusion n’ayant pas de système de référence lors des tests. Concernant la détection d’activité, les tests nous montrent que nous devons modifier la base de données sur laquelle les modèles sont appris, avant de nous lancer dans une expérimentation, notamment pour la situation « Monter sur un obstacle ». 119Chapitre 9. Tests en situations réelles 120Conclusion Différentes expérimentations ont été mises en place pour tester les algorithmes d’analyse des paramètres de la marche et de détection des activités. Les expérimentations concernant la détection d’activité nous ont permis d’identifier les modèles, que nous avons construits, les plus proches de la réalité. Nous avons également constaté que certains d’entre eux pouvaient s’adapter à des situations n’appartenant pas à la base d’apprentissage. Notamment, certains modèles se sont adaptés aux situations d’occlusions, qui sont des situations très souvent rencontrées dans une maison. Les expérimentations testant la précision des paramètres de la marche fournis par l’algorithme nous ont révélé que des erreurs subsistent, plus ou moins grandes selon les situations réalisées. La caméra Kinect étant précise à quelques centimètres près, comme nous l’avions précisé à la section 3.3, nous nous approchons de cette erreur. L’expérimentation réalisée avec les personnes âgées nous donne une idée du type de trajectoires que nous pouvons obtenir. Mais les tests effectués sont insuffisants pour pouvoir conclure que le système est adapté aux personnes âgées. De plus, avant de tester sur les personnes âgées, nous devons compléter la base d’apprentissage. Actuellement, les paramètres des modèles sont appris à partir d’une base de données contenant uniquement des images de sujets jeunes. Le système sera, dans les prochains mois, testé dans des conditions réelles et avec des personnes âgées dans le cadre du projet SATELOR. Ce projet, financé par la région Lorraine, regroupe des industriels, des hospitaliers et des chercheurs. L’objectif est d’industrialiser un système permettant de maintenir la personne à son domicile. La prochaine étape de ce projet est d’installer le système, dans un premier temps, dans une chambre de l’OHS (Office Hygiène Sociale) à Nancy et d’enregistrer l’activité d’un patient pour pouvoir, par la suite, traiter les données avec notre système. Nous pourrons ainsi constater les manques et atouts du système en situation réelle. Le but final étant d’installer le système au domicile des personnes âgées pour apprendre leurs habitudes, évaluer l’évolution de leur état au quotidien et détecter les éventuelles chutes. 121Conclusion 122Quatrième partie Système pour le maintien à domicile 123Introduction La reconnaissance d’activité et l’extraction des paramètres de la marche sont les deux axes de recherche que nous avons développés pour traiter le problème de la sécurisation de la personne à son domicile et de l’évaluation de son degré d’autonomie. Dans les parties précédentes, nous avons présenté la méthode et les résultats obtenus pour chacun des deux problèmes de manière séparée, tout en sachant que les deux contributions s’appuient sur une base commune de caractéristiques extraites des images de profondeur. L’objectif final est de développer un système unique pour le maintien à domicile. Nous présentons, dans le premier chapitre de cette partie, notre vision du système final, en intégrant la détection d’activité et l’analyse de la marche dans un seul système. Par exemple, lorsque l’algorithme détecte que la personne est dans l’état « Marche », l’algorithme analysant les paramètres de la marche est activé. Nous proposons également une méthode pour apprendre les habitudes de la personne et ainsi, détecter toutes anomalies suite à un événement inhabituel. La méthode consiste à cartographier l’environnement des habitudes de la personne. Dans un deuxième chapitre, nous indiquons d’autres problématiques pour lesquelles le système pourrait être adapté. Par exemple, ce système peut servir à discriminer plusieurs personnes dans la scène et ainsi, suivre l’évolution de l’état de fragilité de plusieurs personnes en même temps. Chaque personne pourrait être identifiée à travers un certain nombre de caractéristiques, comme sa taille, la forme de sa trajectoire de son centre de masse, etc. Ce système pourrait également prévenir, en plus des chutes et de la perte de fragilité des personnes, les troubles cognitifs. En effet, certaines études ont montré qu’une vitesse lente pouvait être un indicateur de troubles cognitifs et de démences à venir. 125Introduction 126Chapitre 10 Vers une implantation au domicile Sommaire 10.1 Couplage des fonctionnalités actuelles du système . . . . . . . . 127 10.2 Cartographie des habitudes dans l’environnement . . . . . . . . 129 10.2.1 Limitations du système et contraintes de l’environnement . . . . . . 129 10.2.2 Détection des cas d’occlusions partielles de la personne . . . . . . . 130 10.2.3 Cartographie des habitudes . . . . . . . . . . . . . . . . . . . . . . 133 10.2.4 Détection des anomalies . . . . . . . . . . . . . . . . . . . . . . . . 134 10.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 Actuellement, le système développé est conçu pour reconnaître différentes activités et extraire des paramètres de la marche. Dans ce chapitre, nous présentons la manière dont nous avons imaginé intégrer les deux fonctionnalités pour former un système unique, répondant à la problématique du maintien à domicile des personnes âgées. Nous présentons, dans un premier temps, comment coupler les fonctionnalités actuelles du système pour sécuriser et évaluer le degré d’autonomie de la personne. Puis, nous proposons une méthode pour apprendre les habitudes des personnes. 10.1 Couplage des fonctionnalités actuelles du système Nous avons précisé, dans l’introduction de cette thèse, que pour sécuriser la personne, nous avons besoin d’utiliser un algorithme de détection de chutes et d’activités à risque. Concernant l’évaluation du degré d’autonomie de la personne, nous avons précisé que les activités réalisées par la personne et les évolutions dans les paramètres de la marche seraient prises en compte. L’idée est de coupler les algorithmes de détection d’activités et d’extraction des paramètres de la marche pour faire un système unique répondant à la problématique du maintien à domicile des personnes âgées. Nous avons imaginé mettre au domicile une ou plusieurs caméras. L’algorithme détectant l’activité de la personne permettrait, en temps réel, de savoir quelle activité la personne réalise. Selon l’activité qui sera reconnue, l’algorithme effectuera telle ou telle tâche, comme montré à la figure 10.1. Les différentes tâches sont dépendantes de l’activité identifiée : — « Marche » : enregistrement du temps passé dans cette situation, que l’on nommera activité « active », et extraction des paramètres de la marche quand la personne est entièrement visible ; 127Chapitre 10. Vers une implantation au domicile — « Debout » : enregistrement du temps passé dans cette situation nommée activité « active » ; — « Chute » et « Allongé Sol » : envoi d’une alerte à la famille ou aux secours ; — « Monté » et « Accroupi » : envoi d’un signal à la famille ou au médecin pour avertir que la personne adopte des comportements dangereux pouvant la conduire à des situations telles que la chute ; — « Assis » et « Allongé Canapé » : enregistrement du temps passé dans cette situation que l’on nommera activité « passive ». Ainsi à la fin de chaque journée, le système pourra fournir un résumé des informations concernant : — le cumul du temps passé dans une activité « passive » ; — le cumul du temps passé dans une activité « active » ; — le nombre de changements d’activité ; — la moyenne des longueurs de pas, cadence et vitesse de marche de la journée. Il sera alors possible d’observer l’évolution dans le temps (dans la semaine, le mois ou l’année) de ces indicateurs. Cette information, couplée à l’évolution des paramètres de la marche de la personne, est un critère d’évaluation de la perte ou non d’autonomie de la personne. L’alerte automatique aux proches ou aux professionnels de la santé, en cas de chutes et d’activités à risque, permettra de sécuriser la personne au domicile. Les différents algorithmes construits permettent donc d’apporter un ensemble d’informations, qui couplées ensembles, pourront aider à maintenir la personne plus longtemps à son domicile. Marche Temps actif Mesure des paramètres Allongé Sol Alerte Chute Assis Monter Accroupi Signaler Allongé Temps passif Figure 10.1 – Les différentes actions réalisées par l’algorithme selon l’état dans lequel se trouve la personne d’après le MMC. 12810.2. Cartographie des habitudes dans l’environnement 10.2 Cartographie des habitudes dans l’environnement L’objectif dans cette section est de développer une méthode d’apprentissage des habitudes des personnes dans l’environnement. Plus précisément, nous voulons cartographier les activités courantes de la personne selon l’endroit de la pièce dans lequel elle se trouve. Ainsi, l’évolution des habitudes au cours des semaines ou des mois peut constituer un indicateur de modification de l’état de la personne, par exemple si elle reste plus longtemps allongée qu’à son habitude. Pour constituer la carte des habitudes de la personne, nous devons relever ses activités au cours du temps. Lors de l’apprentissage de cette carte, nous devons tenir compte du fait que quand la personne n’est pas entièrement visible, l’activité qu’elle réalise n’est pas certaine. Par exemple, quand la personne se trouve derrière une table à moitié visible nous ne pouvons pas connaitre avec certitude son activité. Nous devons différencier dans la carte les zones où la personne est vue entièrement des zones où elle peut être cachée. 10.2.1 Limitations du système et contraintes de l’environnement Les occlusions peuvent être de différentes natures. Comme nous l’avons étudié à la section 8.2, les occlusions peuvent être dues aux meubles de la pièce. En effet, les tables ou les chaises peuvent, par exemple, bloquer la visibilité de la personne. De la même façon, en bordure du champ de vision de la caméra, la personne n’est que partiellement visible. Donc, les problèmes d’occlusions, dues aux meubles et aux limites du champ de vision de la caméra, sont à prendre en compte lorsque l’on suit la trajectoire d’une personne. En effet, si l’analyse des activités est effectuée lorsque la personne est à moitié cachée l’activité ne sera peut être pas reconnue, comme nous l’avons vu à la section 8.2. La figure 10.2 illustre le cas d’une personne marchant à la limite du champ de vision de la caméra. L’image couleur nous montre que la personne est à moitié détectée. Son côté gauche se trouve en dehors du champ de vision de la caméra. Figure 10.2 – Personne sortant du champ de vision et étant à moitié détectée. La section 8.2 permet de constater que certains de nos modèles de Markov cachés sont robustes aux occlusions, en classifiant correctement les activités, dans des conditions non rencontrées lors de l’apprentissage. La plupart des modèles ont le même problème qui est de confondre les trois activités « Penché », « Accroupi » et « Chute ». Ainsi, même s’il est possible de reconnaitre certaines activités dans les zones d’occlusion il est important d’identifier ces zones dans lesquelles les performances du système sont différentes. Les zones de sortie du champ de 129Chapitre 10. Vers une implantation au domicile vision sont également à prendre en compte dans l’interprétation des résultats produits par le système. Ces zones de sorties se situent en bord d’image mais également dans les franchissements de portes si celles-ci se trouvent dans le champ de vision. Nous devons donc différencier les moments où la personne est cachée, des situations où elle est entièrement visible pour intégrer cette information dans la carte des habitudes. 10.2.2 Détection des cas d’occlusions partielles de la personne La méthode proposée pour détecter les cas d’occlusions est fondée sur le calcul de la vraisemblance permettant de savoir si le modèle correspond aux observations. La vraisemblance est une mesure de la probabilité des observations O sachant le modèle λ, soit P(O|λ). Elle est calculée à partir des probabilités obtenues dans la phase Forward de l’algorithme Forward-Backward. Pour rappel, la phase Forward permet de calculer le α pour chaque état, à chaque instant. La vraisemblance correspond au calcul suivant : V raisemblance(t) = logΣ N i=1αt(i). La vraisemblance à l’instant t est égale à la somme des probabilités α à t pour tous les états. Le logarithme de la vraisemblance est préféré pour représenter les résultats. L’idée ici est de comparer les valeurs prises par la vraisemblance lorsque la personne est entièrement visible, avec les valeurs prises lorsque la personne n’est pas entièrement visible. Nous avons alors demandé à une personne d’effectuer les huit activités (les mêmes qui étaient utilisées pour construire les MMC) pour obtenir l’échantillon des valeurs prises par la vraisemblance lorsque la personne effectue les différentes activités en étant entièrement visible. Ensuite nous avons demandé à la personne de réaliser les séquences derrière des obstacles pour obtenir un échantillon de valeurs prises par la vraisemblance lorsque la personne est cachée. Chaque sé- quence a été analysée avec le MMC à 8 états et 3 observations. Ces situations correspondent aux situations décrites au chapitre 8. Les valeurs de la vraisemblance pour chaque activité, réalisée en condition « Caché » et entièrement « Visible », sont représentées à la figure 10.3. Chaque courbe correspond aux valeurs de la vraisemblance à chaque pas de temps. Nous avons inscrit sur chaque graphe les situations réalisées par le sujet. Par exemple, pour le graphe correspondant à la situation « Marcher - Caché », la personne marche en étant visible jusqu’à 44,1 s, puis continue de marcher derrière des chaises en étant à moitié visible. En comparant les situations réalisées lorsque la personne est visible et cachée, nous pouvons voir que les valeurs prises par la vraisemblance sont plus petites quand la personne est cachée. En d’autres termes, le modèle correspond mieux aux observations quand la personne est entièrement visible. Ce constat est logique puisque le modèle a appris sur une base de données ne contenant que des situations où la personne est entièrement visible. Nous pouvons également constater que les valeurs de la vraisemblance effectuent un pic vers le bas lorsque la personne passe d’une activité où elle est entièrement visible à une activité où elle est en partie cachée. Par exemple, pour la situation « Marcher - Caché », le passage de l’état visible à caché est très net par rapport aux valeurs de la vraisemblance. Dans le cas des situations réalisées en étant visibles, nous pouvons également constater une descente des valeurs de la vraisemblance, mais moins prononcée, lorsque la personne change d’activité. Par exemple, les situations « S’accroupir - Visible » ou « S’asseoir - Visible » ont une légère descente des valeurs de la vraisemblance lorsque la personne passe de l’activité « Marche » à « Accroupi » ou « Assis ». Pour la situation « S’accroupir - Caché » et « Chuter+Allongé au sol - Caché », nous voyons que la courbe de la vraisemblance ne cesse de diminuer à un moment. Ce passage correspond au moment où la personne est entièrement cachée et où le modèle ne reçoit plus aucune information. 13010.2. Cartographie des habitudes dans l’environnement Se pencher - Visible Se pencher - Caché -80 -70 -60 -50 -40 -30 -20 28.5 29 29.5 30 30.5 31 31.5 32 32.5 Log Vraisemblance Temps (s) Marche Visible Marche Visible Penché Visible -90 -80 -70 -60 -50 -40 -30 -20 42 43 44 45 46 47 48 49 50 Log Vraisemblance Temps (s) Marche Visible Penché Caché Marche Visible S’accroupir - Visible S’accroupir - Caché -90 -80 -70 -60 -50 -40 -30 -20 27 27.5 28 28.5 29 29.5 30 30.5 31 31.5 Log Vraisemblange Temps (s) Accroupi Visible -90 -80 -70 -60 -50 -40 -30 -20 35 40 45 50 55 60 65 Log V raisem blance Tem p s (s) Accroupi Visible Accroupi Caché Accroupi Visible S’asseoir - Visible S’asseoir - Caché -90 -80 -70 -60 -50 -40 -30 -20 27 28 29 30 31 32 33 34 Log Vraisemblance Temps (s) Marche Visible Assis Visible Marche Visible -100 -90 -80 -70 -60 -50 -40 -30 -20 34 36 38 40 42 44 46 48 Log Vraisemblance Temps (s) Assis Caché Marche Visible Marche Visible S’allonger - Visible S’allonger - Caché -90 -80 -70 -60 -50 -40 -30 -20 30 32 34 36 38 40 42 Log Vraisemblance Temps (s) Marche Visible Allongé Visible Marche Visible -100 -90 -80 -70 -60 -50 -40 -30 -20 30 35 40 45 50 55 60 65 Log Vraisemblance Temps (s) Marche Visible Allongé Caché Marche Visible 131Chapitre 10. Vers une implantation au domicile Marcher - Visible Marcher - Caché -75 -70 -65 -60 -55 -50 -45 -40 -35 -30 -25 28 28.5 29 29.5 30 30.5 31 Log Vraisemblance Temps (s) Marche Visible -70 -65 -60 -55 -50 -45 -40 -35 -30 -25 38 39 40 41 42 43 44 45 46 47 48 Log Vraisemblance Temps (s) Marche Visible Marche Visible Marche Caché Chuter+Allongé au sol - Visible Chuter+Allongé au sol - Caché -80 -70 -60 -50 -40 -30 -20 28 30 32 34 36 38 40 42 44 46 Log Vraisemblance Temps (s) Chute Visible Marche Visible Marche Allongé Visible Visible -90 -80 -70 -60 -50 -40 -30 -20 32 34 36 38 40 42 44 46 48 50 52 54 Log Vraisemblance Temps (s) Marche Visible Chute Caché Marche Visible Allongé Caché Monter - Visible Monter - Caché -90 -80 -70 -60 -50 -40 -30 -20 28 29 30 31 32 33 34 35 Log Vraisemblance Temps (s) Marche Visible Monté Visible Marche Visible -80 -75 -70 -65 -60 -55 -50 -45 -40 -35 -30 -25 32 34 36 38 40 42 44 46 Log Vraisemblance Temps (s) Monté Visible Monté Caché Marche Visible Monté Caché Marche Visible Figure 10.3 – Courbes des vraisemblances pour différentes activités réalisées par un sujet entièrement et partiellement visible. 13210.2. Cartographie des habitudes dans l’environnement 1 2 3 4 5 6 7 8 Figure 10.4 – Séquence dans laquelle le sujet réalise plusieurs activités. Donc, à partir des valeurs de vraisemblance, il est possible de reconnaître une situation où la personne est cachée en utilisant un seuil en dessous duquel la personne sera considérée cachée par un obstacle. Ainsi, nous pouvons discriminer les situations où la personne est entièrement visible et celles où elle ne l’est pas. 10.2.3 Cartographie des habitudes Pour apprendre l’environnement, nous découpons la scène en zones de 50 cm de côté. Nous demandons à une personne d’effectuer plusieurs activités dans l’appartement expérimental. Nous y avons placé deux fauteuils mis côte à côte. Ainsi, la personne a pu s’asseoir, s’allonger, marcher derrière les fauteuils en étant cachée et marcher devant les fauteuils en étant visible. Cette séquence est montrée à la figure 10.4. Les images représentent les différentes activités réalisées par la personne. Le corps de la personne est toujours en partie visible durant toutes ces activités. L’algorithme apprend, pour chaque zone de l’environnement, la fréquence des activités réalisées par la personne, la visibilité ou non du corps de la personne et les bords du champ de vision de la caméra. Plus précisément, l’algorithme observe si la personne est cachée ou entièrement visible, par rapport à la valeur prise par la vraisemblance. Si la personne est visible, le modèle apprend pour la zone de l’environnement où elle se trouve qu’il est possible, à cet endroit, d’effectuer l’activité détectée. Si la personne est cachée par un meuble, le modèle apprend que la case, où elle se trouve, est localisée derrière un obstacle. Pour finir, nous considérons un bord comme étant l’endroit où la personne sort entièrement du champ de vision de la caméra. La figure 10.5 représente l’apprentissage de l’environnement qui a été construit lorsque la personne a effectué les différentes activités dans l’appartement expérimental. Les cases blanches correspondent aux zones non explorées. La personne n’a jamais été détectée à ces endroits. La couleur bleue représente les zones où la personne a été détectée comme réalisant une activité dite « passive ». Nous avons représenté une chaise dans cette case, pour montrer que dans cette zone se trouve une chaise, car le MMC a détecté que la personne était soit dans l’état « Allongé Canapé », soit dans l’état « Assis ». La couleur rouge représente les zones où la personne a été détectée comme étant cachée par un obstacle. La couleur verte représente les zones où la personne a été détectée réalisant une activité dite « active ». Le MMC a détecté que la personne était soit dans l’état « Marche », soit dans l’état « Debout ». Les proportions des couleurs dans chaque 133Chapitre 10. Vers une implantation au domicile case représentent les proportions des situations détectées. Nous pouvons voir que les zones rouges se situent correctement derrière les deux fauteuils. Les zones bleues, représentant les activités « passives », sont situées à l’endroit où se trouvent les deux fauteuils. Cela nous montre que les activités « Allongé Canapé » et « Assis » ont été correctement identifiées au niveau des deux fauteuils. Les zones vertes, représentant les activités « actives », sont situées à l’endroit où la personne a marché en étant entièrement visible. Sur la carte, nous pouvons également voir l’inscription « bord », placée là où la personne est sortie entièrement du champ de vision de la caméra. Figure 10.5 – Carte de l’environnement représentant les habitudes apprises d’une personne (en blanc : zones non explorées, en bleu : zones passives, en vert : zones actives et en rouge : zones se trouvant derrière un meuble). Dans la réalité, au domicile des personnes âgées, nous imaginons apprendre au fur et à mesure les activités réalisées par la personne pour construire la carte de leur environnement et de leurs habitudes. 10.2.4 Détection des anomalies La carte peut être utilisée comme une méthode de détection d’anomalies. La cartographie des habitudes de la personne permet d’identifier, à différents intervalles de temps par exemple, l’évolution des activités de la personne. L’évolution des habitudes peut être un indicateur d’une éventuelle anomalie dans l’état général de la personne. D’autres anomalies peuvent être détectées, en utilisant la carte, pouvant faire l’objet d’une alerte envoyée aux personnes extérieures. Notamment, lorsque la personne disparait du champ de vision, la carte peut renseigner sur sa proximité avec une zone d’occlusion et nous indiquer un risque de chute non visible. Nous détectons les moments où la personne est entièrement cachée après avoir visité une case rouge. L’algorithme calcule le temps passé dans cette situation. Si le temps est supérieur à un certain seuil (de quelques secondes), nous en déduisons une possibilité de chute. La figure 10.6 correspond à une situation où une personne se trouve cachée derrière un fauteuil. Sur l’image de l’apprentissage de l’environnement en haut à gauche, le cercle représente 13410.3. Conclusion la dernière position du centre de masse qui a été détectée lorsque la personne était encore visible. Nous pouvons voir que la position du cercle se trouve au dessus d’une case rouge, signifiant que cette zone a été apprise comme étant une case où la personne peut potentiellement être cachée. Un compteur est lancé à partir du moment où la personne n’a plus été visible, pour déterminer s’il y a chute ou non. A l’inverse, la carte peut nous aider à prendre en compte les zones de sorties habituelles du champ de vision. La personne peut sortir du champ de vision en bord d’image mais aussi suite au franchissement d’une porte qui serait visible dans la scène. Si la personne disparait du champ de vision à proximité d’une zone de sortie habituelle, l’alerte ne sera pas déclenchée. bord Figure 10.6 – Carte de l’environnement sur laquelle est représentée la dernière position du centre de masse perçue par le système. 10.3 Conclusion Le couplage entre la fonctionnalité de détection des activités et la fonctionnalité permettant d’extraire les indicateurs de marche permet d’obtenir de nombreuses données qui peuvent servir à sécuriser la personne à son domicile et évaluer son degré de fragilité. En mettant des outils en place, tels que la détection des occlusions et l’apprentissage de l’environnement, nous renforçons la robustesse du système pour permettre son fonctionnement au domicile, dans un environnement où les occlusions de la personne sont très courantes. 135Chapitre 10. Vers une implantation au domicile La carte de l’environnement permet de connaître les zones d’occlusions habituelles en cumulant au cours du temps l’analyse de la vraisemblance. La détection d’une occlusion peut ensuite se faire en regardant la position de la personne sur la carte, en étant robuste aux éventuelles variations ponctuelles de vraisemblance. Elle peut être utilisée pour éviter d’éventuelles fausses détections, en prenant en compte les zones d’occlusions et les activités habituelles dans la zone où l’alerte a été détectée. Enfin, la carte de l’environnement donne une représentation spatiale des habitudes qui peut être utilisée pour analyser plus finement les évolutions des habitudes de la personne. 136Chapitre 11 Autres perspectives d’utilisation du système Sommaire 11.1 Différenciation des personnes . . . . . . . . . . . . . . . . . . . . . 137 11.2 Couplage de plusieurs capteurs . . . . . . . . . . . . . . . . . . . . 138 11.3 Observance des patients . . . . . . . . . . . . . . . . . . . . . . . . 139 11.4 Prévention de certains troubles . . . . . . . . . . . . . . . . . . . 139 11.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Le système est actuellement conçu pour apporter une solution à la problématique du maintien à domicile des personnes âgées. Nous pensons que ce système pourrait avoir d’autres applications. Nous proposons ici quelques perspectives d’évolution et exemples d’utilisation du système. 11.1 Différenciation des personnes Le système actuel est prévu pour qu’il n’y ait qu’une seule personne dans le champ de vision de la caméra. Lorsque plusieurs personnes entrent dans le champ de vision de la caméra, le système analyse la marche et l’activité de l’une des personnes, qui n’est pas nécessairement la personne que l’on souhaite suivre. Ces erreurs d’attributions provoqueront des données aberrantes, pouvant gêner l’analyse de l’évolution des paramètres de la marche de la personne à suivre. Nous aimerions donc pouvoir distinguer les personnes entre elles pour analyser l’activité et la marche de la ou les personnes à suivre. Nous nous basons sur l’idée que chaque personne a une façon de marcher différente. Nous pourrions alors identifier chaque personne en prenant en compte un certain nombre de caracté- ristiques telles que sa taille, sa longueur de pas moyenne, sa cadence, sa vitesse de marche, la symétrie de sa marche, etc. La taille de la personne est une information que nous connaissons, car nous avons une méthode d’extraction du sol, comme présenté à la section 4.1, et une méthode de détection du point maximum du corps. Les longueurs, cadences et vitesses de marche sont également connues avec l’algorithme d’analyse de la marche. Et la symétrie des pas peut être obtenue en analysant la régularité des trajectoires du centre de masse. Nous pensons qu’il serait alors possible, à l’installation du système, d’apprendre les caractéristiques de la personne et de les mettre à jour au cours des évolutions. Ainsi, l’algorithme pourrait suivre plusieurs personnes en leurs attribuant les paramètres observés. 137Chapitre 11. Autres perspectives d’utilisation du système 11.2 Couplage de plusieurs capteurs Nous imaginons poser plusieurs caméras aux domiciles des personnes. Le positionnement des caméras serait effectué pour qu’il n’y ait pas de zone de recouvrement, car nous avons montré, au chapitre 7, que l’interférence entre caméras dégrade la précision des résultats. Par exemple, dans l’appartement expérimental, nous pensons installer les caméras comme montré à la figure 11.1. Une caméra serait installée pour couvrir le salon ayant une profondeur d’environ 7 m, une autre pour la cuisine et une dernière pour la chambre. Les caméras n’ayant pas de zone de recouvrement, certains endroits ne seront pas couverts. Les zones importantes où sont situés la table, les chaises, les fauteuils, le canapé et le lit doivent être vues. Une solution pour pallier au problème des zones non vues est d’effectuer les traitements concernant l’analyse de l’activité et l’apprentissage de l’environnement pour chaque caméra. Ainsi, lorsqu’une personne ne sera visible d’aucune caméra, sa dernière position visible sera recherchée. La carte de l’environnement de la caméra, où la personne est apparue visible, nous permettra de connaître la distance entre la personne et une zone d’occlusion ou une zone de bord du champ de vision. Si la personne était proche d’un bord, nous pourrons en conclure qu’elle se trouve, sûrement, entre deux champs de vision de caméra. Comme précédemment, nous pourrons ajouter la notion de temps et apprendre les habitudes de la personne. C’est-à-dire que nous pourrions apprendre combien de temps, la personne passe, généralement, entre chaque zone non visible par la caméra, pour savoir si la situation est normale. Figure 11.1 – Proposition d’emplacement de plusieurs caméras permettant de couvrir tout un appartement. Nous n’avons pas mis de caméra dans la salle de bains et les toilettes, à la figure 11.1, pour préserver l’intimité de la personne. L’idée serait de mettre d’autres capteurs, tels que des détecteurs d’ouvertures sur les robinets pour savoir si la personne est active. Ainsi, si aucune activité n’est détectée dans la pièce, nous pourrons en déduire un risque d’activité anormale. 13811.3. Observance des patients 11.3 Observance des patients Nous pensons que ce système pourrait servir au médecin, pour vérifier que le patient respecte, par exemple, les indications qui lui ont été données sur sa façon de marcher. En d’autres termes, le médecin pourrait évaluer l’observance du patient. Nous avons testé le système avec une personne âgée de 90 ans, ayant des problèmes d’équilibre. Nous lui avons demandé de marcher sans sa canne et avec sa canne. Quand la personne marche sans sa canne, la trajectoire du centre de masse n’est pas régulière comme illustré à la figure 11.2(a). A l’inverse, quand elle marche avec sa canne, la courbe du centre de masse suit une trajectoire sinusoïdale plus régulière, comme le montre la figure 11.2(b). Le médecin de cette personne lui a conseillé de marcher uniquement avec sa canne au domicile pour lui éviter de chuter et pour ne pas empirer ses problèmes d’équilibre. Ce système lui permettrait donc de pouvoir observer, à travers la régularité, ou non, de la trajectoire du centre de masse, si la personne respecte ses conseils. Ainsi, il pourrait prévenir les futures évolutions de l’état de la personne liées à la non utilisation de la canne, alors qu’actuellement le médecin constate les dégradations lorsque la personne chute. 550 600 650 700 750 800 850 900 47 48 49 50 51 52 53 54 Y (mm) Temps (s) (a) Marche sans la canne. 550 600 650 700 750 800 850 900 46 46.5 47 47.5 48 48.5 49 49.5 50 50.5 Y (mm) Temps (s) (b) Marche avec canne. Figure 11.2 – Représentation du centre de masse, sur l’axe vertical, d’une personne de 90 ans ayant des problèmes d’équilibre . En restant dans le même contexte, cet outil pourrait également être utile pour que le mé- decin évalue l’observance dans le cas des patients en rééducation, suite à un accident ou une amputation par exemple. Un des problèmes en rééducation est le retour des patients au domicile. Les personnes à l’hôpital suivent les exercices qui leur sont indiqués par le personnel soignant. Mais, une fois de retour chez eux, ils ne continuent pas l’entrainement instauré par le médecin. L’installation d’un tel système au domicile permettrait au médecin de revoir avec le patient chaque semaine, chaque mois, les trajectoires de son centre de masse. Il pourrait alors savoir si son patient continue la rééducation en marchant correctement chez elle et continue de progresser. 11.4 Prévention de certains troubles L’analyse de la marche est utilisée, dans le système actuel, comme indicateur de fragilité et de chute à venir. A la section 5.3, nous avons présenté certaines études montrant que l’analyse des troubles de la marche peut aider à détecter les risques d’hospitalisations, les troubles cognitifs et les démences. Nous pouvons imaginer, tout comme pour la prévention de la fragilité, d’évaluer au quotidien les paramètres de la marche et d’observer leur évolution dans le temps. Les personnes seraient alors orientées, assez rapidement, vers les spécialistes adéquates. Comme il a été dit à 139Chapitre 11. Autres perspectives d’utilisation du système la section 5.3.3, dans le cas des démences, l’un des problèmes majeurs est que bien souvent les personnes sont prises en charge trop tard. Avec un système analysant la marche au quotidien, nous pouvons alerter dès les premiers signes de troubles et les orienter vers des neuropsychologues par exemple, pour leur faire passer des tests cognitifs. Pour rendre le système capable de prévenir ces différents troubles, nous devons mettre en place des expérimentations pour connaître les seuils à partir desquelles nous alerterons les médecins. Aujourd’hui, il y a peu d’information à ce sujet, car l’évaluation de la marche n’est pas une pratique courante pour déceler un problème cognitif ou un risque d’hospitalisation. 11.5 Conclusion Ce système a été pensé pour répondre au besoin du maintien à domicile des personnes âgées. La détection de chutes des personnes âgées au domicile est une thématique pouvant concerner d’autres populations comme les personnes handicapées ou même les personnes épileptiques, dont un des symptômes possibles est la perte de connaissance entrainant des chutes. La chute est souvent brutale et peut entraîner des conséquences physiques empêchant la personne de se relever. Nous pouvons également imaginer que l’analyse de la marche puisse être détournée de sa fonction première qui était de prévenir les chutes et la fragilité des personnes âgées. L’analyse de la marche, au quotidien au domicile, peut être un outil supplémentaire pour le médecin pour prévenir les risques d’hospitalisations et de démences. Cet outil peut également permettre d’analyser les anomalies de symétrie de la marche et ainsi fournir une indication concernant l’évolution des progrès d’une personne suite à un accident par exemple. Sur le plan technique, nous avons identifié la possibilité d’utiliser les mêmes algorithmes pour distinguer et suivre plusieurs personnes en constatant que les caractéristiques extraites sont spécifiques à chacun. Une autre perspective d’évolution est le couplage de plusieurs caméras pour permettre une meilleure couverture du domicile. Ce couplage pose la question du non recouvrement des champs de vision et de la gestion des zones aveugles entre les caméras. Enfin, la fusion de l’information provenant de capteurs complémentaires installés dans des pièces telles que la salle de bains ou les toilettes permettrait de compléter la zone de surveillance tout en conservant l’acceptabilité du système. 140Conclusion Cette partie permet de montrer le couplage des deux contributions de la thèse, la détection d’activités et l’analyse de la marche, pour former un système permettant le maintien à domicile des personnes âgées. Le système pourrait envoyer une alerte aux personnes extérieures en cas de détection de l’activité « Chute » et des activités à risque, « Accroupi » et « Monté ». Il pourrait, également, évaluer au quotidien les paramètres de la marche de la personne et comparer ses activités à celles réalisées habituellement, dans le but d’évaluer l’état de fragilité de la personne. Ce système peut fonctionner pour une personne entièrement visible et cachée par des meubles. Une carte de l’environnement, représentant les habitudes des personnes et découpant la scène en zones d’activités possibles à cet endroit, est ajoutée au système pour le rendre plus robuste dans les cas des zones partiellement occultées par des meubles. Ce système peut également avoir d’autres applications. Il pourrait nous servir à distinguer les personnes. Actuellement, une seule personne est détectée dans la scène. Dans le cas où plusieurs personnes sont dans la scène, le système pourrait suivre la personne qui nous intéresse parmi d’autres, ou en suivre plusieurs et distinguer les informations appartenant à chacune d’entre elles. Cette distinction se ferait par l’apprentissage de caractéristiques discriminant chaque personne. Une autre utilité, que nous avons évoquée dans ce chapitre, est la possibilité de coupler les caméras entre elles et avec d’autres capteurs pour ainsi avoir des informations dans toutes les pièces de la maison. Nous avons, également, évoqué dans cette partie la possibilité d’utiliser ce système comme outil de suivi de l’observance pour les médecins. Ce système pourrait, aussi, prévenir d’autres risques comme les troubles cognitifs ou les risques d’hospitalisation. 141Conclusion 142Conclusion générale et perspectives 143L’augmentation du nombre de personnes âgées est un enjeu majeur de santé publique des prochaines années. Le maintien à domicile s’avère être une préoccupation importante pour les personnes âgées et leur famille. Mais le domicile n’est pas un endroit sans risque pour les personnes, il peut même être responsable de leur perte d’autonomie. Une des causes fréquentes de perte d’autonomie au domicile est la chute. Les séquelles physiques peuvent conduire la personne au handicap ou à des incapacités locomotrices, entrainant une perte d’autonomie pouvant mener au placement en institution. Les séquelles psychologiques sont aussi très fréquentes après une chute. Le risque de séquelles psychologiques augmente avec le temps passé au sol. Elles provoquent la diminution des activités et des sorties par peur de rechuter. Ces séquelles ont pour effet d’entraîner les personnes vers une perte d’autonomie et de compromettre leur maintien à domicile. Pour que les personnes âgées puissent rester le plus longtemps possible autonomes à leur domicile, il est nécessaire de les sécuriser chez elles en détectant les chutes pour intervenir le plus rapidement possible et diminuer les risques de séquelles physiques et psychologiques. En plus de détecter les chutes, nous pensons qu’il est également nécessaire de prévenir les chutes et plus généralement de prévenir les risques de fragilité de la personne. Actuellement, à l’hôpital, il est possible de mesurer, lors des consultations, le niveau de dépendance des personnes à l’aide de tests cliniques, analysant la marche de la personne. Ces mesures sont alors faites dans des conditions modifiées comparées aux mesures qui pourraient être faites au domicile. Notre objectif est donc de proposer un système permettant de détecter les chutes pour éviter l’aggravation des séquelles physiques et psychologiques et détecter, dans le milieu écologique, une détérioration du comportement locomoteur pour ainsi prévenir la fragilité des personnes. Ainsi, nous aurons une mesure quotidienne pour évaluer l’évolution de la personne. Dans cette thèse, nous proposons un système, pour détecter les chutes et prévenir la fragilité des personnes âgées. Pour détecter les chutes, nous avons développé un algorithme de reconnaissance des chutes et des comportements à risque pouvant entraîner une chute, comme monter sur une chaise ou s’accroupir. Pour prévenir la fragilité, nous avons développé un algorithme de détection d’activité, pour savoir si la personne continue de réaliser autant d’activité qu’à son habitude, et un algorithme d’analyse de la marche, pour évaluer l’évolution de ses comportements locomoteurs. Ces deux algorithmes permettent d’établir un degré de fragilité des personnes, comme les médecins le font en consultation avec leurs tests cliniques. En résumé, nous avons contribué à la conception d’un système d’aide au maintien à domicile des personnes âgées, par le développement d’un algorithme de détection d’activité (capable, entre autres, de nous détecter les chutes et les situations à risque) et le développement d’un algorithme d’analyse de la marche. Le système que nous avons imaginé doit, pour pouvoir être installé au domicile, être peu coûteux et ne pas perturber la vie quotidienne des personnes. Nous avons donc développé des algorithmes possibles à implémenter dans n’importe quelle machine bas coût et fonctionnant en temps réel pour pouvoir détecter les chutes le plus rapidement possible. Le système repose sur un capteur bas coût, non embarqué sur la personne. Nous avons choisi d’utiliser la caméra de profondeur de Microsoft. A partir de cette caméra, nous pouvons détecter la personne à son domicile avec un algorithme de soustraction du fond très simple et peu coûteux en temps de calcul. Le fond est appris à partir de l’image de profondeur et la personne est extraite de la scène par soustraction. Suivre la personne dans le temps peut requérir beaucoup de ressource, car chaque partie du corps a des mouvements indépendants qu’il est possible de suivre séparément. Par souci d’économie, nous extrayons quelques paramètres de l’image nous permettant de représenter la personne au cours du temps. Tout d’abord, nous nous intéressons au centre de masse, car certains auteurs ont mis en évidence que pour suivre le déplacement du corps en mouvement, la trajectoire du centre de masse est une information riche. A partir du centre de masse, nous pouvons obtenir des informations comme la position, la vitesse verticale et horizontale. Nous avons également 145extrait deux autres paramètres qui ont une importance pour détecter l’activité, il s’agit de la dispersion verticale de la silhouette et du point maximum du corps. Ces 5 paramètres, simples à extraire, sont les caractéristiques représentant la personne au cours du temps et sur lesquels nos algorithmes de détection d’activité et d’analyse de la marche sont fondés. Selon la littérature, l’analyse des paramètres de la marche, tels que les longueurs de pas, la cadence et la vitesse de marche sont de bons indicateurs de l’évolution de la fragilité des personnes âgées. L’algorithme d’extraction des paramètres de la marche d’une personne est fondé sur une seule caractéristique représentant la personne, à savoir le centre de masse. A partir du centre de masse et de la détection des maxima locaux sur l’axe vertical, nous obtenons les paramètres de la marche. En comparant les paramètres de la marche fournis par notre algorithme et ceux obtenus avec une méthode de référence, pour 10 sujets participant à l’expérience, nous obtenons des résultats assez précis puisque l’erreur obtenue est comparable à l’erreur due à la précision de la caméra. L’algorithme de détection d’activité, fondé sur des modèles de Markov cachés, permet de discriminer entre 8 et 9 activités selon le modèle construit. Il permet de reconnaître les activités s’asseoir, marcher, s’accroupir, se pencher, monter sur un obstacle, s’allonger sur un lit ou un canapé, chuter, être allongé au sol et certains modèles identifient aussi l’activité être debout. Les modèles construits distinguent les activités à partir de 3 ou 5 observations représentant les personnes. Les modèles reconnaissant 8 activités se basent sur la position et vitesse du centre de masse et la distribution verticale de la silhouette. Les modèles reconnaissant 9 états se basent sur 5 paramètres en ajoutant la vitesse horizontale et le point maximum du corps. Une base de données a été construite en demandant à 28 sujets de réaliser des situations correspondantes aux activités devant être reconnues. Les paramètres des différents modèles construits, comme les probabilités de transition, les probabilités initiales, les fonctions d’observations sont apprises à partir de quelques séquences de la base de données. Les séquences restantes de la base servent à vérifier la validité des modèles pour classifier correctement les activités. Ainsi, nous avons pu constater que les modèles discriminants 8 activités classifient correctement toutes les situations sans faire de fausses détections, notamment sans déclarer une chute alors qu’il n’y en a pas. Les modèles détectant 9 activités ont des bons taux de classifications également mais indiquent trop souvent l’activité chute alors qu’elle n’est pas réalisée. Malgré l’augmentation du nombre d’observations pour discriminer les activités (5 pour les modèles discriminant 9 états, et 3 pour ceux discriminant 8 activités), l’augmentation de la complexité du modèle ne permet pas d’être plus performant pour reconnaître les activités, au contraire cela ajoute du bruit. En revanche, les modèles discriminant les activités à partir de 5 observations ont l’avantage d’être plus robustes aux situations où la personne n’est pas entièrement visible. Ces situations sont considérées comme nouvelles, car la base de données ne contenait que des situations où la personne était entièrement visible. Les algorithmes de détection d’activité et d’analyse de la marche ont été testés sur quelques personnes âgées. Les tests montrent que certaines situations sont reconnues. Pour la suite, il est toutefois nécessaire de refaire des expérimentations avec des personnes âgées pour créer une nouvelle base de données adaptée à la bonne catégorie de personnes. De plus, même si les personnes âgées ont une façon de marcher différente des personnes jeunes, l’algorithme est toujours capable d’extraire les paramètres de la marche. Une étude plus approfondie permettra de déterminer si la précision des paramètres de la marche, extrait avec notre système, est similaire à la précision obtenue dans l’expérimentation avec les sujets jeunes. Ces premiers tests nous ont également permis de constater d’autres applications possibles du système. Notamment, l’observation de la trajectoire générale du centre de masse pourrait être un indicateur d’observance pour le médecin. La trajectoire pourrait également servir comme indicateur pour discriminer plusieurs 146personnes dans une scène, car chaque trajectoire présente des irrégularités qui sont propres à chaque personne. L’une des difficultés est de concevoir un système assez générique pour pouvoir être utilisé pour une population de personnes très disparate. Nous ne pouvons pas insérer manuellement des seuils à partir desquelles alerter les personnes d’une perte d’autonomie. Le système doit être capable de s’adapter à chaque personne, à partir d’une quantité suffisante de données, pour qu’il puisse apprendre ses habitudes au fur et à mesure. Il doit également apprendre les paramètres de la marche habituels et pouvoir ainsi détecter les seuils au-delà desquels l’évolution doit être considérée comme anormale. Ces seuils doivent être appris automatiquement par l’algorithme. L’algorithme d’analyse de la marche et celui de détection d’activité peuvent être regroupés dans un système unique. Chaque caméra placée dans une pièce de la maison analyserait l’activité de la personne. Chaque détection des activités « Chute », « Accroupi » ou « Monté Obstacle » serait signalée aux personnes extérieures pour intervenir le plus rapidement possible en cas de chute. Les détections de l’activité « Marche » permettraient de lancer l’algorithme d’extraction des paramètres et de calculer le temps passé dans cette activité. Ce temps serait alors comparé au temps passé dans les situations « Assis » et « Allongé ». L’analyse de l’évolution des paramètres de la marche et l’évolution des activités constituerait des informations dans le cadre de la prévention de la fragilité. Ce système a été pensé en vue d’être expérimenté au domicile des personnes âgées. Dans les objectifs, nous avions mentionné que nous voulions construire un système réaliste, utilisable. Se pose également la question de l’acceptation du système par les personnes. Peu d’études évaluent la perception qu’ont les personnes âgées face aux nouvelles technologies pouvant être installées à leur domicile. La question de l’acceptabilité est davantage nécessaire pour l’installation de caméras qui pose le problème du respect de la vie privée de la personne. Bellotti et Sellen [Bellotti and Sellen, 1993] précise qu’il est nécessaire de répondre à quatre catégories de questions lorsque l’on crée un système ayant pour objectif d’être installé au domicile. La réponse à ces problématiques peuvent influencer la façon dont la personne perçoit l’intrusion dans sa vie privée de la technologie, à savoir : quand et quelle information est enregistrée, comment l’information est enregistrée et une fois enregistrée ce qui lui arrive, qui a accès à l’information et comment l’information est utilisée. Les systèmes doivent être techniquement fiables et inspirer la confiance chez les utilisateurs. Malgré le peu d’articles existants sur l’acceptation des caméras à domicile, nous pouvons citer quelques auteurs proposant des débuts de réponse et des pistes à prendre en compte pour développer un système qui sera mieux accepté. Selon Caine et al. [Caine et al., 2005], les personnes seraient prêtes à faire des compromis par rapport à leur vie privée si cela leur permet de rester indépendantes. Melenhorst et al. [Melenhorst et al., 2004] ont également montré que les technologies perçues comme envahissantes pour l’intimité sont susceptibles d’être acceptées si elles sont considérées comme nécessaires pour répondre à un besoin. D’autres articles montrent que l’anonymat des images pourrait être une solution pour rendre les systèmes à base de caméra moins intrusifs dans l’intimité des personnes. Notamment l’étude de Demiris et al. [Demiris et al., 2009] consistait à demander à 10 personnes d’effectuer plusieurs scénarios représentants des activités de la vie quotidienne comme s’asseoir dans le salon, accueillir un visiteur, préparer un repas, etc. Ces séquences étaient enregistrées par deux webcams et analysées de façon à rendre les images anonymes. Pour cela, ils ont utilisé une méthode de soustraction du fond pour obtenir uniquement la silhouette. Puis ils ont créé une deuxième représentation en modifiant la silhouette pour la transformer en 3 dimensions. Les deux représentations étaient alors montrées aux personnes lors d’interviews. Les interviews ont été menées autour des quatre problématiques qui ont été décrites par Bellotti et Sellen. Les réponses aux interviews ont montré que les personnes s’intéressaient à comprendre comment le système fonctionne, comment est 147extraite la silhouette. Les interviews ont également indiqué que l’utilisation des vidéos réduite au simple suivi de la silhouette atténuait les préoccupations concernant le respect de la vie privée, car pour les personnes la vidéo restait anonyme. Par contre la représentation 3D n’a pas été appréciée. Selon les commentaires des personnes, cette représentation enlevait ce qui caractérise la personne, ils ne se reconnaissaient plus et donc ils ne voyaient pas comment le système pouvait être utilisé à des fins de sécurisation. Cela confirme la nécessité pour les utilisateurs d’avoir une compréhension non seulement de la sortie du système, mais aussi de ses processus et de son but. Elles ont également exprimé le désir de contrôler le fonctionnement du système en étant en mesure de l’éteindre et de l’allumer quand elles le désiraient. De plus, elles ont souligné l’importance de pouvoir déterminer elles-mêmes les personnes qui pourront avoir accès à l’information recueillie. Selon les personnes interrogées, certaines voulaient que les proches puissent avoir accès à l’information pour les rassurer et d’autres ne le souhaitaient pas. A la question de l’intérêt d’un tel système, neuf personnes sur dix ont répondu qu’elles ne voulaient pas installer ce système chez elles, car elles ne jugeaient pas en avoir besoin, elles se sentaient indépendantes. La seule personne qui voulait installer ce dispositif avait récemment chuté et a précisé qu’un tel système aurait été utile lors de sa chute pour alerter des personnes. Pour construire le système final, nous devons donc prendre en compte ces différentes préconisations pour que le système soit accepté. Les images doivent rester anonymes. Pour cela, le système est conçu pour que l’analyse des images puisse être faite localement et que seules les mesures d’activité soient transmises ou stockées. Nous ajouterons au système la possibilité de l’éteindre ou l’allumer. Cette action est non seulement utile pour la personne suivie mais aussi pour les personnes extérieures (personnel soignant et famille) qui pourraient avoir des réticences à être filmées. L’utilisateur doit être mis dans la boucle en lui expliquant l’intérêt qu’il a d’installer un tel système, lui expliquer le fonctionnement et lui laisser la décision de qui aura accès aux données. 148Annexe A Modèle de Markov caché Le modèle de Markov caché est la méthode paramétrique choisie pour développer un algorithme de détection d’activité. Avant de définir le formalisme, nous présentons le cas plus général des processus de Markov. Nous présentons également les différents algorithmes, de la littérature, utilisés pour l’apprentissage et l’inférence dans les modèles de Markov cachés. A.1 Définition des modèles de Markov cachés A.1.1 Processus de Markov Un modèle de Markov est un processus stochastique dont le but est de représenter l’évolution dans le temps de l’état d’un système. Les modèles de Markov suivent l’hypothèse de Markov, selon laquelle l’état courant ne dépend que d’un nombre fini et fixé d’états précédents. En d’autres termes, l’état dans lequel se trouve le système au temps t ne dépend que de l’état dans lequel il se trouvait aux temps t−1, t−2, . . . , t−n, n étant le nombre d’états antérieurs que l’on souhaite prendre en compte. Les processus satisfaisant cette hypothèse sont appelés processus de Markov ou chaînes de Markov. Deux éléments composent un modèle de Markov, les états et les transitions. Une transition est définie comme la probabilité de passer d’un état à un autre. A chaque pas de temps, une transition est appliquée au modèle qui modifie son état selon une certaine probabilité. La représentation d’un modèle de Markov, à deux états, est présentée à la figure A.1. Sur cette figure sont représentés deux états et les probabilités de transition entre chaque état. Par exemple, la probabilité de passer de l’état 1 à l’état 2 est de 70 %. Etat 1 Etat 2 0,7 0,3 0,8 0,2 Figure A.1 – Exemple de modèle de Markov à deux états. Les modèles de Markov permettent d’étudier l’évolution de la séquence d’états produite par le modèle, et surtout sa probabilité d’apparition. C’est pourquoi, une autre façon de représenter les chaines de Markov est fondée sur le temps. La chaine de Markov à la figure A.2 représente une séquence d’états de 0 à t, où Xi représente l’état à l’instant i. 149Annexe A. Modèle de Markov caché X0 X1 Xt Figure A.2 – Représentation graphique d’une chaine de Markov. A.1.2 Modèle de Markov caché Un modèle de Markov caché (MMC), en anglais Hidden Markov Model (HMM), est basé sur un modèle de Markov avec la particularité que les états ne sont pas directement observables [Rabiner, 1989]. Chaque état conditionne les observations qui sont visibles et qui permettront d’estimer l’état courant. Un MMC étudie l’évolution d’une séquence d’observations mesurées dans un système, comme représenté à la figure A.3. La figure illustre un MMC évoluant dans le temps avec Xt les états cachés, représentés en gris, et Ot les observations. Un MMC est défini par : — un ensemble d’états ; — une matrice aij = P(Xt = j|Xt−1 = i) représentant toutes les probabilités de transition entre chaque paire d’états ; — une probabilité initiale πi = P(X0 = i) pour chaque état i, qui est la probabilité a priori que le système se trouve dans l’état i à t = 0 ; — une fonction d’observation bi(o) = P(Ot = o|Xt = i). X0 O0 X1 O1 Xt Ot Figure A.3 – Représentation graphique d’une chaine de Markov cachée, avec Xt le processus Markovien caché et Ot la séquence d’observations correspondantes. A.2 Algorithmes d’apprentissage et d’inférence L’objectif de cette section est de présenter les algorithmes capables d’inférer, pour un MMC, dans quel état se trouve la personne à chaque pas de temps. Les MMC peuvent être utilisés soit individuellement, soit par combinaison. Pour résoudre les systèmes basés sur un unique MMC, les algorithmes d’inférences couramment utilisés sont les algorithmes Forward-Backward et de Viterbi [Rabiner, 1989]. Pour résoudre les systèmes à base de combinaison de MMC, un algorithme d’inférence et un algorithme d’apprentissage, tel que l’algorithme de Baum-Welch, sont nécessaires. A.2.1 Inférence pour le cas du MMC unique Deux algorithmes peuvent résoudre l’inférence, l’algorithme Forward-Backward et l’algorithme de Viterbi. Algorithme Forward-Backward L’algorithme Forward-Backward est utilisé ici pour calculer la probabilité d’être dans tel ou tel état, connaissant les observations et le modèle. Le modèle constitue un ensemble d’hypothèses 150A.2. Algorithmes d’apprentissage et d’inférence que l’on définit comme vrai. La probabilité de chaque état est représentée par la variable γ et l’équation qui en découle est la suivante : γt(i) = P(qt = i|O, λ) avec qt l’état au temps t, O la séquence d’observation O = (o1o2 . . . oT ) et λ le modèle. La variable γ calcule donc la probabilité d’être dans l’état i au temps t, sachant la séquence d’observation O et le modèle λ. Pour calculer la variable γ, il est nécessaire de calculer des variables intermédiaires obtenues grâce à deux étapes, Forward et Backward. La phase Forward permet de calculer la probabilité jointe d’observer une séquence de valeurs passées et d’être dans tel état. La phase Backward calcule la probabilité d’être dans tel état sachant les observations futures. Ainsi, la probabilité γ de l’état sachant les observations passées et futures est calculée à partir des deux variables obtenues avec Forward et Backward. Forward L’idée est de calculer la probabilité jointe de la séquence d’observation O = (o1, o2, . . . , ot) (jusqu’au temps t) et de l’état i au temps t, sachant le modèle λ. L’équation à résoudre est la suivante : αt(i) = P(o1, o2, . . . , ot , qt = i|λ). La première étape de l’algorithme initialise la probabilité α comme la probabilité jointe de l’état i et de l’observation initiale o1 : α1(i) = πibi(o1), pour 1 ≤ i ≤ N c’est-à-dire que la valeur α de l’état i au temps t = 1 est égale à πi , la probabilité initiale de l’état i, multipliée par bi(o1), la probabilité d’observation de l’état i. Pour l’induction allant de t > 1 à t = T, le α est égal à : αt+1(j) = "X N i=1 αt(i)aij# bj (ot+1), pour 1 ≤ t ≤ T − 1 et pour 1 ≤ j ≤ N, avec N le nombre d’état, aij la probabilité de transition entre i et j, bj (ot+1) la probabilité d’observation de l’état j au temps t + 1. Ce calcul est représenté graphiquement à la figure A.4. Cette figure est une illustration, pour un MMC à trois états, du calcul de la probabilité effectué pour αt+1(j = 1) par Forward. Dans l’implémentation, une étape de normalisation est nécessaire pour permettre aux valeurs de rester dans un domaine représentable numériquement, soit : α 0 t+1(j) = αt+1(j) hPN j=1 αt+1(j) i, pour 1 ≤ j ≤ N. Backward L’idée est de calculer la probabilité d’être dans un état sachant les observations futures. Contrairement à Forward, la probabilité à l’instant t est calculée à partir de la probabilité à l’instant t + 1 c’est-à-dire que le calcul se fait à partir du dernier pas de temps T jusqu’au début de la séquence, sachant le modèle λ. L’équation à résoudre est : βt(i) = P(ot+1, ot+2, . . . , oT , qt = i|λ). 151Annexe A. Modèle de Markov caché α(i = 1) α(i = 2) α(i = 3) α(j = 1) t t + 1 i = 1 i = 2 i = 3 j = 1 j = 2 j = 3 a11 a21 a31 Figure A.4 – Représentation du calcul αt+1(j = 1) par l’algorithme Forward pour un modèle à trois états. A l’initialisation, le β vaut 1 pour tous les états : βT (i) = 1, pour 1 ≤ i ≤ N. Pour l’induction allant de t = T − 1 à t = 1, le β est égal à : βt(i) = X N j=1 aij bj (ot+1)βt+1(j), pour t = T − 1, T − 2, . . . , 1 et pour 1 ≤ i ≤ N, avec N le nombre d’état, aij la probabilité de transition entre i et j, bj (ot+1) la probabilité d’observation de l’état j au temps t + 1. Ce calcul est représenté graphiquement à la figure A.5. Cette figure est une illustration, pour un MMC à trois états, du calcul de la probabilité effectuée pour βt(i = 1) par Backward. Dans l’implémentation, une étape de normalisation est effectuée à chaque pas de temps soit : β 0 t (i) = βt(i) hPN i=1 βt(i) i, pour 1 ≤ i ≤ N. Couplage Forward-Backward Après avoir calculé α et β pour chaque pas de temps, γ est alors déduit à partir de ces deux valeurs pour ainsi donner les probabilités d’apparition de chaque état de t = 1 à t = T, sachant les observations passées et futures et le modèle. L’équation à calculer est la suivante : γt(i) = αt(i)βt(i) PN i=1 αt(i)βt(i) , pour 1 ≤ i ≤ N. L’état le plus probable à chaque pas de temps est déduit en prenant la valeur du γ la plus grande. M ax(γt(i)) conserve l’état parmi tous les états au temps t ayant le γ le plus élevé. Ainsi dans notre cas, nous obtiendrons l’état dans lequel la personne est passée. Et comme à chaque état du MMC correspond une activité, ainsi nous obtenons, en conservant l’état ayant la plus grande probabilité, l’activité qui est réalisée par la personne. 152A.2. Algorithmes d’apprentissage et d’inférence β(j = 1) β(j = 2) β(j = 3) β(i = 1) t t + 1 i = 1 i = 2 i = 3 j = 1 j = 2 j = 3 a11 a12 a13 Figure A.5 – Représentation du calcul pour l’état βt(i = 1) par l’algorithme Backward pour un modèle à trois états. Algorithme de Viterbi L’algorithme de Viterbi, à la différence de l’algorithme Forward-Backward, fournit le « chemin » le plus probable, c’est-à-dire la meilleure séquence d’état (q1, q2, . . . , qT ), sachant les observations et le modèle. Pour résoudre ce problème, il est nécessaire de passer par le calcul de δ défini par : δt(i) = max q1,q2,...,qt−1 P[q1q2 . . . qt−1, qt = i, o1o2 . . . ot |λ]. A travers le δt(i), cet algorithme calcule pour chaque état caché du modèle, le chemin le plus probable atteignant l’état i au temps t. Pour mémoriser le chemin, l’état qui maximise les probabilités à chaque pas de temps sera conservé à travers la variable ψ. Au temps t = 1, l’initialisation est définie par : δ1(i) = πibi(o1), pour 1 ≤ i ≤ N ψ1(i) = 0. Pour l’induction allant de t > 1 à t = T : δt(j) = max 1≤i≤N [δt−1(i)a(ij)] bj (ot), pour 2 ≤ t ≤ T, ψt(j) = arg max 1≤i≤N [δt−1(i)a(ij)] et pour 1 ≤ j ≤ N. ψt(j) est donc la mémorisation de l’état précédent (au temps t − 1) appartenant au meilleur chemin qui mène à l’état j au temps t. La figure A.6 représente le calcul de δ et de ψ pour l’état j au temps t, effectué par l’algorithme de Viterbi pour un modèle à trois états. Le rouge symbolise l’état et la transition atteignant l’état j qui a la plus grande probabilité. A l’implémentation, à chaque pas de temps et pour chaque état, il est nécessaire de normaliser : δ 0 t (j) = δt(j) PN j=1 δt(j) , pour 1 ≤ j ≤ N. Au dernier pas de temps, pour t = T, la plus grande probabilité entre tous les états est calculée : P ∗ = max 1≤i≤N [δT (i)], 153Annexe A. Modèle de Markov caché δ(i = 1) δ(i = 2) δ(i = 3) δ(j = 1) ψ(j = 1) t − 1 t i = 1 i = 2 i = 3 j = 1 j = 2 j = 3 a11 a21 a31 Figure A.6 – Représentation du calcul δt(j = 1) et ψt(j = 1) par l’algorithme de Viterbi pour un modèle à trois états. q ∗ T = arg max 1≤i≤N [δT (i)]. Une dernière étape est nécessaire, il s’agit d’une étape de rétro-propagation. En prenant la plus haute probabilité parmi les états du temps t = T, on retrace le meilleur chemin en remontant jusqu’au premier pas de temps : q ∗ t = ψt+1(q ∗ t+1), pour t = T − 1, T − 2, . . . , 1. La figure A.7 représente les différentes étapes effectuées par l’algorithme de Viterbi. A chaque étape de l’induction, l’algorithme se souvient de l’état le plus probable (rond rouge) et pour chaque état il se souvient de son prédécesseur le plus probable (transition rouge).Cette figure représente également la rétro-propagation à partir du dernier temps t = T sur 4 pas de temps. Le chemin le plus probable trouvé par l’algorithme de Viterbi, sur cette figure, est représenté en vert. Les chiffres correspondent aux différentes itérations de l’étape d’induction (en rouge) et de l’étape de rétro-propagation (en vert). Nous pouvons remarquer que le chemin le plus probable ne correspond pas forcément aux transitions des états les plus probables (représentées en rouge) définies par les calculs de l’induction. t = 1 T − 2 T − 1 T 1 2 3 3 2 1 Figure A.7 – Représentation du calcul de l’algorithme de Viterbi avec la rétro-propagation (en vert) pour quatre pas de temps successifs et trois états. 154A.2. Algorithmes d’apprentissage et d’inférence A.2.2 Apprentissage et inférence pour les systèmes de plusieurs MMC L’utilisation de MMC combiné permet de ne pas insérer de connaissance a priori. L’objectif est de générer un modèle appris en fonction des données qui lui sont fournies. La solution consiste à construire un modèle qui maximise la vraisemblance, c’est-à-dire la probabilité d’apparition d’une séquence d’observations O = (o1, o2, . . . , oT ). En d’autres termes, l’objectif est de trouver le modèle qui explique le mieux la séquence. Pour construire un modèle collant au plus près des données, il est nécessaire d’apprendre les paramètres du modèle qui sont les probabilités initiales, les probabilités de transition et les paramètres de la fonction d’observation (moyenne et covariance de chaque état). Pour estimer les paramètres, l’algorithme de Baum-Welch est utilisé. Cet algorithme présente le défaut de ne pas toujours converger vers la même solution. Apprentissage L’algorithme de Baum-Welch est un cas particulier de l’algorithme Espérance-Maximisation, qui sont les deux étapes à appliquer itérativement pour apprendre les paramètres du modèle. La première étape permet d’estimer la séquence d’états correspondant aux observations à partir du modèle courant. La seconde étape consiste à ré-estimer les paramètres du modèle pour augmenter sa vraisemblance. La base d’apprentissage est composée d’un ensemble d’exemples pour chaque état à modéliser. Espérance Cette première étape consiste à calculer pour chaque séquence, les probabilités a postériori. Cette étape est réalisée avec l’algorithme Forward-Backward décrit précédemment à la section A.2.1. Le résultat de cette étape est pour chaque séquence s de longueur Ts, composant les exemples de l’activité à modéliser, les valeurs α s t β s t et γ s t . Pour la première itération, les valeurs prises par le modèle sont des valeurs d’initialisation arbitraires. Pour les probabilités initiales de chaque état, nous les fixons à l’identique. Concernant la matrice de transition, toutes les probabilités sont fixées également de manière équivalente. Concernant les observations, la moyenne et la covariance, nécessaires pour former les gaussiennes multivariées de chaque état et chaque MMC, doivent être initialisées. Les moyennes pour la position du centre de masse, la vitesse, et la distribution verticale sont initialisées en prenant, de manière aléatoire, les valeurs d’une observation correspondant à une activité. A partir de ces moyennes tirées au hasard, la covariance est calculée pour chaque état. Pour les itérations suivantes, l’algorithme consiste à reprendre les paramètres estimés par l’étape de maximisation. Maximisation Dans cette étape, la moyenne et la covariance sont alors recalculées de façon à maximiser la vraisemblance, pour faire en sorte que le modèle soit plus proche de la réalité. En d’autres termes, l’ensemble des MMC est réévalué par rapport à la séquence d’observations sur laquelle nous voulons l’entraîner. L’estimation des paramètres est renouvelée jusqu’à ce qu’il y ait convergence. Réestimation de la matrice de transition Les probabilités de transition sont recalculées en comptant les transitions à partir des données obtenues à l’étape Espérance. L’équation suivante permet de calculer ξt(i, j), qui est la probabilité de transition entre les états i et j entre les instants 155Annexe A. Modèle de Markov caché t et t + 1. ξ s t (i, j) = α s t (i)aij bj (o s t+1)β s t+1(j) PN k=1 PN l=1 α s t (k)aklbl(o s t+1)β s t+1(l) où s est le numéro de la séquence dans la base d’apprentissage. La probabilité de transition entre i et j est ensuite obtenue en faisant la somme sur toutes les séquences des ξ s t (i, j) divisée par la somme des γ s t (i) qui représente la probabilité de se trouver dans l’état i : aij = PS s=1 PTs−1 t=1 ξ s t (i, j) PS s=1 PTs−1 t=1 γ s t (i) . Réestimation de la matrice des probabilités initiales La probabilité initiale est obtenue en regardant la probabilité des différents états en début de séquences dans les données de l’étape Espérance : πi = PS s=1 γ s 0 (i) S . Réestimation de la matrice des probabilités d’observations. Les moyennes et covariances des fonctions d’observations sont recalculées pour chaque état en prenant en compte à chaque instant la probabilité d’appartenir à l’état : µi = PS s=1 PTs t=1 γ s t (i)o s t PS s=1 PTs t=1 γ s t (i) , Σi = PS s=1 PTs t=1 γ s t (i)(o s t − µi)(o s t − µi) 0 PS s=1 PTs t=1 γ s t (i) . Inférence L’inférence est réalisée en calculant à chaque pas de temps la vraisemblance du modèle. L’état le plus probable est celui qui correspond au modèle donnant la plus grande vraisemblance. La vraisemblance L se calcule en reprenant les valeurs de l’étape Forward en fin de séquence : L = X N i=1 αT (i). Dans l’implémentation, il est habituel d’utiliser le logarithme de la vraisemblance qui permet de garder les valeurs dans un domaine représentable numériquement. Et comme les valeurs α ont été normalisées à chaque pas de temps, le logarithme de la vraisemblance se calcule en faisant la somme des logarithmes des coefficients de normalisation. 156Publications [1] Amandine Dubois and François Charpillet. A gait analysis method based on a depth camera for fall prevention. In 36th Annual International Conference of the IEEE Engineering in Medicine and Biology Society (EMBC). IEEE, 2014. [2] Amandine Dubois and François Charpillet. Detecting and preventing falls with depth camera, tracking the body center. In 12th European Association for the Advancement of Assistive Technology in Europe (AAATE), 2013. [3] Amandine Dubois and François Charpillet. Human activities recognition with RGB-Depth camera using HMM. In 35th Annual International Conference of the IEEE Engineering in Medicine and Biology Society (EMBC), pages 4666–4669. IEEE, 2013. [4] Amandine Dubois and François Charpillet. Automatic fall detection system with a RGB-D camera using a Hidden Markov Model. In 11th International Conference on Smart Homes and Health Telematics (ICOST), pages 259–266, 2013. [5] Amandine Dubois and François Charpillet. Système d’évaluation de la fragilité chez les personnes âgées. In Journée d’étude sur la TéléSanté (JETSAN). IEEE france, 2013. [6] Amandine Dubois and François Charpillet. Tracking mobile objects with several kinects using HMMs and component labelling. In Workshop Assistance and Service Robotics in a human environment, International Conference on Intelligent Robots and Systems (IROS). IEEE, 2012. [7] Amandine Dubois, Abdallah Dib, and François Charpillet. Using HMMs for discriminating mobile from static objects in a 3D occupancy grid. In 23rd International Conference on Tools with Artificial Intelligence (ICTAI), pages 170–176. IEEE, 2011. 157BIBLIOGRAPHIE 158Références [Aggarwal and Ryoo, 2011] J.K. Aggarwal and Michael S. Ryoo. Human activity analysis : A review. ACM Computing Surveys, 43(3), 2011. [Alexander et al., 1997] Neil B. Alexander, Jessica Ulbrich, Aarti Raheja, and Dwight Channer. Rising from the floor in older adults. Journal of the American Geriatrics Society, 45(5) :564– 569, 1997. [Allard and Blanchi, 1996] Paul Allard and Jean-Pierre Blanchi. Analyse du mouvement humain par la biomécanique. Décarie, 1996. [Anderson et al., 2006] Derek Anderson, James M. Keller, Marjorie Skubic, Xi Chen, and Zhihai He. Recognizing falls from silhouettes. In 28th Annual International Conference of the Engineering in Medicine and Biology Society, (EMBS), pages 6388–6391. IEEE, 2006. [Anderson et al., 2009] Derek Anderson, Robert H. Luke, James M. Keller, Marjorie Skubic, Marilyn Rantz, and Myra Aud. Linguistic summarization of video for fall detection using voxel person and fuzzy logic. Computer Vision and Image Understanding, 113(1) :80–89, 2009. [André et al., 2001] J.-M. André, J. Paysant, N. Martinet, J-M. Beis, and C. Beyaert. Georges Gilles de la Tourette, initiateur de l’enregistrement de la marche dans les maladies du système nerveux. Revue neurologique, 157(3) :293–296, 2001. [Auvinet et al., 2003] Bernard Auvinet, Gilles Berrut, Claude Touzard, Nadine Collet, Denis Chaleil, and Eric Barrey. Gait abnormalities in elderly fallers. Journal of Aging and Physical Activity, pages 40–52, 2003. [Auvinet et al., 2011b] Edouard Auvinet, Franck Multon, Alain Saint-Arnaud, Jacqueline Rousseau, and Jean Meunier. Fall detection with multiple cameras : An occlusion-resistant method based on 3-D silhouette vertical distribution. IEEE transactions on information technology in biomedicine : a publication of the IEEE EMBS, 15(2) :290–300, 2011. [Avidan, 2004] Shai Avidan. Support vector tracking. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 26(8) :1064–1072, 2004. [Bellotti and Sellen, 1993] Victoria Bellotti and Abigail Sellen. Design for privacy in ubiquitous computing environments. In Proceedings of the Third European Conference on ComputerSupported Cooperative Work (ECSCW), pages 77–92. Springer, 1993. [Bian et al., 2012] Zhen-Peng Bian, Lap-Pui Chau, and Nadia Magnenat-Thalmann. Fall detection based on skeleton extraction. In Proceedings of the 11th ACM SIGGRAPH International Conference on Virtual-Reality Continuum and its Applications in Industry, pages 91–94. ACM, 2012. [Blanpain and Chardon, 2010] Nathalie Blanpain and Olivier Chardon. Projections de population à l’horizon 2060. Un tiers de la population âgé de plus de 60 ans, INSEE. Octobre 2010. 159BIBLIOGRAPHIE [Bourke et al., 2007] A.K. Bourke, J.V. O’Brien, and G.M. Lyons. Evaluation of a thresholdbased tri-axial accelerometer fall detection algorithm. Gait & posture, 26(2) :194–199, 2007. [Bramell-Risberg et al., 2005] Eva Bramell-Risberg, G-B Jarnlo, Lennart Minthon, and Sölve Elmståhl. Lower gait speed in older women with dementia compared with controls. Dementia and geriatric cognitive disorders, 20(5) :298–305, January 2005. [Caine et al., 2005] Kelly E. Caine, Wendy A. Rogers, and Arthur D. Fisk. Privacy perceptions of an aware home with visual sensing devices. In Proceedings of the Human Factors and Ergonomics Society Annual Meeting, volume 49, pages 1856–1858. SAGE Publications, 2005. [Camicioli et al., 1998] R. Camicioli, D. Howieson, B. Oken, G. Sexton, and J. Kaye. Motor slowing precedes cognitive impairment in the oldest old. American Academy of Neurology, 50(5) :1496–1498, 1998. [Comaniciu, 2002] Dorin Comaniciu. Bayesian kernel tracking. In Pattern Recognition, pages 438–445. Springer, 2002. [Condouret et al., 1987] J. Condouret, M. Iehl, C. F. Roques, P. Dupui, F. Montoya, B. Pages, P. Bessou, and M. Pujol. Analyse spatio-temporelle de la marche par la technique de Bessou : résultats chez l’hémiplégique. In Annales de réadaptation et de médecine physique, volume 30, pages 267–278. Elsevier, 1987. [Deeb et al., 2012] Rada Deeb, Félix Lédée, Elodie Desserée, and Saida Bouakaz. Méthode robuste pour la détection de chute dans un environnement non-contrôlé. In Actes de la conférence RFIA, Reconnaissance des Formes et Intelligence Artificielle, 2012. [Demiris et al., 2009] George Demiris, Debra Parker Oliver, Jarod Giger, Marjorie Skubic, and Marilyn Rantz. Older adults’ privacy considerations for vision based recognition methods of eldercare applications. Technology and Health Care, 17(1) :41–48, 2009. [Enzweiler and Gavrila, 2009] Markus Enzweiler and Dariu M. Gavrila. Monocular pedestrian detection : Survey and experiments. Transactions on Pattern Analysis and Machine Intelligence, 31(12) :2179–2195, 2009. [Faivre, 2003] Arnaud Faivre. Conception et validation d’un nouvel outil d’analyse de la marche. PhD thesis, Université de Franche-Comté, 2003. [Ferri et al., 2006] Cleusa P. Ferri, Martin Prince, Carol Brayne, Henry Brodaty, Laura Fratiglioni, Mary Ganguli, Kathleen Hall, Kazuo Hasegawa, and Hugh Hendrie. Global prevalence of dementia : a Delphi consensus study. The Lancet Neurology, 2006. [Fried et al., 2001] Linda P. Fried, Catherine M. Tangen, Jeremy Walson, Anne B. Newman, Calvin Hirsch, John Gottdiener, Teresa Seeman, Tracy Russell, Willem J. Kop, Gregory Burke, and Mary Ann McBurnie. Frailty in older adults : Evidence for a phenotype. Journal of Gerontology Series A : Biological Sciences and Medical Sciences, 56(3) :146–156, 2001. [Fusco, 2008] Nicolas Fusco. Analyse, modélisation et simulation de la marche pathologique. PhD thesis, Université Rennes 2, 2008. [Gaxatte et al., 2011] C. Gaxatte, T. Nguyen, F. Chourabi, J. Salleron, V. Pardessus, I. Delabrière, A. Thévenon, and F. Puisieux. Fear of falling as seen in the multidisciplinary falls consultation. Annals of physical and rehabilitation medicine, 54(4) :248–258, 2011. [Gillet, 2004] Christophe Gillet. Analyse Biomécanique de la marche et proposition de classes de marcheurs -Application au portage de sacs à dos. PhD thesis, Université de Valenciennes et du Hainaut-Cambrésis, 2004. 160BIBLIOGRAPHIE [Gómez-Conde, 2011] Iván Gómez-Conde. Simple human gesture detection and recognition using a feature vector and a real-time histogram based algorithm. Journal of Signal and Information Processing, 02(04) :279–286, 2011. [Grewe and Kak, 1995] Lynne Grewe and Avinash C. Kak. Interactive learning of a multipleattribute hash table classifier for fast object recognition. Computer Vision and Image Understanding, 61(3) :387–416, 1995. [Guimaraes and Isaacs, 1980] R.M. Guimaraes and Bernard Isaacs. Characteristics of the gait in old people who fall. Disability & Rehabilitation, 2(4) :177–180, 1980. [Hageman and Blanke, 1986] Patricia A. Hageman and Daniel J. Blanke. Comparison of gait of young women and elderly women. Physical therapy, 66(9) :1382–1387, September 1986. [Hagler et al., 2010] Stuart Hagler, Daniel Austin, Tamara L. Hayes, Jeffrey Kaye, and Misha Pavel. Unobtrusive and ubiquitous in-home monitoring : A methodology for continuous assessment of gait velocity in elders. IEEE transactions on bio-medical engineering, 57(4) :813–820, April 2010. [Harris and Stephens, 1988] Chris Harris and Mike Stephens. A combined corner and edge detector. In 4th Alvey Vision Conference, volume 15, pages 147–151. Manchester, UK, 1988. [Hausdorff et al., 2001] Jeffrey M. Hausdorff, Dean A. Rios, and Helen K. Edelberg. Gait variability and fall risk in community-living older adults : A 1-year prospective study. Archives of physical medicine and rehabilitation, 82(8) :1050–1056, August 2001. [Hewson et al., 2007] David J. Hewson, Jacques Duchêne, François Charpillet, Jamal Saboune, Valérie Michel-Pellegrino, Hassan Amoud, Michel Doussot, Jean Paysant, Anne Boyer, and Jean-Yves Hogrel. The PARAchute project : remote monitoring of posture and gait for fall prevention. EURASIP Journal on Advances in Signal Processing, 2007. [Holtzer et al., 2006] Roee Holtzer, Joe Verghese, Xiaonan Xue, and Richard B. Lipton. Cognitive processes related to gait velocity : Results from the einstein aging study. Neuropsychology, 20(2) :215–223, March 2006. [Jansen et al., 2007] Bart Jansen, Frederik Temmermans, and Rudi Deklerck. 3D human pose recognition for home monitoring of elderly. In 29th Annual International Conference of the Engineering in Medicine and Biology Society (EMBS), pages 4049–4051. IEEE, January 2007. [Jepson et al., 2003] Allan D. Jepson, David J. Fleet, and Thomas F. El-Maraghi. Robust online appearance models for visual tracking. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 25(10) :1296–1311, 2003. [Ke et al., 2013] Shian-Ru Ke, Hoang Le Uyen Thuc, Yong-Jin Lee, Jenq-Neng Hwang, Jang-Hee Yoo, and Kyoung-Ho Choi. A review on video-based human activity recognition. Computers, 2(2) :88–131, 2013. [Kirtley, 2006] Christopher Kirtley. Clinical Gait Analysis : Theory and practice. Elsevier Health Sciences, 2006. [Kuo et al., 2007] Hsu-Ko. Kuo, Suzanne G. Leveille, Yau-Hua Yu, and William P. Milberg. Cognitive function, habitual gait speed, and late-life disability in the national health and nutrition examination survey (NHANES) 1999-2002. Gerontology, 53(15) :102–110, 2007. [Lowe, 2004] David G. Lowe. Distinctive image features from scale-invariant keypoints. International Journal of Computer Vision, 60(2) :91–110, 2004. [Marey, 1894] Etienne-Jules Marey. Le mouvement. Masson, 1894. 161BIBLIOGRAPHIE [Martin et al., 2004] David R. Martin, Charless C. Fowlkes, and Jitendra Malik. Learning to detect natural image boundaries using local brightness, color, and texture cues. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 26(5) :530–549, 2004. [Melenhorst et al., 2004] Anne-Sophie Melenhorst, Arthur D. Fisk, Elizabeth D. Mynatt, and Wendy A. Rogers. Potential intrusiveness of aware home technology : Perceptions of older adults. In Proceedings of the Human Factors and Ergonomics Society Annual Meeting, volume 48, pages 266–270. SAGE Publications, 2004. [Moravec, 1979] Hans P. Moravec. Visual mapping by a robot rover. In Proceedings of the 6th International Joint Conference on Artificial Intelligence-Volume 1, pages 598–600. Morgan Kaufmann Publishers Inc., 1979. [Nait-Charif and McKenna, 2004] H. Nait-Charif and S.J. McKenna. Activity summarisation and fall detection in a supportive home environment. In 17th International Conference on Pattern Recognition (ICPR), volume 4, pages 323–326. IEEE, 2004. [Noury et al., 2007] Norbert Noury, Anthony Fleury, Pierre Rumeau, A.K. Bourke, G.O. Laighin, Vincent Rialle, and J.E. Lundy. Fall detection-principles and methods. In Engineering in Medicine and Biology Society (EMBS), 29th Annual International Conference of the IEEE, pages 1663–1666. IEEE, 2007. [Papageorgiou et al., 1998] Constantine P. Papageorgiou, Michael Oren, and Tomaso Poggio. A general framework for object detection. In International conference on Computer Vision, 1998, pages 555–562. IEEE, 1998. [Pepin et al., 2009] Nicolas Pepin, Olivier Simonin, and François Charpillet. Intelligent tiles : Putting situated multi-agents models in real world. In International Conference on Agents and Artificial Intelligence (ICAART’09), pages 513–519, 2009. [Perry and Davids, 1992] Jacquelin Perry and Jon R. Davids. Gait analysis : Normal and pathological function. Journal of Pediatric Orthopaedics, 12(6) :815, 1992. [Peursum et al., 2005] Patrick Peursum, Hung H. Bui, Svetha Venkatesh, and Geoff West. Robust recognition and segmentation of human actions using HMMs with missing observations. EURASIP Journal on Applied Signal Processing, 2005(13) :2110–2126, 2005. [Rabiner, 1989] Lawrence Rabiner. A tutorial on hidden Markov models and selected applications in speech recognition. In Proceedings of the IEEE, pages 257–286, 1989. [Rangarajan and Shah, 1991] Krishnan Rangarajan and Mubarak Shah. Establishing motion correspondence. Conference Vision Graphies Image Process, 54(1) :56–73, 1991. [Rimmer et al., 2005] E. Rimmer, M. Wojciechowska, C. Stave, A. Sganga, and B. O’Connell. Implications of the facing dementia survey for the general population, patients and caregivers across europe. International Journal of Clinical Practice, 1(146) :17–24, March 2005. [Rimminen et al., 2009] Henry Rimminen, Juha Lindström, and Raimo Sepponen. Positioning accuracy and multi-target separation with a human tracking system using near field imaging. International Journal on Smart Sensing and Intelligent System, 2(1) :156–175, 2009. [Rimminen et al., 2010] Henry Rimminen, Juha Lindström, Matti Linnavuo, and Raimo Sepponen. Detection of falls among the elderly by a floor sensor using the electric near field. IEEE transactions on information technology in biomedicine : a publication of the IEEE Engineering in Medicine and Biology Society, 14(6) :1475–1476, November 2010. [Rose et al., 2008] Cédric Rose, Jamal Saboune, and François Charpillet. Reducing particle filtering complexity for 3D motion capture using dynamic bayesian networks. In Twenty-Third AAAI Conference on Artificial Intelligence, pages 1396–1401, 2008. 162BIBLIOGRAPHIE [Rougier and Meunier, 2010] Caroline Rougier and Jean Meunier. 3D head trajectory using a single camera. In Image and Signal Processing, pages 505–512. Springer, 2010. [Rougier et al., 2011] Caroline Rougier, Edouard Auvinet, Jacqueline Rousseau, Max Mignotte, and Jean Meunier. Fall detection from depth map video sequences. International Conference on Smart Homes and Health Telematics (ICOST), pages 121–128, 2011. [Rowley et al., 1998] Henry A. Rowley, Shumeet Baluja, and Takeo Kanade. Neural networkbased face detection. Pattern Analysis and Machine Intelligence, 20(1) :23–38, 1998. [Russell and Norvig, 2010] Stuart Jonathan Russell and Peter Norvig. Intelligence artificielle. Pearson Education France, 2010. [Saboune and Charpillet, 2005] Jamal Saboune and Francois Charpillet. Using interval particle filtering for marker less 3D human motion capture. In 17th IEEE International Conference on Tools with Artificial Intelligence (ICTAI’05). IEEE, 2005. [Saunders et al., 1953] M. Saunders, Verne T. Inman, and Howard D. Eberhart. The major determinants in normal and pathological gait. The Journal of Bone & Joint Surgery, pages 543–558, July 1953. [Sethi and Jain, 1987] Ishwar K. Sethi and Ramesh Jain. Finding trajectories of feature points in a monocular image sequence. Pattern Analysis and Machine Intelligence, IEEE Transactions on, (1) :56–73, 1987. [Shaw, 2002] Fiona E. Shaw. Falls in cognitive impairment and dementia. Clinics Geriatric Medicine, pages 18 :159–280, 2002. [Shi and Malik, 2000] Jianbo Shi and Jitendra Malik. Normalized cuts and image segmentation. Pattern Analysis and Machine Intelligence, 22(8) :888–905, 2000. [Shotton et al., 2013] Jamie Shotton, Toby Sharp, Alex Kipman, Andrew Fitzgibbon, Mark Finocchio, Andrew Blake, Mat Cook, and Richard Moore. Real-time human pose recognition in parts from single depth images. Communications of the ACM, 56(1) :116–124, 2013. [Silva et al., 2002] Mauricio Silva, Eric F. Shepherd, Walter O. Jackson, Frederick J. Dorey, and Thomas P. Schmalzried. Average patient walking activity approaches 2 million cycles per year : pedometers under-record walking activity. The Journal of Arthroplasty, 17(6) :693–697, 2002. [Stauffer and Grimson, 2000] Chris Stauffer and W. Eric L. Grimson. Learning patterns of activity using real-time tracking. Pattern Analysis and Machine Intelligence, 22(8) :747–757, 2000. [Studenski et al., 2003] Stephanie Studenski, Subashan Perera, Dennis Wallace, Julie M. Chandler, Pamela W. Duncan, Earl Rooney, Michael Fox, and Jack M. Guralnik. Physical performance measures in the clinical setting. Journal of the American Geriatrics Society, 51(3) :314– 322, March 2003. [Suzuki et al., 2003] Kenji Suzuki, Isao Horiba, and Noboru Sugie. Linear-time connectedcomponent labeling based on sequential local operations. Computer Vision and Image Understanding, 89(1) :1–23, January 2003. [Thomesse et al., 2001] Jean-Pierre Thomesse, David Bellot, Anne Boyer, Eric Campo, Marie Chan, François Charpillet, Jocelyne Fayn, Claire Leschi, Norbert Noury, Vincent Rialle, Laurent Romary, Paul Rubel, Nazha Selmaoui, François Steenkeste, and Gilles Virone. Integrated information technologies for patients remote follow-up and homecare. 3rd International Workshop on Enterprise Networking and Computing in Health Care Industry (HealthCom), 2001. 163BIBLIOGRAPHIE [Tieu and Viola, 2004] Kinh Tieu and Paul Viola. Boosting image retrieval. International Journal of Computer Vision, 56(1-2) :17–36, 2004. [Tinetti et al., 1993] Mary E. Tinetti, Wen-Liang Liu, and Elizabeth B. Claus. Predictors and prognosis of inability to get up after falls among elderly persons. Journal of the American Medical Association (Jama), 269(1) :65–70, 1993. [Turaga et al., 2008] Pavan Turaga, Rama Chellappa, Venkatramana S. Subrahmanian, and Octavian Udrea. Machine recognition of human activities : A survey. IEEE Transactions on Circuits and Systems for Video Technology, 18(11) :1473–1488, 2008. [Valera and Velastin, 2005] M. Valera and Sergio A. Velastin. Intelligent distributed surveillance systems : a review. In Vision, Image and Signal Processing, IEE Proceedings-, volume 152, pages 192–204. IET, 2005. [Van Iersel et al., 2004] M.B. Van Iersel, W. Hoefsloot, M. Munneke, B.R. Bloem, and M.G.M. Olde Rikkert. Systematic review of quantitative clinical gait analysis in patients with dementia. Zeitschrift für Gerontologie und Geriatrie, 37(1) :27–32, February 2004. [Veenman et al., 2001] Cor J. Veenman, Marcel J.T. Reinders, and Eric Backer. Resolving motion correspondence for densely moving points. Pattern Analysis and Machine Intelligence, IEEE Transactions on, 23(1) :54–72, 2001. [Viel, 2000] Eric Viel. La marche humaine, la course et le saut. Biomécanique, explorations, normes et dysfonctionnements. Elsevier Masson, Paris, 2000. [Viola et al., 2003] Paul Viola, Michael J. Jones, and Daniel Snow. Detecting pedestrians using patterns of motion and appearance. In Proceedings of the International Conference on Computer Vision, pages 734–741. IEEE, 2003. [Waite et al., 2005] L.M. Waite, D.A Grayson, O. Piguet, H. Creasey, H.P. Bennett, and G.A. Broe. Gait slowing as a predictor of incident dementia : 6-year longitudinal data from the sydney older persons study. Journal of the Neurological Sciences, 229-230 :89–93, March 2005. [Webe, 2006] Amandine Webe. Dépendance des personnes âgées et handicap : les opinions des Français entre 2000 et 2005. DREES Études et résultats, mai 2006. [Wild et al., 1981] D. Wild, U.S. Nayak, and B. Isaacs. How dangerous are falls in old people at home ? British Medical Journal (Clinical research ed.), 282(6260) :266, 1981. [Winter et al., 1990] David A. Winter, Aftab E. Patla, James S. Frank, and Sharon E. Walt. Biomechanical walking pattern changes in the fit and healthy elderly. Physical therapy, 70(6) :340– 347, June 1990. [Wu, 2000] Ge Wu. Distinguishing fall activities from normal activities by velocity characteristics. Journal of Biomechanics, 33(11) :1497–1500, 2000. [Yilmaz et al., 2006] Alper Yilmaz, Omar Javed, and Mubarak Shah. Object tracking : A survey. ACM Computing Surveys, 38(4) :13, dec 2006. 164Résumé Le vieillissement de la population est un enjeu majeur pour les prochaines années en raison, notamment, de l’augmentation du nombre de personnes dépendantes. La question du maintien à domicile de ces personnes se pose alors, du fait de l’impossibilité pour les instituts spécialisés de les accueillir toutes et, surtout, de la volonté des personnes âgées de rester chez elles le plus longtemps possible. Or, le développement de systèmes technologiques peut aider à résoudre certains problèmes comme celui de la sécurisation en détectant les chutes, et de l’évaluation du degré d’autonomie pour prévenir les accidents. Plus particulièrement, nous nous intéressons au développement des systèmes ambiants, peu coûteux, pour l’équipement du domicile. Les caméras de profondeur permettent d’analyser en temps réel les déplacements de la personne. Nous montrons dans cette thèse qu’il est possible de reconnaître l’activité de la personne et de mesurer des paramètres de sa marche à partir de l’analyse de caractéristiques simples extraites des images de profondeur. La reconnaissance d’activité est réalisée à partir des modèles de Markov cachés, et permet en particulier de détecter les chutes et des activités à risque. Lorsque la personne marche, l’analyse de la trajectoire du centre de masse nous permet de mesurer les paramètres spatio-temporels pertinents pour l’évaluation de la fragilité de la personne. Ce travail a été réalisé sur la base d’expérimentations menées en laboratoire, d’une part, pour la construction des modèles par apprentissage automatique et, d’autre part, pour évaluer la validité des résultats. Les expérimentations ont montré que certains modèles de Markov cachés, développés pour ce travail, sont assez robustes pour classifier les différentes activités. Nous donnons, également dans cette thèse, la précision, obtenue avec notre système, des paramètres de la marche en comparaison avec un tapis actimètrique. Nous pensons qu’un tel système pourrait facilement être installé au domicile de personnes âgées, car il repose sur un traitement local des images. Il fournit, au quotidien, des informations sur l’analyse de l’activité et sur l’évolution des paramètres de la marche qui sont utiles pour sécuriser et évaluer le degré de fragilité de la personne. Mots-clés: Caméra de profondeur, Modèle de Markov caché, Reconnaissance d’activité, Analyse de la marche. Abstract Population ageing is a major issue for society in the next years, especially because of the increase of dependent people. The limits in specialized institutes capacity and the wish of the elderly to stay at home as long as possible explain a growing need for new specific at home services. Technologies can help securing the person at home by detecting falls. They can also help in the evaluation of the frailty for preventing future accidents. This work concerns the development of low cost ambient systems for helping the stay at home of elderly. Depth cameras allow analysing in real time the displacement of the person. We show that it is possible to recognize the activity of the person and to measure gait parameters from the analysis of simple feature extracted from depth images. Activity recognition is based on Hidden Markov Models and allows detecting at risk behaviours and falls. When the person is walking, the analysis of the trajectory of her centre of mass allows measuring gait parameters that can be used for frailty evaluation. This work is based on laboratory experimentations for the acquisition of data used for models training and for the evaluation of the results. We show that some of the developed Hidden Markov Models are robust enough for classifying the activities. We also evaluate de precision of the gait parameters measurement in comparison to the measures provided by an actimetric carpet. We believe that such a system could be installed in the home of the elderly because it relies on a local processing of the depth images. It would be able to provide daily information on the person activity and on the evolution of her gait parameters that are useful for securing her and evaluating her frailty. Keywords: Depth camera, Hidden Markov Model, Activity recognition, Gait analysis. Intégration de l’inférence abductive et inductive pour la repr´esentation des connaissances dans les r´eseaux de g`enes Tan Le To cite this version: Tan Le. Int´egration de l’inf´erence abductive et inductive pour la repr´esentation des connaissances dans les r´eseaux de g`enes. Automatic Control Engineering. Universit´e Paul Sabatier - Toulouse III, 2014. French. HAL Id: tel-00996894 https://tel.archives-ouvertes.fr/tel-00996894 Submitted on 27 May 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es. THÈSE En vue de l’obtention du DOCTORAT DE L’UNIVERSITÉ DE TOULOUSE Dévilré par l’Université Toulouse III – Paul Sabatier Discipline ou spécialité : Systèmes informatiques Présentée et soutenue par LE Tan Le 28 Avril 2014 Titre : Intégration de l’inférence abductive et inductive pour la représentation des connaissances dans les réseaux de gènes JURY Gilles RICHARD Président du jury Professeur, Université Toulouse III Jacques DEMONGEOT Rapporteur Professeur, Université Joseph Fourier, Grenoble Yves LACROIX Rapporteur Professeur, Université de Toulon Jean-Charles FAYE Examinateur Directeur de Recherche INSERM, Toulouse Belaid BENHAMOU Examinateur Maître de conférences, Université de Provence, Marseille Vincent RISCH Examinateur Maître de conférences, Université de Provence, Marseille Andrei DONCESCU Directeurs de thèse Maître de conférences, Université Toulouse III Pierre SIEGEL Co-directeurs de thèse Professeur, Université de Provence, Marseille Ecole doctorale : EDSYS Unité de recherche : LAAS-CNRS Directeur(s) de Thèse : Andrei DONCESCU et Pierre SIEGEL Rapporteurs : Jacques DEMONGEOT et Yves LACROIX A ceux qui m’aiment, A ceux que j’aime, A mes filles Hanh Quynh et Hanh Quyen, je vous aime !!! i Résumé Le raisonnement diagnostique (abductif) et le raisonnement de prédiction (inductif) sont deux des méthodes de raisonnement qui permettent la découverte de connaissances nouvelles. Lorsque le raisonnement abductif est le processus permettant de trouver la meilleure explication (hypothèse) pour un ensemble d’observations (Josephson, 1994), le raisonnement de prédiction est le processus, à partir d’un ensemble d’observations, permettant de trouver tous les résultats possibles. Ces observations peuvent être les symptômes d’un patient, des expériences concernant les réseaux métaboliques et génomiques, etc. Dans cette thèse, nous nous sommes intéressés à la représentation, l’analyse et la synthèse des réseaux de signalisation génomique en utilisant la logique des hypothèses. En fait, ce mémoire se focalise sur la modélisation des voies de signalisation en réponse à la cassure double-brin de l’ADN. Pour implémenter l’abduction nous utilisons les algorithmes de production. Ensuite, la logique des défauts permet de construire des modèles de représentation minimale. Ces algorithmes de découvertes de connaissances sont prouvés sur la carte de cassure double brin de l’ADN. Cette carte est minimale en tant que graphe de causalité biologique et elle permet d’intégrer les données biomoléculaires. Mots clés : conclusion conséquente, abduction, champ de production, logique des défauts, raisonnement diagnostique, raisonnement de prédiction, cassure double-brin de l’ADN, voie de signalisation, voie métabolique, représentation, modélisation, connaissances biologiques. iii Abstract Diagnostic reasoning (abductive) and predictive reasoning (inductive) are two methods of reasoning that enable the discovery of new knowledge. When abductive reasoning is the process of finding the best explanation (hypothesis) for a set of observations (Josephson, 1994), the inductive reasoning is the process of predicting, from a set of observations, to find all possible results. These observations may be symptoms of a patient, experiments on genomic and metabolic networks, etc. In this PhD thesis, we are interested in the representation, analysis and synthesis of genomic signaling networks using hypothetical logic. In fact, this thesis focuses on modeling of signaling pathways in response to the DNA double stranded break. To implement the abduction, we use algorithms of production. Then, the default logic is used to build models of minimum representation. These algorithms are proven knowledge discovery on the map of DNA double-strand break. This map is minimal as biological causality graph and allows integrating bio-molecular data. Keywords: consistent conclusion, abduction, field of production, default logic, diagnostic reasoning, predictive reasoning, double-stranded break DNA, signaling pathway, metabolic pathway, representation, modeling, biological knowledge. v Remerciements Le travail présenté dans ce rapport a été réalisé au sein du groupe Diagnostic, Supervision et Conduite (DISCO), du Laboratoire d’Analyse et d’Architecture et des Systèmes (LAAS) du Centre National de la Recherche Scientifique (CNRS). Il a été effectué grâce au support financier du gouvernement vietnamien, et également du LAAS – CNRS, avec le support de la vie du Centre Régional des œuvres Universitaires et Scolaires (CROUS) de Toulouse. Je tiens, en premier lieu, à adresser mes plus sincères remerciements et ma plus profonde reconnaissance à Monsieur Andrei DONCESCU et Monsieur Pierre SIEGEL, pour avoir bien voulu être mes directeurs de thèse, pour leur soutien et pour leur direction souple et sécurisante tout au long de ce travail. Je souhaite exprimer ma plus profonde gratitude à Monsieur Jean ARLAT, Directeur du LAAS – CNRS, pour m’avoir accueilli au sein de laboratoire. Je tiens à exprimer ma sincère gratitude à Messieurs : Jean-Charles FAYE, Directeur de Recherche à l’Institut Claudius Regaud (ICR) Olivier SORDET, Rechercheur à l’Institut Claudius Regaud Barthélémy DWORKIN Henri BONNABAU pour leurs connaissances de la voie de réponse à la cassure double-brin de l'ADN. Finalement, je tiens également à remercier spécialement tous les amis français et vietnamiens que je côtoie pendant mon séjour en France. vii Table des matières Résumé.................................................................................................................................................i Abstract..............................................................................................................................................iii Remerciements.................................................................................................................................... v Table des matières.............................................................................................................................vii Liste des figures...................................................................................................................................ix Liste des tableaux................................................................................................................................xi Introduction......................................................................................................................................... 1 Chapitre 1. Contexte et cas d’application.......................................................................................... 5 1.1. Contexte ........................................................................................................................... 5 1.1.1. Connaissances biologiques ...................................................................................... 5 1.1.2. Inhibiteurs de Chk2 comme nouveaux agents anticancéreux................................. 27 1.1.3. Problématique ........................................................................................................27 1.1.4. Exigences................................................................................................................28 1.2. Cas d’application............................................................................................................28 1.2.1. Contexte des gènes et leurs interactions ................................................................28 1.2.2. Définitions..............................................................................................................31 1.2.3. Règles de comportements.......................................................................................34 Chapitre 2. Conclusion conséquente et la production......................................................................35 2.1. Conclusion conséquente et SOL.....................................................................................35 2.1.1. Conclusion conséquente .........................................................................................35 2.1.2. SOL.........................................................................................................................35 2.2. Production pour l’abduction et l’induction.....................................................................41 2.2.1. Définition................................................................................................................41 2.2.2. Exemple d’utilisation..............................................................................................41 2.3. Champ de production .....................................................................................................42 2.3.1. Définition................................................................................................................42 2.3.2. Exemple d’utilisation..............................................................................................44 2.4. Algorithmes de calcul de production..............................................................................45 2.4.1. Description simplifiée.............................................................................................45 2.4.2. Algorithme avec coupure........................................................................................49 2.4.3. Algorithme en Prolog .............................................................................................52 Chapitre 3. La logique des défauts..................................................................................................55 3.1. Introduction ....................................................................................................................55viii Table des matières 3.2. Notion de défaut.............................................................................................................55 3.3. Syntaxe de la logique des défauts...................................................................................57 3.4. Extensions. .....................................................................................................................58 3.4.1. Extensions - définition formelle..............................................................................58 Chapitre 4. Approche proposée et résultats....................................................................................63 4.1. Utilisation de l’algorithme de production de clauses. ....................................................63 4.2. Utilisation de la logique des défauts...............................................................................70 4.2.1. Dans le cas général ................................................................................................70 4.2.2. Utilisation dans le domaine temporel discret.........................................................77 Conclusion .........................................................................................................................................93 Bibliographie......................................................................................................................................95Liste des figures ix Liste des figures Figure 1.1. Structure d’une cellule animale eucaryote typique .............................................................. 6 Figure 1.2. Structure des nucléotides ..................................................................................................... 7 Figure 1.3. Structure des 22 acides aminés ............................................................................................ 8 Figure 1.4. Mécanismes intracellulaires de régulation de l’apoptose................................................... 12 Figure 1.5. Les étapes du cycle cellulaire : la mitose ........................................................................... 13 Figure 1.6. Les étapes du cycle cellulaire : la méiose .......................................................................... 14 Figure 1.7. Division des chromosomes dans un noyau cellulaire......................................................... 15 Figure 1.8. Les quatre phases du cycle cellulaire avec des chromosomes dans le noyau .................... 15 Figure 1.9. Cycle cellulaire avec des points de contrôle ...................................................................... 16 Figure 1.10. Molécules régulant intervenant dans le cycle cellulaire chez les mammifères................ 18 Figure 1.11. Composants de la voie de signalisation p53 .................................................................... 23 Figure 1.12. Définitions des symboles et des conventions de la carte ................................................. 28 Figure 1.13. La carte d'interaction de la réponse ATM-dépendante de la cassure double-brin............ 29 Figure 2.1 Tableaux résolus pour l’Exemple 2.1.................................................................................. 39 Figure 2.2. La procédure conséquente de recensement SOL................................................................ 40 Figure 2.3. Les étapes d’une production............................................................................................... 42 Figure 3.1. Arbre de recherche des solutions pour le calcul d'extensions............................................ 60 Figure 4.1. Interactions de la carte de Pommier................................................................................... 64 Figure 4.2. Un exemple d’interactions dans une cellule....................................................................... 70 Figure 4.3. Système équilibré de masse ............................................................................................... 77 Figure 4.4. La première relation entre les états de réaction et les changements de concentration de métabolites ............................................................................................................................................ 79 Figure 4.5. La deuxième relation entre les états de réaction et les changements de concentration de métabolites ............................................................................................................................................ 79 Figure 4.6. La troisième relation entre les états de réaction et les changements de concentration de métabolites ............................................................................................................................................ 79 Figure 4.7. Une extension de la carte de Pommier............................................................................... 92 Liste des tableaux xi Liste des tableaux Tableau 1.1. Les codes des 22 acides aminés......................................................................................... 9 Introduction 1 Introduction Une fonction biologique n’est pratiquement jamais le produit d’une seule macromolécule mais plutôt le résultat de l’interaction d’un groupe de macromolécules (gènes, protéines). Comprendre les mécanismes complexes à l’œuvre dans la cellule requiert donc une approche intégrative de la modélisation de toutes les interactions entre les macromolécules. Modéliser, identifier et éventuellement simuler les réseaux d’interactions entre macromolécules qui interviennent à différents niveaux dans la cellule forment les enjeux principaux d’une nouvelle discipline transversale qu’on appelle biologie de systèmes. Les systèmes biologiques changent sans cesse. La reconstruction de réseaux biologiques à partir de données expérimentales constitue un des éléments clefs des objectifs scientifiques en biologie moléculaire: le biologiste s’intéresse souvent à la réponse cellulaire d’un organisme ou d’un certain tissu dans un organe à un signal ou stress donné. Il cherche par exemple à définir ou à compléter le réseau de régulation impliqué dans le contrôle de cette réponse en exploitant des données expérimentales (données d’expression de gènes etc.). L’apprentissage automatique intervient alors comme une des composantes de l’activité de découverte scientifique : à partir des données, à partir d’une classe de modèles de réseaux de régulation, un algorithme d’apprentissage permet de définir une ou plusieurs solutions candidates (graphe d’interaction et paramètres des modèles) que le biologiste peut ensuite tester en générant d’autres expériences pour vérifier telle ou telle particularité du modèle. Pour cela, il est habituel de considérer qu’il y a deux modes de raisonnements, deux façons de progresser dans la connaissance : le raisonnement diagnostique, et le raisonnement de prédiction. Le raisonnement diagnostique (ou abductif) est une partie essentielle d’un grand nombre tâches du monde réel, par exemple le diagnostic médical, le débogage des programmes d’ordinateur, la découverte scientifique, etc. En règle générale, le raisonnement abductif est le processus permettant de trouver la meilleure explication pour un ensemble d’observations (Josephson, 1994). Ces observations peuvent être les symptômes d’un patient, les messages d’erreur d’un programme d’ordinateur, ou les résultats d’une expérience. La tâche de la résolution des problèmes dans chacun de ces domaines est de trouver un ensemble d’hypothèses élémentaires qui explique le mieux ces symptômes. Une autre méthode est tout aussi importante pour la représentation et le traitement des connaissances biologiques, c’est le raisonnement de prédiction par la logique des défauts. Quand un système intelligent essaye de résoudre un problème, il peut être en mesure de s’appuyer sur des informations complètes sur ce problème, et sa tâche principale est de tirer la bonne conclusion par un raisonnement classique. Dans ce cas, la logique des prédicats classique peut être suffisante. Cependant, dans de nombreuses situations, le système a seulement l’information incomplète, parce que certaines informations ne sont pas disponibles, ou bien parce qu’il doit répondre vite et n’a pas de temps de recueillir toutes les données pertinentes. La logique classique a en effet la capacité de représenter et raisonner avec certains aspects de 2 Introduction l’information incomplète. Mais il y a des occasions où l’information supplémentaire doit être remplie pour surmonter l’incomplétude, parce que certaines décisions doivent être prises. Dans ce cas, le système doit faire des conjectures plausibles, qui dans le cas du raisonnement par défaut sont basés sur des règles empiriques, appelé des défauts. Par exemple, un médecin d’urgence doit faire des conjectures sur les causes les plus probables des symptômes observés. Évidemment, il serait inapproprié d’attendre le résultat de tests éventuellement étendus et chronophages avant le début du traitement. Puisque les décisions sont fondées sur des hypothèses, elles peuvent se révéler fausses face à de nouvelles informations qui seront disponibles, à savoir les examens médicaux peuvent conduire à un diagnostic modifié. Le phénomène d’avoir à reprendre certaines conclusions précédentes est appelé non-monotonie, ça veut dire que si une déclaration X découle d’une série de prémisses M, et M est un sous-ensemble de N, X ne découle pas nécessairement de N. La logique des défauts, à l’origine présentée by Reiter [1980], fournit la méthode formelle pour soutenir ce genre de raisonnement. Elle est peut-être la méthode la plus importante pour le raisonnement non-monotone, essentiellement en raison de la simplicité de l’idée d’un défaut, et parce que les défauts prévalent dans de nombreux domaines d’application. Cependant, il existe plusieurs décisions de conceptions alternatives qui ont conduit à des variations de l’idée initiale. En fait, il y a une famille de méthodes de raisonnement par défauts qui partagent les mêmes fondements. Le travail présenté dans ce mémoire se focalise sur le raisonnement par l’abduction et par la logique des défauts pour la modélisation des voies de signalisation en réponse à la cassure double-brin de l’ADN. En fait, on a utilisé les algorithmes de production avec un champ de production pour faire le raisonnement diagnostique sur la carte d’interactions de Pommier. Ensuite, la logique des défauts a été utilisée pour faire le raisonnement de prédiction à partir de la carte. Toutefois, cette méthode ne nous permettait pas de connaitre l’ordre dans lequel se déroulaient les événements. Nous avons alors ajouté une variable temps à la logique des défauts ce qui nous a permis d’obtenir une chronologie des événements. Dans le processus de travail, on se rend compte que les algorithmes ne fonctionnent pas bien avec les variables lorsqu’ils sont implémentés en Prolog, alors on a cherché à résoudre ce problème et nous avons fourni des solutions. Introduction 3 Plan de la thèse Ce document s’organise en quatre chapitres suivants : Le chapitre 1 introduit le contexte applicatif considéré dans le cadre de la thèse, en examinant les notions de gènes, de protéines et de métabolites, ainsi que les règles de base de comportement d’une cellule. Le chapitre 2 présente les bases des outils mathématiques utilisés pour exécuter la synthèse des voies de signalisation. Ce chapitre se concentre sur la conclusion conséquence et la production. Le chapitre 3 détaille la logique des défauts, l’outil est utilisé pour représenter les interactions dans les réseaux de régulation. Le chapitre 4 propose une approche de représentation des connaissances – de la voie de signalisation cellulaire : utilisation de la production pour le raisonnement diagnostique ; et de la logique des défauts pour le raisonnement de prédiction. En conclusion, nous présentons un bilan du travail réalisé et des orientations pour développer le sujet. Contexte et cas d’application 5 Chapitre 1. Contexte et cas d’application Ce chapitre présente le contexte et le cas d’application de la thèse. Tout d’abord, il faut examiner les notions de gènes et leurs interactions dans les réseaux biologiques. 1.1. Contexte Comme nous le savons, la plupart des médicaments anticancéreux qui sont encore actuellement utilisés en clinique ciblent l’ADN. L’action de ces médicaments anticancéreux sur les tissus tumoraux est probablement due au fait qu’ils peuvent supprimer les défauts tumeur-spécifiques des points de contrôle (checkpoint en anglais) du cycle cellulaire et améliorer la réparation de l’ADN, afin d’augmenter la réponse apoptotique des cellules tumorales. Nous nous intéresserons ici à l’interaction moléculaire qui apparaît dans la voie ATM-Chk2. 1.1.1. Connaissances biologiques L’interaction moléculaire implique une liste de notions biologiques qui doivent être clarifiées. D’abord, nous étudierons la notion de cycle cellulaire. Le cycle cellulaire est l’ensemble des phases par lesquelles une cellule passe entre deux divisions successives. Le cycle des cellules eucaryotes est divisé en quatre phases : G1, S, G2 et M. L’ensemble des trois premières phases est souvent appelé l’interphase. Cellule : La cellule est une unité structurale et fonctionnelle de la plupart des organismes. Chaque organisme est structuré d’une ou plusieurs cellules. Des cellules ne sont produites qu’à partir des cellules précédentes. Toutes les fonctions vitales d’un organisme ont lieu dans la cellule. Les cellules contiennent des informations génétiques nécessaires pour diriger leurs fonctions et peuvent transmettre les matériaux génétiques aux générations suivantes. Caractères de la cellule : Chaque cellule est un système ouvert, autonome et autoproductif. La cellule peut recevoir des nutriments, les convertir en énergie, exercer des fonctions spéciales, et produire des nouvelles cellules s’il est nécessaire. Chaque cellule contient un cryptage distinct dirigeant ses actions et a les capacités suivantes : - Reproduction par la division. - Métabolisme cellulaire : Recevoir des matières brutes et les transformer en substances nécessaires pour la cellule, produire les molécules à haute énergie et les sous-produits. Pour exercer leurs fonctions, les cellules ont besoin d’absorber et d’utiliser l’énergie chimique contenue dans les molécules organiques. Cette énergie est libérée dans les voies métaboliques. - Faire la synthèse des protéines. Ce sont des molécules qui assument des fonctions fondamentales de la cellule, par exemple les enzymes. - Répondre aux stimuli ou aux changements d’environnement extérieur tels que les changements de température ou de pH ou des éléments nutritifs.6 Contexte et cas d’application - Déplacer des vésicules. Figure 1.1. Structure d’une cellule animale eucaryote typique (source : wikipedia.org) (1) Nucléole, (2) Noyau, (3) Ribosome, (4) Vésicule, (5) Réticulum endoplasmique rugueux (granuleux), (6) Appareil de Golgi, (7) Microtubule, (8) Réticulum endoplasmique lisse, (9) Mitochondrie, (10) Lysosome, (11) Cytoplasme, (12) Peroxysome, (13) Centrosome Composants d’une cellule : chaque cellule a une membrane plasmique pour l’envelopper, isoler l’intracellulaire de l’extérieur, contrôler strictement le transport des substances, maintenir le potentiel de membrane et la concentration des substances intérieures et extérieures. Chaque cellule contient des molécules d’ADN, matériels génétiques importants et des molécules d’ARN qui participent directement au processus de synthèse des protéines. À l’intérieur de la cellule, dans les temps donnés, la cellule synthétise une grande variété de molécules différentes. - Membrane plasmique : l’enveloppe d’une cellule a la fonction d’encapsulation et de distinction de cellule avec le milieu environnant. La membrane est formée par une double couche de lipides et de protéines. - Cytosquelette : un composant important compliqué et flexible. Il inclut un système de microtubules et de protéines et forme et maintient la forme de la cellule. - Cytoplasme : le cytoplasme désigne le contenu d’une cellule vivante. Il s’agit de la totalité du matériel cellulaire du protoplasme délimité par la membrane plasmique et des organites. - Matériel génétique : ce sont des molécules d’acides nucléides (ADN et ARN). L’information génétique de l’organisme est le code génétique qui prescrit toutes les protéines nécessaires pour toutes les cellules d’un organisme. - Organites : les cellules ont souvent des petits organes appelés des organites, adaptés et différenciés pour une ou plusieurs fonctions vitales. Les organites se trouvent souvent dans les cellules eucaryotes et souvent ont leurs propres membranes. Noyaux : les noyaux sont aussi entourés d’une membrane les isolant du cytoplasme et contiennent des acides nucléiques, ce sont des grandes molécules ayant la structure multimoléculaire, incluant plusieurs molécules de nucléotides. Il existe deux types d’acides nucléiques : l’acide désoxyribonucléique (ADN) et l’acide ribonucléique (ARN). L’ADN Contexte et cas d’application 7 contient l’information génétique lorsque l’ARN est la copie d’ADN, souvent en un seul brin alors que l’ADN a deux brins. Nucléotide : Un nucléotide est une molécule organique. Certains nucléotides forment la base de l’ADN et de l’ARN, d’autres sont des cofacteurs ou coenzymes. Chaque molécule nucléotidique consiste en trois composants, ce sont une base azotée, un sucre et un groupement phosphate (ou acide phosphorique). Figure 1.2. Structure des nucléotides (source : wikipedia.org) - Base azotée : Variable en fonction du type de nucléotide (purine ou pyrimidine) fixé à l’atome de carbone 1' du désoxyribose. Pour l’ADN, il existe quatre nucléotides différents correspondant aux quatre bases azotées différentes, ce sont l’adénine (A), la guanine (G), la cytosine (C), et la thymine (T). Dans l’ARN, la thymine (T) est remplacée par l’uracile (U). - Sucre : Pentose (ou désoxyribose), les acides nucléiques se différencient par la base qui est fixée sur le sucre. - Groupement phosphate (acide phosphorique) : Grâce à la liaison covalente entre l’acide phosphorique d’un nucléotide avec un sucre, des nucléotides se relient et forment une chaîne de poly-nucléotides. Cette liaison suit la règle complémentaire : une grande base est supplée par une petite base. Alors il existe deux types de liaison : le dAMP (adénine) avec le dTMP (thymine) en établissant deux liaisons hydrogènes (A-T), et le dCMP (cytosine) avec le dGMP (guanine) en établissant trois liaisons hydrogènes (G-C). Par exemple : si on a un brin A G G C T A C alors l’autre brin est T C C G A T G ADN : L’acide désoxyribonucléique (ADN) est une molécule, elle est présente dans toutes les cellules vivantes, renferme l'ensemble des informations nécessaires au développement et au fonctionnement d’un organisme. C’est aussi le support de l’hérédité car il est transmis lors de la reproduction, de manière intégrale ou non. Il porte l’information génétique et constitue le génome des êtres vivants. La structure standard de l’ADN est une double-hélice droite, composée de deux brins complémentaires. Chaque brin d’ADN est constitué d’un enchaînement de nucléotides. 8 Contexte et cas d’application La fonction de l’ADN est de préserver et de transmettre des informations sur la structure des tous les types de protéines d’un organisme, de sorte qu’elles définissent les caractères de l’organisme. L’information génétique (l’information de structure des protéines) est codée dans l’ADN. Chaque section (tranche) de molécule ADN qui porte l’information régulant la séquence d’une protéine est appelée gène de structure (cistron). Chaque acide aminé de la molécule de protéine est régulé par trois nucléotides successifs dans l’ADN (codon), c’est le code triplet. La succession de trois nucléotides correspondant à un acide aminé est appelé l’unité de code (codon). Il est facile de voir que le nombre de combinaisons des trois à partir des quatre types de nucléotides est 4 3 = 64. En fait, seulement 61 combinaisons sont utilisées pour coder 22 acides aminés. Il existe certains cas où un acide aminé correspond à plusieurs codons différents (dégénérescence du code génétique). D’autre part, il existe des codons qui ne régulent aucun acide aminé, ils ont juste la tâche de finir la synthèse de chaîne polypeptique. Ce sont UAA, UAG, et UGA. Figure 1.3. Structure des 22 acides aminés (source : wikipedia.org) Un caractère très important de l’ADN est la capacité de réplication (reproduction). Sous l’action d’enzymes, la double hélice de l’ADN est étirée, deux brins se détachent pas à pas. Chaque nucléotide dans chaque brin se combine avec un nucléotide libre suivant la règle (AT, G-C) pour former une nouvelle double hélice, donnant deux molécules enfants. Contexte et cas d’application 9 Tableau 1.1. Les codes des 22 acides aminés Code Abrév Acide aminé Nature Codons Y Tyr Tyrosine Polaire, aromatique UAU, UAC W Trp Tryptophane Apolaire, aromatique UGG (et UGA chez les mycoplasmes) V Val Valine Apolaire, aliphatique GUU, GUC, GUA, GUG U Sec Sélénocystéine Polaire UGA associé à un élément SECIS T Thr Thréonine Polaire ACU, ACC, ACA, ACG S Ser Sérine Polaire UCU, UCC, UCA, UCG, AGU, AGC R Arg Arginine Basique CGU, CGC, CGA, CGG, AGA, AGG Q Gln Glutamine Polaire CAA, CAG P Pro Proline Apolaire CCU, CCC, CCA, CCG O Pyl Pyrrolysine Polaire UAG associé à un élément PYLIS N Asn Asparagine Polaire AAU, AAC M Met Méthionine Apolaire AUG L Leu Leucine Apolaire, aliphatique UUA, UUG, CUU, CUC, CUA, CUG K Lys Lysine Basique AAA, AAG I Ile Isoleucine Apolaire, aliphatique AUU, AUC, AUA H His Histidine Basique, aromatique CAU, CAC G Gly Glycine Apolaire, aliphatique GGU, GGC, GGA, GGG F Phe Phénylalanine Apolaire, aromatique UUU, UUC E Glu Acide glutamique Acide GAA, GAG D Asp Acide aspartique Acide GAU, GAC C Cys Cystéine Polaire UGU, UGC A Ala Alanine Apolaire, aliphatique GCU, GCC, GCA, GCG ARN : l’acide ribonucléique (ARN) est une molécule biologique trouvée pratiquement dans tous les organismes vivants, y compris dans certains virus. L’ARN est une molécule très proche chimiquement de l’ADN. Selon sa fonction, l’ARN est divisée en trois types : ARN messager (ARNm), ARN de transfert (ARNt), et ARN ribosomique (ARNr). - ARNm : l’ARN messager est une chaîne poly nucléotidique copiant exactement un ou parfois plusieurs cistrons d’ADN, mais l’Uracile (U) remplace la Thymine (T). L’ARNm a la tâche de transmettre l’information génétique qui précise la séquence d’acides aminés de la protéine synthétisée. - ARNt : l’ARN de transfert a la tâche de transporter des acides aminés au lieu de synthèse des protéines (le ribosome). L’ARN de transfert a une structure caractéristique en feuille de trèfle, composée de quatre tiges appariées. L’une de ces tiges est terminée par une boucle qui contient l’anticodon, le triplet de nucléotides qui s’apparie au codon lors de la traduction d’un ARNm par le ribosome. À l’autre extrémité, l’ARNt porte l’acide aminé correspondant attaché par une liaison ester à son extrémité 3'-OH. Cette estérification est catalysée par des enzymes spécifiques, les aminoacyl-ARNt synthétases. - ARNr : L’ARN catalytique ou ribozyme constitue les composants du ribosome. 10 Contexte et cas d’application Chromosome : Un chromosome est un élément microscopique constitué de molécules d’ADN et de protéines. Chez les cellules eucaryotes, les chromosomes se trouvent dans le noyau où ils prennent la forme soit d’un bâtonnet, soit d’un écheveau, selon qu’ils sont condensés ou non. Chez les cellules procaryotes (sans noyau), le chromosome se trouve dans le cytoplasme. Le chromosome est l’élément porteur de l’information génétique. Les chromosomes contiennent les gènes et permettent leur distribution égale dans les deux cellules enfants lors de la division cellulaire. Ils sont formés d’une longue molécule d’ADN, associée à des protéines (notamment les histones). Entre deux divisions, la séparation entre les molécules d’ADN différentes (chromosomes) est peu perceptible, l’ensemble porte alors le nom de chromatine. Ils se condensent progressivement au cours de la division cellulaire pour prendre une apparence caractéristique en forme de X à deux bras courts et deux bras longs, reliés par un centromère. Au figuré, le mot chromosome est utilisé pour décrire son contenu en termes d’information génétique. Les chromosomes portent les gènes, supports de l’information génétique transmise des cellules mères aux cellules filles lors de la mitose ou de la méiose (reproduction sexuée). Les chromosomes sont habituellement représentés par paires, en parallèle avec leur homologue. Ils sont souvent illustrés sous leur forme condensée et dupliquée (en métaphase de la mitose). L’ensemble des chromosomes est représenté sur un caryotype, ou carte de chromosomes. Processus de synthèse des protéines : L’ADN régule la séquence des protéines par l’ARNm, donc la synthèse de protéine se compose de deux étapes principales : la transcription et la traduction. - Transcription : C’est le processus de synthèse de l’ARNm. La plupart de l’ARN est synthétisée sur le modèle de l’ADN. Sous l’action des enzymes ARN-polymérases, une section de molécule d’ADN correspondant à un ou plusieurs gènes est étirée, deux brins se détachent. Chaque nucléotide du brin d’origine est relié avec un ribonucléotide libre selon la règle (A-U, G-C), formant une chaîne polyribonucléotidique d’ARN. Après la synthèse, pour la cellule eucaryote, l’ARNm quitte le noyau vers le cytoplasme pour participer au processus de synthèse de protéine. - Traduction : Elle inclut deux étapes principales, activation d’acide aminé et synthèse de polypeptide. Lors de l’étape de synthèse de l’acide aminé, des acides aminés libres dans le cytoplasme sont activés par la liaison avec des composés riches en énergie adénosines triphosphates (ATP) par l’action de certains enzymes. Ensuite, grâce à d’autres enzymes spécifiques, l’acide aminé activé est lié avec l’ARNt correspondante pour former l’acide aminé – ARNt (aa-ARNt). Dans la synthèse du polypeptide, d’abord, l’ARNm se lie avec le ribosome à la place du codon de départ. Ensuite, l’ARNt porte le premier acide aminé vers le ribosome, son codon coïncide avec le code de départ de l’ARNm par la règle (A-U, G-C). aa1-ARNt arrive à la position suivante, son codon coïncide avec le codon du premier acide aminé d’ARNm. Par la Contexte et cas d’application 11 suite, la chaîne forme la structure de degré plus élevé pour former la protéine complète. Par exemple : brin origine ADN T A C G T A C G G A A T A A G brin d’ARNm A U G C A U G C C U U A U U C Décodage Méthionine Histidine Alanine Leucine Phénylalanine Mort cellulaire : La cellule ayant reçu un signal de son environnement va exprimer un programme qui entraîne sa mort (l’apoptose est un de ces mécanismes). Ce phénomène est nécessaire au développement des organismes pluricellulaires ; autant chez les végétaux (avec par exemple la mort des cellules formant le tube criblé), que chez les animaux (lors de la mise en place de la main chez l’homme : On a initialement une main palmée, la mort des cellules permet l’individualisation des doigts). Ce phénomène a aussi été découvert chez certaines bactéries (la mort cellulaire permet de limiter le nombre de bactéries lorsque les ressources sont insuffisantes). La cellule, tant pour les êtres pluricellulaires que pour les unicellulaires, constitue une structure vouée avant tout à permettre la reproduction de l’organisme et donc la transmission d’une structure de base contenant un programme génétique. Ainsi, certains auteurs ont été amenés à formuler la théorie du gène égoïste, considérant les organismes (et donc les cellules) comme de simples structures destinées à assurer la transmission et la prolifération des gènes (le gène proliférant est qualifié d’égoïste). La mort cellulaire peut se faire par nécrose, par autophagie, ou par apoptose. - Mort cellulaire par nécrose : La mort est causée par des dommages physiques ou chimiques. La nécrose est causée par des enzymes spéciales produites par les lysosomes, petites usines à enzymes de la cellule. La cassure de la membrane plasmique qui en résulte conduit à la libération dans le milieu extérieur du contenu cytoplasmique. La nécrose est accompagnée habituellement d’une réponse inflammatoire qui consiste en la présence d’exsudat et de cellules spécialisées du système hématopoïétique comme les lymphocytes et les macrophages. Une nécrose peut également être causée par une ischémie (plus ou moins) longue d’un membre. - Mort cellulaire par autophagie : La dégradation d’une partie du cytoplasme de la cellule par ses propres lysosomes. Le terme ‘autophagie’ (se manger soi-même) regroupe plusieurs voies de dégradation de lysosome des constituants cellulaires, essentielles à l’homéostasie cellulaire. Il existe trois types différents d’autophagies : la micro-autophagie, l’autophagie réalisée par des protéines chaperonnées, et la macroautophagie (c’est le type principal). - Mort cellulaire par apoptose : Ou mort cellulaire programmée, c’est un processus par lequel des cellules déclenchent leur auto-destruction en réponse à un signal. C’est l’une des voies de mort cellulaire, génétiquement programmée, nécessaire à la survie des organismes multicellulaires. Elle est en équilibre constant avec la prolifération cellulaire. Contrairement à la nécrose, l’apoptose ne provoque pas d’inflammation : les membranes plasmiques ne sont pas détruites, du moins dans un premier temps, et la cellule émet des signaux. 12 Contexte et cas d’application Figure 1.4. Mécanismes intracellulaires de régulation de l’apoptose (source : wikipedia.org) Reproduction cellulaire : Comme mentionné ci-dessus, une capacité importante de la cellule est la reproduction (réplication, ou bien duplication) par la division. Ceci est fait pendant un cycle appelé le cycle cellulaire (ou bien cycle de division cellulaire). Avant d’entrer en division cellulaire, une cellule doit accumuler des éléments nutritifs durant l’interphase. L’interphase procède en trois phases : G1, S, et G2. La division cellulaire fonctionne dans un cycle. La première phase dans l’interphase est la phase G1 (phase gap 1, ou post-mitotique phase), c’est une période principale de la croissance cellulaire. Au cours de cette phase, la biosynthèse, qui a été diminuée considérablement pendant la phase M précédente, recommence à haut taux. La cellule se prépare pour le processus de réplication de l’ADN. La cellule intègre les mitogènes, grossit et en fin de G1 la cellule peut se mettre en pause ou quitter le cycle cellulaire. Un point de contrôle important en G1 a été identifié pour toutes les cellules de levure et de mammifère. C’est le moment où la cellule va entrer dans la phase de réplication de l’ADN avant l’achèvement d’un cycle cellulaire. La phase suivante S commence quand la synthèse (réplication) de l’ADN commence. C’est une période au cours de laquelle le matériel chromosomique est doublé par réplication de l'ADN : duplication des chromosomes. Lorsque la phase est complète, tous les chromosomes ont été produits, c’est à dire chaque chromosome a deux chromatides enfants. Ainsi, au cours de la phase, la quantité d’ADN dans la cellule est effectivement doublée, quoique la ploïdie de la cellule ne change pas. Les vitesses de transcription et de synthèse protéiques sont très basses pendant cette phase.Contexte et cas d’application 13 Figure 1.5. Les étapes du cycle cellulaire : la mitose (source : wikipedia.org) Ensuite, la phase G2 est la seconde phase de croissance cellulaire, où la cellule se prépare à se diviser en deux cellules enfants. À l’issue de cette phase, chaque chromosome est parfaitement identique à son homologue sur le plan morphologique et du point de vue des gènes présents, mais chaque gène n’est pas nécessairement identique à son homologue (généralement plusieurs allèles existent).14 Contexte et cas d’application Figure 1.6. Les étapes du cycle cellulaire : la méiose (source : wikipedia.org) Enfin, c’est la phase M. La lettre M représente la mitose. La mitose est un processus dans lequel une cellule eucaryote sépare les chromosomes dans son noyau cellulaire en deux ensembles identiques dans deux noyaux. Il est généralement suivi immédiatement par la cytokinèse, qui divise le noyau, le cytoplasme, les organelles et la membrane cellulaire en deux cellules contenant des parts à peu près égales de ces composants cellulaires. L’ensemble de la mitose et la cytokinèse définissant la phase mitotique (phase M) du cycle cellulaire – la division de cellule parente en deux cellules enfantes, généralement identiques et ressemblent à leur parent. La phase M a été décomposée en plusieurs phases distinctes, successivement connues sous les noms prophase, métaphase, anaphase, télophase, et cytokinèse. Les erreurs dans une mitose peuvent tuer la cellule par l’apoptose ou causer la mutation qui peut mener au cancer.Contexte et cas d’application 15 Figure 1.7. Division des chromosomes dans un noyau cellulaire (source : wikipedia.org) Pendant le cycle cellulaire, il existe une phase supplémentaire G0. C’est une phase de repos où la cellule quitte le cycle et arrête de se diviser. Les cellules non-prolifératives dans les eucaryotes multicellulaires sont en phase G0 de G1 et peuvent rester tranquillement pour longtemps et peut être indéfiniment. La décrépitude de la cellule est un état qui a lieu en réponse au dommage de l’ADN ou à la dégradation de l’ADN qui peuvent faire un descendant cellulaire non-viable. Il est souvent une alternative biochimique à l’autodestruction par apoptose d’une telle cellule endommagée. Figure 1.8. Les quatre phases du cycle cellulaire avec des chromosomes dans le noyau (source : wikipedia.org) Point de contrôle : Un terme très important qui a été rappelé est le point de contrôle. Le point de contrôle est utilisé par la cellule pour contrôler et régler le processus de cycle cellulaire. Les points de contrôle bloquent le processus de cycle cellulaire aux points spécifiques, laissent la vérification de phase nécessaire se faire et permettent de réparer les dommages à l’ADN. En d’autres mots, le point de contrôle traite l’ensemble des signaux 16 Contexte et cas d’application régulateurs reçus par la cellule et décide si elle doit se diviser. La cellule n’a pas pu passer à la phase suivante jusqu’à ce que le point de contrôle ait été passé. Quelques points de contrôle sont désignés pour assurer que les ADN incomplets ou endommagés ne sont pas passés à la cellule enfante. Il existe deux points de contrôle principaux : le point G1/S et le point G2/M. La transition G1/S est un pas dans le cycle cellulaire et est aussi appelé le point de restriction (non-retour). Le point G1/S est le contrôle de l’état de l’ADN. Si c’est bon, il met en route la réplication par l’activation de facteurs inducteurs de la réplication. Par contre, le point G2/M est le contrôle de l’état de l’ADN répliqué et le contrôle de la duplication des centrosomes. Si c’est bon, il met en route la mitose par l’activation de facteurs mitotiques. Figure 1.9. Cycle cellulaire avec des points de contrôle (source : wikipedia.org) Bague extérieure : I – interphase, M – Mitose ; Bague intérieure : M – Mitose, G1 – Gap 1, G2 – Gap 2, S – Synthèse ; Pas dans les bagues : G0 – Gap 0/ Repos Lorsque l'ADN génomique des cellules eucaryotes est endommagé par des processus spontanés, mutagènes chimiques ou l'exposition au soleil, la réplication de l'ADN endommagé déclenche une réponse cellulaire appelée un point de contrôle post-réplication. Cette réponse empêche la progression du cycle cellulaire jusqu'à ce que les processus de la réparation postréplicative soient terminés et puissent contrôler l'activité de ces voies de réparation de l'ADN. Dans les types de cellules qui exécutent la phase S avant la mitose, comme la levure de fission et les cellules humaines, le point de contrôle post-réplicatif prend le temps de réparation en retardant le début de la mitose. Dans les types cellulaires où la mitose et la phase S sont concurrentes, tels que la levure bourgeonnante, les retards aux points de contrôle postréplicatifs sont l'état d'avancement de la mitose à la métaphase. Rôle de complexes cycline-CDK : Les complexes cycline-CDK sont des kinases capables de phosphoryler des protéines substrats. Ils sont constitués des deux sous-unités : la cycline (sous-unité activatrice de la kinase), et le CDK (sous-unité catalytique de la kinase). Les cyclines n’ont pas d’activité catalytique et les CDKs sont inactives en absence d’une Contexte et cas d’application 17 partenaire cycline. Les CDKs effectuent une commune réaction biochimique lorsqu’activées par une cycline liée appelée la phosphorylation ; ceci active ou ralentit les protéines cibles pour orchestrer l’entrée coordonnée à la phase suivante du cycle cellulaire. Des combinaisons cycline-CDK différentes déterminent les protéines ciblées en aval. Les CDKs sont exprimées constitutivement dans les cellules alors que les cyclines sont synthétisées à des étapes spécifiques du cycle, en réponse à divers signaux moléculaires. Lors de la réception d’un signal pro-mitotique extracellulaire, les complexes cycline-CDK de G1 deviennent actifs afin de préparer la cellule pour la phase S, en promouvant l’expression des facteurs de transcription qui à leur tour promeuvent l’expression des cyclines de S et des enzymes nécessaires pour la réplication de l’ADN. Les complexes cycline-CDK de G1 promeuvent également la dégradation des molécules qui fonctionnent comme les inhibiteurs de la phase S en les ciblant pour l’ubiquitination. Une fois qu’une protéine a été ubiquitinilée, elle est dégradée par le protéasome. Les complexes cycline-CDK actifs de S phosphorylent des protéines qui forment des complexes pré-réplications assemblés durant la phase G1 sur les origines de réplication de l’ADN. La phosphorylation sert à deux objets : pour activer chaque complexe pré-réplication déjà-assemblé, et pour prévenir la formation de nouveaux complexes. Ceci assure que chaque portion de génome de la cellule sera reproduite une fois et une seule fois. La raison de prévention de gaps en réplication est claire, parce que les cellules enfants manquant de tout ou partie des gènes essentiels seront mortes. Toutefois, pour les raisons liées aux effets du nombre de copies de gènes, la possession de copies extra de certains gènes est aussi délétère pour les cellules enfants. Les complexes mitotiques cycline-CDK, synthétisés mais inactifs pendant les phases S et G2, promeuvent l’initiation de mitose en stimulant les protéines en aval impliquées dans la condensation des chromosomes et l’assemblage du fuseau mitotique. L’ubiquition ligase fait partie d’un complexe (APC) indispensable à la promotion de l’anaphase. Ce complexe chargé de dégrades les protéines vise également les cyclines mitotiques. La cycline D est la première cycline produite dans le cycle cellulaire, en réponse aux signaux extracellulaires (facteurs de croissance, par exemple). La cycline D se lie à la CDK4 existante, forme le complexe de cycline D-CDK4 actif. Le complexe de cycline D-CDK4 à son tour phosphoryle la protéine du rétinoblastome susceptibilité (Rb). Le Rb hyperphosphorylée se dissocie du complexe E2F/DP1/Rb, ceci active E2F. L’activation d’E2F entraîne la transcription de divers gènes, comme cycline E, cycline A, ADN polymérase, etc… La cycline E ainsi produite se lie à CDK2, ceci forme le complexe de cycline E-CDK2, qui pousse la cellule de phase G1 à la phase S (transition G1/S). La cycline B avec le complexe cdc2 (cdc2 – levures à fission, CDK1 – mammalien) forme le complexe de cycline B-cdc2, qui prend l’initiation de la transition G2/M. L’activation du complexe cycline B-cdc2 cause la rupture de l’enveloppe nucléaire et l’initiation de la prophase. Et par la suite, sa désactivation entraîne la cellule à sortir de la mitose.18 Contexte et cas d’application Figure 1.10. Molécules régulant intervenant dans le cycle cellulaire chez les mammifères (source : wikipedia.org) cdc2 (levures) = CDK1 (mammifères) Il semble qu’un réseau semi-autonome de la transcription agit en concert avec la machinerie cycline-CDK pour régler le cycle cellulaire. Plusieurs études d’expression génique ont identifié environs 800 à 1200 gènes dont l’expression change au cours du cycle cellulaire. Ils sont transcrits à des niveaux élevés à des points spécifiques du cycle cellulaire, et restent à des niveaux faibles dans le reste du cycle cellulaire. Tandis que l’ensemble des gènes identifiés diffère entre les études en raison de méthodes de calcul et des critères utilisés pour les identifier. L’expression de nombreux gènes est modulée par des facteurs de transcription exprimés aussi périodiquement. Les profils d’expression de ces facteurs de transcription sont modulés par les facteurs de transcription exprimés dans la phase précédente, et des modèles informatiques ont montré qu’un réseau CDK-autonome des facteurs de transcription est suffisant pour produire les oscillations dans l’expression de gènes. Rôle dans la formation tumorale : Une déréglementation du cycle cellulaire peut conduire à la formation de tumeur. Certains gènes tels que les inhibiteurs du cycle cellulaire, RB, p53, etc., lorsqu’ils sont mutés, peuvent permettre à la cellule de se multiplier sans contrôle, provoquant alors l’apparition de tumeurs. Bien que la durée du cycle cellulaire dans les cellules tumorales soit égale ou supérieure au cycle cellulaire dans les cellules normales, la proportion des cellules qui se trouvent dans la division cellulaire activée (par rapport à des cellules quiescentes en phase G0) dans les tumeurs est beaucoup plus élevée que dans les tissus normaux. L’ADN des cellules activées au cours du cycle cellulaire est ciblé dans le traitement du cancer car il est relativement exposé pendant la division cellulaire et donc susceptible d’être endommagé par des médicaments (intercalant de l'ADN) ou des radiations. La radiothérapie ou la chimiothérapie en suivant la procédure de réduction tumorale tuent les cellules qui sont récemment entrées dans le cycle cellulaire. En général, les cellules sont plus radiosensibles à la fin de M et de G2, et plus résistantes à la fin de S. Le motif de la résistance Contexte et cas d’application 19 et de la sensibilité est en corrélation avec le niveau de composé de sulfhydrile dans la cellule. Les sulfhydriles sont les radio-protecteurs et tendent à être à leur plus haut niveau en phase S et à leur plus bas près de la phase M. Le cycle cellulaire est contrôlé en plusieurs points de contrôle. Lorsque les cellules subissent un stress extracellulaire ou intracellulaire, ou les deux, ces points de contrôle, spécialement G1/S et G2/M qui sont contrôlés par un nombre de complexes composés des cyclines-CDKs et leurs régulateurs négatifs, incluant la famille Cip/Kip et la famille INK4a/ARF, sont activés. Le point G1/S est la première surveillance du système pour arrêter la synthèse de l’ADN quand les cellules subissent un stress extracellulaire et il est un pas effectif de contrôle de la prolifération et l’apoptose cellulaire. Le point de contrôle G1/S est situé à la fin de phase G1, juste avant la phase S, prend la décision importante de savoir si la cellule doit se diviser, retarder la division ou entrer en phase de repos. De nombreuses cellules s’arrêtent à ce stade et entrant en phase de repos appelée G0. Les cellules du foie, par exemple, n’entrent uniquement en phase M qu’une ou deux fois par an. Réseau de p53 : p53 (aussi appelé protéine 53 ou protéine tumorale 53) joue un rôle important en causant un contrôle mécanique aux deux points de contrôle G1/S et G2/M. La perte de contrôle de stabilité génomique est un élément central dans le développement du cancer, et p53, par la régulation des réponses normales au dommage de l’ADN et autres formes de stress gèno-toxique, est un élément très important dans le maintien de la stabilité génomique. Ainsi, il n’est pas surprenant que la protéine p53 fonctionnelle est perdue dans environ la moitié de tous les cancers humains. Qu’en est-il de l’autre moitié ? Une possibilité est que les mécanismes p53-indépendants de régulation ont été perdus. Une autre possibilité est que l’inactivation des voies p53-indépendantes peut arriver à n’importe lequel de plusieurs points différents et que la p53 elle-même n’est que la cible la plus courante. Par exemple, l’inhibiteur Mdm2 de p53 est surexprimé dans les tumeurs, indépendamment de la mutation de p53. Maintenant, vu les voies de signal qui arrivent à p53, en réponse à différentes formes de stress, et les voies de signal qui sortent de p53, déclenchés par p53 activée, il est clair que la p53 est le composant central d’un réseau complexe de voies de signalisation et que les autres composants de ces voies présentent les cibles alternatives pour l’inactivation. - Signal d’entrée : La quantité de p53 augmente en réponse à une série de signaux, tels que le dommage de l’ADN, l’arrêt de la synthèse de l’ARN ou de l’ADN, ou la déplétion de nucléotides. Les mêmes stimuli activent également la p53, qui est souvent latente en l’absence de stress. Des évidences récentes ont également montré que la protéine Mdm2, qui se lie à p53, accélère la dégradation de p53, éventuellement par la voie d’ubiquitine. Le fait que le gène Mdm2 est une cible traductionnelle de p53 suggère une base moléculaire pour les protéines p53 mutantes. Par conséquent, la stabilité de ces protéines mutantes semble être due à leur incapacité à régler positivement l’expression de Mdm2, une protéine impliquée dans leur dégradation, plutôt qu’une propriété intrinsèque conférée par la résistance à la dégradation.20 Contexte et cas d’application Une augmentation dans la transactivation de p53, sans augmentation dans le niveau de concentration de la protéine, a été trouvée dans les cellules traitées avec des doses basses de radiation d’UV, et la micro-injection d’un anticorps contre le domaine Cterminal stimule également la transcription p53-dépendente, même en l’absence de dommage à l’ADN. Plusieurs processus peuvent être impliqués dans l’activation de p53, ils incluent la phosphorylation, la glycosylation, la liaison aux protéines régulatrices, l’épissage alternatif, et l’acétylation. Comment p53 « sent » les signaux ? Plusieurs protéines connues sont suspectées. La protéine kinase ADN-dépendante (DNAPK), un candidat plausible, se lie à et est activée par les extrémités cassées de l’ADN, elle peut phosphoryler des résidus 15 et 37 de p53 d’une manière ADN-dépendante. La phosphorylation de la serine 15 affecte la transactivation et les fonctions d’arrêt de croissance de p53 dans des cellules. Cependant, les cellules dépourvues de DNAPK ne montrent aucun défaut dans l’inhibition p53-médiée du cycle cellulaire, montrant que si DNAPK a un rôle dans la régulation de p53, d’autres composants doivent être en mesure de compenser sa perte. De nombreuses protéines kinases ont été montrées pour phosphoryler p53 in vitro et sont des candidats pour être des régulateurs en amont. Cependant, très peu de données in vitro existent pour le rôle de la phosphorylation dans la régulation de p53. Les travaux récents qui montrent que p53 peut être acétylée in vitro sont intrigants et suggèrent la possibilité d’un mécanisme supplémentaire de régulation. Toutefois, il est nécessaire de montrer que l’acétylation se produit en réponse à un stress. La poly (ADP-ribose) polymérase (PARP) a longtemps été connue pour avoir un rôle dans la reconnaissance de l’ADN endommagé et dans sa réparation. Les cellules PARP-KO de hamster chinois sont défectueuses dans l’activation de p53 et résistantes à l’apoptose induite par le dommage à l’ADN. Toutefois, des fibroblastes PARP-KO d’embryon des souris ont une réparation normale de l’ADN, et bien qu’il existe une diminution appréciable dans l’induction de p53 après le dommage de l’ADN ou la déplétion de nucléotide, il n’y a pas de changement dans l’activité de p53 dans les réponses cellulaires au stress. Par conséquent, bien que PARP soit impliquée dans l’augmentation de la quantité de p53 dans les fibroblastes de souris, d’autres voies de signalisation doivent être plus importantes dans l’activation de p53 en réponse aux dommages de l’ADN. La perte de l’ATM, le produit du gène de l’ataxie télangiectasie, ralentit l’induction de p53 en réponse à des ruptures de brins d’ADN causées par γ- radiation, mais pas en réponse à des dimères de pyrimidine causées par radiation d’UV. De même, p53 est induite normalement dans les cellules ATM-KO humaines après traitement avec N-(phosphonacétyl)-L-aspartate (PALA), qui bloque la biosynthèse de novo UMP, ou l’adriamycine, qui endommage l’ADN. La p53 et l’ATM peuvent à la fois être des composants de complexes qui fonctionnent dans la recombinaison. De même, le produit du gène impliqué dans le syndrome de la rupture de Nimègue (NBS) a également été placé en amont de p53 dans la voie qui répond aux rayonnements ionisants mais pas dans les réponses à d’autres agents endommageant l’ADN. Parce que les défauts dans l’induction de p53 dans les cellules ATM-KO sont Contexte et cas d’application 21 partiels ou sélectifs pour certains types de dommages de l’ADN, ces produits de gènes sont impliqués dans certains mais pas tous les signaux. Des knockouts doublés ou triplés doivent avoir un défaut plus profond dans l’induction de p53 en réponse aux dommages de l’ADN. Les défauts partiels similaires dans la signalisation de p53 ont été observés dans le syndrome de l’anémie de Fanconi (FAS) et le syndrome de Bloom (BLS) des fibroblastes, ceci suggère que de nombreuses voies régulent p53. Récemment un rôle pour l'oncogène Ras et la voie des MAP kinases a été démontré dans la modulation et le fonctionnement de p53 dans les cellules humaines et de rongeurs. L’expression élevée de Ras ou l’activation de la voie de Mos/MAPK induit des niveaux de p53 de type sauvage et cause un arrêt de la croissance permanente, semblable à la sénescence cellulaire. Les cellules dépourvues de p53 peuvent tolérer des niveaux élevés de MAPK et affichent beaucoup d’arrêts p53-dépendants du cycle cellulaire et d’instabilité génomique. Dans une lignée de cellules défectueuses dans la voie des MAP kinases et dans l’expression de p53, une expression accrue de la MAP kinase, ERK2 restaure les niveaux normaux de p53, ce qui montre clairement que ERK2 est dans une voie qui régule le niveau d'expression de p53. Cette MAPK a été montrée pour phosphoryler les résidus 73 ou 83 de p53 in vitro, et cette phosphorylation peut être importante dans la stabilisation de la protéine. D’autres kinases, comme DNAPK II, cycline A-Cdc2, et cycline B-Cdc2, sont connues pour phosphoryler la protéine p53 in vitro et peuvent jouer un rôle dans la stabilisation de p53. Les mécanismes de l’induction de p53 en réponse aux types différents de stress sont encore largement méconnus. - Signalisation post p53 : p53 est impliquée dans plusieurs aspects différents de l’arrêt du cycle cellulaire, l’apoptose, contrôle de l’intégrité du génome, et la réparation de l’ADN. Comment p53 régule de nombreux processus différents ? p53 est un tétramère qui peut se lier à des séquences spécifiques de l'ADN et donc transactiver de nombreux gènes. Plusieurs travaux ont montré que la p53 active est associée différemment sur les promoteurs, ceci entraîne la liaison et la transactivation différentielles de l’ADN. La p53 peut également inhiber l’expression de certains gènes. En outre, certains phénotypes p53-dépendents ne comportent pas de régulation de la transcription du tout. - Contrôles du cycle cellulaire : La transition G1/S – Les anticorps, qui reconnaissent l’extrémité terminale C de p53, empêchent des fibroblastes stimulés d’entrer dans la phase S. Ce résultat, à l’origine interprété comme une preuve qu’une fonction positive de p53 a été nécessaire, pose un paradoxe quand la surexpression de la p53 typesauvage a été trouvée causant un arrêt de la croissance. Le paradoxe a été résolu quand on a constaté que ces anticorps inhibent plutôt que d’activer p53. Il est maintenant mieux compris que p53 est le médiateur pour l’arrêt en G1 en réponse aux dommages de l’ADN causés par les UV ou la γ-radiation, les médicaments chimio-thérapeutiques ou la privation de nucléotides. La variabilité de type cellulaire dans l’arrêt p53- dépendant en G1 est illustré par les études avec la γ-radiation, ce qui dans les fibroblastes diploïdes normaux provoque un arrêt long-terme p53-dépendant associé à l’induction prolongée de p21/Waf1. L’irréversibilité de cet arrêt dépend de 22 Contexte et cas d’application l’incapacité de ces cellules à réparer même un petit nombre de cassures double-brin de l’ADN, de sorte que le signal d’activation persiste. En revanche, la γ-irradiation de cellules HT1080, issues d’un fibrosarcome avec la p53 type-sauvage, provoque un arrêt en G1 transitoire, tandis que la lignée tumorale colorectale RKO et la lignée tumorale mammaire MCF7, qui ont également une p53 type-sauvage, ne parviennent pas à arrêter en G1 après l’irradiation. Ces différences peuvent indiquer que la formation tumorale peut impliquer l’inactivation des composants en amont ou en aval de p53, ce qui provoque un échec de la réponse cellulaire aux dommages à l’ADN. Par exemple, la γ-irradiation active p53 pour activer la transcription de p21/Waf1, qui se lie à et inhibe les kinases cycline-dépendantes, provoque une hypo-phosphorylation de Rb, empêchant ainsi la libération de E2F et bloque la transition G1/S. La modification d’un de ces composants en aval peut avoir un effet similaire à celui de l’inactivation de p53 lui-même dans la prévention de la voie de signalisation. La p53 fuseau est impliquée dans un point de contrôle qui empêche la réplication de l’ADN lorsque le fuseau mitotique a été endommagé. Lorsque le contenu de l’ADN des fibroblastes d’embryons a été mesuré après le traitement avec du nocodazole ou autres inhibiteurs de l’assemblage des microtubules, il a été constaté que les fibroblastes normaux ont un contenu 4 N de l’ADN, tandis que les fibroblastes p53- KO atteignent des contenues de l’ADN de 8 ou 16 N. La destruction du fuseau peut bloquer la progression en mitose, ou la réplication peut être contrôlée en bloquant l’entrée à la phase S. Dans la lignée cellulaire murine avec p53 type-sauvage, la nocodazole cause un arrêt mitotique transitoire, à la suite de l’entrée en G1 sans ségrégation des chromosomes. Après la mitose, p53 est induit. La conclusion selon laquelle p53 induite en réponse aux dommages du fuseau bloque l’entrée à la phase S a été obtenue par l’analyse de la synthèse de l’ADN dans les fibroblastes exposées au nocodazole ou à la colcémide. Il est intéressant de noter que, les fibroblastes des p21/Waf1-KO de souris ne reproduisent pas leur ADN lorsqu’ils sont traités avec des poisons du fuseau. Par conséquent, p53 doit également utiliser le mécanisme p21-indépendent pour arrêter les cellules en G1 et donc inhiber la réplication en réponse à des poisons du fuseau. L’homéostasie du centrosome – Les fibroblastes p53-KO d’embryon de souris acquièrent plus de deux centrosomes, conduisant à la mitose avec plus de deux pôles du fuseau. p53 est associée aux centrosomes et donc peut affecter directement la duplication des centrosomes. Comme alternatif, la duplication impropre des centrosomes peut induire l’activation de p53, ceci peut à son tour causer l’arrêt dans G2 ou G1. Il est curieux que les MAP kinases et Cdc2, capables de phosphoryler p53, sont également liées aux centrosomes, et, comme p53, la MAP kinase est importante pour l’homéostasie de centrosomes [25]. Contexte et cas d’application 23 Figure 1.11. Composants de la voie de signalisation p53 (source : Munna et all 1998 [25]) p53 s’accumule et est modifiée et activée en réponse aux signaux générés par une variété de stresses génotoxiques. Plusieurs protéines, incluant ATM, PARP, FAS, BLS, et NBS sont impliquées dans l’activation, mais les voies qui conduisent à la modification sont largement inconnues. La voie RAS-MAP kinase est impliquée dans les niveaux de base de p53 et peut également affecter sa fonction. Certaines des fonctions cellulaires affectées par p53 peuvent être compromises par l’expression dérégulée de Myc, Bcl2, E1B, ou E2F. Le contrôle de l’activité de p53 comprend une boucle autorégulatrice liée à Mdm2. L’ensemble des voies p53-dépendentes aident à maintenir l’intégrité génomique par l’élimination des cellules endommagées, soit en les arrêtant de façon permanente ou par apoptose. p53 aide également à régler l’entrée en mitose, la formation du fuseau, et l’intégrité centrosome. - Régulation de l’apoptose : p53 joue un rôle dans le déclenchement de l’apoptose dans certains types cellulaires, par exemple pour les cellules d’origine hématopoïétique. Les stimuli tels que les dommages à l’ADN, le retrait des facteurs de croissance, et l’expression de Myc ou E1A peuvent également causer l’apoptose p53-dépendente. La p53 doit être capable de fonctionner comme un facteur de transcription pour bloquer la transition G1/S, mais l’apoptose ne requiert pas nécessairement l’activation de la transcription, car l’inhibition de la transcription par l’actinomycine D ou de la traduction par la cycloheximide n’affectent pas toujours l’apoptose p53-dépendente. En outre, les inhibiteurs de phosphatase induisent l’apoptose p53-dépendente en l’absence de transactivation. Cependant, les protéines pré-apoptotiques Bax et Igf-Bp3 sont des cibles de la transcription activée par p53, ceci suggère que la transactivation par p53 est importante dans l’induction de l’apoptose dans certaines circonstances. En outre, les anti-apoptotiques Bcl2 et la protéine adénovirus 19-kDa E1B peuvent prévenir l’apoptose p53-médiée. En réponse à un même stimulus p53 induit une apoptose dans certains types de cellules, mais un arrêt du cycle cellulaire dans les Hausse de quantité ou d’activité de p53 E2F RB Arrêt de G1 MYC Stimuli Instabilité génomique Apoptose Voie de kinases RAS/MAP Inhibition de mitose checkpoint du fuseau centrosome duplication BAX BCL2 ou E1B PARP, ATM, NBS, BLS, FAS, Modificateurs biochimiques p21 MDM2 CDK4 Cycline D + E2F Progression de phase S P RB24 Contexte et cas d’application autres. Plusieurs variables, telles que l’ampleur des dommages à l’ADN et les niveaux de p53, affectent également le choix entre l’arrêt du cycle cellulaire et l’apoptose. Également, le dialogue entre les voies de p53 et de Rb peut être important dans la détermination de ces réponses biologiques aux dommages à l’ADN. Par exemple, l’inactivation de Rb cause la perte de l’arrêt en G1 et l’induction de l’apoptose après dommages à l’ADN. Ceci peut être expliqué par la libération de E2F, qui, lorsqu’il est surexprimé à lui seul peut induire l’apoptose. Par ailleurs, la surexpression de Rb bloque l’apoptose p53-médiée. - Stabilité génomique : Le contrôle p53-dépendant du cycle cellulaire maintient l’intégrité génétique dans la population des cellules. L’amplification du gène est un modèle utilisé largement pour étudier l’intégrité génétique. Dans la plupart des cellules transformées ou immortalisées, des médicaments tels que PALA ou méthotrexate inhibent la synthèse de précurseurs nucléotidiques. La fonction de p53 est fréquemment perdue au cours du processus de tumorigenèse et dans l’immortalisation spontanée des cellules primaires, ceci indique que p53 peut être le facteur principal déterminant la permissivité pour l’amplification génique. En effet, les fibroblastes d’embryons de souris p53-KO sont permissives pour l’amplification génique, et des cellules humaines primaires de patients de Li-Fraumeni sont devenues permissives dès qu’elles ont perdu leur seul exemplaire de p53 de type sauvage. Quel signal est généré en tant que partie du mécanisme de l’amplification génique qui pourrait activer les voies p53-dépendantes et prévenir la propagation de cellules résistantes aux médicaments? Le modèle actuel de l’amplification implique, dans une première étape essentielle, de multiples cycles pont-cassé-fusions dans lesquels l’ADN cassé est formé tout au long d’une lignée entière des cellules enfants. L'importance des lésions de l'ADN dans la régulation des stades précoces de l'amplification génique a été démontrée avec des cellules REF52 transfectées avec un mutant de grand antigène T de SV40 sensible à la température. Lorsque ces cellules sont choisies avec PALA à la température basse, l’antigène T inactive p53, ceci rend les cellules permissives pour l’amplification génique. La restauration de p53 en inactivant l’antigène T à une température plus élevée très tôt dans le processus de formation des colonies PALA-résistantes arrête stablement toutes les cellules contenant l’ADN nouvellement amplifié. Des lignées cellulaires humaines peuvent acquérir une résistance à PALA par des mécanismes autres que l’amplification génique in situ, qui est de loin le mécanisme le plus commun dans les cellules de rongeurs. La plupart des colonies PALA-résistantes, provenant de plusieurs lignées cellulaires humaines, ne contiennent pas d’ADN. Cependant, dans les deux cas, les voies p53-dépendantes sont toujours impliquées. L’épuisement des nucléotides pyrimidiques causés par PALA génère un signal pour l’induction de p53 avant que tout endommagement de l’ADN ne se produise, en arrêtant les cellules et inhibant la formation des colonies PALA-résistantes. Réseau de Chk2 : Pommier et al ont montré le rôle de Chk2 (et de Chk1 aussi) dans les cellules. Les agents ciblant l’ADN ont été utilisés dans la chimiothérapie du cancer, et peuvent guérir les patients atteints de leucémies, lymphomes, et cancers des testicules. Dans de nombreux autres cancers, les réponses à ces thérapies sont limitées et la rechute est Contexte et cas d’application 25 courante. Une approche consiste à rechercher les déterminants moléculaires de réponse tumorale et à extraire les paramètres moléculaires à utiliser pour prédire la réponse tumorale. Les paramètres moléculaires comprennent le point de contrôle du cycle cellulaire, les voies de la réparation de l’ADN et de l’apoptose. Les points de contrôle cellulaires sont des voies moléculaires, qui sont activées en réponse aux dommages à l’ADN. L’Activation des points de contrôle peut tuer les cellules endommagées par apoptose ou arrêter la progression du cycle cellulaire pour réparer l’ADN avant la reproduction/division cellulaire. Deux voies bien connues sont les voies ATM-Chk2 et ATR-Chk1. La voie ATM-Chk2 est principalement activée par la cassure double-brin de l’ADN (DSB) produite par les rayonnements ionisants (IR) ou les agents endommageant de l’ADN tels que la bléomycine et la camptotécine. La voie ATR-Chk1 apparaît dans le cas de la DSB réplication-médiée, à côté de la voie ATM-Chk2. Les deux voies ATM-Chk2 et ATRChk1 semblent fonctionner comme des cascades de transduction parallèles des dommages à l’ADN. Il existe cependant un dialogue entre les deux voies, ATM peut également phosphoryler Chk1 en réponse à IR, et ATR peut phosphoryler Chk2 en réponse aux dommages réplication-associés. ATM et ATR appartiennent à la famille des kinases phosphatidylinositol-3 (PI3K), qui contient également la kinase ADN-dépendante (DNA-PK) et ATX. La fonction des PI3K est de former des grands complexes multi-protéiques dans le voisinage des dommages à l’ADN. L’Activation de la famille PI3K conduit à la phosphorylation/activation directe des effecteurs du point de contrôle (Cdc25A et Cdc25C, p53, BRCA1), et indirectement par la phosphorylation/activation des kinases Chk1 et Chk2, qui, à leur tour, phosphorylent les effecteurs du point de contrôle. Les Chk1 et Chk2 ont des rôles redondants partiellement pour l’arrêt/point de contrôle du cycle cellulaire, la réparation de l’ADN, et la transcription de l’ADN, car elles partagent une gamme de substrats, incluant p53, Cdc25A et Cdc25C. Pour la Chk2 humaine, le domaine SQ/TQ est dans la partie NTerminale, et plus spécialement, T68 est une cible de PI3K’s. La phosphorylation de T68 est une condition préalable pour l’autophosphorylation ultérieure sur T383 et T387, et l’activation de Chk2. Le domaine FHA fonctionne comme des sites de liaison pour les protéines phospho-thréonines (pT)-contenant, y compris les substrats de Chk2 aussi bien que Chk2 T68-phosphorylée. Le domaine de kinase catalytique (résidu 226-486) contient une boucle de l’activation autour de l’autophosphorylation/activation de résidus T383/387. Deux mutations, D347A ou D368N induisent une Chk2 kinase-morte. Le signal nucléaire de localisation (NLS) de Chk2 se trouve vers le C-Terminus. La phosphorylation de la Sérine 516 est impliquée dans l’apoptose en réponse aux dommages de l’ADN (DSB). Ainsi, DSB active Chk2, qui à son tour phosphoryle les substrats dont la phosphorylation réglemente des points de contrôle, qui soit tuent les cellules par l’apoptose ou arrêtent le cycle cellulaire et améliorent la survie cellulaire en laissant du temps pour la réparation. - Activation de Chk2 par les dommages à l’ADN : En réponse aux DSB, Chk2 est phosphorylée par ATM (et ATR aussi) et DNA-PK, qui à son tour active Chk2 soit directement par phosphorylation de T68, soit indirectement lorsque ATM phosphoryle/active la Plk3. La phosphorylation de T68 est une condition préalable pour l’activation de Chk2. Elle est essentielle pour la dimérisation (une T68 phosphorylée d’une Chk2 fait l’interaction avec le domaine FHA d’autre), qui autorise 26 Contexte et cas d’application la trans-phosphorylation intermoléculaire de Chk2 sur T383/387 dans la boucle d’activation du domaine kinase et la cis-phosphorylation sur S516. La phosphorylation est nécessaire à l’activation complète de Chk2 vers ses substrats hétérologues. Le domaine FHA de Chk2 est essentiel pour que la mutation I157T diminue dans la dimérisation et l’activation de Chk2. La phosphorylation ATMdépendante ne peut pas arriver librement dans le nucléoplasme, mais nécessite des complexes de protéines adaptatrices spécifiques DSB-associées contenant des motifs BRTC. Ainsi, la phosphorylation ATM-dépendante de Chk2 nécessite Nbs1 intacte, Brca1, la réparation fonctionnelle de mésappariement, et est stimulée par la liaison à la protéine liée, 53BP1. Aussi, la protéine partenaire Chk2-liée MDC1 est nécessaire pour les réponses Chk2-médiées aux dommages de l’ADN. MDC1, comme Chk2, contient un domaine FHA, et est phosphorylée d’une manière ATM/Chk2-dépendante. La suppression de l’induction de MDC1 entraîne la défection du point de contrôle de phase S. MDC1 est trouvée sur les sites de cassures de l’ADN, et associée à Chk2 T68-phosphorylée après dommages à l’ADN. Chk2 active ses cibles en aval, dont sept sont actuellement connues. Trois sont impliquées dans l’apoptose : PML, p53 et E2F1. Deux sont impliquées dans l’arrêt au point de contrôle du cycle cellulaire : Cdc25A et Cdc25C. Brca1 règle probablement la structure de la chromatine, l’induction de la réparation de l’ADN. La cible de Chk2 la plus récemment identifiée est la phosphatase-2A (PP2A), qui à son tour peut inactiver Chk2 par la déphosphorylation de T68. - Cibles en aval de Chk2 impliquées dans l’apoptose : Chk2 peut régler l’apoptose par phosphorylation de PML. Les polymères PML sont normalement concentrés dans les corps nucléaires qui contiennent au moins 30 protéines différentes impliquées dans la réparation de l’ADN, le point de contrôle du cycle cellulaire, la dégradation de protéine et l’apoptose telles que p53, Nbs1, BLM, pRb, Dax. La deuxième cible de Chk2 impliquée directement dans l’apoptose est p53. Chk2 phosphoryle p53 sur la S20, la phosphorylation active p53 par prévention de la liaison de Mdm2 à p53, et donc la dégradation Mdm2-médiée de p53. Chk2 peut également induire l’activité de transcription de p53 par dissociation de Mdm2 à p53. La liaison de Chk2 à 53BP1 (un régulateur de transcription de p53), peut également contribuer à l’activation de la transcription de p53. Chk1 et Jnk peuvent également phosphoryler p53, ce qui explique que le knockout de Chk2 ne prévient pas la phosphorylation IR-inductive de p53 sur S20. Chk2 phosphoryle aussi E2F1. Un ensemble des gènes impliqués dans l’apoptose sont transactivés par la sur-induction d’E2F1, sont inclus INK4a/ARF, p73, Apaf-1, Noxa at PUMA. La phosphorylation d’E2F1 sur S364 par Chk2 augmente sa demi-vie en bloquant sa dégradation, qui améliore l’activité de transcription d’E2F1. E2F1 est également phosphorylée sur S31 et activée directement par ATM (et ATR) en réponse aux dommages de l’ADN. Les dommages à l’ADN peuvent diriger E2F1 sur ses gènes cibles apoptotiques. - Cibles en aval de Chk2 impliquées dans l’arrêt du cycle cellulaire : Chk2 peut inactiver les kinases cycline-dépendantes et induire l’arrêt du cycle cellulaire par phosphorylation et donc inactivation de Cdc25A et Cdc25C, deux des trois kinases de Cdc25. La phosphorylation de Cdc25A induit sa dégradation, et bloque les cellules à Contexte et cas d’application 27 la frontière G1/S. Les deux Chk1 et Chk2 peuvent effectivement phosphoryler Cdc25A sur S123. La phosphorylation qui en résulte conduit à l’ubiquitination et la dégradation rapide de Cdc25A par le protéasome. La phosphorylation Chk2-médiée de Cdc25C sur S216 inactive Cdc25C par induction de sa liaison à la protéine 14-3-3 et son exportation nucléaire. Donc, l’inactivation de Cdc25C prévient l’activation de Cdk1/cycline A et Cdk1/cycline B, et donc induit l’arrêt G2/M. La phosphorylation/l’activation de p53 peut également fonctionner comme une réponse d’arrêt du cycle cellulaire G1 retardée par induction de la transcription de p21 et de Gadd45. - Rôle possible de Chk2 en réparation de l’ADN : Aucun rôle direct de Chk2 en réparation de l’ADN a encore été montré. Cependant, il y a des preuves de relier l’hyper-phosphorylation Chk2-médiée de BRCA1 au processus qui règle la réparation de DSB. BRCA1 est un gène vital de suppresseur tumoral dont l’inactivation augmente le risque de cancer du sein et de l’ovaire. Les cellules déficientes en BRCA1 présentent une hypersensibilité aux agents d’IR et d’ADN-réticulation. La phosphorylation de BRCA1 induit la dissociation de BRCA1 de Chk2, une situation appelée interaction Chk2/PML. BRCA1 libre pourrait alors fonctionner en réparation de l’ADN et en régulation de la transcription. L’évidence récente suggère que l’inhibition de la phosphorylation Chk2-médiée via la mutation de S988 sur BRCA1 prévienne la régulation positive BRCA1-dépendante de la recombinaison homologue (HR) et la régulation négative d’end-jonction non-homologue (NHEJ). En vertu de la phosphorylation de p53, Chk2 est potentiellement capable de régler un certain nombre d’événements en aval qui sont réglementés par l’activité transcriptionnelle de p53 et impliqués en réparation. Une preuve supplémentaire que Chk2 pourrait fonctionner en réparation de l’ADN provient de l’interaction de Chk2 avec Msh2, qui est impliquée dans la réparation de décalage, et avec Mus81 qui est impliquée dans la réparation de DSB. - Autres substrats potentiels de Chk2 : Deux substrats potentiels supplémentaires de Chk2 sont la Phospho-kinase-3 (Plk3) et Mdm2. Plk3 forme une boucle d’activation positive avec Chk2, les deux kinases s’activent l’une l’autre. Par ailleurs, elles sont toutes les deux activées par ATM, et elles phosphorylent Cdc25C et p53. La phosphorylation de Mdm2 soit par Chk2, soit par Chk1 pourrait activer p53 en inactivant l’interaction p53-Mdm2, qui fonctionne comme un antagoniste de p53. 1.1.2. Inhibiteurs de Chk2 comme nouveaux agents anticancéreux Pommier et al ont trouvé que l’inhibition de l’activité de p53 a amélioré la réponse apoptotique des cellules p53-défectueuses à l’IR. Ainsi, il semble rationnel de proposer l’utilisation des inhibiteurs de Chk2 pour les tumeurs p53-déficients. 1.1.3. Problématique La régulation du cycle cellulaire est un processus décidant de la survie d’une cellule, contenant la détection et la réparation de dommage génétique ainsi que la prévention de la division cellulaire incontrôlée. Les événements moléculaires contrôlant le cycle cellulaire sont 28 Contexte et cas d’application ordonnés et directionnels. C’est à dire, chaque processus se déroule de manière séquentielle et il est impossible d’inverser le cycle. Deux classes principales de molécules, cyclines et kinases cycline-dépendantes (CDKs), déterminent un progrès cellulaire dans le cycle. Un grand nombre de gènes codant pour les cyclines et CDKs sont conservés chez tous les eucaryotes, mais en général, les organismes plus complexes ont des systèmes de contrôle du cycle cellulaire plus élaborés qui intègrent des composants individuels. 1.1.4. Exigences De nombreuses études se sont penchées sur la construction des réseaux de gènes grâce à des méthodes mathématiques ou logiques (Tomshine & Kaznessis, 2006 ; Brun et al, 2004). Le logiciel SOLAR [14] est un logiciel développé au Japon (Nabeshima et al, 2003), utilisant de la programmation logique et employé pour effectuer de la conséquence finding, c'est à dire trouver des conséquences logiques à partir d'un jeu de données. La logique basée sur l'abduction fait de ce logiciel un outil de choix pour une telle étude. D'autre part, c'est aussi et surtout parce que Katsumi Inoue a participé à son élaboration que le projet lui donne un rôle prépondérant. SOLAR a déjà été utilisé en biologie des systèmes, notamment sur p53 (Inoue et al, 2010), mais les résultats n'étaient pas aussi probants qu'on aurait pu espérer : un des objectifs de travail devait alors inclure une meilleure rigueur dans les données afin d'obtenir des résultats biologiquement significatifs. 1.2. Cas d’application 1.2.1. Contexte des gènes et leurs interactions Le modèle biologique adopté a suivi celui indiqué dans la carte de Pommier [24], et a été complété par des informations trouvées dans la littérature. Dans la carte, les symboles et conventions sont définis ci-dessous Figure 1.12. Définitions des symboles et des conventions de la carte Couleurs : Noir – interaction de liaison ; bleu – modification de protéine ; vert – processus enzymatiques ou autres stimulants ; rouge – inhibitions ou autres effets négatifs ; pourpre – activation de transcription ou répression.Contexte et cas d’application 29 Symboles : (a) Protéines A et B peuvent se lier, le nœud représente le complexe A:B ; (b) Complexes multimoléculaires ; (c) Modification covalente de A ; (d) Dégradation de A ; (e) Stimulation enzymatique en transcription ; (f) Stimulation enzymatique en trans; plus spécifiquement autophosphorylation en trans ; (g) Symbole général de stimulation; (h) Une barre derrière la tête de flèche signifie la nécessité ; (i) Symbole général d’inhibition ; (j) Symbole de raccourci pour l'activation de transcription ; (k) Symbole de raccourci pour l'inhibition de transcription Figure 1.13. La carte d'interaction de la réponse ATM-dépendante de la cassure double-brin (source : Pommier et al, 2005[24]) Explication de la carte : #1.D4 : Chk2 est activé suite à la phosphorylation par ATM en réponse à DSB (en anglais : double-strand break) et la réplication blocus menant à DSB de réplication-associée30 Contexte et cas d’application #2.D4 : ATR phosphoryle et active Chk2 en réponse à UV (ultraviolet) et réplication des blocs mais pas IR (en anglais : ionizing radiation). Ainsi, Chk2 peut être activé par des voies ATM indépendants #3.D5 : Chk2 est activé par homodimérisation et phosphorylé par des kinases PI3 #4.D4 : Nbs1 est nécessaire pour la phosphorylation ATM-dépendante et l’activation de Chk2. #5.C4 : Chaque molécule Nbs1 recrute un dimère de Mre11 et Rad50 aux foyers DSB, où le complexe nucléase Mre11-Rad50 répare le DSB #6.B4: Nbs1 est phosphorylée au S343 par ATM #7.B3: H2AX est phosphorylée au S139 (γH2AX) par ATM en réponse à DSB et par ATR et DNA-PK en réponse à la réplication-médiation DSB #8.D3: MDC1 forment les foyers nucléaires avec γ-H2AX et Chk2 T68-phosphorylée en réponse à l'IR. #9.D3: 53BP1, une autre protéine BRCT-contenant, améliore également la phosphorylation à T68 de Chk2 #10.C2: BRCA1 est phosphorylée par ATM sur plusieurs sites #11.D1: ATM phosphoryle CtIP sur S664 et S745, inhibant ainsi la liaison de CtIP à BRCA1 #12.C1: BRCA1 se lie à Rad50 en réponse à DSB et co-localise avec les foyers Mre11- Rad50-Nbs1 suivante l’IR #13.E4: Polo kinase 3 (PLK3), qui, comme Chk2, est présente pendant tout le cycle cellulaire, est phosphorylée et activée dans les minutes suivant IR et MMS de manière ATMdépendante #14.D3: Kinase Polo-like (Plk1) phosphoryle Chk2 (à T68), co-IP avec Chk2, et colocalise avec Chk2 à centrosomes #15.F4: Chk2 phosphoryle p53 sur T18 et S20, ceci empêche la liaison de p53-Mdm2 et de la dégradation de p53 #16.E5: Chk2 phosphoryle PML sur S117, qui se dissocie PML de Chk2 et active l'apoptose PML-médiation #17.F6: Chk2 phosphoryle E2F1 dans les cellules traitées avec de l'étoposide #18.C2: Chk2 phosphoryle BRCA1 au S988 #19.F2: La phosphorylation de Cdc25A par Chk2 et ATM au S123 induire la destruction de Cdc25A Contexte et cas d’application 31 #20.G2: La phosphorylation de Cdc25C par Chk2 et p38 MAPK inactive Cdc25C #21.D1: ATM est requis pour l'activation de p38-gamma, ce qui conduit à l'activation de Chk2, et est suffisante pour activer un arrêt G2-M en réponse à IR #22.E1: Jnk est activé par UV, et peut activer Cdc25C et inactiver p53 par la phosphorylation S20 #23.C5: La phosphorylation de FANCD2 en réponse à l'IR au S222 est ATM-dépendante (directe ou indirecte ne sait pas) et nécessite la phosphorylation au S343 de Nbs1 #24.D6: Mus81 se lie spécifiquement au domaine FHA de Chk2 et de Mus81 #25.D6: Msh2 lie à Chk2, et MLH1 lie à l'ATM #26.E6: La protéine phosphatase 2A (PP2A) se lie à Chk2 et déphosphoryle T68, inactivant ainsi Chk2 1.2.2. Définitions Quelques définitions sont données sur le langage de programmation utilisé dans la thèse : Prolog et logiciel SWI-Prolog. Le langage a en premier été conçu par un groupe autour d’Alain Colmerauer à Marseille, France, dans les années 1970. Il a été un des premiers langages de programmation logique, et reste le plus populaire parmi ces langages aujourd’hui, avec beaucoup d’implémentations gratuites et commerciales disponibles, l’une d’elles est SWI Prolog. Prolog (PROgramming in LOGic) est un langage de programmation de but général. Il est aussi appelé le langage de programmation de notation (symbolic programming) comme les langages de programmation fonctionnelle (functional programming) ou de programmation non-numérique (non-numerical programming). Ce langage de programmation est associé avec l’intelligence artificielle et la linguistique computationnelle. Il a ses racines en logique du premier ordre, une logique formelle, et contrairement à de nombreux autres langages de programmation. Prolog est déclaratif : le programme logique est exprimé en termes de relations : il est bien adapté pour résoudre les problèmes liés à des objets et des relations entre eux. Le principe de la programmation logique est basé sur les clauses de Horn. Une clause est appelée une clause de Horn si et seulement si elle a au plus un littéral positif. Par exemple, pour dire « Tous les hommes doivent mourir » et « Socrate est un homme », on peut déclarer: Clause 1 : mourir(X) ← homme(X) Clause 2 : homme(Socrate) Ce sont des clauses de Horn. La première clause est une règle, la deuxième est un fait. Un programme Prolog peut être considéré comme une base des données qui contient des clauses de Horn en forme de faits et/ou de règles. L’utilisateur peut exécuter un programme Prolog en posant des questions sur la base des données, par exemple : est-ce que Socrate doit mourir « mourir(Socrate) »? Le système va exécuter le programme en raisonnant – cherchant 32 Contexte et cas d’application sur la connaissance – la base des données, pour donner une réponse qu’elle soit « vraie » ou « fausse ». Pour l’exemple ci-dessus, le système va répondre à la question « Est-ce que mourir(Socrate) est vrai ?» en répondant à la question « Est-ce que « homme(Socrate) est vrai ?» (Clause 1). La réponse est « oui » (Clause 2), alors mourir(Socrate) est vrai. Un autre exemple plus compliqué, parent(Tom, Bob) signifie que Tom est parent de Bob. C’est un fait, dans lequel parent est un prédicat, Tom et Bob sont des arguments. Si on a parent(Tom, Bob) et parent(Bob, Liz), alors on a grandparent(Tom, Liz), signifie que Tom est grand parent de Liz. Généralement, X est grand parent de Z si et seulement s’il existe un Y, tel que X est parent de Y et Y est parent de Z. On a une règle comme grandparent(X, Z) ⃪ parent(X, Y) ⋀ parent(Y, Z) qui signifie que si X est parent de Y et Y est parent de Z, alors X est grand parent de Z. Dans Prolog, la règle est représentée par grandparent(X, Z) :- parent(X, Y), parent(Y, Z). Ensuite, une relation plus compliquée est définie, c’est l’ancêtre. X est ancêtre de Y si X est parent de Y, ou grand parent de Y, ou parent de grand parent de Y, etc. De façon récurrente, la relation peut être définie comme ça : X est ancêtre de Y si et seulement si (X est parent de Y ou X est parent de Z qui est ancêtre de Y). Dans Prolog, ceci est représenté par deux clauses consécutives : ancestor(X,Y) :- parent(X,Y) et ancestor(X,Y) :- parent(X,Z), ancestor(Z, Y). Pour écrire et exécuter des programmes, on utilise l’implémentation gratuite SWI-Prolog. SWI-Prolog appartient à la famille Prolog Edinburgh, il est en développement continu depuis 1987. Son principal auteur est Jan Wielemaker. Le nom est dérivé de SWI : SociaalWetenschappelijke Informatica (Social Science Informatique), le nom ancien du groupe de l’Université d’Amsterdam, où Wielemaker est employé. SWI-Prolog dispose d’une bibliothèque des prédicats et de guidage riche. Il fonctionne dans l’environnement graphique d’objet orienté. SWI-Prolog est assez simple à utiliser en exploitant les caractéristiques interactives graphiques. Après le téléchargement et l’installation de SWI-Prolog en ligne : http://www.swiprolog.org/, et l’exécution de swipl-win.exe, la fenêtre de travail apparaît pour déposer des questions. SWI-Prolog fonctionne en mode interactif : l’utilisateur dépose des questions et le système répond. L’invite de commande de SWI-Prolog est un point d’interrogation avec un tiret, l’ordre indiqué pour surveiller le processus de travail de l’utilisateur, puis un curseur clignotant. Après qu’un programme de Prolog soit compilé et chargé en mémoire, l’utilisateur peut déposer des questions (finies par un point). En fonction de la question, le système répond vrai (true) ou faux (false) avec une valeur X = < value > s’il y a une variable X quelconque dans la question. Dans le cas où il y a plusieurs réponses, après la première réponse, l’utilisateur peut taper un point-virgule s’il veut que le système continue à donner d’autres réponses, jusqu’à ce que le système réponde false (c’est à dire, il n’y a plus de réponse). Ou bien l’utilisateur peut Contexte et cas d’application 33 arrêter en tapant « entrée ». L’utilisateur peut également recevoir un message d’erreur s’il y a des problèmes dans la question déposée. Retourner au problème principal. Ayant pour base la carte de Pommier, le choix du prédicat le plus simple a été de se baser sur les types d’interactions déjà existantes sur cette carte : stimulation (une réaction enzymatique générale), phosphorylation, autophosphorylation, inhibition, nécessité (désigne une interaction nécessaire en tant que condition prérequis pour qu’une autre interaction soit réalisable), liaison, activation de transcription, dégradation et déphosphorylation. Le deuxième choix de stratégie est de vouloir représenter les interactions de la voie de signalisation de façon linéaire et chronologique, c’est à dire de vouloir créer un modèle dans lequel une interaction peut être issue d’une autre interaction, et va probablement entraîner une autre encore. Il s’agit alors de trouver une façon de représenter une succession chronologique des interactions. En effet, la carte d’interaction de Pommier ne montre que les interactions en elles-mêmes, de manière générale, sans distinction quant à leur ordre d’apparition dans la cascade d’événements. Le choix est alors d’inclure le facteur temps dans le modèle d’une manière indirecte, sur les conséquences de la succession des événements dans les états différents des protéines. En connaissant leur ordre chronologique d’apparition, on peut connaître l’évolution des événements en transposant chacun de ces états dans le modèle logique [22]. Par exemple : si ‘ATM → Chk2 → p53 → Apoptose’ est lu dans la carte, après descriptions on a alors ‘ATM/ATM (se phosphoryle) → pATM (ATM phosphorylé) → Chk2 (phosphoryle) → pChk2 (Chk2 phosphorylé) → Chk2/Chk2 (se lie) → p53 (phosphoryle) → pp53 (p53 phosphorylé) → Transcription → Apoptose’ L’étape suivante dans la réalisation de la thèse est de construire un modèle contenant les interactions présentes dans la voie de signalisation en réponse à la cassure double brin de l’ADN. Ce modèle doit avant tout être un modèle biologique avant d’être un modèle logique, car il faut dans un premier temps lister les interactions avant de les implémenter dans Prolog. La nécessité de définir un modèle biologique a entraîné de faire des choix dans les informations apportées à ce modèle. Pour pouvoir établir ce modèle, il faut une compréhension de la voie de réponse à la cassure double brin, or à l’heure actuelle, elle n’est pas encore bien connue. Des informations certaines restant encore à découvrir. Pour passer du modèle biologique au modèle logique, il faut considérer plusieurs contraintes : comment modéliser les interactions, bien faire attention au sens des implications logiques, respecter l'ordre chronologique préalablement défini et vérifier la cohérence des informations. Mais l'étape la plus importante à ce niveau d'avancement a été de bien définir les prédicats. Les prédicats choisis ont été calqués sur ceux de la carte de Pommier, à savoir stimulation, phosphorylation, autophosphorylation, inhibition, nécessité, liaison, activation de transcription, dégradation et déphosphorylation. Au départ, les prédicats ont été conceptualisés, pour la majorité d'entre eux, de la façon suivante : produit ⃪ réaction(enzyme, substrat). La réaction peut être stimulation, phosphorylation, déphosphorylation, liaison, activation ou dégradation. Par exemple, p*-Y ⃪34 Contexte et cas d’application phosphorylation(X, Y). Les autres prédicats qui ne sont pas de type produit ⃪ réaction(enzyme, substrat) sont modélisés séparément : p*-Y ⃪ autophosphorylation(Y) ¬Y ⃪ inhibition(X, Y) : si X est vrai, alors Y ne peut pas l’être Y ⃪ nécessité(X, Y) : pour que Y est vrai, X doit être vrai En effet, certains prédicats ont été modifiés, ou bien supprimés, au cours d’implémentations, tandis que d’autres ont été rajoutés grâce aux mises à jours effectuées dans le modèle biologique et avec l’avancement de son implémentation dans Prolog. Par exemple, les prédicats ajoutés sont ubiquitination, méthylation et dissociation. Une fois l’inventaire des réactions réalisé, un modèle biologique adopté, les prédicats choisis et réactualisés, il faut implémenter les informations dans Prolog. Pour la thèse, le logiciel SWI-Prolog a été utilisé. Ce programme utilise un fichier qui doit posséder une syntaxe propre. En effet, le fichier doit contenir des informations en forme de clauses, plus précisément des clauses en Forme Normale Conjonctive (CNF). Une CNF est une conjonction de clauses, de laquelle chaque clause est une disjonction de littéraux. Exemple : Soient A, B, C, et D des littéraux, contenus dans les clauses (A ⋁ B) et (C ⋁ D). Une CNF possible pourra alors être [(A ⋁ B) ⋀ (C ⋁ D)]. 1.2.3. Règles de comportements Il y a des règles de comportement entre les protéines dans le réseau de gènes. Par exemple, s’il y a une relation causale directe d’une protéine A à une protéine B, elle est définie que si cause(A, B) est vrai. En autres mots, si A cause B, et si A est vrai, alors B est vrai. Le fait qu’il n’y a pas de relation causale directe d’une protéine A à une protéine B est représenté par un contraire de la forme ¬cause(A, B). Similairement, s’il y a une relation de blocage directe d’une protéine A à une protéine B, elle est définie que bloque(A, B) est vrai, etc. Le prédicat bloque peut être expliqué ci-dessous : si A bloque B, est si A est vrai, alors B est faux. Dans ce contexte, pour donner les liens entre les relations cause et bloque, la logique classique est utilisé. La solution élémentaire est alors de donner explicitement les deux règles de comportements [3]. Règle 1 : cause(A, B) ⋀ cause(B, C) → cause(A, C) Règle 2 : cause(A, B) ⋀ bloque(B, C) → bloque(A, C) La règle 1 veut dire que si A cause B, et si B cause C, alors A cause C. Similairement, la règle 2 veut dire que si A cause B, et si B bloque C, alors A bloque C. Conclusion conséquente et la production 35 Chapitre 2. Conclusion conséquente et la production 2.1. Conclusion conséquente et SOL 2.1.1. Conclusion conséquente La conclusion conséquente est la tâche de calcul des théorèmes entraînés par un ensemble d'axiomes [10]. Son importance réside dans le fait que les tâches de raisonnement sont des cas particuliers de conclusions conséquentes [11]. Par exemple, la démonstration d’un théorème est équivalente à démontrer que la clause vide est une conséquence logique des axiomes et de la négation du théorème à démontrer. Un autre exemple est le raisonnement abductif, qui consiste à construire des hypothèses, lorsqu’est ajoutée à une théorie donnée une série d'observations [16]. Mais la génération des hypothèses par raisonnement abductif est équivalente à nier les conséquences de la théorie et de la négation des observations. De cette façon, la conclusion conséquente fournit un cadre général pour résoudre une variété de problèmes de raisonnement [17]. La plupart des applications de conclusion conséquente exigent les théorèmes générés pour satisfaire certaines propriétés syntaxiques. Par exemple, dans la démonstration de théorèmes, la seule conséquence d'intérêt est la clause vide, tandis que, dans l'abduction, les conséquences doivent en général être broyant des clauses unitaires dont les prédicats sont parmi un ensemble d’abductibles. En outre, pour éviter de produire un nombre infini de clauses redondantes et intérêt, il est généralement nécessaire de générer uniquement les conséquences qui ne sont pas englobées par d'autres [18,19]. 2.1.2. SOL G. Bossu et P. Siegel ont présenté un algorithme basé sur la SL-résolution pour implémenter une logique non-monotone, la sub-implication [29,30]. Cet algorithme est basé sur la génération de clauses caractéristiques. En [26] les clauses caractéristiques sont généralisées par P. Siegel pour définir les champs de production et leurs propriétés [26,31]. La thèse de 1987 [26] donne aussi un algorithme de production qui est une méthode complète pour calculer toutes les clauses impliquées par un ensemble de clauses et appartenant à un champ de production. Ces travaux ont été repris par Inoue [12] pour proposer la SOLrésolution comme une méthode complète pour trouver les clauses caractéristiques d'une théorie. Ensuite, Iwanuma et al. [14] ont reformulé la SOL-résolution dans le cadre des tableaux de la connexion et proposé plusieurs méthodes de taille pour élaguer des branches redondantes de l'espace de recherche. Tableaux de la connexion : Dans la logique du premier ordre, une clause est un multiensemble de littéraux, écrite comme une disjonction L1 ∨ …∨ Ln. La clause vide est notée ∅. Un littéral L est général maximum, si les arguments de L sont des variables distinctes. Par exemple, p(X, Y, Z) est un littéral général maximum. Un soulignement «_» est utilisé pour représenter une variable distincte si le nom de la variable n'est pas nécessaire, par exemple, p(_, _, _). L'ensemble de toutes les instances d'un littéral L est défini comme inst(L). Pour un 36 Conclusion conséquente et la production ensemble de littéraux L = {L1,. . . , Ln}, alors inst(L) = inst(L1) ∪…∪inst(Ln). Le nombre d'éléments dans un ensemble S est noté |S|. Occ(e, S) est le nombre d'occurrences de e dans S. Le signe ⊆ms désigne la relation d'inclusion sur les multi-ensembles, c'est-à-dire S1 ⊆ms S2 si et seulement si Occ(e, S1) ≤ Occ(e, S2) pour tout e contenu dans S1 ou S2. Lorsque C et D sont des clauses, C subsume D s’il y a une substitution θ telle que Cθ ⊆ms D. C subsume correctement D si C subsume D mais D ne subsume pas C. Pour un ensemble Σ de clauses, μΣ désigne l'ensemble des clauses de Σ non subsumées correctement par une clause dans Σ. Th(Σ) représente l'ensemble des conséquences logiques de Σ. Les clauses caractéristiques sont destinées à représenter les clauses «intéressantes», et sont construites sur un sous-vocabulaire du langage sous-jacent appelé un champ de production. Définition 2.1: Un champ de production P est une paire (L, Cond), où L est un ensemble de littéraux et Cond est une condition veut être satisfaite. Si Cond n'est pas spécifié, P est juste noté (L). Une clause C appartient à P = (L, Cond) si chaque littéral dans C appartient à inst(L) et C satisfaite Cond. Pour un ensemble de clauses Σ, l'ensemble des conséquences logiques de Σ appartenant à P est noté Thp(Σ). Un champ de production P est stable si, pour deux clauses des C et D telles que C subsume D, la clause D appartient à P seulement si C appartient à P. Définition 2.2: Les clauses caractéristiques de Σ par rapport à P sont Carc(Σ, P) = μThp(Σ). Soit C une clause. Les nouvelles clauses caractéristiques de C par rapport à Σ et P sont Newcarc(Σ, C, P) = μ[Thp(Σ ∪ {C}) \ Th (Σ)]. Proposition 2.1: Une clause est une nouvelle clause caractéristique de C par rapport à Σ et P si et seulement si elle est la clause caractéristique de Σ ∪ {C} mais pas la clause caractéristique de Σ. À savoir, Newcarc (Σ, C, P) = Carc(Σ ∪ {C}, P) \ Carc(Σ, P). Soit F = C1∧…∧Cm comme une forme normale conjonctive (CNF) de formule. Alors, �������(∑, �, �) = µ ���������(∑� , �� , �) � �=1 � où Σ1 = Σ et Σi+1 = Σi ∪ {Ci} pour i = 1,…, m - 1. Noter que Σ n’est pas consistent si et seulement si Carc(Σ, P) = {∅} pour tout champ de production stable P = (L, Cond). Cela signifie que la conclusion de preuve est un cas particulier de conclusion conséquente. D'autre part, si Σ |≠ L (Σ n’entraîne pas L) et Σ |≠ ¬L (Σ n’entraîne pas ¬L) pour les littéraux L et ¬L appartenant à P, Carc(Σ, P) contient une tautologie L ∨ ¬L tant que L ∨ ¬L satisfait Cond. Les clauses caractéristiques Carc(Σ, P) peuvent être exprimées en utilisant progressivement les opérations Newcarc. Soit Taut(L) l'ensemble des tautologies de la forme L ∨ ¬L tel que L et ¬L appartiennent à inst (L). Alors, pour un ensemble Σ de clauses, une clause C et un champ de production stable P = (L, Cond), il vient que : Conclusion conséquente et la production 37 Carc(∅, P) = μ{T | T ∈ Taut(L) et T satisfait Cond}, Carc(Σ ∪ {C}, P) = μ[Carc(Σ, P) ∪Newcarc(Σ, C, P)]. Pour calculer Newcarc(Σ, C, P), SOL se concentre sur la seule production des théorèmes appartenant à P, et traite une clause C nouvellement ajoutée comme la clause de départ. Ces caractéristiques sont importantes pour la conclusion conséquente car la procédure peut directement déduire les théorèmes relatifs à l'information ajoutée. Définition 2.3: Un tableau de clauses T est un arbre ordonné étiqueté, où chaque nœud non racine de T est marqué par un littéral. Un nœud est défini avec son étiquette (soit un littéral) si aucune confusion ne se pose. Si les successeurs immédiats d'un nœud sont des littéraux L1,…, Ln, alors la clause L1 ∨…∨ Ln est appelé une clause de tableau. La clause de tableau en dessous de la racine est appelée la clause de départ. T est un tableau de clauses pour un ensemble Σ de clauses si chaque clause de tableau C en T est une instance d'une clause D dans Σ. Dans ce cas, D est appelé une clause d'origine de C dans Σ. Un tableau de connexion (serré) est un tableau de clauses tel que, pour chaque nœud nonfeuille L sauf la racine, il y a un successeur immédiat marqué avec ¬L. Un tableau marqué T est un tableau de clauses tel que des feuilles sont marquées avec des étiquettes fermé ou sauté. Les feuilles non marquées sont appelées sous-buts. Un nœud N dans T est dit être résolu si N lui-même est un nœud de feuille marqué ou tous les nœuds de feuilles de branches à N de T sont marqués. T est résolu si toutes les feuilles sont marquées. Sauté(T) désigne l'ensemble des littéraux de nœuds marqués sauté. Définition 2.4: Un tableau T est régulier si chaque nœud sur une branche en T est étiqueté avec un littéral différent. T est dit libre-tautologie si aucune clause de tableau en T n’est une tautologie. T est dit libre-complément si deux nœuds non-feuilles sur une branche en T ne sont jamais étiquetés avec des littéraux complémentaires. Un tableau T est sauté-régulier s’il n’y a pas de nœud L en T tel que ¬L ∈ sauté(T). T est TCS-libre (TCS-Tableau de Clauses Subsumées libre) pour un ensemble de clauses Σ si aucune clause tableau C en T n’est subsumée par une clause dans Σ autre que les clauses d'origine de C. Définition 2.5: Une fonction φ de sélection est une application attribution d'un sous-but à chaque tableau. φ est dite profondeur d'abord si φ choisit de tout tableau T un sous-but avec une profondeur maximale. φ est stable par substitution si, pour tout tableau T et toute substitution, φ(t) = φ(Tσ) où Tσ est le tableau qui est construit en appliquant σ à tous les littéraux de T. Définition 2.6: Soit Σ un ensemble de clauses, C une clause, P un champ de production, et φ une fonction de sélection. Un SOL-déduction dérivée d’une clause S de Σ + C et P via φ est constituée d'une séquence de tableaux T0, T1,…, Tn satisfaisant: (1) T0 se compose seulement de la clause de départ C. Tous les nœuds de feuille de T0 ne sont pas étiquetés. (2) Tn est un tableau résolu, et sauté(Tn) = S. 38 Conclusion conséquente et la production (3) Pour chaque Ti (i = 0, ..., n), Ti est régulier, libre-tautologie, libre-complément, sauté- régulier, et TCS-libre pour Σ ∪ {C}. (4) Pour chaque Ti (i = 0, ..., n), la clause sauté(Ti) appartient à P. (5) Ti+1 est construit à partir de Ti comme suit. Sélectionner un sous-but K par φ, puis appliquer une des règles suivantes à Ti pour obtenir Ti +1: (a) Si sauté(Ti) ∪ {K} appartient à P, alors marquer K avec sauté. (b) Si sauté(Ti) contient un littéral L, et K et L sont unifiables (K et L peuvent être l’inverse l’un de l’autre) avec θ, marquer K avec sauté, et appliquer θ à Ti . (c) Sélectionner une clause B de Σ ∪ {C} et obtenir une variante B’ = L1 ∨…∨ Lm en renommant. S’il y a un littéral Lj tel que ¬K et Lj sont unifiables avec θ, puis ajouter les nouveaux nœuds L1,…, Lm à K comme les successeurs immédiats. Ensuite, marquer Lj avec fermé et appliquer θ au tableau prolongée. (d) Si K a un nœud ancêtre L, et ¬K et L sont unifiables avec θ, alors marquer K avec fermé, et appliquer θ à Ti . Théorème 2.1: (Correction et exhaustivité de SOL) Pour toute fonction φ de sélection, ce qui suit s'applique: (1) Correction : S’il y a un SOL-déduction d'une clause S de Σ + C et P par φ, alors S appartient à Thp(Σ ∪ {C}). (2) Exhaustivité : Si une clause F n'appartient pas à Thp(Σ), mais appartient à Thp(Σ ∪ {C}), alors il existe une SOL-déduction d'une clause S de Σ + C et P par φ tels que S subsume F. Exemple 2.1: Une clause de départ C, un ensemble de clauses Σ et un champ de production P sont définis comme suit. Soit φ une fonction de sélection. C = p(X) ∨ s(X), Σ = {q(X) ∨ ¬p(X), ¬s(Y), ¬p(Z) ∨ ¬q(Z) ∨ r(Z)} P = (L+ , la longueur est inférieure à 2) La Figure 2.1 montre trois tableaux résolus qui sont dérivés par SOL-déduction sur Σ + C et P par φ. Dans le tableau Ta, le nœud p(X) est sauté depuis le littéral positif p(X) qui appartient à P, et s(X) est étendu à l'aide de la clause d’unité ¬s(Y). Noter que s(X) ne peut pas être sauté puisque le champ de production P limite la longueur maximale des conséquences à 1. La conséquence est sauté(Ta) = {p(X)}. Tb représente un autre tableau dérivé dont le nœud p(X) est prolongé par q(X) ∨ ¬p(X), et le nœud q(X) est sauté. La conséquence de Tb est sauté(Tb) = {q(X)}. Dans Tc, le nœud p(X) est prolongé par q(X) ∨ ¬p(X) et q(X) par ¬p(Z) ∨ ¬q(Z) ∨ r(Z) respectivement. Le nœud du bas ¬p(X) est fermé par réduction avec l'ancêtre p(X), et r(X) est sauté. La conséquence est sauté(Tc) = {r(X)}. Dans cet exemple, il y a six Conclusion conséquente et la production 39 tableaux résolus. Car les tableaux restés génèrent la même conséquence que Tc, ils sont redondants. Comme résultats, trois nouvelles clauses caractéristiques sont obtenues dans cet exemple : Newcarc(Σ, C, P) = {p(X), q(X), r(X)}. La tâche de conclusion conséquente est de trouver toutes les (nouvelles) clauses caractéristiques. Cela signifie que même si un tableau résolu est trouvé, il faut continuer à chercher d'autres tableaux résolus pour trouver toutes les clauses caractéristiques. En conclusion de preuve, le processus de calcul peut être arrêté immédiatement si une réfutation apparait. Ceci est la différence importante entre la conclusion conséquente et la conclusion de preuve. Définition 2.7: L'ensemble de SOL-dérivées de Σ + C et P par φ est: �(∑, �, �, ϕ) = {�|� ��� �é���é� ��������� ��� ���−�é������� �� ∑ + � �� � ��� ϕ} L'ensemble des clauses de production de Σ + C et P par φ est: Prod(Σ, C, P, φ) = μΔ(Σ, C, P, φ). Proposition 2.2: Pour toute fonction φ de sélection, Newcarc(Σ, C, P) = Prod(Σ, C, P, φ) - Thp(Σ). Afin de clarifier l'espace de recherche du processus de conclusion conséquente, l'arbre de recherche SOL est défini pour explicitement toutes les SOL-déductions possibles. p(X) s(X) ¬s(X) fermé Tb q(X) sauté ¬p(X) fermé p(X) sauté s(X) ¬s(X) fermé Ta Tc p(X) s(X) ¬s(X) fermé q(X) ¬p(X) fermé ¬p(X) fermé r(X) sauté ¬q(X) fermé réduction Figure 2.1 Tableaux résolus pour l’Exemple 2.1 40 Conclusion conséquente et la production Définition 2.8: L'arbre de recherche SOL de Σ + C et P par φ est un arbre T marqué avec les tableaux comme suit. Un nœud est identifié avec son étiquette (c'est à dire un tableau) si aucune confusion ne se pose: (1) La racine de T est un tableau qui se compose seulement de la clause de départ C. (2) Chaque nœud non-feuille N dans T a autant de nœuds successeurs qu’il existe d’applications réussies d'une étape d'inférence unique appliquée au sous-but sélectionné dans N par φ, et les nœuds successeurs de N sont les tableaux de résultantes respectives. La procédure conséquente de recensement SOL visite constructivement tous les nœuds dans l'arbre de recherche SOL, et énumère l'ensemble des clauses de production. Définition 2.9: La procédure conséquente de recensement SOL de Σ + C et P via φ est définie comme suit: (1) T0 est un tableau qui comprend seulement la clause de départ C, et Conqs est initialisée comme {} (Conqs est une variable globale). (2) Appeler la procédure EnumConqs(T0) dans la Figure 2.2. (3) Renvoyer l’ensemble de clauses de production Conqs. La correction de la procédure conséquente de recensement SOL tient évidemment par les définitions de clauses de production et d’EnumConqs. Proposition 2.3: Laisser Conqs être un ensemble de conséquences obtenues de la procédure conséquente de recensement SOL de Σ + C et P par φ. Alors, Conqs = Prod(Σ, C, P, φ). EnumConqs(T) T: un tableau Commencer si Conqs = {∅} alors revenir; fin / * trouvé la conséquence la plus générale * / si T est un tableau résolu alors C := sauté(T); / * trouvé une nouvelle conséquence * / Conqs := μ(Conqs ∪ {C}); / * supprimer conséquences non minimales * / revenir; fin K := φ(T); / * sélectionner un sous-but de T * / R := un ensemble de règles d'inférence qui sont applicables à K; pour chaque r ∈ R faire T’ := le tableau obtenu à partir de T en appliquant r de K; EnumConqs(T’) ; / * Correspondant à l'extension de l'arbre de recherche SOL * / fin fin Figure 2.2. La procédure conséquente de recensement SOL.Conclusion conséquente et la production 41 2.2. Production pour l’abduction et l’induction 2.2.1. Définition Selon la thèse de P.Siegel [26], une production PR de C (un ensemble des clauses) est une suite finie de couples . Chacun de ces couples est une étape (ou une inférence) de PR dans laquelle pi est une clause, la clause en production et Ai un arbre. Cette suite a les propriétés A, B et C : A. La première étape de PR est = <0, (l1) ... (lm)> où les lj sont tous les littéraux d’une même clause c de C, l’origine de la production. Chacun de ces littéraux apparaissant une et une seule fois. La clause en production est vide. B. La dernière étape est si An est l’arbre vide. La clause pn est alors la clause produite par la production. C. Si la k-ième (k = où (l s) est une branche de feuille l (le littéral à effacer), B un arbre et p la clause en production, alors l’étape suivante a l’une des forme C1 ou C2. C1. On met en production le littéral l si l’étape suivante est : C2. On effectue une résolution si l’étape suivante est : où les littéraux l’i sont tels que les conditions de C2a et de C2b sont vérifiées. C2a. Il existe une clause c’ de C, la clause appelée à cette étape, - qui contient l’opposé de l, - dont aucun littéral n’est dans la branche (l s) (les littéraux de cette branche sont les ascendants ou a-ancêtres) - dont aucun littéral n’a pour opposé une feuille de l’arbre B (les frères de l) - dont aucun littéral n’a pour opposé un littéral de la clause en production p (les littéraux de cette clause sont les littéraux en production). Les trois dernières conditions sont les conditions de non répétition. C2b. Les l’i sont alors les littéraux de cette clause c’, qui ne sont pas immédiatement effaçables, c’est à dire ceux : - dont l’opposé n’est pas dans la branche (l s), - qui ne sont pas égaux à une feuille de l’arbre B, - qui ne sont pas égaux à un littéral de la clause en production. 2.2.2. Exemple d’utilisation Soit l’ensemble C de cinq clauses : 42 Conclusion conséquente et la production ¬a b c ¬b d e f e ¬a ¬d c ¬c e f ¬e f g L’ensemble C ⋃ {a f} implique la clause f g et C ne l’implique pas. Il existe donc au moins une production d’origine a f qui produit f g. C’est par exemple le cas de : 1. <0 ,(a) (f)> 2. ¬a b c <0 ,(ba) (ca) (f)> 3. ¬b d e <0 ,(dba) (eba) (ca) (f)> 4. f e ¬a ¬d c <0 ,(eba) (ca) (f)> 5. ¬e f g <0 ,(geba) (ca) (f)> 6. 7. ¬c e f 8. ¬e f g 9. Pour visualiser globalement toutes les étapes d’une production, il est possible de faire un dessin du type : Figure 2.3. Les étapes d’une production 2.3. Champ de production La notion de champ de production dépassant le cadre restreint du calcul propositionnel, cette partie en donnera la définition dans le cadre général du calcul des prédicats. Une « formule » sera donc ici une formule de la logique du premier ordre et, bien entendu, une « formule propositionnelle » une formule du calcul propositionnel. 2.3.1. DéfinitionConclusion conséquente et la production 43 Définition 2.10: Un champ de production P est un ensemble de formules dont chacune est un résultat possible dont on a besoin de savoir s’il est vrai ou non dans un certain état de connaissance. Le but du jeu est de trouver les formules de cet ensemble vraies pour une connaissance donnée. Il s’agit donc d’une notion assez naturelle qui pourra se définir, correctement d’un point de vue logique, de manière simple. De manière très générale, deux problèmes se posent : Problème 2.1: Soit : - L un langage du premier ordre, - P un ensemble de formules de L, le champ de production, - C un ensemble de formules de L, la connaissance, Trouver l’ensemble, produites(C, P), des formules sémantiquement impliquées par C et appartenant à P. Si th(C) représente toutes les formules sémantiquement impliquées par C, on a donc : produites(C, P) = th(C) ∩ P Problème 2.2: Soit : - L, P, C définis comme précédemment, - C’ un nouvel ensemble de formules de L, la nouvelle connaissance, Trouver toutes les formules de P impliquées par C ⋃ C’, qui appartiennent à P et qui ne sont pas impliquées par C. Cet ensemble des formules se notera nouv-prod(C’, C, P) : nouv-prod(C’, C, P) = produites(C ⋃ C’, P) – produites(C, P). Définition 2.11: Si c1 et c2 sont des clauses, on dira que c1 est une sous clause de c2, ou que c1 subsume c2 si tout littéral de c1 est un littéral de c2. On dira également que c1 subsume strictement de c2 (est une sous clause stricte) si c1 subsume c2 et c2 ne subsume pas c1. Si F est un ensemble de formules qui ne sont pas des tautologies, et G un sous ensemble de F, on dit que : - G est un précurseur de F si toute formule de F est impliquée par une formule de G. « Pour toute f dans F il existe g dans G telle que g ⊨ f » 44 Conclusion conséquente et la production - G est un plus petit précurseur de F (ou précurseur minimal de F), si de plus aucune formule de G n’implique une autre formule de G. « Si G est un précurseur de F, et si g1 et g2 sont dans G et g1 ⊨ g2 alors g1 = g2 ». Propriété 2.1: Si G1 et G2 sont deux précurseurs minimaux de F, il existe une bijection bij de G1 dans G2 telle que, pour toute formule g1 de G1, il existe un unique g2 de G2 tel que g1 et bij(g2) sont logiquement équivalentes. Définition 2.12: Un champ de production P est stable pour l’implication sémantique si toute formule qui implique sémantiquement une formule de P est dans P. Propriété 2.2: Si P est un ensemble de clauses propositionnelles, alors P est stable si et seulement si toute sous clause d’une clause de P est dans P. 2.3.2. Exemple d’utilisation Si L est un langage propositionnel contenant une infinité de propositions p1, p2, ..., et si la connaissance est un ensemble de deux clauses : C = ¬p1⋁p2⋁p3 ‘si p1, alors p2 ou p3 est vrai’ p1 ‘p1 est vrai’ Si le champ de production est l’ensemble des clauses de L ne contenant que des littéraux positifs (clauses positives), on a : produites(C, P) = p1 ‘p1 est vrai’ p2⋁p3 ‘p2 ou p3 est vrai’ Si maintenant la nouvelle connaissance se compose des deux unaires : C’ = p4 ‘p4 est vrai’ ¬p3 ‘p3 est faux’ alors on obtient : nouv-prod(C’, C, P) = p4 ‘p4 est vrai’ p2 ‘p2 est vrai’Conclusion conséquente et la production 45 2.4. Algorithmes de calcul de production 2.4.1. Description simplifiée Notre problème pratique est dont de calculer toutes les clauses impliquées par un ensemble fini C de clauses et appartenant à un champ de production P. Comme P est en général très grand, il est évident que la technique consistant à vérifier, pour toute clause de P, si elle est impliquée par C ou non, est totalement inapplicable. Cette partie va étudier un algorithme basé sur la SOL résolution qui essaie de résoudre partiellement ce problème. Pour bien faire son travail, il doit s’arrêter, ne donner que des résultats corrects et donner tous les résultats. On s’assure de ceci en démontrant trois propriétés. Propriété 2.3: Un ensemble fini de clauses a un ensemble fini de productions (l’algorithme s’arrête). Propriété 2.4: Toute clause produite par une production de C est impliquée par C (les résultats sont valides). En particulier, si une production de C produit la clause vide, alors C est inconsistant. Propriété 2.5: Si une clause d est impliquée par C, il existe une production de C dont la clause produite subsume d (les résultats sont tous trouvés). En particulier, si C est inconsistant, il existe une production de C qui produit la clause vide. Propriété 2.6: Si C n’implique pas d et C ⋃ {c} implique d, il existe une production de C ⋃ {c}, d’origine c dont la clause produite subsume d. En particulier, si C ⋃ {c} est inconsistant, et C ne l’est pas, il existe une production de C d’origine c qui produit la clause vide. Il faut maintenant décrire l’algorithme qui génère toutes les clauses impliquées par un ensemble C de clauses et appartenant à un champ de production P. Cet algorithme a été implanté en SWI Prolog. Les clauses, branches et arbres sont représentés classiquement : - un littéral x s’écrira plus(x) s’il est positif et moins(x) s’il est négatif. - une liste de littéraux (clause ou branche) se notera de la manière habituelle l1. l2... ln. nil où nil représentant la liste vide. - un arbre est une liste s1. s2... sm. nil de branches. Les si sont donc des listes non vides de littéraux (donc différentes de nil). - un ensemble de clauses est identifié à une liste c1. c2... cp. nil de clauses.46 Conclusion conséquente et la production Description simplifiée : Pour produire les clauses impliquées par une liste C = c. C’ (c est une clause et C’ une liste de clauses éventuellement vide) appartenant à un champ de production P, il faut produire les clauses impliquées par C’ puis produire les clauses impliquées par c.C’ et non par C’. Pour ce faire on utilise le prédicat grande-production : grande-production(nil, P) → ; grande-production(c.C, P) → grande-production(C, P) construire-arbre(c, nil, nil, nil, A) production(nil, A, C, P) ; Le cœur de l’algorithme est la définition d’un prédicat à quatre arguments production(p, A, C, P), où p est la clause en production, A un arbre, C l’ensemble de clauses et P le champ de production. L’arbre A origine est donné par le prédicat construire-arbre, qui transforme la clause origine c = l1. l2... ln. nil en un arbre dont les branches sont composées d’un littéral de cette clause : A = (l1.nil).(l2.nil) .... (ln. nil).nil On définit production par trois clauses Prolog : (1) production(p, nil, C, P) → utiliser(p) ; (2) production(p, (l.s).B, C, P) → /* Forme C2*/ dans(c’, C) /* Prendre une clause c’ de C */ bonne-clause(c’, p, (l.s).B) /* Conditions C2a */ construire-arbre(c’, p, (l.s).B, B’) /* Construire l’arbre B’ à partir de la clause c’, conditions C2b*/ production(p, B’, C, P) ; (3) production(p, (l.s).B, C, P) → /* Forme C1*/ bon-debut-de-clause(l.p, P) /* l .p satisfaisante le champ de production P*/ production(l.p, B, C, P) ; dans(x, x.r) → ; dans(x, y.r) → dans(x,r) ; La clause (1) est le cas terminal d’une production. Ici, on l’ajoutera sous de forme d’une clause Prolog : clause-produite(p) → ; utiliser(p) → assert(clause-produite(p), nil) ;Conclusion conséquente et la production 47 Pour être en accord avec la définition, bonne-clause doit vérifier les conditions de non répétition. Il faut donc : 1- S’assurer que l’opposé de la feuille de la première branche de l’arbre est bien dans la clause candidate. 2- Vérifier que tous les littéraux de cette clause : - ne sont pas dans la première l.s de l’arbre, - n’ont pas leur opposé dans la clause en production p, - n’ont pas leur opposé égal à une feuille de l’arbre B. Ceci s’effectue de manière naturelle : bonne-clause(c’, p, (l.s).B) → oppose(l, l’) dans(l’, c’) bons-littéraux(c’, p, (l.s), B) bons-littéraux(nil, p, A) → ; bons-littéraux(l.r, p, s.B) → bons-littéraux(r, p, s.B) pas-dans(l, s) oppose(l, l’) pas-dans(l’, p) pas-dans-feuilles(l’, B) ; oppose(plus(x), moins(x)) → ; oppose(moins(x), plus(x)) → ; pas-dans(x, nil) → ; pas-dans(x, y.r) → dif(x, y) pas-dans(x, r) ; pas-dans-feuilles(x, nil) → ; pas-dans-feuilles(x, (l.s).B) → pas-dans(x, l.s) pas-dans-feuilles(x, B) ; 48 Conclusion conséquente et la production Il faut maintenant définir construire-arbre qui, à partir de la clause c’ = l1. l2... ln. nil de la clause en production p et de l’arbre (l.s).B va construire l’arbre A’ = (l’1.l.s) ... (l’p.l.s).B les l’i étant les littéraux de c’ non immédiatement effaçables. construire-arbre(nil, p, s.B, B) → ; construire-arbre(l.r, p, s.B, (l.s).B’) → /* Conditions C2a sont vérifiées*/ oppose(l, l’) pas-dans(l’, s) pas-dans(l, p) pas-dans-feuilles(l, B) / construire-arbre(r, p, s.B, B’) ; construire-arbre(l.r, p, A, A’) → /* Conditions C2a ne sont pas vérifiées*/ construire-arbre(r, p, A, A’) ; Pour vérifier qu’une clause est dans un champ de production défini par une quadruplé de bases quelconque, on peut écrire : bon-debut-de-clause(c, P.l-iste-P) → dans-le-champ(c, P) / ; bon-debut-de-clause(c, P.l-iste-P) → bon-debut-de-clause(c, l-iste-P) ; dans-le-champ(l.c, ) → eq(l, s-igne) dans(l, a-lpha) longueur-inferieure(l.c, l-ong) dans(c’, s-ous-cl) subsume(c, c’)Conclusion conséquente et la production 49 / ; subsume(nil, c) → / ; subsume(l.c’, c) → subsume(c’, c) dans(l, c) ; longueur-inferieure(c, infini) → / ; longueur-inferieure(nil, l) → ; longueur-inferieure(a.c, l) → / impasse ; longueur-inferieure(a.c, l) → val(sub(l, l), l’) longueur-inferieure(c, l’) ; 2.4.2. Algorithme avec coupure A toute étape de production, on essaie d’effacer le premier littéral de la première branche d’arbre (le littéral à effacer). Pour ce faire, il faut choisir une clause candidate contenant l’opposé de ce littéral et satisfaisant aux conditions de non répétition, en ôter tous les littéraux immédiatement effaçables (qui ne satisfont pas aux conditions C2b), puis essayer d’effacer la clause restante. Quand tous ces choix ont été effectués et résolus, il reste un choix supplémentaire qui est de mettre en production le littéral à effacer. Or, si le littéral à effacer a été, pour un certain choix, complètement effacé sans avoir eu besoin d’installer des littéraux en productions supplémentaires, il est inutile d’effectuer les choix restants. On peut formaliser ceci par une définition et une propriété. Définition 2.13: S’il existe un début de production, D, de dernière étape (j) : .............................. (i) .............................. 50 Conclusion conséquente et la production (j) telle que B1 = B2 et p1 = p2, on dira que le littéral l a été complètement effacé. Propriété 2.7: Dans ce cas toute production égale à D jusqu’à l’étape (i) incluse, ne pourra produire que des clauses subsumées par d’autres clauses produites par les productions de début D. Donc, d’après la structure de l’algorithme, qui à partir de l’étage (i+1), calcule toutes les productions ayant ces (i) premières étapes avant de faire les autres choix pour l à l’étape (i+1), il sera inutile si ce littéral est complètement effacé de faire ces autres choix. C’est principalement pour cette raison que l’on essaie d’abord d’effectuer toutes les résolutions possibles sur un littéral avant de mettre ce littéral en production (avant d’essayer d’effacer de manière classique un littéral, on regarde s’il n’existe pas une clause contenant son opposé et dont tous les littéraux sont immédiatement effaçables). Le choix inverse est possible mais donne de moins bons résultats. Démonstration : Soit PR1 une production égale à D jusqu’à (i). Cette production aura une étape (j’) dont l’arbre est B1, et peut donc s’écrire : .............................. (i) .............................. (j’) .............................. (n’) PR1 produit la clause p = r q p1 dans laquelle q et r sont des clauses éventuellement vides (la notation inclut le cas où j’ = n’). Pour prouver le théorème, il faut construire à partir de PR1 une production, PR2, dont le début est D et dont la clause produite subsume p. Le début de PR2 est donc : .............................. (i) .............................. (j) Conclusion conséquente et la production 51 L’important est que, à l’étape (j’) de PR1 et à l’étape (j) de PR2, les arbres sont égaux. À l’étape (j), la clause en production, p1, de PR2 est une sous clause de la clause en production à l’étape (j’), q p1, de PR1. Les étapes de PR2 qui suivent (j) sont construites à partir des étapes de PR1 qui suivent (j’) telles que, si la clause appelée contient un littéral de r q alors ce littéral n’est pas immédiatement effacé mais inséré dans l’arbre. Il sera mis en production à l’étape où il sera littéral à effacer de l’arbre courant. Plus précisément : 1. L’étape (j+1) de PR2 est construite à partir de l’étape (j’+1) de PR1 telle que : - si (j’+1) met en production le littéral à effacer, alors (j+1) mettra également en production ce même littéral à effacer. - si (j’+1) effectue une résolution sur une clause c, alors (j+1) effectuera également une résolution sur cette même clause c. Les branches ajoutées à l’arbre B1 (dans PR2) sont obtenues à partir des littéraux de c non immédiatement effaçables (dans PR1). Mais les littéraux de c immédiatement effaçables dans PR2, sont les littéraux de c immédiatement effaçables dans PR1, plus les littéraux de c, égaux à un des littéraux de q (les ascendants et frères sont les mêmes dans PR1 et PR2 car les arbres sont égaux à l’étape (i)). Donc les branches à ajouter dans PR2 sont les branches à ajouter dans PR1, plus éventuellement un certain nombre de branches dont les racines sont les littéraux de c qui ne sont pas dans q. 2. On répète l’opération pour les étapes suivantes de PR2, qui sont construites à partir des étapes de PR1. Les clauses appelées sont les mêmes dans PR1 et PR2. La seule différence est que dans les arbres correspondants (dans PR2) sont insérées un certain nombre de branches supplémentaires, branches dont les racines seront toujours des éléments de q. Quand le littéral à effacer (dans PR2) portera sur une de ces branches supplémentaires, ce littéral sera mis en production. On insère donc un certain nombre d’étapes qui sont toutes des mises en production de littéraux de q. La suite de couples ainsi formée est bien une production, car comme PR1 en est une, on en déduit que pour toutes les étapes de résolution de PR2 les clauses appelées satisfont aux conditions de non répétition. En effet, ces étapes sont telles que : - l’étape associée dans PR1 satisfait aux conditions de non répétition - les ascendants sont les mêmes dans PR1 et PR2 car ces étapes sont des étapes de résolution et ne portent donc pas sur les branches supplémentaires (on a dit que les étapes portant sur les branches supplémentaires mettent en production un littéral). - l’union des frères et littéraux en production de PR2 est incluse dans l’union des frères et littéraux en production de PR2. PR2 est donc bien une production et la clause produite par PR2 subsume bien celle produite par PR1 car les littéraux mis en production dans PR1 et non dans PR2 sont tous dans q. Exemple 2.2: Soit un ensemble de clause : 52 Conclusion conséquente et la production C = {a b c, ¬a b, ¬a u, ¬u v, ¬v w} On veut calculer toutes les productions d’origine a b c. L’algorithme construira, par ses appels récursifs, la première production qui produit la clause c b : 1. <0 ,(a) (b) (c)> 2. ¬a b <0 ,(b) (c)> 3. 4. Cette production est donnée par le choix de ¬a b à la deuxième étape. Il reste deux choix à cette étape : soit appeler la clause ¬a u, soit mettre a en production. En fait ces choix sont inutiles car ils ne pourront générer que des clauses subsumées par d’autres clauses produites par la production effectuée auparavant. Le premier choix donne trois productions dont la première est : 1. <0 ,(a) (b) (c)> 2. ¬a u <0 ,(ua) (b) (c)> 3. ¬u v <0 ,(vua) (b) (c)> 4. ¬v w <0 ,(wvua) (b) (c)> 5. 6. 7. En fait, c b w est subsumée par c b. 2.4.3. Algorithme en Prolog Pour produire les clauses d’un champ de production P impliquées par un ensemble C on appellera comme auparavant grande-production(C, P) : grande-production(nil, P) → ; grande-production(c.C, P) → grande-production(C, P) production(c, nil, nil, nil, p, C, P) utiliser(p) ; production(nil, A, B, p, p, C, P) → ; //le cas terminal production(l.c, A, B, p1, p3, C, P) → conc(c, B, B1) // B1=c.B, construire la liste des frères oppose(l, l’) dans(c1, C) dans(l’, c1) bonne-clause(c1, l.A, B1, p1) // Conditions C2a Conclusion conséquente et la production 53 simplifier-clause(c1, l.A, B1, p1, c2) // Conditions C2b, enlever les littéraux production(c2, l.A, B1, p1, p2, C, P) //Concaténant aux ascendants le littéral (p1 == p2 *→ !; true) //couper(p1, p2) production(c, A, B, p2, p3, C, P) ; //si p1 = p2 ou p1≠ p2 production(l.c, A, B, p1, p3, C, P) → //mettre en production si p1≠ p2 bon-debut-de-clause(l.p1, P) production(c, A, B, l.p1, p3, C, P) ; bonne-clause(nil, A, B, p) → ; bonne-clause(l.c, A, B, p) → pas-dans(l , A) oppose(l, l’) pas-dans(l’, B) pas-dans(l’, p) bonne-clause(c, A, B, p) ; simplifier-clause(nil, A, B, p, nil) → ; simplifier-clause(l.c, A, B, p, l.c’) → oppose(l, l’) pas-dans(l’, A) pas-dans(l, B) pas-dans(l, p) / simplifier-clause(c, A, B, p, c’) ; simplifier-clause(l.c, A, B, p, c’) → simplifier-clause(c, A, B, p, c’) ; conc(nil, y, y) → ; conc(a.x, y, a.z) → conc(x, y, z) ; Où : production(clause, ascendants, frères, produit-initiale, produit-finale, ensemble, champ) 54 Conclusion conséquente et la production - La clause à effacer, clause, est un bout d’une clause de c ∪ C qui contient le premier littéral (littéral à effacer). - ascendants est la liste des ascendants de ce premier littéral. - frères est la liste des frères de ce premier littéral, autres que les littéraux de clause. - A l’appel de production, produit-initiale donne la clause en production à ce moment. L’argument produit-finale donne alors la clause en production résultante. Pour que ces algorithmes travaillent avec les variables, il faut les améliorer. Par exemple, pour représenter l’idée : a est une protéine et b un substrat ; tous les substrats sont activés par les protéines, ceci doit être écrit dans la basée de données comme ci-dessous : proteine(a). substrat(b). ecrit :- proteine(X), substrat(Y), assert(clause(active(X,Y))). La logique des défauts 55 Chapitre 3. La logique des défauts 3.1. Introduction Quand un algorithme d’Intelligence Artificielle doit résoudre un problème, il peut être en mesure de s'appuyer sur des informations complètes. Sa tâche principale est alors de donner de bonnes conclusions par un raisonnement classique. Dans ce cas, la logique des prédicats peut être suffisante. Cependant, souvent l’information est incomplète, car certaines informations ne sont pas disponibles. Parfois, il peut aussi être nécessaire de répondre rapidement et il est alors impossible de recueillir toutes les données pertinentes en un temps raisonnable. Dans ce cas, le système doit faire des conjectures plausibles, c’est la problématique des logiques nonmonotones [7,9]. Pour la logique des défauts ces conjectures sont basées sur des règles empiriques, appelées défauts. Par exemple, un médecin d’urgence doit faire des conjectures sur les causes les plus probables des symptômes observés et il est impossible d'attendre le résultat de tests éventuellement étendus et chronophages avant le début du traitement. Lorsque les décisions sont fondées sur des hypothèses, elles peuvent se révéler fausses face à de nouvelles informations qui seront disponibles [13]. Par exemple les examens médicaux peuvent conduire à un diagnostic modifié. Il faut alors ajouter de nouvelles informations qui peuvent être contradictoires, avec les conclusions (le diagnostic) précédent. Cet ajout est impossible en logique classique, qui a la propriété de monotonie. Intuitivement cette propriété dit que si une conclusion C est déductible d’un ensemble de prémices P1, et que l’on ajoute des informations P2 à P1, alors C est démontrable de P1 et P2. Dans le cas de la logique du premier ordre P1, P2 et C sont des ensembles de formule et la propriété de monotonie s’écrit : P1 ⊢ C ⇒ P1 ⋃ P2 ⊢ C Si cette propriété n’est pas vérifiée, alors on a une logique non-monotone. La logique des défauts présentée par Reiter en 1980 est une des premières logiques non-monotones. Elle est très intéressante, car simple à comprendre et à utiliser. 3.2. Notion de défaut La logique des défauts définie par Reiter formalise le raisonnement par défaut. Elle permet de traiter les règles admettant des exceptions sans être obligé de remettre en cause les règles précédemment établies à chaque fois qu'une nouvelle exception apparaît. Une théorie des défauts est un couple {W, D} où W est un ensemble de formules classiques de la logique du premier ordre et D un ensemble de défauts, qui sont des règles d'inférence spécifiques. Les défauts permettent de gérer les informations incomplètes [8]. Par exemple, en hiver, une règle générale utilisée par les arbitres de football pourrait être : «Un match de football doit avoir lieu, à moins qu’il n’y ait de la neige sur le stade ». Cette règle de base est représentée par un défaut : 56 La logique des défauts ��������: ¬����� �����_���� L’interprétation du défaut est la suivante : si on n’a pas l’information explicite qu'il y aura de la neige dans le stade, il est raisonnable de supposer qu’il n’y aura pas de neige (¬neige) et de conclure que le match aura lieu. On peut donc préparer le match. Mais s’il y a une forte chute de neige pendant la nuit avant le match, cette hypothèse n’est plus valide. On sait qu'il y a de la neige, et il est donc impossible d’assumer ¬neige, donc le défaut ne peut pas être appliqué. Dans ce cas, il faut renoncer à la conclusion précédente (le match aura lieu). Le raisonnement est donc non-monotone. La logique classique n’est pas appropriée pour modéliser cette situation. En effet, on pourrait tenter d’utiliser la formule football ∧ ¬neige → avoir_lieu Le problème avec cette règle, c'est qu’il faut établir de façon définitive qu'il n'y aura pas de neige dans le stade avant d'appliquer la règle. Pour résoudre ce problème, le même exemple aurait pu être représenté par le défaut ��������: �����_���� �����_���� avec la règle de logique classique neige → ¬avoir_lieu. Si la neige est certaine alors on déduit ¬avoir_lieu par la logique classique, donc on ne peut pas inférer avoir_lieu par le défaut. Dans cette représentation, le défaut est une règle qui dit que les matchs se déroulent généralement et les exceptions de cette règle sont représentées par les règles classiques telles que celle ci-dessus. Les défauts peuvent être utilisés pour modéliser le raisonnement prototypique, ce qui signifie que la plupart des instances d’un concept ont une certaine propriété. Un exemple est l’énoncé « Typiquement, l’enfant a des parents (vivants) », qui peut être exprimé par le défaut : ������(�): �����_�������(�) �����_�������(�) Une autre forme de raisonnement par défaut est le raisonnement sans-risque. Il s'agit de situations où une conclusion peut être tirée, même si ce n'est pas le plus probable, car une autre décision peut conduire à une catastrophe. Par exemple « En l'absence de preuve contraire présumer que l'accusé est innocent, s’exprime par : �����é(�): ��������(�) ��������(�)La logique des défauts 57 On donne aussi des hiérarchies avec des exceptions qui sont en biologie. L’exemple classique est « En règle générale, les oiseaux volent », « les manchots sont les oiseaux », « les manchots ne volent pas ». On a alors le défaut: ������(�): ����(�) ����(�) avec la règle de logique classique : manchot(X) → oiseau(X)∧¬vole(X) Les défauts peuvent être aussi utilisés pour modéliser l’hypothèse du monde clos de Reiter, utilisée pour les bases de données et pour la programmation logique. Selon cette hypothèse, un domaine d’application est décrit par un ensemble de formules logiques F. En simplifiant, l’hypothèse du monde clos dit qu’une information élémentaire positive (un atome) ϕ est considéré comme faux si F n’implique pas logiquement ϕ. Ceci peut se représenter par un défaut normal sans prérequis : ����: ¬ϕ ¬ϕ On encore, s’il est consistant d’assumer ¬ϕ (ce qui est équivalent à ne pas avoir de preuve pour ϕ), on conclue ¬ϕ 3.3. Syntaxe de la logique des défauts. Une théorie des défauts ∆ = (D, W) est une paire (D, W), contenant un ensemble W de formules de la logique des prédicats (appelées faits ou axiomes) et un ensemble dénombrable D de défauts. Dans sa forme la plus générale, un défaut d s’écrit : � = �:�1,�2, … �� � où A, B1,…, Bn et C sont des formules logiques bien formées du premier ordre. La formule A est le prérequis, les formules B1,…, Bn sont les justifications et C est le conséquent. Un défaut signifie informellement : si A est vérifié, et s’il est possible que B1,…, Bn soient vrais alors C est inféré. Un défaut d est appelé normal si et seulement si sa justification est égale à son prérequis, donc s’il est de la forme : � = �: � � Un défaut peut contenir des variables libres, par exemple : ������(�): ����(�) ����(�)58 La logique des défauts Ces défauts sont appelés défauts ouverts. Dans ce cas le défaut ouvert est considéré comme l’ensemble des défauts où X a été remplacée par tous les termes terminaux (sans variables) du langage. Un défaut ouvert représente donc un ensemble de défauts fermés qui peut éventuellement être infini. 3.4. Extensions. L'utilisation des défauts augmente le nombre de formules déduites de la base de connaissance W : nous obtenons alors des extensions qui sont des ensembles de théorèmes dérivables de façon monotone. Intuitivement une extension est obtenue en utilisant un ensemble maximal consistant de défauts possibles. Cette définition va entrainer qu’il pourra exister plusieurs extensions éventuellement contradictoires. 3.4.1. Extensions - définition formelle. Une extension de la théorie des défauts ∆ = (D,W) est un ensemble E de formules, clos pour la déduction, contenant W et vérifiant la propriété suivante : si d est un défaut de D dont le prérequis est dans E, sans que la négation de sa justification soit dans E, alors le conséquent de d est dans E. Plus formellement, les extensions sont définies de la façon suivante. Définition 3.1: E est une extension de ∆ si et seulement si � = ⋃�=0,∞ �� , avec : 1) E0 = W 2) Pour tout i, ��+1 = �ℎ(�� ∪ {�/� = (�:� � ) ∈ �, � ∈ �� , ¬�∉�}) où Th(F) désigne l'ensemble des théorèmes obtenus en logique classique à partir de F, c’est à dire Th(F) = {w/F ⊢ w}. Remarque : Il est important de noter que E apparaît dans la définition de Ei+1. Donc dans le cas général il peut ne pas être possible de construire E car à cause de la condition ¬B ∉ E, il faut déjà connaître E pour construire E. La définition n’est donc pas constructive. Ceci peut être très gênant mais si l’on utilise uniquement des défauts normaux, la condition ¬B ∉ E se transforme en ¬B ∉ Ei . Cette fois, il suffit de vérifier que la négation de la justification n'appartient pas à Ei . Un algorithme récursif peut donc être utilisé pour calculer E. De plus lorsque tous les défauts sont normaux et que W est satisfaisable, l'existence d'au moins une extension est assurée. Exemple 3.1: Soit ∆ = (D, W), où W = {a}, et D contient les défauts normaux suivants : �1 = �:¬� ¬� �2 = �: � �La logique des défauts 59 On obtient avec la définition des extensions une extension E = Th({a, ¬b}) en utilisant le défaut d1. Dans ce cas d2 ne pas être utilisé car comme ¬b ∈ E, la justification de d2 n’est pas vérifiée. Exemple 3.2: C’est l’exemple classique. On sait que Les manchots sont des oiseaux et que Titi est un manchot. Ceci va s’exprimer par W composé de deux formules de la logique des prédicats : W = {∀x, Manchot(x) → Oiseau(x), Manchot(Titi)} On sait aussi que Sauf exception, les oiseaux volent et que Sauf exception, les manchots ne volent pas. On exprime ceci par un ensemble de deux défauts normaux D = {d1, d2} : d1 = Oiseau(x):Vole(x)/Vole(x) d2 = Manchot(x):¬Vole(x)/ ¬Vole(x) Le défaut d1 peut aussi s’exprimer par : Si x est un oiseau et qu'il est consistant de supposer que x peut voler, alors on conclue que x peut voler. On voit que si l’on utilisait les deux défauts en même temps on obtiendrait que Vole(Titi) et ¬Vole(Titi) ce qui est insatisfaisable. Pour cet exemple, on aura deux extensions. On a deux cas : Cas 1: Dans ce cas on va commencer à construite l’extension en utilisant le défaut d1 - On part de E0 = W = Th({Manchot(Titi) → Oiseau(Titi), Manchot(Titi), Oiseau(Titi)}) - On utilise alors d1. Le prérequis de d1, Oiseau(Titi) est dans E0. La négation de la justification de d1, ¬vole(Titi), n’est pas dans E0. Donc avec la définition d’une extension, on peut ajouter Vole(Titi) à E0 pour obtenir E1. E1 = Th({E0) ∪ Vole(Titi)}) - Ensuite on essaie d’utiliser d2 pour compléter E1. Le prérequis Manchot(Titi) est bien dans E1. Mais Vole(Titi) qui est la négation de la justification de d2, est dans E1. Il est impossible d’utiliser d2. Le calcul s’arrête et la première extension est E1. Dans cette extension, Titi vole. Cas 2: On va maintenant commencer la construction de l’extension en utilisant d2 - On part de E0 = W = Th({Manchot(Titi) → Oiseau(Titi), Manchot(Titi), Oiseau(Titi)}) - On utilise alors d2. Le prérequis de d2, Manchot(Titi) est dans E0. La négation de la justification de d2, Vole(Titi) n’est pas dans E0. Donc avec la définition d’une extension, on peut ajouter ¬Vole(Titi) à E0 pour obtenir E1. E1 = Th({E0) ∪ ¬Vole(Titi)}) - Ensuite on essaie d’utiliser d1 pour compléter E1. Le prérequis Manchot(Titi) est bien dans E1. Mais Vole(Titi) qui est la négation de la justification de d2, est dans E1. Il est impossible 60 La logique des défauts d’utiliser d2. Le calcul s’arrête et on a une deuxième extension dans laquelle Titi ne vole pas. Figure 3.1. Arbre de recherche des solutions pour le calcul d'extensions On obtient donc deux extensions qui sont contradictoires. Si nous cherchons à répondre à la question : "Est-ce que Titi vole ?", il faut pouvoir choisir entre ces deux extensions. On peut par exemple préférer les défauts les plus particuliers, ou encore établir des préférences entre les défauts. Comme nous venons de voir dans cet exemple, les théories des défauts peuvent avoir plusieurs extensions. Il y a également des cas où elles n’ont pas d’extension. Dans certains cas, ces défauts classiques peuvent donc poser des problèmes. Mais il est démontré qu’il existe toujours une extension si W est satisfaisable et tous les défauts sont normaux [23]. 3.6 Algorithme de calcul d’extensions. Avant de décrire l’algorithme, on généralise la définition d’une extension en considérant qu’un défaut peu avoir plusieurs prérequis. Pour que la logique des défauts travaille dans le domaine de temps discret, il faut ajouter un argument temporal ti . L’ensemble de faits W = {w1, w2, …} est représenté avec l’argument comme W = {(w1,t0), (w2,t0), …}. Une extension de la théorie des défauts ∆ = (D, W) est un ensemble E de formules, clos pour la déduction, contenant W et vérifiant la propriété suivante : si d est un défaut de D dont les prérequis A(X) (avec tk) sont dans E, sans que la négation des justifications Bi(X) ne soient dans E, alors le conséquent C(X) (avec tk+1) de d est dans E. Formellement, les extensions sont définies de la façon suivante : E est une extension de ∆ si et seulement si � = ⋃�=0,∞ �� , avec E0 = W (avec t0) et pour i >0, �� = �ℎ(��−1) ∪ {(�(�), t�+1)/( �(�):�� (X) �(�) ) ∈ �, (�(�), t� ), ∈ ��−1, ¬��(X)∉��−1} où Th(Ei-1) désigne l'ensemble des théorèmes obtenus de façon monotone à partir de ��−1: �ℎ(��−1) = {�/��−1├�}. La logique des défauts 61 Pour une théorie des défauts ∆ = (D, W), avec D l'ensemble des défauts et W la base de connaissance, le calcul d'extension se fait par l'algorithme : Entrée : D ; (ensemble des défauts). � = ∅; (ensemble d'extension). Sortie : � =∪�=0,� �� . calcul_extension(Ei) :{ Ei := W (en moment t0); tantque il y a un défaut � = �(�):�� (�) �(�) qui n'a pas encore été inspecté faire - Sélectionner ce défaut d, - Vérifier que les prérequis A(X) sont vrais avec Ei (en moment tk), - Vérifier que les justifications Bj(X) sont consistantes avec Ei (utiliser la négation par échec en cas d'inconsistance), - Ajouter (C(X), tk+1)) à Ei fin tantque Fin du calcul pour une extension. Backtracking (Suppression des (C(X), tk+1) ajoutés à Ei). calcul_extension(Ei). } Approche proposée et résultats 63 Chapitre 4. Approche proposée et résultats 4.1. Utilisation de l’algorithme de production de clauses. On revient à la carte d’interactions de Pommier. Pour passer du modèle biologique au modèle logique, il faut considérer plusieurs contraintes : comment modéliser les interactions, bien faire attention aux sens des implications logiques, respecter l'ordre chronologique préalablement défini et vérifier la cohérence des informations [15]. L'étape initiale est de définir correctement les prédicats. Ici les prédicats ont été calqués sur ceux de la carte de Pommier, à savoir stimulation, phosphorylation, autophosphorylation, inhibition, nécessité, liaison, activation de transcription, dégradation et déphosphorylation. Au départ, les prédicats ont été conceptualisés, pour la majorité d'entre eux, de la façon suivante : produit ⃪ réaction(enzyme, substrat). La réaction peut être stimulation, phosphorylation, déphosphorylation, liaison, activation ou dégradation. Par exemple, p*-Y ⃪ phosphorylation(X, Y). Les autres prédicats qui ne sont pas de type produit ⃪ réaction(enzyme, substrat) sont modélisés séparément : p*-Y ⃪ autophosphorylation(Y) ¬Y ⃪ inhibition(X, Y) : si X est vrai, alors Y ne peut pas l’être Y ⃪ nécessité(X, Y) : pour que Y soit vrai, X doit être vrai En effet, certains prédicats ont été modifiés, ou bien supprimés, au cours de l’implémentation, tandis que d’autres ont été rajoutés grâce aux mises à jours effectuées dans le modèle biologique et avec l’avancement de son implémentation dans Prolog. Par exemple, les prédicats ajoutés sont ubiquitination, méthylation et dissociation. Dans ce programme, cnf(nom_de_clause, type_de_clause, [littéraux]) indique une clause. Pour la partie contenant des littéraux, chaque disjonction doit être indiquée par une virgule, une négation par un signe moins, le signe plus peut être « oublié ». Voici un exemple qu’on souhaite mettre au format de Prolog : • D’abord, γH2AX se lie avec Mdc1. • Ensuite, ATM peut phosphoryler Mdc1 liée à γH2AX. • Mdc1, une fois phosphorylée, va se lier avec Rnf8. • Enfin, Rnf8 va se lier avec Ubc13. C’est modélisé par les équations logiques suivant les prédicats : • Produit(γH2AX) → liaison(γH2AX, MDC1). • Liaison(γH2AX, MDC1) → produit(γH2AX/MDC1). • Produit(γH2AX/MDC1) → phosphorylation(ATM, γH2AX/MDC1). • Phosphorylation(ATM, γH2AX/MDC1) → produit(p*-MDC1). • Produit(p*-MDC1) → liaison(p*-MDC1, MRF8).64 Approche proposée et résultats • Liaison(p*-MDC1, MRF8) → produit(MRF8_liée). • Produit(MRF8_liée) → liaison(MRF8_liée, UBC13). • Liaison(MRF8_liée, UBC13) → produit(MRF8/UBC13) De façon plus intuitive, ceci peut être présenté par l’image ci – dessous : Dans la Figure 4.1, une flèche à deux têtes présente une liaison, une flèche à une tête présente une production, et une flèche brisée est une phosphorylation. Suite, on replace les implications en utilisant les équivalences (A → B ≡ ¬A ⋁ B) : • ¬Produit(γH2AX) ⋁ liaison(γH2AX, MDC1). • ¬Liaison(γH2AX, MDC1) ⋁ produit(γH2AX/MDC1). • ¬Produit(γH2AX/MDC1) ⋁ phosphorylation(ATM, γH2AX/MDC1). • ¬Phosphorylation(ATM, γH2AX/MDC1) ⋁ produit(p*-MDC1). • ¬Produit(p*-MDC1) ⋁ liaison(p*-MDC1, MRF8). • ¬Liaison(p*-MDC1, MRF8) ⋁ produit(MRF8_liée). • ¬Produit(MRF8_liée) ⋁ liaison(MRF8_liée, UBC13). • ¬Liaison(MRF8_liée, UBC13) ⋁ produit(MRF8/UBC13) Enfin, on adapte les équations au format de Prolog : • cnf(mdc1_1, axiom, [-product(gamma_h2ax),binding(gamma_h2ax,mdc1)]). • cnf(mdc1_2, axiom, [-binding(gamma_h2ax,mdc1),product(h2ax_mdc1)]). • cnf(mdc1_3,axiom,[product(h2ax_mdc1), phosphorylation(p_atm_bound,h2ax_mdc1)]). • cnf(mdc1_4, axiom, [-phosphorylation(p_atm_bound,h2ax_mdc1),product(p_mdc1)]). • cnf(rnf_01, axiom, [-product(p_mdc1),binding(p_mdc1,rnf8)]). • cnf(rnf_02, axiom, [-binding(p_mdc1,rnf8),product(rnf8_bound)]). • cnf(rnf_03, axiom, [-product(rnf8_bound),binding(rnf8_bound,ubc13)]). • cnf(rnf_04, axiom, [-binding(rnf8_bound,ubc13),product(rnf8_ubc13)]). ATM γH2AX/MDC1 γH2AX MDC1 P*-MDC1 MRF8 MRF8_liée UBC13 MRF8/UBC13 Figure 4.1. Interactions de la carte de PommierApproche proposée et résultats 65 À partir de la carte, avec la modélisation, on a adapté la base de données au format de Prolog. Les lignes ci-dessous sont celles utilisées dans le modèle et qui relatent les événements biologiques précédemment indiques : /****************************************/ cnf(mrn_0, axiom, [-product(dsb),stimulation(dsb,dna)]). cnf(mrn_1, axiom, [-stimulation(dsb,dna),product(altered_dna)]). cnf(mrn_2, axiom, [-product(altered_dna),binding(mre11,rad50)]). cnf(mrn_3, axiom, [-binding(mre11,rad50),product(mre11_rad50)]). cnf(mrn_4, axiom, [-product(mre11_rad50),binding(mre11_rad50,nbs1)]). cnf(mrn_5, axiom, [-binding(mre11_rad50,nbs1),product(mrn)]). cnf(mrn_6, axiom, [-product(mrn),binding(mrn,altered_dna)]). cnf(mrn_7, axiom, [-binding(mrn,altered_dna),product(mrn_bound_to_dna)]). cnf(atm_1, axiom, [-product(mrn_bound_to_dna),binding(mrn_bound_to_dna,atm_atm)]). cnf(atm_2, axiom, [-binding(mrn_bound_to_dna,atm_atm),product(atm_bound_to_mrn)]). cnf(atm_3, axiom, [-product(atm_bound_to_mrn),-product(atm_atm)]). cnf(atm_4, axiom, [-product(atm_bound_to_mrn),autophosphorylation(atm_bound_to_mrn)]). cnf(atm_5, axiom, [-autophosphorylation(atm_bound_to_mrn),product(p_atm_atm_bound)]). cnf(atm_6, axiom, [-product(p_atm_atm_bound),-product(atm_atm)]). cnf(atm_7, axiom, [-product(p_atm_atm_bound),dissociation(p_atm_atm_bound)]). cnf(atm_8, axiom, [-dissociation(p_atm_atm_bound),product(p_atm_bound)]). cnf(atm_9, axiom, [-dissociation(p_atm_atm_bound),product(p_atm_free)]). %Chk1 Phosphorylation cnf(chk1_1, axiom, [-product(p_atm_free),phosphorylation(p_atm_free,chk1)]). cnf(chk1_2, axiom, [-phosphorylation(p_atm_free,chk1),product(p_chk1)]). cnf(chk1_3, axiom, [phosphorylation(atr,chk1)]). cnf(chk1_4, axiom, [-phosphorylation(atr,chk1),product(p_chk1)]). %Other MRN needs cnf(mrn_add_1, axiom, [-product(mrn_bound_to_dna),product(p_smc1)]). cnf(mrn_add_2, axiom, [-product(mrn_bound_to_dna),product(p_mre11)]). %gamma-H2AX cnf(h2ax_1, axiom, [-phosphorylation(atr,h2ax),product(gamma_h2ax)]). cnf(h2ax_2, axiom, [-phosphorylation(p_atm_bound,h2ax),product(gamma_h2ax)]). %MDC1, Ubiquitination and BRCA1 cnf(mdc1_1, axiom, [-product(gamma_h2ax),binding(gamma_h2ax,mdc1)]). cnf(mdc1_2, axiom, [-binding(gamma_h2ax,mdc1),product(h2ax_mdc1)]). cnf(mdc1_3, axiom, [-product(h2ax_mdc1),phosphorylation(p_atm_bound,h2ax_mdc1)]). cnf(mdc1_4, axiom, [-phosphorylation(p_atm_bound,h2ax_mdc1),product(p_mdc1)]). cnf(rnf_01, axiom, [-product(p_mdc1),binding(p_mdc1,rnf8)]). cnf(rnf_02, axiom, [-binding(p_mdc1,rnf8),product(rnf8_bound)]). cnf(rnf_03, axiom, [-product(rnf8_bound),binding(rnf8_bound,ubc13)]). cnf(rnf_04, axiom, [-binding(rnf8_bound,ubc13),product(rnf8_ubc13)]). cnf(rnf_05, axiom, [-product(rnf8_ubc13),ubiquitination(rnf8_ubc13,h2a)]). cnf(rnf_06, axiom, [-ubiquitination(rnf8_ubc13,h2a),product(ub_h2a)]). cnf(rnf_07, axiom, [-product(ub_h2a),binding(ub_h2a,rnf168)]). cnf(rnf_08, axiom, [-binding(ub_h2a,rnf168),product(rnf168_bound)]). cnf(rnf_09, axiom, [-product(rnf168_bound),binding(rnf168_bound,ubc13)]). 66 Approche proposée et résultats cnf(rnf_10, axiom, [-binding(rnf168_bound,ubc13),product(rnf168_ubc13)]). cnf(rnf_11, axiom, [-product(rnf168_ubc13),ubiquitination(rnf168_ubc13,h2a)]). cnf(rnf_12, axiom, [-ubiquitination(rnf168_ubc13,h2a),product(poly_ub_h2a)]). cnf(rnf_13, axiom, [-product(poly_ub_h2a),stimulation(poly_ub_h2a,dna)]). cnf(rnf_14, axiom, [-stimulation(poly_ub_h2a,dna),product(changed_struct_dna)]). cnf(rap_01, axiom, [-product(poly_ub_h2a),binding(poly_ub_h2a,rap80)]). cnf(rap_02, axiom, [-binding(poly_ub_h2a,rap80),product(rap80_bound)]). cnf(rap_03, axiom, [-product(rap80_bound),binding(rap80_bound,abraxas)]). cnf(rap_04, axiom, [-binding(rap80_bound,abraxas),product(abraxas_bound)]). cnf(rap_05, axiom, [-product(abraxas_bound),binding(abraxas_bound,bre)]). cnf(rap_06, axiom, [-binding(abraxas_bound,bre),product(bre_bound)]). cnf(rap_07, axiom, [-product(abraxas_bound),binding(abraxas_bound,brcc36)]). cnf(rap_08, axiom, [-binding(abraxas_bound,brcc36),product(brcc36_bound)]). cnf(rap_09, axiom, [-product(brcc36_bound),binding(brcc36_bound,merit40)]). cnf(rap_10, axiom, [-binding(brcc36_bound,merit40),product(merit40_bound)]). cnf(rap_10, axiom, [-product(merit40_bound),binding(merit40_bound,brcc36_bound)]). cnf(rap_11, axiom, [-binding(merit40_bound,brcc36_bound),product(brcc36_merit40)]). cnf(rap_12, axiom, [-product(brcc36_merit40),binding(brcc36_merit40,brca1)]). cnf(rap_13, axiom, [-binding(brcc36_merit40,brca1),product(brca1_bound_to_rap80_complex)]). %53BP1 binding cnf(mmset_1, axiom, [-product(changed_struct_dna),phosphorylation(p_atm_bound,mmset)]). cnf(mmset_2, axiom, [-phosphorylation(p_atm_bound,mmset),product(p_mmset)]). cnf(mmset_3, axiom, [-product(h2ax_mdc1),binding(h2ax_mdc1,mdc1)]). cnf(mmset_4, axiom, [-binding(h2ax_mdc1,mdc1),product(mdc1_multi)]). cnf(mmset_5, axiom, [-product(mdc1_multi),-product(p_mmset),binding(mdc1_multi,p_mmset)]). cnf(mmset_6, axiom, [-binding(mdc1_multi,p_mmset),product(mmset_mdc1)]). cnf(mmset_7, axiom, [-product(mmset_mdc1),methylation(mmset_mdc1,h4)]). cnf(mmset_8, axiom, [-methylation(mmset_mdc1,h4),product(h4k20me2)]). cnf(p53bp1_1,axiom,[-product(h4k20me2),-product(brca1_bound_to_rap80_complex), binding(h4k20me2,p53bp1)]). cnf(p53bp1_2, axiom, [-binding(h4k20me2,p53bp1),product(p53bp1_bound)]). cnf(p53bp1_3, axiom, [-product(p53bp1_bound),phosphorylation(p_atm_bound,p53bp1_bound)]). cnf(p53bp1_4, axiom, [-phosphorylation(p_atm_bound,p53bp1_bound),product(p_53bp1)]). %Chk2 formation with Plk3 action (and binding with 53bp1) cnf(plk3_1, axiom, [-product(p_atm_free),phosphorylation(p_atm_free,plk3)]). cnf(plk3_2, axiom, [-phosphorylation(p_atm_free,plk3),product(p_plk3)]). cnf(chk2_01, axiom, [-product(p_atm_free),phosphorylation(p_atm_free,chk2)]). cnf(chk2_02, axiom, [-phosphorylation(p_atm_free,chk2),product(p_s33_35_chk2)]). cnf(chk2_03, axiom, [-product(p_s33_35_chk2),phosphorylation(p_plk3,p_s33_35_chk2)]). cnf(chk2_04, axiom, [-phosphorylation(p_plk3,p_s33_35_chk2),product(p_s33_35_s62_73_chk2)]). cnf(chk2_05,axiom,[-product(p_s33_35_s62_73_chk2), phosphorylation(p_atm_free,p_s33_35_s62_73_chk2)]). cnf(chk2_06, axiom, [-phosphorylation(p_atm_free,p_s33_35_s62_73_chk2),product(p_t68_chk2)]). cnf(chk2_07,axiom,[-product(p_s33_35_s62_73_chk2), phosphorylation(atr,p_s33_35_s62_73_chk2)]). cnf(chk2_08, axiom, [-phosphorylation(atr,p_s33_35_s62_73_chk2),product(p_t68_chk2)]). cnf(chk2_09, axiom, [-product(p_t68_chk2),binding(p_t68_chk2,p_t68_chk2)]). cnf(chk2_10, axiom, [-binding(p_t68_chk2,p_t68_chk2),product(chk2_chk2)]). cnf(chk2_11, axiom, [-product(chk2_chk2),autophosphorylation(chk2_chk2)]). cnf(chk2_12, axiom, [-autophosphorylation(chk2_chk2),product(p_active_chk2_chk2)]). cnf(chk2_13,axiom,[-product(p_active_chk2_chk2),-product(p_53bp1), binding(p_active_chk2_chk2,p_53bp1)]). Approche proposée et résultats 67 cnf(chk2_13, axiom, [-binding(p_active_chk2_chk2,p_53bp1),product(chk2_53bp1)]). %BRCA1 regulation by CtIP and Chk2 cnf(ctip_1, axiom, [binding(brca1,ctip)]). cnf(ctip_2, axiom, [-binding(brca1,ctip),product(brca1_ctip)]). cnf(ctip_3, axiom, [-product(brca1_ctip),-product(chk2_53bp1),binding(brca1_ctip,chk2_53bp1)]). cnf(ctip_4, axiom, [-binding(brca1_ctip,chk2_53bp1),product(chk2_53bp1_bound_to_brca1)]). cnf(ctip_5, axiom, [-binding(brca1_ctip,chk2_53bp1),product(brca1_ctip_bound_to_chk2)]). cnf(ctip_6,axiom,[-product(chk2_53bp1_bound_to_brca1),-product(brca1_ctip_bound_to_chk2), phosphorylation(chk2_53bp1_bound_to_brca1,brca1_ctip_bound_to_chk2)]). cnf(ctip_7,axiom,[-phosphorylation(chk2_53bp1_bound_to_brca1,brca1_ctip_bound_to_chk2), product(p_brca1_ctip_bound_to_chk2)]). cnf(ctip_8, axiom, [-product(p_brca1_ctip_bound_to_chk2),product(p_s988_brca_ctip)]). cnf(ctip_9, axiom, [-product(chk2_53bp1_bound_to_brca1),product(chk2_53bp1)]). cnf(brca1_0,axiom,[-product(p_s988_brca_ctip), phosphorylation(p_atm_bound,p_s988_brca_ctip)]). cnf(brca1_1, axiom, [-phosphorylation(p_atm_bound,p_s988_brca_ctip),product(brca_p_ctip)]). cnf(brca1_2, axiom, [-product(brca_p_ctip),-product(brca1_ctip)]). cnf(brca1_3, axiom, [-product(brca_p_ctip),dissociation(brca_p_ctip)]). cnf(brca1_4, axiom, [-dissociation(brca_p_ctip),product(brca1)]). cnf(brca1_5, axiom, [-dissociation(brca_p_ctip),product(p_ctip)]). cnf(brca1_6, axiom, [-product(brca1),phosphorylation(p_atm_bound,brca1)]). cnf(brca1_7, axiom, [-phosphorylation(p_atm_bound,brca1),product(p_brca1)]). cnf(brca1_8, axiom, [-product(brca1),phosphorylation(atr,brca1)]). cnf(brca1_9, axiom, [-phosphorylation(atr,brca1),product(p_brca1)]). %DNA repair proposed mecasism cnf(repa_1, axiom, [-product(p_brca1),-product(p_53bp1),binding(mrn_bound_to_dna,p_brca1)]). cnf(repa_2, axiom, [-binding(mrn_bound_to_dna,p_brca1),product(brca1_bound_to_mrn)]). %p53 pathway and regulation including PML cnf(pml_1, axiom, [-product(chk2_53bp1),phosphorylation(chk2_53bp1,pml)]). cnf(pml_2, axiom, [-phosphorylation(chk2_53bp1,pml),product(p_pml)]). cnf(pml_3, axiom, [-product(p_pml),stimulation(p_pml,cell)]). cnf(pml_4, axiom, [-stimulation(p_pml,cell),product(apoptosis)]). cnf(pml_5, axiom, [-product(p_pml),binding(p_pml,mdm2)]). cnf(pml_6, axiom, [-binding(p_pml,mdm2),product(pml_mdm2)]). cnf(pml_7, axiom, [-product(pml_mdm2),-binding(mdm2,p53)]). cnf(mdm2_1, axiom, [product(p53)]). cnf(mdm2_2, axiom, [-product(mdm2),-product(p53),binding(mdm2,p53)]). cnf(mdm2_3, axiom, [-binding(mdm2,p53),product(mdm2_p53)]). cnf(mdm2_4, axiom, [-product(mdm2_p53),stimulation(p53_degradation_effectors,mdm2_p53)]). cnf(mdm2_5,axiom,[-stimulation(p53_degradation_effectors,mdm2_p53), product(p53_degradation)]). cnf(p53_01,axiom,[-product(p_atm_free),-product(mdm2_p53), phosphorylation(p_atm_free,mdm2_p53)]). cnf(p53_02, axiom, [-phosphorylation(p_atm_free,mdm2_p53),product(p_s15_p53_mdm2)]). cnf(p53_03, axiom, [-product(mdm2_p53),phosphorylation(atr,mdm2_p53)]). cnf(p53_04, axiom, [-phosphorylation(atr,mdm2_p53),product(p_s15_p53_mdm2)]). cnf(p53_05,axiom,[-product(p_s15_p53_mdm2),-product(chk2_53bp1), phosphorylation(chk2_53bp1,p_s15_p53_mdm2)]). cnf(p53_06, axiom, [-phosphorylation(chk2_53bp1,p_s15_p53_mdm2),product(p_p_p53_mdm2)]). cnf(p53_07,axiom,[-product(p_s15_p53_mdm2),-product(p_chk1), phosphorylation(p_chk1,p_s15_p53_mdm2)]). 68 Approche proposée et résultats cnf(p53_08, axiom, [-phosphorylation(p_chk1,p_s15_p53_mdm2),product(p_p_p53_mdm2)]). cnf(p53_09, axiom, [-product(p_s15_p53_mdm2),-product(p53_degradation)]). cnf(p53_10, axiom, [-product(p_p_p53_mdm2),-product(p53_degradation)]). cnf(p53_11, axiom, [-product(p_p_p53_mdm2),dissociation(p_p_p53_mdm2)]). cnf(p53_12, axiom, [-dissociation(p_p_p53_mdm2),product(p_p_p53)]). cnf(p53_13, axiom, [-dissociation(p_p_p53_mdm2),product(mdm2)]). cnf(p53_14, axiom, [-product(p_atm_free),-product(mdm2),phosphorylation(p_atm_free,mdm2)]). cnf(p53_15, axiom, [-phosphorylation(p_atm_free,mdm2),product(p_mdm2)]). cnf(p53_16, axiom, [-product(p_p_p53),binding(p300,p_p_p53)]). cnf(p53_17, axiom, [-product(p_pml),-binding(p300,p_p_p53),product(active_p53)]). cnf(p53_18,axiom,[-product(active_p53), transcription_activation(active_p53,prom_p21_gadd45)]). cnf(p53_19,axiom,[-transcription_activation(active_p53,prom_p21_gadd45), product(p21_and_gadd45)]). cnf(p53_19a, axiom, [-product(p21_and_gadd45),stimulation(p21_and_gadd45,cell_cycle)]). cnf(p53_20, axiom, [-stimulation(p21_and_gadd45,cell_cycle),product(cell_cycle_arrest)]). cnf(p53_21, axiom, [-product(active_p53),transcription_activation(active_p53,prom_bnpf)]). cnf(p53_22,axiom,[-transcription_activation(active_p53,prom_bnpf), product(box_nas_puma_fas)]). cnf(p53_23, axiom, [-product(box_nas_puma_fas),stimulation(box_nas_puma_fas,cell)]). cnf(p53_24, axiom, [-stimulation(box_nas_puma_fas,cell),product(apoptosis)]). cnf(p53_21, axiom, [-product(active_p53),transcription_activation(active_p53,prom_mdm2)]). cnf(p53_22, axiom, [-transcription_activation(active_p53,prom_mdm2),product(mdm2)]). %E2F1 action cnf(e2f1_00, axiom, [product(e2f1)]). cnf(e2f1_01, axiom, [-product(e2f1),-product(chk2_53bp1),phosphorylation(chk2_53bp1,e2f1)]). cnf(e2f1_02, axiom, [-phosphorylation(chk2_53bp1,e2f1),product(p_e2f1)]). cnf(e2f1_03, axiom, [-product(e2f1),stimulation(e2f1_degradation_effectors,e2f1)]). cnf(e2f1_04, axiom, [-stimulation(e2f1_degradation_effectors,e2f1),product(e2f1_degradation)]). cnf(e2f1_05, axiom, [-product(p_e2f1),-product(e2f1_degradation)]). cnf(e2f1_06, axiom, [-product(p_e2f1),phosphorylation(p_atm_free,p_e2f1)]). cnf(e2f1_07, axiom, [-phosphorylation(p_atm_free,p_e2f1),product(p_p_e2f1)]). cnf(e2f1_08, axiom, [-product(p_e2f1),phosphorylation(atr,p_e2f1)]). cnf(e2f1_09, axiom, [-phosphorylation(atr,p_e2f1),product(p_p_e2f1)]). cnf(e2f1_10, axiom, [-product(p_p_e2f1),transcription_activation(p_p_e2f1,prom_chk2)]). cnf(e2f1_11, axiom, [-transcription_activation(p_p_e2f1,prom_chk2),product(chk2)]). cnf(e2f1_12, axiom, [-product(p_p_e2f1),transcription_activation(p_p_e2f1,prom_arf)]). cnf(e2f1_13, axiom, [-transcription_activation(p_p_e2f1,prom_arf),product(arf)]). cnf(e2f1_14, axiom, [-product(p_p_e2f1),transcription_activation(p_p_e2f1,prom_p73_apaf1)]). cnf(e2f1_15, axiom, [-transcription_activation(p_p_e2f1,prom_p73_apaf1),product(p73_apaf1)]). cnf(e2f1_16, axiom, [-product(p73_apaf1),stimulation(p73_apaf1,cell)]). cnf(e2f1_17, axiom, [-stimulation(p73_apaf1,cell),product(apoptosis)]). cnf(e2f1_18, axiom, [-product(arf),binding(arf,mdm2)]). cnf(e2f1_19, axiom, [-binding(arf,mdm2),product(arf_mdm2)]). cnf(e2f1_20, axiom, [-product(arf_mdm2),-product(mdm2_p53)]). cnf(e2f1_21, axiom, [-product(p_p_e2f1),stimulation(p_p_e2f1,unknown_atm_way)]). cnf(e2f1_22, axiom, [-stimulation(p_p_e2f1,unknown_atm_way),product(p_atm_free)]). %p38 phosphorylation (usefull for cdc25c and cdc25b) cnf(p38_1, axiom, [-product(p_atm_free),phosphorylation(p_atm_free,p38)]). cnf(p38_2, axiom, [-phosphorylation(p_atm_free,p38),product(p_p38)]). %Cdc25 regulation cnf(cdc25a_0, axiom, [-stimulation(cdc25a,cell),-product(cell_cycle_arrest)]).Approche proposée et résultats 69 cnf(cdc25a_1, axiom, [-product(chk2_53bp1),phosphorylation(chk2_53bp1,cdc25a)]). cnf(cdc25a_2, axiom, [-phosphorylation(chk2_53bp1,cdc25a),product(p_cdc25a)]). cnf(cdc25a_3, axiom, [-product(p_chk1),phosphorylation(p_chk1,cdc25a)]). cnf(cdc25a_4, axiom, [-phosphorylation(p_chk1,cdc25a),product(p_cdc25a)]). cnf(cdc25a_5, axiom, [-product(p_cdc25a),stimulation(p_cdc25a,cdc25a_degradation_effectors)]). cnf(cdc25a_6,axiom,[-stimulation(p_cdc25a,cdc25a_degradation_effectors), product(cdc25a_degradation)]). cnf(cdc25a_7, axiom, [-product(cdc25a_degradation),-stimulation(cdc25a,cell)]). cnf(cdc25c_00, axiom, [-stimulation(cdc25c,cell),-product(cell_cycle_arrest)]). cnf(cdc25c_01, axiom, [-product(chk2_53bp1),phosphorylation(chk2_53bp1,cdc25c)]). cnf(cdc25c_02, axiom, [-phosphorylation(chk2_53bp1,cdc25c),product(p_cdc25c)]). cnf(cdc25c_03, axiom, [-product(p_plk3),phosphorylation(p_plk3,cdc25c)]). cnf(cdc25c_04, axiom, [-phosphorylation(p_plk3,cdc25c),product(p_cdc25c)]). cnf(cdc25c_05, axiom, [-product(p_chk1),phosphorylation(p_chk1,cdc25c)]). cnf(cdc25c_06, axiom, [-phosphorylation(p_chk1,cdc25c),product(p_cdc25c)]). cnf(cdc25c_07, axiom, [-product(p_p38),phosphorylation(p_p38,cdc25c)]). cnf(cdc25c_08, axiom, [-phosphorylation(p_p38,cdc25c),product(p_cdc25c)]). cnf(cdc25c_09, axiom, [-product(p_cdc25c),stimulation(p_cdc25c,cdc25c_degradation_effectors)]). cnf(cdc25c_10,axiom,[-stimulation(p_cdc25c,cdc25c_degradation_effectors), product(cdc25c_degradation)]). cnf(cdc25c_11, axiom, [-product(cdc25c_degradation),-stimulation(cdc25c,cell)]). cnf(cdc25b_1, axiom, [-stimulation(cdc25b,cell),-product(cell_cycle_arrest)]). cnf(cdc25b_2, axiom, [-product(p_p38),phosphorylation(p_p38,cdc25b)]). cnf(cdc25b_3, axiom, [-phosphorylation(p_p38,cdc25b),product(p_cdc25b)]). cnf(cdc25b_4, axiom, [-product(p_cdc25b),-stimulation(cdc25b,cell)]). %JNK actions (mechanisms quite unclear) cnf(jnk_1, axiom, [-stimulation(jnk,cdc25c),product(p_cdc25c)]). cnf(jnk_2, axiom, [-phosphorylation(jnk,p_s15_p53_mdm2),product(p_p_p53_mdm2)]). %FANCD2 first steps cnf(fancd2_1, axiom, [-product(p_atm_bound),phosphorylation(p_atm_bound,nbs1)]). cnf(fancd2_2, axiom, [-phosphorylation(p_atm_bound,nbs1),product(p_nbs1)]). cnf(fancd2_3, axiom, [-product(p_nbs1),phosphorylation(p_atm_bound,fancd2)]). cnf(fancd2_4, axiom, [-phosphorylation(p_atm_bound,fancd2),product(p_fancd2)]). cnf(fancd2_5, axiom, [-product(p_fancd2),stimulation(p_fancd2,cell)]). cnf(fancd2_6, axiom, [-stimulation(p_fancd2,cell),-product(cell_cycle_arrest)]). %Mus81 actions on DNA Repair cnf(mus81_1, axiom, [-product(chk2_53bp1),binding(chk2_53bp1,mus81)]). cnf(mus81_2, axiom, [-binding(chk2_53bp1,mus81),product(mus81_chk2)]). cnf(mus81_3, axiom, [-product(mus81_chk2),binding(mus81_chk2,altered_dna)]). cnf(mus81_4, axiom, [-binding(mus81_chk2,altered_dna),product(mus81_bound_to_dna)]). %cnf(mus81_5, axiom, [-binding(mus81_chk2,altered_dna),product(mus81_bound_to_dna)]). /****************************************/ Le résultat : Avec le champ de production champ([_,1,[stimulation(_,_)],_]), après l’exécution de programme, le résultat est donné Pour activer product(cell_cycle_arrest): -stimulation(p21_and_gadd45,cell_cycle) 70 Approche proposée et résultats % 261,290 inferences, 0.156 CPU in 20.794 seconds (1% CPU, 1674925 Lips) Pour bloquer product(cell_cycle_arrest) : -stimulation(cdc25a,cell) -stimulation(cdc25c,cell) -stimulation(cdc25b,cell) -stimulation(dsb,dna) -stimulation(p_fancd2,cell) % 18,008 inferences, 0.047 CPU in 7.993 seconds (1% CPU, 384784 Lips) Pour activer product(apoptosis) : -stimulation(p_pml,cell) -stimulation(box_nas_puma_fas,cell) -stimulation(p73_apaf1,cell) % 154,139 inferences, 0.094 CPU in 20.310 seconds (0% CPU, 1646774 Lips) Pour bloquer product(apoptosis), le résultat est un ensemble vide de clauses. 4.2. Utilisation de la logique des défauts 4.2.1. Dans le cas général La Figure 4.2 représente un exemple très simplifié d'interactions dans une cellule. Figure 4.2. Un exemple d’interactions dans une celluleApproche proposée et résultats 71 Par des mécanismes divers non indiqués ici, les ultraviolets (UV) mettent la cellule en apostase (elle devient de fait immortelle) d'où le cancer. Ceci est représenté par une flèche. D'un autre coté les UV activent la production de la protéine p53. Cette protéine va activer une protéine A qui va bloquer le cancer. Mais p53 liée à la protéine Mdm2 va produire B, qui va bloquer A. Pour un biologiste, la question est donc de bloquer le cancer en bloquant B. Les expériences biologiques ont montré que le X pourrait être un candidat pour ce blocage. Les figures (b) et (c) donnent deux types d'interactions possibles avec X pour expliquer ce blocage de B. Le problème est d'utiliser l'informatique pour compléter le graphe [3]. Pour décrire les interactions entre les gênes dans la figure, on part d’un langage L de logique classique (propositionnel ou du premier ordre). Dans L, la proposition A (resp ¬A) signifie que A est vrai (faux). Les interactions entres les gênes sont une forme très simple de causalité. Pour exprimer ces interactions il est courant d'aller à l'essentiel en donnant deux relations binaires cause(A, B) et bloque(A, B). La première relation veut dire, par exemple, qu'une protéine A déclenche la production d'une protéine B, la deuxième est l’inhibition. De manière classique, ces relations sont représentées dans le réseau de gênes, par A → B et A ⊣ B. Bien entendu, ces causalités sont élémentaires et de nombreux travaux très savants ont été écrits pour les représenter. Pour représenter les liens entre les relations, dans le langage L, il faut faire deux choses : décrire les propriétés internes aux relations cause et bloque ; décrire les liens entre ces relations. Les premières propriétés que l’on a envie de donner peuvent s’exprimer naturellement, par des règles du type : (1) Si A cause B et si A est vrai, alors B est vrai. (2) Si A bloque B et si A est vrai, alors B est faux. La solution élémentaire est alors de donner explicitement les deux schémas d'axiomes : (C1) cause(A,B) ∧ cause(B, C) → cause(A, C) (C2) cause(A, B) ∧ bloque (B, C) → bloque(A, C) La première idée est d'exprimer ces lois en logique classique par les axiomes : cause(A, B) ∧ A → B bloque(A, B) ∧ A → ¬B On peut aussi les exprimer plus faiblement par des règles d'inférences proches du modus ponens : cause(A, B) ∧ A / B bloque(A, B) ∧ A / ¬B72 Approche proposée et résultats Mais ces deux formulations posent problème dès qu'il y a conflit. Si par exemple on a un ensemble F de quatre formules F = {A, B, cause(A, C), bloque(B, C)}, alors on va dans les deux approches données ci-dessus inférer de F, C et ¬C ce qui est inconsistant. Pour résoudre ce conflit, on peut utiliser la logique des défauts. Pour résoudre les conflits vus ci-dessus, l'idée intuitive est d'affaiblir la formulation des règles de causalité en : (1') Si A cause B, et si A est vrai, et s'il est possible que B est vrai, alors B est vrai. (2') Si A bloque B, et si A est vrai, et s'il est possible que B est faux, alors B est faux. Dans la logique des défauts, les règles (1') et (2') vont s'exprimer intuitivement. (1") Si A cause B, et si A est vrai, et si B n'est pas contradictoire, alors B est vrai. (2") Si A bloque B, et si A est vrai, et si ¬B n'est pas contradictoire, alors ¬B est vrai. Ces règles vont se représenter par des défauts normaux et s'écrire : d1 : cause(A, B) ∧ A : B / B d2 : bloque(A, B) ∧ A : ¬B / ¬B Pour le cas élémentaire qui précède, si A et B sont vrais, on a : W = {A, B, cause(A,C), bloque(B,C)} D = {d1, d2} et on obtient deux extensions : E1 contient C (en appliquant d1) E2 contient ¬C (en appliquant d2) Le conflit est donc résolu, mais se pose le problème des extensions à préférer ; est-ce que C est induit ou bloqué? En fait ceci va vraiment dépendre du contexte. On peut par exemple préférer les interactions positives par rapport aux négatives ; ou bien utiliser des méthodes statistiques ou probabilistes. Plus en détail, pour l’application, on a [28]: W = {UV, Mdm2} D = { d1 = UV : cancer / cancer d2 = UV : p53 / p53 d3 = p53 : A / A d4 = p53 ∧ Mdm2: B / BApproche proposée et résultats 73 d5 = B : ¬A / ¬A d6 = A : ¬cancer / ¬cancer d7 = C : ¬B / ¬B } On a encore deux défauts généraux : d8 = Y : x /x ; où Y ∈ {UV, Mdm2} et d9 = Z ∧ x: C / C; où Z ∈ {UV, Mdm2, p53, A, B} Comme on a dit précédemment, pour que l’algorithme travaille avec des variables, il faut l’améliorer. Dans ce cas, les défauts d8 et d9 peuvent être écrits : source(uv). % UV est une source source(mdm2). substance(uv). % UV est une substance substance(mdm2). substance(p53). substance(a). substance(b). ecrit: source(Y), % « ordre 1 » assert(cl(def(Y,x))), % « ordre 2 » substance(Z), % « ordre 3 » assert(cl(def(joint(Z,x),c))). % « ordre 4 » où « ordre 1 » et « ordre 2 » peuvent dire : pour toutes les sources Y, ajouter les défauts Y:x/x à la base de données ; « ordre 3 » et « ordre 4 » peuvent dire : pour toutes les substances Z, ajouter les défauts Z∧ x:C/C à la base de données. En utilisant l’algorithme de calculer des extensions, on a 18 extensions cidessous (l’extension 12 correspond à la Figure 4.2-b, et l’extension 13 correspond à la Figure 4.2-c) : EXTENSION 1: uv -> p53 p53 -> a74 Approche proposée et résultats joint(p53,mdm2) -> b uv -> x joint(uv,x) -> c a -> -cancer EXTENSION 2: uv -> p53 p53 -> a joint(p53,mdm2) -> b uv -> x joint(mdm2,x) -> c a -> -cancer EXTENSION 3: uv -> p53 p53 -> a joint(p53,mdm2) -> b uv -> x joint(p53,x) -> c a -> -cancer EXTENSION 4: uv -> p53 p53 -> a joint(p53,mdm2) -> b uv -> x joint(a,x) -> c a -> -cancer EXTENSION 5: uv -> p53 p53 -> a joint(p53,mdm2) -> b uv -> x joint(b,x) -> c a -> -cancer EXTENSION 6: uv -> p53 p53 -> a joint(p53,mdm2) -> b mdm2 -> x joint(uv,x) -> c a -> -cancerApproche proposée et résultats 75 EXTENSION 7: uv -> p53 p53 -> a joint(p53,mdm2) -> b mdm2 -> x joint(mdm2,x) -> c a -> -cancer EXTENSION 8: uv -> p53 p53 -> a joint(p53,mdm2) -> b mdm2 -> x joint(p53,x) -> c a -> -cancer EXTENSION 9: uv -> p53 p53 -> a joint(p53,mdm2) -> b mdm2 -> x joint(a,x) -> c a -> -cancer EXTENSION 10: uv -> p53 p53 -> a joint(p53,mdm2) -> b mdm2 -> x joint(b,x) -> c a -> -cancer EXTENSION 11: uv -> p53 p53 -> a uv -> x joint(uv,x) -> c c -> -b a -> -cancer EXTENSION 12: uv -> p53 p53 -> a uv -> x joint(mdm2,x) -> c76 Approche proposée et résultats c -> -b a -> -cancer EXTENSION 13: uv -> p53 p53 -> a uv -> x joint(p53,x) -> c c -> -b a -> -cancer EXTENSION 14: uv -> p53 p53 -> a uv -> x joint(a,x) -> c c -> -b a -> -cancer EXTENSION 15: uv -> p53 p53 -> a mdm2 -> x joint(uv,x) -> c c -> -b a -> -cancer EXTENSION 16: uv -> p53 p53 -> a mdm2 -> x joint(mdm2,x) -> c c -> -b a -> -cancer EXTENSION 17: uv -> p53 p53 -> a mdm2 -> x joint(p53,x) -> c c -> -b a -> -cancer EXTENSION 18: uv -> p53 Approche proposée et résultats 77 p53 -> a mdm2 -> x joint(a,x) -> c c -> -b a -> -cancer % 599,907 inferences, 1.700 CPU in 2.402 seconds (71% CPU, 352801 Lips) 4.2.2. Utilisation dans le domaine temporel discret Bien que les cellules aient des morphologies et des structures différentes et que leurs rôles dans les organismes différents soient variés, leurs fonctionnalités de base sont les mêmes [1,4]. Une de ces fonctionnalités est d'assurer la survie de la cellule. Cette activité dans son ensemble peut être résumée en deux points [21]. Premièrement, une cellule a besoin de trouver l'énergie nécessaire pour son activité. Cette énergie est principalement obtenue par la dégradation des ressources minérales ou organiques, c’est le catabolisme. Deuxièmement, les cellules doivent fabriquer les molécules simples nécessaires à leur survie, c’est l’anabolisme. Ces deux grandes activités sont regroupées sous le nom de métabolisme, et résultent d'un grand nombre de mécanismes et de réactions biochimiques. La plupart des réactions, qui se déroulent dans une cellule, sont catalysées par des molécules spéciales appelées enzymes. Tout ceci est représenté comme un réseau, appelé voie métabolique [20]. Figure 4.3. Système équilibré de masse La Figure 4.3 représente la topologie simple d'une voie métabolique dans une cellule, qui se compose de cinq métabolites A, B, C, D et E et six réactions, dont chacune relie deux métabolites. Chaque flux est placé sur la réaction correspondante. Bien que les concentrations de A, C, D et E soient expérimentalement mesurables, la concentration de B ne peut pas être mesurée. Par conséquent, B est le métabolite intracellulaire. Sur la base de la cinétique enzymatique, le comportement dynamique du flux d'une réaction enzymatique peut être représenté comme l'équation différentielle suivante: ��� �� = ��� − ���� − ��� (4.2) où Cx est la concentration d'un métabolite X, vin (resp. vout) est la somme des flux de réactions pour la production (resp. consommation) de X, et μCX représente le taux de croissance de la biomasse dans une cellule. Si tous les métabolites sont à l'état stationnaire, le terme de gauche de l'équation (4.2) doit être nul car il n'y a pas de changements de séries chronologiques des concentrations, et aussi, on peut supposer que la dilution des éléments à cause de la croissance 78 Approche proposée et résultats de la biomasse (correspondant à la durée de la dernière équation (4.2)) est négligée. Ce fait signifie que pour chaque métabolite X, les flux de consommation de X sont équilibrés avec les flux de production de X à l'état stationnaire. L’équilibrage de flux métabolique est basé sur cette notion simple. Par exemple, son équilibrage dans la Figure 4.3 peut être représenté comme les équations linéaires suivantes: �1 = ��, �2 + �3 + = �3 − + �1, �5 = �2 + ��, �4 + �� = �5, �3 − + �� = �3 + + �4 (4.3) Ensuite, nous pouvons analyser la distribution du flux sur la base des équations (4.3) avec les flux mesurables rA, rC, rD et rE. En général, ces équations ne peuvent pas être résolues de façon déterministe parce que le nombre de valeurs inconnues comme v1,. . . , v5 correspondant aux flux de réactions enzymatiques intracellulaires devient plus grand que le nombre de valeurs connues correspondant aux flux mesurables. Des méthodes ont été proposées précédemment telles que l'analyse en mode primaire et extrêmes de la voie, des fonctions d'analyse d'utilisation d'optimisation afin de résoudre les équations. Ces fonctions introduites sont généralement construites en supposant que la maximisation de la croissance cellulaire ou la minimisation de la consommation d'énergie. Toutefois, dans le cas d'une grande échelle de la voie métabolique, nous ne pouvons pas résoudre la distribution de flux avec ces méthodes d'approximation en raison du coût de calcul énorme. Le système métabolique cellulaire dispose d'un mécanisme sophistiqué pour contrôler dynamiquement les activités des enzymes pour répondre aux besoins d'une cellule. Ce mécanisme de régulation peut être représenté comme des relations causales entre les activités enzymatiques et la concentration de métabolites changeants. Ici, nous considérons trois voies métaboliques simples: la première se compose de deux réactions avec trois métabolites, la seconde se compose de deux réactions avec trois métabolites aussi, et la troisième se compose d'une réaction avec deux métabolites. Noter que dans les figures suivantes, nous décrivons activé et non-activé par des réactions comme les cercles et barres obliques plus flèches correspondant aux réactions, respectivement. Et aussi, une hausse (resp. baisse) flèche représente l'augmentation (resp. la diminution) à une concentration de métabolites. La figure 4.4 correspond à la voie métabolique composée de trois métabolites X, Y et Z, et deux réactions. La figure dit que si la concentration de Y tend à augmenter à un certain moment, et si la réaction enzymatique Y→X (resp. X→Z) est activée (resp. non-activée) dans un état, alors la concentration de X va aussi augmenter. Cette relation causale est prise en compte par l'équation (4.2). Supposons que l'augmentation de la concentration de X est observée, ce qui est représentée par une flèche en pointillés dans les figures. Un cas possible est que la concentration de Y augmente, la réaction de Y→X est activée et la réaction X→Z n'est pas activée. Ceci parce que la production de X à partir de Y ne peut pas être consommée pour générer le Z. Approche proposée et résultats 79 Figure 4.4. La première relation entre les états de réaction et les changements de concentration de métabolites La Figure 4.5 correspond à la voie métabolique composée de trois métabolites X, Y et Z, et deux réactions. La figure montre que si la concentration de Y tend à augmenter à un certain moment, et si la réaction enzymatique Y→X (resp. X→Z) est non-activée (resp. activée) dans un l'état, alors la concentration de X va diminuer. Cette relation causale est prise en compte par l'équation (4.2). Supposons que la diminution de la concentration de X est observée, ce qui est désignée par une flèche en pointillés dans les figures. Un cas possible est que la concentration de Y augmente, la réaction de Y→X n’est pas activée et la réaction X→Z est activée. C'est parce que la production de Z à partir de X peut être consommée. Figure 4.5. La deuxième relation entre les états de réaction et les changements de concentration de métabolites Ensuite, nous considérons la Figure 4.6 qui représente une voie métabolique composée de deux métabolites X et Y, et une réaction. La figure montre que, même si la réaction Y→X est activée, la concentration de X doit diminuer en ce que la concentration de Y diminue. Par conséquent, si nous observons que la concentration de X diminue, on peut supposer une diminution de la concentration de Y et la réaction Y→X est activée comme un cas possible. Figure 4.6. La troisième relation entre les états de réaction et les changements de concentration de métabolites Les métabolites et les protéines sont considérés comme un même objet. On va souvent se restreindre ici à une représentation propositionnelle. Dans la pratique l'étude fine des interactions va demander de représenter des augmentations ou des diminutions de concentration de protéines. On sort donc du cadre propositionnel mais les problèmes de base sont les mêmes. Pour représenter une variation de concentration il est par exemple possible d'utiliser des prédicats de type "augmente" ou "diminue" et de limiter l'utilisation de ces prédicats. Pour décrire les interactions entre les métabolites dans la cellule, on part d’un langage L de logique classique (propositionnel ou du premier ordre). Dans L, la proposition A (resp ¬A) signifie que A est vrai (faux). On pourra utiliser par exemple con(A, up, ti) pour dire que la Y X Z Y X Z Y X80 Approche proposée et résultats concentration de A est augmentée au moment ti , ou encore, con(A, down, tj) pour dire que la concentration de A est diminuée au moment tj . On est dans un cadre logique, donc il est possible de représenter à peu près tout ce que l'on veut de manière naturelle. Le prix à payer, si l’on utilise la totalité du langage peut être l'explosion combinatoire des algorithmes. Les réactions entres métabolites sont une forme très simple de causalité. Pour exprimer ces réactions, il est courant d'aller à l'essentiel en donnant deux relations binaires act(A, B) et ¬act(A, B). La première relation veut dire, par exemple, qu’un métabolite A est consommé pour la production d'un métabolite B, la deuxième n’est pas consommé. De manière classique ces relations sont représentées dans le réseau de gênes, par A → B et A ⊣ B. Bien entendu cette causalité est élémentaire et de nombreux travaux très savants ont été écrits pour représenter les causalités. (C1) con(A,up,ti)∧react(A,B)∧active(A,B)∧react(B,C)∧non_active(B,C) → con(B,up,ti+1) (C2) con(A,up,tj)∧react(A,B)∧non_active(A,B)∧react(B,C)∧active(B,C) → con(B,down,tj+1) (C3) con(A,down,tk)∧ react(A,B)∧ active(A,B) → con(B,down,tk+1) L’expression (C1) veut dire que si la concentration de A est augmentée au moment ti , s’il y a une réaction entre A et B dans laquelle le métabolite A est consumée pour la production du métabolite B, et si pour toutes les réactions entre B et C le métabolite B n’est pas consommé pour la production du métabolite C, alors la concentration de B est augmentée au moment ti+1. L’expression (C2) veut dire que si la concentration de A est augmentée au moment tj , s’il y a une réaction entre A et B dans laquelle le métabolite A n’est pas consommé pour la production du métabolite B, et si pour une réaction entre B et C le métabolite B est consommé pour la production du métabolite C, alors la concentration de B est diminuée au moment tj+1. L’expression (C3) veut dire que si la concentration de A est diminuée au moment tk, s’il y a une réaction entre A et B dans laquelle le métabolite A est consommé pour la production du métabolite B, alors la concentration de B est diminuée au moment tk+1. Mais ces deux formulations posent problème dès qu'il y a un paradoxe. Si par exemple on a un ensemble F de sept formules F = {con(A, up, ti), react(A, B), react(B, C), active(A, B), non_active(B, C), non_active(A, B), active(B, C)}, alors on va dans les deux approches données ci-dessus inféré de F, con(B, up, ti+1) et con(B, down, ti+1) ce qui est paradoxe, parce que la concentration de B est augmentée et diminuée au même moment ti+1. Pour résoudre ce conflit, on peut utiliser la logique des défauts. Dans notre exemple, pour fournir des liens entre ces relations actives et non actives, l'idée intuitive est donc d'affaiblir la formulation de règles de causalité: (1) Si con(A,up,ti) , react(A,B), react(B,C), active(A,B), et non_active(B,C) sont vrais, et s’il est possible que con(B,up,ti+1), alors con(B,up,ti+1) est conclu (2) Si con(A,up,tj), react(A,B), react(B,C), non_active(A,B), et active(B,C) sont vrais, et s’il est possible que con(B,down,tj+1), alors con(B,down,tj+1) est concluApproche proposée et résultats 81 (3) Si con(A,down,tk), react(A,B), et active(A,B) sont vrais, et s’il est possible que con(B,down,tk+1), alors con(B,down,tk+1) est conclu La question est alors de formellement décrire le possible. Dans la logique des défauts, les règles (1), (2) et (3) seront exprimées de manière intuitive. �1: ���(�, ��,�� ) ∧ �����(�, �) ∧ �����(�, �) ∧ ������(�, �) ∧ ���_������(�, �): ���(�, ��,��+1) ���(�, ��,��+1) �2: �����, ��,��� ∧ �����(�, �) ∧ �����(�, �) ∧ ���_������(�, �) ∧ ������(�, �): ���(�, ����,��+1) ���(�, ����,��+1) �3: ���(�, ����,�� ) ∧ �����(�, �) ∧ ������(�, �): ���(�, ����,��+1) ���(�, ����,��+1) Le paradoxe a été résolu. Pour une théorie des défauts ∆ = (D, W), où D l'ensemble des défauts et W = {con(A, up, t0)}, en utilisant l’algorithme de calcul des extensions, on a 12 extensions ci-dessous [27]: EXTENSION 1: joint(con(a,up, t0), act(a,b), non_act(b,c)) → con(b,up, t1) joint(con(b,up, t1), act(b,d), non_act(d,e)) → con(d,up, t2) joint(con(d,up, t2), act(d,e), non_act(e,c)) → con(e,up, t3) joint(con(e,up, t3), act(e,c), non_act(c,b)) → con(c,up, t4) EXTENSION 2: joint(con(a,up, t0), act(a,b), non_act(b,c)) → con(b,up, t1) joint(con(b,up, t1), act(b,d), non_act(d,e)) → con(d,up, t2) joint(con(d,up, t2), act(d,e), non_act(e,c)) → con(e,up, t3) joint(con(e,up, t3), non_act(e,c), act(c,b)) → con(c,down, t4) EXTENSION 3: joint(con(a,up, t0), act(a,b), non_act(b,c)) → con(b,up, t1) joint(con(b,up, t1), act(b,d), non_act(d,e)) → con(d,up, t2) joint(con(d,up, t2), non_act(d,e), act(e,c)) → con(e,down, t3) joint(con(e,down, t3), act(e,c)) → con(c,down, t4) EXTENSION 4: joint(con(a,up, t0), act(a,b), non_act(b,c)) → con(b,up, t1)82 Approche proposée et résultats joint(con(b,up, t1), non_act(b,d), act(d,e)) → con(d,down, t2) joint(con(d,down, t2), act(d,e)) → con(e,down, t3) joint(con(e,down, t3), act(e,c)) → con(c,down, t4) EXTENSION 5: joint(con(a,up, t0), non_act(a,b), act(b,c)) → con(b,down, t1) joint(con(b,down, t1), act(b,c)) → con(c,down, t2) joint(con(b,down, t1), act(b,d)) → con(d,down, t2) joint(con(d,down, t2), act(d,e)) → con(e,down, t3) EXTENSION 6: joint(con(a,up, t0), non_act(a,b), act(b,c)) → con(b,down, t1) joint(con(b,down, t1), act(b,d)) → con(d,down, t2) joint(con(d,down, t2), act(d,e)) → con(e,down, t3) joint(con(e,down, t3), act(e,c)) → con(c,down, t4) EXTENSION 7: joint(con(a,up, t0), act(a,b), non_act(b,d)) → con(b,up, t1) joint(con(b,up, t1), act(b,d), non_act(d,e)) → con(d,up, t2) joint(con(d,up, t2), act(d,e), non_act(e,c)) → con(e,up, t3) joint(con(e,up, t3), act(e,c), non_act(c,b)) → con(c,up, t4) EXTENSION 8: joint(con(a,up, t0), act(a,b), non_act(b,d)) → con(b,up, t1) joint(con(b,up, t1), act(b,d), non_act(d,e)) → con(d,up, t2) joint(con(d,up, t2), act(d,e), non_act(e,c)) → con(e,up, t3) joint(con(e,up, t3), non_act(e,c), act(c,b)) → con(c,down, t4) EXTENSION 9: joint(con(a,up, t0), act(a,b), non_act(b,d)) → con(b,up, t1) joint(con(b,up, t1), act(b,d), non_act(d,e)) → con(d,up, t2) joint(con(d,up, t2), non_act(d,e), act(e,c)) → con(e,down, t3) joint(con(e,down, t3), act(e,c)) → con(c,down, t4)Approche proposée et résultats 83 EXTENSION 10: joint(con(a,up, t0), act(a,b), non_act(b,d)) → con(b,up, t1) joint(con(b,up, t1), non_act(b,d), act(d,e)) → con(d,down, t2) joint(con(d,down, t2), act(d,e)) → con(e,down, t3) joint(con(e,down, t3), act(e,c)) → con(c,down, t4) EXTENSION 11: joint(con(a,up, t0), non_act(a,b), act(b,d)) → con(b,down, t1) joint(con(b,down, t1), act(b,c)) → con(c,down, t2) joint(con(b,down, t1), act(b,d)) → con(d,down, t2) joint(con(d,down, t2), act(d,e)) → con(e,down, t3) EXTENSION 12: joint(con(a,up, t0), non_act(a,b), act(b,d)) → con(b,down, t1) joint(con(b,down, t1), act(b,d)) → con(d,down, t2) joint(con(d,down, t2), act(d,e)) → con(e,down, t3) joint(con(e,down, t3), act(e,c)) → con(c,down, t4) Cet algorithme a une complexité très grande. Il sera sans doute nécessaire de réduire les possibilités d'expression du langage pour arriver à des temps de calcul raisonnables. On retrouve ici la même problématique que pour la résolution pratique des problèmes NPComplets. Pour la carte de Pommier, après une coupe de l’algorithme pour réduire les extensions équivalentes, on a la base de données et le résultat ci-dessous, où un fait w dans W est défini « dur : --> w », et un défaut d = A:C/C dans D est défini « def : A --> C ». LA BASE DE DONNÉES: 1 dur : --> phosphorylation(atr,h2ax) 2 dur : --> stimulation(dsb,dna) 3 def : stimulation(dsb,dna) --> product(altered_dna) 4 def : product(altered_dna) --> binding(mre11,rad50) 5 def : binding(mre11,rad50) --> product(mre11_rad50) 6 def : product(mre11_rad50) --> binding(mre11_rad50,nbs1) 7 def : binding(mre11_rad50,nbs1) --> product(mrn) 8 def : product(mrn) --> binding(mrn,altered_dna) 9 def : binding(mrn,altered_dna) --> product(mrn_bound_to_dna) 10 def : product(mrn_bound_to_dna) --> binding(mrn_bound_to_dna,atm_atm) 11 def : binding(mrn_bound_to_dna,atm_atm) --> product(atm_bound_to_mrn) 12 def : product(atm_bound_to_mrn) --> bloq-product(atm_atm) 13 def : product(atm_bound_to_mrn) --> autophosphorylation(atm_bound_to_mrn) 14 def : autophosphorylation(atm_bound_to_mrn) --> product(p_atm_atm_bound) 84 Approche proposée et résultats 15 def : product(p_atm_atm_bound) --> bloq-product(atm_atm) 16 def : product(p_atm_atm_bound) --> dissociation(p_atm_atm_bound) 17 def : dissociation(p_atm_atm_bound) --> product(p_atm_bound) 18 def : dissociation(p_atm_atm_bound) --> product(p_atm_free) 19 def : product(p_atm_free) --> phosphorylation(p_atm_free,chk1) 20 def : phosphorylation(p_atm_free,chk1) --> product(p_chk1) 21 dur : --> phosphorylation(atr,chk1) 22 def : phosphorylation(atr,chk1) --> product(p_chk1) 23 def : product(mrn_bound_to_dna) --> product(p_smc1) 24 def : product(mrn_bound_to_dna) --> product(p_mre11) 25 def : phosphorylation(atr,h2ax) --> product(gamma_h2ax) 26 def : phosphorylation(p_atm_bound,h2ax) --> product(gamma_h2ax) 27 def : product(gamma_h2ax) --> binding(gamma_h2ax,mdc1) 28 def : binding(gamma_h2ax,mdc1) --> product(h2ax_mdc1) 29 def : product(h2ax_mdc1) --> phosphorylation(p_atm_bound,h2ax_mdc1) 30 def : phosphorylation(p_atm_bound,h2ax_mdc1) --> product(p_mdc1) 31 def : product(p_mdc1) --> binding(p_mdc1,rnf8) 32 def : binding(p_mdc1,rnf8) --> product(rnf8_bound) 33 def : product(rnf8_bound) --> binding(rnf8_bound,ubc13) 34 def : binding(rnf8_bound,ubc13) --> product(rnf8_ubc13) 35 def : product(rnf8_ubc13) --> ubiquitination(rnf8_ubc13,h2a) 36 def : ubiquitination(rnf8_ubc13,h2a) --> product(ub_h2a) 37 def : product(ub_h2a) --> binding(ub_h2a,rnf168) 38 def : binding(ub_h2a,rnf168) --> product(rnf168_bound) 39 def : product(rnf168_bound) --> binding(rnf168_bound,ubc13) 40 def : binding(rnf168_bound,ubc13) --> product(rnf168_ubc13) 41 def : product(rnf168_ubc13) --> ubiquitination(rnf168_ubc13,h2a) 42 def : ubiquitination(rnf168_ubc13,h2a) --> product(poly_ub_h2a) 43 def : product(poly_ub_h2a) --> stimulation(poly_ub_h2a,dna) 44 def : stimulation(poly_ub_h2a,dna) --> product(changed_struct_dna) 45 def : product(poly_ub_h2a) --> binding(poly_ub_h2a,rap80) 46 def : binding(poly_ub_h2a,rap80) --> product(rap80_bound) 47 def : product(rap80_bound) --> binding(rap80_bound,abraxas) 48 def : binding(rap80_bound,abraxas) --> product(abraxas_bound) 49 def : product(abraxas_bound) --> binding(abraxas_bound,bre) 50 def : binding(abraxas_bound,bre) --> product(bre_bound) 51 def : product(abraxas_bound) --> binding(abraxas_bound,brcc36) 52 def : binding(abraxas_bound,brcc36) --> product(brcc36_bound) 53 def : product(brcc36_bound) --> binding(brcc36_bound,merit40) 54 def : binding(brcc36_bound,merit40) --> product(merit40_bound) 55 def : product(merit40_bound) --> binding(merit40_bound,brcc36_bound) 56 def : binding(merit40_bound,brcc36_bound) --> product(brcc36_merit40) 57 def : product(brcc36_merit40) --> binding(brcc36_merit40,brca1) 58 def : binding(brcc36_merit40,brca1) --> product(brca1_bound_to_rap80_complex) 59 def : product(changed_struct_dna) --> phosphorylation(p_atm_bound,mmset) 60 def : phosphorylation(p_atm_bound,mmset) --> product(p_mmset) 61 def : product(h2ax_mdc1) --> binding(h2ax_mdc1,mdc1) 62 def : binding(h2ax_mdc1,mdc1) --> product(mdc1_multi)Approche proposée et résultats 85 63 def : product(mdc1_multi), product(p_mmset) --> binding(mdc1_multi,p_mmset) 64 def : binding(mdc1_multi,p_mmset) --> product(mmset_mdc1) 65 def : product(mmset_mdc1) --> methylation(mmset_mdc1,h4) 66 def : methylation(mmset_mdc1,h4) --> product(h4k20me2) 67 def : product(h4k20me2), product(brca1_bound_to_rap80_complex) --> binding(h4k20me2,p53bp1) 68 def : binding(h4k20me2,p53bp1) --> product(p53bp1_bound) 69 def : product(p53bp1_bound) --> phosphorylation(p_atm_bound,p53bp1_bound) 70 def : phosphorylation(p_atm_bound,p53bp1_bound) --> product(p_53bp1) 71 def : product(p_atm_free) --> phosphorylation(p_atm_free,plk3) 72 def : phosphorylation(p_atm_free,plk3) --> product(p_plk3) 73 def : product(p_atm_free) --> phosphorylation(p_atm_free,chk2) 74 def : phosphorylation(p_atm_free,chk2) --> product(p_s33_35_chk2) 75 def : product(p_s33_35_chk2) --> phosphorylation(p_plk3,p_s33_35_chk2) 76 def : phosphorylation(p_plk3,p_s33_35_chk2) --> product(p_s33_35_s62_73_chk2) 77 def : product(p_s33_35_s62_73_chk2) --> phosphorylation(p_atm_free,p_s33_35_s62_73_chk2) 78 def : phosphorylation(p_atm_free,p_s33_35_s62_73_chk2) --> product(p_t68_chk2) 79 def : product(p_s33_35_s62_73_chk2) --> phosphorylation(atr,p_s33_35_s62_73_chk2) 80 def : phosphorylation(atr,p_s33_35_s62_73_chk2) --> product(p_t68_chk2) 81 def : product(p_t68_chk2) --> binding(p_t68_chk2,p_t68_chk2) 82 def : binding(p_t68_chk2,p_t68_chk2) --> product(chk2_chk2) 83 def : product(chk2_chk2) --> autophosphorylation(chk2_chk2) 84 def : autophosphorylation(chk2_chk2) --> product(p_active_chk2_chk2) 85 def : product(p_active_chk2_chk2), product(p_53bp1) --> binding(p_active_chk2_chk2,p_53bp1) 86 def : binding(p_active_chk2_chk2,p_53bp1) --> product(chk2_53bp1) 87 dur : --> binding(brca1,ctip) 88 def : binding(brca1,ctip) --> product(brca1_ctip) 89 def : product(brca1_ctip), product(chk2_53bp1) --> binding(brca1_ctip,chk2_53bp1) 90 def : binding(brca1_ctip,chk2_53bp1) --> product(chk2_53bp1_bound_to_brca1) 91 def : binding(brca1_ctip,chk2_53bp1) --> product(brca1_ctip_bound_to_chk2) 92 def : product(chk2_53bp1_bound_to_brca1), product(brca1_ctip_bound_to_chk2) --> phosphorylation(chk2_53bp1_bound_to_brca1,brca1_ctip_bound_to_chk2) 93 def : phosphorylation(chk2_53bp1_bound_to_brca1,brca1_ctip_bound_to_chk2) --> product(p_brca1_ctip_bound_to_chk2) 94 def : product(p_brca1_ctip_bound_to_chk2) --> product(p_s988_brca_ctip) 95 def : product(chk2_53bp1_bound_to_brca1) --> product(chk2_53bp1) 96 def : product(p_s988_brca_ctip) --> phosphorylation(p_atm_bound,p_s988_brca_ctip) 97 def : phosphorylation(p_atm_bound,p_s988_brca_ctip) --> product(brca_p_ctip) 98 def : product(brca_p_ctip) --> bloq-product(brca1_ctip) 99 def : product(brca_p_ctip) --> dissociation(brca_p_ctip) 100 def : dissociation(brca_p_ctip) --> product(brca1) 101 def : dissociation(brca_p_ctip) --> product(p_ctip) 102 def : product(brca1) --> phosphorylation(p_atm_bound,brca1) 103 def : phosphorylation(p_atm_bound,brca1) --> product(p_brca1) 104 def : product(brca1) --> phosphorylation(atr,brca1) 105 def : phosphorylation(atr,brca1) --> product(p_brca1) 106 def : product(p_brca1), product(p_53bp1) --> binding(mrn_bound_to_dna,p_brca1)86 Approche proposée et résultats 107 def : binding(mrn_bound_to_dna,p_brca1) --> product(brca1_bound_to_mrn) 108 def : product(chk2_53bp1) --> phosphorylation(chk2_53bp1,pml) 109 def : phosphorylation(chk2_53bp1,pml) --> product(p_pml) 110 def : product(p_pml) --> stimulation(p_pml,cell) 111 def : stimulation(p_pml,cell) --> product(apoptosis) 112 def : product(p_pml) --> binding(p_pml,mdm2) 113 def : binding(p_pml,mdm2) --> product(pml_mdm2) 114 def : product(pml_mdm2) --> bloq-binding(mdm2,p53) 115 dur : --> product(p53) 116 def : product(mdm2), product(p53) --> binding(mdm2,p53) 117 def : binding(mdm2,p53) --> product(mdm2_p53) 118 def : product(mdm2_p53) --> stimulation(p53_degradation_effectors,mdm2_p53) 119 def : stimulation(p53_degradation_effectors,mdm2_p53) --> product(p53_degradation) 120 def : product(p_atm_free), product(mdm2_p53) --> phosphorylation(p_atm_free,mdm2_p53) 121 def : phosphorylation(p_atm_free,mdm2_p53) --> product(p_s15_p53_mdm2) 122 def : product(mdm2_p53) --> phosphorylation(atr,mdm2_p53) 123 def : phosphorylation(atr,mdm2_p53) --> product(p_s15_p53_mdm2) 124 def : product(p_s15_p53_mdm2), product(chk2_53bp1) --> phosphorylation(chk2_53bp1,p_s15_p53_mdm2) 125 def : phosphorylation(chk2_53bp1,p_s15_p53_mdm2) --> product(p_p_p53_mdm2) 126 def : product(p_s15_p53_mdm2), product(p_chk1) --> phosphorylation(p_chk1,p_s15_p53_mdm2) 127 def : phosphorylation(p_chk1,p_s15_p53_mdm2) --> product(p_p_p53_mdm2) 128 def : product(p_s15_p53_mdm2) --> bloq-product(p53_degradation) 129 def : product(p_p_p53_mdm2) --> bloq-product(p53_degradation) 130 def : product(p_p_p53_mdm2) --> dissociation(p_p_p53_mdm2) 131 def : dissociation(p_p_p53_mdm2) --> product(p_p_p53) 132 def : dissociation(p_p_p53_mdm2) --> product(mdm2) 133 def : product(p_atm_free), product(mdm2) --> phosphorylation(p_atm_free,mdm2) 134 def : phosphorylation(p_atm_free,mdm2) --> product(p_mdm2) 135 def : product(p_p_p53) --> binding(p300,p_p_p53) 136 def : product(p_pml), binding(p300,p_p_p53) --> product(active_p53) 137 def : product(active_p53) --> transcription_activation(active_p53,prom_p21_gadd45) 138 def : transcription_activation(active_p53,prom_p21_gadd45) --> product(p21_and_gadd45) 139 def : product(prom_and_gadd45) --> stimulation(prom_and_gadd45,cell_cycle) 140 def : stimulation(p21_and_gadd45,cell_cycle) --> product(cell_cycle_arrest) 141 def : product(active_p53) --> transcription_activation(active_p53,prom_bnpf) 142 def : transcription_activation(active_p53,prom_bnpf) --> product(box_nas_puma_fas) 143 def : product(box_nas_puma_fas) --> stimulation(box_nas_puma_fas,cell) 144 def : stimulation(box_nas_puma_fas,cell) --> product(apoptosis) 145 def : product(active_p53) --> transcription_activation(active_p53,prom_mdm2) 146 def : transcription_activation(active_p53,prom_mdm2) --> product(mdm2) 147 dur : --> product(e2f1) 148 def : product(e2f1), product(chk2_53bp1) --> phosphorylation(chk2_53bp1,e2f1) 149 def : phosphorylation(chk2_53bp1,e2f1) --> product(p_e2f1) 150 def : product(e2f1) --> stimulation(e2f1_degradation_effectors,e2f1) 151 def : stimulation(e2f1_degradation_effectors,e2f1) --> product(e2f1_degradation) 152 def : product(p_e2f1) --> phosphorylation(p_atm_free,p_e2f1) Approche proposée et résultats 87 153 def : phosphorylation(p_atm_free,p_e2f1) --> product(p_p_e2f1) 154 def : product(p_e2f1) --> phosphorylation(atr,p_e2f1) 155 def : phosphorylation(atr,p_e2f1) --> product(p_p_e2f1) 156 def : product(p_p_e2f1) --> transcription_activation(p_p_e2f1,prom_chk2) 157 def : transcription_activation(p_p_e2f1,prom_chk2) --> product(chk2) 158 def : product(p_p_e2f1) --> transcription_activation(p_p_e2f1,prom_arf) 159 def : transcription_activation(p_p_e2f1,prom_arf) --> product(arf) 160 def : product(p_p_e2f1) --> transcription_activation(p_p_e2f1,prom_p73_apaf1) 161 def : transcription_activation(p_p_e2f1,prom_p73_apaf1) --> product(p73_apaf1) 162 def : product(p73_apaf1) --> stimulation(p73_apaf1,cell) 163 def : stimulation(p73_apaf1,cell) --> product(apoptosis) 164 def : product(arf) --> binding(arf,mdm2) 165 def : binding(arf,mdm2) --> product(arf_mdm2) 166 def : product(arf_mdm2) --> bloq-product(mdm2_p53) 167 def : product(p_p_e2f1) --> stimulation(p_p_e2f1,unknown_atm_way) 168 def : stimulation(p_p_e2f1,unknown_atm_way) --> product(p_atm_free) 169 def : product(p_atm_free) --> phosphorylation(p_atm_free,p38) 170 def : phosphorylation(p_atm_free,p38) --> product(p_p38) 171 def : product(chk2_53bp1) --> phosphorylation(chk2_53bp1,cdc25a) 172 def : phosphorylation(chk2_53bp1,cdc25a) --> product(p_cdc25a) 173 def : product(p_chk1) --> phosphorylation(p_chk1,cdc25a) 174 def : phosphorylation(p_chk1,cdc25a) --> product(p_cdc25a) 175 def : product(p_cdc25a) --> stimulation(cdc25a,cell) 176 def : stimulation(cdc25a,cell) --> bloq-product(cell_cycle_arrest) 177 def : product(p_cdc25a) --> stimulation(p_cdc25a,cdc25a_degradation_effectors) 178 def : stimulation(p_cdc25a,cdc25_degradation_effectors) --> product(cdc25a_degradation) 179 def : product(cdc25a_degradation) --> bloq-stimulation(cdc25a,cell) 180 def : product(chk2_53bp1) --> phosphorylation(chk2_53bp1,cdc25c) 181 def : phosphorylation(chk2_53bp1,cdc25c) --> product(p_cdc25c) 182 def : product(p_plk3) --> phosphorylation(p_plk3,cdc25c) 183 def : phosphorylation(p_plk3,cdc25c) --> product(p_cdc25c) 184 def : product(p_chk1) --> phosphorylation(p_chk1,cdc25c) 185 def : phosphorylation(p_chk1,cdc25c) --> product(p_cdc25c) 186 def : product(p_p38) --> phosphorylation(p_p38,cdc25c) 187 def : phosphorylation(p_p38,cdc25c) --> product(p_cdc25c) 188 def : product(p_cdc25c) --> stimulation(cdc25c,cell) 189 def : stimulation(cdc25c,cell) --> bloq-product(cell_cycle_arrest) 190 def : product(p_cdc25c) --> stimulation(p_cdc25c,cdc25c_degradation_effectors) 191 def : stimulation(cdc25b,cell) --> bloq-product(cell_cycle_arrest) 192 def : product(p_p38) --> phosphorylation(p_p38,cdc25b) 193 def : phosphorylation(p_p38,cdc25b) --> product(p_cdc25b) 194 def : product(p_cdc25b) --> bloq-stimulation(cdc25b,cell) 195 def : stimulation(jnk,cdc25c) --> product(p_cdc25c) 196 def : phosphorylation(jnk,p_s15_p53_mdm2) --> product(p_p_p53_mdm2) 197 def : product(p_atm_bound) --> phosphorylation(p_atm_bound,nbs1) 198 def : phosphorylation(p_atm_bound,nbs1) --> product(p_nbs1) 199 def : product(p_nbs1) --> phosphorylation(p_atm_bound,fancd2) 200 def : phosphorylation(p_atm_bound,fancd2) --> product(p_fancd2)88 Approche proposée et résultats 201 def : product(p_fancd2) --> stimulation(p_fancd2,cell) 202 def : stimulation(p_fancd2,cell) --> bloq-product(cell_cycle_arrest) 203 def : product(chk2_53bp1) --> binding(chk2_53bp1,mus81) 204 def : binding(chk2_53bp1,mus81) --> product(mus81_chk2) 205 def : product(mus81_chk2) --> binding(mus81_chk2,altered_dna) 206 def : binding(mus81_chk2,altered_dna) --> product(mus81_bound_to_dna) LE RÉSULTAT def 3 : (stimulation(dsb,dna), up, t0) ==> (product(altered_dna), up, t1) def 4 : (product(altered_dna), up, t1) ==> (binding(mre11,rad50), up, t2) def 5 : (binding(mre11,rad50), up, t2) ==> (product(mre11_rad50), up, t3) def 6 : (product(mre11_rad50), up, t3) ==> (binding(mre11_rad50,nbs1), up, t4) def 7 : (binding(mre11_rad50,nbs1), up, t4) ==> (product(mrn), up, t5) def 8 : (product(mrn), up, t5) ==> (binding(mrn,altered_dna), up, t6) def 9 : (binding(mrn,altered_dna), up, t6) ==> (product(mrn_bound_to_dna), up, t7) def 10 : (product(mrn_bound_to_dna), up, t7) ==> (binding(mrn_bound_to_dna,atm_atm), up, t8) def 11 : (binding(mrn_bound_to_dna,atm_atm), up, t8) ==> (product(atm_bound_to_mrn), up, t9) def 12 : (product(atm_bound_to_mrn), up, t9) ==> (product(atm_atm), down, t10) def 13 : (product(atm_bound_to_mrn), up, t9) ==> (autophosphorylation(atm_bound_to_mrn), up, t10) def 14 : (autophosphorylation(atm_bound_to_mrn), up, t10) ==> (product(p_atm_atm_bound), up, t11) def 16 : (product(p_atm_atm_bound), up, t11) ==> (dissociation(p_atm_atm_bound), up, t12) def 17 : (dissociation(p_atm_atm_bound), up, t12) ==> (product(p_atm_bound), up, t13) def 18 : (dissociation(p_atm_atm_bound), up, t12) ==> (product(p_atm_free), up, t13) def 19 : (product(p_atm_free), up, t13) ==> (phosphorylation(p_atm_free,chk1), up, t14) def 20 : (phosphorylation(p_atm_free,chk1), up, t14) ==> (product(p_chk1), up, t15) def 23 : (product(mrn_bound_to_dna), up, t7) ==> (product(p_smc1), up, t8) def 24 : (product(mrn_bound_to_dna), up, t7) ==> (product(p_mre11), up, t8) def 25 : (phosphorylation(atr,h2ax), up, t0) ==> (product(gamma_h2ax), up, t1) def 27 : (product(gamma_h2ax), up, t1) ==> (binding(gamma_h2ax,mdc1), up, t2) def 28 : (binding(gamma_h2ax,mdc1), up, t2) ==> (product(h2ax_mdc1), up, t3) def 29 : (product(h2ax_mdc1), up, t3) ==> (phosphorylation(p_atm_bound,h2ax_mdc1), up, t4) def 30 : (phosphorylation(p_atm_bound,h2ax_mdc1), up, t4) ==> (product(p_mdc1), up, t5) def 31 : (product(p_mdc1), up, t5) ==> (binding(p_mdc1,rnf8), up, t6) def 32 : (binding(p_mdc1,rnf8), up, t6) ==> (product(rnf8_bound), up, t7) def 33 : (product(rnf8_bound), up, t7) ==> (binding(rnf8_bound,ubc13), up, t8) def 34 : (binding(rnf8_bound,ubc13), up, t8) ==> (product(rnf8_ubc13), up, t9) def 35 : (product(rnf8_ubc13), up, t9) ==> (ubiquitination(rnf8_ubc13,h2a), up, t10) def 36 : (ubiquitination(rnf8_ubc13,h2a), up, t10) ==> (product(ub_h2a), up, t11) def 37 : (product(ub_h2a), up, t11) ==> (binding(ub_h2a,rnf168), up, t12) def 38 : (binding(ub_h2a,rnf168), up, t12) ==> (product(rnf168_bound), up, t13) def 39 : (product(rnf168_bound), up, t13) ==> (binding(rnf168_bound,ubc13), up, t14) def 40 : (binding(rnf168_bound,ubc13), up, t14) ==> (product(rnf168_ubc13), up, t15) def 41 : (product(rnf168_ubc13), up, t15) ==> (ubiquitination(rnf168_ubc13,h2a), up, t16) def 42 : (ubiquitination(rnf168_ubc13,h2a), up, t16) ==> (product(poly_ub_h2a), up, t17) def 43 : (product(poly_ub_h2a), up, t17) ==> (stimulation(poly_ub_h2a,dna), up, t18) def 44 : (stimulation(poly_ub_h2a,dna), up, t18) ==> (product(changed_struct_dna), up, t19) def 45 : (product(poly_ub_h2a), up, t17) ==> (binding(poly_ub_h2a,rap80), up, t18) Approche proposée et résultats 89 def 46 : (binding(poly_ub_h2a,rap80), up, t18) ==> (product(rap80_bound), up, t19) def 47 : (product(rap80_bound), up, t19) ==> (binding(rap80_bound,abraxas), up, t20) def 48 : (binding(rap80_bound,abraxas), up, t20) ==> (product(abraxas_bound), up, t21) def 49 : (product(abraxas_bound), up, t21) ==> (binding(abraxas_bound,bre), up, t22) def 50 : (binding(abraxas_bound,bre), up, t22) ==> (product(bre_bound), up, t23) def 51 : (product(abraxas_bound), up, t21) ==> (binding(abraxas_bound,brcc36), up, t22) def 52 : (binding(abraxas_bound,brcc36), up, t22) ==> (product(brcc36_bound), up, t23) def 53 : (product(brcc36_bound), up, t23) ==> (binding(brcc36_bound,merit40), up, t24) def 54 : (binding(brcc36_bound,merit40), up, t24) ==> (product(merit40_bound), up, t25) def 55 : (product(merit40_bound), up, t25) ==> (binding(merit40_bound,brcc36_bound), up, t26) def 56 : (binding(merit40_bound,brcc36_bound), up, t26) ==> (product(brcc36_merit40), up, t27) def 57 : (product(brcc36_merit40), up, t27) ==> (binding(brcc36_merit40,brca1), up, t28) def 58 : (binding(brcc36_merit40,brca1), up, t28) ==> (product(brca1_bound_to_rap80_complex), up, t29) def 59 : (product(changed_struct_dna), up, t19) ==> (phosphorylation(p_atm_bound,mmset), up, t20) def 60 : (phosphorylation(p_atm_bound,mmset), up, t20) ==> (product(p_mmset), up, t21) def 61 : (product(h2ax_mdc1), up, t3) ==> (binding(h2ax_mdc1,mdc1), up, t4) def 62 : (binding(h2ax_mdc1,mdc1), up, t4) ==> (product(mdc1_multi), up, t5) def 63 : (product(mdc1_multi), up, t5), (product(p_mmset), up, t21) ==> (binding(mdc1_multi,p_mmset), up, t22) def 64 : (binding(mdc1_multi,p_mmset), up, t22) ==> (product(mmset_mdc1), up, t23) def 65 : (product(mmset_mdc1), up, t23) ==> (methylation(mmset_mdc1,h4), up, t24) def 66 : (methylation(mmset_mdc1,h4), up, t24) ==> (product(h4k20me2), up, t25) def 67 : (product(h4k20me2), up, t25), (product(brca1_bound_to_rap80_complex), up, t29) ==> (binding(h4k20me2,p53bp1), up, t30) def 68 : (binding(h4k20me2,p53bp1), up, t30) ==> (product(p53bp1_bound), up, t31) def 69 : (product(p53bp1_bound), up, t31) ==> (phosphorylation(p_atm_bound,p53bp1_bound), up, t32) def 70 : (phosphorylation(p_atm_bound,p53bp1_bound), up, t32) ==> (product(p_53bp1), up, t33) def 71 : (product(p_atm_free), up, t13) ==> (phosphorylation(p_atm_free,plk3), up, t14) def 72 : (phosphorylation(p_atm_free,plk3), up, t14) ==> (product(p_plk3), up, t15) def 73 : (product(p_atm_free), up, t13) ==> (phosphorylation(p_atm_free,chk2), up, t14) def 74 : (phosphorylation(p_atm_free,chk2), up, t14) ==> (product(p_s33_35_chk2), up, t15) def 75 : (product(p_s33_35_chk2), up, t15) ==> (phosphorylation(p_plk3,p_s33_35_chk2), up, t16) def 76 : (phosphorylation(p_plk3,p_s33_35_chk2), up, t16) ==> (product(p_s33_35_s62_73_chk2), up, t17) def 77 : (product(p_s33_35_s62_73_chk2), up, t17) ==> (phosphorylation(p_atm_free,p_s33_35_s62_73_chk2), up, t18) def 78 : (phosphorylation(p_atm_free,p_s33_35_s62_73_chk2), up, t18) ==> (product(p_t68_chk2), up, t19) def 79 : (product(p_s33_35_s62_73_chk2), up, t17) ==> (phosphorylation(atr,p_s33_35_s62_73_chk2), up, t18) def 81 : (product(p_t68_chk2), up, t19) ==> (binding(p_t68_chk2,p_t68_chk2), up, t20) def 82 : (binding(p_t68_chk2,p_t68_chk2), up, t20) ==> (product(chk2_chk2), up, t21) def 83 : (product(chk2_chk2), up, t21) ==> (autophosphorylation(chk2_chk2), up, t22) def 84 : (autophosphorylation(chk2_chk2), up, t22) ==> (product(p_active_chk2_chk2), up, t23) def 85 : (product(p_active_chk2_chk2), up, t23), (product(p_53bp1), up, t33) ==> 90 Approche proposée et résultats (binding(p_active_chk2_chk2,p_53bp1), up, t34) def 86 : (binding(p_active_chk2_chk2,p_53bp1), up, t34) ==> (product(chk2_53bp1), up, t35) def 88 : (binding(brca1,ctip), up, t0) ==> (product(brca1_ctip), up, t1) def 89 : (product(brca1_ctip), up, t1), (product(chk2_53bp1), up, t35) ==> (binding(brca1_ctip,chk2_53bp1), up, t36) def 90 : (binding(brca1_ctip,chk2_53bp1), up, t36) ==> (product(chk2_53bp1_bound_to_brca1), up, t37) def 91 : (binding(brca1_ctip,chk2_53bp1), up, t36) ==> (product(brca1_ctip_bound_to_chk2), up, t37) def 92 : (product(chk2_53bp1_bound_to_brca1), up, t37), (product(brca1_ctip_bound_to_chk2), up, t37) ==>(phosphorylation(chk2_53bp1_bound_to_brca1,brca1_ctip_bound_to_chk2), up, t38) def 93 : (phosphorylation(chk2_53bp1_bound_to_brca1,brca1_ctip_bound_to_chk2), up, t38) ==> (product(p_brca1_ctip_bound_to_chk2), up, t39) def 94 : (product(p_brca1_ctip_bound_to_chk2), up, t39) ==> (product(p_s988_brca_ctip), up, t40) def 96 : (product(p_s988_brca_ctip), up, t40) ==> (phosphorylation(p_atm_bound,p_s988_brca_ctip), up, t41) def 97 : (phosphorylation(p_atm_bound,p_s988_brca_ctip), up, t41) ==> (product(brca_p_ctip), up, t42) def 99 : (product(brca_p_ctip), up, t42) ==> (dissociation(brca_p_ctip), up, t43) def 100 : (dissociation(brca_p_ctip), up, t43) ==> (product(brca1), up, t44) def 101 : (dissociation(brca_p_ctip), up, t43) ==> (product(p_ctip), up, t44) def 102 : (product(brca1), up, t44) ==> (phosphorylation(p_atm_bound,brca1), up, t45) def 103 : (phosphorylation(p_atm_bound,brca1), up, t45) ==> (product(p_brca1), up, t46) def 104 : (product(brca1), up, t44) ==> (phosphorylation(atr,brca1), up, t45) def 106 : (product(p_brca1), up, t46), (product(p_53bp1), up, t33) ==> (binding(mrn_bound_to_dna,p_brca1), up, t47) def 107 : (binding(mrn_bound_to_dna,p_brca1), up, t47) ==> (product(brca1_bound_to_mrn), up, t48) def 108 : (product(chk2_53bp1), up, t35) ==> (phosphorylation(chk2_53bp1,pml), up, t36) def 109 : (phosphorylation(chk2_53bp1,pml), up, t36) ==> (product(p_pml), up, t37) def 110 : (product(p_pml), up, t37) ==> (stimulation(p_pml,cell), up, t38) def 111 : (stimulation(p_pml,cell), up, t38) ==> (product(apoptosis), up, t39) def 112 : (product(p_pml), up, t37) ==> (binding(p_pml,mdm2), up, t38) def 113 : (binding(p_pml,mdm2), up, t38) ==> (product(pml_mdm2), up, t39) def 114 : (product(pml_mdm2), up, t39) ==> (binding(mdm2,p53), down, t40) def 148 : (product(e2f1), up, t0), (product(chk2_53bp1), up, t35) ==> (phosphorylation(chk2_53bp1,e2f1), up, t36) def 149 : (phosphorylation(chk2_53bp1,e2f1), up, t36) ==> (product(p_e2f1), up, t37) def 150 : (product(e2f1), up, t0) ==> (stimulation(e2f1_degradation_effectors,e2f1), up, t1) def 151 : (stimulation(e2f1_degradation_effectors,e2f1), up, t1) ==> (product(e2f1_degradation), up, t2) def 152 : (product(p_e2f1), up, t37) ==> (phosphorylation(p_atm_free,p_e2f1), up, t38) def 153 : (phosphorylation(p_atm_free,p_e2f1), up, t38) ==> (product(p_p_e2f1), up, t39) def 154 : (product(p_e2f1), up, t37) ==> (phosphorylation(atr,p_e2f1), up, t38) def 156 : (product(p_p_e2f1), up, t39) ==> (transcription_activation(p_p_e2f1,prom_chk2), up, t40) def 157 : (transcription_activation(p_p_e2f1,prom_chk2), up, t40) ==> (product(chk2), up, t41) def 158 : (product(p_p_e2f1), up, t39) ==> (transcription_activation(p_p_e2f1,prom_arf), up, t40) Approche proposée et résultats 91 def 159 : (transcription_activation(p_p_e2f1,prom_arf), up, t40) ==> (product(arf), up, t41) def 160 : (product(p_p_e2f1), up, t39) ==> (transcription_activation(p_p_e2f1,prom_p73_apaf1), up, t40) def 161 : (transcription_activation(p_p_e2f1,prom_p73_apaf1), up, t40) ==> (product(p73_apaf1), up, t41) def 162 : (product(p73_apaf1), up, t41) ==> (stimulation(p73_apaf1,cell), up, t42) def 164 : (product(arf), up, t41) ==> (binding(arf,mdm2), up, t42) def 165 : (binding(arf,mdm2), up, t42) ==> (product(arf_mdm2), up, t43) def 166 : (product(arf_mdm2), up, t43) ==> (product(mdm2_p53), down, t44) def 167 : (product(p_p_e2f1), up, t39) ==> (stimulation(p_p_e2f1,unknown_atm_way), up, t40) def 169 : (product(p_atm_free), up, t13) ==> (phosphorylation(p_atm_free,p38), up, t14) def 170 : (phosphorylation(p_atm_free,p38), up, t14) ==> (product(p_p38), up, t15) def 171 : (product(chk2_53bp1), up, t35) ==> (phosphorylation(chk2_53bp1,cdc25a), up, t36) def 172 : (phosphorylation(chk2_53bp1,cdc25a), up, t36) ==> (product(p_cdc25a), up, t37) def 173 : (product(p_chk1), up, t15) ==> (phosphorylation(p_chk1,cdc25a), up, t16) def 175 : (product(p_cdc25a), up, t37) ==> (stimulation(cdc25a,cell), up, t38) def 176 : (stimulation(cdc25a,cell), up, t38) ==> (product(cell_cycle_arrest), down, t39) def 177 : (product(p_cdc25a), up, t37) ==> (stimulation(p_cdc25a,cdc25a_degradation_effectors), up, t38) def 180 : (product(chk2_53bp1), up, t35) ==> (phosphorylation(chk2_53bp1,cdc25c), up, t36) def 181 : (phosphorylation(chk2_53bp1,cdc25c), up, t36) ==> (product(p_cdc25c), up, t37) def 182 : (product(p_plk3), up, t15) ==> (phosphorylation(p_plk3,cdc25c), up, t16) def 184 : (product(p_chk1), up, t15) ==> (phosphorylation(p_chk1,cdc25c), up, t16) def 186 : (product(p_p38), up, t15) ==> (phosphorylation(p_p38,cdc25c), up, t16) def 188 : (product(p_cdc25c), up, t37) ==> (stimulation(cdc25c,cell), up, t38) def 190 : (product(p_cdc25c), up, t37) ==> (stimulation(p_cdc25c,cdc25c_degradation_effectors), up, t38) def 192 : (product(p_p38), up, t15) ==> (phosphorylation(p_p38,cdc25b), up, t16) def 193 : (phosphorylation(p_p38,cdc25b), up, t16) ==> (product(p_cdc25b), up, t17) def 194 : (product(p_cdc25b), up, t17) ==> (stimulation(cdc25b,cell), down, t18) def 197 : (product(p_atm_bound), up, t13) ==> (phosphorylation(p_atm_bound,nbs1), up, t14) def 198 : (phosphorylation(p_atm_bound,nbs1), up, t14) ==> (product(p_nbs1), up, t15) def 199 : (product(p_nbs1), up, t15) ==> (phosphorylation(p_atm_bound,fancd2), up, t16) def 200 : (phosphorylation(p_atm_bound,fancd2), up, t16) ==> (product(p_fancd2), up, t17) def 201 : (product(p_fancd2), up, t17) ==> (stimulation(p_fancd2,cell), up, t18) def 203 : (product(chk2_53bp1), up, t35) ==> (binding(chk2_53bp1,mus81), up, t36) def 204 : (binding(chk2_53bp1,mus81), up, t36) ==> (product(mus81_chk2), up, t37) def 205 : (product(mus81_chk2), up, t37) ==> (binding(mus81_chk2,altered_dna), up, t38) def 206 : (binding(mus81_chk2,altered_dna), up, t38) ==> (product(mus81_bound_to_dna), up, t39) Ce résultat est représenté dans la Figure 4.7. Les chiffres rouges sont les défauts utilisés dans le résultat.92 Approche proposée et résultats Figure 4.7. Une extension de la carte de PommierConclusion 93 Conclusion Les voies de signalisation sont très importantes pour la compréhension des mécanismes des fonctions biologiques. Cette thèse étudie la synthèse automatique des voies de signalisation à partir d’informations trouvées dans des bases de connaissances. Une composante essentielle de cette approche est l’utilisation du raisonnement logique pour représenter la connaissance biologique de la communication intracellulaire. En choisissant la représentation adéquate des connaissances biologiques la partie « raisonnement » est capable d’assigner un ordre dans l’acquisition des faits et d’extraire les interactions nécessaires à la synthèse des voies métaboliques ou de signalisation. La première partie de la thèse est consacrée à la synthèse des voies pharmaco-cinétiques par des algorithmes de production. Cet algorithme est décidable, cohérent et complet. La deuxième partie utilise la logique des défauts pour représenter les interactions dans les réseaux de gènes. Le problème de l'implémentation et de la complexité algorithmique n'a pas été abordé. Il sera sans doute nécessaire de réduire les possibilités d'expression du langage pour arriver à des temps de calcul raisonnables. On retrouve ici la même problématique que pour la résolution pratique des problèmes NP-Complets. Bien entendu le problème est ici plus compliqué. La complexité pratique peut alors rester accessible en contrôlant l'écriture des règles. Par exemple dans un premier temps on peut essayer de se restreindre à quelque chose qui ressemble à des clauses de Horn (clauses qui contiennent au plus un littéral positif [2]). Bibliographie 95 Bibliographie [1] Demongeot J, “Multi-stationarity and cell differentiation”, J. Biol. Systems., 6, 1-2 (1998). [2] Doncescu A. , Inoue K. and Yamamoto, “Knowledge-based discovery in systems biology using CF-induction”. New Trends in Applied Artificial Intelligence: Proceedings of the 20th International Conference on Industrial, Engineering and Other Applications of Applied Intelligent Systems (IEA / AIE 2007), Lecture Notes in Artificial Intelligence, volume 4570, pages 395-404, Springer-Verlag. [3] Doncescu A, and Siegel P, “Utilisation de la logique des hypothèses pour la modélisation des voies de signalisation dans la cellule”, JIAF 11, Lyon 8-10, June 2011. [4] Doncescu A., Waissman J.,Richard G.,Roux G. “Characterization of bio-chemical signals by inductive logic programming”, Knowledge-Based Systems 15 (1), 129-137, 2002. [5] Christophe Chassagnole, Juan Carlos, A Rodriguez, Andrei Doncescu, Laurence T Yang “Differential evolutionary algorithms for in vivo dynamic analysis of glycolysis and pentose phosphate pathway in Escherichia Coli”, Parallel Computing for Bioinformatics and Computational Biology: Models, Enabling Technologies, and Case Studies, 59-78, John Wiley & Sons, Inc.,2006. [6] Montseny E., Doncescu A., “Operatorial Parametrizing of Controlled Dynamic SystemsApplication to the Fed-Batch Bioreactor Control Problem”, 17th World Congress The International Federation of Automatic Control. Seoul, Korea, June 2008. [7] Forget L, Rish V. , P Siegel. “Preferential Logics are X-logics” Journal of Computational Logic, 10, 2000, pp. 1-13. [8] Ginsberg, ML, Smith, DE (July 1988). “Reasoning about action II: the qualification problem”. Artificial Intelligence Vol. 35 No. 3 pp.311-342. [9] Giunchiglia, E., Lee, J., Lifschitz, V., McCain, N., & Turner, H. (March 2004). “Nonmonotonic causal theories”. Artificial Intelligence No. 1-2 vol.153 pp.49-104. [10]Inoue K, “Induction as Consequence Finding”. Machine Learning, 55 (2) :109-135, 2004. [11]Inoue K, Saito H. “Circumscripta Policies for Induction” Proceedings of 14th Conf. on Inductive Logic Programming, LNAI 3194, pp.164-179, Springer, September 2004. [12]K. Inoue, T. Sato, M. Ishihata, Y. Kameya and H. Nabeshima, “Evaluating abductive hypotheses using an em algorithm on bdds”, in: Proceedings of IJCAI-09, Pasadena, CA, 2009, pp. 810–815. [13]Kayser D., Levy F. “Modeling symbolic causal reasoning”, Intellecta 2004 / 1, 38, pp 291-232 [14]Nabeshima H. , Iwanuma K., Inoue K. Ray O. “SOLAR: An automated deduction system for Finding consequence”. AI Commun. 23 (2-3): 183-203 (2010) [15]Roux-Rouquié M., L. Hood, Imbeaud S., Auffray C. “Issues in Computational Methods for Functional Genomics and Systems Biology”. CMSB 2003 : 182-186 [16]Schwind P. , Siegel P: “Modal Logic for Hypothesis Theory”, Fundamentae Informaticae, cal 21, No. 1-2 89-101. [17]Synnaeve G, Inoue K, Doncescu A, Nabeshima N, Kameya Y, Ishihata M., Sato T, “Kinetic models and qualitative abstraction for relational learning in systems biology”, BIOSTEC Bioinformatics 2011 [18]Siegel P. : “A modal language for Nonmonotonic Reasonning”, Proc. Workshop DRUMS / EEC Marseille 24-27 February 90. [19]P. Siegel , C. Schwind, “Modal logic based theory for nonmonotonic reasoning”. Journal of Applied Non-classical Logic, Volume 3 - No. 1 / 1993, P 73-92. [20]Synnaeve G., Doncescu A., Inoue K., “Kinetic models for logic-based hypothesis finding in metabolic pathways”, Int’l Conf. on Inductive Logic Programming (ILP-09), 2009. [21]Tran N. , C. Baral (2007) “Hypothesizing and reasoning about signaling networks”. Journal of Applied Logic 7 (2009) 253-274 96 Bibliographie [22]Barthélémy DWORKIN “Utilisation de SOLAR dans la voie de signalisation ATM-dépendante de la cassure double-brin de l'ADN”. Mémoire de master 2 / Université Paul Sabatier, Toulouse 2011. [23]Toulgoat I. “Modélisation du comportement humain dans les simulations de combat naval”. Thèse doctorat / Université du Sud, Toulon-Var [s.n] 2011. [24]Pommier Y et al. “Targeting Chk2 kinase: Molecular interaction maps and therapeutic rationale”. 2005 [25]Munna L. Agarwal et al. “The p53 Network”, Journal of Biological Chemistry, Vol. 273, No 1, Issue of January 2, pp. 1-4, 1998 [26]P. Siegel, “Représentation et utilization de la connaissance en calcul propositionnel”, Thèse d’État, Université d’Aix-Marseille II, Luminy, France, 1987. [27]Tan Le, A. Doncescu, P. Siegel, “Default Logic for Diagnostic of Discrete Time System”, 8th international conference BWCCA, October 28-30 2013, Compiegne, France, pp. 488-493. [28]Tan Le, A. Doncescu, P. Siegel, “Utilization of Default Logic for Analyzing a Metabolic System in Discrete Time”, 13th international conference ICCSA, June 24-27 2013, Ho Chi Minh City, Vietnam, pp. 130-136. [29]G. Bossu, P. Siegel, “Nonmonotonic Reasoning and databases”, Workshop Logic and Data Bases. CERT - Toulouse - Décembre 1982 [30]G. Bossu, P. Siegel, “Saturation, Nonmonotonic Reasoning and the Closed World Assumption”, Artificial Intelligence 25, Janvier 1985, p. 13-63 [31]J.M. Boi, E. Innocenti, A. Rauzy, P. Siegel, “Production Fields : a New approach to Deduction Problems and two Algorithms for propositional Calculus”, Revue d'Intelligence Artificielle, vol 6 - n° 3/1992 , p 235, 255. Equilibrage de charge dynamique avec un nombre ´ variable de processeurs bas´e sur des m´ethodes de partitionnement de graphe Cl´ement Vuchener To cite this version: Cl´ement Vuchener. Equilibrage de charge dynamique avec un nombre variable de processeurs ´ bas´e sur des m´ethodes de partitionnement de graphe. Distributed, Parallel, and Cluster Computing. Universit´e de Bordeaux, 2014. French. HAL Id: tel-00952777 https://tel.archives-ouvertes.fr/tel-00952777 Submitted on 27 Feb 2014 HAL is a multi-disciplinary open access archive for the deposit and dissemination of scientific research documents, whether they are published or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers. L’archive ouverte pluridisciplinaire HAL, est destin´ee au d´epˆot et `a la diffusion de documents scientifiques de niveau recherche, publi´es ou non, ´emanant des ´etablissements d’enseignement et de recherche fran¸cais ou ´etrangers, des laboratoires publics ou priv´es.THESE ` PRESENT ´ EE´ A` L’UNIVERSITE DE BORDEAUX ´ ECOLE DOCTORALE DE MATH ´ EMATIQUES ET ´ D’INFORMATIQUE Par Cl´ement VUCHENER POUR OBTENIR LE GRADE DE DOCTEUR SPECIALIT ´ E : INFORMATIQUE ´ Equilibrage de charge dynamique avec un nombre ´ variable de processeurs bas´e sur des m´ethodes de partitionnement de graphe Soutenue le : 7 f´evrier 2014 Apr`es avis des rapporteurs : Pierre Manneback Professeur Bora U¸car . . . . . . . . Charg´e de Recherche Devant la commission d’examen compos´ee de : Florent Duchaine . Senior Researcher . . . . Examinateur Aur´elien Esnard . . Maˆıtre de Conf´erences Directeur de Th`ese Pierre Manneback Professeur . . . . . . . . . . . . Pr´esident du Jury & Rapporteur Fran¸cois Pellegrini Professeur . . . . . . . . . . . . Examinateur Jean Roman . . . . . Professeur . . . . . . . . . . . . Directeur de Th`ese Bora U¸car . . . . . . . . Charg´e de Recherches Rapporteur 2014iiiii Remerciements Avant tout, je remercie mes directeurs de th`ese Jean Roman et Aur´elien Esnard qui ont accept´e d’encadrer cette th`ese. Et plus particuli`erement Aur´elien pour tout le temps qu’il m’a accord´e, ces longues discussions qui ont permis `a cette th`ese d’avancer et tous les conseils donn´es. Je remercie Pierre Manneback et Bora U¸car qui ont accept´e de rapporter cette th`ese malgr´e des d´elais tr`es courts, ainsi que les autres membres du jury : Fran¸cois Pellegrini et Florent Duchaine pour l’int´erˆet port´e `a mes travaux. Je remercie ´egalement S´ebastien Fourestier et, encore une fois, Fran¸cois Pellegrini pour toute leur aide sur Scotch et comment y ajouter ma m´ethode de partitionnement. Je remercie toute l’´equipe INRIA HiePACS au sein de laquelle j’ai effectu´e cette th`ese et plus particuli`erement les autres doctorants de l’´equipe qui m’ont tenu compagnie pendant pr`es de trois ans pour certains.ivv Equilibrage de charge dynamique avec un nombre variable ´ de processeurs bas´e sur des m´ethodes de partitionnement de graphe R´esum´e L’´equilibrage de charge est une ´etape importante conditionnant les performances des applications parall`eles. Dans le cas o`u la charge varie au cours de la simulation, il est important de redistribuer r´eguli`erement la charge entre les diff´erents processeurs. Dans ce contexte, il peut s’av´erer pertinent d’adapter le nombre de processeurs au cours d’une simulation afin d’obtenir une meilleure efficacit´e, ou de continuer l’ex´ecution quand toute la m´emoire des ressources courantes est utilis´ee. Contrairement au cas o`u le nombre de processeurs ne varie pas, le r´e´equilibrage dynamique avec un nombre variable de processeurs est un probl`eme peu ´etudi´e que nous abordons ici. Cette th`ese propose diff´erentes m´ethodes bas´ees sur le repartitionnement de graphe pour r´e´equilibrer la charge tout en changeant le nombre de processeurs. Nous appelons ce probl`eme « repartitionnement M × N ». Ces m´ethodes se d´ecomposent en deux grandes ´etapes. Dans un premier temps, nous ´etudions la phase de migration et nous construisons une « bonne » matrice de migration minimisant plusieurs crit`eres objectifs comme le volume total de migration et le nombre total de messages ´echang´es. Puis, dans un second temps, nous utilisons des heuristiques de partitionnement de graphe pour calculer une nouvelle distribution optimisant la migration en s’appuyant sur les r´esultats de l’´etape pr´ec´edente. En outre, nous proposons un algorithme de partitionnement k-aire direct permettant d’am´eliorer le partitionnement biais´e. Finalement, nous validons cette th`ese par une ´etude exp´erimentale en comparant nos m´ethodes aux partitionneurs actuels. Mots-cl´es Simulation num´erique, parall´elisme, ´equilibrage de charge dynamique, redistribution, partitionnement de graphe, repartitionnement.vi Dynamic Load-Balancing with Variable Number of Processors based on Graph Partitioning Abstract Load balancing is an important step conditioning the performance of parallel programs. If the workload varies drastically during the simulation, the load must be redistributed regularly among the processors. Dynamic load balancing is a well studied subject but most studies are limited to an initially fixed number of processors. Adjusting the number of processors at runtime allows to preserve the parallel code efficiency or to keep running the simulation when the memory of the current resources is exceeded. In this thesis, we propose some methods based on graph repartitioning in order to rebalance the load while changing the number of processors. We call this problem “M × N repartitioning”. These methods are split in two main steps. Firstly, we study the migration phase and we build a “good” migration matrix minimizing several metrics like the migration volume or the number of exchanged messages. Secondly, we use graph partitioning heuristics to compute a new distribution optimizing the migration according to the previous step results. Besides, we propose a direct k-way partitioning algorithm that allows us to improve our biased partitioning. Finally, an experimental study validates our algorithms against state-of-the-art partitioning tools. Keywords Numerical simulation, parallelism, dynamic load-balancing, redistribution, graph partitioning, repartitioning.Table des mati`eres 1 Introduction 1 2 Etat de l’art ´ 5 2.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Mod´elisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2 M´ethodes de partitionnement de graphe . . . . . . . . . . . . . . . . . . . 9 2.2.3 Etat de l’art des outils de partitionnement . . . . . . . . . . . . . . . . . . 11 ´ 2.3 Repartitionnement pour l’´equilibrage dynamique . . . . . . . . . . . . . . . . . . 13 2.3.1 Mod´elisation du probl`eme de repartitionnement . . . . . . . . . . . . . . . 13 2.3.2 M´ethodes de repartitionnement de graphe . . . . . . . . . . . . . . . . . . 14 2.4 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3 Mod`ele de migration pour le repartitionnement M × N 25 3.1 Notations et d´efinitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1 G´en´eralit´es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.2 D´efinitions pour le repartitionnement M × N . . . . . . . . . . . . . . . . 27 3.2 Matrices de migration optimales dans le cas ´equilibr´e . . . . . . . . . . . . . . . . 28 3.3 Construction des matrices de migration . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.1 M´ethode bas´ee sur la chaˆıne (1D) . . . . . . . . . . . . . . . . . . . . . . . 35 3.3.2 M´ethode d’appariement (Matching) . . . . . . . . . . . . . . . . . . . . . 42 3.3.3 M´ethode gloutonne (Greedy) . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.3.4 Programme lin´eaire (LP) . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.4 Evaluation des m´ethodes et conclusion . . . . . . . . . . . . . . . . . . . . . . ´ . . 62 4 Repartitionnement M × N 67 4.1 Repartitionnement M × N bas´e sur le partitionnement biais´e (BIASED) . . . . . 67 4.1.1 M´ethodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.1.2 Limitations des partitionneurs . . . . . . . . . . . . . . . . . . . . . . . . 71 4.2 Partitionnement k-aire direct (KGGGP) . . . . . . . . . . . . . . . . . . . . . . . 73 4.2.1 Description de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . 73 4.2.2 Crit`eres de s´election . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.2.3 Complexit´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.2.4 Am´eliorations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.2.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 ´ 4.3 Repartitionnement M × N bas´e sur la diffusion (DIFF) . . . . . . . . . . . . . . 85 4.4 Partitionnement biais´e `a l’aide d’hyper-arˆetes de repartitionnement . . . . . . . . 89 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 viiviii TABLE DES MATIERES ` 5 R´esultats 91 5.1 M´ethodologie exp´erimentale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.2 Influence du coˆut de migration et du facteur de repartitionnement . . . . . . . . 94 5.3 Influence du nouveau nombre de processeurs . . . . . . . . . . . . . . . . . . . . . 97 5.4 Comparaison sur des graphes complexes . . . . . . . . . . . . . . . . . . . . . . . 101 5.5 Etude de la complexit´e en temps . . . . . . . . . . . . . . . . . . . . . . . . . ´ . . 110 6 Conclusion et Perspectives 115 6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116 A Programmes lin´eaires pour optimiser les diff´erentes m´etriques 119 A.1 Minimisation de TotalV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 A.2 Minimisation de MaxV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 A.3 Minimisation de TotalZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 A.4 Minimisation de MaxZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 B Documentation du KGGGP dans Scotch 123 C R´esultats suppl´ementaires 125 C.1 Influence du coˆut de migration et du facteur de repartitionnement . . . . . . . . 125 C.2 Comparaison sur des graphes complexes . . . . . . . . . . . . . . . . . . . . . . . 126 Bibliographie 133 Liste des publications 137Chapitre 1 Introduction Une simulation num´erique mod´elise g´en´eralement l’´evolution en temps d’un ph´enom`ene physique dans un domaine de l’espace. Souvent, on utilise un sch´ema it´eratif en temps et une discr´etisation de l’espace via un maillage d’´el´ements g´eom´etriques (triangles, carr´es, t´etra`edres, etc.). Des simulations de plus en plus complexes demandent une plus grande puissance de calcul. Pour cela, ces applications doivent fonctionner en parall`ele sur plusieurs nœuds de calcul. Les donn´ees sont alors r´eparties sur les diff´erentes unit´es de traitement ou « processeurs ». Les processeurs ne pouvant pas acc´eder directement et rapidement aux donn´ees des autres processeurs, ce parall´elisme induit un surcout dˆu aux communications sur le r´eseau. La m´emoire ´etant distribu´ee, la r´epartition des calculs implique une distribution des donn´ees. Dans ce contexte, la distribution des donn´ees est une ´etape importante conditionnant les performances d’une simulation num´erique et elle est faite selon deux objectifs : — la charge de calcul affect´ee aux diff´erents processeurs doit ˆetre ´equilibr´ee pour minimiser le temps de calcul de chacun ; — les communications inter-processeurs induites par la distribution doivent ˆetre minimis´ees. Certaines simulations num´eriques complexes ont une charge de calcul qui peut ´evoluer de fa¸con impr´evisible ; c’est le cas par exemple des simulations de type AMR (Adaptive Mesh Refinement) o`u la discr´etisation de l’espace ´evolue pour ˆetre plus fine autour de points d’int´erˆet. La charge de certains processeurs peut augmenter plus rapidement que d’autres et il n’est alors plus possible de garder une mˆeme distribution tout le long de la simulation. De nouvelles distributions doivent ˆetre recalcul´ees pour r´e´equilibrer la charge lorsque le d´es´equilibre devient trop important. On parle alors d’´equilibrage dynamique. En plus des deux objectifs pr´ec´edents, la nouvelle distribution doit r´epondre `a deux nouvelles contraintes : — la nouvelle partition doit ˆetre calcul´ee rapidement en parall`ele ; — la migration des donn´ees n´ecessaire pour passer de l’ancienne distribution `a la nouvelle doit ˆetre la plus rapide possible, c’est-`a-dire qu’il faut que le moins possible de donn´ees ne change de processeurs. Le probl`eme de calcul de telles distributions peut ˆetre r´esolu `a l’aide du partitionnement d’un graphe non-orient´e en k parties. Les sommets du graphe repr´esentent les calculs et les arˆetes repr´esentent les d´ependances entre ces calculs. Chaque partie repr´esente l’ensemble des calculs affect´es `a un processeur. Deux sommets connect´es qui se trouvent dans deux parties diff´erentes (on dira que l’arˆete est coup´ee) induisent un besoin de communication entre ces deux processeurs. L’objectif de la distribution devient alors de construire une partition dont les parties sont de mˆeme taille et coupant un minimum d’arˆetes. Dans le cas de l’´equilibrage dynamique, on parlera de « repartitionnement ». Le partitionnement de graphe est un probl`eme d´ej`a bien ´etudi´e, que 12 CHAPITRE 1. INTRODUCTION ce soit dans le cas statique o`u une seule partition est calcul´ee, ou dynamique o`u la partition est recalcul´ee r´eguli`erement. Augmentation de la charge M = 4 N = 6 Figure 1.1 – Allocation dynamique de processeurs pour un code parall`ele dont la charge augmente. Lorsque la charge de calcul varie de fa¸con importante, il peut devenir int´eressant de changer le nombre de processeurs allou´es. Cela peut permettre de continuer la simulation quand toute la m´emoire des processeurs est utilis´ee, ou ainsi d’am´eliorer la consommation des ressources pour garder une bonne efficacit´e au cours de la simulation. Par exemple, un code AMR utilise initialement un maillage tr`es simple avec peu d’´el´ements, qu’il ne serait pas efficace de distribuer sur un grand nombre de processeurs. Avec le raffinement du maillage, la quantit´e de calcul augmente de fa¸con importante, et la parall´elisation sur un plus grande nombre de processeurs devient plus int´eressante, voire n´ecessaire si la taille du probl`eme d´epasse la capacit´e m´emoire des processeurs d´ej`a allou´es. Il faut alors ˆetre capable de calculer une nouvelle distribution pour un plus grand nombre de processeurs, comme illustr´e en figure 1.1. Augmentation de la charge relative A/B M + M' = 6 N + N' = 6 A B A B Figure 1.2 – Allocation dynamique de processeurs pour deux codes coupl´es A et B dont la charge relative de A par rapport `a B augmente. L’allocation dynamique de processeurs est ´egalement utile dans le cas des codes coupl´es. Ce sont diff´erents codes s’ex´ecutant en parall`ele et collaborant pour r´ealiser une simulation plus complexe. Ces codes doivent r´eguli`erement ´echanger des donn´ees entre eux durant la « phase de couplage » qui induit une synchronisation plus ou moins explicite. Il est donc n´ecessaire que les diff´erents codes avancent `a la mˆeme vitesse pour ne pas se ralentir entre eux. Cet ´equilibrage entre les codes peut s’av´erer tr`es difficile `a cause des natures tr`es diff´erentes de ces codes, ou dans le cas o`u au moins un des codes a une charge de calcul qui ´evolue dynamiquement. La figure 1.2 pr´esente un exemple avec deux codes coupl´es A et B utilisant initialement 3 processeurs chacun. Si le code B devient trop rapide par rapport `a A, on peut transf´erer un processeur du code B vers A. Cette th`ese propose un ensemble de m´ethodes permettant de r´esoudre le probl`eme d’´equilibrage dynamique de la charge avec changement du nombre de processeurs, et ce en se basant sur3 le repartitionnement de graphe. Nous appellerons ce probl`eme, le repartitionnement M × N. Ce repartitionnement doit r´ealiser les diff´erents objectifs d´ej`a cit´es : — ´equilibrage de la charge ; — minimisation des communications dues aux d´ependances de calculs ; — rapidit´e de calcul de la nouvelle partition ; — minimisation des communications dues `a la redistribution. Ceci devra ˆetre fait en prenant en compte `a la fois une charge variable et un nombre de processeurs variable. Ces m´ethodes de repartitionnement se divisent en deux ´etapes : la construction d’une matrice de migration puis le repartitionnement bas´e sur cette matrice de migration. Plusieurs m´ethodes de construction de matrices de migration permettent d’optimiser diff´erentes m´etriques relatives `a la migration des donn´ees. Deux m´ethodes de repartitionnement sont pr´esent´ees : l’une de partitionnement biais´e et l’autre diffusive. De plus, des limitations des m´ethodes de bissections r´ecursives utilis´ees habituellement sont mises en ´evidence dans le cadre du partitionnement biais´e et nous proposons une m´ethode de partitionnement k-aire direct pour y rem´edier. Nous commencerons par pr´esenter un ´etat de l’art du partitionnement et repartitionnement de graphe (chapitre 2). Puis, dans le chapitre 3, nous d´efinirons et construirons des mod`eles pour la migration. Le chapitre 4 pr´esentera des m´ethodes de repartitionnement s’appuyant sur les mod`eles de migration introduits au chapitre pr´ec´edent. Puis, nous ´evaluerons nos m´ethodes au travers d’une s´erie d’exp´eriences comparatives avec d’autres outils de repartitionnement de graphe (chapitre 5). Finalement, nous conclurons et pr´esenterons quelques pistes d’am´eliorations de ces m´ethodes dans le chapitre 6. Plusieurs annexes compl`etent ce manuscrit.4 CHAPITRE 1. INTRODUCTIONChapitre 2 Etat de l’art ´ Sommaire 2.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Mod´elisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2.2 M´ethodes de partitionnement de graphe . . . . . . . . . . . . . . . . . 9 2.2.3 Etat de l’art des outils de partitionnement . . . . . . . . . . . . . . . . ´ 11 2.3 Repartitionnement pour l’´equilibrage dynamique . . . . . . . . . . 13 2.3.1 Mod´elisation du probl`eme de repartitionnement . . . . . . . . . . . . . 13 2.3.2 M´ethodes de repartitionnement de graphe . . . . . . . . . . . . . . . . 14 2.4 Positionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.1 Contexte Une simulation num´erique mod´elise l’´evolution d’un ph´enom`ene physique dans le temps sur un domaine de l’espace. Ces simulations s’appuient sur une discr´etisation en temps et en espace. Le domaine de l’espace simul´e est discr´etis´e `a l’aide d’un maillage d’´el´ements g´eom´etriques : triangles, carr´es, t´etra`edres, ... La discr´etisation en temps permet de calculer l’´etat du syst`eme `a un instant donn´e `a partir de l’´etat pr´ec´edent. Plus pr´ecis´ement, l’´etat d’un ´el´ement est calcul´e `a partir de son ´etat pr´ec´edent et de l’´etat de quelques autres ´el´ements en fonction du mod`ele physique ; g´en´eralement, ce sont les ´el´ements voisins dans le maillage. Ces simulations, de plus en plus complexes, n´ecessitent d’ˆetre ex´ecut´ees en parall`ele. Le domaine doit donc ˆetre distribu´e parmi plusieurs unit´es de calcul. Le maillage est donc d´ecoup´e en autant de parties que de processeurs utilis´es. Le calcul de l’´etat d’un ´el´ement d´ependant de l’´etat d’autres ´el´ements, le plus souvent dans son voisinage, cette distribution induit des communications entre processeurs quand l’un d’entre eux n´ecessite les donn´ees poss´ed´ees par un autre. Ces communications sont synchronisantes et tous les processeurs doivent donc faire progresser la simulation au mˆeme rythme. Une bonne distribution ou partition des donn´ees doit donc fournir des parties ´equilibr´ees et minimisant le nombre de d´ependances de donn´ees entre processeurs, minimisant ainsi le temps de calcul et de communication. Par exemple, un code simulant la diffusion de la chaleur sur un maillage calcule la chaleur de chaque ´el´ement `a partir de sa propre chaleur et de celle des ´el´ements voisins `a l’it´eration pr´ec´edente. Une unit´e de calcul travaillant 56 CHAPITRE 2. ETAT DE L’ART ´ sur un domaine doit donc recevoir les temp´eratures des ´el´ements sur la fronti`ere des domaines voisins. La distribution des donn´ees peut ˆetre statique, c’est-`a-dire fix´ee au d´ebut de la simulation, ou dynamique qui ´evolue au cours de la simulation. Certaines simulations utilisent des maillages dynamiques : le domaine de simulation peut s’´etendre, par exemple pour la simulation d’une explosion, ou le maillage peut ˆetre raffin´e autour de certains points d’int´erˆet permettant ainsi d’utiliser peu d’´el´ements tout en gardant une bonne pr´ecision l`a o`u c’est n´ecessaire. Cette derni`ere m´ethode est appel´ee Adaptive Mesh Refinment (AMR). Au cours de ces simulations dynamiques, la charge de calcul des processeurs ´evolue de fa¸con h´et´erog`ene. Il est donc n´ecessaire de r´e´equilibrer r´eguli`erement cette charge en calculant une nouvelle partition des donn´ees. Une fois cette nouvelle partition r´ealis´ee, les donn´ees doivent ˆetre migr´ees vers leur nouveau propri´etaire. La nouvelle partition doit optimiser cette phase de migration en plus des crit`eres pr´ec´edents. Il existe une grande vari´et´e de m´ethodes pour partitionner des maillages. Les plus courantes sont les m´ethodes g´eom´etriques, s’appuyant uniquement sur les coordonn´ees des ´el´ements dans l’espace, et les m´ethodes bas´ees sur les graphes utilisant les d´ependances de calcul entre ´el´ements et ne s’int´eressant plus qu’`a la topologie et non `a la g´eom´etrie du probl`eme. 2.2 Partitionnement Le partitionnement de maillages `a l’aide de graphes utilise les d´ependances de calcul entre les ´el´ements pour construire un graphe. Certains partitionneurs utilisent un mod`ele d’hypergraphe, plus g´en´eral que le mod`ele de graphe. Un partitionneur de graphe ou d’hypergraphe calcule des partitions en prenant en compte deux objectifs : — les parties doivent ˆetre ´equilibr´ees, c’est-`a-dire de mˆeme taille. Les partitionneurs sont g´en´eralement tol´erants et se contentent de cr´eer des parties `a peu pr`es ´equilibr´ees `a un « facteur de d´es´equilibre » pr`es. Un facteur de d´es´equilibre de 5% veut dire qu’une partie pourra atteindre jusqu’`a 1, 05 fois sa taille id´eale. Ce premier objectif permet d’optimiser le temps de calcul de la simulation. — une fonction de coˆut, appel´ee coupe du graphe, est minimis´ee. Cette fonction de coˆut varie suivant les mod`eles mais repr´esente le temps de communication entre les processeurs. 2.2.1 Mod´elisation Pour pouvoir appliquer le partitionnement de graphe ou d’hypergraphe `a un probl`eme donn´e, il est n´ecessaire de mod´eliser celui-ci. Il est important de choisir une mod´elisation adapt´ee au probl`eme pour que le partitionneur puisse cr´eer une partition optimisant les bons crit`eres pour cette simulation. a) Mod´elisation `a l’aide de graphes L’approche la plus courante consiste `a mod´eliser les ´el´ements `a distribuer sous forme d’un graphe. Le graphe construit doit mod´eliser les contraintes du calcul distribu´e : ´equilibrage de charge et r´eduction de communications. Un graphe est d´efini par un ensemble de sommets et un ensemble d’arˆetes connectant les sommets par paires. Le graphe est donc construit avec un sommet pour repr´esenter chaque ´el´ement. Les arˆetes de ce graphe servent `a repr´esenter les d´ependances entre les ´el´ements. Par exemple, le calcul sur un ´el´ement peut n´ecessiter les donn´ees des ´el´ements voisins dans le maillage. Un sommet est donc connect´e `a tous les sommets repr´esentant les ´el´ements voisins dans le maillage.2.2. PARTITIONNEMENT 7 Si des ´el´ements sont associ´es `a des charges de calcul diff´erentes, il est possible d’associer des poids aux sommets repr´esentant ces charges de calcul. De la mˆeme fa¸con, si certaines communications sont plus coˆuteuses que d’autres, un poids peut ˆetre affect´e aux arˆetes. Un partitionneur de graphe optimise deux objectifs : l’´equilibrage et la coupe. La taille d’une partie est le nombre de sommets dans cette partie ou, s’ils sont pond´er´es, la somme des poids de ceux-ci. La fonction de coˆut la plus g´en´eralement utilis´ee dans les partitionneurs de graphe est le nombre d’arˆetes coup´ees (ou la somme de leurs poids). Une arˆete est dite « coup´ee » lorsque ses deux extr´emit´es sont affect´ees `a des parties diff´erentes. On vise ainsi `a r´eduire le volume de donn´ees `a communiquer entre processeurs. La figure 2.1 pr´esente la mod´elisation d’un maillage : une grille de 2 × 3 carr´es sous forme de graphe. Chaque sommet du graphe correspond `a un carr´e de la grille et est reli´e aux sommets correspondant `a ses voisins dans le maillage. Figure 2.1 – Un maillage de 6 ´el´ements et le graphe associ´e mod´elisant les d´ependances. Cette mod´elisation, bien que tr`es r´epandue, ne mod´elise pas toujours parfaitement le volume de communication n´ecessaire pour la distribution induite. On pourrait penser que comme une arˆete relie deux sommets, chaque arˆete coup´ee induit deux sommets devant communiquer. Mais un sommet peut avoir plusieurs arˆetes coup´ees par la mˆeme partie et la coupe du graphe peut sur´evaluer le volume de communication induit par cette partition. Sur la figure 2.2, un maillage de 6 ´el´ements est partitionn´e en deux : une partie bleue et une partie verte. Il y a 4 ´el´ements qui ont au moins un voisin dans l’autre partie, ce sont les ´el´ements qui ont besoin d’ˆetre communiqu´es avec l’autre processeur. Mais 3 arˆetes sont coup´ees par la partition. Figure 2.2 – Maillage et graphe partitionn´es en deux.8 CHAPITRE 2. ETAT DE L’ART ´ Figure 2.3 – Un maillage de 6 ´el´ements et l’hypergraphe associ´e mod´elisant les d´ependances. Pour ne pas surcharger le dessin, seule l’hyper-arˆete correspondant `a l’´el´ement rouge est repr´esent´ee. b) Mod´elisation `a l’aide d’hypergraphes Il est ´egalement possible d’utiliser une mod´elisation `a partir d’hypergraphe. Le partitionnement d’hypergraphe est depuis longtemps utilis´e pour le partitionnement de VLSI [33, 59], mais il est ´egalement int´eressant dans le cas du partitionnement de matrices ou de maillages [63]. Les hypergraphes sont des extensions des graphes, o`u une arˆete appel´ee hyper-arˆete, ne connecte plus deux sommets mais un nombre quelconque de sommets. Un graphe peut ˆetre consid´er´e comme un hypergraphe particulier contenant uniquement des hyper-arˆetes de taille 2. Ces hyper-arˆetes plus complexes rendent la repr´esentation graphique des hypergraphe plus difficile. Il existe plusieurs fa¸cons de repr´esenter une hyper-arˆete ; par exemple, on peut dessiner une courbe entourant les sommets inclus dans l’hyper-arˆete. Il est aussi possible de repr´esenter une hyper-arˆete par un sommet sp´ecial reli´e aux sommets qu’elle connecte. Cette repr´esentation est en fait celle d’un graphe biparti dont les parties sont l’ensemble des sommets et l’ensemble des hyper-arˆetes. Comme avec les graphes, chaque ´el´ement d’un maillage est repr´esent´e par un sommet de l’hypergraphe. Mais les hyper-arˆetes permettent de mod´eliser diff´eremment les d´ependances. Une hyper-arˆete est associ´ee `a chaque sommet, repr´esentant toutes les d´ependances de cet ´el´ement. Une hyper-arˆete contient donc le sommet auquel elle est associ´ee, ainsi que tous les sommets qui d´ependent de celui-ci. La figure 2.3 montre une hyper-arˆete de l’hypergraphe mod´elisant la grille 2×3. Cette hyperarˆete est associ´ee au sommet rouge et contient tous les sommets voisins. Cette nouvelle mod´elisation des d´ependances permet d’utiliser des mod`eles de coupe diff´erents repr´esentant mieux les communications induites par le partitionnement. La coupe connectivit´e−1, aussi app´el´ee λ−1, permet de repr´esenter fid`element les communications [63]. Ce mod`ele de coupe prend en compte le nombre de parties coupant une arˆete. Si une hyper-arˆete est coup´ee par λ parties, son poids est compt´e λ−1 fois dans la coupe finale. En effet, une hyper-arˆete est associ´ee `a un ´el´ement et λ parties poss`edent des ´el´ements appartenant `a cette hyper-arˆete. Ces ´el´ements sont soit ceux qui ont une d´ependance sur l’´el´ement associ´e `a l’hyper-arˆete, soit l’´el´ement luimˆeme. Parmi ces λ parties, une poss`ede l’´el´ement et les λ−1 autres devront recevoir les donn´ees associ´ees `a cet ´el´ement. La figure 2.4 montre la mˆeme partition que la figure 2.2 mais en utilisant un mod`ele d’hypergraphe. Parmi les 6 hyper-arˆetes de cet hypergraphe, 4 sont coup´ees (en rouge). Ce sont les hyper-arˆetes associ´ees aux sommets se trouvant sur la fronti`ere. La mod´elisation `a l’aide d’hypergraphe permet de mod´eliser exactement la quantit´e de donn´ees se trouvant sur la fronti`ere des domaines contrairement `a la mod´elisation `a l’aide de graphe.2.2. PARTITIONNEMENT 9 Figure 2.4 – Maillage et hypergraphe partitionn´e en deux. Les hyper-arˆetes en rouge sont coup´ees par les deux parties. c) Sommets fixes Certains partitionneurs permettent d’utiliser des sommets fixes. Ces sommets sont initialement fix´es dans une partie et le partitionneur ne remettra pas en cause cette affectation, mais en tiendra compte dans l’´equilibrage et l’optimisation de la coupe. Les sommets fixes ont ´et´e largement utilis´es dans le cadre du partitionnement de VLSI [7] mais ont ´egalement trouv´e une utilisation dans le cadre du r´e´equilibrage dynamique [2, 9]. Le probl`eme de partitionnement `a sommets fixes est une version plus contrainte du partitionnement de graphe ou hypergraphe compl`etement libre. Bien que le probl`eme puisse paraitre plus simple, comme il y a moins de sommets `a placer dans les diff´erentes parties, les heuristiques ´elabor´ees pour le partitionnement libre peuvent avoir du mal `a prendre en compte ces nouvelles contraintes [3, 7]. 2.2.2 M´ethodes de partitionnement de graphe Le partitionnement d’un graphe ou d’un hypergraphe est un probl`eme NP-complet [20, GRAPH PARTITIONING]. On utilise donc diverses heuristiques pour pouvoir calculer une partition en un temps raisonnable. La plupart des m´ethodes utilis´ees s’appliquent aussi bien sur des graphes que sur des hypergraphes. La plupart des partitionneurs de graphe ou d’hypergraphe utilisent des m´ethodes appel´ees « multi-niveaux » [4, 22, 36]. L’approche multi-niveaux permet d’acc´el´erer les m´ethodes de partitionnement classiques tout en gardant une bonne qualit´e. Cette approche se d´ecompose en trois ´etapes, comme indiqu´e en figure 2.5. G0 G1 Gk ... P0 P1 Pk ... Contraction Expansion Partitionnement Initial Figure 2.5 – Phases d’un partitionnement multi-niveaux.10 CHAPITRE 2. ETAT DE L’ART ´ La phase de contraction : Dans un premier temps, la taille du graphe est r´eduite en fusionnant des sommets. Cela est r´ep´et´e pendant plusieurs it´erations, jusqu’`a obtenir un graphe suffisamment petit. Une suite de graphes de taille d´ecroissante a ainsi ´et´e cr´e´ee : (G0, G1, . . . , Gk). Le partitionnement initial : Une fois que le graphe a ´et´e suffisamment contract´e, on applique une heuristique de partitionnement pour calculer la partition Pk du graphe Gk. N’importe quelle strat´egie de partitionnement peut ˆetre appliqu´ee ici. Certaines seront d´etaill´ees par la suite. La phase d’expansion : La suite des diff´erents graphes construits pendant l’´etape de contraction est alors « remont´ee ». La partition Pi+1 du graphe Gi+1 est prolong´ee sur le graphe Gi puis cette nouvelle partition Pi est raffin´ee `a l’aide d’une heuristique am´eliorant localement la coupe. a) Strat´egies de contraction Il existe plusieurs heuristiques pour s´electionner les sommets `a fusionner. La plus connue, appel´ee Heavy Edge Matching (HEM), recherche les arˆetes de poids les plus ´elev´es et en fusionne les deux extr´emit´es. Cette op´eration est r´ep´et´ee jusqu’`a obtenir un graphe suffisamment petit. Dans un partitionneur supportant les sommets fixes, ces derniers doivent ˆetre trait´es de mani`ere particuli`ere pendant la phase de contraction. En effet, le graphe contract´e doit garder les mˆemes informations sur les sommets fixes. Dans certains partitionneurs, il peut ˆetre d´ecid´e de ne jamais fusionner ces sommets fixes. Dans d’autres, il peut ˆetre d´ecid´e de les fusionner seulement avec des sommets non fix´es ou fix´es dans la mˆeme partie. Dans ce cas, le sommet obtenu apr`es fusion est consid´er´e comme un sommet fixe dans le graphe contract´e. b) Strat´egies de partitionnement initial La strat´egie de partitionnement utilis´ee au niveau le plus bas dans un partitionneur multiniveaux peut ˆetre n’importe quelle strat´egie de partitionnement, y compris un autre algorithme multi-niveaux. Il existe une tr`es grande vari´et´e de m´ethodes de partitionnement ou de bissection comme par exemple des algorithmes gloutons ajoutant les sommets un `a un dans les parties [5, 6, 29], ou des algorithmes spectraux utilisant des propri´et´es d’alg`ebre lin´eaire pour obtenir une partition [53]. La strat´egie la plus utilis´ee est celle des bissections r´ecursives. Le graphe est coup´e r´ecursivement en deux parties jusqu’`a obtenir le nombre de parties souhait´e. Il est possible d’obtenir un nombre de parties qui n’est pas une puissance de 2 en cr´eant des parties d´es´equilibr´ees. Par exemple pour obtenir 3 parties, on cr´ee deux parties avec les proportions 1/3 et 2/3, la partie de taille 2/3 est ensuite coup´ee en deux parties ´egales de 1/3 chacune. Son int´erˆet r´eside dans la grande vari´et´e et qualit´e des heuristiques de bissection souvent mieux maˆıtris´ees que les heuristiques de partitionnement k-aires [35]. Le graphe peut ´egalement ˆetre partitionn´e directement en k parties ; on parlera de partitionnement k-aire direct. Ces strat´egies peuvent ˆetre plus rapides que les bissections r´ecursives car une seule partition est calcul´ee. Th´eoriquement, le partitionnement k-aire direct permet une meilleure qualit´e car il profite d’une vision globale du probl`eme que les bissections r´ecursives n’ont pas [60]. Mais en pratique, il est plus difficile de calculer une bonne partition k-aire directement et la m´ethode des bissections r´ecursives donne souvent de meilleurs r´esultats [35].2.2. PARTITIONNEMENT 11 c) Strat´egies de raffinement utilis´ees dans la phase d’expansion Les strat´egies de raffinement modifient une partition d´ej`a existante en changeant quelques sommets de partie pour am´eliorer la coupe. L’algorithme de Kernighan et Lin [39] (KL) raffine une bissection en cherchant des paires de sommets dont l’´echange am´eliore le plus la coupe (ou la d´egrade le moins). Un sommet d´eplac´e ne sera plus consid´er´e pour un ´echange dans la mˆeme passe. Ces ´echanges sont consid´er´es mˆeme s’ils d´egradent la coupe, cela permettant de ne pas rester bloqu´e sur une solution localement optimale mais qui pourrait ˆetre am´elior´ee en s’en ´eloignant plus. A la fin de la passe, seuls les ´echanges ` menant `a la meilleure coupe sont conserv´es. L’´echange par paires permet de conserver l’´equilibre mais rend l’algorithme complexe. Plusieurs passes peuvent ˆetre appliqu´ees pour am´eliorer encore plus la coupe. Fiduccia et Mattheyses [17] (FM) s’inspirent de cet algorithme pour d´ecrire un raffinement lin´eaire en temps en ne d´epla¸cant les sommets que un par un et grˆace `a une structure de donn´ees adapt´ee. L’´equilibre est conserv´e en se refusant d’effectuer des d´eplacements qui d´es´equilibreraient trop la partition, c’est-`a-dire que la partition d´epasserait la taille maximale donn´ee par le facteur de d´es´equilibre. Cet algorithme, initialement con¸cu pour les bissections, a ´egalement l’avantage de s’´etendre facilement aux k-partitions. Le principe g´en´eral reste le mˆeme, mais il y a plusieurs d´eplacements `a consid´erer pour chaque sommet. Les sommets fixes s’int`egrent facilement aux m´ethodes de types KL/FM, car il suffit de ne pas consid´erer ces sommets parmi les d´eplacements possibles. Comme un algorithme de raffinement se contente d’am´eliorer une partition d´ej`a existante en ne d´epla¸cant souvent que les sommets le long de la fronti`ere, il n’est pas toujours n´ecessaire de l’appliquer sur le graphe entier. Ces strat´egies sont souvent appliqu´ees sur un graphe « bande » ne contenant que les sommets `a une certaine distance de la fronti`ere entre les parties, les autres sommets ´etant r´eunis en un seul sommet fixe pour chaque partie appel´e « ancre ». La taille du probl`eme est ainsi largement r´eduite [10]. D’autres m´ethodes de raffinement s’inspirent de la diffusion d’un liquide dans le graphe [42,49]. Ces m´ethodes se basent sur des graphes bandes : un type liquide diff´erent pour chaque partie est inject´e dans chaque sommet ancre. Le liquide se diffuse it´erativement dans le graphe le long des arˆetes et est d´etruit lorsqu’il rencontre un autre type de liquide. Quand un sommet re¸coit plusieurs type de liquide, il choisit la partie dont il en re¸coit le plus. Cette heuristique tend `a cr´eer des parties aux formes tr`es lisses mais la coupe n’est pas toujours optimale. Elle aussi pour avantage d’ˆetre locale et donc d’ˆetre plus efficace en parall`ele que les heuristiques de type KL/FM. 2.2.3 Etat de l’art des outils de partitionnement ´ Il existe une grande vari´et´e d’outils de partitionnement. Le tableau 2.1 pr´esente quelques partitionneurs de graphe ou d’hypergraphe et quelques unes de leurs fonctionnalit´es. Les sommets fixes sont surtout support´es par les partitionneurs d’hypergraphe car ils sont utilis´es depuis longtemps pour le partitionnement de circuits int´egr´es (VLSI). Beaucoup de partitionneurs offrent le choix entre un partitionnement multi-niveaux r´ecursif ou directement k-aire, mais le partitionnement initial du multi-niveaux direct utilise le plus souvent des bissections r´ecursives. Metis [31] est un des partitionneurs les plus connus et utilis´es. Il poss`ede deux m´ethode de partitionnement : r´ecursif ou k-aire mais la m´ethode k-aire se base sur des bissections r´ecursives pour son partitionnement initial. Il existe ´egalement une version parall`ele : ParMetis permettant de cr´eer une partition en parall`ele sur au moins 2 processus. ParMetis propose ´egalement une m´ethode de repartitionnement permettant de r´e´equilibrer une partition existante [57]. hMetis est un partitionneur d’hypergraphe ´egalement disponible en version r´ecursive ou k-aire. Il supporte12 CHAPITRE 2. ´ETAT DE L’ART Outil Type Sommets fixes Parall`ele Type de multi-niveaux Partitionnement initial Metis [31] graphe non non bissections [34] — k-aire [35] bissections ParMetis [32] graphe non oui k-aire [37] bissections hMetis [30] hypergraphe oui non bissections [33] — non k-aire [38] bissections PaToH [64] hypergraphe oui non bissections — kPaToH [3] hypergraphe oui non k-aire bissections + matching Zoltan [1] hypergraphe oui oui bissections — Scotch [48] graphe oui non bissections — k-aire bissections PT-Scotch [48] graphe non oui bissections RM-Metis [2] graphe oui (exactement k) non k-aire k-aire direct (GGGP) Mondriaan [62] hypergraphe non non bissections — ML-Part [47] hypergraphe oui non bissections — Parkway [61] hypergraphe non oui k-aire bissections Chaco [24] graphe non non bissections — Table 2.1 – Partitionneurs de graphe et d’hypergraphe.2.3. REPARTITIONNEMENT POUR L’EQUILIBRAGE DYNAMIQUE ´ 13 les sommets fixes mais ne peut optimiser que le nombre d’hyper-arˆetes coup´ees et non la coupe λ − 1. Scotch [48] est un partitionneur de graphe et de maillage sous licence libre. Il est tr`es configurable et modulaire. Il propose une grande vari´et´e de m´ethodes de partitionnement, mais seulement des m´ethodes de bissections sont disponibles pour le partitionnement initial. Depuis sa derni`ere version (6.0), il permet d’utiliser des sommets fixes et de r´e´equilibrer une partition existante. PT-Scotch est la version parall`ele multi-thread et multi-processus de Scotch. Zoltan [1] est une biblioth`eque permettant de g´erer la distribution des donn´ees pour des applications parall`eles. Il offre en particulier des fonctionnalit´es de partitionneur. Il est possible d’utiliser ParMetis ou Scotch, mais il contient ´egalement son propre partitionneur d’hypergraphe. Le partitionneur d’hypergraphe de Zoltan utilise des bissections r´ecursives et supporte les sommets fixes. Il est ´egalement capable de r´e´equilibrer la distribution des donn´ees lorsque celles-ci ´evoluent dynamiquement [8, 9]. 2.3 Repartitionnement pour l’´equilibrage dynamique Dans certaines simulations num´eriques, la charge varie dynamiquement. C’est par exemple le cas des simulations AMR (Adaptive Mesh Refinement) dans lesquelles la r´esolution du maillage s’adapte dynamiquement pour r´eduire la quantit´e de calcul tout en gardant une pr´ecision suffi- sante l`a o`u elle est n´ecessaire. La charge ne varie pas de fa¸con homog`ene et il devient n´ecessaire apr`es un certain temps de simulation de r´e´equilibrer la charge entre les diff´erents processeurs. Le graphe repr´esentant les donn´ees doit alors ˆetre « repartitionn´e ». Les objectifs du repartitionnement de graphe sont : — la charge de calcul doit ˆetre ´equilibr´ee entre tous les processeurs ; — le volume de donn´ees `a communiquer entre les processeurs doit ˆetre minimal ; — le temps de calcul de la nouvelle partition doit ˆetre minimal ; — la migration des donn´ees, c’est `a dire l’envoi depuis l’ancien propri´etaire des sommets vers le nouveau, doit ˆetre le plus rapide possible. Aux deux premiers objectifs communs avec le partitionnement classique, on ajoute la minimisation du temps de repartitionnement (calcul de la nouvelle partition et migration induite par celle-ci). Notons que pour obtenir une partition de qualit´e (d’apr`es les deux premiers crit`eres), il est souvent n´ecessaire de migrer beaucoup de sommets. 2.3.1 Mod´elisation du probl`eme de repartitionnement On peut exprimer le temps total de la simulation (Ttotal) `a minimiser sous la forme [8, 57] : Ttotal = α × (Tcalcul + Tcomm) + Trepart + Tmig avec : — α le nombre d’it´erations avant que la partition devienne trop d´es´equilibr´ee et qu’un repartitionnement devienne n´ecessaire ; — Tcalcul le temps d’une it´eration de calcul, pris sur le processeur le plus lent et donc minimis´e par l’´equilibrage ; — Tcomm le temps des communications entre processeurs, correspondant `a la coupe du graphe ; — Trepart le temps pass´e `a calculer la nouvelle partition ; — Tmig le temps de migration des sommets vers leur nouvelle partie.14 CHAPITRE 2. ETAT DE L’ART ´ Ce mod`ele d’une simulation it´erative est repr´esent´e en figure 2.6. Apr`es chaque it´eration de calcul, les processeurs effectuent une phase de communication collective qui les synchronise ; le temps de calcul en parall`ele est donc celui du processeur le plus lent. Apr`es α = 3 it´erations, la partition devient trop d´es´equilibr´ee ; une nouvelle partition est calcul´ee lors du repartitionnement puis les sommets sont migr´es pour respecter cette nouvelle partition. En pratique, le repartitionnement n’est pas effectu´e apr`es un nombre fixe d’it´erations mais quand le d´es´equilibre d´epasse un certain seuil. On peut alors consid´erer que α est le nombre moyen d’it´erations avant que ce seuil soit d´epass´e. Obtenir une nouvelle partition de qualit´e (c’est-`a-dire avec Tcalcul et Tcomm faibles), impose un repartitionnement plus complexe et une nouvelle partition plus ´eloign´ee de l’ancienne (Trepart et Tmig plus ´elev´es). Il est donc n´ecessaire de r´ealiser un compromis suivant la valeur de α entre la qualit´e de la nouvelle partition et la rapidit´e de sa construction et mise en place. Si le besoin de repartitionnement est rare (α ´elev´e), il faut privil´egier la qualit´e de la partition avant celle de la migration. Mais pour les applications tr`es dynamiques qui n´ecessitent des repartitionnements fr´equents (α faible), il faut mieux privil´egier la migration devant la qualit´e de la partition qui se d´egradera de toute fa¸con rapidement. Concernant la migration, diff´erents crit`eres peuvent ˆetre optimis´es [44]. L’objectif le plus souvent optimis´e est le volume total des donn´ees migr´ees, appel´e volume total de migration. Mais il peut aussi ˆetre int´eressant de minimiser le volume de migration par processeur, ou encore le nombre de messages n´ecessaires `a la migration d’un point de vue global ou par processeur. Les communications de migration peuvent ˆetre mod´elis´ees par une matrice que nous appellerons matrice de migration dans laquelle chaque ´el´ement repr´esente le volume de donn´ees d’un message. Chaque ligne est associ´ee `a un processeur (et `a son ancienne partie) et chaque colonne est associ´ee `a une nouvelle partie. L’´el´ement (i, j) repr´esente le volume de donn´ees que le processeur i enverra au processeur associ´e `a la nouvelle partie j. La figure 2.7 pr´esente deux exemples de repartitionnement. La partition initiale sur la fi- gure 2.7a est d´es´equilibr´ee : la partie 1 poss`ede quatre sommets alors que la partie 3 n’en a que deux. Les figures 2.7b et 2.7c pr´esentent deux nouvelles partitions et les matrices de migrations associ´ees. Les sommets migrants (en rouge) correspondent aux ´el´ements hors diagonale alors que les sommets ne migrant pas correspondent aux ´el´ements de la diagonale (les messages qu’une partie « s’envoie » `a elle-mˆeme). Par exemple, sur la figure 2.7c, la nouvelle partie 4 contient deux sommets de l’ancienne partie 4 et un de l’ancienne partie 1 : la quatri`eme colonne de la matrice contient donc un 1 sur la premi`ere ligne et un 2 sur la quatri`eme. 2.3.2 M´ethodes de repartitionnement de graphe Pour ´equilibrer la charge, il existe diff´erentes approches bas´ees sur le repartitionnement de graphe dont les plus courantes sont le Scratch-Remap, les m´ethodes diffusives et le partitionnement biais´e. Il existe d’autres approches bas´ees des m´ethodes g´eom´etriques (bissections r´ecursives ou SFC [52]) ou encore des m´ethodes spectrales modifi´ees pour prendre en compte la migration [23]. Nous allors maintenant pr´esenter les trois approches les plus courantes. a) Scratch-Remap La m´ethode la plus simple et la plus ´evidente est le « Scratch-Remap ». Cette m´ethode se d´ecompose en deux ´etapes. Dans un premier un temps, le graphe est partitionn´e « from scratch », c’est-`a-dire sans prendre en compte l’ancienne partition. Ensuite les parties obtenues sont renum´erot´ees pour optimiser la migration.2.3. REPARTITIONNEMENT POUR L’EQUILIBRAGE DYNAMIQUE ´ 15 Calcul Calcul Calcul Calcul Calcul Calcul Calcul Calcul Communications Calcul Calcul Calcul Calcul Calcul Calcul Calcul Calcul Communications Calcul Calcul Calcul Calcul Calcul Calcul Calcul Calcul Communications Repartitionnement Migration Calcul Calcul Calcul Calcul Calcul Calcul Calcul Calcul Communications Calcul Calcul Calcul Calcul Calcul Calcul Calcul Calcul Communications Calcul Calcul Calcul Calcul Calcul Calcul Calcul Calcul Communications Repartitionnement Migration Figure 2.6 – Etapes d’un code se r´e´equilibrant toutes les ´ α = 3 it´erations.16 CHAPITRE 2. ETAT DE L’ART ´ 1 2 3 4 (a) Partition initiale d´es´equilibr´ee en 4 parties. 4 3 1 2     1 0 0 3 0 0 3 0 0 2 0 0 2 1 0 0     (b) Partition en 4 parties avec une mauvaise correspondance des parties. 1 2 4 3     3 0 0 1 0 3 0 0 0 0 2 0 0 0 1 2     (c) Mˆeme partition que pr´ec´edemment mais avec une bonne correspondance. Figure 2.7 – Exemples de repartitionnement. Les sommets migrants sont dessin´es en rouge. La figure 2.7 pr´esente deux exemples de repartitionnement produisant la mˆeme nouvelle partition, mais avec une num´erotation diff´erente des nouvelles parties. Un repartitionnement « from scratch » peut tout `a fait donner la partition de la figure 2.7b o`u tous les sommets sauf un sont migr´es, alors qu’en renum´erotant les nouvelles parties par rapport `a l’ancienne partition comme sur la figure 2.7c, seulement deux sommets doivent ˆetre migr´es. Dans PLUM, Oliker et Biswas [45] proposent une heuristique gloutonne pour r´esoudre le probl`eme d’association des nouvelles parties aux processeurs (remap). Cette heuristique est d´ecrite par l’algorithme 1. Il parcourt les ´el´ements Ci,j de la matrice de migration du plus grand au plus petit ´el´ement. La partie j est associ´ee au processeur i d`es que c’est possible, c’est-`a-dire si le processeur i est libre (free[i] est vrai) et si la partie j n’est pas d´ej`a associ´ee `a un processeur (unassigned[j] est vrai). L’algorithme se termine lorsque toutes les parties ont ´et´e affect´ees `a un processeur. Comme la m´ethode Scratch-Remap recalcule une partition sans prendre en compte la migration, celle-ci poss`ede g´en´eralement une bonne coupe car c’est le seul crit`ere optimis´e lors du partitionnement. En revanche, la migration n’est minimis´ee que dans un second temps et peut ˆetre tr`es sup´erieure `a l’optimal. Il est possible d’apporter quelques am´eliorations au Scratch-Remap. Pour obtenir un volume de migration plus faible, Oliker et Biswas [45] repartitionne en kM parties au lieu de M. Lors de la phase de remapping, k nouvelles parties sont associ´ees `a chaque processeur. Ce grain plus fin permet un volume de migration moindre mais une coupe un peu plus ´elev´ee. Schloegel et al. [58] proposent une autre variante du Scratch-Remap appel´ee LMSR (Locally Matched Scratch Remap) dans laquelle la phase de contraction du partitionnement multi-niveaux est contrainte pour ne fusionner que des sommets appartenant `a une mˆeme ancienne partie en esp´erant cr´eer une nouvelle partition avec des fronti`eres plus proches de l’ancienne partition. b) Diffusion Les m´ethodes diffusives s’inspirent du ph´enom`ene physique de diffusion de la chaleur pour r´e´equilibrer la charge. L’id´ee de base des m´ethodes diffusives est que chaque processeur ´echange2.3. REPARTITIONNEMENT POUR L’EQUILIBRAGE DYNAMIQUE ´ 17 Algorithme 1 R´eaffectation des nouvelles parties aux anciens processeurs (remap) Entr´ee : Matrice de migration C de taille M × M map : vecteur d’association des nouvelles parties unassigned : vecteur de bool´eens initialement vrais free : vecteur de bool´eens initialement vrais n ← M L ← liste tri´ee des Ci,j par ordre d´ecroissant tant que n > 0 faire Prendre et retirer le premier ´el´ement Ci,j de L si free[i] ∧ unassigned[j] alors map[j] ← i free[i] ← faux unassigned[j] ← faux n ← n − 1 fin si fin tant que retourner map des sommets avec ses voisins selon le d´es´equilibre de charge entre les deux parties. Ces ´echanges locaux de sommets `a la fronti`ere des parties concern´ees permettent de r´e´equilibrer la charge. Dans la version it´erative de cette m´ethode, un r´e´equilibrage partiel est r´ep´et´e `a chaque it´eration. Lors de ce r´e´equilibrage partiel, deux processeurs voisins ´echangent un nombre de sommets proportionnel `a leur diff´erence de charge. Cybenko [12] calcule la nouvelle charge w (t+1) i d’une partie i `a l’it´eration t + 1, `a l’aide la formule : w (t+1) i = w (t) i + X j αij (w (t) j − w (t) i ). (2.1) Les αij sont des coefficients positifs ou nuls et tels que ∀i,P j αij ≤ 1 (chaque partie ne peut pas donner plus de charge qu’elle n’en poss`ede), permettant de choisir si les parties i et j ´echangeront facilement des sommets. Cela permet de favoriser les ´echanges entre parties proches dans le graphe ou entre processeurs proches sur le r´eseau. Apr`es plusieurs it´erations, cette m´ethode tend `a homog´en´eiser la charge, conform´ement au principe de diffusion de la chaleur. Le r´e´equilibrage peut ´egalement ˆetre r´ealis´e directement en cherchant la solution finale du probl`eme de diffusion `a l’aide d’un solveur. Hu et Blake [26] montrent que chercher la solution optimisant la norme 2 de la migration (la racine carr´e de la somme des carr´es de la taille de chaque message) est ´equivalent au probl`eme de diffusion. La solution est calcul´ee `a l’aide de la m´ethode du gradient conjugu´e. Ou et Ranka [46] expriment le probl`eme sous forme d’un programme lin´eaire pour minimiser la norme 1 de la migration (la somme des tailles de chaque message). Ce programme est r´esolu `a l’aide de la m´ethode du simplexe [43]. Une fois que la charge `a ´echanger entre chaque processeur a ´et´e d´ecid´ee, il faut choisir quels seront les sommets `a migrer. Ce choix est fait de fa¸con `a optimiser la coupe de la partition finale et peut ˆetre r´ealis´e `a l’aide d’un algorithme de type FM. Comme les d´eplacements de sommets s’effectuent entre des pairs de parties, il est n´ecessaire de trouver un bon ordonnancement de ses migrations [58]. En effet un processeur peut avoir besoin de transmettre plus de sommets qu’il n’en poss`ede initialement et il a donc besoin de recevoir des sommets avant de pouvoir en envoyer.18 CHAPITRE 2. ETAT DE L’ART ´ 1 2 3 (a) Partition d´es´equilibr´ee. 0 0 1 1 2 3 (b) Echanges de sommets entre ´ parties. 1 2 3 (c) Partition finale r´e´equilibr´ee. Figure 2.8 – Exemple de diffusion. Un exemple de repartitionnement par diffusion est illustr´e sur la figure 2.8. Tous les sommets sont de poids unitaires. A partir de la partition initialement d´es´equilibr´ee (figure 2.8a) ` , on calcule la migration optimale (figure 2.8b). Il faut alors d´eplacer un sommet de la partie 3 vers la partie 2. Ce sommet est choisi de fa¸con `a obtenir la meilleure coupe possible et ainsi obtenir la partition finale ´equilibr´ee de la figure 2.8c. Les m´ethodes diffusives permettent d’obtenir de faibles volumes de migration. Mais les heuristiques locales utilis´ees se comportent mal si il y a de grandes variations de charge. c) Partitionnement biais´e Le partitionnement peut ˆetre biais´e pour optimiser la migration. Les heuristiques habituelles sont modifi´ees pour ne plus optimiser seulement la coupe mais un compromis entre la coupe et le volume total de migration. Au lieu de modifier les heuristiques, il est ´egalement possible de modifier le graphe `a partitionner pour biaiser le partitionnement. Plusieurs ´etudes [2, 8, 9] montrent qu’il est possible de mod´eliser le probl`eme de repartitionnement `a l’aide de sommets fixes. Le graphe `a partitionner est enrichi pour mod´eliser les objectifs du repartitionnement : la coupe des arˆetes ajout´ees repr´esente la migration des sommets. Cette m´ethode est utilis´ee par le partitionneur d’hypergraphe Zoltan [9] et le partitionneur de graphe RM-Metis [2]. Des sommets sont ajout´es dans ce graphe pour mod´eliser les processeurs. Les processeurs ne sont pas des calculs `a distribuer ; le poids de ces sommets est donc nul et ils sont fix´es dans la partie du processeur qu’il mod´elise, c’est-`a-dire que le partitionneur ne pourra pas les placer dans une autre partie. Ces sommets fixes sont ensuite connect´es `a tous les sommets contenus dans l’ancienne partie associ´ee au sommet fixe. Ces nouvelles arˆetes permettent de mod´eliser la migration et sont donc appel´ees arˆetes de migration. En effet, si un sommet est migr´e, l’arˆete le connectant au sommet fixe de son ancienne partie sera coup´ee, ajoutant ainsi un coˆut de migration dans la taille de la coupe de la nouvelle partition. Le poids de l’arˆete de migration permet donc de repr´esenter la taille des donn´ees `a migrer. Sur la figure 2.9, on peut voir un exemple de repartitionnement qui illustre cette m´ethode. La partition en 5 parties est initialement d´es´equilibr´ee ; 5 sommets fixes (carr´es) sont ajout´es et reli´es par des arˆetes de migration aux sommets de leur partie respective (figure 2.9a). Apr`es l’utilisation d’un partitionneur `a sommets fixes, une nouvelle partition ´equilibr´ee est obtenue (figure 2.9b). Les arˆetes de migration associ´ees aux sommets ayant migr´e sont coup´ees (en rouge). La plus2.3. REPARTITIONNEMENT POUR L’EQUILIBRAGE DYNAMIQUE ´ 19 (a) Graphe colori´e selon l’ancienne partition auquel les sommets fixes ont ´et´e ajout´es. (b) Graphe colori´e selon la nouvelle partition. Les arˆetes de migration coup´ees sont colori´ees en rouge. Figure 2.9 – Exemple de repartitionnement bas´e sur des sommets fixes.20 CHAPITRE 2. ETAT DE L’ART ´ grande partie des arˆetes n’est pas coup´ee (en vert). Le partitionneur a donc cr´e´e une nouvelle partition avec peu de migration (15 sommets migrent correspondant aux 15 arˆetes de migration coup´ees). Scotch [18,19] utilise une m´ethode de repartitionnement biais´e : sa m´ethode de raffinement par « diffusion » est modifi´ee dans le cas du repartitionnement. Pour prendre en compte la migration des sommets, une nouvelle source de « liquide » est ajout´ee pour chaque sommet l’incitant `a rester dans sa partie d’origine. Hendrikson et al. [23] proposent une autre approche du repartitionnement biais´e o`u chaque sommet u a un d´esir dk(u) d’ˆetre dans un partie k. Au lieu de minimiser le coˆut de migration, le but est de maximiser les d´esirs de chaque sommet (si p(u) est la partie de u, on maximise la somme P u dp(u)(u)). Deux approches sont pr´esent´ees : un raffinement de type FM modifi´e et une m´ethode de partitionnement spectrale prenant en compte les d´esirs des sommets. Le partitionnement biais´e permet un compromis entre qualit´e de la nouvelle partition et volume de migration grˆace `a un coˆut de migration introduit dans la coupe `a optimiser, par exemple, `a l’aide du poids des arˆetes de migration. Mais le repartitionnement est plus complexe car une nouvelle partition est compl`etement recalcul´ee avec des heuristiques modifi´ees. Le partitionnement biais´e peut ´egalement ˆetre hybride [57]. Dans le cadre d’un partitionnement multi-niveaux, le partitionnement initial est r´ealis´e `a l’aide d’une m´ethode Scratch-Remap ou diffusive, mais le raffinement appliqu´e lors de la phase d’expansion est biais´e pour optimiser la migration. 2.4 Positionnement Toutes les m´ethodes de repartitionnement pour l’´equilibrage dynamique pr´esent´ees ici ne s’int´eressent qu’au cas o`u le nombre de processeurs reste fixe. Le probl`eme de l’´equilibrage dynamique avec variation du nombre de processeurs est peu ´etudi´e. Iqbal et Carey [27,28] ont pourtant montr´e que faire varier le nombre de processeurs au cours de la simulation permet d’optimiser la consommation de ressources et mˆeme, dans certains cas, le temps d’ex´ecution. Bien choisir le nombre de processeurs allou´es `a une simulation est essentiel pour avoir une bonne performance ou efficacit´e. Si une simulation est lanc´ee en parall`ele sur un trop grand nombre de processeurs, le temps pass´e `a communiquer peut devenir trop important par rapport au temps de calcul. Utiliser le maximum de processeurs possible n’est pas toujours un bon choix suivant la taille du probl`eme. La taille du probl`eme pouvant varier au cours de la simulation, le nombre de processeurs devrait varier en cons´equence. Augmentation de la charge M = 4 N = 6 Figure 2.10 – Allocation dynamique de processeurs pour un seul code dont la charge augmente. Par exemple, un code AMR (Adaptive Mesh Refinement) commence sa simulation sur un maillage grossier contenant peu d’´el´ements. Puis, au cours de la simulation, le maillage est raf-2.4. POSITIONNEMENT 21 Augmentation de la charge relative A/B M + M' = 6 N + N' = 6 A B A B Figure 2.11 – Allocation dynamique de processeurs pour deux codes coupl´es A et B dont la charge relative de A par rapport `a B augmente. fin´e l`a o`u c’est n´ecessaire. La charge de calcul, initialement tr`es faible, croˆıt avec le temps. La simulation tr`es l´eg`ere au d´ebut finit par demander beaucoup de ressources, que ce soit en puissance de calcul ou en m´emoire. En commen¸cant le calcul sur tr`es peu de processeurs puis en l’augmentant quand la limite m´emoire est atteinte, il est possible de garder une meilleure efficacit´e tout le long de la simulation. Les surcoˆuts dus au parall´elisme inutile en d´ebut de simulation sont ´evit´es quand c’est possible. C’est la cas pr´esent´e sur la figure 2.10 : apr`es une augmentation significative de la charge, deux processeurs suppl´ementaires sont allou´es, et il faut donc effectuer un repartitionnement de 4 processeurs vers 6. L’allocation dynamique de processeurs peut aussi ˆetre utile dans le cas du couplage de codes. Dans un couplage de codes, plusieurs codes parall`eles s’ex´ecutent simultan´ement et doivent r´eguli`erement ´echanger des donn´ees. Cette phase d’´echange est synchronisante. Il est donc important que tous les codes concern´es progressent `a la mˆeme vitesse pour minimiser le temps d’attente lors de cette synchronisation. Le choix du nombre de processeurs utilis´es par chaque code doit ˆetre fait en prenant en compte les charges relatives de chacun. Cette ´equilibrage entre plusieurs codes peut ˆetre difficile, plus particuli`erement si la charge de ces codes peut varier dynamiquement. Pour r´e´equilibrer ces codes, une solution serait donc de r´eallouer des ressources d’un code vers un autre. Le nombre id´eal de processeurs allou´es `a chaque code peut donc ˆetre approch´e exp´erimentalement en corrigeant au cours de la simulation les d´es´equilibre qui surviendraient. Par exemple, sur la figure 2.11, le code A est devenu trop lent par rapport `a B, un processeur est donc r´eallou´e du code B vers le code A. Il faut repartitionner chacun des deux codes : de 3 processeurs vers 4 pour A, et de 3 vers 2 pour B. Pour r´ealiser ce changement du nombre de ressources, il est n´ecessaire de mettre en place une m´ethode repartitionnement prenant en compte le changement du nombre de parties. Nous appelons ce probl`eme, le repartitionnement M × N. Les objectifs du repartitionnement sont similaires `a ceux du repartitionnement classiques : — ´equilibrer la charge parmi les N processeurs ; — minimiser la coupe du graphe ; — calculer rapidement la nouvelle partition ; — minimiser la migration (diff´erentes m´etriques seront pr´esent´ees). Les outils de repartitionnement suivent d´ej`a ces objectifs mais ne sont pas pr´evus pour le changement du nombre de processeurs. La m´ethode de Scratch-Remap est facilement adaptable au repartitionnement M × N. Lors du partitionnement from scratch, l’ancienne partition, et donc l’ancien nombre de processeurs, n’a pas d’influence. L’algorithme de Remapping peut ˆetre facilement adapt´e en prenant en compte le fait que certaines parties ne seront pas associ´ees `a un ancien processeur (lors de l’ajout de processeurs), ou que des anciens processeurs ne recevront pas de nouvelles parties (lors de la suppression de processeurs).22 CHAPITRE 2. ETAT DE L’ART ´ Nous proposons donc une nouvelle m´ethode de repartitionnement adapt´ee au cas o`u le nombre de processeurs varie. La m´ethode propos´ee est pr´esent´ee sur la figure 2.12. Elle se d´ecompose en deux ´etapes. Dans un premier temps, nous cherchons `a construire des matrices de migrations adapt´ees `a ce probl`eme. Apr`es une ´etude de quelques matrices optimales, plusieurs m´ethodes seront pr´esent´ees dans le chapitre 3. La construction de la matrice de migration ne s’int´eresse pas aux sommets du graphe individuellement mais seulement aux parties, `a leurs tailles et `a leurs positions respectives. Ainsi, la construction de la matrice s’effectue `a partir du graphe quotient des parties. Ensuite, la matrice de migration construite est utilis´ee pour guider un repartitionnement du graphe remplissant les objectifs habituels du partitionnement de graphe : l’´equilibre et la coupe tout en fournissant une migration telle que pr´evue par la matrice construite `a l’´etape pr´ec´edente. Plusieurs approches sont possibles : un partitionnement biais´e utilisant des sommets fixes pour imposer une matrice de migration lors du repartitionnement ; une approche diffusive adapt´ee pour le repartitionnement M × N ; et un partitionnement biais´e utilisant des hyper-arˆetes pour optimiser les messages de migration sans utiliser de matrice de migration calcul´ee `a l’avance. Les m´ethodes de partitionnement biais´e mettent en ´evidence les limites des bissections r´ecursives utilis´ees dans les partitionneurs usuels. Un module de partitionnement k-aire utilisant une heuristique de greedy graph growing est ajout´ee dans le partitionneur Scotch pour am´eliorer la qualit´e de nos partitionnements.2.4. POSITIONNEMENT 23 Méthode d'appariement (Matching) Méthode de la chaîne (1D) Méthode gloutonne (Greedy) Méthode de partitionnement biaisé (Biased) Méthode diffusive (Diff) Hyper-arêtes de repartitionnement Matrice de migration Graphe quotient Nouvelle partition en N Graphe partitionné en M Construction de la matrice de migration M×N Repartitionnement M×N Programme linéaire (LP) Figure 2.12 – Vue d’ensemble de nos m´ethodes de repartitionnement M × N.24 CHAPITRE 2. ETAT DE L’ART ´Chapitre 3 Mod`ele de migration pour le repartitionnement M × N Sommaire 3.1 Notations et d´efinitions . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.1.1 G´en´eralit´es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1.2 D´efinitions pour le repartitionnement M × N . . . . . . . . . . . . . . 27 3.2 Matrices de migration optimales dans le cas ´equilibr´e . . . . . . . 28 3.3 Construction des matrices de migration . . . . . . . . . . . . . . . . 35 3.3.1 M´ethode bas´ee sur la chaˆıne (1D) . . . . . . . . . . . . . . . . . . . . . 35 3.3.2 M´ethode d’appariement (Matching) . . . . . . . . . . . . . . . . . . . 42 3.3.3 M´ethode gloutonne (Greedy) . . . . . . . . . . . . . . . . . . . . . . . 47 3.3.4 Programme lin´eaire (LP) . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.4 Evaluation des m´ethodes et conclusion . . . . . . . . . . . . . . . . 62 ´ La premi`ere ´etape de notre m´ethode de repartitionnement consiste `a construire une matrice de migration optimis´ee. Pour r´ealiser cela, il n’est pas n´ecessaire de disposer de toute l’information sur le graphe partitionn´e mais seulement du graphe quotient. Nous proposons plusieurs algorithmes permettant de construire des matrices de migration optimisant diff´erents crit`eres. Cette ´etape est r´esum´ee en figure 3.1. Dans un premier temps, nous ´enoncerons quelques d´efinitions g´en´erales sur le graphe et le partitionnement, puis des d´efinitions particuli`eres pour nos algorithmes de repartitionnement. Ensuite, nous ´etudierons plus en d´etails les matrices de migration dans le cas o`u l’ancienne partition est d´ej`a ´equilibr´ee. Enfin, nous d´ecrirons nos algorithmes de construction de matrice de migration, avant de conclure sur une comparaison de ces diff´erents m´ethodes. 3.1 Notations et d´efinitions Dans cette section, nous d´efinissons les notations et termes qui seront utilis´es dans cette th`ese. Nous rappelons d’abord les d´efinitions relatives au partitionnement, puis nous introduisons les nouvelles notations que nous utiliserons pour le repartitionnement M × N. 2526 CHAPITRE 3. MODELE DE MIGRATION ` Méthode d'appariement (Matching) Méthode de la chaîne (1D) Méthode gloutonne (Greedy) Matrice de migration Graphe quotient Graphe partitionné en M Construction de la matrice de migration M×N Programme linéaire (LP) Figure 3.1 – Vue d’ensemble de nos algorithmes de construction des matrices de migration. 3.1.1 G´en´eralit´es Soit G = (V, E), un graphe o`u V est l’ensemble des sommets et E l’ensemble des arˆetes. A` chaque sommet v est associ´e un poids wv repr´esentant la charge de calcul associ´e `a ce sommet. P Une arˆete e peut avoir un poids we repr´esentant le coˆut de la communication. On notera W = v∈V wv le poids total du graphe. D´efinition 1 (Partition). Une k-partition P de V est un ensemble de k sous-ensembles deux `a deux disjoints (Pi)i∈J1,kK de V tels que l’union de tous les sous-ensembles couvre V . D´efinition 2 (Poids d’une partie). Le poids d’une partie Pi not´e w(Pi) est la somme des poids des tous les sommets de la partie : w(Pi) = P v∈Pi wv. D´efinition 3 (Partition ´equilibr´ee). La k-partition P est dite ´equilibr´ee au facteur de d´es´equilibre ǫ ≥ 0 pr`es si ∀Pi ∈ P, w(Pi) ≤ (1 + ǫ) W k . En pratique, le facteur de d´es´equilibre souvent utilis´e est de l’ordre de quelques pour cent. Avec un facteur de 5 % (ǫ = 0, 05), une partie qui aurait une taille id´eale de 1000 ´el´ements, ne devra pas d´epasser 1050. D´efinition 4 (Coupe d’un graphe). On appelle taille de la coupe (ou par abus de langage, coupe) d’un graphe pour une partition donn´ee, le nombre d’arˆetes coup´ees ou la somme de leurs poids si elles sont pond´er´ees. Les arˆetes coup´ees sont les arˆetes dont les deux extr´emit´es sont dans des parties diff´erentes. D´efinition 5 (Graphe quotient). La graphe quotient Q = G/P d’un graphe G par rapport `a la partition P est obtenu `a partir de G en fusionnant les sommets appartenant `a une mˆeme partie de P. Les arˆetes devenues identiques apr`es la fusion des sommets sont ´egalement fusionn´ees et leurs poids sont additionn´es. Si les arˆetes n’´etaient pas pond´er´ees, le poids des arˆetes du graphe quotient est le nombre d’arˆetes fusionn´ees. Le graphe quotient Q = G/P poss`ede autant de sommets qu’il y a de parties dans P. Le poids de chaque sommet est le poids de la partie correspondante (la somme des poids des sommets de cette partie). Les sommets sont connect´es aux sommets correspondant aux parties voisines et le poids des arˆetes est la somme des poids des arˆetes coup´ees entre ces deux parties.3.1. NOTATIONS ET DEFINITIONS ´ 27 (a) Partition d’un graphe en 5 parties. 4 3 2 1 4 7 7 (b) Graphe quotient correspondant `a la partition. Figure 3.2 – Exemple de construction d’un graphe quotient pour une grille 10 × 10. La figure 3.2 montre la partition d’un graphe issu d’une grille 2D de taille 10 × 10 et le graphe quotient associ´e. La partition est en 5 parties et le graphe quotient poss`ede 5 sommets colori´es de la mˆeme couleur que la partie `a laquelle il est associ´e. La partition ´etant parfaitement ´equilibr´ee, le poids de chaque sommet est ´egal, et vaut 20. Le poids des arˆetes est plus variable : par exemple, l’arˆete entre le sommet jaunes et cyan a un poids 7, comme il y a 7 arˆetes dans le graphe partitionn´e connectant des sommets jaunes et cyan. 3.1.2 D´efinitions pour le repartitionnement M × N Dans le cas du repartitionnement, on distinguera deux partitions : la partition initiale P en M parties et une partition finale d´esir´ee P ′ en N parties. D´efinition 6 (Matrice de migration). On appelle matrice de migration, la matrice C de dimension M × N d´ecrivant les volumes de donn´ees `a migrer entre les diff´erents parties. L’´el´ement Ci,j correspond au nombre d’´el´ements en commun entre l’ancienne partie i et la nouvelle partie j. C’est aussi la quantit´e de donn´ees envoy´ee par le processeur i au processeur j si i 6= j ; si i = j, Ci,i est la quantit´e de donn´ees ne migrant pas, c’est-`a-dire restant « sur place ». Chaque ligne repr´esente une ancienne partie, donc la somme des ´el´ements sur cette ligne est ´egale `a sa taille. De la mˆeme fa¸con, une colonne repr´esente une nouvelle partie et la somme des ´el´ements de chaque colonne est ´egale `a sa taille. Pour ´evaluer la qualit´e des matrices de migration, nous d´efinissons plusieurs m´etriques : TotalV et MaxV sont d´ej`a introduits par Oliker et al. [45] ; nous y ajoutons deux nouvelles m´etriques TotalZ et MaxZ. Le volume total de migration, not´e TotalV, est la quantit´e de sommets qui migrent (ou la somme de leurs poids s’il sont pond´er´es). Cela correspond donc `a la somme des ´el´ements non-diagonaux de la matrice de migration. Le volume maximum par processeur, not´e MaxV, correspond `a la plus grande quantit´e de sommets (ou somme des poids) re¸cus et envoy´es par un mˆeme partie. Il correspond `a la plus grande somme sur une ligne et une colonne de mˆemes num´eros des ´el´ements hors diagonale de la matrice de migration.28 CHAPITRE 3. MODELE DE MIGRATION ` Le nombre total de messages n´ecessaires `a la migration, not´e TotalZ, correspond au nombre de non-z´eros hors diagonale. De la mˆeme fa¸con, on d´efinit le nombre maximal de messages (envoy´es et re¸cus) par processeur, not´e MaxZ. TotalZ vaut au plus M × N − min(M, N) dans le cas o`u tous les ´el´ements non-diagonaux de C sont non nuls. La figure 3.3 montre plusieurs cas de repartitionnement de la partition initiale de la figure 3.3a. Pour chaque repartitionnement, la matrice de migration et les diff´erentes m´etriques sont donn´ees. Les figures 3.3b et 3.3c montrent la mˆeme nouvelle partition mais avec une num´erotation diff´erente. Il est important de bien faire correspondre les anciennes et nouvelles parties pour avoir une faible migration. En effet, le volume total de migration TotalV est bien plus important dans le cas de la figure 3.3b. La figure 3.3d montre une partition diff´erente ayant une meilleure coupe mais une migration plus ´elev´ee. D´efinition 7 (Graphe biparti de migration). Le graphe biparti de migration est le graphe biparti G = ((A, B), E) o`u A est l’ensemble des M anciennes parties et B l’ensemble des N nouvelles parties. Il existe une arˆete dans E entre une ancienne et une nouvelle partie si elles partagent des sommets. Le poids de cette arˆete est la somme des poids des sommets partag´es. La matrice d’adjacence de ce graphe biparti est la matrice de migration C. Il existe une arˆete entre les sommets i et j si et seulement si Ci,j est non nul et si le poids de cette arˆete vaut Ci,j . Des exemples de graphes biparti de migration sont pr´esent´es sur la figure 3.3. Chaque arˆete du graphe repr´esente soit un message de migration, soit les donn´ees qui restent sur place lorsque l’arˆete relie une ancienne partie `a sa nouvelle partie associ´ee. D´efinition 8 (Hypergraphe de repartitionnement). L’hypergraphe de repartitionnement est l’hypergraphe comportant M sommets correspondant aux anciennes parties et N hyper-arˆetes correspondant aux nouvelles parties. Une hyper-arˆete contient tous les sommets correspondant aux anciennes parties avec lesquelles la nouvelle partie ´echange des sommets. Les hyper-arˆetes ne sont pas pond´er´ees. La matrice d’adjacence de cet hypergraphe est la matrice de migration sans prendre en compte les valeurs : on ne s’int´eresse qu’aux z´eros et non-z´eros. Le sommet v appartient `a l’hyper-arˆete e si et seulement si Cv,e est non nul. Chaque ligne de la matrice ou ancienne partie correspond `a un sommet de l’hypergraphe et chaque colonne ou nouvelle partie correspond `a une hyper-arˆete. Une hyper-arˆete contient tous les sommets dont l’´el´ement dans la matrice est non nul. Les hypergraphes de repartitionnement correspondant `a chaque matrice de migration sont donn´es dans la figure 3.3. La renum´erotation des parties entre les figures 3.3b et 3.3c ne change pas l’hypergraphe de repartitionnement mais seulement les num´eros des hyper-arˆetes. L’utilisation de ces graphes bipartis et hypergraphes permet de repr´esenter le sch´ema de communication utilis´e lors de la migration. Les hypergraphes de repartitionnement permettent une repr´esentation plus graphique des relations entre une ancienne et une nouvelle partition : c’est ce que l’on constate par exemple sur la figure 3.4 en le superposant avec le graphe quotient de l’ancienne partition. 3.2 Matrices de migration optimales dans le cas ´equilibr´e Dans un premier temps, nous allons ´etudier les matrices de migration dans le cas particulier o`u la partition initiale est d´ej`a parfaitement ´equilibr´ee. Plus pr´ecis´ement, on consid`ere que les partitions initiales et finales sont parfaitement ´equilibr´ees. Dans ce cas, W doit ˆetre un multiple commun de M et de N. On a donc W = k × ppcm(M, N) avec k un entier strictement positif.3.2. MATRICES DE MIGRATION OPTIMALES DANS LE CAS EQUILIBR ´ E´ 29 1 2 3 Coupe : 8 (a) Partition initiale d´es´equilibr´ee en 3 parties. 4 3 1 2 Coupe : 11 TotalV : 11 MaxV : 8 TotalZ : 4 MaxZ : 3   1 0 0 3 0 0 3 0 2 3 0 0   1 2 3 1 2 3 4 1 3 2 4 2 1 3 (b) Partition en 4 parties avec une mauvaise correspondance des parties. 1 2 4 3 Coupe : 11 TotalV : 3 MaxV : 3 TotalZ : 2 MaxZ : 2   3 0 0 1 0 3 0 0 0 0 3 2   1 2 3 1 2 3 4 1 3 2 1 3 4 2 (c) Mˆeme partition que pr´ec´edemment mais avec une bonne correspondance. 2 1 4 3 Coupe : 10 TotalV : 4 MaxV : 3 TotalZ : 3 MaxZ : 2   3 1 0 0 0 2 0 1 0 0 3 2   1 2 3 1 2 3 4 1 3 2 1 3 2 4 (d) Autre exemple de repartitionnement en 4 parties. Figure 3.3 – Exemples de repartitionnement avec les matrices de migration, graphes bipartis de migration, hypergraphes de repartitionnement et mesures associ´ees.30 CHAPITRE 3. MODELE DE MIGRATION ` 1 2 3 4 1 3 2 Figure 3.4 – Superposition de l’hypergraphe de repartitionnement de la figure 3.3c et du graphe quotient de la partition de la figure 3.3a. Pour simplifier notre discussion, on supposera que les poids des sommets sont unitaires. Ainsi le probl`eme de la partition du graphe est ´equivalent `a la partition de l’entier correspondant `a son poids. D´efinition 9 (Matrice de migration optimale). Nous appelons matrice de migration optimale, une matrice de migration C minimisant `a la fois le volume de total de migration (TotalV) et le nombre de messages (TotalZ). Lemme 1. Le volume total de migration optimal v´erifie : TotalVopt ≥ W  1 − min(M, N) max(M, N)  . D´emonstration. Il y a min(M, N) parties communes entre les partitions initiale et finale et |M − N| parties diff´erentes. Comme les partitions sont ´equilibr´ees, les tailles des parties initiales et finales sont respectivement W M et W N . Donc au plus, min(W M , W N ) = W max(M,N) donn´ees restent en place pour chaque partie commune. Le reste des donn´ees migre, donc TotalVopt ≥ W − min(M, N) × W max(M,N) = W × (1 − min(M,N) max(M,N) ). Lemme 2. Une matrice de migration minimisant le nombre de messages poss`ede au moins M + N − pgcd(M, N) coefficients non nuls. Le nombre minimal de messages v´erifie : TotalZopt ≥ max(M, N) − pgcd(M, N). D´emonstration. Le volume total de donn´ees est W = k × ppcm(M, N) = kaM = kbN avec a et b deux entiers strictement positifs premiers entre eux. Chaque partie poss`ede initialement ka sommets et finalement kb sommets. Soit G = ((A, B), E) le graphe biparti de migration. Pour d´enombrer les ´el´ements non nuls dans la matrice de migration, il suffit de compter le nombre d’arˆetes dans le graphe biparti de migration. On note (Gi = ((Ai , Bi), Ei))i∈J1,KK , les K composantes connexes de G. Pour chaque composante Gi , Mi = |Ai | processeurs envoient Mika sommets `a Ni = |Bi | processeurs qui re¸coivent Nikb sommets. Dans Gi , on a donc Wi = Mika = Nikb sommets qui sont ´echang´es, avec Mi et Ni non nuls. Comme Wi est un multiple commun de ka et kb et comme a et b sont premiers entre eux, le plus petit multiple commun de ka et kb est kab. Donc Wi ≥ kab. Le volume total ´echang´e W = PK i=1 Wi est donc sup´erieur ou ´egal `a Kkab. Autrement dit, K ≤ W kab = M b .3.2. MATRICES DE MIGRATION OPTIMALES DANS LE CAS EQUILIBR ´ E´ 31 D’autre part, on sait que MN = pgcd(M, N) × ppcm(M, N) et ppcm(M, N) = bN. On a donc M b = pgcd(M, N). On obtient alors K ≤ pgcd(M, N). Comme Gi est un graphe connexe, il poss`ede au moins Mi + Ni − 1 arˆetes. Donc le nombre total d’arˆetes |E| = PK i=1 |Ei | est au moins PK i=1 Mi + PK i=1 Ni − K = M + N − K. Comme K ≤ pgcd(M, N), on obtient |E| ≥ M + N − pgcd(M, N). Le nombre de coefficients non nuls dans la matrice de migration est donc au moins M + N − pgcd(M, N). TotalZ est le nombre de coefficients non nuls hors de la diagonale. Il y a au plus min(M, N) coefficients non nuls sur la diagonale. Donc TotalZ ≥ M + N − pgcd(M, N) − min(M, N) = max(M, N) − pgcd(M, N). B A×B 1 2 3 4 5 6 7 1 2 3 4 5 6 7 8 9 10 A 8 11 12 ka kb kab Figure 3.5 – Partitionnement d’un graphe chaˆıne en 8 et 12 parties, le motif de l’intersection A × B permet de construire la matrice de migration « en escalier ». Il existe diff´erentes m´ethodes pour obtenir de telles matrices avec un nombre minimal d’´el´ements non nuls. Une premi`ere m´ethode s’inspire du partitionnement d’un graphe « chaˆıne » ou d’un tableau, comme pr´esent´e sur la figure 3.5. Pour compter le nombre de messages, il faut compter le nombre d’arˆetes du graphe biparti. En reprenant les notations de la d´emonstration du lemme 2, la taille des parties de A est ka et celle des parties de B est kb. Tous les ppcm(ka, kb) = kab sommets, les s´eparateurs des anciennes parties et des nouvelles parties sont juxtapos´es. Le graphe biparti de migration est coup´e en sous-graphes (composantes connexes), chacun avec b anciennes parties de taille ka et a nouvelles parties de taille kb. Ce motif de longueur kab est donc r´ep´et´e W kab = M b = N a = pgcd(M, N) fois. Chacun de ces sous-graphes contient b + a − 1 arˆetes. Le nombre total d’arˆetes est donc (b + a − 1) × pgcd(M, N) = M + N − pgcd(M, N). Sur l’exemple de la figure 3.5, on a ppcm(8, 12) = 24 donc a = 3 et b = 2. Chacune des pgcd(8, 12) = 4 composantes connexes contient 3 + 2 − 1 = 4 arˆetes. Le graphe biparti contient 16 arˆetes. Cette construction donne une matrice « en escalier » comme montr´e sur la figure 3.7a. Il est ´egalement possible de construire une telle matrice r´ecursivement. On remplit la matrice avec des blocs qui sont des matrices carr´ees diagonales de taille min(M, N), et le bloc restant est rempli en r´ep´etant la mˆeme m´ethode sur le nouveau sous-probl`eme. Pour que la matrice soit une matrice de migration, il faut que les sommes sur les lignes ou colonnes soient respectivement les tailles des anciennes et nouvelles parties. Les valeurs diagonales sont donc W max(M,N) . La figure 3.6 donne un exemple de telle construction dans le cas 7 × 10 avec W = 7 × 10 en trois ´etapes. Calculer le nombre de non-z´eros avec cette m´ethode, revient `a appliquer l’algorithme d’Euclide. La division euclidienne de M par N donne M = qN + r : on commence `a remplir q blocs carr´es de taille N × N et on recommence r´ecursivement sur le bloc restant de taille r × N32 CHAPITRE 3. MODELE DE MIGRATION ` avec r < N. L’algorithme d’Euclide donne une suite d’´equations : M = q2N + r2 (3.1) . . . (3.2) ri−2 = qiri−1 + ri (3.3) . . . (3.4) rn−3 = qn−1rn−2 + rn−1 (3.5) rn−2 = qnrn−1 (3.6) avec r0 = M, r1 = N et rn−1 = pgcd(M, N). A chaque ´etape de l’algorithme, ` qiri−1 ´el´ements non nuls sont ajout´es dans la matrice : ce sont les ´el´ements diagonaux des qi blocs carr´es. Le nombre total d’´el´ements non nuls est donc Pn i=2 qiri−1. En faisant la somme de toutes les ´equations pr´ec´edentes, on obtient : nX−2 i=0 ri = Xn i=2 qiri−1 + Xn i=2 ri (3.7) Xn i=2 qiri−1 = r0 + r1 − rn−1 − rn (3.8) Xn i=2 qiri−1 = M + N − pgcd(M, N). (3.9) D’apr`es l’´equation 3.9, cette m´ethode construit bien une matrice avec un nombre minimal de non-z´eros. La figure 3.7d pr´esente un exemple d’une telle matrice. Th´eor`eme 3. Les bornes inf´erieures donn´ees dans les lemmes 1 et 2 sont atteintes. C’est-`a-dire : TotalVopt = W  1 − min(M, N) max(M, N)  (3.10) TotalZopt = max(M, N) − pgcd(M, N). (3.11) D´emonstration. La m´ethode de construction bas´ee sur l’algorithme d’Euclide construit une matrice de migration avec M + N − pgcd(M, N) coefficients non nuls. Les min(M, N) ´el´ements sur la diagonale sont maximis´es et valent W max(M,N) . On a donc TotalV = W  1 − min(M,N) max(M,N)  et TotalZ = max(M, N) − pgcd(M, N). Proposition 4. Soient M et N deux entiers tels que M < N. Soient D une matrice diagonale de dimension M × M dont les ´el´ements diagonaux sont W N et A une matrice de migration de dimension M × (N − M) minimisant le nombre de messages. Alors, la matrice D A
est une matrice de migration optimale au sens de la d´efinition 9. De mˆeme, dans le cas o`u M > N, si D est de taille N × N avec des ´el´ements diagonaux valant W M et si A est de taille (M − N) × N, alors  D A  est une matrice de migration optimale. D´emonstration. La d´emonstration est faite dans le cas M < N. La d´emonstration du cas M > N est similaire. La quantit´e de donn´ees qui reste sur place correspond `a la premi`ere diagonale de la matrice, soit D. Donc, on a W M N donn´ees qui restent sur place, ce qui est bien le cas optimal.3.2. MATRICES DE MIGRATION OPTIMALES DANS LE CAS EQUILIBR ´ E´ 33   7 7 7 7 reste 7 7 7   10 = 1 × 7 + 3   7 3 7 3 7 3 7 3 7 3 7 3 7 reste   7 = 2 × 3 + 1   7 3 7 3 7 3 7 3 7 3 7 3 7 1 1 1   3 = 3 × 1 + 0 Figure 3.6 – Exemple de construction r´ecursive (avec les divisions euclidiennes associ´ees `a chaque ´etape) d’une matrice de migration avec un nombre minimal de communications. D contient M ´el´ements non nuls et A contient par hypoth`ese un nombre minimal d’´el´ements non nuls pour sa taille : M + (N − M) − pgcd(M, N − M) = N − pgcd(M, N). Le nombre total d’´el´ements non nuls est donc M + N − pgcd(M, N) qui est bien le nombre minimal. La matrice D A
remplit bien les deux crit`eres pour ˆetre optimale. La figure 3.7 pr´esente quelques exemples de matrices de migration. La matrice de la figure 3.7a a ´et´e obtenue par la m´ethode inspir´ee du repartitionnement d’une chaˆıne qui donne une forme en escalier. Le nombre de messages est optimal mais pas le volume de migration. Seules 12 donn´ees restent sur place (les nombres en rouges) contre W M × N
= 49 dans le cas d’une migration optimale. Le volume de migration peut ˆetre am´elior´e `a l’aide d’une simple renum´erotation des parties similaires au « remapping » de la m´ethode Scratch-Remap (cf. section 2.3). La matrice obtenue est pr´esent´ee sur le figure 3.7b, 45 donn´ees restent alors sur place, ce qui est tr`es proche de l’optimal. D’apr`es le th´eor`eme pr´ec´edent, il nous suffit de combiner une matrice diagonale et une matrice minimisant le nombre de message pour obtenir une matrice optimale. La figure 3.7c montre la combinaison d’une matrice diagonale et d’une matrice en escalier. Dans le cas de la figure 3.7d, on construit r´ecursivement une matrice optimale `a l’aide de matrices diagonales en se basant sur l’algorithme d’Euclide. Bien que ces deux matrices soient optimales pour les m´etriques d´esir´ees (TotalV et TotalZ), la matrice construite `a partir de la matrice en escalier donne un nombre de messages par processeur (MaxZ) plus faible que la m´ethode r´ecursive. En pratique, les partitions ne sont pas parfaitement ´equilibr´ees car cela n’est pas n´ecessaire : on se contente d’une partition `a peu pr`es ´equilibr´ee `a un facteur de d´es´equilibre pr`es. Cette ´equilibre parfait peut mˆeme ˆetre impossible lorsque W n’est pas divisible par M ou N ou que le34 CHAPITRE 3. MODELE DE MIGRATION `   7 3 4 6 1 7 2 5 5 2 7 1 6 4 3 7   1 2 3 4 7 5 6 a b c d e f g h i j (a) Matrice « en escalier ».   7 3 6 4 1 7 2 5 5 7 1 2 6 4 7 3   1 2 3 4 7 5 6 a h b c d i e f j g (b) Matrice « en escalier » avec permutation des colonnes pour minimiser TotalV.   7 3 7 3 7 1 2 7 3 7 2 1 7 3 7 3   1 2 3 4 5 6 7 a b c d e f g h i j (c) Matrice optimale utilisant une sousmatrice en escalier.   7 3 7 3 7 3 7 3 7 3 7 3 7 1 1 1   1 2 4 3 5 6 7 a b c d e f g h i j (d) Exemple de matrice optimale construite par ajout de blocs diagonaux r´ecursivement. Figure 3.7 – Exemples de matrices de migration pour le cas 7 × 10 et leurs repr´esentations en hypergraphe de repartitionnement. Les ´el´ements nuls ne sont pas montr´es. Les lignes num´erot´ees de 1 `a 7 correspondent aux sommets et les colonnes num´erot´ees de a `a j correspondent aux hyper-arˆetes. Les ´el´ements en rouge montrent les donn´ees qui restent en place. Les ´el´ements en noir sont ceux qui migrent, la somme de ces ´el´ements donne le volume de migration.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 35 poids des sommets de permet pas un d´ecoupage en parties rigoureusement ´egales. Les r´esultats pr´esent´es dans cette section sur le nombre de messages restent vrais pour des d´es´equilibres faibles. En effet, il est possible de profiter de la tol´erance au d´es´equilibre des nouvelles parties pour mieux s’adapter aux anciennes parties l´eg`erement d´es´equilibr´ees et ´economiser des messages. Le volume de migration optimal reste proche. Dans le cas o`u la partition initiale est fortement d´es´equilibr´ee, il est difficile de donner des valeurs optimales pour tous les cas. Il est toujours possible d’effectuer la migration en max(M, N)−1 messages (le nombre minimal d’arˆetes d’un graphe biparti connexe ´etant M + N − 1), mais ce nombre n’est pas toujours minimal. 3.3 Construction des matrices de migration 3.3.1 M´ethode bas´ee sur la chaˆıne (1D) a) Cas ´equilibr´e Dans le cas d’une partition initiale ´equilibr´ee, la m´ethode la plus simple pour construire une matrice de migration permettant `a la fois une bonne migration (m´etriques TotalV, MaxV, TotalZ et MaxZ) et une bonne coupe, consiste `a r´eutiliser le principe du partitionnement de la chaˆıne pr´esent´ee dans la section 3.2. De telles matrices de migration peuvent ˆetre obtenues `a l’aide d’un repartitionnement bas´e sur des courbes de remplissage ou space filling curve (SFC) [52,54]. Ce repartitionnement g´eom´etrique construit une courbe remplissant l’espace `a partitionner, comme par exemple `a l’aide d’une courbe de Hilbert [54] (cf. figure 3.8). On peut facilement obtenir une partition en M parties en coupant cette courbe en M sections ´egales. Si on construit une nouvelle partition en N parties en utilisant la mˆeme courbe de remplissage, on obtient un repartitionnement bas´e sur la chaˆıne (la chaˆıne ´etant la courbe de remplissage). Cette m´ethode a l’inconv´enient de n´ecessiter des informations g´eom´etriques sur les donn´ees `a partitionner et donne une coupe assez ´elev´ee `a cause de la nature fractale des courbes utilis´ees. Pour appliquer le principe du partitionnement de la chaˆıne sur un graphe quelconque, il suffit de trouver un chemin dans le graphe quotient. L’utilisation du graphe quotient au lieu du graphe `a partitionner permet de laisser `a une heuristique de partitionnement classique le choix de la distribution des sommets. Ainsi, le probl`eme de coupe des courbes de remplissage est r´egl´e tout en gardant le mˆeme sch´ema de communication. Le chemin de M sommets dans le graphe quotient est alors d´ecoup´e en N nouvelles parties, un sommet (correspondant `a une ancienne partie) pouvant ˆetre partag´e entre plusieurs nouvelles parties. Le choix de ce chemin influence directement la coupe de la partition finale. En effet, comme une nouvelle partie peut prendre des sommets de plusieurs anciennes parties cons´ecutives dans ce chemin, il est pr´ef´erable que ces parties soient bien connect´ees entre elles. Il faudra donc trouver un chemin dont les arˆetes ont des poids ´elev´es dans le graphe quotient. Pour optimiser la migration, une renum´erotation des nouvelles parties est n´ecessaire, car en num´erotant les parties dans l’ordre du chemin, les num´eros sont d´ecal´es par rapport `a la partition initiale comme on peut le voir sur la figure 3.9. L’utilisation d’un chemin peut aussi ˆetre vue comme une renum´erotation des anciennes parties apr`es laquelle on applique le repartitionnement de la chaˆıne sur le nouvel ordre des parties. Donc, deux renum´erotations sont en fait n´ecessaires : l’une permutant les anciennes parties (ou lignes de la matrice de migration) en fonction du chemin, l’autre permutant les nouvelles parties (ou colonnes de la matrice de migration) pour optimiser la migration.36 CHAPITRE 3. MODELE DE MIGRATION ` (a) Partitionnement en 3. (b) Partitionnement en 5.   13 8 5 12 5 8 13   (c) Matrice de migration. Figure 3.8 – Partitionnement et repartitionnemnent d’une grille 8 × 8 bas´es sur une courbe de remplissage de Hilbert. B 1 2 3 4 5 6 7 1 2 3 4 5 6 7 8 9 10 A 8 11 12 (a) Num´erotation des nouvelles parties dans l’ordre du chemin. B 1 2 3 4 5 6 7 1 9 2 3 10 4 5 11 6 7 A 8 12 8 (b) Renum´erotation pour optimiser la migration. Figure 3.9 – Exemple de num´erotations des nouvelles parties. Les arˆetes en pointill´es correspondent aux « communications » d’un processeur vers lui-mˆeme. Les donn´ees qui ne migrent pas sont en gris clair.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 37 Nœud courant Partie suivante Partie précédente Figure 3.10 – Exemple d’´etape de l’algorithme de recherche de chemin `a partir de l’arbre des bissections. La zone verte contient les nœuds dont l’ordre est d´ej`a fix´e, la zone rouge ceux dont on ne connait pas encore l’ordre. Le choix de l’ordre est `a faire entre les deux sommets de la zone bleue claire. La recherche d’un tel chemin dans le graphe quotient est un probl`eme analogue `a celui du voyageur de commerce, qui est NP-complet [20, TRAVELING SALESMAN]. Il existe de nombreuses m´ethodes pour obtenir des chemins non optimaux mais assez proches de l’optimal, comme par exemple des algorithmes probabilistes. Mais certains « bons » chemins peuvent cr´eer des probl`emes dans le cas d’un partitionnement par bissections r´ecursives. En effet, une bissection devra couper ce chemin en deux en mˆeme temps que le graphe. La bissection du chemin est forc´ee par la num´erotation des nouvelles parties : elle s´epare les plus petits num´eros des plus grands. Une bissection du chemin par le milieu doit donc laisser la possibilit´e d’une bonne bissection du graphe. Dans le cas o`u la partition initiale a ´et´e r´ealis´ee par un partitionneur utilisant des bissections r´ecursives, l’arbre des bissections peut ˆetre utilis´e pour trouver rapidement un chemin. Les parties issues d’une bissection r´ecursive sont num´erot´ees dans l’ordre des feuilles. Les nœuds internes repr´esentent l’union des parties dans le sous-arbre. A l’aide d’un parcours en largeur de l’arbre, ` chaque nœud interne est visit´e. L’ordre de ses deux fils est choisi de fa¸con `a maximiser les connexions avec les parties (ou unions de parties) pr´ec´edentes et suivantes. Comme tout l’arbre n’a pas encore ´et´e visit´e, l’ordre de toutes les parties n’a pas encore ´et´e d´ecid´e. On prend donc la partie pr´ec´edente au mˆeme niveau dans l’arbre et la partie suivante au niveau sup´erieur comme indiqu´e sur la figure 3.10. La figure 3.12 pr´esente un exemple d’ex´ecution de cet algorithme sur le graphe quotient de la figure 3.11. L’arbre initial est celui de la figure 3.12a. Au niveau de la racine, il n’y a pas de choix `a faire car il n’y a ni partie pr´ec´edente ni suivante. Le premier choix arrive avec le nœud unissant 0 et 1. La partie suivante est 2–4 dont la connexion avec 0 est 39 + 14 = 53 et celle avec 1 est 17 + 34 = 51. La partie 0 est donc plac´ee en second comme indiqu´e sur la figure 3.12b. Sur la figure 3.12c, les connexions des parties 2 et 3–4 avec la partie pr´ec´edente 0 sont compar´ees. Enfin, les connexions des parties 3 et 4 avec les parties pr´ec´edente 0 et suivante 2 sont compar´ees, et l’ordre est conserv´e (figure 3.12d). En pratique, pour am´eliorer la qualit´e du chemin en gardant un algorithme rapide, toutes les solutions possibles sont recherch´ees quand on arrive sur un sous-arbre suffisamment petit. Une fois la nouvelle partition obtenue, il faut renum´eroter les parties pour optimiser la migration comme montr´e sur la figure 3.9. De la mˆeme fa¸con que le Scratch-Remap, il faut chercher la meilleure association entre anciennes et nouvelles parties. Mais dans le cas du partitionnement38 CHAPITRE 3. MODELE DE MIGRATION ` 39 39 14 34 17 62 65 0 1 2 3 4 Figure 3.11 – Exemple de partition initiale en 5 partie et du graphe quotient associ´e. de la chaˆıne, le choix est plus simple : — si M < N, pour chaque ancienne partie, on choisit la nouvelle partie qui re¸coit le plus de donn´ees ; — si M > N, pour chaque nouvelle partie, on choisit l’ancienne partie qui lui en envoie le plus. Les nouvelles parties qui ne sont pas associ´ees `a une ancienne prennent alors de nouveaux num´eros qui n’existaient pas dans l’ancienne partition : ce sont les N − M plus grands. On peut v´erifier par l’absurde que ces choix sont possibles dans le cas M < N. Cette m´ethode de renum´erotation poserait probl`eme si et seulement si une mˆeme nouvelle partie est le meilleur choix pour deux anciennes. Si une ancienne partie partage des donn´ees avec trois ou plus nouvelles parties, une de ces nouvelles parties ne re¸coit des donn´ees que de cette ancienne partie et ne serait le meilleur choix que pour celle-ci. Ces deux anciennes parties n’ont donc chacune des donn´ees partag´ees qu’avec deux nouvelles : les nouvelles parties ´etant plus petites, il y en a au moins deux. La nouvelle partie qui serait le meilleur choix pour les deux anciennes doit donc recevoir plus de la moiti´e des donn´ees de chacune des deux anciennes parties. Elle serait donc plus grande que les anciennes, ce qui est en contradiction avec l’hypoth`ese M < N. On peut faire un raisonnement similaire dans le cas M > N, en inversant les rˆoles des anciennes et nouvelles parties. b) Illustration dans le cas ´equilibr´e La figure 3.13 pr´esente un exemple de repartitionnement dans le cas o`u il y a 5 parties initiales ´equilibr´ees (1400 ´el´ements chacune) et 7 parties finales qui doivent contenir 1000 ´el´ements chacune pour ˆetre ´equilibr´ees. On commence par construire une matrice correspondant au repartitionnement de la chaˆıne comme pr´esent´e dans la section 3.2 (matrice en escalier) :   1000 400 0 0 0 0 0 0 600 800 0 0 0 0 0 0 200 1000 200 0 0 0 0 0 0 800 600 0 0 0 0 0 0 400 1000  3.3. CONSTRUCTION DES MATRICES DE MIGRATION 39 0–4 0–1 2–4 0 1 2 3–4 3 4 (a) Arbre de bissections initial. 0–4 0–1 2–4 1 0 2 3–4 3 4 (b) Permutation de 0 et 1. 0–4 0–1 2–4 1 0 3–4 3 4 2 (c) Permutation de 2 et 3–4. 0–4 0–1 2–4 1 0 3–4 3 4 2 (d) L’ordre entre 3 et 4 est pr´eserv´e. Figure 3.12 – Exemple de recherche de chemin par permutation de l’arbre des bissections. Ensuite, un chemin est recherch´e dans le graphe, maximisant la connexion entre les sommets successifs (les anciennes parties). Ici, le chemin choisi est 1, 0, 3, 4 et 2. Les lignes de la matrice sont permut´ees en cons´equence. Enfin, il faut renum´eroter les nouvelles parties pour minimiser le volume de migration. On choisit les nouvelles parties recevant le plus d’´el´ements des anciennes parties. Les nouvelles parties correspondant aux anciennes 1, 0, 3, 4 et 2, sont respectivement 0, 2, 3, 4 et 6. Renum´eroter les nouvelles parties revient `a permuter les colonnes de la matrice de migration. Les nouvelles parties non associ´ees aux anciennes (1 et 5) prennent de nouveaux num´eros, ici 5 et 6. Les colonnes sont permut´ees en cons´equence, les colonnes suppl´ementaires (5 et 6) peuvent ˆetre dans un ordre quelconque. La figure 3.14 pr´esente les hypergraphes de repartitionnement dans trois cas de repartitionnement. Dans les cas ou les nombres de parties initial et final ne sont pas premiers entre eux (8×12 et 12×14), les chemins sont coup´es en plusieurs parties : ce sont les composantes connexes utilis´ees dans la d´emonstration du lemme 2. On remarque ´egalement que les hyper-arˆetes sont de petites tailles et regroupent des anciennes parties voisines comme on le souhaitait. c) G´en´eralisation au cas d´es´equilibr´e Cette m´ethode peut ˆetre facilement adapt´ee dans le cas o`u la partition initiale est d´es´equilibr´ee. Il faut d’abord trouver un chemin dans le graphe quotient. Ensuite, connaissant cet ordre des parties, il suffit de le red´ecouper en parties de tailles ´egales. Dans le cas d´es´equilibr´e, toutes40 CHAPITRE 3. MODELE DE MIGRATION ` 39 39 14 34 17 62 65   800 0 0 0 0 0 600 0 1000 0 0 0 0 400 0 0 1000 0 0 400 0 200 0 0 1000 200 0 0 0 0 0 0 800 600 0   TotalV = 2400 MaxV = 1000 TotalZ = 6 MaxZ = 2 Figure 3.13 – Exemple de repartitionnement bas´e sur la chaˆıne dans le cas 5×7 (cas ´equilibr´e). 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16 × 21. Figure 3.14 – Applications du repartitionnement bas´e sur la chaˆıne dans le cas ´equilibr´e.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 41 900 500 1500 1700 2400 1000 1 0 3 4 2 1 0 3 4 6 2 5 39 39 14 34 17 62 65   400 100 0 0 0 0 0 0 900 0 0 0 0 0 0 0 1000 0 0 1000 400 600 0 0 900 0 0 0 0 0 0 100 1000 0 600   TotalV = 2800 MaxV = 1400 TotalZ = 6 MaxZ = 2 Figure 3.15 – Exemple de repartitionnement bas´e sur la chaˆıne dans le cas 5×7 (cas d´es´equilibr´e). les parties ne se valent pas. La forme de l’hypergraphe de repartitionnement utilis´e peut varier suivant l’ordre choisi. Par exemple, consid´erons le cas 5 × 7 o`u les parties sont initialement d´es´equilibr´ees avec comme poids dans l’ordre de 0 `a 4 : 500, 900, 2400, 1500 et 1700. En reprenant le mˆeme chemin 1 que dans le cas ´equilibr´e (figure 3.12), l’ordre des poids devient 900, 500, 1500, 1700 et 2400, et on obtient le repartitionnement pr´esent´e sur la figure 3.15. La figure 3.16 pr´esente alors les hypergraphes de repartitionnement obtenus avec la m´ethode de la chaˆıne dans le cas d´es´equilibr´e. Contrairement au cas ´equilibr´e, il n’est plus garanti que certaines s´eparations entre parties soient communes entre l’ancienne partition et la nouvelle. Le nombre de messages peut donc atteindre, au pire, M+N −1 messages. On peut voir que les hyperarˆetes forment les mˆemes chemins que ceux de la figure 3.14 mais « sans ˆetre coup´ees ». Dans le cas ´equilibr´e, le chemin ´etait d´ecoup´e en pgcd(M, N) parties correspondant aux composantes connexes du graphe biparti de repartitionnement utilis´ees dans la section 3.2. 1. Le chemin ne d´epend que de la connectivit´e du graphe quotient, pas du poids de ses sommets.42 CHAPITRE 3. MODELE DE MIGRATION ` 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16 × 21. Figure 3.16 – Applications du repartitionnement bas´e sur la chaˆıne dans le cas d´es´equilibr´e. 3.3.2 M´ethode d’appariement (Matching) Dans le cas ´equilibr´e, nous avons vu en section 3.2 qu’il est possible de construire des matrices de migration optimales, c’est-`a-dire optimisant `a la fois le volume de migration et le nombre de messages. Mais l’optimisation de la coupe n’est pas consid´er´ee. Comme on l’a vu avec la m´ethode de la chaˆıne, il peut ˆetre n´ecessaire de permuter la matrice de migration pour obtenir une bonne coupe. Mais une matrice optimale ne correspond pas toujours `a une chaˆıne : il ne suffit plus de trouver un bon chemin dans le graphe quotient. On cherche donc `a apparier correctement la matrice de migration avec le graphe quotient pour que la partition finale ait une bonne coupe. Comme les valeurs des ´el´ements de la matrice de migration n’influencent pas cet appariement, nous utiliserons l’hypergraphe de repartitionnement dans cette section. Le choix de la matrice de migration ou de l’hypergraphe repartitionnement conditionne la qualit´e de la migration. Nous d´ecidons de prendre une matrice de migration optimale (d’apr`es la d´efinition 9), plus pr´ecis´ement la matrice optimale compos´ee d’une diagonale et compl´et´ee avec une sous-matrice « chaˆıne » (comme celle de la figure 3.7c). En plus de minimiser T otalV et T otalZ, cette matrice a l’avantage de garder un M axZ plus faible que les autres matrices optimales. a) Probl`eme d’appariement entre le graphe quotient et l’hypergraphe de repartitionnement Une bonne matrice de migration ne suffit donc pas pour obtenir un bon repartitionnement. Elle ne permet que d’optimiser la migration et l’´equilibre. Un bon repartitionnement doit aussi fournir une coupe basse. La coupe sera principalement d´ecid´ee lors de l’´etape de repartitionnement, mais la matrice de migration a une influence sur la coupe. Une matrice de migration indique l’emplacement des nouvelles parties : elles seront l`a o`u se trouvent les anciennes parties dont elles prennent les sommets. Pour permettre au partitionneur de bien optimiser la coupe, il faut que les anciennes parties communiquant avec une mˆeme nouvelle partie soient proches. Pour obtenir ce r´esultat, on apparie l’hypergraphe de repartitionnement avec le graphe quotient, c’est-`a-dire qu’on cherche une correspondance entre les sommets de l’hypergraphe et ceux du graphe quotient comme pr´esent´e sur la figure 3.17. En effet, les hyper-arˆetes regroupent les anciennes parties donnant des sommets `a une mˆeme nouvelle partie, alors que les arˆetes du graphe quotient connectent les anciennes parties proches.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 43 1 2 3 4 5 6 7 7 2 1 4 3 6 5 Figure 3.17 – Appariement d’un graphe quotient et d’un hypergraphe de repartitionnement. Par exemple, il y a plusieurs fa¸cons d’apparier l’hypergraphe de repartitionnement pour repartitionner la partition initiale d’un maillage en grille visible sur la figure 3.18a. Les figures 3.18b et 3.18c pr´esentent deux possibilit´es d’appariement de l’hypergraphe de repartitionnement en le superposant au graphe quotient. Dans le premier cas, les hyper-arˆetes regroupant plusieurs sommets contiennent des sommets « proches » organis´es en cliques. En cons´equence la partition finale sur la figure 3.18d a des parties bien form´ees, alors que, dans le second cas, les hyper-arˆetes regroupent des sommets « ´eloign´es » et la partition finale sur la figure 3.18e a des parties d´econnect´ees sur le maillage. Les m´etriques pour ´evaluer la migration (TotalV, MaxV, TotalZ et MaxZ) sont les mˆemes dans ces deux cas, mais la coupe du graphe est bien meilleure dans le premier cas. Pour ´eviter de tels sc´enarios, une m´etrique suppl´ementaire est introduite pour estimer la qualit´e de la coupe finale. Cette m´etrique doit favoriser les nouvelles parties prenant des donn´ees `a un ensemble d’anciennes parties bien connect´ees, autrement dit des quasi-cliques. Cette m´etrique s’exprime `a l’aide du graphe quotient de l’ancienne partition et de l’hypergraphe de repartitionnement. b) D´efinition d’un score d’appariement Une fois la matrice choisie, il faut trouver une bonne correspondance entre les sommets du graphe quotient et ceux de l’hypergraphe de repartitionnement associ´e `a la matrice. Cet appariement n´ecessite la d´efinition d’un score. Notons Q = (VQ, EQ) le graphe quotient par rapport `a l’ancienne partition, H = (VH, EH) l’hypergraphe de repartitionnement d´ej`a appari´e (on consid`ere que les sommets de Q et de H sont les mˆemes, on pose V = VQ = VH) et ES(e) l’ensemble des arˆetes du sous-graphe de Q induit par l’hyper-arˆete e. Une premi`ere version simple de ce score compte la somme des poids des arˆetes des sous-graphes induits par chaque hyper-arˆete e : Score = X e∈EH   X e ′∈ES (e) we ′   (3.12) o`u ES(e) = {(i, j) ∈ EQ : i ∈ e ∧ j ∈ e} .44 CHAPITRE 3. MODELE DE MIGRATION ` (a) Hypergraphe de repartitionnement et partition initiale. (b) Exemple de bonne correspondance. (c) Exemple de mauvaise correspondance. (d) La partition est bien form´ee. (e) Certaines parties sont d´econnect´ees. Figure 3.18 – Deux cas d’application d’un mˆeme hypergraphe de repartitionnement.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 45 Il est possible d’´ecrire ce score sous forme matricielle. Notons X la matrice d’appariement (ou de permutation) de taille M × M `a trouver : Xi,i′ vaut 1 si et seulement si le sommet i de l’hypergraphe de repartitionnement est associ´e au sommet i ′ du graphe quotient, sinon 0. La matrice H repr´esente l’hypergraphe de repartitionnement 2 . Elle est de taille M × N et Hi,j vaut 1 si est seulement si le sommet i est inclus dans l’hyper-arˆete j. Q est la matrice d’adjacence du graphe quotient de taille M × M, Qi,j est le poids de l’arˆete entre les sommets i et j. Ces notations sont r´esum´ees sur la figure 3.19. i' j' j i k Qi',j' Xi,i' = 1 Xj,j' = 1 Figure 3.19 – Illustration des notations utilis´ees dans la formule de score avec une arˆete (i ′ , j′ ) du graphe quotient Q `a gauche et une hyper-arˆete k `a droite. Grˆace aux matrices `a valeurs binaires X et H, on peut ´ecrire la somme du poids des arˆetes ei ′ ,j′ dont les extr´emit´es i ′ et j ′ sont respectivement associ´ees `a deux sommets i et j dans la mˆeme hyper-arˆete k : Score = X i,j,i′ ,j′ ,k Xi,i′Xj,j′Hi,kHj,kQi ′ ,j′ soit (3.13) Score = X i,i′  Xi,i′ X j,j′ Xj,j′ X k Hi,kHj,k! Qi ′ ,j′ ! . (3.14) D´efinition 10 (Produit de Kronecker). Le produit de Kronecker de deux matrices A ⊗ B, A de taille m × n et B de taille m′ × n ′ , est une matrice de taille mm′ × nn′ , d´ecrite par la matrice bloc suivante :   A1,1B · · · A1,nB . . . . . . . . . Am,1B · · · Am,nB   . En notant A = HHT ⊗ Q, o`u ⊗ est le produit de Kronecker, et x le vecteur colonne de taille M2 tel que xiM+i ′ = Xi,i′ , le score s’´ecrit comme la forme quadratique : Score = x T Ax. (3.15) Dans l’´equation 3.14, on reconnait le coefficient de la matrice A = HHT ⊗ Q : AiM+i ′ ,jM+j ′ = X k Hi,kHj,k! Qi ′ ,j′ , 2. Par abus de langage, on confond les graphes et hypergraphes avec leurs matrices d’adjacence.46 CHAPITRE 3. MODELE DE MIGRATION ` 20 20 (a) Chaine de 3 parties r´eunies dans une mˆeme hyper-arˆete. Les deux parties aux extr´emit´es sont ´eloign´ees l’une de l’autre. 15 20 5 (b) Clique de 3 parties r´eunies dans une mˆeme hyper-arˆete. Figure 3.20 – Deux exemples de sous-graphes quotients appari´es avec une hyper-arˆete. P k Hi,kHj,k correspondant au coefficient (i, j) de la matrice HHT . Cette m´etrique favorise les hyper-arˆetes regroupant des sommets fortement connect´es. Mais elle est loin d’ˆetre parfaite, car elle ne prend pas en compte le nombre d’arˆetes du graphe quotient associ´ees `a une hyper-arˆete. A score ´egal, il apparait plus avantageux de favoriser trois sommets ` connect´es par trois arˆetes plutˆot que par deux. Sur l’exemple de la figure 3.20, les deux appariements d’une hyper-arˆete avec un graphe de 3 sommets ont le mˆeme score : 40. Pourtant, dans le cas de la figure 3.20a, les deux parties aux extr´emit´es de la chaˆıne peuvent ˆetre ´eloign´ees et la nouvelle partie cr´e´ee devra alors ˆetre ´etir´ee, ce qui n’est pas optimal pour la coupe. On pr´ef´ererait favoriser les cas de cliques comme sur la figure 3.20b, o`u les 3 parties sont bien regroup´ees. Pour corriger ces d´efauts, nous allons modifier le score pour prendre en compte la quantit´e d’arˆetes et la taille des hyper-arˆetes 3 . On propose la nouvelle formule de score suivante. Soient ES(e) l’ensemble des arˆetes du sous-graphe induit par l’hyper-arˆete e et K(e) l’ensemble des arˆetes d’une clique entre les sommets de l’hyper-arˆete e. La m´etrique s’exprime : ScoreR = X e∈EH   |ES(e)| |K(e)| X e ′∈ES (e) we ′   (3.16) o`u  ES(e) = {(i, j) ∈ EQ : i ∈ e ∧ j ∈ e} K(e) =  (i, j) ∈ V 2 : i 6= j ∧ i ∈ e ∧ j ∈ e . En reprenant l’exemple 3.20, les anciens scores sont multipli´es par 2/3 dans le cas de la chaˆıne (fig. 3.20a) et par 1 dans le cas de la clique (fig. 3.20b), ce qui donne les scores 26 et 40 : la clique est maintenant favoris´ee par rapport `a la chaˆıne. c) Choix d’un appariement par une m´ethode d’optimisation du score Afin de choisir un bon appariement, nous allons utiliser une m´ethode d’optimisation du score d´efini pr´ec´edemment. La maximisation de l’´equation 3.15 est un probl`eme d’optimisation quadratique `a valeurs binaires. C’est un probl`eme NP-difficile [20, QUADRATIC PROGRAMMING] mais d´ej`a beaucoup ´etudi´e, en particulier dans le domaine de la vision num´erique [15,41]. Une premi`ere solution consiste `a utiliser une m´ethode spectrale. Comme x T x = M est une constante, maximiser revient 3. On rappelle que la taille d’une hyper-arˆete est le nombre de sommets qu’elle regroupe.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 47 `a maximiser le quotient de Rayleigh-Ritz [25] x T Ax xT x . Dans le cas o`u x est `a coefficient r´eels, ce quotient atteint son maximum pour un vecteur propre associ´e `a la plus grande valeur propre. Mais ici x est `a valeur binaire, et la relaxation du probl`eme ne donne pas de solution convenable. En effet, approcher le vecteur propre avec un vecteur correspondant `a une permutation est une approximation trop importante. D’autres heuristiques pour trouver un bon appariement sont possibles, comme par exemple des algorithmes probabilistes, combinatoires de type branch & bound, ... Nous avons choisi d’utiliser un algorithme de recuit simul´e [40] qui donne des r´esultats satisfaisants. En partant d’une correspondance quelconque, des permutations de deux sommets al´eatoires sont appliqu´ees. Si la nouvelle correspondance a un meilleur score, elle est conserv´ee. Sinon, elle est conserv´ee ou non avec une probabilit´e qui d´ecroit exponentiellement avec le nombre d’it´erations. Apr`es un nombre d’it´erations fix´e, l’algorithme s’arrˆete. Cette m´ethode peut s’appliquer `a n’importe quelle forme de score et notamment `a la formule du score 3.16. d) Illustration de la m´ethode de matching La figure 3.21 pr´esente un exemple de repartitionnement bas´e sur le matching. Dans un premier temps, une matrice de migration optimale est choisie. Ici, on choisit une matrice combinant une sous-matrice diagonale avec une sous-matrice en escalier dont l’hypergraphe de repartitionnement associ´e est repr´esent´e dans la figure 3.21a. Cette classe de matrice a l’avantage de fournir un nombre de messages par partie souvent plus faible que les matrices construites r´ecursivement (cf. section 3.2). Ensuite, cet hypergraphe de repartitionnement est mis en correspondance avec le graphe quotient `a l’aide de l’heuristique de recuit simul´e optimisant la fonction ScoreR (´equation 3.16). Le r´esultat est visible sur la figure 3.21b. Cette appariement correspond `a une permutation des lignes de la matrice mais aussi des 5 premi`eres colonnes pour garder une diagonale optimisant le volume de migration. La figure 3.22 pr´esente des r´esultats d’application de la m´ethode d’appariement dans diff´erents cas. On remarque que dans le cas 8×12 (figure 3.22a), le r´esultat est le mˆeme qu’avec la m´ethode de la chaˆıne. En effet, les matrices 8×12 choisies dans les deux m´ethodes sont ´equivalentes `a une permutation pr`es dans ce cas pr´ecis. Dans le cas 12×14 (figure 3.22b), il y a de tr`es grandes hyperarˆetes. Cela risque de poser probl`eme pour la construction des parties associ´ees `a ces grandes hyper-arˆetes. Ce probl`eme vient du choix de la matrice optimale qui concentre les non-z´eros dans les derni`eres colonnes de la matrice. Cela aurait pu ˆetre ´evit´e en choisissant un autre type de matrice, mais le volume total de migration n’aurait pas ´et´e optimal. Le recuit simul´e ne trouve pas toujours de bonne solution : sur la figure 3.22c, l’hyper-arˆete contenant les sommets 0, 4, 7 et 15 ne contient que deux arˆetes (4–7 de poids 25 et 0–15 de poids 4), mais les autres hyper-arˆetes sont assez bien plac´ees. Notons que cette m´ethode de repartitionnement ne peut pas ˆetre appliqu´ee dans le cas o`u les parties sont initialement d´es´equilibr´ees. La mise en correspondance de l’hypergraphe de repartitionnement et du graphe quotient n´ecessite que les parties initiales soient interchangeables, ce qui n’est le cas que quand les parties initiales ont toutes le mˆeme poids. 3.3.3 M´ethode gloutonne (Greedy) Dans le cas g´en´eral, il n’est pas possible de choisir une matrice avant de l’apparier au graphe quotient : les anciennes parties ont chacune un poids diff´erent et elles ne sont plus interchangeables. Il faut construire la matrice de migration directement en tenant compte de la connectivit´e entre les parties et de leurs diff´erents poids.48 CHAPITRE 3. MODELE DE MIGRATION `   1000 0 0 0 0 400 0 0 1000 0 0 0 400 0 0 0 1000 0 0 200 200 0 0 0 1000 0 0 400 0 0 0 0 1000 0 400   (a) Matrice de migration optimale et hypergraphe de repartitionnement associ´e pour le cas 5 × 7. 39 39 14 34 17 62 65   1000 0 0 0 0 0 400 0 1000 0 0 0 400 0 0 0 1000 0 0 400 0 0 0 0 1000 0 0 400 0 0 0 0 1000 200 200   TotalV = 2000 MaxV = 1000 TotalZ = 6 MaxZ = 3 (b) Hypergraphe appari´e au graphe quotient et matrice de migration finale. Figure 3.21 – Exemple de repartitionnement bas´e sur le matching dans le cas 5 × 7.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 49 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16 × 21. Figure 3.22 – Application du repartitionnement bas´e sur le matching. a) Construction de la matrice de migration par une m´ethode gloutonne La matrice de migration C est construite par l’algorithme 2 selon une m´ethode gloutonne en prenant en entr´ee le graphe quotient Q = (V, E) et le nouveau nombre de parties N. On note (Pi)i∈J0,M−1K les anciennes parties et (P ′ j )j∈J0,N−1K les nouvelles parties. L’algorithme commence avec une matrice vide, puis les colonnes de la matrice (correspondant aux hyper-arˆetes de l’hypergraphe de repartitionnement) sont remplies une par une. Ce remplissage s’effectue de fa¸con `a respecter les contraintes sur les sommes des lignes et des colonnes qui correspondent respectivement aux poids des anciennes parties (w(Pi)) et des nouvelles parties (w(P ′ j )). La migration peut ˆetre minimis´ee (optdiag = vrai en entr´ee de l’algorithme) en construisant une hyper-arˆete de taille 1 pour chaque sommet du graphe quotient quand cela est possible, c’est-`a-dire quand l’ancienne partie est plus grosse que la nouvelle (w(Pi) > w(P ′ j )). Les hyper-arˆetes suivantes sont construites de fa¸con gloutonne en commen¸cant par une sommet pseudo-p´eriph´erique (voir d´efinition 12) de faible degr´e, puis en ajoutant des sommets v un `a un dans l’hyper-arˆete h en cherchant `a maximiser un score inspir´e de celui pr´esent´e dans la section 3.3.2 : score (v, h) =|ES(h) ∩ EV (v)| |EV (v)| × |ES(h)| × P e∈ES (h)∩EV (v) we P e∈EV (v) we × X e∈ES (h) we avec  ES(h) = {(u, v) ∈ E : u ∈ h ∧ v ∈ h} EV (v) = {e ∈ E : v ∈ e} . (3.17) ES(h) est l’ensemble des arˆetes du sous-graphe d´efini par l’hyper-arˆete h. EV (v) est l’ensemble des arˆetes dont une extr´emit´e est v (son voisinage). Le score de l’´equation 3.17 reprend du score 3.16 le produit du nombre d’arˆetes et de leur poids permettant d’obtenir des groupes d’anciennes parties bien connect´ees et le multiplie par la proportion des arˆetes autour du nouveau sommet v qui sont dans l’hyper-arˆete h, en nombre et en poids. Cette modification du score permet de mieux guider l’algorithme glouton qui pr´ef´erera alors choisir des sommets sur le bord ou encercl´es par l’hyper-arˆete, laissant de meilleurs choix pour la construction des hyper-arˆetes suivantes. Pour chaque sommet ajout´e dans l’hyper-arˆete, on remplit le coefficient correspondant dans la matrice avec la valeur maximale permettant de respecter les contraintes de poids sur les lignes et colonnes. Comme les coefficients de la matrice doivent ˆetre positifs, la somme des valeurs sur la ligne (et respectivement la colonne) ne doit pas d´epasser la taille d’une partie initiale (et respectivement finale). A une it´eration de notre algorithme, la valeur choisie pour l’´el´eme ` nt Ci,j50 CHAPITRE 3. MODELE DE MIGRATION ` est donc min(w(Pi) − P k Ci,k, w(P ′ j ) − P k Ck,j ). Comme on veut obtenir une partition finale ´equilibr´ee, on pose ∀j, w(P ′ j ) = wf inal = W N . Le volume total de migration peut ˆetre minimis´e en commen¸cant par remplir la diagonale de la matrice de migration avec les plus grandes valeurs possibles. Le reste de la matrice est alors rempli normalement selon l’heuristique gloutonne. Algorithme 2 Construction de la matrice de migration C (Greedy1) Entr´ee : Nombre d’anciennes parties M Entr´ee : Nombre de nouvelles parties N Entr´ee : Graphe quotient de l’ancienne partition Q = (V, E) Entr´ee : Bool´een optdiag indiquant l’optimisation de la diagonale C ← matrice nulle de dimension M × N j ← 0 /* Indice de l’hyper-arˆete en cours de construction. */ /* Construction d’hyper-arˆetes de taille 1. */ si optdiag alors pour tout v ∈ V correspondant `a l’ancienne partie Pi faire si wv ≥ wf inal et j < N alors Ci,j ← wf inal wv ← wv − wf inal j ← j + 1 fin si fin pour fin si /* Construction gloutonne des hyper-arˆetes */ tant que j < N faire v ← sommet pseudo-p´eriph´erique de Q d’indice i et de poids wi non nul h ← {v} /* Hyper-arˆete d’indice j en cours de construction. */ Ci,j ← min(wi , wf inal) wi ← wi − Ci,j tant que P k Ck,j < wf inal faire v ← sommet de V d’indice i, de poids wi non nul tel que score(v, h ∪ {v}) soit maximal h ← h ∪ {v} Ci,j ← min(wi , wf inal − P k Ck,j ) wi ← wi − Ci,j fin tant que j ← j + 1 fin tant que retourner C Notre algorithme se base sur la notion de sommet pseudo-p´eriph´erique pour trouver un sommet sur le « bord » du graphe. Rechercher un sommet p´eriph´erique 4 est plus complexe et n’est pas n´ecessaire pour l’application de notre heuristique. D´efinition 11 (Excentricit´e). L’excentricit´e d’un sommet v dans un graphe, not´ee ǫ(v), est la plus grande distance entre v et n’importe quel autre sommet du graphe. 4. Un sommet p´eriph´erique est un sommet d’excentricit´e maximale.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 51 D´efinition 12 (Sommet pseudo-p´eriph´erique). Un sommet v est un sommet pseudo-p´eriph´erique si pour tous les sommets u les plus ´eloign´es de v, on a ǫ(v) = ǫ(u) = d(u, v). Plus formellement v est pseudo-p´eriph´erique si ∀u ∈ V, d(u, v) = ǫ(v) =⇒ d(u, v) = ǫ(u). Un sommet pseudo-p´eriph´erique peut ˆetre facilement trouv´e comme le montre l’algorithme 3. En partant d’un sommet quelconque, on cherche, `a l’aide d’un parcours en largeur, un sommet le plus loin possible (calculant ainsi l’excentricit´e du sommet de d´epart) et de faible degr´e. Cette recherche est r´ep´et´ee `a partir du nouveau sommet jusqu’`a trouver un sommet dont l’excentricit´e est ´egale `a celle du sommet pr´ec´edent. En pratique cet algorithme termine en tr`es peu d’it´erations [21] (2 ou 3 it´erations lors de nos tests). Algorithme 3 Recherche d’un sommet pseudo-p´eriph´erique de degr´e faible Entr´ee : Graphe G u ← sommet quelconque de G ǫnouveau ← 0 r´ep´eter Effectuer un parcours en largeur du graphe G en partant de u v ← sommet avec une distance maximale et un degr´e minimal ǫcourant ← ǫnouveau ǫnouveau ← d(u, v) /* correspond `a l’excentricit´e de u */ u ← v jusqu’`a ǫnouveau = ǫcourant retourner u b) Optimisation du nombre de messages par une recherche de sous-ensembles L’algorithme 2 construit une matrice de migration avec M + N − 1 messages. A chaque ` it´eration, la valeur de l’´el´ement est choisie pour satisfaire la contrainte de poids sur la ligne ou la colonne, sauf `a la derni`ere it´eration o`u les contraintes sur la ligne et la colonne de l’´el´ement sont satisfaites. Comme il y a M lignes et N colonnes, il y a au plus M + N − 1 it´erations et ´el´ements non nuls. Il est possible de diminuer ce nombre de messages en d´ecomposant le probl`eme de construction de la matrice de migration en plusieurs sous-probl`emes de repartitionnement sur des sousensembles disjoints de parties, comme le montre la d´emonstration du lemme 2. Pour d´ecomposer le probl`eme en K sous-probl`emes, l’ensemble des parties (Pi)i∈J1,MK est partitionn´e en K sous-ensembles (Sj )j∈J1,KK . Pour chaque sous ensemble Sj , la somme des poids des parties qu’il contient est `a peu pr`es un multiple de la taille id´eale d’une partie finale. Plus formellement, avec un facteur de d´es´equilibre ǫ, un sous-ensemble Sj est de « bonne taille » si il existe un entier Nj tel que P j Nj = N et (1 − ǫ) × Nj W N < X Pi∈Sj w(Pi) < (1 + ǫ) × Nj W N . On note Mj = |Sj | la taille de chaque sous-ensemble. Comme les sous-ensembles sont une partition de l’ensemble des parties, on a P j Mj = M. Chaque sous probl`eme est donc de taille Mj × Nj et construit une sous-matrice de migration avec Mj + Nj − 1 messages. Le nombre de messages total est donc M + N − K. Pour minimiser le nombre de messages, il faut donc trouver le plus possible de sous-ensembles. Dans le cas ´equilibr´e, on trouvait pgcd(M, N) tels sous-ensembles de chacun M/pgcd(M, N) parties.52 CHAPITRE 3. MODELE DE MIGRATION ` La recherche de tels sous-ensembles est une version plus g´en´erale du probl`eme de la somme d’un sous-ensemble 5 qui est NP-complet [20, SUBSET SUM]. Ces sous-ensembles peuvent ˆetre construits avec un algorithme glouton similaire `a celui de construction de la matrice de migration. Dans l’algorithme 4, on commence par trouver un sommet pseudo-p´eriph´erique dans le graphe quotient, puis on cherche parmi ses voisins si il existe un sommet permettant de cr´eer un sousensemble de la bonne taille, sinon on en choisit un qui maximise le score du sous-ensemble comme dans l’algorithme 2. Puis on recommence `a chercher parmi les voisins du sous-ensemble jusqu’`a construire un sous-ensemble de bonne taille. Au pire, l’algorithme termine en s´electionnant tous les sommets du graphe quotient dans un seul sous-ensemble, puisque par d´efinition de la taille id´eale, le poids total du graphe vaut N fois celle-ci. Algorithme 4 Construction de la matrice de migration avec une recherche de sous-ensembles (Greedy2) Entr´ee : Nombre d’anciennes parties M Entr´ee : Nombre de nouvelles parties N Entr´ee : Graphe quotient Q = (V, E) R ← V /* Ensemble des sommets restants */ tant que R 6= ∅ faire u ← un sommet pseudo-p´eriph´erique du sous-graphe de Q restreint `a R S ← {u} R ← R \ {u} tant que S n’est pas un sous-ensemble de bonne taille pour N′ nouvelles parties faire si il existe v ∈ R tel que v est connect´e `a S et S ∪ {v} est de bonne taille alors S ← S ∪ {v} /* S´electionner v */ R ← R \ {v} sinon u ← sommet maximisant le score du sous-ensemble S ∪ {u} S ← S ∪ {u} /* S´electionner u */ R ← R \ {u} fin si fin tant que Construire la sous-matrice |S| × N′ associ´ee au sous-ensemble S (appel de l’algorithme 2 (Greedy1) sur le sous-graphe de Q restreint `a S) fin tant que Un exemple d’application de ces algorithmes est pr´esent´e sur les figures 3.23 `a 3.25 avec le cas 5 × 7 d´es´equilibr´e. La figure 3.23 pr´esente la recherche des sous-ensembles, alors que les figures 3.24 et 3.25 pr´esentent respectivement les constructions des sous-matrices pour chacun des sous-ensembles. Les poids des parties initiales sont dans l’ordre 500, 900, 2400, 1500 et 1700. Les parties finales devront ˆetre de poids 1000. Les valeurs indiqu´ees `a cot´e des sommets correspondent aux donn´ees des anciennes parties qui n’ont pas encore ´et´e affect´ees dans une nouvelle. Les ´el´ements de la matrice ne faisant pas partie de la sous-matrice concern´ee sont gris´es. L’algorithme commence par chercher un sous-ensemble en partant d’un sommet pseudop´eriph´erique (figure 3.23a). Parmi les voisins, la partie 3 permet d’avoir un sous-ensemble adapt´e 5. Etant donn´e un ensemble d’entiers, existe-t-il un sous-en ´ semble non vide dont la somme vaut une valeur donn´ee ?3.3. CONSTRUCTION DES MATRICES DE MIGRATION 53 39 39 14 34 17 62 65 500 1 900 2 2400 3 1500 4 1700 (a) Premi`ere ´etape de la construction des sousensembles. 39 39 14 34 17 62 65 500 1 900 2 2400 4 1700 (b) Seconde ´etape de la construction des sousensembles : le premier sous-ensemble est termin´e. 39 39 14 34 17 62 65 500 900 (c) Cinqui`eme et derni`ere ´etape de la construction des sousensembles. Figure 3.23 – Construction des sous-ensembles. au repartitionnement en 2 parties (500+1500 = 2×1000) (figure 3.23b). L’algorithme de construction de la matrice de migration est alors appliqu´e sur le sous-ensemble {0, 3}. La partie 0 est trop petite pour cr´eer une hyper-arˆete de taille 1 (figure 3.24a). La partie 3 a un poids suffisant donc 1000 est ajout´e sur la diagonale (figure 3.24b). Il reste alors une hyper-arˆete `a construire : elle part du sommet 0 (figure 3.24c) et s’´etend sur le seul sommet voisin 3 (figure 3.24d). Les deux hyper-arˆetes n´ecessaires sont donc construites et toutes les donn´ees de 0 et 3 ont ´et´e redistribu´ees. Le second sous-ensemble est construit avec le reste du graphe quotient (figure 3.23c). Les parties 1, 2 et 4 seront repartitionn´ees vers 5 parties (900 + 2400 + 1700 = 5 × 1000). On commence par construire les hyper-arˆetes de taille 1 (figure 3.25a) pour optimiser la diagonale de la matrice, ici 2 et 4 sont de poids suffisants. L’hyper-arˆete suivante est construite `a partir de 1 (figure 3.25b) et s’´etend sur le voisin « libre » le plus connect´e `a 1 : 2 (figure 3.25c). La suivante est construite `a partir de 2 qui a encore assez de donn´ees (1300) pour construire une hyper-arˆete de taille 1 (figure 3.25d). La derni`ere hyper-arˆete part de 2 (figure 3.25e) et s’´etend sur le seul sommet restant, la partie 4 (figure 3.25f). Par la suite, nous utiliserons syst´ematiquement la recherche des sous-ensembles (Greedy2) pour notre algorithme glouton (Greedy). c) Illustration de la m´ethode gloutonne Les figures 3.26 et 3.27 pr´esentent des r´esultats de la m´ethode gloutonne avec optimisation de la diagonale dans les cas ´equilibr´es et d´es´equilibr´es. Comme avec la m´ethode d’appariement, de grandes hyper-arˆetes sont cr´e´ees. Cela est dˆu au remplissage de la diagonale qui laisse de petits restes pour cr´eer les parties suppl´ementaires. Dans le cas d´es´equilibr´e, cet effet est att´enu´e : la diagonale ne peut pas toujours ˆetre remplie et les restes peuvent ˆetre plus importants. Les figures 3.28 et 3.29 montrent les r´esultats dans les mˆemes cas, mais sans l’optimisation de la diagonale. Les tailles des hyper-arˆetes sont bien plus raisonnables. Comme avec la m´ethode de la chaˆıne, les nouvelles parties sont souvent plac´ees entre deux anciennes parties voisines.54 CHAPITRE 3. MODELE DE MIGRATION ` 39 39 14 34 17 62 65 0 500 1 0 2 0 3 1500 4 0   0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0   (a) Premi`ere ´etape du remplissage de la diagonale. 39 39 14 34 17 62 65 0 500 1 0 2 0 500 4 0   0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 0 0 0 0 0 0 0 0 0 0   (b) Seconde ´etape du remplissage de la diagonale. 39 39 14 34 17 62 65 0 1 0 2 0 500 4 0   500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 0 0 0 0 0 0 0 0 0 0   (c) Premi`ere ´etape de la construction de la seconde hyper-arˆete. 39 39 14 34 17 62 65 0 1 0 2 0 4 0   500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 500 0 0 1000 0 0 0 0 0 0 0 0 0 0   (d) L’hyper-arˆete est construite. Figure 3.24 – Construction des sous-ensembles et de la sous-matrice correspondant au premier sous-ensemble {0, 3}.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 55 39 39 14 34 17 62 65 1 900 1400 700   500 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1000 0 0 0 0 500 0 0 1000 0 0 0 0 0 0 0 1000 0 0   (a) Remplissage de la diagonale. 39 39 14 34 17 62 65 1400 700   500 0 0 0 0 0 0 0 900 0 0 0 0 0 0 0 1000 0 0 0 0 500 0 0 1000 0 0 0 0 0 0 0 1000 0 0   (b) Premi`ere ´etape de la construction de la troisi`eme hyper-arˆete. 39 39 14 34 17 62 65 700   500 0 0 0 0 0 0 0 900 0 0 0 0 0 0 100 1000 0 0 0 0 500 0 0 1000 0 0 0 0 0 0 0 1000 0 0   (c) Seconde ´etape de la construction de la troisi`eme hyper-arˆete. 39 39 14 34 17 62 65 700   500 0 0 0 0 0 0 0 900 0 0 0 0 0 0 100 1000 0 0 1000 0 500 0 0 1000 0 0 0 0 0 0 0 1000 0 0   (d) Construction de la quatri`eme hyper-arˆete. 39 39 14 34 17 62 65 700   500 0 0 0 0 0 0 0 900 0 0 0 0 0 0 100 1000 0 0 1000 300 500 0 0 1000 0 0 0 0 0 0 0 1000 0 0   (e) Premi`ere ´etape de la construction de la cinqui`eme hyper-arˆete. 39 39 14 34 17 62 65   500 0 0 0 0 0 0 0 900 0 0 0 0 0 0 100 1000 0 0 1000 300 500 0 0 1000 0 0 0 0 0 0 0 1000 0 700   (f) Seconde ´etape de la construction de la cinqui`eme hyper-arˆete et fin de l’algorithme. Figure 3.25 – Construction de la sous-matrice correspondant au second sous-ensemble {1, 2, 4}.56 CHAPITRE 3. MODELE DE MIGRATION ` 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12 ´equilibr´e. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14 ´equilibr´e. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16×21 ´equilibr´e. Figure 3.26 – Evaluation du repartitionnement `a l’aide de l’algorithme glouton avec op ´ timisation de la diagonale dans des cas ´equilibr´es. 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12 d´es´equilibr´e. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14 d´es´equilibr´e. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16 × 21 d´es- ´equilibr´e. Figure 3.27 – Evaluation du repartitionnement `a l’aide de l’algorithme glouton avec op ´ timisation de la diagonale dans des cas d´es´equilibr´es.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 57 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12 ´equilibr´e. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14 ´equilibr´e. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16×21 ´equilibr´e. Figure 3.28 – Evaluation du repartitionnement `a l’aide de l’algorithme glouton sans opt ´ imisation de la diagonale dans des cas ´equilibr´es. 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12 d´es´equilibr´e. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14 d´es´equilibr´e. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16 × 21 d´es- ´equilibr´e. Figure 3.29 – Evaluation du repartitionnement `a l’aide de l’algorithme glouton sans opt ´ imisation de la diagonale dans des cas d´es´equilibr´es.58 CHAPITRE 3. MODELE DE MIGRATION ` 3.3.4 Programme lin´eaire (LP) Les m´ethodes de repartitionnement diffusives [26,46] optimisent le volume de migration en effectuant des communications entre les parties voisines sur le graphe quotient (cf. section 2.3.2 b)). Nous proposons d’´etendre la m´ethode en utilisant un programme lin´eaire dans le cas du repartitionnement avec changement dynamique du nombre de processeurs et pour optimiser les diff´erentes m´etriques TotalV, MaxV, TotalZ et MaxZ. Le principal probl`eme de cette adaptation est que le graphe quotient ne prend en compte que les anciennes parties et non les nouvelles. Il faut donc adapter celui-ci pour prendre en compte ce changement de nombre de parties. Pour un repartitionnement de M vers N parties, on utilise un graphe d´ecrivant les messages possibles entre max(M, N) parties. Le poids de certaines parties peut ˆetre initialement nul, si elles n’existaient pas dans l’ancienne partition (cas o`u M < N) ; on peut aussi vouloir un poids final nul pour les parties qui n’existent pas dans la nouvelle partition (cas o`u M > N). Dans le cas o`u le nombre de parties augmente (M < N), il faut ajouter des nouveaux sommets dans le graphe quotient et, pour que la migration soit possible, connecter ces nouveaux sommets avec le reste du graphe. En effet, Hu et al. [26] montrent que pour qu’une solution soit possible, le graphe doit ˆetre connexe. On veut donc construire `a partir du graphe quotient Q, un nouveau graphe quotient enrichi Q˜. La fa¸con dont sont connect´es ces nouveaux sommets influence grandement la migration optimale possible, mais aussi la coupe de la partition finale. Pour obtenir une bonne migration, il faut placer les nouvelles parties proches des anciennes parties capables de fournir les sommets n´ecessaires. Pour obtenir une bonne coupe, il faut connecter les nouvelles parties avec des anciennes proches entre elles. Une m´ethode na¨ıve pour trouver de tels placements est de rechercher dans le graphe quotient de petites cliques de parties bien connect´ees entre elles et poss´edant un poids ´elev´e. Dans le cas o`u le nombre de parties diminue, le graphe quotient n’a pas besoin d’ˆetre modifi´e mais il faut choisir les parties qui seront supprim´ees, c’est-`a-dire dont le poids final vis´e est nul. a) Optimisation du volume total de migration TotalV Une fois le graphe Q˜ des messages autoris´es construit, il faut d´ecider du volume de donn´ees `a communiquer sur chaque arˆete. Pour minimiser le volume total de migration, il est possible d’utiliser le programme lin´eaire suivant : minimiser X i,j eij . Contraintes lin´eaires : ∀i ∈ V, vi = X j (eji − eij ). (3.18) Bornes : ∀i ∈ V, vi ≤ di + ub. (3.19) ∀(i, j) ∈ E, 0 ≤ eij . (3.20) On note eij la quantit´e de donn´ees envoy´ees par la partie i vers la partie j. Cette variable est toujours positive ou nulle (´equation 3.20) ; si le message se passe dans l’autre sens, eij est nul et eji contient le volume de donn´ees ´echang´ees. vi est la variation de la quantit´e de donn´ees de la partie i et est ´egale `a la diff´erence des donn´ees re¸cues et envoy´ees (´equation 3.18). di est3.3. CONSTRUCTION DES MATRICES DE MIGRATION 59 1 2 3 1 3 2 4 4 3 5 2 3 3 0 Figure 3.30 – Exemple de partition initiale et de son graphe quotient enrichi. la variation souhait´ee de la quantit´e de donn´ees de la partie i, c’est-`a-dire la diff´erence entre le poids initial et le poids souhait´e. vi doit ˆetre `a peu pr`es ´egal `a di `a une tol´erance de d´es´equilibre ub pr`es (´equation 3.19). Par exemple, en prenant la partition en trois parties de la figure 3.30, on construit un graphe quotient de trois sommets auquel on ajoute un quatri`eme pour repartitionner en 4 parties. Ici, le nouveau sommet est connect´e aux trois autres. L’application des contraintes 3.18 donne : v1 = e21 − e12 + e31 − e13 + e41 − e14 v2 = e12 − e21 + e21 − e23 + e42 − e24 v3 = e13 − e31 + e23 − e32 + e43 − e34 v4 = e14 − e41 + e24 − e42 + e34 − e43 et les bornes 3.19 : v1 ≤ −1 v2 ≤ 0 v3 ≤ −2 v4 ≤ 3. De plus tous les eij sont positifs ou nuls. La solution de ce probl`eme est : e41 = 1 e43 = 2 et tous les autres eij sont nuls. Ce qui veut dire que la partie 1 devra envoyer un sommet `a la partie 4 et la partie 3 devra en envoyer deux. Il n’y a pas d’autre communication. b) Extension `a d’autres m´etriques Il est possible d’´etendre le programme lin´eaire pour d’autres objectifs, tels que : MaxV, TotalZ, MaxZ ou n’importe quelle combinaison lin´eaire de ceux-ci. Pour optimiser MaxV, il suffit d’ajouter une variable v repr´esentant le volume maximal de migration par partie. On cherche donc `a minimiser v = maxi∈V P j (eij + eji)  . Cela se traduit par les contraintes suppl´ementaires :60 CHAPITRE 3. MODELE DE MIGRATION ` 39 39 14 34 17 62 65 0 2020 1 1984 2 1986 3 2014 4 1996 (a) Graphe quotient. 39 39 14 34 17 62 65 (b) Groupes de sommets retenus pour les nouvelles parties ajout´ees. 0 1 2 3 4 5 6 (c) Graphe quotient enrichi avec les nouveaux sommets.   1500 0 0 0 0 520 0 0 1184 0 0 0 0 800 0 0 1428 0 0 0 558 0 0 0 1500 0 514 0 0 172 0 0 1500 324 0   (d) Matrice de migration obtenue pour l’optimisation de TotalV. Figure 3.31 – Enrichissement du graphe quotient puis construction de la matrice de migration pour le cas 5 × 7. ∀i ∈ V,X j (eij + eji) ≤ v. (3.21) v ´etant minimis´e, il vaut bien la plus grande des valeurs P j (eij + eji). Lorsque les valeurs eij sont enti`eres, on peut ajouter des variables binaires xij pour chaque arˆete donnant l’existence ou non d’un message sur cette arˆete grˆace aux contraintes : xij ≤ eij ≤ W xij . (3.22) W est le poids total du graphe, aucun message ne peut d´epasser cette taille. En ´etudiant les deux cas possibles suivant la valeur de xij , on obtient : eij = 0 si xij = 0 1 ≤ eij ≤ W si xij = 1. (3.23) xij correspond donc bien `a l’existence d’un message de la partie i vers la partie j. Il est alors possible de minimiser TotalZ en minimisant la somme des xij et MaxZ en utilisant une m´ethode similaire `a celle pour MaxV. Les programmes lin´eaires complets pour les diff´erentes m´etriques sont d´ecrits dans l’annexe A. c) Application du programme lin´eaire Pour enrichir le graphe quotient, un algorithme recherche, pour chaque nouvelle partie suppl´ementaire, de petits groupes de sommets (de taille 1, 2 ou 3) bien connect´es et de poids importants.3.3. CONSTRUCTION DES MATRICES DE MIGRATION 61 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12 ´equilibr´e. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14 ´equilibr´e. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16×21 ´equilibr´e. Figure 3.32 – Application de la construction de la matrice de migration `a l’aide du programme lin´eaire dans des cas ´equilibr´es. Nous ne d´etaillerons pas ici cet algorithme qui utilise une approche gloutonne selon un crit`ere comparable `a celui de la m´ethode Greedy, mais en bornant la taille des hyper-arˆetes (entre 1 et 3). Sur l’exemple de la figure 3.31, pour passer de 5 `a 7 parties, il faut ajouter deux nouvelles parties : un groupe de trois sommets et un groupe de deux sont choisis (fig. 3.31b). Les deux nouveaux sommets sont connect´es aux anciens sommets d’apr`es ces ensembles (fig. 3.31c). En appliquant le programme lin´eaire pour l’optimisation de TotalV sur ce graphe quotient enrichi, on obtient 6 messages : 5 messages correspondant aux arˆetes ajout´ees pour cr´eer les nouvelles parties suppl´ementaires et un message entre les parties 4 et 1. Pr´esent´es sous forme de matrice de migration, ces r´esultats donnent la matrice sur la figure 3.31d. Les valeurs sur la diagonale (en gris) ne sont pas obtenues directement par le programme lin´eaire mais calcul´ees indirectement d’apr`es les tailles des messages et les tailles des anciennes parties. 52 22 49 5 26 47 6 50 51 8 24 22 51 (a) Hypergraphe de repartitionnement dans le cas 8 × 12 d´es´equilibr´e. 26 21 17 32 26 23 30 12 28 27 40 30 3 9 29 19 22 21 25 21 17 29 29 (b) Hypergraphe de repartitionnement dans le cas 12 × 14 d´es´equilibr´e. 27 20 24 4 23 4 5 30 23 21 5 25 21 25 8 21 21 4 25 29 26 10 24 8 26 23 20 28 4 23 23 24 23 (c) Hypergraphe de repartitionnement dans le cas 16 × 21 d´es- ´equilibr´e. Figure 3.33 – Application de la construction de la matrice de migration `a l’aide du programme lin´eaire dans des cas d´es´equilibr´es. Les r´esultats obtenus pour diff´erents cas avec l’optimisation de TotalV sont pr´esent´es sur62 CHAPITRE 3. MODELE DE MIGRATION ` les figures 3.32 et 3.33. Les tailles des hyper-arˆetes finales correspondant aux nouvelles parties sont effectivement limit´ees `a un maximum de 3 et les autres communications se font uniquement le long des arˆetes du graphe quotient. Cet algorithme optimise la m´etrique souhait´ee, mais relativement `a un graphe quotient enrichi donn´e dont la construction ne permet pas toujours une migration optimale. 3.4 Evaluation des m´ethodes et conclusion ´ Nous comparons les m´ethodes de construction de matrice de migration pr´esent´ees dans ce chapitre : la m´ethode bas´ee sur la chaˆıne (1D), la m´ethode d’appariement (Matching, seulement dans le cas ´equilibr´e), les deux variantes de l’algorithme glouton avec optimisation de la diagonale (GreedyD) et sans (Greedy) et le programme lin´eaire optimisant TotalV (LP). Les m´ethodes pr´esent´ees sont ´evalu´ees sur six cas ´equilibr´es et d´es´equilibr´es. Les trois cas ´equilibr´es sont : — 8×12 avec des anciennes parties de taille 1500 et donc des nouvelles parties de taille 1000 ; — 12 × 14 avec des anciennes parties de taille 1000 et donc des nouvelles parties de taille 857 ; — 16 × 21 avec des anciennes parties de taille 1000 et donc des nouvelles parties de taille 761. Les trois cas d´es´equilibr´es utilisent les mˆemes nombres de parties : — 8 × 12 avec un d´es´equilibre de 49 % et des nouvelles parties de taille 1509 ; — 12 × 14 avec un d´es´equilibre de 58 % et des nouvelles parties de taille 1311 ; — 16 × 21 avec un d´es´equilibre de 50 % et des nouvelles parties de taille 922. Ces d´es´equilibres ont ´et´e r´ealis´es avec la m´ethode utilis´ee par l’article [56] : pour chaque partie, un nombre al´eatoire de sommets sont s´electionn´es pour avoir leur poids tripl´es, conduisant `a un d´es´equilibre d’environ 50 %. Les tableaux 3.1 et 3.2 pr´esentent les m´etriques associ´ees aux applications pr´esent´ees dans les sections pr´ec´edentes. Les quatre m´etriques pr´esent´ees ne permettent pas d’´evaluer la qualit´e de la coupe finale mais seulement la qualit´e de la migration. La coupe ne pourra ˆetre ´evalu´ee qu’apr`es le repartitionnement dans le chapitre 5. En dehors du repartitionnement 8×12 dans le cas ´equilibr´e, on remarque que les optimisations de TotalV et MaxZ sont contradictoires. En effet, comme expliqu´e avec la m´ethode d’appariement, l’optimisation de la diagonale oblige les nouvelles parties suppl´ementaires `a prendre les donn´ees depuis de nombreuses anciennes parties, ce qui favorise des hyper-arˆetes de grandes tailles et donc l’augmentation de MaxZ. Les m´ethodes 1D et Greedy donnent un MaxZ bas mais un TotalV plus ´elev´e, contrairement aux m´ethodes Matching (avec choix d’une matrice diagonale) et GreedyD qui optimisent en priorit´e TotalV. Le cas du programme lin´eaire est particulier : bien que le programme lin´eaire minimise TotalV, la construction du graphe quotient enrichi impose un degr´e faible. Malgr´e cette minimisation, TotalV peut ˆetre plus ´elev´e qu’avec d’autres m´ethodes mais MaxZ est maintenu bas. TotalV aurait pu ˆetre plus bas avec un choix de graphe quotient enrichi diff´erent. Il est ´egalement possible d’utiliser le programme lin´eaire pour optimiser d’autres crit`eres. Dans le cas 8 × 12 ´equilibr´e, il existe une solution donnant `a la fois un TotalV bas et un MaxZ bas que toutes les m´ethodes trouvent. Le programme lin´eaire est capable de donner un TotalV plus bas que l’optimal (4000) en profitant de la tol´erance au d´es´equilibre. Le MaxV varie peu d’une m´ethode `a l’autre et il est g´en´eralement proche de la taille d’une nouvelle partie. Une nouvelle partie devant recevoir l’int´egralit´e de ses donn´ees, il n’est pas3.4. EVALUATION DES M ´ ETHODES ET CONCLUSION ´ 63 possible d’avoir un MaxV inf´erieur `a la taille id´eale d’une nouvelle partie. Dans le cas ´equilibr´e, le TotalZ optimal est bien atteint pour toutes les m´ethodes sauf le programme lin´eaire qui n’optimise pas ce crit`ere. Dans le cas d´es´equilibr´e, l’optimal n’est pas connu. La m´ethode de la chaˆıne atteint max(M, N) − 1 messages et les algorithmes gloutons donne un nombre de messages inf´erieur grˆace `a la recherche des sous-ensembles. Bien que le programme lin´eaire n’optimise pas le nombre de messages, celui-ci reste tr`es bas. C’est un effet de bord de la minimisation de TotalV. Dans la suite de cette th`ese, nous retiendrons les m´ethodes utilisant l’algorithme glouton (Greedy et GreedyD) et le programme lin´eaire (LP). L’algorithme glouton permet de minimiser TotalZ et offre deux variantes permettant au choix de minimiser fortement TotalV ou de garder MaxZ bas. La m´ethode d’appariement (Matching) n’est pas utilisable dans le cas g´en´eral et la m´ethode 1D donne des r´esultats comparables `a la m´ethode Greedy (MaxZ faible mais TotalV plus ´elev´e) mais avec de moins bons r´esultats. La construction de matrices de migration `a partir du graphe quotient est la premi`ere ´etape de notre m´ethode de repartitionnement dont la d´emarche globale est rappel´ee en figure 3.34. Les matrices de migration ainsi construites vont ˆetre utilis´ees par les algorithmes de repartitionnement de graphe pr´esent´es dans le chapitre suivant.64 CHAPITRE 3. MOD `ELE DE MIGRATION 1D (fig. 3.14) Matching (fig. 3.22) GreedyD (fig. 3.26) Greedy (fig. 3.28) LP (fig. 3.32) Cas 8 × 12 TotalV 4000 4000 4000 4000 3960 MaxV 1000 1000 1000 1000 900 TotalZ 8 8 8 8 8 MaxZ 2 2 2 2 2 Cas 12 × 14 TotalV 3427 1714 1714 3426 2900 MaxV 857 857 857 857 939 TotalZ 12 12 12 12 13 MaxZ 2 6 6 2 3 Cas 16 × 21 TotalV 5239 3808 3808 5335 5606 MaxV 762 762 762 762 1150 TotalZ 20 20 20 20 20 MaxZ 2 4 4 3 3 Table 3.1 – R´esultats des diff´erentes m´ethodes dans le cas ´equilibr´e.3.4. EVALUATION DES M ´ ETHODES ET CONCLUSION ´ 65 1D (fig. 3.16) GreedyD (fig. 3.27) Greedy (fig. 3.29) LP (fig. 3.33) Cas 8 × 12 TotalV 7453 6266 7127 6299 MaxV 1871 1869 1869 1862 TotalZ 11 10 10 10 MaxZ 2 4 3 2 Cas 12 × 14 TotalV 5064 5960 5769 5261 MaxV 1311 1372 1372 2013 TotalZ 13 12 12 13 MaxZ 2 3 3 4 Cas 16 × 21 TotalV 6200 5504 6138 5858 MaxV 922 922 923 1103 TotalZ 20 18 18 19 MaxZ 2 5 3 4 Table 3.2 – R´esultats des diff´erentes m´ethodes dans le cas d´es´equilibr´e.66 CHAPITRE 3. MOD `ELE DE MIGRATION Méthode d'appariement (Matching) Méthode de la chaîne (1D) Méthode gloutonne (Greedy) Méthode de partitionnement biaisé (Biased) Méthode diffusive (Diff) Hyper-arêtes de repartitionnement Matrice de migration Graphe quotient Nouvelle partition en N Graphe partitionné en M Construction de la matrice de migration M×N Repartitionnement M×N Programme linéaire (LP) Figure 3.34 – Vue d’ensemble.Chapitre 4 Repartitionnement M × N Sommaire 4.1 Repartitionnement M×N bas´e sur le partitionnement biais´e (BIASED) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.1.1 M´ethodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68 4.1.2 Limitations des partitionneurs . . . . . . . . . . . . . . . . . . . . . . 71 4.2 Partitionnement k-aire direct (KGGGP) . . . . . . . . . . . . . . . 73 4.2.1 Description de l’algorithme . . . . . . . . . . . . . . . . . . . . . . . . 73 4.2.2 Crit`eres de s´election . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.2.3 Complexit´e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 4.2.4 Am´eliorations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.2.5 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 ´ 4.3 Repartitionnement M × N bas´e sur la diffusion (DIFF) . . . . . . . 85 4.4 Partitionnement biais´e `a l’aide d’hyper-arˆetes de repartitionnement 89 4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Dans ce chapitre, nous pr´esentons nos algorithmes de repartitionnement M × N, r´esum´es en figure 4.1. Nos m´ethodes de repartitionnement biais´e (BIASED) et diffusive (DIFF) s’inspirent des m´ethodes de repartitionnement classiques du mˆemes noms mais sont ´etendues dans le cas du repartitionnement avec un nombre de processeurs variable. Ces deux m´ethodes se basent sur une matrice de migration obtenue `a l’aide d’un des algorithmes pr´esent´es dans le chapitre pr´ec´edent. De plus, dans le cadre de notre partitionnement biais´e, nous mettons en ´evidence des limitations de la m´ethode des bissections r´ecursives largement utilis´ee par les diff´erents outils de partitionnement actuels, et nous proposons une m´ethode de partitionnement k-aire direct (KGGGP) qui surmonte ces limitations. 4.1 Repartitionnement M × N bas´e sur une m´ethode de partitionnement biais´e (BIASED) Nous pr´esentons dans cette section une m´ethode partitionnement biais´e permettant de r´ealiser un repartitionnement M × N en respectant un mod`ele de migration donn´e par une matrice C. Cette m´ethode n’impose que les messages donn´es dans le mod`ele de migration et non leur volume. N´eanmoins, les volumes sont respect´es lorsque le nombre de messages de C est minimal, comme 6768 CHAPITRE 4. REPARTITIONNEMENT M × N Méthode de partitionnement biaisé (Biased) Méthode diffusive (Diff) Hyperarêtes de repartitionnement Matrice de migration Nouvelle partition en N Graphe partitionné en M Repartitionnement M×N Figure 4.1 – Vue d’ensemble de nos algorithmes de repartitionnement M × N d’un graphe. nous le verrons dans la section suivante. Cette m´ethode est donc d´econseill´ee pour les mod`eles de migration n’optimisant pas TotalZ, en particulier ceux obtenus `a l’aide du programme lin´eaire optimisant seulement TotalV, MaxV ou MaxZ. Cette m´ethode de partitionnement biais´e s’inspire des m´ethodes de repartitionnement utilisant des sommets fixes [2, 8, 9] (cf. section 2.3.2). Le graphe est enrichi avec des sommets fixes et de nouvelles arˆetes puis il est partitionn´e avec un partitionneur acceptant les sommets fixes. 4.1.1 M´ethodologie Pour cr´eer un nouvelle partition respectant le mod`ele de communication construit grˆace aux m´ethodes pr´esent´ees dans le chapitre 3, on utilise une m´ethode de repartitionnement `a sommet fixes. De la mˆeme fa¸con que dans le cas du repartitionnement sans changement du nombre de processeurs, on ajoute N sommets fixes de poids nuls repr´esentant les processeurs. Mais au lieu de les connecter aux sommets de leur ancienne partie, ils sont connect´es aux sommets des parties dont on accepte qu’ils re¸coivent des donn´ees, conform´ement `a la matrice C. Plus pr´ecis´ement, pour repartitionner un graphe G de M parties vers N et obtenir une nouvelle partition P ′ , ´etant donn´e une ancienne partition P = (Pi)i∈J1,MK et une matrice de migration C, il faut : 1. construire un graphe enrichi G˜ = (V , ˜ E˜) `a partir de G avec : — N sommets fixes (fj )j∈J1,NK de poids nuls, chacun fix´e dans une nouvelle partie diff´erente j ; — des arˆetes suppl´ementaires dont le poids est appel´e « coˆut de migration », telles que pour chaque ´el´ement Ci,j > 0 de la matrice de migration, les sommets de l’ancienne partie i soient connect´es au sommet fixe de la nouvelle partie j. Plus formellement, ∀i ∈ J1, MK, ∀j ∈ J1, NK, ∀v ∈ Pi ,  Ci,j 6= 0 ⇐⇒ (v, fj ) ∈ E˜  . 2. partitionner le nouveau graphe enrichi G˜ en N parties avec un partitionneur acceptant les sommets fixes ;4.1. PARTITIONNEMENT BIAISE´ 69 3. restreindre la partition de G˜ au graphe original G pour obtenir P ′ . Le rˆole des arˆetes ajout´ees, dites « de migration », n’est pas exactement le mˆeme que dans les m´ethodes classiques. Elles ne servent pas, ici, `a minimiser la migration directement mais `a imposer le sch´ema de communication choisi. Un sommet est souvent reli´e `a plusieurs sommets fixes et au plus une de ses arˆetes de migration peut ne pas ˆetre coup´ee. Avec un poids suffisamment ´elev´e, le partitionneur laissera exactement une arˆete de migration par sommet non-coup´ee, pour minimiser la coupe. Ainsi, en cherchant `a remplir ses objectifs habituels, le partitionneur impose le sch´ema de migration choisi. Un exemple de repartitionnement est propos´e en figure 4.2. En partant de l’ancienne partition en M = 5 parties (figure 4.2a), on veut construire une nouvelle partition en N = 7 parties. A l’aide ` du graphe quotient associ´e (figure 4.2b), on construit une matrice de migration (ici repr´esent´ee par l’hypergraphe de repartitionnement) comme indiqu´e dans le chapitre pr´ec´edent (figure 4.2c). Les arˆetes de migration sont ajout´ees d’apr`es cet hypergraphe sur la figure 4.2d : par exemple, le sommet fixe de la nouvelle partie 3 est reli´e `a tous les sommets des parties contenues dans l’hyper-arˆete correspondante (les anciennes parties 3 et 4). Le partitionneur calcule ensuite une nouvelle partition de ce graphe enrichi. La figure 4.2e montre les arˆetes de migration coup´ees (en rouge) et internes (en vert). Enfin, la partition de G˜ est restreinte graphe G pour obtenir la partition finale (figure 4.2f). Cette m´ethode utilise n’importe quel outil de partitionnement classique capable de prendre en compte le cas des sommets fixes 1 . Il est aussi possible d’utiliser des partitionneurs d’hypergraphe, les arˆetes de migration deviennent alors des hyper-arˆetes de taille 2, la coupe de telles hyper-arˆetes ´etant ´equivalente `a celle des arˆetes du graphe. Les sommets fixes et les arˆetes de migration imposent le sch´ema de communication mais pas le volume des messages ´echang´es. Affecter un sommet `a une partie de fa¸con `a engendrer un message non autoris´e correspond `a une arˆete de migration coup´ee en plus. Un sommet est reli´e par des arˆetes de migration `a un ou plusieurs sommets fixes chacun dans une partie diff´erente. Au mieux une seule de ces arˆetes de migration n’est pas coup´ee (le sommet ne peut ˆetre que dans une seule partie), alors la migration de ce sommet est autoris´e par la matrice de migration. Si le sommet est dans une partie diff´erente de celles des sommets fixes auxquels il est connect´e, la migration de ce sommet n’est pas autoris´ee et toutes les arˆetes de migration de ce sommets sont coup´ees. Le partitionneur choisira donc de placer un sommet dans l’une des parties des sommets fixes auxquels il est connect´e. La contrainte sur la taille des parties n’empˆeche pas ce choix car, par construction de la matrice de migration, il y a toujours assez de sommets reli´es au sommet fixe pour cr´eer la partie de la taille souhait´ee parmi ces derniers. Bien que seul le sch´ema de communication soit impos´e, les tailles des messages sont respect´ees lorsque le nombre de message (TotalZ) est minimal. Le partitionneur est libre de cr´eer n’importe quelle partition induisant une matrice de migration avec les non-z´eros souhait´es. On cherche le nombre de matrices de migration C ′ qu’il est possible d’obtenir apr`es le partitionnement. L’espace des matrices de migration possibles peut ˆetre d´efini par un syst`eme d’´equations lin´eaires avec autant d’inconnues, not´ees C ′ i,j , que de messages (d’une ancienne partie i vers une nouvelle partie j). Les ´equations sont les contraintes de sommes sur les lignes et les colonnes ; il y en a M +N. Il y a autant d’inconnues C ′ i,j que d’´el´ements Ci,j non nuls dans la matrice de migration C souhait´ee. En notant Vi le poids de l’ancienne partie i, V ′ j la poids de la nouvelle partie j et W le poids 1. Il est en fait possible d’obtenir un partitionnement ´equivalent sans sommets fixes : il suffit de donner aux sommets « fixes » un poids suffisamment grand, pour qu’il ne puisse pas y en avoir deux dans une mˆeme partie. Les nouvelles parties sont ensuite renum´erot´ees pour que les sommets fixes soient dans les bonnes parties. Le d´efaut de cette m´ethode est que le d´es´equilibre tol´er´e est plus important `a cause du poids de ces sommets.70 CHAPITRE 4. REPARTITIONNEMENT M × N (a) Partition initiale de G en 5 parties. 1 2 3 4 5 (b) Graphe quotient Q de la partition initiale. 1 2 3 4 5 6 7 (c) Hypergraphe de repartitionnement dessin´e par dessus le graphe quotient. (d) Graphe G˜ auquel est ajout´e les sommets fixes et arˆetes de migration. (e) Partition de G˜ en 7 parties. Les arˆetes de migration coup´ees sont en rouge, les arˆetes de migration non-coup´ees en vert. (f) Partition finale de G en 7 parties. Figure 4.2 – Repartitionnement de 5 vers 7 parties.4.1. PARTITIONNEMENT BIAISE´ 71 total du graphe (W = P i Vi = P j V ′ j ), on a : ∀i ∈ J1, MK , X j∈J1,NK Ci,j>0 C ′ i,j = Vi (4.1) ∀j ∈ J1, NK , X i∈J1,MK Ci,j>0 C ′ i,j = V ′ j (4.2) La somme des ´equations sur les lignes (´equations 4.1) est ´equivalente `a la somme des ´equations sur les colonnes (´equations 4.2) et donnent : X i∈J1,MK j∈J1,NK Ci,j>0 C ′ i,j = W Ce syst`eme poss`ede donc M + N − 1 ´equations ind´ependantes 2 . On sait que l’ensemble des solutions n’est pas vide car la matrice de migration C est une solution. La dimension de l’espace solution est donc ´egale `a la diff´erence entre le nombre d’inconnues (le nombre de messages dans la matrice C) et le rang du syst`eme. Si le nombre de messages dans C n’est pas minimal (il n’atteint pas le rang du syst`eme), il existe une infinit´e de solutions C ′ possibles. Le partitionneur peut donner une de ces matrice C ′ (´eventuellement diff´erente de C) en minimisant la coupe du graphe enrichi. Plus le nombre de messages dans C est important plus il y a de libert´e dans le partitionnement. La matrice de migration C ′ effectivement obtenue apr`es repartitionnement peut ne pas ˆetre aussi bonne que la matrice C choisie. On pr´ef´erera donc utiliser ce partitionnement biais´e avec des matrices de migration donnant un faible nombre de messages (TotalZ). 4.1.2 Limitations des partitionneurs Cette m´ethode partitionnement `a sommets fixes peut poser quelques probl`emes avec certains partitionneurs, plus particuli`erement ceux utilisant des bissections r´ecursives [3]. Le premier probl`eme est que le placement et la num´erotation des nouvelles parties peut ne pas ˆetre favorable aux bissections r´ecursives. Comme expliqu´e dans la section 3.3.1, lors d’une bissection, chaque moiti´e regroupera plusieurs parties suivant leurs num´eros : g´en´eralement les parties avec les plus petits num´eros sont regroup´ees dans une moiti´e et les plus grand num´eros dans l’autre. Il est possible qu’une moiti´e regroupe des parties qu’on souhaite ´eloign´ees. Les heuristiques peuvent avoir plus de mal `a cr´eer des parties et devoir travailler avec des graphes non connexes. Mais, certains cas sont encore plus graves. Mˆeme avec des bissections parfaites et un poids tr`es important sur les arˆetes de migration, un partitionneur `a bissections r´ecursives peut ne pas 2. Il est possible de r´eduire encore le nombre d’´equations ind´ependantes lorsqu’il existe une somme partielle de poids d’anciennes parties ´egale `a une somme partielle de poids de nouvelles parties. C’est-`a-dire que s’il existe A ⊂ J1, MK et B ⊂ J1, NK tels que P i∈A Vi = P j∈B V ′ j et que pour tout (i, j) ∈ J1, MK × J1, NK tels que (i ∈ A ∧ j /∈ B) ∨ (i /∈ A ∧ j ∈ B), Ci,j = 0, alors la somme des ´equations sur les lignes correspondant aux anciennes parties de A est ´equivalente `a la somme des ´equations sur les colonnes correspondant aux nouvelles parties de B : X i∈A j∈B Ci,j>0 C ′ i,j = X i∈A Vi = X j∈B V ′ j72 CHAPITRE 4. REPARTITIONNEMENT M × N 1 2 3 4 (a) Partition intiale et sommets fixes. 3 3 4 (b) Graphe quotient et hypergraphe de repartitionnement. (c) Partition finale k-aire direct. 1–2 3–4 (d) Premi`ere bissection. (e) Partition finale avec bissections r´ecursives. Figure 4.3 – Exemple d’´echec de partitionnement avec bissections r´ecursives. respecter le sch´ema de communication impos´e alors qu’un partitionneur k-aire direct trouverait une solution [3, 60]. Par exemple, la figure 4.3 pr´esente un cas o`u la m´ethode des bissections r´ecursives ´echoue. La grille est initialement partitionn´ee en 3 (figure 4.3a) et on souhaite la repartitionner en 4 en utilisant l’hypergraphe de repartitionnement de la figure 4.3b. Un exemple de partition finale respectant ce sch´ema est pr´esent´e sur la figure 4.3c. On essaye d’appliquer les bissections r´ecursives sur ce graphe. Lors de la premi`ere bissection (figure 4.3d), le partitionneur regroupe les parties 1 et 2 d’un cot´e, et 3 et 4 de l’autre. La meilleure bissection possible est de coup´ee le graphe verticalement par le milieu. Les parties 1 et 2 seront donc dans la partie gauche et les parties 3 et 4 dans la partie droite. Il n’est donc pas possible pour la partie 4 de reprendre des sommets de l’ancienne partie 2. Chaque moiti´e est ensuite `a nouveau bipartitionn´ee pour obtenir la partition finale pr´esent´ee sur la figure 4.3e. Sa matrice de migration est :   6 6 3 9 9 3   ,4.2. PARTITIONNEMENT K-AIRE DIRECT (KGGGP) 73 alors que celle attendue, qui est celle de la partition de la figure 4.3c, est :   9 3 9 3 9 3   . La partition de bissections r´ecursives coupent 39 arˆetes de migration alors qu’il est possible de n’en couper seulement 36, mˆeme si on a suppos´e que les bissections ´etaient parfaites et le poids des arˆetes de migration bien plus important que celui des arˆetes internes. En pratique, la plupart des outils utilisent un multi-niveaux k-aire avec une partition initiale du graphe contract´e calcul´ee par bissections r´ecursives. Dans le cas o`u les bissections r´ecursives ´echouent `a calculer une bonne partition initiale, le raffinement k-aire appliqu´e pendant la phase d’expansion doit alors grandement modifier la partition initiale pour optimiser la coupe. Quand l’heuristique de raffinement r´eussit `a corriger la partition initiale, ce qui est difficile comme ces heuristiques sont souvent incr´ementales, le partitionneur est alors tr`es ralenti par la phase d’expansion. Pour cette raison, nous proposons une heuristique de partitionnement k-aire direct pouvant ˆetre utilis´ee `a la place des bissections r´ecursives en tant que m´ethode de partitionnement initiale dans un partitionneur. 4.2 Partitionnement k-aire direct (KGGGP) L’heuristique du Greedy Graph Growing Partitioning (GGGP) est une heuristique gloutonne largement utilis´ee dans le cadre du bipartitionnement [5, 11, 29]. En partant de deux sommets « graines », les autres sommets sont ajout´es un `a un dans chacune des parties. Nous proposons d’´etendre cette m´ethode dans le cas du partitionnement k-aire. Nous l’appellerons dans ce cas KGGGP (k-way greedy graph growing partitioning). 4.2.1 Description de l’algorithme Cette heuristique s’inspire en grande partie de celle de Fiduccia et Mattheyses [17] (abr´eg´ee FM), `a la diff´erence que les sommets ne sont initialement dans aucune partie et sont `a distribuer dans k parties. Cette m´ethode peut ˆetre vue comme un raffinement FM k + 1-aire o`u la partie suppl´ementaire (que l’on num´erotera −1) contient initialement tous les sommets et doit ˆetre vide dans la partition finale. Pour r´ealiser cet algorithme, on consid`ere tous les d´eplacements possibles des sommets sans parties vers une des k parties. Chaque it´eration de l’algorithme 5 place un sommet sans partie dans une partie p. A chaque it´eration, on s´electionne le meilleur d´eplacement, d’ ` apr`es un crit`ere de s´election bas´e sur la coupe, qui respecte l’´equilibre final (c’est-`a-dire que le poids Wp de la partie p ne d´epassera pas la taille maximum permise avec un facteur de d´es´equilibre ǫ). Il existe plusieurs crit`eres de s´election qui seront d´etaill´es plus loin dans cette section. Il est possible qu’aucun sommet ne respecte la contrainte d’´equilibre, particuli`erement dans le cas d’un graphe contract´e dans le cadre d’un algorithme multi-niveaux, o`u des sommets peuvent avoir un poids tr`es important par rapport au poids total du graphe. Dans ce cas, l’´equilibre ne pourra pas ˆetre respect´e et le meilleur d´eplacement est choisi ind´ependamment du poids du sommet et de la partie cible. Une fois un sommet s´electionn´e, il est alors d´eplac´e et verrouill´e, c’est-`a-dire qu’il ne sera plus consid´er´e pour d’autres d´eplacements. Le crit`ere de s´election calcule le score si(u) d’un d´eplacement `a partir des parties de ses voisins (cf. section suivante). Ainsi lorsqu’un sommet est d´eplac´e, le crit`ere de s´election de chacun de ses voisins doit ˆetre mis `a jour.74 CHAPITRE 4. REPARTITIONNEMENT M × N p v s = sp(v) = sp'(v') déplacement de v dans p tableau des scores tableau des déplacements p' v' déplacement de v' dans p' ... score min score max Figure 4.4 – Structure de donn´ees inspir´ee de Fiduccia et Mattheyses, illustrant le cas des d´eplacements de v dans p et de v ′ dans p ′ ayant un mˆeme score s. L’algorithme 5 s´electionne le meilleur d´eplacement globalement. Mais il existe d’autres variantes possibles pour s´electionner un d´eplacement afin d’obtenir une partition ´equilibr´ee [29]. Par exemple, la partie de destination du d´eplacement est choisie l’une apr`es l’autre (m´ethode appel´ee round-robin), ou elle peut ˆetre la partie dont le poids courant est le plus faible. Dans ces deux cas, on choisit le meilleur d´eplacement seulement vers la partie choisie. Pour trouver rapidement le meilleur d´eplacement d’apr`es le crit`ere choisi, la structure de donn´ees pr´esent´ee par Fiduccia et Mattheyses est utilis´ee. Cette structure de donn´ees (r´esum´ee sur la figure 4.4) utilise un tableau `a chaque case duquel est associ´ee une valeur du score utilis´ee comme crit`ere de s´election (le gain de coupe du d´eplacement dans le cas de FM). Chaque case de ce tableau donne la liste doublement chain´ee des d´eplacements correspondant `a ce score. Ce tableau des scores permet de s´electionner rapidement un d´eplacement avec un gain donn´e (ici, le plus grand). Un autre tableau r´ef´eren¸cant les ´el´ements des listes chain´ees par leur num´ero de sommet permet de les retrouver rapidement pour effectuer une mise `a jour du gain. Dans notre algorithme k-aire ce tableau est ´etendu avec une seconde dimension correspondant `a la partie du d´eplacement. Le double chainage permet d’effectuer en temps constant le changement de liste d’un ´el´ement apr`es une mise `a jour ou son retrait quand le sommet est plac´e dans une partie. En pratique, notre mise en œuvre de cet algorithme utilise deux tableaux de score pour classer les d´eplacements. Initialement, le premier contient tous les d´eplacements et le second est vide. Les d´eplacements sont recherch´es d’abord dans la premi`ere structure, lorsque qu’un d´eplacement ne respectant pas la contrainte d’´equilibre est trouv´e, il est d´eplac´e dans la seconde. En effet, le poids des parties ne faisant que croˆıtre, il ne respectera pas la contrainte d’´equilibre dans le futur, il est inutile de le consid´erer `a nouveau pour ˆetre d´eplacer. Quand la premi`ere structure4.2. PARTITIONNEMENT K-AIRE DIRECT (KGGGP) 75 est vide, il n’y a plus de d´eplacements respectant la contrainte d’´equilibre, la seconde structure est alors utilis´ee jusqu’`a la fin de l’algorithme et le poids de la partie n’est plus v´erifi´e. Il est tr`es simple de g´erer le cas des sommets fixes avec cette m´ethode. En effet, les sommets fixes sont simplement plac´es dans leur parties respectives initialement et ne sont pas consid´er´es dans les d´eplacements possibles. Algorithme 5 Heuristique de partitionnement gloutonne (KGGGP) Entr´ee : Graphe G `a partitionner Entr´ee : k parties ne contenant que les sommets fixes Entr´ee : Partition o`u tout les sommets fixes sont dans leur partie respective, et les autres sommets sont dans la partie −1 tant que il existe des sommets dans la partie −1 faire S´electionner un sommet v sans partie dont le d´eplacement vers une partie p a un crit`ere de s´election sp(v) maximal et tel que Wp + wv ≤ (1 + ǫ) × W/k si un tel sommet n’existe pas alors S´electionner un sommet v sans partie dont le d´eplacement vers une partie p a un crit`ere de s´election sp(v) maximal fin si Placer le sommet v dans la partie p Wp ← Wp + wv pour tout voisin u de v faire pour tout partie i faire Mettre `a jour le crit`ere de s´election si(u) fin pour fin pour fin tant que retourner Partition de G en k parties 4.2.2 Crit`eres de s´election Il existe plusieurs crit`eres pour ´evaluer la qualit´e des d´eplacements. On note sp(v), le score du d´eplacement du sommet v vers la partie p. Les d´eplacements sont ´evalu´es en fonction des arˆetes les connectant aux diff´erentes parties. On notera Ni(u) le poids des arˆetes connectant le sommet u `a des voisins dans la partie i, et N−1(u) le poids des arˆetes le connectant `a des sommets sans partie. On appelle arˆete interne, une arˆete dont les deux extr´emit´es sont dans la mˆeme partie et on appelle arˆete externe (ou coup´ee), une arˆete dont les deux extr´emit´es sont dans des parties diff´erentes. Comme avec la m´ethode FM, il est possible d’utiliser la formule du gain de coupe en consid´erant que les sommets sans parties sont dans une partie num´erot´ee −1. Le gain d’un sommet u d´eplac´e de la partie i vers j se calcule par la diff´erence entre les arˆetes vers la nouvelle partie j, qui ´etaient coup´ees mais ne le seront plus, et les arˆetes vers l’ancienne partie i, qui ´etaient internes et seront coup´ees. En reprenant la formule du gain : gi→j (u) = Nj (u) − Ni(u), le crit`ere de s´election bas´e sur le gain pour d´eplacer u dans i est si(u) = g−1→i(u) = Ni(u) − N−1(u). Battiti et Bertossi [5] proposent d’utiliser un autre crit`ere, appel´e diff. Bien que con¸cu pour le bipartitionnement, ce crit`ere peut ´egalement s’appliquer dans le cas du partitionnement k-aire. Ce crit`ere ne s’int´eresse plus aux voisins sans partie, mais utilise la diff´erence entre les nouvelles arˆetes internes (voisins dans la partie vis´ee) et les nouvelles arˆetes coup´ees (voisins dans les autres76 CHAPITRE 4. REPARTITIONNEMENT M × N i j –1 u Figure 4.5 – Diff´erentes arˆetes autour du sommet sans partie u qui se trouve `a la fronti`ere des parties i et j. parties) : si(u) = diffi (u) = Ni(u) − P j6=i Nj (u). En effet, minimiser la coupe avec la partie −1 qui finira par disparaitre peut paraitre inutile alors que les arˆetes vers les autres parties font partie de la coupe finale. D’autre part, en maximisant le nombre d’arˆetes internes (Ni(u)), on esp`ere r´eduire le nombre d’arˆetes qui devront ˆetre coup´ees plus tard. La figure 4.5 pr´esente les diff´erentes arˆetes autour du sommet u : en vert, les arˆetes correspondant `a Ni(u) ; en rouge `a Nj (u) ; et en bleu `a N−1(u). On suppose que toutes les arˆetes de cet exemple ont un poids unitaire. Si on consid`ere le d´eplacement de u dans la partie i, le gain est g−1→i(u) = 0 : initialement 3 arˆetes sont coup´ees (en vert et rouge), apr`es d´eplacement 3 arˆetes sont toujours coup´ees (cette fois en bleu et rouge). Le crit`ere diff ne s’int´eresse pas aux arˆetes avec les sommets sans partie (en bleu) mais seulement `a la diff´erence entre les futures arˆetes internes (en vert) et les arˆetes externes avec les « vraies » parties (en rouge). On a donc diffi (u) = 2 − 1 = 1. 4.2.3 Complexit´e L’algorithme de partitionnement d´eplace une fois chaque sommet libre. Il y a donc autant d’it´erations de la boucle principale que de sommets non fixes (au plus |V |). La boucle principale comporte les ´etapes de s´election, d´eplacement et mise `a jour des structures de donn´ees. Lors de la s´election, chaque d´eplacement n’est consid´er´e qu’une ou deux fois : s’il n’est pas accept´e la premi`ere fois, il est retir´e de la premi`ere liste des d´eplacements et plac´e dans la seconde ; dans la seconde liste, un d´eplacement n’est jamais rejet´e. La complexit´e en temps totale de la s´election est donc au pire proportionnelle au nombre de d´eplacements possibles, c’est-`a-dire O(k|V |). Le d´eplacement est une op´eration simple en temps constant. Cela n’est que le changement d’une valeur dans le tableau repr´esentant la partition. La mise `a jour des structures de donn´ees apr`es le d´eplacement d’un sommet, n´ecessite de visiter tous les voisins du sommet d´eplac´e. Pour chaque voisin, il est n´ecessaire de mettre `a jour le crit`ere de s´election vers chacune des k parties. Comme ces op´erations sont effectu´ees pour chaque sommet du graphe, la complexit´e en temps totale des mises `a jour est au pire O(k|E|). La complexit´e en temps de l’algorithme est donc au pire O(k|E|), en consid´erant que |V | est domin´e par |E|. La complexit´e en m´emoire est principalement due au stockage des d´eplacements possibles, elle est donc au pire O(k|V |).4.2. PARTITIONNEMENT K-AIRE DIRECT (KGGGP) 77 4.2.4 Am´eliorations Plusieurs variantes peuvent ˆetre utilis´ees pour am´eliorer la qualit´e des partitions produites par l’algorithme. a) S´election al´eatoire et r´ep´etition Lors de la s´election des sommets, plusieurs peuvent avoir le mˆeme score. Si le premier sommet trouv´e est choisi, la s´election est biais´ee par l’ordre de parcours des sommets ou par le dernier d´eplacement. En effet, lors de la mise `a jour, les voisins dont le score s’est am´elior´e se retrouvent en d´ebut de liste, ce qui tend `a faire grossir la partie toujours dans la mˆeme direction. En s´electionnant un sommet al´eatoire parmi les meilleurs, on ´evite ce biais. Cela permet d’obtenir des partitions diff´erentes avec diff´erentes ex´ecutions de l’algorithme. Comme cet algorithme est tr`es rapide lorsqu’il est appliqu´e dans le cadre d’un partitionnement multi-niveaux, il devient int´eressant de le r´ep´eter plusieurs fois et de garder la meilleure partition. Cela permet aussi une version parall`ele triviale o`u chaque nœud calcule une partition puis partage la meilleure. b) Graines Bien que l’algorithme puisse s’appliquer sans aucun sommet initialement dans une partie, les crit`eres de s´election ne seront pas tr`es efficaces pour le choix des premiers sommets. Il est donc int´eressant de choisir avant le d´ebut de l’algorithme certains sommets qui initieront les parties. Il existe plusieurs possibilit´es pour choisir ces sommets qu’on appelle « graines ». Graines al´eatoires. k sommets sont choisis al´eatoirement dans le graphe pour servir de graines `a chacune des parties. Ces techniques se combinent bien avec la r´ep´etition de l’heuristique et permettent encore plus de vari´et´e dans les tentatives pour trouver la meilleure partition possible. Graines au centre des parties. La r´ep´etition de l’heuristique peut ´egalement ˆetre utilis´ee pour trouver des graines de fa¸con plus intelligente. Apr`es une premi`ere passe `a l’aide de graines choisies d’une mani`ere quelconque, les centres 3 ou des « pseudo-centres 4 » des parties sont calcul´es et servent de graine `a l’it´eration suivante. Cette m´ethode est propos´ee par Diekmann et al. dans le cadre du Bubble Partitioning [14]. Graines ´eloign´ees. Diekmann et al. [14] proposent ´egalement un algorithme pour optimiser l’ensemble des graines initiales. L’algorithme 6 permet de construire un ensemble de k graines bien ´eloign´ees les unes des autres. En partant d’un sommet quelconque, on recherche le sommet le plus ´eloign´e `a l’aide d’un parcours en largeur. Les graines suivantes sont trouv´ees de fa¸con similaire en initialisant le parcours en largeur avec les n graines d´ej`a trouv´ees. La seconde boucle permet d’am´eliorer cet ensemble. On retire une `a une les graines de l’ensemble et on en cherche une nouvelle, toujours `a l’aide d’un parcours en largeur. Cette derni`ere boucle peut ˆetre r´ep´et´ee jusqu’`a ce que l’ensemble ne change plus ou r´ep´et´ee un nombre limit´e de fois. La complexit´e d’un parcours en largeur ´etant O(|E|), la complexit´e de la cr´eation de l’ensemble initiale ou d’une passe d’optimisation est O(k|E|). 3. Le centre d’un graphe est un sommet avec une excentricit´e minimale. 4. La recherche du centre d’un graphe est complexe. Nous pr´ef´erons donc chercher un « pseudo-centre » `a l’aide d’un parcours en largeur `a partir de la fronti`ere de la partie. Le dernier sommet parcouru est le plus ´eloign´e de la fronti`ere, il est donc s´electionn´e en tant que « pseudo-centre »78 CHAPITRE 4. REPARTITIONNEMENT M × N Algorithme 6 Cr´eation d’un ensemble de k graines ´eloign´ees