例8が示すように、開発者は問題とその解決をいくつかのモジュールに分解した結果生じる依存関係に対処する必要がある。 あるモジュールへの変更が他のモジュールへの変更を必要とする可能性がある場合、システムのモジュールが他のモジュールに依存すると言います。 たとえば、ビジネスがその生産方法を変更すると、生産する商品に必要な支払いを計算する方法に結果として変更が生じるかもしれません。
開発者は各依存の性質だけでなく、依存関係の数にも対処する必要があります。 ソフトウェア工学では、「カップリング」はシステムの異なる部分の間の相互依存の程度を指すのに使われます。 あるシステムでは、たとえばモジュールAがモジュールBに依存し、モジュールBがモジュールCに依存する、といった相互依存モジュールの連鎖が起こり得ることは容易に理解できる。 場合によっては、これらのチェーンが結合して、循環的な依存関係を作成することがあり、これは強い（または高い）結合の特定の形式です。 つまり、良いソフトウェア システムは低結合であり、ある部分への変更がシステムの残りの部分に伝搬する可能性が低いことを意味します。 低結合のさらなる利点は、コンポーネントを交換しやすく、潜在的に再利用しやすいことです。
ソフトウェア システムの結合のレベルがどのようなものであっても、どのモジュールが結合されているかを知ることが重要です。 もしモジュール間の結合の記録がなかったら、開発者はモジュールを通して、それぞれが変更の影響を受けるかどうかを判断するのに時間を費やさなければならないでしょう。 その結果、変更が必要ない場合でも、チェックに多くの労力を費やすことになる。 例9は、複数のモジュールが共通または共有データを使用することの危険性を示している。
Example 9
日付処理はソフトウェア開発者にとって常に問題であった。 ある年代のアプリケーションでは、年を表す最も適用可能なストレージ形式は 0 から 99 までの数字でした。 これは、1966年は 66、1989年は 89 というように保存され、したがって、2 桁だけを保存するために必要なスペースが少なくて済むため、理にかなった形式でした。 1989年1月22日は890122、1966年12月22日以降は661222というように、日付の順番で並べ替えることも簡単にできる。
残念なことに、これらのアプリケーションの多くは 2000 年に近づいてもまだ使用されていたため、年の短い形式を使用するすべてのアプリケーションのすべてのモジュールを調査する必要がありました。 このため、いわゆるミレニアム・バグの解決に必要な労力が増加しました。 開発者が保存形式に依存しない日付操作の一貫した方法を持っていたならば、ミレニアム・バグは懸念すべき問題ではなかっただろう。
Cohesion は、1 つのモジュール内のアクティビティがどれだけ密接に関連しているかを説明する方法である。 例えば、組織内のある部門は、まとまった責任のセットを持つかもしれませんし (例えば会計)、持たないかもしれません (雑多なサービス)。 ソフトウェアシステムでは、高度に凝集したモジュールは1つのタスクを実行し、1つの目的を達成します。「1つのことを、うまくやる」というのは、適用するのに有効なモットーです。 モジュールは、単一の論理タスクまたは単一の論理エンティティを実装する必要があります。
低結合と高結合は相反する目標です。 すべてのモジュールが低い抽象度で1つのことしかしない場合、より高い抽象度で活動を行うために、高度に結合されたモジュールの複雑な建造物が必要になることがある。 開発者は、ソフトウェアシステムにおいて、結合度と凝集度の最適なバランスを実現するよう努めなければならない。 例えば、ホテルは宿泊客に部屋を貸すことで収入を得ます。 部屋の概念は、ホテルの予約システムのどこかで表現される可能性があります。 部屋を貸すことによって得られる収入に関するデータを収集し、保存するために、部屋の概念を表すモジュールやクラスを使用すると便利かもしれません。 しかし、より良い解決策は、別の請求書または支払いモジュールを持つことです。特に、ホテルが他の方法、例えば居住者でない人に食事を提供することで収入を得る場合、よりまとまりがあります。
Activity 5 Divide and conquer
- a.なぜ大きなプロジェクトを小さな塊に分割することを考えるかもしれないか？
- b.ソフトウェアシステムの複雑さは保守作業にどのように影響するか？
- c.モジュールとは何でしょう？
- d.なぜソフトウェアシステムでは低結合であることが役立つのですか。
- e.あるモジュールへの変更を検討する際に価値のある情報の種類の例を挙げてください。
- f.モジュールのコンテキスト依存性とは何ですか。
- g.定義されたインタフェースを持つモジュールを使用する利点は何か。
- h.ソフトウェアシステムのモジュールに高い凝集性があることはなぜ役に立つのか。
- i.モジュールのインタフェースを定義する利点は何か。開発・保守が容易かつ安価で、エラーが最小限に抑えられるようにするために、モジュールはどのような特性を示すべきか
- j.なぜ結合と凝集のバランスをとることが重要か
Answer
- a.一人が一度に理解できる量に限度がある。 ですから、一人の人間が扱えるソフトウェアシステムの規模には限りがあります。
- b.ソフトウェアシステムに変更を加える場合、そのシステムについてのすべてを知っている必要がないことが不可欠です。 プログラム内の制御の流れや依存関係が複雑な場合、それぞれの変更は難しくなる。
- c.モジュールとは、ソフトウェアシステムの識別可能な部分であり、個別に検討されるものである。 例えば、モジュールはサブルーチン（手続き型言語ではメソッドに相当）、クラス（オブジェクト指向言語）、ライブラリ関数、または独立して扱われる他の構成要素である。
- d.低結合では、モジュール間の依存関係はほとんどない。 したがって、ソフトウェアシステムの一部分（1つまたは複数のモジュール）に加えられた変更は、システム全体に伝播する可能性が低くなる。 (モジュール間の依存関係の明確な記録は、ソフトウェアシステムに提案された変更の影響を予測するのに役立ちます。)
- e.提案された変更の分析に貢献する2種類の情報があります：
- どのモジュールが問題のモジュールのクライアントですか？
- 問題のモジュールのクライアントモジュールでは、どのような仮定がなされているか。
- f.モジュールのコンテキスト依存は、モジュールが正しく動作するために必要とする他のモジュールのサービスです。 モジュールのコンテキスト依存性は、他のインタフェースで表現することができます。 事実上、モジュールの責任をインターフェースとコンテキスト依存性で表現することができます。
- g.利点は次のとおりです。
- 開発者はモジュールのインターフェイス (その構文と、それが要求し達成するもの – そのセマンティクス) についてだけ知る必要があり、そのサービスを提供する方法については知る必要がありません。 その結果、開発者はより生産的になることができる。
- 開発者はソフトウェアシステムの側面をより徹底的に理解することができるので、バグの発生が少なくなる。
- 無関係なモジュールが回避されるので、バグの発見が容易になるはずだ。
- モジュールが何を提供し要求するかが分かれば、モジュール再利用の可能性は高まる。
- h. 高い凝集性を持つと、モジュールが操作またはアクティビティの賢明なセットを実行する。 理想的には、高い結合性は、モジュールごとにただ1つの主要な抽象化を意味する。 インタフェースは、開発者がモジュールを使用するために知っていなければならないことを抽象化する。 これにより、開発者はモジュールの目的とその使い方を理解しやすくなります。 さらに、高い結合性は、モジュールが他のアプリケーションでより再利用可能になる傾向がある。
- j.システムを構築する際、疎結合で結合度の低いモジュールの小さなセットと、密結合で結合度の高いモジュールの大きなセットのどちらかを選択しなければならないかもしれない。 前者の場合、各モジュールが理解しにくく、後者の場合、モジュール間の関係が複雑になりすぎる可能性がある。 適切なバランスをとる必要がある。