Difference between pages "D45 General Platform Maintenance" and "Extending the project explorer"

From Event-B
(Difference between pages)
Jump to navigationJump to search
imported>Ilya.lopatkin
 
imported>Renato
 
Line 1: Line 1:
= Overview =
+
{{TOCright}}
The Rodin platform versions concerned by this deliverable are:
+
= Introduction =
* 2.1(08.02.2011),
+
The purpose of this page is to describe how to extend the Event-B project explorer. It covers on the one hand, the definition of the extension, and on the other hand its implementation. The Event-B project explorer is itself an implementation of the extension-point <tt>org.eclipse.ui.views</tt>. The corresponding view id is '''fr.systerel.explorer.navigator.view''' which is defined as a subclass of <tt>org.eclipse.ui.navigator.CommonNavigator</tt> and it is over this view that we extend the project explorer.
* 2.2(01.06.2011),
 
* 2.2.2(01.08.2011),
 
* 2.3(04.10.2011),
 
* 2.4(31.01.2011),
 
* 2.5(30.04.2011).
 
This year, the maintenance carried on fixing identified bugs, although an emphasis was put on correcting usability issues. Indeed, during the annual meeting in Nice, the WP9 members agreed to refocus on the needed tasks to address some specific bugs and issues reported by DEPLOY partners, and wished resolved by the end of DEPLOY. Thus, no new features were implemented but those appearing in the description of work. The tasks to be performed by the WP9 members were then scheduled, prioritized and regularly updated during the WP9 bi-weekly meetings. The updates allowed to capture and integrate rapidly some minor changes to enhance the usability of the platform which were required by the DEPLOY partners. 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).
 
  
See the Release Notes<ref name="documentation">http://wiki.event-b.org/index.php/D32_General_Platform_Maintenance#Available_Documentation</ref> and the SourceForge<ref name=documentation>http://wiki.event-b.org/index.php/D45_General_Platform_Maintenance#Available_Documentation</ref> databases (bugs and feature requests) for details about the previous and upcoming releases of the Rodin platform.
+
[[Image:EventB project explorer.png]]
  
* General platform maintenance
+
The useful extension points are listed below; they offer the possibility to contribute to the project explorer:
The maintenance done to overcome Rodin scalability weaknesses and enhance the proving experience will be detailed in a separate chapter. However, some features initially planned and some other which were later added and prioritized are worth to mention:
+
* <tt>org.eclipse.ui.navigator.navigatorContent</tt>
:*Possibility to highlight patterns in the ProverUI,
+
* <tt>org.eclipse.ui.navigator.viewer</tt>
:*A better output providing warnings and errors in case of wrong or missing building configurations,
 
:*The switch to Eclipse 3.7,
 
:*A Handbook to complete and enhance the existing documentation.
 
  
== An overview of the contribution about Mathematical extensions / Theory Plug-in (Issam Maamria) ==
+
= Before Starting =
Mathematical extensions have been co-developed by Systerel (for the Core Rodin Platform) and Southampton (for the Theory plug-in). The main purpose of this new feature was to provide the Rodin user with a way to extend the standard Event-B mathematical language by supporting user-defined operators, basic predicates and algebraic types. Along with these additional notations, the user can also define new proof rules (prover extensions).
 
A theory is a file that can be used to define new algebraic types, new operators/predicates and new proof rules. Theories are developed in the Rodin workspace, and proof obligations are generated to validate prover and mathematical extensions. When a theory is completed and (optionally) validated, the user can make it available for use in models (this action is called the deployment of a theory). Theories are deployed to the current workspace (i.e., Workspace Scope), and the user can use any defined extensions in any project within the workspace.
 
The scope of the ongoing work on the Theory plug-in centers around bug fixes, improving usability and performance and exploring other venues for operator definitions.
 
* {{TODO}} An overview of the contribution about Plug-in Incompatibilities (All partners)
 
  
* {{TODO}} An overview of the contribution about Modularisation (Alexei Illiasov)
+
It is necessary to define the elements and structure to be represented. We will use as an example the ''decompositionFile'' that is defined as follows:
  
* {{TODO}} An overview of the contribution about Decomposition (Renato Silva)
+
*decompositionFile
 +
**decompositionRoot
 +
***Component with the following attributes: ''machine'' (to be decomposed)
 +
***Configuration with the following attributes: ''style'': shared event/shared variables; ''newProjectOption'': decompose in the same project/different projects; ''decomposeContextOption'': noDecomposition/minimal decomposition)
 +
***SubComponent (resulting decomposed parts) with the following attributes: ''label''
 +
****SubComponentElement (elements used to decompose:variables for shared event and events for shared variable) with the following attributes: '' element name/identifier''
  
* {{TODO}} An overview of the contribution about Team-based Development (Colin Snook, Vitaly Savicks)
+
[[Image:Decomp file pretty print.png]]
  
* {{TODO}} An overview of the contribution about UML-B (Colin Snook, Vitaly Savicks)
+
= Navigator Content =
  
== An overview of the contribution about ProR (Michael Jastram) ==
+
A content extension provides a content and label provider that can be used by a navigator content service (in out case the ''Event-B project explorer''). The navigatorContent extension defines the specific classes for the content provider, label provider, and action provider in addition to the types of elements the extension knows about. To extend the project explorer, it is also required to add the following children of the navigatorContent:
  
