Este contenido no está disponible en el idioma seleccionado.
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.java
class: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’sDEBUG
orTRACE
log, as shown later.Create the
src/main/java/com/example/domain/Room.java
class:Copy to Clipboard Copied! Toggle word wrap Toggle overflow Create the
src/main/java/com/example/domain/Lesson.java
class:Copy to Clipboard Copied! Toggle word wrap Toggle overflow The
Lesson
class has an@PlanningEntity
annotation, so Red Hat Business Optimizer knows that this class changes during solving because it contains one or more planning variables.The
timeslot
field has an@PlanningVariable
annotation, so Red Hat Business Optimizer knows that it can change its value. In order to find potentialTimeslot
instances to assign to this field, Red Hat Business Optimizer uses thevalueRangeProviderRefs
property 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
room
field also has an@PlanningVariable
annotation for the same reasons.