|
|
Applying all that we've learned in this chapter about static modeling, we've produced the UML class diagram for the SRS shown in Figure 10-56. Of course, as we've said repeatedly, this isn't the only correct way to model the requirements, nor is it necessarily the "best" model that we could have produced; but it is an accurate, concise, and correct model of the static aspects of the problem to be automated.
We opted to use the "generic" many notation (* for UML) rather than specifying 0..* or 1..*; this is often adequate during the initial modeling stages of a project.
Note that we've reflected two separate many-to-many associations between the Student and Section classes: waitlisted for and attends. A given Student may be waitlisted for many different Sections, and he or she may be registered for/attending many other Sections. What this model doesn't reflect is the fact that a Student is not permitted to simultaneously be attending and waitlisted for the same Section. Constraints such as these can be reflected as textual notes on the diagram, enclosed in curly braces, or can be omitted from the diagram but spelled out in the data dictionary. In the diagram excerpt in Figure 10-57, we use the annotation [ xor ] to represent an "exclusive or" situation between the two associations: a Student can either be waitlisted for or attending a given Section, but not both.
As mentioned earlier in this chapter, we're able to get by with a single attends association to handle both the Sections that a Student is currently attending, as well as those that he or she has attended in the past. The date of attendance—past or present—is reflected by the "semester" attribute of the Section class; also, for any courses that are currently in progress, the value of the "grade" attribute of the TranscriptEntry association class would be as of yet undetermined.
We could have also reflected an association class on the waitlisted for association representing a given Student's position in the wait list for a particular Section, and then could have gone on to model the notion of a WaitList as an aggregation of WaitListEntry objects (see Figure 10-57).
Since we're going to want to use the object model to gain user confirmation that we understand his or her primary requirements, we needn't clutter the diagram with such behind-the-scenes implementation details just yet, however.
We also renamed the association class for the attends relationship; it was introduced earlier in this chapter as GradeReceived, but is now called TranscriptEntry. We've also introduced an aggregation relationship between the TranscriptEntry class and another new class called Transcript (see Figure 10-58).
Let's explore how all of this evolved.
When we first introduced the attends association earlier in this chapter, we portrayed it as shown in Figure 10-59.
We then learned that it could equivalently be represented as a pair of one-to-many associations issues and receives (see Figure 10-60).
In this alternative form, it's clear that any individual GradeReceived object maintains one handle on a Student object and another handle on a Section object, and can ask either of them for information whenever necessary. The Section object, in turn, maintains a handle on the Course object that it represents by virtue of the offered as association. It's a trivial matter, therefore, for the GradeReceived object to request the values of attributes semester, courseNo, courseName, and credits from the Section object (which would in turn have to ask its associated Course object for the last three of these four values); this is illustrated conceptually in Figure 10-61.
If the GradeReceived object pulls these values together, we have everything that we need for a line item entry on a student's transcript, as shown in Figure 10-62.
Therefore, we see that renaming the association class from GradeReceived to TranscriptEntry makes good sense. It was then a natural step to aggregate these into a Transcript class.
Our SRS diagram is a little "light" in terms of attributes; we've only reflected those that we'll minimally need when we build an automated SRS in Part Three.
Of course, we now need to go back to the data dictionary to capture definitions of all of the new attributes, relationships, and classes that we've identified in putting together this model. The following sidebar shows our revised SRS data dictionary.
 |
Classes
Course A semester-long series of lectures, assignments, exams, etc., that all relate to a particular subject area, and which are typically associated with a particular number of credit hours; a unit of study toward a degree. For example, Beginning Objects is a required course for the Master of Science degree in Information Systems Technology.
Person A human being associated with the university.
PlanOfStudy A list of the courses that a student intends to take to fulfill the course requirements for a particular degree.
Professor A member of the faculty who teaches sections or advises students.
Section The offering of a particular course during a particular semester on a particular day of the week and at a particular time of day. (For example, course Beginning Objects is taught in the Spring 2004 semester on Mondays from 1:00 to 3:00 p.m.).
Student A person who is currently enrolled at the university and who is eligible to register for one or more sections.
Transcript A record of all of the courses taken to date by a particular student at this university, including which semester each course was taken in, the grade received, and the credits granted for the course, as well as reflecting an overall total number of credits earned and the student's grade point average (GPA).
TranscriptEntry One-line item entry from a transcript, reflecting the course number and name, semester taken, value in credit hours, and grade received.
Advises: a professor advises a student A professor is assigned to oversee a student's academic pursuits for the student's entire academic career, leading up to his or her attainment of a degree. An advisor counsels his or her advisees regarding course selection, professional opportunities, and any academic problems the student might be having.
Attends: a student attends a section A student registers for a section, attends class meetings for a semester, and participates in all assignments and examinations, culminating in the award of a letter grade representing the student's mastery of the subject matter.
Calls for: a plan of study calls for a course A student may only take a course if it's called out by his or her plan of study. The plan of study may be amended, with a student's advisor's approval.
Maintains: a student maintains a transcript Each time a student completes a course, a record of the course and the grade received is added to the student's transcript.
Observes: a student observes a plan of study See notes for the calls for association.
Offered as: a course is offered as a section The same course can be taught numerous times in a given semester, and of course over numerous semesters for the "lifetime" of a course—that is, until such time as the subject matter is no longer considered to be of value to the student body, or there is no qualified faculty to teach the course.
Prerequisite: a course is a prerequisite for another course If it's determined that the subject matter of a course A is necessary background to understanding the subject matter of a course B, then course A is said to be a prerequisite of course B. A student typically may not take course B unless he or she has either successfully completed course A, or can otherwise demonstrate mastery of the subject matter of course A.
Teaches: a professor teaches a section A professor is responsible for delivering lectures, assigning thoughtful homework assignments, examining students, and otherwise ensuring that a quality treatment of the subject matter of a course is made available to students.
Waitlisted for: a student is waitlisted for a section If a section is "full"—for example, the maximum number of students have signed up for the course based on either the classroom capacity or the student group size deemed effective for teaching—then interested students may be placed on a wait list, to be given consideration should seats in the course subsequently become available.
(aggregation between Transcript and TranscriptEntry)
(specialization of Person as Professor)
(specialization of Person as Student)
Person.ssn The unique social security number (SSN) assigned to an individual
Person.name The person's name, in "last name, first name" order
Professor.title The rank attained by the professor, e.g., "Adjunct Professor"
Student.major A reflection of the department in which a student's primary studies lie—for example, Mathematics (We assume that a student may only designate a single major.)
Student.degree The degree that a student is pursuing, e.g., Master of Science degree
TranscriptEntry.grade A letter grade of A, B, C, D, or F, with an optional +/- suffix, such as A+ or C-
Course.courseNo A unique ID assigned to a course, consisting of the department designation plus a unique numeric ID within the department, for example, MATH 101
Course.courseName A full name describing the subject matter of a course, for example, Beginning Objects
Course.credits The number of units or credit hours a course is worth, roughly equating to the number of hours spent in the classroom in a single week (typically, 3 credits for a full semester lecture course)
Section.sectionNo A unique number assigned to distinguish one section/offering of a particular course from another offering of the same course in the same semester, for example, MATH 101 section no. 1
Section.dayOfWeek The day of the week on which the lecture course meets
Section.timeOfDay The time (range) during which the course meets, for example 2–4 p.m.
Section.semester An indication of the scholastic semester in which a section is offered—for example, Spring 2004
Section.room The building and room number where the section will be meeting—for example, Government Hall, Room 105
Section.seatingCapacity The maximum number of students permitted to register for a section
|
|
|
