Programmation orientée aspect

Pour les articles homonymes, voir POA et AOP.

La programmation orientée aspect ou POA (en anglais, aspect oriented programming ou AOP) est un paradigme de programmation qui permet de traiter séparément les préoccupations transversales (en anglais, cross-cutting concerns), qui relèvent souvent de la technique, des préoccupations métier, qui constituent le cœur d'une application^{[1],[trad 1],[trad 2]}. Un exemple classique d'utilisation est la journalisation, mais certains principes architecturaux ou modèles de conception peuvent être implémentés à l'aide de ce paradigme de programmation, comme l'inversion de contrôle^{[trad 3]}.

La programmation orientée aspect est bien une technique transversale (paradigme) et n'est pas liée à un langage de programmation en particulier mais peut être mise en œuvre aussi bien avec un langage orienté objet comme Python qu'avec un langage procédural comme le C, le seul prérequis étant l'existence d'un tisseur d'aspect pour le langage cible (cf. § Tisseurs d'aspects).

Les concepts de la programmation orientée aspect ont été formulés par Gregor Kiczales et son équipe, qui travaillaient alors pour le Xerox PARC.

Le paradigme est breveté par eux-mêmes aux États-Unis en 1999^[2].

Les techniques actuelles de conception logicielles et de programmation amènent à découper un logiciel en modules logiciels a priori indépendants les uns des autres car gérant des aspects différents du système conçu. Certains de ces modules implémentent soit des tâches métier, soit des tâches plus applicatives comme l'authentification des utilisateurs ou encore offrant des services techniques comme la génération de trace ou le multi-threading. Ces modules représentent alors au même niveau d'abstraction, différentes considérations (différents aspects) d'une application, le plus souvent celui de la couche métier.

Liste non exhaustive d'exemples de modules :

• gestion des utilisateurs (authentification) ;
• archivage des données (persistance) ;
• programmation concurrente (multi-threading) ;
• information pendant l'exécution du logiciel (historique des événements, trace) ;

Dans la pratique, les considérations techniques que sont censés implémenter les modules non seulement s'entrecroisent (par exemple la gestion des utilisateurs fait aussi appel à la génération de trace) mais sont de plus réparties dans la couche métier : c'est l'intrication ou entrecroisement des aspects techniques^{[trad 4]}. Ainsi, une couche logicielle, initialement dédiée à gérer la logique métier applicative (par exemple un système bancaire), va se retrouver dépendante de modules gérant les aspects transactionnels, de journalisation, etc. ; la croissance de ces dépendances conduisant à une complexification du code, de son développement et de sa maintenance.

La programmation par aspect va permettre d'extraire les dépendances entre modules concernant des aspects techniques entrecroisés et de les gérer depuis l'extérieur de ces modules en les spécifiant dans des composants du système à développer nommés « aspects » ; ils sont développés à un autre niveau d'abstraction.

Ainsi, au lieu d'avoir un appel direct à un module technique depuis un module métier, ou entre deux modules techniques différents, en programmation par aspect, le code du module en cours de développement est concentré sur le but poursuivi (la logique bancaire, pour reprendre notre exemple), tandis qu'un aspect est spécifié de façon autonome, implémentant un aspect technique particulier, par exemple la persistance ou encore la génération de trace. Un ensemble de points d'insertions sont ensuite définis pour établir la liaison entre l'aspect et le code métier ou un autre aspect^{[trad 5]}. Ces définitions de point d’insertion sont définies dans le cadre de la POA. Selon les frameworks ou les langages d'aspects, la fusion du code technique avec le code métier est alors soit réalisée à la compilation, soit à l'exécution.

Bien sûr, si chaque aspect créé devait lui-même définir explicitement à quel point d'exécution il doit s'insérer dans le code métier ou dans un autre aspect, c’est-à-dire par exemple avec une dépendance directe vers le module métier où devra s'intercaler le code technique, la méthode n'aurait alors fait que décaler le problème. Aussi, l'astuce utilisée par plusieurs langages consiste à utiliser un système d'expressions rationnelles pour préciser à quels points d'exécution du système l'aspect spécifié devra être activé.

Un logiciel métier qui décrit un environnement distribué est écrit de manière classique en utilisant une décomposition fonctionnelle ou objet. Au moment du déploiement du système, on s’aperçoit que les machines physiques sur lesquelles le système va tourner ont en fait des caractéristiques hétérogènes (puissance, bande passante, etc.) qui affectent ou modifient les fonctionnalités du logiciel d’origine.

Une approche fréquente consisterait en ce cas à appliquer des correctifs un peu partout dans le code pour adapter le logiciel à son environnement d’exécution réel. Avec les outils de POA il devient possible de facilement spécifier les changements requis sans toucher aux sources du code original, dont la logique reste intacte.

Les outils de programmation par aspect sont en fait similaires aux modificateurs (before, after et around) que l’on trouve dans des langages comme LISP, auxquels on a ajouté la possibilité d’une description d’insertions déclaratives.

Un aspect permet donc de spécifier :

• les points d'action, qui définissent les points de jonction satisfaisants aux conditions d'activation de l'aspect, donc le ou les moments où l'interaction va avoir lieu^{[trad 6]} ;
• les greffons, c’est-à-dire les programmes qui seront activés avant, autour de ou après les points d'action définis^{[trad 7]}.

