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

組み込み開発者が犯しがちな「動かすだけのモデル」3タイプ

　前述したように、組込みソフトウェアのモデル化にあたっては、「動かすだけ」のモデルになりがちという問題があります。ここからは、組込みソフトウェア開発者が描いてしまいがちな「動かすだけのモデル」を具体的に紹介していきましょう。大きく3つのタイプがあります。

株式会社エクスモーション

株式会社エクスモーション 常務取締役　エグゼクティブコンサルタント 芳村美紀氏

　自動販売機をテーマに1つずつ見てみましょう。まずは、「機能（手続き）で分解したモデル」の例です（図3）。

図3：機能（手続き）で分解したモデル

　構造化手法で行う機能分担でモデリングするとこのような図になりがちです。「システムデータ」部分にグローバルな情報が押し込まれていて、要求に変更があると全面的な見直しが必要になります。C言語で長年開発を行ってきたエンジニアが、こういうモデルを作りがちです。

　「物理構成で分解したモデル」もよく見られるパターンです（図4）。

図4：物理構成で分解したモデル

　このモデルでは、自動販売機というひとつのクラスにすべての処理が詰め込まれ、その周囲に、デバイスやメカ機構など物理的な実体を表すクラスが登場します。わざわざモデリングという手法を使うのは、自動販売機の機能を可視化したいからなのですが、それがひとつのクラスに詰め込まれてしまっては意味がありません。オブジェクト指向では「モノ」に着目するよう教えられますが、それを十分消化しきれていない経験の浅いエンジニアがやってしまいがちなミスです。

　最後は、「制御動作で分解した」モデルを紹介しましょう（図5）。

図5：制御構成で分解したモデル

　こちらは、制御という観点で整理されていますが、動かすノウハウそのものは各クラスの中に埋没してしまっています。つまり、制御の単位や方法が変われば、すべて作り直しになってしまうわけです。ハードウェアの“おまけ”的な位置づけでソフトウェアを開発してきたエンジニアがこのようなモデルを描いてしまいがちです。