Retakes, Grades, and the Association Class Trap

Use a reified class (a plain class Enrollment with associations to Student and Course) rather than an association class, because a Student-Course pair can have multiple enrollments (retakes). An association class has at most one instance per link; with multiplicity 0..* on both ends, attaching Enrollment as an association class implies one enrollment per student-course pair, which contradicts the retake requirement. A qualified association can work if the qualifier is (term, attempt) or an enrollment ID: Student to Course with qualifier [term, attempt] and Enrollment as the qualified class. That is acceptable if the tool and team understand qualifiers, but it is less obvious to reviewers. The reified class makes the many-to-many link explicit, allows Enrollment to have its own identity and associations (for example, to Advisor for approval), and keeps history queryable. If you retain the association class notation, add the qualifier and a constraint stating the uniqueness rule.

Grade is a property of the enrollment, not of the Student: one student has many grades across courses and attempts. Moving grade to Student collapses history and makes it impossible to say which course or attempt a grade belongs to. CourseCode is an identifier of Course, not of the link; putting it on the association duplicates Course's identity and invites inconsistency. UML attributes belong to the classifier whose instances they describe, and association-owned attributes are only for data that exists because of the link. The proposal also loses term and attempt, so retake history disappears. The derived attribute Student.gpa should remain derived from Enrollment grades, not stored independently. The correct fix is to keep Enrollment as the owner of term, attempt, grade, and approval, with associations to Student and Course, and to state the uniqueness constraint (student, course, term, attempt).

Model advises as an association between Advisor and Student with two association ends; set the end names (role names) advisor and advisee, and multiplicities such as Advisor 0..* to Student 0..*. Role names are not attributes and should not appear as attributes in either class. If advising has its own data (start date, load), reify it as an association class or a class Advising with associations. For Student.gpa, prefix the attribute name with / and add a constraint {derived} or an OCL expression that derives it from Enrollment.grade, for example weighted by credits. State the derivation rule in a note or constraint; a slash alone signals derivation but does not define it. Also specify navigability deliberately: if Student does not need to navigate to Advisor, make that end non-navigable. This removes ambiguity for implementers and prevents the model from implying stored duplicates.