はじめに
今回は前回に引き続き、ドメインと制御の区別について取り上げていきたいと思います。前回はドメインと制御はそれぞれを分けてモデリングしようという話でしたが、この考え方は分析のモデルを作るためには良いのですが、設計のモデルとして見ると、分割されたクラス図をコードで表現することはできないので、開発で使える状態ではありません。
そこで今回はドメインのモデルと制御のモデルの間の関係をどのように表し、またそれをどのように設計のモデルにしていくのかについて、取り上げていこうと思います。
トレースによる対応関係の明示
前回、ドメインと制御のモデルは次のようになっていました(前回のものにメソッドが追加されています)。
今回はこの2つのクラス図の間の対応関係を明らかにしていくのですが、まずは「搬送」がどのようなロジックになっているのかを書いておきましょう(蛇足ですが、こうしたロジックは機能的モデルと呼ばれ、UMLではアクティビティ図で表現されます。機能的モデルについてはまた別の機会に)。
- 入場センサが荷物を検知したら搬入を行う
- 荷物を「ベルトコンベア中央」まで運ぶ
- 決められた静止時間だけ停止する
- 荷物の搬出を行う
- 退場センサが荷物の搬出終了を確認したら搬出を終了する
そして、このロジックをシーケンス図を使ってトレースした結果がこちらです。
シーケンス図上では、制御とドメインのクラス図に登場するオブジェクトを使って制御のロジックがどのように実現されるのかが表現されています。このシーケンス図をよく見ると、搬送オブジェクトがドメインの各オブジェクトに対してメッセージを送りながら、ロジックを実現しているのが分かります。この関係をクラス図で表現すると、制御のオブジェクトからドメインのオブジェクトに対して無数の関連が引かれることになります。制御のオブジェクトが少ないうちはいいのですが、多くなってくるとクラス図が関連に埋もれて読めない状態になってしまうので、このようにシーケンス図を使ってクラス間の関係を表現します。
設計モデルへの落し込み
では次に設計モデルを作ることを考えてみましょう。設計モデルとするためには、前述の制御とドメインのそれぞれのクラス図をマージしてひとつにまとめなければなりません。
ちなみに、ドメインと制御を分けないタイプの分析モデリングを行っている場合、こうした手順は必要ありません。ただ、そうしたモデリングでは、制御に相当する部分がドメインのオブジェクト内に配置されていたりと、設計的な思考が分析の段階から入ってくることが多分にあります。そのため、豆蔵では分析では制御とドメインは分け、設計でこれをマージするという考え方をとっています。
話を元に戻しましょう。設計での制御とドメインのモデルのマージ方法には様々な考え方があります。ドメインと制御を直接結び付ける方法もありますし、制御側の責務の一部をドメインに渡し、高機能化されたドメインオブジェクトを作るという考え方もあります(例：自身で検知したことを通知してくるアクティブなセンサークラス)。ただ、ひとつ言えることは最初の段階では、シンプルにマージしておくということです。
再利用性や保守性の考慮、性能の向上といった設計課題への対応は、優先順位の検討やメカニズムの立案等様々な要素が絡むため、マージ後に行うことになります。むしろ、そうした設計課題への対応の方が設計としては本番です。そうした本番に臨む前に中途半端に複雑な設計モデルを出発点としてしまうと、設計もうまく進みません。そのため、制御とドメインをマージする段階では可能な限りシンプルな構造にしておき、設計課題の解決に応じて徐々に設計モデルが作り込まれていくというのが設計モデルへの落とし込み方としては正しい流れです。
こうしたことを踏まえて、制御とドメインをマージを行うと、次のようなモデルが出来上がります。
他のマージ方法もあるとは思いますが、ここでは一番シンプルなマージを行いました。制御のクラスを中心とし、制御のクラスから利用されるドメインのクラスとの間を片方向の関連で直接結んでいます。また、制御とドメインの間を繋ぐようなメカニズムも入れない形になっています。この状態であればプログラミング言語で全体を記述することもできるため、今後の設計のベースとなるモデルとして利用していくことができます。
制御とドメインの分離ということで2回にわたって取り上げてきましたが、いかがだったでしょうか。制御とドメインをそれぞれ分けて考えるというのは、組込系のモデリングを行う上で便利な考え方ですので、是非適用してみて頂ければと思います。次回は基本的な話に立ち返って、状態遷移について取り上げていきたいと思います。
