Sequence diagrams express interactions among classes in terms of messages exchanged for a period of time, and, as we've seen, they fall in the category of interaction diagrams.
When you're done with the robustness analysis, you have defined most of your objects, their static relations and some of the dynamic relations. Now it's time to refine the diagram again, and to bring it closer to how the actual code will look like. Sequence diagrams can also be used to validate use cases.
You have four types of elements in a sequence diagram: objects, methods, messages and text. You will take the objects from the robustness analysis, and you can include their class, if you need to. The methods are shown as rectangles, while messages are arrows (messages are what stimulates an object to perform a certain action). Finally, the text comes directly from the use case.
This is the moment when you're most likely to get stuck, particularly if you've made mistakes so far. Make sure you allotted enough time to this stage to go back, if necessary. You will definitely need for attributes - check them out carefully, particularly if you plan to skip the class diagram and to move directly to the code after this.
When you draw the diagram, leave the methods last. You will need to check them with the controllers from the robustness analysis, but remember that one controller may translate into more than one method. Also, this is where you may decide that you can use some patterns already available, or that you can create some new ones that would be helpful.
As long as the use case diagram corresponds to the robustness analysis and the analysis corresponds to the sequence diagram, you are following your requirement specifications and will obtain what the client wanted. Otherwise, go back and see what you've done wrong. You cannot be sure that you've covered everything until you've drawn sequence diagrams for each use case, and then check the diagram with the text from the original use case, just to make sure that you didn't get "lost in translation".
Check your message carefully, and make sure that, for each of them, you understand which object is in control (and why, for all that matters). This is where you make some crucial decisions for your code - try to estimate how long a method takes, and if there isn't a shorter option available. Also, check the potential blocks or bottlenecks where your application will choke, and correct them at this stage. The sequence of the diagram is no longer an abstract drawing - this is what your code will also look like. Make sure you apply correctly all the principles of object-oriented design - you can't enforce them later on.
When everything was checked one hundred times, you can move on to the class diagram - which describes the types of objects and the relationships among them. It used to be called "object model", because this is exactly what it does - it models the class structure and content. This is the actual model of the code. All classes have names, attributes and operations, and the relations among them are the typical ones, such as inheritance, association, aggregation and containment. For complex classes, you can use a statechart diagram.
Leave a Reply