2020年6月21日日曜日

PHS待機問題の対応構想

なるべくPythonでの記述をなくして、GUIだけで記述できないかを検討しました。

新しく、PhaseVarというオブジェクトを作れば、対応できそうだ、という結論に至りました。

PhaseVarというのは、PhaseとTask・Task集合を結びつけるオブジェクトになります。




PhaseVar
PhaseVar名ラベルPhase0(午前)Phase1(午後)Phase2(拘束)
日勤   
午前    
午後   
拘束日勤  拘束集合
午後拘束  拘束集合
午前拘束西   西

 さらにPhaseVarの集合を定義すればより汎用的でしょう。
(また、PhaseVarは、OneDayに限定されることはない、翌日に跨ってもよさそうです。)

例えば、日勤は、午前午後共 働くという意味の変数になります。午前という変数は、Phase0上に日(Task)があったときにアサートされる変数です。日勤拘束という変数は、日勤の上にさらに拘束集合(TaskAggregate)がアサートされる変数です。このように、シフトベースで作っていたシフトラベル名が、フェーズで改めて明確に定義されるという風にも理解できます。

こうしたオブジェクト郡を定義して行制約で使えるようにします。この構想にすると、設計構造上、大変更が必要になってしまいます。今までTask周りは、殆どPythonのお世話にならずには書けない事態に陥っていましたが、逆に殆どPythonを使わずに書ける可能性が出てきました。また、Python制約では、基数制約については、GUI表示を実現していますが、その他については、計数表示できない、複数解に対応していない等、色々制限があります。これら諸問題も同時にクリアできます。

これらの実装には、一ヶ月程度かかると思います。AWS対応以上に変更インパクトがあります。SC3正式リリース、及びAWS DOCKER対応は、上記問題の解決後としておよそ6週間遅延します。

大変大きなインパクトではありますが、Pythonを500行書くよりは、GUI数十行で済ませたい、実際に書いてみて、切にそう思いました。





0 件のコメント:

コメントを投稿