Le couplage entre les modules gérant des aspects techniques peut être réduit de façon très importante, en utilisant ce principe, ce qui présente de nombreux avantages :

• maintenance aisée : les modules techniques, sous forme d'aspect, peuvent être maintenus plus facilement du fait de leur détachement de leur utilisation,
• meilleure réutilisation : tout module peut être réutilisé sans se préoccuper de son environnement et indépendamment du métier ou du domaine d'application. Chaque module implémentant une fonctionnalité technique précise, on n'a pas besoin de se préoccuper des évolutions futures : de nouvelles fonctionnalités pourront être implémentées dans de nouveaux modules qui interagiront avec le système au travers des aspects.
• gain de productivité : le programmeur ne se préoccupe que de l'aspect de l'application qui le concerne, ce qui simplifie son travail, et permet d'augmenter la parallélisation du développement.
• amélioration de la qualité du code : la simplification du code qu'entraîne la programmation par aspect permet de le rendre plus lisible et donc de meilleure qualité.

Le tissage d'aspect qui n'est finalement que de la génération automatique de code inséré à certains points d'exécution du système développé, produit un code qui peut être difficile à analyser (parce que généré automatiquement) lors des phases de mise au point des logiciels (débogage, test). Mais en fait cette difficulté est du même ordre que celle apportée par toute décomposition non linéaire (fonctionnelle ou objet par exemple).

Cela dit, une implémentation comme AJDT (acronyme anglais de AspectJ Development Tools), basée sur AspectJ, offre des outils sophistiqués qui permettent de passer de façon transparente, en mode débogage, du code d'une classe à celui d'un aspect.

La programmation orientée aspect, parce qu'elle propose un paradigme de programmation et de nouveaux concepts, a développé un jargon bien spécifique qui ne facilite pas la compréhension de ses concepts qui sont, en définitive, simples mais puissants.

Aspect

un module définissant des greffons et leurs points d'activation ;

Greffon (advice)^{[trad 7]}

un programme qui sera activé à un certain point d'exécution du système, précisé par un point de jonction ;

Tissage ou tramage^{[trad 8]}

insertion statique ou dynamique dans le système logiciel de l'appel aux greffons ;

Point de coupe, d'action, de coupure ou de greffe (pointcut)

endroit du logiciel où est inséré un greffon par le tisseur d'aspect ;

Point de jonction ou d'exécution^{[trad 5]}

endroit spécifique dans le flot d'exécution du système, où il est valide d'insérer un greffon. Pour clarifier le propos, il n'est pas possible, par exemple, d'insérer un greffon au milieu du code d'une fonction. Par contre on pourra le faire avant, autour de, à la place ou après l'appel de la fonction.

Considérations entrecroisées ou préoccupations transversales ^{[trad 9]}

mélange, au sein d'un même programme, de sous-programmes distincts couvrant des aspects techniques séparés.

Deux grandes stratégies de tissage d'aspects existent :

• le tissage statique par instrumentation du code source ou du pseudo-code machine intermédiaire (bytecode Java, IL)
• le tissage dynamique lors de l'exécution du logiciel (implémentée par exemple par JAC)

• En Java :
  • AspectJ : Extension du langage Java nécessitant donc une étape de précompilation^[3]. Le résultat est toutefois du bytecode Java standard.
  • Java Aspect Components (JAC) : Framework 100 % Java conçu par des centres de recherche français^[4].
  • Spring : Spring AOP
• En C++ :
  • AspectC++ (en)
• En .NET (C#, VB.NET …) :
  • LOOM.NET
  • AspectDNG
  • KingAOP
  • PostSharp (commercial)
  • Spring.NET
  • CodeFluent Entities (commercial)
• En PHP :
  • PHP-AOP (AOP.io)
  • la Go! AOP bibliothèque
  • AOP Pecl extension
• En C :
  • Aspect-C
• En Caml :
  • Aspectual Caml
• En Python :
  • Aspyct
  • Aspects
  • Spring Python
• En Common Lisp :
  • AspectL
• En Ruby :
  • AspectR
• En Lua :
  • AspectLua
  • RE-AspectLua, le remplaçant d'AspectLua
• En Ada :
  • AspectAda : Extension^[5] du langage Ada.

• L'article de référence sur l'AOP au Xerox Palo Alto Research Center, Aspect Oriented programming ECOOP 1997
• Renaud Pawlak, Jean-Philippe Retaillé, Lionel Seinturier, Programmation orientée aspect pour Java / J2EE, Eyrolles, 2004, 446 p., (ISBN 2212114087)
• Maxime Borin, Ramnivas Laddad, AspectJ in Action: Practical Aspect-Oriented Programming, Manning Publications, 2003, 512 p., (ISBN 1930110936)
• Russell Miles, AspectJ Cookbook, O'Reilly, 2004, 360 p., (ISBN 0596006543)

• (fr) « http://www.dotnetguru.org/articles/dossiers/aop/quid/AOP15.htm »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)} (consulté le 29 mars 2013)
• (en) AOP Alliance (Java/J2EE AOP standards)
• (fr) Initiation à la programmation orientée aspect
• (fr) Programmation orientée aspect en Java avec AspectJ
• (fr) Java Aspect Components

• Portail de la programmation informatique