詳細設計を行うことで、プログラミングに必要な仕様を明確化することになります。必要な情報を漏れなく記載し、仕様バグをできるだけ取り除くことが必要です。

プログラムの仕様を記述していくため、プログラミング言語に依存した書き方になりますが、概ね記述すべき内容は決まっています。正常系と異常系の処理フローを記述し、異常時の場合の処理内容を詳しく書きます。処理フローの内容を次に示します。

異常系とはどのような処理なのか、混合する場合がある。ここでは、異常系の考え方について解説します。

業務的な異常なのか、システム的な異常なのかを把握しながら異常系処理を設計する必要があります。システム的な異常であれば、動作環境に原因があるため、OSや環境設定を見直すことで解決することが多いでしょう。すなわち、環境の見直し以外に対応策がなく、プログラムを終了させる必要があります。このような状況に対して処理を再施行しても、効果は非常に低いのです。一方で、業務的な異常処理を設計するときは、内部設計の設計バグの可能性もあり、慎重に設計する必要があります。ファイルレイアウトが不正の場合など、本当にそこでプログラムを異常終了して良いのか、機能の特性を見極めなければなりません。例えば、「不正な入力があった場合でも、運用側で障害回復を期待するのではなく、できるだけアボートせずに機能を満足させる」というような、システムのポリシーを定義することもあります。

処理の正当性を判定するために、戻り値を判定する分岐処理が必要です。これらの判定にかかるコストについて、考慮せずに設計してしまう場合が多いのです。特に、サーバプログラム（デーモン）はシステムに常駐して動き続けます。処理の実行頻度が高いものに関しては、判定の回数が性能問題に直結します。このような状況の回避策としては、判定処理を減らすしかありません。しかし、判定を減らすことはプログラムがコアダンプする可能性もあり、むやみに判定を減らすことは危険です。判定を減らすことができる条件は、異常が起こりえないことが保障されている場合のみです。例えば、データベースで10バイトまでしか扱わないのに、プログラム側でその値を取得したあとに、10バイトを超えているかどうかを判定する必要はありません。このようなデータサイズの検査は定型的に行ってしまうことが多く、無意味な処理が増加する原因です。また、考えられる異常系を起こりえないものとして、判定処理を行わない場合もあります。それはプログラムの制限事項として、そのプログラムの呼び出し側で十分に考慮しなければなりません。制約があるほどプログラム自体がリスクとなるわけで、呼び出し側で制限事項の考慮がされていないままに実装してしまうと、予期しない動作をしてしまう恐れがあります。

プログラムを堅牢に設計するのか、性能重視で設計するのかは、機能の要件に依存します。しかし、性能はマシンスペックを向上させることで、ある程度改善するという観点から、堅牢に設計するほうが安全と言えるでしょう。また、単体テストの作業量を減らすために判定処理を減らそうとすることは、決して行ってはいけません。

内部設計ではデータベース論理設計を行い、データベースの論理モデルを作成します。それを元に、本フェーズでは物理モデルを設計します。具体的には論理モデルの正規化などを行い、データベーステーブルを定義します。詳細設計でプログラムの仕様を決める際に、具体的なデータベース定義が必要になります。そのため、データベース物理設計のほうがプログラム仕様の定義よりも優先度は高いのです。

データベース物理設計では、最終的にエンティティ定義書を作成します。エンティティ定義書はデータベースの定義内容を帳票にしたもので、テーブル名、列名、値の型、列のサイズを表記します。エンティティ定義の設計を支援するツールは非常に多く、Object Browser ER などは代表的なツールです。エンティティ定義の他に、テーブル間の関連を示したER図を作成します。これによってデータの関連を視覚的に把握することが出来るのです。

＞＞　製造とは？