第4章 Planner の設定

@PlanningSolution または @PlanningEntity が含まれるクラスを手動で宣言する代わりに以下を行います。

<solver>
  <!-- Define the model -->
  <solutionClass>org.optaplanner.examples.nqueens.domain.NQueens</solutionClass>
  <entityClass>org.optaplanner.examples.nqueens.domain.Queen</entityClass>

  ...
</solver>

Planner では、自動的にクラスパスをスキャンして、検索します。

<solver>
  <!-- Define the model -->
  <scanAnnotatedClasses/>

  ...
</solver>

クラスパスに複数のモデルがある場合 (またはスキャンのスピードを速める場合) は、以下のようにスキャンするパッケージを指定します。

<solver>
  <!-- Define the model -->
  <scanAnnotatedClasses>
    <packageInclude>org.optaplanner.examples.cloudbalancing</packageInclude>
  </scanAnnotatedClasses>

  ...
</solver>

これにより、パッケージまたはサブパッケージのソリューションおよびエンティティークラスがすべて検出されます。

Planner は、ドメインモデルのどのクラスが、プランニング変数などをプロパティーとするプランニングエンティティーであるかを指定する必要があります。この情報を渡す方法は複数あります。

本書は、1 つ目の方法に焦点を当てていますが、明示的に記してない場合でも、すべての機能でこの 3 つの方法に対応しています。

プランニングエンティティーは、問題解決時に変化する JavaBean (POJO) のことで、例としては、別の行に移動する クィーン が挙げられます。また、計画の問題には複数のプランニングエンティティーが含まれます。N クィーンの問題では、各 クィーン がプランニングエンティティーですが、プランニングエンティティークラスは 1 つのみとなっています (例: Queen クラス)。

プランニングエンティティークラスは、@PlanningEntity アノテーションを付ける必要があります。

各プランニングエンティティークラスには、1 つまたは複数の プランニング変数 を追加し、それぞれに 定義 プロパティーを 1 つ以上追加する必要があります。たとえば、N クィーンでは、クィーン は 列 で定義され、行 がプランニング変数になります。これは、問題解決時にクィーンの列を変更せず、行を変更することを示しています。

@PlanningEntity
public class Queen {

    private Column column;

    // Planning variables: changes during planning, between score calculations.
    private Row row;

    // ... getters and setters
}

プランニングエンティティークラスには、複数のプランニング変数を指定することができます。たとえば、授業 は、コース やコースのインデックス (1 つのコースには複数の授業が含まれるため) で定義されます。各 授業 は、時間帯 と 講義室 のスケジュールを組む必要があるので、プランニング変数 (時間帯と講義室) は 2 つになります。たとえば、数学のコースでは、1 週間に授業が 8 個あり、最初の授業は月曜の午前 8 時に 212 号室で開催されます。

@PlanningEntity
public class Lecture {

    private Course course;
    private int lectureIndexInCourse;

    // Planning variables: changes during planning, between score calculations.
    private Period period;
    private Room room;

    // ...
}

また、自動スキャン がない場合には、Solver 設定で以下のように各プランニングエンティティーを宣言する必要があります。

<solver>
  ...
  <entityClass>org.optaplanner.examples.nqueens.domain.Queen</entityClass>
  ...
</solver>

ユースケースによっては、複数のプランニングエンティティークラスが含まれます。たとえば、鉄道路線図に、貨物および車両を追加します。このとき、1 つの貨物を輸送するのに車両を複数使用したり、1 つの車両で貨物を複数輸送したりできます。このように、プランニングエンティティークラスが複数になると、ユースケース実装の複雑性が増します。

計画がより困難なプランニングエンティティーが予測できる場合には、最適化アルゴリズムはより効率的に機能します。たとえば、ビンパッキング問題ではアイテムが大きくなればなるほど詰めるのは難しく、コースの時間割では授業に出席する学生が多くなればなるほど時間割を作成するのは困難になります。また、N クィーンでは、真ん中のクィーンの配置場所を決めるのがより困難です。

そのため、以下のように、@PlanningEntity アノテーションに difficultyComparatorClass を設定できます。

@PlanningEntity(difficultyComparatorClass = CloudProcessDifficultyComparator.class)
public class CloudProcess {
    // ...
}

