How effective are automated round-trip tools for UML modeling? Do they help in coding quick, clean, efficient code? In what ways do these tools fit into the Agile methodology?
- Anybody can ask a question
- Anybody can answer
- The best answers are voted up and rise to the top
closed as not constructive by Tom Squires, P.Brian.Mackey, Yannis♦, ChrisF♦ Nov 24 '11 at 23:48
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.
Part of the Agile Manifesto states:
It all boils down to the reason you're using UML. Everywhere I've worked that used it, it was used as an artifact to "prove" you had completed the design phase, then classes were generated and it was never looked at again because it was too much work to keep the two in sync. If that's how you're using it, that is decidedly non-agile.
On the other hand, if your team is that mythical creature who actually manages to keep their UML in sync, who constantly refers to it throughout the entire lifecycle, and would miss it when it's gone, that definitely fits with agile. Remember that tools and documentation are fine, even encouraged under agile, as long as it doesn't interfere with interactions and working software.
I fail to see how an UML round-trip synchronization tool would "help in coding quick, clean, efficient code".
Since we're talking agile practices, as far as TDD is concerned, what you often see (and it is promoted by people such as Bob Martin) is UML diagrams used merely as a sketching tool to flesh out the main classes before starting your TDD session. But these models more often than not prove totally wrong and become invalid as your code design incrementally emerges through the TDD process.
It's the TDD Refactor step combined with good coding practices that allows you to write "quick, clean, efficient code", not having ready-made UML diagrams and sticking to them while coding.
As for whether the UML models should be perfectly in sync with the code at any given time, I consider the benefits to be far less important than the cost. Unit tests are usually a better way of documenting the code IMO.
That's not to say higher level UML diagrams describing the architecture or use cases of the application aren't useful, though. But these are precisely too high-level to be used in round-trip generation.
I think there is a confusion when talking of live code and model synchronization. It is not a good idea to permanently synchronize your model with your code. I still remeber Togethersoft which was the best round trip tool but it was so slow and if the UML editor was not open then your model was not updated if new classifiers creation at code level etc....
There is a new initiative which is a mix of round trip and code generation on demand with java code and model merge. The mechanism is based on mapping each java classifiers Id to a model element Id. I mean that you reverse first time the project and get a single model. It creates UML Id for each java classifiers and sub-elements which is related to java id. Once this job has been done you can model or code with UML eidtor. When you want to update you just select the merge option which will incrementally creates new classifiers added at code level with existing classifiers already created in your model. You can therefore have as many as needed iteration between code and model.
What I like with this Id approach mapping each java Id to UML id is that UML is now like a java editor and you can graphically change in 5 seconds what will be over 30mn at code level because everything is refactored immediately and model integrity check. It means if what you do is not correct you can immediately get a warning. It is just at model level therefore no other tool to install. Very simple just a click on Model check option.
What I also like is to create a model independent of my code. No tag in my java code because all model information is the UML model which is a single model. I then can just extract model views graphically. These views are built on a model representing the full application and updated on demand when model merge is selected.
This is why UML ids merge with java Ids make UML efficient, faster to write code but don't try to replace the code by using code generation templates. I mean that UML ids are done as if you were codding at graphical level and certainly not try to generate the code.
I would say that traditional UML with code generation templates is like when you try to create HTML page from a word document automatically. It certainly works well but then you are stuck and can not change anything. It is also horrible code HTML quality. To avoid this problem of using code generation templates the UML ids to Java Ids merge make code the same as if hand codded. Really good quality.
Really very few UML initiative has been done on UML ids because the graphical layer is managing mapping (e.g. for example the GMF project used by Topcased or Papyrus) to the metamodel while it should be the model directly managing each UML and java ids working natively with no intermediate layers !!