Soutenance mémoire
De nos jours le logiciel est touché par des changements fréquents pour qu’il puisse réagir avec ces nouveaux besoins. Le processus d’extension et d’adaptation continue est connu sous le nom «l’évolution du logiciel». Le problème principal des systèmes logiciels est que le logiciel est soumis de façon continue à l’évolution ou au changement. L’évolution du logiciel est menée par plusieurs facteurs, y compris le changement des besoins, technologies, plates-formes et la maintenance corrective et perfective (changements pour supprimer des bogues et améliorer des fonctionnalités). La compréhension, le changement, la correction, et l’adaptation des systèmes logiciels sont des activités essentielles pendant le développement du logiciel. Donc, la recherche sur le génie logiciel doit fournir des méthodes et des outils pour supporter ces différentes tâches d’évolution du logiciel.
Par conséquent, l’évolution des systèmes logiciels est devenue une matière vitale dans l’industrie du logiciel. Le terme évolution du logiciel a paru premièrement dans la littérature du génie logiciel en 1970s par une étude menée par Lehman et al. [LEH76]. Dans cette étude les auteurs ont mesuré la complexité, la taille, le coût et la maintenance de 20 versions du système d’exploitation OS/360, basé sur son code source. Toutes les 20 versions de ce système logiciel ont montré une tendance croissante dans toutes les mesures. Cette étude a montré que l’évolution des systèmes logiciels est une opération très importante et très coûteuse [ERL00].
Donc, puisque le développement de logiciel doit traiter de plus en plus la compréhension et la modification des systèmes hérités (legacy systems), qui ont évolué avec le temps, au lieu de reproduire de nouveaux systèmes logiciels à partir de zéro. La plupart des projets logiciels essaient de garder l’infrastructure et la modifier pour satisfaire de nouveaux besoins. En résultat, un montant énorme du code doit être maintenu et actualisé chaque année. Les études sur l’effort de développement de logiciel prouvent que la portion dépensée pour l’évolution du logiciel a augmenté dramatiquement de 49% en 1977 [LIE96] à plus que 90% en 1995 [AKS92, REE95].
L’Evolution des Logiciels Orientés Aspects: Challenges et Approches
“Given that AOP has set out to modularize crosscutting concerns (its methodological claim), but by its very nature (its mechanics) breaks modularity….” Friedrich Steimann, 2006 [STE06] .
Depuis 1997, la POA provoque l’engouement de la communauté scientifique s’intéressant au génie logiciel. Cette technique offre des nouvelles perspectives à la séparation avancée des préoccupations. Le but principal de ce nouveau paradigme est d’améliorer la séparation des préoccupations lors du développement de logiciel. On cherche à isoler chaque problématique pour pouvoir la coder séparément, et définir les règles d’intégration afin de les combiner pour pouvoir former un système final.
La séparation des préoccupations est bonne théoriquement. Quand nous utilisons la POA, nous obtenons beaucoup d’avantages, mais nous devons aussi traiter leurs problèmes. Si on modifie un logiciel OA pour le faire évoluer ou si on transforme un système existant en un système OA, nous serons confrontés aux problèmes évolutionnaires. Nous allons découvrir ce paradigme de programmation dans ce chapitre, son principe, ses bénéfices…etc. Ainsi que le langage AspectJ, qui est le langage le plus populaire parmi les langages OA. D’un autre côté, nous discuterons les différents challenges de l’évolution du logiciel OA, et nous présentons brièvement les travaux existants dans cette zone de recherche.
La Séparation des Préoccupations
La séparation des préoccupations (Separation of Concerns) [LOP95, PAR72] est un principe commun, largement utilisé dans le génie logiciel. Elle est considérée comme l’une des approches les plus prometteuses du génie logiciel. Elle suggère qu’un problème complexe doit être divisé en une série de plus petits problèmes qui sont moins complexes et plus facile à comprendre. Ces plus petits problèmes peuvent être résolus séparément, et finalement ils peuvent être intégrés ensemble pour résoudre le grand problème. Le développement du logiciel avec cette manière offre une plus grande compréhensibilité, maintenabilité, adaptabilité, et réutilisabilité aux programmes. Puisque les problèmes sont réduits en des unités dont la taille est perceptible par les esprits humains, et cela peut être généralisé pour adapter à plusieurs besoins.
Au niveau du logiciel, chaque unité représente ou implémente une préoccupation du système. La définition communément utilisée d’une préoccupation à partir de l’IEEE 1471: Une préoccupation est un intérêt qui a rapport au développement du système, son opération ou tout autre aspect qui est critique ou autrement important à un ou plusieurs utilisateurs .
Depuis une trentaine d’années, l’approche orientée objet a procuré des bénéfices au niveau de la séparation des préoccupations. En effet, elle permet de modulariser de larges systèmes d’une manière intuitive, car elle offre un modèle de programmation riche très proche du monde réel. Elle représente des objets individuels dans un modèle du domaine du problème. Aujourd’hui, l’orienté objet bénéficie d’un excellent background notamment grâce à la popularisation d’UML. En plus, une multitude de langages de programmation (Java, C++, Smalltalk, …) ont adopté ce paradigme de manière native. Cependant, l’approche orientée objet montre ses limites et échoue face à la modularisation des préoccupations transversales (crosscutting concerns) au système. Parmi les préoccupations transversales les plus courantes, on trouve la sécurité, la gestion transactionnelle de la persistance, la synchronisation, le logging…etc. Le domaine de recherche qui est survenu pour traiter ce problème était connu par la séparation avancée des préoccupations.
La Séparation Avancée des Préoccupations
Cet axe de recherche prend en charge les préoccupations transversales du système. Ces dernières sont les fonctionnalités dites non métiers. Un développeur est souvent confronté à ce genre de fonctionnalités lorsqu’il développe une application de grande taille. Dans ce cas, même si on applique une bonne modularisation verticale des préoccupations métiers (avec un langage orienté objet), on aura toujours un problème de préoccupations horizontales qui transverses l’ensemble des modules métiers. Ces préoccupations transversales ne peuvent pas être modularisées dans la décomposition sélectionnée.
Il existe en fait deux principaux symptômes liés aux préoccupations transversales: (1) ces préoccupations ont la particularité d’un côté, d’être dispersées à travers plusieurs modules, (2) et d’un autre côté, d’être enchevêtrées avec les modules métiers du système.
Enchevêtrement du code (code tangling): L’enchevêtrement du code est provoqué quand un module est implémenté pour traiter plusieurs préoccupations en même temps. Un développeur a souvent affaire, pendant qu’il développe un module, à des préoccupations telles que la logique métier, la gestion transactionnelle de la persistance, le logging, la sécurité…etc. Cela conduit à la présence simultanée d’éléments issus de chaque préoccupation, et il en résulte en un enchevêtrement du code .
Éparpillement du code (code scattering): L’éparpillement du code survient quand une préoccupation est implémentée dans plusieurs modules. Les préoccupations transversales sont, par définition, dispersées à travers plusieurs modules. Par exemple, dans un système utilisant une base de données, le logging est une préoccupation implémentée dans tous les modules qui accèdent à la base de données .
Ces deux phénomènes dégradent considérablement le maintien, la compréhension et l’évolutivité du code. Plusieurs approches ont été proposées pour traiter la séparation avancée des préoccupations [OSS99], tel que la programmation orientée aspect (Aspect Oriented Programming) [KIC97], la programmation flexible (Adaptive Programming) [LIE96], la composition des filtres (Composition Filters) [AKS92], la modélisation de rôle (Role Modeling) [REE95], et la programmation orienté sujet (Subject Oriented Programming) [HAR93]. Nous nous intéressons dans cette thèse à la programmation orientée aspect (POA) qui est une solution efficace de la séparation avancée des préoccupations.
La Programmation Orientée Aspect
La POA permet de modulariser le code en fournissant des mécanismes explicites pour capturer la structure des préoccupations transversales dans les systèmes logiciels, telle que le traitement des exceptions, la synchronisation, les optimisations de la performance, et le partage de ressource. Cela est habituellement difficile à exprimer proprement dans le code source par les techniques de programmation existantes (ex. orientée objet). Les langages OA peuvent contrôler un tel code enchevêtré et éparpillé pour rendre les préoccupations transversales plus apparentes. En effet, l’orienté aspect procure une solution élégante aux problèmes d’enchevêtrement et d’éparpillement du code. Cette technique d’ingénierie du logiciel offre une nouvelle dimension pour la modularisation avec la notion d’«Aspect». Par conséquent, parallèlement aux classes qui sont un support idéal pour modulariser les préoccupations métiers du système, les aspects sont un support pour capturer les préoccupations transversales, où chaque aspect se concentre sur une fonctionnalité transversale spécifique. Par exemple, une préoccupation de logging peut être séparée d’un programme de base en spécifiant tous les points du programme qui doivent être enregistrés. Si l’architecture de logging devrait être changée, par exemple en utilisant un Framework plus sophistiqué à la place des appels println, tous les changements sont localisés dans l’aspect logging.
Dans une démarche OA, les préoccupations transversales peuvent évoluer indépendamment des préoccupations métier et vice-versa. Et afin que l’application finale prennent en compte toutes les préoccupations, le système passe par une étape dite de tissage d’aspects (Aspect weaving). Durant cette étape , les préoccupations transversales encapsulées dans les aspects vont être tissées ou intégrées dans les préoccupations métiers. Par conséquent, la POA aide pour créer des applications qui sont plus faciles à concevoir, à implémenter et à maintenir.
|
Table des matières
1. Introduction Générale
1.1 Contexte de Recherche
1.2 Problématique et Motivations
1.3 Objectifs et Contributions
1.4 Plan de la Thèse
2. L’Evolution des Logiciels Orientés Aspects: Challenges et Approches
2.1 La Séparation des Préoccupations
2.2 La Séparation Avancée des Préoccupations
2.3 La Programmation Orientée Aspect
2.3.1 Les Bénéfices de la POA
2.3.2 Les Différentes Applications de la POA
2.4 Le Langage AspectJ
2.4.1 Concepts Transversaux Dynamiques
2.4.2 Concept Transversal Statique (Introduction)
2.4.3 Aspects
2.5 Les Challenges de l’Evolution du Logiciel Orienté Aspect
2.5.1 La Quantification & l’Inconscience
2.5.2 Les Défis de l’Evolution
2.5.3 Des Etudes Empiriques
2.6 Les Approches supportant l’Evolution du Logiciel OA
2.6.1 L’analyse du Flux de Contrôle et du Flux de Données
2.6.2 L’Analyse de l’Impact du Changement
2.6.3 Le Test du Logiciel OA
2.6.4 Résoudre le Problème de la Fragilité des Points de Coupure
2.7 Bilan
3. L’Analyse de l’Evolution du Logiciel Orienté Aspect
3.1 La Gestion de la Configuration Logicielle
3.2 Les Systèmes de Contrôle de Versions
3.2.1 Les Approches de Versioning
3.2.2 Le Principe des SCVs
3.2.3 Les Types des SCVs
3.3 L’Analyse de l’Historique de l’Evolution
3.3.1 Le Principe Générale
3.3.2 Les Approches d’Analyse de l’Evolution
3.3.3 L’analyse de l’Evolution des Logiciels OA
3.4 La POA Versus les SCVs Actuels
3.4.1 Les Limites des SCVs Actuels
3.4.2 L’Evolution du Logiciel OA et les Dépôts de Version Actuels
3.5 Bilan
4. Vers un Framework d’Evolution du Logiciel Orienté Aspect basé sur la Transformation de Graphes
4.1 La Transformation Algébrique de Graphes
4.1.1 Les Grammaires de Graphes
4.1.2 Graphe coloré attribué et Graphe Type
4.1.3 La Réécriture de Graphes
4.1.4 Les Conditions d’Application des Règles de Réécriture
4.1.5 Les Approches de la Transformation de Graphes
4.1.6 Les Outils de la Transformation de Graphes
4.2 La Transformation de Graphes comme Support de l’Evolution
4.2.1 Les Bénéfices d’une Fondation Formelle
4.2.2 Le Logiciel Vu Comme un Graphe
4.2.3 L’Evolution basée sur la Transformation de Graphes
4.3 Notre Framework d’Evolution du Logiciel Orienté Aspect
4.3.1 L’Idée de Base
4.3.2 Présentation Globale du Framework d’Evolution
4.4 Bilan
5. La Modélisation de l’Evolution des Logiciels Orientés Aspect
5.1 La Modélisation du Programme
5.1.1 Le Sous-Graphe du Code de Base
5.1.2 Le Sous-Graphe d’Aspect
5.1.3 La Modélisation du Système Globale
5.1.4 Discussion
5.2 La Modélisation du Changement
5.2.1 La Formalisation des Opérations d’Evolution
5.2.2 Les Opérations d’Evolution comme des Règles de Réécriture
5.3 Mise en Œuvre du Modèle d’Evolution Proposé
5.3.1 Présentation globale de l’outil
5.3.2 Expérimentations
5.4 Bilan
6. Conclusion Générale
