Model-driven architecture (MDA) essentially represents a different approach to programming and software development, intended to provide an abstract structure in the realization of those tasks that are usually accomplished by (more or less hardcore) manual coding. Ideally, a model driven approach is supposed to provide an easy-to-follow guideline which can improve code reusability while shortening development times. But can it really be thought as a real substitute for old-style coding? I don’t think so, yet I think that MDA approach can anyway represent a precious ally for programmers.

First of all, we have to face the fact that asking if a MDA approach can substitute “traditional” programming already represents a misunderstanding. MDA, often combined with Agile approach and diagrams modeling, defines system functionality using a platform-independent model (PIM) using an appropriate domain-specific language (DSL) (see Model-Driven Architecture). So its natural placement structurally preceeds coding. For example, there are thousand (or millions?) of programmers that dauntlessly engage their coding sessions without drawing diagrams and schemas: those braves won’t need an MDA approach, which will almost certainly result frustrating for their usual habits. Let’s assume they’ve got their good reasons to choose this type of approach. Typical MDA users, instead, will look for something more complex that can guide them through a long path of decisions and revisions, usually made by different actors in an enterprise context. In general, each of these experts will manage his own models and diagrams, bringing his contribution to a global Unified Process. Executable code implementation will be just one of the many steps on this path, not even the last one. So, MDA and traditional coding are different practices, and they often mirror different needs.

Moreover, differences between traditional coding and MDA approach can also be found when speaking about time scheduling. I won’t assert that there’s something like a “winner” between the two, since there’s not. More precisely, each of the two approaches will guarantee a time saving when used in the appropriate situation. If you’re a coder and you want to create a simple blog, or a small site for which you already prepared all needed libraries, using an MDA approach (or even a MDA framework) will probably become an useless and tedious waste of time, unless you want to take advantage of modeling to better understand your application structure. On the contrary, if you’re part of a big company, you’ll be absolutely facilitated using an MDA approach in an iterative Unified Process, and the whole process will speed up (given that every member of the team knows how to manage his own task).

Moreover, probably the most controversial side of a hypotetical comparison between MDA approach and hardcore programming is that of code generation. Good automated tools can generate source code starting from the models that MDA actors created during Unified Process iteration. But what does this generated code look like? Does it follow shared standards? Do models model every single part of this code, or something is silently invented during generation (breaking coders trust in automated generation)? This is one of the most complicated tasks that a good MDA framework has to carry out. It has to be confortable enough to make its use worthwhile, but it should at the same time provide a way to mix “manual” coding with model generation, in order to allow programmers to customize their source code when they need to.

Finally, MDA frameworks often rely on a myriad of different technologies and frameworks (e.g. Spring MVC, Apache Wicket, Spring WebFlow, Apache Tiles, logging utilities, EJB containers, Web Services technologies, etc.); those technologies are continuously updated, trashed, deprecated and forked, they’re often patched when bugs or security issues are discovered, so it’s really difficult to keep updated a framework that makes use of tons of them. Even the newest MDA framework runs the risk of becoming outdated in a truly short time. But this can also be interpreted as a strong point for MDA; think about the moment in which one of your business clients asks for a technology update for his application: if your MDA framework is constantly updated, you could be able to generate a new version of the old application simply using its old models and clicking on “generate”. But, as far as I know, nobody has already achieved this level of quality (even if I presume we’re not so far from it).

In conclusion, I think that a rough comparison between Model-Driven Architecture approach and hardcore coding is often the result of misconceptions about both of them. I don’t think that MDA and hardcore coding should be so easily compared without mentioning their relative peculiarities, so, if asked about whether MDA could really be thought as a real substitute for old-style coding, my answer is no, unless we situate “old-stile coding” in an enterprise context (or a complex context in general). Yet, I expect a foreseeable future in which simpler MDA frameworks will help everyday users (even non-coders) to create their own applications with a growing level of accuracy.

Comments and criticisms are more than accepted!

References

• Model-Driven Architecture
• Unified Process