I have been reading some articles on UML and how nice it is to draw the initial picture of the whole system design. There are claims that say there are some tools out there that automate code generation to create empty classes and methods based on the UML diagram. What a novel idea! So I went and hurt for “those tools”.

To my disappointment, I found many “old websites” and dead links… a domain was on sale as well… This doesn’t look exciting…

I went to read the comments from the experts at stackoverflow:
Is UML practical?
Do you still use UML? How? What for?

To be fair, there are some people in big organizations that are using UML for documentation and illustration purposes. But the issue here is code generation, or in general the whole design flow…

Say for example, some architects made the UML diagram and got all the applause from the investors. Now, you being the poor engineers need to implement all the claims on the UML diagram. You start with code generation, the feature to dump initial code from the UML diagram to code. In the middle of your implementation, you may realize that there is a critical change that needs to be made in the design, perhaps something changed in the requirements. So now what? You probably have two choices:

1. Change the UML, then do code generation… and start over…
2. Change the UML, but skip code generation. Keep writing your code and implement the new change.

If you pick option 1, I can see that you are being very responsible. In addition, I can also say that you have quite a lot of time to re-write your code, coz I believe the majority of programmers out there don’t have the luxury to re-write their code from the beginning.

If you pick option 2, it’s probably for the reason of practicality. At any agile development work place, changes happen all the time sometimes even right before you deliver your product. The UML diagram is to serve as documentation, rather than being the initial stage of the design flow.

Here is an article titled 13 reasons for UML’s descent into darkness dated May 15th, 2008. Good read! I will highlight a few reasons below:

The obsessive focus on monetizing UML
Trying to sell expensive tools for a technology that is not mature enough and only makes promises to the management (just express your ideas in pictures and the code will be generated by our magic wand) can only work in short term. At some moment somebody realizes the costs are too big for the benefits. Lots of programmers instinctively hated the whole thing. Others were persuaded by management or by curiosity to try it. Most of them never used UML tools for more than a project.

Concept bloat
Trying to bridge UML to reality made it incorporate concepts from all the languages in fashion during the last 10-15 years. Anybody knows how to represent a Java anonymous inner class?

Always catch-up with new languages and concepts
In continuation of the above… and because the promised prize was full code generation you have to be able to represent specific language constructs. Closures in UML anybody?

Treat software development like manufacturing
Software design is not manufacturing no matter how much management likes to think about it this way. Software creation is a creative activity so a more accurate description would be craft, art or something along this line. UML tries to standardize and formalize the unknown, the imagination and the talent.

As of now, I really like the UML idea, but I don’t see this as a practical approach yet to design flow. Using UML as a reference documentation is surely a good start, but the connection between the UML diagram and the actual code remains a practical problem to be solved.