11.4. Using Sequence Diagrams to Determine Methods
Now that we've prepared a sequence diagram, how do we put the information that it contains to good use? In particular, how do we extract information from such diagrams concerning the methods that the various classes need to implement?
The process is actually quite simple. We step through the diagram, one lifeline at a time, and study all arrows pointing into that line.
Arrows representing a new request being made of an object—solid-line arrows—signal methods that the receiving object must be able to perform. For example, we see a solid-line arrow labeled "check prerequisite" pointing into the lifeline representing a Transcript object. This tells us that the Transcript class needs to define a method that will allow some client object to pass in a particular course object reference, and receive back a response indicating whether or not the Transcript contains evidence that the course was successfully completed.
We're free to name our methods in whatever intuitive way makes the most sense, consistent with the method naming conventions discussed in Chapter 4. We're using the method in this particular scenario to check completion of a prerequisite course, so we could declare the method as follows:
bool CheckPrerequisite(Course c)
But this name is unnecessarily restrictive; what we're really doing with this method is checking the successful completion of some Course c; the fact that it happens to be a prerequisite of some other course is immaterial to how this method will perform. So, by naming the method instead, as follows, we'll be able to use it anywhere in our application that we need to verify successful completion of a course—for example, when we check whether a student has met all the course requirements necessary to graduate:
bool VerifyCompletion(Course c)
Of course, we could have still used the method in this fashion even if it had been named CheckPrerequisite, but then our code would be less transparent to readers.
Arrows representing responses from an operation that some other object has performed—dashed-line arrows—don't get modeled as methods/operations. These do, however, hint at the return type of the method from which this response is being issued. For example, because the response to the "verify plan of study" message is "plan of study verified," this would imply that the method is returning a bool result, hence we'd declare a method header as follows:
bool VerifyPlan(Course c)
Loops also represent method calls, performed by an object on itself; these might either represent private "housekeeping" methods or public methods that other client objects can avail themselves of.
In looking at the sequence diagram for Scenario #1 from a few pages back, note the arrows in Table 11-2.
| Arrow Labeled | Drawn Pointing into Class X | A New Request or a Response to a Previous Request? | Method to Be Added to Class X |
|---|---|---|---|
| log on | Student | Request | A method to reconstitute this object from persistent storage, such as a file or database; perhaps a special form of constructor—we'll discuss this in Part Three of the book. |
| request display | ScheduleOfClasses | Request | void Display() of schedule. |
| schedule displayed | Student (Actor) | Response | N/A. |
| request seat | Section | Request | bool Enroll(Student s). |
| verify plan | PlanOfStudy | Request | bool VerifyPlan(Course c) of study. |
| plan of study verified | Section | Response | N/A. |
| check prerequisite | Transcript | Request | bool VerifyCompletion(Course c). |
| prerequisite confirmed | Section | Response | N/A. |
| confirm seat availability | Section | Request | bool ConfirmSeatAvailability() (perhaps a private housekeeping method). |
| add to course load | Student | Request | void AddSection(Section s). |
| display message confirming seat | (actor/user) | Response | N/A. Will eventually involve calling upon some method of a user interface object—we'll worry about this in Part Three of the book. |
Thus we have identified six new "standard" methods plus one constructor that will need to be added to our class diagram; we'll do so shortly.
Repeating this process of sequence diagram production and analysis for various other use case/scenario combinations will flush out most of the methods that we'll need to implement for the SRS. Despite our best efforts, however, a few methods might not surface until we've begun to program our classes; this is to be expected.