I recently happened to read this abstract of Friedrich Steimann’s verdict on MDA/MDD:
Models have their greatest value for people who cannot program. Unfortunately, this is not because models are more expressive than programs (in the sense that they are capable of expressing complex things in a simple manner), but because they oversimplify. To make a useful program (i.e., one that meets its users’ expectations) from a model, the model must be so complicated that people who cannot program cannot understand it, and people who can program would rather write a program than draw the corresponding model. Even though (over)simplification can be useful sometimes, it is certainly not a sufficient basis for creating a satisfactory end product.
While I agree on some statements, I strongly disagree on the conclusions.
It’s true that models are appealing because they are a simplified representation of the reality. This is exactly their definition. Not a weakness, but a strength, I think. Just think what has been possible in the scientific fields of physics and chemistry. All we studied in classes are models, not the actual reality. Then one can discuss how much these models simplify such reality.But the final outcome is that several real solutions has been devised based on these studies on simplified models.
Back to software engineering, models are crucial for describing overly complex systems, and I strongly believe they are a powerful tool for leading to the end product. Then, the question could be how to reach the target.
One could argue that models can help in the initial phases, while manual implementation is needed at the end. However, I think that MDD is now comprehensive enough to provide a good set of tools for modeling applications down to the final product delivery. We should not forget that we may apply hierarchies of models, model transformations, and aggregation of complementary models for describing a system. At the end, simplification is just another word for abstraction.
Therefore, I think that simplification is actually sufficient for going to the end products, provided that the MDD approaches allows for models with multiple levels of details, transformations among them, and appropriate inferences starting from the simplified views of the reality. I.e., one must assume that starting from a simplification of the reality (or from a combination thereof) there are some logical deductions (more or less automatic) that lead to filling the gap from the simplification to the final result.
I base my opinions on very concrete experience of the MDD approach in the Web field, in which the combination of appropriate models (BPM, ER, WebML, presentation layer [see also the RUX-tool]), of proper transformations, and of design tools (WebRatio) actually allows us to “magically” get to the final product delivery with hundreds of customers.
I mostly agree with you, Marco. While Mr. Steimann's verdict is correct for many model-centric MDD approaches, there are some MDD approaches, most notably IBM Rational's strategic direction, whose primary focus is the fast and efficient delivery of complete software. It is these newer approaches whose practical results contradict Mr. Steimann's claim.
You are right, by looking back one can appreciate how dramatic the change in the MDD field has been in just three or four years.
In general, the combination of MDD, agile, and Saas at the modeling level have changed the attitude towards modeling. Furthermore, DSLs have become a widespread practice.
On the other side, wider availability of well established development frameworks have improved the possibility and quality of generated code.
Marco,
I also disagree with this statement, but at the same time, I think our industry has not focused on creating “behavioral” models. A lot of the models we see are very static in nature, with canned behavior at best. I have published an article a couple of years ago explaining how to create “cogent” models and show the continuum between general purpose programming languages and cogent polyadic models. (http://www.infoq.com/articles/mop).
I have created a product to develop my ideas around Metamodel Oriented Programming (http://www.moppr.com) and but I am not completely sure like you that “it is sufficient for going to the end products”. I am clearly working to get there, but, so far my customers need to drop into the generated code to achieve what they need. I don't think this is bad, but I don't see today how this will not be necessary in the next few years.
JJ-
Marco,
here is the link to the article: http://www.infoq.com/articles/mop (the blog link works too).
>> I definitely think that actually going into the generated code IS bad
I know why you are saying that, and I don't disagree, but I don't see any solution today.
>> you put your customized parts within the modeling or transformation layer,
Yes, I have also explored putting that code in the transformation layer and that looks promising, because the end result is always generated as you say, however, your transformation become project specific.
Thanks JJ for the correct link.
About existing solutions: actually it's what we are really doing (and here I hope not to be politically incorrect) with the product (webratio) and language (webml) we developed.
You get high quality, production-ready applications just by following the virtuous MDD cycle, and you NEVER touch the generated code (and we don't do toy apps, we have huge applications spanning a diverse set of scenarios and user profiles, accessed by millions of people worldwide).
That's not magic, you don't get everything for free: if you need some custom business logic, you have to implement it, but you do it as a plugin in the MDD environment, so that it becomes part of it.
About transformations becoming project specific: let's say that typically a large part still remains project independent, then the customized part can be specific, but I would count it in the amount of reusable knowledge you can exploit in the future. Indeed, if you are smart enough, you can build your custom components and transformations to be reusable.
agree, too!
abstraction is the human way of solving problems, execution is the computer's one. Think, in the end the point is just, that the (modeling/ programming) language used is expressive enough.
“… the model must be so complicated …”
obviously, Steimann hasn't captured the idea, that one can have different views on things (including models themselves), where a view consists not only of a 'simplification', but also of a perspective (>point< of view). |=
You are perfectly right, simplification + perspective are the ways one can abstract (i.e., select the details of interest = simplification, with respect to the objective/task = perspective). The good thing is that different abstractions can complement each other in the definition of the problem and of the solution.
Oh yes, and problems can suddenly become so incredibly nice and easy when you find the right set of views.
Unfortunately I think by now there is not much guidance for finding good views, as compared for example to all the guidelines and rules there are for writing good programs.
|=
You are perfectly right. This is crucial because I think understanding the right abstraction and perspective is the core of the expertise that makes a good software engineer.