ProR is a replacement of the original requirements plug-in, which got discontinued in 2010. It is based on the OMG ReqIF standard (<ref name="reqif">http://www.omg.org/spec/ReqIF/</ref>), which provides interoperability with industry tools. It evolved into the Eclipse Foundation project "Requirements Modeling Framework" (RMF, <ref name="rmf">http://eclipse.org/rmf</ref>), resulting in significant visibility. ProR is independent from Rodin.  Integration is achieved with a separate plug-in that provides support for traceability and model integration.
+
* ''triggerPoints'': defines the nodes to be used when resolving the Common Navigator content provider's getElements() or getChildren(). This is also used to select the extension for providing labels, images, descriptions and for sorting.
 +
*''possibleChildren'': defines the node to be used when resolving the Common Navigator content provider's getParent(). It is also used to help determine the parent when handling drop operations.
  
== An overview of the contribution about BMotion Studio (Lukas Ladenberger) ==
+
== Declaration ==
  
BMotion Studio is a visual editor which enables the developer of a formal model to set-up easily a domain specific visualisation for discussing it with the domain expert. BMotion Studio comes with a graphical editor that allows to create a visualisation within the modeling environment. Also, it does not require to use a different notation for gluing the state and its visualisation. BMotion Studio is based on the ProB animator and is integrated into the RODIN tool. However, BMotion Studio is independent from Rodin. Integration is achieved with a separate plug-in.
+
The navigatorContent extension-point allows tool writers to register their tool implementation under a symbolic name that is then used by the Rodin platform to find and run the tool. The symbolic name is the id of the tool extension. The declaration of this extension is defined as follows:
  
The main advantages of BMotion Studio are:
+
<!ELEMENT navigatorContent ((enablement | (triggerPoints , possibleChildren)) , actionProvider* , commonSorter* , override? , dropAssistant* , commonWizard*)>
 +
  <!ATTLIST navigatorContent
 +
  id                CDATA #REQUIRED
 +
  name              CDATA #REQUIRED
 +
  priority          (lowest|lower|low|normal|high|higher|highest)
 +
  contentProvider  CDATA #IMPLIED
 +
  icon              CDATA #IMPLIED
 +
  activeByDefault  (true | false)
 +
  providesSaveables (true | false)
 +
  labelProvider    CDATA #IMPLIED
 +
>
  
* The modeler stays within a single notation. BMotion Studio uses Event-B predicates and expressions as gluing code.
+
A navigator content extension defines a content provider and label provider that can be used to provide children whenever an element matches the triggerPoints expression and also to provide a parent whenever an element matches the possibleChildren expression. Optionally, we may also provide an action provider which can provide menu contributions and action bar contributions when an element is selected that the extension contributed, or that matches the triggerPoints expression. It is possible to contribute with a sorter to sort elements that are contributed by the extension.
* An easy to use graphical editor, that allows to create visualisations with a few mouse clicks.
 
* BMotion Studio comes with a number of default observers and controls that are sufficient for most visualisations.
 
* It can be extended for specific domains.
 
  
== An overview of the contribution about Mode/FT Views ==
+
* id - A unique ID to identify this extension. Used for extension activation and by other extensions that would like to extend the defined extension (e.g. add another <tt>org.eclipse.ui.navigator.CommonActionProvider</tt>)
The Mode/FT Views plug-in is a modelling environment for constructing modal and fault tolerance features in a diagrammatic form and formally linking them to Event-B models. The consistency conditions between the modal/FT views and Event-B models are ensured by additional proof obligations. The views form a refinement chain of system modal and fault tolerant behaviour which contribute to the main Event-B development. The views reserve a place for tracing modal and FT requirements.
+
* name - Specify a display name for the Content Extension. The display name is used in the activation dialog to allow clients to turn an extension on or off.
 +
* priority - Indicates the relative priority of this extension to other extensions. Used by the Common Navigator to handle sorting and organization of the contributed content from this extension in relation to content from other extensions. Defaults to "normal"
 +
* contentProvider - Supplies the name of a class which implements <tt>org.eclipse.jface.viewers.ITreeContentProvider</tt> or <tt>org.eclipse.ui.navigator.ICommonContentProvider</tt>. The content provider will be consulted when adding children to the tree. Use the enablement, triggerPoints, or possibleChildren clauses to indicate what kinds of content should trigger a request to your content provider. Elements contributed from the content provider are not guaranteed to appear in the tree in the same order. Clients should take advantage of the sorting extension (commonSorter) to ensure proper ordering of their elements. All elements contributed by this content provider are associated with this navigatorContent extension for the purposes of determining the label provider, action providers, sorters, drop assistants and common wizards.
 +
* icon - A plugin-relative path to an icon for use when displaying the metadata about the content extension to the user.
 +
* activeByDefault - Indicates whether the current extension will be active by default. Each content extension may be turned on or off by the user. The active state is differentiated from the visible state. See <tt>org.eclipse.ui.navigator.viewer/viewerContentBinding</tt> for more information on visibility
 +
*labelProvider - Supplies the name of a class which implements <tt>org.eclipse.jface.viewers.ILabelProvider</tt> or for more advanced functionality, the <tt>org.eclipse.ui.navigator.ICommonLabelProvider</tt>. Clients may also implement <tt>org.eclipse.ui.navigator.IDescriptionProvider</tt> in order to add text to the status bar at the bottom of the Eclipse workbench based on the selection in the viewer. Since Eclipse 3.4, clients may also implement <tt>org.eclipse.jface.viewers.DelegatingStyledCellLabelProvider.IStyledLabelProvider</tt> to provide styled text labels. Note that the empty styled string signals that the label provider does not wish to render the label.
  
= Motivations =
+
===Action Provider===
The tasks to solve the issues faced by the DEPLOY partners have been listed and have been assigned to groups according to their priority. A high priority means a high need in the outcome of a given task. The group 1 has the highest priority, the group 2 has an intermediate priority, and the group 3 has the lowest priority. The group 4 concerns topics that could not be resourced during the lifetime of DEPLOY.The prover integrity item, although not being directly covered, has been partially addressed thanks to Isabelle and SMT integration. Unfortunately, the originally planned export of full proofs and integrity check was too ambitious to be fully achieved in the scope of DEPLOY.
 
  
{{SimpleHeader}}
+
Still inside the navigatorContent, it is possible to add the following:
|-
 
! scope=col | Group 1 (highest priority) || Responsible
 
|-
 
|Performance <br /> - Core (large models, etc.) <br /> - GUI (incl. prover UI, edition, etc.) || SYSTEREL
 
|-
 
|Prover Performances <br /> - New rewriting rules / inference rules <br /> - Automatic tactics (preferences, timeout, etc.) || SYSTEREL
 
|-
 
|ProB Disprover (incl. counter examples to DLF POs) || Düsseldorf
 
|-
 
|Stability (crash, corruption, etc.)  || SYSTEREL
 
|-
 
|Editors || SYSTEREL/Düsseldorf
 
|-
 
|}
 
{{SimpleHeader}}
 
|-
 
! scope=col | Group 2 || Responsible
 
|-
 
| Prover Performances <br /> - SMT provers integration <br /> - connection with Isabelle  <br /> - Mathematical extensions <br /> - ProB || <br />SYSTEREL <br /> ETH Zürich <br /> Southampton/SYSTEREL <br /> Düsseldorf
 
|-
 
|Scalability <br /> - Decomposition <br /> - Modularisation plug-in <br /> - Team-based development || <br /> Southampton <br /> Newcastle <br /> Southampton
 
|-
 
|Plug-in incompatibilities || Newcastle
 
|-
 
|Model-based testing || Pitesti/Düsseldorf
 
|-
 
|ProR || Düsseldorf
 
|}
 
{{SimpleHeader}}
 
|-
 
! scope=col | Group 3 || Responsible
 
|-
 
|Scalability <br /> - Generic instantiation <br /> - UML-B maintenance <br /> || <br /> Southampton <br /> ETH Zürich/Southampton
 
|-
 
|Code Generation || Southampton
 
|}
 
{{SimpleHeader}}
 
|-
 
! scope=col | Group 4
 
|-
 
|Prover Integrity
 
|-
 
|Integrity of Code Generation
 
|}
 
== Platform maintenance ==
 
