スポンサードリンク

詳細設計とは?

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

詳細設計(プログラム設計)

詳細設計では、内部設計で設計したシステムの各機能をより詳細化し、実際にどのような処理を行ってプログラムを動作させるかを決めていきます。プログラマは詳細設計書を元にプログラムを実装していくため、プログラマに分かりやすい表記で設計していくことが求められます。

インプット アウトプット
  • 内部設計書
  • 機能仕様書
  • データフロー図
  • データベース物理設計書
  • 詳細設計書
  • データベース物理設計書
  • エンティティ定義書
  • ER図

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

正常系処理 プログラムの基本動作を記述する。
異常系処理  プログラムの異常時の処理内容を記述する。例えばログ出力のログの内容、戻り値の内容などを記述する。

異常系処理の考え方

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

予期できる異常

内部設計で想定していないデータなどが入力されてきた場合などの異常を指します。例えば、金額などの0以上の整数を想定したプログラムであるのに、マイナスの値が入力された場合などがこれに該当します。この場合は、プログラムの引数チェック処理などで検出します。引数のほかに、ファイルレイアウト不正、電文レイアウト不正などがあげられます。

予期できない異常

プログラムを実行したときに、実行環境が原因で起きる異常等を指します。ここで言うシステムとは、オペレーション・システム(OS)のことです。例えば、変数のメモリ領域サイズ不足などのシステムコールでの異常(OS依存)や、データベースへの接続の失敗(設定依存)などがあげられます。これらのシステム的な異常は、再現性が低くテストされずに潜在していることがあり、十分注意しなければなりません。

スポンサードリンク


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

判定と処理コスト

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

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

データベース物理設計

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

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

スポンサードリンク