Difference between pages "Code Generation Activity" and "The Use of Theories in Code Generation"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Andy
 
imported>Andy
 
Line 1: Line 1:
Tasking Event-B is the extension of Event-B for defining concurrent systems sharing data, for details see the [[Tasking Event-B Overview]] page. For more information contact Andy Edmunds - University of Southampton - mailto:ae2@ecs.soton.ac.uk, or Chris Lovell mailto:cjl3@ecs.soton.ac.uk
+
= Defining Translations Using The Theory Plug-in =
 +
The theory plug-in is used to add mathematical extensions to Rodin. The theories are created, and deployed, and can then be used in any models in the workspace. When dealing with implementation level models, such as in Tasking Event-B, we need to consider how to translate newly added types and operators into code. We have augmented the theory interface with a Translation Rules section. This enables a user to define translation rules that map Event-B formulas to code.
 +
== Translation Rules==
 +
Code generation rules are specified in a theory file, which is created using the Theory plug-in.
  
 +
<div id="fig:Translation Rules">
 +
<br/>
 +
[[Image:TheoryCGRules.png|center||caption text]]
 +
<center>'''Figure 1''': Translation Rules</center>
 +
<br/>
 +
</div>
  
 +
Figure 1 shows a pretty print of some of the translations rules that have been specified to generate Ada code. In the figure we can see that the theory is given a name, and may import some other theories. Type parameters can be added, and we use them here to type the meta-variables. The meta-variable ''a'' is restricted to be an integer type, but meta-variable ''c'' can be any unspecified type, ''Q''. Meta-variables are used in the translator rules for pattern matching.
  
== Code Generation Feature - Version 0.2.3 For Rodin 2.5==
+
Translator rules are templates, used in a pattern matching algorithm in the code generator. Event-B formulas are defined on the left hand side of the rule, and the code to be output (as text) appears on the right hand side of the matching rule. During translation an abstract syntax tree (AST) representation of the formula is used. The theory plug-in attempts to match the formulas in the rules with each syntactic element of the AST. As it does so it builds the textual output as a string, until the whole AST has been successfully matched. When a complete tree is matched, the target code is returned. If the AST is not matched, a warning is issued, and a string representation of the original formula is returned.
A new release of the tool is imminent.
 
  
The main new features are:
+
== Type Rules for Code Generation ==
  
