EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

UMTPモデリング技術セミナーレポート 組込み技術者はなぜ「使える」モデル図が描けないのか?~業界特有の苦悩とその打開策

  2010/03/10 00:00

ソフトウェア開発者をデスマーチから救う鍵となるモデリングは、なぜか組込みソフトウェア業界では今ひとつ普及していません。その理由とはいったい? 株式会社エクスモーションの渡辺博之専務取締役と芳村美紀常務取締役によるセミナーの様子を、本記事読者向けに、再構成してお届けします。

その重要性を頭では理解していても、実践となると難しく感じられるのがモデリングだ。特に、開発現場で試行錯誤しながら製品を作り上げていく組込みソフトウェアの世界では、“動いたもの”をモデルとしてしまいがち。しかし、モデリングを軽視して現状追認を続けていると、いつまでたっても仕事は楽にならない。では、いかにすれば開発の現場で使えるようなモデルが描けるようになるのか。同領域に通じた株式会社エクスモーションの渡辺博之専務取締役と芳村美紀常務取締役によるUMTPモデリング技術セミナーの模様を再構成してお届けする。

 

UMTP(UMLモデリング推進協議会):UML技術者認定試験やモデリング技術の研究や普及を推進するNPO

読者への挑戦!

 突然ですが、クレーンゲームのモデル図を描いてみてください。ボタンでクレーン位置を操作して景品をキャッチするあのゲームです。時間は5分。気楽に描いてみてください。

図1:練習問題
図1:練習問題

 いかがですか? ちょっとここで手を休めてあるモデル図を見てみましょう。

図2:モデリング初心者の山田さんが描いたモデル
図2:モデリング初心者の山田さんが描いたモデル

 実はこれ、モデリング初心者の山田さんが描いたモデルなのですが、彼の先輩から見ると改善の余地があるのだとか。皆さん、どこが問題なのかわかりますか?回答は後ほど。

組込みソフトウェアは一般のソフトウェアよりもモデリングが難しい

 組込みソフトウェアの開発者であれば、程度の差はあれ誰もが同意できる夢があると思います。ハードウェア構成や制御方式の変更に振り回されないようにしたい。もっと楽に追加や変更を行うことができて、しかも障害が発生しにくい開発体制を確立したい。

 その夢を叶えるためのツールとしてモデリングはとても有効です。複雑な現実を整理し、多くの人が理解できる形で共有し、その知見を再利用するという考え方が、組込みソフトウェア開発でも正しく定着すれば、厳しい開発現場の改善が実現できるはずです。

株式会社エクスモーション
専務取締役 エグゼクティブコンサルタント 渡辺博之氏
株式会社エクスモーション 専務取締役 エグゼクティブコンサルタント 渡辺博之氏

 ただし、現実にはそれが十分に達成されているとは言えません。その理由はいくつか考えられますが、端的に言えば抽象的・概念的な設計よりも目の前で実際に動く実装の方が尊重されるからでしょう。とはいえ、そうせざるを得ない理由があることも事実です。

 一般的なソフトウェアと違って組込みソフトウェアは自然現象に大きく影響される傾向があります。例えば、自動車のブレーキを制御するABSは、運転手がペダルを踏む強さだけでなく、路面の滑りやすさや凸凹などの情報を総合的に勘案して、ディスクの油圧を調整しています。このような自然現象は机上の設計で十分に想定しつくすことが困難です。

 そこへ来てコストの問題もあります。例えば、ABSの設計者は路面状況を検知するためのセンサーを望むでしょうが、そうやって必要なリソースを逐一積んでいくと車の価格が跳ね上がってしまう。製品の構成要素として設計される組込みソフトウェアは、コストなどとの兼ね合いから利用可能なリソースが常に限定されています。ABSの場合も、車輪の回転速度を測るセンサーの情報を基に路面状況などを推量します。

 「予測困難な自然現象」を「限られたリソース」で制御する組込みソフトウェアの世界では、教科書に書かれた理論どおりに設計しても目的は達成されませんし、必要なデータを直接的に取得できない場合が多い。だから、「係数を調整したら挙動が安定した」「この機器の値を使えばセンサーの代わりになりそうだ」など、現場レベルで試行錯誤を重ね、その過程で得られた実践ノウハウを取り込むことが必要不可欠なのです。「理論的に正しい設計」よりも「実際に動くもの」が尊重されることはやむを得ないことでしょう。

 結果として、組込みソフトウェアにおけるモデル図は単純に実装を引き写しただけのものになりがちですが、それらを見てもどのように機能が実現されているかという理屈はわかりません。「ただ単にそうなっている」という現状追認の図では、ハードウェアに縛られず、追加や変更を容易に行なうという“夢”の実現もまた難しいと言わざるを得ません。そして、まさにこれこそが、組込みソフトウェアをモデリングする難しさと言えます。

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

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

