When I was at university a lecturer said how some people managed to code using sequence diagrams, this to me seems a good way of programming but of course the devil is in the details. I have a few questions.
I've found that "normal" sequence diagrams are almost always more of a pain than they're worth (although I have found them useful for showing data flow in LINQ). Doing a "rough and ready" diagram and explaining it (preferably in person, but with plenty of words either way) works better in my experience.
I think it's a good idea to have a diagram (or several) showing a sort of "vertical slice" of your application - how each layer talks to another, and perhaps showing the course of a request/response in suitable cases. However, this doesn't need to be at the "individual method call and always 100% accurate" level - making sure that you convey the right general impression is more important, assuming the reader can then dive into the real code.
Having said all of this, my views on UML in general are much the same, so if you're a big fan of precise diagrams always being kept meticulously in sync with reality etc, take it all with a pinch of salt :)
I think that sequence diagrams are one of the best ways to visualize complex, multithreaded programs with lots of messages being passed between threads. I don't use them much in design, but sometimes they are the best way to debug.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With