*begin*back*foward*end*contents

開発モデル編 -
第17章 動的構造モデル

動的構造モデルとは、オブジェクトの動的な振る舞いをとらえるためのモデルであり、その目的は静的構造モデルの妥当性を検証したり、クラスのメソッド設計に対して基本的な指針となる振る舞い関係を決定することにある。

Dropの動的構造モデルの図式表現は、UML表記法をベースとした表記を使う。ただし、中には、Drop独自に表記を拡張し新たな図としているものもある。そのような図には、Dropマークを付けている。

表17-1に動的構造モデルの表記図一覧を示す。

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

動的構造モデルの中心となる表記は、コラボレーション図とシーケンス図である。コラボレーション図とは、ソフトウェアが動作する際、設計に重要となるオブジェクト同士の協調動作にスポットをあて、そのオブジェクト動作イメージにメッセージ交換の順序を付加したものである。シーケンス図は、オブジェクト動作イメージを協調せず、メッセージの流れを厳密にとらえようとするものである。

上記図で利用頻度がもっとも少ないと思われる図は、状態図と状態インスタンス図である。状態図は対象システムの中に複雑な状態を持つとき、それをモデル化するものであり、状態にクリテイカルなシステムでは重要となるモデルである。(利用頻度は問題領域によって異なるだろうが..)

動的構造モデルは、下記の項目に分けて解説をおこなう。

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

17.1 インスタンス図

表記法

sorry this is image
図17-1 インスタンス図

解説

クラス図中の文字列にアンダーラインを付けることで、クラスからソフトウェア実行時に作成されるインスタンスを示すことができる。このインスタンス図は、主にソフトウェアのダイナミックな動作をとらえるモデルの図式表現である。一般的にインスタンスの記述は、インスタンス名と属性を省略したA形式が多く使われる。インスタンス図の中でインスタンス名が重要な役割(たとえば社員クラスの社長インスタンス)を表すものならDが使われる。また、属性値を表した方がモデル表現上理解性が高まるのならBまたはCを使うこともできる。

Eは、インスタンス間のリンクを表す。このようにリンクがあるインスタンス同士は、メッセージ交換をおこなうことができる。このメッセージ交換まで表す図がコラボレーション図である。

使い方

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

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

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

Drop利用フェーズ

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

注意事項

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

利用例

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

この図のように、インスタンス図をクラス図とペアにして使うことで、クラス図の理解性を高めることができる。

sorry this is image
図17-2 インスタンス図利用例

17.2 コラボレーション図

表記法

sorry this is image
図17-3 コラボレーション図

解説

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

記述方法の詳細は以下のとおりである。

メッセージタイプ

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

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

メッセージの呼び出し形式

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

単なるメッセージ呼び出し
1: display(GC) パラメタGC型を持つdisplayを呼び出す
戻り値付きメッセージ呼び出し
2: y:= getHigh() getHigh()を呼び出し戻り値"y"を受ける。(その後yは図の中で使用される)
条件付きメッセージ呼び出し("[条件]"を使う)
3.1 [y>0]: display(GC) y > 0 ならdisplayを呼び出す。
繰り返しメッセージ呼び出し("*[繰り返し条件]"を使う)
3.2 *[n := 0..y]: line(0,y) 0からyまでline(0,y)を呼び出す。
ブロードキャストメッセージ("methodName(){broadcast}")
3.2 display(){broadcast} インスタンス集合内の全てのインスタンスに送る。
非同期メッセージ呼び出し(数字の代わりに英小文字"a,b"を使う)
3.2.a: fooAsync() fooAsync()を非同期で呼び出す。,
3.2.b: barAsync() fooAsync()を呼び出した直後にbarAsyncを非同期に呼び出す。
インスタンスのライフタイム

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

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

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

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

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

