The Road to MDA

The most expensive phase of software construction is coding and this is because it’s the less intuitive: it requires constant attention and reasoning, errors (logical or not) are difficult to spot because they are immersed in text that often is long, separated in more than one file, and not written by us.

More, this text describes a behavior to which you must think about. Human brain is not so good at reasoning or reading and understanding text: it’s better at looking at images. Everyone can spot an error in a picture in a relatively shot time and there’s immediate agreement on that (it will never happen something like one that thinks that the performance problem of a web app is in the database only and another in the access library only).

What are the solutions to solve this problem, the problem of coding?

I see at least two solution:

  • improve the text, how it is organized, using more and more powerful concepts that become programming languages and writing conventions
  • eliminate text and use something different

In the last years I followed the evolution of what I think will be the future of mainstream programming: Model Driven Development or MDA. MDA is a relatively recent concept that was born after another big quake in software industry that was UML: UML was not a new concept, but this modeling tool was presented in a new “unified” way that was the real revolution, it gave finally the mean to developers to do blueprints of software, thing that human beings did for thousands of years.

MDA is the next step: the computer itself transforms these blueprints in runnable applications, so the only real work left is using the brain to solve real problems, translating ideas in images (UML) instead of text (code).

As you know, or as you can imagine, MDA has the potential to take software development to the next level of evolution, like high level languages did in the “text” world, so why are we still here discussing if MDA is a good solution and not something too idealistic? Ok there’s a small problem here: with UML you cannot (yet ?) express everything is needed in the real world by a computer software, and probably you will never do.

In fact, actually all MDA solution create incomplete source code for your future running application, code that you must complete in well-known points that represent what cannot be expressed in its blueprints. Why these holes exist and what should be put inside them?

The responses can be many, but normally they can be summarized in three words: non-standard behaviour.

In fact, MDA packages (like AndroMDA) offer a complete solution if you want to build certain types of applications that do certain operations: if your application happens to be in the same area of solved problems, you are lucky and you can go on only with your blueprints in UML. On the contrary, the package will leave a “signaled” hole which you will fill with your code. You can change your blueprint how many times you want and re-generate the application, the package will preserve your code.

Note that, in the next version of the package, you could find your code obsoleted by the new package features (more UML covered and/or more “standard” behavior added) and the process will repeat at every version released, so the package will be able to cover more and more needs, until a day, if not yet today, that it (or they) will be able to cover practically all computer software needs of the real world.

It’s only a matter of time. What is “standard behavior”? Common sense will decide.

If you are not convinced yet, think about something very different in appearance from MDA and UML: web frameworks a là Ruby on Rails. What RoR and the other MVC frameworks did that convinced so much people of their goodness? They eliminated a lot of text, configuration text and code text, because the people behind it used common sense and applied it to their frameworks: you can do everything with RoR, but if you follow some simple rules you can do it much faster.

An example yet brighter comes to my mind: symfony web framework. You generate a lot of things like in RoR, but with admin mode for your entity (a sort of “back-office” generator), you cannot avoid writing even a single line of code, obtaining a complete CRUD interface with even complex links between other entities (like combos, lists, etc.) What you have to do is to fill a YAML file with a textual description, in symfony terms, of what you need as rich as you need: I can assure you that, even if it’s not so simple, you write only some tens of lines of text, and you see the results, even wrong, immediately.

Now imagine the next generation of framework: it will be something in them that will eliminate some more text, in the same intelligent and revolutionary way. I do not know what concepts will cause the new change, but repeat the process again and again and only smaller and smaller bits of text will remain: remember that bits of text cannot be smaller than a minimum size to remain expressive, they will be more and more as systems will increase their size and complexity, and you’ll need a big picture of your system/application and pictures of its parts and so… what will you use for that?

Perhaps some images will be a better representation for all of them (I can say running blueprints), and they could be in UML or in a new visual language/convention born e.g. as a high level mix of the two trends, the “improve text” and the “eliminate text” ones that I mentioned before: they will meet themselves in some point in future in drawings decorated with small bits of text, like a blueprint of a house, to compose pictures that every professional (and non-professional to some extent) could understand with a reasonable margin of error.

I am sure that point in future and the road to that point will be exciting.

One thought on “The Road to MDA”

  1. teh holy grail of computer programming is not programming that’s your point I understand. Sound very good to me, let’s use less time programming and more time doing more interesting/abstract/funny things. But let’s not forget that eventually software runs on machines and we have to know them. Top doen reasoning is ok but you have to know the “down” part of the paradigm, especially when working on “bleeding edge” software that is software with lots of data to process quickly.

Comments are closed.