Relationship diagrams are often (ab)used to visualize relationships between tables in SQL databases. Sequence diagrams are probably the most ubiquitous, and very useful in explaining protocols. The 3 actually useful diagrams that I have seen in the last 10 years are:Īll 3 are useful for communicating protocols, schemas and state charts. They'll often go out of date as quickly as you make them, so keeping them up to date and well versioned turns into a challenge.īecause it's free and provides cross platform compatibility (and the diagrams are supposed to be communication devices), we tend to use yEd for most things. Protocols are well described by a lightweight treatment of sequence diagrams, etc. Lightweight versions of the Archimate style work well for describing complete systems. There's also often better, simpler ways to document many aspects of a system, a few boxes and arrows work well for many things. And in addition, the level of detail should be just as much as is sufficient to communicate what's necessary - don't "prematurely optimize" by trying to document every bit of the system in excruciating detail. The principal of using diagramming as a descriptive documentation and communication solution is highly worthwhile, but again it should be limited to pieces of the system that need such things. (not to mention that the people who usually end up creating the UML might be many organizational layers away from the developers).īut there's some goodness in there.
MAKING A STATIC METHOD IN VIOLET UML EDITOR CODE
It also is taught wrong, it tends to be taught as a design tool, but there's such a tremendous impedence mismatch between the diagramming tools and the way the code actually gets written that it ends up doing more harm than good. Never go "full UML", it will annihilate productivity and produce abominable software.
0 kommentar(er)