クラス図ではパラメータで参照するクラスの関連は省略されることが多い。なぜなら、すべての関連を記述してしまうと、図が関連だらけになってしまうのでパラメータ参照などという非常に疎な関係については省略されるのである。しかし、コラボレーション図では、メッセージを送るという必要上リンクを線で示すことになる。このような一時的でかつ疎結合のリンクをコラボレーション図で示す際に、{local}や{parameter}は有効に使える。{global}についても同様である。クラス図では、どのクラスからも参照されるため関連を省略されることが多いだろう。コラボレーションでは、globalなオブジェクトを一時的に参照するという意味で使用するとよい。

使い方

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

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

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

Drop利用フェーズ

システム共通設計フェーズ、コンポーネント分析フェーズ、コンポーネント設計・実装フェーズ、アプリケーション設計・実装フェーズ

注意事項

コラボレーション図は、頭に描くオブジェクトの動作イメージに近いものである。しかしながら、複雑なメッセージの流れを厳密にとらえるのは不得手である。このような場合は、シーケンス図の方がよいだろう。

コラボレーション図は、アプリケーションの機能を複数のオブジェクトインスタンスで実現しているケースで、その関連が複雑で頭で考えにくい場合に使用するとよい。このときは、ラフスケッチによってあらゆるケースをコラボレーション図で記述し、機能をシミュレーションするのである。その結果、オブジェクトの仕様が具体化されたり、クラス間の連携の際の問題を発見したりすることができる。

コラボレーション図は他のモデルと同じく、すべての機能に対して記述するものではない。あくまでオブジェクト同士のメッセージ交換が複雑なものを対象とする。

利用例

ここでは、社員検索システムを例に取り、コンポーネント開発においてコラボレーション図がどのように使われるかを順序を追って解説する。なお、ここで取り上げるクラスは、システム共通コンポーネントとして設計されていくという前提の基に話を進める。

その1

コンポーネント分析フェーズにて、オブジェクト間のメッセージの流れを繰り返しイメージ(ラフスケッチ)しながらコラボレーション構造を確立する。 図17-5は、ViewManager(アプリケーション画面オブジェクト)に指定部門の社員検索を行わせるコラボレーション図の例。ViewManagerはDBAccessを使って人事データベースを検索させる。DBAccessは検索結果データからPersonインスタンスを作成して返し、そのインスタンスに「表示メッセージ」を送る。

この段階では、メッセージのパラメータなどはまだ明確にしていないため、メッセージのタイプの表記も「シンプル」記述となっている。

sorry this is image
図17-5 コラボレーション図利用例(ラフなメッセージの流れ)

その2

設計が進むに従い、オブジェクトのメッセージの仕様が明らかになったらメッセージタイプを「シンプル」から「同期メッセージ」に代える。また、Personインスタンスの具体的な管理方法も決まるだろう。その段階で、PersonListを図の中に追加する。

ここで1つ気になることがある。手続きが詳細化されたにも関わらず、実際のデータベース制御部分を「DBコンポーネント」という抽象化した表現にしていることである。

このような抽象化された構造のままにしておくのは、「このモデルは、データベースへのアクセス方法ではなくPersonデータ取得についての一連の流れをとらえることが目的である」という理由からくる。よって、DBクラスは、コンポーネントとしてその制御と構造を隠してしまい目立たなくする。このような抽象化は、問題の本質に的を絞り深く考察するためには欠かせないテクニックである。

sorry this is image
図17-6 コラボレーション図利用例(メッセージの詳細化)

その3

図17-7は、非同期に実行される部分を明示化したものである。ViewManagerがDBAccessにfindメッセージを出した時点から検索(select)が非同期に行われることを示している。DBAccessは、DB検索を依頼されて結果を戻すまで自スレッドにて能動的に動作するため、Activeクラスの表記を使ってそのことを強調している。検索終了後、DBAccessはViewManagerに検索完了通知(FindFinish)をウインドウシステムのイベントとして送る。

DBコンポーネントも実はActiveコンポーネントかもしれない。しかしながらこのモデルでは、それを強調する意味がなくAvtive表記にしていない。

