Difference between pages "D32 UML-B" and "The Use of Theories in Code Generation"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Colin
 
imported>Andy
 
Line 1: Line 1:
= Overview =
+
= Defining Translations Using The Theory Plug-in =
Progress on UML-B consists of three parallel developments.
+
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.
# Enhancement and maintenance of the current and existing UML-B plug-in with new functionality and usability features.
+
== Translation Rules==
# Development of a new plug-in to provide animation of UML-B state-machine diagrams.
+
<div id="fig:Translation Rules">
# Development of a new plug-in (called iUML-B) that provides an alternative to UML-B which is more closely integrated with Event-B.
+
<br/>
 +
[[Image:TheoryCGRules.png|center||caption text]]
 +
<center>'''Figure 1''': Translation Rules</center>
 +
<br/>
 +
</div>
  
== Enhancement and Maintenance of Existing UML-B ==
+
Figure 1 shows the interface, and some translations rules of the mapping to Ada.
  
:The main progress on UML-B has been to implement new features, improve usability and fix bugs. As in the previous years of DEPLOY, these bugs and features are reported either by email or through dedicated SourceForge trackers. The list below gives an overwiew of the noteworthy features added in UML-B during the past year:
+
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 type. Meta-variables are used in the translator rules for pattern matching.
  
:# Functional enhancements to modelling
+
Translator rules are templates, which are used in pattern matching. 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.
:#* State-machine transitions emanating from multiple states. It is often the case that a transition may occur from several (possibly all) states within a state-machine. Such models were impossible to represent in UML-B. Two pseudo-states were added to represent this. Firstly an 'ANY' pseudo-state can be used as a transition source to represent that the transition can occur from ANY state of the state-machine. Secondly a disjunctive pseudo-state can be used to combine several transitions from different source states into a single transition.
 
:#* Conceptual Singleton classes - provides a conceptual grouping of associated modelling elements without generating the lifting mechanisms of a class.  
 
:#* Super-type arrows to target ExtendedClassTypes and RefinedClasses - this functionality was missing in previous versions.
 
:#* Event convergence property on state-machine transitions - convergence was previously available only on events
 
:# Enhancements to improve usability
 
:#* Report to user if translation didn't proceed due to model validator - previously, it was not clear when the model had failed validation and the translation had not been executed.
 
:#* Improve refresh of diagrams - in some situations the diagram graphics did not update error marking and properties changes unless some other event caused a refresh.
 
:#* Improvements and additions to model validations - some model validations were inconsistent or incomplete.
 
:#* Preference for line routing style for each diagram type - allows the user to choose whether to use rectilinear or oblique line routing for each diagram type.
 
:# Corrections
 
:#* Correct and improve missing default labelling in diagrams.
 
:#* Corrections and improvements to automatic diagram deletion.
 
:#* Improved management of diagram files when model changes.
 
