凝集度

凝集度（ぎょうしゅうど、コヒージョン、cohesion）とは、情報工学においてモジュール内のソースコードが特定の機能を提供すべく如何に協調しているかを表す度合いである。IPAが実施する情報処理技術者試験では、強度(きょうど、ストレングス、strength)という言葉が使われる。凝集度は順序尺度の一種であり、「凝集度が高い」とか「凝集度が低い」といった言い方で使われる。凝集度の高いモジュールは、堅牢性、信頼性、再利用性、読みやすさなどの点で好ましく、凝集度の低いモジュールは保守/評価/再利用/読解が難しいため好ましくないとされる。

凝集度は結合度と組み合わせて議論されることが多い。凝集度が高いモジュールは他との結合度が低いことが多く、逆に凝集度が低ければ結合度が高くなる傾向がある。ソフトウェアの品質を凝集度と結合度で表す手法は、、、 が定義したもので、「良い」プログラミングの実例の特徴を探るためにIBMで彼らが指揮したいくつかのソースコード解析から生まれた。

高い凝集度 
凝集度は、あるコードがどれだけそのクラスの責任分担に集中しているかを示す尺度である。オブジェクト指向プログラミングでは、クラスの凝集度を高めるようにそのクラスの責任範囲を設定することが有益とされている。凝集度の高いシステムでは、コードの読みやすさと再利用の容易さが増し、複雑さが管理可能な程度に抑えられる。

凝集度は次のような場合に低下する:
 クラスの責任範囲（メソッド群）に共通性がほとんどない。
 メソッドが様々なことを行い、しばしば粒度の粗いデータや全く関係のないデータ群を扱う。

凝集度が低い（弱い）場合の欠点は次の通りである:
 モジュール群を理解することが難しくなる。
 システムの保守が難しくなる。ある論理的修正が複数のモジュールにまたがって影響する可能性が増すためである。
 モジュールの再利用が難しくなる。凝集度の低いモジュールの提供するAPIには一貫性がないことが多いため。

凝集度の程度 
凝集度は品質尺度であり、ソースコードを調査検討することで凝集度の程度が分類される。低い凝集度から高い凝集度までを以下のように分類できる:

偶発的凝集（Coincidental Cohesion）「最悪」 適当（無作為）に集められたものがモジュールとなっている。モジュール内の各部分には特に関連性はない（例えば、よく使われる関数を集めたモジュールなど）。
論理的凝集（Logical Cohesion） 論理的に似たようなことをするものを集めたモジュール（例えば、全ての入出力ルーチンを集めたモジュールなど）。
時間的凝集（Temporal Cohesion） 動作させたときにモジュール内の各部分が時間的に近く動作する（例えば、ある例外を受けたときに動作するルーチンとして、ファイルをクローズするルーチン、エラーログを作成するルーチン、ユーザーに通知するルーチンなどを集めたモジュール）。
手続き的凝集（Procedural Cohesion） ある種の処理を行うときに動作する部分を集めたモジュール（例えば、ファイルのパーミッションをチェックするルーチンとファイルをオープンするルーチンなど）。
通信的凝集（Communicational Cohesion） 同じデータを扱う部分を集めたモジュール（例えば、同種のレコードの情報を操作するルーチンを集めたモジュールなど）。
逐次的凝集（Sequential Cohesion） ある部分の出力が別の部分の入力となるような部分を集めたモジュール（例えば、全体としてあるファイルを読み込んで処理をするモジュール）。
機能的凝集（Functional Cohesion）「最善」 単一のうまく定義されたタスクを実現するモジュール（例えば、角度のサインを計算するモジュール）

凝集度は必ずしも上記の順に高いとか低いと言えるものではない。Larry Constantine やエドワード・ヨードンや他の人々の研究によると、上記の最初の2つは他の凝集よりも劣っており、通信的凝集以下の3つはそれ以外よりも優れている。いずれにしても7番目の機能的凝集が最も優れているとされる。

機能的凝集が最も好ましいとしても、現実には実現できない場合があるだろう。状況によっては通信的凝集が最善であることも多い。いずれにしても通信的凝集以下の3つの凝集では、モジュールを構成するコードが特定の機能を実現するために集中していて無駄がない傾向が強く、様々な状況で再利用の可能性が広がる。

参考文献

関連項目 
結合度
モジュール
ソフトウェア測定法

外部リンク 
Cohesion metrics

ソフトウェア測定の尺度
ソフトウェアアーキテクチャ
プログラミング原則