移動: トップ > ラボ > プログラミングのアイディア > クラスコラボ図
人に仕事を頼む感覚でクラスを作る | クラスコラボ図を使った開発の流れ |
クラスとは会社の中で働く人 | クラスとは?
履歴:
統計:
目次:
このページの最終更新日: 2012/02/21
提案日: 2009/09/05

クラスコラボ図

概要

概要文章
○ 短い背景+をするかの短い説明(どちらにも一番分かりやすく短い具体例を使う、まとめではない)
○ 「~するといったアイディアです。」の形で終わる
○ これによって現在よりもよくなること

次第にクラスの数が増えてくると、クラスの間でお互いがどのように協調し合うのかを図に描いて、一目で全体を把握したくなります。 そこで、クラスコラボ図という新しい図の描き方を提案します。

クラスコラボ図とは、簡単に言うと、四角の中にクラス名を書いてクラスを描き、その間に矢印を描いて、あるクラスから別のクラスの関数を呼び出す動作を矢印で表したものです。これによって、複数のクラスがお互いに協調し合う様子を見える化します。

背景

一目で全体を把握したい

背景文章
○ これが出てきた過程、これを思いつくまでの経緯、世の中の必要性などを書く。
○ 「そこで、~する、といったアイディアに至りました。」の形で終わる。
○簡単な言葉で書ける必要なことだけを短く書く。詳細な背景は後で書く。

別ページ「人に仕事を頼む感覚でクラスを作る」でクラスの作り方について考えました。このページで考えたようにクラスを作っていくと、なるべく単純な機能に分けてクラスを作るので、小さな機能を持ったクラスがたくさん出来ます。これらの小さなクラスがお互い協調して、より大きな機能を実現します。

次第にクラスの数が増えてくると、全体を把握しきれなくなってきます。クラスの間で、お互いがどのように協調し合うのかを図に描いて、一目で全体を把握したくなります。そこで、複数のクラスがお互いに協調し合う様子クラスコラボ図で表現する、といったアイディアに至りました。本記事では、クラスコラボ図という新しい図の描き方を提案します。

次の2つの図は、クラスコラボ図が誕生する前後に描いた手書きの図です。左の図は、クラスコラボ図になりかけている前身の図です。右の図は、初めてクラスコラボ図を描いたときの図です。

クラスコラボ図になりかけの前身のグラフ [全体] 初めて描いたときのクラスコラボ図 [拡大]

クラスの関連性を見れば、コードが分かる? 自分で作ったクラスを上位層でどのように使っているかを把握したい。20081011_MakeClassAsIfAskWorkでクラスの作り方を考えた、このようにクラスを作っていくとお互いのコラボ状態を描きたくなる。
別ノート09/05/15 p11に原型?(歌詞表示アプリ)→09/09/05 p15に初使用(時間記録アプリ)
20081006_ClassCollaboとの名前の衝突を解決。

どんなもの?

クラスがお互いに協調し合う様子を見える化する

方法文章
○「背景」からの流れを使わず、ここから読んでも分かるように新しく文章を書き始める。
○はじめに筆者が想像するその具体的な場面状況をまず読者に伝える。「~ときに/~の場合を考えます」のようなフレーズを使う。
○状況設定の後、そのアイディアがどんなものなのかを一言(最も短い例)で書く。 「~といったアイディアです。」のようなフレーズを使う。限定しすぎたり不足があっても後の文章で修正できる。
○一言説明の後、アイディアの説明を1つの例に限定してそのシナリオ全部を書く。
取り残した部分、利点性質後で書く。

クラスコラボ図とは、簡単に言うと、次の図に示すように、四角の中にクラス名を書いてクラスを描き、その間に矢印を描いて、あるクラスから別のクラスの関数を呼び出す動作矢印で表したものです。これによって、複数のクラスがお互いに協調し合う様子を見える化します。

クラスコラボ図の例 : クラスと関数の呼び出し

クラスコラボ図は、次の図に示すように、クラスの他にも、ファイルデータベースなどを描いて、クラスがストレージへアクセスする様子を表すことが出来ます。