:#* Add missing comment fields in properties view.
 
  
== UML-B State-machine Animation Plug-in==
+
== Type Rules for Code Generation ==
:The UML-B State-machine Animation Plug-in is a new feature developed by University of Southampton as a response to a request from industrial partners to support the animation of UML-B state-machine diagrams. The essence of the request was to provide a means of visualising the animation and model-checking process of Event-B machines modelled in UML-B tool, in particular state-machines, thus to simplify this process. The tool integrates the capabilities of ProB animation and UML-B State-machine notation.
 
  
== iUML-B - Integrated UML-B ==
+
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.
: The prototype iUML-B plug-in (not yet released) is an extension to the Event-B EMF framework. It will consist of a collection of independent plug-ins that provides support for diagrammatic modelling integrated with Event-B textual modelling. At this stage a plug-in to show the project structure (in terms of machines and contexts and their relationships has been released. A plug-in to support state-machine diagrams integrated with textual Event-B is at a prototype stage and nearing release. Plug-ins to support other kinds of diagram are in the early stages of development.
 
  
= Motivations =
+
= 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.
  
== Enhancement and Maintenance of Existing UML-B ==
+
== An Array Type Definition ==
Several case studies were involving state machine diagrams which were problematic because particular transitions could be enabled from any sub-state. there was no way to represent these cases in UML-B.
+
<div id="fig:Extension with an Array Type">
 +
<br/>
 +
[[Image:ArrayDef.png|center||caption text]]
 +
<center>'''Figure 2''': Array Definition</center>
 +
<br/>
 +
</div>
  
== Animation Plug-in ==
+
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.
The motivation for the Animation Plug-in was to extend already beneficial graphical notation of UML-B with animation capabilities similar to those that ProB tool provides for Event-B models. With the aid of such a plug-in animation and model checking would be possible on UML-B diagrams instead of translated and less obvious Event-B code. The resulting plug-in uses ProB tool to run the standard animation on translated models and animates UML-B state-machines at the same time.
 
  
= Choices / Decisions =
+
== Translation Rules ==
== Integrated UML-B ==
 
: It was planned to develop a new version (iUML-B) of UML-B which is more integrated with Event-B. A precursor stage to this was to develop an EMF representation of Event-B. This was completed last year and is now used successfully by several plug-ins. A Records plug-in was developed in response to user requests. The Records plug-in was implemented as an extension to the Event-B EMF framework. This was seen as a 'practice run' before attempting a similar extension to support UML-B. However, the Records plug-in took longer than expected and this has delayed work on iUML-B. Some progress on iUML-B has recently been made with the release of a project level diagram tool for Event-B and some progress on representing State-Machine diagram models as an extension to the Event-B EMF models.
 
  
== State-machine Animation Plug-in ==
+
<div id="Translation Rules for the Array Type">
: The initial design decision was to extend the UML-B metamodel with the animation components. Due to difficulties with UML-B diagram extensibility an alternative option was determined to create a separate model, derived from UML-B state-machine subset, with incorporated animation support. This design was successfully implemented together with ProB and Rodin UI extensions into Animation plug-in, which supports such UML-B concepts as classes and different state-machine translation kinds, as well as Event-B refinement.
+
<br/>
 +
[[Image:ArrayTrans.png|center||caption text]]
 +
<center>'''Figure 3''': Translation Rules for the Array Type</center>
 +
<br/>
 +
</div>
  
= Available Documentation =
+
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.
The following pages give useful information about UML-B:
 
* Lectures<ref name="UML-B">http://wiki.event-b.org/index.php/UML-B</ref>.
 
* Tutorials<ref name="UML-B">http://wiki.event-b.org/index.php/UML-B</ref>.
 
* Worked Examples<ref name="UML-B">http://wiki.event-b.org/index.php/UML-B</ref>.
 
 
 
UML-B State-machine Animation Plug-in:
 
* General information<ref>http://wiki.event-b.org/index.php/UML-B_-_Statemachine_Animation</ref>
 
* Tutorial<ref>http://wiki.event-b.org/index.php/Statemachine_Animation_Tutorial</ref>
 
 
 
= Planning =
 
During the coming year, special efforts will be made on the following topics,
 
* Development of the Project Diagram Plugin for Event-B to make it extensible and/or to automatically cater for future component types.
 
: The current version of the Project Diagram Plugin only supports Machines and Contexts and their relationships. Already, several plug-ins are contributing new kinds of components such as theories, tasking machines and compositions. The Project Diagram plug-in will be enhanced to provide an extension mechanism that allow other plug-ins to extend the project diagram to show new kinds of components and their relationship.
 
* Development of a State-machine diagram plug-in as an integrated part of Event-B modelling
 
: The State-machine diagram plug-in will provide a diagrammatic modelling environment based on state-machines alongside the usual Event-B modelling format. The two views will contribute to the same model simultaneously.
 
 
 
In parallel with these new plug-ins, the current version of UML-B will continue to be enhanced. This may include some new modelling features such as better support for synchronisation of state-machines and support for more UML modelling details. However, usability of the current features is seen as the main objective. This will include,
 
* Support for copy, cut and paste of diagram elements so that they can be moved and/or replicated more easily,
 
* Support for re-attaching links (e.g. transitions) to different source/target elements,
 
* Facilities for refactoring/renaming elements,
 
* Support for the event extension mechanism of Event-B,
 
* Integration of Context Diagram model elements on Class diagrams,
 
* Improve facilities for navigating between state-machines and visualising multiple state-machines.
 
 
 
== References ==
 
<references/>
 
 
 
[[Category:D32 Deliverable]]
 

Revision as of 15:51, 15 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


caption text
Figure 1: Translation Rules


Figure 1 shows the interface, and some translations rules of the mapping to Ada.

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 type. Meta-variables are used in the translator rules for pattern matching.

Translator rules are templates, which are used in pattern matching. 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.