SC3への拡張

INRC2のインスタンスをSC３GUIで記述しました。



予定入力では、シフトとタスクの記述は分離しています。シフトは従来と同じです。タスクは、上部になりますが、最初に記述したフェーズで、一日が分割（薄緑→緑)されています。解画面では、シフト・タスクが統合した画面となります。

スタッフプロパティの記述です。SC2であったプロパティが下のタスクに移動しています。

各スタッフはありえるタスクリストを定義します。



タスクの定義です。タスクとフェーズを記述しなければ、SC2と同じ機能となります。
 

フェーズは、時刻概念で一日のSPLITです。1フェーズ中、最大1タスクまでです。（一人が同時にできる仕事は、一つまで）　フェーズはExclusiveな性質をもち、フェーズ同士はオーバラップしません。
それに対してシフトは、時間帯です。一日にできるのは、これまで通り１シフトのみです。

＜利点＞
フェーズとタスクの機能追加によって、柔軟にシフト勤務を記述できます。これまでもシフトの種類を増やすことで、同様の機能を記述することは可能でした。従って、SC2の記述のままで特に問題はありません。

利用の場面としては、タスクを導入することで、シフト数を大幅に削減できる場合、あるいは、一日に複数の仕事を定義したい場合になるかと思います。
技術的な問題として、SC3では、複数のソルバを搭載しますが、シフト数が多いとソルバが利用可能なソルバ種類が限定される方向になります。
　いずれにしても、この機能追加によって、さらに記述自由度が上がります。どんなに複雑な制約を持つシフト勤務でも記述可能となるでしょう。

Task変数Yは、次のように4次元に修正しました。Dayの次にフェーズが来ます。フェーズは、便宜的にシフト分割で定義されますが、絶対時刻なのでシフトの集合要素ではなく、Dayを構成する集合要素です。あまりないかと思いますが、同じ時刻を共有する別なシフト記述は許すものとします。その場合、同じ時刻なので、同時に可能なTaskは、一つのみです。つまり同じフェーズを共有すると考えた方が自然な解釈になります。

Taskは、縦方向の制約記述（Ex.　X日の午前はZ人以上）に使い、シフトは、横方向のシーケンス記述に特化すると、記述の柔軟性が高まります。SC2の記述だと、Taskが増えた場合は、シフト記号を増やさざるえません。本来Day方向のシーケンスが変わらないならば、シフト記述は変えない方が分かりやすいでしょう。



$Y_p_d_u_t$. または　$ Y[p][d][u][t]$
ここで、
$p \in Persons$
$d \in Days$
$u \in Phases$
$t \in Tasks$
です。4次元でアクセス可能です。
最も基本的な制約は、
$\sum_{t\in Tasks}Y_p_d_u_t=1　　\ \ \ 　\forall u \in Phases$
subject to active shift
$\sum_{s\in Shifts}X_p_d_s=1　　\ \ \ 　\forall p \in Persons, \forall d \in Days$

です。