UML Sequence Diagrams – Implementation and Use Cases

designobject-orientedsequence-diagramumluse-case

In the design phase we create UML Sequence diagrams (in OOD). My understanding is that after creating an Use Case diagram if we need to show further information in terms of time sequence of events of that Use Case, we can go for sequence diagrams.

My question is, should a sequence diagram represent exact implementation details? If I ask in another way, should all method calls and object interactions in the implementation be shown in the Sequence Diagram? Or else it should present a high level picture of the implementation?

Normally in the implementation, things could be implemented with slight differences than specified in design diagrams. So that if a sequence diagram should show exact implementation details, we might have to revise them after the implementation.

Another related question would be, who are the audiences of these sequence diagrams other than the author? An answer for this question might answer the original question as well.

Best Answer

I would say go as high level as you can while still including all the necessary method calls, etc for your topic. My reasoning for this is that if you're including every single interaction then you might as well just write the code yourself.

Personally, I have always viewed sequence diagrams more or less as "guidance" for the implementer. I've never viewed them as living documents - if the implementation differs from the design I won't go update the diagram (unless it's different because my design was wrong). However, you're right in assuming that it largely depends on the audience.

If you have a team full of experienced developers with knowledge of your product, you should be able to leave a few things out here and there and trust them to fill in the blanks with their best judgement. In my case, I usually confine my sequence diagrams to a particular topic, say "Process XYZ", and only show method calls and object interactions that are relevant to that topic, leaving out things in between that are obvious or are defined in another diagram. If I'm writing a diagram for a junior developer who's learning the project and domain, then I tend to be more specific.

The only reason I would include every single method call and interaction is if you're actually generating the code from the model. For example, I've worked on some embedded systems where we generate our code out of a Rhapsody model, so obviously in that case you should include as much as you can.