Méta-modélisation du Comportement d'un Modèle de Processus : Une Démarche de Construction d'un Moteur d'Exécution - thèse Informatique - Revenir à l'accueil

 

Thèses en informatique :

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

 Lh-rs-p2p-une-nouvel..> 03-Jan-2015 21:59  2.7M  

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

 Vers-une-capitalisat..> 03-Jan-2015 22:00  4.6M  
Congrès d'informatique :

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

 The-Power-of-Polynom..> 03-Jan-2015 21:16  2.1M  
Cours d'informatique :

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

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

[TXT]

 Vers-une-signalisati..> 03-Jan-2015 17:25  3.8M 
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 consommat