|
Software
Design
まだ、別の階層はMULTICSシステムで見つけることができます。オペレーティング・システム（スーパーバイザと呼ばれる低レベルおよび次のレベルのユーザ）への従来の2レベルのアプローチは「輪」と呼ばれるスーパーバイザの中の連続したレベルに一般化されました。MULTICSプロセス内のプログラムセットは、内部の輪として知られているより低いレベル、および外部の輪として知られているより高いレベルの階層的構造で組織されている。そのものはプログラムであるが、この関係はセクション１で議論したプログラム階層ではありません。それらの仕事[12]を行うために、方向とより低いレベルのプログラム両方に生じた呼び出しが、より高いレベルのものを使うかもしれません。 あるデータが、他のデータよりシステムの働きがはるかに重大であることや、ある手続きが他の手続きよりシステムの全面的な働きがはるかに重大であるこという特色を設計者は彼らの階層の基本として使ってきた。システムが最も敏感なデータは内部の輪手続きによってコントロールされ、そしてそれらのプログラムへの翻訳はとても注意深くコントロールされている。内部の輪手続きは、外部の輪の中でプログラムとデータに無制限にアクセスします。比較的少数のユーザやhenceに影響するデータおよび手続きを含んだ外部の輪はそれほど“敏感”ではない。階層は、上に使われたような感覚の“感度”を定義することが困難であるとして以来、“アクセス可能である”ということの関連によって最も簡単に定義された。低レベルのものは、逆は真ではなくより高いレベルへの無制限のアクセスを持っています。 “アクセス可能である”という関係の制限を置くことはシステム信頼度およびセキュリティにとって重要であるということは明白である。 しかしながら、“アクセス可能である”という関係が階層であるべきという主張によって、私たちは望まれるかもしれないある入場可能パターンを防ぐことを示唆しています。私たちは、AがBへ、BがCへ、CがAへのアクセスを要求する3つのセグメントを持っているかもしれません。アクセス権が一つであることが必要であり望ましい。もし私たちが“アクセス可能である”ということは階層によって定義されるということを主張したら、私たちは（この場合）Ａ、Ｂ、Ｃをひとつの部分とみなした平凡な階層を使わなければならない。 著者の見地からすれば、“アクセス可能である”という関係のペアの数が最小限にされるべきであるが、彼はそれが階層[13]および[14]を定義するということを主張することに利点を見出しません。 実際のMULTICS制限は階層の要求よりさらに強い。プロセス内では、関係が完全なオーダーであるに違いありません。 8.3.5
Hierarchies and “Top Down”Design Methodology（階層とトップダウンデザイン方法論） T.H.E.システムの働きが現われた時に関して、[15]、[16]、[17]のように“トップダウン”や“アウトサイドイン”を使った設計方法は議論するのに有名になりました。よい設計方法およびよい設計システムを示唆する論文の同時の出現は、T.H.Eシステムが“トップダウン”設計プロセスの結果だったという根拠がないという仮定に結びつきました。より最近の仕事[18]でさえ、トップダウン設計と構造化プログラミングは、ほとんど同義であるとみなされました。 実際に、“アウトサイドイン”は、“トップダウン”より意図されたもののため、はるかによい用語でした。意図されたものは、システムのユーザ・インターフェースの記述から始まり、実行に向けての小さく証明可能なステップで働くことでした。その階層中の“トップ”は、ユーザに見えたシステムのそれらの部分から成りました。“プログラム階層”によって設計されたシステムでは、より低いレベルの機能がより高いレベルの機能によって使用されるでしょう。しかし、それらのうちのいくつかはさらにユーザに見えるかもしれません（例えば、格納と割り当て）。より高いレベルでのある機能はそれ（再起システム）に利用可能ではないかもしれません。私が質問[19]について議論したT.H.E.システムのデザインの関係者は、より高いレベルのデザインをそれらが最初に続けなかったと報告しました。 8.3.6
Hierarchical Structure and Decomposition into Modules（階層構造とモジュール分解） しばしば、あるものは“モジュール” （例えば[5]と[20]の中で概説された目的のような）に分割されるようなシステムを見たがる。この分割は“部分”との関係を定義します。サブ・プログラムの一つのグループはモジュールへ集められ、モジュールのグループはより大きなモジュールへ集められました。このプロセスはグラフが明らかにループフリーである部分との関係を定義します。プログラムまたはモジュールがいくつかのモジュールの一部であることを私たちが認めても、それはループフリーのままである。その部分は全体を含んでいないのです。 単に定義されたモジュール階層はいかなるプログラム階層とのつながりも必要でないため、私たちが1つのモジュール中のプログラムが別のモジュール中のプログラムを呼びだすのを認めてもよいことに注目する。もしあるモジュール中のプログラムが別のものの中のプログラムに関してあまり想定しなければ、モジュール間の再帰呼び出しをさらに許可することはモジュールの分解[5]の目的をくつがえすことはありません。 8.3.7
Levels of Language（言語レベル） それは“高水準言語”や“低水準言語”、この論文の初期のセクションで議論された階層と、暗黙の言語階層との間の関係に関してコメントすることが必要な“言語のレベル”のような表現を聞くことに共通している。もし例えば、より高いレベル言語がプログラム階層中のより高いレベルの抽象的な機械の言語ならば、それはよいでしょう。不運にも、この著者はそのような関係を見つけることができず、それらの表現の使用で意味される階層を定義することができません。懐疑の瞬間にあるものは、関係は“それほど効率的でない”あるいは“より大きな文法を持っている”あるいは、“より大きなコンパイラーを持っている”であると示唆したかもしれません。しかしながら、それらの表現のどれも注文を示唆していませんし、それは用語の使用と完全に一致しています。論文の中で"高水準言語"という表現を使用する次の人が、彼が言及する階層を定義したならば、それはよいでしょう。 8.4
Summary(概略) コンピューター・システムデザイン文学は今、プログラムに階層的構造を課することによりコンピューター・システムの分かりやすさおよび予言を改善するために非常に価値のある提案を含んでいます。この論文は、これらの提案は全く同様の用語に記述されましたが、それらの提案によって意味された構造が必ずしも密接に関連づけられないことを実証しようとしました。各々の提案は独立して理解され評価される(特別のシステムデザイン問題へのその適用可能性のために)に違いない。さらに、私たちは、各々の提案には”非構造的な”設計に対するいくつかの長所がある一方、さらに考慮されるに違いない損失があることを示そうとしました。この論文の主要な目的は、初期の文学を読むものにいくらかの補導を定め、将来の著者が設計方法についての彼らの論文に、より正確な定義を含める方法を示唆することでした。 |
トップページへもどる