Skip to content
Sebi1006 edited this page Jun 25, 2021 · 13 revisions

The structure of the architecture is shown in the following figure. The first part (INPUT) represents user input, which is mainly done by the four DSLs (style, shape, diagram, concept). These defined components are eventually used as an input of the Zeta generator which subsequently is responsible for producing artefacts of the new graphical editor. The main part here takes place in the frontend. The user can design the structure of his own graphic editor here. The second part (GENERATOR) takes place entirely in the backend. Here, the graphic editor is generated by a complex set of rules using the previously defined DSLs. The third part (OUTPUT) is the domain-specific graphic DSL. For example, BPMN, EPK or petri nets can be created or new user-defined modeling tools.

Zeta Architecture

The graphical definition of a model has advantages which has already been discussed in literature. These advantages are reflected especially in complex models. The presented approach generates a JSON structure derived from the graphical metamodel. The generated JSON file has a notable size even for simple metamodels.

Technical Overview

The following figure shows a technical overview of the Zeta architecture.

Zeta Architecture Overview

Class Diagram (Concept Editor)

These classes are building the core functionality of the concept editor. JavaScript classes which are mainly holding data are represented by cylinders. Arrows define the line of actions. For example, to export a graph, app.js has to create a new exporter. The exporter creates an exported metamodel and fills it with information from graph.js. Event triggers are handled by different classes. The switch of focus for example is processed by properties.js.

Zeta Architecture 2

The following illustration shows the yZeta architecture.

yZeta Architecture

Lastly, the Zeta frontend architecture is shown in the figure below.

Zeta Frontend Architecture