How to lower redundancy in my UML Class diagram?

I am modeling a course management system with the following requirements:

• 2 roles: Student can choose course; Administrator can make courses and then make groups for course, based on list of students who chose that course and based on list of tutors for that course.
• In one course students can go only in one group, and teacher can teach more groups in one course. But student can go in 1 or more courses.

This diagram is a sketch of a class diagram. There is too much redundancy and I don't know how to solve it. Please help me to model my domain and ignore the mistakes in UML syntax or multiplicitycardinality.

More precisely, how can I make association between students and groups, and tutors and groups without redundancy, because I already have associations with courses?

Let's focus indeed on the domain model:

• The direct association between Student and Course corresponds to the student's choice. The choice may or may not be fulfilled. And if it is fulfilled, it's only when the groups are made.
• The indirect association between Student and Course via Group corresponds not only to fulfilled choices, but also to practical organisation of courses.

The two paths that exist are not redundant, but the representation of two different realities. For the tutor, it's similar: the direct association tells what the tutor is able to do, and the indirect one tells what he/she has to do. So the model looks fine in this regard.

In some cases you could simplify (hint: not here)

In some situation a choice/plan can be combined with a fulfilled choice/implementation, by merging associations. For example, if there wasn't your group requirement, you could have only one association class between Student and Course and use a state of your association class to make the difference. But this will not work here, given your requirements.

You could also trick with the requirements. For example, you could have for every course a dummy group that corresponds to students that chose the course and are not assigned to a group. But shortcuts in the design can (and often will) backfire. Here for example, it would add complexity (need to create a dummy group for every course, make a difference between the dummy group and the real groups in almost every activity). Moreover, this trick would constrain your solution. For instance, not having an association class for the choice will prevent from enabling the students to prioritise their courses or providr other elements that facilitate the creation of groups that do not yet exist (e.g. pre-existing skill level).

In summary: your model should primarily aim at addressing the requirements. Premature optimisation is the root of all evil, in modelling as well.