SysML/KerML as Modelling Languages for Ecore based tools

In Model-based / Model-Driven based tooling, the Eclipse Modeling Framework EMF was very influential. It is a very comprehensive framework that covers a plethora of use cases and can be easily extended to add new use cases. Although it seems to be loosing a bit of traction with many parties moving to Python or web-based tech stacks and reinventing the wheel, it still plays a role in many frameworks.

In the GAIA-X lighthouse project COOPERANTS we are using the in-house systems engineering tool of one of our project partners as a collaborative platform for multi-party systems engineering. Although that tool is not EMF-based, it uses the EMF based "Ecore"-format to define its meta-model.

The creation of the ecore is often done with one of these approaches in the EMF community:

• Direct editing with Ecore-Tooling (not the greatest user experience)
• Transforming an UML model to Ecore, based on a profile (e.g. with Magicdraw or Papyrus)
• Textual Definition with the XCore tools, which provide a textual DSL for creating the artifacts
• Deriving the model from an Xtext grammar.

I personally like the XCore approach, since it is a nice user experience with a lean tooling. However, since the systems engineering community is adopting SysML v2 as a standard including a textual notation, why not have a look at that? So in the last weeks of COOPERANTS we started adopting KerML as modelling language for space metamodels.

Basic Modelling

The SysML Pilot implementation comes with an example for an addressbook that illustrates that it is well suited also for data modelling:

A simple KerML textual notation to .ecore generator is written in a few hours. The major challenge is understanding the new meta-model and navigating through the model hierarchy (finding right way to get multiplicities and feature values) was one thing.

KerML extension mechanisms / metadata

But code generation / model transformation often needs additional data to define specifics of the target model, which are not direct model concepts in the source model. In the modelling of Ecore with UML we might have used stereotypes / tagged values. These concepts did not find there way into SysML v2. But SysML v2 has the concept of meta-data, which we use to define some aspects required to configure a full .ecore:

Now we can augment our address book model to include additional information for the generated target ecore

Now we are able to configure our systems engineering's tool meta-model based on KerML and use .ecore as a standard interface / configuration file to configure the model.