La programmation par aspects est un paradigme de programmation qui permet de mieux séparer les préoccupations d'une application. Un aspect est défini pour chaque préoccupation qui ne peut pas être isolée dans un module. Les aspects sont ensuite ajoutés au programme de base par un processus automatique appelé tissage. Cependant, l'expressivité des langages d'aspect généraux permet de modifier totalement la sémantique du programme de base (par ex., un aspect peut remplacer certains appels de méthode par du code arbitraire). Ce comportement peut entraîner la perte des avantages (lisibilité, maintenabilité, réutilisabilité, etc.) d'une meilleure modularisation des préoccupations. Il devient impossible de raisonner sur le programme de base sans regarder le programme tissé. Cette thèse apporte une réponse aux problèmes ci-dessus en définissant des catégories d'aspects dont l'impact sur la sémantique du programme de base reste sous contrôle. Pour chaque catégorie d'aspects, nous déterminons l'ensemble des propriétés du programme de base qui est préservé par tissage. L'appartenance d'un aspect à une catégorie est garantie par construction grâce à des langages d'aspect dédiés pour chaque catégorie. L'utilisation de ces langages assure que le tissage préservera l'ensemble des propriétés associé à la catégorie concernée. Les propriétés préservées sont représentées comme des sous ensembles de LTL et de CTL*. Nous prouvons formellement que quelque soit le programme de base, le tissage de n'importe quel aspect d'une catégorie préserve les propriétés de la catégorie correspondante. Ces langages et catégories sont définis dans un cadre formel indépendant de tout langage de base ou d'aspect. L'expressivité de ce cadre est montrée en décrivant des primitives complexes de langages d'aspect comme AspectJ et CaesarJ et en effectuant une preuve de correction de transformation d'aspect.

L'utilisation d'AOP pour modéliser les préoccupations transverses ou non modulaire de CBSE assure une meilleure modularité et réutilisabilité des composants. Dans ce cadre, nous proposons une approche générique pour modéliser les aspects dans les modèles à composants. Nous modélisons un aspect par un wrapper sur une vue de système. Une vue décrit une configuration adéquate du système où tous les composants dans l'intérêt d'un aspect sont encapsulés dans le même composite. Pour la définition des vues, nous définissons un langage déclaratif VIL. Nous illustrons comment les vues sont mises en œuvre dans des modèles à composants (ex., Fractal), et nous fournissons un modèle formel pour l'analyse des interférences d'aspects. Les composants et les aspects sont modélisés par des automates et Uppaal est utilisé pour détecter les interférences. Pour la résolution d'interférences, nous fournissons un ensemble d'opérateurs de composition. Notre approche est illustrée par un exemple : l'accès wifi dans un aéroport. / Using AOP to model non-modular concerns in CBSE ensures better modularity and reusability of components. In this thesis, we provide a model independent approach for modeling aspects in component models. In the approach we model aspects as wrappers on views of component systems. A view describes an adequate component system configuration where all the components of interest of an aspect are encapsulated in the same composite.For declarative definition of views, we provide a declarative language VIL. We illustrate how views are implemented in component models(e.g., Fractal). We provide a formal framework for aspect interferences analysis. In the framework component systems and aspects are modeled as automata and Uppaal model checker is used for the detection of aspect interferences. For interferences resolution, we provide a set of composition operators as templates to be instantiated for any two arbitrary aspects. Our approach is illustrated with an airport wireless access example.

Basés sur les protocoles XML, SOAP et WSDL, les Services Web (SW) sont la technologie de base pour le développement d'Architectures Orientées Services (AOS). Ces architectures permettent de mettre en place des applications faiblement couplées avec un fort degré de configuration dynamique. Elles se basent sur la notion de relation de "services" formalisée par un contrat qui unit le client et le prestataire de services. Ce contrat est le point charnière de ce type d'applications. D'un point de vue purement marketing, les Services Web peuvent être développés pour satisfaire les besoins des clients, être facile à maintenir et aussi fournir un haut niveau de qualité de service. Les prestataires de Services Web doivent s'assurer de la fiabilité et de la disponibilité de leur infrastructure individuelle de Services Web. Cependant, les prestataires ne peuvent pas tenir compte de tous les besoins possibles des clients et des contraintes liées au développement de l'application donnée. Cela signifie que des mécanismes additionnels doivent être développés et ciblés pour un contexte d'utilisation donné. C'est exactement le type de problèmes que j'ai examiné dans mes travaux. Les développeurs d'application regardent les Services Web comme des COTS (Component Off-The Shell) et ignorent donc leurs implémentations et leurs comportements en présence de fautes. De ce point de vue, les clients ont besoin de développer des mécanismes de tolérances aux fautes spécifiques bien adaptés à leurs applications. Dans ce but, mes travaux de thèse m'ont conduit à proposer une plate-forme pour aider les clients à réaliser des connecteurs spécifiques de tolérance aux fautes (SFTC - Specifique Fault Tolerance Connectors) qui implémentent des filtres et autres techniques de détection d'erreurs (c.à.d des assertions exécutables) ainsi que des mécanismes de recouvrement qui sont déclenchés quand les Services Web ne satisfont plus les caractéristiques de sûreté demandées. De plus, le même Services Web peut être employé dans plusieurs applications orientées services avec différentes contraintes et peut donc tirer profit de plusieurs connecteurs (SFTCs). Le problème est similaire à l'utilisation des composants COTS dans les systèmes critiques de sûreté, et des travaux précédents ont déjà prouvé que des mécanismes tels que les wrappers étaient une solution possible. La différence dans le contexte des Architectures Orientées Services est que des wrappers prédéfinis ne peuvent pas être spécifiés pour satisfaire tous les besoins possibles. L'approche doit être plus adaptative pour permettre à des mécanismes de sûreté : 1) d'être définis au cas par cas pour une utilisation donnée du Service Web et 2) d'avoir une forte dynamique afin d'être modifiés selon les besoins. Ainsi, mes travaux de recherches ont permis de fournir aux développeurs d'Architectures Orientées Services: 1) un langage nommé DeWeL pour décrire les caractéristiques de sûreté de fonctionnement du connecteur et 2) l'infrastructure IWSD pour dynamiquement contrôler et exécuter les connecteurs dans des applications critiques. L'objectif final est de fournir aux développeurs d' Architectures Orientées Services une infrastructure et des outils capables de les aider à déployer des applications orientées services tolérants les fautes.