7.6.5　　　循環シフトモジュールの改良

そのような基準の影響を説明することで、第２分割から循環シフトモジュールを考察することができる。Hindsightは今、この定義が必要な情報よりも多くの情報を明らかにすることを提案している。循環シフトのリストの格納や計算方法を慎重に隠している間に、そのリストの順番を指定した。もし、次の（１）から（３）のみ指定すれば、プログラムを効果的に書くことができる。

（１）   循環シフトモジュールの最新の定義で表示されるラインは、全てのテーブルに存在する。

（２）   それらのどれも２度含まれることはない。

（３）   付加された機能は、シフトによって与えられたオリジナルラインと同一のものとして存在する。

　　シフトの順序を定めることにより必要とするよりも多く　　の情報を与えられ、システムのクラスは限定され、不必　　要なので定義を変えることなく構成することができる。　　例えば、アルファベット順に生成された循環シフトシス　　テムを考慮にいれておかないと、ALPHは空で、ITHは簡　　単な独立変数を返す。第2分割でシステムを構築するとき　　にこのようなことをしないことは、明らかに設計ミスと　　して分類される。それぞれのモジュールがシステム停止　　からある設計の決定を隠蔽するという一般的な基準に加　　えて、賢明であるように見えるいくつかの明確な分割の　　例を挙げることが出来る。

１．データ構造。その内部連結、アクセス処理や変更処理は、１つのモジュールの一部である。それらは、習慣的に処理される多くのモジュールで共有されてはいない。この概念は、もしかするとBalzer〔9〕とMealy〔10〕の論文の背景にある前提の苦心の作であろう。この考え方での設計は、はっきりとBLISS〔１１〕の設計の背景にある。

２．与えられたルーチンとルーチン自体を呼び出す必要のある命令配列は、同じモジュールの一部である。この法則は、実験に使われたFORTANシステムと関連はないが、アセンブリ言語で構成されたシステムにとって極めて重要である。現実のマシンにとって完全で一般的な呼び出し配列ではなく、その結果、それらは理想的な連続の研究を続けている時にも変化しがちである。ルーチンにとって責任のあるものへの呼び出しを生成する責務を割り当てることによって、私達はそのような改良をより簡単にし、同じソフトウェア構造においていくつかの明確な連続により適したものにする。

　　　３　．ペレーティングシステムの待ち行列に使われる制御　　ブロックのデータ構造とよく似たプログラムは“control block module”内に隠蔽されなければならない。さまざまなモジュール間で、そのようなデータ配列のインタフェースを作ることは従来のものである。なぜなら、設計の発展は制御ブロックのデータ構造においてしばしば極端な損失をもたらす決定のような変化が起こるからである。

４．字コード、アルファベット配列、そして同類のデータはすばらしい柔軟性を持つためにモジュール内に隠蔽されるべきである。

５．処理されるであろうある項目における連続は、単一のモジュール内に隠蔽されるべきである。オペレーティングシステムにおけるある手段の有効性を付加した技術に囲まれている様々な修正は、極度に変化しやすい配列をつくる。

7.6.6   効率と実行

慎重に行わなければ、第２分割は第１分割よりも効率が悪くなる。もしそれぞれの機能が実際の手の込んだ呼び出し配列の処理として実行されるなら、モジュール間で繰り返し行われる交換のため呼び出しは大量なものになるだろう。第１分割は、この問題で困ることはない。なぜなら、モジュール間での制御が比較的少ないからである。上記でのような利点を得たが、オーバーヘッドと呼ばれる処理の蓄積のためには、独特の方法で実行しなければならない。

多くの場合、ルーチンはアセンブラによってコードに書き込まれるだろう。他の場合、高度に研究され、効率がよい移動が書き込まれるかもしれない。第２分割を上手く効率的に利用することは、機能がサブルーチンであるかのようにプログラムが書かれる必要がある。しかし、特殊な実行はなんでもアセンブリ言語に翻訳される。もしこのような技法が使われたら、モジュール間の独立は、ファイナルコードでははっきりしないだろう。このような理由から、追加されたプログラム修正の特徴はさらに効果的になるだろう。言い換えると、初期に書かれたいくつかのプログラム表記は、それらの間で作られるプログラムに加えてマシンの中で維持されるにちがいない。

7.6.7   同じ言語に対するコンパイラとインタープリタの分割共有

