開発モデル編

第１７章　動的構造モデル

　動的構造モデルとは、オブジェクトの動的な振る舞いをとらえるためのモデルであり、その目的は静的構造モデルの妥当性を検証したり、クラスのメソッド設計に対して基本的な指針となる振る舞い関係を決定することにある。
　Dropの動的構造モデルの図式表現は、UML表記法をベースとした表記を使う。ただし、中には、Drop独自に表記を拡張し新たな図としているものもある。そのような図には、Dropマークを付けている。
表17-1に動的構造モデルの表記図一覧を示す。

インスタンス図	オブジェクトの関連構造を示すにふさわしいシステム状態のスナップショットをイメージする
コラボレーション図	インスタンス図にメッセージの送信順番を加えたもの	UML
シーケンス図	オブジェクト間のメッセージ送信の流れを時間軸でとらえたもの	UML
状態インスタンス図	重要なイベントに着目し、その実行前と実行後をインスタンス図の変化で表す
状態図	状態と状態を引き起こすイベントを表す	UML

表17-1 動的構造モデルの表記図一覧

　動的構造モデルの中心となる表記は、コラボレーション図とシーケンス図である。コラボレーション図とは、ソフトウェアが動作する際、設計に重要となるオブジェクト同士の協調動作にスポットをあて、そのオブジェクト動作イメージにメッセージ交換の順序を付加したものである。シーケンス図は、オブジェクト動作イメージを協調せず、メッセージの流れを厳密にとらえようとするものである。
　上記図で利用頻度がもっとも少ないと思われる図は、状態図と状態インスタンス図である。状態図は対象システムの中に複雑な状態を持つとき、それをモデル化するものであり、状態にクリテイカルなシステムでは重要となるモデルである。（利用頻度は問題領域によって異なるだろうが．．）
　動的構造モデルは、下記の項目に分けて解説をおこなう。

表記法	表記の説明
解説	表記法の詳細について解説
使い方	記述のための説明と表記のノウハウ
オブジェクトモデルの検証	クラス図に対する検証項目
Drop利用フェーズ	Drop開発サイクルで使われるフェーズ
注意事項	使う必要のない場合、代替できる表記について
利用例	実際の利用事例

１７．１　インスタンス図

表記法

図17-1 インスタンス図

解説
　クラス図中の文字列にアンダーラインを付けることで、クラスからソフトウェア実行時に作成されるインスタンスを示すことができる。このインスタンス図は、主にソフトウェアのダイナミックな動作をとらえるモデルの図式表現である。一般的にインスタンスの記述は、インスタンス名と属性を省略したＡ形式が多く使われる。インスタンス図の中でインスタンス名が重要な役割(たとえば社員クラスの社長インスタンス)を表すものならＤが使われる。また、属性値を表した方がモデル表現上理解性が高まるのならＢまたはＣを使うこともできる。
　Ｅは、インスタンス間のリンクを表す。このようにリンクがあるインスタンス同士は、メッセージ交換をおこなうことができる。このメッセージ交換まで表す図がコラボレーション図である。

使い方
　インスタンス同士が実際にどのような関係を持つのかを図により説明するものであり、クラス図の理解性を高めるための補足として使用される。インスタンス図は、開発システムの動作中のオブジェクトを写真に撮るようなものである。つまり、システムのある状態を想定して模擬的に作成される事例のようなものである。このようにインスタンス図はクラスの関連構造の明確化が目的であり、クラス図のようにモデルの静的側面だけでは表しにくいシステムの重要な動作側面について補足・検証するものといえる。

オブジェクトモデルの検証

関連の正当性を検証する。(たとえば多対多の関連など)

Drop利用フェーズ
　問題領域分析やコンポーネント分析フェーズ

注意事項
　すべてのシステム状態に対してインスタンス図を使う必要はない。クラス図で表現できるインスタンスのリンクパターンが複雑で理解しづらいものを対象として作成するとよい。クラス図により十分理解できるようなインスタンスのリンク構造であるならばインスタンス図を作成する必要はない。

利用例
　利用例を図17-2に示す。インスタンス図はクラス図を補足するために使用する。図では、社員オブジェトと顧客オブジェクトの多対多という関連をインスタンス同士のリンクによって具体的に示している例である。クラス図からインスタンス図に引かれている矢印は、この図を解説するためにつけた補足であり実際には記述しない。
　この図のように、インスタンス図をクラス図とペアにして使うことで、クラス図の理解性を高めることができる。

sorry this is image

図17-2 インスタンス図利用例

１７．２　コラボレーション図

表記法

