|
|
|
# Generating DSLs
|
|
|
|
|
|
|
|
With DEAL, it is possible to generate a **Domain-Specific Language (DSL)** from the GUI of an existing application.
|
|
|
|
|
|
|
|
For example, if we have a simple from for filling information about a Person, such as:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A **DSL grammar** can be generated from such a form, for example:
|
|
|
|
|
|
|
|
```
|
|
|
|
Person -> <Person> Name Surname Age Gender FavouriteColor
|
|
|
|
Name -> <Name> <STRING>
|
|
|
|
Surname -> <Surname> <STRING>
|
|
|
|
Age -> <Age> <NUMBER>
|
|
|
|
Gender -> <Gender> (<man> | <woman>)
|
|
|
|
FavouriteColor -> <Favourite colors> (<red>? <blue>? <green>? <yellow>?)
|
|
|
|
```
|
|
|
|
|
|
|
|
The grammar is in the EBNF notation, terminals are noted in `< >` brackets. `<STRING>` and `<NUMBER>` terminals represent terminal string and numeric value.
|
|
|
|
|
|
|
|
A sentence in this language could look as follows:
|
|
|
|
|
|
|
|
```
|
|
|
|
Person Name Michaela Surname Bacikova Age 28 Gender woman Favourite colors blue yellow
|
|
|
|
```
|
|
|
|
|
|
|
|
And writing such sentences in the GUI language means filling the form with values.
|
|
|
|
|
|
|
|
Along with the EBNF grammar, DEAL also generates a **JavaCC language** parser for the DSL and Java classes modeling the basic language constructs.
|
|
|
|
|
|
|
|
## How to?
|
|
|
|
|
|
|
|
Start DEAL with the application, which you would like to generate a DSL from. Set DEAL to the **non-functional extraction mode** by unchecking the checkbox in **Settings -> Extract functional components**.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Use the **Hide** functionality of DEAL to hide properties, which you do not wish to extract into a DSL. For each node under the root node, a new DSL will be created - if you do not wish to use the whole window, hide the whole node using the **Hide All** functionality.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The language for each UI can be generated automatically by using the **Generate DSL** functionality located in the **Menu**.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
After generating, the workspace **src directory has to be refreshed** in Eclipse using **F5** shortcut to be able to see the actual generated directory.
|
|
|
|
|
|
|
|
The generated files can be found in the **src/dsl/[LanguageName]** directory of the DEALprototype project. The directory will automatically open in Windows OS after the generation process. The **LanguageName** will be automatically derived from the name of the application window/dialog.
|
|
|
|
|
|
|
|
The generated files include:
|
|
|
|
|
|
|
|
| **Generated resource** | **Path to the resource** |
|
|
|
|
|----------------------------------------------------------------------|-------------------------------------------------------------------|
|
|
|
|
| EBNF grammar | `[Project dir]/src/dsl/[LanguageName]/parser/javacc/grammar.ebnf` |
|
|
|
|
| JavaCC language parser for the generated DSL | `[Project dir]/src/dsl/[LanguageName]/parser` |
|
|
|
|
| Java classes modeling the basic language constructs | `[Project dir]/src/dsl` |
|
|
|
|
| Description of the language tokens, skipped characters, and concepts | |
|
|
|
|
|
|
|
|
## How does it work?
|
|
|
|
|
|
|
|
The terminology is extracted from the existing applications' user interface as the **Term graph** (on the right in DEAL) along with the information about components and component types and **relations** are derived. Then the [**yajco**](https://github.com/kpi-tuke/yajco) tool generates the DSL grammar, javacc parser and Java classes for the DSL.
|
|
|
|
|
|
|
|
Text components are extracted as `<STRING>` tokens. A **data type** can be extracted from the component type (e.g. *Spinner* with only numeric values as input is of type `NUMBER`).
|
|
|
|
|
|
|
|
If there is a group of components or a list and **single or multiple selection** is supported, then the **relation** between the terms (describing the items of the group or list) is **mutually exclusive** or **mutually not exclusive**. Examples for both cases are the rules generated from the radio button group (Gender) and from the check box button group (FavouriteColor), which describe mutual exclusivity with **alternatives** and mutual non-exclusivity with **0-1 alternatives**.
|
|
|
|
|
|
|
|
For more deails see the subsection **More resources on this topic** on this page.
|
|
|
|
|
|
|
|
## Why does DEAL not generate anything?
|
|
|
|
|
|
|
|
The generated DSL is a language of the application inputs, it describes the rules for these inputs. Therefore it can be generated only for applications, which contain any input components.
|
|
|
|
If an application contains only functional components (menus and buttons), then the grammar will not be generated. Functional components do not describe any input data, they only provide means to send the data (or retrieve them), or to change the application state.
|
|
|
|
|
|
|
|
## More resources on this topic
|
|
|
|
|
|
|
|
For more information about the motivation, extraction method and DSL generating method, see our SLATE paper:
|
|
|
|
|
|
|
|
> Defining Domain Language of Graphical User Interfaces / Michaela Bačíková, Jaroslav Porubän, Dominik Lakatoš - 2013. In: SLATE 2013: Symposium on Languages, Applications and Technologies : proceedings : June 20-21 2013, Porto, Portugal. S. 187-202. - ISBN: 978-3-939897-52-1, ISSN: 2190-6807. Available online: [PDF](http://drops.dagstuhl.de/opus/frontdoor.php?source_opus=4038) |
|
|
|
\ No newline at end of file |
