Sequence Diagram - Checklist
o FLOWS
 If a use case creates/updates/deletes an object in a class, consider whether an
object in an associated class is also created/updated/deleted.
 The object that receives the initial (trigger) message may require data from other
objects to respond.
 Messages to/from actor should follow same sequence as basic flow. Scenarios
should not include more/less interaction than is shown on diagrams.
 Alternative flows in use case scenarios should have corresponding guard
conditions on diagrams.
o NOTATION
 Included and Extended use cases should be shown as a message to the object that
handles that use case, using the same name as use case.
 Use activation lifelines (rectangles) to show created and deleted objects.
 Show object deletion with an X on the activation lifeline (‘delete member’,
‘delete resume’)
 The class that has the data as attributes should be the class to get the triggering
(first) message. (eg, ‘add user’ would be handled by the Users class) Don’t
include user interface objects at this stage of analysis. Don’t confuse actors with
classes.
o BALANCE
 All objects should be the same as on the class diagram.
 Values and parameters on the OID should match attributes on the class diagram.