The platform maintenance, as it can be deduced from the above tables in section [[#Motivations | Motivations]], mainly concerned stability and performance improvement. These topics will be discussed and detailed in a separate chapter about scalability improvements.<br>
 
However, other improvements of utmost importance were made on the platform. These improvements either came from DEPLOY partners specific needs, or were corresponding to previously identified needs (listed in D32 - Model Construction tools & Analysis III Deliverable).
 
Hence we review below the motivations of some noteworthy implemented features:
 
* A Possibility to highlight patterns in the Prover UI.
 
This feature came from a request of DEPLOY partners<ref name="searchInPUI">https://sourceforge.net/tracker/?func=detail&atid=651672&aid=3092835&group_id=108850</ref>, often facing the need to find particular patterns such as expressions in long predicates (e.g. long goals). Since Rodin 2.2, and its new Proving UI interface, a nice feature was added, allowing to search and highlight a string pattern into the whole Proving UI views and editors. This function as also been enabled on direct selection of text in this UI.
 
* A better output providing warnings and errors in case of wrong or missing building configurations.
 
This issue, often seen as a bug or as a plug-in incompatibility, was raised when a user imports and tries to use a model on a platform with some missing required plug-ins. The user often thought his models corrupted whereas Rodin was not able to build them, and hid this information to the user. This is why, since Rodin 2.3, an output has been provided in such case, taking the form of warnings or errors that any user can understand and review. This is a first answer to Rodin plug-in incompatibilities issues.
 
* The switch to Eclipse 3.7.
 
Due to the major improvements made every year in Eclipse releases and the continuously growing number of contributing projects which are for some of them used as basis for Rodin plug-ins, the Rodin platform follows the evolution and is adapted every year quickly to the latest Eclipse version available. This year, Rodin 2.3 originated the switch from Eclipse 3.6 to Eclipse 3.7.
 
* A Handbook to complete and enhance the existing documentation.
 
At the DEPLOY Plenary Meeting in Zürich in 2010, it has been stated that the current documentation, in its state at that time, would not support a engineer starting using the tools without significant help of an expert <ref name="documentationoverhaul>http://wiki.event-b.org/index.php/User_Documentation_Overhaul</ref>. Significant efforts to improve the documentation were performed and coordinated by Düsseldorf, and took form of a handbook<ref name="RodinHandbook">http://handbook.event-b.org/</ref>. The Rodin handbook has the aim to minimize the access to an expert, by providing the necessary assistance to an engineer in the need to be productive using Event-B and the Rodin toolset. The contents of the handbook, user oriented, were originated by some contents of the Event-B wiki.
 
  
== Mathematical extensions / Theory Plug-in (Issam Maamria) ==
+
<!ELEMENT actionProvider (enablement?)>
The Theory plug-in enables the definition of mathematical and prover extensions. It provides a high-level interface to the Rodin Core capabilities with regards to mathematical extensions. The Rule-based Prover was originally devised to provide an usable mechanism for user-defined rewrite rules through theories. Theories were, then, deemed a natural choice for defining mathematical extensions as well as proof rules to reason about such extensions. In essence, the Theory plug-in provides a systematic platform for defining and validating extensions through a familiar technique: proof obligations.
+
  <!ATTLIST actionProvider
 +
  class        CDATA #REQUIRED
 +
  id            CDATA #IMPLIED
 +
  dependsOn    CDATA #IMPLIED
 +
  overrides    CDATA #IMPLIED
 +
  priority      (lowest|lower|low|normal|high|higher|highest)
 +
  appearsBefore IDREF #IMPLIED
 +
  >
  
Support for using polymorphic theorems in proofs was added in version 1.1.
+
A top level actionProvider is visible to an abstract viewer if there is a viewerActionBinding for that actionProvider. It is possible to provide actionProvider(s) under the root extension element (peer to other navigatorContent) in order to better control their enablement and viewer binding (see viewerActionBinding). Any items contributed to the toolbar or the view menu should be removed when the actionProviders is disposed. We described the two most used attributes of this element:
  
== Plug-in Incompatibilities ==
+
* ''class'' - Supplies the name of a class that implements <tt>org.eclipse.ui.navigator.CommonActionProvider</tt>. The action provider has an opportunity to contribute to the context menu and the retargetable actions defined in the IActionBars for the view that holds the navigator. It is also possible to contribute directly to the view menu through the IActionBars view menu.
By its extensibility nature, the Rodin platform is susceptible to incompatibilities. Indeed, there are many ways in which incompatibilities could occur, and some occurred in the lifetime of DEPLOY. A good example, is the dependency management. Suppose that a bundle x_v1.0 is needed by a plug-in A (i.e. a dependency from A has been defined to x in at most the version 1.0) and installed in Rodin. Then the plug-in x_v1.1 is needed by a plug-in B. The both versions 1.0 and 1.1 of x could not be installed and used at the same time and create thus some usage incompatibility.
+
* ''id'' - Clients may optionally define an id to use for filtering purposes (either through activities or viewerContentBindings).
  
== Modularisation ==
+
To define when to enable this actionProvider, it is necessary to define the ''enablement'':
{{TODO}} ''To be completed by Alexei Illiasov''
 
== Decomposition ==
 
{{TODO}} ''To be completed by Renato Silva'' 
 
== Team-based Development ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
 
== UML-B ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
 
== ProR ==
 
  
While the original requirements plug-in for Rodin was useful as a prototype, a number of shortcomings lead to a new development.  In particular, the original plug-in was a traceability tool with externally managed requirements.  With ProR, requirements are authored and edited within Eclipse.  The original plug-in supported only a limited number of attributes and flat (unstructured) requirements.  ProR supports all data structures that the ReqIF standard<ref name="reqif">http://www.omg.org/spec/ReqIF/</ref> supports. Further, ReqIF-support for industry tools like Rational DOORS, MKS or IRqA is expected in the near future, while the original plug-in required a custom adaptor for each data format.
+
<!ELEMENT enablement (not , and , or , instanceof , test , systemTest , equals , count , with , resolve , adapt , iterate , reference)*>
  
ProR is developed independently from Rodin.  Dependencies to Rodin exist only in the Rodin integration plug-in. This significantly decreases the maintenance effort for the integration plugin, while increasing the visibility of ProR in the Open Source community. The move of ProR from the University of Düsseldorf to the Eclipse Foundation increases visibility even further. The Rodin integration plug-in is maintained as an independent project at github.
+
The enablement expression allows clients to specify the same expression for both triggerPoints and possibleChildren. In the case of actionProvider, clients must define an expression that will indicate to the framework when their <tt>org.eclipse.ui.navigator.CommonActionProvider</tt> should be invoked. Because of contributions to the ''IActionBars'', clients must be invoked whenever an object they are interested in is selected. Therefore, clients should use discretion in deciding when their extension should be enabled.
  
== BMotion Studio ==
+
== Programmatic usage ==
The communication between a developer and a domain expert (or manager) is very important for successful deployment of formal methods. On the one hand it is crucial for the developer to get feedback from the domain expert for further development. On the other hand the domain expert needs to check whether his expectations are met. An animation tool allows to check the presence of desired functionality and to inspect the behaviour of a specification, but requires knowledge about the mathematical notation. To avoid this problem, it is useful to create domain specific visualisations. However, creating the code that defines
 
the mapping between a state and its graphical representation is a rather time consuming task. It can take several weeks to develop a custom visualisation.
 
  
BMotion Studio is a visual editor which enables the developer of a formal model to set-up easily a domain specific visualisation for discussing it with the domain expert. BMotion Studio comes with a graphical editor that allows to create a visualisation within the modeling environment. Also, it does not require to use a different notation for gluing the state and its visualisation.
+
In the java side, create 4 packages:
  
== Mode/FT Views ==
+
* *.*.editors.image: Where you have the class that handles the images to be used to display the elements in the project explorer (see for example: <tt>/org.eventb.ui/src/org/eventb/ui/IEventBSharedImages.java</tt>)
There are two major motivations for creating the Mode/FT Views plug-in:
 
* An overview of the requirements documents within Deploy indicated that systems are often described in terms of operational modes and configurations. This led to a work on formal definition of modal systems.
 
* Fault-tolerance is the crucial part of the behaviour of dependable critical systems that needs to benefit from formal modelling as functionality does. The requirements documents for the pilot studies in Deploy contain a high number of requirements related to fault handling and fault tolerant behaviour. A significant part of them are also described by using recoveries and degraded modes.
 
The plug-in provides an environment for specifying modal and fault tolerant behaviour which are often interrelated. By having a refinement chain of system-level modal diagrams, the development benefits from additional modelling constraints and improved requirements traceability.
 
  
= Choices / Decisions =
+
* *.*.ui.explorer.contentProvider: contains the classes required in the extension point <tt>org.eclipse.ui.navigator.navigatorContent</tt>.
== Platform maintenance ==
 
* Revisited task priority
 
This year, the process of giving priority to maintenance tasks was revisited according the the refocus mentioned above. The aim was to address all the major scalability issues before the end of DEPLOY. Thus, the requests coming from DEPLOY partners were given high priorities, and they were also prioritized against the already planned tasks coming from both DEPLOY partners and the Description of Work.  
 
* Keep 32-bit versions of the Rodin platform on linux and windows systems
 
It was asked by end users to make both 32-bit and 64-bit versions of the Rodin platform available for Linux and Windows platforms. Only a 64-bit version of Rodin is available on Mac platforms as 32-bit Mac (early 2006) platforms are no longer maintained. The request to offer 64-bit was motivated by the possibility to increase for them the available Java heap size for some memory greedy platforms (these before 2.3). However, the drawbacks of assembling and maintaining more platforms (5 platforms instead of 3) and the corrections brought to the database which improved the memory consumption pushed away the limitations of the platform, made this request not relevant for now.
 
  
== Mathematical extensions / Theory Plug-in (Issam Maamria)==
+
* *.*.ui.explorer.actionProvider: contains the classes that handle the actions that can be originated by the added navigatorContent.
The Theory plug-in contributes a theory construct to the Rodin database. Theories were used in the Rule-based Prover (before it was discontinued) as a placeholder for rewrite rules. Given the usability advantages of the theory component, it was decided to use it to define mathematical extensions (new operators and new datatypes). Another advantage of using the theory construct is the possibility of using proof obligations to ensure that the soundness of the formalism is not compromised. Proof obligations are generated to validate any properties of new operators (e.g., associativity). With regards to prover extensions, it was decided that the Theory plug-in inherits the capabilities to define and validate rewrite rules from the Rule-based Prover. Furthermore, support for a simple yet powerful subset of inference rules is added, and polymorphic theorems can be defined within the same setting. Proof obligations are, again, used as a filter against potentially unsound proof rules.
 
  
== Plug-in Incompatibilities ==
+
* *.*.ui.explorer.model: The content of the explorer is structured in classes called ''Models''. They all implement the interface <tt>fr.systerel.internal.explorer.model.IModelElement</tt>. The elements are structured in projects (''ModelProjects'') where the root file contains elements that can have proof obligations associated (in that case they should extends the abstract class <tt>fr.systerel.internal.explorer.model.ModelPOContainer</tt>). The elements of a root file are ''ModelElementNode'' similar to <tt>fr.systerel.internal.explorer.model.ModelElementNode</tt>. The models structure would look like this:
It has been decided in cooperation with all the WP9 partners to find better ways to address the plug-in incompatibility issues. First of all, the various partners refined the concept of "plug-in incompatibility". Hence, various aspects could be identified and some specific answers were given to each of them. The user could then defined more clearly the incompatibility faced. Plug-in incompatibilities can be separated in two categories:
 
:* Rodin platform/plug-in incompatibilities, due to some wrong match between Rodin included packages and the plug-in dependencies (i.e. needed packages). These incompatibilities, when reported, allowed the plug-in developers to contact SYSTEREL in charge of managing the packages shipped with a given version of Rodin. It could also allow traceability of incompatibilities and information to the user through a specific and actualized table on each Rodin release notes page on the Wiki<ref name="incompTableA">http://wiki.event-b.org/index.php/Rodin_Platform_Releases#Current_plug-ins</ref>.
 
:* Plug-in/plug-in incompatibilities, due to some wrong match between needed/installed packages, or API/resources incompatible usage. A table was created on each release notes wiki page, and a procedure was defined<ref name="incompTableB">http://wiki.event-b.org/index.php/Rodin_Platform_Releases#Known_plug-in_incompatibilities</ref> so that identified incompatibilities are listed and corrected by the concerned developers.
 
It appeared that cases of using a model which references some missing plug-ins were formerly often seen as compatibility issues although they were not.<br>
 
After the incompatibilities have been identified, the developing counterparts being concerned assigned special tasks and coordination to solve issues the soonest as possible. Incompatibilities are often due to little glitches or desynchronisation and such direct coordination of counterpart appeared appropriate because quick and effective.
 
  
== Modularisation ==
+
  ModelProject
{{TODO}} ''To be completed by Alexei Illiasov''
+
    - ModelRoot1
== Decomposition ==
+
        - ModelElementNode1
{{TODO}} ''To be completed by Renato Silva''
+
        - ModelElementNode2
== Team-based Development ==
+
        - ...
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''  
+
    - ModelRoot2
== UML-B ==
+
        - ModelElementNode3
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
+
        - ModelElementNode4
== ProR ==
+
        - ...
 +
       
 +
Moreover, a class called ''ModelController'' defined as a singleton controls all the models and contains useful methods. It also implements the interface <tt>org.rodinp.core.IElementChangedListener</tt> that will be called whenever there is a change in one of the model elements. It will clean up the existing elements in the project explorer and reload with the recent changes through a class called ''DeltaProcessor'': processes an IRodinElementDelta for the ''ModelController''. It decides what needs to be refreshed in the model and the viewer and what needs to be removed from the model (see as an example the class <tt>fr.systerel.internal.explorer.model.DeltaProcessor</tt>). The ''ModelController'' instance should be called by implementing the method <tt>org.eclipse.jface.viewers.IContentProvider#inputChanged</tt> (required for classes that implement interface <tt>org.eclipse.jface.viewers.ITreeContentProvider</tt>). Usually an abstract class that implements ITreeContentProvider is created: ''AbstractContentProvider''.
  
The following key decisions were made when developing ProR:
+
public abstract class AbstractContentProvider implements ITreeContentProvider {
 +
        protected static Object[] NO_OBJECT = new Object[0];
 +
        protected IInternalElementType<?> type;
 +
        public AbstractContentProvider(IInternalElementType<?> type){this.type = type;}
 +
        public Object[] getChildren(Object parentElement) {
 +
                IModelElement model = ModelControllerDecomposition.getModelElement(parentElement);
 +
                if (model != null) {
 +
                      return model.getChildren(type, false);
 +
                }
 +
                return NO_OBJECT;
 +
        }
 +
        public Object getParent(Object element) {
 +
                IModelElement model = ModelControllerDecomposition.getModelElement(element);
 +
                if (model != null) {
 +
                        return model.getParent(true);
 +
                }
 +
                return null;
 +
      }
 +
      public boolean hasChildren(Object element) {
 +
              return getChildren(element).length>0;
 +
      }
 +
      public Object[] getElements(Object inputElement) {
 +
            return getChildren(inputElement);
 +
      }
 +
      public void dispose() {}
 +
      public void inputChanged(Viewer viewer, Object oldInput, Object newInput) {
 +
              if (viewer instanceof CommonViewer) {
 +
                    ModelControllerDecomposition.createInstance((CommonViewer)viewer);
 +
              }
 +
      }
 +
}
  
* '''New development, rather than continuing the original plug-in''' - the architecture of ProR differs significantly from that of the original plug-in (see [[D45_General_Platform_Maintenance#ProR]].  In addition, new technologies like EMF promised a cleaner, more powerful framework for an implementation.
+
This class is extended by the respective ''contentProviders''. For instance:
  
* '''ReqIF as the underlying data model''' - the ReqIF standard <ref name="reqif">http://www.omg.org/spec/ReqIF/</ref> is gaining traction and promises interoperability with industry tools.  In addition, a digital version of the data model was available for free and could serve as the foundation for the model code.
+
public class DecompositionContentProvider extends AbstractContentProvider{...}
  
* '''The Eclipse Modeling Framework''' (EMF) was identified as a technology that would allow a quick and clean foundation for an implementation.  Further, the Rodin EMF-plug-in represents a convenient interface for integrating ProR and ProB.  Last, the digital data model from the OMG could be imported directly into EMF and used for generating the model code.
+
== Example ==
  
* '''Keeping ProR independent from Rodin''' - There is significant interest in ReqIF right now, but this interest is unrelated to formal methods.  By providing an implementation that is independent from Rodin, we have a much larger target group of potential users and developers.  By carefully designing extension points, we can still provide a powerful Rodin integration.
+
An example of the implementation of this extension-point is defined below:
  
* '''Eclipse Foundation Project''' - we were actively establishing an open source community around ProR. By recruiting engaged partners early on, development progressed faster than anticipated. By becoming an Eclipse Foundation project <ref name="rmf">http://eclipse.org/rmf</ref>, we exceeded our goals in this respect.
+
<extension
 +
        point="org.eclipse.ui.navigator.navigatorContent">
 +
      <navigatorContent
 +
            contentProvider="ch.ethz.eventb.decomposition.ui.explorer.contentProvider.DecompositionContentProvider"
 +
            id="ch.ethz.eventb.decomposition.ui.navigator.explorer.decomposition"
 +
            labelProvider="ch.ethz.eventb.decomposition.ui.explorer.contentProvider.DecompositionLabelProvider"
 +
            name="Decomposition Root"
 +
            priority="highest">
 +
        <triggerPoints>
 +
            <or>
 +
              <instanceof
 +
                    value="org.eclipse.core.resources.IProject">
 +
              </instanceof>
 +
              <instanceof
 +
                    value="ch.ethz.eventb.decomposition.core.IDecompositionRoot">
 +
              </instanceof>
 +
            </or></triggerPoints>
 +
        <possibleChildren>
 +
            <instanceof
 +
                  value="ch.ethz.eventb.decomposition.core.IDecompositionRoot">
 +
            </instanceof>
 +
        </possibleChildren>
 +
      </navigatorContent>
 +
      <navigatorContent
 +
            contentProvider="ch.ethz.eventb.decomposition.ui.explorer.contentProvider.ComponentContentProvider"
 +
            id="ch.ethz.eventb.decomposition.ui.navigator.explorer.component"
 +
            labelProvider="ch.ethz.eventb.decomposition.ui.explorer.contentProvider.DecompositionLabelProvider"
 +
            name="Decomposition Component"
 +
            priority="higher">
 +
        <triggerPoints>
 +
            <or>
 +
              <instanceof
 +
                    value="ch.ethz.eventb.decomposition.core.IDecompositionRoot">
 +
              </instanceof>
 +
              <instanceof
 +
                    value="ch.ethz.eventb.decomposition.core.IComponent">
 +
              </instanceof>
 +
            </or>
 +
        </triggerPoints>
 +
        <possibleChildren>
 +
            <instanceof
 +
                  value="ch.ethz.eventb.decomposition.core.IComponent">
 +
            </instanceof>
 +
        </possibleChildren>
 +
</extension>
  
== BMotion Studio ==
+
Above we defined two navigatorContent elements (''DecompositionContentProvider'' and ''ComponentContentProvider'') using the same class as labelProvider (''DecompositionLabelProvider''). The first is triggered by instances of ''IProject'' and ''IDecompositionRoot'' and the possible children of this element are ''IDecompositionRoot'' as well.
The following key decisions were made when developing BMotion Studio:
 
  
* '''Keeping BMotion Studio user-friendly''' - The user should be able to create a visualization not requiring additional skills in programming languages.
+
An actionProvider example is described below:
* '''ProB as animator for providing state information''' - With the ProB animator, we have a powerful tool for interacting with the model.
 
* '''Provide extensibility for specific domains''' - By carefully designing extension points, we can provide a powerful integration for specific domains.
 
* '''Keeping BMotion Studio independent from Rodin''' - By providing an implementation that is independent from Rodin, we have a much larger target group of potential users and developers.
 
  
== Mode/FT Views ==
+
      <actionProvider
The following key decisions were made when developing Mode/FT Views:
+
            class="ch.ethz.eventb.decomposition.ui.explorer.actionProvider.DecompositionRootActionProvider"
* '''The Eclipse Graphical Modelling Framework (GMF)''' was used as a platform for building a user-friendly modelling environment.
+
            id="ch.ethz.eventb.decomposition.ui.DecompositionRootActionProvider">
* '''Proof obligations for the views are injected into the standard PO repository of the models''' - This ensures that all the tools related to theorem proving can be used in the same way as they are used for Event-B proof obligations.
+
        <enablement>
 +
            <or>
 +
              <instanceof
 +
                    value="ch.ethz.eventb.decomposition.core.IDecompositionRoot">
 +
              </instanceof>
 +
              <instanceof
 +
                    value="ch.ethz.eventb.decomposition.core.IDecompositionConfiguration">
 +
              </instanceof>
 +
              <instanceof
 +
                    value="ch.ethz.eventb.decomposition.core.ISubComponent">
 +
              </instanceof>
 +
              <instanceof
 +
                    value="ch.ethz.eventb.decomposition.core.ISubComponentElement">
 +
              </instanceof>
 +
              <instanceof
 +
                    value="ch.ethz.eventb.decomposition.core.IComponent">
 +
              </instanceof>
 +
            </or>
 +
        </enablement>
 +
      </actionProvider>
  
= Available Documentation =
+
This actionProvider, described by the class <tt>ch.ethz.eventb.decomposition.ui.explorer.actionProvider.DecompositionRootActionProvider</tt> is enabled by instances of IDecompositionRoot, IDecompositionConfiguration, ISubComponent, ISubComponentElement and IComponent.
* Core platform:
 
:The following pages give useful information about the Rodin platform releases:
 
:* Release notes<ref>http://wiki.event-b.org/index.php/Rodin_Platform_Releases</ref>.
 
:* Bugs<ref>https://sourceforge.net/tracker/?group_id=108850&atid=651669</ref>.
 
:* Feature requests<ref>https://sourceforge.net/tracker/?group_id=108850&atid=651672</ref>.
 
*The Rodin handbook is proposed as a PDF version and a HTML version and a dedicated plug-in makes it available as help within Rodin<ref name="RodinHandbook">http://handbook.event-b.org/</ref>.
 
  
* Mathematical extensions / Theory Plug-in
+
= Navigator Viewer =
** Pre-studies (states of the art, proposals, discussions).
 
*** [http://deploy-eprints.ecs.soton.ac.uk/216/ ''Proposals for Mathematical Extensions for Event-B'']
 
*** [http://deploy-eprints.ecs.soton.ac.uk/251/ ''Mathematical Extension in Event-B through the Rodin Theory Component'']
 
*** [http://wiki.event-b.org/index.php/Constrained_Dynamic_Parser#Design_Alternatives ''Generic Parser's Design Alternatives'' ]
 
*** [http://wiki.event-b.org/index.php/Structured_Types ''Theoretical Description of Structured Types'']
 
** Technical details (specifications).
 
*** [http://wiki.event-b.org/index.php/Mathematical_Extensions ''Mathematical_Extensions wiki page'']
 
*** [http://wiki.event-b.org/index.php/Constrained_Dynamic_Lexer ''Constrained Dynamic Lexer wiki page'']
 
*** [http://wiki.event-b.org/index.php/Constrained_Dynamic_Parser ''Constrained Dynamic Parser wiki page'']
 
*** [http://wiki.event-b.org/index.php/Theory_Plug-in ''Theory plug-in wiki page]
 
*** [http://wiki.event-b.org/index.php/Records_Extension ''Records Extension Documentation on wiki'']
 
** User's guides.
 
*** [http://wiki.event-b.org/images/Theory_UM.pdf ''Theory Plug-in User Manual'']
 
  
*{{TODO}}  Links for Modularisation
+
The viewer element defines the configuration for a common viewer. We define two children of this extension point:
*{{TODO}}  Links for Decomposition
 
*{{TODO}}  Links for Team-based Development
 
*{{TODO}}  Links for UML-B
 
* Links for ProR
 
** ProR at the Eclipse Foundation <ref name="rmf">http://eclipse.org/rmf</ref>
 
** ProR Documentation for end users and plugin developers <ref>http://pror.org</ref>
 
* Links for BMotion Studio
 
** BMotion Studio Documentation for end users and plugin developers <ref>http://www.stups.uni-duesseldorf.de/BMotionStudio</ref>
 
** Context sensitive help is in work.
 
  
* Links for Mode/FT Views
+
* ''viewerContentBinding'': to define the visibility of ''contentProviders''.
** Mode/FT Views documentation for users <ref name="modeft">http://wiki.event-b.org/index.php/Mode/FT_Views</ref>
+
* ''viewerActionBinding'': to define the visibility of ''actionProviders''.
** Papers.
 
*** [http://deploy-eprints.ecs.soton.ac.uk/105/ ''Structuring Specifications with Modes'']
 
*** [http://deploy-eprints.ecs.soton.ac.uk/153/ ''Modal Systems: Specification, Refinement and Realisation'']
 
*** [http://deploy-eprints.ecs.soton.ac.uk/253/ ''On Fault Tolerance Reuse during Refinement'']
 
  
= Status =
+
== Declaration ==
== Platform maintenance ==
 
By the end of the project, there are :
 
* xx bugs reported and open. All with a priority lower or equal to 5.
 
* xx feature requests expressed and still open.
 
  
== Mathematical extensions / Theory Plug-in (Issam Maamria) ==
+
<!ELEMENT viewerContentBinding (includes? , excludes?)>
Work on the Theory plug-in includes:
+
  <!ATTLIST viewerContentBinding
* Bug fixes.
+
  viewerId CDATA #REQUIRED
* Usability improvements.
+
  >
* Exploring other potential ways of defining operators and types (e.g., axiomatic definitions).
 
  
== Plug-in Incompatibilities ==
+
Clients must define one or more viewerContentBinding elements to describe which content extensions, common filters, and link helpers are visible to the viewer. A content extension or common filter is visible if the id of the content extension or common filter matches an includes statement under a viewerContentBinding and is not excluded by an excludes statement. If a content extension or common filter is not visible to a viewer, then the extension will never be asked for content by a content service for that viewer or be presented to the user in the available filters dialog. Clients may define an includes element to select which extensions are visible to the viewer, and similarly an excludes element for extensions that should not be made visible to the viewer. Clients may further define the extensions that should be explicitly queried for root elements (through ITreeContentProvider.getElements()) by the "isRoot" attribute. If one or more contentExtension elements have "isRoot" set to true within the includes statement, only those extensions will be queried for root elements. The "isRoot" attribute has no effect for exclusions. A viewer may have multiple viewerContentBindings defined, and their includes/excludes statements will be aggregated to produce the final behavior.
As the time of writing this deliverable, no plug-in incompatibilities are left or known to exist between the platform and plug-ins or between plug-ins.
 
  
== Modularisation ==
+
* viewerId - The id of the common viewer. If the viewer is in a common navigator then the id must match the navigator's id defined in its org.eclipse.ui.views extension.
{{TODO}} ''To be completed by Alexei Illiasov''
 
== Decomposition ==
 
{{TODO}} ''To be completed by Renato Silva'' 
 
== Team-based Development ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
 
== UML-B ==
 
{{TODO}} ''To be completed by Colin Snook, Vitaly Savicks''
 
== ProR ==
 
  
ProR took on a life on its own as part of the Requirements Modeling Framework<ref name="rmf">http://eclipse.org/rmf</ref>.  It is currently in the incubation stage of an Eclipse project.  There are currently five committers in total, with two from the Rodin project, namely Michael Jastram (Project Lead) and Lukas Ladenberger.
+
<!ELEMENT viewerActionBinding (includes? , excludes?)>
 +
  <!ATTLIST viewerActionBinding
 +
  viewerId CDATA #REQUIRED
 +
  >
  
The Rodin integration supports:
+
Clients must define which action providers are visible to their viewer. Clients may define an includes element to select which extensions are visible to the viewer, and similarly an excludes element for extensions that should not be made visible to the viewer. A viewer may have multiple viewerActionBindings defined, and their includes/excludes statements will be aggregated to produce the final behavior.
  
* Creating traces between model elements and requirements
+
== Example ==
* Highlighting of model elements in the requirements text
 
* Marking of invalidated traces, where either the requirement or model element had changed.
 
  
The Rodin integration is hosted at GitHub.
+
An example of the use of this extension point is defined below:
  
== BMotion Studio ==
+
<extension
The tool is available as a part of the ProB animator and is ready for use for visualizing Event-B models within the Rodin tool. Of course, we are working on new features.
+
        point="org.eclipse.ui.navigator.viewer">
 +
      <viewerContentBinding
 +
            viewerId="fr.systerel.explorer.navigator.view">
 +
        <includes>
 +
            <contentExtension
 +
                  pattern="ch.ethz.eventb.decomposition.ui.navigator.explorer.decomposition">
 +
            </contentExtension>
 +
            <contentExtension
 +
                  pattern="ch.ethz.eventb.decomposition.ui.navigator.explorer.component">
 +
          </contentExtension>
 +
            <contentExtension
 +
                  pattern="ch.ethz.eventb.decomposition.ui.navigator.explorer.configuration">
 +
            </contentExtension>
 +
            <contentExtension
 +
                  pattern="ch.ethz.eventb.decomposition.ui.navigator.explorer.subComponent">
 +
            </contentExtension>
 +
            <contentExtension
 +
                  pattern="ch.ethz.eventb.decomposition.ui.navigator.explorer.subComponentElement">
 +
            </contentExtension>
 +
        </includes>
 +
      </viewerContentBinding>
 +
      <viewerActionBinding
 +
            viewerId="fr.systerel.explorer.navigator.view">
 +
        <includes>
 +
            <actionExtension
 +
                  pattern="ch.ethz.eventb.decomposition.ui.DecompositionRootActionProvider">
 +
            </actionExtension>
 +
        </includes>
 +
      </viewerActionBinding>
 +
  </extension>
  
== Mode/FT Views ==
+
The contentExtension patterns correspond to the ids in the contentProvider and actionProvider extension-points defined above (see the navigatorContent example section).
The Mode/FT Views is a plug-in for the Rodin platform. The tool is available from its update site <ref name="modeft">http://wiki.event-b.org/index.php/Mode/FT_Views</ref>
 
  
= References =
+
[[Category:Developer documentation]]
<references/>
+
[[Category:Rodin Platform]]
 
 
[[Category:D45 Deliverable]]
 

Revision as of 16:28, 24 May 2010

Introduction

The purpose of this page is to describe how to extend the Event-B project explorer. It covers on the one hand, the definition of the extension, and on the other hand its implementation. The Event-B project explorer is itself an implementation of the extension-point org.eclipse.ui.views. The corresponding view id is fr.systerel.explorer.navigator.view which is defined as a subclass of org.eclipse.ui.navigator.CommonNavigator and it is over this view that we extend the project explorer.

EventB project explorer.png

The useful extension points are listed below; they offer the possibility to contribute to the project explorer:

  • org.eclipse.ui.navigator.navigatorContent
  • org.eclipse.ui.navigator.viewer

Before Starting

It is necessary to define the elements and structure to be represented. We will use as an example the decompositionFile that is defined as follows:

  • decompositionFile
    • decompositionRoot
      • Component with the following attributes: machine (to be decomposed)
      • Configuration with the following attributes: style: shared event/shared variables; newProjectOption: decompose in the same project/different projects; decomposeContextOption: noDecomposition/minimal decomposition)
      • SubComponent (resulting decomposed parts) with the following attributes: label
        • SubComponentElement (elements used to decompose:variables for shared event and events for shared variable) with the following attributes: element name/identifier

Decomp file pretty print.png

Navigator Content

A content extension provides a content and label provider that can be used by a navigator content service (in out case the Event-B project explorer). The navigatorContent extension defines the specific classes for the content provider, label provider, and action provider in addition to the types of elements the extension knows about. To extend the project explorer, it is also required to add the following children of the navigatorContent:

  • triggerPoints: defines the nodes to be used when resolving the Common Navigator content provider's getElements() or getChildren(). This is also used to select the extension for providing labels, images, descriptions and for sorting.
  • possibleChildren: defines the node to be used when resolving the Common Navigator content provider's getParent(). It is also used to help determine the parent when handling drop operations.

Declaration

The navigatorContent extension-point allows tool writers to register their tool implementation under a symbolic name that is then used by the Rodin platform to find and run the tool. The symbolic name is the id of the tool extension. The declaration of this extension is defined as follows:

<!ELEMENT navigatorContent ((enablement | (triggerPoints , possibleChildren)) , actionProvider* , commonSorter* , override? , dropAssistant* , commonWizard*)>
 <!ATTLIST navigatorContent
 id                CDATA #REQUIRED
 name              CDATA #REQUIRED
 priority          (lowest|lower|low|normal|high|higher|highest)
 contentProvider   CDATA #IMPLIED
 icon              CDATA #IMPLIED
 activeByDefault   (true | false)
 providesSaveables (true | false)
 labelProvider     CDATA #IMPLIED
>

A navigator content extension defines a content provider and label provider that can be used to provide children whenever an element matches the triggerPoints expression and also to provide a parent whenever an element matches the possibleChildren expression. Optionally, we may also provide an action provider which can provide menu contributions and action bar contributions when an element is selected that the extension contributed, or that matches the triggerPoints expression. It is possible to contribute with a sorter to sort elements that are contributed by the extension.

  • id - A unique ID to identify this extension. Used for extension activation and by other extensions that would like to extend the defined extension (e.g. add another org.eclipse.ui.navigator.CommonActionProvider)
  • name - Specify a display name for the Content Extension. The display name is used in the activation dialog to allow clients to turn an extension on or off.
  • priority - Indicates the relative priority of this extension to other extensions. Used by the Common Navigator to handle sorting and organization of the contributed content from this extension in relation to content from other extensions. Defaults to "normal"
  • contentProvider - Supplies the name of a class which implements org.eclipse.jface.viewers.ITreeContentProvider or org.eclipse.ui.navigator.ICommonContentProvider. The content provider will be consulted when adding children to the tree. Use the enablement, triggerPoints, or possibleChildren clauses to indicate what kinds of content should trigger a request to your content provider. Elements contributed from the content provider are not guaranteed to appear in the tree in the same order. Clients should take advantage of the sorting extension (commonSorter) to ensure proper ordering of their elements. All elements contributed by this content provider are associated with this navigatorContent extension for the purposes of determining the label provider, action providers, sorters, drop assistants and common wizards.
  • icon - A plugin-relative path to an icon for use when displaying the metadata about the content extension to the user.
  • activeByDefault - Indicates whether the current extension will be active by default. Each content extension may be turned on or off by the user. The active state is differentiated from the visible state. See org.eclipse.ui.navigator.viewer/viewerContentBinding for more information on visibility
  • labelProvider - Supplies the name of a class which implements org.eclipse.jface.viewers.ILabelProvider or for more advanced functionality, the org.eclipse.ui.navigator.ICommonLabelProvider. Clients may also implement org.eclipse.ui.navigator.IDescriptionProvider in order to add text to the status bar at the bottom of the Eclipse workbench based on the selection in the viewer. Since Eclipse 3.4, clients may also implement org.eclipse.jface.viewers.DelegatingStyledCellLabelProvider.IStyledLabelProvider to provide styled text labels. Note that the empty styled string signals that the label provider does not wish to render the label.

Action Provider

Still inside the navigatorContent, it is possible to add the following:

<!ELEMENT actionProvider (enablement?)>
 <!ATTLIST actionProvider
 class         CDATA #REQUIRED
 id            CDATA #IMPLIED
 dependsOn     CDATA #IMPLIED
 overrides     CDATA #IMPLIED
 priority      (lowest|lower|low|normal|high|higher|highest)
 appearsBefore IDREF #IMPLIED
 >

A top level actionProvider is visible to an abstract viewer if there is a viewerActionBinding for that actionProvider. It is possible to provide actionProvider(s) under the root extension element (peer to other navigatorContent) in order to better control their enablement and viewer binding (see viewerActionBinding). Any items contributed to the toolbar or the view menu should be removed when the actionProviders is disposed. We described the two most used attributes of this element:

  • class - Supplies the name of a class that implements org.eclipse.ui.navigator.CommonActionProvider. The action provider has an opportunity to contribute to the context menu and the retargetable actions defined in the IActionBars for the view that holds the navigator. It is also possible to contribute directly to the view menu through the IActionBars view menu.
  • id - Clients may optionally define an id to use for filtering purposes (either through activities or viewerContentBindings).

To define when to enable this actionProvider, it is necessary to define the enablement:

<!ELEMENT enablement (not , and , or , instanceof , test , systemTest , equals , count , with , resolve , adapt , iterate , reference)*>

The enablement expression allows clients to specify the same expression for both triggerPoints and possibleChildren. In the case of actionProvider, clients must define an expression that will indicate to the framework when their org.eclipse.ui.navigator.CommonActionProvider should be invoked. Because of contributions to the IActionBars, clients must be invoked whenever an object they are interested in is selected. Therefore, clients should use discretion in deciding when their extension should be enabled.

Programmatic usage

In the java side, create 4 packages:

  • *.*.editors.image: Where you have the class that handles the images to be used to display the elements in the project explorer (see for example: /org.eventb.ui/src/org/eventb/ui/IEventBSharedImages.java)
  • *.*.ui.explorer.contentProvider: contains the classes required in the extension point org.eclipse.ui.navigator.navigatorContent.
  • *.*.ui.explorer.actionProvider: contains the classes that handle the actions that can be originated by the added navigatorContent.
  • *.*.ui.explorer.model: The content of the explorer is structured in classes called Models. They all implement the interface fr.systerel.internal.explorer.model.IModelElement. The elements are structured in projects (ModelProjects) where the root file contains elements that can have proof obligations associated (in that case they should extends the abstract class fr.systerel.internal.explorer.model.ModelPOContainer). The elements of a root file are ModelElementNode similar to fr.systerel.internal.explorer.model.ModelElementNode. The models structure would look like this:
 ModelProject
   - ModelRoot1
       - ModelElementNode1
       - ModelElementNode2
       - ...
   - ModelRoot2
        - ModelElementNode3
        - ModelElementNode4
        - ...
        

Moreover, a class called ModelController defined as a singleton controls all the models and contains useful methods. It also implements the interface org.rodinp.core.IElementChangedListener that will be called whenever there is a change in one of the model elements. It will clean up the existing elements in the project explorer and reload with the recent changes through a class called DeltaProcessor: processes an IRodinElementDelta for the ModelController. It decides what needs to be refreshed in the model and the viewer and what needs to be removed from the model (see as an example the class fr.systerel.internal.explorer.model.DeltaProcessor). The ModelController instance should be called by implementing the method org.eclipse.jface.viewers.IContentProvider#inputChanged (required for classes that implement interface org.eclipse.jface.viewers.ITreeContentProvider). Usually an abstract class that implements ITreeContentProvider is created: AbstractContentProvider.

public abstract class AbstractContentProvider implements ITreeContentProvider {	
       protected static Object[] NO_OBJECT = new Object[0];
       protected IInternalElementType<?> type;
       public AbstractContentProvider(IInternalElementType<?> type){this.type = type;}
       public Object[] getChildren(Object parentElement) {
               IModelElement model = ModelControllerDecomposition.getModelElement(parentElement);
               if (model != null) {
                     return model.getChildren(type, false);
               }
               return NO_OBJECT;
       }
       public Object getParent(Object element) {
               IModelElement model = ModelControllerDecomposition.getModelElement(element);
               if (model != null) {
                       return model.getParent(true);
               }
               return null;
      }
      public boolean hasChildren(Object element) {
             return getChildren(element).length>0;
      }
      public Object[] getElements(Object inputElement) {
           return getChildren(inputElement);
      }
      public void dispose() {}
      public void inputChanged(Viewer viewer, Object oldInput, Object newInput) {
             if (viewer instanceof CommonViewer) {
                   ModelControllerDecomposition.createInstance((CommonViewer)viewer);
             }
      }
}

This class is extended by the respective contentProviders. For instance:

public class DecompositionContentProvider extends AbstractContentProvider{...}

Example

An example of the implementation of this extension-point is defined below:

<extension
        point="org.eclipse.ui.navigator.navigatorContent">
     <navigatorContent
           contentProvider="ch.ethz.eventb.decomposition.ui.explorer.contentProvider.DecompositionContentProvider"
           id="ch.ethz.eventb.decomposition.ui.navigator.explorer.decomposition"
           labelProvider="ch.ethz.eventb.decomposition.ui.explorer.contentProvider.DecompositionLabelProvider"
           name="Decomposition Root"
           priority="highest">
        <triggerPoints>
           <or>
              <instanceof
                    value="org.eclipse.core.resources.IProject">
              </instanceof>
              <instanceof
                    value="ch.ethz.eventb.decomposition.core.IDecompositionRoot">
              </instanceof>
           </or></triggerPoints>
        <possibleChildren>
           <instanceof
                 value="ch.ethz.eventb.decomposition.core.IDecompositionRoot">
           </instanceof>
        </possibleChildren>
     </navigatorContent>
     <navigatorContent
           contentProvider="ch.ethz.eventb.decomposition.ui.explorer.contentProvider.ComponentContentProvider"
           id="ch.ethz.eventb.decomposition.ui.navigator.explorer.component"
           labelProvider="ch.ethz.eventb.decomposition.ui.explorer.contentProvider.DecompositionLabelProvider"
           name="Decomposition Component"
           priority="higher">
        <triggerPoints>
           <or>
              <instanceof
                    value="ch.ethz.eventb.decomposition.core.IDecompositionRoot">
              </instanceof>
              <instanceof
                    value="ch.ethz.eventb.decomposition.core.IComponent">
              </instanceof>
           </or>
        </triggerPoints>
        <possibleChildren>
           <instanceof
                 value="ch.ethz.eventb.decomposition.core.IComponent">
           </instanceof>
        </possibleChildren>
</extension>

Above we defined two navigatorContent elements (DecompositionContentProvider and ComponentContentProvider) using the same class as labelProvider (DecompositionLabelProvider). The first is triggered by instances of IProject and IDecompositionRoot and the possible children of this element are IDecompositionRoot as well.

An actionProvider example is described below:

     <actionProvider
           class="ch.ethz.eventb.decomposition.ui.explorer.actionProvider.DecompositionRootActionProvider"
           id="ch.ethz.eventb.decomposition.ui.DecompositionRootActionProvider">
        <enablement>
           <or>
              <instanceof
                    value="ch.ethz.eventb.decomposition.core.IDecompositionRoot">
              </instanceof>
              <instanceof
                    value="ch.ethz.eventb.decomposition.core.IDecompositionConfiguration">
              </instanceof>
              <instanceof
                    value="ch.ethz.eventb.decomposition.core.ISubComponent">
              </instanceof>
              <instanceof
                    value="ch.ethz.eventb.decomposition.core.ISubComponentElement">
              </instanceof>
              <instanceof
                    value="ch.ethz.eventb.decomposition.core.IComponent">
              </instanceof>
           </or>
        </enablement>
     </actionProvider>

This actionProvider, described by the class ch.ethz.eventb.decomposition.ui.explorer.actionProvider.DecompositionRootActionProvider is enabled by instances of IDecompositionRoot, IDecompositionConfiguration, ISubComponent, ISubComponentElement and IComponent.

Navigator Viewer

The viewer element defines the configuration for a common viewer. We define two children of this extension point:

  • viewerContentBinding: to define the visibility of contentProviders.
  • viewerActionBinding: to define the visibility of actionProviders.

Declaration

<!ELEMENT viewerContentBinding (includes? , excludes?)>
 <!ATTLIST viewerContentBinding
 viewerId CDATA #REQUIRED
 >

Clients must define one or more viewerContentBinding elements to describe which content extensions, common filters, and link helpers are visible to the viewer. A content extension or common filter is visible if the id of the content extension or common filter matches an includes statement under a viewerContentBinding and is not excluded by an excludes statement. If a content extension or common filter is not visible to a viewer, then the extension will never be asked for content by a content service for that viewer or be presented to the user in the available filters dialog. Clients may define an includes element to select which extensions are visible to the viewer, and similarly an excludes element for extensions that should not be made visible to the viewer. Clients may further define the extensions that should be explicitly queried for root elements (through ITreeContentProvider.getElements()) by the "isRoot" attribute. If one or more contentExtension elements have "isRoot" set to true within the includes statement, only those extensions will be queried for root elements. The "isRoot" attribute has no effect for exclusions. A viewer may have multiple viewerContentBindings defined, and their includes/excludes statements will be aggregated to produce the final behavior.

  • viewerId - The id of the common viewer. If the viewer is in a common navigator then the id must match the navigator's id defined in its org.eclipse.ui.views extension.
<!ELEMENT viewerActionBinding (includes? , excludes?)>
 <!ATTLIST viewerActionBinding
 viewerId CDATA #REQUIRED
 >

Clients must define which action providers are visible to their viewer. Clients may define an includes element to select which extensions are visible to the viewer, and similarly an excludes element for extensions that should not be made visible to the viewer. A viewer may have multiple viewerActionBindings defined, and their includes/excludes statements will be aggregated to produce the final behavior.

Example

An example of the use of this extension point is defined below:

<extension 
        point="org.eclipse.ui.navigator.viewer">
     <viewerContentBinding 
           viewerId="fr.systerel.explorer.navigator.view">
        <includes>
           <contentExtension 
                 pattern="ch.ethz.eventb.decomposition.ui.navigator.explorer.decomposition">
           </contentExtension>
           <contentExtension 
                 pattern="ch.ethz.eventb.decomposition.ui.navigator.explorer.component">
         	 </contentExtension>
           <contentExtension 
                 pattern="ch.ethz.eventb.decomposition.ui.navigator.explorer.configuration">
           </contentExtension>
           <contentExtension 
                 pattern="ch.ethz.eventb.decomposition.ui.navigator.explorer.subComponent">
           </contentExtension>
           <contentExtension
                 pattern="ch.ethz.eventb.decomposition.ui.navigator.explorer.subComponentElement">
           </contentExtension>
        </includes>
     </viewerContentBinding>
     <viewerActionBinding
           viewerId="fr.systerel.explorer.navigator.view">
        <includes>
           <actionExtension
                 pattern="ch.ethz.eventb.decomposition.ui.DecompositionRootActionProvider">
           </actionExtension>
        </includes>
     </viewerActionBinding>
  </extension> 

The contentExtension patterns correspond to the ids in the contentProvider and actionProvider extension-points defined above (see the navigatorContent example section).