This is an inventory of user story requirements:

• A rotation is a number of days. Usually 4 weeks or 6 weeks.
  • But in some cases it is 10 days, so it might not even match a week.
• Each day in a rotation doesn't have a date, instead it has a dayOffset.
  • When a rotation is appended in a rolling matter to the end of spot roster, it starts with the dayOffset where it previously ended
  • For example, presume a rotation of 14 days (dayOffset 0 to 13) and that in the spot roster 1-FEB was dayOffset 1 and only until 7-FEB (dayOffset 7) is filled in. If we now append 2 weeks, then 8-FEB gets the rotation dayOffset 8, 9-FEB gets dayOffset 9, ..., 13-FEB gets dayOffset 13, 14-FEB gets dayOffset 0, 15-FEB gets dayOffset 1, ...
• Each rotation day determines the default shifts any day that dayOffset rolls over
• Each rotation day determines for each of those shifts, the "rotation employee".
  • The rotation employee is the employee that will do the shift in a perfect world.
  • The user (not optaplanner) determines who's the rotation employee for each rotation shift
  • The world is not perfect: employees take PTO, surgery, shifts get added/removed, there are holidays (even during weekdays), overtime/sick snowball effects, employee desire certain shifts, ...
  • There is a soft constraint for the optaplanner shift roster to match the real employee with the rotation employee, whenever possible.
    • Expect about 60% of the shifts to match in stable rosters.
• In volatile rosters (think guard scheduling for events such as the olympic games), there will be no rotation employees and possible not even any rotation shifts at all.

Class diagram proposal A:

class RotationTimeslot {
   int dayOffset;
   LocalTime startingTime;
   LocalTime endingTime; // what do we do if it's the next day? what do we do if it's the day after the next day??
}

class RotationShift {
   RotationTimeslot rotationTimeslot; // Instead of Timeslot
   // rest similar
}