public class CloudProcessDifficultyComparator implements Comparator<CloudProcess> {

    public int compare(CloudProcess a, CloudProcess b) {
        return new CompareToBuilder()
                .append(a.getRequiredMultiplicand(), b.getRequiredMultiplicand())
                .append(a.getId(), b.getId())
                .toComparison();
    }

}

または、以下のように、Solution からも残りの問題ファクトにアクセスできるように、@PlanningEntity アノテーションに difficultyWeightFactoryClass を設定することも可能です。

@PlanningEntity(difficultyWeightFactoryClass = QueenDifficultyWeightFactory.class)
public class Queen {
    // ...
}

詳しい情報は「ソートした選択」を参照してください。

プランニングエンティティーの難易度を比較するのに、現在のプランニング変数の状態を使用するべきではありません。構築ヒューリスティックの間、これらの変数は null の可能性が高くなります。たとえば、クィーン の row 変数は使用するべきではありません。

プランニング変数とは、プランニングエンティティーにある JavaBean プロパティー (つまり、ゲッターとセッター) のことです。この変数は、計画時に変化する計画値を参照します。たとえば、クィーン の row プロパティーはプランニング変数となります。計画時に、クィーン の row プロパティーが Row に変化した場合でも、Row インスタンス自体は変化しません。

プランニング変数のゲッターには、@PlanningVariable のアノテーションを付ける必要があります。このアノテーションは、空以外の valueRangeProviderRefs プロパティーを必要とします。

@PlanningEntity
public class Queen {
    ...

    private Row row;

    @PlanningVariable(valueRangeProviderRefs = {"rowRange"})
    public Row getRow() {
        return row;
    }

    public void setRow(Row row) {
        this.row = row;
    }

}

valueRangeProviderRefs プロパティーは、対象のプランニング変数で許容可能な計画値は何かを定義します。このプロパティーは、1 つまたは複数の @ValueRangeProvider ID を参照します。

プロパティーではなく、フィールドにアノテーション を付けることも可能です。

@PlanningEntity
public class Queen {
    ...

    @PlanningVariable(valueRangeProviderRefs = {"rowRange"})
    private Row row;

}

デフォルトでは、初期化されたプランニング変数は null にすることができないので、初期化されたソリューションが、プランニング変数に null を使用することはありません。過制約のユースケースではこれは逆効果です。たとえば、従業員にタスクが過剰に割り当てられてしまう場合には、優先順位の低いタスクを、負担の多いスタッフに割り当てるのではなく、未割り当ての状態にしておきます。

初期化されたプランニング変数を null に設定できるようにするには、nullable を true に設定します。

    @PlanningVariable(..., nullable = true)
    public Worker getWorker() {
        return worker;
    }

反復計画 (特に リアルタイム計画) は、null 許容型変数と適切に連携しません。Solver が開始したり、問題ファクトが変更したりするたびに、構築ヒューリスティック は null 変数すべてを再初期化しようとして、長時間無駄にしてしまう可能性があります。これに対応するには、reinitializeVariableEntityFilter で、プランニングエンティティーを再初期化するタイミングを変更します。

    @PlanningVariable(..., nullable = true, reinitializeVariableEntityFilter = ReinitializeTaskFilter.class)
    public Worker getWorker() {
        return worker;
    }

プランニング変数は、値が null でない場合、または変数が nullable の場合に初期化されると見なされるため、カスタムの reinitializeVariableEntityFilter が構築ヒューリスティック時に再初期化をトリガーする場合でも、null 許容型変数は常に初期化すると見なされます。

プランニング変数すべてが初期化されると、プランニングエンティティーは初期化されます。

また、プランニングエンティティーがすべて初期化されると、ソリューション が初期化されます。

計画値は、プランニング変数の許容値です。通常、計画値は問題ファクトですが、double などのオブジェクトの場合もあります。また、別のプランニングエンティティーや、プランニングエンティティーと問題ファクトの両方が実装したインターフェースの可能性もあります。

プランニング変数の範囲は、プランニング変数が許容できる一連の値のことです。この一連の値として、可算値 (例: 1、2、3、または 4) または、非可算値 (例: 0.0 から 1.0 の間の double) などを指定できます。

