4.3システム開発技術（オブジェクト指向・UML・設計・テスト）

システム開発技術の問題で失点しやすいのは、似た用語の境界線を曖昧に覚えていることです。「外部設計と内部設計はどちらがユーザー視点か」「結合度は低いほど良いのか高いほど良いのか」「ホワイトボックステストの網羅基準はどれが最も厳格か」といった対になる概念の相対関係を正確に押さえることが、応用情報レベルでは得点に直結します。この節では開発プロセスの流れに沿って、オブジェクト指向・UML・モジュール設計・テスト技法を一気通貫で整理します。

4.3.1開発プロセスとオブジェクト指向

• 開発プロセス＝要件定義→外部設計（概要設計）（利用者視点の画面・帳票・インタフェース設計）→内部設計（詳細設計）（開発者視点のモジュール構造・アルゴリズム・データ構造の設計）→プログラミング→テストという流れ。外部設計はユーザーが確認できる仕様、内部設計はユーザーには見えない実装寄りの仕様という視点の違いを区別する。
• オブジェクト指向の三大要素＝カプセル化（データとそれを操作する処理をひとつにまとめ、外部から不要な内部詳細を隠す情報隠蔽を実現）／継承（既存クラス=スーパークラスの性質を引き継いで新クラス=サブクラスを定義し、共通部分の再利用と差分の追加を両立）／多相性（ポリモーフィズム）（同じメソッド呼び出しでも、呼び出すオブジェクトの実際の型によって異なる処理が実行される性質。オーバーライドで実現）。
• カプセル化=隠す、継承=引き継ぐ、多相性=同じ呼び方で違う動きをする、という役割の違いを区別する。例えば「図形」スーパークラスの面積を求める()メソッドを「円」「四角形」の各サブクラスがそれぞれ独自の計算式でオーバーライドすれば、呼び出し側は図形の種類を意識せず同じメソッド呼び出しで正しい面積を得られる（多相性の典型例）。

4.3.2UMLとモジュール分割

• UML（統一モデリング言語）の主要図＝クラス図（クラス間の関連・集約・汎化（継承）等の静的構造を表す）／ユースケース図（利用者=アクターとシステムの機能=ユースケースの外部から見た振る舞いを表す。要件定義段階で有用）／シーケンス図（オブジェクト間のメッセージのやり取りを時系列で表す。処理の流れを追う設計段階で有用）。
• クラス図=静的な構造、シーケンス図=動的な時間の流れ、ユースケース図=外部からの機能の見え方、という描く対象の違いを区別する。クラス図の汎化はスーパークラス-サブクラス関係（継承）、集約は「全体-部分」の緩やかな所有関係（部分は全体から独立して存在しうる）、コンポジションはより強い所有関係（部分は全体のライフサイクルに従属）を表す。
• モジュール分割の良否は結合度（モジュール間の依存の強さ）と強度（凝集度）（モジュール内部の要素のまとまりの強さ）で評価する。結合度は低いほど良い（モジュール間が疎結合＝独立性が高く保守しやすい）。強度は高いほど良い（モジュール内が単一目的にまとまっている＝機能的強度が最も強い）。「結合度は高いほど良い」と誤って覚えないこと（強度と逆の評価軸）。

4.3.3テスト技法とレビュー

• ホワイトボックステスト＝プログラムの内部構造（制御の流れ）に着目してテストケースを設計する手法。網羅基準には強さの順に、命令網羅（C0）（全命令を最低1回実行）／分岐（判定）網羅（C1）（全分岐の真偽を最低1回ずつ実行）／条件網羅（C2）（判定内の各条件の真偽を最低1回ずつ実行）／複数条件網羅（条件の組合せを全て網羅・最も厳格で必要テストケース数も最多）がある。
• ブラックボックステスト＝プログラムの内部構造を見ずに、入力と出力の仕様だけに着目してテストケースを設計する手法。同値分割（仕様上同じ結果になると期待される入力の集合=同値クラスから代表値を選ぶ）と限界値分析（同値クラスの境界付近にバグが集中しやすいという経験則から、境界値とその前後を重点的にテストする）を組み合わせるのが定石。
• 分岐網羅（C1）は分岐網羅を満たせば命令網羅（C0）も自動的に満たすが、条件網羅（C2）は分岐網羅（C1）を自動的には満たさない（個々の条件の真偽を網羅しても、判定全体としての真偽の組合せが偏る場合がある）。レビュー＝コードやドキュメントを人手で確認する品質保証活動。ウォークスルー（作成者主導で進行を追いながら指摘を得る非公式な形式）とインスペクション（役割を定めたモデレータ主導の公式な形式で、より厳格）を区別する。

ある通販システムの「クーポン割引額を計算する」機能を例に、テスト技法の違いを具体的に確認しましょう。仕様は「購入金額が3000円未満なら割引なし、3000円以上10000円未満なら10%割引、10000円以上なら20%割引」だとします。ブラックボックステストの同値分割では、この仕様から「3000円未満」「3000円以上10000円未満」「10000円以上」という3つの同値クラスを識別し、各クラスから代表値（例: 1000円・5000円・15000円）を選んでテストします。しかし同値分割だけでは境界のずれ（例: >= を > と書き間違えるようなバグ）を見逃しやすいため、限界値分析を組み合わせ、各境界の前後（2999円・3000円・9999円・10000円）を重点的にテストします。一方、ホワイトボックステストでは実装コードのif文の分岐構造そのものに着目します。仮に実装がif (金額 >= 3000) { if (金額 >= 10000) {20%} else {10%} } else {割引なし}という入れ子の分岐だった場合、命令網羅（C0）は全行を1回は通ればよいため甘く、分岐網羅（C1）は各ifの真偽を最低1回ずつ通る必要があり、条件網羅（C2）はさらに個々の比較演算子の真偽まで意識します。条件網羅を満たしても分岐網羅を自動的には満たさないことがある点が引っかけやすく、複数の条件が&&や||で組み合わさっている判定文では、個々の条件の真偽を網羅しても判定全体の結果が偏ってテストされないケースがあるため、より厳密な検証には複数条件網羅が必要です。設計段階でこの割引ロジックをどう分割するかはモジュール分割の問題であり、「割引率の計算」だけを行う単一目的のモジュールに切り出せば強度（凝集度）が高く、注文処理や在庫管理といった無関係な処理と混在させなければ結合度も低く保てます。

4.3.4この節のまとめ

• 外部設計=利用者視点・内部設計=開発者視点。カプセル化=隠す／継承=引き継ぐ／多相性=同じ呼び方で違う動作
• クラス図=静的構造・シーケンス図=時系列・ユースケース図=外部からの機能の見え方。結合度は低く・強度(凝集度)は高くが良い設計
• ホワイトボックス網羅基準の強さ＝命令<分岐<条件<複数条件。ブラックボックス=同値分割+限界値分析