“execution element” may not be the best name. The basic idea behind MOP is that OO methods are an example of “execution element” in the OO metamodel. Take a metamodel, you can “add” execution elements anywhere you want (where it makes sense of course). The next question what do you write in these execution elements? Well, you have the usual control structures of course, the basic data types and then, this is where the lifecycle of metamodel elements come to play. In OO, an object instance has a lifecycle, created, deleted, garbage collected,… Basically you can come up with any lifecycle that makes sense to you.

MOP provides a blueprint to create cogent polyadic programming languages. DSLs and general purpose languages are very particular cases of these programming languages and frankly far less useful. MOP bridges GPLs and DSLs.

See, the problem with OO is that people need the polyadism. 15 years ago it was not clear. Add SOA, the Web, BI, BAM, … and you start seeing annotations everywhere, in essence OO is becoming polyadic. Actually, OO is polyadic .Net, Java -all- have added polyadism, unfortunately without truly understanding the implications of polyadism. The last problem to solve is “how do you express behavior in a polyadic world?”. You guessed it, with OO you are limited to the Object lifecycle, -declarative- annotations have no way to express behavior correctly. You can say “start” or “stop” this service.

So turn the OO model around like a sleeve and look at its structure (metamodel) and create a cogent polyadic meta-metamodel (that’s what I call MAF -MetaArchitecture Framework). Voila. OO is just a cogent monadic language, it’s good, it’s great, we all have done incredible things with it but add polyadism… and let’s talk again.

JJ-

Not yet. However I will release a white paper with ABSE’s specification/formalisms. I am determined to have a working proof-of-concept (AtomWeaver, the ABSE IDE) at the same time this whitepaper is released.

Time is a (very) limited resource!

I am glad ABSE conforms to your specification!

ABSE’s meta-metamodel, the Atom, does not rely on a DSL. Instead, it uses a general-purpose language and a library/framework. I think we can compare this to core classes you mention. Then, each Atom can have properties and relations. What is missing on your analysis from ABSE is behavior: An Atom can act, run, and behave differently according to its parameters, relations, or global model settings. For instance, this makes it easy to create software product families.

Also, I can consider the four meta-levels as matching:

M3 : Atom, ABSE’s meta-metamodel
M2 : Atom Templates, created following the rules of Atom
M1 : Atom Instances, created by instantiating Atom Templates
M0 : Generated Artifacts, created by executing Atom Instances

In conclusion, you made a very good overall analysis of the current MDSD methodologies!

Your claim about implicit life-cycles in OO and the necessity to make them explicit seems sensible to me in some scenarios.

On the other hand, you are also asserting that OO is not the correct foundation for doing MDE because something else is missing.
So, in your opinion, what are the missing parts we need to fix it?

>> The M0 level for SOA is the running system containing the traces
With all due respect, that does not fit your definition of M1/M0. At best, I would say that in SOA M1 could be the contract level and M0 the service implementation, but that’s not fitting very well the M levels of MDA.

Personally, my conclusion is that MDA was designed with OO in mind without looking any further. Hence MDA is flawed. I can see how M3/M2/M1 fit well. As soon as you are stepping into the runtime, you have to be careful on how you articulate the relationship between the model and the execution.

Our industry is so conservative that we never question anything even as new evidence show that ideas that were thought to be “universal” simply cannot account for modern architecture concepts.

>> anemic
this is a reference to DDD, I use it in the same sense.

>>the what” and avoid any details about “the how”
again, this is not the distinction, it is rather a question of anemic vs behavior or static vs dynamic. The dynamicity of the model cannot be escaped. It amounts to saying that Turing was wrong all along. Building systems abstracted from Turing is, IMHO, a huge, historical mistake for the MDE movement.

>>able to execute algorithms with a well defined execution rules
This is actually not what I describe in MOP. You seem to not see the difference between the lifecycle of the model elements (implied and constant in an OO system) and algorithms. Lots of people actually burry the lifecycle behind patterns and treat it as code. Again this is a huge and historical mistake for MDA, which is directly coming from the anchorage in OO. As soon as MDA/MDE will understand that OO is not the foundation of its architecture but OO should be built on top of an MDA/MDE, then we will see MDA and MDE bloom like we have seen nothing before.

>> imperative executions semantics
again, this has nothing to do with imperative vs declarative. It has to do with dymanic vs static. The lifecycle of the model elements cannot be ignored or buried in the code generator or code interpretor. It has to surface at the same level as the model itself.

JJ

To my understanding, as M0 represents the reality level, also SOA has an M0 layer. We could make this layer emerge if needed. In SOA, services are modeled in an M1 layer, that’s true. The M0 level for SOA is the running system containing the traces of real execution of services. Such traces could contain the service already executed (or in execution), the values of the parameters/messages already passed, timestamps, IP of the machine executing the service, etc.

Business Activity Monitoring products (BAM), for example, work with these assets tracking these executions and triggering new actions to fire Business Alerts.

On the other hand, instead of referring to pure structural models, as anemic (that sounds to me a bit pejorative), I prefer to call it just declarative models or declarative DSLs.
Declarative DSLs like SQL, OCL, HTML, or Prolog have one nice virtue: they focus on describing “the what” and avoid any details about “the how”.

This virtue, to be purely declarative, is exactly what allows a runtime engine to apply optimizations to an SQL query, for example, or to optimize a rendering in HTML.

Of course, your definition of Cogent DSL can help to transform a model into another level of refinement. But to me, this rings a bell in my mind and looks to me quite near to an imperative language approach (an abstract one, but an imperative language at the end, like Java, Pascal or Javascript able to execute algorithms with a well defined execution rules).

When generating declarative conceptual models, I prefer to isolate the transformations, from the input and output model/DSLs. And maintain the models pure (or anemic, if you prefer).
Again, when describing the transformation, it can be expressed using a declarative formalism or a imperative one (anemic or cogent in your terminology, if I understood it well).

On the other hand, I agree with you, that if you are going to capture an algorithm, a workflow, a process, etc. where the execution order and steps are the specification itself (as Service requires), then you will need a predefined imperative executions semantics when modeling, that also has to be preserved till reaching the runtime layer.

Thanks JJ for sharing your impressions and generating debate.

I would also argue that:

>> Take the following concepts: entity, attribute and
>> relation. These are more than enough to create your basic
>> meta-meta-model.

is leading to anemic metamodels (see my article here: http://www.infoq.com/articles/mop) and anemic metamodels are not as useful as the cogent kind.