Does the sequence diagram have a mission statement?
Preconditions describe the starting point for the scenario execution and the assumptions being made. Post-conditions are
things that are true after the end of the scenario, such as object states and values of variables. The pre- and
post-conditions should be visible on the diagram; this is often done with a comment in the upper left- or right-hand corner
of the diagram. |
Does each use case have at least three scenarios?
A common use for a scenario is to describe a specific system-actor interaction performed while executing a use case. There
should be no less than three such scenarios, although one or two dozen is more common. More than 50 might result in
decomposing the use cases into smaller pieces. |
Does each scenario have at least three messages?
Scenarios may be highly complex but some people err on the side of making the scenarios so trivial that they add no value.
For example, a sequence diagram that shows a single message "TurnOn()" adds no value. In this case, either go into more
detail about what turning on the system means or add this an a first step in a more complex scenario that initializes the
system. |
Does the scenario show a proper sequence of messages?
Are all sequence diagram operators not nested more than three deep?
UML 2.0 added sequence diagram operators. While they significantly improve the rigor of the diagrams, they are easily and
often overused. |
Do messages show parameter and return values?
To understand the specific scenario, it is often necessary to know the data being passed in or out of the services invoked
by the messages. |
Does the lifeline decomposition show the scenario at a deeper level of detail?
Lifeline decomposition is an addition in UML 2 that allows a scenario to be viewed at different levels of abstraction.
Lifeline decomposition should be used to show how the internal parts of the element represented by the lifeline collaborate
in the same scenario. |
Is the ENV lifeline used to glue together scenarios at different levels of abstraction?
Since lifeline decomposition shows the same scenario at different levels of detail, there must be a means by which messages
shown at the higher level enter into the lower level decomposed lifeline. This is done by creating the sequence diagram for
the decomposed lifeline and using the ENV (environment) lifeline. Messages entering the lifeline in the higher-level
scenario exit the ENV lifeline at the lower level. Messages leaving the lifeline in the higher-level scenario enter the ENV
lifeline at the lower level. |
Are Execution Occurrences used infrequently?
Execution occurrences are rectangles placed on the line to show the execution resulting from reception of an incoming
message. These only make sense in strictly sequential flows but normally different lifelines may execute in different
threads. Generally, the use of execution occurrences should be avoided. |
Do the scenarios contain relevant quality of service constraints?
Messages, sets of messages, lifelines, and other elements should have quality of service constraints added as appropriate. |
Is time used as an actor?
Time should be depicted as a messages-to-self on some lifeline. Time is not an executable element and is therefore not an
actor. Occasionally, when using less capable tools to capture highly detailed design scenarios, you may use a timer as a
lifeline and use it to initiate time-events. However, this should never be done in a scenario in the use case or PIM
models. |
|