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

5.2 Bilan de l’activité de validation des modèles 147
En suivant ces recommandations, on parvient à retrouver dans Cecilia TM Arbor les probabilités
des évènements élémentaires présents dans les arbres et la probabilité de l’évènement
redouté de haut niveau. Par contre et étant donné que l’arbre est sous-forme de « râteau », on
perd la représentation et la probabilité des évènements intermédiaires présents dans les arbres de
défaillance.
Remarque : L’arbre représentant les séquences générées par le modèle peut être vu d’une certaine
manière comme une « mise à plat » de l’arbre de défaillance disponible dans les
analyses de sécurité actuelles.
5.2.3 Vers l’utilisation du processus de validation proposé
Nous avons proposé au chapitre 4 un processus visant à valider le comportement du modèle
AltaRica et plus particulièrement des nœuds d’une bibliothèque. Nous rappelons qu’il est composé
de trois étapes principales : la validation unitaire (i.e. la validation de la bibliothèque de nœud
AltaRica), la validation de l’intégration et la validation globale (figure 4.2).
Ce processus concerne surtout la validation unitaire. Nous avons alors vu que potentiellement,
la validation d’un nœud peut nécessiter l’introduction d’un nombre important de modifications
(section 4.6) dans le code AltaRica implémentant le nœud. N’ayant alors pas d’outil
supportant l’écriture automatique de ces modifications (section 4.7.3), celui-ci n’a pas été au
cours de ces travaux déployé à une échelle importante. Ainsi, seul le principe général de l’approche
a été étudié en l’appliquant à un nœud AltaRica unitaire. L’intégration des nœuds entre eux ainsi
que le modèle global n’ont pas été validé de la sorte.
Nous montrons ici l’application du processus au composant Valve dont le code est présenté
figure 2.6. Une spécification typique du comportement d’une telle valve est présentée figure 2.1.
De ce schéma, on tire sans grande difficulté et en suivant le principe de l’exemple page 116 un
ensemble de tests T composé de plusieurs scénarios de test :
– des scénarios permettant de s’assurer que les comportements spécifiés sont correctement implémentés
: {∅}, {Blocage}, {Fermeture}, {Fermeture, Ouverture}, {Fermeture, Blocage} ;
– des scénarios permettant de s’assurer que les comportements non spécifiés ne sont pas
implémentés : {Ouverture}, {Blocage, Ouverture}, {Blocage, Fermeture}, {Blocage, Blocage},
{Fermeture, Fermeture}, {Fermeture, Blocage, Fermeture}, {Fermeture, Blocage,
Ouverture} et {Fermeture, Blocage, Blocage}.
Pour rappel, les transitions implémentant ce comportement sont les suivantes :
trans
bloque=false |- Blocage -> bloque :=true ;
etat=ouverte and bloque=false |- Fermeture -> etat :=fermee ;
etat=fermee and bloque=false |- Ouverture -> etat :=ouverte ;
Imaginons pour présenter le principe de l’approche que l’analyste en charge de l’implémentation
fasse une erreur et implémente de la façon suivante (la fermeture et l’ouverture peuvent
alors avoir lieu même après blocage de la valve) :