MDA/MDD: Model is not code!?
Following my post on round-tripping, a discussion raised again on “what is model?” on Think in models. Here I try to focus on why “model is not code” in an MDA/MDD context.
First of all, let’s define the investigation field:
- MDA/MDD: using models to generate (parts of) code with generators
- Model (in this context): a formal description of (part of) user requirements for an application
- Code: text understandable by a compiler on a platform to run the program that implements the application (note: code stands for source code+configuration files)
Now have a look on the matter from different viewpoints:
- Trivial standpoint:
As proposed in Is MDA the Holly Grail of Agile Manifesto?, in an MDA project model and generators are “source artifacts”.
The MDA equation is: code = generation(model) + non generated code- Is the model “understandable” by the compiler? Not. It is not built to be. So model is still not code.
- If we decide to call “generation()” a compiler, may the model be called code? Yes. We could call it meta-code in fact as generation() produces code. Eureka! Model is meta-code. Fine.
(but generation() is not a meta-compiler as 1) we called it a compiler, 2) it does not produces compilers!) - Is meta-code code? Yes meta-code is kind of code, but not of the same order as THE application code.
Why should we boring with meta-thing? Sounds complex and not pragmatic, neither the user nor the developer want to be bored with meta-things. So, stick to “model is not code”!
- Logical standpoint:
In MDA themodelis used to: 1) capture a structural organization of user requirements 2) help mapping this structure with an application logical architecture. In OMG’s MDA definition thismodelis called Platform Independent Model (PIM)(*).- So model is an extract of a theoretical model of business needs. Meanwhile code is something to be compiled to produce an application program. We clearly don’t speak of the same level of representation. Model is not code.
- What if the model is executable?… Why should it be? We don’t expect this from the model which describes user needs. Keep things simple. Model is still not code.
- Near the bounds:
- Original MDA goal is said to transform a Computational Independent Model (CIM) into executable code through successive models transformations: CIM > Platform Independent Model(PIM) > Platform Specific Model (PSM) > Code. What a Weird idea! Probably too much beer… ;D
- Executable models are another curiosity, raised in a tentative to build an Agile MDA approach. It even seems that Executable UML is still alive. Probably some survivors from the first MDA raft… ;D
But even this way, the model is still meta-code, or at least parameters. And real code pieces are hidden into transformation/generation rules.
Model is not code in real life for MDA/MDD. Not an absolute conclusion as we could have chosen other hypothesis. But this choice is for sure compliant with the KISS principle…
By the way, is MDA/MDD compliant with the KISS principle? Yeah. I’m sure. I’ll show it in another post ;D
(*) All successful MDA projects that I know use only PIM among the CIM>PIM>PSM>Code MDA’s canonical transformation chain
Featured image taken from http://www.redsen-consulting.com/2011/06/quelle-forme-pour-mon-modele/
23 comments on “MDA/MDD: Model is not code!?”
Leave a reply to vhanniet Cancel reply
IT Modernization < V. Hanniet by Vincent Hanniet is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
IT Modernization < V. Hanniet 
I do believe there is value in distinguishing model and code, probably in a non-absolute way. I suggested some signals for telling model an code apart here. So I am with you in your ultimate conclusion. I had trouble with how you got there though.
Some comments over your points (1-3):
1) models being well-formed and complete enough to be understandable by a compiler is a very good thing IMO, except you are talking about models for communication purposes.
2) models don’t exist only to represent user needs. I am more interested in models that describe (high-level, domain-centric) solutions that satisfy user needs (solution models). There is a lot of value if models are executable (see link above).
3a) There is no transformation step between CIM and PIM as the first is focused on requirements and the latter on solution. Traceability is useful though.
3b) There is nothing weird in automatically transforming a PIM to a PSM. And the PSM might as well be the 3GL code – there is no transformation from PSM to code (or to anything), only from PIM to PSM – the PSM in one step may become the PIM in the next (but in that context it is not a PSM). For example: UML -> C++, C++ -> Windows Executable.
3c) In executable UML, the core of your solution is in the model. Code generation deals with secondary concerns and architectural choices. It sounds weird to say the “real code” is in the transformation rules. Unless you already made your mind about what is real code. It is not as clear cut as that IMO. It is just a matter of using the best level of abstraction possible for describing a solution, and sometimes that is in the model, and sometimes that is in the transformation.
Cheers,
Rafael
Let me reverse the question: Code is not Model?!
Although in the perfect world (and in a purist MDE sense) I would say yes, several pragmatic issues make me think that it isn’t. More or less with the same arguments you have for the opposite question.
What do you think?
Marco —
Myself, I just don’t think “code” is the right thing to ask about. Rather, I think it is more interesting to ask “is a program a model?”
As I have said before, I would say that all programs are models. They are models of a desired computation that are detailed enough that that computation may be mechanically executed. (They may also be use to model some aspect of reality, as in OO design or simulation, but that is secondary to their purpose as programs.)
On the other hand, not all models are programs, because some models, by intent, are not detailed enough to be mechanically executed. Or they focus on modeling things that may not be computable (like requirements).
However, by definition, executable models are, well, executable (even if their intent is to model something else, too). Therefore, executable models are programs.
But are they code? They are if that is what you end up having to debug! 😉
Hi Ed,
you make a very good point here. I agree with you.
I would close the loop by saying the obvious: programs are much more than code.
To me, the most relevant aspect of programs is actually the algorithm they implement, not the code that compose them.
So, I agree that we should talk about programs and models, not code and models.
Going back to the model-program , let me just say that we are actually starting experimenting model debugging.
It might sound weird, but we are now allowing to debug your model in our toolsuite; which is something different than simulating and/or prototyping. You can really define typical debug concepts like breakpoints, variables, and so on in WebML models, and then run and debug the actual applications.
So, the border becomes more and more blurred.
Marco —
Model debugging is not at all weird! In fact, I think having good model-level debugging is critical for a real executable modeling environment, just as source-level debugging was critical for moving from assembly language to the current generation of high-level languages.
I believe that the Shlaer-Mellor tools (like BridgePoint) already provide such capabilities. More recently, the MagicDraw Simulation Toolkit, even though not currently targeted for production execution of models, provides a pretty complete debugger, including breakpoints, single stepping, etc, as, I believe, does the model execution environment in Rational Software Architect 8.
Once you really can create, run and debug you model all in one environment, it really is the program. And we are definitely getting there!
Ed –
Question: executable models are programs. Do you have any use of models of these executable models?
[Ed, Vincent, I’m replying here because I not able to reply to your most recent post, don’t know why].
@Ed: Thanks for the broad picture on model debugging, I wasn’t aware of so many well established solutions covering this.
Good to know, it’s always hard to be the first and struggle to convince customers on something disruptive :D.
Anyway, for the interested readers, WebRatio is actually implementing debugging on webml models (see the piece of news here).
@Vincent: out of the MDA context, the WebML domain specific models are both executable (in the sense that they have a completely specified semantics and the corresponding app can be 100% generated) and useful as models for documentation, specification, model transformation purposes.
Vincent —
I would certainly say that there are still models that are of great interest that are not programs and may not be executable. I may have requirements models, business process models, enterprise architecture models, conceptual models, and so forth. Some of these may be “executable” in the sense of simulation or enactment, but I don’t think I would consider any of them programs.
But I am not sure that I would see a lot of use in models “of” executable models, though. Rather, I may initially start with models that are only sketched out and then develop them incrementally into fully executable models. In this case, I wouldn’t say that the initial versions are “models of” the later versions — just earlier, not yet complete versions.
So, I would certainly say that there are models that are not programs, and these may be models of many things (requirements, concepts, processes, architecture) that are very relevant to what I want to program. But I would not say that they are “models of executable models”.
To be honest, I never really liked the idea of using UML to create “models of programs” anyway, even when those programs were in Java or whatever. In MDA terms, I liked to model at the PIM level, and just code at the PSM level. Now, what I used to model as a PIM for the “real” PSM/program may be able to be executed as the program in its own right. But there are still a lot of useful models, perhaps at what some would have called the CIM level, but which now become more like a PIM for the executable models.
This is all part of raising our level of abstraction for programming!
Hi! Ed,
Nice to see you here!
I agree that ‘programs’ is the right thing to ask with ‘models’, not ‘code’. More clearly, the ‘code’ is not the hyponym of ‘model’, there is not a ‘is-a’ relationship between models and code. This proposition is stronger than the “model is not code.” (I am not sure whether is it an error while the ‘model’ is a countable noun but ‘code’ is non?)
Furthermore, according your definition of models (2003), as you said here, perhaps, it can be stated as a program is a class of mode？
As you said, “programs are models”, and “executable models are programs”, thus, it seems there is a obvious conclusion that, the notion of executable modes is equal to the notion of programs?
If programs have code to implement, then the models, or the executable models at least, may also have code to implemnt. Thus, what are the differences between the code of models and programs?
Vincent —
To be honest, in the end, I think the issue of whether a “model is code” is kind of pointless. There seems to be this idea that there is an absolute concept of what “code” is and that the goal of programming is specifically to produce this “code”. In reality, this has never been the case: what is called “code” has changed over time, and the goal of programming is to provide a solution to an end user. Creating “code” is only a means to an end.
Way back in the 50’s when FORTRAN was created, it was called “automatic programming” (really!). So, one could have made the following argument then:
– Automatic programming: Using FORTRAN to generate (parts of) code using compilers.
– Program (in this context): A formal description of (part of) the mathematical computations for an application.
– Code: The instructions understandable by a computer in order to run the application.
So a FORTRAN program is not “code”!
There were even discussions in those days about whether you should modify the “code” that was produced by the compiler, or if you could really trust the compiler to produce good “code”!
Flash forward 50 some years, and, even with all our advances, we are still stuck with languages that are more or less at the same “third generation” level as FORTRAN. Perhaps executable modeling is at last a way to take a step up from that — hence the very parallel kinds of discussions about whether “a model is code”. Or maybe not.
But the reality is that an executable subset of UML can be made just as Turing complete as FORTRAN or any 3GL, and “model compilers” already exist (and are called such) that allow programming in models the same way one programs in a 3GL today — without regard to what comes out the other end of the compiler.
You may or may not think this is a good way to program. But, to me at least, such models are, indeed, “code”. (Well, maybe just for the next 50 years or so! 😉 )
@Rafael
1) Yes I’m speaking of models suitable for communication purpose AND usable for MDE purpose. In MDA they are compiled in some way, but this is not the primary purpose.
2) I agree. Models may be used for a lot of purposes and, again, an MDE tool is a kind of compiler and may produce runnable artifacts. In my MDA pragmatic target there is only one modeling level (PIM) which holds mainly business/functional notions.
3a) You’re right.
3b) In my MDA pragmatic target, PSM is not a model: it’s code that transforms model into code with help of code templates.
3c) The fact is that trying to distinguish model and code is a bit artificial and tedious, but write a compiler and you will see that 100% of the generated machine code is produced by the compiler. The compiled language is just parameters.
@Marco
I agree with you. And read Ed’s comment.
@Ed
Is the issue of code vs model pointless?
From a scientific standpoint, I agree. From a MDE business standpoint I don’t 🙂
I agree on the historical perspective, and I’m sure that “model compilers” and “model debuggers” already exist and are functional.
There are many good ways to program, it all depends on contexts and goals. My perspective, in this blog, is trying to explain how we can hope applying Model Driven Engineering approaches to better produce better programs right now.
“Modeling” is a proved available piece of solution to drastically improve needs formal expression, and “programming” a well known other one to build programs. Combining the two is not easy but feasible at an industrial scale… Provided we keep things as simple as possible.
Executable models are not, from this viewpoint, an acceptable all-purpose solution (I’ll try to explain why later)
Vincent —
I have done “industrial scale” model driven development more than once, and I agree that it is important to keep it simple — or, rather, to add more complexity only as that results in a demonstrable benefit. Indeed, I have done these projects without executable models and sometimes even without code generation at all. To my mind, the most important thing that discriminates “model driven” approaches is that the models become primary artifacts, however downstream artifacts are produced — and whether than means the models are “code” or not is really immaterial.
But it is exactly my experience with MDD that makes me really want to be able to do executable modeling. Going back to my historic analogy, the reason that FORTRAN was created was because, in the end, a compiler can translate mathematical expressions into machine code quicker and more accurately than a person can by hand. The same holds, I believe, for translating models into “code”.
@Rafael
I took time to read you post Productivity of UML. Very interesting as a resume of a bunch of points on the “modeling paradigm”. I will take more time to give my two cents!
Other discussion on this subject:
Executable UML – A misunderstanding of boundaries?
My conclusion on this subject… (unless brand new counter-arguments)
Regrettably, do not have read timely, I recently was sick.
This discussions has been so wonderful, it would be difficult to further expand here – because Ed Seidewitz be here, the level of the discussion has risen to the ultimate, based on the definitions in his paper (Seidewitz 2003) – unless to put forward more sophisticated, in-depth definitions of models, code or programs and so on, otherwise, it would be not easy to make the discussions more constructive.
However, I want to remark, the discussions is meaningful and significant, of course, not mainly among the ideas and practices already existing (such as the MDA/MDD even current MDE), but related to some of the problems, and more, it is about some of new possibilities, some of new ideas or technologies. They also already have certain good practice, yet has not been given sufficient attention, I think. 🙂
Pingback: The Sustainable MDA Manifesto: 1st draft « Vincent Hanniet * IT Modernization
Pingback: 模型、程序与代码：一些前提的澄清 | 企业工程论坛
Pingback: Models: Execution or More « THINK IN MODELS
“•What if the model is executable?… Why should it be? We don’t expect this from the model which describes user needs. Keep things simple. Model is still not code.”
This seems to be a statement of blind predjudice.
I have used executable modelling in a number of projects with great success. See:
Click to access re2008.pdf
It is not suitable for every project, but in some it is invaluable.
Ashley
Hi Ashley,
I agree with you that your “Protocol Modeling” approach, a way to simulate future system behavior by executing a requirements model, may be useful to clarify non technical requirements. And I also know people using this kind of approach with some success.
However, my post is focused on MDA and my point here was using models execution instead of models as specification for code development. In your paper model execution “just” help focusing on valid requirements… Which is for sure invaluable!
On another hand, OMG has produce a specification on making some UML models executable: http://www.omg.org/spec/FUML/. I don’t know if fUML may be of any use for your approach, but as far as I know their initial intent is not “just” requirements validation.
Hi Vincent
Thanks for the clarification.
I tend to agree with you about MDA. If you use “code to specify code” then you are simply changing your source language. Dressing it up as anything else is just marketing hype.
Rgds
Ashley
Pingback: The Book of Fallacies | Caminao's Ways