Sequence Diagram

---

We use sequence diagrams to show interactions between objects related to our system or software application. You can use these diagrams to detail the scenarios for each use case. The sequence diagram shows a small group of objects and the events (important moments in time) being passed between the objects. As time passes, you show each event in sequence, moving down the page of the diagram.

 Warning   Don’t try to show how your objects collaborate by using a sequence diagram during analysis. Some developers use the sequence diagram to show how their programs work before they clearly understand the requirements. You can avoid this mistake by showing when an object must notify another object that an important moment has arrived.

Don’t try to show thirty-object instances across the top of a sequence diagram. We’ve seen this done—it isn’t pretty. You should have between two and eight objects on a single sequence diagram—no more. That way, the diagram doesn’t get too cluttered.

We like to build two levels of sequence diagrams during analysis:

• High-level sequence: To focus on a use case, we show a sequence diagram with just the actor objects and an object representing the system. These diagrams, each showing no more than two or three objects, are a graphical way of relating the text of a use-case description. This type of sequence diagram gives a high-level view of events and of the order in which they come into and go out of our system.

• Application-level sequence: For each use case, we build application-level sequence diagrams. For each high-level sequence diagram, we substitute the actor objects with application objects such as view, boundary, and device objects. These are the objects that the users will actually interact with. We replace the system object with some kind of controller or manager object.

 Tip   If you want to show object collaboration during design, use a communication diagram and not a sequence diagram.

---