Missing clear figure about the various language definition "styles"

[dvojtise]

seeing the various questions from most users (such as https://github.com/gemoc/gemoc-studio/issues/59, but also from other more experienced GEMOC users)

We need a clear synthetic map of the various ways to define the DSL that we can expose in the documentation.

Ideally, it should:

• point to the relevant documentations, tutorials, and examples
• provide some pro and cons (or link to implementation detail discussion)

as we have several variants, I'm not sure that a single table is enough, maybe we need some kind of variability model and appropriate doc generation tooling.

current draft variants:

• engine variants:

  • sequential with K3 + Melange
  • sequential with K3 only (ie. without Melange; similarly to early version of Gemoc)
  • sequential with ALE
  • sequential with Xmof
  • concurrent with ECL + K3
  • engine compilation (experimental)

• language definition: (let's discuss about the names :wink: )

  • Build mode, an original ecore, is used to create another ecore file, all the editor and animator are built on top of the resulting ecore (the one generated in the runtime language),the original one is withdrawn.
  • Model conversion mode, the original ecore is maintained and declared as an "external language" , a new language will extends it in order to declare all the runtime aspects (structure and behavior), the editor is built on top of the original ecore, the animator is built on the ecore of the generated runtime language. This uses Melange resource in order to transform model instances from base metamodel to executable metamodel on the fly.
  • Model adaptation mode, the original ecore is maintained and declared as an "external language" , a new language will extends it in order to declare all the runtime aspects (structure and behavior), the editor is built on top of the original ecore, the animator is built on the ecore of the Model type (MT). This uses Melange resource in order to transform model instances from base metamodel to executable metamodel on the fly. (see https://github.com/eclipse/gemoc-studio-modeldebugging/issues/27).
  • degraded variant of the 2 first options: some aspects can be defined on top of an "external" language, ie. only aspects that do not changes the ecore signature. So you can have an ecore that declares all the methods and runtime data, then use k3 to implement the behavior.

Some requirements to consider:

• need support for User events
• need support for legacy code (in the animator, in the engine semantics)
• need support for language coordination
• need support for trace (multidimensionnal, multibranch)