Utilisation des sondes dans UML

Après avoir présenté le profil Probe_profile, nous illustrons dans cette section les différents stéréotypes introduits sur deux exemples concrets de sondes. Le premier est un exemple simple traitant le cas d'une sonde élémentaire. Le deuxième est un exemple plus complexe manipulant les trois mécanismes de définition de la portée d'une sonde (la projection, la dérivation et la composition de sondes).

IV.3.3.3.1. Exemple d'utilisation des sondes élémentaires

Soit Ma_Classe une classe désirant se servir d'une sonde pour détecter les signaux startReparation envoyés par le chef d'agence. La démarche à suivre pour mettre en œuvre l'observation est la suivante :

1. Instancier la classe de sondes assortie au type de l'événement à observer. Il s'agit dans ce cas de la classe SignalSendProbe. Nous avons nommé cette instance startRepObs. Cela est réalisé en déclarant une InstanceSpecification et puis en la stéréotypant par « probe ».

2. Spécifier le filtre de la sonde en décrivant les contraintes à vérifier sur les attributs et méta-attributs associés au type de sonde utilisé. Dans notre exemple, nous avons deux contraintes à appliquer sur les attributs observedSignal et sender.

3. Déclarer une référence à la sonde startRepObs dans la classe utlisatrice de la sonde Ma_Classe. Cela est réalisé en déclarant une réception dans la classe et puis en la stéréotypant par

« probeUse ».

4. Utiliser la sonde dans la spécification du comportement de Ma_Classe au sein de sa machine à états.

La Figure IV.23 donne un aperçu général de l'utilisation de la sonde startRepObs dans la description du comportement de Ma_Classe. La Figure IV.23-a illustre la définition de la sonde startRepObs, la Figure IV.23-b présente le référencement de la sonde startRepObs par Ma_Classe, et la Figure IV.23-c montre l'utilisation de la sonde par la machine à états associée à la classe Ma_Classe.

- 113 - Figure IV.23. Principe général d'utilisation d'une sonde

IV.3.3.3.2. Exemple d'utilisation des sondes composées

Dans cet exemple, nous allons construire la sonde Verif_preReparation, qui est une sonde composée de trois sondes élémentaires. Deux d'entre elles sont de type SignalSendProbe et la troisième est de type AttributeChangeProbe. Il s'agit d'observer le système pour récolter les informations nécessaires pour pouvoir débuter la réparation d'une voiture. Nous proposons pour cette observation les contraintes suivantes :

- (c1) La permission de réparation d'une voiture peut être donnée soit par le chef d'agence soit par le responsable d'unité.

- (c2) Il faut vérifier si la réservation des outils et des pièces de rechange est faite ou pas. - (c3) Au moment de la réalisation du comportement, il faut sauvegarder la date de l'émission

de l'ordre et le responsable de cet ordre.

Pour répondre à ce besoin, nous déclarons les sondes suivantes :

startRepObs.filter = " Context startRepObs : SignalSendProbe inv : self.observedSignal.oclIsTypeOf(startReparation)

and self.sender.oclIsTypeOf(ChefAgence) "

(a) : Définition de la sonde

(b) : Référencement de la sonde

- 114 -

¾ ordre_RA_Rep_Obs. Cette sonde, de type SignalSendProbe, détecte l'envoi du signal ordreRA_Rep_Ok qui désigne l'accord du responsable de l'atelier pour débuter la réparation.

¾ ordre_CA_Rep_Obs. Cette sonde, de type SignalSendProbe, détecte l'envoi du signal ordreCA_Rep_Ok qui désigne l'accord du chef de l'agence pour débuter la réparation. ¾ reservation_Materiel. Cette sonde, de type AttributeChangeProbe, détecte le changement de

l'attribut booléen reservationOutil de la classe Voiture quand il passe de la valeur false à true ; il indique que la demande de réservation des outils et des pièces de rechange nécessaires à la réparation est assurée.

La définition des trois sondes élémentaires pré-citées suit la même démarche utilisée dans l'exemple de la sous-section précédente.

¾ Verif_preReparation est la nouvelle classe de sondes à créer pour composer les trois sondes précitées. Le processus à suivre pour définir cette nouvelle classe de sondes est le suivant :

o Dériver la classe Probe (la classe racine de la bibiothèque ProbeLibrary) ; le nom de la classe dérivée est Verif_preReparation ;

o Stéréotyper la classe dérivée par « classProbe » et affecter à l'attribut isComposite la valeur true ;

o Compléter la classe dérivée par les attributs/opération en cas de besoin. Dans notre exemple, on ajoute deux attributs dateOrdre et responsable pour répondre à la contrainte (c3) ;

o Déclarer au sein de la classe dérivée des références aux trois sondes élémentaires ordre_RA_Rep_Obs, ordre_CA_Rep_Obs et reservation_Materiel en se servant du stéréotype « probeUse » ;

o Développer la machine à états représentant les conditions de composition des trois sondes et puis l'associer à l'opération projection(). Arrivant à ce stade du processus, la classe de sonde Verif_preReparation est désormais prête à être instanciée ;

o Instancier la nouvelle classe. Nous avons nommé cette instance "s".

La Figure IV.24-a illustre la définition des trois sondes élémentaires ordre_RA_Rep_Obs, ordre_CA_Rep_Obs et reservation_Materiel. La Figure IV.24-b illustre la définition et l'instanciation de la classe Verif_preReparation, et la Figure IV.24-c illustre la machine à états associée à l'opération projection() de cette sonde composée Verif_preReparation.

- 115 -

Figure IV.24. Définition de la sonde composée Verif_preReparation (a)

(b)

(c)

ordre_RA_Rep_Obs.filter =

" Context ordre_RA_Rep_Obs : SignalSendProbe inv : self.sender.oclIsTypeOf(ResponsableAtelier)

and self.observedSignal.oclIsTypeOf(ordreRA_Rep_Ok) "

ordre_CA_Rep_Obs.filter =

" Context ordre_RA_Rep_Obs : SignalSendProbe inv : self.sender.oclIsTypeOf(ChefAgence)

and self.observedSignal.oclIsTypeOf(ordreCA_Rep_Ok) "

reservation_Materiel.filter =

"Context reservation_Materiel : AttributeChangeProbe inv : self.object.oclIsTypeOf(Voiture)

and let m:Voiture = self.object.oclAsType(Voiture) in m.reservationOutil.value=true

" (a)

- 116 -