モジュール強度とは？7種類と論理的強度の見分け方【基本情報技術者試験】

まず結論

モジュール強度とは、1つのモジュール内に含まれる処理同士が、どれくらい強く関係しているかを表す考え方です。

基本情報技術者試験では、次の順序を押さえます。

弱い
暗合的
↓
論理的
↓
時間的
↓
手順的
↓
連絡的
↓
情報的
↓
機能的
強い

強度が高いほど、モジュールの役割が明確になり、修正や再利用がしやすくなります。

さらに、モジュール設計全体では次の組合せが重要です。

モジュール内部のまとまり
→ 強度は高い方がよい

モジュール同士の依存
→ 結合度は低い方がよい

試験では、「中は強く、外は弱く」と覚えると判断しやすくなります。

特に重要なのは、次の切り分けです。

処理コードや引数で、複数機能のうち1つを選ぶ
→ 論理的強度

同じデータ構造を扱い、機能ごとに入口を分ける
→ 情報的強度

直感的な説明

モジュール強度は、

なぜ、その処理を同じ箱に入れたのか

を見る考え方です。

例えば、1つのモジュールに次の処理が入っているとします。

挿入
更新
削除

そして、処理コードによって、どれか1つを選んで実行します。

I → 挿入
U → 更新
D → 削除

これは、似た種類の処理をまとめ、条件で選んでいるため、論理的強度です。

一方、次のように入口を分けている場合は、情報的強度に近づきます。

insert()
update()
delete()

また、設計全体を見るときは、次のイメージが役立ちます。

1つのモジュールの中
→ 同じ目的の処理をまとめる
→ 強度を高くする

別のモジュールとの関係
→ 必要以上に依存しない
→ 結合度を低くする

つまり、High Cohesion / Low Coupling（高い強度・低い結合度）が望ましい設計です。

定義・仕組み

モジュール強度は、英語では cohesion と呼ばれます。

1つのモジュールが、どれだけ一貫した目的を持っているかを見る指標です。

7種類のモジュール強度

種類	まとめる理由	見分ける言葉
暗合的強度	関係のない処理をまとめる	寄せ集め、特別な関係がない
論理的強度	同種の機能をまとめ、条件で選ぶ	処理コード、引数、分岐
時間的強度	同じ時期に実行する処理をまとめる	起動時、終了時、初期化時
手順的強度	決められた順序で実行する処理をまとめる	順番、手順、逐次
連絡的強度	同じデータを受け渡しながら処理する	同じデータ、参照、受け渡し
情報的強度	同じデータ構造を扱い、入口を分ける	同じ資源、機能ごとの入口
機能的強度	1つの明確な機能だけを実現する	単一機能、1つの目的

強度が高い方がよい理由

モジュール強度が高いほど、モジュールの役割が明確になります。

1つの役割に集中する
↓
変更範囲が小さくなる
↓
他への影響を抑えやすい
↓
再利用しやすい

一方、関係の薄い処理をまとめると、1か所を修正しただけで別の処理へ影響する可能性があります。

結合度との関係

モジュール強度と一緒に問われやすいのが、モジュール結合度です。

モジュール強度：モジュール内部のまとまり
モジュール結合度：モジュール同士の依存の強さ

信頼性・保守性を高めるには、一般に次の方向が望まれます。

強度を高くする
＋
結合度を低くする

例えば、あるモジュールを修正しただけで別の多数のモジュールまで修正が必要になるなら、結合度が高い状態です。

Aを変更
↓
Bも変更
↓
Cも変更
↓
Dにも影響

これに対して、変更の影響ができるだけそのモジュール内に閉じていれば、保守しやすくなります。

科目Aでどう出る？

科目Aでは、モジュール設計書や処理内容を読み、どの強度に当たるかを選ぶ問題が出ます。

論理的強度

次のような特徴があれば、論理的強度です。

関連する複数の機能を1つにまとめる
＋
パラメータや処理コードで1つを選ぶ

例：

process(code)

code = I → 挿入
code = U → 更新
code = D → 削除

入力媒体を条件で選ぶ場合も、論理的強度です。

input_data("keyboard")
input_data("file")
input_data("network")

