Méthodes pour la validation de modèles formels pour la ... - ISAE

3.8 Formalisation des données extraites 95
On représente en fait sur ce tableau 3.7 les modes de défaillance sur les sorties des composants.
Un avantage de cette méthode est la mise à disposition de scénarios de tests quasi-immédiat.
En effet, pour un composant donné, le tableau obtenu nous fournit un ensemble de scénario munis
de déviations d’entrées et / ou de modes de défaillance internes au composant. De ce tableau
également, nous connaissons la sortie attendue du modèle. Il sera donc possible de comparer la
sortie effective du modèle avec l’effet décrit dans la première colonne du tableau.
Cependant, il est difficile à partir de ce formalisme d’appréhender l’historique d’un état du
système, de tracer les scénarios de pannes possibles (i.e. le chemin ayant conduis à telle ou telle
valeur de sortie). De plus et en l’état, ce formalisme est plutôt utilisé pour la représentation du
comportement dysfonctionnel du composant. Pour aller plus loin, différents travaux présentés dans
la littérature se proposent de représenter le comportement (fonctionnel et dysfonctionnel) d’un
système à l’aide de diagrammes états-transitions. On trouvera alors des références utilisant UML,
Statecharts, ou la méthode SCR.
3.8.4 Méthode SCR
La méthode SCR (pour Software Cost Reduction [32]) est à la base une méthode se voulant
permettre de spécifier formellement des exigences sur un système à l’aide d’une représentation
tabulaire. Introduit à l’origine pour décrire les comportements d’un logiciel de manière précise et
non ambiguë, la méthode s’est peu à peu étendue à une gamme plus large de système. Pour aider
à l’application pratique de la méthode, celle-ci est supportée par une suite d’outils incluant par
exemple un éditeur (pour écrire formellement l’ensemble des exigences), un outil de vérification
de la cohérence de cette spécification (pour trouver des « oublis », des cas manquants dans la
spécification), un simulateur interactif, un vérificateur permettant de tester si la spécification
possède une propriété donnée.
Le principe de la méthode SCR a des similarités avec le principe du langage AltaRica.
Brièvement et pour ne présenter que très simplement la chose, un système (ou un logiciel) est
représenté à l’aide de différentes variables. Nous en considérerons trois ici : des variables d’entrée,
des variables de sorties et des variables d’état. La spécification, présentée sous forme tabulaire,
consiste tout d’abord à décrire la logique de changement d’état, pour chaque variable d’état. Le
principe est illustré sur le tableau 3.8.
Remarque : Un remarque au sujet des évènements modélisés. Ils le sont par l’intermédiaire d’un
changement de valeur des variables d’entrée et sont formalisés grâce à une écriture
du type « @T (Changement de l’entrée) ». Dans les exemples vus dans la littérature,
les défaillances propres au système ne sont pas modélisées.
L’exemple est celui d’un système d’alarme observant le niveau d’eau d’une cuve. Le système
reçoit en entrée un signal IN lui indiquant le niveau d’eau (ok, bas ou haut). Le logiciel traite ce
signal et si besoin, renvoie en sortie un signal d’alarme OUT (OUT sera vrai si le niveau est haut
ou bas). Le système possède également une entrée switch lui indiquant s’il est allumé ou éteint
(switch = ON ou OFF).
Valeur de départ Évènement Valeur d’arrivée
ok @T(IN < Seuil bas) bas
ok @T(IN > Seuil haut) haut
bas @T(IN > Seuil bas) ok
haut @T(IN < Seuil haut) haut
Tableau 3.8 – Méthode SCR : Table de transition pour une variable d’état ST