クラスコラボ図の例 : ストレージへのアクセス

さらに、クラスコラボ図は、次の図に示すように、関数呼び出しの他にも、イベントの矢印と、プロパティ値の読み取りの矢印を描くことが出来ます。イベントの矢印は、白丸とそれを受けるような半円を描いて、イベントの発生を受け取る様子を表します。次の図の例では、ClassName1が公開するイベントにClassName2が登録して、ClassName2がClassName1のイベントを受け取る様子を表します。プロパティ値の読み取りの矢印は、先頭に反対向きの矢印を描いて、プロパティ値を参照して読み取る様子を表します。次の図の例では、ClassName2がClassName3のプロパティを読み取る様子を表します。

クラスコラボ図の例 : イベントとプロパティ

クラスコラボ図は、基本的には、四角形と、その間をつなぐ線から成る図なので、ノード/エッジ型のグラフの1つと言えます。ノードとエッジには、それぞれ次のような項目を描くことが出来ます。

ノードには :

  • クラス
  • ストレージ(ファイル、データベース...)

エッジには :

  • 関数の呼び出し矢印
  • イベントの受け取り矢印
  • プロパティ値の読み取り矢印

このようにクラスコラボ図を見れば、複数あるクラスのそれぞれがお互いにどのように関係するか(相互関係)が分かり、プログラム全体の構成が分かるようになります。クラスコラボ図は、複数のクラスがお互いにコラボレーションする方法を見える化します。

クラスコラボ図を描いて、真っ先にどんなものかを簡易説明→詳細は後述。まず関数呼び出しのみの図を説明→イベントの矢印/パラ参照の矢印/ストレージの図を説明。人に仕事を頼む感覚でクラスを作った場合、それらクラスの相互関係を見れば、プログラム全体の構成が分かるようになります。クラスコラボ図は、複数のクラスがお互いにコラボレーションする方法を見える化します。

クラスコラボ図の利用例

ここでは、実際にどのようにクラスコラボ図を使うのかについて、例を使って説明します。例えば、PCの使用時間をログするソフトを考えます。このソフトは、マウスの移動やキーボードのタイピングを検知して、その情報を基にユーザーがPCを使用していた時間を測定し、その結果をファイルに保存します。このソフトの中身をクラスコラボ図で表現すると、例えば、次の図のようになります。

PCの使用時間をログするソフトのクラスコラボ図

大まかに図を眺めると、ソフトの中には複数のクラスがあり、それぞれのクラスの間で何らかの影響を及ぼし合う様子が分かります。このように、クラスコラボ図は、クラスをどのように使ってソフトの機能を実現するか、を表す場合に使用します。上の図を詳しく見ていくと、次のようなことが読み取れます。

  • まず図の全体を見ると、この例では6つのクラスを作って、ソフトの機能を実現することが分かります。
  • 図を上の方から順に見ていくと、PCの使用を検知するために、「マウスの移動を検知」するクラスと、「キーボードの使用を検知」するクラスを別々に作ることが分かります。
  • これら2つのクラスは、マウスやキーボードの使用を検知した瞬間にイベントを発生させて、他のクラスに検知した瞬間を伝達します。
  • 「イベント和算」クラスを新たに作って、「マウスの移動を検知」するクラスと「キーボードの使用を検知」するクラスの2つから来るイベントを1つに合わせます。
  • 「イベント和算」クラスは、PCの使用を検知した瞬間にイベントを発生させて、他のクラスに検知した瞬間を伝達します。
  • 「使用時間を測定」するクラスを作って、「イベント和算」クラスからイベントを受け取ります。イベントによって、PCの使用を検知した時刻を知ります。この時刻から、使用の開始時間と終了時間を測定します。
  • 「使用時間を測定」するクラスは、使用の開始時間と終了時間を測定できたら、その瞬間にイベントを発生させて、他のクラスに開始時間と終了時間を伝達します。
  • 「使用時間をファイルにログ」するクラスを作って、「使用時間を測定」するクラスからイベントを受け取ります。イベントによって、PCの使用開始時間と終了時間を知ります。これらの時間を.csvファイルに書き込んで、保存していきます。
  • 保存した.csvファイルの情報を表示するために、「ログを表示」するクラスを作ります。.csvファイルからログを読み込んで、ウィンドウに一覧表示します。

