組み込みUMLのリファレンスモデルを学ぶ：組み込み開発にUMLを活用しよう（3）（1/3 ページ）

ユースケース分析やドメイン図、概念モデルなど、組み込み開発に特化したUMLモデリングの各工程を詳細に解説する

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

はじめに

　組み込み開発に「UML」を導入するメリットを紹介する本連載は、第3回に当たる今回が最終回となります。第1回は「UMLと組み込み開発の関係」、第2回は「UMLの組み込み開発への適用ポイント」を紹介しました。今回はエレベータのキャビンをモデリングした「リファレンスモデル」を紹介します。UMLを組み込み開発にどのようにして適用していくか、その参考になればと思っています。また、本稿を読む前に、第1回、第2回をもう1度読んでおくと、より理解が深まると思います。

　UMTP（UMLモデリング推進協議会）モデル共有部会の「組み込み分科会」（以下、分科会）では、複雑化／膨大化する組み込み開発にUMLを適用していくことを目的とし、そのためのガイドラインとしてリファレンスモデルを作成しています。題材は「エレベータのキャビン」に決定しました。一般のUMLモデリングの教材でもエレベータ・モデルが使用されていますが、分科会は組み込み開発に限定するため、実際に動作している部分（キャビン）をモデルの題材にしました。モデルは本稿執筆時点ではまだ開発中ですが、これまでの成果を紹介したいと思います。

エレベータの要求仕様

　第2回で紹介したように、分科会では一度モデリングに行き詰まり、概念モデルからやり直しを行いました。従って以下の要求仕様を参照すると分かりますが、「キャビンが呼び出され」→「移動階に移動して」→「ドアが開いて降りる」といった非常に単純な要求仕様となっています。それでは、以下エレベータの要求仕様を参照ください。

エレベータの要求仕様

シャフトは1つのみ

キャビン移動の仕様

• フロア呼び出しボタン△▽が押された際は、押された階に移動してドアを開く
• キャビン内移動階ボタンが押された際は、移動して、ドアを開く

乗客が行う動作

フロアの乗客

1. 上下ボタンを押す
2. キャビンが移動してくる
3. →到着する
4. ドアが開く
5. →乗り込む

キャビンの乗客

1. 目的のフロアボタンを押す
2. ドアが閉まる
3. キャビンが移動する
4. →到着する
5. ドアが開く
6. →降りる
7. ドアが閉まる

キャビンの動作

ドアを開く

ドアを閉じる

目的フロアへ移動する

ユーザーのイベント

フロア乗客から呼び出す（上下ボタンを押す）

キャビン内乗客から（移動先指定、ドアを開く、ドアを閉じる）

開発フローと各工程の作業

　まず、開発フローと各工程の作業の説明をします。開発フローは、

要求仕様（分析）→ドメイン分け→分析モデリング→設計モデリング

の順番で開発を行います（図1）。

図1　開発フローと各工程の作業

　要求仕様（分析）の工程では、ユースケース図とユースケース記述を用いて表現します。次にドメイン分けの工程では、パッケージ図を用いて表現します。

　そして次は分析モデリングの工程ですが、ここでの成果物は分析モデルクラス図になります。どのようにしてクラス図を作成していくかがノウハウになります。まず名詞抽出を行い、責務を記した概念モデルを作成します。そしてCBC（クラスベース・コミュニケーション図）とIBC（インスタンスベース・コミュニケーション図）を作成します。CBCはUMLで規定された表現ではなく、UMTP会員企業様で使用していたオリジナルのモデル図です。IBCはUMLのコミュニケーション図そのものなのですが、CBCとの区別のためにIBCと呼称しています。組み込み開発にUMLを適用するうえで有効であったため、今回使用することにしました。現在、分科会では分析作業の洗練中であり、その作業の終了後に設計モデリングを行います。

　UMLは単なる表記法であり、どの工程でどのように使用するかがポイントになります。以下に各工程でのポイントを紹介します。