Reconfiguration dynamique des architectures logicielles

Le travail que nous présentons dans cette thèse a été élaboré au niveau de l’équipe SAFA du laboratoire d’ingénierie des systèmes complexes (LISCO) de l’université de Badji-Mokhtar d’Annaba. L’équipe SAFA (Software Architecture and Formal Approaches) s’active autour des thèmes liés à l’ingénierie du logiciel. Son activité de recherche se concentre actuellement sur les nouveaux paradigmes de génie logiciel, et plus particulièrement les paradigmes d’architectures logicielles et les approches formelles.

L’architecture logicielle comme nouvelle discipline du génie logicielle, décrit de manière abstraite les systèmes à l’aide de composants logiciels, les relations entre ces composants, leurs propriétés fonctionnelles et non fonctionnelles ainsi que les principes qui régissent leur conception et leur évolution [IEE 00]. Afin de maitriser le processus de développement de logiciels basés architectures, un langage de spécification est nécessaire. Les langages de description d’architectures (ADLs) répondent à ce besoin, et fournissent une représentation abstraite des éléments de base constituant un système complexe, en réduisant le coût de détection et de correction d’erreurs [Med 02]. Ces langages sont formels et peuvent décrire l’architecture d’un système assez complexe [Cle 96]. Un ADL garanti un niveau élevé d’abstraction, ignorant ainsi les détails d’implémentation [Med 00]. Grâce à cette description abstraite, les ADLs aident les développeurs, en facilitant le contrôle du processus de développement à un stade avancé [Hus 13]. Les ADLs sont donc cruciaux dans le développement logiciel particulièrement ceux basés architecture. Chaque ADL a ses caractéristiques, certains ADLs ont été proposé pour la modélisation d’architectures dans un domaine bien précis, d’autres sont plus spécialisés. Voici une liste non exhaustive d’ADLs présents dans la littérature : LIEANNA [Tra 93], Artek [Ter 95], MetaH [Bin 96], Aesop [Sha 96], SADL [Mor 97] ; [Mor 95), Weaves [Gor 94] ; [Gor91], Wright [All 97], AESOP [Gar 95], Darwin [Mag 95], Acme [Gar 00], Rapide [Luc 95], UNICON [Sha 95] and C2 [Tay 96].

Les applications des ADLs sont très diverses, c’est pourquoi beaucoup d’ADLs sont développés. La liste est si importante qu’il est fastidieux de discuter en détail chaque ADL avec son évaluation. Dans [Hus 13], Sajjad organise ces détailles, en regroupant les secteurs industriel et universitaire.

Présentation des contributions

Bien que certains ADLs supportent les reconfigurations dynamiques à des niveaux variables, le problème de la fiabilité de ces reconfigurations n’est pas réellement abordé comme un objectif à part entière. En effet cet aspect est peu détaillé, et il manque clairement un mécanisme robuste pour l’évaluation des systèmes. La programmation par composants, associée à des outils et des langages dédiés, comme les langages de description d’architecture, est un bon support pour les reconfigurations dynamiques d’architecture. Grâce à la réflexion, les modèles de composants permettent l’introspection et les modifications dans les systèmes à l’exécution, tout en maintenant une connexion causale entre architecture et système concret. Modifier dynamiquement un système à travers son architecture n’est pas sans poser des problèmes de fiabilité, et qui demeure une préoccupation importante du génie logiciel. En général, la plupart des modèles de composants ne définissent pas les besoins et les règles à respecter pour que les applications basées sur ces modèles puissent évoluer et s’adapter dynamiquement au cours de leur exécution [Ket 04].

La fiabilité des reconfigurations dynamiques est un problème global qui requiert une démarche rigoureuse, dont le point de départ serait de définir le concept de cohérence dans une architecture, essentiellement d’un point de vue structurel. La cohérence d’une architecture est ensuite conditionnée par la satisfaction d’un ensemble de contraintes exprimées dans une certaine logique. Les contraintes doivent être extensibles, afin de permettre d’exprimer les invariants aux niveaux des configurations, et de couvrir le coté sémantique des opérations de reconfiguration. La cohérence doit être maintenue même dans le système reconfiguré. Il est aussi important de vérifier les contraintes avant de valider les modifications des reconfigurations.

