ronSpace

Educators, generals, dieticians, psychologists, and parents program. Armies, students, and some societies are programmed.

Harold Abelson, Gerald Jay Sussman, Julie Sussman, "Structure and Interpretation of Computer Programs" Second Edition, (MIT Press, 1996)

詳細設計書の読み手は，あくまで人間であって，機械ではないわけですから，当然，曖昧さはあるでしょう．また，曖昧さがなければ意味がないとも言えます．

ひとまず詳細設計書には意味を与えるべきです。機械的実行が可能な表記法を定義し、それに則って記述するべきです。なんなら「詳細設計書を読み込んで実行するプログラム」があれば良いでしょう。

古き悪しき詳細設計書 - SiroKuro Page

事前条件，事後条件（，不変条件）を列挙して，機械に実行させる，というのは，宣言型プログラミング言語が目指すところであるわけでして．形式仕様記述言語¹というのは，そうしたものでしょう． そうした仕様記述から，機械で実行可能なプログラムを作り出すのであれば，詳細設計書を読んでコードを書く人間は不要になりますね．²

詳細設計書に擬似コードを載せる，ということにも，意味はあると思います．そのとおりに実装しろという指示ではなく，あくまで，仕様を理解するための一例とするなら．例えば，コード例がひとつも載っていない，言語仕様， API 仕様， アルゴリズム仕様を読んで理解できるのか，という話です．この場合，コード例が COBOL をベースにした擬似コードでも構わないと思います．

もちろん，仕様が正しいことを，設計者・プログラマの双方が確認できるように，事前条件，事後条件，不変条件を列挙したり，テストケース，テストデータといったものを用意する必要はあるでしょう．

詳細設計書の問題として語られているのは，実は詳細設計書の書き方の問題ではなく，工程が分断されていて，コミュニケーションが一方通行になってしまっている，という問題ではないでしょうか．

詳細設計書というものは，プログラマを「プログラムする」ためのドキュメントと考えます．そうしますと，詳細設計書を入力されたプログラマが，「コンパイル・エラー」をだす可能性は当然あるわけです．この場合，設計書を書いた人間にエラーを知らせて，設計書を修正させなければなりません．

詳細設計書をレビューするのに，最も適した人間は，それを読んでコードを書くプログラマです．プログラマがレビューし，設計書を書いた人間にフィードバックできないのであれば，その設計書の品質は，かなり低いものとならざるを得ないでしょうし，場合によっては無用の長物となるでしょう．

1. 例えば，VDM．　形式仕様記述から，C++ ，Java のコードを自動的に生成する機能がある．

2. SQL ，Prolog がそうであるように，宣言型プログラミング言語は，パフォーマンスの問題を無視できるには至っていない．従って，プログラマを「人間コンパイラ/オプティマイザ」として位置付けるのは，それはそれで一定の意味はある． RISC プロセッサと， C コンパイラが成し遂げたように，機械が自動生成するコードが，人間の書くコードにパフォーマンスで勝る，ということが，この抽象度のレベルで有り得るのかが問題．