Coding using sequence diagrams

Question

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.

• Does this actually happen or was I misinterpreting what he said?
• Has anyone here actually done this?
• Is it more productive?
• What are the disadvantages?
• What tools would be needed when using Java?

Answer 1

Sequence diagrams have their place. I've never been one to worry about keeping a UML diagram in sync with code changes. That being said, I'm a big fan of using sequence diagrams as a brainstorming tool. You want your team to understand and agree on the underlying process and call structure. When you also track arguments and instance creation, it can highlight holes in your understanding. If you need data 'x' as an argument, it is either already local or needs to be passed in, "We are requesting the report data from the database and it needs us to send the report type, we remembered to include it as an incoming parameter, right?

This works for the high-level pass over the design. After that, it can serve as general documentation for late comers. They'll understand where you were headed and when they see the code, they won't be so confused by the changes.

Answer 2

Sequence diagrams work for procedural languages. They are not as useful for OO languages.

Answer 3

A sequence diagram will show an interaction, which is typically a single path through your code. Your code, on the other hand, has to define every path, with every if-then-else and edge condition etc. You can show all that stuff on sequence diagrams, but they tend to get much too complex and unwieldy. I would recommend you use sequence diagrams to help visualise your code at the design stage, if that is useful to you, but that is as far as you should probably go.

Answer 4

I've found that sequence diagrams fall short for real applications because:

1. I can do just well using an outline in English explaining the call hierarchy from layer to layer, when there's a single thread of control. The outline styles in MS Word do just fine here.

2. My English explanation has more detail and takes up less space than a UML picture.

3. With English I can explain other details such as guard conditions and loops better than a sequence diagram.

4. I can write up the outline quicker than drawing up the UML.

If you really need a "picture" with this much detail, perhaps an activity diagram will do the trick.

On the other hand, a sequence diagram is great for a high-level overview.

As far as Java is concerned, my project team really likes Jude as it can reverse engineer a Java 5 codebase's class hierachy.

Answer 5

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.

Answer 6

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 :)