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).
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.
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.