Reconfiguration des architectures logicielles

Problématique et état de l’art

L’étude des changements dynamiques d’une architecture logicielle est un domaine de recherche actif au sein de la communauté scientifique. Pour permettre aux architectures de satisfaire certaines qualités malgré les changements de leur environnement, celles-ci doivent avoir la capacité de réagir aux événements de l'utilisateur ou de l'environnement et d'exécuter des changements architecturaux d’une façon autonome. La reconfiguration d’une architecture consiste à proposer au niveau architectural les changements suivants:

  • addition / suppression de nouveaux composants,
  • ajout de nouveaux composants qui raffinent ou mettent à jour les composants existants,
  • reconfiguration et/ou extension de l'architecture en terme d'ajout ou suppression des connecteurs et des attaches des composants à ces connecteurs.

Les mécanismes comme l'ajout de composants (sur un site local ou sur un site distant), la suppression de composants et la modification des attaches sont suffisants pour une simple reconfiguration. Des opérations de reconfigurations complexes sont mises en œuvre en composant les mécanismes de base. Le processus d’adaptation pour reconfigurer une architecture doit d’une part utiliser un certain nombre de techniques, qui peuvent être fortement spécialisées et d’autre part, garantir que les qualités de l'architecture sont préservées. Le procédé d'adaptation doit être correctement contrôlé et coordonné pour assurer la modifiabilité et la maintenabilité. Pour cela il doit procéder à:

L'évaluation du changement pour déterminer quelles propriétés sont affectées et quelles incohérences peuvent se produire.

La gestion du changement pour assurer la protection des propriétés globales pendant que de nouveaux composants et connexions sont dynamiquement ajoutés ou enlevés du système.

Contributions

Notre approche est complètement innovante dans le sens où elle vise à construire une plate-forme basée sur des agents intelligents qui devrait pouvoir être installée au dessus de n’importe quelle architecture (architectures pour les applications Distribuées, Temps Réel Réparties, Embarquées, Multimodales Multimédia, Pervasive, Wireless,… etc.). Cette plate-forme prend le contrôle de l’architecture dans le but de l’adapter aux exigences de plus en plus fortes de qualité et aux changements fréquents des besoins fonctionnels et non fonctionnels de l’utilisateur ou de l’environnement.

Cette plate-forme contrôle les différents composants et connecteurs de l’architecture et elle peut ainsi auto reconfigurer, auto adapter et auto évoluer l’architecture d’une façon complètement dynamique en se basant sur des stratégies spécifiques pré sauvegardées dans la base de connaissance des agents de la plate-forme. Généralement, la reconfiguration de l’architecture sera effectuée dans le but d’améliorer les attributs de qualité suivants des architectures  (propriétés non fonctionnelles): maintenabilité, reutilisabilté, flexibilité, performance, fiabilité, interopéralilité, portabilité, integrabilité, testabilité, sécurité, etc. Pour cela, la plate-forme doit pouvoir évaluer ces attributs pour les améliorer en appliquant des scénarii spécifiques de reconfiguration pour chaque attribut de qualité qui sont pré définis dans la base de connaissance des agents. Elle permet aussi d’offrir une maquette de simulation comportementale et d’analyse des qualités au niveau architectural.

Nous nous concentrons sur la reconfiguration, l’adaptation et l’évolution dynamique d’architectures logicielles. Nous présentons une nouvelle approche basée sur les systèmes multi-agents. Ces agents sont utilisés pour surveiller l'architecture, pour recueillir des informations sur l’architecture elle-même ainsi que sur son environnement. Ils sont capables de réaliser les trois fonctionnalités : tester, évaluer et améliorer les attributs de qualité d’une architecture. Toutes les stratégies de modification et de test sont stockées dans la base de connaissance de la plate-forme qui dispose de tous ces différents agents qui sont repartis selon une distribution orientée tâche.

La traçabilité des modifications effectuées sur l’architecture est sauvegardée dans la base de connaissance de la plate-forme. Cette plate-forme permet aussi d’avoir une maquette de simulation de l’évolution des attributs de qualité de l’architecture ou d’un composant/connecteur au sein de cette architecture. Cela a un impact considérable sur le processus de développement orienté architecture dans les application à base de composants.

