▲ | alganet 5 days ago | ||||||||||||||||
Good UML is really simple UML. "Then what about complex things? Can't make everything simple" Do partial diagrams. Simplify or skip things your team already knows. Also, great UML is no UML. Sometimes the code itself is short and clear enough, requiring no diagram (of course, not all diagrams are about code... but use case diagrams are rare these days anyway). Also, use cases and use case diagrams are great. Also, perfect UML is disposable. Thinking of long term diagrams that serve as documentation is a mistake. | |||||||||||||||||
▲ | bartvk 4 days ago | parent | next [-] | ||||||||||||||||
I very much like your comment. It describes practical use of diagrams. In the past, I've included diagrams for a particularly complex state in the comment on top of my code. It certainly doesn't describe the whole system, or even the complete state of that code. And I expect that someone will delete the comment at some point. That's all fine. | |||||||||||||||||
| |||||||||||||||||
▲ | teeray 4 days ago | parent | prev [-] | ||||||||||||||||
This is why UML only belongs on a whiteboard. It makes it much harder to include unnecessary detail when you have to physically add it, and there’s hard real estate constraints. | |||||||||||||||||
|