Hello Strumenta community,
More than a year ago, I was mentioning in my introduction post that I was wondering if there was any low-code platform on the market that was embracing some of the standards from MDD / MDE.
Working on the evolution of my company internal low-code platform, I’m currently considering formalising our meta-model using something more standard than our in-house approach.
By more standard, I refer to EMF (as the only EMOF implementation I’m aware of), and using (or creating) one of the library mentioned in Polyglot Modeling/Metamodeling formats and frameworks - #29 by ftomassetti
In my recent research on this topic, and particularly on this forum, I came upon the fact that Mendix (particularly @meinte.boersma and @jos.warmer 
) has given some thoughts on its meta-model, even exposing a Model SDK (documented on their website).
This is the only example of an actual “public” (but not relying on a standard?) approach I could find.
Do you know of any other example in the low-code / rapid-application development industry?
3 Likes
I do not know of other examples, but I am for sue interested in hearing more.
By the way, JetBrains MPS has a similar approach to EMF with some variations. Basically, the meta-metamodel of MPS is simplers (for example references can only have multiplicity up to 1).
From what I have heard MetaEdit+ is doing something slightly different because they have richer relationships, I think. Perhaps they support properties on relationships. @juha-pekka could perhaps tell us more
2 Likes
Tools tend to apply their own metamodeling languages (e.g. State of the Art article by Erdweg et al. as fewer seems to use some “standard” like MOF/EMF alone. Reasons could be that something more is needed for a complete language definition covering also constraints and concrete syntax or that tool implementers have not found “standard” solutions adequate. To my knowledge, the most covering comparison of metamodeling languages is Kern et al.
When it comes to industrial use, MetaEdit+ is a commercial tool (I work for this company) and we provide a domain-specific language that was built already from the start to target language definition (=metamodeling). As @ftomassetti mentioned, we support properties for relationships, but also properties for roles, and even to ports in case language uses such. Figure below shows an overview, but there are also manuals for all details. It is based on other work done in the industrial settings, most importantly what MetaSystems Ltd did.
1 Like
Thank you @juha-pekka for the literature review!
I had forgotten about the LWC paper from 2013 even though we participated in the challenge with Generative Objects (and @walter.almeida)!
Another and recent paper on metamodeling related tools is a survey paper: “What do practitioners expect from the meta-modeling tools?”. It is interesting as touches current users views.
1 Like
As @juha-pekka already said: tools tend to apply their own [meta-]metamodeling languages.
At Mendix, Jos created a meta meta DSL called MxCore to meta-model the Mendix modeling language. I implemented an export to EMF from that, but that hasn’t been released publicly - for obvious commercial reasons, I guess. It was necessary to make MxCore instead of going with EMF directly because the Mendix modeling language was grown “organically” by an organization where only few people had an idea about language engineering.
So, MxCore captures the core concepts emerging from the implementation as it was at the time. The immediate goal of MxCore was to explicitly meta-model the Mendix language and then generate source code from the meta model, for the desktop (C#) resp. Web (TypeScript) modelers. Because of that, it made much more sense to first capture the existing meta-concepts, before contemplating migrating to EMF - which never happened.
As long as the meta meta languages used are equivalent(/“isomorphic”) in some way, I don’t really see a problem with this. And as sketched above: sometimes there’s legacy. Of course, being able to use an existing standard like EMF has obvious advantages, even if the target platform isn’t Java.
1 Like
In my view, most platforms calling themselves “low code platforms” are pretty limited as they propose their own model to represent an application that is set in stone and cannot be changed by users.
This way, the low code platforms are restricted to generate the type of applications they were designed for, naming : data driven management applications. Yes they allow to address any functional domain, but no, they don’t allow to create any type of application.
Another limitation of most low code platforms (I say most because I don’t know them all, but I imagine it be close to all of them) is that they are limited to create applications following their technological stack and architecture, which is a big barrier to adoption for IT Departments.
Low code platforms in general are not workbenches or model driven environments as such, but merely specific out of the shelf platforms designed for a specific task, and to be used as such.
What I believe we need is a new “meta low code” approach, new generation of low code platforms, combining the business user friendliness of low code platforms with the versality of a true model driven approach.
This is what I am doing with Generative Objects (GO), and this is built into the product since inception. Until now, GO was used as a classical low code platform externally and as a meta platform internally to GO, but I have now finalized all the wiring to actually offer the meta side of the platform to users. And I am just now am about to package and finalize the first open source “Meta low code” platform of history 
I have written a post describing the meta low code approach : Generative Objects (GO), introducing the Meta Low Code approach