クラスコラボ図を見れば、ソフトの機能を実現するために、どのようなクラスがどのようにコラボレーションするのかが分かります。クラスコラボ図を使えば、このようにソフトの中身を分かりやすく表すことが出来ます。

新しく出てきたマークや書き方

前述したPCの使用時間をログするクラスコラボ図の例で、新しく出てきたマークや書き方が3つあります。これらを次に説明します。

  タイマの形をしたマーク。このクラスの中には、タイマを使って何かを定期的に監視する動作があることを示します。前述の図では、タイマを使ってマウスとキーボードの動きを定期的に監視する様子を示します。
  クラスの周りに描いたイラスト。このクラスの主な動作を分かりやすく表すために、動作に関連するイラストをクラスの周りに付加します。イラストは何でも構いません。前述の図では、「マウスの移動を検知」するクラスにマウスのイラスト、「キーボードの使用を検知」するクラスにキーボードのイラスト、「ログを表示」するクラスにウィンドウのイラストを付加しています。
  人の形をしたマーク。このソフトを使用するユーザを表します。このユーザのマークとクラスの間に矢印を描くことで、ユーザがソフトに何かを入力する操作や、ソフトがユーザに何かを出力する動作など、ユーザとソフトの間で相互に与える影響を表現します。

PC使用の例図、画像取得の例図を挙げる。ここでは、図からソフトが何をしているかを説明する。クラスコラボ図をどのように読めばよいかを例に沿って説明する。クラスコラボ図は実際どのように使うものかを説明する。

クラスコラボ図から分かること

前述のクラスコラボ図の利用例では、PCの使用時間をログする例を使って、どのようにクラスコラボ図を使うのかを説明しました。ここでは、同じ例を使って、クラスコラボ図からどんなことが分かるのかに注目します。もう一度、前述と同じ次の図を見ます。

PCの使用時間をログするソフトのクラスコラボ図

クラスコラボ図から分かることは、主に次の3つです。以降の節で詳しく説明します。

機能の分割/クラスへの割り当て (責務の分離の様子)

クラスコラボ図にある、四角の中の言葉を見ることで、ソフトの中にはどんな機能を持ったクラスがあるか、といったことが分かります。各クラスが持つ機能を見ることで、最終的にソフトで達成したい大きな機能をどのように小さく分割して、それらの小さな機能をどのようにクラスに割り当てるのか、といったことが分かります。

各クラスが持つ機能 [全体]

上の図の例では、例えば、ソフトの中にはマウスの移動だけを専門に検知する「マウスの移動を検知」クラスがあることが分かります。このように各クラスが持つ機能を見ていくと、このソフトは、PCの使用時間をログするといった大きな機能を6つの機能に分割して、それらを6つのクラスに割り当てることでソフトを実現していることが分かります。

このようにクラスコラボ図を見ることで、そのクラスはどんな仕事を担当し、どんな責務を果たすのかが分かります。他のクラスと責務の範囲を見比べることで、そのクラスに与えられた責務が他のクラスとどのように分離されているか、責務の分離の様子が分かります。

誰が誰に何を伝達するか (インターフェース)

クラスコラボ図にある、矢印でつながった2つのクラスを見ることで、どのクラスからどのクラスにどんな情報を伝達するか、といったことが分かります。また、2つのクラスの間にある矢印の種類を見ることで、どのような方法で情報を伝達するのか、といったことが分かります。

クラス間で情報を伝達する様子 [全体]

上の図の例では、例えば、「マウスの移動を検知」クラスと「イベント和算」クラスの間にある矢印を見ると、「マウスの移動を検知」クラスから「イベント和算」クラスに、検知した瞬間のタイミング情報を伝達することが分かります。間にある矢印の種類を見ると、イベントの発行と受け取りの仕組みで情報を伝達することが分かります。

