11.3. Sequence Diagrams
Sequence diagrams are one of two types of UML interaction diagrams (we'll explore the second type, collaboration diagrams, a bit later in this chapter). Sequence diagrams are a way of graphically portraying how messages should flow from one object to another in carrying out a given scenario.
We'll illustrate the process of creating a sequence diagram by creating one for Scenario #1 of the "Register for a Course" use case, which was presented in Chapter 9.
11.3.1.
11.3.1.1. Determining Objects and External Actors for Scenario #1
To prepare a sequence diagram, we must first determine the following:
Which classes of objects (from among those that we specified in the static model [class diagram] in Chapter 10) are involved in carrying out a particular scenario
Which external actors are involved
Looking back at Scenario #1 for the "Register for a Course" use case, we determine that the following objects are involved:
One Student object (representing Fred)
One Section object (representing the course titled "Beginning Computer Technology," course number CMP101, section 1)
One PlanOfStudy object, belonging to Fred
One Transcript object, also belonging to Fred
The scenario also mentions that the student "views the schedule of classes for the current semester to determine which section(s) he wants to register for." You might recall that when we were determining what our candidate classes should be back in Chapter 10, we debated whether or not to add ScheduleOfClasses as a candidate class to our model, and elected to leave it out at that time. To fully represent the details of Scenario #1, we'll reverse that decision and retrofit ScheduleOfClasses into our UML class diagram now as follows:
We'll show ScheduleOfClasses participating in a one-to-many aggregation with the Section class because one ScheduleOfClasses object will be instantiated per semester to represent all the sections that are being taught that semester. (It's an abstraction of the paper booklet or online schedule that students look at in choosing which classes they want to register for in a given semester.)
We'll also transfer the semester field from the Section class to ScheduleOfClasses. Because each Section object will now be maintaining a reference to its associated ScheduleOfClasses object by virtue of the aggregation relationship between them, a Section object will be able to request semester information whenever it is needed.
The results of these changes to the class diagram are highlighted in Figure 11-7.
Figure 11.7. Fine-tuning the UML diagram
Representing ScheduleOfClasses as a class in our model allows us to now reference a ScheduleOfClasses object in our sequence diagram, as you'll see in a moment. Scenarios often unearth new classes, fields, and relationships, thus contributing to our structural "picture" of the system; this is a common occurrence and is a desirable side effect of dynamic modeling.
Of course, we must remember to add a definition of ScheduleOfClasses to our data dictionary!
NOTE
What is the schedule of classes? It is a list of all course sections that are being offered for a particular semester; students review the schedule of classes to determine which sections they want to register for.
Finally, because the scenario explicitly mentions interactions between the student user and the system, we'll represent Fred the actor separately from Fred the object. Doing so will allow us to represent the SRS interacting with the user, as well as showing the system's internal object-to-object interactions. We refer to an object that represents an abstraction of an actor as an instance of a boundary class.
Our adjusted list of object/actor participants is now as follows:
One Student object (representing Fred)
One Section object (representing the course titled "Beginning Objects," course number CMP101, section number 1)
One PlanOfStudy object, belonging to Fred
One Transcript object, also belonging to Fred
One ScheduleOfClasses object
One Student actor (Fred again!)
11.3.1.2. Preparing the Sequence Diagram
To prepare a sequence diagram for Scenario #1, we do the following:
We draw vertical dashed lines, one per object or actor that participates in the scenario; these are referred to as the objects' lifelines. Note that the objects/actors can be listed in any order from left to right in a diagram, although it's common practice to place the external user/actor at the far left.
At the top of each lifeline, as appropriate, we place either an instance icon—that is, a box containing the (optional) name and class of an object participant—or a stick figure symbol to designate an actor. (For rules governing how an instance icon is to be formed, please refer to the section on creating object diagrams in Chapter 10.)
Then, for each event called out by our scenario, we reflect its corresponding message as a horizontal solid-line arrow drawn from the lifeline of the sender to the lifeline of the receiver.
Responses back from messages (in other words, return values from methods, or simple return; statements in the case of methods declared to have a void return type) are shown as horizontal dashed-line arrows drawn from the lifeline of the receiver of the original message back to the lifeline for the sender of the message.
Message arrows appear in chronological order from top to bottom in the diagram.
The completed sequence diagram for Scenario #1 is shown in Figure 11-8.
Figure 11.8. Sequence diagram for Scenario #1
Let's step through the diagram to make sure that we understand all the activities that are reflected in the diagram.
When Fred logs on to the system, his "alter ego" as an object is activated (see Figure 11-9).
Figure 11.9. When Fred logs on, a Student object is created.
NOTE
Presumably, information representing each Student—in other words, the Student object's field values—is maintained offline in persistent storage, such as a database management system (DBMS) or file, until such time as he or she logs on, at which time the information is used to instantiate a Student object in memory, mirroring the user who has just logged on. We'll talk about reconstituting objects from persistent storage in Chapter 15.
When Fred the user/actor requests that the semester class schedule be displayed, we reflect the message "request display of schedule" being sent to an anonymous ScheduleOfClasses object. The dashed-line arrow response from the ScheduleOfClasses object indicates that the schedule is being displayed to the user, strictly speaking, via a GUI (see Figure 11-10).
Figure 11.10. As requested, a schedule of classes is displayed.
The next message shown in our diagram is a message from the user to the Section object, requesting a seat in the class.
NOTE
This message is shown originating from the user; in reality, it originates from a GUI component object of the SRS GUI, but we aren't worrying about such implementation details at this stage in the analysis effort. We'll talk about the OO aspects of GUI design and event processing in depth in Chapter 16.
Note that there is no immediate reply to this message; that's because the Section object has a few other objects that it needs to consult with before it can grant a seat to this student, namely the following:
The Section sends a message to the object representing Fred's plan of study, asking that object to confirm that Fred is permitted to take the course.
The Section next sends a message to the object representing Fred's transcript, asking that object to confirm that a prerequisite course—say OBJ 001—has been satisfactorily completed by this student.
Assuming that both of these other objects respond favorably, as they are expected to do by virtue of how this scenario was written, the Section object then performs some internal processing to verify that there is indeed room for Fred in this section. We reflect internal processing within a single object as an arrow that loops back to the same lifeline that it starts with, as shown in Figure 11-11.
Figure 11.11. Availability of the requested section is confirmed.
Of course, if we were to reflect all the internal processing that is performed by every one of the objects in our sequence diagram, it would be flooded with such loops! The only reason that we chose to show this particular loop is because it's explicitly called out as a step in Scenario #1; if we had omitted it from our diagram, it might appear that we had accidentally overlooked this step.
Finally, with all checks having been satisfied, the Section object has two remaining responsibilities:
First, it sends a new message to the Fred Student object, requesting that the Student object add this Section object to Fred's course load.
Next, the Section object sends a response back to Fred the user/actor (via the GUI) confirming his seat in the section. This is the response to the original "request seat" message that was sent by the user toward the beginning of the scenario! All the extra behind-the-scenes processing necessary to fulfill the request—involving a Section object collaborating with a PlanOfStudy object, a Transcript object, and a Student object—is invisible to the user. As you saw earlier in the chapter, Fred merely selected a section from the schedule of classes that was displayed on the SRS GUI, clicked the Add button, and saw a confirmation message appear on his screen a few moments later.
Of course, as with all modeling, this particular sequence diagram isn't necessarily the best or only way to portray the selected scenario. And for that matter, one can argue the relative merits of one scenario as compared with another. It's important to keep in mind that preparing sequence diagrams is but a means to an end: namely, discovering the dynamic aspects of the system to be built—that is, the methods—to complement our static/structural knowledge of the system.
Recall that our ultimate goal for Part Two of the book is to produce an OO blueprint that we can use as the basis for coding the SRS as a C# application in Part Three. But, as we've already pointed out, the class diagram that we created in Chapter 10 had a noticeable deficiency: all of its classes' operations compartments were empty. Fortunately, sequence diagrams provide us with the missing pieces of information.