ViewManagerには、画面表示(display())後のPersonListの後始末(detach())を追加し、PersonList、Personクラスを{transient}に変更している。また、ViewManegerがPersonListを参照する方法を{parameter}と記述することで明らかにしている。

sorry this is image
図17-7 コラボレーション図利用例(非同期メッセージの表現)

17.3 シーケンス図

表記法

sorry this is image
図17-8 シーケンス図

解説

シーケンス図は、1つのシーンを実現するための手順(シナリオ)を基にメッセージの流れを時間順に表したものである。図中の横線がメッセージを表し、縦線はオブジェクト(インスタンスまたはクラス)だけでなく、コンポーネントやサブシステムなども表す。オブジェクト内部の記述形式やメッセージタイプはコラボレーション図と同一の形式となる。

縦太枠が示す活動中とは、メッセージを処理中もしくは他のオブジェクトにメッセージを送り出している状態、つまり、そのオブジェクトがメッセージに対して活動状態であることを示している。また、オブジェクトライフラインとは、オブジェクトインスタンスの生命線であり、インスタンスが破壊されるときは「X」を付けることもできる。

リアルタイムな要求が必要とされるものについては、区間をA-Bのように指定し、その処理時間を示すことも可能である。

使い方

シーケンス図は、1つの機能を発生させるイベントを基に、オブジェクトが処理の役割分担をおこなう手順を記述したものである。これによって個々のオブジェクトのメッセージ処理手順が明確化される。オブジェクトはできるだけ手順性を持たせないように設計しなければならない。しかし、複数のオブジェクトの連携によって1つの機能を果たす場合は、必ずメツセージを受け渡す順序が発生するものである。しかも、オブジェクト間のメッセージ交換だけではなくソフトウェア上のオブジェクトではない部品やユーザともメッセージ交換が必要となる。このような複雑なメッセージ交換をおこなう箇所を抽出してモデル化することで、個々のオブジェクトがメッセージ受けた際のメソッドの手続きを具体化する。

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

  • いくつかのオブジェクトとアクターやウィンドウなどの連携動作に対して、順序的な誤りはないか、不足するメッセージはないかを検証する。

Drop利用フェーズ

アプリケーション設計・実装フェーズ、システム共通設計フェーズ、コンポーネント設計・実装フェーズ

注意事項

シーケンス図は、限定されたオブジェクト同士が多くのメッセージ交換を行う問題に適している。たとえばクライアント・サーバーにおける非同期オブジェクト通信などのように固定されたオブジェクト同士がプロトコルに従ってメッセージを交換し合うようなパターンを厳密に示すには、コラボレーション図よりも適しているだろう。

利用例

ここでは、コラボレーション図で取り上げた同じ例題を使ってシーケンス図の特徴を解説する。

その1

図17-9の利用例は、コラボレーション図17-5をシーケンス図に書き換えたものである。コラボレーション図と比較すると、呼び出し順序が視覚化される代わりに、オブジェクトの連携動作イメージが薄れてしまうという特徴がある。

sorry this is image
図17-9 シーケンス図利用事例

その2

図17-10は図17-7を書き換えたものである。ViewManagerとDBAccessがfindメッセージからFindFinishメッセージまで非同期的に動作することを表している。この図では、PersonListとPersonが破壊されるタイミングを「X」で示している。また、find()からFindFinish()までは10秒以内に終わらせなければならないという要求を例として追加した。

sorry this is image
図17-10 シーケンス図利用事例

その3

UMLのシーケンス図において残念な点は、活動中のオブジェクトのどこに実行制御(実行コンテクスト)が渡されているのかはっきり把握できない点である。たとえば、図17-10において非同期メソッドfind()により2つに別れたスレッドの実行がどこを通過しているかつかみにくい。そこで、Dropでは図17-11のように活動中を示すボックス内に線を引く形式を勧める。これによって、2つの実行中スレッドの流れを視覚化することができる。

sorry this is image
図17-11 シーケンス図利用事例

17.4 状態インスタンス図