Résultats


Les résultats obtenus à ce jour se sont concrétisés par des articles dans des revues et de nombreuses publications dans des conférences internationales avec comité de lecture.

Un premier prototype de la plate-forme a été réalisé. Des applications sur des architectures client serveurs, architecture de contrôle de robot mobile ont été testées.

Suite aux résultats obtenus nous établit une collaboration avec l’ETS de l’Université de Québec ‘projet franco-québécois’ pour étendre nos résultats vers les architecture multimodale multimédia.

 

 Imprimer  E-mail

Présentation Equipe SFAL

Tout système informatique a une architecture. La conception de celle-ci relève d’un domaine de recherche relativement récent. Des langages et des outils ont été proposés pour aider les concepteurs à concevoir des architectures logicielles qui répondent au mieux aux besoins non fonctionnels. Cependant, de nombreux problèmes restent ouverts. L’expression des propriétés non fonctionnelles lors de l’analyse des besoins n’est pas standardisée et il est difficile de les prendre en compte lors des étapes postérieures de développement. Si l’évaluation de certaines propriétés de qualité telles que la performance en temps ou en place ont bien été étudiées, d’autres restent difficilement quantifiables. De plus, en cours d’exécution,  un système peut voir ses qualités varier selon les caractéristiques de son environnement. Dans ce cas, le système doit pouvoir être reconfiguré de manière plus ou moins automatique ou autonome.

Le thème de l’équipe Spécification Formelle et Architecture Logicielle est l'étude du développement d'architectures logicielles basées sur l'utilisation de méthodes formelles. Notre objectif est de proposer des outils d'aide à la conception et évolution d’architectures logicielles basés sur des approches formelles et intégrant aussi bien les aspects fonctionnels que non fonctionnels.

Notre recherche est orientée selon deux grands axes. D’une part l’étude de la conception des architectures qui implique l’étude des langages d’expression semi formels et formels, l’expression et la prise en compte des besoins non fonctionnels et la conception par application de patrons d’architecture. D’autre part l’étude de la reconfiguration dynamique d’architectures logicielles.


Dans le premier axe l’objectif est de proposer une méthode d’aide à la conception d’architectures basée sur i) l’étude des qualités non fonctionnelles, ii) des styles d’architectures et iii) les méthodes semi formelles et formelles. Les résultats du ce premier axe seront entendus pour tenir compte de la reconfiguration dynamique des architectures logicielles. Le but donc dans ce deuxième axe est d’ajouter à la méthode proposée un processus de contrôle de l’architecture dans le but de l’adapter aux exigences de plus en plus fortes de qualité et aux changements fréquents des besoins fonctionnels et non fonctionnels de l’utilisateur ou de l’environnement.

Actions de recherche :

Relations scientifiques :

Publications :

Publication du rapport d'activité : 2001-2004 

Revues internationales/nationale et chapitre de livre avec comité de lecture : 1999-2003 ... 2003-2007

Conférences internationales/nationale avec actes et comité de lecture : 1999-2002 ... 2003-2007

Workshop et Symposiums Internationaux : 1999-2002 ... 2003-2007

Rapports de Projets de Recherche : 1999-2002 ... 2003-2007

Thèses

Brevet

Membres :

Nicole Levy - Professeur
Amar ramdane-Cherif - Maitre de conference
Lotfi Hazem
Samir Benarif
Olfa Lamouchi
Parinaz Davari
Abdel-Aziz Ouali
Nesrine Yahiaoui
Manolo Dulva Hina
Hicham Djenidi

 Imprimer  E-mail

Patterns de conception d’architectures logicielles

Problématique et état de l’art

La conception d'architectures logicielles est une tâche difficile qui nécessite des guides et des outils.

Les patterns de conception et d'architecture qui décrivent des solutions éprouvées à des problèmes récurrents, ont prouvé leur utilité et sont très appréciés des utilisateurs. Les patterns, comme les composants, facilitent la réutilisation mais ils sont aussi fort utiles  pour assembler des composants. Ils sont par ailleurs institutionnalisés dans les technologies les plus récentes (EJB, CORBA, COM),  où des formes de conception typiques sont requises. Les patterns sont décrits de manière relativement standard, informellement et à l’aide d’exemples. De ce fait, seuls les utilisateurs expérimentés et les connaissant peuvent effectivement les appliquer.