最適化アルゴリズムは、より強度の高い計画値を予測できる場合に、より効率的に機能します。つまり、プランニングエンティティーを満たす可能性が高くなります。たとえば、ビンパッキング問題では、大きい容器のほうがアイテムが入りやすく、またコースの時間割では、大きい講義室のほうが学生の収容人数の制約に違反する可能性が低くなります。

そのため、@PlanningVariable アノテーションに strengthComparatorClass を設定できます。

    @PlanningVariable(..., strengthComparatorClass = CloudComputerStrengthComparator.class)
    public CloudComputer getComputer() {
        // ...
    }

public class CloudComputerStrengthComparator implements Comparator<CloudComputer> {

    public int compare(CloudComputer a, CloudComputer b) {
        return new CompareToBuilder()
                .append(a.getMultiplicand(), b.getMultiplicand())
                .append(b.getCost(), a.getCost()) // Descending (but this is debatable)
                .append(a.getId(), b.getId())
                .toComparison();
    }

}

または、ソリューションから残りの問題ファクトにアクセスできるように、@PlanningVariable アノテーションに strengthWeightFactoryClass を設定することも可能です。

    @PlanningVariable(..., strengthWeightFactoryClass = RowStrengthWeightFactory.class)
    public Row getRow() {
        // ...
    }

詳しい情報は「ソートした選択」を参照してください。

プランニングエンティティーの現在のプランニング変数を使用して、計画値を比較しないでください。構築ヒューリスティックの間、これらの変数は null の可能性が高くなります。たとえば、クィーン の row 変数を使用して、Row の強度を判断することはできません。

TSP や配送経路のユースケースには、連鎖が必要です。つまり、プランニングエンティティー同士で相互参照し、連鎖を形成します。(ツリー/ループのセットではなく) 連鎖セットとして問題をモデル化すると、探索空間を大幅に縮小することができます。

連鎖するプランニング変数は、以下のいずれかです。

以下に有効な連鎖と無効な連鎖の例を示します。

初期化されるプランニングエンティティーはすべて、アンカーから始まる、一端が開放型の連鎖に含まれます。有効なモデルとは以下のとおりです。

最適化アルゴリズムと組み込みの Move は、連鎖的に修正して、モデルが有効な状態を保てるようにします。

たとえば、TSP では、アンカーは Domicile です (配送経路ではアンカーは Vehicle です)。

public class Domicile ... implements Standstill {

    ...

    public City getCity() {...}

}

アンカー (つまり、問題ファクト) とプランニングエンティティーは、たとえば TSP の Standstill のように共通のインターフェースを実装します。

public interface Standstill {

    City getCity();

}

このインターフェースがプランニング変数の戻り値型で、さらにプランニング変数は連鎖されています (例: TSP の Visit、配送経路の Customer)。

@PlanningEntity
public class Visit ... implements Standstill {

    ...

    public City getCity() {...}

    @PlanningVariable(graphType = PlanningVariableGraphType.CHAINED,
        valueRangeProviderRefs = {"domicileRange", "visitRange"})
    public Standstill getPreviousStandstill() {
        return previousStandstill;
    }

    public void setPreviousStandstill(Standstill previousStandstill) {
        this.previousStandstill = previousStandstill;
    }

}

この 2 つの ValueRangeProvider が、通常、統合されている点に注目してください。

シャドウ変数とは、正しい値を正規のプランニング変数の状態から推測できる変数のことです。この変数が定義上、正規化の原則に違反するにもかかわらず、ユースケースによっては、特により自然に制約を表現する場合など、シャドウ変数を使用すると非常に実用的です。たとえば、時間枠がある配送経路の場合には、車両が顧客先に到着する時間は、その車両がその前に顧客先に訪問したタイミング (および、2 箇所の既知の移動時間) をベースに計算することができます。

車両が対応する顧客が変化すると、各顧客先への到着時間は自動的に調節されます。詳しい情報は、「配送経路ドメインモデル」を参照してください。

スコア計算の観点からすると、シャドウ変数は他のプランニング変数とよく似ています。最適化の観点からすると、Planner は正規の変数を効果的に最適化するだけです (シャドウ変数はほぼ無視されます)。正規の変数が変化すると、従属のシャドウ変数もそれに合わせて変化するようにするだけです。

