...
- CanonicalCourse - Aspects of a course that stay the same across instances of a course. The CanonicalCourse exists whether there's any instances of the course or not. Includes a name, a department, a title, a number, a description, and cross-listed CanonicalCourses, among other things.
Note icon false Ray: Craig pointed out in email that we may need to take versioning into account, so that old CourseOfferings don't end up bringing out newly revised CanonicalCourse data. Another approach would be templating the interface – - that is, letting the CourseOffering effectively subclass CanonicalCourse, including its properties. Behind the scenes, the implementation could still use versioning. The essential point at the interface level is that our logic needs to decide whether two CourseOfferings are instances of the "same" CanonicalCourse by using a CanonicalCourse ID rather than full object equality.
...
- CourseOffering - An instance of a course. Includes a name, default instructors and possibly other Memberships, a Terman AcademicSession, Sections, EnrollmentSections, and cross-listed CourseOfferings.
...
- EnrollmentSet - This lets the LMS/CMS/CLE ask the question "Who is allowed to submit the final grade for this student, and what is the grade for?" Includes Enrollments, official graders, a CourseOffering, and an enterprise integration ID. Every Enrollment appears in one and only one EnrollmentSet. In contrast, any student might have Memberships in any number of Sections. An EnrollmentSet is often very tightly associated with a Section. This is a common enough case that we may find it worthwhile to create an "EnrollmentSection" to combine the two interfaces. At UC Berkeley, the type of Section associated with an EnrollmentSet is called a "Primary Section". At some other schools, it's just called a "Section". At some institutions (U. Arizona and UC Davis, for example) a single student might be in multiple EnrollmentSets for a single CourseOffering (and therefore receive multiple final grades from different instructors for a single course). At still other institutions, there's just one EnrollmentSet for the whole course: students enroll in the course and pick their sections afterwards. In either case, users tend not to think of the EnrollmentSet as a separate object, but instead identify it with the associated Section or CourseOffering attributes.
Note icon false Ray: In our last face-to-face, we went back and forth for a while about whether EnrollmentSet should be expressed as an extension of Section or should be expressed as its own interface. Practically speaking, most of the use cases we'd examined strongly associated EnrollmentSets with sections, and so the logic might be simplified if we could talk about them as one thing. We don't want to end up with a situation in which we show the instructor a list containing both "LECT 1" (the section) and "LECT 1" (the enrollment set). However, my first attempt to describe this as a subtype of Section caused confusion of its own, and we do have cases in which EnrollmentSets are associated with a CourseOffering rather than with any particular section. Therefore I'm now trying it the other way.