このようにクラスコラボ図を見ることで、そのクラスが持つインターフェースが分かります。そのクラスがどんな関数を持っていて、どんなプロパティ値を持っているか、どんなイベントを発行するかといった、そのクラスが外部に対してどのようなインターフェースを公開するのかが視覚的に分かります。

誰が誰に何を委譲しているか (依存関係)

クラスコラボ図にある、矢印をさかのぼっていくことで、そのクラスは他のどのクラスに頼っているか、といったことが分かります。また、矢印に付いた文字を見ることで、そのクラスは他のクラスに何を頼っているかが分かります。

他のクラスに依存する様子 [全体]

上の図の例では、例えば、「使用時間をファイルにログ」クラスを見ると、このクラスは自分1人だけで処理が完結するわけではなく、「使用時間を測定」クラスから与えられる開始&終了時間の情報が必要です。「使用時間をファイルにログ」クラスは「使用時間を測定」クラスに、開始&終了時間の情報を頼っていることが分かります。

このようにクラスコラボ図を見ることで、クラス間の依存関係が分かります。そのクラスがどのクラスに何を依存しているのかが視覚的に分かります。また、矢印の数を見ることで、そのクラスが他のクラスにどれぐらい依存しているのかといった、依存度が分かります。

クラスコラボ図から分かること(例図と対応させて説明)→クラス/仕事の分け方=担当/責務の分離の様子、誰が誰に何を伝達するか=インターフェース、誰が誰に何を委譲しているか=依存関係/依存粒度、の情報が分かる。()前の説明→例図に沿う→()内の説明

矢印の線がクロスする場合

クラスコラボ図に細かいコラボレーションまで忠実に描こうとすると、かなりたくさんの矢印が必要になることがあります。このように描く矢印の数が増えてくると、クラスコラボ図は2Dの図なので、どうしても矢印の線がクロスします。たくさんの矢印がクロスすると、クラスコラボ図が分かりにくくなります。

たくさんの矢印がある場合は、通常、メインの関係を表す重要な矢印と、そうではない矢印に分けることが出来ます。このうち、重要な矢印は、矢印がクロスしてもそのまま矢印を描いて、しっかりコラボレーションを表現すべきです。一方、重要でない矢印は、矢印がクロスするなら線を引かない方が見やすくなります。

そこで、クラスのクローンを作ることで、重要でない矢印の線をクロスしないように出来ます。下にある左図は矢印がクロスする場合で、右図がクローンを作ってクロスを回避した場合です。

クローンでクロスを回避するには、まず、図の「CA」のようにクラスに適当な識別子を付けます。次に、その識別子だけをコピーして、同じクラスを表す小さなクローン「CA」を作ります。作ったクローンを矢印の結びやすい位置に配置して、クローンと矢印を結びます。このように、クラスと矢印を結ぶ代わりに、クラスのクローンと矢印を結ぶことで、矢印がクロスするのを防ぎます。

矢印の線がクロスする場合(左図) 矢印の線を引かないようにした場合(右図)

クローンはいくつでも作れます。矢印がクロスして困る場合は、すべてクラスのクローンを作ってクロスを回避します。

クラスに識別子を付けて、小さなクローンを作り、それと矢印を結ぶことで、矢印のジャンプを防ぐ。

クラスの機能構成/コラボ方法だけを分離

プログラムには色々な要素が含まれています。多くの要素が複雑に絡み合って混在すると、プログラムが分かりにくくなります。このように要素が混在するときは、多くの場合、その中からある側面だけを分離して表現することで、プログラムを分かりやすく出来ます

クラスコラボ図は、プログラムに混在する要素のうち、クラスの機能構成/コラボ方法だけを分離して描いたものです。分離して機能構成/コラボ方法の側面だけに注目することで、プログラムを理解しやすくします。ここで、クラスの機能構成/コラボ方法とは、次のようなものです。

機能構成とは
  それぞれのクラスがどのような機能を持っているのか
大きな機能をどのように分割して、それらをどのようにクラスに割り当てるのか
それらのクラスをどのように構成するのか
コラボ方法とは
  他のクラスとどのように協調して動作(コラボレーション)するのか
