Recently I have partecipated in a discussion about the value of forward-reverse engineering of UML models. Undoubtedly generating code from models can save the developer to perform routine operations. Furthermore, the automatic synchronization of models and code can be really rewarding when the expected outcome is mainly to avoid the premature obsolescence of models with respect to the real system (expressed concretely and precisely only in the code). However, a more in-depth investigation about modern UML tools reveals many problems that can discourage this practice. I am not saying that approaches such as Executable and Translatable UML (xtUML) are bad or wrong. Simply I say that modern tools are quite far from being satisfactory, especially from the architect/designer’s point of view. In my opinion, one of the most important remarks concerning executable models is that the price to pay for having them today is an increase of detailed, low-level information in models. The immediate side effect is that models become more obscure, plenty of pseudocode, stereotypes, and (often proprietary) action language statements that hide the essence of a model: its design. Tools simply are not enough “smart” to keep this information (the graphical notation and its textual specification) in separate views, forming different layers of abstraction (Isn’t it one of the most evident promises of MDA?).
These critiques can be relevant or not, depending on the way and for which purpose the UML is used. UML adopters should understand in the first place why they are building models (in particular, design models). Are they interested mainly to raise the level of abstraction, moving their development environments from textual programming languages to graphical programming environments (with an obvious shift in notation)? Otherwise, are they approaching modeling in an attempt to give dignity to design artifacts like architecture, subsystems, protocols, and so on, that are usually implicit (hidden) in the code? Are they focusing on generating code, or they consider the goal of improving communication as a mandatory requirement?
Design models are artifacts to be maintained and updated. There is a lot of emphasis about automatic synchronization in the market, but (considering the state-of-the-art tools that are available nowadays) I do not believe that this is the right direction, in most cases. Simply, this type of automation it is not about design. It provides a mechanistic view of code. After some rounds, people continue to do all the shortcuts in the code (perhaps because they are programmer and code is their natural place to work…), and the only fact that an integrated environment is able to automatically re-align with a single click both models and code does not mean that you are doing design! Neither that you are doing GOOD design. It is exactly the opposite. It is the shortest path to bypass design!
Who claims that automatic generation of UML models is the right tool to avoid the burden of synchronize code and models has in mind the main goal of speeding productivity. But it seems they are focusing only to the most easy (and useless) way of measure productivity: the percentage of LOCs automatically generated. Without taking too much into account the quality of the design, this attempt to improve will fail because the most important improvements in productivity come from design, not from code. In the long term, this choice is usually counter-productive. In my opinion, you have to pay a price for keeping a high level of (design) quality in a complex project. Building models and maintaining them as the backbone of the system is an important investment in communication, IP sharing inside the company, and in development.
If the development team really embrace a model-driven approach, modeling should not be viewed as “a way of building programs”, but as a way of designing solutions, a way of thinking to problem domains without the bias of a programming language, a way of communicating with people rather than with machines. Not one of these in particular, but all of these at the same time. Of course, we have to remember that the sole use of UML is not a guarantee of success. The value is not in the notation, but in the way the notation is exploited to guide the development process, to forge and inspire good solutions, and to better communicate with people (eventually even with ourself).