以下のように、組み込みのシャドウ変数は複数あります。

2 つの変数は、各変数のインスタンスが常に相互参照する場合には、双方向となります (一方が null を参照し、他方が存在しない場合を除きます)。そのため、A が B を参照している場合には、B は A を参照することになります。

非連鎖型のプランニング変数の場合には、双方向の関係は、多対一の関係である必要があります。2 つのプランニング変数間で双方向の関係をマッピングするには、マスターの方 (正規の変数) を通常のプランニング変数としてアノテーションを付けます。

@PlanningEntity
public class CloudProcess {

    @PlanningVariable(...)
    public CloudComputer getComputer() {
        return computer;
    }
    public void setComputer(CloudComputer computer) {...}

}

次に、もう一方 (シャドウ変数) には、Collection (通常は Set または List) プロパティーで @InverseRelationShadowVariable アノテーションを付けます。

@PlanningEntity
public class CloudComputer {

    @InverseRelationShadowVariable(sourceVariableName = "computer")
    public List<CloudProcess> getProcessList() {
        return processList;
    }

}

sourceVariableName プロパティーは、ゲッターの戻り値型の正規プランニング変数の名前です (つまり、他方 の正規プランニング変数の名前)。

連鎖型のプランニング変数の場合には、双方向の関係は一対一にする必要があります。この場合、正規変数の側の設定は以下のようになります。

@PlanningEntity
public class Customer ... {

    @PlanningVariable(graphType = PlanningVariableGraphType.CHAINED, ...)
    public Standstill getPreviousStandstill() {
        return previousStandstill;
    }
    public void setPreviousStandstill(Standstill previousStandstill) {...}

}

また、シャドウ変数側の設定は以下のとおりです。

@PlanningEntity
public class Standstill {

    @InverseRelationShadowVariable(sourceVariableName = "previousStandstill")
    public Customer getNextCustomer() {
         return nextCustomer;
    }
    public void setNextCustomer(Customer nextCustomer) {...}

}

アンカーシャドウ変数は、連鎖型変数 のアンカーのことです。

アンカーのプロパティーは、@AnchorShadowVariable でアノテーションを付けます。

@PlanningEntity
public class Customer {

    @AnchorShadowVariable(sourceVariableName = "previousStandstill")
    public Vehicle getVehicle() {...}
    public void setVehicle(Vehicle vehicle) {...}

}

sourceVariableName プロパティーは、同じエンティティークラスの連鎖型変数の名前を指定します。

Planner は、シャドウ変数を更新するのに VariableListener を使用します。また、カスタムのシャドウ変数を定義するには、カスタムの VariableListener を記述します。インターフェースを実装して、変更が必要なシャドウ変数にアノテーションを付けます。

    @PlanningVariable(...)
    public Standstill getPreviousStandstill() {
        return previousStandstill;
    }

    @CustomShadowVariable(variableListenerClass = VehicleUpdatingVariableListener.class,
            sources = {@CustomShadowVariable.Source(variableName = "previousStandstill")})
    public Vehicle getVehicle() {
        return vehicle;
    }

variableName は、シャドウ変数で変更をトリガーする変数を指定します。

たとえば VehicleUpdatingVariableListener は連鎖のアンカーの役割を果たし、連鎖内のすべての Customer に同じ Vehicle が指定されるようにします。

public class VehicleUpdatingVariableListener implements VariableListener<Customer> {

    public void afterEntityAdded(ScoreDirector scoreDirector, Customer customer) {
        updateVehicle(scoreDirector, customer);
    }

    public void afterVariableChanged(ScoreDirector scoreDirector, Customer customer) {
        updateVehicle(scoreDirector, customer);
    }

    ...

    protected void updateVehicle(ScoreDirector scoreDirector, Customer sourceCustomer) {
        Standstill previousStandstill = sourceCustomer.getPreviousStandstill();
        Vehicle vehicle = previousStandstill == null ? null : previousStandstill.getVehicle();
        Customer shadowCustomer = sourceCustomer;
        while (shadowCustomer != null && shadowCustomer.getVehicle() != vehicle) {
            scoreDirector.beforeVariableChanged(shadowCustomer, "vehicle");
            shadowCustomer.setVehicle(vehicle);
            scoreDirector.afterVariableChanged(shadowCustomer, "vehicle");
            shadowCustomer = shadowCustomer.getNextCustomer();
        }
    }

}

