La création des instances APAM :

COMPASS-RT crée directement ou par résolution l instance composite APAM

(Composite correspondant à l instance composite de l application :

i) Si le modèle d application contient l instance composite de l application COMPASS

-RT crée directement l instance composite APAM correspondante Pour ce faire il crée directement l instance APAM correspondante à l instance principale mainInst)

instances APAM correspondantes aux instances contenues dans l instance composite dont la propriété d activation est définie comme immédiate, et les ajoute/lie à

l instance composite APAM créée

ii) Sinon, COMPASS-RT déclenche la résolution de l implémentation composite de l application afin d obtenir une instance composite APAM avec son instance

principale APAM (obtenue aussi par résolution). COMPASS-RT effectue directement la résolution si la propriété de résolution est définie comme contrainte, autrement il délègue la résolution au résolveur APAM.

En outre, COMPASS-RT déclenche la résolution des implémentations contenues dans

l implémentation composite dont la propriété d activation est définie comme immédiate et ajoute lie les instances APAM issues de la résolution à l instance composite APAM Le modèle d état d exécution d une application démarrée contient donc les composants

indispensables et immédiats mappés à leur composant APAM correspondant.

Une fois une application démarrée, son exécution est pilotée et gérée par APAM à l aide de l ensemble des gestionnaires disponibles COMPASS-RT y compris.

2.2.2 G

COMPASS-RT, étant un gestionnaire de type DependencyManager, contrôle et réalise la résolution des services requis par une application lors de leur demande.

COMPASS-RT contrôle la résolution d un service via le chemin d ordre de délégation suivi par

APAM : le resolutionPath ; et via les propriétés, les contraintes et les préférences de résolution à

satisfaire En effet afin d établir le resolutionPath lors de la résolution d un service APAM interroge les

gestionnaires de type DependencyManager : chaque gestionnaire signale sa position dans le

resolutionPath ainsi que ses contraintes et ses préférences pour la résolution en question. COMPASS-RT se positionne en première position dans le resolutionPath si la propriété de résolution du service à résoudre (propriété gérée par COMPASS-RT) est spécifiée comme fermée. Sinon, il se place derrière APAMMan et OBRMan (si disponibles). APAM demande donc la résolution du service aux gestionnaires

dans l ordre établi par le resolutionPath.

COMPASS-RT réalise la résolution d un service suite à la demande transmise par APAM. Il

résout un service d abord dans le modèle d application correspondant car celui peut contenir des

services déjà sélectionnés (résolus) mais qui ne sont pas encore activés sur la plate-forme d exécution ;

ensuite si la résolution dans le modèle d application n a pas réussi il résout dans l espace de travail

COMPASS-RT peut donc sélectionner un composant contenu dans le modèle d application ou dans l espace de travail ou il peut le créer à l aide d une fabrique. Pour un composant sélectionné/créé, COMPASS-RT crée le composant APAM correspondant résultat de la résolution l ajoute au modèle d état de l application et établit ses correspondances avec les composants correspondants de l espace

de travail et APAM. La résolution des services requis par une application gérée par COMPASS-RT est

réalisée ainsi en conformité à son modèle d application

De plus, COMPASS-RT vérifie et garantit la conformité de l exécution d une application vis-à-vis de son modèle d application.

En effet en plus d être un gestionnaire de type DependencyManager, COMPASS-RT est de type

PropertyManager et DynamicManager. Il est donc notifié par APAM des changements (ajout, suppression, modification) des propriétés des composants APAM, ainsi que de leur retrait du modèle

d état

Ainsi suite à la notification du changement d une propriété d un composant participant à une

application gérée par COMPASS-RT, il vérifie si le composant en question satisfait toujours les propriétés, les contraintes et les préférences de l application spécifiées dans son modèle d application

2.E

Lorsqu un composant ne satisfait plus les propriétés de lapplication à laquelle il participe, ou

lorsqu un composant participant à une application est retiré de la plate-forme d exécution COMPASS

-RT retire le composant avec ses liaisons du modèle d état actuel de l application et si nécessaire du modèle d état géré par APAM

