Framework Overview
From Furcas Wiki
This document is supposed to give a rough introduction to FURCAS, an Eclipse-based language workbench. It is assumed that readers are familiar with metamodeling and the basics of Eclipse and EMF.
Contents |
Important Artifacts and Components
Metamodel and Domain Model
FURCAS can be used to create textual concrete syntaxes for EMF/Ecore metamodels. Model instances of such metamodels can then be created using the designated textual language. It is also possible to modify existing models.
Mapping and Grammar
FURCAS uses a template language to create textual representations of classes of a metamodel. As this language maps grammar fragments to metamodel classes, it is called mapping. Being a model itself, the mapping is somtimes also called syntax model .
Such mappings are not (yet) modified using a FURCAS textual model editor, but are created from a plain text file. These are simple text files with the tcs file-extension. They are written by the language designer.
Editing Environment
A user modifies models rendered in a concrete textual syntax from within a textual model editor. A Text-To-Model transformation is then responsible to translate the textual syntax into its model representation. This is realized with an incrementel lexer and an incremental parser which are both automatically derived from the mapping.
The Model-To-Text transformation implements exactly the opposite operation and updates the text artifacts according to model changes. It can also be used to render an existing domain model in a designated textual syntax. The responsible component within FURCAS is called pretty printer.
Language Design Workflow
It is assumed that the Install Guide is completed and a target workbench is started. Within this target workbench all FURCAS plugins should be loaded.
Run the FURCAS Wizard to create an empty DSL project: File -> New -> Project -> FURCAS Language Workbench -> Create a FURCAS Project. It will look similar to the following:
project org.example.mylanguage.dsl:
src/org.example.mylanguage.dsl....
MyLanguageEditor.java
MyLanguageTokenMapper.java
....
generated/generated:
MyLanguage.tcs (plain text file)
....
MyLanguageParser.java
MyLanguageLexer.java
mappings/
MyLanguage.tcs (mapping model)
After the FURCAS Wizard has finished the genmodel (which can be found in the /model folder within the metamodel project) has to be excecuted. It should create the projects org.example.mylanguage.edit, org.example.mylanguage.editor and org.example.mylanguage.tests.
To define a language the MyLanguage.tcs plaintext file (under generated/generated) as well as the Mylanguage.ecore (under /model within the metamodel project) file have to be edited. Whenever they are saved a project builder re-generates lexer, parser and mapping. The only other class that one is required to modify is MyLanguageTokenMapper.java. Within this class, text attributes (e.g., color) are associated to token types as provided by the lexer.
Language Usage Workflow
Close the running target workbench. Import all projects that were created in the last step into the development workspace. The imported projects have to be refreshed (press F5) whenever the language has been modified within the target workbench. (This import step is cumbersome. It will go away once we can provide a stable build of the FURCAS plugins on our Eclipse update-site)
Start the target workbench. The project org.example.mylanguage.dsl will now be loaded and DSL editor will be available. Create an empty project and create folder called "model" within it. Use the model wizard generated by EMF (from org.example.mylanguage.editor) to create a new model instance within the model folder. Select the element that corresponds to the main template (as defined within the textual concrete syntax) as the root element.
Right click on the generated resource and open it with the associated FURCAS text editor. You can now start editing.
Creating Test Cases
Testcases are independent of the whole editing environment and created in the development workspace. They take a tcs-file and a metamodel and do generate a parser on the fly. The parser can then be tested with DSL example files or text fragments.
Take a look at the following examples TestBibTexGeneration and TestSynthesizedAttributeGrammar.
Mind the difference of StubParsingHelper and EMFParsingHelper. The first one can only be used for basic error checking, as it does not create EMF models. The latter creates full EMF models upon parsing. The example testcases use reflection to navigate these models. If EMF was used to create Java-Classes for the own metamodel, it is advisable to use this explicit API instead.
Known Environment Limitations and Bugs
- Do not try to simultaneously edit a resource using different model editors.
