Rodin Developer Support: Difference between revisions
imported>Stefan No edit summary |
imported>Stefan No edit summary |
||
| Line 16: | Line 16: | ||
=== Event-B User Interface === | === Event-B User Interface === | ||
The Event-B User Interface of the Roding Platform has two major components that are concerned with either [[editing | The Event-B User Interface of the Roding Platform has two major components that are concerned with either [[Editing|editing]] Event-B models or [[Proving|proving]] properties of models. | ||
* [[Editing]] | * [[Editing]] | ||
| Line 24: | Line 24: | ||
=== Event-B Component Library === | === 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 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 | 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 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|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|proof obligation generator]] uses those parts of constructs that are well-formed and generates proof obligations from them. Finally, the [[Proof Manager|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|proving user interface]]). | ||
* [[Abstract Syntax Tree]] | * [[Abstract Syntax Tree]] | ||
Revision as of 15:00, 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 user interface).
