Software Design

１、序論

　私の教育経歴は、電気工学の設計講座から始まった。別の学科でプログラミングを教えていた同僚の急死により、私はそこで教えるように依頼された。私は、工学とプログラムの設計の教え方の相違点に驚いた。工学では、根拠があり、実質的な数学や科学に基づいて設計方法を教えてきた。工学の講座では、設計する場合、数学と物理学を応用する方法について説明した。対照的に、プログラミングの講義では、私の場合プログラミング言語の文法のような独断的かつ人工的な雑学に多くの時間を使った。設計原理を教えるのではなく、私たちはよい設計であると思われるプログラムを生徒に示してきた。
　しばらくして、私はソフトウェア設計方法が公式化されていなかったので、それが教えられないことがわかった。私たちが自然言語を見に付ける方法で、プログラミングを学習した。学生はプログラムを見て、彼らが見たものと同じ形式でプログラムを書いた。学習した意図的な設計方法より、むしろ「コンピュータのような思考」をし、実行するための命令を書く。
　プログラムは、工学の法則を応用するための機会ではなく、物語を書くことのように表現形式の問題とみなされていた。実際、それらのプログラムをどのように改善するかを生徒に教える試みは、言語の自由を侵すものとしてみられていた。その見解は、今日まだ耳にする。私は、本の書き方を知っている著者に、本の書き方を言うべきではないこと以上に、どのようにプログラムを書くかはいってはいけない。プログラムは他のものの安全性に影響するので、私はその見方は不適切であると考える。エンジニアの仕事は、長い間公を保護するために規制されてきた。

１、GATE

GATEは（次にITの後継者だった)GATの拡張だった。ITは、最初のFORTRAN翻訳機械のうちの一つであるFORTRANSIT翻訳機械で使用された。今日、誰もこれらのツールのうちのどれかを使用しない。また、それらについての知識は、それらに関する講義をとった人々に価値がない。

２、
　私がオランダのアーペルドールンのフィリップス・コンピュータ部門で働いたとき、設計原理が持っている重要性がさらに明らかになった。作り出されるソフトウェア設計の決定に関して多くの論争があった。また、論争の不一致を解決することができる法則はなかった。実際、設計法則の欠如はとても不十分なソフトウェアを設計してしまう原因となる。「汚い」プログラムであると思われるものを確認したとき、同僚がその批判を認めないことがわかった。彼らは、汚いという事が何を意味するか理解できなかった。そして、ソフトウェアが仕事をしている間、どれも容認可能であると思っていた。（つまり、動けばよいと考えていた。）私たちの部長は、上記の言葉（「汚い」プログラム）が何を意味するか説明するように求めた。
　設計についての私の論文は、彼の要請に応える、つまり、他のものが「汚いプログラム」や「スパゲッティ・プログラム」だと考えられる一方、なぜあるソフトウェアが「きれい」や簡単に見えるかを説明するための努力の成果だった。機能性を越えて、重要な問題があることは明らかだった。いくつかのプログラムは、他のものより変更したり、検査したり、再利用することは、はるかに容易である。これらは単に表現形式やセンスの問題ではなく、本当の実質的な関係である。今、「情報隠蔽」として知られている設計法則は、より維持可能なプログラムを作る法則を明確に述べるための成果であった。最初に公式化されたとき、この原理（参考文献や定義なしで本や論文でよく言及されていた事は有名である）は論争の的になっていた。（昔は経験の中で情報隠蔽を理解していて、定義などは分かっていなかった。）評論家は、最もよく知られている論文の議題への批判について説明した。誰もその方法をしなかったので、Parnasは明らかに何について話しているのかわからなかった。しかし、わずか１０年後に教科書では「Parnasは、よいプログラマが行ったことだけを書きとめた」（「新しい発見ではない」という意味）と記述されていた。論理学者は、よいプログラマの背景には、何もないと結論を出すだろう。（これは情報隠蔽には定義がないからである。）　情報隠蔽の原理は、抽象データ型、オブジェクト指向、コンポネント指向のようなより新しい考えが背景にあるが、それはよく理解されずに応用されない。相互インタフェースが絡み合った任意のソフトウェア設計決定は、検査や変更が必要以上に難しくなるということが大学や企業で一般的に分かった。私は、その考えをまったく耳にしていない「ソフトウェア・エンジニア」と呼ばれている人に頻繁に会う。（つまり、情報隠蔽を考慮せずに、曖昧な設計をしてしまうと、検査や変更がしにくくなる。）
　情報隠蔽は、実際非常に理解しにくい。情報隠蔽の初期の例では、KWICインデックス・プログラム原理はその原理を妨害していた。プログラムが標準のアルファベット順の配列規則を使用して、一続きのものを整列させるという事実は、その情報なしで適切に書くことができたモジュールのプログラマに明らかになった。彼らは情報を使用し、それによって重要かつ実質的な速度アップ技術の導入を妨害した。多くの人々がこの例を検討していた一方、ほとんどの人々はこの誤りに気づいていなかった。同じ問題を与えられても、今日のプログラマの大多数は情報隠蔽を適用しようとしないだろう。また、大多数の人々は私の論文の誤りを繰り返し述べようとした。これは情報隠蔽が難しすぎるので、適用することはできないという発言として解釈されてはいけない。設計が不完全な場合でさえ、情報隠蔽に基づく設計は、それがないものよりよくなる。
　情報隠蔽の原理は、非常に多くのテキストの中で述べられている。しかし、それは非常に表面的な方法で扱われる。私はまだそれを最も重要で基本的なソフトウェアの設計原理と考え、学生がソフトウェア設計に関してただ一つのことを研究するなら、その原理を使用する方法を研究すべきであると考える。原理は４０分で説明することができる。しかし、それを使用する方法を習得するために、少なくとも練習に一学期をとる。そのときでさえ、隠すべきだったという仮説を潜在意識的に使用しているかもしれない。