Ce travail [Mez 18], permet de formaliser une configuration d’architecture (figure 1.1). Dans cet objectif, nous décrivons les contraintes en logique des prédicats du premier ordre, que nous traduisons ensuite en utilisant un style architectural Acme/Armani détaillé dans [Mon 01] afin de valider la configuration statique. En ce qui concerne l’aspect dynamique, il est validé par un autre processus, où les contraintes sont   en Plastik et le système validé dans le modèle OpenCom. Etant donné l’influence de l’architecture d’un système sur l’ensemble des attributs de qualité d’un système logiciel, il devient pertinent de développer un support pour la qualité logicielle dés le niveau architectural. En effet, ce travail représente le niveau de base qui inclut : le style architectural, les composants, les connecteurs et les contraintes de configuration. En préservant la conformité de la couche architecturale à la couche application, et en assurant la consistance, une spécification formelle d’un modèle Acme peut servir à plusieurs fins :
— Permettre une vérification formelle d’une conception Acme ;
— Fournir la base d’un langage de description d’architecture formelle pour Acme ;
— Fournir une spécification plus abstraite et indépendante du langage de programmation pour le modèle Acme ;
— Permettre une comparaison rigoureuse avec les autres modèles de composants ;
— Permettre une spécification formelle et une vérification des outils Acme ;

Programmation par composants

La programmation par composant est un paradigme de développement pour la conception et l’implémentation de systèmes logiciels et qui ressort de l’incapacité de l’approche orienté objet à soutenir une réutilisation efficace [Jai 16]. Les composants sont plus abstraits que les classes d’objets et peuvent être considérés comme des fournisseurs de services autonomes. La composition doit être conforme aux règles de construction des architectures, et se fait grâce aux langages de description des architectures. En ce qui concerne les contraintes, elles sont gérées par des styles architecturaux. Avec la croissance de la taille et de la complexité du logiciel, l’approche traditionnelle qui correspond à la construction à partir de zéro, devient de plus en plus inefficace en termes de productivité et de coût. Afin de répondre aux exigences de qualité, et des logiciels modernes à grande échelle, différents paradigmes de développement ont été introduits dans le but de faciliter la création de systèmes évolutifs, flexibles, fiables et réutilisables.

La programmation par objets a émergé depuis une vingtaine d’année [Coi 06] et s’est ainsi imposée comme évolution majeure par rapport à la programmation procédurale. Le paradigme objet apporte en effet de bonnes propriétés, telles qu’un niveau d’abstraction plus élevé (concepts de classes et d’instances), etc. Cependant, l’objet n’est pas suffisamment abstrait et reste à un niveau de granularité trop fin pour maitriser aisément la structuration des systèmes complexes, structuration indispensable à leur maintenance et à leur évolution. Les lacunes de l’approche objet ont mené à la création d’un nouveau paradigme de programmation : le composant. Le paradigme composant est une approche appropriée et méthodique, qui implique la construction d’un système en utilisant des briques de bases qui ont été développés à différents moments, par différentes personnes, et probablement en ayant à l’esprit différents concepts et utilisations [Sha 12]. Afin de pouvoir découvrir les différents composants, leurs manières de communiquer et de construire dynamiquement l’assemblage, un environnement de composants fournit toujours un mécanisme d’introspection et un mécanisme d’invocation dynamique (le référentiel des interfaces et le DII (Dynamic Invocation Interface) de CORBA [Gei 00], l’API java.lang.reflect du langage Java [Bel 99][Bel 98], les interfaces IUnknown et IDispatch dans COM). L’introspection permet de découvrir à l’exécution les interfaces d’un composant. En Java, l’introspection permet aussi de découvrir la structure interne des composants (les attributs). Depuis JDK version 1.1, la sérialisation des objets Java met en œuvre ce mécanisme d’introspection de manière automatique afin de permettre de rendre un objet ou un graphe d’objets de la JVM persistant pour stockage ou échange. L’invocation dynamique permet de construire dynamiquement des requêtes sur les composants. L’association de ces deux mécanismes permet de construire des outils d’interaction sur les composants pour configurer/reconfigurer un assemblage de composants.

Modèles de composants

