学習目標
要求、モデル、設計、テストを別々に暗記せず、「どの要求を、どの設計で満たし、何で確かめるか」で結ぶ。システム開発技術はSAの公式重点分野である。
モデルは答えたい問いで選ぶ
| 図 | 答えたい問い | 注文システムの例 |
|---|---|---|
| ユースケース図 | 外部の主体が何を達成するか | 購入者が注文する、担当者が返金する |
| クラス図 | 何がどのような関係を持つか | 注文と明細、属性、関連、多重度 |
| シーケンス図 | 誰がどの順序でやり取りするか | 在庫照会、引当、決済依頼 |
| 状態機械図 | 出来事に応じて状態がどう変わるか | 未確定→確定→出荷済み→取消不可 |
| アクティビティ図 | 作業・制御がどう流れるか | 検査、条件分岐、並列処理 |
同じ対象でも図は相補的であり、1種類で全てを表す必要はない。クラス図は常にそのまま物理DB表になるわけではない。OMG UML 2.5.1仕様
凝集度と結合度
凝集度はモジュール内部の責務のまとまり、結合度はモジュール間の依存の強さを見る観点。基本方針は、関連の強い処理をまとめ、不要な依存を減らすこと。
| 例 | 起こりやすい問題 | 改善の考え方 |
|---|---|---|
| 注文計算と画面色の設定が同居 | 無関係な変更が同じ部品に集中 | 変更理由の異なる責務を分離 |
| 他モジュールの内部変数を書換え | 内部変更が外へ波及 | 明示した操作や契約でやり取り |
| 大きな共有グローバル領域 | 誰が変更したか追跡しにくい | 所有者と更新経路を限定 |
| 必要な項目だけを引数で渡す | 依存を限定しやすい | 値の意味、制約、エラーを契約化 |
「呼出し回数が少ないほど低結合」「小さく分けるほど高凝集」とは限らない。責務と依存内容で判断する。
要求とテストの対応
図は代表的な対応を示す独自の簡略図。工程名や粒度は開発標準で異なる。重要なのは、対応する要求・仕様からテスト条件を導き、変更時に影響先を追えること。Vモデルの図を使うこと自体は、全作業を一度だけ順番に行うという意味ではない。
解法例
受注数量の有効範囲が1〜100の整数である。境界値分析なら0、1、2、99、100、101が有力なテスト候補。正常範囲の中央だけでは下限・上限の比較演算ミスを見落としやすい。一方、数値でない入力、桁あふれ、空欄などは別の同値クラスや入力条件として考える。境界値を選んだだけで網羅完了とはしない。
品質モデルは版を混ぜない
| 規格 | 製品品質モデル | 過去問での注意 |
|---|---|---|
| ISO/IEC 25010:2011 | 8特性。機能適合性、性能効率性、互換性、使用性、信頼性、セキュリティ、保守性、移植性 | 当時の8特性を現行の数で否定しない |
| ISO/IEC 25010:2023 | 9特性のモデルへ改訂 | 名称・構成の変更がある。単に安全性を足しただけと扱わない |
2011版は利用時品質と製品品質を扱っていたが、2023版は製品品質モデル。ISOは旧版の後継として25002、25010、25019を案内している。JISへの対応と発行年も確認し、問題が指定した規格に従う。ISO 2011版の概要、ISO 2023版の概要
間違えやすい点と確認
- 正常系のテスト成功は例外時の安全性を保証しない。再試行、途中失敗、境界条件も検討する。
- テストで欠陥が見つからないことは、欠陥が存在しない証明ではない。
- 注文状態ごとの許可操作を整理する最適な図は？ → 状態機械図が有効。
- 複数サービス間の呼出し順序を整理したいときは？ → シーケンス図が有効。
出典と適用上の注意
例と図は独自作成。詳細な規格適合を保証する資料ではない。SAの工程・知識の位置付けはIPA SAシラバスVer.5.2参照。