［技術情報］
| （株）オージス総研 | 渡辺 博之 |
| ソニー（株） | 堀松 和人 |
はじめに 組込みソフトの開発プロセス 例題の説明 ユースケース分析 アーキテクチャ要求分析 《コラム》
・ユースケースは要求仕様の一部
・ユースケース記述のまとめ方
・ユースケースどうしの関係
・要求仕様書のまとめ方システムビヘイビア分析 ドメイン定義 《コラム》
・ドメインのカテゴリ
・複雑なドメインのバリエーション
・デバイスドメインの位置付と開発方法
・ドメインのインタフェース実現方法
・ドメインのユースケースを使った再帰的開発エンティティ分析 《コラム》
・エンティティ分析のクラスカテゴリ
・エンティティ《entity》
・仕様《spec》オブジェクト構造分析 《コラム》
・オブジェクト構造分析のクラス
・カテゴリアプリケーションドメイン
・メカニズムドメイン
・ユーザーインターフェースドメインオブジェクトコラボレーション分析 《コラム》
・コラボレーション図は詳細すぎない
・コラボレーションパターンの利用オブジェクトビヘイビア分析 《コラム》
・一つのクラスには一種類の責務
・複雑すぎる状態図の分割
・状態図か状態遷移表か最後に 参考文献
はじめに
皆さんは、「組込み」と聞けば、即iアプリのような組込みJavaを想像されるだろうか。確かに携帯電話を筆頭に、ここ最近のJavaの浸透には目を見張るばかりだ。しかしよく考えてみて欲しい。Javaの適用はまだまだGUI部分に限定されており、組込みシステムの本丸とも言えるメカ制御やアプリケーションといった部分については、依然としてCやアセンブラのままというのが実情ではないだろうか。今後ますます多機能化・大規模化する組込みソフト開発のカギは、この本丸をJavaを始めとするオブジェクト指向技術を駆使して、いかに迅速・確実に開発するかにかかっているといっても過言ではない。
しかし、ここにひとつ大きな問題がある。組込みシステムのアプリケーションやメカ制御といった部分にはGUIのような定番のクラスやパターンが存在していないということだ。したがって、この部分をJava化するには、まずその部分をきちんとオブジェクト指向とUMLでモデル化することが前提となる。
以上の理由から、この記事では、Javaで過熱しているGUIの後ろに控えている、アプリケーションやメカ制御といった一見地味な部分をいかにモデル化していくのかについて、具体的な事例を使いながら紹介していく。組込み分野以外の方にも、UMLを使ったモデリング開発の実践例としてぜひ参考にしてほしい。
INDEX
組込みソフトの開発プロセス
まず、モデリングに入る前に、今回ベースにしている開発プロセスについて、簡単に紹介したい。オブジェクト指向を前提とした開発プロセスとしては、既にRational Unified Processなどが存在しているが、実用には多くのカスタマイズが発生し、その適用が容易ではないというのが実情である。そこで、われわれは今までの経験を元に、新たに組込みシステムにターゲットを絞った開発プロセスを定義した。図1はこの開発プロセスの全体像をわかりやすく示したものである。
プロセスに含まれる全ての作業は、モデルを中心とした開発とそれを実装する技術を中心とした開発の2つに大きく分かれている。後者の実装技術を独立させることで、モデルから頻繁に変わりやすい環境や実装依存部分を切り離し、より再利用性・保守性の高いものにすることが可能になる。あわせて、担当者のスキルという面でも、煩雑な実装に関する知識を特定の作業者だけに局所化できる利点を持っている。
このプロセスを眺めると、作業内容とその間のつながりが非常に細かく定義されていることにお気付きかと思う。われわれは、今までの開発経験から、オブジェクト指向開発の難しさの一つとして、次のような問題を感じていた。すなわち、要求分析や分析、アーキテクチャ設計といった上流工程での作業内容やその範囲がかなり曖昧で、かつその自由度が高いため、そこから生成されるモデルの品質や粒度がプロジェクトや担当者毎に大きく異なってしまう、という点である。今回紹介するプロセスでは作業の範囲を細かく定義するとともに、作業間のつながりを明確にすることで、この問題を解消している。
以下、簡単にこのプロセスで定義している各作業のオーバービューを紹介する。
● 要求分析
システムに対する要求をまとめる作業である。「ユースケース分析」による機能要求の定義と、「アーキテクチャ要求分析」による非機能的要求の定義といった2つの作業から構成される。
● 分析分析以下の作業は全て、静的な構造面に着目した「構造モデル」と、主にビヘイビア（振る舞い）に着目した「ビヘイビアモデル」の2種類のモデルを作成することを基本に据えている。
分析における構造モデリングは次の手順で実施する。まず「ドメイン定義」により開発対象を問題領域毎に分割する。次に「エンティティ分析」で主たる業務知識をモデル化し、最後に「オブジェクト構造分析」でシステム構築を前提としたモデル化を行う。この段階的な作業により、問題領域や業務知識ごとに適切にモジュール化された保守性・再利用性の高い構造モデルの骨格を作り出すことができる。
ビヘイビアについては、システム内部の作業手順を分析する「システムビヘイビア分析」と、オブジェクトの協調の仕方をモデル化する「オブジェクトコラボレーション分析」、個々のクラスのビヘイビアを仕様化する「オブジェクトビヘイビア分析」からそれぞれモデル化される。特に「システムビヘイビア分析」は、ユースケース分析だけでは見つからないシステム内部での作業手順や並行性・アルゴリズム（いわゆる組込みシステムが肩代わりする、従来人間がやっていた仕事の作業手順）などを、状態図やアクティビティ図などを使って開発初期から明確にしようという作業であり、組込みソフトに特化した作業である。
● アーキテクチャ設計ここでは主に、パッケージやコンポーネントという大~中粒度の概念をベースにしてシステムをモジュール化していく作業と、並行性を実現するための設計作業から構成される。
● 設計ここには、各コンポーネントやパッケージの内部を、オブジェクトをベースとした小粒度のモジュールで仕様化する作業と、実装を前提として次に述べるアーキテクチャメカニズム設計の成果物をモデルに埋め込む作業が含まれる。
● アーキテクチャメカニズム設計ここでは、モデルを実装するために必要な、環境に依存した実装方法、オブジェクトやメモリの管理方法、並行性の実現方法、コレクションや状態図の実装方法、などをライブラリや作業手順などの形で実現する。
なお、今回の記事では、特に曖昧になりがちな「要求分析」と「分析」の2つの作業に焦点を絞って、例題を用いながら具体的な作業手順やポイントなどについて説明していくことにする。
INDEX
例題の説明
それでは、今回の記事で使用する例題を説明しよう。なお、説明の都合上、既に要求仕様書としてまとめたものを紹介することにした。本来ならば、この要求仕様書自体を作成するのが要求分析作業になるのだが、例題として紹介するためにはこのような形を取らざるを得なかった。その点はご了承いただきたい。
1 装置概要この装置は、キャンディの仕分け行うもので、「キャンディソーター」と呼ばれる（図xx参照）。キャンディソーターの主な仕事は、あらかじめ装置内に充填されているキャンディをそれぞれの色に応じた容器に仕分けすることである。また、仕分け後には、あらかじめ指定された内容と仕分け結果を比較し、それらが一致するかどうかを判定する。
2 ロット
複数のキャンディがあらかじめ装置に充填されており、この単位をロットと呼ぶ。ロットは本装置が作業を行う際の単位となり、ロットに対しては以下の内容が決められている。
● ロットに含まれるキャンディの総数● ロットに含まれるキャンディの色と数（例：赤5個、白2個、黄1個など）
● 各色を入れる容器の位置（色毎に左、中央、右のいずれか）
● 色の判別が不能なキャンディを入れる容器の位置（左、中央、右のいずれか）
なお、これらの値はあらかじめプログラム上に記述されており、動作中の変更はできない。
3 キャンディの仕分け手順
まず、装置に充填されたキャンディを一つずつ取り出し、その色を判別する。判別後、色毎に指定された容器にキャンディを運搬する。ただし、本装置では、左、中央、右の3種類の容器しか使用できないため、キャンディの色が3色以上ある場合は、容器に複数の色が混在することになる。運搬が終了したら、再び色の判別から作業を繰り返し、この作業をキャンディがなくなる（ロットのキャンディ数分）まで続ける。
4 仕分け結果を使ったロットの判定
仕分けが済んだら、ロットに含まれていたキャンディの構成（色と数）を指定された値と比較し、その結果（一致または不一致）を外部に表示する。
5 装置のメカニズム
● キャンディの色の識別
キャンディの色を識別するために、光センサーを1つ使用する。キャンディに光を当てその反射光を測定することで、色を識別することができる。
● キャンディの搬送キャンディを容器まで運搬するために、モーターを１つ使用して、キャンディ搬送用のコンベヤを駆動する。このモーターには特殊なギヤが取り付けてあり、キャンディを搬送するには、まずモーターを逆転させてキャンディを色の判別位置からコンベヤまで押し出し、次にモーターを正転させてコンベヤを駆動しキャンディを容器位置まで運搬する。
なお、キャンディは色判別位置の上方に垂直に充填されており、判別位置からコンベヤ位置までキャンディを押し出すことによって、自動的に次のキャンディが判別位置にセットされる仕組みとなっている。
● 容器の選択色毎に指定された容器位置まで搬送先を移動するために、もう一つのモーターを接続する。このモーターを回転させることで、コンベヤの搬出先を適切な容器の上に移動させることができる。
6 ユーザーインターフェース
本装置には2つのボタンがついている。電源ボタンを押下することで起動し、動作中に再び電源ボタンを押すと終了する。このボタンのON/OFFは装置上のOSによって制御されるため、プログラム側で意識する必要はない。
本装置は起動後にアイドル状態となり、スタートボタンが押されることで仕分け動作を開始する。ロット分の仕分けを完了すると、LCDを使って仕分け結果を表示する。表示中にスタートボタンが押されると、次のロットの仕分けを開始する。
7 ハードウェア制御仕様
● 光センサー
光センサーは、自らが発光しその反射光を捕らえることで対象物の色を判別する。まず、各色毎のキャンディを光センサーで読み取り、その値に調整値(3～5)を加算・減算したものを、色判定のための閾値（上限値と下限値）として使用する。
● モーターモーターは速度、回転方向を指定することで制御する。速度は0以上255以下の値を指定し、回転方向は、前進／後進／ブレーキ／OFF(空回り)のいずれかを指定する。動作時間を指定したい場合は、アプリケーション側で時間の制御を行わなければならない。
● ボタンボタンの押下状態は、OSにより該当するグローバル変数に格納されている。また、ボタン状態の監視は、取りこぼしを防ぐために、約100msec以下のサイクルで行う必要がある。
● LCDLCDには、文字列(英数字)と整数(10進または16進)が最大4桁まで表示できる。
8 アーキテクチャ要求
本装置のアーキテクチャ要求は以下の3点である。
● 保守性・拡張性
ハードウェア構成は将来的に変更が予測される（センサー数やモーター数の増加など）ため、これへの対応が容易に可能なこと。同時に、ハードウェアの変更の影響が最小限となるような構成とすること。
● 再利用性センサーやモーターなどハードウェア個々の制御を行うクラスは、キャンディソーターだけでなく、同じハードウェアを使用する他の装置にも流用したい。
INDEX
ユースケース分析
まず、システムを開発するには、そこに求められる機能的な要求を把握することが先決である。ユースケース分析では、このシステムの機能要求をUMLのユースケースモデルを使って仕様化していく。ここでの成果物は、次に紹介するアーキテクチャ要求分析の結果とあわせて、最終的に要求仕様書の形でまとめられる。
なお、この作業の本質は機能をもれなく抽出し定義することであり、それをユースケースという形でまとめるのは副次的なことに過ぎない。たとえば、今回のように予め要求仕様書という形でまとまっていれば、あえてユースケースとしてまとめなくても十分である。
今回は、参考までに要求仕様書にある機能をユースケースとして整理してみる。図2はこのシステムのユースケース図である。
各ユースケースの記述については、要求仕様書に記述されているため省略する（記述方法の詳細についてはコラムを参照）。
また、ユースケースの実体として、それぞれ以下のケースが考えられるため、これらをシナリオとしてリストアップする。
● キャンディを仕分けする《 正常系 》
・1つのロットのキャンディを仕分けする
・複数ロットのキャンディを仕分けする《 例外系 》
・キャンディがロット指定数より不足する
・ロットに未指定色のキャンディが含まれる
・仕分け中にエラーが発生する
・仕分け中にスタートボタンが押される
● ロットの判別を行う《 正常系 》
・ロットの判別結果がOK
・ロットの判別結果がNGまた、ユースケース間の関連（これについてはコラムを参照）については、図3のような状態図として仕様化している。
INDEX
アーキテクチャ要求分析
ここでは、非機能的な要求をまとめて定義する。たとえば、保守性や拡張性、再利用性などと言った要求（変更が予想される部分や適用範囲に対する具体的な指示など）や実装上の制約（稼働環境、リソース制約、実行効率など）といった特定の機能に依存しない要求について記述する。また、メカニズムやハードウェアに対する仕様もあわせて記述する。
なお、今回の例題に関しては、予めこれらの要求は要求仕様書の中に記述済みであるため、この作業は省略する。
INDEX
《コラム》
ユースケースは要求仕様の一部
UMLを使った開発で大きな落とし穴となり易いのがユースケースである。ユースケース図を書くことで要求仕様が整理できたと勘違いしてしまうのだ。ユースケースはあくまでも機能要求の整理の仕方であって、本文にも書いたようにユースケース記述や非機能要求があって、初めて要求仕様が完成することを忘れてはならない。
また、既存システムなどで既に十分な機能要求ドキュメントが存在しているのであれば、それで代用しても構わない。ただし、これらもユースケースとして整理しておくと開発の目安（機能の優先付け、繰り返し開発の単位など）として有効なことも多い。
ユースケース記述のまとめ方
ユースケース記述の例としてよく用いられるのが自然言語による記述である。もちろんこれで十分な場合も多いが、ユースケースで実現する機能のワークフローが複雑な場合には、アクティビティ図やフローチャートなどで記述したほうがわかりやすい。また、ユーザーとシステム間での手順が複雑な場合には、状態図やシーケンス図を用いることで二者間のメッセージの流れをうまく表現することができる。
ユースケースどうしの関係
ユースケース間の関係（排他関係や並行関係など）や、システムに「動作モード」などが存在する場合、ユースケース図やユースケース記述だけではこれらをうまく表現するここができない。このような場合には、システム全体に対する状態図を書くと、うまく表現できることが多い。これは、状態図を使うことで、特定の状態に依存する機能を表現することが可能になるからで、動作モードや関係を持つユースケース（の実行状態）をそのまま状態として切り出すことでユースケース間の関係を状態間の関係で表現できるようになる。但し、状態を定義する場合には、あくまでもユーザーが意識する粒度に抑えておかないと、要求仕様の範疇を越えてしまうので注意が必要である。
要求仕様書のまとめ方
今までの結論として、要求仕様書は以下のような内容から構成される。
● 機能仕様ユースケース図とユースケース記述を用いるが、先述したとおり既に機能仕様書があればそれで代行しても構わない。
ユースケース記述は、自然言語、アクティビティ図、状態図、シーケンス図などを使用して記述する。なお、複数のユースケース間の関係を補足するために、通常システム全体に対し、１つの状態図を作成すると有効であることが多い。
● 非機能仕様アーキテクチャ要求分析の結果を非機能要求仕様としてまとめる。内容には、システムのアーキテクチャに対する要求（保守性・拡張性・再利用性など）、システムに対する制約、装置のメカニズム、ハードウェア制御仕様、エラー仕様、その他各種規約（UI基準、プロトコルなど）が含まれる。
INDEX
システムビヘイビア分析
通常、組込みシステムの持つ多くの機能は、ユーザーの意思や行動の一部を肩代わりしており、見た目以上に内部処理が複雑なことが多い。一方、先に行ったユースケース分析は、あくまでも外部から見た機能要求に着目しており、このような内部機能の複雑さについては一切考慮していない。システムビヘイビア分析とは、このシステムの内部で行われる、いつ、どんな作業を、どういった順序で、どのように分担して行うのか、といったビヘイビアを検討する作業である。そして最終的にここで作成されたビヘイビア仕様が、オブジェクトのコラボレーションを検討する際のシナリオとなる。
つまり、システムビヘイビア分析とは、ユースケース分析とコラボレーション分析の間を埋める、組込みシステム特有の作業とも言える。
この作業では、ビヘイビアを状態図またはアクティビティ図で記述する。どちらを使うかはシステムの特性によって異なり、イベント駆動のシステムであれば状態図、処理の順序（シーケンス）が中心のシステムであればアクティビティ図が効果的である。
図4は、ユースケース「キャンディを仕分けする」に対するシステム内部の実現手順を示したアクティビティ図である。この図では、キャンディを仕分けするために最適な手順を示しており、今回は「色判定工程」「搬送工程」「回転工程」の3つの工程をそれぞれパイプライン的に制御することで最適な効率が得られるように考えてみた。アクティビティ図の各レーンが並行に行われる工程を表し、各レーン内に記述されている凸型の5角形と凹型の5角形はそれぞれ工程間で同期を取るためのイベントの送信・受信を表している。
● 色判定工程キャンディの色を判定し、搬送工程と回転工程に同時に動作指示を出す。
● 搬送工程検査位置（色判定位置）からキャンディをコンベヤに押し出す作業とキャンディをコンベヤで容器まで搬送する作業を行う。
● 回転工程コンベヤの先端が該当する容器位置になるようにキャンディの色に合わせ最適な位置にコンベヤを回転させる。
なお、ここでの作業ではオブジェクトについては一切考慮せず、単にシステム内部の仕事をどのような分担でどういった手順で進めるのが効率的なのかを考えることがポイントになる。
INDEX
ドメイン定義
システム内部の分析を詳細に行うにあたり、システム内部を複数の問題領域(ドメイン)に分割してそれぞれを定義する｡
数人規模程度のきわめて小さいシステムを除いて、分析担当者全員が同じ知識を持ち、全員で共同作業を行っていくことは効率的ではないし、現実的でない｡ある問題領域に対する専門家、あるいは専門知識を共有するチームを複数編成し、並行して分析作業を行う方が効率的である｡
ドメインとは、この専門家(チーム)が責任を持って分析を担当する問題領域のことである｡従ってドメインの境界は実装時のコンポーネントの境界と異なることもある｡
図5にキャンディソーターのドメインの構造を示す｡
ここで、パッケージはドメインを、依存関係はその問題領域の解を依存している下位のドメインに求めていることを表している｡なお、最上位に位置するドメイン(通常アプリケーションドメインと呼ぶ)は、要求分析で分析された問題領域そのものである｡それ以外のドメインは、上位のドメインからの要求に対して解を与えることが問題領域となる｡そのための、別の専門知識を必要とする｡このように、システムを再帰的に分割していくことにより、効率的な分析作業を行うことができる｡
● キャンディの仕分けキャンディソーターの要求仕様そのものを問題領域とする、アプリケーションドメインである｡このドメインを実現するためには業務知識の他に、ユーザーインターフェース、メカニズムといった他のドメインを必要とする｡
● メカニズムコンベアや回転台といった、キャンディソーターのメカニズムを制御することを問題領域とするドメインである｡メカニズムに関する知識の他、実現するためにはデバイスドメインを必要とする｡
● ユーザーインターフェースユーザーからシステムへの入力、ユーザーへの表示などのいわゆるLOOK&FEELを問題領域とするドメインである｡ユーザーインターフェースに関する知識の他、実現するためにはデバイスドメインを必要とする｡
● デバイスソフトウェアとハードウェアのインターフェースを問題領域とする｡ハードウェアの知識を必要とする｡
ドメインが定義できたら、次にドメイン間のコラボレーション図を用いてドメインに割り当てられた責任と定義を検証する｡図７に「キャンディを仕分けする」のコラボレーションを、図８に「ロットの判別を行う」のコラボレーションを示す。これらの図は、ユースケースごとに作成し、ドメインの責任に漏れや重複がないかを確認する｡
INDEX
《コラム》
ドメインのカテゴリ
組み込みシステムのドメインはおおよそ以下のカテゴリに分類可能である｡
● アプリケーションシステム固有の業務に関する知識｡各システムによって全く異なる｡
● メカニズムアプリケーションを支える様々な仕組み｡メカ、通信プロトコル、DBMSなどある程度汎用性を求められる｡
● ユーザーインターフェースGUIから物理的なコンソールまで実現方法は様々だが、組込みシステムといえども、ほとんどの場合必要となる｡
● デバイス組込みシステムの場合、必要の無い場合は少ない｡必ずあるといっても良い｡
複雑なドメインのバリエーション
複雑なシステムになればなるほど機能は増え、複雑化する｡これに応じて専門家の数も増え、またその専門知識の幅も広がるため、ドメインの数も多くなってくる｡システム上で機能すべきアプリケーションの機能が増えていく場合には、最上位のドメインが横に広がる(パーティショニング)傾向があり、機能が複雑さを増していくと、ドメインの構造が縦に深くなる(レイヤリング)傾向がある｡
デバイスドメインの位置付と開発方法
デバイスに関する知識を表現するのに、オブジェクト以外の方法が適している場合も多い｡レジスタのアドレスやビット位置を表すI/O表など、オブジェクト指向にこだわらずに分析したほうが良い｡
ドメインのインタフェース実現方法
設計に関する事柄なので詳しくは述べないが、ドメインのインターフェースの実装にあたっては、Javaならインターフェースクラス、C++なら抽象クラスや静的メンバー関数のみをもつクラス、Cなら関数群などが使用されることが多い｡
ドメインのユースケースを使った再帰的開発
ドメイン分割された最上位のドメインに対する要求は、要求分析の結果そのものであるが、それ以外のドメインの定義は別途行う必要がある｡これにもユースケースを用いることができる｡ユースケースをオブジェクト指向分析した結果、下位のドメインのユースケースを定義でき、またこのユースケースをオブジェクト指向分析してさらに下位のドメインのユースケースを定義して、と再帰的に開発していく方法である｡このようにすると、システム全体に対して、要求仕様に対する分析結果の検証とトレースを行うことができる｡
INDEX
エンティティ分析
システムをドメインに分割した後は、いよいよ各ドメインの静的な構造をクラス図でモデル化していく作業に入る。まず最初は、開発プロセスの項で述べたように、業務知識をモデル化するエンティティ分析からスタートする。
エンティティ分析での対象ドメインは業務知識を扱うアプリケーションドメインになる。また、この時点ではシステムの実現方法等は考慮しないため、対象とするクラスもエンティティクラスと呼ばれる主として情報を主体としたクラスに限られる（詳細はコラム「エンティティクラスのカテゴリ」を参照）。
それではさっそく例題に対してエンティティ分析を開始してみよう。まずは、「キャンディの仕分けを行う」というこのシステムの主な業務に関する概念を分析するため、アプリケーションドメインである「キャンディの仕分け」ドメインの中心的なオブジェクト（エンティティ）を抽出し、それをクラスとしてモデル化する｡
● 制御対象を考えるまず、このシステムで制御される対象である、キャンディに関する情報中心にモデリングする｡
図9では、キャンディの他、仕分け作業の単位であるロット、キャンディやロットを規定したロット仕様、キャンディ仕様、同色キャンディ仕様を抽出し、モデリングしている｡
● 業務内容を考える次に、このシステムの業務である、仕分けに関する情報を追加し、モデリングする｡
図10では、仕分け業務のルールを規定するクラスである、「仕分け仕様」、「仕分け結果」、「色別仕分け結果」及び「容器仕様」を追加している｡なお、分析を進めた結果、キャンディそのものは扱う必要がなく、必要なのは仕分け結果であることが判明し、「キャンディ」は削除している｡
INDEX
《コラム》
エンティティ分析のクラスカテゴリ
「オブジェクト指向開発が難しいのは、何を基準にしてクラスを決めればよいのかわからないからだ」という声が多く聞かれる。確かに、何をクラスにするかはオブジェクト指向のアーキテクチャを決める上での最も重要なポイントであり、その分多くの経験や知識を必要とする部分とも言える。
今回の記事では、コラムの中でわれわれがクラス抽出の際に参考にしているクラスの分類法をクラスカテゴリという考え方で紹介していく。また、モデルを見たときに、どのクラスがどのカテゴリに該当するのかがわかるようにステレオタイプも定義した。
まず最初は、エンティティ分析で使用するクラスカテゴリを紹介する。
エンティティ《entity》
エンティティとは、主として問題領域に存在する情報をモデル化するためのオブジェクトである。エンティティ分析で対象とするアプリケーションドメインに含まれるエンティティクラスには、大きく以下の2種類がある。
● 制御の対象となるもの組込みシステムが取り扱う物理的なモノや概念的なモノとそれらが持つ情報をクラスにする。前者の例としては、CDプレイヤーのCDや半導体製造装置のウェハ、プラント制御の化学薬品などがある。後者の例としては、エアコンの温度、クルーズコントロールの速度や加速度、欠陥検査システムの欠陥などといったものが挙げられる。
● 業務知識先にあげた対象に対してシステムが実施する業務（サービス）に関する情報をクラスにする。ある業務に必要なルールや手順、結果などは、このカテゴリのクラスである。例としては、CDプレイヤーの演奏順序や演奏内容、半導体製造装置の工程順序や工程内容・結果、欠陥検査システムの検査方法や検査結果などがある。
仕様《spec》
先にあげた2つのカテゴリのクラスをよく検討していくと、インスタンス毎に必要な情報とインスタンス間に共通する特性やルールの2種類のクラスが混在していることがわかる。たとえば、制御対象のウェハで言えば、個々のシリアル番号を持ったウェハクラスとウェハに共通のサイズや型番などを持つウェハ仕様クラスである。ここで、前者を実体クラス、後者を仕様クラスと呼び、それぞれ異なるクラスとして定義する。仕様クラスは他から参照されることが多く変更頻度が少ないが、実体クラスは操作の状態や結果の書き込みが主体で頻繁に変更される。したがって、これらを別のクラスにしておくことで、保守性・拡張性の高いクラス構造にすることができる。
今回の例題では、ロットに含まれるキャンディ数や色構成など、仕分け作業に必要な知識は全て仕様クラスとして表し、仕分け作業の結果だけを実体クラスとして定義している。
INDEX
オブジェクト構造分析
これまでの作業で業務の最も中心的な概念についてはモデリングできたが、実際に動作させるために必要なクラスの追加と、他の、下位のドメインの分析を行っていく必要がある｡
● 仕分けドメインへのコントロールクラスの追加エンティティクラスを用いてユースケースを実現するのに必要と思われるクラスを追加する｡
図11では、ロットの仕分け作業を制御する「ロットの仕分け作業」と、キャンディひとつひとつの仕分け作業を制御する「キャンディの仕分け作業」を追加し、エンティティクラスとの関連をモデリングしている｡ここでは、実際の制御を追加したコントロールクラスが行い、エンティティクラスはそのために必要な情報を提供することを想定している｡
● 下位ドメインのクラス定義IT関連のシステムでは、ほとんどの場合アプリケーションドメインと、ユーザーインターフェースドメインの分析が中心である｡一方、組込みシステムの場合、これらはもちろん必要であるが、最も多くの時間と労力を注ぎ込んでいるのがメカニズムドメインである｡メカニズムドメインは、ほとんど再利用が進んでおらず、毎回新規に開発しているのが現状である｡
ここではメカニズムドメインの分析結果を例として挙げよう｡
図12では「装置」を「回転台」、「色判定装置」、「コンベア」の3つのユニットからなるものとみなし、それぞれがどのような仕様、ルールに基づいて動作するかを分析し、モデリングしている｡
図13では3つのユニットが、それぞれどのような部品から成り立っているかを分析しモデリングしている｡「回転台」と「コンベア」は「モーター」を用いて動作し、「色判定装置」は「光センサー」を用いて判別を行う必要があり、そのメカ設計結果をモデリングしている｡
メカ設計の場合には物理的なものをモデリングするため比較的直感的であるが、通信などの場合にはメッセージやプロトコルなど、目に見えないものをモデリングする必要がある｡
INDEX
《コラム》
オブジェクト構造分析のクラスカテゴリ
このコラムでは、オブジェクト構造分析に必要なクラスカテゴリをドメイン別に紹介していく。
アプリケーションドメイン
このコラムでは、オブジェクト構造分析に必要なクラスカテゴリをドメイン別に紹介していく。
● コントロール《control》コントロールオブジェクトとは、エンティティオブジェクトを使用してユースケースを実現する責務を負うオブジェクトを指す。この責務をエンティティや後述するハードウェア、インタフェースなどのオブジェクトに持たせると、機能の変更がそれら全てのオブジェクトに波及してしまう。コントロールオブジェクトの導入は制御面での振る舞いを局所化するのに役立つ。
コントロールオブジェクトの候補としては、先にモデル化したシステム内部のビヘイビアモデルを活用できる。状態図であればその状態全体の制御と行うもの、アクティビティ図であればレーンの制御を行うもの、などに着目して導出することが可能である。今回の例題では、状態図からシステム全体の状態を管理する「ロットの仕分け作業」クラスを、アクティビティ図から色判定工程を管理する「キャンディの仕分け作業」クラスを導出している。
なお、コントロールオブジェクトはその名の通り制御が主体であり、ややもすると全ての機能をコントロールオブジェクトに振り分ける弊害を生みやすい。極力エンティティやハードウェア、インタフェースなどのオブジェクトに責務を振り分け、それらの調整のみをコントロールが行うように注意しなければならない。
メカニズムドメイン
このコラムでは、オブジェクト構造分析に必要なクラスカテゴリをドメイン別に紹介していく。
● ハードウェアユニット《hardware unit》
● ハードウェア《hardware》
これらのクラスは、物理的なメカニズム装置の制御を行うクラスである。前者は比較的抽象度の高い複合的なハードウェア構成を表し、後者はより具体的なハードウェア単体を表現している。通常ハードウェアユニットはハードウェアを内部に保有する形をとる。抽象度の高いハードウェアユニットクラスを使うことで、細部に左右されないメカニズム構成の本質が表現しやすくなると共に、細かなデバイス構成を隠蔽することができる。
● エンティティ《entity》
● 仕様《spec》
メカニズムドメインにもエンティティクラスや仕様クラスが存在する。たとえば、あるハードウェアを制御するために必要なデータは仕様クラスとして、それにより制御された結果はエンティティクラスとしてそれぞれ表すことができる。これらの情報は比較的変更されることが多く、前述したハードウェアクラスと別に定義しておいたほうが保守性の観点からも優位である。今回の例では、色判定装置で使用する補正仕様や色判定仕様、コンベアの搬送仕様や送り出し仕様などがこのクラスに該当する。
ユーザーインターフェースドメイン
● ユーザーインターフェース《user interface》
● システムインターフェース《system interface》
これらのクラスは、システムの外側に存在するユーザーや外部システムとのやり取りが主たる任務である。
● エンティティ《entity》
● 仕様《spec》
メカニズムドメインと同様に、このドメインにもエンティティクラスや仕様クラスが存在する。たとえば、システムの状態をユーザーに知らせるためのランプの表示パターンやユーザーが押すボタンの押下パターンなどは仕様クラスの一例である。また、ユーザーから投入されるコマンドなどは、エンティティクラスとして定義できる。
● ハードウェアユニット《hardware unit》
● ハードウェア《hardware》
明らかにユーザーインターフェースでしか使用されない装置があれば、それはメカニズムドメインよりも、このドメイン内で定義したほうが保守性の観点から良いことが多い。本文中では省略しているが、今回の例題でのユーザーインターフェースドメインでは、LCDクラスやボタンクラスを定義している。
INDEX
オブジェクトコラボレーション分析
オブジェクトコラボレーション分析は、エンティティ分析、オブジェクト構造分析で得られた静的な構造を表すクラスに動的な責務を割当てることが目的である｡その結果をコラボレーション図で表し、検証を行う｡コラボレーション図は、各ドメインに定義されたインタフェース毎に作成するとよい。
最初に仕分けドメインの「仕分けが完了してその結果を判断して表示する」というシナリオに対するコラボレーション図を図14に示す｡
これによって各クラスがどのような役割を果たしているかが明確に分かるであろう｡あるクラスに与えられた責務に違和感があれば、それは責務の割当てについて再考すべきである｡
次にメカニズムドメインのコラボレーションを見てみよう。キャンディの搬送のシナリオに関するコラボレーションについて、2つの図（図16、図17）を示す｡
要求仕様書によると、これらの動作は同時に(並行に)実行されるべきものである｡各クラスがそれぞれデータの管理、シーケンスの制御、デバイスへのインターフェースなど、与えられた責務を果たしていることが分かる｡
INDEX
《コラム》
コラボレーション図は詳細すぎない
オブジェクトコラボレーション分析の目的はあくまで責務の割当てとその検証である｡処理の正確な順序や、メッセージの詳細はオブジェクトビヘイビア分析、静的なオブジェクトの生成や初期化などは設計まで待った方が良い｡
コラボレーションパターンの利用
コラボレーションにはパターンがある｡パイプライン＆フィルター、レイヤーなど、具体例は割愛するが、これらについてはソフトウェアアーキテクチャ（参考文献参照）等を、参考にしてほしい｡
INDEX
オブジェクトビヘイビア分析
ここでは、オブジェクトコラボレーション分析で各クラスに割当てられた責務を詳細に分析する｡なお、割り当てられた責務はクラス図において、クラスのオペレーションとして表してある｡
責務には大きく二つの種類がある｡一つはそのオブジェクトの状態に関わらず、常に有効な責務であり、もう一つは状態によっては無効になったり、結果が大きく異なったりする責務である｡
組込みシステムに特有なメカニズムドメインには、特に状態を意識すべき責務が多い｡
このような責務はクラスの状態図を用いて記述する必要がある｡
「ある状態のときに、ある事象が起きたら～をしなければならない｡」というような仕様を表現するには、状態図が最も適した表現手段である｡シーケンス図を100枚書くよりもはるかに正確であることは間違いない｡
ちなみに、IT関連のシステムは、かつてはどちらかというとDBの管理が主体であったが、今日のブロードバンド時代のシステムにおいてはネットワークが非常に大きなウェイトを占めている。ネットワークとは、地球の裏側のできごとが非同期に（知らないうちに勝手に）伝わってくるシステムである。このような状況においては、ＩＴ関連のシステムも今後はますます非同期な事象に関する取り扱いが重要になってくるが、この分野に関しては組込みシステムが先達といえよう。
例題の状態図を具体的に見てみよう｡まずは仕分けドメインから、「ロットの仕分け作業」クラスの状態図を示す｡これはシステムの状態図と非常に似通っている｡これはアプリケーションドメインがユーザーにとって最も興味のある業務を扱っていることの証でもある｡この状態図からは、キャンディの仕分け中に、仕分け開始をさらに要求されても何もしないことを表している｡
次に「キャンディの仕分け作業」の状態図を示す｡それぞれのキャンディひとつひとつに対し、色の判定と、それが完了したら搬送を行うことが示されている｡また、実際の作業はメカニズムドメインに求めていることも分かる｡
最後にメカニズムドメインを見てみよう｡「コンベア」クラスの状態図は、まずキャンディの押し出しを開始し、一定時間がたったら搬送を開始し、さらに一定時間がたったら搬送が完了したとみなして、もとの状態に戻ることを示している｡これは要求仕様書の「装置のメカニズム」に記述されているとおりである｡
次に「回転台」クラスの状態図を示す｡これは、回転台は指定された位置と現在の位置が異なる場合には回転を開始し、回転時間を計算してその時間がたったらモーターを停止する｡というメカニズムを示している｡
INDEX
《コラム》
一つのクラスには一種類の責務
1クラス1メソッドではないが、一つのクラスに複数の責務が割当てられないように留意する｡責務が集中したり、複数の状態図が必要になったりするクラスは分割するか、他のクラスに責務を委譲したほうが良い｡
複雑すぎる状態図の分割
まずは状態図を階層化して整理する｡スーパー状態だけを集めた状態図を作り、これをスーパクラスが持つようにする｡各スーパー状態に対応するサブクラスを作成し、それぞれのスーパー状態内のサブ状態図をサブクラスに割当てると良い｡
状態図か状態遷移表か
状態図よりもさらに正確に書けるのは状態遷移表である｡ある状態で受け取れないイベントが発生したとき、システムは実際にどのような振る舞いをするのだろうか?無視?システム停止?状態遷移表では書くことができるが状態図には表せない｡しかし、状態図は直感的である｡レビューには状態図をまず使ってもらいたい｡その後、状態遷移表である｡
INDEX
最後に
以上、UMLを使った組込みシステムの開発について、主に要求分析・分析といったモデリングを中心の作業を紹介してきた。紙面の都合上、設計や実装等の作業まで紹介できなかったが、オブジェクト指向開発においては、やはりクラスの抽出を始めとした分析モデルの構築が開発の大きなカギを握っており、この部分を紹介できただけでも非常に有意義であったと自負している。
この記事がUMLとオブジェクト指向だけではなかなかうまく進められない開発作業のガイドラインとして、少しでも読者のお役に立つことができたのなら幸いである。
なお、筆者らは現在、「UMLを使った組込みシステムの開発ガイドライン」をeUML（embedded UML）としてまとめている。今回紹介した内容の詳細版に加えて、設計や実装、テストなども含めていく予定である。来年度早々に書籍の形で公開し、多くの人々に使用していただくことを考えているので、こちらもぜひ期待していただきたい。
INDEX
参考文献
UMLによる統一ソフトウェア開発プロセス
著者：イヴァー・ヤコブソン／グラディ・ブーチ／ジェームズ・ランボー
監訳：藤井 拓、訳：日本ラショナルソフトウェア
発行：翔泳社
ISBN：4-88135-836-7ラショナル統一プロセス入門
著者：フィリップ・クルーシュテン
監訳：藤井 拓、訳：日本ラショナルソフトウェア
発行：ピアソン・エデュケーション
ISBN：4-89471-157-5デザインパターン 改訂版
著：Erich Gamma／Richard Helm／Ralph Johnson／John Vlissides
監訳：本位田 真一／吉田 和樹
発行：ソフトバンク
ISBN：4-7973-1112-6ソフトウェアアーキテクチャ ソフトウェア開発のためのパターン体系
出版社 ：近代科学社
著：F．ブッシュマン／R．ムニエ／H．ローネルト／P．ゾンメルラード／M．スタル
訳：金澤典子／水野貴之／桜井麻里／関富登志／千葉寛之
ISBN 4-7649-0283-4オブジェクト・モデリング
著者：レオン・スター
訳：Shlaer-Mellor研究会
発行：プレンティスホール
ISBN：4-89471-036-6リアルタイムUML 第2版
著者：ブルース・ダグラス
監訳：渡辺 博之、訳：オージス総研
発行：翔泳社
ISBN：4-88135-979-7Designing Concurrent, Distributed, and Real-Time Application with UML
著者：HASSAN GOMAA
発行：ADDISON-WESLEY
ISBN：0-201-65793-7
INDEX
| © 2001 OGIS-RI Co., Ltd. |
|
