Sequence coding

Question

When I was at university, a lecturer said that some people managed to code sequence diagrams, it seems to me a good way of programming, but, of course, the devil is in the details. I have a few questions.

• Is this really so, or was I misinterpreting what he said?
• Has anyone here really done this?
• Is it more productive?
• What are the disadvantages?
• What tools will you need when using Java?

Answer 1

I found that “normal” sequence diagrams are almost always painful than they are worth it (although I found them useful for displaying data flow in LINQ). Performing a "rough and ready" diagram and explaining it (preferably personally, but with a lot of words anyway) works better in my experience.

I think it’s nice to have a diagram (or several) showing a kind of "vertical cut" of your application - how each layer talks to the other and, possibly, shows the progress of the request / response in appropriate cases. However, this does not have to be at the “individual method call and always at 100% accurate” level - make sure that you convey the correct overall impression, more importantly, assuming that the reader can immerse himself in real code.

Having said all this, my views on UML are generally the same, so if you are a big fan of accurate diagrams that are always carefully monitored with reality, etc., take it all with a big cheek :)

Answer 2

I think sequence diagrams are one of the best ways to visualize complex multi-threaded programs with a lot of messages being transmitted between threads. I do not use them a lot in design, but sometimes this is the best way to debug.

Answer 3

I found that sequence diagrams are not suitable for real applications because:

• I can just make good use of the outline in English, explaining the hierarchy of calls from level to layer when there is one control flow. Styles in MS Word are very good here.

• My English explanation is more detailed and takes up less space than a UML image.

• Using English, I can explain other details, such as protection conditions and cycles, better than a sequence diagram.

• I can write a diagram faster than composing UML.

If you really need a “picture” with this detail, perhaps the activity diagram will do the trick.

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

As for Java, my project team really likes Jude , as it can reprogram the Java 5 codebase class hierarchy.

Answer 4

The sequence diagram will show the interaction, which is usually a single path through your code. On the other hand, your code should define every path with every if-then-else and edge condition, etc. You can show all this in sequence diagrams, but they tend to become too complex and cumbersome. I would recommend you use sequence diagrams to visualize your code during the development phase, if it is useful to you, but as far as possible, you should go.

Answer 5

Sequential charts have their place. I never worried about synchronizing a UML diagram 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 with the basic process and structure of the call. When you also track arguments and instantiation, it can highlight holes in your understanding. If you need the data "x" as an argument, it is either local or must be passed: "We request report data from the database, and we need to send the report type, we remembered that we included it as an input parameter, correctly ?

This works for passing a high level of design. After that, it can serve as general documentation for late visitors. They will understand where you were going, and when they see the code, they will not be so confused by the changes.

Answer 6

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