組み込みUMLを成功させる5つの鉄則とは？：組み込み開発にUMLを活用しよう（2）（1/3 ページ）

UMLを組み込み開発に適用する際は、「概念モデルから着手する」「デバイスとの関係を明確に」など5つのポイントを守る

[塚田 雄一 キャッツ，＠IT MONOist]

はじめに

　日々膨大化／複雑化をたどっている組み込み開発。本記事では全3回の連載で「UML」による解決策を紹介しています。前回は「UMLと組み込み開発の関係」を紹介しました。

　第2回に当たる今回は「UMLの組み込み開発への適用ポイント」を紹介したいと思います。さらに今回は、筆者が参加するUMTP（UMLモデリング推進協議会）「組み込み分科会」（以下、分科会）とは別の活動で、組み込み開発のハードウェアを取り扱う「SoC分科会」とUMLとの関連についても触れてみます。

エレベータを題材にしたリファレンスモデルに挑戦

　今回の目玉は、UMLを組み込み開発へ適用するポイントです。分科会では、UMLを組み込み開発に適用するためのガイドラインとして、リファレンスモデルを作成しています。その取り組みの中で明らかになったUMLの適用ポイントを紹介していきます。

　リファレンスモデル作成への取り組みでは、UMLの教育などの際によく利用されるエレベータを題材にし、その中で特に組み込みらしく動作しているキャビン部分についてモデリングを行うことに決定しました。

　しかし、分科会にはエレベータの開発経験者はおりません。またエレベータについて豊富な知識があるわけでもありません。そこでまず、エレベータに関する知識を高めるため、エレベータ関連の情報を集めることにしました。例えば通常ボタンと車椅子ボタンが押された場合の違い、災害など緊急停止した際などの処理などさまざまな情報です。

　そして、いよいよモデリングの開始です。エレベータの知識を集めたメンバーは、自信を持ってモデリングに臨みました。一定のところまでスムーズに進んだのですが、ある個所でモデリングに行き詰まってしまいました。それもそのはずです。エレベータの開発経験のないメンバーが多くの知識を詰め込んだだけで、いきなりモデリングを開始したため、細かい仕様を一度に考え過ぎていたのです。モデルは複雑になってしまい、どの処理部分でどの機能を実現すればよいか、明確ではなくなってしまいました。

図1　エレベータモデル失敗例

　UMLのモデリング経験のあるエンジニアたちでさえ、このような事態に直面します。また今回のように、仕様段階においてモデルの複雑さが明確になったのは、UMLを使用するメリットであるともいえるでしょう。そこでエレベータの知識の少ないメンバーは、単純な仕様からモデリングをし直すことにしました。

ポイント1

初めてモデリングする際は、まず概念モデルから

概念モデルに立ち返って再挑戦！

　それでは概念モデルを紹介いたします。いきなりモデルが出てきましたが、深く考えずに気軽に読んでみてください（UMLの用語をなるべく使わず、一般的な用語を使って説明します）。まずモデリングの流れを説明します。

• 最初に、キャビンはどのような「要求」があるかを考える
• その要求からはどのような「処理」があるかを考える
• その処理を実現するのはどのような「動作」をしなくてはいけないかを考える
• 最後に、物理的にどのような「デバイス」が必要になるかを考える

　初めに要求する人（アクタ）は何になるのかを考えてみましょう。要求する人は乗客ですが、まだエレベータに乗っていないフロアにいる乗客とエレベータに乗っている乗客の2種類が考えられます。フロアの乗客はエレベータに乗るために「キャビンを呼び出す」という処理が考えられ、すでにエレベータに乗っているキャビンの乗客は「目的のフロアに移動する」という処理が考えられます。よって処理としては2つ考えられます。

図2　キャビンのユースケース図 Vol.1