imported>Tommy |
imported>Wohuai |
| Line 1: |
Line 1: |
| − | = Core Platform Maintenance = | + | {{Navigation|Previous= [[The_Event-B_Explorer_(Rodin_User_Manual)|The Event-B Explorer]]|Next= [[The_Mathematical_Language_(Rodin_User_Manual)|The Mathematical Language]]|Up= [[index_(Rodin_User_Manual)|User_Manual_index]]}} |
| | + | {{TOCright}} |
| | | | |
| − | == Overview ==
| + | The Proving Perspective is made of a number of windows: the proof tree, the goal, the selected hypotheses, the proof control, the proof information, and the searched hypotheses. In subsequent sections, we study these windows, but before that let us see how one can load a proof. |
| − | The Rodin platform versions concerned by this deliverable are: | |
| − | * 2.1(08.02.2011),
| |
| − | * 2.2(01.06.2011),
| |
| − | * 2.2.2(01.08.2011),
| |
| − | * 2.3(04.10.2011),
| |
| − | * 2.4(31.01.2012),
| |
| − | * 2.5(30.04.2012).
| |
| − | This year, the maintenance carried on fixing identified bugs, although an emphasis was put on rectifying usability issues. Indeed, during the annual meeting in Nice, the WP9 members agreed to refocus on addressing some specific bugs and issues reported by DEPLOY partners, and wished resolved by the end of DEPLOY. Thus, no new features were implemented but those mentioned in the description of work. The tasks to be performed by the WP9 members were then scheduled, prioritized and regularly updated during the WP9 bi-weekly teleconferences. The updates allowed to capture and integrate rapidly some minor changes to enhance the usability of the platform which were required by the DEPLOY partners. The following paragraphs will give an overview of the the work that has been performed concerning maintenance on the existing platform components (i.e. core platform and plug-ins).
| |
| | | | |
| − | See the Release Notes<ref name="documentation">http://wiki.event-b.org/index.php/D32_General_Platform_Maintenance#Available_Documentation</ref> and the SourceForge<ref name=documentation>http://wiki.event-b.org/index.php/D45_General_Platform_Maintenance#Available_Documentation</ref> databases (bugs and feature requests) for details about the previous and upcoming releases of the Rodin platform.
| + | == Loading a Proof == |
| | | | |
| − | Some other which were later added and prioritized are worth to mention:
| + | In order to load a proof, enter the Proof Obligation window, select the project, select and expand the component, finally select the proof obligation: the corresponding proof will be loaded. As a consequence: |
| − | :*Possibility to highlight patterns in the Proving UI,
| |
| − | :*A better output providing warnings and errors in case of wrong or missing building configurations,
| |
| − | :*The switch to Eclipse 3.7, | |
| − | :*A Handbook to complete and enhance the existing documentation. | |
| | | | |
| − | == Motivations ==
| + | * the proof tree is loaded in the Proof Tree window. As we shall see in section [[The_Proving_Perspective_(Rodin_User_Manual)#The_Proof_Tree|6.2]], each node of the proof tree is associated with a sequent. |
| − | The tasks to resolve the issues faced by the DEPLOY industrial partners have been listed and have been assigned to groups according to their priority. A high priority means a high need in the outcome of a given task. Group 1 has the highest priority, group 2 has an intermediate priority, and group 3 has the lowest priority. Group 4 concerns topics that could not be resourced during the lifetime of DEPLOY.
| + | * In case the proof tree has some "pending" nodes (whose sequents are not discharged yet) then the sequent corresponding to the first pending node is decomposed: its goal is loaded in the Goal window (section [[The_Proving_Perspective_(Rodin_User_Manual)#Goal and Selected Hypotheses|6.3]]), whereas parts of its hypotheses (the "selected" ones) are loaded in the Selected Hypotheses window (section [[The_Proving_Perspective_(Rodin_User_Manual)#Goal and Selected Hypotheses|6.3]]). |
| | + | * In case the proof tree has no pending node, then the sequent of the root node is loaded as explained previously. |
| | | | |
| − | {{SimpleHeader}}
| + | == The Proof Tree == |
| − | |-
| |
| − | ! scope=col | Group 1 (highest priority) || Responsible || Group 2 || Responsible || Group 3 || Responsible || Group 4
| |
| − | |-
| |
| − | |Performance <br /> - Core (large models, etc.) <br /> - GUI (incl. prover UI, edition, etc.) || SYSTEREL || Prover Performances <br /> - SMT provers integration <br /> - connection with Isabelle <br /> - Mathematical extensions <br /> - ProB || . <br />SYSTEREL <br /> ETH Zürich <br /> Southampton/SYSTEREL <br /> Düsseldorf || Scalability <br /> - Generic instantiation <br /> - UML-B maintenance <br /> || . <br /> ETH Zürich/Southampton <br /> Southampton || Prover Integrity
| |
| − | |-
| |
| − | |Prover Performances <br /> - New rewriting rules / inference rules <br /> - Automatic tactics (preferences, timeout, etc.) || SYSTEREL || Scalability <br /> - Decomposition <br /> - Modularisation plug-in <br /> - Team-Based Development || . <br /> Southampton <br /> Newcastle <br /> Southampton ||Code Generation || Southampton ||Integrity of Code Generation
| |
| − | |-
| |
| − | |ProB Disprover (incl. counter examples to DLF POs) || Düsseldorf || Plug-in incompatibilities || Newcastle
| |
| − | |-
| |
| − | |Stability (crash, corruption, etc.) || SYSTEREL || Model-based testing || Pitesti/Düsseldorf
| |
| − | |-
| |
| − | |Editors || SYSTEREL/Düsseldorf || ProR || Düsseldorf
| |
| − | |}
| |
| | | | |
| − | The platform maintenance, as it can be deduced from the above tables, mainly concerned stability and performance improvement. These topics will be discussed and detailed in a separate chapter about scalability improvements.<br>
| + | === Description of the Proof Tree === |
| | | | |
| − | Other improvements of utmost importance were made on the platform. These improvements either came from DEPLOY partners specific needs, or were corresponding to previously identified needs (listed in [http://wiki.event-b.org/index.php/Category:D32_Deliverable D32 - Model Construction tools & Analysis III Deliverable]).
| + | The proof tree can be seen in the corresponding window as shown in the following screen shot: |
| − | Hence we review below the motivations of some noteworthy implemented features:
| |
| − | * Possibility to highlight patterns in the Prover UI
| |
| − | This feature came from a request of DEPLOY partners<ref name="searchInPUI">https://sourceforge.net/tracker/?func=detail&atid=651672&aid=3092835&group_id=108850</ref>, often facing the need to find particular patterns such as expressions in long predicates (e.g. long goals). Since Rodin 2.2, and its new Proving UI interface, a feature has been added, allowing to search and highlight a string pattern into the whole Proving UI views and editors. This function has also been enabled on direct selection of text in this UI.
| |
| − | * A better output providing warnings and errors in case of wrong or missing building configurations
| |
| − | This issue, often being seen as a bug or as a plug-in incompatibility, was raised when a user imports and tries to use a model on a platform with some missing required plug-ins. The user often thought his models corrupted whereas Rodin was not able to build them, and hid this information to the user. This is why, since Rodin 2.3, an output has been provided in such case, taking the form of warnings or errors that any user can understand and review.
| |
| − | * The switch to Eclipse 3.7
| |
| − | Due to the major improvements made every year in Eclipse releases and the continuously growing number of contributing projects, some of them used as basis for Rodin plug-ins, the Rodin platform follows the evolution and is adapted every year quickly to the latest Eclipse version available. This year, Rodin 2.3 originated the switch from Eclipse 3.6 to Eclipse 3.7.
| |
| − | * A Handbook to complete and enhance the existing documentation
| |
| − | At the DEPLOY Plenary Meeting in Zürich in 2010, it has been stated that the current documentation, in its state at that time, would not support an engineer starting using the tools without significant help of an expert<ref name="documentationoverhaul>http://wiki.event-b.org/index.php/User_Documentation_Overhaul</ref>. Significant efforts to improve the documentation were performed and coordinated by Düsseldorf, and took form of a handbook<ref name="RodinHandbook">http://handbook.event-b.org/</ref>. The Rodin handbook has the aim to minimize the access to an expert, by providing the necessary assistance to an engineer in the need to be productive using Event-B and the Rodin toolset. The contents of the handbook, user oriented, were originated by some contents of the Event-B wiki.
| |
| | | | |
| − | == Choices / Decisions ==
| + | [[Image:um-0095.png|center]] |
| − | * Revisited task priority
| |
| − | This year, the process of giving priority to maintenance tasks was revisited according to the refocus mentioned above. The aim was to address all the major scalability issues before the end of DEPLOY. Thus, the requests coming from DEPLOY partners were given high priorities, and they were also prioritized against the already planned tasks coming from both DEPLOY partners and the Description of Work.
| |
| − | * Keep 32-bit versions of the Rodin platform on Linux and Windows systems
| |
| − | It was asked by end users to make both 32-bit and 64-bit versions of the Rodin platform available for Linux and Windows platforms. Only a 64-bit version of Rodin is available on Mac platforms as 32-bit Mac (early 2006) platforms are no longer maintained. The request to offer 64-bit was motivated by the possibility to increase for them the available Java heap size for some memory greedy platforms (these before Rodin 2.3). After having ensured to get all physical platforms to test the different versions, and despite the drawbacks of assembling and maintaining more platforms (5 platforms instead of 3), Rodin 2.4 has started a new era where Rodin platforms are available on Linux and Windows 64-bit as well as 32-bit.
| |
| | | | |
| − | == Available Documentation ==
| + | Each line in the proof tree corresponds to a node which is a sequent. A line is right shifted when the corresponding node is a direct descendant of the node of the previous line. Here is an illustration of the previous tree: |
| − | The following pages give useful information about the Rodin platform releases:
| |
| − | * Release notes<ref>http://wiki.event-b.org/index.php/Rodin_Platform_Releases</ref>
| |
| − | Two trackers follow and document the platform status in terms of knows bugs and feature requests:
| |
| − | * Bugs,<ref>https://sourceforge.net/tracker/?group_id=108850&atid=651669</ref>
| |
| − | * Feature requests<ref>https://sourceforge.net/tracker/?group_id=108850&atid=651672</ref>.
| |
| − | The Rodin handbook is available as a PDF version, a HTML version, and help contents within Rodin<ref name="RodinHandbook">http://handbook.event-b.org/</ref>
| |
| | | | |
| − | == Status ==
| + | [[Image:Tree.png|center]] |
| − | By the end of DEPLOY, the ultimate version of the Rodin platform is 2.5.
| |
| − | One can download it on the sourceforge [http://sourceforge.net/projects/rodin-b-sharp/files/Core_Rodin_Platform/2.5/ repository] and read the [http://wiki.event-b.org/index.php/Rodin_Platform_2.5_Release_Notes release notes] on the wiki.
| |
| | | | |
| − | <!-- /////////////////////////////////////////////////////////////////////// -->
| + | Each node is labelled with a comment explaining how it can be discharged. By selecting a node in the proof tree, the corresponding sequent is decomposed and loaded in the Goal and Selected Hypotheses windows as explained in section [[The_Proving_Perspective_(Rodin_User_Manual)#Loading a Proof|6.1]]. |
| | | | |
| − | = Plug-in incompatibilities = | + | === Decoration === |
| | | | |
| − | == Overview ==
| + | The leaves of the tree are decorated with three kinds of logos: |
| − | Some plug-in incompatibilities occured and were continuously handled throught the lifetime of the project.
| |
| | | | |
| − | == Motivations ==
| + | * a green logo with a "<math>\surd </math>" in it means that this leaf is discharged, |
| − | By its extensibility nature, the Rodin platform is susceptible to incompatibilities. Indeed, there are many ways in which incompatibilities could occur, and some occurred in the lifetime of DEPLOY. A good example, is the dependency management. Suppose that a bundle x_v1.0 is needed by a plug-in A (i.e. a dependency from A has been defined to x in at most the version 1.0) and installed in Rodin. Furthermore the plug-in x_v1.1 is needed by a plug-in B. Both versions 1.0 and 1.1 of x could not be installed and used at the same time and thus create some usage incompatibility.
| + | * a red logo with a "?" in it means that this leaf is not discharged, |
| | + | * a blue logo with a "R" in it means that this leaf has been reviewed. |
| | | | |
| − | == Choices / Decisions ==
| + | Internal nodes in the proof tree are decorated in the same (but lighter) way. Note that a "reviewed" leaf is one that is not discharged yet by the prover. Instead, it has been "seen" by the user who decided to have it discharged later. Marking nodes as "reviewed" is very convenient in order to perform an interactive proof in a gradual fashion. In order to discharge a "reviewed" node, select it and prune the tree at that node (section [[The_Proving_Perspective_(Rodin_User_Manual)#Pruning|6.2.5]]): the node will become "red" again (undischarged) and you can now try to discharge it. |
| − | It has been decided in cooperation with all the WP9 partners to find better ways to address the plug-in incompatibility issues. First of all, the various partners refined the concept of "plug-in incompatibility". Hence, various aspects could be identified and some specific answers were given to each of them. The user could then defined more clearly the incompatibility faced. Plug-in incompatibilities can be separated in two categories:
| |
| − | :* Rodin platform/plug-in incompatibilities, due to some incorrect matches between Rodin included packages and the plug-in dependencies (i.e. required packages). These incompatibilities, when reported, allowed the plug-in developers to contact SYSTEREL in charge of managing the packages shipped with a given version of Rodin. It could also allow traceability of incompatibilities and information to the user through a specific and actualized table on each Rodin release notes page on the Wiki<ref name="incompTableA">http://wiki.event-b.org/index.php/Rodin_Platform_Releases#Current_plug-ins</ref>.
| |
| − | :* Plug-in/plug-in incompatibilities, due to some incorrect matches between needed/installed packages, or API/resources incompatible usage. A table was created on each release notes wiki page, and a procedure was defined<ref name="incompTableB">http://wiki.event-b.org/index.php/Rodin_Platform_Releases#Known_plug-in_incompatibilities</ref> so that identified incompatibilities are listed and corrected by the concerned developers.
| |
| − | It appeared that cases of using a model which references some missing plug-ins were formerly often seen as compatibility issues although they were not.<br>
| |
| − | After the incompatibilities have been identified, the concerned developing counterparts assigned special tasks and coordinated to solve issues as soon as possible. Incompatibilities are often due to little glitches or desynchronisation. As a result, direct coordination of counterparts appeared to be appropriate because of its promptness and effectiveness.
| |
| | | | |
| − | == Available Documentation == | + | === Navigation within the Proof Tree === |
| − | *The process to report plug-in incompatibilities is documented on each release notes page right after the plug-in availability tables. [http://wiki.event-b.org/index.php/Rodin_Platform_2.4_External_Plug-ins][http://wiki.event-b.org/index.php/Rodin_Platform_2.5_External_Plug-ins]
| |
| | | | |
| − | == Status ==
| + | On top of the proof tree window one can see three buttons: |
| − | As the time of writing this deliverable, no plug-in incompatibilities are left or have been reported between the platform and plug-ins or between plug-ins.
| |
| | | | |
| − | <!-- /////////////////////////////////////////////////////////////////////// -->
| + | * the "G" buttons allows you to see the goal of the sequent corresponding to the node |
| | + | * the "+" button allows you to fully expand the proof tree |
| | + | * the "-" allows you to fully collapse the tree: only the root stays visible. |
| | | | |
| − | = Mathematical extensions/ Theory Plug-in = | + | === Hiding === |
| | | | |
| − | == Overview ==
| + | The little triangle next to each node in the proof tree allows you to expand or collapse the subtree starting at that node. |
| − | Mathematical extensions have been co-developed by Systerel (for the Core Rodin platform) and Southampton (for the Theory plug-in). The main purpose of this new feature was to provide the Rodin user with a way to extend the standard Event-B mathematical language by supporting user-defined operators, basic predicates and algebraic types. Along with these additional notations, the user can also define new proof rules (prover extensions).
| |
| − | The scope of the ongoing work on the Theory plug-in centers around bug fixes, improving usability and performance and exploring other venues for operator definitions.
| |
| | | | |
| − | == Motivations == | + | === Pruning === |
| − | The Theory plug-in provides a high-level interface to the Rodin core platform capabilities which enables the definition of mathematical and prover extensions grouped into modules called theories. These mathematical and prover extensions are new algebraic types, new operators/predicates and new proof rules. Theories are developed in the Rodin workspace, and proof obligations are generated to validate prover and mathematical extensions. When a theory is completed and (optionally) validated, the user can make it available for use in models (this action is called the deployment of a theory). Theories are deployed to the current workspace (i.e., Workspace Scope), and the user can use any defined extensions in any project within the workspace.
| |
| − | The Rule-based Prover was originally devised to provide a usable mechanism for user-defined rewrite rules through theories. Theories were, then, deemed a natural choice for defining mathematical extensions as well as proof rules to reason about such extensions. In essence, the Theory plug-in provides a systematic platform for defining and validating extensions through a familiar technique: proof obligations.
| |
| | | | |
| − | Support for using polymorphic theorems in proofs was added in version 1.1.
| + | The proof tree can be pruned from a node: it means that the subtree starting at that node is eliminated. The node in question becomes a leaf and is red decorated. This allows you to resume the proof from that node. After selecting a sequent in the proof tree, pruning can be performed in two ways: |
| | | | |
| − | == Choices / Decisions ==
| + | * by right-clicking and then selecting "Prune", |
| − | The Theory plug-in contributes a theory construct to the Rodin database. Theories were used in the Rule-based Prover (before it was discontinued) as a placeholder for rewrite rules. Given the usability advantages of the theory component, it was decided to use it to define mathematical extensions (new operators and new datatypes). Another advantage of using the theory construct is the possibility of using proof obligations to ensure that the soundness of the formalism is not compromised. Proof obligations are generated to validate any properties of new operators (e.g., associativity). With regards to prover extensions, it was decided that the Theory plug-in inherits the capabilities to define and validate rewrite rules from the Rule-based Prover. Furthermore, support for a simple yet powerful subset of inference rules is added, and polymorphic theorems can be defined within the same setting. Proof obligations are, again, used as a filter against potentially unsound proof rules.
| + | * by pressing the "Scissors" button in the proof control window (section [[The_Proving_Perspective_(Rodin_User_Manual)#The Proof Control Window|6.4]]). |
| | | | |
| − | == Available Documentation ==
| + | Note that after pruning, the post-tactic (section [[The_Proving_Perspective_(Rodin_User_Manual)#The Automatic Post-tactic|6.8]]) is not applied to the new current sequent: if needed you have to press the "post-tactic" button in the Proof Control window (section [[The_Proving_Perspective_(Rodin_User_Manual)#The Proof Control Window|6.4]]). This happens in particular when you want to redo a proof from the beginning: you prune the proof tree from the root node and then you have to press the "post-tactic" button in order to be in exactly the same situation as the one delivered automatically initially. |
| − | * Pre-studies (states of the art, proposals, discussions)
| |
| − | ** [http://deploy-eprints.ecs.soton.ac.uk/216/ ''Proposals for Mathematical Extensions for Event-B'']
| |
| − | ** [http://deploy-eprints.ecs.soton.ac.uk/251/ ''Mathematical Extension in Event-B through the Rodin Theory Component'']
| |
| − | ** [http://wiki.event-b.org/index.php/Constrained_Dynamic_Parser#Design_Alternatives ''Generic Parser's Design Alternatives'' ]
| |
| − | ** [http://wiki.event-b.org/index.php/Structured_Types ''Theoretical Description of Structured Types'']
| |
| − | * Technical details (specifications)
| |
| − | ** [http://wiki.event-b.org/index.php/Mathematical_Extensions ''Mathematical_Extensions wiki page'']
| |
| − | ** [http://wiki.event-b.org/index.php/Constrained_Dynamic_Lexer ''Constrained Dynamic Lexer wiki page'']
| |
| − | ** [http://wiki.event-b.org/index.php/Constrained_Dynamic_Parser ''Constrained Dynamic Parser wiki page'']
| |
| − | ** [http://wiki.event-b.org/index.php/Theory_Plug-in ''Theory plug-in wiki page]
| |
| − | ** [http://wiki.event-b.org/index.php/Records_Extension ''Records Extension Documentation on wiki'']
| |
| − | * User's guides
| |
| − | ** [http://wiki.event-b.org/images/Theory_UM.pdf ''Theory Plug-in User Manual'']
| |
| | | | |
| − | == Status ==
| + | When you want to redo a proof from a certain node, it might be advisable to do it after copying the tree so that in case your new proof fails you can still resume the previous situation by pasting the copied version (see next section). |
| − | Work on the Theory plug-in includes:
| |
| − | * Bug fixes.
| |
| − | * Usability improvements.
| |
| − | * Exploring other potential ways of defining operators and types (e.g., axiomatic definitions).
| |
| | | | |
| − | <!-- /////////////////////////////////////////////////////////////////////// -->
| + | === Copy/Paste === |
| | | | |
| − | = Decomposition =
| + | By selecting a node in the proof tree and then clicking on the right key of the mouse, you can copy the part of the proof tree starting at that sequent: it can later be pasted in the same way. This allows you to reuse part of a proof tree in the same (or even another) proof. |
| | | | |
| − | == Overview == | + | == Goal and Selected Hypotheses == |
| − | Decomposition can advantageously be used to decrease the complexity and increase the modularity of large systems, especially after several refinements. Main benefits are the distribution of proof obligations over the sub-components which are expected to be easier to be discharged and the further refinement of independent sub-components in parallel introducing team development of a model which is attractive for the industry. Shared variable and shared event decomposition are supported in the same tool: the former seems to be suitable when designing concurrent programs while the latter seems to be particularly suitable for message-passing distributed programs. The tool was initially developed in ETH Zurich. Further development of the tool was a collaboration between ETH Zurich, Southampton and Systerel. After some user feedback, the tool was improved in terms of usability and performance. The ongoing work aims for a more automated tool that can propagate changes in the sub-components and minimise the user intervention as much as possible while maintaining or enhancing the performance.
| |
| | | | |
| − | == Motivations ==
| + | The "Goal" and "Selected Hypotheses" windows display the current sequent you have to prove at a given moment in the proof. Here is an example: |
| − | The ''top-down'' style is one of the most used in modelling in Event-B. It allows the introduction of new events and data-refinement of variables during refinement steps. A consequence of this development style is an increasing complexity of the refinement process when dealing with many events and state variables. The main purpose of the model decomposition is precisely to address such difficulty by separating a large model into smaller components. Two methods have been identified for the Event-B decomposition: shared variable (proposed by Abrial) and shared event (proposed by Butler). We developed a plug-in in the Rodin platform that supports these two decomposition methods for Event-B. Because decomposition is monotonic, the generated sub-components can be further refined independently. Therefore we can expand the team development options: several developers share parts of the same model and work independently in parallel. Moreover the decomposition also partitions the proof obligations which are expected to be easier to discharge in sub-components. | |
| | | | |
| − | == Choices / Decisions ==
| + | [[Image:um-0098.png|center]] |
| − | The tasks performed on the decomposition plug-in were focused on consolidation.
| |
| | | | |
| − | == Available Documentation ==
| + | A selected hypothesis can be deselected by first clicking in the box situated next to it (you can click on several boxes) and then by pressing the red (-) button at the top of the selected hypothesis window: |
| − | *[http://wiki.event-b.org/index.php/Decomposition_Plug-in_User_Guide ''The Decomposition Plug-in User Guide'']
| |
| − | *[http://wiki.event-b.org/index.php/Event_Model_Decomposition ''The event model decomposition wiki page'']
| |
| | | | |
| − | == Status ==
| + | [[Image:um-0099.png|center]] |
| − | The decomposition plug-in is available in version 1.2.2 and works on Rodin 2.4 and 2.5. It is available from the main Rodin update site.
| |
| | | | |
| − | <!-- /////////////////////////////////////////////////////////////////////// -->
| + | Here is the result: |
| | | | |
| − | = Team-Based Development=
| + | [[Image:um-0100.png|center]] |
| − | == Overview ==
| |
| − | The Team-Based Development plug-in enables Rodin models to be stored in a version repository such as SVN. During the final year of DEPLOY, the development concerned mostly consolidation and interface enhancement.
| |
| | | | |
| − | == Motivations ==
| + | Notice that the deselected hypotheses are not lost: you can get them back by means of the Searched Hypotheses window (section [[The_Proving_Perspective_(Rodin_User_Manual)#srchhyp|6.7]]). |
| − | To achieve the storage of Rodin models in SVN, the Team-Based Development plug-in allows maintaining a synchronised copy of the model resources in an EMF format. EMF comparison tools can then be used to examine differences between versions.
| |
| | | | |
| − | == Choices / Decisions ==
| + | The three other buttons next to the red (-) button allow you to do the reverse operation, namely keeping some hypotheses. The (ct) button next to the goal allows you to do a proof by contradiction: pressing it makes the negation of the goal being a selected hypothesis whereas the goal becomes "false". The (ct) button next to a selected hypothesis allows you to do another kind of proof by contradiction: pressing it makes the negation of the hypothesis the goal whereas the negated goal becomes an hypothesis. |
| − | The EMF default XMI format was used to store models in a form that can be accessed independently of the Rodin database. Since an EMF framework for Event-B already existed (but relied on serialisation into the Rodin database), it was easy to provide an option to serialise into the XMI format. The EMF compare was customised to provide a more user friendly comparison. | |
| | | | |
| − | == Available Documentation == | + | == Rewrite Rules == |
| − | * [http://wiki.event-b.org/index.php/Team-based_development Team-based Development Documentation on wiki]
| |
| | | | |
| − | == Status ==
| + | Rewrite rules are applied either automatically (A) or manually (M). |
| − | The Team-Based Development plug-in is available on the main Rodin update site. Currently 3-way comparison is not supported. (3-way comparison is needed if 2 people check out and change the model so that there are 2 working copies as well as a repository baseline).
| |
| | | | |
| − | <!-- /////////////////////////////////////////////////////////////////////// -->
| + | A rule may be applied: |
| | + | * Automatically (A), when post tactics are enabled. These rules are equivalence simplification laws. |
| | + | * Manually (M), through an interactive command. These rules gathers non equivalence laws, definition laws, distributivity laws and derived laws. |
| | | | |
| − | = Modularisation =
| + | Rewrite rules are applied from left to right either in the goal or in the selected hypotheses, when their ''side condition'' hold. |
| − | == Overview ==
| |
| − | Modularisation offers an intuitive yet rigorous mechanism for structuring large developments. Its main distinguishing feature is the use of ''interface'' components - a special form of an abstract machine defining callable operations and external variables. To decompose a design using modularisation a designer needs to identify a self-contained part of a design and captures it in an independent ''module''. A module is an Event-B development starting with an interface as its top-level abstraction. Modules may be included into machines and offer ''operations'' that may be used to define actions of an including machine. Variables of an interface may not be modified directly and thus the invariant property of an interface holds at all times. An essential part of a decomposition step is identifying a part of an abstract state that is removed and said to be realised by one of the included modules. Modularisation works well for sequential and concurrent systems.
| |
| | | | |
| − | == Motivations ==
| + | Each rule is named after the following elements: |
| − | The major motivation for the initial design and the continuing development of the modularisation extension is the desire to deal with large-scale specification using Event-B notation and refinement-based development. Generally, users find the modularisation approach fairly intuitive and flexible.
| |
| | | | |
| − | == Choices / Decisions ==
| + | * The law category: simplification law (SIMP), definition law (DEF), distributivity law (DISTRI), or else derived law (DERIV). |
| − | Modularisation is not a simple extension and it changes both the syntax and semantics (the set of proof obligations) of Event-B. It is possible to encode all of the modularisation concepts directly in the Event-B notation. However, it was deemed very important to offer high-level structuring concepts - interfaces and operations - that engineers may relate to. Although an operation call in modularisation is merely a metaphore, the syntactic resemblances of an procedure call in a programming language significantly improves model readability. A similar idea motivated the introduction of an interface component - sensible syntax and efficient set of proof obligations are paramount.
| + | * Particularity on terminal elements of the left part of the rule (optional): special element (SPECIAL) such as the empty-set, type expression (TYPE), same element occurring more then once (MULTI), literal (LIT). A type expression is either a basic type (<math>\intg, \Bool</math>, any carrier set), or <math>\pow</math>(type expression), or type expression<math>\cprod</math>type expression. |
| | + | * One or more elements describing from top to down the left part of the rule, eg. predicate AND, expression BUNION. |
| | + | * Detail to localize those elements (optional): left (L), right (R). |
| | | | |
| − | == Available Documentation ==
| + | Rewrite rules having an equivalence operator in their left part may also describe other rules. eg: the rule: |
| − | * See the [[Modularisation_Plug-in]] wiki page
| |
| | | | |
| − | == Status == | + | <math> \True = \False \;\;\defi\;\; \bfalse </math> |
| − | The modularisation plug-in is available for Platform versions 1.6 - 2.4. Starting from Platform version 2.3, modularisation is compatible with the ProB animator and model checker. The modularisation is not compatible with Camille text editor.
| |
| | | | |
| − | <!-- /////////////////////////////////////////////////////////////////////// -->
| + | should also produce the rule: |
| | | | |
| − | = UML-B = | + | <math> \False = \True \;\;\defi\;\; \bfalse </math> |
| − | == Overview ==
| |
| − | The UML-B plug-in supports modelling in a UML-like diagrammatic notation with conversion to Event-B for verification. UML-B supports class and state machine diagrams as well as a project structure diagram (showing machines and contexts). UML-B continues to be supported but currently is not undergoing new development. Some enhancements were made last year in order to improve the usability of state machines, however, most new development concentrates on the new Event-B diagrammatic extensions to Event-B (such as the Event-B Statemachines plug-in).
| |
| | | | |
| − | The Event-B Statemachines plug-in is a new tool, based on the UML-B state machine diagrams, which allows to integrate state machines into normal Event-B machines. It provides a graphical diagram editor, an Event-B generator and, as an optional plug-in, diagram animator for ProB.
| |
| | | | |
| − | == Motivations ==
| + | For associative operators in connection with distributive laws as in: |
| − | The Event-B Statemachines plug-in has been introduced as a result of the necessity to integrate higher level constructs into established Event-B modelling process. From the experience of working with the UML-B tool it became apparent that a tighter integration is required between Event-B models under development and high level extensions such as state machines. In particular, this integration should be flexible enough to make it easy for an user to add new constructs at any point of Event-B development and work with them through refinement, which is a key feature of the Event-B language and Rodin tool.
| |
| | | | |
| − | == Choices / Decisions ==
| + | <center><math> P \land (Q \lor \ldots \lor R) </math></center> |
| − | For the Event-B Statemachines plug-in the following key decisions were made:
| |
| − | * The UML-B state machines example was taken as a concept.
| |
| − | * Well-established Eclipse development frameworks — EMF and GMF — were chosen for implementation of the new plug-in and simplified (from the original UML-B state machines) EMF metamodel and diagram have been implemented.
| |
| − | * The integration idea between Event-B and state machines was based on EMF extension mechanism and serialisation principle: a state machine was designed as an extension to EMF Event-B metamodel that would be serialised as a string to an attribute in Rodin database, thus making the details of it transparent to Rodin.
| |
| − | * For the translation of state machines to Event-B the QVT framework has been selected, considering it as a well-supported framework, used in other Eclipse projects such as GMF, and more declarative nature of it compared to pure Java, which would improve maintainability.
| |
| | | | |
| − | As a result of work on Event-B Statemachines plug-in a set of additional plug-ins has been developed that forms a framework to support developer effort in implementing other similar tools and high level extensions for Event-B. These plug-ins include generic serialised persistence and navigator support for new EMF extensions, generic diagram metamodel and navigator actions, generic refinement and Event-B generator modules for new extensions.
| + | it has been decided to put the "button" on the first associative/commutative operator (here <math>\lor </math>). Pressing that button will generate a menu: the first option of this menu will be to distribute all associative/commutative operators, the second option will be to distribute only the first associative/commutative operator. In the following presentation, to simplify matters, we write associative/commutative operators with two parameters only, but it must always be understood implicitly that we have a sequence of them. For instance, we shall never write <math> Q \lor \ldots \lor R </math> but <math> Q \lor R </math> instead. Rules are sorted according to their purpose. |
| | | | |
| − | == Available Documentation ==
| + | Rules marked with a star in the first column are implemented in the current prover. Rules without a star are planned for implementation. |
| − | * [http://wiki.event-b.org/index.php/Event-B_Statemachines "Event-B State-machines Documentation on wiki"]
| |
| | | | |
| − | == Status ==
| + | Rewrite rules are split into: |
| − | The Event-B State machines plug-in is available on the main Rodin update site.
| |
| | | | |
| − | <!-- /////////////////////////////////////////////////////////////////////// -->
| + | * [[Set Rewrite Rules]] |
| | + | * [[Relation Rewrite Rules]] |
| | + | * [[Arithmetic Rewrite Rules]] |
| | | | |
| − | = ProR =
| + | They are also available in a single large page [[All Rewrite Rules]]. |
| | | | |
| − | == Overview == | + | == Inference Rules == |
| − | ProR is a replacement of the original requirements plug-in, which got discontinued in 2010. It is based on the OMG ReqIF standard<ref name="reqif">http://www.omg.org/spec/ReqIF/</ref>, which provides interoperability with industry tools. It evolved into the Eclipse Foundation project "Requirements Modeling Framework" (RMF<ref name="rmf">http://eclipse.org/rmf</ref>), resulting in significant visibility. ProR is independent from Rodin. Integration is achieved with a separate plug-in that provides support for traceability and model integration.
| |
| | | | |
| − | == Motivations ==
| + | Inference rules are applied either automatically (A) or manually (M). |
| − | While the original requirements plug-in for Rodin was useful as a prototype, a number of shortcomings lead to a new development. In particular, the original plug-in was a traceability tool with externally managed requirements. With ProR, requirements are authored and edited within Eclipse. The original plug-in supported only a limited number of attributes and flat (unstructured) requirements. ProR supports all data structures that the ReqIF standard<ref name="reqif">http://www.omg.org/spec/ReqIF/</ref> supports. Further, ReqIF-support for industry tools like Rational DOORS, MKS or IRqA is expected in the near future, while the original plug-in required a custom adaptor for each data format.
| |
| | | | |
| − | ProR is developed independently from Rodin. Dependencies to Rodin exist only in the Rodin integration plug-in. This significantly decreases the maintenance effort for the integration plugin, while increasing the visibility of ProR in the Open Source community. The move of ProR from the University of Düsseldorf to the Eclipse Foundation increases visibility even further. The Rodin integration plug-in is maintained as an independent project at GitHub.
| + | Inference rules applied automatically are applied at the end of each proof step when the post-tactic is enabled. They have the following possible effects: |
| | | | |
| − | == Choices / Decisions ==
| + | * they discharge the goal, |
| − | The following key decisions were made when developing ProR:
| + | * they simplify the goal and add a selected hypothesis, |
| | + | * they simplify the goal by decomposing it into several simpler goals, |
| | + | * they simplify a selected hypothesis, |
| | + | * they simplify a selected hypothesis by decomposing it into several simpler selected hypotheses. |
| | | | |
| − | * '''New development, rather than continuing the original plug-in''' - the architecture of ProR differs significantly from that of the original plug-in (as explained earlier). In addition, new technologies like EMF promised a cleaner, more powerful framework for an implementation.
| + | Inference rules applied manually are used to perform an interactive proof. They can be invoked by pressing "buttons" which corresponds to emphasized (red) operators in the goal or the hypotheses. A menu is proposed when there are several options. |
| | | | |
| − | * '''ReqIF as the underlying data model''' - the ReqIF standard<ref name="reqif">http://www.omg.org/spec/ReqIF/</ref> is gaining traction and promises interoperability with industry tools. In addition, a digital version of the data model was available for free and could serve as the foundation for the model code.
| + | See the [[Inference Rules]] list. |
| | | | |
| − | * '''The Eclipse Modeling Framework''' (EMF) was identified as a technology that would allow a quick and clean foundation for an implementation. Further, the Rodin EMF-plug-in represents a convenient interface for integrating ProR and ProB. Last, the digital data model from the OMG could be imported directly into EMF and used for generating the model code.
| + | == The Proof Control Window == |
| | | | |
| − | * '''Keeping ProR independent from Rodin''' - There is significant interest in ReqIF right now, but this interest is unrelated to formal methods. By providing an implementation that is independent from Rodin, we have a much larger target group of potential users and developers. By carefully designing extension points, we can still provide a powerful Rodin integration.
| + | The Proof Control window contains the buttons which you can use to perform an interactive proof. Next is a screen shot where you can see successively from top to bottom: |
| | | | |
| − | * '''Eclipse Foundation Project''' - we were actively establishing an open source community around ProR. By recruiting engaged partners early on, development progressed faster than anticipated. By becoming an Eclipse Foundation project <ref name="rmf">http://eclipse.org/rmf</ref>, we exceeded our goals in this respect. | + | * some selected hypotheses, |
| | + | * the goal, |
| | + | * the "Proof Control" window, |
| | + | * a small editing area within which you can enter parameters used by some buttons of the Proof Control window |
| | + | * the smiley (section [[The_Proving_Perspective_(Rodin_User_Manual)#The Simley|6.5]]) |
| | | | |
| − | == Available Documentation ==
| + | [[Image:um-0101.png|center]] |
| − | * ProR at the Eclipse Foundation <ref name="rmf">http://eclipse.org/rmf</ref>
| |
| − | * ProR Documentation for end users and plugin developers <ref>http://pror.org</ref>
| |
| | | | |
| − | == Status ==
| + | The Proof Control window offers a number of buttons which we succinctly describe from left to right: |
| − | ProR took on a life on its own as part of the Requirements Modeling Framework<ref name="rmf">http://eclipse.org/rmf</ref>. It is currently in the incubation stage of an Eclipse project. There are currently five committers in total, with two from the Rodin project, namely Michael Jastram (Project Lead) and Lukas Ladenberger.
| |
| | | | |
| − | The Rodin integration supports: | + | * (p0): the prover PP attempts to prove the goal (other cases in the list) |
| | + | * (R) review: In an attempt by the user to carry out proofs in a gradual fashion, they might decide to postpone the task of discharging some interactive proofs for a later stage. In this case they have the possibility to mark these proofs as reviewed (by choosing the proof node and pressing the blue button with a “R” letter on the top-left corner of the Proof Control view). This means that by visually checking this proof, the user convinced that they can discharge it later but they do not want to do it right now. |
| | + | * (dc) proof by cases: the goal is proved first under the predicate written in the editing area and then under its negation, |
| | + | * (ah) lemma: the predicate in the editing area is proved and then added as a new selected hypothesis, |
| | + | * (ae) abstract expression: the expression in the editing area is given a fresh name, |
| | + | * the auto-prover attempts to discharge the goal. The auto-prover is the one which is applied automatically on all proof obligations (as generated automatically by the proof obligation generator after a "save") without any intervention of the user. With this button, you can call yourself the auto-prover within an interactive proof. |
| | + | * the post-tactic is executed (see section [[The_Proving_Perspective_(Rodin_User_Manual)#The Automatic Post-tactic|6.8]]), |
| | + | * lasso: load in the Selected Hypotheses window those unseen hypotheses containing identifiers which are common with identifiers in the goal and selected hypotheses, |
| | + | * backtrack form the current node (i.e., prune its parent), |
| | + | * scissors: prune the proof tree from the node selected in the proof tree, |
| | + | * show (in the Search Hypotheses window) hypotheses containing the character string as in the editing area, |
| | + | * '''Cache Hypotheses Button''': By pressing ''"Cache Hypotheses"'' button the tool displays the ''"Cache Hypotheses"'' view. This view displays all hypotheses that are related to the current goal. Some of these hypotheses might not been chosen as current active hypotheses (this is the set of hypotheses that considered by the prover to discharge the current goal). By opening the cached hypotheses view the user can manually select and add some of them to the current active hypotheses view. |
| | + | * load the previous non-discharged proof obligation, |
| | + | * load the next undischarged proof obligation, |
| | + | * (i) show information corresponding to the current proof obligation in the corresponding window. This information correspond to the elements that took directly part in the proof obligation generation (events, invariant, etc.), |
| | + | * goto the next pending node of the current proof tree, |
| | + | * load the next reviewed node of the current proof tree. |
| | | | |
| − | * Creating traces between model elements and requirements,
| + | == The Smiley == |
| − | * Highlighting of model elements in the requirements text,
| |
| − | * Marking of invalidated traces, where either the requirement or model element had changed.
| |
| | | | |
| − | The Rodin integration is hosted at GitHub. | + | The smiley can take three different colors: (1) red, meaning that the proof tree contains one or more non-discharged sequents, (2) blue, meaning that all non-discharged sequents of the proof tree have been reviewed, (3) green, meaning that all sequents of the proof tree are discharged. |
| | | | |
| − | <!-- /////////////////////////////////////////////////////////////////////// -->
| + | == The Operator "Buttons" == |
| − | = BMotion Studio = | |
| | | | |
| − | == Overview ==
| + | In the goal and in the selected, searched, or cache hypotheses some operators are colored in red. It means that they are "buttons" you can press. When doing so, the meaning (sometimes several) is shown in a menu where you can select various options. The operation performed by these options is described in sections [[The_Proving_Perspective_(Rodin_User_Manual)#Interactive Rewrite Rules|6.9.1]] and [[The_Proving_Perspective_(Rodin_User_Manual)#Interactive Inference Rules|6.9.2]]. |
| − | BMotion Studio is a visual editor which enables the developer of a formal model to set-up easily a domain specific visualisation for discussing it with the domain expert. BMotion Studio comes with a graphical editor that allows to create a visualisation within the modeling environment. Also, it does not require to use a different notation for gluing the state and its visualisation. BMotion Studio is based on the ProB animator and is integrated into Rodin. However, BMotion Studio is independent from Rodin. Integration is achieved with a separate plug-in.
| |
| | | | |
| − | * BMotion Studio has been quite successful, and besides a number of bug fixes and some performance profiling and tuning, the useability of the tool was improved.
| + | == The Search Hypotheses Window == |
| − | * One of our students made experiments towards visualizing industry standards with BMotion Studio. The first experiments were quite successful.
| |
| − | * First experiments towards visualizing mathematical assertions found in formal specifications using Venn Diagrams/Euler Diagrams/Constraint Diagrams were made.
| |
| | | | |
| − | == Motivations ==
| + | By typing a string in the '''Proof Control''' window and pressing the '''Search Hypotheses''' button a window is provided which contains the hypotheses having a character string in common with the one entered by the user in the editing area. For example, if we search for hypotheses involving the character string "cr", then after pressing the '''Search Hypothesis''' button on the proof control window, we obtain the following: |
| − | The communication between a developer and a domain expert (or manager) is very important for successful deployment of formal methods. On the one hand it is crucial for the developer to get feedback from the domain expert for further development. On the other hand the domain expert needs to check whether his expectations are met. To avoid this problem, it is useful to create domain specific visualisations. However, creating the code that defines the mapping between a state and its graphical representation is a rather time consuming task. It can take several weeks to develop a custom visualisation. To overcome this problem, BMotion Studio comes with a graphical editor that allows to create a visualisation with static images and drag and drop within the modelling environment, not requiring additional skills.
| |
| | | | |
| − | An often stated limitation in using formal methods is the difficulty in understanding the formal notation. To overcome this problem and to support the user we made first experiments towards visualizing mathematical assertions found in formal specifications using Venn Diagrams/Euler Diagrams/Constraint Diagrams.
| + | [[Image:um-0102.png|center]] |
| | | | |
| − | == Choices / Status ==
| + | This view also integrates a "quick search" area (A), that allows us to search quickly hypothesis involving short character strings such as "cr". A '''search hypothesis button (B)''' that behaves the same as the button of the proving window, a '''refresh button (C)''' that updates the window manually for more control, and a '''drop down menu (D)''' to set the preferences of the view up. |
| − | The following key decisions were made when developing BMotion Studio:
| |
| − | * '''Keeping BMotion Studio user-friendly''' - The user should be able to create a visualization not requiring additional skills in programming languages.
| |
| − | * '''ProB as animator for providing state information''' - With the ProB animator, we have a powerful tool for interacting with the model.
| |
| − | * '''Provide extensibility for specific domains''' - By carefully designing extension points, we can provide a powerful integration for specific domains.
| |
| − | * '''Keeping BMotion Studio independent from Rodin''' - By providing an implementation that is independent from Rodin, we have a much larger target group of potential users and developers.
| |
| | | | |
| − | == Available Documentation ==
| + | By pressing '''return''' key or the button (B) (once a short string has been given in the input area (A)), hypotheses can be searched quickly as if we used the '''Proof Control''' as described before. |
| − | * BMotion Studio Documentation for end users and plugin developers <ref>http://www.stups.uni-duesseldorf.de/BMotionStudio</ref>
| |
| − | * Context sensitive help is in work
| |
| | | | |
| − | == Status ==
| + | The drop down menu (D) is accessible to set some preferences over the searched hypotheses : |
| − | The tool is available as a part of the ProB animator and is ready for use for visualizing Event-B models within the Rodin tool. Of course, we are working on new features. | |
| | | | |
| − | <!-- /////////////////////////////////////////////////////////////////////// -->
| + | [[Image:SearchHyp_view_menu.png|center]] |
| − | = Mode/FT Views =
| |
| | | | |
| − | == Overview ==
| + | If we change preferences for the search, we might need to "update" manually the view with the button (C). |
| − | The Mode/FT Views plug-in is a modelling environment for constructing modal and fault tolerance features in a diagrammatic form and formally linking them to Event-B models. The consistency conditions between the modal/FT views and Event-B models are ensured by additional proof obligations. The views form a refinement chain of system modal and fault tolerant behaviour which contribute to the main Event-B development. The views reserve a place for tracing modal and FT requirements.
| + | By selecting "Consider hidden hypotheses in search" option, we can review all hypotheses that have been unselected in the selected hypotheses window(more info about[[Rodin_Proving_Perspective#Goal and Selected Hypotheses| selected/hidden hypotheses]]...). |
| | | | |
| − | == Motivations ==
| + | In the next step any of these hypotheses can be selected and then by pressing the '''(+)button''' they will be moved to the '''Selected Hypotheses''' window . Adding these hypotheses to the set '''Selected Hypotheses''' means that they will be visible to the prover. This means that they can be used during the next interactive proof phase. Accordingly by selecting any numbers of hypotheses and pressing the '''(-)button''' they will be removed from the '''Search Hypotheses''' window. The '''(-)button''' also appears above the selected hypotheses, and allow the user to remove any hypothesis form the '''Selected Hypotheses''' window. The other button which is situated in the left-hand-side of all hypotheses is the '''(ct) Button'''. By pressing the '''(ct) Button''' the negation of the corresponding hypothesis is taken as a new hypothesis. For this purpose we have to prove it first and therefore it appears as a new goal which the user must discharge it first and then proceed with the previous goal. |
| − | There are two major motivations for creating the Mode/FT Views plug-in:
| |
| − | * An overview of the requirements documents within DEPLOY indicated that systems are often described in terms of operational modes and configurations. This led to a work on formal definition of modal systems.
| |
| − | * Fault-tolerance is the crucial part of the behaviour of dependable critical systems that needs to benefit from formal modelling as functionality does. The requirements documents for the pilot studies in DEPLOY contain a high number of requirements related to fault handling and fault tolerant behaviour. A significant part of them are also described by using recoveries and degraded modes.
| |
| − | The plug-in provides an environment for specifying modal and fault tolerant behaviours which are often interrelated. By having a refinement chain of system-level modal diagrams, the development benefits from additional modelling constraints and improved requirements traceability.
| |
| | | | |
| − | == Choices / Decisions == | + | == The Automatic Post-tactic == |
| − | The following key decisions were made when developing Mode/FT Views:
| |
| − | * '''The Eclipse Graphical Modelling Framework (GMF)''' was used as a platform for building a user-friendly modelling environment.
| |
| − | * '''Proof obligations for the views are injected into the standard PO repository of the models''' - This ensures that all the tools related to theorem proving can be used in the same way as they are used for Event-B proof obligations.
| |
| | | | |
| − | == Available Documentation ==
| + | In this section, we present the various rewrite or inference rules which are applied automatically as a systematic post-tactic after each proof step. Note that the post-tactic can be disabled by using the "'''P'''<math>\! \! \! \! /</math>" button situated on the right of the proof control window. |
| − | * Mode/FT Views documentation for users <ref name="modeft">http://wiki.event-b.org/index.php/Mode/FT_Views</ref>
| |
| − | * Papers
| |
| − | ** [http://deploy-eprints.ecs.soton.ac.uk/105/ ''Structuring Specifications with Modes'']
| |
| − | ** [http://deploy-eprints.ecs.soton.ac.uk/153/ ''Modal Systems: Specification, Refinement and Realisation'']
| |
| − | ** [http://deploy-eprints.ecs.soton.ac.uk/253/ ''On Fault Tolerance Reuse during Refinement'']
| |
| | | | |
| − | == Status ==
| + | The post-tactic is made of two different rules: rewrite rules, which are applied on any sub-formula of the goal or selected hypotheses (section [[The_Proving_Perspective_(Rodin_User_Manual)#Rewrite Rules|6.8.1]]) and inference rules which are applied on the current sequent (section [[The_Proving_Perspective_(Rodin_User_Manual)#Automatic Inference Rules|6.8.2]]). |
| − | The Mode/FT Views is a plug-in for the Rodin platform. The tool is available from its update site <ref name="modeft">http://wiki.event-b.org/index.php/Mode/FT_Views</ref> | |
| | | | |
| − | = Shared references =
| |
| − | <references/>
| |
| | | | |
| − | [[Category:D45 Deliverable]] | + | |
| | + | |
| | + | |
| | + | === Preferences for the Post-tactic === |
| | + | |
| | + | The post-tactic can be configured by means of a preference page which can be obtained as follows: press the "Window" button on the top tooolbar. On the coming menu, press the "Preferences" button. On the coming menu, press the "Event-B" menue, then the "Sequent Prover’, and finally the "Post-Tactic" button. This yilds the following window: |
| | + | |
| | + | [[Image:um-0147.png|center]] |
| | + | |
| | + | In the left part you can see the ordered sequence of individual tactics composing the post-tactic, whereas the right part contains further tactics you can incorporate in the left part. By selecting a tactic you can move it from on part to the other or change the order in the left part. |
| | + | |
| | + | |
| | + | [[Category:User documentation|The Proving Perspective]] |
| | + | [[Category:Rodin Platform|The Proving Perspective]] |
| | + | [[Category:User manual|The Proving Perspective]] |
The Proving Perspective is made of a number of windows: the proof tree, the goal, the selected hypotheses, the proof control, the proof information, and the searched hypotheses. In subsequent sections, we study these windows, but before that let us see how one can load a proof.
Loading a Proof
In order to load a proof, enter the Proof Obligation window, select the project, select and expand the component, finally select the proof obligation: the corresponding proof will be loaded. As a consequence:
- the proof tree is loaded in the Proof Tree window. As we shall see in section 6.2, each node of the proof tree is associated with a sequent.
- In case the proof tree has some "pending" nodes (whose sequents are not discharged yet) then the sequent corresponding to the first pending node is decomposed: its goal is loaded in the Goal window (section 6.3), whereas parts of its hypotheses (the "selected" ones) are loaded in the Selected Hypotheses window (section 6.3).
- In case the proof tree has no pending node, then the sequent of the root node is loaded as explained previously.
The Proof Tree
Description of the Proof Tree
The proof tree can be seen in the corresponding window as shown in the following screen shot:
Each line in the proof tree corresponds to a node which is a sequent. A line is right shifted when the corresponding node is a direct descendant of the node of the previous line. Here is an illustration of the previous tree:
Each node is labelled with a comment explaining how it can be discharged. By selecting a node in the proof tree, the corresponding sequent is decomposed and loaded in the Goal and Selected Hypotheses windows as explained in section 6.1.
Decoration
The leaves of the tree are decorated with three kinds of logos:
- a green logo with a "
" in it means that this leaf is discharged,
- a red logo with a "?" in it means that this leaf is not discharged,
- a blue logo with a "R" in it means that this leaf has been reviewed.
Internal nodes in the proof tree are decorated in the same (but lighter) way. Note that a "reviewed" leaf is one that is not discharged yet by the prover. Instead, it has been "seen" by the user who decided to have it discharged later. Marking nodes as "reviewed" is very convenient in order to perform an interactive proof in a gradual fashion. In order to discharge a "reviewed" node, select it and prune the tree at that node (section 6.2.5): the node will become "red" again (undischarged) and you can now try to discharge it.
Navigation within the Proof Tree
On top of the proof tree window one can see three buttons:
- the "G" buttons allows you to see the goal of the sequent corresponding to the node
- the "+" button allows you to fully expand the proof tree
- the "-" allows you to fully collapse the tree: only the root stays visible.
Hiding
The little triangle next to each node in the proof tree allows you to expand or collapse the subtree starting at that node.
Pruning
The proof tree can be pruned from a node: it means that the subtree starting at that node is eliminated. The node in question becomes a leaf and is red decorated. This allows you to resume the proof from that node. After selecting a sequent in the proof tree, pruning can be performed in two ways:
- by right-clicking and then selecting "Prune",
- by pressing the "Scissors" button in the proof control window (section 6.4).
Note that after pruning, the post-tactic (section 6.8) is not applied to the new current sequent: if needed you have to press the "post-tactic" button in the Proof Control window (section 6.4). This happens in particular when you want to redo a proof from the beginning: you prune the proof tree from the root node and then you have to press the "post-tactic" button in order to be in exactly the same situation as the one delivered automatically initially.
When you want to redo a proof from a certain node, it might be advisable to do it after copying the tree so that in case your new proof fails you can still resume the previous situation by pasting the copied version (see next section).
Copy/Paste
By selecting a node in the proof tree and then clicking on the right key of the mouse, you can copy the part of the proof tree starting at that sequent: it can later be pasted in the same way. This allows you to reuse part of a proof tree in the same (or even another) proof.
Goal and Selected Hypotheses
The "Goal" and "Selected Hypotheses" windows display the current sequent you have to prove at a given moment in the proof. Here is an example:
A selected hypothesis can be deselected by first clicking in the box situated next to it (you can click on several boxes) and then by pressing the red (-) button at the top of the selected hypothesis window:
Here is the result:
Notice that the deselected hypotheses are not lost: you can get them back by means of the Searched Hypotheses window (section 6.7).
The three other buttons next to the red (-) button allow you to do the reverse operation, namely keeping some hypotheses. The (ct) button next to the goal allows you to do a proof by contradiction: pressing it makes the negation of the goal being a selected hypothesis whereas the goal becomes "false". The (ct) button next to a selected hypothesis allows you to do another kind of proof by contradiction: pressing it makes the negation of the hypothesis the goal whereas the negated goal becomes an hypothesis.
Rewrite Rules
Rewrite rules are applied either automatically (A) or manually (M).
A rule may be applied:
- Automatically (A), when post tactics are enabled. These rules are equivalence simplification laws.
- Manually (M), through an interactive command. These rules gathers non equivalence laws, definition laws, distributivity laws and derived laws.
Rewrite rules are applied from left to right either in the goal or in the selected hypotheses, when their side condition hold.
Each rule is named after the following elements:
- The law category: simplification law (SIMP), definition law (DEF), distributivity law (DISTRI), or else derived law (DERIV).
- Particularity on terminal elements of the left part of the rule (optional): special element (SPECIAL) such as the empty-set, type expression (TYPE), same element occurring more then once (MULTI), literal (LIT). A type expression is either a basic type (
, any carrier set), or 
(type expression), or type expression
type expression.
- One or more elements describing from top to down the left part of the rule, eg. predicate AND, expression BUNION.
- Detail to localize those elements (optional): left (L), right (R).
Rewrite rules having an equivalence operator in their left part may also describe other rules. eg: the rule:
should also produce the rule:
For associative operators in connection with distributive laws as in:
it has been decided to put the "button" on the first associative/commutative operator (here 
). Pressing that button will generate a menu: the first option of this menu will be to distribute all associative/commutative operators, the second option will be to distribute only the first associative/commutative operator. In the following presentation, to simplify matters, we write associative/commutative operators with two parameters only, but it must always be understood implicitly that we have a sequence of them. For instance, we shall never write 
but 
instead. Rules are sorted according to their purpose.
Rules marked with a star in the first column are implemented in the current prover. Rules without a star are planned for implementation.
Rewrite rules are split into:
They are also available in a single large page All Rewrite Rules.
Inference Rules
Inference rules are applied either automatically (A) or manually (M).
Inference rules applied automatically are applied at the end of each proof step when the post-tactic is enabled. They have the following possible effects:
- they discharge the goal,
- they simplify the goal and add a selected hypothesis,
- they simplify the goal by decomposing it into several simpler goals,
- they simplify a selected hypothesis,
- they simplify a selected hypothesis by decomposing it into several simpler selected hypotheses.
Inference rules applied manually are used to perform an interactive proof. They can be invoked by pressing "buttons" which corresponds to emphasized (red) operators in the goal or the hypotheses. A menu is proposed when there are several options.
See the Inference Rules list.
The Proof Control Window
The Proof Control window contains the buttons which you can use to perform an interactive proof. Next is a screen shot where you can see successively from top to bottom:
- some selected hypotheses,
- the goal,
- the "Proof Control" window,
- a small editing area within which you can enter parameters used by some buttons of the Proof Control window
- the smiley (section 6.5)
The Proof Control window offers a number of buttons which we succinctly describe from left to right:
- (p0): the prover PP attempts to prove the goal (other cases in the list)
- (R) review: In an attempt by the user to carry out proofs in a gradual fashion, they might decide to postpone the task of discharging some interactive proofs for a later stage. In this case they have the possibility to mark these proofs as reviewed (by choosing the proof node and pressing the blue button with a “R” letter on the top-left corner of the Proof Control view). This means that by visually checking this proof, the user convinced that they can discharge it later but they do not want to do it right now.
- (dc) proof by cases: the goal is proved first under the predicate written in the editing area and then under its negation,
- (ah) lemma: the predicate in the editing area is proved and then added as a new selected hypothesis,
- (ae) abstract expression: the expression in the editing area is given a fresh name,
- the auto-prover attempts to discharge the goal. The auto-prover is the one which is applied automatically on all proof obligations (as generated automatically by the proof obligation generator after a "save") without any intervention of the user. With this button, you can call yourself the auto-prover within an interactive proof.
- the post-tactic is executed (see section 6.8),
- lasso: load in the Selected Hypotheses window those unseen hypotheses containing identifiers which are common with identifiers in the goal and selected hypotheses,
- backtrack form the current node (i.e., prune its parent),
- scissors: prune the proof tree from the node selected in the proof tree,
- show (in the Search Hypotheses window) hypotheses containing the character string as in the editing area,
- Cache Hypotheses Button: By pressing "Cache Hypotheses" button the tool displays the "Cache Hypotheses" view. This view displays all hypotheses that are related to the current goal. Some of these hypotheses might not been chosen as current active hypotheses (this is the set of hypotheses that considered by the prover to discharge the current goal). By opening the cached hypotheses view the user can manually select and add some of them to the current active hypotheses view.
- load the previous non-discharged proof obligation,
- load the next undischarged proof obligation,
- (i) show information corresponding to the current proof obligation in the corresponding window. This information correspond to the elements that took directly part in the proof obligation generation (events, invariant, etc.),
- goto the next pending node of the current proof tree,
- load the next reviewed node of the current proof tree.
The Smiley
The smiley can take three different colors: (1) red, meaning that the proof tree contains one or more non-discharged sequents, (2) blue, meaning that all non-discharged sequents of the proof tree have been reviewed, (3) green, meaning that all sequents of the proof tree are discharged.
The Operator "Buttons"
In the goal and in the selected, searched, or cache hypotheses some operators are colored in red. It means that they are "buttons" you can press. When doing so, the meaning (sometimes several) is shown in a menu where you can select various options. The operation performed by these options is described in sections 6.9.1 and 6.9.2.
The Search Hypotheses Window
By typing a string in the Proof Control window and pressing the Search Hypotheses button a window is provided which contains the hypotheses having a character string in common with the one entered by the user in the editing area. For example, if we search for hypotheses involving the character string "cr", then after pressing the Search Hypothesis button on the proof control window, we obtain the following:
This view also integrates a "quick search" area (A), that allows us to search quickly hypothesis involving short character strings such as "cr". A search hypothesis button (B) that behaves the same as the button of the proving window, a refresh button (C) that updates the window manually for more control, and a drop down menu (D) to set the preferences of the view up.
By pressing return key or the button (B) (once a short string has been given in the input area (A)), hypotheses can be searched quickly as if we used the Proof Control as described before.
The drop down menu (D) is accessible to set some preferences over the searched hypotheses :
If we change preferences for the search, we might need to "update" manually the view with the button (C).
By selecting "Consider hidden hypotheses in search" option, we can review all hypotheses that have been unselected in the selected hypotheses window(more info about selected/hidden hypotheses...).
In the next step any of these hypotheses can be selected and then by pressing the (+)button they will be moved to the Selected Hypotheses window . Adding these hypotheses to the set Selected Hypotheses means that they will be visible to the prover. This means that they can be used during the next interactive proof phase. Accordingly by selecting any numbers of hypotheses and pressing the (-)button they will be removed from the Search Hypotheses window. The (-)button also appears above the selected hypotheses, and allow the user to remove any hypothesis form the Selected Hypotheses window. The other button which is situated in the left-hand-side of all hypotheses is the (ct) Button. By pressing the (ct) Button the negation of the corresponding hypothesis is taken as a new hypothesis. For this purpose we have to prove it first and therefore it appears as a new goal which the user must discharge it first and then proceed with the previous goal.
The Automatic Post-tactic
In this section, we present the various rewrite or inference rules which are applied automatically as a systematic post-tactic after each proof step. Note that the post-tactic can be disabled by using the "P
" button situated on the right of the proof control window.
The post-tactic is made of two different rules: rewrite rules, which are applied on any sub-formula of the goal or selected hypotheses (section 6.8.1) and inference rules which are applied on the current sequent (section 6.8.2).
Preferences for the Post-tactic
The post-tactic can be configured by means of a preference page which can be obtained as follows: press the "Window" button on the top tooolbar. On the coming menu, press the "Preferences" button. On the coming menu, press the "Event-B" menue, then the "Sequent Prover’, and finally the "Post-Tactic" button. This yilds the following window:
In the left part you can see the ordered sequence of individual tactics composing the post-tactic, whereas the right part contains further tactics you can incorporate in the left part. By selecting a tactic you can move it from on part to the other or change the order in the left part.
