Approches de modélisation orientée aspects

Les approches de modélisation orientée aspects séparent les éléments de modèles qui appartiennent à différentes préoccupations. Un modèle primaire ou aussi de base représente le cœur fonctionnel du système. Plusieurs modèles d’aspects sont aussi modélisés pour représenter les préoccupations transverses du système, comme par exemple la sécurité et la persistance. Les modèles d’aspects doivent alors être composés avec le modèle primaire afin d’obtenir un modèle de conception intègre [47].

La communauté de développement de logiciels par aspects porte un intérêt particulier à l’exploitation des mécanismes utilisés pour le développement des lignes de produits logiciels. Plusieurs travaux se sont focalisés sur la capture des points communs et des points variables dans une ligne de produits logiciels en utilisant les aspects à une étape précoce [48][49][50][51] ainsi qu’à l’utilisation de la technologie de l’aspect au niveau implémentation pour représenter les caractéristiques des lignes de produits. Par exemple, Groher et Voelter [52][53][54] représentent les caractéristiques d’une ligne de produits logiciels au niveau modèle par des aspects (qui sont aussi des modèles). Au niveau implémentation, les aspects encapsulent les implémentations des caractéristiques. Pour obtenir un produit de la ligne de produits, les aspects sont composés avec la base selon une sélection des caractéristiques pour une configuration donnée. C’est ainsi qu’ils expriment la variabilité par les aspects.

2.2.2.2. Composition

Parmi les approches existantes pour la composition des modèles de lignes de produits logiciels par utilisation des technologies de l’aspect, deux approches sont sélectionnées et analysées dans cette partie.

Dans [55][56][57] les auteurs proposent de fusionner les modèles en deux phases. La première phase consiste à comparer les modèles à fusionner pour identifier les éléments qui représentent un même concept. Ces éléments sont alors dits des éléments correspondants. Ils sont ensuite fusionnés durant la phase de fusion. Pour identifier les éléments correspondants, l’approche propose de se baser sur la comparaison des signatures des éléments. Tout type d’élément possède un type de signature défini par ses propriétés syntaxiques pour assurer l’unicité des éléments. Deux éléments sont alors fusionnés s’ils ont des signatures équivalentes. Par exemple, le type de signature d’une classe UML est défini par la propriété

name qui indique le nom de la classe ainsi que la propriété isAbstract qui indique si la classe

est abstraite ou non. La signature de la classe Sensing de la figure 15 est donc définie par

{name= Sensing, isAbstract=false}. Si deux vues de la classe Sensing appartiennent aux

modèles à fusionner et qu’elles ont le même nom et la même valeur de la propriété isAbstract, elles sont alors correspondantes et elles sont fusionnées durant la phase de fusion pour former une seule classe dans le modèle de fusion résultant.

Figure 2.15: Exemple de fusion basée sur les aspects

Dans ce travail, les auteurs mènent un raisonnement local sur les modèles durant la fusion. La variabilité n’est pas traitée à ce niveau, ce qui explique l’absence de gestion de l’information de variabilité associée aux éléments des modèles à fusionner. De même pour les contraintes de variabilité qui ne sont pas traitées durant le processus de fusion proposé.

311 1 _{Etat de l’art1} 1

L’approche de Clarke [58][59] représente beaucoup de similitudes avec l’approche précédente. Dans cette proposition, un modèle appelé theme est créé pour chaque exigence du système. Ces themes, équivalents aux modèles d’aspects et primaires, représentent différentes vues du modèle global. Le modèle intègre est obtenu par composition des ces themes. Dans l’approche Theme, des relations de composition spécifient comment les modèles doivent être composés par identification des éléments correspondants ainsi que comment ils sont fusionnés. Le mécanisme de fusion est utilisé en se basant sur la comparaison des noms des éléments à fusionner. La description de l’utilisation de ce critère de comparaison manque de précision. Elle reste dépendante de l’utilisateur de l’approche. Cependant, nous rappelons que la comparaison des éléments à fusionner en se basant sur leurs noms demeure un critère faible et permissif comme nous l’avons illustré pour l’approche d’Acher dans la figure 2.8. De plus comme pour l’approche précédente, les auteurs raisonnent localement sur les modèles et ne traitent pas la variabilité. La fusion des modèles ne traite donc ni l’information de variabilité des éléments à fusionner ni les contraintes de variabilité qui leurs sont associées. De même que l’approche précédente, le raisonnement sur les modèles durant la fusion reste local. La variabilité n’est pas traitée à ce niveau, ce qui explique l’absence de gestion de l’information de variabilité associée aux éléments des modèles à fusionner. De même pour les contraintes de variabilité qui ne sont pas traitées durant le processus de fusion proposé.

2.2.2.3. Synthèse

L’utilisation des techniques de développement par aspect des logiciels dans le contexte des lignes de produits logiciels prend de plus en plus d’ampleur. En effet, les différentes exigences de la ligne de produits sont modélisées sous forme d’aspects (qui sont des modèles) et d’un modèle de base. Pour obtenir un produit de la ligne de produits logiciels, le modèle de base est composé avec les aspects qui représentent les exigences du produit souhaité. Les mécanismes de composition à ce niveau se basent sur l’aspect structurel des modèles composés. Cependant le raisonnement de ces approches au niveau composition reste local et ne traite donc ni l’information de variabilité des éléments structurels ni les contraintes de variabilité. De même la sémantique de composition n’est pas évoquée par ces approches.

2.2.3. Approches dirigées par les modèles annotatrices de variabilité