Soutenance mémoire
La programmation orientée objet est le paradigme de choix pour plusieurs projets logiciels. Elle est particulièrement efficace dans l’expression des fonctionnalités dites verticales, fonctionnalités exprimant les préoccupations métiers du système. Cependant, elle s’avère limitée dans le cas de l’existence des fonctionnalités qui sont enchevêtrées ou dispersées dans différents endroits d’une application, et qui ne bénéficient pas d’une encapsulation adéquate, tant au niveau des modèles de conception que des langages de programmation. Ces fonctionnalités sont dites transversales. Le fait d’être enchevêtrées ou dispersées rend complexe la compréhension du code source, la maintenance, l’évolution et la réutilisation du système logiciel.
Pour remédier aux insuffisances du paradigme orienté objet, plusieurs approches de la séparation avancée des préoccupations ont vu le jour, telle que la programmation orientée aspect. Cette dernière vise à améliorer l’évolution et la lisibilité des systèmes logiciels, en encapsulant chacune des préoccupations, indépendamment les unes des autres et de tout objet métier, ce qui simplifie le travail du programmeur et permet la réutilisation du code existant. Afin de bénéficier des avantages du paradigme orienté aspect, nous avons besoin d’identifier d’abord les préoccupations transversales, ensuite les transformer en aspects.
Le processus d’identification des préoccupations transversales vise la découverte des préoccupations entrecoupant les classes d’un système logiciel. Trois applications ont motivé l’émergence du domaine d’identification d’aspects: la maintenance des systèmes logiciels orientés objet déjà implémentés (legacy systems), la migration des systèmes logiciels orientés objet vers le paradigme aspect, et le développement orienté aspect.
La maintenance :
La loi d’entropie du logiciel, formulée par Belady et Lehman [Bel 76], nous apprend qu’avec le temps, la plupart des systèmes logiciels ont tendance à se dégrader progressivement dans la qualité, sauf s’ils sont maintenus. Toutes les études en génie logiciel ont montré que la maintenance et l’évolution sont les phases les plus longues et les plus coûteuses dans le cycle de vie du logiciel [Mas 03, Hil 07]. Cela est dû au besoin de satisfaire les nouvelles exigences des utilisateurs (telles que celles commerciales et technologiques), ou de modifier celles existantes, afin d’éviter la dégradation de l’efficacité du logiciel. Pour ces raisons, la maintenance logicielle a fait l’objet de beaucoup d’attention ces dernières années. Son utilisation permet d’apporter des modifications aux systèmes logiciels déjà implémentés. Mais auparavant, il convient de comprendre ces systèmes. La dispersion et l’enchevêtrement de certaines préoccupations rendent la compréhension difficile. Le programmeur passe plus de 50% de son temps à essayer de comprendre le programme [Won 95]. A cet effet, nous avons besoin d’identifier et d’extraire au préalable ces préoccupations transversales.
La migration :
Afin de bénéficier de la décomposition offerte par le paradigme orienté aspect, il est nécessaire de migrer les systèmes logiciels orientés objet existants (legacy systems) vers une solution orientée aspect. C’est ce qu’on appelle la migration orientée aspect des systèmes orientés objet [Cec 07]. Cette migration suppose l’extraction des préoccupations transversales, afin de pouvoir ensuite les refactoriser dans des aspects [Deu 03].
Le développement orienté aspect :
Les intervenants peuvent décrire leur système en termes d’exigences, dont chacune peut concerner une ou plusieurs préoccupations. Celles-ci s’enchevêtrent et se dispersent sur les exigences, impliquant l’émergence de préoccupations transversales. Afin de bénéficier d’un développement orienté aspect, il est nécessaire d’extraire et de gérer ces préoccupations transversales durant les phases du cycle de développement du logiciel [Ban 06, Mor 11] (avant la phase de l’implémentation), au niveau exigences, architecture ou conception. Cela permet d’obtenir une implémentation orientée aspect.
CONCEPT DE PRÉOCCUPATION ET PROGRAMMATION ORIENTÉE ASPECT
L’existence des préoccupations enchevêtrées ou dispersées, à travers les classes fonctionnelles du code source orienté objet, et qui ne peuvent pas avoir une encapsulation propre dans le paradigme objet, rend difficile la compréhension du code source objet, sa maintenance, son évolution et sa réutilisation. La programmation orientée aspect a émergé pour supporter la modularité améliorée des systèmes logiciels, en séparant mieux les préoccupations.
Notion de préoccupation
Sutton et Rouvellou définissent les préoccupations (concerns) comme l’ensemble des questions d’intérêt dans un système logiciel [Sut 02]. Une préoccupation peut être directement liée au système ou son environnement [Bus 08]. Elle est définie dans le processus d’ingénierie [Fil 05] comme étant un concept générique décrivant une entité homogène composant le logiciel. Un programme écrit avec la technologie objet [Mad 86] contient deux parties principales.
➤ Une partie fonctionnelle qui implémente les services pour lesquels l’objet a été écrit; c’est la préoccupation principale de l’objet (préoccupation fonctionnelle). la couleur verte présente les préoccupations fonctionnelles (logique métier).
➤ Une autre partie qui adapte l’objet à un environnement et/ou à une application particulière. Cette partie regroupe des préoccupations secondaires, parfois complexes et dispersées dans tout le code source de l’application (préoccupation non fonctionnelle) [Hür 95].
Si on prend l’exemple du paiement par carte de crédit [Poa 11], la préoccupation fonctionnelle est : « Effectuer des paiements » (débiter un montant d’un compte défini). Parmi les préoccupations non fonctionnelles, on trouve: « Traçage », « Intégrité de la transaction », « Identification/Authentification », « Sécurité » et « Performances ».
Caractéristiques d’une préoccupation
Une préoccupation transversale est caractérisée par deux propriétés, qui sont l’enchevêtrement et la dispersion [Ber 05a].
Enchevêtrement (Tangling)
La programmation orientée objet (POO) sépare les données et les traitements associés dans des classes. Ces dernières peuvent être corrélées. C’est typiquement le cas des contraintes d’intégrité référentielle. Par exemple, un objet client ne doit pas être supprimé tant qu’une commande pour ce client n’est pas prise en compte, sinon on risque de perdre les coordonnées du client [Paw 04]. La classe client n’est pas le meilleur lieu pour l’implémentation de la contrainte d’intégrité référentielle empêchant la suppression d’un client n’ayant pas toutes ses factures traitées, car la vérification d’une commande non traitée n’appartient pas à la logique de gestion d’un client. Si on modifie la classe client pour tenir compte des contraintes d’intégrité introduites par les autres classes de l’application, elle sera dépendante et, par conséquent, non réutilisable d’une manière indépendante. Même la classe commande n’est pas davantage adaptée à l’implémentation de cette fonctionnalité : si on cherche à supprimer un client, il n’y a aucune raison pour que la classe commande permette de le faire. Finalement, ni la classe client ni la classe commande ne sont adaptées à l’implémentation de la contrainte d’intégrité référentielle. Cette contrainte est enchevêtrée dans ces deux classes.
Alors que le découpage des données en classes a pour but de rendre les classes indépendantes entre elles, on constate que des fonctionnalités enchevêtrées, telles que les contraintes d’intégrité référentielle, viennent se superposer à ce découpage et brisent l’indépendance des classes. La POO ne fournit aucune solution pour proprement prendre en compte ces fonctionnalités enchevêtrées [Paw 04]. L’enchevêtrement se produit quand deux ou plusieurs fonctionnalités sont contenues dans une même autre fonctionnalité (au niveau implémentation, deux ou plusieurs préoccupations différentes seront mises en œuvre dans le même corps du code d’un module, ce qui le rend plus difficile à comprendre).
Dispersion (Scattering)
En POO, le mécanisme principal d’interaction entre objets est l’invocation de méthodes. Un objet qui souhaite effectuer un traitement invoque une méthode d’un autre objet. Un objet peut aussi invoquer une de ses propres méthodes. Dans tous les cas, il existe un rôle d’invocateur et un rôle d’invoqué [Paw 04]. Dans l’invocation d’une méthode, il suffit que les paramètres transmis par l’invocateur soient conformes à la signature de cette méthode, pour que l’invoqué prenne en charge la demande. L’implémentation d’une méthode en POO est localisée dans une classe. La modification d’une méthode est une opération simple : il suffit de modifier le seul fichier qui contient la classe dans laquelle est définie la méthode. Lorsque la modification porte sur le code de la méthode, elle devient transparente pour tous les objets qui invoquent cette méthode. La modification de la signature de la méthode nécessite de modifier toutes les classes qui invoquent cette méthode. Ces modifications deviennent plus coûteuses si la méthode est d’usage courant. Par conséquent, en POO, l’implémentation d’une méthode est localisée dans une classe, tandis que son invocation, ou utilisation, est dispersée. Ce phénomène de dispersion du code est un frein à la maintenance et l’évolution des applications orientées objets. Toute modification dans la manière d’utiliser un service entraîne des modifications nombreuses, coûteuses et sujettes à erreur [Paw 04].
|
Table des matières
CHAPITRE 1 INTRODUCTION
1.1 CONTEXTE DE RECHERCHE
1.2 PROBLÉMATIQUE
1.3 MOTIVATIONS
1.4 OBJECTIFS
1.5 CONTENU DE LA THÈSE
CHAPITRE 2 CONCEPT DE PRÉOCCUPATION ET PROGRAMMATION ORIENTÉE ASPECT
2.1 INTRODUCTION
2.2 NOTION DE PRÉOCCUPATION
2.3 CARACTÉRISTIQUES D’UNE PRÉOCCUPATION
2.3.1 Enchevêtrement (Tangling)
2.3.2 Dispersion (Scattering)
2.4 SÉPARATION DES PRÉOCCUPATIONS
2.5 PROGRAMMATION ORIENTÉE ASPECT
2.5.1 Principe
2.5.2 Concepts de base
2.5.2.1 Aspect
2.5.2.2 Point de jonction
2.5.2.3 Point de coupure
2.5.2.4 Consigne (code advice)
2.5.2.5 Mécanisme d’introduction
2.5.3 Langage orienté aspect : AspectJ
2.6 QUELQUES MÉTRIQUES ORIENTÉES PRÉOCCUPATION
2.6.1 CONT et LOCC
2.6.2 Diffusion
2.6.3 LCOO
2.6.4 Couplage
2.7 CONCLUSION
CHAPITRE 3 IDENTIFICATION D’ASPECTS À PARTIR DU CODE SOURCE ORIENTÉ OBJET : ÉTUDE COMPARATIVE DES APPROCHES
3.1 INTRODUCTION
3.2 DÉFINITIONS DE LA TRANSVERSALITÉ
3.2.1 Définition basée sur la projection
3.2.2 Définition basée sur la décomposition
3.3 PROBLÈMES POSÉS PAR LA TRANSVERSALITÉ
3.4 NAVIGATEURS DÉDIÉS
3.4.1 Concern Graphs
3.4.2 Aspect Browser
3.4.3 Aspect Mining Tool
3.4.4 Prism
3.5 APPROCHES D’IDENTIFICATION D’ASPECTS
3.5.1 Analyse formelle des concepts (FCA)
3.5.2 Clustering
3.5.3 Fan-in
3.5.4 Modèle récurrent
3.5.5 Détection de clones
3.5.6 Transversalité statique et dynamique
3.5.7 Arbre d’appels et traces
3.5.8 Rétro-ingénierie d’UML
3.6 DISCUSSIONS DES APPROCHES
3.7 CONCLUSION
CHAPITRE 4 IDENTIFICATION D’ASPECTS DURANT LES PHASES DU DÉVELOPPEMENT DE LOGICIEL: ÉTUDE COMPARATIVE DES APPROCHES
4.1 INTRODUCTION
4.2 DÉFINITIONS DE LA TRANSVERSALITÉ
4.2.1 Définition basée sur les exigences
4.2.2 Définition basée sur le domaine source et cible
4.3 SYNTHÈSE SUR LES DÉFINITIONS DE LA TRANSVERSALITÉ
4.4 APPROCHES D’IDENTIFICATION D’ASPECTS À PARTIR DES EXIGENCES
4.4.1 Approches orientées points de vue
4.4.1.1 Approches non orientées aspects
4.4.1.2 Approche orientée aspects (Arcade)
4.4.2 Approches orientée buts
4.4.2.1 Approches non orientées aspects
4.4.2.2 Approche orientée aspects (AOV-graph)
4.4.3 Approches orientées cas d’utilisation
4.4.4 Approches basées composants (AOREC)
4.4.5 Séparation multidimensionnelle des préoccupations (Cosmos)
4.4.6 Ea-Miner
4.4.7 Theme/Doc
4.4.8 HASoCC
4.4.9 Clustering (ACE)
4.4.10 Réseau de Petri
4.5 APPROCHES D’IDENTIFICATION D’ASPECTS AU NIVEAU ARCHITECTURE
4.5.1 DAOP-ADL
4.5.2 AOGA
4.5.3 ASAAM
4.6 APPROCHES D’IDENTIFICATION D’ASPECTS AU NIVEAU CONCEPTION
4.7 DISCUSSION DES APPROCHES
4.8 CONCLUSION
CHAPITRE 5 CONCLUSION
