戦国IT - 情報処理技術者試験の過去問対策サイト
ブログお知らせお問い合わせ料金プラン

基本情報技術者 2011年 秋期 午前(科目A)45


問題文

モジュール設計書を基にモジュール強度を評価した。適切な評価はどれか。   〔モジュール設計書(抜粋)〕  上位モジュールから渡される処理コードに対応した処理をする。処理コードが“I”のときは挿入処理、処理コードが“U”のときは更新処理、処理コードが“D”のときは削除処理である。

選択肢

これは“暗合的強度”のモジュールである。モジュール内の機能間に特別な関係はなく、むしろ他のモジュールとの強い関係性をもつ可能性が高いので、モジュール分割をやり直した方がよい。
これは“情報的強度”のモジュールである。同一の情報を扱う複数の機能を、一つのモジュールにまとめている。モジュール内に各処理の入口点を設けているので、制御の結びつきがなく、これ以上のモジュール分割は不要である。
これは“連絡的強度”のモジュールである。モジュール内でデータの受渡し又は参照を行いながら、複数の機能を逐次的に実行している。再度見直しを図り、必要に応じて更にモジュール分割を行った方がよい。
これは“論理的強度”のモジュールである。関連した幾つかの機能を含み、パラメタによっていずれかの機能を選択して実行している。現状では大きな問題となっていないとしても、仕様変更に伴うパラメタの変更による影響を最小限に抑えるために、機能ごとにモジュールを分割するか、機能ごとの入口点を設ける方がよい。(正解)

モジュール強度の評価【午前2 解説】

要点まとめ

  • 結論→ 上記の設計書は一つの入口で処理コードにより挿入・更新・削除など複数の機能を選択して実行しているため、論理的強度に該当し、正解は です。
  • 根拠→ モジュール内で関連する幾つかの機能が存在し、外部から渡されるパラメタ(処理コード)でどの機能を実行するか決定している点が論理的強度の典型的特徴です。
  • 差がつくポイント→ 情報的強度は各機能ごとに別々の入口を持つ点であり、入口が単一でパラメタ選択している場合は論理的強度と判定することが合格者との差になります。

正解の理由

正解は です。問題文のモジュールは「上位モジュールから渡される処理コードに対応した処理をする」とあり、1つの入口で処理コードに応じて挿入(I)、更新(U)、削除(D)といった複数の機能を切替実行しています。これは「関連した複数の機能をパラメタで選択して実行する」振る舞いであり、ソフトウェア工学でいうところの「論理的強度(logical cohesion)」に該当します。論理的強度は機能が関連しているとはいえ、単一の分岐(パラメタ)に依存するため、機能追加や仕様変更時にパラメタ処理や分岐ロジックを修正する必要が生じ、保守性が低下しやすい点に注意が必要です。

よくある誤解

  • 「同じデータを扱っている=情報的強度」と誤認する人が多いが、情報的強度は各機能ごとに独立した入口を持つ構成が要件です。
  • 「複数機能を順番に実行している=連絡的強度」と誤ることがあるが、連絡的(逐次的)強度は機能間でデータが逐次渡される流れがある場合に該当します。
  • 仕様記述に「関連した機能」と書かれているだけで機能的強度/情報的強度と判断すると誤るため、入口の数と選択方法(パラメタか入口分離か)を必ず確認してください。

解法ステップ

  1. モジュールの入口(エントリポイント)が何個あるか確認する。単一か複数かが重要。
  2. 単一入口なら、内部でパラメタ(例:処理コード)により機能を選択しているかを確認する。あれば論理的強度。
  3. 複数入口で、それぞれが同一データを扱うなら情報的強度を検討する。
  4. 機能が逐次的にデータを受け渡しているなら連絡的(逐次的)強度の可能性を検討する。
  5. 選択肢と設問文を照らし合わせ、「入口の数」と「機能の選択方法」を根拠に最終判断する。

選択肢別の誤答解説

  • ア: 暗合的強度(偶然的・低い強度)とする説明は誤りです。暗合的強度はモジュール内の機能間に関連性がなく単に集めた状態を指しますが、問題文の機能は「挿入・更新・削除」といった関連性があるため該当しません。
  • イ: 情報的強度とするのも誤りです。情報的強度は「同一データに対する複数の機能を、各機能ごとに入口を持ってまとめた」構成が特徴です。本設計書は単一入口で処理コードにより機能を切替しているため情報的強度ではありません。
  • ウ: 連絡的強度(逐次的強度)とする判断も不適切です。連絡的強度は複数機能を順序立ててデータを受け渡しながら実行する場合に該当しますが、ここでは機能は選択実行され順次処理されるとは限らないため該当しません。
  • エ: は正しい。関連する幾つかの機能を含み、パラメタ(処理コード)でいずれかを選択して実行している点が論理的強度の定義に一致します。

補足コラム

論理的強度は機能をまとめて管理しやすい反面、分岐ロジックやパラメタ管理が肥大すると保守性が低下します。改善策は主に2つです。1)機能ごとにモジュールを分割し、個別の責務を持たせる(機能的強度へ近づける)。2)現在の単一入口を残す場合は内部で各機能を責務分割したサブモジュールに委譲し、Dispatcher(分配役)だけを残す設計にする。設計例(擬似コード):
def process_record(code, record):
    if code == 'I':
        insert_record(record)
    elif code == 'U':
        update_record(record)
    elif code == 'D':
        delete_record(record)
改善例は各処理を外部化して dispatcher を薄くすることです。

FAQ

Q1: 情報的強度と論理的強度の見分け方のコツは?
A1: 入口(エントリポイント)の数を確認すること。複数入口でそれぞれが独立した機能なら情報的強度、単一入口でパラメタ選択なら論理的強度です。
Q2: 論理的強度は必ず分割すべきですか?
A2: すぐに必須ではありませんが、仕様変更が頻繁であれば分割(またはサブモジュール化)して保守性を上げることを推奨します。
Q3: 「処理コードが一つで複数処理を順に実行する」場合は?
A3: その場合は逐次的(連絡的)強度の可能性があります。機能が順序に依存してデータを渡すかどうかを確認してください。

関連キーワード: モジュール強度, 論理的強度, 情報的強度, 暗合的強度, 連絡的強度, モジュール設計, エントリポイント, コヒージョン, 保守性, リファクタリング
← 前の問題へ次の問題へ →
戦国ITクイズ機能

\ せっかくなら /

基本情報技術者
クイズ形式で学習しませんか?

クイズ画面へ遷移する

すぐに利用可能!

©︎2026 情報処理技術者試験対策アプリ

このサイトについてブログプライバシーポリシー利用規約特商法表記開発者について