システム設計と情報連携

要点と定義

システム設計は、システム要件をハードウェア、ソフトウェア、サービス、手作業などに割り振り、実現に必要な構成品目や処理方式を決める工程です。運用・保守のしやすさ、性能、信頼性、作業負荷や費用も考慮します。ソフトウェア方式設計では、ソフトウェア要件をソフトウェアの最上位構造に変換し、ソフトウェアコンポーネントを識別します。コードの一行ごとまで決める段階とは区別します。

設計では、画面に見える機能だけでなく、データがどこにあり、どの情報を使って処理するかを明確にします。たとえば定期健康診断のコース決定では、従業員の年齢・性別に加え、職位情報の管理職フラグが必要です。実施場所は従業員の現在の在勤地を基に決めるため、従業員情報から現在の在勤地コードを得て、在勤地情報から場所を得ます。再検査でも転勤後の現在地を使うなら、従業員情報と在勤地情報の両方が必要です。必要な値をたどり、値の所在に対応した情報源を選ぶのが設計上の要点です。

データ入力の検査は、検査する性質ごとに考えます。形式チェックは日付や数値の書式、重複チェックは同一値やレコードの重なり、シーケンスチェックは番号などの順序・連続性を確認します。論理チェックは、入力値同士や業務条件との整合性を確認します。たとえば注文日が入力日以前の営業日であるかは、日付の書式ではなく業務上の条件を確かめる論理チェックです。

システムの処理方式は、業務の特性や要件に合わせて決めます。SOAは、ソフトウェアの機能をサービスという部品として扱い、それらを組み合わせてシステムを構築する考え方です。利用するサービスの境界や、サービス間で受け渡す情報を設計する必要があります。

処理の順序、条件分岐、並行処理を表すUML図はアクティビティ図です。業務の手順を活動の流れとして表現できます。ある時点のオブジェクトやその関係、クラスの構造、構成要素の依存関係などを表す図とは役割が異なります。

既存のWeb APIを組み合わせる設計では、画面が必要とする情報と、各APIが返す情報・受け取る識別子を対応付けます。たとえば農産物の検査結果画面に、検査農産物情報、申込者情報、検査結果情報を表示する場合、まず農産物IDで農産物情報を取得し、その情報に含まれる申込者IDで申込者情報を取得します。農産物IDを使って、その農産物の検査結果一式も取得します。結果が複数件でも、一括取得できるAPIなら検査結果ごとの呼出しは不要です。

適用条件と例

入力値の検査では、値の形が正しいかと、値の意味が業務条件に合うかを分けて考えます。例として、注文日が「年月日」の形式で入力されているかを形式チェックし、注文日が入力日以前の営業日かを論理チェックします。形式が正しくても、未来の日付や休日が業務規則に反すれば論理チェックで検出します。営業日の判定には営業日を定める情報が必要です。

マスタやデータベースを参照する処理では、必要な項目から情報源を逆にたどると整理しやすくなります。例として、従業員番号から従業員レコードを引き、職位コードを使って職位情報を参照し、管理職かどうかを得ます。また、従業員レコードの在勤地コードを使って在勤地情報を参照すれば、その場所の健診実施場所が分かります。従業員情報に職位名や実施場所が直接含まれているとは限らないため、参照先も設計に含めます。再検査のコースが前回の定期健診と同じという業務条件なら、コースの決定に職位情報を再利用する必要があるかは、その条件に沿って判断します。