|
[2006 年 2 月号] |
［技術講座］
前編では，ドメインユースケース分析までをご紹介しました．中編では，エンティティ分析からオブジェクトコラボレーション分析までをご紹介します．特に，前編で書いたドメインユースケースが，クラスとどのように関係してくるのか，そのつながりを知りたい方の参考になるのではないかと思います．
前編では，分析のうち，ドメイン定義，副アクタの抽出，およびドメインユースケース分析まで行いました． 中編では，エンティティ分析，オブジェクト構造分析，およびオブジェクトコラボレーション分析を行います．
2．1．エンティティ分析
エンティティ分析では，ドメイン毎にエンティティクラスを抽出し，その関係をクラス図で表現します．エンティティクラスとは，そのドメイン固有の情報を表すクラスで，複数のドメインユースケースに登場する，ドメインユースケース共通の概念です．エンティティクラスを適切に抽出することで，変更に強いシステムを作ることが可能になります．
エンティティクラスを抽出するときには，分析対象のドメインのすべてのドメインユースケース記述を参照します．ドメインユースケースに現れる「情報」を表す言葉や，オブジェクトフローで表現したオブジェクトなどがエンティティクラスの候補となります．
それでは，ユーザインターフェースドメインに着目して分析を進めましょう． 前編で分析した，ユーザインターフェースドメインのユースケース記述のひとつ「タッチパネル押下通知を受け取る」（図2.1）を例に考えてみましょう．
※クリックすると拡大します．
＜図2.1.タッチパネル押下通知を受け取る-ユースケース記述＞
（本記事のUMLダイアグラムは，全てUML1.5に準拠しています．）
このドメインユースケース記述では，デバイスドメインから"座標情報"を受け取り，その座標が"登録モードボタン"の範囲か，"発信モードボタン"の範囲か，"操作ボタン"の範囲かを確認して，"モード"を切り替える下請けドメインユースケースを呼び出すと記述されています．ダブルクォーテーション（""）で囲んだ部分が情報を表す言葉なので，エンティティの候補とします．同様に，他のドメインユースケースからもエンティティの候補を抽出します．
次に，抽出したエンティティの候補を分類します．分類を行うとき，ステレオタイプやキーワードを用いるとわかりやすく表現できます．今回は，eUMLで用いられているステレオタイプentity,specに加え，キーワードenumerationを用いて表現しています．
- ステレオタイプentityを持つクラスは，システム実行中に変化する可能性のある情報を表します．
- ステレオタイプspecを持つクラスは，システム実行中に変化する可能性のない情報を表します．
- キーワードenumerationを持つクラスは，列挙情報を表し，属性フィールドのいずれか一つの値をとることを意味します．
ユーザインターフェースドメインには，システム起動時から変化することのない，ボタンの座標配置や文字列に関する情報があります．よって，これらは，specに分類されます．分類の過程で，ドメインユースケースに言葉としては現れない，共通の概念を表すエンティティを抽出します．例えば，"登録モードボタン"，"発信モードボタン"，"操作ボタン"は，すべて"ボタン"という概念を表しています．これら"ボタン"からは，通常時の色，選択時の色，および文字の色を取得することが可能です．また，そのボタンが押されているかどうかを，座標情報を元に判断することが可能です．よって，これら共通の操作をもつインターフェース「I_ボタン」を抽出しました（図2.2）．
次に，これら3つのボタンが持つべき情報について考えます．"登録モードボタン"と"発信モードボタン"は，表示のための名前と，ボタンの位置と大きさをあらわす矩形情報を持つ必要があります．一方，"操作ボタン"は，名前と矩形情報に加え，学習リモコンドメインに通知を行うための番号を持つ必要があります．よって，"登録モードボタン"，"発信モードボタン"をあらわすエンティティクラスを"モード切替ボタン"として抽出し，"操作ボタン"をあらわすエンティティクラスを"操作ボタン"として抽出しました．これら2つのエンティティクラスから，インターフェース「I_ボタン」に実現の関係を結びます．そして，これらのエンティティクラスを属性として持つspecクラス，"モード切替ボタン仕様"，"操作ボタン仕様"を抽出しました．なお，エンティティクラスの候補の"座標情報"はデバイスドメインのエンティティと判断したため，ユーザインターフェースドメインには含めていません．
※クリックすると拡大します．
＜図2.2.ユーザインターフェースドメイン エンティティ分析＞
他のドメインユースケースに対しても同様の手順で分析を行い，クラス間の関係をクラス図に記述します．なお，クラス図における属性の可視性は，この段階ではそれほど意識しなくてもよいと思います．図2.2では可視性表記および属性に対応するsetter,getterなどの操作は省略しています．
2．2．オブジェクト構造分析
オブジェクト構造分析では，ドメインユースケースを実行するために必要なクラスを抽出し，エンティティ分析で抽出したエンティティクラスとの関係を適切に定義します．
まず，ドメインのインターフェースを定義します．ドメインユースケース記述において，他のドメインのユースケースを呼び出す部分がありますが，これはすべてインターフェースを介して行います．まずは，各ドメインに1つずつインターフェースを定義し，依存関係を記述します．インターフェースの依存関係は，前編で示したドメインの依存関係（図2.3）と同じになります．
※クリックすると拡大します．
＜図2.3.学習リモコンのドメイン定義＞インターフェースの依存関係を示すクラス図を図2.4に示します．なお，インターフェース以外のクラスは後ほど分析するため，この段階では，ドメイン名と同じ名前のコントロールクラスを便宜的に配置しています．
※クリックすると拡大します．
＜図2.4.インターフェースの抽出＞図2.4では，一部のドメインが相互に依存しています，例えば，学習リモコンドメインはユーザインターフェースドメインのインターフェースに依存し，ユーザインターフェースドメインは学習リモコンドメインのインターフェースに依存しています．相互依存しているドメインは，依存先ドメインの存在を前提とするため，常に一緒に扱うことになってしまいます．そこで，ドメインの相互依存の解消を行います．相互依存の解消は以下の手順で行います．
- アーキテクチャ要求分析の結果を元にして，インターフェースを分割．
- 分割したインターフェースをどのドメインの管理下に配置するか決定．
[参考]ドメインの相互依存の解消タイミング
eUMLでは，ドメインの相互依存の解消は，アーキテクチャ設計と呼ばれる，オブジェクト構造分析よりも後工程で行うことになっています．しかし，後述のオブジェクトコラボレーション分析などで，相互依存解消後のインターフェースを利用して記述した方がわかりやすいため，私は分析フェーズで行っておくべきと考えています．
インターフェースの分割と，適切なドメインへの配置を行った結果を図2.5に示します．なお，相互依存解消後（図2.5）のインターフェースの色と，相互依存解消前（図2.4）のインターフェースの色は対応しているので，どのインターフェースを分割したのか確認してみてください．
※クリックすると拡大します．
＜図2.5.相互依存解消後のインターフェース＞具体的な分割手順に関して，ユーザインターフェースドメインと学習リモコンドメインに着目して確認していきましょう．
分割前は，学習リモコンドメインはI_ユーザインターフェースに依存し，ユーザインターフェースドメインはI_学習リモコンに依存していました．
前編で行ったアーキテクチャ要求分析の結果，「学習リモコンは，ユーザインターフェースに変更があったとしても，対応が容易であることとします．」という要求を抽出しているので，学習リモコンドメインが，I_ユーザインターフェースに依存する点に関して修正する必要があります．具体的には，I_ユーザインターフェースに「処理結果を表示する」といった操作が存在し，それを学習リモコンドメインから呼び出すといった形だと，問題が発生します．例えば，ユーザインターフェースが，送信失敗などの処理結果を，LCDではなく音で知らせるように変更された場合，学習リモコンドメイン側の変更が必要になってしまいます．
そこで，I_ユーザインターフェースのうち，登録結果を表示する部分を分割し，I_処理完了通知としました．合わせて，そのインターフェースを学習リモコンドメインに配置しました．これによって，学習リモコンドメインは，自ドメインの管理下にあるインターフェースを利用することになります．もし，ユーザインターフェースに変更があった場合，I_処理完了通知を実現しているユーザインターフェースドメインで，その変更を吸収します．I_処理完了通知の操作は，「処理完了を通知する」というような，通知の実現手段（表示，音など）に言及しない表現とします．同様に，I_機器制御情報管理，I_機器制御情報受信通知，およびI_信号送受要求を学習リモコンドメインに配置しました．これによって，アーキテクチャ要求「学習リモコンは，リモコン信号の送受信方法や，保存方法に変更があったとしても，対応が容易であることとします．」に対応できます．
[参考]アーキテクチャ要求が異なる場合の相互依存解消
前述の通り，ドメイン間の依存関係解決方法は，アーキテクチャ要求分析の結果によって変わってきます．図2.6にその一例を示します．
※クリックすると拡大します．
＜図2.6.アーキテクチャ要求が異なる場合の相互依存解消例[参考]＞例えば，アーキテクチャ要求分析の結果が，「ユーザインターフェースや，信号送受部，および信号の格納は，学習リモコンアプリケーション以外のアプリケーションでも容易に再利用可能であること．」であった場合，ユーザインターフェースドメインなどは学習リモコンドメインに依存するわけにはいかないので，図2.6のような結果になると考えられます．
また，アーキテクチャ要求の結果が，「ユーザインターフェースの再利用性を高め，かつ，学習リモコンアプリケーションがユーザインターフェースの変更の影響を受けないようにしたい」，というケースも考えられます．そのような場合は，学習リモコンドメインとユーザインターフェースドメインの間にAdaptorと呼ばれる，相互の要求を吸収する層を設けることで解決できます（図2.7）．
＜図2.7.Adaptorを利用した相互依存解消例[参考]＞ただし，ソフトウェア構成はその分複雑になります．よって，アーキテクチャ要求分析の段階で，本当にそのような要求があるのか確認することが重要です．
ドメインのインターフェースが確定したら，ドメインユースケースに対応したコントロールクラスを抽出します(図2.8)．
※クリックすると拡大します．
＜図2.8.ユーザインターフェースドメイン オブジェクト構造分析＞図2.8における黄色のクラスがコントロールクラスです．以下に，コントロールクラスとドメインユースケースの関係を示します．これに加えて，コントロールクラスに対応する，インターフェースと呼び出し元も合わせて示しました．
ドメインユースケース，コントロールクラス，
対応するインターフェースと呼び出し元の関係
ドメインユースケース コントロールクラス インターフェース 呼び出し元 初期化する 初期化 I_ユーザインターフェース システム起動部 タッチパネル押下通知を受け取る タッチパネル押下通知受信 I_タッチパネルイベント通知 デバイスドメイン 登録モードにする
発信モードにするモード切替ボタン管理 なし タッチパネル押下通知受信コントロールクラス 操作ボタンを選択する 操作ボタン管理 なし タッチパネル押下通知受信コントロールクラス 処理結果を表示する ステータス表示エリア管理 I_処理完了通知 学習リモコンドメイン ドメインユースケース「初期化する」は，学習リモコン起動時に，システム起動部から呼び出されます．システム起動時の処理の詳細は，設計フェーズで決定します．分析フェーズでは，自ドメインのインターフェースに操作「初期化する」を追加しておきます．なお，ユーザインターフェースドメインは，他のドメインのインターフェースを実現するだけで，自ドメインのインターフェースを持っていないため，「I_ユーザインターフェース」を新たに抽出します．
次に，インターフェースを実現するためのディスパッチャクラスを配置します．1つのドメインにつき1つ，ステレオタイプdispatcherを持つディスパッチャクラスを用意し，すべてのインターフェースを実現します．ディスパッチャクラスは，先ほど抽出したコントロールクラスに要求を転送する役割を果たします．よって，ディスパッチャクラスからコントロールクラスに向けて関連を結びます．
さらに，エンティティ分析で抽出したエンティティクラスとコントロールクラスの間に，適切に関係を結びます．また，必要に応じて，下請けとなるコントロールクラスを抽出を行います．表記においては，自ドメインのインターフェースやクラスを，自ドメインを示すパッケージ内に配置し，利用または実現する他ドメインのインターフェースをパッケージ外に配置しています．
他のドメインでも同様にオブジェクト構造分析を行います．分析過程の詳細は省略しますが，図2.9に，学習リモコンドメインのオブジェクト構造分析結果を示します．
※クリックすると拡大します．
＜図2.9.学習リモコンドメイン オブジェクト構造分析＞2．3．オブジェクトコラボレーション分析
オブジェクトコラボレーション分析では，オブジェクト構造分析で抽出したインターフェースやクラスが，協調してドメインユースケースを実行していく様子を，シーケンス図で記述して確認します．学習リモコンドメインの「機器制御情報を送信する」ドメインユースケースに対応する，オブジェクトコラボレーション分析結果を図2.10に示します．
※クリックすると拡大します．
＜図2.10.機器制御情報を送信する-オブジェクトコラボレーション分析＞赤い枠に囲まれている部分が学習リモコンドメインです．ユーザインターフェースドメインからの要求に従って，機器制御情報送信の要求が，インターフェースおよびディスパッチャを介して，機器制御情報送信コントロールクラスに配送されています．機器制御情報送信コントロールクラスは，インターフェースI_機器制御情報管理の操作「機器制御情報を取得する」を呼び出した後，インターフェースI_信号送受要求の操作「機器制御情報を送信する」を呼び出しています．
このように呼び出しシーケンスを記述することで，各クラスの責務を確認することができます．複数のオブジェクトコラボレーション分析結果のシーケンス図で，コントロールクラスが同じ呼び出しシーケンスを繰り返す場合，下請けのコントロールクラスを抽出すべきかもしれません．ただし，下請けのコントロールクラスの抽出は，たまたま同じシーケンスなのか，常に同じシーケンスであるのか分析を行い，後者の場合に限るべきです．
オブジェクトコラボレーション分析を行うことで，オブジェクト構造分析で抽出したインターフェースの操作や引数，返値などに漏れがないか確認することができます．オブジェクトや情報が正しく伝搬しているか確認し，必要に応じて修正を行いましょう．
今回は，エンティティ分析からオブジェクトコラボレーション分析までの流れをご紹介しました．
最後に，今回の各作業でのポイントをまとめておきたいと思います．
- エンティティ分析では，「情報」を表す言葉をエンティティクラスの候補として抽出します．
- オブジェクト構造分析では，アーキテクチャ要求分析結果に従って，ドメイン間の相互依存を解消します．
- オブジェクト構造分析では，ドメインユースケースを実行するコントロールクラスと，エンティティ分析で抽出したエンティティクラス間に，適切に関連を設定します．
- オブジェクトコラボレーション分析では，コントロールクラスに適切な責務が割り当てられているか確認します．
以上の点に注意しながら分析フェーズ（後半）を進めるとよいでしょう．
最後までご覧いただき，ありがとうございました．
- 渡辺博之｜渡辺政彦｜堀松和人｜渡守武和記 著，『組み込みUML ― eUMLによるオブジェクト指向組み込みシステム開発』，翔泳社 ，ISBN：4798102148
| © 2006 OGIS-RI Co., Ltd. |
|
![アーキテクチャ要求が異なる場合の相互依存解消例[参考]](img/cls_dep_3.png)
![Adaptorを利用した相互依存解消例[参考]](img/cls_dep_4.png)
