Depuis plusieurs années, l'évolution naturelle des applications vers la distribution a mis en évidence le besoin d'informations autre que celles uniquement nécessaires aux traitements. C'est ainsi qu'au fil du temps, les concepteurs et développeurs ont dû intégrer à leurs applications des tâches d'acquisition de l'environnement d'exécution permettant ainsi aux applications dans un premier temps de prendre en compte le contexte, puis de devenir « sensibles au contexte » et d'adapter leurs traitements en conséquence puis, dans un second temps, d'évoluer par reconfigurations dynamiques de manière à répondre au mieux aux sollicitations.<br /><br />Le contexte peut se diviser en trois couches. La première appelée « type de contexte » permet de réaliser l'acquisition du contexte, la deuxième, appelée « moyens de mise en œuvre de la gestion du contexte » est chargée de la gestion du contexte, enfin, la troisième couche offre les mécanismes permettant l'adaptation au contexte.<br /><br />Le premier chapitre de ce mémoire est intitulé « Processus de réingénierie » porte principalement sur la première phase d'acquisition des informations contextuelles et plus particulièrement sur les applications totalement (réingénierie) ou partiellement existantes comme les COTS.<br />Dans un premier temps, l'objectif est de réaliser une analyse des informations produites par des modules logiciels afin de prendre en compte mais également de fabriquer (si nécessaire) automatiquement à l'aide de connecteurs - lorsque c'est possible - des informations contextuelles de plus haut niveau. Dans un second temps, je me suis intéressé à l'intégration de Composants sur Etagères (ou COTS Products). L'objectif est ici une analyse des assemblages de COTS sélectionnés afin de s'assurer de la faisabilité du déploiement, et donc de la réalisation de l'application. Nous nous situons ici également dans le domaine de l'acquisition des informations contextuelles dans le sens où nous ne gérons que la phase d'acquisition du contexte et de production d'informations permettant des prises de décisions concernant la possibilité d'assemblage des COTS Products. <br /><br />Le deuxième chapitre intitulé « Outils d'adaptation permettant la prise en compte du contexte » est transversal aux trois couches précédemment présentées. Un modèle de plate-forme de supervision réflexive (Kalinahia) y est présenté afin de proposer les services nécessaires à la gestion du contexte. Un modèle de composant supervisable (Osagaia) ainsi qu'un modèle de connecteur (Korrontea) y est également présenté. Ces deux modèles offrent les mécanismes d'adaptation, de migration et de composition nécessaires à l'adaptation de l'application. <br /><br />Le troisième chapitre intitulé « Contexte et Qualité de service » présente comment la notion de qualité de service, intimement liée à celle de contexte, est intégrée dans nos travaux. En effet, fournir la qualité de service adéquate à un utilisateur ou, plus généralement à une application, demande d'avoir une connaissance à la fois du contexte de l'application mais aussi du contexte de l'utilisateur. Aussi, je propose un modèle formel de la qualité de service selon les deux critères intrinsèques (fonctionnalité) et contextuels (dans et sous quelles conditions).<br /><br />Enfin, le quatrième chapitre « Représentation des applications et de leur qualité de service » a pour objectif de proposer une modélisation d'applications sensibles au contexte ayant pour but d'assurer une qualité de service aux utilisateurs. L'approche formelle utilise des graphes orientés et prend en considération la qualité de service. Les différents graphes proposés vont du niveau conceptuel au niveau d'implantation permettant de générer directement les graphes d'implantation et de déploiement qui seront ensuite utilisés par la plateforme Kalinahia pour la reconfiguration dynamique de l'application. <br />L'objectif étant d'assurer une qualité de service acceptable (la meilleure étant un problème NP-Complet), le contexte de qualité est également pris en compte tout au long de la démarche et surtout lors des étapes de reconfiguration puisque c'est une modification du contexte qui déclenchera la modification du déploiement de l'application. L'objectif est de continuer à assurer une qualité de service « acceptable » malgré le contexte mouvant en provoquant des reconfigurations dynamiques de l'application.
| Identifer | oai:union.ndltd.org:CCSD/oai:tel.archives-ouvertes.fr:tel-00346756 |
| Date | 27 November 2008 |
| Creators | Roose, Philippe |
| Publisher | Université de Pau et des Pays de l'Adour |
| Source Sets | CCSD theses-EN-ligne, France |
| Language | French |
| Detected Language | French |
| Type | habilitation ࠤiriger des recherches |
Page generated in 0.0034 seconds