Soutenance mémoire
Cette thèse s’inscrit dans le domaine du génie logiciel et plus précisément dans celui de l’ingénierie des besoins au sein du paradigme de l’orienté aspect initié principalement par Peri L. Tarr et Gregor Kiczales dans deux projets différents [Tarr 1999] [Kiczales 2001]. Le travail que nous présentons dans cette thèse a été élaboré dans un premier temps au niveau de l’équipe ERELOG (Evolution et REutilisation des LOGiciels), du Laboratoire de Recherche en Informatique (LRI) de l’Université de Annaba et dans un deuxième temps au niveau de l’équipe MODAL (langages de MODélisation d’Architectures Logicielles) du Laboratoire d’Informatique de Nantes Atlantique (LINA) de l’Université de Nantes – France. Les logiciels actuels répondent à diverses exigences. Nous pouvons distinguer les exigences fonctionnelles, décrivant le comportement du système et définissant les fonctions que le système doit remplir et les exigences non-fonctionnelles qui expriment les contraintes imposées sur la manière de satisfaire les exigences fonctionnelles comme la performance, la sécurité, la concurrence, la synchronisation, etc.
La séparation des préoccupations : Principes et Motivations
Dans “Mythical Man-Months” [Brooks 1995] F. Brooks a écrit: “…the essential difficulties are inherent in the conceptual complexity of the software functions to be designed and built at any time, by any method…”, i.e. le logiciel a une complexité inhérente certes; cependant toute la complexité dans le développement logiciel n’est pas inhérente : la méthode que nous choisissons pour concevoir et implémenter les logiciels possède souvent sa propre complexité inhérente. Cette complexité est appelée complexité accidentelle. Comme l’apport du développement de logiciel orienté aspect (Aspect Oriented Software Development, AOSD) consiste à faire promouvoir le raisonnement modulaire et la composition, il est essentiel d’éliminer les éléments de complexité accidentelle dans ces méthodes.
Durant la phase de conception, la plupart des approches se concentrent sur l’élaboration d’une conception orientée objet, c’est-à-dire, la décomposition du système en un ensemble d’objets, où chacun fournit une partie bien définie de la fonctionnalité principale du système. Par conséquent, les fonctionnalités secondaires (e.g. la sécurité, performance, …) sont souvent mal encapsulées. Ce phénomène est considéré par Ossher et Tarr [Ossher 2001] comme la tyrannie de la décomposition dominante “… the tyranny of the dominant decomposition is the single most significant cause of the failure, to date, to achieve many of the expected benefits of separation of concerns”. L’orienté aspect est une voie prometteuse pour contourner ce phénomène inhérent à la décomposition. Le développement de logiciels orientés aspect est initialement apparu comme une technique d’implémentation et récemment devenu un sujet de recherche très abordé dans d’autres disciplines du développement de logiciels. Particulièrement, un grand intérêt pour l’approche orientée aspect a émergé dans le domaine de l’ingénierie des besoins (Requirement Engineering, RE). L’AOSD est principalement fondée sur le concept de séparation des préoccupations (Separation of Concerns, SoC). La séparation des préoccupations est considérée depuis longtemps comme l’une des approches les plus prometteuses du génie logiciel. Selon cette approche, un programme écrit avec la technologie objet contient deux parties principales :
• Une partie fonctionnelle qui implémente les services pour lesquels les objets ont été créés ; c’est la préoccupation principale du programme appelée parfois le code de base.
• Une partie qui adapte les objets du code de base à un environnement et/ou à une application particulière. Cette partie regroupe des préoccupations secondaires parfois complexes et disséminées dans tout le code source de l’application.
La séparation de ces deux parties permet d’une part, de réduire le travail et l’expertise demandés au programmeur de l’objet, et d’autre part, de mieux réutiliser la partie fonctionnelle des objets dans d’autres environnements et d’autres applications. Pour cela, l’objet ne doit contenir que sa partie fonctionnelle et son adaptation doit être effectuée à l’extérieur de l’objet. Après cette brève introduction au principe de la séparation des préoccupations, nous considérons dans la suite de ce chapitre les motivations de cette séparation en tant que technique de programmation puis nous mettons en évidence les insuffisances de l’approche orientée objet. Dans la quatrième section, nous présentons le concept préoccupation transversale (crosscutting concern) que l’approche objet n’offre pas de moyens pour l’encapsuler. Dans la cinquième section, nous explicitons les principaux problèmes engendrés par les préoccupations transversales. Pour terminer, nous abordons dans la sixième section l’ensemble des travaux actuellement menés autour de la notion d’aspect.
La séparation des préoccupations
Nous sommes de plus en plus confrontés à des systèmes logiciels extrêmement complexes. Nous avons intérêt à gérer cette complexité, d’une façon ou d’une autre, pour faire face aux contraintes d’adaptabilité, d’évolution et de réutilisation. Plutôt que d’attaquer le développement d’une application de front, les concepts d’abstraction et de modularisation permettent de raisonner sur un problème donné sans se préoccuper de sa solution entière ou encore moins de la connaître dans sa globalité. Cette abstraction permet ainsi l’identification de plusieurs problèmes récurrents et concrets qui peuvent apparaître dans divers contextes semblables [Pawlak 2000]. La conception des systèmes logiciels consiste alors à décomposer un problème donné en sous-problèmes (de petites unités ou modules) qui sont traités séparément les uns des autres . Le système final est ensuite construit par l’implémentation des différents modules conceptuels et leur composition. La programmation de ces unités permet de réduire la complexité du problème à implémenter, augmentant, entre autre, la flexibilité et facilitant aussi la compréhension du système [Parnas 1972].
C’est l’approche désormais classique de modularisation évoquée depuis les années 1970 par R. Gauthier [Gauthier 1970] qui a été adoptée par l’ensemble des approches de développement traditionnelles (procédurale, fonctionnelle et objet). Aujourd’hui, toutes ces approches visent à appliquer le principe de séparation des préoccupations dans leur processus de développement [Dijkstra 1976, Hursh 1995]. Une préoccupation est un concept, un but particulier ou une unité d’intérêt. Un système typique admet principalement deux types de préoccupations : fonctionnelles et non-fonctionnelles. Par exemple, l’abstraction d’une carte de crédit admet une préoccupation fonctionnelle concevant le processus de payement et des préoccupations systémiques assurant la gestion de la connexion, l’authentification, l’intégrité de la transaction de paiement, la sécurité, etc.
En adoptant l’idée classique de l’approche de modularisation, le principe de séparation des préoccupations consiste à identifier séparément l’ensemble des préoccupations d’un système logiciel et à les adresser d’une façon relativement indépendante, aussi bien à la phase de conception qu’à la phase d’implémentation. Ce principe est reconnu essentiel au développement des logiciels : il améliore la lisibilité et la flexibilité du système permettant ainsi l’évolution, l’adaptation et la réutilisation de toute ou une partie de l’application [Amirat 2005b].
Les préoccupations transversales
Pour illustrer les préoccupations transversales, considérons l’exemple d’une librairie électronique dont la réalisation nécessite, en plus des services attendus, la prise en compte de différentes propriétés non-fonctionnelles affectant l’application dans sa globalité. Dans cette application, les clients utilisent un réseau pour consulter la liste des ouvrages disponibles et éventuellement les commander. Plusieurs clients peuvent être connectés en même temps et plusieurs commandes peuvent être traitées en parallèle.
La conception objet de cette application conduit à définir notamment les classes : Librairie, Client, Ouvrage, Commande, Banque et CarteDeCredit qui représentent les entités du domaine d’application, fournissant les services de base de l’application (e.g. la consultation d’un ouvrage ou la passation d’une commande). Par ailleurs, nous pouvons identifier au moins trois propriétés non fonctionnelles différentes correspondant à des propriétés non-fonctionnelles de cette application : la distribution, la persistance et la synchronisation.
• La distribution apparaît du fait que les instances des différentes classes mises en jeu se trouvent sur des sites distants. Cette propriété non fonctionnelle regroupe entre autre la gestion des communications de site à site et la définition du protocole de communication utilisé.
• La persistance se justifie parce que des objets comme, par exemple, les ouvrages mis en vente, doivent persister à un arrêt de l’application. La sauvegarde de tels objets sur un support de masse et la gestion des mises à jour de cette sauvegarde font partie de la définition de cette propriété non fonctionnelle, quelle que soit la technique de persistance utilisée.
• La synchronisation est mise en évidence, notamment, par le besoin de synchroniser les accès concurrents aux structures des objets. C’est le cas, par exemple, lorsqu’un client demande le prix d’un ouvrage pendant que le libraire modifie ce même prix. Cette propriété non fonctionnelle englobe la gestion de tels accès concurrents.
Nous remarquons ici, que ces trois propriétés non fonctionnelles sont en interaction avec l’ensemble des objets mis en jeu dans l’application, et qu’elles sont transversales à l’ensemble des classes définissant cette application. D’une façon générale, ce phénomène de recoupement des préoccupations (propriétés transversales) est connu sous le nom de crosscutting.
Les problèmes du crosscutting
Une utilisation classique de l’approche orientée objet pour traiter ce phénomène de crosscutting, impose de mêler le code des préoccupations transversales au code des classes définissant l’application. De tels enchevêtrements introduisent des problèmes récurrents, qui compromettent la réutilisation des implantations de l’ensemble des unités fonctionnelles ainsi que celles des propriétés transversales de l’application, indépendamment les unes des autres [Hursh 1995, Kiczales 1997]. Nous distinguons principalement deux problèmes induits par l’approche orientée objet :
• L’enchevêtrement du code (Code Tangling)
L’approche orientée objet conduit à l’enchevêtrement du code source correspondant aux services de base de l’application, traités par les différentes classes, avec celui correspondant aux différentes propriétés transversales.
• La dispersion du code (Code Scattering)
L’approche orientée objet conduit à la dispersion du code correspondant à chacune des propriétés transversales dans la description des différentes classes concernées par ces propriétés.
Combinés ensemble, ces deux problèmes récurrents contrarient le principe de séparation des préoccupations et affectent ainsi, la conception et l’implantation de l’application de plusieurs façons. Dans ce qui suit, nous illustrons tout d’abord ces deux problèmes et nous détaillons ensuite leurs implications.
|
Table des matières
Introduction
Contexte de recherche
Problématique
Motivations et Objectifs
Organisation du document
Chapitre 1 La séparation des préoccupations : principes et motivations
1.1. Introduction
1.2. La séparation des préoccupations
1.3. L’approche objet
1.4. Les préoccupations transversales
1.5. Les problèmes du crosscutting
1.5.1. Dispersion du code
1.5.2. Enchevêtrement du code
1.5.3. Conséquences
1.6. Approches pour séparation des préoccupations
1.6.1. La programmation orientée aspects (PAO)
1.6.2. La composition de filtres (CF)
1.6.2.1. Concepts de bases
1.6.2.2. Fonctionnement des filtres
1.6.3. La séparation multidimensionnelle des préoccupations (MDSOC)
1.7. Conclusion
Chapitre 2 Mise en Œuvre des Approches de Séparation des Préoccupations
2.1. Introduction
2.2. AspectJ
2.2.1. Les concepts de base d’AspectJ
2.2.1.1. Les points de jointure (Join Point)
2.2.1.2. Les points de coupe (Pointcut)
2.2.1.3. Les consignes (Advice)
2.2.1.4. Les Introductions
2.2.2. L’héritage d’aspect
2.2.3. La recomposition dans AspectJ
2.2.4. La représentation UML des aspects
2.3. Les Filtres de Composition
2.3.1. Implémentations du CF-modèle
2.3.2. Types de Filtres
2.4. HyperJ – Concepts de bases
2.5. Modèle de transformation entre langages orientés aspect
2.6. Conclusion
Chapitre 3 Ingénierie des Besoins Orientée Aspect
3.1. Introduction
3.2. Définitions
3.2.1. Besoins (Requirement)
3.2.1. Préoccupation (Concern)
3.3. Approches non orientées aspects
3.3.1. Approches orientées point de vue (PREview)
3.3.1.1. Méthode PREview
3.3.2. Approches orientées but (Goal)
3.3.2.1. NFR Framework (NFRF)
3.3.2.2. KAOS (Knowledge Acquisition in Automated Specification)
3.3.2.3. i* Framework / Méthodologie Tropos
3.3.2.4. Conclusion
3.3.3. Approche orientée Problem Frames (PF)
3.3.4. Approches basées cas d’utilisation (Use Cases)
3.3.4.1. Mécanisme de séparation des cas d’utilisation
3.3.4.2. Mécanisme de composition des cas d’utilisation
3.3.5. Conclusion
3.4. Approches Orientées Aspect
3.4.1. Approches orientées aspect basées point de vue (AORE)
3.4.2. Approches orientées aspect basées but
3.4.2.1. Approche ARGM (Aspects in Requirements Goal Models)
3.4.3. Approche orientée aspect basée cas d’utilisation
3.4.3.1. Approche AOSD/UC
3.4.4. Approches orientées MDSC
3.4.4.1. Méthode CORE (Concern-Oriented Requirements Engineering)
3.4.5. Approche orientée aspect basée composant
3.4.5.1. Approche AOREC (AORE for CBSD)
3.4.6. Approche Theme/Doc
3.5. Comparaison
3.6. Langages d’expressions des besoins
3.7. Conclusion
Conclusion
