はじめに

今回からドメインのモデルと制御のモデルを分けようという話を取り上げます。ドメインと制御を分離するという話はあまり語られることはありませんが、組込系システムをモデル化する上で多くの場面で適用できる考え方ですので、覚えていって頂けると役に立つことも多いと思います。今回は前編として、ドメインと制御のそれぞれのモデルについて取り上げていきます。

ドメインとは、制御とは

まずはドメインと制御の分離という話に行く前に、組込系システムでいうドメインとは何か、制御とは何かという話に行きましょう。例題として前回と同じくベルトコンベアを使いたいと思います。

図:荷物を矢印の方向に搬送するベルトコンベア
荷物を矢印の方向に搬送するベルトコンベア。
前段モータと後段モータには同じサーボモータが使われており、
入場センサと退場センサも同じ赤外線センサが使われている。

ドメインとは日本語で言えば問題領域のことで、システムが対象としている領域に普遍的に存在するもののことです。ベルトコンベアでいえば、入場センサ、退場センサ、前段モータ、後段モータ、ベルトといった静的なものや、モータの回転動作や、センサの検知動作といった動的なものがドメインになります。

ここで注意しなければいけないのが、「ドメイン」とされるものの範囲です。ドメインはシステムが取扱う問題領域ですが、この「システム」がハードウエアを含めたプロダクト全体のことを指しているのか、ソフトウエアだけを指しているのかでドメインの範囲が変わってきます。ベルトコンベアでいえば、「ベルト」はプロダクト全体で見れば普遍的に存在するものなのでドメインに入りますが、ソフトウエアから見ると感知の範囲外なので、ドメインには入りません。ですので、ドメインを扱うときにはその範囲(スコープ)を決めなければなりません。

ということで、ここではソフトウエアの話を扱っていますので、スコープをソフトウエアとした時のベルトコンベアのドメインのモデルは次のようになります。

図:ソフトウエアとした時のベルトコンベアのドメインのモデル

このモデルでは、ソフトウエアで扱う範囲に普遍的に存在している「モノ」(登場人物と言い換えてもいいかもしれません)とその構造を表しています。

読んでわかる通りですが、搬送用ベルトコンベアには、前段・後段という役割のサーボモータと入場・退場を検知するための赤外線センサが付いて、サーボモータは方向、移動量、速度を指定して駆動することができ、赤外線センサはものを検知することができる、ということを表しています。これらはベルトコンベアの使い方に関わらず、普遍的に存在しているものになります。

次に「制御」です。システムはドメインにあるものをいろいろと組み合わせて、機能を実現しています。例えば、ベルトコンベアーだったら、「入場センサーが荷物を検知したら前段・後段モータを駆動させて荷物を移動させる」ことで「荷物を搬送する」という機能を実現しています。この「何らかの機能を実現するために行う、ドメインにあるものの組合せ方」を「制御」といいます。この制御にも静的な側面や動的な側面があるので、これをモデル化したものが制御のモデルになります。

ベルトコンベアの制御の静的側面をモデル化すると次のようになります。

図:モデル化したベルトコンベアの制御の静的側面

このモデルでは、ドメインを利用してどんなことを実現したいのかを表しています。

搬送という制御があり、それは搬入、移動、搬出といった処理から構成されていて、位置ごとに搬送対象となる荷物の有無を管理しています。

ドメインと制御の分離

ここで、モデリング経験のある方の中には、ベルトコンベアというひとつの問題だったのに、モデルが分かれてしまっていることに違和感を覚える方もいらっしゃると思います。「普通、モデルといったらひとつのクラス図で全体を表すのではないか」という考え方で見ると、前述したモデルは別々のものになっているため、どこが繋がっているのか分からず、おかしいことになります。

では、なぜひとつのモデルにしないのでしょうか?この理由が組込系システムのモデリングにおけるひとつの大きなポイントだと思います。

ドメインは制御と関係なく普遍的に存在しているものです。一方、制御は提供する機能の内容によって変化していくものです。例えば仕様変更があれば制御の内容は変わってしまいます。こうした寿命の異なるものをひとつのモデルで扱うとモデル化が難しくなります。特に、ドメインのモデルの中に制御が入り込むと、モデルが複雑になってしまいます。例えば、モータやセンサの中に搬送に関する知識があるといった状態です。そうした場合、機能が少ない時はいいのですが機能が増えていくほど、センサやモータの中に制御に関係する話が増えていきます。そうなると、普遍的なものと変化していくものが同じクラスの中に同居するような形になっていくので、静的モデルも動的モデルも扱いづらいものになります。

また、本質的な話ではないですが、制御とドメインをひとつの静的モデルで扱うと、制御のクラスとドメインのクラスとの間に無数に関連が現れ、モデルが読みづらくなってしまうという問題もあります。

そうした理由から制御とドメインを分けて扱うと、普遍的なものと一時的なものとの世界を分けて扱うことができ、モデルも読みやすくなるというメリットが生まれます。また、「基本的なハードウエア構成は同じにして、複数のグレードや製品シリーズを作る」という組込系システムの特徴にもぴったり来ます。

ドメインと制御を分離するという話は、モデルとして表現すると次のようになります。

図:モデル化したドメインと制御の分離

ドメインと制御を別のパッケージ(世界)として扱い、その間の繋がりは依存関係として書きます。そして、それぞれのパッケージにモデルが存在するという表現です。こうすることでそれぞれのモデルをシンプルにしながら、全体の構造を表現できるようになります。また、具体的な制御とドメインとの間の繋がりはシーケンス図等の別のダイアグラムで表していきます。

さいごに

ドメインと制御を分けるという話でしたが、いかがでしたでしょうか。設計の段階でモデルを階層化するという話は良く見かけますが、今回のような分析レベルのモデリングで全体を階層化して表現するというのは珍しいかと思います(設計の階層化とは考え方が異なりますが)。 次回は、このドメインと制御の間の関係のモデル化について取り上げていきたいと思います。