This may or may not be an answer to your exercise. If I got these requirements in the real world, I would refactor them. (Of course, in the real world, I would have a lot of questions about further refinements and details as well.) The real-world situation is (we may presume) that we are dealing with persons who always have a name and surname. Since the names and surnames don't change (we may also presume) when person is specialized into subclasses, there is no reason to provide a means to implement them differently in subclasses. Therefore there is no reason to make the person class abstract, since that's why you make abstract classes.
This is also a situation where aggregation (one class "has" other classes) makes more sense than inheritance (a subclass "is" a superclass). So I would restructure the requirements this way:
Person: Name, Surname
Student: School, Grades
Worker: Salary
Person class may "have" zero to one Student classes. Person class may "have" zero to one Worker classes.
There is also the implication, by requiring Person to be abstract, that a person must be either a student, a worker, or both. This can be specified by an or
constraint between the two classes.
Here's a diagram:

Person class has an aggregate relationship with both student and worker classes. One person class may have zero to one student classes. One person class may also have zero to one worker classes. The {or}
constraint further specifies that there must be one of either student or worker, or one of each.