システム設計とレビュー

要点と定義

システム設計では、システム要件をハードウェア、ソフトウェア、サービス、手作業に振り分け、実現に必要な構成品目を決めます。業務効率、作業負荷、費用などを考慮し、要件を実現できるか、効率的に運用・保守できるかも検討します。ソフトウェア設計では、ソフトウェア要件を基に構造や要素を設計し、各要素の機能と要素間の処理やインタフェースを明確にします。

設計の評価では、システム要件との合致や実現可能性を確認します。要求と設計要素を両方向にたどれること、一貫性、運用・保守の実現可能性なども評価基準になります。レビューは、方式・評価基準・参加者を決めて成果物や活動を確認し、その結果を文書に反映する活動です。

レビュー方式は、確認したいことと進め方を手掛かりに区別します。インスペクションでは、対象を絞った問題について複数の視点から分析し、対策につなげます。ウォークスルーでは作成者が資料を説明し、参加者が質問や意見を出しながら確認します。過去の出題で扱った補足として、ラウンドロビンレビューは参加者が順番にレビューを進める方式であり、順番に作業すること自体で経験や知識の差がなくなるわけではありません。利用者によるプロトタイプの確認も、レビューの代わりになるとは限らず、確認できる観点を分けて考えます。

ソフトウェア要素を分割するときは、モジュール内のまとまりである結束性と、モジュール間の依存の強さである結合度を見ます。一般に、関連するデータと操作を一体にし、データの内部表現を外から隠す設計は結束性を高めます。処理の順序や初期化時点だけでまとめる場合とは、まとまりの根拠が異なります。

モジュール間では、必要な単一データを引数で明示して渡すと、データ構造全体を渡す場合や大域データを共有する場合より依存を限定できます。受け手に必要な情報だけを渡せているかを確かめます。

設計図は、表す関係で使い分けます。ユースケース図はアクターとシステム機能の関係、クラス図は構造、ステートチャート図は状態の遷移を表します。過去の出題で扱った補足として、コラボレーション図はオブジェクト間の相互作用を表す図として区別できます。

汎化は、複数の下位概念に共通する性質を上位概念にまとめる関係です。たとえば、複数の会員種別に共通する性質を「会員」にまとめる関係が該当します。「一種である」という上下関係を、部品と全体や属性の関係と混同しないようにします。

過去の出題で扱った補足として、CRUD表は業務機能とデータの関係を、生成・参照・更新・削除の観点で整理する方法です。エンティティごとにどの機能が各操作を担うかを見れば、表の範囲内で操作が示されていない箇所を把握できます。削除が示されていない場合は、誤登録などを解消する機能が不足しているおそれを検討します。ただし、表にない別機能や手作業まで否定するには、表の対象範囲を確認する必要があります。

過去の出題で扱った補足として、フールプルーフは人の誤操作や不適切な入力による誤りを防止・低減する設計です。条件に合わない入力を検出して再入力を促す例があります。故障時に安全な状態へ移る設計や、一部機能を落として運転を続ける設計とは目的が異なります。

過去の出題で扱った補足として、Observerパターンは、あるオブジェクトの状態が変化したとき、依存するオブジェクトへ自動的に通知する仕組みです。既存オブジェクトに機能を動的に加える方法や、インスタンス数を一つに制限する方法とは区別します。

適用条件と例

予約管理システムの設計なら、利用者が行う作業とシステムが処理する機能を整理し、必要な構成やインタフェースを決めます。設計レビューでは、要求と設計要素の対応をたどれるか、設計が要件を満たせるか、運用や保守が可能かなど、あらかじめ定めた基準に沿って確認します。