Côté outils, à l'heure actuelle, le support des patterns de conception ou d‘architecture dans les outils CASE est très superficiel. Il s'agit soit d'outils de navigation hypertexte pour accéder aux définitions des patterns, soit d'outils relativement rudimentaires de génération de modèles UML ou de code.

Un pattern est une solution à un problème et donc peut être défini par un couple <problème, solution>. Cependant, de façon générale les outils ne tiennent aucun compte du problème résolu par ces patterns et se concentrent sur une solution typique représentée par une micro-architecture (diagramme de classes ou d'objets). UML propose par exemple un moyen de représenter les patterns de conception au moyen de "collaborations paramétrées".  Non seulement à l'heure actuelle la sémantique de cette notation reste vague, mais là encore  la partie « problème » des patrons est oubliée pour se concentrer sur la solution.

Contributions

Nous proposons une méthode permettant de formaliser les patterns de telle manière à pouvoir guider les utilisateurs dans le choix des patterns à appliquer ainsi qu’un outil permettant l'application automatique des patterns. Dans notre approche, un pattern est explicitement défini par un couple  <Problème – Solution>.

Le problème est décrit précisément et la solution proposée est prouvée résoudre le problème posé. Ainsi, la solution est prouvée comme étant un raffinement du problème. La notion de raffinement utilisée est celle de B. Ainsi, nous traduisons indépendamment les définitions du problème et de la solution, tous deux décrits en UML, en B et prouvons que la traduction de la solution est bien un raffinement de la traduction du problème. Pour cela, nous utilisons notre traducteur UML/OCL2B.

Le problème ainsi que la solution sont définis comme des spécifications abstraites génériques. Pour déterminer si un pattern peu s’appliquer à un problème spécifique, il faut pouvoir retrouver la partie problème du pattern instancié, dans le contexte de la spécification courante. Appliquer alors le pattern revient à remplacer le problème ainsi découvert par l’instanciation appliquée à la partie solution. Une des caractéristiques de cette approche formelle est la possibilité de l‘implanter dans un outil. La découverte de l’instanciation ainsi que l’application de pattern peuvent alors être automatisés.

Résultats


Ce travail est réalisé dans le cadre du projet RNTL LUTIN qui a débuté en novembre 2001. Nos partenaires dans ce projet sont le LIP6 (M. Ziane) et la société Softeam (Ph. Desfray et X. Blanc). Une bibliothèque de patterns est en cours de définition. Un prototype permettant l’application automatique des patterns ainsi spécifié est également en cours de réalisation comme complément de l’outil CASE Objecteering commercialisé par notre partenaire.

 Imprimer  E-mail

Langages d’architectures logicielles semi-formels et formels

Problématique et état de l’art

De nombreux langages de définition d’architectures logicielles ont été définis depuis une dizaine d’années. Ils permettent d’une part de définir des configurations comportant des composants et des connecteurs et d’autre part de décrire la communication entre les composants via les connecteurs. Cette communication est souvent décrite à l’aide d’un langage formel basé sur une algèbre de processus tel que CSP (Wright). Le comportement des composants est en général peu formalisé, seule l’interface des ports de communication étant donné (UML2.0). L’inconvénient de ces langages est d’une part qu’ils ne permettent pas de décrire dans un cadre unique tous les aspects d’une architecture et d’autre part que les parties semi formelles ne disposent pas d’outils de validation et de vérification performants. Cependant, la version standardisée en mars 2003 d’UML 2.0 semble s’imposer aujourd’hui comme langage de description d’architectures logicielles.

Contributions


Notre objectif est de proposer des outils d’aide à la conception d’architectures logicielles. Nous nous basons sur le standard UML 2.0. Pour proposer des outils de validation et de vérification, notre idée est de traduire les différents diagrammes UML dans le cadre unique d’une spécification B et d’utiliser après les outils existants de vérification et validation. Nous avons ainsi dans un premier temps décrit la transformation de diagrammes de classes et de transition UML en B. Puis nous avons défini la traduction des expressions formelles OCL qui en UML sont décrites comme des étiquettes et ne sont pas prises en compte par les outils. Les traductions des expressions OCL viennent s’insérer dans une spécification B là où il faut. Ce qui nous reste à faire à présent est de traduire la notation spécifique pour l’expression des architectures. Il faut pour cela proposer une description en B des notions de composants et de connecteurs.

Résultats

L’outil UML/OCL2B d’aide au développement intègre une approche basée à la fois sur les méthodes semi formelles et formelles afin d’améliorer la qualité des logiciels.

A partir de diagrammes de classes UML annotés de contraintes OCL et de diagrammes états-transitions, notre outil UML/OCL2B permet de générer automatiquement des spécifications formelles en B. L’utilisateur peut ainsi manipuler parallèlement la représentation semi formelle et la spécification formelle automatiquement générée. L’apport principal de notre outil est de proposer une aide aux développeurs en leur facilitant la validation de leurs modèles UML en validant leurs traductions en B.

Un prototype a été implémenté supportant le format d’échange standard XMI pour les modèles UML, en particulier ceux générés par l’outil commercialisé UML Objecteering Modeller [1] . La traduction de UML vers B est réalisée par un outil de transformation écrit en Ocaml.

 Imprimer  E-mail

Expression et prise en compte des besoins non fonctionnels

Problématique et état de l’art

La conception de l'architecture logicielle d'un système est considérée une étape critique dans la construction des systèmes logiciels qui doivent répondre à des propriétés précises de qualité, telles que la sécurité, l’intégrité, la fiabilité, l‘efficacité et l’évolutivité. Les méthodes existantes telles que celles de J. Bosch, ATAM (Architecture Tradeoff Analysis Method) et UP (Unified Process) ne permettent pas la construction systématique d’architectures logicielles en prenant en compte les besoins non fonctionnels. Or ce sont ceux qui orientent vraiment la conception architecturale. Un des problèmes auquel nous sommes confrontés pour prendre en compte les besoins en terme de critères de qualité pendant les étapes du développement est le fait que nous manquons de méthode appropriée de mesure de ces qualités. La spécification, le choix et l'évaluation des critères de qualité d'une architecture sont les aspects cruciaux, autant au niveau statique que dynamique. Bien que la communauté scientifique des architectures logicielles ait formulé plusieurs propositions en ce sens dans les organismes tels que l’ISO (International Standard Organization), l’OMG (Object Management Group ) ou l’IEEE (Institute of Electrical and Electronics Engineers), très peu parlent de la mesure. Ceci est en partie du au fait que, d'une part les normes ne sont pas directement applicables et d'autre part, qu’il manque de méthodes appropriées de mesure. Ceci entraîne que, dans le domaine de l'architecture logicielle, les pratiques habituelles exigées par le génie logiciel sont difficiles à appliquer.

Contributions


La conception d’architectures logicielles doit être guidée par les propriétés non fonctionnelles. Ceci implique d’une part de pouvoir exprimer les besoins et d’autre part de savoir évaluer une architecture de telle manière à permettre à l’utilisateur de faire les choix en fonction de priorités données aux propriétés non fonctionnelles requises. Nous avons défini une méthode basée sur des attributs de qualité permettant d'évaluer une architecture. Ces attributs sont explicitement introduits dans une architecture décrite en UML 2.0. L'étude des critères de comparaison permet de sélectionner un pattern à appliquer lors du développement d'un système distribué. L'utilisation de ces attributs de qualités permet également de guider la reconfiguration dynamique d'une architecture.

Résultats


Le développement de systèmes distribués requiert l’expression des besoins non fonctionnels et leur prise en compte lors de la conception architecturale. Pour valider la méthode proposée, nous avons étudié un système de travail collaboratif dans un réseau sans fil ad hoc. Pour aider à la conception de son architecture nous avons été amenés à compléter les patterns d’architecture de systèmes distribués existants afin de décrire les propriétés non fonctionnelles prises en compte par chacun des patterns.

 Imprimer  E-mail

Our website is protected by DMC Firewall!