D32 Provers

From Event-B
Revision as of 15:04, 11 November 2010 by imported>Wohuai (New page: === Overview === Concerning Rodin's provers the following contributions have been made: * Jann Röder (ETH Zurich) developed a relevance filter plug-in. The plug-in provides a proof tactic...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Overview

Concerning Rodin's provers the following contributions have been made:

  • Jann Röder (ETH Zurich) developed a relevance filter plug-in. The plug-in provides a proof tactic that first removes hypotheses from a given sequent according to several heuristics. The tactic then inputs the reduced sequent to one or several of Rodin's external provers (PP, newPP, ML). Jann Röder carried out experiments using Event-B models from different domains and observed that his tactic significantly increases the number of proof obligations proved automatically.
  • Matthias Schmalz (ETH Zurich) worked out the theoretical foundations of Event-B's logic. "Event-B's logic" stands for the formalism in which, e.g., guards, invariants, axioms, and theorems are expressed, and proof obligations are expressed and proved. He provides a comprehensive specification of syntax, semantics, proofs, theories, and mathematical extensions in one document. The document encompasses a small theory "Core" and shows how to define the remaining operators, types, and binders available in Rodin using mathematical extensions. The document thus provides a proof calculus for Event-B that is sound by construction, and a methodology for reasoning about the soundness of Event-B proof rules within Event-B. The document also allows users to look-up definitions of predefined operators and binders, answering questions like "what is the meaning of x \div y if x or y is negative". For developers, it sheds some light on intricate questions concerning partial functions, e.g., why is it sound to rewrite x \in \{y \mid \varphi(y)\} to \varphi(x) but unsound (in general) to rewrite \varphi(x) to x \in \{y \mid \varphi(y)\}.

Motivations

This paragraph shall express the motivation for each tool extension and improvement. More precisely, it shall first indicate the state before the work, the encountered difficulties, and shall highlight the requirements (eg. those of industrial partners). Then, it shall summarize how these requirements are addressed and what are the main benefits.

Choices / Decisions

This paragraph shall summarize the decisions (eg. design decisions) and justify them. Thus, it may present the studied solutions, through their main advantages and inconvenients, to legitimate the final choices.

Available Documentation

This paragraph shall give pointers to the available wiki pages or related publications. This documentation may contain:

  • Requirements.
  • Pre-studies (states of the art, proposals, discussions).
  • Technical details (specifications).
  • Teaching materials (tutorials).
  • User's guides.

A distinction shall be made on the one hand between these different categories, and on the other hand between documentation written for developers and documentation written for end-users.

Planning

This paragraph shall give a timeline and current status (as of 28 Jan 2011).