システム設計とソフトウェア設計

要点と定義

システム設計では、システム要件をハードウェア、ソフトウェア、サービス、手作業に振り分け、必要な構成品目を決めます。実現可能性に加え、効率的に運用・保守できるかも考慮します。

ソフトウェア設計では、ソフトウェア要件を基に構造と要素を設計し、要素をソフトウェアユニットまで分割します。各ユニットの機能と、ユニット間の処理手順や関係を明確にします。

過去の出題で扱った補足として、モジュールの独立性を評価するときは、モジュール内のまとまりである結束性と、モジュール間の依存を表す結合度を見ます。必要な単一の値を引数で渡す方法は、データ構造全体や大域的データを共有する方法より、依存する情報を限定しやすい設計です。

過去の出題で扱った補足として、データと関連する操作をまとめ、データの内部表現を外部から隠すと、機能上のまとまりを強められます。同時に使う、処理が順に続く、引数で処理を切り替える、といった理由だけで機能をまとめても、同じ目的に沿うまとまりとは限りません。

設計では品質特性も考慮します。過去の出題で扱った補足として、利用者が操作方法を理解しやすくするオンラインヘルプは使用性に関係し、修正一件当たりの平均時間は保守性を評価する指標の例です。

過去の出題で扱った補足として、アクティビティ図は処理の流れや並行処理を表す図です。クラスの静的な関係や、コンポーネントの物理的な関係を表す図とは用途が異なります。

過去の出題で扱った補足として、汎化は複数の下位概念に共通する性質を上位概念にまとめる関係です。例えば、ペンギンとスズメを鳥の下位概念として整理する関係が汎化です。

過去の出題で扱った補足として、利用者の誤操作や不適切な入力を防いだり、気付きやすくしたりする設計をフールプルーフといいます。

過去の出題で扱った補足として、SOAは業務機能をサービスとして構成し、それらを連携させて業務プロセスを実現するシステムアーキテクチャです。

適用条件と例

例えば、オンライン申込みの設計では、本人確認の定型チェックをソフトウェアに割り当て、例外の判断を担当者の作業にする構成が考えられます。要件に照らし、どの機能をシステムの各要素が担うか、運用や保守ができるかを検討します。

モジュール間で値を渡すときは、受け手が必要とする情報を明確にします。単一の値を引数で渡せるなら、その値だけをやり取りする設計を検討します。データ構造全体が必要な場合は、受け手がどの項目に依存するかを確認します。

品質の改善策は、解決したい困りごとに合わせます。初めて使う人が操作方法をつかみにくい場合は、ヘルプの充実が使用性の改善につながります。修正作業の平均時間を求めるなら、対象とする修正時間の合計を件数で割ります。例えば合計九時間で三件なら、一件当たり三時間です。この値だけで、他の品質特性まで評価できるわけではありません。