July 26 2006
Sequence Diagram Guidelines revisited
- 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
Huh?
- 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.
