Being able to break down an interaction into a sequence diagram (especially between 2 or 3 servers) is a powerful thought tool for specifying interactions and its easy for people to understand.
Being able to break down an interaction into a sequence diagram (especially between 2 or 3 servers) is a powerful thought tool for specifying interactions and its easy for people to understand.
The only problem with UML is that it was used as a method of intellectual masturbation by people who love massive class hierarchies. There's a lot of good stuff in UML, the problem is that the people who were attracted to it in the mid 90s were the same people who were poor programmers and were looking for any excuse to avoid writing code. There are the same guys who spent years building up formalisms in tools like Rational Rose and other pseudo-engineering tools.
When used by good programmers to illustrate specific hard-to-reason about components of the system, it is a useful tool. Activity diagrams, sequence diagrams, use case diagrams and communication diagrams are all useful.
Sounds like the same people who became Agile consultants in the early 2000's. Perhaps they realized activity and sequence diagrams can get fairly complicated soon enough, so they looked for a bandwagon requiring no technical chops whatever.
I co-wrote a book on UML years ago, used to be an enthusiast. Now I write some sequence diagrams, and once in a while might write a high level class diagram.
It is all about communication, and a sequence diagram is good for that.
and http://www.umlet.com/ (if you need to do more then just sequence diagrams)
[1] https://chrome.google.com/webstore/detail/websequencediagram...
After that it usually turns out to be simpler to create a prototype or wireframe than UML diagrams these days (IMO).