05/16/09 :: [MOP] The MoDISCO Project (ModelPlex) [permalink]
This week-end I discovered the MoDisco project (Eclipse).
MoDisco (for Model Discovery) is an Eclipse-GMT project for model-driven reverse engineering. The objective is to allow practical extractions of models from legacy systems. Because of the widely different nature and technological heterogeneity of legacy systems, there are several different ways to extract models from such systems. MoDisco proposes a generic and extensible metamodel-driven approach to model discovery.
MoDisco is part of the ModelPlex European project (MODELling solution for comPLEX software systems) and not surprisingly, Jean Bezivin is participating.
In many ways, I wonder how Microsoft can compete against Eclipse. It should have joined the Eclipse organization years ago and it could benefit today from all kinds of modeling technologies that it will never ever be in the position to develop. Microsoft has Software Factories and DSL Tools and nothing else (Oslo will be coming some day). It has not built any significant community around these assets and most likely will not be able to build any community. Once it falls behind in MDE, it will not be able to catch up and this will have dire consequences for its overall strategy. What the folks in Redmond don't seem to realize is that Modeling is "technology agnostic". It is no longer about Java vs .Net, once you understand what Metamodel Oriented Programming is, you realize that there won't be any room for a Microsoft's version of MOP. Ironically, Microsoft was one of the first to MOP around way back in the early 2000s. But it got out control, because they never understood they were MOPing one attribute at a time. Microsoft, could have positioned itself to compete advantageously on creating interpreters and compilers for MOP and deliver the best engines in the industry (and it certainly could do that if it wanted to), but if they don't even understand what Metamodel Oriented Programming is, so how could they build an MDE community and a customer base? The amount of IP that Microsoft is leaving to others to land grab is just staggering.
This paragraph, of course, begs the question: what are Oracle, Amazon and Google doing about MOP? Oracle seems to be in better shape than the others Fusion is polyadic and they are rewriting all their apps with it. Amazon, I think, does not realize how critical MOP can be to the Cloud and probably thinks it can afford to play below the MOP layer. Google, well, I am sure they think that Protocol Buffers can solve any problem known to man. Google seems to be deeply rooted in the monadic tribe and anyone there seems to be ready to reify everything and anything behind a class and occasionally a resource or an (Atom) feed. You could even argue that Google seems to drive towards an anemic monadic programming paradigm. When all you do is "search", you probably don't care much about cogency and polyadism. I did not mention SAP, but you guessed it, I am sure someone there is going to conclude that ABAP was MOP-ready before anyone and therefore they should continue the course and ABAP happily ever after.
What I find interesting too is that Europe seems to be way ahead of the US in MDE.
Now, I must admit that I had in mind something like MoDisco once MOP would be a bit more formalized. It seems like a natural progression, once you understand that when we write write code we have in mind a cogent DSL as part of a polyadic programming model, however we only have the constructs of a monadic programming model to do that. What it means is that most code is full of patterns (explicit or not) that can be de-reified into a cogent DSL. De-reify, ah! what a word. I have started a couple of weeks ago to see how traditional patterns play into Metamodel Oriented Programming. If all goes well, and MOP really can do what I claim it can do, these patterns should disappear from the cogent-DSLs (in general). Some new pattern may appear, but the goal of MOP is really to program without the need for patterns, this is the role of the DSL and the resulting polyadic programming model.
For instance, if we take a look at creational patterns, e.g. the Abstract Factory Pattern, we see that a cogent-DSL should abstract the need of having to use this pattern in the cogent-DSL itself (not in the interpreter or the code generation tool that process the c-DSL into an executable). If we go back to my 3 element DSL example, we can see that an Element1 instance has the ability to manipulate Element3 instances. Element3 is stereotyped with a resource lifecycle.
This means that an Element1's operation can do this kind of thing (but remember it cannot manipulate Element2s):
void myOperation()
{
Element3 r = new Element3();
...
//do some stuff with it
r.&Element3(); //move r into an archive state
...
//well we can't do much now that it is in an archive state
r.~Element3(); //Delete the resource
}
How does the abstract factory pattern play here? Well, remember that the goal of MOP is to enable Architecture Refactoring so when you say new Element3(); you actually specify that you need a new element, you just don't know how this will happen. Now, some code might we written in the Element3() constructor or it might be entirely virtual and resolved at the "Architecture Factoring" time, using in effect an abstract factory pattern (or not). What MOP gives you is an opportunity to completely separate the business logic that is specific to the solution (and written in the constructor implementation) from what is specific to the architecture (which is using the Abstract Factory pattern for instance).
It works the other way around too: you can easily detect Abstract Factory patterns in a given code base and you can de-reify them into a c-DSL following MOP principles. One of the most important thing to realize in this de-reification process is that DSL elements have a lifecycle and that lifecycle must be de-reified from the code. If you don't do that, the de-reification process might not succeed because some intermediary actions (such as "archive" in the example above, noted &Element3()) might not easily fit in the cogent-DSL or even be detectable from the de-reificator.
Today I remain convinced that the next decade will be the Model-Driven-Engineering decade, or more exactly the MOP decade. As I said, everyone is MOPing today, and has been for quite sometime, like Mr. Jourdain, unbeknownst. So, I don't feel any kind of ownership for MOP, I am just trying to formalize what everybody is doing in an architecture independent way. Sure there are still a few die-hard monadics who think they can build any kind of solution with just X or no more than Y. These guys will spend the rest of their lives deriving all kinds of patterns and coupling or cohesion rules. They'll write countless book and articles describing their witchcraft, while trying to sell their "knowledge" at a hefty premium. So what? I don't think it will be really hard to convince the 99.99% of us -the polyadics- who just want to do their job in a sensible way that they need to bring some structure into what they have been doing for well over a decade now. Just tell me which company in the world would not want to express the solutions it is using (business, industrial,...) in an architecture independent way? Just give me one... Can you imagine? there is even the prospect to de-reify billions of lines of code into cogent-DSL? Who would say no to that?