Sequence Diagram Guidelines revisited

Posted:   |  More posts about uml

  • Strive for left-to-right ordering of messages.
    And if you need to put right-to-left non-return message - consider using another instance of the swimline
  • Layer classifiers
  • Give an actor the same name as a class, if necessary.
    We are not dealing with classes in sequence diagrams, so give name to the instance of the actor's class.
  • Include a prose description of the logic.
    Not always needed, but helps in complicated places.
  • Place proactive system actors on the left-most side of your diagram.
    Actors are always start interactions. This is whe they called actors - they act.
  • Place reactive system actors on the right-most side of your diagram.
    No actors in the right side of the diagram at all. This is the rule!
  • Avoid modeling object destruction.
    Model object destruction freely if it whats you modeling.
  • Don’t sweat activation boxes.
    Again - if it is required you have to model it. Don't leave it for developer to decide.
  • Name objects when you reference them in messages.
    Don't do it. It will add much more complexity to the message signatures with no added value.
  • Name objects when several of the same type exist.
    Name all objects. This is what developer will do anyway.
  • Apply textual stereotypes to classifiers consistently.
  • Apply visual stereotypes sparingly.
  • Focus on critical interactions.
  • Justify message names beside the arrowhead.
    Don't waste your time. This will not be appreciated.
  • Create objects directly.
    Is there another way? I think not.
  • Apply operation signatures for software messages.
  • Apply prose for messages involving human and organization actors.
  • Prefer names over types for parameters.
    This is true, but you should also set the types for all parameters too.
  • Indicate types as parameter placeholders.
  • Apply the > stereotype for use case invocations.
    No use case invocations in sequence diagrams! It is possible, but will not help developer. Remember: sequence diagram is for developers.
  • Do not model obvious return values.
    Model them! Let developer know that return value is expected.
  • Model a return value only when you need to refer to it elsewhere on a diagram.
    Model it everywhere.
  • Justify return values beside the arrowhead.
    Waste of time!
  • Model return values as part of a method invocation.
    Before it was said that we don't have to model return values and not we need to model them? As I said - model return values all time.
  • Indicate types as return-value placeholders.
    Model them in the method signature.
  • Indicate the actual value for simple return values.
    Indicate the type of the return value. Anything else goes into comments.
Contents © 2013 Aleksey Maksimov - Powered by Nikola