株式会社エクスモーション
株式会社エクスモーション 常務取締役 エグゼクティブコンサルタント 芳村美紀氏
株式会社エクスモーション 常務取締役 エグゼクティブコンサルタント 芳村美紀氏
組込みソフトウェア開発者が書いてしまいがちなモデル図
  1. 機能(手続き)で分解したモデル
  2. 物理構成で分解したモデル
  3. 制御動作で分解したモデル

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

図3:機能(手続き)で分解したモデル
図3:機能(手続き)で分解したモデル

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

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

 

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

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

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

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

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

対象を変わらない目的でとらえるそれが「使えるモデル」への第一歩

 それでは、組込みの分野で「使えるモデル図」を描くにはどうしたらいいでしょうか。まずは、制御装置があろうがなかろうが「変わらない目的」を捉えることが重要です。そして、その目的を徐々に手段レベルに落としていく階層化を行いましょう。

図6:目的を捕らえ、階層化することが「使えるモデル」への第一歩
図6:目的を捕らえ、階層化することが「使えるモデル」への第一歩

 例えば、自動販売機なら「商品販売」が目的です。プロセスは「お金をもらってその金額に見合った商品を渡す」と言い表すことができます。よく考えてみると、これはかつて駄菓子屋のおばちゃんが行っていた業務ですよね。今でこそ自動販売機がその実行主体となっていますが、プロセス自体は本質的に変化していないわけです。

 このように、具体的な実装形態にとらわれずに「変わらない目的」に着目すると、あとあと長く使えるモデルを作成できます。これは、製品ファミリーの多様化や派生化が進んで、その寿命が延びつつある組込みソフトウェアの分野では非常に重要なことです。

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

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

図1:練習問題(再掲)
図1:練習問題(再掲)

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

図2:モデリング初心者の山田さんが描いたモデル(再掲)
図2:モデリング初心者の山田さんが描いたモデル(再掲)

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

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

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

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

図8:クレーンゲームを目的ベースで整理すると・・・
図8:クレーンゲームを目的ベースで整理すると・・・
図9:モデル図にまとめると・・・
図9:モデル図にまとめると・・・

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

モデルをたくさん描いて問題を分けて整理する習慣を身につける

 ここまで、組込みソフトウェアにおけるモデリングについてお話してきましたが、使えるモデルを描くためのポイントをまとめると以下のようになるでしょう。

使えるモデル図を描くために必要なこと
  1. 実装ありきのモデルから脱却すること
  2. モデルを目的・手段で階層化すること
  3. 階層化したモデルの中でも特に目的レベルを重視すること

 もちろん、一朝一夕にできることではありません。これらを実践するためにはモデルをたくさん描いて慣れることが一番です。いきなり複雑なものに手を出すと混乱するので、小さく簡単なものから始めると良いでしょう。自動制御のない旧式の洗濯機や扇風機、黒電話などのモデル図を描いてみましょう。洗濯板やうちわ、糸電話でも構いません。

図10:身近な電化製品をモデリングしてみましょう
図10:身近な電化製品をモデリングしてみましょう
図11:始めのうちは簡単なものでもかまいません
図11:始めのうちは簡単なものでもかまいません

 ただし、モデル図を作成する際にはUML表記に従うことをお勧めします。きちんとした表現は、共有・再利用という点でも重要なことですからね。考えを整理するスキルはすぐには身につきませんが、千里の道も一歩から。今日からすぐに始め、根気よく続けていきましょう!

関連情報
  • 今回のセミナーの講演スライド、および講演者を囲んで行われたワークショップの詳細は、UMTPのWebサイトにて提供されています。
  • 「読者への挑戦!」として取り上げた問題は、UMTPのUMLモデリング技能認定試験サンプル問題の中で、【L3モデリング問題-問題2(組込み系)】の例題として提供されています。

著者プロフィール

  • EnterpriseZine編集部(エンタープライズジン ヘンシュウブ)

    「EnterpriseZine」(エンタープライズジン)は、翔泳社が運営する企業のIT活用とビジネス成長を支援するITリーダー向け専門メディアです。データテクノロジー/情報セキュリティの最新動向を中心に、企業ITに関する多様な情報をお届けしています。

All contents copyright © 2007-2021 Shoeisha Co., Ltd. All rights reserved. ver.1.5