システム設計

要点と定義

システム設計では、システム要件をハードウェア、ソフトウェア、サービス、手作業に振り分け、実現に必要な構成品目を決めます。要件を実現できるか、効率的に運用・保守できるか、作業負荷やコストに無理がないかを考慮します。設計案は評価基準に照らし、関係者のレビューで確かめます。

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

機能をどの要素に割り当てるかは、業務効率、作業負荷、コストなどを見て決めます。例えば、頻度の低い例外対応を手作業に割り当てる案も、必要な要件を満たし、運用可能かを評価して選びます。

過去の出題で扱った補足として、UMLのアクティビティ図は活動や処理の流れを表し、分岐や並行処理、同期も表現できます。業務フローの検討では、処理の流れを表す図として選べることが判断に必要です。 オブジェクト図は、ある時点のインスタンスと、その間のリンクを表します。一般的なクラス構造ではなく、個々の実例の関係を確かめるときに使い分けます。

過去の出題で扱った補足として、UMLの多重度は、関連する一方のインスタンスに結び付く反対側のインスタンス数の許容範囲を示します。「0..*」なら0件も複数件も許し、「1..*」なら少なくとも1件必要です。例えば、全ての設備に点検記録が必須なら、設備ごとの記録数の最小値は1です。必須でないなら、0件を許すか業務条件を確認します。 個々のインスタンス間のリンクも、多重度の範囲と照らして妥当性を確認できます。

過去の出題で扱った補足として、モジュール結合度はモジュール間の依存の強さを表します。処理に必要なデータ項目だけを引数で渡す方式は、共有データや相手の動作を制御する情報に依存する方式より、モジュール間の依存を抑えます。受け渡す情報の範囲と、相手の内部状態や制御への依存を確認します。

過去の出題で扱った補足として、SOAは業務システムの機能を独立性のあるサービスとして構成し、必要に応じて連携させる考え方です。業務プロセスを実現する機能の構成や、ソフトウェア間の連携を考える際に関係します。

過去の出題で扱った補足として、フェールソフトは障害発生後に機能や性能を一部制限しながら、運転を続ける設計の考え方です。縮小した構成で運転を継続する案がこれに当たるかは、障害後も運転を続けるかで判断します。

適用条件と例

申請システムを設計する際、通常の申請はソフトウェアで処理し、判断が難しい例外は担当者が確認する案を考えます。例外の頻度、担当者の作業負荷、誤処理時の影響を確認し、機能の割当てが要件と運用条件に合うかを評価します。すべてを自動化することが常に適切とは限りません。

この申請の流れを図にするなら、受付後に申請内容と添付資料を並行して確認し、両方の確認後に承認へ進む、といった処理の順序や同期を表せます。一方、申請者や機能との関係、個々の申請データの状態など、見たい対象が違えば図の選択も変わります。

多重度は業務条件を数の範囲に直して決めます。例えば、全ての設備に点検記録が1件以上必要で、件数の上限が決まっていないなら、設備ごとの記録数は「1..*」です。導入前の設備など記録がまだない状態も扱うなら、最小値を0にできるかを条件に照らして決めます。