|
|
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 cases, and data dictionary) and study verb phrases this time. 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, but 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."
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, etc.—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 …").
 |
We have been asked to develop an automated Student Registration System (SRS) for the university. This system will enable students to register online for courses each semester, as well as track their progress toward completion of their degree.
When a student first enrolls at the university, he/she uses the SRS to set forth a plan of study as to which courses he/she plans on taking to satisfy a particular degree program, and chooses a faculty advisor. The SRS will verify whether or not the proposed plan of study satisfies the requirements of the degree that the student is seeking.
Once a plan of study has been established, then, during the registration period preceding each semester, students are able to view the schedule of classes online, and choose whichever classes he/she wishes to attend, indicating the preferred section (day of the week and time of day) if the class is offered by more than one professor. The SRS will verify whether or not the student has satisfied the necessary prerequisites for each requested course by referring to the student's online transcript of courses completed and grades received (the student may review his/her transcript online at any time).
Assuming that (a) the prerequisites for the requested course(s) are satisfied, (b) the course(s) meet(s) one of the student's plan of study requirements, and (c) there is room available in each of the class(es), the student is enrolled in the class(es).
If (a) and (b) are satisfied, but (c) is not, the student is placed on a first-come, first-served wait list. If a class/section that he/she was previously waitlisted for becomes available (either because some other student has dropped the class or because the seating capacity for the class has been increased), the student is automatically enrolled in the waitlisted class, and an email message to that effect is sent to the student. It is his/her responsibility to drop the class if it is no longer desired; otherwise, he/she will be billed for the course.
Students may drop a class up to the end of the first week of the semester in which the class is being taught.
|
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 embodiments 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 attribute 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 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/observes 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.
and so on.
Another complementary technique for both determining and recording what the relationships between classes should be is to create an n ?n association matrix, where n represents the number of candidate classes that we've identified. Label the rows and the columns with the names of the classes, as shown for the empty matrix represented by Table 10-1.
| ?/td> |
Section |
Course |
PlanOfStudy |
Professor |
Student |
Transcript |
|
Section | ?/td> | ?/td> | ?/td> | ?/td> | ?/td> | ?/td> |
|
Course | ?/td> | ?/td> | ?/td> | ?/td> | ?/td> | ?/td> |
|
PlanOfStudy | ?/td> | ?/td> | ?/td> | ?/td> | ?/td> | ?/td> |
|
Professor | ?/td> | ?/td> | ?/td> | ?/td> | ?/td> | ?/td> |
|
Student | ?/td> | ?/td> | ?/td> | ?/td> | ?/td> | ?/td> |
|
Transcript | ?/td> | ?/td> | ?/td> | ?/td> | ?/td> | ?/td> |
Then, complete the matrix as follows.
In each cell of the matrix, list all of the associations 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 on maintaining a history of all of the classes that 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 we'll see later on in this chapter.)
| ?/td> |
Section |
Course |
PlanOfStudy |
Professor |
Student |
Transcript |
|
Section |
?/p> |
instance of |
?/p> |
is taught by |
✓ |
included in |
|
Course |
✓ |
prerequisite for |
is called for by |
?/p> |
✓ |
?/p> |
|
PlanOfStudy |
?/p> |
calls for |
?/p> |
?/p> |
observed by |
?/p> |
|
Professor |
teaches |
?/p> |
?/p> |
?/p> |
advises; teaches |
?/p> |
|
Student |
registered for; waitlisted for |
plans to take; has previously taken |
observes |
is advised by; studies under | ?/td> |
owns ?/i> |
|
Transcript |
includes |
?/p> |
?/p> |
?/p> |
belongs to |
?/p> |
Mark a cell with an ?if there are no known relationships between the classes in question, or if the potential relationships between the classes are irrelevant. For example, we've marked the cells representing the intersection between Professor and Course with an ? 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, since the intersection of the PlanOfStudy "row" and the Course "column" indicates that "a PlanOfStudy calls for a Course," then 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 symbol √.
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; here's one such example:
|
Calls for (a Plan of Study calls for a Course): In order to demonstrate that a student will satisfy the requirements for his or her chosen degree program, the student must formulate a plan of study. This plan of study lays out all of the courses that a student intends to take, and possibly specifies in which semester the student hopes to complete each course.
|
To determine what the attributes for each of our domain classes should be, we make yet another pass through the requirements specification looking for clues. We already stumbled upon a few attributes earlier, when we weeded out some nouns/noun phrases from our candidate class list:
For the Section class, we identified "day of week", "room", "seating capacity", "semester", and "time of day" as attributes.
For the Student class, we identified "degree" as an attribute.
We can also bring any prior knowledge that we have about the domain into play when assigning attributes to classes. Our knowledge of the way that universities operate, for example, suggests that all students will need some sort of student ID number as an attribute, even though this isn't mentioned anywhere in the SRS specification. We can't be sure whether this particular university assigns an arbitrary student ID number, or whether the policy is to use a student's social security number (SSN) as his or her ID; these are details that we'd have to go back to our end users for clarification on.
Finally, we can also look at how similar information has been represented in existing legacy systems for clues as to what a class's attributes should be. For example, if a Student Billing System already exists at the university based on a relational database design, we might wish to study the structure of the relational database table housing student information. The columns that have been provided in that table—name, address, birthdate, etc.—are logical attribute choices.
|
|