他のクラスとどのようなやりとりをして(どのように相互作用して)機能を実現するのか

そのため、クラスコラボ図には機能構成/コラボ方法だけを描くようにします。クラスコラボ図に、これ以外の他の要素を混在して描いてはいけません。分離して描いた意味がなくなってしまいます。

例えば、クラスコラボ図に実装方法/アルゴリズムの情報を描いてはいけません。クラスの中で具体的にどのような処理を行うのか、どのような順序で処理が進み、どのようにデータが流れていくのか、といった実装内部の情報は描かないようにします。クラスコラボ図は、このような実装内部を切り離して、機能構成/コラボ方法だけを抽出することで、複雑なプログラムをより簡単に表現します。

クラスコラボ図を見れば、インターフェースに関する部分のコードを作ることが出来ます。どのような名前のクラスを作って、そのクラスの中にどのような名前/型の関数/プロパティ値を作るか、といった外枠の部分(インターフェース)は、クラスコラボ図を見ながらコードに書くことが出来ます。一方、関数の中に書くプログラム(実装内部)は、クラスコラボ図を見ても作ることは出来ません。

言い換えれば、クラスコラボ図はプログラムの中の機能構成/コラボ方法という一面しか表現しないということです。クラスコラボ図を見ても、実装方法/アルゴリズムは分かりません。このように他の要素を全て切り捨てることで、クラスコラボ図は、機能構成/コラボ方法の一面について分かりやすく表現します。

クラスコラボ図は、機能構成&コラボ動作とクラスの実装内部/アルゴリズムを分離して、機能構成&コラボ動作だけを描くものである。実装内部を分離することで、物事をより簡単に表現するもの。そのため、クラスコラボ図には、クラスの実装内部/アルゴリズム詳細の情報は含まないようにする(分離)。つまり、クラスコラボ図を描ければコードのインターフェース/フレーム部は書ける。一方、実装の詳細は書けない。クラスコラボ図を描くときはその前にシナリオをステートマシン的に描いて内在する仕事を洗い出してからクラスコラボ図を描くと描きやすい。クラス=人で作っていると必要になる図。

クラス内部の動作が表せなくてもクラスの挙動は表現できる

前述したように、 クラスコラボ図には実装方法/アルゴリズムの情報を描いてはいけません。 そのため、クラスコラボ図ではクラス内部の動作を表すことが出来ません。

しかし、クラス内部の動作を表さなくても、各クラスの持つ機能がそれぞれ小さければ、クラスコラボ図だけでクラスの挙動十分詳細に表現できます。クラスの機能が小さければ、クラス内部の動作が単純になり、処理の内容が少なくなるので、クラス名や関数名から簡単に内部動作の処理内容が分かります。クラス内部の動作を表さなくても、クラス名や関数名から動作の内容が分かるので、クラスの挙動は十分詳細に表現できます。

別ページ「人に仕事を頼む感覚でクラスを作る」で考えたようにクラスを作っていくと、なるべく単純な機能に分けてクラスを作ることが出来ます。この方法でクラスを作ることで、各クラスの持つ機能をなるべく小さくし、クラスコラボ図で全体の挙動を分かりやすく表現できるようになります。

