Évolution architecturale

L’évolution logicielle a tendance à être progressive et incrémentale, dirigée, par exemple, par les retours des utilisateurs ou d’autres intervenants, sous la forme de rapports d’erreurs et de demandes de nouvelles fonctionnalités, ou plus généralement, par les changements des exigences fonctionnelles ou non-fonctionnelles. La plupart des systèmes logiciels sont donc exposés à de nombreuses forces qui exigent leur modification. En conséquence, le logiciel change continuel- lement. Ce phénomène inévitable est appelé évolution logicielle [LB85], et a été souligné par

les travaux de Lehman et al. dès les années 70. En pratique, il n’y a pas de définition précise et largement acceptée de ce que doit être l’évolution logicielle, selon le niveau d’abstraction et le niveau de granularité considéré. Cependant, nous pouvons formuler trois observations ma- jeures. Premièrement, l’évolution peut avoir lieu durant le développement ou après la mise en exploitation du logiciel. Ce dernier cas est souvent assimilé à une activité de maintenance. Deuxiè- mement, l’évolution se manifeste par des modifications, très simples ou très complexes, jusqu’à la restructuration totale du logiciel. Troisièmement, l’évolution peut concerner les différents ar- tefacts produits lors du cycle de développement du logiciel : code source, modèle de conception, architecture, documentation, etc. Lorsque l’évolution concerne spécifiquement l’architecture des systèmes, on parle d’évolution architecturale – ou encore d’évolution basée architecture. Dans de nombreux systèmes, l’évolution architecturale peut fournir la capacité de modifier l’ensemble des fonctionnalités offertes par le système, dans un effort de personnalisation et d’extensibilité atten- due par les utilisateurs finaux. Dans ce qui suit, nous explorons dans quelle mesure l’architecture logicielle offre une fondation saine pour aborder la problématique de l’évolution.

2.1.1

Motivation

Il existe différentes stratégies pour faire face à l’évolution. L’approche classique en ré-ingénierie consiste à faire évoluer les logiciels au niveau de leur code. Une approche plus récente consiste à faire évoluer les logiciels au niveau de leur modèle1_{. Dès lors qu’un système dispose d’une}

architecture explicite, c’est-à-dire d’un modèle de son architecture, il est envisageable d’aborder la problématique de son évolution sur ce dernier. Nous qualifions d’évolution à grande échelle (evolving-in-the-large) l’approche qui consiste à faire évoluer un système au niveau de son archi- tecture plutôt qu’au niveau de son code source. A l’instar du glissement de paradigme qui s’est opéré pour le développement des systèmes complexes (cf. chapitre 1), le niveau architectural offre un niveau d’abstraction et de raisonnement bien supérieur aux lignes de code, permettant à l’ar- chitecte de décider et de réaliser des évolutions d’ensemble sur son système. En outre, il est admis que le niveau architectural joue un rôle bénéfique dans l’évolution en exposant les dimensions (complexité, coûts, etc.) selon lesquelles un système peut évoluer [Gar00a]. Ainsi, l’importance de l’architecture logicielle pour l’évolution des systèmes devient de plus en plus évident.

2.1.2

Pour quels usages ?

Considérons un scénario dans lequel une société développe un logiciel innovant. Conformé- ment aux bonnes pratiques du génie logiciel, la société développe en premier lieu une bonne architecture pour son logiciel dans un style architectural approprié, puis modélise son archi- tecture avec un ADL, raffine ensuite l’architecture en une conception détaillée (e.g., via une méthodologie objet) et enfin implémente l’application (e.g., via une technologie objet). Le nou- veau logiciel connaît un succès immédiat et de nombreux exemplaires sont vendus. Motivé par ce succès, la société entame un cycle d’avancements rapides, créant des "add-ons", vendant des mises à jour, adaptant le logiciel à différentes plateformes ou encore personnalisant l’application pour différents clients. Dans ce cas de figure, l’architecture évolue pour refléter l’évolution du système logiciel qu’il est censé représenter [MR97]. Une perte de synchronisation entre un sys-

1_{. Dans un certain sens, l’évolution de modèle englobe l’évolution de code, au moins pour ceux qui considèrent} qu’un programme n’est rien d’autre qu’un type spécial (très détaillé) de modèle.

tème et son architecture – appelé phénomène d’érosion architecturale [PW92] – remet en cause la valeur de l’architecture puisque cette dernière ne fourni plus une image fidèle du système.

Par ailleurs, les activités de maintenance logicielle ont été déplacées du niveau du code source vers le niveau de l’architecture. Le mise à jour d’un composant pour utiliser une toute nouvelle librairie par exemple, peut être réalisée en changeant ses connexions architecturales de façon à ce qu’il soit lié à cette nouvelle librairie plutôt que de changer le code source du composant. A travers le niveau d’abstraction élevé qu’ils offrent, les modèles architecturaux sont plus faciles à comprendre que les artefacts du niveau inférieur et fournissent une "vue d’ensemble", essentielle dans la réussite d’une maintenance. En règle générale, travailler à ce niveau d’abstraction est intéressant si les changements impactent l’architecture du système, comme c’est souvent le cas avec de la maintenance perfective (qui représente près de 65% des coûts de maintenance [Som95]), mais plus rarement avec de la maintenance corrective ou adaptative.

2.1.3

Avantages et défis

Les architectures logicielles à base de composants offrent des défis intéressants dans l’étude de l’évolution. Oreizy et al. [OT98] par exemple, mettent en avant plusieurs avantages résultant directement de la gestion de l’évolution au niveau de l’architecture :

1. Le contrôle de la portée et de la politique des évolutions est placée entre les mains des archi- tectes, où les décisions peuvent ainsi être prises sur la base d’une véritable compréhension des exigences et de la sémantique de l’application.

2. Les architectes utilisent communément l’architecture logicielle pour décrire, comprendre et raisonner de façon globale sur un système. Valoriser la connaissance de l’architecte à ce niveau d’abstraction tend à faciliter la gestion de l’évolution.

3. Si aucune restriction particulière n’est placée sur la spécification interne des composants amenés à évoluer, alors il devient possible d’accueillir des composants sur étagères (COTS). 4. Les connecteurs facilitent la séparation du comportement spécifique à l’application des dé- cisions relatives à la portée et la politique des évolutions, permettant à ces derniers d’être modifiés indépendamments.

Un autre point d’intérêt pour l’évolution est le support de familles d’architectures partageant des caractéristiques communes. Une façon de supporter les familles dans les ADLs est de séparer les types de composants et de connecteurs de leurs instances. Intuitivement, toutes les architec- tures issues de la même famille évoluent selon les mêmes stratégies ou "patterns". D’autre part, il est à noter que certaines familles d’applications sont amenées à évoluer plus facilement que d’autres [Gom05]. Récemment, on observe que l’évolutivité est considéré comme un attribut de qualité à part entière des styles architecturaux [OMT08]. Des investigations en ce sens pour- raient par exemple aboutir sur une meilleure compréhension des limitations placées sur les types d’évolutions acceptables par un style architectural donné.