( VariableListeners を 2 つ設定するのは効率的でないため) 1 つの VariableListener が 2 つのシャドウ変数を変更する場合に、variableListenerClass でアノテーションを付けるのを 1 番目のシャドウ変数に限定し、他のシャドウ変数が 1 番目のシャドウ変数を参照するように設定します。

    @PlanningVariable(...)
    public Standstill getPreviousStandstill() {
        return previousStandstill;
    }

    @CustomShadowVariable(variableListenerClass = TransportTimeAndCapacityUpdatingVariableListener.class,
            sources = {@CustomShadowVariable.Source(variableName = "previousStandstill")})
    public Integer getTransportTime() {
        return transportTime;
    }

    @CustomShadowVariable(variableListenerRef = @PlanningVariableReference(variableName = "transportTime"))
    public Integer getCapacity() {
        return capacity;
    }

すべてのシャドウ変数は、組み込みまたはカスタムにかかわらず、VariableListener によりトリガーされます。正規の変数およびシャドウ変数でグラフが形成され、afterEntityAdded() メソッド、afterVariableChanged() メソッド、afterEntityRemoved() メソッドが呼び出される順番を決定します。

Planner は以下を保証します。

影響を受けた順番になる可能性は高くなりますが、Planner は、異なるパラメーター (上記の例では A1 と A2) が指定した 同じ VariableListener に対して after*() メソッドが呼び出される順番を保証しません。

計画問題のデータセットは、Solver が解 (ソリューション) を出せるように、クラス内でラッピングする必要があります。このクラスは必ず実装してください。たとえば N クィーン問題では、Column リスト、Row リスト、Queen リストが含まれる NQueens クラスです。

計画問題とは、未解決のプランニングソリューション、または 未初期化の ソリューション のことです。そのため、ラッピングクラスは Solution インターフェースを実装する必要があります。たとえば、N クィーン問題で、NQueens クラスは Solution を実装しますが、新しい NQueens に含まれる全 Queen は Row に割り当てられていません (クィーンの row プロパティーは null です)。これは実行可能解でも、可能解ではなく、未初期化解となります。

Solver に対する Solution インスタンスとして問題を提示する必要があるため、クラスは Solution インターフェースを実装する必要があります。

public interface Solution<S extends Score> {

    S getScore();
    void setScore(S score);

    Collection<? extends Object> getProblemFacts();

}

たとえば、NQueens インスタンスは、全行、全列、全 Queen インスタンスの一覧を保持します。

@PlanningSolution
public class NQueens implements Solution<SimpleScore> {

    private int n;

    // Problem facts
    private List<Column> columnList;
    private List<Row> rowList;

    // Planning entities
    private List<Queen> queenList;

    // ...
}

また、プランニングソリューションクラスは、@PlanningSolution アノテーションを付ける必要があります。自動スキャン がない場合には、Solver 設定はプランニングソリューションクラスも宣言する必要があります。

<solver>
  ...
  <solutionClass>org.optaplanner.examples.nqueens.domain.NQueens</solutionClass>
  ...
</solver>

Planner は、Solution インスタンスからエンティティーインスタンスを抽出する必要があります。これは、@PlanningEntityCollectionProperty アノテーションが付いた全ゲッター (フィールド) を呼び出してこれらのコレクションを取得します。

@PlanningSolution
public class NQueens implements Solution<SimpleScore> {
    ...

    private List<Queen> queenList;

    @PlanningEntityCollectionProperty
    public List<Queen> getQueenList() {
        return queenList;
    }

}

@PlanningEntityCollectionProperty のアノテーションがついたメンバーが複数存在する可能性があります。このようなメンバーは、同じエンティティークラスタイプの Collection を返すことも可能です。

あまり一般的ではありませんが、ゲッター (またはフィールド) の @PlanningEntityProperty を使用するなど、プランニングエンティティーがシングルトンの可能性があります。

Solution には、スコアプロパティーが必要です。スコアプロパティーは、Solution が初期化されていない場合や、スコアが (再) 計算されていない場合には null になります。score プロパティーは通常、使用する固有の Score 実装に型指定されます。たとえば、NQueens は SimpleScore を使用します。

