← Back to context

Comment by microtherion

5 years ago

The problem with tools that generate code is that they are often unidirectional. If there is no way to get code changes to propagate back to the visual model, the latter is likely to fall into disrepair pretty quickly.

It could be possible to do something interesting in this space, where UML can be used generate template code, and later on, another tool could extract UML from the code, compare it to the baseline, and flag any discrepancies. From there, you can either sign off on the discrepancies (and replace your hand-made UML with the extracted one) or fix your code. Bit of a kludge, but at least automatic verification is possible unlike documentation

  • If only it were that simple but the code is so expressive that you can't really create the UML as easily from it as the other way around. You just can do too much stuff in code that the UML generator would just not understand at all. Or you'd have to basically code in a very specific manner. Not fun. Of course since I last tried it they probably got better at it.

    I even remember back in university you'd have to write your custom code _in_ the UML tools dialogs if you didn't want it to be overwritten next time you tried to generate code. Of course these were just simple text boxes. Horrible dev experience.

The trick is propagating "backwards" to the model feedback from tests, not changes, preserving the normal loop of receiving requirements, writing code (in this case the "model"), compiling it to something else (including generated code that fools would be tempted to modify) and running the program.