Modélisation du système Train-Gate-Controller en UML/OCL

La description des propriétés du système, est une activité décisive pour assurer qu’un produit sera correct dans le future. La consistance du système dépend de l’habilité des concepteurs pour mettre en place toutes les propriétés qui définissent le comportement du système avec un risque zéro.

Cependant, une description détaillée du système TGC est donnée dans [EN97, JS00, Be96]. Cette description inclus la connaissance du domaine comme un élément très important pour la spécification formelle du système. Le système TGC, considérée comme une application répartie en trois sous-systèmes : le train qui est un système qui se déplace sur des rails d’un point (disons) de départ vers un autre point (disons) d’arrivée de façon continue. Donc, nous considérons que le train contient en son sein un dispositif de communication qui peut envoyer des messages renseignant sur sa position sur un tronçon de rail. Un contrôleur automatique utilisé pour manipuler une barrière automatique lui donnant des ordres de mouvement d’une position précise (position de repos) vers le haut, et dans le cas opposé un ordre de mouvement vers le bas lui est intimé vers la position de repos. Le système contrôleur-barrière se trouve à proximité de toute intersection d’une route usagée pour véhicule et une autre (rails) pour les trains. La zone d’intersection est appelée la zone dangereuse, qu’on appellera aussi la zone de passage. Le troisième sous-système étant un système de contrôle centralisé.

8.5.1 L’approche de modélisation par le langage UML

Donc, selon ce qui vient d’être cité, le système étant constitué de trois sous-systèmes qui communiquent entre eux. Le système complet est décrit par le diagramme de classe de la Figure 8.12. Pour ne pas trop tergiverser sur le fonctionnement du système complet qui est formé de trois sous-systèmes, une attention particulière est donnée dans la Figure 8.11 et 8.12. Le lecteur ne trouvera aucun difficulté à comprendre l’architecture mais aussi le fonctionnement c’est-à-dire son comportement. Nous comprendrons mieux tous les aboutissants à travers les règles OCL

123

8.5.2 Spécification de Contraintes en OCL

L’utilisation d’un langage unifié et standardisé permet d’outre passer toutes les divergences au sein d’un groupe de concepteurs qui en général possède des connaissances diverses touchant pratiquement à plusieurs disciplines. Comme nous l’avons vu, l’idée de l’utilisation du langage OCL, permet d’associer des contraintes aux objets d’un système pour qu’il soit spécifié formellement, préservant toutes les caractéristiques structurelles et dynamiques du système. Cette manière de représentation permet ainsi d’associer le formel avec le graphique, ce qui à coup sûr permet d’éviter l’incompréhension, l’ambiguïté et ainsi assuré l’exactitude de la spécification, et de traiter des problèmes très complexes sans risque majeur. Nous avons vu, qu’OCL met en place des mécanismes d’écriture assurant la référence aux éléments des classes, à la notion de typage, à la représentation de contraintes sous forme de pre et post-conditions, à l’expression de caractéristiques du temps etc.

Dans ce qui suit, nous montrons certaines recommandations du langage OCL, pour spécifier un certain nombre de propriétés de notre système, à savoir le TGC (train-gate_controller). Nous commencerons par exemple par les propriétés qui expriment la sûreté du système du moins certains comportements du système (Safety).

Comme la propriété la plus importante du système étant de préserver le trafic routier d’un côté et de permettre au train de passer sur la zone dangereuse (l’intersection) sans encombre, cependant à un niveau d’abstraction (élevé) de la spécification de control, il est tout à fait suffisant de modéliser la zone du passage à niveau et la barrière automatique et ceci à tout instant.

Les contraintes OCL suivantes (invariants) spécifient ce qui suit (voir Figure 8.15) : 1. S’il existe un train traversant la zone d’intersection alors la barrière doit être fermée :

context CrossingArea inv:

not(self.train ->isEmpty()) implies self.barrier.state=Closed 2. Si la barrière automatique est ouverte alors aucun train ne s’est approché de la zone dangereuse :

context Barrier inv:

self.state=Opened implies self.guards.train ->isEmpty() 3. La barrière automatique doit être fermée lorsqu’un train passe sur la zone dangereuse :

context PhysicalTrain inv: self.crosses.barrier=Closed

Ces contraintes doivent être respectées (vraie). Pour le moment il n’est pas nécessaire d’expliquer physiquement comment l’avant des trains et leurs queues sont détectées pour connaître les positions de certaines variables du modèle de spécification soient vrais. Ceci n' a pas une très grande importance pour le moment, il suffit pour le moment que le train s’approche de la zone, qu’il soit dans la zone ou bien qu’il soit sorti de la zone.

La spécification des positions (états) de la barrière peut être décrite par les contraintes OCL suivantes (Figure 8.12):

4. Le feu rouge est allumé (switched on) chaque fois que la barrière est fermée et que le feu jaune soit allumé lorsque la barrière se ferme. Si le feu rouge et le feu jaune sont éteints alors la barrière est ouverte:

context TGC System inv:

self.theBarrier.state=Closed implies self.redLight.state=On and

self.theBarrier.state=Closing implies self.yellowLight.state=On and

124

implies self.theBarrier.state=Opened

Figure 8.12 : Diagramme de Class du TGC

5. Lorqu’il reste encore un train dans la zone dangereuse, l’état level crossing est en position activated state. La variable activated state est composée de trois sous-états (WaitingAck, Closing, Closed, Opening) :

context TGC System inv:

not(self.train ->isEmpty()) implies self.state=Activated and

Set(Activated)=Set(WaitingAck->Union(Closing)->Union(Closed)-> Union(Opening))

6. Lorsque le système TGC est positioné à activated state et la barrière soit ouverte alors l’état level crossing est en mode unsafe :

context TGC System inv:

self.state=Activated and self.bSensor.state=Opened implies self.mode=Unsafe

7. Si la barrière est fermée alors que le sensor indique que la barrière est ouverte alors l’état the level crossing est dans le mode unsafe. Ceci, ne se fait que si la barrière soit dans l’état « entrain de se fermer », dans ce cas le système reste unsafe jusqu’à ce que la barrière soit complètement fermée. :

context TGC System inv:

self.bSensor.state=Opened and self.theBarrier.state=Closed) implies self.mode=Unsafe

Les opérations de la classe TGC sont spécifiées avec les pré- et post-conditions de l’OCL.

OCL est aussi utilisé pour la spécification des contraintes dans le diagramme de séquences pour l’écriture des pre-conditions et des invariants sur les opérations (diagramme de séquence train approaching). Par contre le diagramme des états est utilisé pour dériver une première spécification de chaque opération. Dans ce cas les contraintes OCL sont d’une importance capitale pour donner plus de précisions aux informations qui ne peuvent pas figurées sur le diagramme d’état.

125