クラスの内部の動作は表せられない(⇔1クラスの果たす機能は小さく、内部動作は少ないので、クラスコラボだけで十分挙動を表現できるOK、別ページ「人に仕事を頼む感覚でクラスを作る」で考えたようにクラスを作っていくと、なるべく単純な機能に分けてクラスを作るので。

図に描き出して毎回図を見る方が効率的

プログラムを作る中で、クラスの機能構成/コラボ方法を考えたいときに、関連するクラスの数が5つを超えてくると、コードの上で考えるより、図に描き出し毎回図を見る方が効率的です。コードの上で考えようとすると、結局、コードを見ながら頭の中で考えることになります。クラスの数が少ないうちは、これで間に合いますが、数が5つを超えてくると、頭の中だけでは手に負えなくなってきます。

そのため、クラスコラボ図を描いて、その図の上で考えます。図に描けるものは図に描き出して、頭で考える負担を減らします。代わりに、頭ではもっとクリエイティブなことを考えるのに集中できます。頭の負担を減らして、毎回図を見る方が楽になります。

利点→前述の「クラスコラボ図から分かること」節で説明した3つの点が一目で分かること/クラスの数が5つを超えてくると、頭の中で考えるより、図に書き出して毎回参照した方が良い。

クラスコラボ図では表せないこと

前述のように、クラスコラボ図は、プログラムに混在する要素のうち、クラスの機能構成/コラボ方法だけを分離して描いたものです。しかし、クラスの機能構成/コラボ方法であっても、クラスコラボ図では表せなかったり、表しにくい場合があります。それらは、主に次に挙げるケースです。 以降の節で詳しく説明します。

動的なコラボレーションの様子は1つの図で表せられない

協調動作の形が時間と共に変わるケースは、1つのクラスコラボ図で表せません。例えば、次の図のように、あるときは左図のような形でお互いのクラスが協調動作をして、また、あるときは右図のような形で協調動作をする場合を考えます。このように、時間と共にクラス間を結ぶ矢印が変わる(協調動作の形が変わる)と、その個々のケースに対して1つずつクラスコラボ図を描くことは出来ますが、これらを1つのクラスコラボ図で一度に表すことは出来ません。

あるときの協調動作(左図) 別のときの協調動作(右図)

このように、時間と共に協調動作の形が変わる動的なコラボレーションの様子は、1つのクラスコラボ図で表せません。クラスコラボ図は、ある瞬間で止めたときの静的なコラボレーションの様子を表すものです。

動的なコラボレーションは、例えば、次のような場面でよく見られます。

  • 実行の途中でモードが遷移することで、コラボレーションの様子が変わる場合
  • 時間と共に複数のインスタンスが生成されたり解放されたりして、コラボレーションの様子が変わる場合
  • 主にデータを格納するために作られたデータクラスにおいて、処理が進むに連れて格納するデータが変わっていくことで、コラボレーションの様子が変わる場合

クラスコラボ図で動的なコラボレーションの様子を表したい場合は、個々の瞬間に対して1つずつ、必要な数だけクラスコラボ図を描いて、複数のクラスコラボ図を用いることで対応します。

複数のインスタンス同士が生成されたり解放されたりするコラボは、一度に表わせられない=コードが実行されたときの時間軸で見た動的なコラボ情報は表せられない(処理していくとデータクラス(配列など)のリンク先(コラボ形態)が変わる場合、モード遷移でクラスの挙動やコラボ形態が変わる場合)⇔個々のケースに対して1つずつクラスコラボ図を描くことは出来る。

複数パターンあるコラボレーションは1つの図で表せられない

前述のように、クラスコラボ図は、静的なコラボレーションの様子を表すもので、これはすなわち、ある1種類のコラボレーションの様子を表すものです。そのため、複数パターンあるコラボレーションは、そのすべてを1つのクラスコラボ図で表せません。

複数パターンあるコラボレーションは、例えば、汎用的なクラスを説明したい場面でよく見られます。汎用的なクラスは、ライブラリにあるような汎用的に利用できるクラスで、例えば、.Netライブラリの場合、IO(入出力)関係の次のようなクラスがあります。

  • IO関係
    • System.IO.FileStream
    • System.IO.MemoryStream
    • System.IO.BinaryReader
    • System.IO.StringReader ...など他多数

これらのクラスの使い方を説明したい場合、どのクラスをどのように組み合わせて使うか、その組み合わせ方はいろいろと考えられます。FileStreamをBinaryReaderに代入してBinaryReaderの関数からデータを読んだり、FileStreamをStringReaderに代入してStringReaderの関数からデータを読んだりと、組み合わせ方(コラボレーションの方法)が複数パターンあります。このように、複数パターンあるコラボレーションは、1つのクラスコラボ図で表せません。

このコラボレーションをなるべく少ないクラスコラボ図で表すと、次の2つの図のようになります。BinaryReaderやStringReaderに代入できるクラスは、Streamクラスを継承するクラスなので、コラボレーションは継承元のStreamにアクセスする形で表現しました。FileStreamとMemoryStreamはStreamを継承するので、UMLのクラス図にある継承の矢印を使って表現します。このように、継承関係の表現を使うことで、FileStreamとMemoryStreamの2パターンある組み合わせを1つにまとめて表すことが出来ます。

BinaryReaderの使い方 StringReaderの使い方

もう1つの例を挙げます。.Netライブラリの場合、コレクション関係の次のようなクラスがあります。

  • コレクション関係
    • System.Collections.Generic.List<T>
    • System.Collections.Generic.Dictionary<TKey, TValue>
    • System.Collections.Generic.Queue<T> ...など他多数

ListやDictionaryは非常に汎用的なクラスです。あらゆる場面で頻繁に利用されます。使い方は千差万別で、クラスの組み合わせ方に多くのパターンがあります。さらに、List<T>のようにジェネリクスなので、ジェネリクス<T>に他のいろいろなクラスを指定して型を拡張できます。これによって、さらに多くのパターンがあります。

ListやDictionaryのように、柔軟に組み合わせ可能な自由度の高いクラスは、そのクラスにいくつもある使い方のすべてを、クラスコラボ図で一度に表せません。そのため、クラスコラボ図では、そのクラスが潜在的に持つすべての機能を一度にまとめて表現することが出来ません。

このように、クラスコラボ図では、使い方(組み合わせ方=コラボレーション方法)のすべてを一度に表せません。しかし、その一例あれば、個別に表すことが出来ます。なので、クラスコラボ図で複数パターンあるコラボレーションを表したい場合は、個々のパターンに対して1つずつ、必要な数だけクラスコラボ図を描いて、複数のクラスコラボ図を用いることで対応します。

類似して、ライブラリとして汎用的なクラス(汎用的に組み合わせ可能な自由度の高いクラス、ex: EventWaitのクラス、Rxのクラス、XAMLのクラス)は、それが持つすべての潜在能力を表せない⇔その使用の一例であれば表せる
類似して、アクターでないクラス(ex: データクラス、ものクラス)はクラスコラボ図で表しにくい

多くのクラス/矢印を含む複雑なコラボレーションは表しにくい

クラスコラボ図は2Dの図です。そのため、1つの図の中に大量のクラスや矢印を描くことは出来ません。実際に描けるクラスや矢印の数には、限界があります。分かりやすいクラスコラボ図にするには、1つのクラスにつながる矢印の数を、多くても5±2個程度までに抑える必要があります。

クラスコラボ図を描いたときに、1つのクラスにつながる矢印の数が7個以上と多くなってしまう場合は、そのクラスの設計が悪いのかもしれません。通常、1つのクラスが持つ機能は、小さければ小さいほどよいと言われます。クラスが多くの機能を持っていると、クラスに多くの矢印がつながる傾向があります。

そこで、クラスが持つ機能をより小さく分割して、複数のクラスに機能を分けます。これによって、クラスの数は増えますが、1つのクラスが持つ機能は小さくなります。これをクラスコラボ図に描いてみると、自然に矢印の数が減る場合が多くあります。このように、クラスコラボ図が複雑になってしまう場合は、クラスの設計を見直すのも1つの方法です。

しかし、それでもなお、クラスにつながる矢印の数が多くなる場合があります。矢印の数が多くて、クラスコラボ図が分かりにくい場合は、描く内容をいくつかに分けて、複数のクラスコラボ図を描くことで対応します。必要な部分だけを抜き出したり、注目する視点を変えたりして、描く内容を分けます。そして、それらを別々のクラスコラボ図で表現します。

多くのクラス間の複雑なコラボの様子は表しにくい=1クラスから出る関連線は5±2個程度までしか表現できない(⇔1クラスの果たす機能は小さいので、コラボが多くなることは少ないOK、必要な部分だけを描いて複数のクラスコラボ図で表現する)。

テンプレートダウンロード

クラスコラボ図のテンプレートをダウンロードできます。.svg形式のファイルです。.svg形式はChrome (汎用のブラウザ、フリー)などで表示でき、Inkscape (ベクター画像編集ソフト、フリー)などで編集できます。

class_collabo_template.svg [26.3KB]

ダウンロードしたテンプレートの内容は、次に示す図のようになります。テンプレートには、クラスコラボ図を描くのに必要な代表的な部品が揃えてありますので、必要な部品を適宜、コピー&ペーストして、自身のクラスコラボ図作成にご活用ください。

テンプレートの内容 [拡大]

テンプレートには、次の3種類の部品、ノード、エッジ、付加アイコンがあります。ノードを配置して、その間をエッジでつなげることで、クラスコラボ図を作っていきます。付加アイコンは、ノードの左上などに付加して、ノードの情報を補完します。クラスコラボ図の例は「クラスコラボ図の利用例」の節をご覧ください。

クラスコラボ図のテンプレートDLサービス

UMLでの代用

UMLを使ってクラスコラボ図を描きたい場合は、簡易的にクラス図を使って描くことが出来ます。また、アクティビティ図やステートマシン図を代用して描くことも出来ます。例えば、これら3つのUMLを使って、簡単なクラスコラボ図を描くと、次の図のようになります。代用してクラスコラボ図を描く場合、本来の意味とは異なるUMLの使い方をして、クラスコラボ図を描くことになります。

UMLのクラス図を使った場合
UMLのアクティビィティ図を使った場合 UMLのステートマシン図を使った場合

このようにUMLを代用してクラスコラボ図を描くことは可能ですが、描ける図は限られてしまいます。クラスコラボ図を描くには、次の図のような矢印が必要です。しかし、UMLには3、4、6番の矢印がありません。そのため、表現できる範囲が限られてしまいます。

クラスコラボ図に必要な矢印

UMLではアクティビティ図やステートマシン図で簡易的に代用できます。

世の中の似た機能

現状文章 (同じこと、似たことがされている場合のみ)
参照は「本記事のアイディアのように/本記事で提案した~」

本記事で提案したクラスコラボ図は、UMLのコミュニケーション図(共通の目的を協調して達成する複数のオブジェクトの振る舞いを描く)や、クラス図(システムの静的な(時間によって変わらない)関係をモデリングする)などに似ています。下の図は、コミュニケーション図とクラス図の一例です。

コミュニケーション図の例 (引用元: IT専科) [拡大] クラス図の例 (引用元: アジャイルモデリング(AM) 公式サイト) [拡大]

コミュニケーション図は、あるオブジェクトから他のオブジェクトの関数を呼び出したり、その結果を受け取ったりする振る舞いの様子を、上の左図のような矢印で描きます。複数のオブジェクトの間で行われるメッセージのやり取りを描きます。

クラスコラボ図は、コミュニケーション図の描き方をベースにしており、最もよく似ています。コミュニケーション図と違う点は、主に次の3種類の矢印、関数の呼び出し矢印、イベントの受け取り矢印、プロパティ値の読み取り矢印を使って、お互いのクラスがどのように作用し合うかを表します。このように、クラスコラボ図は協調し合う様子を、さまざまな矢印を使ってより具体的に表現しようとします。もし、新しい協調方法の考え方が出てきたときには、その協調方法を表す新しい矢印を積極的に作って、新しい協調方法を明確に表現しようとします。

クラス図は、クラスの間にある静的な(時間によって変わらない)関係を、上の右図のような線と矢印で描きます。クラスコラボ図では、クラス図の描き方のうち、継承インターフェースの描き方を部分的に取り入れて、継承/インターフェースの関係を合わせて描きます。

UMLのクラス図、オブジェクト図(似てない)、コミュニケーション図に似ている。違う点の明記。

 

更新履歴
2010/04/26
  • 書き始め
2012/01/28 v1
  • 初版作成
    (8/B-1/M (6ヶ月弱)は作成休止)

※ご意見、ご感想、改善点、その他の情報などがありましたら、メールにてお知らせ願います。

Copyright (C) 2002 - 2016 Simon.P.G. All Rights Reserved. Top | Simon.P.G. とは | 使用条件 | ご意見
inserted by FC2 system