ql-gemoc-lwb2025

Authors: Didier Vojtisek <[email protected]>, Benoit Combemale <[email protected]> — v1.1, 2025-05-20

Questionnaire Language DSL implemented using the GEMOC Studio as a solution for the Language Workbench Challenge 2025 (LWB2025)

Challenge Participation and Context

This document presents the implementation of the "Questionnaire Language" proposed in the Language Workbench Challenge 2025, using the GEMOC Studio as the target language workbench. This challenge, as a continuation of the Language Workbench Contest initiated in 2013, aims to demonstrate the capabilities of modern language workbenches by modeling and implementing a relatively simple but representative domain-specific language (DSL).

The origins of the GEMOC Studio trace back to an initial ANR-funded research project launched in 2011, prior to the formalization of the GEMOC initiative (2013). Initially developed as a research platform to explore model execution and coordination of heterogeneous modeling languages, the Studio has since evolved through successive research collaborations and open-source contributions. Over time, it has matured into a modular workbench built on Eclipse technologies, primarily used in research and transfert contexts for designing and executing DSMLs. Today, the GEMOC Studio is hosted as an official project under the Eclipse Foundation, benefiting from a stable and open governance structure within the broader Eclipse Modeling ecosystem.

The GEMOC Studio aims to offer a comprehensive environment for designing, executing, and coordinating DSMLs, with a particular focus on executable modeling and multi-language system integration.

The GEMOC Studio integrates and assembles several major existing Eclipse technologies for language engineering, including:

• EMF (Eclipse Modeling Framework) for metamodeling and model management,

• Sirius Desktop for the definition of graphical editors,

• Xtext for the specification of textual editors.

Readers may refer to the respective official documentation of these tools for detailed usage information.

Beyond this integration, the GEMOC Studio extends these capabilities by providing:

• Several semantic modeling frameworks for defining the execution semantics of DSMLs, i.e., the underlying execution behavior of conforming models to be executed and evaluated accordingly (e.g., K3, ALE for sequential semantics; MoCCML for concurrency modeling),

• Execution engines and engine addons that enable advanced runtime services such as model animation, debugging, timeline visualization, state space exploration, and concurrency control,

• Coordination mechanisms for combining multiple models or languages at execution time.

This architecture allows users to not only define the structure and editors of a DSL but also to specify, execute, and debug its execution semantics.

Given the diversity of capabilities offered by the GEMOC Studio, specific tools and approaches were deliberately chosen to showcase the breadth of GEMOC’s potential. The design decisions made in this implementation aim not only to address the technical requirements of the Questionnaire Language but also to illustrate various features of the GEMOC Studio. In some cases, alternative choices might have been more appropriate for a production-ready language implementation, but demonstrating the versatility of the workbench was prioritized.

Deliverables

• The git repository: https://github.com/gemoc/ql-gemoc-lwb2025

• The feature tables for this submission:

  • QL: https://github.com/gemoc/ql-gemoc-lwb2025/blob/main/docs/QLFeatures_Table_Template.xlsx

  • LWB: https://github.com/gemoc/ql-gemoc-lwb2025/blob/main/docs/LanguageWorkbench_FeatureConfiguration.xlsx

  • MW: https://github.com/gemoc/ql-gemoc-lwb2025/blob/main/docs/ModelingWorkbench_FeatureConfiguration.xlsx

Document Structure

The remainder of this document is organized as follows:

• Repository Structure: A description of the repository content.

• Quick Start Instructions: A brief guide to install the necessary tools, import the project, and launch the Questionnaire Language execution. This section allows readers to quickly verify the implementation without going into technical details.

• Selected Tools, Approaches, and Design Rationale: A description of the tools and modeling approaches selected within the GEMOC Studio environment, combined with explanations of the main motivations behind these choices.

• Modeling and Implementation Overview: A detailed description of the abstract syntax, concrete syntax, and behavioral semantics.

• Demonstration of Execution and Tooling Support: An illustration of the execution features enabled by the implementation, including screenshots and explanations of the available tooling.

• Additional GEMOC Studio features illustrated in other case studies: Although not directly demonstrated in this implementation, other capabilities of the GEMOC Studio — such as advanced concurrency modeling, state space exploration, live model-execution synchronization, and multi-language coordination — are highlighted through complementary case studies and example languages.

• Implementation metrics numbers based on the implementation (e.g., SLOC, time to implement it)

Repository Structure

The repository is organized as follows:

• plugins/

  • Contains the source code for the language definition and execution support.

  • Subfolders:

    • commons/: Utility projects intended for reuse across multiple engine implementations. This reflects an initial design goal to support alternative execution approaches (e.g., MoCCML, coordination-based engines) in addition to the current K3-based implementation.

    • k3ql/: Projects defining the behavioral semantics of the Questionnaire Language using the K3 framework (GEMOC Sequential Engine).

    • ql/: Projects defining the structural (metamodels) and syntactical (editors) aspects of the Questionnaire Language (including Xtext grammar and Sirius diagrams).

    • qls/: Projects defining the structural (metamodels) and syntactical (editors) aspects of the Questionnaire Layout and Styling (including Xtext grammar).

Note	Each of these folders contains multiple Eclipse plug-in projects that must be imported individually into the GEMOC Studio.

• model_examples/

  • Example models conforming to the Questionnaire Language.

  • Includes textual models (.ql), corresponding graphical representations (.aird) and associated Layout and Styling models (.qls)..

• docs/

  • .xlsx files for the QL, LWB, and MW feature tables applied for the GEMOC Studio and this implementation.

  • Documentation files for the project (such as metamodel diagrams and development notes).

• releng/

  • Maven/Tycho configuration for building and managing the project as an Eclipse-based product.

• README.adoc

  • Entry point documentation, including context, quick start, and technical explanations.

• .github/, .mvn/, .settings/

  • Standard GitHub Actions, Maven, and Eclipse settings for automation and environment configuration.

Quick start

This section provides the basic instructions to install the Language Workbench with the language definitions for the challenge, and to run the Modeling Workbench with example models conforming to the languages.

Setting up the Language Workbench for the design of the Questionnaire Language

Requirements:

• Java 17 or higher

• A GEMOC Studio downloaded from http://gemoc.irisa.fr/pub/studio/gemoc_studio_2024_11_12/

Note	This is the version used to develop the languages for the challenge. A more recent version may be available from https://gemoc.org/download.html.

Note	Documentation for the GEMOC Studio is available here.

• A git clone of the challenge repository: https://github.com/gemoc/ql-gemoc-lwb2025 (This can also be performed directly from within GEMOC Studio.)

Steps:

• Unzip or untar the downloaded GEMOC Studio.

• Start GEMOC Studio.

Note	In this context, we refer to this initial workspace as the Language Workbench, since it contains the language definitions for the challenge.