表記法

sorry this is image
図17-12 状態インスタンス図

解説

インスタンス図を応用して、インスタンスのリンク状態を何らかのイベントにより変化させる際にその前後の構造を記述する。このような図をDropでは状態インスタンス図と呼び、何らかのイベントによってもたらされるインスタンス同士のリンクの変化とインスタンスの属性値の変化を具体的に示し、イベントによって変化するインスタンスと属性値についての説明を補足する。

使い方

状態インスタンス図のパターンを正確に洗い出すことでアプリケーションの仕様を限定し、責任範囲を明確にできる。また、クラス図では伝えられないオブジェクト間の動的側面を仕様化するものである。

この図は、複雑なデータ関連構造を持つ問題領域にて、その複雑性を解消するために、抽象化したデータモデルを実現しているようなデータ中心の基幹系アプリケーションにおいて有用となる。すなわち、抽象化されたデータモデルの関連構造から具体的に派生されるリンクの関係を重要なイベントの前後の構造として書き表すことがができる。

状態インスタンス図によってオブジェクトのテスト項目を洗い出すこともできる。1つのイベントに対する前後のインスタンスリンクの構造を試験項目として記述するのである。

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

  • 状態の変化に対してクラスの持つ関連で正しく動作できるかの検証。

Drop利用フェーズ

アプリケーション設計・実装フェーズ、システム共通設計フェーズ

注意事項

状態インスタンス図は、何かのきっかけを基に、複数のインスタンスが協調し合って処理を実現した結果、インスタンスリンクの構造に変化が発生するようなパターンに対して使用する。自然言語だけで説明がた足りるようなパターンについては記述する必要はない。

利用例

利用例を図17-13に示す。

sorry this is image
図17-13 状態インスタンス図利用例

17.5 状態図

表記法

sorry this is image
図17-14 状態図

解説

状態図とは、与えられた時刻において、有限数の状態の中からただ1つの状態をとるように記述される。図中の線は事象と呼ばれ、状態Aから状態Bに変化させるための刺激と考える。状態図は、オブジェクト内部の状態をとらえたり、問題領域に存在する現実世界の状態をとらえるために使用する。オブジェクト内部の状態をとらえる際には、状態はオブジェクトの属性となり、事象は、そのオブジェクトの操作の一部もしくは、そのオブジェクトをアクセスする他のオブジェクトの操作の一部となる。

使い方

状態図はある状態から遷移できる状態をすべて記述することを要求される。これによって、分析段階では、問題領域の動的側面を詳細に把握することができる。また、設計段階ではプログラムロジックの曖昧性をなくすことが可能となる。

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

  • 状態を変化させる事象を発生させるオブジェクトとの関連と事象を管理するための属性。

注意事項

対象とする問題にもよるが、状態図は、オブジェクトメッセージやシーケンス図と比べて利用頻度が少ないだろう。状態図は、複雑な状態管理を必要とする部分のみの利用に止めなければならない。

Drop利用フェーズ

問題領域分析、コンポーネント分析、アプリケーション設計・実装フェーズ、システム共通設計フェーズ、コンポーネント設計・実装フェーズ

利用例

図17-15は、「備品管理システム」の問題領域分析フェーズにおいて状態図を使用した例である。この例では、登録備品の使用状態、廃棄状態、未使用状態があることを示している。これらは、問題領域中に本質的に存在する状態である。

sorry this is image
図17-15 状態図利用事例

注意事項

状態図を使うことで、むやみに不必要な状態を作り出してはならない。あくまで問題領域をソフトウェア化する際に複雑な状態がそこに含まれている時に、それをモデル化することで単純な状態になるよう整理することが主目的である。

また、対象問題にもよるが問題領域分析フェーズでの利用は注意が必要である。あくまで、要求の中で状態管理が複雑なものだけを対象としなければならない。このフェーズで状態図を使うと議論の中心がソフトウェア領域になりがちである。


*begin*back*foward*end*contents

この記事のトップへ