2. Le développement orienté aspects (AOSD)
2.8 Problème d’interaction : Discussion
2.8.1 Exemple :
Il s’agit d’un exemple d’un système décrit dans [ 33,57] où des chaînes de caractère sont envoyées entre des objets. Les aspects suivants, partageant les mêmes chaînes, sont introduits dans le système:
Un aspect journalisation qui enregistre les appels des méthodes dans un fichier. Un aspect autorisation qui interdit aux utilisateurs non privilégiés d'utiliser certaines méthodes dans le système.
un aspect filtre qui filtre les chaînes à envoyer et supprime celles inappropriées. Un aspect Encodeur qui code une chaîne de caractère pour un envoi sécurisé. A partir de ce simple exemple on peut observer plusieurs cas d’interférence. Le premier cas est observé, lorsque l’aspect journalisation est exécuté avant l’aspect autorisation, une méthode peut être enregistrée sans être exécutée, dans l’ordre inverse, si la méthode n'est pas autorisée, elle est interrompue, et abandonnée avant qu’elle ne soit enregistrée. Un autre cas d’interaction est observé entre les aspects encodeur et filtre. Evidement, Coder la chaîne après le filtrage des mots inappropriés est le comportement souhaité, mais, un autre comportement indésirable peut se produire, si le filtre sera appliqué sur des chaînes codées. Cependant, L’aspect journalisation semble générer un fichier journal incluant des chaînes de caractères sans sens s’il est appliqué après avoir codé les chaînes, dans un autre ordre inverse il va enregistrer les chaînes d’origine [57].
De là, en cas d’interaction entre les aspects, leurs advices pourraient se comporter correctement tant qu’ils sont orthogonaux même s’ils partagent des variables communes, où pourraient influencer un autre calcul sans influencer l'effet des advices. Autrement, si l'exécution des différents ordres d’advices produira des comportements différents du système, dont un est le comportement désiré (ou aucun des comportements dans tous les cas est désiré), c’est le problème d’interférence qui doit être traité. Il faut comparer les différents ordres des advices pour détecter les interférences entre les aspects [57].
2.8.2 Discussions
Ainsi a partir de cet exemple on a essayé d’expliquer ce très difficile problème et qui contrait toute la technologie orienté aspect. En effet l’évolution et l’adoption de la technologie orientée aspect dépend beaucoup d’émergence et développement de solutions efficaces à ce problème « l’interaction entre les aspects ». Car enfin on doit être toujours rassuré que le système composé soit réellement le bon système qu’on veut obtenir, et qu’il ne montre pas des comportements indésirables. Il doit répondre aux demandes et désirs du développeur et satisfait les besoins des utilisateurs. par conséquent ,le développeur doit être équipé par des outils, méthodes et techniques qui assistent à la détection de points d’interaction potentiels et qui aident à la détection et résolution de problème de conflits durant tout le processus du développement.
Bien que les langages de programmation orientée aspect permettent aux ingénieurs logiciels d’encapsuler séparément des préoccupations transversales, cela ne signifie pas que toutes les préoccupations peuvent être traitées indépendamment, les aspects peuvent être en conflit ou dépendant l’un de l’autre. En réalité le problème d’interaction entre les aspects est un problème adhèrent a l’approche orienté aspect elle-même. Décomposer le système à un ensemble de partie indépendant, n’enlèvera jamais des relations de dépendances et de conflits entre eux une fois composés ensemble pour avoir le système complet. En effet, s’il y avait une approche qui ne serait pas touchée par se problème, on pourrait simplement élire cette approche et se concentrer sur elle pour un développement sans problème d’interaction, mais malheureusement ce n’est pas le cas, les définitions des aspects et de base peuvent être conflictuelles, les aspects peuvent entrer en conflit les uns avec les autres ou avec la base dans laquelle ils vont être tissés, malgré la diversité de façons d’implémenter les préoccupations aspects et base [36].
Enfin, toutes les approches orienté aspect sont affrontées par ce problème. Explicitement cela est indiqué pour des approches tel que : la séparation multidimensionnelle, filtres de composition et programmation par aspect respectivement dans [12][11],[32,31,34,22]. En outre comme l’approche orienté aspect est étendue à toutes les phases du développement orienté aspect, cela rend toute les phases concernées par les interactions entre les aspects.
Ainsi, en adoptant une terminologie orienté aspect on peut dire que le problème d’interaction entre les aspects est un aspect qui transverse toutes les approches orienté aspect et tout le processus du développement orienté aspect. Actuellement comme on peut remarquer dans ce chapitre, ce problème est traité en deux axes distincts.
- des approches de test et de vérification formelles ont été proposées pour des programmes orientés aspect, ces approches tardives reposent sur une spécification opérationnelle complète (programme) et généralement elles
sont classées à des approches basées sur le modèle checking, d’analyse statique, et le tranchage (slicing)[42,57,10]. Dans l’introduction générale sont décrit des exemples de ces approches
- Des approches d’aspects précoces telles que d’ingénierie d’exigence par aspect qui proclament l’avantage du traitement précoce des aspects pour le développement par aspect.
Et donc, dans le cadre de notre travail, nous choisissons le traitement précoce des interactions entre les aspects. Ainsi, nous adoptons deux stratégies pour nous attaquer à ce problème difficile :
- une solution générique pour le traitement d’interaction : comme il a été
présenté durant ce chapitre l’approche orientée aspect englobe plusieurs approches avec des différences apparentes mais heureusement, tous acceptent un ensemble de concept. Ainsi il est avantageux de développer une idée commune sur le traitement d’interaction des aspects basé sur l’ensemble de concepts communs, il reste à toutes les approches d’implémenter la solution commune selon leur mécanismes orienté aspect.
- un traitement précoce du problème : le problème d’interaction et de conflit
entre les aspects est un grand problème, comme il est préférable d’identifier les aspects tôt dans le cycle de développement, l’analyse de leur interaction doit être aussi précoce. nous reconnaissons que ce problème doit être géré durant tous les phases du développement, mais nous posons toujours qu’un bon départ du projet conduit au succès du projet. C’est durant les phases précoces qu’on doit développer des spécifications utiles à toutes les phases. dans ce stade une solution générique peut être utile puisqu’elle peut être acceptée et adaptée aux différentes phases.
- enfin ; bien qu’actuellement un grand intérêt est accordé aux approches formelles d’analyses des interactions entre aspects, nous pensons que notre approche générique et précoce se complémente avec ces approches tardives.
2.9 Conclusion
Dans ce chapitre, nous avons présenté Les concepts de base de l’AOSD, pourquoi l’orienté aspect est nécessaire dans le développement logiciel moderne et comment il contribue à l’amélioration des processus de développement modernes. Bien que ces approches améliorent la structuration des logiciels, elles sont freinées par le problème d’interaction entre les aspects. Comme il est préférable d’identifier les aspects tôt dans le cycle de développement, l’analyse de leur interaction doit être aussi précoce. Notre contribution sera durant la phase d’analyse des exigences. Le chapitre suivant est consacré à donner une introduction a l’ingénierie des exigences orientée aspects.