図17-3 コラボレーション図

解説
　コラボレーション図は、「１７．１　インスタンス図」にメッセージの順序を記述したものである。図のようにインスタンスを重ね合わせることでインスタンス集合を示すこともできる。また、イベントとは、一連の動作を引き起こすきっかけとなるものであり、それは他のオブジェクトからのメッセージであったりウインドウシステムからのイベントであったりする。
記述方法の詳細は以下のとおりである。

メッセージタイプ
　メッセージタイプとは、リンク線の上下にメッセージを表す矢印線の種類のことをいう。図17-4の解説を補足すると、「同期メッセージ」は制御をメッセージを送ったオブジェクトに渡す。そして、そのオブジェクトから制御がリターンした時に「シンプル」表記を使うが一般的にこれは省略されることが多い。もし同期メッセージすぐリターンするような参照系などであるならば、「同期メッセージの即時リターン」を使う方が分かりやすくなる。「シンプル」は、コンポーネント分析フェーズや設計フェーズの初期過程でメソッド型がまだ明確化されていない時に使う。

図17-4 コラボレーションのメッセージタイプ

メッセージの呼び出し形式
メッセージの呼び出し形式とは、メッセージの線に並行して記述するメソッド文字列である。まず、初めの数字は呼び出し順である。また「1.2.1:」といった"."は、メソッド呼び出しにおけるオブジェクト間のネストを表し":"で終わる。以下にその記述形式を解説する。

単なるメッセージ呼び出し
戻り値付きメッセージ呼び出し
条件付きメッセージ呼び出し("[条件]"を使う)
繰り返しメッセージ呼び出し("*[繰り返し条件]"を使う)
ブロードキャストメッセージ("methodName(){broadcast}")
非同期メッセージ呼び出し(数字の代わりに英小文字"a,b"を使う)

インスタンスのライフタイム

図17-3中クラス名の後方に{new}と書かれているのは、インスタンスのライフタイムを表すものである。これは、コラボレーションが開始されて終了するまでのインスタンスライフサイクルの変化をとらえるためのものであり、以下の記述が用意されている。

{new}　　　　....コラボレーションが開始されてから作成される
{destroyed}　....コラボレーションが終了するまでに破壊される
{transient}　....コラボレーションが開始・終了するまでに生成・破壊される

リンク実現形式

インスタンス同士はリンクを持つことにより相手インスタンスにメッセージを送ることができる。リンク実現形式とは、相手インスタンスからどのように参照されているかを明示したい時に表すものである。この記述は、インスタンスを表す矩形につながる線の横に記述される。実際に記述した例は、図17-6を参照してほしい。{parameter}がPersonListの斜め上に書かれている。

{global}　　....相手側のインスタンスからグローバルに参照される
{local} 　....相手側のインスタンスメソッド内のローカル変数として参照される
{parameter} ....相手側のインスタンスのメッセージ呼び出しのパラメータや戻り値として参照される
{self} 　....同一クラスの異なるインスタンスから参照される。(自己参照)

[リンク実現形式利用のヒント]

使い方
　システムの利用ケースを例にとり、オブジェクトインスタンス間のメッセージの流れをとらえるもの。それぞれのメッセージには名前と順番を記述する。また、この図によってオブジェクト以外のリソース(たとえばデータベースとオブジェクトの連携)との関係を示すこともある。

オブジェクトモデルの検証

メッセージがうまく流れるかという視点でクラス図の妥当性を検証する
　オブジェクトインスタンスへメッセージを送りだすためのアクセスパス(インスタンスのリンク)経路を分析すること。
メッセージの流れをシミュレーションすることでクラス図の関連の正規化を図る
　オブジェクトインスタンス間のメッセージ交信が最小化されるようなシンプルな構造にクラス図を再設計する。また、関連を実装する最適な方法(List、Array、Setなど問題に適しているデータ管理を選択 )の選択するための検討材料。
オブジェクトインスタンスのライフサイクル
　機能を実行する際に一時的に作りだされるオブジェクトインスタンスについて、それを所有するオブジェクトを明らかにし、生成、消滅のタイミングを記述する。
メッセージ内容と順序の明確化
　機能を実行するために必要な処理を各インスタンスのメソッドに対応付けて、そのメソッドの呼び出しに順序をつける。もし、対応するインスタンスに必要なメソッドがない場合は、関連構造の誤りか、そのインスタンスのクラス仕様にメソッドが漏れているのかもしれない。
　オブジェクト以外のリソース(DB、ファイルやプリンタなど)との関係を記述する
システム全体としての流れを把握する。