@PlanningSolution
public class NQueens implements Solution<SimpleScore> {

    private SimpleScore score;

    public SimpleScore getScore() {
        return score;
    }

    public void setScore(SimpleScore score) {
        this.score = score;
    }

    // ...
}

代わりに、多くのユースケースでは、HardSoftScore を使用します。

@PlanningSolution
public class CourseSchedule implements Solution<HardSoftScore> {

    private HardSoftScore score;

    public HardSoftScore getScore() {
        return score;
    }

    public void setScore(HardSoftScore score) {
        this.score = score;
    }

    // ...
}

Score 実装に関する詳しい情報は、スコア計算のセクションを参照してください。

このメソッドは、スコア計算に Drools を使用する場合にのみ使用します。他のスコアディレクターは、このメソッドを使用しません。

getProblemFacts() メソッドが返すオブジェクトはすべて、Drools のワーキングメモリーにアサートされるので、スコアルールがそのオブジェクトにアクセスできます。たとえば、NQueens は Column インスタンスと Row インスタンスだけを返します。

    public Collection<? extends Object> getProblemFacts() {
        List<Object> facts = new ArrayList<Object>();
        facts.addAll(columnList);
        facts.addAll(rowList);
        // Do not add the planning entities (queenList) because that will be done automatically
        return facts;
    }

プランニングエンティティーはすべて自動的に Drools のワーキングメモリーに挿入されます。getProblemFacts() メソッドには追加しないでください。

getProblemFacts() メソッドは、Solver スレッドの各 Solver フェーズで呼び出されるのは 1 度だけで、頻繁には呼び出されません。

    public Collection<? extends Object> getProblemFacts() {
        List<Object> facts = new ArrayList<Object>();
        // ...
        facts.addAll(calculateTopicConflictList());
        // ...
        return facts;
    }

    private List<TopicConflict> calculateTopicConflictList() {
        List<TopicConflict> topicConflictList = new ArrayList<TopicConflict>();
        for (Topic leftTopic : topicList) {
            for (Topic rightTopic : topicList) {
                if (leftTopic.getId() < rightTopic.getId()) {
                    int studentSize = 0;
                    for (Student student : leftTopic.getStudentList()) {
                        if (rightTopic.getStudentList().contains(student)) {
                            studentSize++;
                        }
                    }
                    if (studentSize > 0) {
                        topicConflictList.add(new TopicConflict(leftTopic, rightTopic, studentSize));
                    }
                }
            }
        }
        return topicConflictList;
    }

(すべてではないとしても) 多くの最適化アルゴリズムは、新しい最適解を見つけた場合 (後で呼び出すため)、または複数の解を並行して使用できるように、その解 (ソリューション) のクローンを作成します。

ソリューション の計画クローンは、以下の要件を満たす必要があります。

計画クローンメソッドを実装するのは困難なので、実装する必要はありません。

@DeepPlanningClone
public class SeatDesignationDependency {
    private SeatDesignation leftSeatDesignation; // planning entity
    private SeatDesignation rightSeatDesignation; // planning entity
    ...
}

public interface PlanningCloneable<T> {

    T planningClone();

}

public class NQueens implements Solution<...>, PlanningCloneable<NQueens> {
    ...

    /**
     * Clone will only deep copy the {@link #queenList}.
     */
    public NQueens planningClone() {
        NQueens clone = new NQueens();
        clone.id = id;
        clone.n = n;
        clone.columnList = columnList;
        clone.rowList = rowList;
        List<Queen> clonedQueenList = new ArrayList<Queen>(queenList.size());
        for (Queen queen : queenList) {
            clonedQueenList.add(queen.planningClone());
        }
        clone.queenList = clonedQueenList;
        clone.score = score;
        return clone;
    }
}

