imported>Tommy |
imported>Asiehsalehi |
| Line 1: |
Line 1: |
| − | This part concerns the general maintenance performed on the Rodin toolset within the first ten months of the ADVANCE project. As the maintenance is a task that concerns the whole toolset, and to ease the reading of this part of the deliverable, the maintenance section has been decomposed in a list of subsections corresponding to scopes of the toolset. These sections are: core Rodin platform, UML-B improvements, code generation, ProR and Camille. All these subsections maintain the template previously defined in the introduction.
| + | == Introduction == |
| | + | The Atomicity Decomposition (AD) plug-in allows an explicit representation of control flow and explicit representation of refinement relationships between an abstract event and the corresponding concrete events. |
| | | | |
| − | = Core Rodin platform =
| + | See the [http://wiki.event-b.org/index.php/Atomicity_Decomposition Atomicity Decomposition] page for technical details. |
| | | | |
| − | == Overview ==
| + | Currently the AD diagrams can be defined in an EMF tree structure included in an Event-B machine which is opened by Rose editor. After defining the control flow and refinement relationships via AD diagrams, the AD diagrams can automatically transformed to the Event-B notation. |
| − | The Rodin platform versions concerned by this deliverable are:
| |
| − | * 2.4 (released on 31.01.2012),
| |
| − | * 2.5 (released on 02.05.2012),
| |
| − | * 2.6 (released on 31.07.2012).
| |
| | | | |
| − | The core Rodin platform maintenance task focused on fixing the identified bugs and mitigating usability issues. During DEPLOY, many features and contributions were added to the toolset as users wishes and requests were collected along. At the same time, the Event-B models and proof got bigger and bigger, in the same way as the experience of the users involved constantly increased ergo the size of the systems they modelled. Scalability issues occured at some point when feature addition was favoured to design refactorings. As the DEPLOY project was nearing its end, it appeared mandatory for the development team, to address the specific bugs and issues reported by the DEPLOY partners and related to scalability or usability, and wished resolved by the end of the project. The various tasks to be performed were scheduled, prioritized and regularly updated during bi-weekly teleconferences.
| + | == Installing and Requirements == |
| | | | |
| − | 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). | + | === Setup === |
| − | Release Notes<ref name="relNotes">http://wiki.event-b.org/index.php/Rodin_Platform_Releases</ref> and the SourceForge trackers<ref>http://sourceforge.net/projects/rodin-b-sharp/</ref> (bugs and feature requests) are available for more details about the previous and upcoming releases of the Rodin platform.
| + | The following steps will guide you through the setup process: |
| | + | # Start Rodin. |
| | + | # In the menu choose ''Help'' -> ''Install New Software...''. |
| | + | # In the ''Work with'' dropdown list, choose the location URL: Rodin - [http://rodin-b-sharp.sourceforge.net/updates http://rodin-b-sharp.sourceforge.net/updates]. |
| | + | # Select the ''Event-B Atomicity Decomposition'' feature under the ''Modelling Extensions'' category, then click the check box. |
| | + | # Click ''Next'', after some time, the ''Install Details'' page appears. |
| | + | # Click ''Next'' and accept the license. |
| | + | # Click ''Finish''. |
| | + | # A ''Security Warning'' window may appear: click ''OK''. |
| | + | # Restart Rodin as suggested. |
| | | | |
| − | == Motivations / Decisions == | + | === Requirements === |
| − | '''Provide 64-bit versions of the Rodin platform on Linux and Windows systems'''<br>
| + | The AD plug-in requires [http://wiki.event-b.org/index.php/Rose_(Structured)_Editor Rose Editor Plug-in] and [http://www.eclipse.org/epsilon/download/ Epsilon framework]. |
| − | End users asked the Rodin team to provide 32-bit and 64-bit versions of the Rodin platform for Linux and Windows operating systems. Before Rodin 2.4, the only 64-bit version of Rodin was available on Mac platforms as 32-bit Mac (early 2006) platforms are no longer maintained by Apple. The motivation that would push forward 64-bit architectures is the possibility to increase the available java heap size which is, for example, extensively used during the automated proof. After a phase of testing and despite the drawbacks of assembling and maintaining five platforms instead of three, Linux and Windows 64-bit as well as 32-bit platforms are now systematically made available since the Rodin 2.4 release.
| |
| | | | |
| − | '''The Rodin Editor and the Theory plug-in in the Rodin core platform'''<br>
| + | == Creating Flow Diagrams == |
| − | According to their role in the Rodin toolset, and their stabilization, the Rodin Editor,<ref>http://wiki.event-b.org/index.php/Rodin_Editor</ref> and later the Theory plug-in<ref>http://wiki.event-b.org/index.php/Theory_Plug-in</ref> were reintegrated into the core platform. The Rodin Editor was released in the core platform since Rodin 2.4, and the Theory plug-in is planned to be integrated in Rodin 2.7.
| |
| | | | |
| − | == Available Documentation ==
| + | First you need to open the machine in the Rose editor by right-clicking on the machine. |
| − | The release notes, that appear and are maintained on the wiki, and that accompany each release, give useful information about the Rodin platforms. Moreover, two web trackers list and detail the known bugs and open feature requests:
| |
| − | * a sourceforge bug tracker,<ref>http://sourceforge.net/tracker/?group_id=108850&atid=651669</ref>
| |
| − | * a sourceforge feature requests tracker.<ref>http://sourceforge.net/tracker/?group_id=108850&atid=651672</ref>
| |
| − | The Event-B wiki,<ref name="rodinWiki">http://wiki.event-b.org/</ref> basic source of documentation for the users and developers of the Rodin toolset, was completed by the Rodin handbook, an ultimate source of documentation which reached completion by the end of the DEPLOY project. The handbook aimed to overcome the lack of a centralized source of information providing the necessary assistance to an engineer in the need to be productive using Event-B and minimize the access to an expert user. It is continuously maintained by the various actors involved in the environment of the Rodin toolset and is available as a PDF version, a HTML version, and help contents within Rodin. Both the Rodin handbook and the Event-B wiki represent the main source of documentation about Event-B and the Rodin toolset.
| |
| − | Finally, a channel has been created on Youtube, in order to provide video tutorials about the use of the platform.<ref>http://www.youtube.com/user/EventBTv</ref>
| |
| | | | |
| − | == Planning ==
| + | [[Image:machine_rose.jpg]] |
| − | Two platforms have been scheduled after Rodin 2.6 has been published: Rodin 2.7 followed by Rodin 3.0. Rodin 2.7 is intended to be released by the end of October 2012, and Rodin 3.0 will be available by the end of January 2013. Rodin 2.7 will be corrective. It has been scheduled to respect the 3 monthly release policy, as the Rodin 3.0 version will require more that 3 months of development. Indeed, this latter version of the platform is being prepared since Rodin 2.6, and will include lots of refactorings and evolutions in the published programming interfaces (API). Here is a non exhaustive list of the main improvements and refactorings that will be part of it:
| |
| − | *Binders will be allowed in extensions.
| |
| − | *The platform will be based on Eclipse 4.
| |
| − | *The AST will be made stronger.
| |
| − | *The sequent prover will be enhanced.
| |
| − | *Parent-child element relationship extension points will be moved from the UI plug-in to the EventB core plug-in.
| |
| − | *The Event-B keyboard plug-in will be refactored to separate the UI code from the ASCII/Math translation mechanism.
| |
| − | *The statistics view will be refactored to handle other kinds of component files (currently just Contexts and Machines are supported).
| |
| | | | |
| − | = UML-B Improvements =
| + | Then a flow can be created: |
| | + | {| |
| | + | |- |
| | + | |1. Either for an Event-B machine, when right-clicking on the machine. |
| | + | |2. Or for a pre-defined leaf, when right-clicking on the leaf. |
| | + | |- |
| | + | | valign="top" | [[Image:flow_machine.jpg|center]] |
| | + | | valign="top" | [[Image:flow_leaf.jpg|center]] |
| | + | |} |
| | | | |
| − | == Overview ==
| + | The following steps will guide you through a combined atomicity decomposition diagram: |
| | + | * Create a flow for the most abstract machine. |
| | + | * When refining a machine, the pre-defined flows are copied to the new (refining) machine. |
| | + | * In the new machine, you can create a new flow for each pre-defined leaf. |
| | | | |
| − | The UML-B plug-in and associated frameworks are developed and maintained by Dr Colin Snook at the University of Southampton. Significant contributions (to the latest version) have been made by Vitaly Savicks (State-machines) and Gintautas Sulskus (Class Diagrams). The UML-B plugin provides UML-like diagrammatic modelling as an extension to Event-B and the Rodin platform. UML-B is an established plug-in which will be developed and improved to support the aims of the ADVANCE project. UML-B was redeveloped during the DEPLOY project to provide closer integration with Event-B. A state-machine diagram editor is already released in this integrated version and a class diagram editor is now being developed as a prototype.
| + | == Elements and Properties == |
| − | [[Image:Umlb_cap2.jpg|center|A UML-B state machine and its Event-B counterpart]]
| |
| − | Other improvements will include new diagrammatic notations which are directly related to the aims of ADVANCE, such as component diagrams, as well as more general improvements, such as usability, and any features required by the projects industrial partners.
| |
| | | | |
| − | == Motivations / Decisions ==
| + | For each flow, you can define one or more of the below elements, when right-clicking on the flow: |
| | + | * typed parameter |
| | + | * leaf |
| | + | * ''loop'' constructor including one leaf (right-click on the ''loop'') |
| | + | * ''and'' constructor including two or more leaves (right-click on the ''and'') |
| | + | * ''or'' constructor including two or more leaves (right-click on the ''or'') |
| | + | * ''xor'' constructor including two or more leaves (right-click on the ''xor'') |
| | + | * ''all'' constructor including one leaf and one parameter (right-click on the ''all'') |
| | + | * ''some'' constructor including one leaf and one parameter (right-click on the ''some'') |
| | + | * ''one'' constructor including one leaf and one parameter (right-click on the ''one'') |
| | | | |
| − | The implementation of the UML-B tool is structured to provide re-usable features as much as possible. To achieve this, wherever possible, generic frameworks are developed and the implementation of specific diagram tools is minimised by utilising these frameworks. The following frameworks are now in use by UML-B and available as a basis for future diagrammatic modelling notations.
| + | [[Image:flow_children.jpg]] |
| | | | |
| − | * The ''Event-B EMF framework'' provides an EMF basis for Event-B models (developed during the DEPLOY project). Indeed, it provides an EMF representation of Event-B models with persistence into the Rodin database. | + | === Flow Properties === |
| − | * The ''Event-B EMF Support for Modelling Extensions framework'' provides support for extending Event-B with new modelling features (initially developed during the DEPLOY project and now being extended in the ADVANCE project). It provides Navigator support for EMF-only model elements, a persistence mechanism for model extensions that are not needed to be processed by Rodin and a Generic Refiner for modelling extensions (which has recently been added). | + | * Name: a string containing the name of the root event. |
| − | * ''The Event-B GMF Diagrams Generic Support framework'' provides support for developing new diagram notations (started in the DEPLOY project but mostly developed during the ADVANCE project). It provides generic support for diagrammatic aspects of modelling extensions, and a generic validation and Event-B generation service (which has recently been added).
| + | * Sw: a boolean indicates strong (''true'') / weak (''false'') sequencing. |
| − |
| |
| − | A new release of the State-machine diagram editor has been made. This release corrected some problems and improved use of the generic framework features.
| |
| | | | |
| − | Work is in progress on a new version of the UML-B Class Diagram editor. This takes the same approach as the State-machines editor in that the models are contained within Machines (and, in this case, also Contexts) and that diagrammatic model features link to and enhance existing Event-B elements rather than generate everything. The Class diagram editor is currently a prototype and has not been released.
| + | === Leaf Properties === |
| | + | * Name: a string containing the name of the event. |
| | + | * Ref: a boolean indicates refining (''true'') / non-refining (''false'') event. |
| | | | |
| − | == Available Documentation ==
| + | [[Image:leaf_properties.jpg]] |
| | | | |
| − | A paper exists about the framework for diagrammatic modelling extension in Rodin:
| + | === Constructor Properties === |
| − | Savicks, Vitaly, Snook, Colin (2012) ''A Framework for Diagrammatic Modelling Extensions in Rodin'' in Rodin User & Developer Workshop 2012 Proceedings. Newcastle University. (Unpublished) <ref>http://deploy-eprints.ecs.soton.ac.uk/382/</ref>
| + | * Ref: a boolean indicates refining (''true'') / non-refining (''false'') constructor (''loop'', ''and'' / ''or'' / ''xor'' / ''all'' / ''some'' / ''one''). |
| | + | NOTE: The refining property for (''loop'' / ''and'' / ''or'' / ''all'' / ''some'') constructors has to be ''false''. |
| | | | |
| − | Wiki pages are available for developers using the Generic extensions and Diagrams frameworks:<br>
| + | === Parameter Properties === |
| − | http://wiki.event-b.org/index.php/EMF_framework_for_Event-B<br>
| + | * Name: a string containing the name of the parameter. |
| − | http://wiki.event-b.org/index.php/Generic_Event-B_EMF_extensions (Under Construction)
| + | * Type: a string containing the type of the parameter. |
| | + | NOTE: the parameter type has to be defined in the context. |
| | | | |
| − | A paper exists about the Event-B Statemachines:
| + | == Transforming to Event-B == |
| − | Savicks, Vitaly, Snook, Colin and Butler, Michael (2009) ''Animation of UML-B State-machines'' in Rodin User & Developer Workshop 2010 Proceedings. Düsseldorf University, 2010.<ref>http://eprints.soton.ac.uk/268261/</ref>
| |
| | | | |
| − | Wiki pages are available for users of UML-B, everything starts from http://wiki.event-b.org/index.php/UML-B<ref>http://wiki.event-b.org/index.php/UML-B</ref>
| + | For each machine, after completing the flow construction process, you can perform the translation rules to transform the defined AD flow to the Event-B notation (For technical details see [http://wiki.event-b.org/index.php/Atomicity_Decomposition Atomicity Decomposition] page). This is done by right-clicking on the machine and launch ''Atomicity Decomposition Transformation -> Transform to Event-B''. |
| | | | |
| − | == Planning ==
| + | As a result, some read-only event-B elements are generated in order to manage the defined control flow and refinement relationships. User defined event-B elements are allowed; but you can not alter the generated read-only elements. |
| | | | |
| − | The following work is planned:
| + | == Validation Rules to Follow == |
| − | * Re-base the Event-B EMF framework on the EMF model of the Rodin database (which is now available as a result of the development of a new Rodin editor to replace the form based editor).
| |
| − | * Re-write the Event-B generator of the State-machine diagram editor so that it uses the generic generator from the Event-B GMF Support for Generic Diagrams framework. This will improve performance.
| |
| − | * Improve the State-machine diagram animation interface so that it supports animation of multiple diagrams.
| |
| − | * Complete the development of the new version of the UML-B Class Diagram editor.
| |
| − | * Develop Animation interface for the Class diagram editor.
| |
| − | * Develop a Component diagram editor and associated simulation tools.
| |
| | | | |
| − | = Code generation =
| + | In order to perform the translation rules correctly, you will need to follow these rules: |
| | + | (For more information about technical reasons see [http://wiki.event-b.org/index.php/Atomicity_Decomposition Atomicity Decomposition] page) |
| | | | |
| − | == Overview == | + | * Rules on the flow: |
| − | We released the latest Code Generation Feature on 30th May 2012.
| + | ** Never change the ''copy'' property of a flow. This is an internal property use to make the internal programming decision. |
| − | New features include code generation from state-machine diagrams.
| + | ** A most abstract flow is a flow with (''sw'' = ''true'') and its children are all non-refining (''ref'' = ''false''). |
| | + | ** For each non-abstract flow, EXACTLY one refining child (''ref'' = ''true'') has to be defined. |
| | + | ** Each flow inherits its parameter from its parent flow and parent (''all'' / ''some'' / ''one'') constructor (if exists). This has to be done manually. For each new defined flow, copy and paste all necessary parameters from pre-defined parent flow / constructor. |
| | + | ** For technical reasons, a ''loop'' constructor never can placed as the first or last child of a flow. |
| | | | |
| − | == Motivations / Decisions ==
| + | *Rules on the parameter: |
| − | State machines are frequently used to describe the behaviour of embedded systems. It is a relatively new feature in Event-B, and we augment the tool with the ability to generate code from state-machine diagrams in version 0.2.3 of the code generation feature plug-in. Implementation code is generated from the diagram itself, and no additional mark-up of the model is required; that is, nothing over and above the usual mark-up required for Tasking Event-B, such as identifying non-typing/typing invariants, and guards etc. State-machines are created, using the existing state-machine plug-in, subject to the limitations described after.
| + | ** The parameter type has to be defined in the context. |
| | + | ** The parameter name has to be unique. |
| | | | |
| − | The current code generation tool is restricted to generating code for a single Event-B machine, which may contain one or more state-machines. We have yet to explore the decomposition/composition of machines containing state-machines. In principal we should be able to apply decomposition techniques to decompose the single Event-B machine with state-machines into a number of machines, with the state-machines, or the elements of state-machines, distributed between them.
| + | * Rules on the constructors: |
| − | Another limitation is that we do not handle nested state-machines, although this should be feasible.
| + | ** The refining property for (''loop'' / ''and'' / ''or'' / ''all'' / ''some'') constructors has to be ''false''. |
| − | Only the state-machines of tasking/environ machines generate code. State-machines of shared machines do not generate code. This should be explored further during research into decomposition.
| + | ** A constructor leaf inherits its refining property from its parent constructor. For example, for a refining ''xor'' (''ref'' = ''true''), all of its leaves' refining property has to be ''true''. Therefore the (''loop'' / ''and'' / ''or'' / ''all'' / ''some'') children refining property is always ''false''. |
| − | | |
| − | The translation of the diagrammatic elements to code has been hard-coded in the code generation plug-in. We have introduced new types to the translator's common language model (IL1). We add case-statements, and a container for them (analogous to switch) since these are commonly used to implement state-machines. The code generator navigates through each state of a state-machine, generating an internal representation of the state-machine, which is used to create the IL1 model. The IL1 model is then used to generate code for the various target languages that may have been implemented. We have also updated the IL1-to-target code generators, to generate case/switch statements in Ada, C and Java.
| |
| − | Each state-machine has an Enumerated type whose elements take the names of the states. A state variable is created in the target that keeps track of the current state, and has the type of the enumeration.
| |
| − | | |
| − | == Available Documentation ==
| |
| − | A specific page on the Event-B wiki<ref>http://wiki.event-b.org/index.php/Code_Generation_Activity</ref> is dedicated to Code Generation Updates.
| |
| − | | |
| − | == Planning ==
| |
| − | Efforts will focus on extending the existing code generation approach, and developing new techniques, for the simulation of cyber-physical systems.
| |
| − | | |
| − | = ProR =
| |
| − | | |
| − | == Overview ==
| |
| − | | |
| − | The Rodin/ProR integration plugin is developed and maintained by Lukas Ladenberger and Michael Jastram at the University of Duesseldorf. ProR is a tool for working with requirements in natural language. It is part of the Eclipse Requirements Modeling Framework (RMF).<ref>http://www.eclipse.org/rmf/</ref> | |
| − | | |
| − | The following paragraphs will give an overview of the the work that has been performed concerning maintenance on the Rodin/ProR plugin.
| |
| − | | |
| − | == Motivations / Decisions ==
| |
| − | | |
| − | The motivation of the Rodin/ProR integration plugin was to bring two complimentary fields of research, requirements engineering and formal modelling, closer together. Especially, the traceability within a system description is a challenging problem of requirements engineering. In particular, formal models of the system are often based on informal requirements, but creating and maintaining the traceability between the two can be challenging. In ''A Method and Tool for Tracing Requirements into Specifications''<ref name="req1ref">http://www.stups.uni-duesseldorf.de/w/Special:Publication/HalJasLad2012</ref>, we presented an incremental approach for producing a system description from an initial set of requirements. The foundation of the approach is a classification of requirements into artefacts W (domain properties), R (requirements) and S (specification). In addition, the approach uses designated phenomena as the vocabulary employed by the artefacts. The central idea is that adequacy of the system description must be justified, meaning that W ∧ S ⇒ R. The approach establishes a traceability, and the resulting system description may consist of formal and informal artefacts. We created tool support for this approach by integrating Rodin and ProR. We designed it with the goal to support the approach described in <ref name="req1ref"/>, and to ease the integration of natural language requirements and Event-B.
| |
| − | | |
| − | == Available Documentation ==
| |
| − | | |
| − | * ''A Method and Tool for Tracing Requirements into Specifications''.<ref name="req1ref"/> The paper has been submitted to Science of Computer Programming.
| |
| − | * ''Requirements Traceability between Textual Requirements and Formal Models Using ProR''.<ref>http://www.stups.uni-duesseldorf.de/w/Special:Publication/LadenbergerJastram_iFMABZ2012</ref> The paper has been accepted for iFM'2012 & ABZ'2012.
| |
| − | | |
| − | * A Tutorial for the Rodin/ProR integration<ref>http://wiki.event-b.org/index.php/ProR</ref> can be found on the Event-B wiki. | |
| − | * The User Guide<ref>http://wiki.eclipse.org/RMF/User_Guide</ref> is available on the Event-B wiki and contains an additional tutorials for ProR.
| |
| − | | |
| − | == Planning ==
| |
| − | | |
| − | There are still some limitations on the ProR/Rodin integration plugin, however. While all required data structures exist, the plugin would benefit from more sophisticated reporting. In particular, <ref name="req1ref"/> lists a number of properties of a correct system description. While the presence of these properties does not guarantee correctness, their absence indicates a problem. This is already done, to a degree, through the colour highlighting, but a reporting tool that lists all violations of those properties would be valuable and is planned.
| |
| − | | |
| − | Currently, each used artifact is identified as belonging to one of the following class: domain properties, requirement items, specification elements, implementation elements and design decisions. This in turn will determine the kinds of phenomena that are allowed to be used by the artefact. For the moment, the plugin does not support phenomena classification. In a next step, we will work on a concept for classifying and maintaining phenomena with ProR.
| |
| − | | |
| − | = Camille =
| |
| − | | |
| − | == Overview ==
| |
| − | The Camille plug-in provides a textual editor for Rodin.
| |
| − | Though such a text editor is prefered by many users, Camille currently has the drawback of not supporting extensibility.
| |
| − | It only supports the core Event-B language and plug-in-specific additions are simply ignored. Such extensions can not be edited through Camille.
| |
| − | Consequently, users have to switch back to Rodin's native Editor to edit plug-in-specific modelling extensions.
| |
| − | This has become a major issue during the last years, since many plug-ins have been developed in the meantime that are widely used by many users.
| |
| − | | |
| − | This issue is currently being adressed by Ingo Weigelt at the University of Duesseldorf.
| |
| − | | |
| − | == Motivations / Decisions ==
| |
| − | A new version of Camille will be implemented during the ADVANCE project to enable users to edit extended Event-B models solely through a text editor.
| |
| − | To plan the new version, the problem and a number of possible solutions have been analysed and related in a technical report<ref name="Architectures_for_an_Extensible_Text_Editor_for_Rodin">http://www.stups.uni-duesseldorf.de/mediawiki/images/0/0a/Pub-Weigelt2012.pdf</ref> from Ingo Weigelt.
| |
| − | The results of this work have been dicussed in the Rodin community and one of the proposed solution (a blockparser) has been selected to be implemented during the next months.
| |
| − | The dedicated solution promises to provide Camille extensibility with minimal extra workload required from plug-in developers while still being very flexible regarding future, yet unknown, requirements.
| |
| − | | |
| − | == Available Documentation ==
| |
| − | | |
| − | * ''Architectures for an Extensible Text Editor for Rodin''.<ref name="Architectures_for_an_Extensible_Text_Editor_for_Rodin"/> Bachelor thesis analysing the problem and discussing possible solutions.
| |
| − | * An earlier version of the thesis has been published as a technical report<ref>http://www.stups.uni-duesseldorf.de/w/Special:Publication/Weigelt2012></ref> that has been discussed on the Roding Developers Mailing List and the ADVANCE Progress Meeting in May 2012 in Paris.
| |
| − | | |
| − | == Planning ==
| |
| − | The new Camille version will be implemented at the University of Duesseldorf during 2012. The final version is expected in January or February 2013.
| |
| − | | |
| − | = References =
| |
| − | <references/>
| |
| − | | |
| − | [[Category:ADVANCE D3.2 Deliverable]]
| |
