A skeptic’s sight on Model Driven Architecture - part 1

Being dealing with MDA lately, I am currently trying to decide which side am I on. As the title above states, I found myself still somewhat skeptic (for reasons I’ll try to explain here). Anyway I am still digging in the MDA area, so my feelings of today will change or might result wrong.

MDA vs. Agile UML Philosophy
A crucial difference between UML modeling and MDA is that UML is a great tool to share a system vision with somebody who is not a programmer. Agile approaches focus on the UML as a tool to communicate so you tend to keep the model as simple as possible, to avoid information overload. Another agile principle is to avoid redundancy, for example including only a typical sequence diagram for a sample interaction with the system, without a detailed model of the others.
MDA goes quite straight in the opposite direction: a model must be formally correct in order to generate working code, so it must be complete. This means that all those not-so-different sequence diagrams now have to be modeled, instead of simply coded (which means also that’s going to be a designer’s job instead of a developer’s job). To be completely honest developers deal with small differences from the sample iterations in two ways: a) refactoring common code to an elegant schema, b) cutting and pasting. The latter – unfortunately – more frequently. Both ways are intended to save time; I guess there will be ways to abstract a common behavior at model’s level to reuse part of the already modeled behavior some way, but the efficiency of this part might not be comparable with what you can do with good refactoring tools on a recent Java IDE.

Another element that affects normal modeling is the adoption of the OCL as a way to define constraints in UML diagram. Bad news are that OCL is probably not so well readable to the domain experts (that’s the reason why you normally prefer plain language). On the other hand, this enables formal controls for completeness or consistency of the logic conditions, improving software robustness. A great burden here resides on the level of usability achieved by the development tools, that could make the difference from a toy to a really useful tool (the more you click, select and drag, the more you are probably faster in just typing java code).

Tags: MDA, Model Driven Architecture, Agile, UML