|
Programmation orientée aspectLa 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). HistoriqueLes 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]. Limites techniquesLes 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 :
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. PrincipeAinsi, 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é. Exemple et étude de casUn 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 ( Un aspect permet donc de spécifier :
AvantagesLe 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 :
InconvénientsLe 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. LexiqueLa 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.
ImplémentationStratégiesDeux grandes stratégies de tissage d'aspects existent :
Tisseurs d'aspects
Notes et citations
Autres références
Liens externes
GlossaireAnglais-Français
|
Portal di Ensiklopedia Dunia
