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 "harvest" 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
```
bool VerifyCompletion(Course c)
```
instead, 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 of the course requirements necessary to graduate. (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 accurately self-documenting.)
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, since 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 may either represent private "housekeeping" methods or public methods that other client objects may avail themselves of.

In looking at our sequence diagram for Scenario #1 from a few pages back, we note the arrows in Table 11-2.

Table 11-2: Determining the Methods Implied by Scenario #1
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 3 of the book.)
request display of schedule	`Schedule OfClasses`	Request	`void Display()`
schedule displayed	`Student`	Response	N/A
request seat	`Section`	Request	`bool Enroll(Student s)`
verify plan of study	`PlanOfStudy`	Request	`bool VerifyPlan(Course c)`
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 may not surface until we've begun to program our classes; this is to be expected.