Modélisation des observations

4.2.2.1 Pincipe général

Nous définissons les observations de manière abstraite par rapport à l’architecture afin que cette approche soit réutilisable dans différents systèmes. Une observation se définit par une donnée à récupérer dans un contexte lorsqu’un déclencheur donné est ac-tionné. Dans notre approche nous distinguons la description d’une observation, de l’observation effective (cf. figure 4.5). La description d’une observation (Observation-Description) revient à décrire la donnée à observer (Data(Observation-Description) ainsi que le dé-clencheur (TriggerDescription). Une fois le dédé-clencheur actionné, un objet observation est produit qui contient la valeur observée (Value), la(es) donnée(s) de déclenchement (Trigger), ainsi qu’une référence à sa description (ObservationDescription) au cas où un raisonnement serait nécessaire sur la description de départ.

4.2.2.2 Modèle générique

L’ObservationDescription. La description d’observation,ObservationDescription, est constituée de l’ensemble d’objets présentés dans la figure 4.6. Elle contient

FIGURE 4.4 – Application des Links et Nodes à l’architecture Fractal.

aussi le nom associé à l’observation qu’elle décrit. Elle possède encore la référence de l’élément d’architecture sur lequel porte les observations qu’elle décrit (base

sur la figure 4.6). En effet l’objet des observations est de permettre à une clause de contraindre son responsable dans le système contractualisé. Ainsi chaque de-scription d’observation, toujours associée à la spécification d’une clause, désigne l’élément du système à observer. Cette référence, stockée dans la description, sert de base à la résolution des chemins utilisés dans les DataDescription et

TriggerDescription pour désigner les éléments du système sur lesquels ils portent. LeDataDescriptionest une description de la donnée que doit contenir l’observation réalisée, et qui par défaut ne propose qu’une méthode permettant d’extraire la donnée de la référence de base et duTrigger. Dans l’implémenta-tion spécifique à une plateforme donnée, cette classe sera spécialisée avec le code nécessaire à l’obtention de la donnée pour cette plateforme. LeTriggerDescription

est une description du déclencheur de l’observation. Dans son implémentation pour une plateforme donnée, cette classe sera spécialisée pour s’interfacer avec les outils de monitoring du système contraint (de plus bas niveau, par exemple des outils d’interception des appels de méthodes, etc). Enfin, lesWatchersont les écouteurs de l’observation qui sont notifiés quand celle-ci a lieu et qui présentent cette interface.

FIGURE 4.6 – diagramme de classes de description de l’observation

Fonctionnement.Quand la description duTriggerDescriptionse réalise, alors

un objetTriggerest instancié par cette dernière et transmis à l’ObservationDescription

qui l’utilise pour obtenir du DataDescriptionla valeur qui lui sert à produire l’Observation. Une fois celle-ci obtenue elle est envoyée auxWatcherqui se sont enregistrés auprès de l’ObservationDescription.

TriggerDescription. La description du déclencheur TriggerDescriptiondéfinit la nature de son critère de déclenchement : détection d’événement, etc. Elle con-tient aussi les paramètres configurant ce critère de déclenchement : propriétés de l’événement, etc. Par ailleurs le Trigger contient les données ayant provo-quées le déclenchement, c’est à dire satisfaisant à la nature et aux paramètres du critère du déclencheur (TriggerDescription). Par exemple une nature de dé-clenchement sera l’interception de l’exécution, configurée par le nom de la méth-ode à intercepter. Dans ce cas le Trigger contiendra alors la pile d’exécution ayant provoqué le déclenchement. Nous pouvons remarquer que la cause du dé-clenchement peut être variée dans le temps et la géographie du système contraint. Nous pouvons distinguer différentes origines géographiqes du déclenchement comme illustré sur la figure 4.7 :

FIGURE 4.7 – Origines du déclenchement de l’observation

contient un timer et déclenche une observation à intervalles fixes, il s’agit alors d’un événement mais qui ne sort pas du déclencheur,

• b) déclenchement à origine externe au déclencheur et interne au système : nous considérons que le déclencheur peut réagir à un événement provoqué par le système contraint par le contrat. L’exemple typique est l’interception d’un flot d’exécution du système contraint, ou l’entrée du système contraint dans un état donné,

• c) déclenchement à origine externe au déclencheur et externe au système : le déclencheur réagit dans ce cas à un événement issu de l’extérieur du sys-tème contraint, par exemple un syssys-tème d’observation peut solliciter des observations à différents instants qu’il définit. Ainsi si un système de val-idation externe au système contraint est déclenché par l’utilisateur, il peut demander que des observations soient effectuées pour évaluer des fonctions reflétant des propriétés du système contraint. Typiquement, il s’agit de tests lancés par l’utilisateur à un moment choisi par lui,

Il faut noter que suivant la sémantique des formalismes de spécifications, les con-traintes que ces dernières expriment peuvent porter sur des durées plutôt que sur des instants. L’exemple le plus courant est celui d’OCL [82] dans lequel les invari-ants sont à satisfaire sur des durées. Dans ce cas, c’est dans le cadre de l’interpré-tation du formalisme en termes d’hypothèses et garanties que la traduction de ces durées en événements discrets doit être opérée. Toutefois, il est possible que les observations développées pour une architecture doivent être enrichies pour un formalisme particulier. Par exemple les formalismes de QoS peuvent requérir la mise en oeuvre d’observations diverses ainsi que de sondes.

