Rodin Developer Support: Difference between revisions

From Event-B
Jump to navigationJump to search
imported>Stefan
No edit summary
imported>Stefan
No edit summary
Line 10: Line 10:
=== Rodin Platform Core ===
=== Rodin Platform Core ===


[[Database]]
* [[Database]]


[[Builder]]
* [[Builder]]


=== Event-B User Interface ===
=== Event-B User Interface ===
Line 18: Line 18:
The Event-B User Interface of the Roding Platform has two major components that are concerned with either '''editing''' Event-B models or '''proving''' properties of models.
The Event-B User Interface of the Roding Platform has two major components that are concerned with either '''editing''' Event-B models or '''proving''' properties of models.


[[Editing]]
* [[Editing]]


[[Proving]]
* [[Proving]]


=== Event-B Component Library ===
=== Event-B Component Library ===

Revision as of 14:56, 4 July 2008

The Developer Support provides resources for developing plug-ins for the Rodin Platform.

Rodin Platform Overview

Architecture of the Rodin Platform

Rodin Platform Core

Event-B User Interface

The Event-B User Interface of the Roding Platform has two major components that are concerned with either editing Event-B models or proving properties of models.

Event-B Component Library

Event-B models and all proof-related information are stored in the Rodin database. The syntax of the mathematical notation, that is, expressions, predicates, and assignments, are maintained in an abstract syntax tree. Abstract syntax trees are manipulated by means of a class library that can be used independently of Eclipse. They are saved in the database in human-readable form as Unicode character strings. Event-B constructs, such as contexts and machines, are not represented as abstract syntax trees. They are stored and retrieved directly from the database (by contrast, mathematical formulas need additional parsing). Well-formedness of of Event-B constructs is verified by a Static Checker. The static checker has two main purposes: (1) it generates error messages for ill-formed constructs, and (2) it filters well-formed parts of components to be subjected to proof obligation generation. The Proof Obligation Generator uses those parts of constructs that are well-formed and generates proof obligations from them. Finally, the Proof Manager attempts to prove proof obligations and maintains existing proofs associated with proof obligations. The proof manager works automatically and interactively. When new proof obligations have been generated it attempts to discharge them automatically. If it does not succeed, it permits interactive proof (by means of the Proving).

Extending the Rodin Platform

Getting Started

Plug-in Tutorials

Useful Hints

Testing

Debugging

Rodin Developer FAQ