Web-Native Graphical EMF Model Editors Susanne Göbel
Ralf Lämmel
[email protected] SoftLang Team, Faculty of CS, University of Koblenz Koblenz, Germany
[email protected] SoftLang Team, Faculty of CS, University of Koblenz Koblenz, Germany
arXiv:2606.11442v1 [cs.SE] 9 Jun 2026
Abstract
RQ1 Landscape Analysis: What architectural characteristics and EMF-related capabilities do existing web-based modeling frameworks provide? In this manner, we inform and justify the design principles and architecture of EMFular. RQ2 Framework Adequacy: To what extent does the EMFular framework satisfy the architectural and EMF-related criteria identified in the framework analysis? RQ3 Generation Robustness: Does the EMFular-Generator generate working web editors for real-world Ecore models without special tailoring? Can the EMFular-Generator handle a diverse set of metamodels with varying size, depth, reference structures, and inheritance patterns? RQ4 Editor Adaptability: Do EMFular-based editors support customization across the established dimensions of model editor customization, and what is the effort required to realize such customizations in practice?
Graphical model editing is shifting from desktop applications to web-based tools. We analyze the characteristics of existing frameworks and, based on this analysis, we derive a set of design principles that imply low-effort generation, extensive customization possibilities, and straightforward deployment of the resulting editors. On these grounds, we introduce EMFular, a purely web-based framework for managing EMF models without any backend. The accompanying EMFular generator maps a given Ecore model (an EMF metamodel) to a ready-to-use and ready-to-customize graphical editor. EMFular editors provide ‘EMF consistency’, that is, they not only support standard modeling operations such as creation, inspection, navigation, editing, and undo/redo, but they also handle containment and inverse references in close alignment with EMF; they also provide interoperability with existing EMF tooling through compatible de-/serialization. A generated editor is an Angular project with designated extension points, which allows developers to customize and extend all aspects of the editor using the expressive power of Angular and its ecosystem, guided by the extension points of EMFular. We evaluate EMFular in terms of editor adequacy (available editing capabilities), adaptability (customization mechanisms and required effort), and robustness of the generation.
Each of the following sections addresses one of these research question in turn: Section 2 answers RQ1 by studying related work, mainly by means of a ‘landscape analysis’, i.e., a criteria-based comparison of existing frameworks; Section 3 answers RQ2 by analyzing EMFular ’s developer-facing API and architectural principles; Section 4 answers RQ3 through a robustness validation using realworld metamodels; and Section 5 answers RQ4 by assessing and demonstrating EMFular ’ customization mechanisms — relative to general customization requirements, which we identify. Together, these results provide a comprehensive evaluation of EMFular as a client-side, EMF-compatible, and customizable foundation for web-based modeling tools, as we conclude in Section 6.
Keywords EMF, Graphical Model Editors, Web-Based Modeling, Code Generation, Code Customization, Angular, EMFular
1
Introduction
2
Modeling tools are essential for the construction, analysis, and maintenance of domain-specific languages. While the Eclipse Modeling Framework (EMF) remains the de-facto standard for meta-modeling and model management, there are many approaches for web-based graphical model editors that differ substantially in their architectural assumptions, their reliance on server-side components, and the extent to which they preserve EMF’s structural semantics. As a result, developers face a fragmented landscape in which no single solution combines EMF compatibility, client-side execution, and customizability within mainstream web development ecosystems. This paper introduces EMFular, a client-side, Angular-based framework for building EMF-compatible web editors, together with the EMFular-Generator, a generator that produces fully functional editors from Ecore meta-models. EMFular aims to preserve EMF’s structural semantics in the browser, support expressive SVGbased visualizations, and remain extensible through idiomatic webdevelopment practices. To evaluate the approach, we structure the paper around four research questions:
Related Work Incl. Landscape Analysis
We begin by discussing work relevant to the development of EMFcompatible graphical editors; we cover both conceptual foundations and empirical reports. Afterwards, we look at three current frameworks—Sirius, GLSP, and Gentleman in terms of their contrasting designs. On these grounds, we motivate a set of criteria for framework comparison. Ultimately, we perform a formal comparison of web-based graphical editor frameworks.
2.1
Conceptual and Empirical Background
Our analysis of frameworks for the generation of EMF-compatible web-based graphical editors complements other surveys and comparisons on approaches that can help with the creation of graphical editors. Often, these frameworks are complete language workbenches (LWBs), that unite meta-modeling with the generation of the tool for the language. There are many studies that compare such LWBs [14, 15, 22] with respect to the features of the developed languages. Criteria for evaluating the functionality of LWBs have also been proposed [3]. 1
Göbel and Lämmel
Currently, many LWBs follow a Low Code approach. Its position towards MDE is studied in detail by DiRuscio et al. [12]. Popov et al. [33] compare the extendability of Low Code development platforms. A stronger focus on frameworks for graphical modeling exists on UX-based taxonomies like that of DeCarlo et al. [9], which they used for developing an GLSP enhancement [8], or the classification of graph-like modeling languages with respect to layouting by Wrobel and Scheffler [39]. In addition to analyzing frameworks, it is instructive to examine reports from developers who have built concrete graphical editors using these technologies. Most helpful are comparisons, like that of Sirius and Graphiti for the development of a graphical editor for EMF models [38]. Recently, Ali et al. [1] described the development of an EMF-based modeling tool at Rolls-Royce and compared their experiences with Sirius and GLSP. They reported openly on success factors and obstacles that made them prefer GLSP over Sirius. A tool to mine user interactions in Sirius- and GLSP- based model editing tools [10] enables comparison in terms of editor UX. Kolovos et al. [24] study the usage of EMF technologies on open source frameworks, assessing its rich adoption.
2.2
architecture using the Language Server Protocol (LSP): a server maintains and manipulates the model, while the client renders a graphical view and forwards user commands. This architecture is particularly attractive when external model management is required or when multiple compatible editors (e.g., a desktop and a web version) must be supported. Features such as undo/redo and the rendering of validation problems come naturally with the LSP-based design. GLSP is actively developed, but its complexity and the limited availability of up-to-date documentation and examples have been noted in recent evaluations [1, 31]. GLSP offers two server implementations: one in Java and one in NodeJS. The Java server can operate directly on EMF models, whereas the NodeJS server requires developers to provide a TypeScript-based JSON model implementation, thereby moving responsibility for EMF-level consistency guarantees to the developer. Due to its higher resource requirements, the Java server is often discouraged in practice, although it remains part of the official starter templates [17]. On the client side, templates exist for Eclipse Theia, Eclipse RCP, and VS Code, as well as a pure TypeScript client. While some integration notes suggest that both server and client could theoretically run in a browser environment [17, 30], no concrete examples exist, and the NodeJS-based server is fundamentally designed for server-side execution.
Framework Architectures: Sirius, GLSP, Gentleman
To understand the architectural landscape of EMF-compatible graphical editors, we examine three frameworks: Sirius and GLSP as the two established and widely used approaches for EMF-based graphical modeling, and Gentleman, which represents the only fully client-side, serverless architecture in the current landscape. Together, these three frameworks illustrate the main architectural options that motivate the criteria introduced in the next subsection.
Gentleman. Gentleman is, to our knowledge, the only framework in the current landscape that achieves a fully client-side, serverless execution model. It is implemented entirely in JavaScript and can be embedded into any JavaScript- or TypeScript-based web page. Architecturally, Gentleman is a projectional language workbench: instead of providing a dedicated graphical modeling canvas, it renders editors using HTML elements and CSS. This makes it suitable for lightweight projectional editors but limits its applicability for detailed graphical modeling. Gentleman offers an experimental mapping from Ecore to its internal meta-model, but the mapping covers only basic concepts and does not preserve EMF’s structural semantics; the resulting models cannot be imported back into EMF. Gentleman therefore targets a different class of modeling tools and serves primarily as a reference point for browser-only deployment rather than EMF interoperability.
Sirius and SiriusWeb. Sirius [26, 36] is EMF’s classical framework for generating graphical editors for EMF models. As a low-code framework, its graphical representations are defined largely through configuration rather than code. This approach simplifies editor creation but also constrains expressiveness: although Sirius uses SVG as its graphical basis, it provides only a small set of predefined diagram types (such as a generic graph layout, a sequence diagram, or a Gantt chart). Mixing different layout paradigms within a single representation is not supported. Despite these limitations, Sirius has a long tradition in the Eclipse ecosystem and is widely used in teaching and industrial MDE settings [2, 18, 29, 35]. Over the years, it has been extended with additional generation mechanisms [4] and support for annotated meta-models [34]. SiriusWeb [19] ports the Sirius concepts to a modern web technology stack in a server-centric architecture: a SpringBoot-based Java backend maintains the EMF model and evaluates AQL expressions, while a React frontend renders the graphical view. This design keeps most editing logic on the server, making serverless deployment impossible.
2.3
Criteria-based Evaluation
The analysis in the previous subsection highlights recurring architectural and technological themes across existing web-based graphical modeling frameworks. Based on these observations, we derive the following criteria for EMF-compatible, extensible clientside graphical modeling frameworks: • Ecore Compatibility: Whether a framework can work directly with an existing Ecore meta-model in a way that preserves EMF’s meta-level semantics (e.g., containment, opposites, multiplicities), either natively or through a conversion step. Why it matters: Translating an Ecore meta-model into another meta-language introduces cognitive overhead and risks semantic drift, making it harder to maintain alignment with EMF-based tooling and developer expectations.
GLSP. The Graphical Language Server Platform (GLSP) [5, 6] takes a fundamentally different approach from low-code frameworks like Sirius. Rather than providing predefined diagram types or configuration-based abstractions, GLSP offers a protocol-centric 2
Web-Native Graphical EMF Model Editors
• Model-level EMF Compatibility: Whether the concrete models produced by the editor can be serialized and deserialized in EMF-native formats. Why it matters: EMF-native persistence is required to integrate with existing toolchains. • Developer Constraints: Architectural or tooling restrictions that shape how developers must implement, extend, or integrate the editor, such as protocol layers (e.g., LSP), mandatory view-model mappings, or low-code abstractions that limit direct control. Why it matters: Such constraints restrict how freely developers can implement custom behavior, integrate existing code, or shape the editor’s interaction and update mechanisms. • Execution and Deployment Model: Whether the framework runs purely client-side or requires a server, and what infrastructure is needed for hosting. Why it matters: Serverbased frameworks require continuous compute resources and operational infrastructure, whereas client-only deployments can be hosted as static assets, which are widely supported by low-cost or free hosting services. • Technology Stack: The client- and server-side technologies developers must adopt, such as specific web frameworks, languages, or build systems. Why it matters: These requirements determine the skills developers must have and the effort needed to integrate the framework into existing architectures and workflows. • Graphical Basis: The rendering approach a framework uses for diagrams, and whether developers draw directly in the browser or through an intermediate protocol or view model. Why it matters: The rendering foundation determines how much control developers have over visuals and interaction, and how deeply the editor can be customized.
As a consequence of the landscape analysis, the following design principles emerge for frameworks aiming to provide a fully client-side, EMF-compatible graphical web editor: • Preserve EMF Semantics at the Meta-Model Level: The editor should use a fully EMF-compatible internal metamodel, ensuring that EMF’s structural semantics remain intact. • Support EMF-Native Persistence: Concrete models should be readable and writable in EMF-native formats to integrate with existing EMF toolchains. • Avoid Mandatory Architectural Constraints: Frameworks should not impose protocol layers (e.g., LSP), custom view-model mappings, or low-code abstractions that restrict developer control. • Enable Fully Client-Side Execution: A modeling framework should support serverless deployment as static web assets without requiring a backend runtime. • Use a Standard Web Technology Stack: The framework should integrate naturally with mainstream web development ecosystems without requiring specialized runtimes or IDE platforms. • Provide a Direct, Standards-Compliant SVG Rendering Layer: The graphical basis should be expressive, standard-compliant, and directly programmable, without intermediate protocols or hidden rendering layers. SVG is preferable over HTML-based rendering because it offers richer graphical expressiveness and native support for shapes and transformations.
3
We shortly illustrate the extension points and architectural constraints of the general-purpose web development framework Angular onto which EMFular is built. We then position EMFular within an established reference architecture for web-based modeling tools. This allows us to assess EMFular not in isolation, but in relation to a widely accepted decomposition of responsibilities across core model management, diagramming, and tool-level functionality. Once this architectural context is established, we show how EMFular implements these layers through a set of lightweight, client-side packages that conform to Angular’s idioms and together form a coherent and extensible foundation for EMF-compatible web editors.
We now apply these criteria to the set of frameworks discussed in the recent informal comparison by Metin and Bork [31], who contrasted their GLSP framework with several other web-based graphical modeling tools, namely AToMPM [37], WebGME [27], CINCO Cloud [32], KIELER [23], jjodel [7, 11], Gentleman [13, 25], Dandelion [28]). We omit PictoWeb [40] because it provides model visualization but no editing capabilities and add GLSP in its two server variants, Java and NodeJS, since these differ fundamentally in their meta-model integration and EMF compatibility. The resulting comparison is shown in Table 1.
2.4
The EMFular Framework
Answer to RQ1: Landscape Analysis
3.1
Overall, the comparison shows that web-based modeling frameworks differ substantially in their architectural assumptions, deployment requirements, and support for EMF-based workflows. None of the established frameworks combine full EMF compatibility — meaning generation from an EMF meta-model, preservation of structural semantics, and import and export of models for use in existing EMF workflows — with a cost-efficient serverless deployment model and the expressive power of an SVG-based web editor. These findings indicate a need for an approach that preserves EMF’s structural semantics, operates entirely client-side, and remains fully customizable within mainstream web development ecosystems.
Angular Concepts for Extensible Editors
Angular is a mature open-source web application framework developed by Google. It provides a component-based architecture in which applications are composed of services and components implemented in TypeScript. Services encapsulate shared logic or state, such as model access, command execution, or file management. They expose typed methods or observable event streams and are injected into other parts of the application through Angular’s dependency-injection system. Observables and subscriptions allow services and components to exchange state and notify each other of changes without relying on global variables or tightly coupled interfaces. 3
Göbel and Lämmel
Tool
Meta-Model with EMF Semantics
EMF-native Read/Write
Developer Constraints
GLSP (Java)
EMF full EMF semantics
EMF (XMI)
LSP
GLSP (Node)
custom JSON no EMF semantics
no EMF
LSP custom view-model
EMF (XMI)
low-code
React
no EMF
low-code
NodeJS
no EMF
low-code
JS (pure or NodeJS)
EMF (XMI)
LSP low-code
EMF (XMI)
LSP
EMF planned
low-code
React
NodeJS
no EMF
low-code
JS
–
HTML
EMF import (lossy)
low-code
React
NodeJS
?
Sirius Web AToMPM WebGME
CINCO Cloud
KIELER jjodel Gentleman Dandelion
EMF full semantics simplified UML partial semantics GME meta-model partial semantics EMF full semantics S (none) or EMF (full semantics) JOM no EMF semantics UML-like partial semantics graph-based (RDF) no EMF semantics
Client Tech TS (pure or NodeJS) or Eclipse Theia/RCP or VSCode TS (pure or NodeJS) or Eclipse Theia/RCP or VSCode
Eclipse Theia or VSCode via Angular NodeJS or VSCode
Server Tech
Graphical Basis
Java
SVG (Sprotty)
NodeJS
SVG (Sprotty)
SpringBoot (Java) NodeJS and Python
SVG SVG
NodeJS
SVG (Raphael)
Java
SVG (Sprotty)
Java
SVG (Sprotty) HTML (JSX)
Table 1: Comparison of Web-based Modeling Frameworks along the defined criteria.
Components build on services by adding a visual representation. A component consists of a TypeScript class, an optional stylesheet, and a template that defines its rendered structure. Components communicate through typed inputs and outputs: inputs supply data or context, while outputs emit events that surrounding components or services can subscribe to. This enables reusable UI elements whose behavior can be customized by their embedding context. Component templates are typically written in HTML, but Angular also supports SVG templates, allowing components to render graphical content directly inside an <svg> element. This makes Angular suitable for diagrammatic editors in which visual elements are represented as SVG groups. Angular further supports content projection, where a component declares slots into which other components or templates can be inserted. This mechanism applies equally to HTML and SVG templates and enables complex visual structures to be composed from smaller, reusable building blocks. Together, these concepts—services, components with HTML or SVG templates, input/output communication and subscriptions, content projection, and dependency injection—form the technical foundation on which EMFular ’s extensibility mechanisms are built.
3.2
responsibilities and APIs, and together they define the conceptual building blocks required for interactive, model-driven editors. While the reference architecture is presented in the context of LSP-based systems, its separation into Core, Diagram, and Tool layers generalizes naturally to modeling tools that do not rely on an LSP backend, in which case the responsibilities typically delegated to the language server — such as model-based CRUD operations and consistency management—must be implemented directly within the client-side editor. These concerns are usually handled in the Core and Tool layers, which assume a broader role in maintaining model state and ensuring consistency. As a result, the architecture remains applicable beyond LSP-based systems, with a shifted distribution of responsibilities: • Core provides the fundamental model management capabilities. This includes model state, containment and reference semantics, command handling, and the APIs through which higher layers create, modify, and query model elements. • Diagram offers the visualization and interaction facilities required to present models graphically. This layer typically includes shape definitions, layout, selection, and the mapping between model elements and their visual representations. • Tool comprises the user-facing editor functionality such as palettes, inspectors, creation logic, and integration with surrounding application frameworks. It builds on the services of the Core and Diagram layers to provide a complete editing experience.
Reference Architecture for Web-Based Modeling Tools
Metin and Bork [31] propose a reference architecture that structures LSP- and web-based modeling tools into three layers: Core, Diagram, and Tool on top of the LSP. Each layer groups a distinct set of
We use this architecture as the conceptual frame for describing the structure of EMFular. 4
Web-Native Graphical EMF Model Editors
Figure 1: Megamodel of EMFular
3.3
Architecture of EMFular
such components, the library provides explicit notions of graphical identity and position, together with a lightweight notification mechanism that emits movement events whenever an element changes its position. These assumptions enable a consistent interaction model in which connectors and arrows can attach to elements by their graphical ID and update automatically when those elements move. Building on these contracts, EMFular-Diagram contributes reusable SVG components, a two-layer dragging mechanism, and adaptive connectors that subscribe to movement notifications, forming a minimal but expressive foundation for constructing SVG-based diagrams in Angular.
EMFular consists of three independent libraries, EMFular-Core, EMFular-Diagram, and EMFular-Tool: each of them addresses one layer of the reference architecture. They fulfill the respective responsibilities without coupling, basically by a small set of assumptions that using projects must fulfill. EMFular-Integration relies on these assumptions to assemble the layer-specific libraries into ready-to-use editor components that can be embedded directly into an application or extended through Angular’s component and service mechanisms. All libraries are published as open-source packages and distributed via the JS standard package manager npm, enabling modular adoption and integration into existing applications. Figure 1 summarizes the architecture of EMFular in a megamodel [16].
EMFular-Tool: Generic Modeling Utilities. EMFular-Tool assumes that the final editor operates on a canvas — HTML or SVG — that should be exportable as SVG, PNG, and JPEG, and that it maintains some JSON-serializable model whose structure is not known in advance. Based on these assumptions, the library provides generic file I/O utilities for loading and saving text and JSON files, exporting canvas content, and integrating these operations with the browser’s download facilities. A lightweight history mechanism
EMFular-Diagram: SVG-based Components. EMFular-Diagram encourages that an editor renders its graphical content on an SVG canvas and that this canvas is populated with small, reusable Angular components whose templates are written in SVG. To support 5
Göbel and Lämmel
stores arbitrary JSON snapshots in a circular buffer and persists them in localStorage, enabling undo/redo and session recovery without making any assumptions about the meaning or schema of the stored data. These utilities abstract the tool-level functionality commonly required in web-based editors into idiomatic Angular services and components, while remaining entirely independent of EMF semantics or diagramming concerns.
A stateful model-management service supplies the editor shell with the current model instance, integrates the history mechanism for undo and redo, and exposes a simple API for creating, loading, and saving models. This service forms the operational backbone of the editor: all components interact with the same model state, and applications can refine the workflow by extending the service without modifying the editor shell itself. Beyond the shell, EMFular-Integration offers a small set of ready-to-use SVG components and interaction services for constructing tree-based graphical editors for EMF-models. These components render containment hierarchies as nested SVG boxes and provide matching interaction services for selection, navigation, and assignment. While intentionally model-agnostic, they form a practical foundation from which applications can build richer, domain-specific visualizations.
EMFular-Core: Runtime and Persistence. EMFular-Core is a pure TypeScript library that provides EMF-style model semantics without depending on Angular or any UI framework, making it usable in other TypeScript-based environments such as Node.js or React. Its purpose is to expose models through a developer-facing API that behaves like ordinary TypeScript objects with explicit attributes and references, while internally guaranteeing the strong consistency constraints of EMF. At the developer level, model classes declare their structure explicitly: attributes are ordinary TypeScript fields, and references appear as single-valued or list-valued properties of the target type. Behind this familiar API, however, each reference is backed by a lightweight proxy that forwards all mutating operations to a hidden layer of containers, selected according to EMF-style metadata attached to the reference declaration. These containers implement the semantics of EMF references — containment, bidirectional opposites, deletion cascades — and ensure that all modifications preserve the invariants of a well-formed EMF object graph. Convenience methods for reordering lists and deleting elements recursively complement the developer-facing API. In this way, the declarative structure of the model and the runtime semantics that enforce EMF-style consistency remain cleanly separated yet tightly connected. For persistence, EMFular-Core adopts EMF-Jackson, EMF’s native JSON-based serialization format, ensuring direct interoperability with existing EMF workflows. Its JSON structure is web-native and permissive, allowing applications to persist additional information alongside the structural model without breaking compatibility. Serialization is driven directly by the attribute and reference declarations of a model class: any field marked with the attribute decorator is written to JSON without requiring changes to the metamodel, which makes it straightforward to persist additional information such as layout or positions. Reference serialization is delegated to the containers, which produce nested JSON for containment references and EMF-Jackson URI-fragment strings for cross-references. Deserialization reconstructs attributes and the containment hierarchy in a first pass and resolves all cross-references in a second, yielding a fully consistent EMF object graph.
3.4
Answer to RQ2: Framework Adequacy
The EMFular framework provides the essential capabilities expected from EMF-based model editors. Its core data layer supports EMF-compatible object graphs with attributes, references, containment, opposites, and deletion cascades, ensuring that editing operations preserve EMF semantics. Editors built on top of the framework can create, inspect, navigate, and modify models uniformly, and the integrated history mechanism offers undo and redo at the level of model operations. Persistence is handled through EMF-Jackson, enabling EMF-native JSON serialization without custom formats. The architecture exposes metadata and extension points to integrate structural checks (validation). EMFular imposes no mandatory protocol layers or low-code abstractions; it is implemented entirely in standard web technologies and executes fully client-side as static assets. Its rendering layer is based on direct, standards-compliant SVG, which Angular’s component mechanism encapsulates into reusable building blocks. Taken together, these properties show that EMFular meets all six criteria and is adequate for building interactive EMF-style web editors without additional infrastructure.
4
The EMFular-Generator
The EMFular-Generator consumes a single Ecore meta-model and produces a corresponding initial web editor as a stand-alone Angular project that depends solely on the EMFular packages available via npm. The generated project exposes all editor logic directly in Angular components and services, without additional protocols or specialized tooling, giving developers an immediately usable and fully transparent starting point for further extension.
EMFular-Integration: Ready-to-Use Editor Components. EMFular-Integration is the only package that depends on all others. It assembles EMFular-Core, EMFular-Diagram, and EMFular-Tool into a set of ready-to-use, model-agnostic editor components that can be embedded directly or extended through Angular’s component and service mechanisms. Building on JSON-serializable EMFular-Core models and an SVG-based canvas, its central element is an extensible editor shell that provides a file-level bar with standard model operations (load, save, export, undo/redo), a central SVG canvas with a projection slot for model-specific visualizations, and an optional model-editing bar that applications can populate with domain-specific creation or layout actions.
4.1
Generator Architecture and Workflow
The generator follows a simple two-stage workflow, shown in Figure 2. First, it processes the input Ecore model and extracts a uniform JSON representation that contains the structural information needed for code generation.
4.2
Template-based Generation
Before generation begins, the user is asked to select a root class from the set of applicable EClasses. This root determines the serialization root and thus the top-level element that the generated editor 6
Web-Native Graphical EMF Model Editors
Ecore File (single .ecore)
Atlantic Zoo has revealed some issues such as usage of subpackages requiring more refined treatment and name clashes between metamodel elements and EMFular requiring resolution. These issues are being addressed.
Ecore Parser extracts EPackage produces JSON meta-model
User selects root class
4.4
Our experiments indicate that EMFular-Generator can produce working web editors for real-world Ecore models without modelspecific tailoring. The generator behaves deterministically—identical input models and root selections yield identical projects—and the architecture scales to metamodels with substantial size, depth, reference structures, and inheritance hierarchies. Although development is ongoing and some issues were identified during testing, the generator already handles both classical EMF examples and large, nested metamodels such as the IFC schema.
Template Engine Angular workspace templates domain TS classes editor and model service
Generated Angular Application uses EMFular via npm fully modifiable deterministic output
5
Customization
Beyond generating a functional baseline editor, practical modeling tools must support adaptation to domain-specific notations, workflows, and integration needs. Customization is therefore a central aspect of evaluating EMFular’s capabilities: it determines whether the generated editors can be meaningfully extended, and whether such extensions remain maintainable. In this section, we first identify general customization dimensions for graphical model editors, then describe how EMFular realizes these capabilities, and finally demonstrate the customization process using a concrete example.
Figure 2: Generation pipeline of the EMFular-Generator: parsing the Ecore model, selecting a root class, and instantiating templates to produce the Angular project.
loads, displays, and persists. In the second stage, the generator then instantiates a set of templates to assemble the Angular project. Figure 3 illustrates how the generator assembles a complete Angular project from its internal template structure. The left side shows the generator’s template folders, grouped into model-agnostic layers (yellow) and a model-specific layer. The latter is divided into two parts: a faithful replication of the Ecore meta-model as TypeScript classes together with a corresponding JSON meta-model (blue), and editor-level templates (green) that integrate this model information into the generated editor and its services. The model-agnostic layer (yellow) is identical for all generated editors, aside from trivial adaptations such as the project name. The model-specific layer (blue) reflects the detailed structure of the given Ecore model and therefore scales with model size. The editor templates (green) depend on both the model and the user-selected root class: they generate one creation command per concrete class, register palette entries, and configure the editor’s state and history management. Although larger models lead to more creation commands and palette entries, the editor layer itself always consists of the same Angular primitives: an editor component and two accompanying model-level services.
4.3
Answer to RQ3: Generator Robustness
5.1
Customization Requirements for Graphical Model Editors
Graphical modeling editors must accommodate a wide range of domain- and workflow-specific needs. Across existing low-code modeling frameworks like Sirius or AToMPM, several recurring customization dimensions have emerged that shape both the expressiveness of the resulting editors and the effort required to adapt them. These dimensions form a general baseline of expectations against which any modeling framework or generator must be evaluated. • General look and feel. Modeling tools are often embedded into larger ecosystems and therefore require control over visual appearance, including color schemes, typography, layout structure, and branding. Such adaptations ensure visual coherence with existing tools and support usability requirements specific to the target domain. • Graphical representation of model elements. A core requirement is fine-grained control over how model concepts are visualized: which elements appear as nodes or edges, their styling, how they are grouped or layered, and which layout strategies govern their spatial arrangement. These decisions strongly influence the readability and semantic adequacy of the resulting diagrams. • Domain-specific perspectives and workflows. Many modeling scenarios rely on multiple (complementary) views of the same underlying model. These perspectives emphasize different subsets of concepts, provide tailored visual
Validation
Several end-to-end tests, using models of different size and structure, were performed. These tests consist of uploading an .ecore file, selecting a root class, unpacking the generated workspace, installing its dependencies via npm install, and launching the editor using ng serve. The generator handles both classical examples (such as ecore.ecore) and large real-world models, including the IFC schema with nearly 700 EClasses, 7 EDataTypes and 164 EEnums. Thus, the workflow is functional and the generation- and web-based approach can handle large and nested metamodels. Exhaustive and fully automated testing with the Ecore models of 7
Göbel and Lämmel
Figure 3: Correspondence between the generator templates and the generated project
models, palettes or toolbars, and guide users through workflowspecific tasks. Supporting such perspectives requires extensibility for several graphical model representations, configurable interaction points, navigation structures, and editing hooks. • Integration of external libraries and services. Modern modeling environments frequently incorporate external components such as layout engines, visualization toolkits, validation frameworks, or domain-specific UI widgets. Effective customization therefore requires well-defined integration points that allow such libraries to be introduced without modifying the underlying platform.
5.2
Customization Capabilities in EMFular
EMFular is built on top of Angular and therefore inherits the framework’s extensibility mechanisms—component templates (HTML and SVG), typed input/output bindings, and content projection—as introduced in Section 3.1. These mechanisms form the basis on which EMFular realizes the customization dimensions identified above. The EMFular-Generator produces a complete, idiomatic Angular workspace that includes the domain model, a stateful model service, and a minimal initial editor. Although a ready-to-use tree component is available in the EMFular-Integration package, the generator deliberately reconstructs it inside the generated project. This replayed construction exposes the relevant extension points directly to the developer. 8
• General look and feel. Since the generated editor is a standard Angular application, its visual appearance can be adapted using familiar mechanisms such as CSS, Angular Material theming, and template modification. Developers can adjust layout structure, typography, color schemes, and branding by editing ordinary components and style sheets, ensuring seamless integration into existing web applications or corporate design systems. • Graphical representation of model elements. EMFular encourages a component-based approach to graphical modeling: each model element can be associated with a dedicated Angular component whose template defines its visual representation, and whose inputs and outputs open natural extension points to insert state and context or receive outputs on user-triggered events. To give developers complete control over all aspects of a visualization, EMFular strongly recommends the use of SVG templates for these components. SVG components can be composed, nested, and grouped in the same way as HTML components, but offer far richer control over shapes, layering, and spatial arrangement—essentially everything that the SVG standard can express. EMFular supports this style of modeling through the EMFular-Diagram package, which provides reusable building blocks for common diagramming tasks such as text placement, bounding boxes, and drag handles, while leaving the overall structure and notation entirely under the developer’s control.
Web-Native Graphical EMF Model Editors
• Domain-specific perspectives and workflows. Perspectives in EMFular are Angular components that render the model—or the relevant subset of it—using either HTML or SVG templates. HTML-based perspectives support formoriented or inspector-style workflows, while SVG-based perspectives enable graphical modeling. The generated tree-based editor serves as an example of an SVG-based perspective: it is a standard HTML component that contains an <svg> element as its main modeling area and exposes a content-projection slot for inserting the root component of a domain-specific SVG-based visualization. This allows the perspective to define the overall interaction frame—such as selection handling, toolbars, or navigation structures—while delegating the actual rendering of model elements to the projected component hierarchy. Additional perspectives can be introduced by providing alternative components that reuse the same model service, and standard Angular interaction patterns (e.g., modal dialogs, detail views, or workflow-specific commands) can be integrated naturally since perspectives are ordinary components embedded in the surrounding application. • Integration of external libraries and services. The generated workspace follows Angular’s dependency-injection conventions, making it straightforward to integrate external visualization libraries, layout engines, validation frameworks, or domain-specific UI widgets. New services can be registered alongside or in place of generated ones, and the component-based architecture ensures that external functionality can be introduced without modifying the generator or the core framework libraries.
in small commits, is available in an anonymized repository.1 A live instance of the customized editor, deployed via GitHub Pages from the same repository, is also available for interactive exploration.2 The required modifications to the generated editor are small and localized. They fall into a few clearly separated areas: • Model-level adaptations. The generated Person class already contains stubs for its derived features, mother and father, that we implement, using the stateful reference parents. We also add a helper to set father and mother, that falls back to parents as well. Two simple predicates (isMan, isWoman) are introduced to support a unified graphical component for persons. • Domain-specific SVG components. The graphical notation is implemented using a single domain-specific Person component that renders individuals, selects the appropriate icon, and visualizes father and mother relationships as colored arrows. This component is instantiated for each model element by a lightweight Family component, which iterates over all persons. By replacing the projection of the default svg-tree component with that of the family, the whole view is adapted. • Positioning and layout persistence. We support dragbased person positioning through EMFular’s SVG utilities for dragging and arrow routing. To persist the resulting layout, we store each person’s position as a model attribute rather than component state and mark it for serialization. This ensures that the graphical arrangement is saved with the model and restored on load, providing stable, modellevel layout metadata. As an alternative to manual positioning, we integrate the ELK layouting engine as a small Angular service. Invoking this service from a button on the model-specific panel computes a fresh layout for the current model and updates the stored bounding boxes accordingly. This demonstrates how external libraries can be incorporated with minimal effort through Angular’s dependency-injection mechanism. • Interaction adaptations. The graphical PersonComponent does not prescribe any interaction behaviour; instead, it simply exposes user events (such as click and double-click) to its surrounding editor. Each perspective interprets these events independently: the SVG-based perspective opens a domain-specific modal for editing names and parent relationships on single click, while the HTML-based details view updates on double click. Because the graphical component itself remains unchanged, the same rendering logic can be reused across perspectives and editors and integrated into different workflows with minimal effort.
Together, these mechanisms allow EMFular-based editors to realize the full customization space identified in the previous subsection while remaining entirely within idiomatic Angular development practices.
5.3
Example: Extending the BasicFamily Editor
To illustrate the customization mechanisms described above, we replay two well-known Sirius tutorials of the BasicFamily metamodel. Starting from the generated EMFular editor—which provides the model service, the tree-based perspective, and the surrounding application shell—we first replace the default SVG tree perspective by implementing the graphical notation from the Sirius Starter Tutorial using domain-specific SVG components. We then add an HTMLbased details perspective corresponding to the Sirius Compartments Tutorial, opened via a double-click on a family member and presenting detailed information in a form-oriented view. The editor also retains the single-click modal interaction from the generated tree-based perspective, which is used here to change names and assign parents. This illustrates that workflow-specific interactions can be adapted or extended using standard Angular components and services. Fig. 4 illustrates the resulting editor for the BasicFamily metamodel, combining an SVG-based graphical perspective and an HTML-based details perspective. The complete source code of the extended editor, showing its evolvement from the generated project
5.4
Answer to RQ4: Editor Adaptability
EMFular-based editors support all four established customization dimensions through the ordinary extension mechanisms of Angular. Visual appearance and layout can be adapted by modifying the top-level components and style sheets; graphical notations are defined by domain-specific SVG components with full control over 1 https://github.com/emfular-demos/basicfamily-ge 2 https://emfular-demos.github.io/basicfamily-ge/
9
Göbel and Lämmel
Figure 4: Customized BasicFamily editor with SVG-based modeling canvas (top) and HTML-based details view (bottom)
rendering and clear interaction points via exposed user events; perspectives and workflows are introduced as additional Angular components that reuse the shared model service and bind to the outputs of graphical components; and external libraries integrate cleanly through dependency injection. The BasicFamily case study shows that such customizations require only small, localized changes to the generated project, indicating that EMFular enables expressive editor adaptations with modest and predictable development effort.
6
EMFular offers a lightweight, purely client-side alternative for creating editors that preserve EMF semantics without requiring any backend. It provides the essential capabilities for EMF-compatible editing — creation, inspection, navigation, modification, and undo/redo — while exposing clear extension points for validation. The accompanying EMFular-Generator further reduces developer effort by producing an initial tree-based editor with explicit extension points directly from an uploaded Ecore file. Editors generated in this way remain fully modifiable Angular applications and can be customized along the established dimensions of model-editor variability. These results demonstrate that a browser-native, EMF-compatible modeling stack is both feasible and effective. Future work will focus on strengthening validation support and extending the generator to cover more complex metamodel constructs such as sub-packages, further maturing EMFular and its generator into a robust foundation for web-based modeling tools.
Conclusion
As our landscape analysis shows, EMF-compatible, semanticspreserving graphical editors are currently only available through heavy Java-based server infrastructures that execute an EMF runtime and impose additional development constraints through lowcode abstractions or protocol layers such as LSP. 10
Web-Native Graphical EMF Model Editors
Engineering Languages and Systems: Companion Proceedings, MODELS 2022, Montreal, Quebec, Canada, October 23-28, 2022, Thomas Kühn and Vasco Sousa (Eds.). ACM, 46–50. doi:10.1145/3550356.3559092 [14] Sebastian Erdweg, Tijs van der Storm, Markus Völter, Meinte Boersma, Remi Bosman, William Cook, Albert Gerritsen, Angelo Hulshout, Steven Kelly, Alex Loh, Gabriël Konat, Pedro Molina, Martin Palatnik, Risto Pohjonen, Eugen Schindler, Klemens Schindler, Riccardo Solmi, Vlad Vergu, Eelco Visser, and Jimi Woning. 2013. The State Of The Art In Language Workbenches. Conclusions From The Language Workbench Challenge. In Proccedings of the 6th International Conference on Software Language Engineering, SLE 2013, Vol. 8225. doi:10.1007/978-3-319-02654-1_11 [15] Sebastian Erdweg, Tijs van der Storm, Markus Völter, Laurence Tratt, Remi Bosman, William R. Cook, Albert Gerritsen, Angelo Hulshout, Steven Kelly, Alex Loh, Gabriël Konat, Pedro J. Molina, Martin Palatnik, Risto Pohjonen, Eugen Schindler, Klemens Schindler, Riccardo Solmi, Vlad Vergu, Eelco Visser, Kevin van der Vlist, Guido Wachsmuth, and Jimi van der Woning. 2015. Evaluating and comparing language workbenches: Existing results and benchmarks for the future. Computer Languages, Systems & Structures 44 (2015), 24–47. doi:10.1016/ j.cl.2015.08.007 Special issue on the 6th and 7th International Conference on Software Language Engineering (SLE 2013 and SLE 2014). [16] Jean-Marie Favre, Ralf Lämmel, and Andrei Varanovich. 2012. Modeling the Linguistic Architecture of Software Products. In Model Driven Engineering Languages and Systems - 15th International Conference, MODELS 2012, Innsbruck, Austria, September 30-October 5, 2012. Proceedings (LNCS), Robert B. France, Jürgen Kazmeier, Ruth Breu, and Colin Atkinson (Eds.). Springer, 151–167. doi:10.1007/978-3-642-33666-9_11 [17] Eclipse Foundation. 2025. GLSP Documentation. https://eclipse.dev/glsp/ documentation [18] Sebastian Friedl, Christian von Arnim, Armin Lechler, and Alexander Verl. 2020. Generation of OPC UA Companion Specification with Eclipse Modeling Framework. In 2020 16th IEEE International Conference on Factory Communication Systems (WFCS). 1–7. doi:10.1109/WFCS47810.2020.9114448 [19] Théo Giraudet, Mélanie Bats, Arnaud Blouin, Benoît Combemale, and PierreCharles David. 2024. Sirius Web: Insights in Language Workbenches – An Experience Report. Journal of Object Technology 23, 1 (2024), 1–20. doi:10.5381/ jot.2024.23.1.a6 OPEN REGULAR ISSUE. [20] Susanne Göbel and Ralf Lämmel. 2024. Model-Based Trust Analysis of LLM Conversations. In Proceedings of the ACM/IEEE 27th International Conference on Model Driven Engineering Languages and Systems (Linz, Austria) (MODELS Companion ’24). Association for Computing Machinery, New York, NY, USA, 602–610. doi:10.1145/3652620.3687809 [21] S. Göbel, J. Zöllner, J. Dohmen, R. Lämmel, and H. Pätzold. 2026. Interaktion mit KI im Kontext organisationaler Entscheidungen: Vertrauen als Ergebnis reflektierter Wissensauswahl. In 7. Jahrbuch der DGfE-Sektion Organisationspädagogik: Organisation & Digitalität. DGfE. [22] Aníbal Iung, João Carbonell, Luciano Marchezan, Elder Rodrigues, Maicon Bernardino, Fabio Paulo Basso, and Bruno Medeiros. 2020. Systematic mapping study on domain-specific language development tools. Empirical Softw. Engg. 25, 5 (Sept. 2020), 4205–4249. doi:10.1007/s10664-020-09872-1 [23] Sven Jäger, Ralph Maschotta, Tino Jungebloud, Alexander Wichmann, and Armin Zimmermann. 2016. Creation of domain-specific languages for executable system models with the Eclipse Modeling Project. In 2016 Annual IEEE Systems Conference (SysCon). 1–8. doi:10.1109/SYSCON.2016.7490558 [24] Dimitrios S Kolovos, Nicholas Drivalos Matragkas, Ioannis Korkontzelos, Sophia Ananiadou, and Richard F Paige. 2015. Assessing the Use of Eclipse MDE Technologies in Open-Source Software Projects. OSS4MDE@ MoDELS 1541 (2015), 20–29. [25] Louis-Edouard Lafontant and Eugene Syriani. 2025. Modeling with Gentleman: a web-based projectional editor. Softw. Syst. Model. 24, 2 (2025), 523–551. doi:10. 1007/S10270-024-01219-4 [26] Frédéric Madiot and Marc Paganelli. 2015. Eclipse Sirius Demonstration. P&D@ MoDELS 1554 (2015), 9–11. [27] Miklós Maróti, Tamás Kecskés, Róbert Kereskényi, Péter Völgyesi, Brian Broll, Tamás Levendovszky, and Akos Ledeczi. 2014. Next Generation (Meta)Modeling: Web- and Cloud-Based Collaborative Tool Infrastructure. In Proceedings of the 8th Workshop on Multi-Paradigm Modeling (MPM@MODELS 2014) (CEUR Workshop Proceedings, Vol. 1237), D. Balasubramanian, C. Jacquet, P. Van Gorp, et al. (Eds.). CEUR-WS.org, Valencia, Spain, 41–60. https://ceur-ws.org/Vol-1237/ [28] Francisco Martínez-Lasaca, Pablo Díez, Esther Guerra, and Juan de Lara. 2023. Dandelion: A scalable, cloud-based graphical language workbench for industrial low-code development. J. Comput. Lang. 76 (2023), 101217. doi:10.1016/J.COLA. 2023.101217 [29] Ralph Maschotta, Sven Jäger, and Armin Zimmermann. 2016. Teaching model driven architecture approach with the sirius project. In European Conference of Software Engineering Education (ECSEE 2016). [30] Haydar Metin and Dominik Bork. 2023. On developing and operating GLSPbased web modeling tools: lessons learned from bigUML. In 2023 ACM/IEEE 26th International Conference on Model Driven Engineering Languages and Systems
Over the last 18 months, EMFular evolved in parallel to our DSML, KEML [20]3 , for which we required an EMF-based fully client-side editor. Because EMFular-based editors run directly in the browser without any installation effort, we were able to conduct ad-hoc experiments with non-technical students [21], which would have been impractical with desktop-based tooling. These studies not only informed the evolution of KEML itself but also provided usability insights into general editor interaction patterns that we fed back into EMFular. As more users apply EMFular to their own DSMLs, their feedback and recurring usage patterns will guide the next development steps and support a broader ecosystem of browser-native EMF-compatible editors across diverse domains.
References [1] Qurat ul ain Ali, Dimitris Kolovos, Antonio Garcia-Dominguez, Michael Bennett, Joe Newton, and Piotr Zacharzewski. 2024. Advancing Domain-Specific HighIntegrity Model-Based Tools: Insights and Future Pathways. In Proceedings of the ACM/IEEE 27th International Conference on Model Driven Engineering Languages and Systems (Linz, Austria) (MODELS ’24). Association for Computing Machinery, New York, NY, USA, 104–113. doi:10.1145/3640310.3674094 [2] Dajana Antanasijević, Sonja Ristić, Marko Vještica, Darko Stefanović, Vladimir Dimitrieski, and Milan Pisarić. 2023. A Prototype of a Domain-Specific Modeling Language for Formal Specification of a Human Worker. Acta Electrotechnica et Informatica 23, 2 (2023), 33–40. doi:10.2478/aei-2023-0010 [3] Mikhail Barash. 2021. Vision: the next 700 language workbenches. In SLE ’21: 14th ACM SIGPLAN International Conference on Software Language Engineering, Chicago, IL, USA, October 17 - 18, 2021, Eelco Visser, Dimitris S. Kolovos, and Emma Söderberg (Eds.). ACM, 16–21. doi:10.1145/3486608.3486907 [4] Francesco Bedini, Ralph Maschotta, and Armin Zimmermann. 2021. A generative Approach for creating Eclipse Sirius Editors for generic Systems. In 2021 IEEE International Systems Conference (SysCon). 1–8. doi:10.1109/SysCon48628.2021. 9447062 [5] Dominik Bork and Philip Langer. 2023. Language server protocol: An introduction to the protocol, its use, and adoption for web modeling tools. Enterprise Modelling and Information Systems Architectures (EMISAJ) 18 (2023), 9:1–16. [6] Dominik Bork, Philip Langer, and Tobias Ortmayr. 2023. A vision for flexible glsp-based web modeling tools. In IFIP Working Conference on The Practice of Enterprise Modeling. Springer, 109–124. [7] Antonio Bucchiarone, Juri Rocco, Damiano Vincenzo, and Alfonso Pierantonio. 2025. Modeling in Jjodel: towards bridging complexity and usability in modeldriven engineering. Software and Systems Modeling (10 2025), 1–25. doi:10.1007/ s10270-025-01324-y [8] Giuliano De Carlo, Philip Langer, and Dominik Bork. 2022. Advanced visualization and interaction in GLSP-based web modeling: realizing semantic zoom and off-screen elements. In Proceedings of the 25th International Conference on Model Driven Engineering Languages and Systems (Montreal, Quebec, Canada) (MODELS ’22). Association for Computing Machinery, New York, NY, USA, 221–231. doi:10.1145/3550355.3552412 [9] Giuliano De Carlo, Philip Langer, and Dominik Bork. 2022. Rethinking Model Representation - A Taxonomy of Advanced Information Visualization in Conceptual Modeling. In Conceptual Modeling: 41st International Conference, ER 2022, Hyderabad, India, October 17–20, 2022, Proceedings (Hyderabad, India). SpringerVerlag, Berlin, Heidelberg, 35–51. doi:10.1007/978-3-031-17995-2_3 [10] MohammadHadi Dehghani, Luca Berardinelli, and Manuel Wimmer. 2023. Towards Modeling Process Mining for Graphical Editors. In 2023 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C). 929–933. doi:10.1109/MODELS-C59198.2023.00146 [11] Juri Di Rocco, Davide Di Ruscio, Amleto Di Salle, Damiano Di Vincenzo, Alfonso Pierantonio, and Giordano Tinella. 2023. jjodel – A Reflective Cloud-Based Modeling Framework . In 2023 ACM/IEEE International Conference on Model Driven Engineering Languages and Systems Companion (MODELS-C). IEEE Computer Society, Los Alamitos, CA, USA, 55–59. doi:10.1109/MODELS-C59198.2023.00019 [12] Davide Di Ruscio, Dimitris Kolovos, Juan de Lara, Alfonso Pierantonio, Massimo Tisi, and Manuel Wimmer. 2022. Low-code development and model-driven engineering: Two sides of the same coin? Softw. Syst. Model. 21, 2 (April 2022), 437–446. doi:10.1007/s10270-021-00970-2 [13] Aurélien Ducoin and Eugene Syriani. 2022. Graphical projectional editing in gentleman. In Proceedings of the 25th International Conference on Model Driven 3 https://keml-group.github.io/web-editor/ for editor access, repository https://github.
com/keml-group/keml.web 11
Göbel and Lämmel
(MODELS). IEEE, 129–139. [31] Haydar Metin and Dominik Bork. 2025. A reference architecture for the development of GLSP-based web modeling tools. Software and Systems Modeling (2025), 1–27. [32] Stefan Naujokat, Michael Lybecait, Dawid Kopetzki, and Bernhard Steffen. 2018. CINCO: a simplicity-driven approach to full generation of domain-specific graphical modeling tools. Int. J. Softw. Tools Technol. Transf. 20, 3 (June 2018), 327–354. doi:10.1007/s10009-017-0453-6 [33] Gregory Popov, Joan Lu, and Vladimir Vishnyakov. 2024. Toward Extensible Low-Code Development Platforms. In Advances in Emerging Information and Communication Technology, Asadullah Shaikh, Abdullah Alghamdi, Qing Tan, and Ibrahiem M. M. El Emary (Eds.). Springer Nature Switzerland, Cham, 487– 497. [34] Nathan Richardson, Dimitris Kolovos, and Antonio Garcia-Dominguez. 2024. Aconite: Towards Generating Sirius-Based Graphical Editors from Annotated Metamodels. In Proceedings of the 17th ACM SIGPLAN International Conference on Software Language Engineering (Pasadena, CA, USA) (SLE ’24). Association for Computing Machinery, New York, NY, USA, 16–28. doi:10.1145/3687997.3695642 [35] Avi Shaked. 2022. PROVE Tool: A tool for designing and analyzing process descriptions. Software Impacts 12 (2022), 100234. doi:10.1016/j.simpa.2022.100234
[36] Eclipse Sirius. 2023. Sirius. https://eclipse.dev/sirius/. Last Accessed: 12.03.2025. [37] Eugene Syriani, Hans Vangheluwe, Raphael Mannadiar, Conner Hansen, Simon Van Mierlo, and Huseyin Ergin. 2013. AToMPM: A Web-based Modeling Environment. In Joint Proceedings of MODELS’13 Invited Talks, Demonstration Session, Poster Session, and ACM Student Research Competition (CEUR Workshop Proceedings, Vol. 1115), Y. Liu, S. Zschaler, B. Baudry, et al. (Eds.). CEUR-WS.org, Miami, USA, 21–25. https://ceur-ws.org/Vol-1115/ [38] Vladimir Vujovic, Mirjana Maksimovic, and Branko Perisic. 2014. Comparative analysis of DSM Graphical Editor frameworks: Graphiti vs. Sirius. In ERK2014. 7–10. [39] Gregor Wrobel and Robert Scheffler. 2023. Classification for the Concrete Syntax of Graph-Like Modeling Languages. SN Computer Science 4 (02 2023). doi:10. 1007/s42979-022-01574-3 [40] Alfa Yohannis, Dimitris Kolovos, Antonio García-Domínguez, and Carlos Javier Fernández Candel. 2022. Picto web: a tool for complex model exploration. In Proceedings of the 25th International Conference on Model Driven Engineering Languages and Systems: Companion Proceedings (Montreal, Quebec, Canada) (MODELS ’22). Association for Computing Machinery, New York, NY, USA, 56–60. doi:10.1145/3550356.3559094
12