défini trois classes de Trigger de spécialisation croissante présentées dans la figure 4.8 qui couvrent différentes sources de déclenchement :

• TriggerDescription: décrit un déclencheur sans besoin de communica-tion particulier, ce pourra être le déclencheur à origine interne,

• EventTriggerDescription: décrit un déclencheur qui réagit à des événe-ments dont l’origine peut aussi bien être externe que interne au système contraint,

• InterceptionEventTriggerDescription: décrit un déclencheur qui réagit à des événements issus de l’interception de l’exécution du système contraint (déclencheur à origine interne au système) : il s’agit de l’exécution au sens large, c’est à dire de fonctionnalités aussi bien fonctionnelles (exécution d’in-teractions métier) que non fonctionnelles (action de configuration etc...) du système contraint (pourvu qu’on puisse les observer),

FIGURE 4.8 – Trigger générique

L’InterceptionEventTriggerDescription décrit un déclencheur qui réagit à l’entrée ou à la sortie (getInstant()) de l’exécution d’un élément d’architecture. Celui-ci est désigné, vis à vis de l’élément d’architecture auquel est attachée l’observation, par la résolution du chemin retourné pargetLocation(). Le Triggerqui con-tient les données de déclenchement permet d’accéder au contexte d’exécution, modélisé de manière générique par unObject.

Dans le système Fractal il peut être ainsi spécialisé de deux manières (cf figure 4.9) :

• non fonctionnelle : les déclencheursComponentStartTriggerDescription

etComponentStopTriggerDescriptionréagissent au démarrage ou à l’ar-rêt d’un composant donné, ils sont de la catégorie de déclencheurs sensibles à la configuration du système de composants. L’observation qu’ils décrivent ne contient pas d’autres informations que le composant dont ils notifient le démarrage ou l’arrêt.

• fonctionnelle : le déclencheurFractalInterceptionTriggerDescription

réagit à l’interception d’échanges de messages entre les composants, c’est un déclencheur sensible à l’activité métier du système de composants. L’obser-vation qu’il décrit contient les données relatives à l’exécution qu’il a inter-cepté (paramètres de méthode, référence de l’appelant, de l’appelé etc...).

DataDescriptionDans le cadre de Fractal nous avons défini différents types de don-nées à observer. Il faut toutefois noter que certains peuvent requérir des types de déclencheurs spécifiques, car ces derniers peuvent ne pas fournir tous les mêmes informations :

FIGURE 4.9 – Déclencheurs dédiés à la plateforme Fractal

• ArchitecturalDataDescription: désigne la référence d’un élément d’ar-chitecture par un chemin qui est résolu par rapport à l’élément de référence de l’observation,

• ParameterInterceptionDataDescription: désigne la valeur prise par le paramètre (défini par son index) d’un appel de méthode intercepté, cette de-scription est à utiliser conjointement avec une FractalInterceptionTri-ggerDescriptionen entrée de méthode,

• ReturnInterceptionDataDescription: désigne la valeur de retour d’un appel de méthode intercepté, cette description est à utiliser conjointement avec une FractalInterceptionTriggerDescription en sortie de méth-ode,

• CalleeInterceptionDataDescription: désigne la référence de l’élément d’architecture émetteur de l’appel de méthode intercepté, cette description est à utiliser conjointement avec une FractalInterceptionTriggerDes-criptionen entrée ou sortie de méthode,

• PreInterceptionDataDescription: désigne la valeur d’un paramètre d’en-trée fournie au moment de l’interception de la sortie de la méthode, à utiliser avec une FractalInterceptionTriggerDescription en sortie de méth-ode,

• FormulaInterceptionDataDescription: désigne le résultat de l’évalua-tion d’une formule qu’elle contient, la formule peut réutiliser les résultats d’autres observations associées au même déclencheur, elle est à utiliser avec uneFractalInterceptionTriggerDescription,

Organisation des observations. Les observations sont organisées dans le cadre d’un

ObservationNotificationManagerdécrit dans la figure 4.10. L’objet du Obser-vationNotificationManager est de maintenir synchronisés les observateurs

(Watcher), les requêtes d’observations (ObservationDescription) et les déclencheurs. En effet les contrats comme l’architecture qu’ils contraignent peuvent évoluer dy-namiquement et indépendamment. Le contrat peut évoluer du fait d’une renégo-ciation (c’est à dire la modification d’une spécification), ou du fait de la mod-ification de la configuration architecturale qu’il contraint. La disparition d’un observateur (c’est à dire d’une clause) doit être retransmise jusqu’à l’observa-tion qui le désabonne et la disparil’observa-tion d’une observal’observa-tion, qui par exemple n’a plus d’observateur, doit être propagée aux outils de déclenchement de l’obser-vation (TriggerDescription) et de monitoring (etc). Comme pour des raisons de ressources il est possible que les ressources de déclenchement et de monitor-ing soient partagées par les observations, l’ObservationNotificationManager

intervient comme un mediateur entre eux, afin de garantir qu’une ressource de déclenchement ou de monitoring inutilisée est bien finalement relachée et qu’une description d’observation nouvellement appliquée au système partage des ressources (déclencheur etc...) potentiellement déjà existantes.

FIGURE 4.10 – Organisation des observations