最終更新日：2026年7月27日
fe fe-technology software-design
まず結論
モジュール強度とは、1つのモジュール内に含まれる処理同士が、どれくらい強く関係しているかを表す考え方です。
基本情報技術者試験では、次の順序を押さえます。
弱い
暗合的
↓
論理的
↓
時間的
↓
手順的
↓
連絡的
↓
情報的
↓
機能的
強い
強度が高いほど、モジュールの役割が明確になり、修正や再利用がしやすくなります。
特に重要なのは、次の切り分けです。
処理コードや引数で、複数機能のうち1つを選ぶ
→ 論理的強度
同じデータ構造を扱い、機能ごとに入口を分ける
→ 情報的強度
直感的な説明
モジュール強度は、
なぜ、その処理を同じ箱に入れたのか
を見る考え方です。
例えば、1つのモジュールに次の処理が入っているとします。
挿入
更新
削除
そして、処理コードによって、どれか1つを選んで実行します。
I → 挿入
U → 更新
D → 削除
これは、似た種類の処理をまとめ、条件で選んでいるため、論理的強度です。
一方、次のように入口を分けている場合は、情報的強度に近づきます。
insert()
update()
delete()
定義・仕組み
モジュール強度は、英語では cohesion と呼ばれます。
1つのモジュールが、どれだけ一貫した目的を持っているかを見る指標です。
7種類のモジュール強度
| 種類 | まとめる理由 | 見分ける言葉 |
|---|---|---|
| 暗合的強度 | 関係のない処理をまとめる | 寄せ集め、特別な関係がない |
| 論理的強度 | 同種の機能をまとめ、条件で選ぶ | 処理コード、引数、分岐 |
| 時間的強度 | 同じ時期に実行する処理をまとめる | 起動時、終了時、初期化時 |
| 手順的強度 | 決められた順序で実行する処理をまとめる | 順番、手順、逐次 |
| 連絡的強度 | 同じデータを受け渡しながら処理する | 同じデータ、参照、受け渡し |
| 情報的強度 | 同じデータ構造を扱い、入口を分ける | 同じ資源、機能ごとの入口 |
| 機能的強度 | 1つの明確な機能だけを実現する | 単一機能、1つの目的 |
強度が高い方がよい理由
モジュール強度が高いほど、モジュールの役割が明確になります。
1つの役割に集中する
↓
変更範囲が小さくなる
↓
他への影響を抑えやすい
↓
再利用しやすい
一方、関係の薄い処理をまとめると、1か所を修正しただけで別の処理へ影響する可能性があります。
科目Aでどう出る？
科目Aでは、モジュール設計書や処理内容を読み、どの強度に当たるかを選ぶ問題が出ます。
論理的強度
次のような特徴があれば、論理的強度です。
関連する複数の機能を1つにまとめる
＋
パラメータや処理コードで1つを選ぶ
例：
process(code)
code = I → 挿入
code = U → 更新
code = D → 削除
情報的強度
同じデータ構造を扱いますが、機能ごとに入口を分けます。
insert(data)
update(data)
delete(data)
判断の違いは次のとおりです。
1つの入口で機能を選ぶ
→ 論理的強度
機能ごとに入口を分ける
→ 情報的強度
手順的強度と連絡的強度
この2つも混同しやすいです。
順番だけでまとめる
→ 手順的強度
同じデータを受け渡しながら順番に処理する
→ 連絡的強度
選択肢を切る判断表
| 問題文の表現 | 選ぶ強度 |
|---|---|
| 関係のない機能をまとめる | 暗合的強度 |
| 処理コードで機能を選ぶ | 論理的強度 |
| 起動時や終了時に実行する | 時間的強度 |
| 決められた順に実行する | 手順的強度 |
| 同じデータを受け渡して処理する | 連絡的強度 |
| 同じデータ構造を扱い、別入口を持つ | 情報的強度 |
| 1つの機能だけを実現する | 機能的強度 |
どんな場面で使う？
モジュール強度は、プログラムを機能ごとに分けるときの判断に使います。
例えば、1つの関数が次の処理をすべて持っているとします。
入力チェック
データ更新
メール送信
ログ出力
画面表示
役割が多すぎると、1か所を修正したときの影響範囲が広がります。
そこで、処理を役割ごとに分けます。
validate_input()
update_data()
send_mail()
write_log()
display_result()
このように、1つのモジュールを1つの明確な目的に近づけると、機能的強度を高められます。
よくある誤解・混同
複数の関連機能をまとめれば、すべて情報的強度
誤りです。
同じ入口で処理コードにより機能を選ぶ場合は、論理的強度です。
process("I")
process("U")
process("D")
→ 論理的強度
機能ごとに入口を分ける場合は、情報的強度です。
insert()
update()
delete()
→ 情報的強度
処理の順番があれば、すべて連絡的強度
誤りです。
順番だけが共通
→ 手順的強度
同じデータを受け渡す
→ 連絡的強度
モジュール強度は低い方がよい
誤りです。
モジュール強度は、高い方が役割が明確です。
高い強度
→ モジュール内のまとまりが強い
なお、モジュール間の依存関係を表す「結合度」は、一般に低い方がよいとされます。
モジュール内のまとまり
→ 強度は高い方がよい
モジュール間の依存
→ 結合度は低い方がよい
まとめ（試験直前用）
- モジュール強度は、モジュール内部の処理同士のまとまりを表す
- 弱い順は、暗合的→論理的→時間的→手順的→連絡的→情報的→機能的
- 処理コードで機能を選ぶなら論理的強度
- 同じデータ構造を扱い、入口を分けるなら情報的強度
- 順番だけなら手順的、同じデータを受け渡すなら連絡的
- 1つの明確な機能だけなら機能的強度
- モジュール強度は高い方がよい