Tell me more ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.
up vote 4 down vote favorite
4

How can I learn to draw UML sequence diagrams. Even though I don't use UML much I find that type of diagrams to be quite expressive and want to learn how to draw them.

I don't plan to use them to visualise a large chunks of code, hence I would like to avoid using tools, and learn how to draw them with just pen and paper. Muscle memory is good.

I guess I would need to learn some basics of notation first, and then just practice it like in "take the piece of code, draw a seq. diagram visualising the code, then generate the diagram using some tool/website, then compare what I'd drawn to what the tool result. Find the differences, correct them, repeat.".

Where do I start? Can you recommend a book or a web site or something else?

Update: I decided that it might be worthwhile to upskill myself in UML, and found this book: http://www.amazon.com/The-Elements-UML-2-0-Style/dp/0521616786 - reviews say it is best practices book on UML. Have you read it? Can you recommend it? Thank you.

share|improve this question

closed as not constructive by gnat, Mark Trapp, Dynamic, Ryathal, Matthieu Sep 28 '12 at 16:30

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

3 Answers

up vote 6 down vote

If you have a piece of code in front of you, a sequence diagram can be derived almost mechanically from it: draw the objects participating in the exchange of messages as boxes at the top of your diagram, draw vertical lines from each box, and then follow the code line-by-line, drawing arrows every time a method is called. Ignore control structures (loops, conditionals, etc.) on your first path through the code.

You may need to go several levels into the method call hierarchy to draw the "A calls B, B calls C, C calls D" sequences. Go only as deep as necessary to illustrate your point; use a ref box to call out interactions depicted in other sequence diagrams. Draw return arrows when you manually trace out of a method call.

On the second path enclose iterations governed by control structures in a corresponding box (alt for an if-then-else, opt for a an if-then, or a loop for a loop).

An article on IBM's developerworks.com provides a good starting point.

share|improve this answer
thanks for the explanation and for the link. I think I am starting "getting it", but just one thing which quite surprisingly is not covered in any tutorial I saw, but I think is crucial. How does one selects "the correct or the optimal" order of the objects (the boxes on top of the diagram). I think the correct order should make the diagram easier to draw and to read. By "order" I mean - do I just put the "actor" object to the left top corner, and then work down through the code and for each new (which is not on a diagram yet) object I put a new box to the left from the leftmost box. – PeterT Sep 26 '12 at 14:40
... this is what I call a "normal" order. However what if a optimal order is an order where the more frequently used object boxes (the objects with a most messages sent to them) are placed closest to the actor box? That should reduce the total lenght of the arrow and make the diagram less cluttered. Does it make sense? – PeterT Sep 26 '12 at 14:45
1  
@PeterT Reordering does not change the meaning of the diagram, only its visual appeal. Most tools should let you drag the objects after finishing the diagram, letting you improve the visual "flow" of the diagram. – dasblinkenlight Sep 26 '12 at 14:59
up vote 3 down vote

There are number of different tutorials and materials on this topic. I think the followings might be good considerations for new starters:

share|improve this answer
up vote 1 down vote

Apart from reading up on the diagrams themselves, f.ex. here or there, and getting some experience by drawing them from existing code, I would like to add a few more interesting options:

  • Verify your diagrams by using conformant tools, or if you're brave enough by consulting the standard. It is very easy to make a mistake and draw arrows of the wrong type, or connecting the wrong things. The standard is pretty strict on that, and while most people will be able to understand your diagram, there is the slight - but very dangerous - chance that it'll throw off people who do know the standard and do interpret your diagram in a much different way.

  • Go the other way round and instead of recovering diagrams from code use them up front. It just so happens to be the normal use-case for these diagrams as well. When you are thinking about a software architecture/design/sequence/state machine/etc. make a UML diagram first. You will soon see that visualizing your thoughts this way allows you to think through it in more detail (simply, because your brain can free processing power as it need not fear that what is already on paper may be forgotten in the process).

  • Once you're more familiar with the diagrams themselves you should start to learn to grasp the power of actual modeling. Some UML diagrams are useful in themselves, even if just as a discussion guideline, the real power shows with proper modeling and code generation. There is a huge difference between drawing a UML state machine, then putting that drawing aside and writing some custom code, as opposed to modelling the state machine and generating code that is faithful to this model - and this difference does not show immediately, but several months down the road.

share|improve this answer
I would actually say the only reason to study the UML standards is to ensure you are obviously non-conformant. Diagrams should be subjected to a common-sense interpretation that will allow all parties to follow it in the same way, the standards ensure your audience is split into 2 parties with 2 different interpretations. If you ensure people who know the standard see your diagram is non-conformant, you can be sure they'll use the same common-sense interpretation that people who don't know the standards use. These standards should have never existed. – Jimmy Hoffa Sep 24 '12 at 18:24
You forgot one "party": programs. These standards make a lot of sense when coming from the modeling direction. – Frank Sep 24 '12 at 18:41

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