* Code generation from [http://wiki.event-b.org/index.php/State-Machines_and_Code_Generation state-machine] diagrams.
+
The type rules section, shown in Figure 1, is where the relationship is defined, between Event-B types and the type system of the implementation.
* Improved static checking.
 
  
We have also provided some details of the [http://wiki.event-b.org/index.php/The_Use_of_Theories_in_Code_Generation use of Theories in code generation], from the previous version.
+
= Adding New (implementation-level) Types =
 +
When we are working at abstraction levels close to the implementation level, we may make an implementation decision which requires the introduction of a new type to the development. We give an example of our approach, where we add a new array type, shown in Figure 2, and then define its translation to code.
  
Updated Examples etc. are available:
+
== An Array Type Definition ==
+
<div id="fig:Extension with an Array Type">
* Tutorial, and example, projects are available from the Examples directory: [https://codegenerationd.svn.sourceforge.net/svnroot/codegenerationd/Examples/v0.2.3/ SVN].
+
<br/>
* Test projects are also available from the Examples directory [https://codegenerationd.svn.sourceforge.net/svnroot/codegenerationd/Examples/v0.2.3/Tests SVN].
+
[[Image:ArrayDef.png|center||caption text]]
* Sources (will be) available at: [https://rodin-b-sharp.svn.sourceforge.net/svnroot/rodin-b-sharp/trunk/CodeGeneration SVN]
+
<center>'''Figure 2''': Array Definition</center>
* Example Theories at: [https://codegenerationd.svn.sourceforge.net/svnroot/codegenerationd/Examples/TheoriesForCG SVN]
+
<br/>
 +
</div>
  
== Code Generation Feature - Version 0.2.2 For Rodin 2.4==
+
The array operator notation is defined in the expression array(s: P(T)); and the semantics is defined in the direct definition. arrayN constrains the arrays to be of fixed length. Array lookup, update, and constructor operators are subsequently defined. In the next step we need to define any translations required to implement the array in code.
  
We released V0.2.2 on 22-03-2012. The main changes, to the interface, and translation from theories are described below:
+
== Translation Rules ==
  
* Tasking Event-B is now integrated with the Event-B Editors.
+
<div id="Translation Rules for the Array Type">
* We have the ability to translate to C, Java, etc. in addition to Ada source code.
+
<br/>
* We use theories to define translations of the Event-B mathematical language (Theories for Ada, Java and C are supplied).
+
[[Image:ArrayTrans.png|center||caption text]]
* We use the theory plug-in as a mechanism for defining new data types , and the translations to target data types.
+
<center>'''Figure 3''': Translation Rules for the Array Type</center>
* The translator is extensible.
+
<br/>
* Minimal use is made of the EMF tree editor in Rose.
+
</div>
  
To install v0.2.2:
+
Figure 3 shows the Ada translation; beginning with the meta-variable definitions that are used for pattern matching in the translation rules. Each of the operators; ''newArray'', and ''update'', and an expression using the ''lookup'' operator, are mapped to their implementations on the right hand side of the rule. The ''Type Rules'' section describes the implementation's description of the ''arrayN'' type.
 
 
* Access the main Rodin Update Site. In Eclispe click on Help/Install new Software. Find the Rodin update site from the list. In Utilities add Code Generation.
 
The approach makes use of the following, which should be installed if the features are required by the user for editing:
 
*Model Decomposition: Download from the main Rodin Update Site, in the Decomposition section.
 
*Shared Event Composition: Download from the main Rodin Update Site, in the Decomposition section.
 
*Theory Plug-in: Download from the main Rodin Update Site, in the Modelling Extensions section.
 
 
 
Examples available at:
 
 
* Tutorial, and example, projects are available from the Examples directory: [https://codegenerationd.svn.sourceforge.net/svnroot/codegenerationd/Examples/v0.2.2/ SVN].
 
* Test projects are also available from the Examples directory [https://codegenerationd.svn.sourceforge.net/svnroot/codegenerationd/Examples/v0.2.2/CG_v0.2.2_Tests SVN].
 
* Sources at: [https://rodin-b-sharp.svn.sourceforge.net/svnroot/rodin-b-sharp/trunk/CodeGeneration SVN]
 
* Example Theories at: [https://codegenerationd.svn.sourceforge.net/svnroot/codegenerationd/Examples/TheoriesForCG SVN]
 
 
 
== Code Generation Feature - Version 0.2.1 For Rodin 2.3==
 
Contains Bug Fixes for previous release. 14-12-2011
 
 
 
== Code Generation Feature - Version 0.2.0 For Rodin 2.3==
 
We released a new version of the code generator on 30-11-2011, and updated documentation.
 
===== Changes to the Tooling and Approach =====
 
The main changes are:
 
* The code generators have been completely re-written. The translators are now implemented in Java, i.e. there is no longer a dependence on the Epsilon tool set. This was undertaken for code maintenance reasons.
 
* Tasking Event-B is now integrated with the Event-B explorer.
 
* The Rose Editor is used for editing the Tasking Event-B, and
 
* a text-based editor is provided, using the Rose extension, for editing the TaskBody. This feature has been added to address some of the usability concerns. It also overcomes the 'problem' experienced with duplicate event names in a development, since the parser-builder that has been implemented automatically selects the correct event.
 
* The EMF tree editor in Rose is only used minimally; we plan enhancements to further reduce its use.
 
* Composed machines are used to store event 'synchronizations'; these are generated automatically during the decomposition process. This reduces the amount of typing in the TaskBody editor, since we no longer need to specify both local and remote (synchronizing) events.
 
* The code generation approach is now extensible; new target language constructs can be added using the Eclipse extension mechanism.
 
* The translation of target's mathematical language is now specified in the theory plug-in. This improves clarity since the the translation from source to target is achieved by specifying pattern matching rules. Extensibility is also improved; the theory plug-in is used to specify new data-types, and how they are implemented.
 
* Translated code is deposited in a directory in the appropriate files. An Ada project file is generated for use with AdaCore's GPS workbench. Eventually this could be enabled/disabled in a preferences dialog box.
 
* The Tasking Event-B to Event-B translator is now properly integrated. Control variable updates to the Event-B model are made in a similar way to the equivalent updates in the state-machine plug-in. The additional elements are added to the Event-B model and marked as 'generated'. This prevents users from manually modifying them, and allows them to be removed through a menu choice.
 
 
 
===== Changes to the Documentation =====
 
The following Pages have been updated:
 
* [http://wiki.event-b.org/index.php/Tasking_Event-B_Overview Tasking Event-B Overview]
 
* [http://wiki.event-b.org/index.php/Tasking_Event-B_Tutorial Tutorial]
 
 
 
TODO
 
* Add addressed variables (for direct read/write access to memory)
 
* Flattening of composed machines/implementation machines.
 
* Interrupts
 
 
 
=== Sensing and Actuating for Tasking Event-B ===
 
Version 0.1.5. Sensing and actuating events, and an Environ Machine have been added to allow simulation of the environment and implementation using memory mapped IO.
 
 
 
* The new v0.1.5 feature is available from the Rodin Update Site, it resides in the Utilities Category.
 
 
 
* As in previous releases, the code generation plug-in relies on the Epsilon tool suite. Add the following Epsilon interim update site to the list of available update sites in the Eclipse menu ''help/install new software'': http://download.eclipse.org/modeling/gmt/epsilon/interim/
 
 
 
* Select 'the Epsilon Core (Incubation)' component, this is the only component that is required for Tasking Event-B.
 
 
 
A new [http://wiki.event-b.org/index.php?title=Tasking_Event-B_Tutorial Code Generation Tutorial] has been produced, that makes use of these new features. There is an explanation of the heating controller, upon which it is based, [http://wiki.event-b.org/index.php/Development_of_a_Heating_Controller_System here].
 
 
 
The example/tutorial projects, and also and a Bundled Windows 7 version, are available in the [http://deploy-eprints.ecs.soton.ac.uk/304/ Deploy E-Prints archive] or [https://codegenerationd.svn.sourceforge.net/svnroot/codegenerationd/Examples/HeatingController_Tutorial_v0.1.4/ Examples SVN site].
 
 
 
== The Code Generation Demonstrator for Rodin 2.1.x ==
 
 
 
Released 24 January 2011.
 
 
 
The Rodin 2.1.x compatible code generation demonstrator plug-ins have been released into the Rodin Sourceforge repository at:
 
 
 
  https://rodin-b-sharp.svn.sourceforge.net/svnroot/rodin-b-sharp/trunk/CodeGeneration
 
 
 
The update-site is available through the Rodin update site in the ''Utilities'' category.
 
 
 
The code generation tutorial examples are available for download at:
 
 
 
  https://sourceforge.net/projects/codegenerationd/files/DemoFiles/
 
 
 
The code generation plug-in relies on the Epsilon tool suite. Install Epsilon manually, since the automatic install utility does not seem to work for this feature. We currently use the Epsilon interim update site available at:
 
 
 
  http://download.eclipse.org/modeling/gmt/epsilon/interim/
 
 
 
Select 'the Epsilon Core (Incubation)' component, this is the only component that is required for Tasking Event-B.
 
 
 
=== Latest Developments ===
 
* Demonstrator plug-in feature version 0.1.0
 
** for Rodin 2.1.x version is available.
 
 
 
* The Code Generation feature consists of,
 
** a tasking Development Generator.
 
** a tasking Development Editor (Based on an EMF Tree Editor).
 
** a translator, from Tasking Development to Common Language Model (IL1).
 
** a translator, from the Tasking Development to Event-B model of the implementation.
 
** a pretty-printer for the Tasking Development.
 
** a pretty-printer for Common Language Model, which generates Ada Source Code.
 
 
 
* A tutorial is available [[Code Generation Tutorial]]
 
** Step 1 - Create the tasking development.
 
** Step 2 - Add annotations.
 
** Step 3 - Invoke translators.
 
 
 
=== Ongoing Work ===
 
 
 
* Full Rodin Integration
 
* Sensed Variables
 
* Branching in Shared Machines
 
 
 
=== Future Work ===
 
* Support for Interrupts.
 
* Richer DataTypes.
 
* Accommodation of duplicate event names in tasking developments.
 
 
 
=== Metamodels ===
 
* In the plug-in we define several meta-models:
 
** CompositeControl: for the control flow (algorithmic) constructs such as branch, loop and sequence etc. These constructs may be used in the specification of either  sequential or concurrent systems.
 
** Tasking Meta-model: defines the tasking model where we attach tasking specific details, such as task priority, task type. The tasking structures provide the ability to define single tasking or multi-tasking (concurrent) systems. We make use of the composite control plug-in to specify the flow of control.
 
** Common Language (IL1) Meta-model: defines an abstraction of common programming language constructs for use in translations to implementations.
 
 
 
=== Translation Rules ===
 
* Tasking to IL1/Event-B translation rules [[http://wiki.event-b.org/images/Translation.pdf]]
 
 
 
== The Code Generation Demonstrator for Rodin 1.3.x ==
 
 
 
 
 
First release: 30 November 2010.
 
 
 
available from:
 
 
 
https://sourceforge.net/projects/codegenerationd/files/
 
 
 
The zip file contains a windows XP bundle, and a Windows V7 bundle. Alternatively, if you wish to build using an update-site, this is also included in the zip file, along with some notes on installation. However, note that the demonstrator tool is only compatible with Rodin 1.3.
 
 
 
A simple shared buffer example is provided. This will form the basis of a tutorial (which is work in progress). The WindowsBundles directory contains a Rodin 1.3.1 platform with the Code Generation plug-ins, together with a patch plug-in. The patch plug-in is required to correct an inconsistency in the org.eventb.emf.persistence plug-in. For the bundles, simply extract the appropriate zip file into a directory and run the rodin.exe. The plug-ins are pre-installed - the only configuration necessary may be to switch workspace to ''<installPath>\rodin1.3bWin7\workspace''. When using the update-site the example projects, and the project forming the basis of a simple tutorial, are provided in the accompanying zip file. These should be imported manually.
 
 
 
Mac users - no bundled version available at present, but use the update site in the 'advanced' folder.
 
 
 
'''A step-by-step [[Code Generation Tutorial]] is available'''
 
 
 
==== About the Initial Release ====
 
The Code Generation (CG) Feature in the initial release is a demonstration tool; a proof of concept, rather than a prototype. The tool has no static checker and, therefore, there will be a heavy reliance on docs and dialogue to facilitate exploration of the tools and concepts.
 
 
 
==== Source Code ====
 
 
 
The sources are available from,
 
 
 
https://codegenerationd.svn.sourceforge.net/svnroot/codegenerationd
 
 
 
Note - I used Eclipse 3.5 Galileo, and you will need to install (or have sources from) Epsilon's interim update site. There is also dependency on Camille v2.0.0
 
 
 
 
 
 
 
[[Category:Work in progress]]
 

Revision as of 10:51, 17 May 2012

Defining Translations Using The Theory Plug-in

The theory plug-in is used to add mathematical extensions to Rodin. The theories are created, and deployed, and can then be used in any models in the workspace. When dealing with implementation level models, such as in Tasking Event-B, we need to consider how to translate newly added types and operators into code. We have augmented the theory interface with a Translation Rules section. This enables a user to define translation rules that map Event-B formulas to code.

Translation Rules

Code generation rules are specified in a theory file, which is created using the Theory plug-in.


caption text
Figure 1: Translation Rules


Figure 1 shows a pretty print of some of the translations rules that have been specified to generate Ada code. In the figure we can see that the theory is given a name, and may import some other theories. Type parameters can be added, and we use them here to type the meta-variables. The meta-variable a is restricted to be an integer type, but meta-variable c can be any unspecified type, Q. Meta-variables are used in the translator rules for pattern matching.

Translator rules are templates, used in a pattern matching algorithm in the code generator. Event-B formulas are defined on the left hand side of the rule, and the code to be output (as text) appears on the right hand side of the matching rule. During translation an abstract syntax tree (AST) representation of the formula is used. The theory plug-in attempts to match the formulas in the rules with each syntactic element of the AST. As it does so it builds the textual output as a string, until the whole AST has been successfully matched. When a complete tree is matched, the target code is returned. If the AST is not matched, a warning is issued, and a string representation of the original formula is returned.

Type Rules for Code Generation

The type rules section, shown in Figure 1, is where the relationship is defined, between Event-B types and the type system of the implementation.

Adding New (implementation-level) Types

When we are working at abstraction levels close to the implementation level, we may make an implementation decision which requires the introduction of a new type to the development. We give an example of our approach, where we add a new array type, shown in Figure 2, and then define its translation to code.

An Array Type Definition


caption text
Figure 2: Array Definition


The array operator notation is defined in the expression array(s: P(T)); and the semantics is defined in the direct definition. arrayN constrains the arrays to be of fixed length. Array lookup, update, and constructor operators are subsequently defined. In the next step we need to define any translations required to implement the array in code.

Translation Rules


caption text
Figure 3: Translation Rules for the Array Type


Figure 3 shows the Ada translation; beginning with the meta-variable definitions that are used for pattern matching in the translation rules. Each of the operators; newArray, and update, and an expression using the lookup operator, are mapped to their implementations on the right hand side of the rule. The Type Rules section describes the implementation's description of the arrayN type.