８．３
フレーズの用途すべての一般的な特性
“階層的構造”
以前にも【２】で議論されたように、“structure（構造）”という語はパーツの収集として表しているそれをシステムの部分的な描出として言及し、そして、いくつかのパーツ間の関係を示している。私達は階層的構造を称することができ、もし関係もしくはパーツ（R（α、β））のペアの断定が私達に以下のことを言うことによってレベルを定義することを認めるなら、
１．レベル０はαのパーツのセットでありそれらはβには存在せず（R（α、β））に存在する、そして、
２． レベル１はαのパーツのセットであり、
a. それらはレベルⅰ－１のβに存在するR（α、β）であり、そして、
b. もしR（α、γ）ならば、そのときγはレベルⅰ－１もしくはそれ以下である。
これは関係Rで可能であるが、ただしRを描いている指図されたグラフにはループが1つもない。
上の定義は最もはっきりしていてほどよく簡単な定義で、それはコンピュータ文学において言葉のすべての使用を包含する。この“私達のオペレーティングシステムには階層型構造がある”という声明はとにかく情報を全く伝えないと提案する。1つのレベルと1つのパーツでどんなシステムでも階層型システムと表現することができ、もっと重要なのは、どんなシステムでもパーツに分けることは可能で、システムには階層型構造があるという関係を考案すること。そのような声明がそもそもどんな情報でも伝えることができる前に、システムがパーツに分けられる方法とその関係の性質は指定されるに違いない。
階層的構造のシステムを生産するための決定は、可能なシステムのクラスを制限するかもしれない。そして、それ故に、望まれた利点と同じくらいの不利を紹介するかもしれない。この論文の残りにおいて、私達はさまざまな定義を“階層型構造”のために紹介するだろう、そしていくらかの利点について言及する、そうすれば制限の不利はこれらの定義によってつけ込むだろう。
８．３．１
階層的プログラム
E．W．Dijkstra教授の論文T.H.E.システムと最新の論文においてプログラミング構造化【３】と【４】は抽象的な機械の使用しているプログラミング層の価値を証明した。私達は次の定義にこの階層的プログラムに挑む。システムのパーツはサブプログラムでまるでそれらが手順だったかのように呼ばれるかもしれない。私たちはそのようなプログラムには指定される目的がそれぞれにあると思う（e.g.,FNO::=もし何もないなら次々と次の奇数を見つけるか、DONEを行使する。）“uses”の関係はPjと呼ばれているUSES（Pi,Pj）iff Piによって定義されるかもしれない、またPjが適切に機能しないなら、Piは不正確だとみなされるだろう。
最後の節で私達は私達の例において、FNOはここに定義されたセンスにおいてDONEを“uses”しないことを意味するつもりだ。FNOの仕事はDONEを行使することだ；DONEの目的と“correctness（正しさ）”はFNOと無関係だ。そのようなcallsを除かないで、それを使うことで私達は階層的においてプログラムが機械より高位になるとみなすことができなかった。トラップが起こった状況のとき、ほとんどの機械にはトラップの能力があるのでソフトウェアroutinesを行使する。“uses”の関係は上記で説明したとレベルと定義する時、サブプログラムのセットに分けられるプログラムは階層的構造化と言えたかもしれない。“abstract machine（抽象的な機械）”の期間は一般的に使われる、なぜならより低いレベルのプログラムとより高いレベルのプログラム間の関係はハードウェアとソフトウェアの間の関係と類似している。少しの所見はここで必要だ。初めに、私達は良いプログラムだけが階層的構造化プログラムと主張しない。次に、私達はサブプログラムに分けられたプログラムは幾分任意であることができる方法を示す。いかなるプログラムのためにも、いくつかの分解されたサブプログラムは階層型構造を見せるかもしれないが、他の分解されたサブプログラムがそれの中にループと図式を示すかもしれない。上記のシンプルな例においてデモを行ったが、それぞれのプログラムの目的の明細は批判的だ。
プログラム構造に関する制限の目的はこの定義によって意味したものが二つある。初めに、呼び出しているプログラムは呼び出されたプログラムの内部労働を無視することができるはずだ；呼び出されたプログラムは呼び出しているプログラムの内部構造について想定を全くするはずがない。そのユーザを呼び出すために呼び出されたプログラムを考慮に入れると、それぞれからこれをもっと難しくするかもしれなく、他から呼び出されることができる状況できちんと働くように計画されなければならないだろう。
2番目の目的は“ease of subsetting（subsettingの容易さ）”と称されるかもしれない。プログラムがこの“program hierarchy（プログラム階層制）”を持っているとき、より低いレベルはいつもより高いレベルが準備できてない時またはそれらのサービスが必要でない時はより高いレベルなしで使われるかもしれない。階層的でないシステムの１つの例はプログラムを作成している“lower level（より低いレベル）”が予定している仕事について情報の保管のために“higher level（高いレベル）”のファイルシステムの使用をした１つだろう。スケジューラーなしで役に立つことがもし何もされなかったら、ファイルシステムを含まなかったシステムの部分集合は1つも存在することができなかった。
ファイルシステム（普通の複合体とソフトウェアの“buggy”の一部）は“virtual machine（仮想機械）”としてのシステムの残りを使っているが開発されることができなかった。階層的構造を提案し、このセクションにおいて再帰的プログラムテクニックの使用の防止を議論する人々のために、私達はサブプログラムへの分解を選択することを利用できる自由を彼らに思い出させる。もしプログラムの部分集合がそこに存在するなら、お互いに再帰的と呼び、私達はグループをこの分析のためのただ一つのプログラムと考えることができ、そしてそれからそれが階層型かどうか調べるために残りの構造体を考慮することができる。システムのできる限り探している部分集合において、私達はただ一つのプログラムとしてこのグループのプログラムを含めるか、排除するかのどちらかである。
もう一つの所見：上記で議論されたことによるレベルへのプログラムの分割の関係は【５】で議論されたようにモジュールへのプログラムの分割への必要なつながりを全く持っていないことをメモして下さい。これはさらに先で遅れて議論される（セクション８．３．６）。