Correction des modèles Event-B

Dans cette section, nous allons examiner les techniques permettant de vérifier la correction de modèles Event-B.

2.4.3.1 Preuve

L’un des points d’orgue d’Event-B est la preuve de correction des modèles. En effet, un modèle Event-B est dit correct si les obligations de preuve (OP) associées sont prouvées (ou déchargées). Plus précisément, une OP est un séquent dont on doit fournir une démonstra- tion pour vérifier un critère de correction sur le modèle. Ces obligations de preuve concernent différents aspects du modèle tels que la vérification des propriétés d’invariance d’une ma- chine Event-B ou la preuve de la correction d’un raffinement ou encore pour prouver que

les propriétés de la clause theorems sont correctes. Elles sont confiées aux prouveurs in- ternes et externes de la plateforme Rodin dédiée à Event-B. Une fois prouvée, une étiquette est attribuée à chaque obligation de preuve pour des raisons de traçabilité. Cette étiquette renseigne sur la provenance de l’obligation de preuve (théorème, invariant, renforcement de garde, simulation d’action, . . . ).

2.4.3.2 Vérification comportementale à l’aide de ProB

ProB [39,49] est un outil incontournable pour un développement formel. Il permet l’ani- mation, le model-checking des propriétés de sûreté et d’absence de blocage, le model-checking des propriétés de vivacité, la vérification de la correction de la relation de raffinement, la ré- solution de contraintes et la contre-preuve. L’outil ProB supporte plusieurs formalismes tels que B, Event-B, Z, CSP et TLA+. ProB complète l’activité de preuve supportée par Event-B. En effet, les propriétés de sûreté (établissement de l’invariant et préservation de l’invariant) et la vérification formelle de la correction de la relation de raffinement sont couvertes par des obligations de preuve standards définies par la théorie Event-B [8] et implémentées dans la plateforme Rodin [9, 10]. Mais l’intégration des propriétés de vivacité dans Event-B sous forme d’obligations demeure un challenge. En effet, le travail décrit dans [41] propose des obligations de preuve couvrant plusieurs types de propriétés de vivacité tels que : Eventually, Until, Progress et Persistence. Cependant, l’expression directe de ces propriétés de vivacité n’est pas actuellement supportée par la plateforme Rodin. Le model-checker temporel ProB apporte une solution générique pour la description et la vérification des propriétés de vivacité. Pour y parvenir, il propose un langage puissant pour la description des propriétés temporelles LTLe [58]. Ce dernier englobe :

— trois types des propositions atomiques : orientés état au sens LTL, orientés transition comme e(evt) qui teste si l’événement evt est couramment franchissable et orientés occurrence d’événement comme [evt] qui teste si evt a été exécuté dans l’instant sui- vant.

— des opérateurs logiques : not, &, or et ⇒.

— des opérateurs temporels tels que G(Globally), F(Finally), X(neXt), U(Until) et

W(Weak until).

— des opérateurs d’équité tels WF et SF [46].

Notons au passage que le langage LTLede ProB fournit plusieurs propositions atomiques liées au blocage d’un ensemble d’événements (deadlock(evt1,evt2,...,evtk)), au déterminisme externe (deterministic(evt1,evt2,...,evtk)) et à la controlabilité (controller(evt1,evt2,...,evtk)). De plus, ProB est doté d’un solveur de contraintes permettant entre autres la vérification de la cohérence des axiomes associés aux constantes. Par exemple, pour le contexte Fibonacci (voir le listing2.12), qui définit en Event-B la suite de Fibonacci, ProB permet de vérifier la cohérence de cette formalisation et génère les n+1 premiers nombres de Fibonacci. De plus, le théorème @fibo_trie est déchargé par le contre-prouveur ProB [39,49].

2.4.3.3 Animation et simulation

La validation d’un modèle Event-B est relative aux attentes de l’utilisateur supposées décrites dans le cahier des charges. Un modèle Event-B correct vis-à-vis de la théorie Event- B n’est pas forcément valide. En effet, les critères de correction introduits par Event-B ne couvrent pas toutes les classes d’erreurs : oublis des fonctionnalités, mauvaise compréhension des besoins, propriétés dynamiques. Pour y parvenir, on peut utiliser avec profit des outils de validation associés à Event-B. Contrairement aux outils de preuve, ces outils permettent

une certaine exécution des modèles Event-B. Ceci, avec l’aide de l’utilisateur final, permet de détecter des erreurs non couvertes par l’analyse statique des prouveurs.

En Event-B, l’activité de validation permet de vérifier la correction des modèles vis-à-vis du cahier des charges. D’une façon générale, un outil de validation permet l’exécution des modèles Event-B à la recherche de contre-exemples. Un contre-exemple traduit forcément la présence des erreurs dans les modèles Event-B traités. Ces erreurs peuvent provenir des défauts de modélisation (incohérence des axiomes, oublis, cas non traités ou mal compris dans le cahier des charges), ou des défauts de conception introduits lors des étapes de raffinement. La plateforme Rodin est dotée d’outils de validation à base d’animation tels que AnimB [53] et ProB [39,49] permettant l’exécution de modèles formels Event-B en explorant d’une ma- nière exhaustive l’espace d’états des modèles construits. En effet, de point de vue pratique, le fonctionnement de tels outils repose sur trois phases à savoir : évaluation des gardes, calcul de l’ensemble d’événements permis (ou accessibles ou franchissables) et finalement exécution proprement dite de l’événement choisi par l’utilisateur.

D’autres outils de validation à base de simulation permettent de transformer des modèles Event-B vers des programmes écrits en langage Javascript supportés par des environnements Web. Pour l’exécution des modèles après leur traduction, les simulateurs reposent sur les trois phases assurées par les outils d’animation comme décrits ci-dessus. Le simulateur JeB [82,83] génère et exécute des simulations de modèles Event-B.