Fundamentals of UML Diagrams
A diagram is the graphical presentation of a set of elements. UML has a lot of different diagrams. Read this section, and make sure you can differentiate between different diagrams.
3. Using the <> relationship
3.2. Sequence Diagrams
A sequence diagram is an interaction diagram that emphasizes the time-ordering of messages. Sequence diagrams focus on the order in which the messages are sent. They provide a sequential map of messages passing between objects over time. The Sequence Diagrams
are driven by the Use Cases which are the system requirements. In this form objects are shown as vertical lines with the messages as horizontal lines between them. The sequence of messages is indicated by reading down the page (read left to right
and descending). Sequence Diagrams are about deciding and modelling "how" the system will achieve "what" we described in the Use Case model.
Although there is no fixed recipe for developing Sequence Diagrams, we can follow an approach that will result in a logical sequence diagram. This is as follows:
- Take the Use Case description and turn it into simple pseudo code running down the right hand side of the State Diagram.
- Guess which classes you think might be involved - based on the content of the Use Case description. Simple noun analysis is as good a way to start as any.
- For each of the steps in you pseudo code, decide which of the classes should have the responsibility for doing that task.
- For each of those tasks, you may want to go back and decide to break them down into a number of simpler tasks.
- Add in probes that correspond to the "uses (includes)" and "extends" relationships in the Use Case diagram.
- Consider any important errors you might have to handle that perhaps weren't covered in the Use Case model.
- Consider whether anything you have discovered needs to be fed-backed into the Use Case model.
An analysis of the Sequence Diagrams shows the following (Shown in Figure 2.8):
i. A Class (Figure 2.8(a))
- Participates in a sequence by sending and/or receiving messages
- Is placed at the top of the diagram and is shown using a rectangle with a descriptive name.
ii. A Lifeline (Figure 2.8(b))
- Denotes the life of an object during a sequence
- Is a dotted vertical line below each class.
iii. A focus of control (Figure 2.8(c))
- Is a long, narrow rectangle placed atop a lifeline
- Denotes when an object is sending or receiving messages
iv. A message (Figure 2.8(d))
- Conveys information from one object to another object
- Is depicted using a horizontal arrow labeled with the message description and applicable parameters.
Example of a "Make a Cup of Tea" sequence diagram generated from its corresponding use
case description is as shown in Figure 2.9.
Figure 2.9: A Sequence Diagram for "Make a Cup of Tea" Use Case