Le concept de composant logiciel est relativement ancien [Mcl 68]. Il est décrit comme une brique logicielle composable et facilement réutilisable, d’où l’appellation de composant sur l’étagère (Composant On The Shell ou COTS). Cependant, il n’existe pas de définition universelle d’une description d’architecture à composant. Selon Szyperski [Szy 98], un composant « est une unité de composition dont les interfaces et les dépendances contextuelles sont spécifiées sous forme de contrats explicites ». Il peut être « déployé indépendamment et est composable par des tiers ». Selon Heieneman et Council [Cou 01]. Un composant logiciel est un élément conforme à un modèle de composition, pouvant être indépendamment déployé et composé. Le modèle de composition définit les standards de spécification et d’interaction. L’implémentation du modèle représente un ensemble d’outils logiciels supportant l’exécution des composants conformes au modèle. En comparaison aux objets, et de part la nature des encapsulations fortes dans le composant (boite noire), les composants offrent une plus grande modularité et facilité de réutilisation, ainsi qu’une meilleure indépendance entre les briques logicielles, représentant clairement les dépendances requises et fournies. La séparation des préoccupations (separation of concerns) est une approche de conception qui consiste à distinguer les préoccupations fonctionnelles et extra-fonctionnelles dans un système afin d’isoler des aspects indépendants ou faiblement couplés. Elle représente un point fort de la programmation par composants [Dij 82]. Le cycle de vie du logiciel est décomposé en plusieurs phases : De la conception de l’architecture, au développement du code métier des composants, suivi de leur déploiement et finalement de leur exécution. L’architecture d’une application, quant à elle, est composée de la définition des différentes instances des différents composants utilisés et de la spécification de leurs interconnexions, c’est-à-dire les dépendances entre les services requis et fournis, ainsi que les schémas de communication utilisés lors de l’exécution [Riv 00]. Cette démarche repose sur des techniques d’injection de dépendances dans le code d’implémentation. Elle offre certains avantages, entre autre, le développeur peut se concentrer sur un problème à la fois. Les besoins et les contraintes de chaque aspect évoluent de manière autonome, grâce à la suppression des interactions entre aspects orthogonaux. En fonction du milieu, la définition d’un composant peut varier. En effet, dans le milieu académique, un composant est vu comme étant une entité bien définie, souvent petite avec des propriétés fonctionnelles et non-fonctionnelles. Dans l’industrie par contre, un composant est considéré comme une partie réutilisable du système, mais que celle-là n’est pas nécessairement bien définie dans ses interfaces et sa conformité à un modèle de composant.

Table des matières

1 Introduction
1.1 Contexte et problématique
1.2 Présentation des contributions
1.3 Organisation du document
I Etat de l’art
2 Concepts et technologies associés au sujet
2.1 Programmation par composants
2.1.1 Modèles de composants
2.1.2 Eléments d’architecture
2.1.3 Étude de quelques modèles de composants
2.1.3.1 Le modèle JavaBeans
2.1.3.2 Le modèle Entreprise JavaBeans
2.1.3.3 Le modèle COM
2.2 Langages de description d’architectures et styles architecturaux
2.2.1 Les langages de description d’architectures
2.2.2 Contraintes et styles architecturaux
2.3 Dynamicité des architectures logicielles
2.3.1 Réflexion et architectures réflexives
2.3.1.1 Systèmes réflexifs
2.3.1.2 Langages réflexifs
2.3.1.3 Architectures réflexives
2.3.2 Reconfiguration dynamique
2.4 Conclusion
3 Fiabilité des architectures logicielles reconfigurables
3.1 Critères de sélection des travaux
3.2 Plateformes construisant un modèle d’architecture
3.2.1 π-ADL
3.2.2 C2SADL
3.2.3 Dynamic Wright
3.2.4 Acme/Plastik
3.3 Synthèse des ADL étudiés
3.4 Conclusion
II Contribution
4 Modélisation des configurations Acme
4.1 L’ADL Acme
4.1.1 Cœur du modèle Acme
4.1.2 Implémentations et outils associés au modèle
4.2 Processus de vérification de la cohérence
4.3 Spécification du modèle Acme
4.3.1 Un méta-modèle pour Acme
4.4 Spécification du modèle par des contraintes d’intégrité
4.5 Traduction de formalisme Armani
4.5.1 Elements architecturaux
4.5.2 Contraintes
4.6 Test et validation
4.6.1 Déclaration des exigences pour l’exemple système ATM
4.6.2 Diagramme de modélisation de l’ATM
4.6.2.1 Diagramme de composant
4.6.2.2 Interfaces de l’ATM
4.6.3 Formalisation d’un ATM en Acme/Armani
4.6.4 Règles de cohérence et vérification du modèle
4.7 Conclusion
5 Spécification des reconfigurations dynamiques
5.1 Gestion des reconfigurations dynamiques par les ADLs
5.1.1 Aspects clés des reconfigurations dynamiques
5.1.2 Contraintes d’intégrité spécifiques à la reconfiguration
5.2 Analyse des opérations de reconfiguration dans Acme /Plastik
5.2.1 Spécification des opérations primitives
5.2.2 Traduction des conditions et contraintes
5.2.3 L’infrastructure d’exécution
5.3 Plate-forme d’exécution
5.3.1 Principales structures de données
5.3.2 Principe
5.4 Conclusion
6 Conclusion et Perspectives
6.1 Synthèse et bilan des contributions
6.2 Perspectives
Bibliographie

Lire le rapport complet