キーボード・ファイル・ネットワークなど
同じ種類の入力処理をまとめる
＋
引数で実行する処理を選ぶ
→ 論理的強度

情報的強度

同じデータ構造を扱いますが、機能ごとに入口を分けます。

insert(data)
update(data)
delete(data)

判断の違いは次のとおりです。

1つの入口で機能を選ぶ
→ 論理的強度

機能ごとに入口を分ける
→ 情報的強度

手順的強度と連絡的強度

この2つも混同しやすいです。

順番だけでまとめる
→ 手順的強度

同じデータを受け渡しながら順番に処理する
→ 連絡的強度

強度と結合度をセットで問う問題

「信頼性・保守性を向上させる設計」を問われたら、次の組合せを選びます。

モジュール強度	モジュール結合度	判断
強い	強い	×
強い	弱い	○
弱い	強い	×
弱い	弱い	×

ここでは、個々の強度の種類まで判別する必要はありません。

モジュール内はまとまりを強く
モジュール間の依存は弱く

この2点だけで選択肢を切れます。

選択肢を切る判断表

問題文の表現	選ぶ強度
関係のない機能をまとめる	暗合的強度
入力媒体などを処理コードで選ぶ	論理的強度
起動時や終了時に実行する	時間的強度
決められた順に実行する	手順的強度
同じデータを受け渡して処理する	連絡的強度
同じデータ構造を扱い、別入口を持つ	情報的強度
1つの機能だけを実現する	機能的強度

4択での典型的な切り分け

説明	強度
異なる入力媒体からのデータを条件で選んで処理する	論理的強度
特定の時点で必要な作業をまとめる	時間的強度
複数の機能を決められた順番で実行する	手順的強度
単一の機能だけを実行する	機能的強度

このような選択肢では、単一の機能だけを実行する機能的強度が最も高いと判断します。

どんな場面で使う？

モジュール強度は、プログラムを機能ごとに分けるときの判断に使います。

例えば、1つの関数が次の処理をすべて持っているとします。

入力チェック
データ更新
メール送信
ログ出力
画面表示

役割が多すぎると、1か所を修正したときの影響範囲が広がります。

そこで、処理を役割ごとに分けます。

validate_input()
update_data()
send_mail()
write_log()
display_result()

このように、1つのモジュールを1つの明確な目的に近づけると、機能的強度を高められます。

さらに、分割したモジュール同士が互いの内部処理を細かく知る必要がないようにすると、結合度も下げやすくなります。

よくある誤解・混同

複数の関連機能をまとめれば、すべて情報的強度

誤りです。

同じ入口で処理コードにより機能を選ぶ場合は、論理的強度です。

process("I")
process("U")
process("D")
→ 論理的強度

機能ごとに入口を分ける場合は、情報的強度です。

insert()
update()
delete()
→ 情報的強度

異なる入力媒体を扱えば、情報的強度

誤りです。

キーボード、ファイル、ネットワークなど、似た入力機能を1つの入口にまとめ、引数で選ぶ場合は論理的強度です。

input_data("keyboard")
input_data("file")
input_data("network")
→ 論理的強度

処理の順番があれば、すべて連絡的強度

誤りです。

順番だけが共通
→ 手順的強度

同じデータを受け渡す
→ 連絡的強度

モジュール強度と結合度は、どちらも高い方がよい

誤りです。

モジュール内部のまとまり
→ 強度は高い方がよい

モジュール間の依存
→ 結合度は低い方がよい

試験中は、「中は強く、外は弱く」で思い出せます。

モジュール強度は低い方がよい

誤りです。

モジュール強度は、高い方が役割が明確です。

高い強度
→ モジュール内のまとまりが強い

まとめ（試験直前用）

モジュール強度は、モジュール内部の処理同士のまとまりを表す
弱い順は、暗合的→論理的→時間的→手順的→連絡的→情報的→機能的
処理コードや入力媒体の種類で機能を選ぶなら論理的強度
同じデータ構造を扱い、入口を分けるなら情報的強度
順番だけなら手順的、同じデータを受け渡すなら連絡的
1つの明確な機能だけなら機能的強度
モジュール強度は高く、結合度は低くする
強度と結合度の問題は 「中は強く、外は弱く」 で切る

🔗 関連記事

🏠 基本情報技術者トップに戻る