Considering the fact that there are many glaring mistakes that are present when it comes to sequence diagrams, we have decided to gauge and mention ten of the most common mistakes you are sure to make. Scour through the list below to see what these mistakes are and how you can avoid them.
Usually, a typical mistake that software diagrammers usually make is adding too much detail when working with sequence diagrams. Say your code has quite a few branches in a particular method; this does not mean that you should include each one within the same diagram using block or scenario elements. The issue is that adding too much detail ends up with too much clutter thereby making the diagrams more difficult to read and comprehend. The same could be said when it comes to sequence diagrams at the system level. What you really need to do is to keep all your diagrams clutter-free, as shown below.
When it comes to sequence diagrams, the message flow should start from the top left corner. Since it is the usual practice in western culture to read from the left to the right, all classifiers such as actors, classes, objects and use cases, should follow this route. However, there are certain exceptions when it comes to this logical flow, such as, when objects pairs invoke operations on each other.
Obsolete and outdated sequence diagrams that are not relevant when compared to the interfaces, actual architecture or behavior of the system, become a pain since they stop offering any documentation value. This is another reason why high-level sequence diagrams work much better than low-level diagrams. The former tends to remain appropriate even as the application details are changed. They may even need only a few modifications over time in order to remain current.
One of the most common mistakes that most of us do is waste time doing too many diagrams for every single use case, one for the basic course of action and one for each alternate course. It is best to design a sequence diagram only when you have complex logic that you have to contend with. If the logic is easy to figure out, having a sequence diagram would not really add any value.
Each sentence of the use case text ideally should have some blank space around it. Each sentence should also be in visual harmony with the message that agrees with the particular behavior. This will help people reading the diagram to see how the system will accomplish what the use case showcases.
When it comes to robustness diagrams, there really is no need to show plumbing, since these diagrams show a design view that is initial. Having said that it is pertinent to illustrate the real design in detail since sequence diagrams are the last stop before coding.
As most diagrammers are aware, the sequence diagram is the main vehicle when it comes to making behavior allocation decisions. You use them to assign operations to your classes as you go. Behavior allocation when it comes to figuring out what operations belong to what classes is significant in the ICONIX approach.
Writing the text for the use case in the margin of the sequence diagram offers a trace from the design back to your needs. In short, the diagram should match the narrative flow of the associated use case.
An object ideally should only require a single personality. What this means is that a class should focus on a set of behaviors that are related. In other words, state objects need to be cohesive and coupled. Other aspects that you need to concentrate on include things like re-usability. What this means is that when you have objects and classes that are general, you could reuse then for other projects. Also, remember that methods are assigned to objects, make sure you make it a habit to ask whether there is a decent fit between the method and object.
You do have to see which object is in control at whatever time so that it is easy to see the flow of control. While the arrows are certainly important when it comes to robustness diagrams, they are more important when it comes to sequence diagrams. Remember that the messages that are present between objects determines the operations on the associated classes.
Image from - http://theodorapap.blogspot.com