組込み技術者はなぜ「使える」モデル図が描けないのか？～業界特有の苦悩とその打開策

クレーンゲームをどうモデリングするか？

　お待たせしました。ここで冒頭の問題に戻りましょう。このようなクレーンゲームをモデル化するのでした。

図1：練習問題（再掲）

　UMLモデリング技能認定試験 L3モデリング問題に出たサンプル問題ですから、ご記憶の方もあるかもしれません。この問題で新人の山田さんは以下のようなクラス図を描きました。このクラス図に難点があるとしたらそれはどこでしょうか。

図2：モデリング初心者の山田さんが描いたモデル（再掲）

　そう、もうお分かりですね。このモデルは、先ほど説明した「物理構成で分解したモデル」になっています。よくコンサルタントの間では“定規のようなクラスを見たら要注意”といっていますが、クレーンゲーム機のクラスはまさにそれです。使えるモデルにするためには、もう少しクレーンゲーム機クラスの中身を掘り下げていく必要がありそうです。

　一方、山田さんの先輩は図7のようなクラス図を作成しました。図2に比べて変わったところはどこでしょう？

図7：山田さんの先輩が描いたクラス図

　そうですね。クレーンゲーム機クラスが小さくなり、代わりに「●●機構」という名称のクラスが増えました。山田君のものよりもずっとわかりやすくなっている気がします。では、このクラス図を見れば、クレーンゲームの本質がわかるでしょうか？ まだ不十分な気もしますね。そこでこんなモデルを考えてみました。

図8：クレーンゲームを目的ベースで整理すると･･･

図9：モデル図にまとめると･･･

　クレーンゲームの動きを目的ベースで整理すると、「行って、取って、戻って、放す」。それを目的レベルと手段レベルで整理したものが右上の図です。気をつけていただきたいのは、ゲームとしての言葉と制御のための言葉は違うということ。デバイスとルールを混在させないことがポイントです。