Toutefois le gestionnaire DynaMan propose différentes stratégies pour l adaptation dynamique d une application suite à l apparition à la disparition ou à l échec de la résolution d un composant Par exemple suite à l échec de la résolution d un composant fail ou à la disparition d un composant participant à une application l application peut être mise en attente (wait jusqu à l apparition d un

fournisseur approprié, ou une exception spécifique peut être levée.

2.2.3 E

COMPASS-RT supporte l évolution dynamique d une application au travers de modifications

dans son modèle dapplication (top-down Le but de l évolution dynamique est de corriger ou de

perfectionner une application pendant son exécution.

Lévolution des applications s est déplacée ces dernières années du code source aux modèles des

architectures logicielles (architecture-centric evolution). En effet, le code source ne peut pas fournir

une vue complète d une application ni refléter les décisions originales de conception Les modèles des

architectures logicielles fournissent ainsi une base plus gérable et plus efficace pour l évolution des

applications ils permettent de changer des éléments logiciels d une application tels que des

composants et des connecteurs entre composants.

Le modèle d application proposé dans notre approche possède des informations sémantiques et

structurelles d une application Ainsi afin de faire évoluer une telle application des modifications

apportées dans son modèle d application à différents niveaux d abstraction spécification

implémentation et instance).

L évolution dynamique dune application est cependant un processus complexe sujet à erreurs. COMPASS-RT implémente le processus suivant pour l évolution d une application :

 la vérification de la validité des modifications à effectuer détection d erreurs de syntaxe

par exemple),

 la vérification de la conformité et la cohérence entre les différentes architectures du

modèle d application i e la détection d erreurs incohérences de sémantique et de structure et la propagation de modifications i e l adaptation des architectures), et

 la projection des modifications du modèle d application sur le modèle d état i e l adaptation des architectures d exécution de l application

COMPASS-RT permet de faire évoluer une application grace aux modifications suivantes effectuées au niveau spécification implémentation et ou instance du modèle d application :

 modifications sémantiques : ajout, modification et suppression de contraintes et de préférences contextuelles.

 modifications structurelles : ajout et retrait de composants et de liaisons entre composants.

De telles modifications conçues par l architecte ou par l administrateur de l application sont

vérifiées et validées par COMPASS-RT afin de les réaliser effectivement dans le modèle d application

Ces modifications, dites externes sont donc responsabilité de l architecte et ou de l administrateur de l application

Toutefois, même si elles sont valides ces modifications peuvent entraîner l érosion

architecturale78 du modèle d application En effet une modification réalisée à un niveau d abstraction

peut affecter les autres niveaux et doit donc être propagée (par exemple, une modification effectuée au niveau spécification entraîne en général des modifications aux niveaux implémentation et instance).

COMPASS-RT réalise la propagation de modifications, guidée par les relations de conformité et de

cohérence entre les architectures afin d éviter l érosion architecturale du modèle d application et de

garantir sa validité.

Une fois un modèle d application validé, COMPASS-RT projette les modifications nécessaires sur le

modèle d état de l application afin de le rendre conforme au modèle d application Toute modification dans le modèle d état géré par COMPASS-RT entraîne une modification dans le modèle d état géré par

APAM car liés causalement provoquant donc l adaptation de l architecture de l application en cours d exécution

Grâce à l information contenue dans un modèle d application et aux fonctionnalités fournies par

COMPASS-RT, des activités de conception et de développement peuvent être réalisées à l exécution entraînant donc l évolution dynamique de l application

3 SYNTHESE

Nous avons présenté la mise en œuvre de notre approche à travers de notre système COMPASS

Nous avons détaillé les environnements qui le composent : COMPASS-CADSE qui supporte la conception et le développement d applications, et COMPASS-RT qui supporte leur exécution.

Notre système, en suivant les principes du génie logiciel, a comme caractéristiques principales la modularité, l extensibilité et la séparation des préoccupations.

78 L érosion architecturale est causée par des modifications réalisées dans une architecture qui violent les

CHAPITRE