D23 TEXT - Revision history

imported>Pascal: /* For PDF rendering */

2010-01-28T15:56:07Z

For PDF rendering

← Older revision		Revision as of 15:56, 28 January 2010
Line 33:		Line 33:
	= Available Documentation =		= Available Documentation =

	=== Online Documentation ===		== Online Documentation ==

	* [http://wiki.event-b.org/index.php/Text_Editor Text Editor Wiki Page]		* [http://wiki.event-b.org/index.php/Text_Editor Text Editor Wiki Page]
Line 39:		Line 39:
	* [http://wiki.event-b.org/index.php/TextEditor_EBNF EBNF Syntax for the Textual Representation]		* [http://wiki.event-b.org/index.php/TextEditor_EBNF EBNF Syntax for the Textual Representation]

	=== Papers ===		== Papers ==

	* [http://www.stups.uni-duesseldorf.de/thesis_detail.php?id=20 A Semantics-Aware Text Editor for Event-B. Fabian Fritz. Master's Thesis. 2009]		* [http://www.stups.uni-duesseldorf.de/thesis_detail.php?id=20 A Semantics-Aware Text Editor for Event-B. Fabian Fritz. Master's Thesis. 2009]

imported>Pascal: /* Papers */

2010-01-26T15:57:14Z

Papers

← Older revision		Revision as of 15:57, 26 January 2010
Line 42:		Line 42:

	* [http://www.stups.uni-duesseldorf.de/thesis_detail.php?id=20 A Semantics-Aware Text Editor for Event-B. Fabian Fritz. Master's Thesis. 2009]		* [http://www.stups.uni-duesseldorf.de/thesis_detail.php?id=20 A Semantics-Aware Text Editor for Event-B. Fabian Fritz. Master's Thesis. 2009]
	* Developing Camille, a Text Editor for Rodin. Jens Bendisposto, Fabian Fritz and Michael Leuschel. 2009. (~~submitted~~)		* Developing Camille, a Text Editor for Rodin. Jens Bendisposto, Fabian Fritz and Michael Leuschel. 2009. (to appear in WS-TBFM 2010)

	= Planning =		= Planning =

imported>Laurent: /* Motivations */

2010-01-06T15:07:37Z

Motivations

← Older revision		Revision as of 15:07, 6 January 2010
Line 8:		Line 8:
	Indeed, events, theorems, axioms, etc. are stored in the Rodin database, and there is no classical text file to edit the models.		Indeed, events, theorems, axioms, etc. are stored in the Rodin database, and there is no classical text file to edit the models.
	The models are directly manipulated by a structural form-based editor.		The models are directly manipulated by a structural form-based editor.
	During the lifetime of the Rodin and DEPLOY projects it became increasingly apparent that the current structural editor was not able to cope with industrial needs. Functions that are taken for granted in an editor - copy & paste~~, undo~~ or printing, just to name a few - were missing or only partially functional.		During the lifetime of the Rodin and DEPLOY projects it became increasingly apparent that the current structural editor was not able to cope with some industrial needs. Functions that are taken for granted in an editor - unstructured copy & paste or printing, just to name a few - were missing or only partially functional.

	As an Event-B model consists of text, users were requesting a text editor, which would allow them to apply their already present editing skills. As text editing is a well-understood problem, a variety of frameworks were available to implement one. These frameworks typically provide a wide range of standard features "for free", and typically provide extension points for extendability with additional features. The development team selected the Eclipse Modeling Framework (EMF), for the reasons outlined below.		As an Event-B model consists of text, users were requesting a text editor, which would allow them to apply their already present text editing skills. As text editing is a well-understood problem, a variety of frameworks were available to implement one. These frameworks typically provide a wide range of standard features "for free", and typically provide extension points for extendability with additional features. The development team selected the Eclipse Modeling Framework (EMF), for the reasons outlined below.

	The wide adoption of the text editor confirms that good decisions have been made. Besides standard text editing features as cut & paste, unlimited undo and redo, line numbering and many more, many Rodin-specific features had been implemented. The text editor supports syntax and semantic highlighting, code completion, templates, an outline view, quick navigation and many more.		The wide adoption of the text editor confirms that good decisions have been made. Besides standard text editing features as cut & paste, unlimited undo and redo, line numbering and many more, many Rodin-specific features had been implemented. The text editor supports syntax and semantic highlighting, code completion, templates, an outline view, quick navigation and many more.

imported>Pascal: /* Planning */

2009-12-07T18:07:20Z

Planning

← Older revision		Revision as of 18:07, 7 December 2009
Line 48:		Line 48:

	Users have expressed the desire to be able to insert comments everywhere. It is unclear whether this can be achieved without a major refactoring of the Rodin Database.		Users have expressed the desire to be able to insert comments everywhere. It is unclear whether this can be achieved without a major refactoring of the Rodin Database.

			[[Category:D23 Deliverable]]

imported>Pascal: /* Typo */

2009-12-04T10:50:58Z

Typo

← Older revision		Revision as of 10:50, 4 December 2009
Line 8:		Line 8:
	Indeed, events, theorems, axioms, etc. are stored in the Rodin database, and there is no classical text file to edit the models.		Indeed, events, theorems, axioms, etc. are stored in the Rodin database, and there is no classical text file to edit the models.
	The models are directly manipulated by a structural form-based editor.		The models are directly manipulated by a structural form-based editor.
	During the lifetime of the Rodin and ~~Deploy~~ projects it became increasingly apparent that the current structural editor was not able to cope with industrial needs. Functions that are taken for granted in an editor - copy & paste, undo or printing, just to name a few - were missing or only partially functional.		During the lifetime of the Rodin and DEPLOY projects it became increasingly apparent that the current structural editor was not able to cope with industrial needs. Functions that are taken for granted in an editor - copy & paste, undo or printing, just to name a few - were missing or only partially functional.

	As an Event-B model consists of text, users were requesting a text editor, which would allow them to apply their already present editing skills. As text editing is a well-understood problem, a variety of frameworks were available to implement one. These frameworks typically provide a wide range of standard features "for free", and typically provide extension points for extendability with additional features. The development team selected the Eclipse Modeling Framework (EMF), for the reasons outlined below.		As an Event-B model consists of text, users were requesting a text editor, which would allow them to apply their already present editing skills. As text editing is a well-understood problem, a variety of frameworks were available to implement one. These frameworks typically provide a wide range of standard features "for free", and typically provide extension points for extendability with additional features. The development team selected the Eclipse Modeling Framework (EMF), for the reasons outlined below.

imported>Pascal: /* Online Documentation */

2009-12-04T10:48:22Z

Online Documentation

← Older revision		Revision as of 10:48, 4 December 2009
Line 35:		Line 35:
	=== Online Documentation ===		=== Online Documentation ===

	[http://wiki.event-b.org/index.php/Text_Editor Text Editor Wiki Page]		* [http://wiki.event-b.org/index.php/Text_Editor Text Editor Wiki Page]

	[http://wiki.event-b.org/index.php/TextEditor_EBNF EBNF Syntax for the Textual Representation]		* [http://wiki.event-b.org/index.php/TextEditor_EBNF EBNF Syntax for the Textual Representation]

	=== Papers ===		=== Papers ===

imported>Pascal: /* Typos */

2009-12-04T10:48:00Z

Typos

imported>Jens: /* Overview */

2009-11-27T10:32:47Z

Overview

← Older revision		Revision as of 10:32, 27 November 2009
Line 1:		Line 1:
	= Overview =		= Overview =
	This part of the deliverable describes ~~improvement of~~ the ~~ProB animation and model checking plugin~~.		This part of the deliverable describes the Camille text editor plug-in.

	= Motivations =		= Motivations =

imported>Leuschel: /* Planning */

2009-11-27T10:02:23Z

Planning

← Older revision		Revision as of 10:02, 27 November 2009
Line 52:		Line 52:
	= Planning =		= Planning =
	This paragraph shall give a timeline and current status (as of 29 Jan 2010).		This paragraph shall give a timeline and current status (as of 29 Jan 2010).

			The Text Editor needs to be extended to support new attributes (e.g., stemming from the upcoming Decomposition plug-in) and the upcoming mathematical extensions.

			Users have expressed the desire to be able to insert comments everywhere. It is unclear whether this can be achieved without a major refactoring of the Rodin Database.

imported>Jens: /* Papers */

2009-11-27T09:58:30Z

Papers

← Older revision		Revision as of 09:58, 27 November 2009
Line 48:		Line 48:

	* [http://www.stups.uni-duesseldorf.de/thesis_detail.php?id=20 A Semantics-Aware Text Editor for Event-B. Fabian Fritz. Master's Thesis. 2009]		* [http://www.stups.uni-duesseldorf.de/thesis_detail.php?id=20 A Semantics-Aware Text Editor for Event-B. Fabian Fritz. Master's Thesis. 2009]
			* Developing Camille, a Text Editor for Rodin. Jens Bendisposto, Fabian Fritz and Michael Leuschel. 2009. (submitted)
	~~WS-TBFM Submission~~

	= Planning =		= Planning =
	This paragraph shall give a timeline and current status (as of 29 Jan 2010).		This paragraph shall give a timeline and current status (as of 29 Jan 2010).

← Older revision		Revision as of 10:48, 4 December 2009
Line 3:		Line 3:

	= Motivations =		= Motivations =
	This paragraph shall express the motivation for each tool extension and improvement. More precisely, it shall first indicate the state before the work, the encountered difficulties, and shall highlight the requirements (eg. those of industrial partners). Then, it shall summarize how these requirements are addressed and what are the main benefits.		A number of frameworks for text editors are available, but EMF ([http://www.eclipse.org/modeling/emf/ Eclipse Modeling Framework Project]) was quickly identified as the target candidate, in combination with TEF (Textual Editing Framework), which is based on EMF. The framework seamlessly integrates into Eclipse. It is already proven within Rodin, as it is the foundation of UML-B. It is extensible - contributors of other plug-ins will be able to extend the text editor as well. And last, a proof-of-concept prototype had been put together very quickly.

	A number of frameworks for text editors are available, but EMF (([http://www.eclipse.org/modeling/emf/ Eclipse Modeling Framework Project]) ) was quickly identified as the target candidate, in combination with TEF (Textual Editing Framework), which is based on EMF. The framework seamlessly integrates into Eclipse. It is already proven within Rodin, as it is the foundation of UML-B. It is extensible - contributors of other plug-ins will be able to extend the text editor as well. And last, a proof-of-concept prototype had been put together very quickly.

	Rodin has done away with a textual representation of the formal models.		Rodin has done away with a textual representation of the formal models.
	Indeed, events, theorems, axioms, etc. are stored in the Rodin database, and there is no classical text file ~~for editing~~ the models.		Indeed, events, theorems, axioms, etc. are stored in the Rodin database, and there is no classical text file to edit the models.
	The models are directly manipulated by a structural form-based editor.		The models are directly manipulated by a structural form-based editor.
	During the lifetime of the Rodin and Deploy projects it became increasingly apparent that the current structural editor was not able to cope with industrial needs. Functions that are taken for granted in an editor - copy & paste, undo or printing, just to name a few - were missing or only partially functional.		During the lifetime of the Rodin and Deploy projects it became increasingly apparent that the current structural editor was not able to cope with industrial needs. Functions that are taken for granted in an editor - copy & paste, undo or printing, just to name a few - were missing or only partially functional.

	As an Event-B model consists of text, users were requesting a text editor, which would allow them to apply their already present editing skills. As text editing is a well-understood problem, a variety of frameworks were available ~~for implementing~~ one. These frameworks typically provide a wide range of standard features "for free", and typically provide extension points for extendability with additional features. The development team selected the Eclipse Modeling Framework (EMF), for the reasons outlined below.		As an Event-B model consists of text, users were requesting a text editor, which would allow them to apply their already present editing skills. As text editing is a well-understood problem, a variety of frameworks were available to implement one. These frameworks typically provide a wide range of standard features "for free", and typically provide extension points for extendability with additional features. The development team selected the Eclipse Modeling Framework (EMF), for the reasons outlined below.

	The wide ~~adaption~~ of the text editor confirms that good decisions have been made. Besides standard text editing features as cut & paste, unlimited undo and redo, line numbering and many more, many Rodin-specific features had been implemented. The text editor supports syntax and semantic highlighting, code completion, templates, an outline view, quick navigation and many more.		The wide adoption of the text editor confirms that good decisions have been made. Besides standard text editing features as cut & paste, unlimited undo and redo, line numbering and many more, many Rodin-specific features had been implemented. The text editor supports syntax and semantic highlighting, code completion, templates, an outline view, quick navigation and many more.

	= Choices / Decisions =		= Choices / Decisions =
	This paragraph shall summarize the decisions (eg. design decisions) and justify them. Thus, it may present the studied solutions, through their main advantages and inconvenients, to legitimate the final choices.


	One important design consideration was to be able to re-use the Rodin formula syntax and parser.		One important design consideration was to be able to re-use the Rodin formula syntax and parser.
	This was deemed vital for keeping up with future evolutions of the platform, e.g., the mathematical extensions will introduce new operators.		This was deemed vital for keeping up with future evolutions of the platform, e.g. the mathematical extensions will introduce new operators.
	As such, the grammar had to be carefully designed to be able to parse the structure of an Event-B model independently of the content of the predicates, expressions and actions.		As such, the grammar had to be carefully designed to be able to parse the structure of an Event-B model independently of the content of the predicates, expressions and actions.
	In other words, the structural parser detects the structure of the model and sends the formula content to the Rodin parser.		In other words, the structural parser detects the structure of the model and sends the formula content to the Rodin parser.

	There is a very important limitation of the editor; while it can cope with changes of the mathematical language, it is not able to automatically deal with changes to the model’s structure. If we need to add information to the structure of a model itself, such as information on decomposition or flows it is necessary to modify the parser’s grammar and recompile it. There is to our best knowledge only one tool for the Eclipse framework that allows modification of the grammar during runtime. In theory, the features of [http://www2.informatik.hu-berlin.de/sam/meta-tools/tef/index.html TEF] perfectly fit our needs and indeed Alexei Iliasov developed in 2008 a prototype based on TEF. However there were a number of things that convinced us to not use it. First of all, the framework is ~~releases~~ under the ~~Gnu~~ Public License which is legally not compatible with the Eclipse Public License used in Rodin. Second, the parser RunCC used in TEF has some issues related to handling parse errors. Because the project did not make progress for three years it is very unlikely that these problems will be fixed by the creators of the parser. Extending RunCC could solve this problem but it does not seem to be feasible without major effort and resources.		There is a very important limitation of the editor; while it can cope with changes of the mathematical language, it is not able to automatically deal with changes to the model’s structure. If we need to add information to the structure of a model itself, such as information on decomposition or flows it is necessary to modify the parser’s grammar and recompile it. There is to our best knowledge only one tool for the Eclipse framework that allows modification of the grammar during runtime. In theory, the features of [http://www2.informatik.hu-berlin.de/sam/meta-tools/tef/index.html TEF] perfectly fit our needs and indeed Alexei Iliasov developed in 2008 a prototype based on TEF. However there were a number of things that convinced us to not use it. First of all, the framework is released under the GNU Public License which is legally not compatible with the Eclipse Public License used in Rodin. Second, the parser RunCC used in TEF has some issues related to handling parse errors. Because the project did not make progress for three years it is very unlikely that these problems will be fixed by the creators of the parser. Extending RunCC could solve this problem but it does not seem to be feasible without major effort and resources.
	The grammar used to generate Camille’s parser is close to EBNF, so we think it is not too difficult for plug-in developers to contribute to the grammar but one has to be careful to not restrict the current language, i.e., we can only add optional syntax elements to the grammar, otherwise we break older models. However, this does not mean, that we cannot have new mandatory elements, it only means that it has to be checked by the underlying model instead of the parser.		The grammar used to generate Camille’s parser is close to EBNF, so we think that it is not too difficult for plug-in developers to contribute to the grammar but one has to be careful to not restrict the current language, i.e. we can only add optional syntax elements to the grammar, otherwise we break older models. However, this does not mean that we cannot have new mandatory elements, it only means that it has to be checked by the underlying model instead of the parser.

	We also considered the [http://www.stups.uni-duesseldorf.de/thesis_detail.php?id=12 BE4 Framework] as well as [http://www.eclipse.org/Xtext/ Eclipse XText]; an early version of Camille was indeed based on BE4 and it still contains some of its basic concepts. The main reason ~~for~~ not ~~using~~ BE4 was that editors for EMF models are less strongly based on files ~~then~~ editors for other languages. The EMF framework has ~~it’s~~ own notification system for changes in models. These change notifications may be caused by file changes. In addition changes to the model coming from other plug-ins may trigger notifications too. This means a text editor needs to react, i.e., run its compiling respectively updating processes according to these changes. Therefore a build process which is based on files as BE4 offers is rather unsuitable.		We also considered the [http://www.stups.uni-duesseldorf.de/thesis_detail.php?id=12 BE4 Framework] as well as [http://www.eclipse.org/Xtext/ Eclipse XText]; an early version of Camille was indeed based on BE4 and it still contains some of its basic concepts. The main reason to not use BE4 was that editors for EMF models are less strongly based on files than editors for other languages. The EMF framework has its own notification system for changes in models. These change notifications may be caused by file changes. In addition, changes to the model coming from other plug-ins may trigger notifications too. This means that a text editor needs to react, i.e. to run its compiling respectively updating processes according to these changes. Therefore a build process which is based on files as BE4 offers is rather unsuitable.
	XText was also considered and is a reasonable alternative to our approach. At the time we started developing Camille, the XText framework was not released and it was not clear if and when certain features are included. Also the API was not stable at that time. In contrast to our solution, ~~Xtext~~ has the advantage that it creates the parser from the EMF model.		XText was also considered and is a reasonable alternative to our approach. At the time we started developing Camille, the XText framework was not released and it was not clear if and when certain features are included. Also the API was not stable at that time. In contrast to our solution, XText has the advantage that it creates the parser from the EMF model.

	The most challenging technical part was the synchronisation with the Rodin database, particularly in the presence of other tools concurrently manipulating the same model.		The most challenging technical part was the synchronisation with the Rodin database, particularly in the presence of other tools concurrently manipulating the same model.
	To achieve this we created a new abstraction of the Rodin database as an EMF ([http://www.eclipse.org/modeling/emf/ Eclipse ~~Modeling~~ Framework Project]) data model. It allows us to work with Event-B models independently of the persistence strategy. In addition we can use EMF standard technologies for manipulating, comparing and merging of Event-B models.		To achieve this, we created a new abstraction of the Rodin database as an EMF ([http://www.eclipse.org/modeling/emf/ Eclipse Modelling Framework Project]) data model. It allows us to work with Event-B models independently of the persistence strategy. In addition we can use EMF standard technologies for manipulating, comparing and merging of Event-B models.

	The fit between the database model and the text representation posed a number of challenges. Users must be able to edit both in the text editor and the structural editor. However, the text editor provides much more freedom in formatting than the structural editor. The current implementation keeps the formatting of the user intact, unless changes through the structural editor are made. Also, comments cannot be placed anywhere, which is unintuitive in a text environment. This is due to the fact that the database allows comments only in certain places. Some constraints on permitted characters in labels and identifiers had to be made. In all these instances, meaningful error messages guide the user, and the editor attempts to be as unobtrusive as possible.		The fit between the database model and the text representation posed a number of challenges. Users must be able to edit both in the text editor and the structural editor. However, the text editor provides much more freedom in formatting than the structural editor. The current implementation keeps the formatting of the user intact, unless changes through the structural editor are made. Also, comments cannot be placed anywhere, which is unintuitive in a text environment. This is due to the fact that the database allows comments only in certain places. Some constraints on permitted characters in labels and identifiers had to be made. In all these instances, meaningful error messages guide the user, and the editor attempts to be as unobtrusive as possible.

	= Available Documentation =		= Available Documentation =

	=== Online Documentation ===		=== Online Documentation ===


	[http://wiki.event-b.org/index.php/Text_Editor Text Editor Wiki Page]		[http://wiki.event-b.org/index.php/Text_Editor Text Editor Wiki Page]
Line 48:		Line 42:

	* [http://www.stups.uni-duesseldorf.de/thesis_detail.php?id=20 A Semantics-Aware Text Editor for Event-B. Fabian Fritz. Master's Thesis. 2009]		* [http://www.stups.uni-duesseldorf.de/thesis_detail.php?id=20 A Semantics-Aware Text Editor for Event-B. Fabian Fritz. Master's Thesis. 2009]
	* Developing Camille, a Text Editor for Rodin. Jens Bendisposto, Fabian Fritz and Michael Leuschel. 2009. (submitted)		* Developing Camille, a Text Editor for Rodin. Jens Bendisposto, Fabian Fritz and Michael Leuschel. 2009. (submitted)

	= Planning =		= Planning =
	~~This paragraph shall give a timeline and current status (as of 29 Jan 2010).~~		The Text Editor needs to be extended to support new attributes (e.g. stemming from the upcoming decomposition plug-in) and the upcoming mathematical extensions.

	The Text Editor needs to be extended to support new attributes (e.g., stemming from the upcoming ~~Decomposition~~ plug-in) and the upcoming mathematical extensions.

	Users have expressed the desire to be able to insert comments everywhere. It is unclear whether this can be achieved without a major refactoring of the Rodin Database.		Users have expressed the desire to be able to insert comments everywhere. It is unclear whether this can be achieved without a major refactoring of the Rodin Database.