＊Spaghetti Code＊
処理の流れや構造を把握しにくく、修正や機能の追加が困難なプログラム。むやみに制御を(GOTO文などで)他の部分に飛ばしたり、変数の有効範囲を必要以上に広げたりすると、後からプログラムのごく一部を修正したい場合でも、プログラム全体を読み直さないと構造が理解できないという事態に陥る。この様子を、麺が複雑に絡み合い、たった数本の麺を引っ張り出そうとしても全体がついてくるスパゲッティに例えたのがこの言葉である。

３、プログラムファミリーやプロダクトライン
　この収集中の他の論文は、単一でないプログラムファミリーやプロダクトラインを設計することを開発者に気付かせようとした。プログラムファミリーを開発していくなら、それを意識的にしなければならない。そうでなければ、不必要な長期的コストを招くだろう。
　フレッド・ブルックスや同僚が、コンピュータのIBM　S/360について書いた時、彼はファミリー概念を応用するための先駆者の一人だった。それらの考えは、一般的なプログラマのインタフェースを備えたコンピュータファミリーだった。その考えは、ソフトウェアに当てはまり、単なるユーザ・インタフェースでなく、他の共通点を持っているプログラムに当てはまるために一般化することができる。今、専門的な関心が増加し、この考えの適用における実際の企業の成功を示す証拠があるが、企業のプログラマは、コードを作成することの需要の増加の中では、それを無視するように思われる。（つまり、コードを作成する際、インターフェースやファミリー、個別の部分をしっかり考慮しなければならないが、作成ばかりに気を回しすぎて疎かになりがちである。）指導書の唯一の根源はWeissとLaiによる本である。

＊IBM　S/360＊　
IBMのコンピュータは、いくつかのシリーズで成功をおさめたが、それぞれのシリーズごとに上位への互換性を前提としたソフトウェア開発が負担となってきた。そのような複数のシリーズを展開する上での問題を解決したのが、全方位360度すべての業務に適用できることからネーミングされたシステム/360である。これは、単一のアーキテクチャーで、商用計算、科学技術計算およびリアルタイム・アプリケーションに適応できる汎用の機能を提供するものである。S/360アーキテクチャーは、それから30年間続く、S/370、S/390などの汎用コンピュータの基礎を築いた。

４、エラー処理
　多くの実際のプログラムでは、プログラムの小さな部分を除いて、正常な場合に対処するコードがある。多くのコードは望ましくない事象や値を検査し、それを対処することに専念する。プログラムを開発するとともに、この「例外処理」はよく特別な方法で加えられる。その結果、最も構造化したプログラムでさえ「スパゲッティ・プログラム」へ変わる。７０年代にHarald　Wurgesと私は、エラー処理のための系統的なアプローチについて説明した。しかし、困難なフロー制御の問題があるので、このアプローチでは満たされないままだった。それは、エラーが検知されたポインタへ戻すか、制御をほかのところに移動させるかのどちらかをするのに可能なはずだった。私は、多重入力や、多重出力プログラムを正常な状況とみなし始めるまで、よい解決策を見つけることができないと思う。そのときは、各プログラムは単に一つの正常な入力ポインタや出力ポインタを持っているべきだと多くのプログラマは信じ、多くの指導者はそれを教える。エラー反応は、例外的な手順を要求する。その仮説は、質問される価値があるというプログラマの言い伝えである。

５、ソフトウェア検査
　このセクションでは、ソフトウェアの品質保証の難しい問題について扱う。バグはまだソフトウェアの標準（あってしかるべきもの）と考えられている。実際、ACM評議会は、バグのないプログラムを書くことはできないと示した。
　プログラムの正確さの証拠は、30年以上議論されており、理論上可能である。実際、それらは非常にまれで、難しく、努力を要する。これは、研究が実際に必要な範囲のうちの一つである。しかし、近年注目されている傾向があるようだ。私は、今日、実際にある正当性の証明を学生に教えることはできない。彼らは今後、それだけ(プログラムの正当性の証明が不可能なこと)を理解し、適切な状況の中で使用するべきである。
　一方、ソフトウェアの系統的な検査のための実用的な手続きについて記述することは可能である。「分割統治」をするような手続きは、大きな問題を一つ一つ小さな問題に分けて、検査をする、分割統治のやり方を選択しなければならない。そのプロセスは、プログラムの一部や条件でないものが見落とされないという保証を与えるために高度に機械的であるに違いない。あいにく、「検査」は、プログラムが上から下まで読まれる一種の解読内容の集合を示すために、時々使用される。また、多くの重大なエラーを見落とすことは容易である。
　[１，２]で議論された検査方法は、時間を消費し、詳細なドキュメントの作成を必要とする。多くの研究が、それらの有効性の効果を失わず、検査のコストを削減するツールおよび方法を見つけるために必要である。

＊ACM＊　Association for Computing Machineryの略