Raise your level of abstraction
Hello! every one, I have some questions about the term “model-driven”
I noted that a change for the subject of ECMFA from Model-Based Engineering (until the sixth in 2010) become to Model-Driven Engineering (the seventh in 2011).
Is there any background story about this?
Model-Driven = The model *is* the source
Model-Based = The model is an important asset but is not the source
Model-Driven = Model-Centric
Model-Based = Model-Oriented
IMHO, of course!
For instance, ABSE is a Model-Driven software development approach, because the ABSE tree (model) really is the source, and the actual [C++/Java/PHP/etc] source code is completely disposable (because it can be regenerated any time).
I do not know whether I understood that you say. I think, “The model *is* the source”, so, it must be implemented that takes transforming automatically in all steps of development. We may lose a lot of profits from models if we have to read and understand the “models” artificially at certain steps – thus the exact models either graphical or textual (e.g. in UML) maybe not better than the “models” writing or drawing on papers by hand.
I just tried to differentiate terms that probably mean the same thing. For instance, I named my approach ABSE, meaning "Atom-Based Software Engineering"... But why not ABSD (Atom-Based Software Development), or ADSE ("Atom-Driven Software Engineering"), or.... you get the point. "ABSE" was just a choice, and most people just choose their favorite way of naming a modeling approach: "driven", "based", "centric". So I tend to agree with what Andreas said: "just a habit only".
"I think, “The model *is* the source”, so, it must be implemented that takes transforming automatically in all steps of development.We may lose a lot of profits from models if we have to read and understand the “models” artificially at certain steps [...]"
Why not? A tool that "enforces" modeling and transformation rules removes most of the ambiguity resulting from human interpretation of a model. Source code has no ambiguity. Why should a model be different?
I read the introduction of your ABSE. I think it is an excellent implementation of authentic MDSE with full code-generation. I like such tools/platforms.
I emphasized “We may lose a lot of profits from models if ...” which is not to criticize such works. I want to emphasize some predicament. Some intermediate state of MDSD maybe unpleasant. It is not only has to realize code-generation completed, and also has to take test, round-trip, government, and so on to become full model-driven way.
However, they still have to face the problems just as CASE in 1980's (I saw a discussion by D. C. Schmidt, 2006), and the fundamental proposition I thought that: the ambiguity and change is the intrinsic nature to the requirements of applications – it is not to be removed or eliminated. Thus the applications themselves has to become change-able at run-time. This is an essential requirement from the real world.
I read at the link. It is a good summary and I have the same considers such as you graphic, the relation between MDE and MBE. It is very clear in the discuss about the question “Is there any software develpment that is not MBE?” but I want to know is it the reason for the change from MBE to MDE at the ECMFA?
However, I still have the questions. In communities or the MDSE, MDE/MBE, or software development, is there some definitions or discusses for the term model-driven (without architecture, development, etc.)? or it is recognized that the driven is just transformation (automatically)? or it is considered that the execution and interpretation of modes are also the approaches “driven”？
> ... definition to the term “model-driven”...
> ... based ... centric ... oriented ... just a habit only?
I have no detailed historic insight in who coined the term in person, but my observations concerning the usage of the term "model-driven" are as follows: I think it became popular because people wanted to avoid the negative connotations of "generating code" which originated from 90'ies early approaches. In the late 90'ies, early 2000 "code generation" was considered a kind of anti-pattern. Then MDA arose, at first wih a rather modest claim ("there are transformations, but MDA permits as well human as automated ones"), and during the '00es it became slightly a kind of synonym for a "modern, nevertheless very complicated approach", so people tried to avoid it too, and the "MD" prefix somehow took on the meaning of "the fresh new approach of code generation, kind of CG 2.0". The seek for terms continued (and under the surface the seek for better solutions, too), all the "MDx" terms poiting to a lively, but a little confused field.
While during the '00es the seek for terms was mainly marketing driven, today we're confronted with a new generation of actually better tools, the seek for better and more sharp terms reflects this maturity in the language.
The diagram seems plausible to me. I wonder what he implications are. Is it better to be in the middle or to be outside? As an example, MDD vs MDA, it might be an advantage to rely on MOF based models, but MDA conformity does not imply fully automated transformations; so a one-step MDD approach with a non-MOF model but fully automated is possibly of greater value to the customer alltogehter.
I think the terms are neither optimal for marketing use (then they should be more positive) nor for expert communication (because they are not clear enough). For the latter maybe we should used "MOF-based", "Fully automated" and the like. Or what about "100% code generation"? It doesn' mean anyhting, if I do not clearly say how my model looks like. A model "<MyCode>here comes the code</MyCode>" allow surely 100% generation, but it's not what we want.