State charts are occasionally useful for obvious reasons. Doesn't even have to complete or correct. Abstract in the sense that it should not necessarily represent physical tables, but give an overview of the underlying structure to the first time user. I actually believe every API documentation should start with an abstract entity relationship diagram. While it's not very useful for designing, I have actually used them for understanding and simplifying a complicated database schema. 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.
#MODELIO SEQUENCE DIAGRAM TUTORIAL FREE#
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.
#MODELIO SEQUENCE DIAGRAM TUTORIAL 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)