これらの分割基準を設計計画に適応する早期の試みにおいて、私達は〔６〕で説明した表記法で表現されるMarkovアルゴリズムのための翻訳機を構成した。それはコンパイルと言語の解釈可能な翻訳機の間の関係を研究するための概念ではないけれど、私達は理論的なコンパイラと数種類のインタープリタにとって効力のある分割を発見した。コンパイラの各タイプには、深く本質的な違いがあるが、全てに対して適用される早期の分割における絶対的な決定事項に気が付いた。もしコンパイラかインタープリタのいずれかに対するクラシカルラインに沿って責務を分割すると、それは正しくはないだろう。そのかわり、分割は上記の例のように、様々な決定事項の隠蔽に基礎をおく。このように記録表記、アルゴリズムの検査、解釈規則、などは、モジュールやコンパイルと解釈可能な翻訳機両方に存在する問題である。全ての場合に分割が効果的があるだけでなく、ルーチンの多くもある翻訳機械でのわずかな変化にも使われる。この例は、モジュールを作る際に使用されるべきではない陳述に対し付加される支えを供給する。それはある計画から他への仕事の重要な影響の結果として生じる分割の慎重な仕事のさらに進んだ証拠を供給する。このさらに詳細な論文は〔８〕に含まれている。

7.7階層構造

分割２によって定義されたシステムの中に　Dijkstra〔５〕によって例証された観念で階層

プログラムがある。シンボルテーブルが実在するなら、他のモジュールなしでも機能を果たす。それゆえ、それはレベル１である。シンボルテーブルが使われていなかったり、　　　　　　　　　　　　　　　　　　　　　　　　　ライン記憶装置はレベル１である。入力と循環シフトはそれらの機能を果たすためにライン記憶装置が必要である。出力とアルファベット順配列は循環シフトを必要とするが、循環シフトとラインホルダーは観念の中に共存する。アルファベット順にするときか、オリジナルラインか循環シフトのどちらかをプリントアウトするに使われるルーチンのパラメータ表示は簡単に構築されるだろう。第１の処理では循環シフトを必要としない。第２の処理でそれを必要とする。言い換えれば、この設計は階層における２つのレベルのうち一方で実行されるであろうプログラムにとっての単一の表記を持つ。システム構造の討論では、階層構造のよい分割の利益を曖昧にしやすい。モジュールやプログラムと部分的な配列の間の定義される関係なら、階層的構造をもつ。私達が関心のある関係は“uses”や“depends upon”である。あるモジュールが他のモジュールの一部のみに依存する場合にプログラム間の関係を使うことはより好ましい。（例えば、循環シフトがラインホルダーにのみ依存していてSETWORDの現在の仕事には依存しない。）例えば、もしすべてのモジュールが同じレベルにあったら、そのような部分的な配列なしで討論される利益を、得ることができると考えられる。部分的配列が２つの付加利益を与える。一つ目はシステムの一部が利益を得る、なぜならそれらは低いレベルの操作を使うからである。二つ目は上位のレベルを切り離すことができ、使用に適しており、効果的な結果であることである。例えば、シンボルテーブルが他のアプリケーションで使われることができる。ラインホルダーはquestion　answering systemで用いることができる。階層構造の存在は、木の上位のレベルを切り取ることができ、古い幹の上に新しい木を始めることができることを確信する。もし上位のレベルのモジュールを使って、下位のモジュールが作られるシステムを設計すると、階層をもてないだろう。システムの一部を取り去ることは、非常に難しいことがわかる。“レベル”はシステムにおいてあまり重要性がない。階層構造をもたない第1分割のシステムをもつことは考えられるので、私達は階層構造ときれいな分割は独立以外の２つの望ましいシステム構造の財産であると結論を下さなければならない。

7.8　　結論

フローチャートの基礎でモジュール内へのシステムの分割を始めることはたいていいつも不適当であるというこれらの例で証明しようとした。その代わりに私達は難しい設計決定や修正しそうな設計決定のリストを提案する。各モジュールはそのような決定を他のモジュールから隠蔽する設計である。多くの場合、設計計画は実行時間を越えるので、モジュールは処理する際に行程に合わないだろう。効率がよい実行を完成するために、私達はモジュールがひとつもしくは多くのサブルーチンであるという前提を捨てなければならない。そして、その代わりサブルーチンと様々なモジュールからコードの集まりをアセンブリ言語に翻訳するプログラムであると考える。