Modèle d’évolution architecturale à base de
NIVEAU 3 QUALITE DE SAEM
|KGMNHN QS XNHNMK } G RRDEM ~USRMS XNHNMK Z M IOQ NXNHNMK LD H G MN L NMK DFRDQ NMN DOOS HNMK | IFR H SS XNHNMK V V V V fg V
Table 3.2 – Évaluation de SAEM vis-à-vis de la pyramide des besoins.
Niveau 1 : SAEM est un modèle d’évolution conçu pour formuler l’évolution sous forme de
styles et également pour propager les impacts des évolutions à travers les relations sémantiques inter-styles. Nous pensons que la traçabilité de l’évolution est une problématique à part entière et qui peut venir compléter SAEM si besoin, sans en changer le fonctionnement.
Niveau 2 : Les styles sont décrits à un haut-niveau d’abstraction, mais une stratégie pour
leur projection vers du code source est proposée dans le Chapitre 4. Par ailleurs, la séparation de l’entête et de la compétence dans la spécification d’un style reconnaît le principe – largement accepté – du masquage de l’information [Par72] et permet de jouer sur le niveau de transparence lors de la réutilisation de l’évolution.
Le SAEM introduit ce que l’on peut appeler un "langage de styles". Un langage de styles est une collection de styles formant un vocabulaire et une démarche pour comprendre et communi- quer des idées portant sur l’évolution logicielle. Il décrit la manière avec laquelle les styles sont inter-reliés et la manière avec laquelle ils se complètent dans un tout cohésif. Dans SAEM, toute évolution récurrente constitue un style d’évolution et est ainsi manipulée de manière uniforme, que celle-ci soit à forte ou plus fine granularité.
Il est utile de faire la distinction entre les évolutions qui sont communes à tous les systèmes à base de composants, de celles qui sont communes à une famille particulière de systèmes. Nous désignons la première catégorie sous le terme d’évolution généraliste tandis que nous désignons
la deuxième catégorie sous le terme d’évolution dédiée3. Nous suggérons que la plupart des
évolutions dédiées peuvent être vues comme des extensions des évolutions généralistes afin de les personnaliser à des besoins particuliers. Pour permettre de spécifier des styles d’évolution ayant une portée variable dans SAEM, les couches d’évolution sont obtenues grâce à la relation de spécialisation inter-styles et son mécanisme d’héritage.
L’évolution peut être gérée à n’importe quel niveau de modélisation d’une architecture lo- gicielle ; tout dépend de la façon dont SAEM est utilisé. Dans SAEM, nous nous basons sur le principe suivant : pour pouvoir gérer l’évolution d’une architecture logicielle décrite sur un niveau de modélisation Ai, il faut d’abord identifier le niveau de modélisation supérieur Ai+1qui
a permis l’instanciation de l’architecture. Tout style d’évolution sera alors spécifié sur la base
des éléments appartenant à Ai+1 pour être exécuté sur les architectures instanciées à partir de
ce niveau. Ceci est comparable à la définition des classes et des objets dans le paradigme objet, où les structures et les comportements des objets sont toujours décrits par leurs classes mais s’appliquent aux objets.
On peut dire que SAEM offre une mécanique opératoire avancée. L’architecte a à sa disposi- tion les relations d’instanciation, de spécialisation, de composition et d’utilisation pour pouvoir décrire et gérer l’évolution selon ses besoins. En outre, en associant à chaque type d’élément ar- chitectural son ou ses styles d’évolution, le raisonnement relatif à l’évolution se retrouve distribué à travers les éléments de l’architecture. En règle générale, un raisonnement distribué facilite le passage à l’échelle, qui est une question importante en raison de la taille et la complexité crois- santes des systèmes logiciels, et qui est prônée dans les définitions récentes de l’évolution comme celles trouvées dans les architectures auto-organisées [GMK02]. Nous verrons dans le Chapitre 4 que le raisonnement supporté par SAEM est de type classificatoire.
Niveau 3 : SAEM s’efforce d’offrir un bon niveau de réutilisation. En effet, il favorise : 1. L’extensibilité : chaque nouvel ajout de style à un élément évolutif ne perturbe aucunement
le fonctionnement des styles déjà présents.
2. L’évolutivité : la compétence d’un style peut être modifiée sans impacter la façon dont d’autres styles l’utilisent.
3. La compositionalité : la relation de composition fournie par SAEM permet la spécification de styles d’évolution composites.
4. La remplaçabilité : un style peut tout à fait être substitué à un autre style, du moment qu’il possède la même entête.
SAEM offre un bon support pour le développement d’architectures évolutives, en reposant sur une description minimaliste des styles d’évolution. Le formalisme du modèle en Y contribue à la simplicité de SAEM. Enfin, l’adaptabilité n’est pas prise en compte pour l’instant par le modèle d’évolution SAEM, mais a été anticipée à travers la notion de vue générique (cf. figure 3.13).
3.7 Conclusion
Nous avons présenté dans ce chapitre le modèle d’évolution baptisé SAEM, que nous pro- posons pour prendre en compte la problématique de l’évolution structurelle des architectures logicielles. Nous avons mis en avant dans SAEM la nécessité de dissocier la spécification de l’évo- lution de la spécification de l’architecture logicielle en elle-même. C’est ainsi que SAEM s’est efforcé de proposer des concepts pour la spécification et la gestion de l’évolution d’une archi- tecture logicielle, indépendamment de tout ADL. Nous avons souligné au travers de SAEM, la nécessité de considérer les différents niveaux de modélisation d’une architecture logicielle, et la nécessité de gérer l’évolution au travers de ces différents niveaux, de manière uniforme. Nous avons également mis en avant l’importance de la propagation des impacts pour garantir la co- hérence globale de l’architecture amenée à évoluer. Les stratégies de propagation sont véhiculées par les relations sémantiques qui existent entre les styles d’évolution.
Nous avons introduit le formalisme MY qui décrit les concepts du styles d’évolution selon trois branches : domaine, entête, compétence. Des liens intra et inter permettent de gérer les
différentes dépendances qu’entretiennent les trois aspects du tryptique. En outre, MY est multi- vues et multi-abstractions. Ainsi, MY est utilisé pour décrire sous forme modulaire et réutilisable des styles d’évolution.
Jusqu’à présent, nous n’avons proposé aucune démarche pour aider les architectes à exploiter SAEM. Une démarche est pourtant nécessaire pour assurer l’efficacité de notre approche de réutilisation dans le contexte de l’évolution dans les architectures à base de composants. Cet aspect fait l’objet du chapitre suivant.