Once we've settled on an initial candidate class list, the next step is to determine how these classes are interrelated. To do this, we go back to our narrative documentation set (which has grown to consist of the SRS requirements specification, use case descriptions, and data dictionary) and study verb phrases this time. These verb phrases indicate the capabilities or functions that the classes will have to implement. Our goal in looking at verb phrases is to choose those that suggest structural relationships, as were defined in Chapter 5—associations, aggregations, and inheritance—but to eliminate or ignore those that represent (transient) actions or behaviors. (We'll focus on behaviors, but from the standpoint of use cases, in Chapter 11.)
For example, the specification states that a student "chooses a faculty advisor." This is indeed an action, and the result of this action is a lasting structural relationship between a professor and a student, which can be modeled via the association "a professor advises a student."
On the other hand, as a student's advisor, a professor also meets with the student, answers the student's questions, recommends courses for the student to take, approves his or her plan of study, and so on—these are behaviors on the part of a professor acting in the role of an advisor, but don't directly result in any new relationships being formed between objects.
Let's try the verb phrase analysis approach on the requirements specification. We've highlighted all relevant verb phrases in the sidebar that follows (note that we omitted such obviously irrelevant verb phrases as "We've been asked to develop an automated SRS . . .").
Let's scrutinize a few of these:
"Students [. . .] register [. . .] for courses": Although the act of registering is a behavior, the end result is that a static relationship is created between a Student and a Section, as represented by the association "a Student registers for a Section." (Note that the specification mentions registering for "courses," not "sections," but as we stated in our data dictionary, a Student registers for concrete Sections as specific types of Courses.) Keep in mind when reviewing a specification that natural language is often imprecise, and that as a result we have to read between the lines as to what the author really meant in every case. (If we're going to be the ones to write the specification, here is an incentive to keep the language as clear and concise as possible!)
"[Students track] their progress toward completion of their degree": Again, this is a behavior, but it nonetheless implies a structural relationship between a Student and a Degree. However, recall that we didn't elect to represent Degree as a class—we opted to reflect it as a simple string field of the Student class—and so this suggested relationship is immaterial with respect to the candidate class list that we've developed.
"Student first enrolls at the university": This is a behavior that results in a static relationship between a Student and the University; but we deemed the notion of "university" to be external to the SRS system and so chose not to create a University class in our model. So, we disregard this verb phrase, as well.
"[Student] sets forth a plan of study": This is a behavior that results in the static relationship "a Student pursues/follows a Plan of Study."
"Students are able to view the schedule of classes online": This is strictly a transient behavior of the SRS; no lasting relationship results from this action, so we disregard this verb phrase.
Another complementary technique for both determining and recording what the relationships between classes should be is to create a two-dimensional association matrix, where the rows and columns of the matrix are labeled with the candidate classes that we identified, as shown in Table 10-1.
Section | Course | PlanOfStudy | Professor | Student | Transcript | |
Section | ||||||
Course | ||||||
PlanOfStudy | ||||||
Professor | ||||||
Student | ||||||
Transcript |
To complete the matrix, list all the associations in each cell that you can identify between the class named at the head of the row and the class named at the head of the column. For example, in the cell highlighted in Table 10-2 at the intersection of the Student row and the Section column, we have listed three potential associations:
A Student is waitlisted for a Section.
A Student is registered for a Section (this could be alternatively phrased as "a Student is currently attending a Section").
A Student has previously taken a Section: This third association is important if we plan to maintain a history of all the classes a student has ever taken in his or her career as a student, which we must do if we are to prepare a student's transcript online. (As it turns out, we'll be able to get by with a single association that does "double duty" for the latter two of these—as you'll see later on in this chapter.)
Mark a cell with an X if there are no known relationships between the classes in question or if the potential relationships between the classes are irrelevant. For example, we marked the cells representing the intersection between Professor and Course with an X, even though there is an association possible—a Professor is qualified to teach a Course—because it isn't relevant to the mission of the SRS.
We mentioned in Chapter 4 that all associations are inherently bidirectional. This implies that if a cell in row j, column k indicates one or more associations, then the cell in row k, column j should reflect the reciprocal of these relationships. For example, because the intersection of the PlanOfStudy row and the Course column indicates that a PlanOfStudy calls for a Course, the intersection of the Course row and the PlanOfStudy column must indicate that a Course is called for by a PlanOfStudy.
It's not always practical to state the reciprocal of an association; for example, our association matrix shows that a Student plans to take a Course, but trying to state its reciprocal—a Course is planned to be taken by a Student—is quite awkward. In such cases where a reciprocal association would be awkward to phrase, simply indicate its presence with the check mark symbol.
Section | Course | PlanOfStudy | Professor | Student | Transcript | |
Section | × | example of | × | is taught by | ✓ | included in |
Course | ✓ | prerequisite for | is called for by | × | ✓ | × |
PlanOfStudy | × | calls for | × | × | observed by | × |
Professor | teaches | × | × | × | advises; teaches | × |
Student | waitlisted for; registered for; has previously taken | plans to take | follows | is advised by; studies under | × | owns |
Transcript | includes | × | × | × | belongs to | × |
We'll be portraying these associations in graphical form shortly! For now, we'd want to go back and extend our data dictionary to explain what each of these associations means; the following is one such example.