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.

  • 1
    As with any kind of technical documentation, the audience depends much on how your team and your development process is organized (which we don't know, since you did not tell).
    – Doc Brown
    Jul 13, 2014 at 18:01

3 Answers 3


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.

  • At a very high level, sequence diagrams can represent high-level interactions between systems or sub-systems at a high level.

  • If they represent interactions between actual classes (or interfaces) they're nice because each message in the diagram corresponds directly to a method that class must have. You can almost write your code from the sequence diagrams by capturing the messages as methods.

  • If they represent interactions between services, each message represents a request or resource that the receiving APIs must support.

As for level of detail, I've created sequence diagrams that represent high-level interactions, with many implementation details left out, for the purposes of design documentation. But I've also created really detailed sequence diagrams that spell out specific methods and even parameters between classes.

It largely depends on what your needs are. I've found sequence diagrams to be a great way to both understand and communicate solutions where the requirements are big and complicated, as well as a way to do class design at a very specific level of detail.


Although I haven't tried it, one might be able to make a high level sequence diagram with fairly high level messages like "Send alarm to server" and then use UML allocation to assign these to more detailed sequence diagrams that got as granular is needed in terms of showing login sequences, acknowledgements, and so on. This approach might be a reasonable way to link the "easy to understand for the stakeholders" version to (a number of) "detailed enough to generate code" versions.

I would be curious to know if anyone has actually tried something like that.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.