基本情報

基本情報 令和元年度 秋期 問46|テクノロジ系に関する問題

問題

基本情報 | 令和元年度 秋期 | 分野:テクノロジ系

モジュール結合度が最も弱くなるものはどれか。

キーボード:1〜4で選択・Enterで次へ

タップするとすぐ答え合わせ

答え合わせ

正解は B
  • A
  • B
  • C
  • D

自信の3択

えらぶと、この端末に記録します(登録はいりません)

解説

答えは b「二つのモジュール間で必要なデータ項目だけを引数として渡す」 です。

モジュール結合度は「モジュール同士のくっつき具合」のこと。弱い=独立性が高くて良いんです。

例えば友達と仕事を分担するとき:

  • 必要な情報だけメモで渡す=シンプルでお互い独立(良い)
  • 共通のホワイトボードに全部書く=みんな影響し合う(悪い)

👉 覚え方:結合度は弱い方が良い。必要なデータだけ渡すのが理想。

ほかの選択肢:a 一つのモジュールに機能を詰め込む=結合度ではなく強度(凝集度)が低くなる話/c グローバル領域=共通結合(強い)/d 制御用の引数=制御結合。

なぜこれが正解か

正解は b。モジュール結合度は弱いほど良い(独立性が高い)。bの「必要なデータ項目だけを引数として渡す」はデータ結合(Data Coupling)で、6段階分類で最も弱い結合。

モジュール結合度の6段階(弱い順)

1. データ結合:必要なデータ項目だけを引数で渡す(最弱・最良)

2. スタンプ結合:構造体・レコードを丸ごと渡す(不要項目も含む)

3. 制御結合:呼ばれる側の処理を制御する引数を渡す(フラグ等)

4. 外部結合:外部宣言した変数を共有

5. 共通結合:グローバル変数を複数モジュールで共有

6. 内容結合:他モジュールの内部を直接参照・変更(最強・最悪)

各選択肢の解説

  • a 一つのモジュールでできるだけ多くの機能を実現:モジュール間の結合ではなく,モジュール内の強度(凝集度)が低下する設計で,結合度を弱める方法ではない。
  • b データ結合:最も弱い結合(正解)
  • c グローバル領域共有:共通結合(強い結合)
  • d 制御用引数:制御結合(中程度の強さ)

覚え方・ひっかけ注意

「結合度は弱いほど良い、強度は強いほど良い」が大原則。モジュール強度(凝集度)と対で覚える:

  • 強度:機能的→情報的→連絡的→手順的→時間的→論理的→暗号的(強→弱)
  • 結合度:データ→スタンプ→制御→外部→共通→内容(弱→強)

良い設計=強度高く結合度弱く(High Cohesion, Loose Coupling)。

理論的背景

モジュール結合度・凝集度の概念はLarry Constantine/Glenford Myersの構造化設計(Structured Design、1974)で確立。後にステーィーブ・マコネル『Code Complete』やマイケル・フェザーズ『Working Effectively with Legacy Code』で再強調され、現代のソフトウェア設計原則の基盤となっている。

設計原則との連関

High Cohesion, Loose Couplingはオブジェクト指向のSOLID原則と直結:

  • SRP(Single Responsibility Principle):単一責任で凝集度向上
  • OCP(Open/Closed Principle):拡張に開き変更に閉じる
  • LSP(Liskov Substitution Principle):継承時の置換可能性
  • ISP(Interface Segregation Principle):インタフェース分離
  • DIP(Dependency Inversion Principle):依存方向の逆転で結合度低減

さらにDDD(ドメイン駆動設計)の境界づけられたコンテキスト(Bounded Context)、アグリゲート、集約ルートもモジュール結合度の現代版設計指針。

結合度が低い設計のメリット

  • 保守性:変更影響範囲が局所化
  • テスタビリティ:単体テストが書きやすい(モック容易)
  • 再利用性:依存少なく独立利用可能
  • 並行開発:チーム分担で並行作業可能
  • 理解容易性:1モジュール読めば理解できる

実装手法

  • DI(Dependency Injection):Spring Framework、ASP.NET Core、Angular。結合度を構成時に解決
  • イベント駆動:Pub/Subで送受信側を分離(Kafka、SNS、EventBridge)
  • マイクロサービス:サービス境界で結合度を低減
  • CQRS(Command Query Responsibility Segregation):書込/読出で分離
  • ヘキサゴナルアーキテクチャ/クリーンアーキテクチャ:依存方向を内側に制約

アンチパターン

  • God Object:1クラスが全てを知る(結合度爆発、凝集度低)
  • Shotgun Surgery:1変更で多モジュール修正必要
  • Feature Envy:他モジュールのデータを過剰に使う
  • Circular Dependency:循環依存
  • Vendor Lock-in:特定ベンダ/ライブラリへの強結合

試験での位置づけ

基本情報・応用情報のソフトウェア工学/設計分野で必出。応用情報・システムアーキテクトでは具体的なリファクタリング手法、設計パターン(GoF)、エンタープライズアーキテクチャ(TOGAF)まで踏み込む。

選択肢の発展補足

制御結合(フラグ引数)の問題:呼び出し側が呼ばれる側の内部分岐を知る必要があり、両者が密結合になる。対策はStrategyパターンやPolymorphismで分岐自体を別オブジェクトに分離。Martin FowlerのRefactoringでは「Replace Parameter with Method」「Replace Conditional with Polymorphism」等のリファクタリングカタログで結合度低減手法が体系化されている。

この問題の根拠出典:IPA(情報処理推進機構)公式 基本情報技術者試験 令和元年度 秋期 問46
訂正の記録この問題の訂正はありません(サイト全体の記録)
出典と作り方

出典:IPA(情報処理推進機構)公式 基本情報技術者試験 令和元年度 秋期 問46/ 公的機関配布資料につき出典明記の上引用。解説は合格ナビ独自の3段階の解説(初級・標準・上級)です。