Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 22. Model the domain objects
The goal of the Red Hat Business Optimizer timetable project is to assign each lesson to a time slot and a room. To do this, add three classes, Timeslot, Lesson, and Room, as shown in the following diagram:
Timeslot
The Timeslot class represents a time interval when lessons are taught, for example, Monday 10:30 - 11:30 or Tuesday 13:30 - 14:30. In this example, all time slots have the same duration and there are no time slots during lunch or other breaks.
A time slot has no date because a high school schedule just repeats every week. There is no need for continuous planning. A Timeslot is called a problem fact because no Timeslot instances change during solving. Such classes do not require any Red Hat Business Optimizer specific annotations.
Room
The Room class represents a location where lessons are taught, for example, Room A or Room B. In this example, all rooms are without capacity limits and they can accommodate all lessons.
Room instances do not change during solving so Room is also a problem fact.
Lesson
During a lesson, represented by the Lesson class, a teacher teaches a subject to a group of students, for example, Math by A.Turing for 9th grade or Chemistry by M.Curie for 10th grade. If a subject is taught multiple times each week by the same teacher to the same student group, there are multiple Lesson instances that are only distinguishable by id. For example, the 9th grade has six math lessons a week.
During solving, Red Hat Business Optimizer changes the timeslot and room fields of the Lesson class to assign each lesson to a time slot and a room. Because Red Hat Business Optimizer changes these fields, Lesson is a planning entity:
Most of the fields in the previous diagram contain input data, except for the orange fields. A lesson’s timeslot and room fields are unassigned (null) in the input data and assigned (not null) in the output data. Red Hat Business Optimizer changes these fields during solving. Such fields are called planning variables. In order for Red Hat Business Optimizer to recognize them, both the timeslot and room fields require an @PlanningVariable annotation. Their containing class, Lesson, requires an @PlanningEntity annotation.
Procedure
Create the
src/main/java/com/example/domain/Timeslot.javaclass:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Notice the
toString()method keeps the output short so it is easier to read Red Hat Business Optimizer’sDEBUGorTRACElog, as shown later.Create the
src/main/java/com/example/domain/Room.javaclass:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the
src/main/java/com/example/domain/Lesson.javaclass:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
Lessonclass has an@PlanningEntityannotation, so Red Hat Business Optimizer knows that this class changes during solving because it contains one or more planning variables.The
timeslotfield has an@PlanningVariableannotation, so Red Hat Business Optimizer knows that it can change its value. In order to find potentialTimeslotinstances to assign to this field, Red Hat Business Optimizer uses thevalueRangeProviderRefsproperty to connect to a value range provider that provides aList<Timeslot>to pick from. See Chapter 24, Gather the domain objects in a planning solution for information about value range providers.The
roomfield also has an@PlanningVariableannotation for the same reasons.