Solution インスタンスを作成して、計画問題のデータセットを表現するため、解決する計画問題として、Solver に設定することができます。たとえば N クィーンでは、NQueens インスタンスが、必須の Column インスタンスおよび Row インスタンスで作成され、全 Queen は異なる column に、全 row は null に設定されます。

    private NQueens createNQueens(int n) {
        NQueens nQueens = new NQueens();
        nQueens.setId(0L);
        nQueens.setN(n);
        nQueens.setColumnList(createColumnList(nQueens));
        nQueens.setRowList(createRowList(nQueens));
        nQueens.setQueenList(createQueenList(nQueens));
        return nQueens;
    }

    private List<Queen> createQueenList(NQueens nQueens) {
        int n = nQueens.getN();
        List<Queen> queenList = new ArrayList<Queen>(n);
        long id = 0L;
        for (Column column : nQueens.getColumnList()) {
            Queen queen = new Queen();
            queen.setId(id);
            id++;
            queen.setColumn(column);
            // Notice that we leave the PlanningVariable properties on null
            queenList.add(queen);
        }
        return queenList;
    }

図4.3 クィーン 4 個のパズルの初期化前の解

通常、データ層から来るこのデータや Solution 実装の多くは、対象のデータを累積して、計画する未初期化プランニングエンティティーインスタンスを作成します。

        private void createLectureList(CourseSchedule schedule) {
            List<Course> courseList = schedule.getCourseList();
            List<Lecture> lectureList = new ArrayList<Lecture>(courseList.size());
            long id = 0L;
            for (Course course : courseList) {
                for (int i = 0; i < course.getLectureSize(); i++) {
                    Lecture lecture = new Lecture();
                    lecture.setId(id);
                    id++;
                    lecture.setCourse(course);
                    lecture.setLectureIndexInCourse(i);
                    // Notice that we leave the PlanningVariable properties (period and room) on null
                    lectureList.add(lecture);
                }
            }
            schedule.setLectureList(lectureList);
        }

FULL_ASSERT モードは (インクリメンタルスコアの計算を Move ごとに低下させないようにするアサーションなど) すべてのアサーションをオンにして、Move 実装、スコアルール、ルールエンジン自体などでバグがあった場合にフェイルファストさせます。

このモードは、再現可能です (再現可能モードを参照)。また、アサーション以外のモードと比べ、calculateScore() メソッドは頻繁に呼び出されるため、割り込みも可能です。

FULL_ASSERT モードは、(インクリメンタルスコアの計算には依存しないので) 極めて遅いです。

NON_INTRUSIVE_FULL_ASSERT は、複数のアサーションをオンにして、Move 実装、スコアルール、ルールエンジン自体などにバグがあった場合にフェイルファストさせます。

このモードは、再現可能です (再現可能モードを参照)。また、アサーション以外のモードと比べ、calculateScore() メソッドはより頻繁に呼び出されないので、割り込みはしません。

NON_INTRUSIVE_FULL_ASSERT モードは、(インクリメンタルスコアの計算には依存しないので) 極めて遅いです。

FAST_ASSERT モードは、(undoMove のスコアが Move の前と同じであるとのアサーションなど) 大半のアサーションをオンにして、Move 実装、スコアルール、ルールエンジン自体などでバグがあった場合にフェイルファストさせます。

このモードは、再現可能です (再現可能モードを参照)。また、アサーション以外のモードと比べ、calculateScore() メソッドがより頻繁に呼び出されるので、割り込みが可能です。

FAST_ASSERT モードは遅いです。

FAST_ASSERT モードがオンの状態で計画問題を簡略的に実行するテストケースを記述することを推奨します。

再現可能モードは、開発中に推奨されるモードであるため、デフォルトのモードとなっています。このモードでは、Planner バージョンを実行した場合に実行されるコードの順番は常に同じです。そして、以下の注意点が適用されている場合を除き、どのステップでも同じ結果となります。こうすることで、一貫性を持ってバグを再現することができます。したがって、実行を繰り返しながら、特定のリファクタリング (例: スコア制約のパフォーマンスの最適化) をベンチマーク化することができます。

再現可能モードは、実稼働モードより若干遅くなります。実稼働環境で再現性が必要な場合には、このモードを実稼働環境でも使用してください。

シードを指定しない場合は、このモードではデフォルトで固定の 乱数シード が使用され、特定の同時最適化 (例: ワークスティーリング) も無効にします。

実稼働モードは、最速ですが再現性はありません。このモードは、再現性の必要がない、実稼働環境に推奨されます。

シードを指定しない場合は、このモードでは固定の 乱数シード は使用されません。