• Import all projects contained in the following folders of the cloned repository:

  • plugins/commons/

  • plugins/k3ql/

  • `plugins/ql/

  • plugins/qls/

Tip	In GEMOC Studio, use File > Import…​ > General > Existing Projects into Workspace, then select each folder above to import all contained projects at once.

Setting up the Modeling Workbench to Use the Questionnaire Language

From the Language Workbench instance of GEMOC Studio, a second instance (the Modeling Workbench) must be launched where the developed language plugins will be deployed.

Steps:

• In GEMOC Studio, open the menu: Run > Run Configurations…​

• Under Eclipse Application, select Launch Runtime Eclipse LWB2025 and click Run.

Note	This launch configuration is available if the org.gemoc.ql.k3ql.xdsml project has been correctly imported.

Note

Although for demonstration purposes we start the Modeling Workbench from the Language Workbench, it is possible to package the DSL for standalone use by end users. See: https://download.eclipse.org/gemoc/docs/releases/3.6.0/userguide-lw-deploy-language.html#distribute-language-for-model-designer-section

• In the opened Modeling Workbench, import the projects located in the model_examples/ folder.

Model Editing

• Edit the provided models using the textual editor (.ql and .qls files).

Figure 1. Modeling Workbench textual editor opened on the HouseOwning example

Figure 2. Modeling Workbench textual editor with typechecker in actionn

Figure 3. Modeling Workbench textual editors with optional QLS in action

• Visualize models using the graphical editor by opening the corresponding *.aird files associated with the .ql files.

Figure 4. Modeling Workbench graphical editor opened on the HouseOwning example

Note	For the challenge, we haven’t implemented Sirius edition tool (palette) except interactions with the Xtext editor. So edition within Sirius views is currently limited to its property view.

Model Execution

To execute a model (i.e., to start a questionnaire):

• Open the view QL Form Browser View:

  • Menu Window > Show View > Other > Questionnaire Language > QL Form Browser View.

• Start the model execution:

  • Menu Run > Run Configurations…​ > Executable GEMOC with Java engine.

  • Use one of the predefined launch configurations for the provided models, or create your own (make sure to activate the QL Form Browser View addon in the Engine Addons tab).

This launches the questionnaire execution inside the QL Form Browser View and, if available, also triggers graphical animation of the model with Sirius.

Note

Several preconfigured launch configurations are provided, they illustrate various options such as: - starting from a .ql file without styling - starting from a .qls styling file - activating the Sirius animation - activating trace/timeline options (these options are actually more relevant when starting the launch configuration in debug mode.)

Important

In order to have a functional launch configuration, the org.gemoc.ql.k3based.addons.views.QLFormBrowserView in the addon tab must be activated. Otherwise, the execution will take no input from the user (see discussion about this implementation later in this document)

The Sirius-based graphical animation offers a complementary visualization of the running questionnaire by displaying runtime information directly on the model: - The current value of each question is dynamically displayed. - The visual appearance of questions (such as color changes) is updated in real-time to reflect their visibility status (e.g., whether a question is currently shown to the user or hidden based on the model’s logic).

Figure 5. Graphical animation of a running questionnaire model in Sirius, showing dynamic updates of question values and visibility states during execution

The use of an optional QLS model allows to illustrate one extension technique supported by the GEMOC Studio by adding layout and styling support to the questionnaire language. The lower rigth part of Figures Execution of a questionnaire without QLS and Execution of a questionnaire without QLS shows the effects on the form view.

Figure 6. Execution of a questionnaire without QLS

Figure 7. Execution of a questionnaire with QLS

Model Debugging

To debug a model (i.e., to start a questionnaire in debug mode):

• Open the Debug perspective:

  • Menu Window > Perspective > Open Perspective > Debug.

• Open the view QL Form Browser View as described above.

• Start the model in debug mode:

  • Menu Debug > Debug Configurations…​ > Executable GEMOC with Java engine.

  • Use one of the predefined launch configurations or create your own.

In addition to the Sirius-based graphical animation available during execution, several debugging-specific views and actions are provided. These features operate at the level of the Questionnaire Language (i.e., they allow debugging the model itself, not the underlying Java code):

• Stack View: Displays the current execution stack when the execution is paused.

• Variables View: Shows the current runtime values of the model elements.

• Step-by-Step Execution: Enables manual control to execute one step at a time through the model behavior.

• Model Breakpoints: Allows breakpoints to be set directly on model elements (Right-click a model element in the Sirius view to toggle a breakpoint; execution will pause when a related model step occurs).

• Current Element Highlighting: Highlights the model element currently being executed (decorated in yellow in the Sirius graphical editor and selected in the textual Xtext editor).

• Multidimensional Timeline (optional): If enabled in the launch configuration (Engine Addons tab), the Multidimensional Timeline view visualizes the history of runtime data changes over time in a structured and synchronized manner.

These capabilities together offer a rich environment for observing, inspecting, and controlling the execution of the questionnaire models at a high level of abstraction.

Figure 8. Modeling Workbench with the HouseOwning example pause after a click on hasSoldHouse and while rendering the questions (only 2 out of the 3 optional questions have been enabled and displayed at this point)

Selected Tools, Approaches, and Design Rationales

For this implementation, we selected a combination of GEMOC Studio tools and modeling approaches to illustrate both basics and advanced capabilities of the platform. The choices were guided by a balance between simplicity, modularity, and demonstration value for the challenge.

DSL Edition

• EMF (Eclipse Modeling Framework) was used to define the metamodel, and automatically provide a basic tree-based editor for model instances (offering a structured syntax).

• Xtext was employed to define a more user-friendly textual syntax for questionnaire models, integrated directly into the Eclipse environment.

• Sirius Desktop was used to define graphical visualizations:

  • A Basic Object Diagram was automatically generated using the GEMOC wizard. Inspired by UML Object Diagrams, this view is verbose and generic, but can serve as a starting point for more specialized diagrams.

  • A manually crafted QLDiagram was designed to offer a more domain-specific and readable visualization of questionnaires.

Note	In this implementation, the Sirius graphical editors focus on visualization rather than full model editing: edition actions (e.g., palette tools) were not implemented, and editing remains limited to the property view or synchronized editing through the Xtext textual editor.

DSL Execution Semantics

• A K3-based sequential execution engine defines the execution semantics of the questionnaire models. K3 language offers a simple yet powerful metaprogramming approach by weaving behavioral aspects directly onto EMF model elements.

Note	As K3 language is actually a set of annotations for the Xtend that compiles to Java, for GEMOC this is also referred to as GEMOC Java Engine.

• Separation of UI and execution semantics was emphasized through the use of the GEMOC Engine Addon mechanism:

  • A custom Engine Addon (QLFormBrowserView) was developed to handle the display and interaction of the questionnaire UI, without mixing UI concerns into the execution semantics.

  • This addon listens to runtime events published by the execution engine, enabling dynamic updates of a web-based form embedded in an Eclipse view.

Important

The https://download.eclipse.org/gemoc/docs/nightly/_contributing.html#dev-new-addonsEngine Addon mechanism used here reflects one of GEMOC Studio’s core strengths: it enables coordination between multiple concurrent runtime models or external systems. In this case, the questionnaire execution and the UI form are treated as loosely coupled artifacts, coordinated dynamically through the engine events.

Edition and Semantic Customizations

• Debug layers were automatically generated for both Sirius diagrams, providing support for execution highlighting, breakpoints, and stepping during model debugging.

• Animation layers were manually designed for the QLDiagram, enabling visual feedback during execution (such as dynamic value display and question visibility indication).

Resulting Language

The resulting language and its associated tooling support are named K3QL. K3QL encapsulates the questionnaire domain-specific modeling constructs, textual and graphical editors, execution semantics, and runtime interaction features defined through the approaches outlined above.

Modeling and Implementation Overview

Abstract Syntax

QL Abstract Syntax

The abstract syntax of the QL language is captured using an Ecore metamodel that is defined in the org.gemoc.ql.model plugin.

It is organized as follows:

Figure 9. QL main class diagram

Figure 10. Named elements class diagram

Figure 11. Expression class diagram

Figure 12. Types class diagram

QL main class diagram shows that Question conforms to a QuestionDefinition. A set of Question is organized in group and sub-group that may have a guard. This guard indicates when the questions in the group must be displayed. QuestionDefinition may be calculated by evaluating an Expression.

Note	The name Question and QuestionDefinition is arguable in case of calculation. A refactoring may be done later in order to enhance the readability of the abstract syntax.

A QuestionDefinition data is typed by a ValueType that can take one of the primitive type as shown in Types class diagram.

ValueType are defined with the Questionnaire (QLModel) and may define a unit and additional attributes such as min or max.

Expression allows the evaluation of Value that can come from different kinds of expression: BinaryExpression for expression having left hand side and right hand side, UnaryExpression for operators such as Not or Minus.

the IfExpression allows to create conditional expression return the evaluation of the thenExpression or the elseExpression depending on the evaluation of the condition.

The runtime data has been directly added into the QL.ecore: QuestionDefinition.currentValue, QuestionDefinition.isDisplayed, and QLModel.canSubmit. These data aren’t intended to be directly edited by the user but used by the interpreter. They have the annotation aspect in order to identify them in the ecore file.

Note

Some techniques exist to define these runtime data separately from the QL.ecore: by weaving ecore models using Melange but this would have made the projects more complex due to the required conversion. (see. https://download.eclipse.org/gemoc/docs/nightly/userguide-lw-create-language-define-syntaxes.html#section-melange-editor and http://melange.inria.fr) by creating a separate metamodel that references the elements in QL.ecore, as a counter-part, the code for the behavior would have been a bit less readable.

QLS Abstract Syntax

The abstract syntax of the QLS (layout and styling) language is captured using an Ecore metamodel that is defined in the org.gemoc.qls.model plugin that depends on org.gemoc.ql.model plugin.

It is organized as follows:

Figure 13. QLS main class diagram

The figure QLS main class diagram shows the reference from QLS to QL model elements.

A QLSModel decorates a QLModel. It specifies sections that contain ordered content (other sub-sections or references to QuestionDefinition). These information are to organize the order and grouping of questions on the view. The actual visibility of a question remains a responsibility of the QL model.

QuestionStyle decorates a QuestionDefinition to provide some visual customization on the label, or on the question type.

Note	The Import coming from xText allows having simple and precise references to imported models. It is used to reference the resource containing the QL model with textual syntax.

Concrete Syntax

Three editors are provided: the EMF tree editor, the XText textual editor, and the Sirius graphical editor

EMF Tree Editors

It was not modified much from its initial generation except for some minor enhancements on the model element labels and icons.

It is composed of the following plugins:

• org.gemoc.ql.model.edit and org.gemoc.ql.model.editor for QL

• org.gemoc.qls.model.edit and org.gemoc.qls.model.editor for QLS

Tip	org.gemoc.ql.model.edit and org.gemoc.qls.model.edit are actually reused in several other editors and Eclipse views, such as the Sirius editor and the outline view.

XText Textual Editors

It is composed of the following plugins:

• org.gemoc.ql.xtext, org.gemoc.ql.xtext.ide, and org.gemoc.ql.xtext.ui for QL

• org.gemoc.qls.xtext, org.gemoc.qls.xtext.ide, and org.gemoc.qls.xtext.ui for QLS

The QL.xtext and QLS.xtext files define a user friendly grammar allowing support of qualified names, expressions, …​

They provide modern textual editors with syntax coloring, code completion, error reporting, …​

They also provide a framework for quick fixes, validation, renaming, hovering, …​ A more complete list of feature is available in this XText documentation section.

For the challenge, in addition to the grammar, we also have:

• customized the formatting support (QL).

• implemented the type checking of expressions (QL).

Sirius Graphical Editor

It is composed of the plugin: org.gemoc.ql.design.

It provides 2 diagrams:

• A Basic Object Diagram was automatically generated using the GEMOC wizard. Inspired by UML Object Diagrams, this view is verbose and generic, but can serve as a starting point for more specialized diagrams.

• A manually crafted QLDiagram was designed to offer a more domain-specific and readable visualization of questionnaires.

Sirius provides a way to define a mapping between visual elements (Node, Edge) and the abstract syntax concepts. Then it interprets this mapping in order to provide the representation of the model in an editor.

Each diagram uses the notion of Layer in order to easily switch on or off some customization.

For example, the QLDiagram proposes a Typing layer that shows the link between Question and QuestionDefinition.

The Debug layer has been generated by GEMOC. It allows setting/removing breakpoints, and allows conditional styling during debug pause (i.e. highlighting the element in the diagram that corresponds to the selection in the stack view)

It also proposes an Animation layer. It is activated during model execution. It changes the color of the Question and QuestionDefinition to grey if they aren’t displayed and add fields to display the current value of the questions.

Tip	Sirius provides several kinds of representations. In the challenge, we used the Diagram representation, but others might be useful too. See Sirius Specifier Manual

For this challenge, we provided a Sirius graphical editor only for QL.

Behavioral Semantics

Core Execution Semantics

The execution semantics are defined in the org.gemoc.ql.k3ql.k3dsa plugin.

The operational semantics of QL are defined in the file qlAspects.xtend, which employs Kermeta 3 (K3) and the Interpreter Design Pattern to describe the dynamic behavior of QL models. Its contents are woven into the metamodel of your executable DSL. In this file, you have aspects for all classes of your metamodel. Some of these aspects use annotations to define execution functions or entry points.

Execution Functions:

The Execution Functions define how the Execution Data evolves during the execution of the model. Execution Functions can be implemented by defining the body of a method. These methods must be annotated with the @Step annotation. Whenever a method with an @Step annotation returns, the changes in the model will be applied (via a transaction) to the resource. This means that the changes will be visible from an animator. K3 supports nested @Step annotation calls so that changes in the model will be applied when entering and leaving methods having these annotations.

Entry Points:

The GEMOC sequential engines use methods annotated with @Main as entry points to model execution. This annotation must be placed on operations that apply to model elements considered the starting point of the model.

Additionally, a function annotated with @InitializeModel captures any arguments passed by the launcher and initializes the runtime data, if necessary.

For the challenge, there are two possible entry points:

• a QLModel element when run without styling

• a QLSModel element when run with styling support.

The logic in QL implementation is as follows:

• The main method is simply a loop that alternates question rendering requests, waiting for user input, and computing value for computed questions.

• When the submit button has been pushed, it ends by performing a basic serialization of the whole model, including the runtime data (i.e. the answers)

Question rendering requests ensure via guard evaluation that only the `Question`s in groups where the guard evaluates to true are rendered.

The concrete rendering in the UI is handled by an engine addon that captures the events QLModel.renderQuestions() and the event QLModel.updateSubmitButtonStatus(). Similarly, the wait for user input is also handled by the engine addon that captures the event QLModel.waitUserInput(). It pauses execution until an event occurs in the UI. The events QLModel.readSubmitButtonStatus() and QuestionDefinition.updateCurrentValueFromUI() are also captured by the addon. They modify the runtime data in the model.

Note

The code for the type checking used by the Xtext editor uses the same approach as the execution semantics: it relies on K3 aspects. The Xtext validation framework triggers validation in the editor and then calls the aspects to infer types and check compatibility. The approach allows reusing the same code in other validation frameworks, such as the EMF validation framework or Sirius’s internal validation. This can be handy if we allow editing of the model using editors other than the textual one.

UI

To separate the core execution semantics from the UI, the UI has been defined as an engine addon in the org.gemoc.ql.k3based.addons plugin.

When activated in the launch configuration, addons listen for engine events.

Thus, the methods in the class QLFormBrowserViewAddon will be called on specific engine events.

In this implementation, most of the work is done while capturing the aboutToExecuteStep engine event, i.e. before a method annotated with @Step is called. All addon API methods provide access to the engine, the EMF model including its runtime data if they have been defined using EMF, as well as details about the triggered event. It is then easy, depending on the event, to read model runtime data in order to do some action in the UI or, conversely, apply UI changes to the model runtime data.

In the engine, the execution of the addon methods is atomic. The engine ensures that all defined addon methods have been completely executed before continuing to the next step. As it pauses the model execution and provides access to runtime data, this is handy to implement the QLModel.waitUserInput() step.

Tip	Most GEMOC features are based on this addon API. For example, the debugger is an addon that pauses the execution when a given condition (a breakpoint) is reached. Timelines listen to model changes to store relevant information (e.g., runtime data changes and events) in order to build the view.

Tip	In some situations, when many addons are activated, the order in which they are called may provide non-intuitive behavior. GEMOC allows to control the call to addon by implementing the getAddonSortingRules method.

As a concrete UI, the implementation provides an HTML web form that is embedded in an Eclipse view. Data exchange between Eclipse and the web page is achieved using the swt.Browser class as it allows to call javascript methods in the page or react to javascript call.

The rendering of the QL form is then performed by writing in an HTML div when QLModel.renderQuestions() event is received. The same principle applies for the other events that must interact with the UI.

As the addon has complete access to the models, it can determine if the model runs with or without styling support. It uses methods in qlHtmlAspects.xtend and qlAspects.xtend to organize the code and simplify the navigation within the model while producing the UI specific code.

Tip	As this is an addon, we can imagine implementing this in many other ways (web protocol, java awt, java swing, javafx, …​) and switch between them by activating them in the launch configuration.

Demonstration of Execution and Tooling Support

As seen in Section Quick start, in addition to the editing capabilities provided by embedded tools such as Xtext and Sirius, the GEMOC Studio offers a strong focus on model execution and debugging support.

This section details several execution and debugging features demonstrated with the Questionnaire language.

By default, in GEMOC, a model is launched using a launch configuration. Figure Main tab of the launch configuration for the ProjectBudgetEstimation questionnaire example shows the main tab of this configuration, which allows users to:

• Select the model to run.

• Choose the behavioral semantics (GEMOC supports multiple variants for the same language).

• Define the entry point (i.e., the model element used to start execution—particularly useful for DSLs with multiple potential roots).

• Select the @Main method, if multiple entry points are defined in the language semantics.

Arguments can also be passed as a list of strings to the @InitializeModel method. This is useful for initializing relevant runtime data before execution starts.

In addition, a Sirius graphical representation can be specified. At launch, the animation layer is automatically activated, based on declarations in the AbstractGemocAnimatorServices subclass.

Tip	Because GEMOC Studio is built on Eclipse, model execution can also be triggered through wizards, menus, popups, or custom UI integrations.

Figure 14. Main tab of the launch configuration for the ProjectBudgetEstimation questionnaire example

Figure Engine addon tab of the launch configuration shows the tab where you can activate or deactivate optional engine addons.

• The Generic Multidimensional Data Trace addon records runtime data, enabling inspection via the Multidimensional Timeline view. This addon is generic and compatible with any language using the sequential engine.

• The QLForm Browser View addon provides the UI for the Questionnaire language. It must be enabled to display the challenge form interface. As discussed in Section Behavioral Semantics, this addon is specific to the QL DSL, but other UI views could be swapped in by enabling different addons.

Figure 15. Engine addon tab of the launch configuration

When launched in Debug mode, the GEMOC Studio provides a suite of integrated views:

• The Sirius editor switches to a read-only mode with active animation layers.

• The QLForm Browser View displays the interactive questionnaire UI.

• The Stack View shows the current execution context.

• Variables View displays current runtime data.

• The Multidimensional Timeline shows historical data changes and supports omniscient navigation.

• Classical debug controls (step into, step over, resume) are fully supported.

Figure Debug view paused after the user enabled the requireDesignAndUX question illustrates a paused execution. Notable elements include:

• The QLForm UI reacts to user input, updating the form and validating completion.

• A breakpoint (blue dot) has been set on any @Step methods applied to the totalProjectCost QuestionDefinition, pausing execution.

• Highlighting and selection in the Sirius view and Xtext editor are synchronized with the stack.

• The Animation layer uses color coding to show which questions are visible, the submit button state, and other dynamic data.

• The Multidimensional Timeline view is divided into two synchronized sections:

  • The top section, labeled All Execution States, shows a global timeline of execution steps. Each blue dot represents a point where at least one dynamic data value changed. Below each dot, horizontal lines indicate the invocation of @Step methods (i.e., the execution stack at that state).

  • The lower section, Timeline for Dynamic Information, displays one timeline per piece of runtime data. Each timeline is continuous and breaks visually at points where the corresponding data changes. These timelines are vertically aligned and synchronized, allowing users to correlate global execution events with specific data changes across time

Figure 16. Debug view paused after the user enabled the requireDesignAndUX question

Figure Debug view with Variables View showing runtime data focuses on the Variables View after the user changed the estimatedPersonHourForDev value.

Figure 17. Debug view with Variables View showing runtime data

It is also possible to navigate backward and forward in time within the execution trace. Clicking on a timeline point restores the model state and updates the views accordingly.

Figure Backward navigation: restored state after the estimatedPersonHourForDev value was changed shows such a rewind, highlighting a previous state where estimatedPersonHourForDev was 7, and estimatedDevCost was 140.

Note	Some custom UIs may also refresh when navigating through the timeline. However, this depends on the UI technology and how it consumes the model state.

Note

Unlike the concurrent engine (see Section Concurrency Modeling with MoCCML), the sequential engine used by K3QL does not support full rollback execution. Timeline navigation is a form of omniscient debugging: the model is restored for inspection, but cannot be resumed from that point. By contrast, the concurrent engine can truly branch execution from earlier states.

Figure 18. Backward navigation: restored state after the estimatedPersonHourForDev value was changed

Additional GEMOC Studio features illustrated in other case studies

Beyond the features demonstrated in the K3QL implementation, the GEMOC Studio offers advanced capabilities that have been showcased in other case studies and tutorials. While these features are not used directly in the context of the Questionnaire Language defined for the challenge, they are important to highlight when evaluating the GEMOC Studio as a language workbench. They illustrate powerful and often unique capabilities—such as explicit concurrency modeling, coordination of multiple DSMLs, and advanced execution analysis—that are especially valuable when engineering complex or interacting languages. These aspects reinforce the strength and flexibility of the GEMOC approach, even beyond the scope of this specific challenge use case.

Concurrency Modeling with MoCCML

The GEMOC Studio supports advanced concurrency modeling through the Model of Concurrency and Communication Modeling Language (MoCCML). This capability allows language designers to formally specify concurrency constraints independently of a language’s operational semantics. The result is a modular and analyzable approach to handling concurrent behaviors in domain-specific modeling languages.

MoCCML is based on defining logical relationships between events—such as precedence, mutual exclusion, and causal dependencies—without prescribing how the behavior is implemented imperatively. This is particularly useful for domains such as reactive systems, embedded control, or human-machine interaction, where concurrency and timing are central.

When a DSL allows several elements to execute independently, it may naturally give rise to multiple valid execution orders. For instance, if two actions A and B are unrelated semantically, then both the execution order A → B and B → A—or even simultaneous execution—can be considered correct. Without a formal concurrency specification, such behavior remains implicit, making it harder to predict, debug, or analyze. MoCCML provides the means to make these concurrency relationships explicit.

A typical development flow includes:

• Defining execution steps in the behavioral semantics (e.g., via methods in K3). Unlike @Step in the sequential engine, these methods must be atomic and cannot be nested. If nesting is required, they must be split into atomic parts. In GEMOC, they are called DSA (Domain Specific Action)

• Declaring relevant event definitions corresponding to those execution steps in the context of the DSL metaclasses. In GEMOC, they are called DSE (Domain Specific Event)

• Writing MoCCML models and ECL constraints to express concurrency constraints between events.

• Launching model execution in GEMOC Studio using the MoCCML engine.

Once in place, these models enable:

• Executions that respect specified concurrency constraints.

• Visualization of partially ordered execution traces.

• Use of the Multibranch Timeline View to inspect concurrent behavior and temporal properties. This view allows omniscient debugging by effectively navigating backward in the execution trace and branching into alternative concurrent possible executions.

• Step-by-step debugging that reflects both behavioral logic and concurrency control.

• Generation of the complete state space of a model.

• Analysis of possible execution paths.

• Identification deadlocks and unreachable states.

This technique is illustrated in several case studies and tutorials, such as the ICSA 2017 tutorial (https://github.com/gemoc/ICSA2017Tutorial), the MODELS 2017 tutorial (https://github.com/gemoc/MODELS2017Tutorial), and the dedicated tutorial “Weave Domain-Specific Concurrency Constraints Into Your DSL!” (https://gemoc.org/weave-domain-concurrency-into-your-dsl.html).

Figure 19. Concurrency MultiBranch Timeline on a FSM model

Figure Concurrency MultiBranch Timeline on a FSM model, taken from the MODELS 2017 tutorial, illustrates the Multibranch Timeline View applied to a concurrent FSM model. It highlights key features of the view and the concurrent engine:

• Blue dots represent the main sequence of selected combinations of simultaneous events during the execution trace.

• Green dots indicate alternative combinations of events that were also valid at a given point, offering insight into possible concurrent interleavings.

• The timeline also supports backtracking and branching, allowing users to jump back to a previous decision point and explore an alternative path of execution, making it possible to analyze multiple valid behaviors of a concurrent system.

MoCCML-based concurrency modeling exemplifies one of GEMOC Studio’s distinctive strengths: allowing DSL designers to explicitly and modularly define how concurrency should behave, enabling more robust and analyzable modeling tools.

Behavioral Coordination with BCOoL

The GEMOC Studio offers a unique and powerful capability for coordinating the behavior of models written in different Domain-Specific Modeling Languages (DSMLs). This is achieved through BCOoL — the Behavioral Coordination Operator Language. BCOoL enables language designers to explicitly define how models from different DSMLs should interact at runtime, making it a key tool for supporting multi-language modeling in complex systems.

When engineering complex systems, different concerns (e.g., control logic, physical simulation, user interaction) are often best expressed using different DSMLs. However, executing and analyzing such systems jointly requires these models to be coordinated: their behaviors must be synchronized according to precise rules. Without this, inconsistencies or timing mismatches may arise during execution.

BCOoL offers:

• Formal definition of coordination operators between events produced by different DSMLs (e.g., synchronizing a state change in a controller with an action in a process model).

• Model-driven generation of coordination logic that is reusable and automatically applicable across different models.

• Integration with GEMOC’s runtime execution framework, enabling the execution of coordinated multi-language models.

Importantly, this integration is made possible by the underlying GEMOC Framework Engine API. At runtime, each language is extended through Engine Addons, which allow models to emit and respond to coordination events. BCOoL-generated coordination logic is deployed as such addons, enabling synchronized execution across independently defined engines.

BCOoL builds on three core concepts:

• Events as a coordination interface: Each DSML exposes a set of meaningful runtime events (called DSAs — Domain-Specific Actions — in GEMOC) that can be coordinated. These are typically defined during the implementation of the DSML’s behavioral semantics.

• Coordination Operators: Coordination logic is written as BCOoL specifications, where language designers declare synchronization rules (e.g., "when event A in language L1 occurs, event B in language L2 must follow").

• Execution Model Coordination:

  • BCOoL specifications are compiled into Coordination Models.

  • These are woven into a Coordinated Execution Engine that integrates the event streams of the involved DSMLs.

  • At runtime, GEMOC Studio uses this coordination model to control the interleaving and synchronization of the models' behaviors.

Example: Coordinating a Coffee Machine using FSM and Activity Diagram

A practical example from the BCOoL tutorial demonstrates coordination between:

• A Finite State Machine (FSM) modeling the user interface of a coffee machine, and

• An Activity Diagram (AD) modeling the internal preparation process of the machine.

BCOoL is used to specify coordination rules that, for instance, ensure that selecting a beverage in the FSM must trigger corresponding activities in the AD. The coordination operators synchronize user-driven state transitions with back-end processing steps.

A coordinated execution engine is generated and used to simulate the interaction between both models. This maintains a clear separation of concerns while ensuring correct behavioral interaction between the front-end control and internal logic.

The following figure shows the Concurrent Logical Step Decider view. This view displays the set of logical steps available at each execution state, including all valid interleavings of steps across the two models. This is particularly useful for visualizing coordination between DSMLs with different execution structures.

Figure 20. Coffee machine example showing coordination between FSM and Activity Diagram (with Concurrent Logical Step Decider)

When executing coordinated models in GEMOC Studio:

• The Multibranch Timeline View from the concurrent engine is particularly helpful for understanding and debug coordination, as it shows how events across languages align and interleave over time.

• The Concurrent Logical Step Decider allows inspection of alternative interleavings, including which combinations of steps are possible or currently selected.

• Standard debugging tools (breakpoints, step-by-step execution, etc.) are also applicable to coordinated models, allowing inspection at both the individual DSML and system levels.

BCOoL exemplifies a rare and highly valuable feature in language workbenches: it enables reusable, model-driven coordination across heterogeneous languages. This goes far beyond integrating APIs or defining ad hoc glue logic. For evaluators of the challenge, it highlights GEMOC Studio’s emphasis on system-level modeling where multiple DSMLs can interoperate in a disciplined and analyzable way.

Note	Further Resources: BCOoL tutorial page: https://gemoc.org/BCOoL/ Section about BCOoL in GEMOC documentation : https://download.eclipse.org/gemoc/docs/nightly/userguide-lw-define-composition-of-languages.html github: https://github.com/gemoc/coordination

Implementation Metrics of K3QL

Metric	Value
Development period	~6 weeks (part-time)
Number of metaclasses (combined across all Ecore models)	46
Total source lines of code (SLOC)	12,011
Number of Sirius viewpoints/diagrams	2
Number of GEMOC engine addons implemented	1

Note	SLOC includes Java/K3 code, Xtend, and model files (e.g., .ecore, .xtext, .odesign), but excludes generated code and standard library dependencies. Command used to obtain SLOC: cloc plugins --exclude-dir=xtend-gen,src-gen,target --exclude-ext=g,g4 from the root of the repository

Detailled SLOC

Language / Format	Files	SLOC
XML (e.g., Sirius models, workflows, configurations)	70	8577
Xtend (behavioral semantics)	13	1,847
Java (engine addons, utilities)	37	922
Properties (config files)	18	342
Maven (build configuration)	5	188
JavaScript (UI customization)	1	107
INI and other small formats	5	27
SVG (placeholder or icon)	1	1
Total	150	12,011

Details of the development status

docs/dev_status.adoc