JPH10503040A

JPH10503040A - 協働する複雑なシステムを構築するための汎用同時コンフィギュレータ

Info

Publication number: JPH10503040A
Application number: JP8505061A
Authority: JP
Inventors: ドルビー，ナイジェル・アイ; グスリング，トーマス・アール; ネイグル，ティモシー・イー
Original assignee: ユニシス・コーポレイション
Priority date: 1994-07-13
Filing date: 1995-06-30
Publication date: 1998-03-17
Also published as: EP0770239A1; EP0770239B1; WO1996002882A1; DE69505537D1

Abstract

(57)【要約】複数のコンポーネントからなるどのような複雑なシステムについても完全で、正当でかつ最適に近いコンフィギュレーションを発生するための汎用コンフィギュレーションエキスパートシステム（１６）を開示する。本発明によれば、デベロッパ（１０）か特定のコンフィギュレーション問題を解決するためのコンフィギュレータフレームワークを特定する。ユーザ（２６）はカスタマイズされたコンフィギュレータ（１６）を作動させてユーザの要求ならびにシステムの要件および制約に基づきコンフィギュレーションの解答を発生させる。汎用コンフィギュレータは宣言的に構成されるグラフ（２４、３４）および複数の相互作用するパッキングエンジン（３６）を使用する。２つのレベルの、活性度伝播二部グラフ（２４、３４）を構成するコンポーネントおよびそれらの相関関係を表わす知識として使用する。本発明によりいずれの時点においても複数のパッカーエンジン（３６）の相互作用をダイナミックに管理して全コンフィギュレーション問題の適切な部分を選択して作業し、その一方で他のパッキング問題についても考慮することができる。本発明によって、パッキングエンジンにより使用される制約を宣言的に定義する能力が得られ、確実に正しいコンフィギュレーションが得られるようになる。

Description

【発明の詳細な説明】発明：協働する複雑なシステムを構築するための汎用同時コンフィギュレータこの特許文書の開示の一部は、著作権保護の対象ともなる素材を含み得るであろう。発明の背景１．発明の分野この発明は一般に、人工知能（ＡＩ）の「エキスパートシステム」または「知識ベースのシステム」に関する。この発明はより特定的には、知識の表現および複数の対話型パッキングエンジンのために宣言的に構築されるグラフを用いる、複雑なシステムのコンポーネントを構成するためのエキスパートシステムに関する。２．背景情報知識ベースのエキスパートシステムは、人間の知識を用いて、通常は人間の知能を必要とする問題を解決するための、人工知能における１つまたはそれ以上の技術を取り入れたものである。これらのエキスパートシステムはしばしば、ある特定の分野に専門知識を有する人間のやり方を模倣するべく構築されているコンピュータのハードウェア／ソフトウェアの組合せからなる。専門知識は典型的には「知識ベース」と呼ばれるデータベース内に含まれる。知識ベースは生成ルール、意味ネットワーク、フレーム、概念依存グラフ、または知識表現の他のパラダイムからなっていてもよい。エキスパートシステムは、１つまたはそれ以上の推論エンジンを含む。推論エンジンとは、知識ベースと対話して、既存の知識から結果、結論、または判断を発生する論理モジュールである。それはルールインタプリタであってもよいし、または確率推論ネットワークにおけるステート情報を伝播することにより結論に辿りついてもよい。人工知能、知識表現、およびエキスパートシステムの一般的な説明について読者は、ユージン・チャーニアック（Eugene Charniak）およびドルー・マクダーモット（Drew McDermott）著、アディソン・ウェスリー・パブリッシング・カンパニー(Addison Wesley Publishing Company)、１９８５年刊の「人工知能入門（Introduction to Artificial Intelligence）」や、ウィリアム・カウフマン・インコーポレーテッド（William Kaufmann，Inc.）の、アブロン・バー（Avro n Barr）およびエドワード・フェイゲンバウム（Edward Feigenbaum）編「人工知能ハンドブック（Handbook of Artificial Intelligence）」第１巻（１９８１年）および第２巻（１９８２年）、ならびにポール・コーヘン（Paul Cohen）およびエドワード・フェイゲンバウム編の第３巻（１９８２年）や、チャップマン・アンド・ホール・リミテッド／メスエン・ロンドン・リミテッド（Chapman and Hall Ltd./Methuen London Ltd.）、１９８５年のリチャード・フォーサイス（Richard Forsyth）およびクリス・ネイラー（Chris Naylor）著「ヒッチハイカーの人工知能ガイド（The Hitch-Hiker's Guide to Artificial Intelligence）」や、スチュアート・シー・シャピロ（Stuart C．Shapiro）著、ジョン・ワイリー・アンド・サンズ（John Wiley & Sons）刊、１９８７年の「人工知能百科事典（The Encyclope dia of Artificial Intelligence）」などの参考文献に導かれる。知識ベースは１種類または２種類の支援で構築されるだろう。１つの種類はエキスパートとの「インタビュー」を行ない、エキスパートに繰返し情報を求める。それはエキスパートの応答から関連構造をつくり上げる。これらのツールは、専門知識−転送システムと呼ばれる。他方の種類の支援は、熟練した知識のあるエンジニアが知識ベースに容易に情報を付け加える（もしくは情報を削除または修正する）ことができるようにする構造化されたエディタまたは言語である。たとえば、そのようなシステムは、ユーザに、生成ルールのリストを閲覧し、付け加え、または取除くことができ、システムがそのルールのシンタックスをチェックしている。このような能力を提供するいくつかの商業的エキスパートシステム「シェル」が利用可能である。この第２の種類のツールおよび生成ルールフォーマットを用いて比較的単純なエキスパートシステムを効果的に構築することができる。初期のエキスパートシステムは、知識ベースのシステムにおけるＲ１系であった。Ｒ１は、後にＸＣＯＮと称するが、ドメインを特定されたルールベースの問題を解決するエキスパートシステムであって、従来のデータ処理方法を用いて対話することができる。コンピュータシステムの正しいコンフィギュレーションの生成には、何千ものヒューリスティックなルールを適用して十分にさまざまなエンジニアリングコンポーネントとサポートされているコンポーネント間の関係とを補足することが必要である。人間のエキスパートはこれらのルールを適用して可能なコンフィギュレーションを生じることができるが、そのコンフィギュレーションが正しいという保証、すなわちそれが適正に製造でき動作し得るであろう保証はない。さらに、最適なコンフィギュレーションの解答という目標は、いかなる人間の能力をも超えているかもしれない。Ｒ１は顧客の購入オーダを構文解析して、その購入オーダを一貫した完全なものとするためになされなければならないコンポーネントの代用および付加がもしあるならば、何であるかを判断する。Ｒ１は、コンピュータシステムのコンフィギュレーションドメインおよびさまざまなコンフィギュレーションの制約における特異性についてのその知識を用いることによって、ある解答に到達する。カーネギー・メロン大学（Carnegie Mellon University）およびデジタル・イクイップメント・コーポレーション（Digital Equipment Corporation）（ＤＥＣ）により開発されたＲ１システムは、生成システムモデルに基づくものであり、ＯＰＳ−５、すなわち生成システムに特に適したプログラミング言語で書かれている。知識表現としての生成システムの基本的特徴は、基本知識とそれまでの計算結果とを含むグローバルデータベースと、データベース上で動作する１組の生成ルールである。生成ルールはルールの本体と呼ばれる手順および関連のパターンからなる。そのようなシステムにおける推論プロセスは、そのパターンがデータベースの一部に一致するルールが発見され、次にそのルールの本体が実行されるというサイクルからなる。ルールの本体の実行は一般にデータベース内のデータ構造を付加する、削除する、または修正することによりデータベースに変化をもたらす。ＯＰＳ−５は問題解決状態データを記述し、この状態データに一致するルール条件を特定するための単純ではあるが均一な表現方法を提供するものである。しかしながら、ＯＰＳ−５が提供する、事実、関係および不確実性を表わすための構造は少ない。したがって、問題解決のための便利な汎用アーキテクチャを提供するものではない。加えて、ルールのアクションコンポーネントをプログラムするには、ＯＰＳ−５は専門的なプログラミング言語でプログラムコードを書くための知識をもったエンジニアを必要とする。Ｒ１システムにはいくつかの欠点がある。元来、これはＤＥＣによって生産されたＶＡＸ１１／７８０コンピュータシステム専用のものであった。したがってこれは、専門化されたコンフィギュレータであった。その能力は徐々に他のＤＥＣコンピュータシステムにも拡張されているが、その代償としてより多くのルールが付加されている。ルールの数が何千もに膨れ上がるにつれ、システムは遅いものになった。知識ベース内のいくつかのルールは冗長であった。コンフィギュレーション知識はルールベースのものであったため、コンポーネント制約情報はエキスパートによって宣言的な態様で書かれるよりもむしろ、やむを得ず専門知識からコンピュータプログラマによって「ハードコード化」されたルールにおいて実施された。したがって、システムが大きくなっていくにつれ、Ｒ１をさらに向上させることは非常に困難なこととなった。オリジナルのＲ１は対話式ではなかった。ユーザは異なった代替的なコンフィギュレーションを容易にセットアップすることはできなかった。通信ネットワークを構成するためのエキスパートシステムが、ガリス（Galis ）らに発行された米国特許第５，１７５，８００号に開示されている。この発明により、ユーザはコンフィギュレーション知識および要求情報のデータベースを規定し維持することができる。システムは通信ネットワークに対するユーザの要求または要求の変更を確認し、全体的および部分的コンフィギュレーションの努力のためのオプションのエキスパートコンフィギュレーションデータセットを生成する。システムはルールベースであり、埋込まれたルールはネットワーク装置間の正当な接続を特定する。したがって、これはＲ１システムと同じ種類の問題の影響を受けやすい。ガリスらのシステムは専用コンフィギュレータである。これは主に時分割マルチプレクス（ＴＤＭ）装置を含む通信ネットワークのために設計されている。そのマンマシンインタフェースは通信ネットワークのためのコンフィギュレーション判断を下すべくデータおよびコマンドをエンターするようユーザを導く。この発明の専用であるという性質は、通信ネットワークコンフィギュレーションの問題へのその応用を制限している。可変の特性によって説明されてもよい接続されたコンポーネントの集合を設計するためのエキスパートシステムが、クィンテロ（Quintero）らに発行された米国特許第５，２９３，４７９号に開示されている。この発明は知識ベースと推論エンジンとを含む。知識ベースは接続可能なコンポーネントの一定および可変の特性およびこれらのコンポーネントを組合せるためのルールに関する情報を含む。推論エンジンは、コンポーネントをユーザの要求について正当に接続するために、ルールを解釈する。クィンテロらのシステムには、それがルールベースであり、専門化された問題ドメイン（この場合はモジュラファニチャーアセンブリ）に向けられているという、Ｒ１およびガリスらのシステムに類似の欠陥がみられる。いくつかの既存の専用コンフィギュレータは、コンピュータシステムについてのコンフィギュレーション問題を解決するのに異なったアプローチをとっている。ユニシス・コーポレーション（Unisys Corporation）により生産された２２００シリーズのコンピュータシステム専用である１つのシステムは、非常にさまざまな、利用可能であるシステムコンポーネントを表わし、コンポーネントのケーブリング（または「ストリンギング」）問題を解決すべく大部分の反復コードおよび専用データ構造を用いる。ユニシスによって販売されている「Ａ」シリーズのコンピュータシステムのための別のシステムも、コンポーネントを表わすのに標準的な高水準言語で書かれた専用データ構造を用い、これらはコンポーネントのパッキング問題を解決すべく操作される。そのパッキング論理モジュールは、動的なオーダリングなしで予め規定されたシーケンスにおいて実行される。結果として、これは時折非常に貧弱な結果の異常なケースをもたらす。パーソナルコンピュータ（ＰＣ）システムを構成するための第３のシステムは、活性度伝播（spreading activation）ネットワークのコンセプトに基づくものである。このシステムは単純なコンフィギュレーションについては効果的に働くが、複雑度のレベルが高くなると、活性度伝播ネットワークは適正に処理されるには余りにも入り組んだものとなってしまう。上述のアプローチの各々には、コンポーネントが接続され得るやり方を変更する、可能なシステムコンポーネントを付加するまたは削除する、またはコンピュータシステムの他のモデルをサポートするために大きなプログラムコード修正を必要とする。オブジェクト志向設計の方法論に基づくプロダクトコンフィギュレータツールは、トリロジー・デベロップメント・グループ（Trilogy Development Group）から商業的に入手可能である。「セールズビルダー（SalesBuilder）」と呼ばれるトリロジーのコンフィギュレータでは、構成されるべき各部分またはコンポーネントはソフトウェアオブジェクトによって表わされる。したがってこのシステムにおける知識はオブジェクトベースのものであって、ルールベースではない。トリロジーシステムは根底にある構造化クエリ言語（ＳＱＬ）データベースマネージャを用いてカスタマイズされたプロダクトコンフィギュレーションシステムを発展させ、これはその後ある会社によってセールスおよびマーケティングの道具として用いられる。このシステムはオブジェクトのヒエラルキーおよびクラス継承の利用可能な特性を利用するため、Ｃ＋＋プログラミング言語で実現されている。オブジェクト志向の設計によるアプローチは、ＰＣのためのものなど、比較的小さいコンフィギュレーションの問題に対しては良好に働くが、大きいメインフレームのコンピュータシステムに固有の複雑なコンフィギュレーションにとっては不十分である。コンフィギュレーションの問題についてのさまざまなレベルの複雑性を管理するには、融通性のある汎用のコンフィギュレータが必要である。数多くの相互に接続された部分からなるたくさんの製品が、その生産のセットおよびパッケージングの中で連続的な変化を被る。生産ラインの流れの一定した状態に遅れないようにすることは、多くのユーザにとって困難かつ時間のかかる課題である。しばしば特殊なデータベースを用いる専用エキスパートシステムは、このコンフィギュレーションの問題に部分的には対処することができるが、時折明らかに順最適である、または全体的な問題のサブセットに限定される結果を生ずる。そのようなシステムはまた、大きな維持の課題をもたらすものでもある。したがって、汎用コンフィギュレータは簡単に定義され変更されるはずである。これまでに設置されたコンフィギュレーションはしばしば寿命が長いが、それでも特定の製品の顧客は現在製造されているかもしれないし、されていないかもしれない交換コンポーネントを時々必要とする。よって、コンフィギュレータは古い受け継がれたコンポーネントに備えるための経歴データをサポートしなければならない。通常コンフィギュレータのユーザ間で専門知識は広く多様なので、コンフィギュレータは経験を積んだユーザのための「手動」制御と初心者のユーザのための自動モードとを提供できるべきである。最後に、コンフィギュレーション問題の著しい複雑性は、人間が適切かつ効率的に解答するには複雑過ぎるような問題に対する自動的な解答を要求するかもしれない。発明の概要この発明の目的は、多くの相互接続されたコンポーネントからなる複雑なシステムの完全な、最適に近い正当なコンフィギュレーションを発生することである。本発明の他の目的は、複雑なコンピュータシステムのための完全な、最適に近い正当なコンフィギュレーションを発生することである。この発明のさらに他の目的は、複数の相互接続されたコンポーネントからなるさまざまな複雑なシステムのためのコンフィギュレーション問題を解決するために容易に特殊化される、汎用コンフィギュレータを提供することである。本発明の他の目的は、さまざまなコンピュータシステムについてのコンフィギュレーション問題を解決するべく簡単に特殊化される汎用コンフィギュレータを提供することである。本発明のさらに他の目的は、既存のパッキングベースであり、かつネットワークベースの情報処理システムのコンフィギュレータを、汎用の包括的なコンフィギュレータエキスパートシステムに統合し、それによって要求される機能性の完全な範囲を均一にサポートすることである。この発明のさらに他の目的は、既存のコンフィギュレータエキスパートシステムよりも簡単に特殊化され、修正され、かつ維持される汎用コンフィギュレータを提供することである。本発明のさらに他の目的は、複数のコンポーネントのパッキング問題が相互に関連したとき、所与のどの時点においても、対処すべき総合的なコンフィギュレーション問題における最も適切なピースを動的かつ自動的に選択することである。この発明のさらに他の目的は、そのユーザインタフェースに融通性があり、使用が簡単であり、コンフィギュレータ内部のコンフィギュレーションロジックから独立している汎用コンフィギュレータを提供することである。この発明のさらなる目的は、複雑なシステム内のさまざまなコンポーネントがどのように接続されてもよいかをそれで規定するための宣言的言語を備えるコンフィギュレータデベロッパを提供することである。この発明のさらなる目的は、コンフィギュレータデベロッパがコンポーネントの組合せに対する制約を宣言的に規定し、コンフィギュレーションプロセスによる結果が確実に正しいものとなるようにする能力を提供することである。本発明の他の目的は、コンピュータシステムコンポーネントの自動コンフィギュレーションをサポートするためのコンフィギュレーション知識の効率的な根底にあるランタイム表現を与えることである。この発明のさらに他の目的は、コンフィギュレータエキスパートシステムによって構成されるべきコンポーネントの宣言的な記述として２レベルで二部の活性度伝播グラフを用い、使いやすさを高め、コンフィギュレータの応用性の範囲を広げ、かつ維持コストを最低限にすることである。この発明のさらに他の目的は、コンフィギュレーション知識のセーブおよびロードをサポートすることである。この発明のさらなる目的、利点および新規な特徴は、部分的にはこれ以降の説明で述べられ、部分的には以下を検討すれば当業者には明らかとなり、またはこの発明の実施から学びとられるであろう。この発明の目的および利点は、図面および好ましい実施例の説明で特定的に指摘されている方便および組合せによって実現され達成されてもよく、発明の範囲および局面は、後の請求の範囲において規定されている。本発明に従い、前述および他の目的および利点は、宣言的に構築されたグラフおよび複数の対話型パッカーを用いる汎用コンフィギュレータにより達成される。この発明は、汎用コンフィギュレーションツールを構築するのに要求される基本的な処理および表現を実現するものである。本発明によって提供される汎用の能力がなければ、広範囲なタイプのアセンブリのためにコンフィギュレーションプロセスの簡単な定義を許容し、かつコンフィギュレーションの詳細に対する手動制御とユーザが制御しないことを選択したいかなる細部に対する自動的な取扱いとが双方ともできる汎用対話型コンフィギュレータを構築することは極めて難しい。本発明は二部グラフおよび関連のシンタックスを用いて、所与のコンフィギュレーションプロセスの一部であるコンポーネントを記述するため、およびユーザによってなされた詳細なコンフィギュレーションリクエストをたどるために、よく構造化され統合されたやり方を提供する。ここに開示されるコンフィギュレータは、パッキングを必要とする各コンポーネントについて個々のパッキングオブジェクトの明示的な別個の表現を用いる。これらのパッカーが広範でさまざまな環境の下で正当かつ最適に近いコンフィギュレーションを生成するべく建設的に対話することを許容する、一般的制御パラダイムが示される。このアプローチは、パッキングプロセスの固定されたシーケンスが行なわれる、以前の状況からは著しい進歩となるものである。本発明はまた、コンフィギュレーションの正当性を規定する制約パラメータを特定するための式文法をも開示する。これらの制約式を扱うための埋込まれた機能性により、コンフィギュレータエキスパートシステムの発展および維持プロセスが向上する。この発明の１つの局面に従い、接続されたコンポーネントの有効なコンフィギュレーションを発生するためのエキスパートシステムは、（コンフィギュレータデベロッパとして知られる）システムデベロッパにより宣言的に特定されたコンポーネント定義をストアするためのアプリオリデータベースを含む。インスタンスデータベースは、（コンフィギュレータユーザとして知られる）エキスパートシステムのユーザにより対話的に選択されるアプリオリデータベース内で規定されたコンポーネントのインスタンスをストアするために設けられる。エキスパートシステムはコンフィギュレータユーザからのリクエストを受け入れて選択されたコンポーネントを構成かつ接続し、リクエストをアプリオリデータベース内にストアされたコンポーネント定義と一致させ、インスタンスの創出および接続が有効であれば選択されたコンポーネントのインスタンスを創出し接続する。有効性のチェックはアプリオリデータベース内のコンポーネント定義と、既に処理されている以前のコンフィギュレータユーザのリクエストとに基づく。インスタンスデータベースは、コンフィギュレータユーザのリクエストの実現の結果もたらされる有効コンフィギュレーションの表現である。処理ユニットはこの有効コンフィギュレーションをグラフィカルユーザインタフェースを介してコンフィギュレータユーザに報告する。この発明の他の局面に従い、各コンポーネントがコンポーネント定義によって記述され得る、接続されたコンポーネントの完全かつ有効な、最適に近いコンフィギュレーションを発生する方法は、コンフィギュレータデベロッパがコンポーネントを宣言的に規定できるようにするステップと、コンポーネント定義および第１の活性度伝播２部グラフにおけるそれらのノードとしての使用により含意されるリソースを表わすステップと、コンフィギュレータユーザからの、選択されたコンポーネントを構成し接続するリクエストを受け入れるステップとを含む。方法の最後のステップは、コンポーネント定義、以前のコンフィギュレータユーザのリクエスト、および第２の二部グラフの現在の状態に基づきインスタンスの創出および接続が有効であれば、選択されたコンポーネントのインスタンスおよび第１の活性度伝播二部グラフにおいて第２の二部グラフ中のノードとして規定されたリソースを創出し、接続することに関わる。この発明の他の局面に従い、接続されたコンポーネントの完全かつ有効な最適に近いコンフィギュレーションを発生するためのコンフィギュレータエキスパートシステムが開示される。コンフィギュレータエキスパートシステムはコンフィギュレータデベロッパによって所与のコンフィギュレーションドメイン用にカスタマイズされ、コンフィギュレータユーザによって、ユーザリクエストならびにコンポーネント定義に含まれる予め定められたコンポーネント要求および接続の制約に基づきコンフィギュレーション解答を発生するべく動作させられる。コンフィギュレータエキスパートシステムはコンフィギュレータデベロッパによって宣言的に特定されたコンポーネント定義をストアするためのアプリオリデータベースと、コンフィギュレータユーザによって対話的に選択されたアプリオリデータベース内で定義されたコンポーネントのインスタンスをストアするためのインスタンスデータベースとを有する。選択されたコンポーネントを創出かつ接続すべくコンフィギュレータからのリクエストを受入れ、アプリオリデータベース内にストアされたコンポーネント定義にリクエストを一致させ、コンポーネント定義および以前のコンフィギュレータユーザのリクエストに基づき創出および接続が有効であればインスタンスデータベース内の選択されたコンポーネントのインスタンスを創出かつ接続し、コンフィギュレータユーザにリクエストからもたらされたコンフィギュレーションを報告するためにロジックエンジンが設けられる。エキスパートシステムは、ロジックエンジンにより参照されるパッカー定義知識ベースを含む。これはアプリオリデータベース内のアイテムに付与されてもよいコンフィギュレーションパッキング動作のタイプに関連する知識をストアする。また、１つまたはそれ以上の制約式においてコンフィギュレータデベロッパにより宣言的に特定された基準に従い、選択されたコンポーネントを他の選択されたコンポーネントに接続する複数パッキング動作を同時に行なうための、パッキングエンジンも含まれる。これらの制約式は、アプリオリデータベース内のアイテムに付される。この発明の他の局面に従い、各コンポーネントがコンポーネント定義により記述され得る、複数の対話型パッカーを用いることにより接続されたコンポーネントの完全かつ有効な最適に近いコンフィギュレーションを発生する方法は、コンフィギュレータデベロッパが宣言的にコンポーネントを定義できるようにするステップと、コンポーネント定義およびそれらを第１の活性度伝播二部グラフにおいてノードとして用いることにより含意されるリソースを表わすステップと、第１の活性度伝播二部グラフにおける選択されたノードにパッカーを付与するステップとを含む。さらなるステップは、コンフィギュレータユーザから選択されたコンポーネントを接続するリクエストを受入れるステップと、選択されたパッカーのセットの各々に従いリクエストを実現するための最重要アクションを識別するステップと、各選択されたパッカーについての最重要アクションに数値的な重みを割当て、各選択されたパッカーに対して最重要アクションがどれほど望ましく、どれほど制約されているかを表わすステップとを含む。プロセスは、選択されたパッカーにより割当てられた数値的な重みを比較して、選択されたコンポーネントのインスタンスと、第１の活性度伝播二部グラフにおいて第２の活性度伝播二部グラフ内のノードとして定義されたリソースとを創出し接続することにより最重要アクションを仮に行なうべく選択されたパッカーの１つを選択するステップで続行する。方法は、パッカーの総合的なセットの各々に従い、第２の二部グラフにより表わされたコンフィギュレーションが有効であるかどうかを判断するステップと、パッカーのセットの各々が最重要アクションの実現を肯定するならば恒常的である最重要アクションの実現の結果として起こる第２の二部グラフにおける変化をもたらすステップとで続行される。最後に、リクエストからもたらされた第２の二部グラフにより表わされるコンフィギュレーションは、コンフィギュレータユーザに報告される。本発明のさらに他の目的および利点は、次に述べる詳細な説明から当業者には容易に明らかとなるであろう。ここにはこの発明の好ましい実施例のみが単に発明を実施するのに企図されるベストモードを説明するためだけに示され記載されている。認識されるであろうように、この発明は他の異なった実施例が可能であり、そのいくつかの詳細はさまざまな明らかな点において修正が、すべてこの発明から逸脱することなく可能である。したがって、図面および明細書は本質的に説明的なものであって限定的なものではないと考えられるべきであり、特許により保護されることが意図されるものは後の請求の範囲に述べられている。図面の簡単な説明図１は、本発明の主要な論理コンポーネントを示すブロック図である。図２は、あるアイテムのための外部形式の基本的シンタックスの図である。図３は、外部形式の記述の一例である。図４は、外部形式の例から結果として生じたアプリオリグラフの図である。図５は、インスタンスグラフの図である。図６は、外部形式のロードプロセスのフローチャートである。図７は、個々のパッカー処理ステップのフロー図である。図８は、パッカーの４つの部分を表わすブロック図である。図９は、マスタスケジューラとパッカーとの間の関係を表わすブロック図である。図１０は、コンフィギュレータ式ハンドラによりサポートされるデータタイプのブロック図である。図１１は、式ハンドラによりサポートされる機能のブロック図である。図１２は、データエントリ形式の表示の一例である。図１３は、ユーザ／インタフェースエンジンの対話を表わすブロック図である。好ましい実施例の説明目次Ｉ．本発明の概観ＩＩ．２レベル二部グラフＩＩＩ．単純な例ＩＶ．知識ベース定義Ａ．ネット定義Ｂ．パッカー定義Ｖ．ローダＶＩ．ロジックエンジンＶＩＩ．パッキングエンジンＡ．パッカー処理Ｂ．選択プロポーザＣ．割当プロポーザＤ．コンサルタントＥ．インプリメンタＦ．マスタスケジューラＧ．パッキング例ＶＩＩＩ．制約式および式ハンドラＡ．制約式の例Ｂ．式ハンドラによりサポートされるファンクションＩＸ．インタフェースエンジンＡ．データエントリ形式Ｂ．カプセルＸ．不変情報付録Ａ．外部形式シンタックスの定義付録Ｂ．外部形式の例付録Ｃ．用語集Ａ．本発明の概観本発明の好ましい実施例は、複雑なコンピュータシステムのコンフィギュレーション問題を解決するための汎用フレームワークを提供する。代替的には、ここで実施されるコンセプトはさまざまなコンポーネントアセンブリおよびシステム定義の問題を解決するために当業者によって用いられることができるだろう。ここに開示されるコンフィギュレータおよび関連のコンフィギュレーション指定言語の一般的な性質は、複数の相互接続されたコンポーネントからなるどのような製品についてのコンフィギュレーション問題をも解決するための基礎を提供する。この発明の最初の実現例は、コモンＬＩＳＰプログラミング言語で書かれた。この実現例は、インテリコープ・インコーポレーテッド（Intellicorp，Incorporated）から商業的に入手可能な知識エンジニアリング環境（ＫＥＥ）と呼ばれるエキスパートシステムシェルを利用する。しかしながら、本発明で実施するコンセプトは、Ｃ＋＋などの他の象徴的またはオブジェクト志向言語で実現することもできるし、マイクロソフト・コーポレーション（Microsoft Corporation）によるウィンドウズ（WINDOWS）などの他のオペレーティングシステムを利用することもできるであろうし、広範かつさまざまなプロセッサによって実行することもできるであろう。本システムの根底にあるＡＩパラダイムは、２レベルの二部グラフである。このグラフはコンフィギュレーション情報を表わすのに用いられる。グラフはコンポーネントおよび関係のネットワークとして規定される。これは宣言的シンタックス、すなわち定義がプロセスとの関連ではなくむしろ状態との関連で与えられるシンタックスの形式で規定される。これにより、コンフィギュレータデベロッパはあるコンフィギュレーション問題を解決するために順次的なステップの論理を規定しなくともよくなる。システムのコンポーネントが構成され定義される際、これらのコンポーネントのインスタンスがグラフの第２レベルにおいて創出される。定義されているコンポーネントの要求および値は、グラフの第１レベルを介して流れる。本システムにおいてグラフの第１のレベルが用いられる態様は、意味ネットワークのための活性度伝播のコンセプトに似ている。活性度伝播は、処理がグラフ中の何らかのノードで始まり、そこから開始ノードへアークによって直接接続されているノードへ移行し、そしてそこから直接接続されたノードの次のセットへ移行する、というような制御パラダイムである。意味ネットワークでは、ネットワーク内の各ノードは通常それに何らかの機能的処理が付されており、これはネットワークを介して論理制御が流れるにつれ、「発火する」（すなわち処理を行なう）。しかしながら本システムでは、グラフの第１レベルのノードには必ずしも機能的処理が付されていなくともよい。さらに、グラフの第１のレベルにおける伝播は、厳密に制御されている。本システムにおける知識の表現は、他の多くのエキスパートシステムでのようにルールに基づくものではなく、二部グラフに基づいている。ルールベースのシステムパラダイムは比較的単純な問題ドメインについては満足のいくものであるが、コンピュータシステムコンフィギュレーションなどの大きく複雑な問題ドメインについては急速に用をなさなくなる。しかしながら、二部グラフは大きいコンフィギュレーション問題にも小さいコンフィギュレーション問題にも等しく良好に作用する。図１は本発明の主要な論理コンポーネントを示すブロック図である。コンフィギュレーションシステムデベロッパ１０は、コンフィギュレータ定義情報（ＣＯＮＦＩＧＤＥＦ）１２を参照し、それをコンフィギュレータシステム１６に入力することによって、コンピュータシステムの所与のセットに利用可能なコンフィギュレーションアイテムおよびリソースを定義する。好ましい実施例では、デベロッパ１０は特定のコンピュータシステムの利用可能な装置およびコンポーネントのためにコンフィギュレータ１０の特定的な実現例をつくり出すべく新しい専用言語を用いる。代替的には、デベロッパは通信ネットワーク、輸送システムなどの、多くのコンポーネントからなる他の複雑なシステムを記述することもできるだろう。コンフィギュレータ定義１２は、問題ドメインに関しての情報を含む。たとえば、コンピュータシステムのコンフィギュレーション問題ドメインでは、コンフィギュレータ定義はキャビネット、バックプレイン、入力／出力（Ｉ／Ｏ）チャネル、電源、周辺装置等の利用可能なシステムコンポーネントに対する情報に加えて、これらのコンポーネントを相互接続するための要求、およびそれらの使用に対する制限の情報を含む。この情報はデベロッパ１０によってテキストベースの外部形式１８にエンターされる。コンフィギュレータ定義１２はデベロッパによって宣言的に定義されており、かつ外部形式ファイル内にストアされていることに注意されたい。デベロッパ１０は、いかなる利用可能なテキストエディタコンピュータプログラムを用いてでもこのファイルを編集することによって、コンフィギュレータの定義を簡単に変更することができるであろう。新しいコンポーネントが利用可能になったり、古いコンポーネントがリタイアさせられたり、または既存のコンポーネント間の関係が改定されたりした場合に、コンフィギュレータ１６を再プログラミングする必要はない。したがって、本システムの維持は、大きいルールベースのエキスパートシステムの維持よりも著しく容易である。コンフィギュレータは知識ベース１９と呼ばれるデータベースを含む。知識ベース１９の内容が、コンフィギュレータによって操作されてもよい構築のタイプを規定する。知識ベース１９は２つの別個になったデータベースを含む。第１のものはネット定義（ＮＥＴＤＥＦ）２０である。ネット定義は外部形式１８にどのタイプのオブジェクトが表わされてもよいかを定義する。第２のデータベースは、パッカー定義（ＰＡＣＫＥＲＤＥＦ）２１である。パッカー定義は、外部形式１８内でどのタイプのパッキング論理オブジェクトが参照されてもよいかを定義する。知識ベース１９に関するさらなる詳細は、セクションＩＶにおいて後述される。外部形式１８はローダモジュール２２によって構文解析され、「アプリオリ」グラフ２４と呼ばれるグラフベースの内部形式に翻訳される。コンフィギュレータ１６は次にエンドユーザに受け渡される。外部形式がエンドユーザに受け渡されるのは、彼らが可能なコンフィギュレーションを修正できるようにするためでもある。続いて、コンフィギュレータユーザ２６は入力装置１４を介してコンフィギュレータ１６の処理を開始する。ユーザ２６はコンフィギュレータ１６を動作させて、このコンフィギュレータによってサポートされるコンピュータシステム（またはデベロッパによって定義される他の複雑なシステム）についての特定的なコンフィギュレーション問題に対する解答を発生させる。インタフェースエンジン２８が、構成すべきコンポーネントを選択するためにディスプレイ３０上にグラフィカルユーザインタフェース（ＧＵＩ）を提供する。インタフェースエンジン２８は入力装置１４を介してユーザ入力選択を受け入れ、結果としてもたらされたシステムコンフィギュレーション情報およびステータスをディスプレイ３０上に表示する。入力装置１４はキーボード、マウス、またはユーザから入力を得るための他の適切な装置であってよい。インタフェースエンジン２８は、ロジックエンジンモジュール３２に、現在のコンフィギュレーションのための選択されたシステムコンポーネントのインスタンスをつくり出し相互に接続するよう指示する。インスタンスとは、アプリオリグラフ２４内に存在するコンポーネントの特定化されたコピーである。この文脈におけるコンポーネントは、オーダされなければならない、および／またはコンフィギュレーションプロセスに影響を与える識別可能なオブジェクト（これはしばしば１つのハードウェアである）である。完成されたコンフィギュレーションは、ユーザのリクエストと、それに加えてそれらの相互接続を満足させるのに必要なコンポーネントの集合からなる。ロジックエンジン３２は、インスタンスから作られたグラフ（インスタンスグラフ）３４を創出する。アプリオリグラフ２４内の情報は各選択されたコンポーネントのインスタンスを生じるためのテンプレートとして用いられる。インスタンスのセットおよびその相互接続は、コンフィギュレーションの現在の状態を定義する。各ユーザ選択がなされると、それによりコンフィギュレーションにコンポーネントが付加され、ロジックエンジン３２がグラフ内の要求される値を伝播させる。すなわち、ロジックエンジンは新たに修正されたアプリオリグラフ２４を考察し、ここまでで処理されたユーザのコンポーネント選択およびそれらに付随する暗黙の制限に基づくコンフィギュレーション問題に対する解答を見つけ出そうとする。伝播は「パッキング」ノードと呼ばれるグラフ内の何らかのノードで立ち往生する。パッキングノードは、グラフ内の異なったノードについての制約が相互に関連しているため、正確にコンフィギュレーション問題を解決するためには、処理されるべき付加的な論理を必要とする。パッキングエンジン３６はこれらの対立を解決して解答にたどり着く。これは再検討のためインタフェースエンジン２８によってユーザ２６に戻るよう提示される。パッキングエンジン３６およびロジックエンジン３２は、アプリオリグラフ２４のノードに特定的な制約または他の式を評価する際に式ハンドラ３７の能力を利用する。この伝播およびパッキングプロセスからもたらされるコンフィギュレーションは、最適なものに近い。これはコンフィギュレータ１６が選択されたコンポーネントの使用にあたっての可能なすべてのデベロッパにより定義された制約を評定することによって解答にたどり着いているため、アセンブルされたときには動作が保証されているという点においては満足のいくものである。解答は理想的なものではないかもしれないが、明らかな問題点はすべて回避するものであり、ほとんどの人間が容易に達成できるであろうよりも一般的に優れている。ＩＩ．２レベルの二部グラフ二部グラフは、コンフィギュレータ１６における知識を表わすために用いられる。グラフはアークによって相互接続されたノードのネットワークである。本発明の好ましい実施例では、これらのアークは双方向性である。グラフはコンフィギュレータの定義と特定のコンフィギュレーションとの双方に関連するすべての情報のための一次的記憶メカニズム（すなわちデータ構造）である。本システムでは、ノードは長方形または長円形の図形で示されており、アークはそれらを接続する線として示される。「二部」は、どのアークも１つのタイプのノードを他のタイプのノードに結合するように、グラフ内に２つの異なる種類のノードがあることを意味する。複雑なコンフィギュレーションは、他のコンポーネントの能力を供給および／または消費するコンポーネントとの関連で大いに特定可能である。これらのコンポーネントはさまざまな態様で互いにリンクされ、コンフィギュレータ論理と現在のコンフィギュレーションとを双方とも表わすグラフを形成する。二部グラフを用いることで、付随の「制約式」を伴う「アイテム」および「リソース」のネットワークにより特徴づけられるコンフィギュレーション問題の図がもたらされる。アイテムとは、コンポーネントを表わすグラフ中のノードである。リソースとは、それ自体はコンポーネントではないがコンポーネントのコンフィギュレーションに影響を与えるアイテムにより供給または消費される能力である。アイテムは構成可能なアセンブリにおける特定的な特徴を提供する物理的コンポーネントであって、一般に他のアイテムのサポートに、これら他のアイテムが、前のアイテムが必要とする、または提供するリソースの量のいくらかを供給または消費するという点において、依存する。たとえば、デジタルコンピュータシステムを構成する際には、カードケージ（アイテム）が、カード（アイテム）が中に差し込まれ得るいくつかのスロット（リソース）を提供する。したがって、二部グラフは供給／消費依存度および量を反映すべく相互接続された交互のアイテムおよびリソースからなる。これらのアイテムおよびリソースが、ソフトウェア用語でいう「オブジェクト」として実現される。これらは名前を有しており、それらが直接関連している他のオブジェクトの名前を指定することによって共に接続される。アイテムおよびリソースは双方とも、局所的な関心の対象となる値を識別する特性を有する。２レベルのグラフを用いることで、コンフィギュレータ１６の定義は特定のコンフィギュレーションの内容から区分され、一方で２組の情報間の一貫性が維持される。第１のレベルでは、各アイテムまたはリソースにグラフのデベロッパ１０により一意的な名前が与えられる。このグラフはデベロッパによって、主として存在すべきアイテムを明示的に特定し、かつそれらを接続するリソースを明示的または暗示的に特定することによって、宣言的シンタックスでつくられ得る。アイテムおよびリソースは、専門化されたローカル情報を付与するのに用いられ得る関連の変更可能な値を備える名前であるプロパティをも有していてよく、アイテムは単純な供給／消費との関連で表わされ得るよりも複雑な関係を定義する制約式を含むことができる。制約式はアイテムおよびリソースの名前のみを参照するファンクションの文法を用いて書かれる。制約はコンポーネントがそれで構成され得る一般性に対する制限である。単一の制約がいくつかのコンポーネントに関わっていてもよく、単一のコンポーネントがいくつかの制約を有していてもよく、１つまたはそれ以上のコンポーネントに対する複数の制約が、複雑なやり方で相互に作用し得る。制約はインスタンスグラフ３４上のユーザのリクエストのインパクトの有効性を判断するためにパッキングエンジン３６によって用いられる。文法とは、言語の要素がどのように組合せられ得るかを規定する１組のルールである。式文法は原始的な値およびファンクションがどのようにして正当な式になるように組合せられ得るかを規定する。宣言的文法の存在により、スタティックプログラムコード以外のやり方でコンフィギュレータ内の計算を記述する可能性が生み出される。制約式を式文法で書き、それをアイテムに付随させることで、デベロッパはアイテム間の関係を正確に表現することができる。記述の第１のレベルは、構成され得るコンポーネントのタイプおよびそれらの相互依存性との関連で特定のコンピュータシステムのためのコンフィギュレータの構造を定義する。これはローダ２２によってサポートされており、ローダ２２は主にアイテムおよびそれらの特性からなるコンフィギュレータ定義１２（すなわち外部形式１８）のシンタックス的形式を、すべてのアイテムおよびリソースならびにそれらの相互接続が明示的にその中で表わされるアプリオリグラフ２４の内部形式に変換する。このグラフのロードされた定義的形式は、コンフィギュレーションプロセスが進むにつれコンフィギュレータ１６によって用いられる情報の「アプリオリ」レベルをなす。ユーザがコンフィギュレータを実行している間にはアプリオリレベルには変更は加えられない。これはユーザがコンポーネントを構成するときに活性度伝播を導くのに用いられる。アプリオリグラフ２４はモノリシックではないことを理解すべきである。これは個別にロード可能なファイルに含まれるグラフの集合から構成され得るだろう。たとえば、１つのファイルがコンピュータシステムの主要コンポーネントを規定するグラフを含んでいてもよい。別のファイルが、コンピュータシステムへの接続に利用可能な周辺装置の定義を含んでいてもよい。さまざまな通信装置が、第３のファイルから得られてもよい、といった具合である。構築されている特定のコンフィギュレーションは、同じアイテムおよびリソースからのユーザの選択を含む同様なグラフによって第２のレベルにおいて表わされているが、各アイテムまたはリソースは（アプリオリグラフのようにすべてのものが存在するがそれはただ１回のみであるのではなく）ユーザのリクエストを満たすのに必要な回数だけ反復される。これがグラフの「インスタンス」レベルであって、各々の必要なコンポーネントがそこで適切な回数だけ「インスタンシエート」される。インスタンスは２方向リンケージによりアプリオリグラフ内の対応するノードに接続される。インスタンスはまた、それが依存するすべてのインスタンス、またはそれに依存するインスタンスにも接続される。これらの接続は接続されたオブジェクトまたはそれらへのポインタの名前との関連で表わされる。２方向リンケージは２つのオブジェクト間の１対の接続であって、これによりいずれかを他方のものから見出すことは簡単なこととなる。インスタンスは常にアプリオリレベルにおいてきっかり１つのアイテムまたはリソースに対応するが、単一のアプリオリレベルアイテムまたはリソースは多くの対応するインスタンスを有し得ることに注意されたい。このレベルでは、アイテムインスタンスは一般にやはりアプリオリレベルと同じようにリソースインスタンスに接続されているが、各インスタンスはちょうどそれ自体が依存している他のインスタンス、そしてこれらの他のインスタンスのみに、接続されている。したがって、インスタンスレベルは究極的に製造され受け渡されるであろうアセンブリを直接表わし、コンポーネントは最終的なシステム内に存在するであろうように相互接続されている。相互接続されたインスタンスは、本質的には、コンフィギュレーションである。インスタンスレベルは、構成されたシステムの値段づけ、顧客に対する見積り、オーダ、および製造を提供する。図２はアイテムのための外部形式の基本的シンタックスの図である。アイテムステートメント３８は、アイテムの名前を特定し、アイテムの宣言を始める。消費ステートメント４０は、アイテムにより消費された名前づけされているリソースの量を特定する。供給ステートメント４２は、アイテムにより供給されている名前づけされたリソースの量を特定する。制約ステートメント４４は、アイテムのコンフィギュレーションに適用される制約を特定する。複数の制約が特定された場合、アイテムの各インスタンスについて列挙された制約のすべてが満足されなければならない。プロパティステートメント４６は、アイテムのためのアトリビュート値を特定する。コンフィギュレータデベロッパ１０は、コンフィギュレータ１６の必要とするものを満たすべく自由にプロパティの名前を定義することができる。プロパティ値は数字または文字列であり得る。エンドアイテム４８トークンは、アイテムの定義の終わりを意味する。１つのアイテム定義内に複数のプロパティ、供給、および消費ステートメントが存在していてもよい。外部形式シンタックスの完全な定義は、付録Ａに示される。ユニシス・コーポレーションにより生産されるＡシリーズのコンピュータシステムのためのサンプルの外部形式は、付録Ｂに示される。ＩＩＩ．単純な例デジタルコンピュータシステムを構成する際のこの表現からもたらされるグラフを説明するには、図３および図４を検討されたい。図３は外部形式の記述の一例である。これは、コンフィギュレータデベロッパ１０がキャビネット、電源、周辺装置、およびこれらのコンポーネント間の関係を定義するのに書くであろうサンプルのシンタックス的外部形式５０を示す。示されている例では、キャビネットアイテム５２は記憶リソースを３６単位供給し、そのうち中央のグループ（大まかにはウェストの高さ）が、人間のコンピュータシステムオペレータにとって便利なアクセスを提供する。電源アイテム５４は、キャビネットスペースを３単位消費し、６つのソケットと電流を８００デシアンペア供給する。周辺装置アイテム５６（これはディスクドライブ、テープドライブ等であってもよい）は、２０デシアンペア、１つのソケット、１つのチャネル接続、およびキャビネットスペースを４単位消費する。図４は、外部形式の例からもたらされるアプリオリグラフの図である。アプリオリグラフは、リソースすなわち電源５４からの電流５８およびソケット６０と、キャビネット５２からのいくらかのキャビネットスペース６２と、何らかの他のサプライヤ６６（これはこの例ではこれ以上扱われない）へのチャネル接続６４を必要とする周辺装置５６を示す。電源５４は、キャビネットスペース６２を消費する。接続をするアークの上の数字は、アイテムによって供給または消費されるかもしれない（さまざまなユニット内の）リソースの典型的な量を表わす。結果として得られるコンフィギュレータ１６を動作させているコンフィギュレータユーザ２６が、２つの周辺装置をこのアプリオリグラフに基づくコンピュータシステムに構成したいと欲した場合、対応するインスタンスグラフが作られる。図５は、インスタンスグラフの図である。第１の周辺装置６８はソケット７０と、電流７２と、キャビネットスペース７４と、チャネル接続７６とを要求する。第２の周辺装置７８は同様に、ソケット８０と、電流８２と、キャビネットスペース８４と、チャネル接続８６とを要求する。双方の周辺装置は電源８８によって、ソケットおよび電流を供給される。２つの周辺装置６８、７８および関連の電源８８は、すべてキャビネット９０により供給されるキャビネットスペースを消費する。キャビネット９０は３６単位のスペースを供給し、２つの周辺装置の各々は４つの単位を消費し、電源８８は３つの単位を消費することに注目されたい。ユーザ２６が、たとえばキャビネットに利用可能なスペースが超過されてしまうことを引き起こすコンポーネントを選択した場合、コンフィギュレータ１６は自動的に付加的なキャビネットアイテムの新しいインスタンスを作る。電源８８に多すぎる数の装置が接続され、それによりソケットまたは電流の供給が超過された場合、同様な処理が起こる。あるアイテムが、何らかの他の単一のアイテムが供給するリソースを１つより多く消費した場合、供給アイテムの１つのインスタンスが通常これらのリソースインスタンスのすべてを消費アイテムのインスタンスに供給しなければならない。単純な場合には、ユーザのリクエストのコンフィギュレーションの暗示は直接、活性度伝播によって、すなわちアプリオリグラフを通って、要求されるコンポーネントを表わすノードから、そのリクエストによって必要性が暗示される付加的なコンポーネントを表わすノードまで制御が流れることを許容することにより、導き出され得る。このフローはインスタンスグラフでの現在の使用に既に利用可能でない、いかなる考察されたノードのインスタンスをもつくり出し、新しいリクエストへの応答を表わす、新しいものと古いものとの双方のインスタンス間での接続をなすようにもたらすことができる。たとえば、電源５４がキャビネット内に収納されるのではなく床上に据えられる、図４のアプリオリグラフの図解では、この場合周辺装置のためのリクエストはキャビネットスペースおよび必要量の電流を供給することのできる任意のソケットのための要求以上のものは含意しないだろう。一旦コンフィギュレーションセッションが始まると、キャビネットおよび電源は他の理由のために既にインスタント化されていることがありがちであり、（残っているキャパシティがない場合）新しいキャビネットまたは電源を構成するか、既に構成されているものの設備を用いるかは、リクエストノードからこれに接続されているノードへ移行することによってグラフの２つのレベルから直接判断され得るだろう。一旦必要とされる電源をキャビネット内に構成することと、それを必要とする装置をそのキャビネット内に構成することとの間に相互作用が起こった場合、アプリオリグラフ内で単純な活性度伝播以上のことを行なうことが必要になってくる。周辺装置とその電源とは同じキャビネット内になければならないと仮定した場合、装置をキャビネット内に位置づけると、新しい電源が必要な場合そのためのスペースが十分に残っていないかもしれない。この相互作用が対処されない限りは、デッドロックまたは早発の故障が生じ得る。デッドロックとは、１つのアクティビティが何らかの能力Ａを取得しておりかつ能力Ｂを必要としていて、別のアクティビティが能力Ｂを取得しておりかつ能力Ａを必要としているという状況である。一方または双方が必要な能力を手放すまでは、これらのアクティビティによってそれ以上の作業がなされることはない。これは、同時に多くの領域で起こり得る問題の非常に単純な例である。たとえば、周辺装置がパワーおよびキャビネットスペースだけでなくＩ／Ｏチャネルへの接続をも要求し、このチャネルはそれがサポートできるであろう装置のアドレスの数に関して制限されているかもしれず、チャネル上の装置は一緒にケーブリングされる必要があるという場合である。このケーブリングにより、最短および最長のケーブル長さの制約がもたらされるかもしれない。そのような状況では、常に満足のいく結果を生じる単一の処理シーケンスはなく、次に対処すべき最も適切な問題のピースを動的に選択し、先を見越して仮に行なわれた選択の結果を探究する必要がある。この複雑性はユーザがその中で選択を行なうシーケンスが最終的なコンフィギュレーションの質に対して持つインパクトによって合成され、これは可能な最良の適合性を達成するために任意の時間においてすべての要求されたコンポーネントを「リパック」することが可能なはずであることを示唆する。リパックにより、インスタンスグラフからユーザによって直接要求されていないすべてのインスタンスが取除かれ、残ったインスタンスの伝播およびパッキングが再実行されて新しいコンフィギュレーションが生成される。再パッキングのプロセスは通常、より最適なコンフィギュレーションを生成する。なぜなら、インスタンスが処理されるシーケンスを選択する自由がコンフィギュレータにあるからである。しかしながら、これを行なうには、（シーケンシャルマシンにおいては）何らかのシーケンスでの処理のためにコンポーネントを選択する必要があるが、どちらに対してこれらの選択を行なうかに関してオーダされた基準の単一のセットはない。セクションＶＩＩで説明されたパッキングエンジン３６は、これらの問題を双方とも、統合された態様で解決する。ＩＶ．知識ベース定義知識ベース１９は、２つの明確に区別される情報の組、すなわちネット定義２０とパッカー定義２１とからなる。Ａ．ネット定義ネット定義２０はアプリオリグラフ２４内でどの種類のデータオブジェクトが定義されてもよいかの定義である。これはロジックエンジン３２によって操作された根底にあるデータ構造を列挙する。ネット定義はアイテム、リソース、モジュール、アイテムセット、リソースセット、およびグループなどのオブジェクトを定義してもよい。ネット定義は、特定の種類の複雑なシステムのコンフィギュレーションをサポートするべくセットアップされる。この発明の最初の実現例では、ネット定義はインテリコープ・インコーポレーテッドから入手可能であるＫＥＥエキスパートシステムシェルを用いて定義されていた。しかしながら、ネット定義におけるオブジェクトは、Ｃ＋＋クラスの定義としても実現され得るであろう。Ｂ．パッカー定義パッカー定義２１は、アプリオリグラフ内のアイテムにどの種類のパッカーが付され得るかの定義である。次の表は、ＬＩＳＰプログラミング言語で実現され、ＫＥＥエキスパートシステムシェルを用いる好ましい実施例のためのサンプルのパッカー定義２１の一部を示す。これはユニシス・コーポレーションから入手可能であるＡシリーズのコンピュータシステムのコンフィギュレーションをサポートする。基本的なパッカーは発端において定義される。キャビネット、パワー分布ユニット（ＰＤＵ）、チャネルアクセスマネージャ（ＣＡＭ）、チャネルマネージャユニット（ＣＭＵ）、およびベースなどのコンポーネントのためのパッカーが定義されている。パッキング制御パッカーが、相互に作用するパッカーの制御局面を特定すべく定義される。チェーンおよび長さチェックパッカーも、定義される。最後に、長さパッカーは、小型コンピュータシステムインタフェース（ＳＣＳＩ）およびインテリジェント周辺インタフェース（ＩＰＩ）のインタフェースのために定義されている。Ｖ．ローダローダモジュール２２は構文外部形式１８をグラフに基づく内部形式のアプリオリレベルに変換する。ローダはデベロッパ１０により入力された外部形式を読出し、アイテム定義を識別する。ローダは次に、アイテム情報を保持するオブジェクトまたは「フレーム」と呼ばれる内部データ構造を創出する。外部形式におけるリソースには一般には明確な定義はない。ローダは各アイテムおよびその属性を取込んでそれに対し含意されるリソースを創出しなければならない。ローダは、アイテムの定義からアイテムの消費／供給ステートメントを見ることによりどのリソースを創出すべきかがわかる。フレームはまた各リソースに対して生成される。各フレームにはそのアイテムまたはリソースの名称が与えられる。各フレームは、消費するものおよび供給するものならびにそれらに関連する量のリストを含む。このようにして、アプリオリグラフとして表わされる関係が、フレーム各々の消費するものおよび供給するもののフィールドにおいて名称および量のリストによって定義される。図６は、外部形式ロードプロセスのフローチャートである。ステップ１００で、ローダは外部形式のファイルにおけるテキストの文字の構文解析を行ないアイテムを獲得する。パーサは付録Ａに詳細に説明されている外部形式の文法定義に従いテキストを読出す。ローダは次にステップ１０２でアイテムに対しフレームを生成する。フレームは次に、外部形式ファイルのアイテム定義の残りから得られたアイテムの属性でロードされる（ステップ１０４）。ステップ１０６でローダは現在のアイテムに対し含意されているリソースを創出する。このステップは、含意されたリソース各々がアプリオリグラフに既に存在していない場合にのみ必要である。新しいフレームが、もし特定的な要求によってまたは異なるアイテムに対し既に生成されていない場合に、識別された各リソースについて生成される。ステップ１０８で、ローダは含意されたリソースを、アイテムおよびリソースを表わすフレームにおけるフィールドを修正することによりアイテムに結び付ける。外部形式ファイルにおけるすべてのアイテムが処理されていなければ（テストステップ１１０）、ステップ１００の次にはノーパス１１２が続き、次のアイテムが外部形式ファイルから入手される。ローダがすべてのアイテムを処理していれば、ローダ処理はイエスパス１１４を介して終了する。ＶＩ．ロジックエンジン一般的にロジックエンジン３２はアプリオリグラフ２４およびインスタンスグラフ３４から、ユーザの要求が何であるかを推論し、コンフィギュレーションの既存の状態に新規のコンポーネント手段を追加する。始めにロジックエンジンはユーザの要求に基づいてアプリオリグラフ２４を調べる。ロジックエンジン３２はユーザの選択に基づいてアイテムおよびリソースに対しインスタンスを創出する。ロジックエンジンは、パッキングエンジン３６（以下で説明する）の実行の前にインスタンスグラフを処理し（「ネットを伝播する」）、終了する。伝播パスはアプリオリグラフによって定義されるが、プログラム制御の実際の伝播はインスタンスグラフで生成される新規のインスタンスを通して行なわれる。ロジックエンジンはノードごとにインスタンスグラフを通して進み、アイテムとリソースとの間の正しいリンケージを構成する。前方または後方チェーニングは行なわれない。ロジックエンジンは単にグラフの状態の検査および更新を行なう。この処理設計方策は、規則に基づく知識表現のための一般の設計よりもはるかに簡単である。ロジックエンジンはワークキューを使用してインスタンスグラフにおけるノード間のロジックリンクを一時的にストアする。各アイテムに対し、リソースリンクはストアされてから辿られる。このリンクはロジックエンジンにより制御メカニズムとして使用される。ワークキューにおける次のリンクを辿ることにより、インスタンスグラフのどのノードを次に処理すべきかがわかる。ネット伝播プロセスは反復する。リソースリンクは同じアイテムに関連付けられかつ接続されるため、ワークキューにストアされたリンクを結合する必要がある場合がある。ロジックエンジンは、アイテムの所与の数のインスタンスを生成すること、所与のアイテムのインスタンスをリターンすること、およびインスタンスを割当てられていた別のインスタンスに接続することなどの動作について呼出可能な機能を提供する。アプリオリグラフ固有の供給／消費関係は、コンポーネントを使用する制限について定義している。たとえば、コンピュータシステムの文脈では、大きなメインフレームには通常制限は少ない。しかしながら、小さなシステムには、マザーボードにおけるスロットの最大数などの制限があることが多い。何らかの所与のシステムについて、一定量のリソースが利用可能である。この制限は、接続できる周辺装置の数などを規定する。グラフから見ると、制限はコンフィギュレーションの問題の逆であるように見える。アプリオリグラフ２４では、消費は「上向きに」流れる。すなわち、コンポーネントを追加することの結果生じる副作用が何であるかを判断するために、ロジックエンジンはグラフを見上げてどのリソースを消費するかを見る。インスタンスグラフでは、制限は「下向きに」流れる。何らかの所与のコンポーネントについての制限を判断するために、ロジックエンジン３２は、絶対的なリソースの制限が設けられているコンポーネントから始めてインスタンスグラフ３４を見下ろし、要求できるコンポーネントの次の下位レベルの最大量を計算する。このプロセスは、所与のコンポーネントに到達するまでレベルごとに繰返される。ＶＩＩ．パッキングエンジンデベロッパ１０は、どの活性度伝播が不適切でありしたがってパッキングがどこで必要とされるかについてアプリオリグラフのノードをマニュアルでマークすることができる。パッキングは、適した基準の何らかの長所（通常は最適な方法に限りなく近い）に従い、コンポーネントのある組を別のコンポーネント内に配置するプロセスであり、「パッカー」はこのプロセスを実行するロジックの組である。アプリオリグラフにおけるこのようなノード各々は、適切な方法で自身に必要なものを扱う異なる「パッカー」を構文的に識別することができる（構文定義については付録Ａ参照）。パッカーはパッキングするアイテムのノードに付けられており、アイテムに接続されるリソースはそのパッカーが処理する。パッキングエンジン３６は複数のパッカーで構成される。パッカーの内部論理は同じである、すなわちパッカー論理のコアとなる実働化は再使用可能な単一ブロックのソフトウエアである。したがって、すべてのパッカーはプロセスの同じサイクルを実行する。好ましい実施例では、パッカーはＫＥＥにおけるオブジェクトである。代替的に、パッカーをＣ＋＋クラスのオブジェクトとして表してもよい。各パッカーのクラスにはデフォルト設定がある。デベロッパはセクションＩＶ．Ｂで先に述べたパッカー定義２１における利用可能なパッカーのクラスを定義する。デベロッパにより特定された制約式は通常異なるパッカーを区別するものである。アプリオリグラフ２４においてアイテムに付けられたパッカーの位置およびその制約式は所与のパッカーに対するタスクを定義する。パッカーは生成およびテスト問題解決法を使用する。好ましい実施例では、パッカーはビンパッキング、ストリンギング、ケーブリング、ラックパッキングまたはその他の複雑なコンポーネントアセンブリの要求に関係する、いくつかの異なっているが相関する問題を解決するために使用される。ビンパッキングの問題では、物理的な大きさを有する多数のオブジェクトがコンテナ（ビン）タイプにパッキングされねばならない。目的は、すべてのオブジェクトをコンテナにパッキングすることができるようにするが使用するコンテナの数を最低限にするパッキングの回答を発見することである。たとえばコンピュータシステムでは、複数の周辺装置を最小数のキャビネットにパッキングするがそれでもなおフロントアクセス要求などの制約を満たすことが望ましい。一般的には、ビンパッキングの問題は、空間のおよび電力ローディングの制約に適合する最適なコンポーネント配置シーケンスを発見することを含む。「ストリンギング」の問題では、目標は、キャビネットにパッキングされているすべての周辺装置を、利用できるＩ／Ｏケーブルが物理的に周辺装置を接続でき、かつケーブルの長さがまた最小となるように接続することである。「ストリング」は複数の周辺装置をＩ／Ｏチャネルに接続する方法であり、各装置が自身のＩ／Ｏチャネルを有する（さらなるハードウエアが必要という点で見れば高価となる）ことではない。ストリングによりホストプロセッサへのデータパスの数が最小になる。コンピュータシステムコンフィギュレーションドメインでは、ストリンギングの目標は、制約式によって表わされる供給／消費の制約および制約の組合せに従う最適な方法で装置を接続することである。制約式を用いて、いかにして装置を接続できるかについての特徴が定義される。本発明は、ビンパッキングおよびストリンギングの問題を同時に解決するためのメカニズムを提供する。ビンパッキング問題を最適な方法で解決することにより、ストリンギング問題の何らかの解決の最適性が低下するかも知れず、またその逆となる場合もある。この問題に同時に取り組むことにより、コンフィギュレータは最適に近い全体的な回答を生成する。たとえば、コンピュータシステムの種々のコンポーネントをキャビネットに配置する状況について考察する。キャビネットは固定された量のラックスペースを提供する。ユニシス・コーポレイションから入手できるＡシリーズのコンピュータシステムでは、キャビネットは、チャネルアダプタモジュール（ＣＡＭ）に接続するチャネルマネージャユニット（ＣＭＵ）に接続するＩ／Ｏチャネルを保持し得る。ＣＡＭは次に磁気テープドライブ装置などの周辺装置に接続するか、または磁気ディスクドライブ装置に接続する。これらのコンポーネントはすべて電力分配ユニット（ＰＤＵ）からの電力の供給を必要とする。これらのコンポーネントをキャビネットに配置するとき、コンフィギュレータは可能性のあるコンポーネントの配置を他の配置とともに同時に評価することにより最適な解決法を判断する。したがって、デベロッパはパッカーをキャビネット、Ｉ／Ｏチャネル装置、ＣＭＵ、ＣＡＭおよびＰＤＵコンポーネントに付ける。これらのパッカーは（以下で述べるように）相互作用してビンパッキングの問題についての好ましい回答を発見する。アプリオリグラフ２４を通して流れる制御がパッキングノードに達するとき、活性度伝播制御の流れは一時的に停止され、その他の懸案中のパス（１つ以上のアークが自身から出ているノードは複数のフローパスを生成する）を辿ることができる。最終的には、アプリオリグラフにおける利用可能なパスすべてが探索され、各パスは終了に通じるかパッキングノードに到達するかいずれかである。懸案中のパッキング決定のために停止されている１組のノードでの不完全なインスタンス接続は、これから行なわなければならないパッキングの作業について規定し、パッキングノードは、処理の次の段を実行するのに誘起せねばならないパッキングエンジン３６における１組のパッカーを自身で識別する。このようにして識別されたすべてのパッカーが開始される。これらのパッカーのうち１つは、コンフィギュレータが処理する次の有用な作業でなければならない。各々がするべき作業を有する１組のパッカーを与えられると、問題はどのパッカーがその他のパッカーに対し優先順位を取るかについていかにして識別するかである。本発明では、各パッカーは自身のローカルワークの優先順位を付けることができる。コンフィギュレータはまた、すべてのパッカーの間で作業を調整しなければならない。この問題に対処するために、パッカーは、所望の動作を要求しかつその応答を相関付けるマスタスケジューラによって呼出される。マスタスケジューラは、スーパバイザ、およびマスタコンサルタントという２つの処理要素からなる。パッカーは優先的にインスタンスによって動作することに注意されたい。パッカーはインスタンスを接続することができ、かつインスタンスグラフにおける新規のインスタンスを作成できる。これらの動作は、アプリオリグラフにおける伝播および停止を生じさせるかもしれない。Ａ．パッカー処理個々のパッカーの処理はいくつかの別々の相に分割され、リターンされる結果は標準化された形式で表現され、マスタスケジューラが相関させることができる。図７は、個々のパッカー処理ステップのフロー図である。ビッドステップ２０２で、各活性パッカーは次に実行することが最も重要である１つの動作を識別し、その動作がいかに所望されるかおよびいかに制約されるかを表わす０と１との間の２つの重みを割当てる（すなわちこの選択に対しその他の配置の可能性がいくつ存在するかである）。選択ステップ２０４で、このビッドが、重み付け方法を用い所望性と可能な配置がいかに制約されるかを組合せて比較される。マスタスケジューラは１つのパッカーを選択してビッドをさらに発展させる。割当ステップ２０６で、選択されたパッカーは、インスタンスを作成することによりおよび／またはインスタンスグラフ３４において接続を行なうことにより提案された動作を一時的に実現し、その他のパッカーのコンサルタント処理（以下で述べる）を誘起して、すべての観点からして結果として生じるコンフィギュレーションの状態が正当であるかどうかを判断する。もしそうでなければ、代わりの割当選択を行なうことができる、すなわち正当であれば、後に問題が発生する場合に備え（前述の周辺／電力供給スペースの衝突の例などのように）、新しい状態からルックアヘッドが行なわれる。ルックアヘッドは、既に一時的に行なわれている選択の意味するものを詳細に調査してその選択に不利な結果が生じる可能性があるかどうかを判断する。ルックアヘッドプロセスが終了まで進むことが可能であり（最良の結果について）、またはプリセットされた数のレベルの後に早期に終了することが可能である（よりよいパフォーマンスについて）。割当プロポーザは、マスタスケジューラによって呼出されると、所与のパッカーについて選択を行なう。この選択はたとえばストリングにコンポーネントを付けることからなるかもしれない。各パッカーは自分自身の観点から提案された選択を査定するロジックを含む。別のパッカーは提案された選択に従うかまたは反対してもよい。割当プロポーザは実際にはインスタンスグラフに新規のアイテムを挿入してその選択を反映させる。この挿入は次に、別のパッカーによる承認の後にバックアウトされる。実現ステップ２０８で、割当相の間に問題が発見されなければ、選択された動作が永久なものとされる。すべての場合において、違法な状態を構成するものの定義は、プログラムコードではなく宣言形式である。この方策の実行に成功する能力は、パッカーの機能性の因数分解、および基礎をなすグラフとの統合に依存する。Ｂ．選択プロポーザ図８は、パッカーの４つの部分を示すブロック図である。選択プロポーザ２１０はインスタンスグラフ３４に影響を及ぼす提案される動作の進路について何をビッドするかの選択を行なう。選択プロポーザは次に最も配置したいインスタンスを選択し、所望性および重要性という点から０ないし１のスケールで評価する。選択プロポーザ２１０はパッカーが処理する必要がある既存のアイテムインスタンスのリストを採用する。次にインスタンスグラフにおいて各アイテムインスタンスを配置するために可能な選択すべてを見る。所与の選択を実現する動作はタスクと呼ばれる。各可能なタスクについて、選択プロポーザは以下の処理を実行する。選択プロポーザは、このパッカーのコンサルタント２１４が決定する制限の理由または制約の理由による現在のタスクを実行する際の制約を表わす、制約される量を計算する。現在のタスクを割当てることができない既存のアイテムインスタンスのリストにおけるメンバの数を同定することにより、制約される量が計算される。コンサルタント２１４が定めるように現在のタスクを新規のインスタンスに割当てることができなければ、選択プロポーザは作成することができる新規のインスタンスの数（制限に従う）を制約される量に加える。方策量が計算されて、デベロッパが特定する方策の機能に従い、現在のタスクをパッキングエンジン３６が実現する次の動作に割当てる値を表わす。次に、値が計算されてデベロッパが規定する制約される量と方策の量との組合せを表わす。今計算された値が、選択プロポーザが可能な各々のタスクを循環するときに見て最適な値であれば、この値はパッカーの最良の値として保存され、現在のタスクはこのパッカーの最良のタスクとして保存される。すべてのタスクの分析の後、選択プロポーザは最良のタスクおよび最良の値をリターンする。Ｃ．割当プロポーザ割当プロポーザ２１２は選択されたビッドの詳細を埋める。選択プロポーザはこの選択を取込みこれをインスタンスグラフに正当に配置しようとする。その他のパッカーの関連するコンサルタントを検査して提案された配置が確実に問題を生じさせないようにする。また前方を見て将来の問題の発生を回避する。割当プロポーザはパッカーが付けられているアイテムの既存のインスタンス各々を調べる。スーパバイザにより送られたタスクをインスタンスグラフのインスタンスに一時的に割当てる。提案された割当が限界を超過しなければ、かつマスタスケジューラのマスタコンサルタント処理がこの割当が許容できることを示していれば、割当プロポーザはインスタンスをスーパバイザに戻す。既存のインスタンスにおける配置が不可能であれば、割当プロポーザ２１２は一時的にタスクを新規のインスタンスに割当てる。マスタコンサルタントがこれか許容できることを示せば、割当プロポーザは「新規の」表示をスーパバイザに戻す。そうでなければ、割当プロポーザは「割当なし」表示をスーパバイザに戻す。Ｄ．コンサルタントコンサルタント２１４は提案されたインスタンスグラフの全般的な状態を再考してパッカーの観点からその正当性を検査する。提案されたインスタンスグラフが許容できるかどうかを示す。コンサルタント２１４は選択プロポーザから送られたインスタンスの文脈内でのパッカーの制約を評価する。この処理の結果は戻される。Ｅ．インプリメンタインプリメンタ２１６は、影響を受けたすべてのパッカーが、提案された動作の進路を許容可能であるとして送った後、それについてインスタンスグラフにおいて永久的な変更を生じさせる。インプリメンタはインスタンスグラフの提案された動作の進路を実行することにより、ユーザの要求の結果としてそれを更新する。Ｆ．マスタスケジューラ図９は、マスタスケジューラとパッカーとの関係を示すブロック図である。マスタスケジューラ２１８はスーパバイザ２２０およびマスタコンサルタント２２２という２つの独立したモジュールからなる。マスタスケジューラ２１８はパッカーの動作を調整する。マスタスケジューラは活性選択プロポーザ２１０各々からの提案を要求する。提出されたうち最も重要な提案を選択する。マスタスケジューラは対応する割当プロポーザ２１２からのその提案に対して配置を要求する。割当に成功すれば、提案を行なったパッカーのインプリメンタ２１６を呼出してその提案を永久のものにする。このプロセスはするべき作業を有するパッカーがなくなるまで繰返される。スーパバイザ２２０は、インスタンスグラフで達成することができるさらなるパッキング活動がなくなったときにのみ終了する、コンフィギュレータ１６内での制御プロセスである。スーパバイザはパッカーに絶え間なく問合せを行ないコンフィギュレーションを生成する際に実行すべき最も重要なタスクを決定する。アプリオリグラフで特定された各々のパッカーについて、スーパバイザ２２０はパッカーの選択プロポーザ２１０を呼出してパッカーの最良のタスクおよび最良の値を得る。選択プロポーザがタスクを戻し、戻された値が今までから見て最良のものであれば、スーパバイザはそのパッカーを最良のパッカーとして保存し、戻されたタスクをシステムの最良のタスクとして保存する。すべてのパッカーの問合せの後、システムの最良のタスクが識別されれば、スーパバイザ２２０はシステムの最良のタスクを入力として有する最良のパッカーの割当プロポーザ２１２を呼出し割当てられるべき新規のインスタンスを得る。割当が発見されれば、スーパバイザは最良のパッカーのインプリメンタ２１６を呼出し、システムの最良のタスクおよび割当を入力として送り、割当を実現する。割当が発見されなければ、システムの最良のタスクは一時記憶領域に置かれプロセスは繰返される。システムの最良のタスクが識別されなければ、スーパバイザ２２０の処理は完了する。マスタコンサルタント２２２はパッカーの割当プロポーザ２１２によって呼出されて、提案された動作の進路がすべてのパッカーにとって許容できるかどうかを判断する。マスタコンサルタントは今度は各パッカーのコンサルタント２１４に問合せを行なう。何らかのパッカーのコンサルタントが提案された動作の進路に反対すれば、マスタコンサルタント２２２は否定的な表示を自身を呼出した割当プロポーザに戻す。マスタコンサルタントはまた、今度は割当てられていないタスク各々を調べる。タスクのパッカーの割当プロポーザがタスクに対する割当を戻せば、マスタコンサルタントは肯定的な表示を自身を呼出した割当プロポーザに戻す。上記のいずれの場合も発生しなければ、マスタコンサルタントは否定的な表示を戻す。インスタンスグラフの伝播におけるロジックエンジンの固定的で順次的な制御の流れと比較すると、パッカーの制御の流れは非常に流動的でかつ同時発生的である。この流れは、現在の部分的なコンフィギュレーションの状態およびどの動作が次に完了させるべき最も重要な動作であるかということによって駆動される。これにより異なるパッカーが、自身が責任を持つべきコンポーネントが特定的な処理の段階で最も重要になったとき次第で、異なるときにコンフィギュレータの処理を制御することができる。パッカーはロジックエンジンにより与えられている何らかの１組のリソースインスタンスを既存のコンフィギュレーションに加えることにより動作する。一度に数多くのインスタンスを考慮に入れていれば、既に構成されているものに加えるものとしてすべてが並行してパッキングされる。１つのインスタンスのみを考慮しているならば、既存のコンフィギュレーションに直接加えられる。既にパッキングされているアイテムがなければ、与えられたすべてのインスタンスが可能な限りパッキングされる。このようにしてパッキングアーキテクチャはコンフィギュレーションへの小さな増分を加えることおよびコンフィギュレーション全体を完全に再びパッキングすること双方をサポートする。コンフィギュレーション全体の再パッキングの結果は通常増分的なパッキングよりも優れている。Ｇ．パッキング例この例は、コンピュータシステムのインスタンスグラフおよびセクションＩＩＩで議論された仮定に基づくものである。ケーブルパッカーの選択プロポーザにおける特別な方策のコードが少量必要であり、このコードは、既存のストリングに取付けることができる周辺装置についての作業を、新規のストリングを必要とする作業よりも好んで選択する（これはデフォルトであろう）。ストリングは複数の装置を１組のＩ／Ｏチャネルに接続する方法である。パッキングの状況が以下のとおりであると想定する。・図５に示す周辺装置の１つがキャビネットにまだ配置されていない（すなわちCabinet space、したがって電力、接続が満たされていない）。・１つ以上の周辺装置に対し既存のキャビネットにスペースがあるがそれ以上はない。・既にキャビネットにパッキングされている電源から十分なソケットおよび電流が利用できる。・キャビネットに既に配置されている周辺装置へのストリングがまだ配置されていない周辺装置にも適用できるが、（ケーブルの長さのために）別のキャビネットのインスタンスに配置されるならば適用できない。・既存のキャビネットにおいて何らかの周辺装置とストリンギングすることができない、キャビネットが必要な異なるタイプの別の周辺装置がある。本質的には、２つのパッカーが各周辺装置に対しあるシーケンスで進行しなければならない。２つのパッカーはすなわちキャビネットパッカーおよびケーブリング（ストリンギング）パッカーである。各パッカーは次に最も所望される動作についてビッドを出すことが求められるだろう。キャビネットパッカーには１つの周辺装置をその他の周辺装置よりも好む根拠がなく、したがっていずれかについてビッドを出すかもしれないが、重みは低い。ケーブルパッカーはさらなる方策のためストリンギングできる周辺装置についてビッドを行なうであろうが、比較的重みは高い。ケーブルパッカーはしたがってビッドに勝ち次にストリンギング可能な周辺装置を既存のストリングに割当てる。結果として生じる状況は正当であるため、永久のものとされる。次にビッドの新ラウンドが開始される。今度はキャビネットパッカーは新しくストリンギングされる周辺装置が部分的に配置されていることを見て、既存のキャビネットにおいてその周辺装置のビッドをする。ケーブルパッカーは残っている周辺装置については比較的無関心であり、そのため重み付けを低くしてビッドする。キャビネットパッカーはこのようにしてビッドに勝利する。割当プロセスには問題はなく、配置はしたがって永久のものとされる。残余の周辺装置は次に新しいストリングで新規のキャビネットに配置される。このシナリオは初期の条件にわずかな変更を加え以下のように非常に異なる結果をもたらす。・２つのストリンギング可能な周辺装置のうちストリングされていない一方は、キャビネットのフロントアクセス領域におけるスペースを要求するテープドライブ装置である。・既存のキャビネットにはフロントアクセス領域にフリースペースかない。こうした条件の下、キャビネットパッカーはテープドライブ装置をビッドするが、その理由はこれが最も制約された選択であるためだが、重みはあまり大きくない。ケーブルパッカーは同じ装置をかなり重みを大きくしてビッドするが、その理由はストリンギングすることができるからである。ケーブルパッカーはしたがって勝利し、以前のようにその周辺装置をストリンギングしようとする。ルックアヘッドの深さがユーザによりあまり低く設定されていなければ、ケーブル割当中のルックアヘッドは選択された装置を既存のキャビネットに配置しようとするが、失敗する、というのもフロントアクセス領域が必要であるためである。したがって新規のキャビネットインスタンスが作成されその装置を新規のキャビネットにおけるフロントアクセス領域に配置する。しかしながら、さらなるルックアヘッド処理により、ケーブルの長さの制約が今破られていることが発されるだろう。既存のストリングへの配置はしたがって失敗する。新しいストリングが生成され、新規のキャビネットへの割当に成功する。第２の装置が次に古いキャビネットにおける新しいストリングに配置される。以前のシナリオについてのわずかな変更について考察する。すなわち・既存のキャビネット装置がフロントアクセス領域にフリースペースを有する。このことは重みが少々異なる、より簡単な処理シーケンスにつながる。ビッドの間、キャビネットパッカーは、テープドライブ装置がフロントアクセス領域を要求していること、したがって、選択がより制約されていることを観察する。キャビネットパッカーはしたがってその装置を重みをかなり高くしてビットするが、マニュアルの方策のためにケーブルパッカーは（ストリンギングに対し同じ装置をビッドする）より高い重みを割当て、したがってビッドに勝利する。このシナリオにおける割当には問題は生じず、第２の装置は再び新しいキャビネットにおける新規のストリングに進む。処理におけるこれらの変化すべては、パッキングアーキテクチャに必要なものとして生じる。これらは、ビッドの計算および次のアイテムの選択のための各パッカーに関連する非常に制限された特定化されたコードと結合された、インスタンスグラフにおけるパッキング可能なアイテムに与えられる、制約式の解釈から生じるものである。図３の例では、関連する制約は、キャビネット（Front Acc essとして９ないし２６のレンジを規定する３６のCabinet Spaceの供給を有する）、周辺装置（ある量のCabinet Spaceの消費を有し、テープドライブ装置であればFront Accessに対する必要性を特定する）、およびケーブル（ケーブル全長について制約を有し、パッカーパラメータにおいて以下に述べられる）に付けられる。コンフィギュレータデペロッパ１０は、すべてのシナリオについて正しいコンフィギュレーションを生成するために、外部形式１８にこの情報すべてを入力しなければならない。ＶＩＩＩ．制約式および式ハンドラパッキングプロセスの制御には２つのレベル、すなわち総合的な戦術的なものと、個々の戦略的なものがある。戦術レベルはパッカーの部分が処理のために選択されビッドの重みの生成されるシーケンスに対応する。これらの動作は完全に宣言型の形式で制御されるのではない。戦略レベルは行なった選択の正当性に関し、プロポーザにおける明らかに違法な選択を回避し、かつコンサルタントにおけるすべての関連する観点からの選択を再考する。制御の戦略レベルは、全体が括弧でくくられ、任意的にネストされ、プレフィックス形式の関数型言語で書かれた制約式を解釈する、一般的な式ハンドラによって実現される。コンフィギュレータには唯一の式ハンドラ３７がある。これはロジックエンジン３２およびパッキングエンジン３６によって呼出される。式ハンドラを呼出す必要性は、インスタンスグラフにおける現在の位置によって決定される。アイテム間の複雑な相互作用が常にリソースの消費および供給という点において特定することができるわけではないので、パッカーは自身が取付けられたアイテムの制約の規定を考慮する。制約式は構成するのに利用できるコンポーネントの内部的な関係を規定するコンフィギュレータデベロッパにより特定されるデータである。すなわち、インスタンスグラフにおけるアイテムのインスタンス内で存在することが許可される関係について記述されている。式ハンドラは式を評価してそのリターンの値を生成することができるプログラムである。この式はパッカーが付けられたアプリオリグラフにおけるアイテムにストアされる。この解釈は常にインスタンスグラフの現在の状態に関して行なわれる。式は、評価して何らかの必要とされる結果をもたらすことができるファンクションコールとアーギュメントとの組合せである。アーギュメントはファンクションに送られるパラメータである。式は、自身が結び付けられているパッカーの観点から現在の状態の正当性を示す、真または偽の結果を生み出す。個々のパッカーに結び付けることにより、コンフィギュレータのデベロッパにとっては自然である態様で、正当性の定義を区切ることができる。式に対する構文形式は、ローダ２２によって内部的に解析される形式に変換され、したがってコンフィギュレーションを支配する規則の正当性が変化したとき修正を容易に行なうことができる。これらの式によって非局所的な正当性の検査すべてが制御される。式における式またはフレーズの一般形式は以下のとおりである。（〈function-keyword〉[〈argument〉]...）〈function-keyword〉は、さらなるプログラムコードを実現しなければ延長することができないファンクションの予め規定されたリストからきたものである。アーギュメントは、文字通りの値、値のリスト、Ｔ（真）、ＮＩＬ（偽または空）、アプリオリグラフにおけるノードの名称、または上記の一般形式での副次的な式である可能性がある。何らかの構成された値のタイプが、コンフィギュレーションの問題（たとえば位置）の具体的な局面に特定的なデータタイプを取扱う際に利用できる。さらに、非常に稀であるが、「パス」の概念は、複数のパスが同じ１対のインスタンスに結合するときにはインスタンスグラフの領域を通したステッピングのプロセスを明確に制御するのに必要とされる。予め規定されたファンクションにより、名称を付けられたアイテムの関連するインスタンスすべてをインスタンスグラフから引出すこと、リストにおいてエントリの数をカウントすること、またはリストにおけるエントリに述語を与え述語が常に満足された（「すべて」）または（「何らか」）であるかどうかを検査することなどの動作が可能になる。式の評価は、始めに式を含むアイテムのインスタンスが「現在の」インスタンスであると考えられる文脈において実行される。暗黙に、この文脈におけるその他のアイテムのインスタンスへのリファレンスは、直接または間接的にこのインスタンスに結び付けられているインスタンスに対してのみである。文脈は自動的にリストにおける各インスタンスに対し、すべてまたは何らかが実行されるファンクションとして再び結び付けられ、そのため暗黙のインスタンスはファンクションが処理しているリストから現在考慮されているものになる。特定的な文脈を、In．Context ファンクションにより選択することができる。この文脈の従属性の効果は、デベロッパが、インスタンスレベルでの制御動作を必要とせずに、専らアプリオリグラフのレベルでコンフィギュレータを特定できることである。こうすることによりコンフィギュレータを開発する言語およびプロセス双方が簡略化される。インスタンスが間接的に現在のインスタンスに結ぴ付けられているとき、概念的にはコンフィギュレータが現在のインスタンスからインスタンスグラフにおいて可能なパスを探索し、ターゲットとするインスタンスに対して文脈を配置することが必要であり、同様の処理が名称が付けられたセットのすべてのメンバを識別するのに必要である。セットはアイテムの集まりである。この文脈処理は、必要なときごとに直接的に実行されるならば遅いであろう。しかしながら、セットへの名称を構成要素のアイテムに拡大し、かつ与えられた各名称に到達するためにたどられるノードの経路を明確に述べることにより、ロードのときに自動的に最適化される。パスは、順次的に、現在のアイテムと所与の名称との間でたどられるアイテムおよびリソースを規定する（そのようにして探索を回避する）。こうした最適化は、式の内部形式はデベロッパが書こうと意図しているものとわずかに異なることを示している。デベロッパが必要な内部ファンクションを明確に書くことが可能である（そうすることにより、より複雑なロードプロセスをプログラムする必要性を回避する）、そうすれば結果として生じるコンフィギュレータの維持が非常に困難になる、その理由は制約式とアプリオリグラフの構造との間の従属性が厳しいためである。Ａ．制約式の例例として再びコンピュータシステムのコンフィギュレーションのドメインから、ＳＣＳＩケーブルパッカーに結び付けられ確実に全体的なケーブルの長さの制限を超過しないようにする長さの制約式は以下のとおりとなる。（〈＝（＋（ＣＯＬＬＥＴ（ＰＲＯＰＥＲＴＹ．ＶＡＬＵＥＬＥＮＧＴＨ）（ＣＨＡＩＮＥＤ．ＩＮＳＴＡＮＣＥ．ＶＡＬＵＥＳＳＣＳＩ．ＣＡＢＬＥ）））８２）これは以下のことを意味すると解釈される。「現在のＳＣＳＩ．ＣＡＢＬＥインスタンスから、ケーブルの各端部におけるコネクタに従い結び付けられたＳＣＳＩ．ＣＡＢＬＥすべてを発見する。」ＣＨＡＩＮＥＤ．ＩＮＳＴＡＮＣＥ．ＶＡＬＵＥＳというファンクションはこの動作を実行し、始めのものを含め発見したすべてのインスタンスのリストをリターンする。「リターンされた各インスタンスに対し、ＬＥＮＧＴＨプロパティを引出し、リストにおけるすべてのプロパティをリターンする。」ＰＲＯＰＥＲＴＹ．ＶＡＬＵＥというファンクションは、現在のインスタンスから名称付けられたプロパティの値をリターンする。ＣＯＬＬＥＴというファンクションは、第２のアーギュメントとして与えられたインスタンスのリストにわたって反復する。各インスタンスに与えられたときに始めのアーギュメントとして付与された式から戻されたものを集めてリストに入れる。このリストは最終的に呼出したものに戻される。ＰＲＯＰＥＲＴＹ．ＶＡＬＵＥが与えられる文脈は自動的に、実行がリストを下に進むときにＣＯＬＬＥＴによって再び結び付けられ、結果として、ＣＨＡＩＮＥＤ．ＩＮＳＴＡＮＣＥ．ＶＡＬＵＥＳがリターンする各インスタンスに与えられる（ＰＲＯＰＥＲＴＹ．ＶＡＬＵＥＬＥＮＧＴＨ）となる。このプロセスにより、考慮中のケーブルを含むストリングにおけるケーブルすべての長さを与えるリストがもたらされる。「値のリターンされたリストを合計する。」この言語の多くのファンクションと同様、「＋」は、一般的な２またはそれ以上のアーギュメントの代わりに値のリストからなる単一のアーギュメントが与えられることが可能であり、この状況を検出し、自動的にリストのすべてのエントリを合計し、この場合はこのチャネルでケーブルの全長をリターンする。最終的に、最後の動作は「全長が８２未満であることを検査する」である。Ｂ．式ハンドラによりサポートされるファンクションより明確には、式は括弧でくくられたプレフィックス形式の制限されたファンクションの式であり、値をリターンするものである。式はネストされた副次的式を含むことができ、かつ多数の異なるアーギュメントのデータタイプおよびファンクションで構成できる。図１０は、コンフィギュレータ式ハンドラがサポートするデータタイプを示すブロック図である。「整数」データタイプ３００は、通常の整数、解釈自身が送られるファンクション次第であるがエラーを生じさせずまた可換の動作の結果の値に影響を及ぼさないように規定される「（）」（空のセット）、および値が常に「１」である「Ｔ」を含む。「ブール」データタイプ３０２は、「０」（「（）」に等しく「偽」である）を含み、それ以外のものは「真」であると考えられる。「ブール」をリターンする算術ファンクションは、「偽」に対して「０」をリターンし、「真」に対して「１」をリターンする。「ブール」をリターンする「リスト」ファンクションは、「偽」に対して「（）」をリターンし、「（）」をリターンするのでなければ「真」についてのテストに成功した最後のリストのアイテムをリターンし、「真」がリターンされる。「プロパティネーム」３０４、「アイテムネーム」３０６、および「セットネーム」３０８データタイプは、それぞれ、プロパティ、アイテム、またはセットについての文字に基づく識別子を規定する。「インスタンス」データタイプ３１０は直接構文的に特定できない。これは暗黙のアーギュメントである可能性がある。「リスト」データタイプ３１２は、（「リスト」を含む）何らかのその他のデータタイプのアーギュメントのリストである。「リスト」は従来は括弧で囲んで記述されている長さが不定の値の集まりが順序付けられたものである。「リスト」はリストを含み得る。「シリーズ」データタイプ３１４は、ファンクションへの不定の長さのアーギュメントのリストを規定する。そのものは括弧に入れる必要はないが、エントリは単に、ファンクションコールを囲む括弧内部のファンクションの名称をたどる。リストを最終のアーギュメントとして受取るファンクションはまた、その代わりとしてその位置における「シリーズ」を受入れる（２つの場合は存在するアーギュメントの数によって区別される）。ファンクション次第で、「シリーズ」は、その各々の要素がエンティティでありその別々のアイデンティティを保持するように扱われるかもしれず、または各要素の内容が他の要素の内容と結合されて単一のリストを形成するように扱われるかもしれない。複数の値をリターンするファンクションは常にそれらをリストにリターンする。「制約」データタイプ３１６は、「ブール」のリターン値を必要とする。「制限」データタイプ３１８は、「整数」をリターンしなければならない。「戦術」データタイプ３２０には２つのタイプかある。パッキングされていないリソースに対する「戦術」データタイプは、望ましさのオーダを減ずる際に連続するアイテムのリストを必要とする。パッキングされたリソースに対する「戦術」は、現在のインスタンスに対しプロポーザが割当てる重みとして使用されるであろう数を必要とする。図１１は、式ハンドラがサポートするファンクションのブロック図である。ＡＮＤファンクション３２２は、標準的なブール接続語である。これは入力パラメータに対し式のシリーズを受取る。ＡＮＤファンクションは、調べられた最後の式がリストまたはインスタンスであれば、「真」については調べられた最後の式の値をリターンし、「偽」に対しては「（）」という空のリストをリターンし、最後に調べた式が整数であれば「偽」について「０」をリターンする。ＡＮＹファンクション３２４は、入力として述語およびインスタンスのリストまたはインスタンスのリストのシリーズを受取る。述語は評価された際に真または偽をリターンするテスト式である。ＡＮＹファンクションは、リストにおける何らかのエントリが述語を満たしていれば「真」をリターンし（始めに満たすエントリ、または「（）」であれば「Ｔ」）、いずれも満たしていなければ「偽」をリターンする（空のリスト「（）」）。ＡＮＹ．ＩＮＳＴＮＣＥＳ．ＯＦファンクション３２６は、入力としてアイテムネームまたはセットネームおよび最適なパスを受取る。これは与えられたネームの何らかのインスタンスが現在の文脈に存在していれば「真」をリターンし（始めに満たすインスタンス）、そのようなインスタンスがなけれは「（）」をリターンする。ＡＴ．ＭＯＳＴファンクション３２８はカウント、述語、およびインスタンスのリストを入力として受取る。リストにおけるインスタンスのカウントの数を上回るものが述語を満たしていなければ、「真」をリターンする（最後に満たすリストにおけるエントリ、または「（）」であれば「Ｔ」）。そうでなければ、ＡＴ．ＭＯＳＴファンクションは「偽」をリターンする（空のリスト）。ＣＨＡＩＮＥＤ．ＩＮＳＴＡＮＣＥ．ＶＡＬＵＥＳファンクション３３０は始めのアーギュメントとして最適のパスを備えるアイテムネームまたはセットネームを受取り、第２のアーギュメントとしてリソースネームのリストを受取る。これは現在の文脈における所与のアイテムのインスタンスのリストまたはセットネームをリターンする。これはまた、この情報を、第２のアーギュメントにおいて与えられたリソースネームを介し元のものから到達可能なその他の同様のインスタンスすべてに対しリターンする。到達可能なインスタンスは、第２のアーギュメントにリストされたリソースのインスタンスにつながる元のインスタンスの消費および供給リンク双方をたどる結合プロセスによって配置される。これらのリソースインスタンスの消費および供給リンクが次にたどられ（エントリリンクを除く）、結び付けられたアイテムインスタンスが集められる。これらのインスタンスの消費および供給リンク（エントリリンクを除く）は次にリストされたリソースなどのインスタンスにつながるところでたどられる。このプロセスはたどるべき消費または供給リンクがなくなるまで続けられる。ＣＨＡＩＮＥＤ．ＩＮＳＴＡＮＣＥ．ＶＡＬＵＥＳファンクションは、ストリングにおけるすべてのものを発見する上で有用である。ストリングは文脈的に駆動され、リストによって決定または規定されるのではない。インスタンスグラフは常に不安定であり、式ハンドラは文脈によりストリングを決定する。ＣＯＬＬＥＣＴファンクション３３２は、インスタンス（たとえばＰＲＯＰＥＲＴＹ．ＶＡＬＵＥ）およびインスタンスリストまたはインスタンスのリストのシリーズから何らかの値をリターンする式を入力として受取る。これは各インスタンスからの対応する値を含むリストをリターンする。ＣＯＬＬＥＣＴ．ＶＡＬＵＥＳファンクション３３４は、インスタンスおよびインスタンスリストまたはインスタンスのリストのシリーズから何らかの値をリターンする式を受取る。これは「０」または「（）」以外の値を有するすべてのインスタンスに対し各インスタンスからの対応する値を含むリストをリターンする。ＣＯＮＣＡＴファンクション３３６はリストのシリーズを受取り順次的に入力リストすべての内容を保持する単一のリストをリターンする。ＣＯＮＳＴＲＡＩＮＥＤＮＥＳＳファンクション３３８は入力として何のアーギュメントも取込まないが現在のパッカーが現在のリソースのインスタンスを配置する際に有する自由度のファンクションである数をリターンする。この数は０ないし１の範囲でなければならず、０は効果的にも制約されていないことを示し、１は非常に制約されていることを意味する。この値はパッキングされたリソースに対してのみ意味を持つ。ＣＯＵＮＴファンクション３４０はリストまたはシリーズを受取り、リストにおけるエントリの数を与える整数またはシリーズすべてにおけるエントリの全数（スプライシング）をリターンする。ＣＯＵＮＴ．ＯＦファンクション３４２は入力としてアイテムネームまたはセットネームを受取る。これはこのアイテムまたはセットのインスタンスの数をリターンする。ＣＯＵＮＴ．ＯＦ．ＯＴＨＥＲファンクション３４４はアイテムネームまたはセットネームを入力として受取る。これは式を含むアイテムのインスタンスを除く特定されたアイテムまたはセットのインスタンスの数をリターンする。ＣＯＵＮＴ．ＶＡＬＵＥＳファンクション３４６は、リストまたはシリーズを受取り、「０」または「（）」でない（ノンスプライシング）リストまたはシリーズにおけるエントリの数をリターンする。ＤＥＳＩＲＡＢＩＬＩＴＹファンクション３４８は入力としてどのアーギュメントも取込まないが、現在のリソースインスタンスの配置の現在のパッカーに対する望ましさのファンクションである数をリターンする。この数は０ないし１の範囲でなければならず、０は望ましさが適用できないことを示し、１は非常に望ましいことを示す。この値はパッキングされたリソースに対してのみ意味をもつ。ＤＩＦＦＥＲＥＮＴファンクション３５０は比較演算子である。これはインスタンスを含めて個々の値のタイプ（リストではない）の１つを比較するために使用される。単一のＤＩＦＦＥＲＥＮＴファンクションコールへのすべてのアーギュメントは同じデータタイプでなければならない。このファンクションは「（）」の値を入力において無視し、２つ以上のアーギュメント、またはアーギュメントとして使用される内容を有する単一のリストのアーギュメントを受入れる。ＤＩＦＦＥＲＥＮＴファンクションはすべてのアーギュメントが異なる値を有することを検査する（すなわち同じものが２つあることはない）。リターンされた値は入力アーギュメントのデータタイプに依存する、すなわち算術アーギュメントについて「偽」は「０」であり、「真」は「１」であり、すべてのその他のアーギュメントについて「偽」は「（）」であり、「真」はテストに成功した最後のアイテムである。ＥＶＥＲＹファンクション３５２は、述語およびインスタンスのリストまたはインスタンスのリストのシリーズを入力として受取る。これはもしリストにおけるすべてのエントリが述語を満たしていれば「真」をリターンし（最後に満たすエントリ、または「（）」であれば「Ｔ」）、または少なくとも１つが述語を満たしていなければ「偽」（空のリスト「（）」）をリターンする。ＦＩＮＤ．ＤＩＳＴＡＮＣＥファンクション３５４は入力としてリストまたはインスタンスのシリーズを受取る。これはシーケンスにおける所与のインスタンスを通し現在のインスタンスから最後のインスタンスへのパスの物理的長さをリターンする。ＨＡＳ．ＰＲＯＰＥＲＴＹファンクション３５６は、入力としてプロパティネームを受取る。これは、現在のインスタンスに特定されたプロパティがあるかどうかに従い、「真」（もしあればプロパティの値、「（）」ではない）、または「偽」（空のリスト）をリターンする。ＩＮ．ＣＯＮＴＥＸＴファンクション３５８は入力としてアイテムネームまたはセットネームおよび式を受取る。これは、名称が付けられたアイテムまたはセットの適切なインスタンスの文脈において式が評価したものをリターンする。ＩＮＣＯＭＰＡＴＩＢＬＥファンクション３６０はアイテムネームのシリーズまたはセットネームを入力として受取る。これは、シリーズにおけるエントリの１つ以上が現在の文脈に存在するかしないか次第で、「真」（もしあれば存在するエントリ、または「（）」であれば「Ｔ」）、または「偽」（空のリスト）をリターンする。ＯＦＦＵＮＣＴＩＯＮファンクション３６２は、入力としてアイテムネームまたはセットネームおよび任意のパスを受取る。これは現在の文脈において与えられたネームのインスタンスのリストをリターンし、インスタンスのない何らかのネームに対しては「（）」をリターンする。ＩＮＳＴＡＮＣＥ．ＶＡＬＵＥＳファンクション３６４は、入力としてアイテムネームまたはセットネームおよび任意のパスを受取る。これは現在の文脈において与えられたネームのインスタンスのリストをリターンする。インスタンスのないネームは無視される。パスが与えられると、インスタンスグラフにおいて調べるべきノードを特定し、式が発生するアイテムから与えられたアイテムネームに到達する。省略によってグラフの調査は下方向に開始されるが、最初のアイテムに達した後はインスタンスグラフを通して逆に上向きに進む。複雑なケースでは、「アップ」および「ダウン」というキーワードを用いて方向の変更を明確に特定する。パスが何らかのポイントでいくつかの可能なノードの１つを通して進むのであれば、可能性のリストは括弧で与えられる。ＩＳ．Ａファンクション３６６は入力としてアイテムネームまたはセットネームを受取る。これはセットにあればまたはアイテムのインスタンスであれば現在のインスタンス（「真」）をリターンする。そうでなければ「（）」をリターンする。ＯＲファンクション３６８は一連の式を受取る標準のブール接続語である。最後に調べられた式がリストまたはインスタンスであれば真について最後に調べられた式の値をリターンし、偽について空のリストをリターンし、または最後に調べられた式が数であれば偽に対し「０」をリターンする。ＭＡＸＩＭＵＭファンクション３７０は数のシリーズのリストを受取りその最大のものをリターンする。ＭＩＮＩＭＵＭファンクション３７２は数のリストまたはシリーズを受取り最小のものをリターンする。ＰＡＴＨ．ＩＮＳＴＡＮＣＥ．ＶＡＬＵＥＳファンクション３７４はアイテムネームまたはセットネームおよび任意的なパスを受取る。これはインスタンスを有さないネームを無視し現在の文脈における所与のネームのインスタンスのリストをリターンする。各インスタンスは文脈へのパスを有するため同じ回数を表わす。ＰＲＯＰＥＲＴＹ．ＶＡＬＵＥファンクション３７６はプロパティネームを受取り、現在のインスタンスからプロパティの値をリターンする。ＳＥＬＥＣＴファンクション３７８は入力として述語およびインスタンスのリストまたはインスタンスのリストのシリーズを受取る。これは述語が真である元のリストにおけるエントリを含むリストをリターンする。ＳＥＬＥＣＴファンクションはリストにおいて反復することにより動作し、述語は文脈をリストからの現在のインスタンスに結び付けた後各反復において評価される。ＳＵＭファンクション３８０は数のリストまたはシリーズを受取り、数の総和をリターンする。＋，−，＊，／＋，および／−ファンクション３８２は標準的な算術演算子である。／＋ファンクションは切上げを分割する（すなわち天井を提供する）。／−ファンクションは切捨てを分割する（すなわち床を提供する）。＝および＜＞ファンクション３８４は、インスタンスを含め個々の値のタイプの１つを比較するために規定される比較演算子である。１つのファンクションコールへのすべてのアーギュメントは同じデータタイプでなければならない。このファンクションは入力における「（）」の値を無視し、２つ以上のアーギュメント、またはアーギュメントとして使用されるであろう内容を有する１つのリストのアーギュメントを受取ることができる。＝ファンクションはすべてのアーギュメントが等しいかどうかを検査する。＜＞ファンクションは＝ファンクションの逆である。リターンされる値は入力アーギュメントのタイプに依存する、すなわち算術アーギュメントについては「偽」は「０」で「真」は「１」であり、すべての他のアーギュメントについては「偽」は「（）」であり、「真」はテストに成功した最後のアイテムである。＜，＜＝，＞＝，および＞ファンクション３８６は算術比較演算子である。これは「０」（偽）または「１」（真）をリターンする。これらのファンクションは算術アーギュメントのみについて規定される。２つ以上のアーギュメントが与えられると、値は適切な単調なシーケンスになければならない。最終的に、「，」ファンクション３８８が副次的な式をグループ分けして評価シーケンスを制御するのに使用される。リストが許されるところでは空のリストが許容できる。空のリストは総和および０のカウントを有し、ＡＮＹは「偽」であり、ＥＶＥＲＹは「真」である。ＳＥＬＥＣＴおよびＣＯＬＬＥＣＴファンクションは空のリストが与えられればそれをリターンする。上記で規定されたファンクションがアイテムネームまたはセットネームを受取るすべての場合において、セットネームを受取らずアイテムネームの対応するリストに拡張することを要求し、各アイテムへのパスが明確に述べられることを要求する同じファンクションの内部形式がある。こうしたファンクションの外部形式から内部形式への変換は自動的に実行することが可能であるが、インスタンスグラフの関連部分の構造次第では同じセットの異なるメンバに対し異なるパスが必要かもしれない。ＩＸ．インタフェースエンジン図１に戻って、インタフェースエンジン２８はディスプレイ３０を通してユーザ２６に図形的なユーザインタフェースを提供する。インタフェースエンジンはまた入力装置１４を介してユーザから入力を受取る。図形的なユーザインタフェースは、ウィンドウ、選択可能なボタン、アイコンなどのプログラミング技術においては周知である標準的な能力からなる。インタフェースエンジンはロジックエンジン３２を用いてユーザの要求の受取りを調整する。これはまたユーザの要求の結果としてのコンフィギュレーション状態をディスプレイに表示する。図形的なユーザインタフェースはおおむねコンフィギュレーションのロジックから独立したものである。これは必要であれば連続して変更または洗練化される。Ａ．データエントリ形式データエントリ形式はユーザにより特定的なアイテムに対してデータの投入のために使用されるフォーマットを規定するオブジェクトである。図１２はディスプレイに示されるデータエントリ形式の例である。この例はユニシス・コーポレイションから入手できるＵＳＲ４０００磁気ディスク周辺装置を構成するためのユーザの選択を示している。これらの形式はデータとして規定され、求められればインタフェースエンジン２８によって解釈される。データエントリ形式におけるフィールド間のリンケージおよびインスタンスグラフ３４における基礎をなすコンフィギュレータロジックはコンフィギュレータデベロッパ１０により提供されるインタフェース定義データにおいて明確に示されており、コンフィギュレータ１６のプログラムコードにおいて暗示されるのではない。可能な限りデータエントリ形式の定義はインスタンスグラフにおける特定的なアイテムを参照しない。その代わりに、インスタンスグラフからのインタフェース情報と組合された、図形的なユーザインタフェースディスプレイ（すなわちメニューのハイアラキ）を通してユーザがたどるパスから文脈的に特定については判断される。インタフェースエンジン２８は、データ駆動ユーザインタフェースに対する以下の要求をサポートする。ユーザ２６が投入する値は継続し、後のコンフィギュレータセッションにおいて修正可能である。この値を用いて新規のコンポーネントが導入され古いものが製品のセットから除去されるときにコンポーネントの交換を制御してもよい。インタフェースエンジンは、ユーザがデータをその他のコンポーネントに投入する際にディスプレイ３０に示される目に見えるコンポーネントの自動的に変化する状態をサポートする。データエントリ形式の特定的なフィールドにおけるデータの投入の意味は、インスタンスグラフの対応する変化でデベロッパが明確に特定しなければならない。ユーザの入力を受入れるデータエントリ形式のすべてのフィールドには独自の関連する「タグ」がある。このタグはフィールドに投入される値に対するネームを構成する。１組のタグおよびデータエントリ形式のインスタンスに対する関連する値はインスタンスグラフ３４にストアされる。データエントリ形式のフィールド間の相関関係は、対応するタグを参照する式によって記述される。この式はデータエントリ形式定義でストアされる。フィールドに投入される値の関係およびインスタンスグラフにおけるアイテムはまた、データエントリ形式のタグおよびアイテムネームを参照する式によって記述される。この式はアプリオリグラフにストアされる。Ｂ．カプセル再び図１を参照して、インタフェースエンジン２８は、ユーザ２６から得られた情報を表わすためにカプセルと呼ばれるオブジェクトを用いる。カプセルは、ユーザとの可能なインタラクションを表わすオブジェクトである。これは、インタフェースエンジン２８とロジックエンジン３２との間のインタフェースの実施例として用いられるデータ構造である。カプセルは、ロジックエンジンによってインスタンシエートされ得る。アプリオリグラフ２４はカプセルを含み、インスタンスグラフ３４はカプセルインスタンスを含む。カプセルは、ユーザが構成したい構成要素を選択しているときにユーザ２６にとって利用可能なインタラクションを表わす。各カプセルは、ディスプレイ３０に示されるグラフィカルユーザインタフエースのユーザ入力ウィンドウに関連する。カプセルはデータエントリ形式に結合される。これは、ユーザの入力を定義しかつ捕捉するためにＩ／Ｏモジュールとして動作する。各カプセルインスタンスは、ユーザの入力を識別する１組のタグを有する。したがって、カプセルインスタンスは、所与のユーザ／コンフィギュレータインタラクションで出されるチョイスを規定するレコードである。カプセルインスタンスは特定のユーザインタラクションから得られるデータをストアする。これは、タグのリストおよび関連する値を含む。対応するアイテムインスタンスは、インタフェースエンジン２８からのリクエストを介してロジックエンジンによって作り出される。カプセルインスタンスはインスタンスグラフにリンクされるが、対応する制御フローは有していない。図１３は、ユーザ／インタフェースエンジンインタラクションを説明するためのブロック図である。コンフィギュレータ定義１２のインタフェース定義４００は、デベロッパ１０によって規定される。これは、システムを構成する際のユーザによる可能なセレクションまたはチョイスのメニュー階層を含む。デベロッパは、どれだけの数の別々のメニューが存在するべきであるかを決定するとともに、各メニューにおいてどのようなチョイスが利用可能であるかを決定する。図１３に示すメニューおよびチョイスは例示的な目的のためだけのものである。メニュー階層のメニューとチョイスとのいかなる組合せおよび深さもデベロッパによって特定されるであろう。各リーフメニューチョイスは、アプリオリグラフ２４のカプセル４０２に対応する。カプセルは、以下の付録Ａで詳細に議論するシンタックスに従ってテクスチャの形式で特定される。これは、データエントリ形式リファレンス４０４、アイコンリファレンス４０６、および更新式４０８を含み得る。これは他のカプセルも含み得る。データエントリ形式４０４は、１つ以上のタグ付フィールドおよびアイテムリファレンス４１０を特定する。各フィールドは、ユーザにより入力される可能なデータ値を表わす。タグは、そのデータの一意の識別子である。アイテムリファレンスは、ユーザがデータを分布しようとしている適切なアイテムへのリンクである。ファイルロケーション４１２は、アイコンビットマップがコンフィギュレータシステムにストアされる場所である。インスタンス創出マップ４１４は、カプセル４０２と、デベロッパによって供給される更新式と、ユーザにより供給されるデータ入力とに基づいてインスタンスグラフ３４にアイテムインスタンスを作り出すのを制御するデータ構造である。プルダウンメニュー、アイコン、ユーザセレクションボタン等を表示するために周知のウィンドウイングソフトウェア４１６が用いられる。コンフィギュレータディスプレイ４２０のメインウィンドウを表わすためにメインウィンドウオブジェクト４１８が作り出される。可能なユーザセレクションまたはコマンドを表わすアイコン４２４を管理するために、ウィンドウイングソフトウェア４１６に種々のアイコンウィンドウオブジェクト４２２が作り出される。各アイコンは、構成され得るコンポーネントの種類を表わす。ユーザ入力の処理は以下のように進む。ユーザは、図示されるようなメニュー１４２６等のプルダウンメニューを選択する。インタフェースエンジンは、ウィンドウイングソフトウェア４１６を用いてメニュー１のチョイスを表示する。ユーザは、たとえば現在のコンフィギュレーションに特定のコンポーネントを加えるコマンドであろうチョイス１２４２８を選択する。このチョイスは対応するカプセル定義４０２を有する。インタフェースエンジンは、カプセル４０２からデータエントリ形式定義４０４を用いて、データエントリウィンドウオブジェクト４３０を作り出す。データエントリウィンドウオブジェクト４３０は、ユーザに示されるデータエントリウィンドウ４３２を管理する。ユーザは、データエントリウィンドウに表示されるボタンを選択しかつ必要に応じてテキストを入力することによってコンフィギュレーションの選択を行なう。データエントリウィンドウが表示されると、インスタンスグラフ３４にカプセルインスタンス４３３が作りだされる。このカプセルインスタンス４３３は、コンフィギュレーションに加えられているアイテムに関してユーザにより入力されたデータを保持する。カプセルインスタンス４３３に付与されたタグマップ４３４は、ユーザの入力とともに更新される。その後、ユーザにより選択されたアイテムに関してインスタンス４３６を作り出すために、インタフェースエンジン２８によってカプセルの更新式４０８が評価される。Ｘ．不変情報再び図１を参照して、「不変（persistent）」情報は、コンフィギュレータ定義１２の外部形式１８と、特定のコンフィギュレーションのインスタンスグラフ３４とを含む。インスタンスグラフデータは、ユーザによってファイルにセーブされ、後に再びロードされ得る。これは、各インスタンスに関するエントリをそのインスタンスの名前およびリンケージとともに含み、かつそれがそのインスタンスであるアプリオリオブジェクトの名前と、カプセルフィールドおよびその値とをさらに含むテキストファイル（不変データファイルと呼ばれる）の書込を伴う。セーブされた不変データファイルは、その不変データファイルがセーブ時間の時点のコンフィギュレーション状態を再び作り出すために生成されたアプリオリグラフ２４のコンテキストで再ロードされ得る。これは、ユーザがコンフィギュレータ１６を用いるセッションをほとんどいつでも中断することを可能にしかつそれを後に再開できることを可能にする。しかしながら、パッキング処理が進行中であれば、いくつかの付加的な状態情報をセーブしなればならない。コンフィギュレーションのいくつかの場所で必要とされ得るサブコンフィギュレーションを表わすためにも不変データファイルを用いることができる。ローダ２２は、１回よりも多く用いられたサブコンフィギュレーションに関するロードされたインスタンスの名前が確実に一意となるようにする。不変データファイルはまた、コンフィギュレーションが常にあるインスタンスを含んでいなければならない場合にインスタンスグラフ３４を初期化する便利な方法を与えることができる。時間が経過するに従って、所与の積の組によって支持されるコンポーネントの組はしばしば変わる。古いコンポーネントは利用不可能となる場合があり、新しいコンポーネントが導入される。古いアイテムは、それ以上利用できなくなればアプリオリグラフ２４から取除かなければならない。しかし、それらのインスタンスはまだ不変データファイルにあり、これはいつでも再ロードされ得る。そのようなローディングを成功させるために、古いアイテムは、アプリオリグラフから取除かれると、その古いアイテムに対するユーザリクエストがいかにして現在利用可能なアイテムにマップされるべきであるかを規定する規則とともに、履歴データベース（図示せず）に加えられる。ロードされている不変データファイルは、特定のカスタマーサイトに存在することが知られているコンフィギュレーションを表わす場合、古いアイテムインスタンスを翻訳せずにロードされなければならない。ロードされている不変データファイルがまだ順序付けされるべきではないコンフィギュレーションを表わす場合、ロードされた形式は現在順序付けされ得るアイテムのみを含むことができる。この場合、ローディングプロセスの間にどの古いアイテムもローダ２２によって翻訳されなければならない。宣言的に構成されたグラフと多数のインタラクトするパッカーとを用いる一般化（汎用）コンフィギュレータが開示されている。２レベル二部活性化伝播グラフは、構成されるべきオブジェクトとそれらに関連する関係との宣言的記述として用いられる。コンフィギュレータは、多数のパッキング問題がインタラクトする際に、いかなる時点でも動作するために構成問題全体から最も適切なピースをダイナミックに選択しながらなおかつ他のパッキング問題を考慮する能力を有する。コンフィギュレータは、正しいコンフィギュレーション結果を保証するためにパッキングアクティビティによって用いられる制約を宣言的に規定する能力を与える。多数のインタラクトするパッキング問題を扱う能力によって、コンフィギュレータは最適に近いコンフィギュレーションをより一貫して生成できるようになる。宣言的表現および明示制約によって与えられる高レベルビューは、以前そのようなエキスパートシステムに関連していたプログラミングスキルからコンフィギュレータを構成するアクティビティを分離する傾向がある。特殊化（専用）コンフィギュレータは宣言的に記述されるため、構成、向上および維持がより簡単である。これにより、コンフィギュレータの開発に必要とされるプログラミングスキルの量が低減され、したがって、より幅広い範囲のスキルを有する人々がアクティビティに寄与できるようになる。それと同時に、一般化された機能性は、コンフィギュレータにおいて与えられ得るカバレッジの幅を増加する。以上本発明を現在企図されているベストモードに関して説明したが、明らかに本発明には種々の変形例、種々の動作モード、および種々の実施例が可能であり、これらはすべて当業者の能力および技術の範囲内であってさらなる進歩性を伴う活動を行なわずになされるものである。したがって、特許によって保護されるべきものは、添付の請求の範囲に記載されている。付録Ａ．外部形式のシンタックスの定義以下の項目は、外部形式定義の正当なシンタックスを定義する。Ａ．１大局的定義コンフィギュレータの定義のほとんどのアスペクトはアイテム、リソース、およびそれらの関係の点から説明できるが、いくつかのアスペクトは大局的に特定しなければならない。これらのいくつかのアスペクトには以下のものがある。・インスタンスグラフの初期化・アイテムスロットからの値がアプリオリグラフのどこで生じても行なわれるそれらの値の集成・ラベルの伝播これらのアスペクトはすべて、知識ベースと呼ばれる１つの大局的オブジェクトのコンテキストで定義される。初期化初期化は、Initialization．Actions スロットによって特定される。このスロットは、たとえばコンフィギュレータの初期状態を効果的に作り出すために予め規定されたインスタンスグラフをロードすることができる式を含む。集成集成は、インスタンスグラフ中の特定の種類のすべての値を必要なときに合計するためにアクセスできるように配列する方法を与える。これは、たとえば、特定のコンフィギュレーションによって与えられる電力または熱の負荷を計算する必要がある場合に有用となり得る。この方法は、同じ名前のプロパティを有するインスタンスグラフ中のすべての関連アイテムに依存する。このプロパティの値は、標準化された単位で測定される、このアイテムのインスタンスによって与えられるこの特定の負荷の量でなければならない。集成はその後このスロットの名前を特定し、アプリオリグラフがロードされるとこのスロットを含むすべてのアイテムが通知され後に合計するために利用可能とされるという効果を有する。伝播ラベルの伝播は周辺装置のための複雑なパスの定義か、または、インスタンスグラフの１つの点でコンフィギュレータユーザによって入力された情報をフィルタ処理しかつインスタンスグラフの他の部分に伝播させなければならないという他の状況を支持する。基本的なアイデアは、インタフェースエンジンによってラベルを生成することができ、インスタンスが生成されるに従ってそれらのインスタンスにラベルを付与することができることである。このラベルはその後、伝播が起こるに従ってインスタンスグラフを介して自動的に分配され、オプションとしては、このラベルがコンフィギュレーションプロセスのアスペクトを駆動するために用いられる場合にはコンフィギュレータデベロッパの制御下で変更される。最も単純な場合には、ラベルは、識別子等の名前であってもよい。より複雑な領域では、ラベルは、マスクおよびパターンからなる構造化された値であってもよい。マスクはパターンのどの部分が現在のインスタンスに当てはまるかを規定する。パターンはこの部分のコンフィギュレーションに当てはまる名前を識別する。たとえば、二本で始まった（dual-initiated）チャネルであれば（Ｈ１Ｈ２）のパターンを有するであろう。生成の時点で、完全なレベルは（１（Ｈ１Ｈ２））であろう。伝播が進行するに従ってチャネルへの接続が分離されると、これらの２つの接続には（（１０）Ｈ１Ｈ２））および（（０１）（Ｈ１Ｈ２））というラベルが付けられるであろう。「１」は、含んでいるインスタンスに適用できるパターンのピースを表わす。マスクおよびパターンはともに任意の深さにネストされ得る。ラベルを付けられたコンシュームズ（Consumes）伝播はそれと一致するラベルを有するサプライヤ（Supplier）またはラベルを有していないサプライヤ（この場合サプライヤは入来するラベルを受取るであろう）のみに行なわれるであろう。伝播は、ラベルの値を含むプロパティを識別しかつそれらを伝播させるために用いられる。Ａ．２オブジエクトの定義｛Capsule ｜Item｜Resource｜Set ｜Package｝〈name〉外部形式中のオブジェクトは、カプセル（Capsule）、アイテム（Item）、リソース（Resource）、セツト（Set）またはパッケージ(Pa ckage)が可能である。このステートメントは、名前が付けられた種類のオブジェクトの定義を導入する。〈name〉は、定義されたオブジェクトを識別するためにコンフィギュレータデベロッパによって選択された名前である。１つ以上のCaps ule、Item、Resource、Set、またはPackageの定義ステートメントはこのステートメントの後に起こり得る。 End〈object-type〉このステートメントは、オブジェクトの定義を終了させる。End ステートメントは、各オブジェクト定義に必要である。Ａ．３カプセルの定義以下のステートメントはCapsuleの後に起こり得る。 Contains〈item-name〉｜〈capsule-name〉[,〈item-name〉｜〈capsule-name 〉]... このステートメントは、カプセルが１つ以上の指定されたアイテムおよび／またはカプセルを含むことを示す。 Icon このステートメントは、ディスプレイ上でカプセルを表わすビットマップを示す。 Data．Entry．Form このステートメントは、ユーザがカプセルの所望の特性を入力するのを可能にするデータエントリ形式を特定する。 Update．Net このステートメントは、現在のデータエントリ形式におけるコンフィギュレータユーザのセレクションによって暗示される結果のインスタンスグラフへのエントリを制御するために評価されるべき式を特定する。データエントリ形式が終了されると、この式が評価される。これは、インスタンシエートされるべきアイテムの名前と、それらに対応する量と、このデータエントリ形式との以前のインタラクションによって生成されたインスタントを取除くべきであるかどうかとを特定しなければならない。これらの目的のために、式からの情報をインタフェースエンジンに通信する３つのステートメント、すなわち、Select、Number、および Rebuildが存在する。 External〈internal-name〉[as〈new-external-name〉].. このステートメントは、このカプセルの内部で用いられる名前であって他のカプセルに利用可能にされるべき名前を定義し、オプションとしては名前が付け変えられる。 Endcapsule このステートメントは、カプセルの定義を終了させる。なお、カプセルはインスタンスグラフにおいてインスタンシエートされてもされなくてもよい。インスタンシエートされないカプセルはインスタンスが必要とされるコンテキストで参照され、この参照は、カプセルに含まれるアイテムの適切なインスタンスにアクセスするために中断される。なお、含まれるものとして挙げたアイテムは、実際には、一旦アプリオリグラフが完全にロードされると存在しなければならない。ロードプロセスによって、ロードされていないアイテムが参照されないことが確認されるであろう。Ａ．４アイテムの定義以下の項目では、SuppliesおよびConsumesは、「変更子(Modifier)」の特定を可能にする。コンフィギュレータデベロッパがそれら自身の変更子を定義しかつ参照することを可能にする一般的なシンタックスがある。Suppliesに関しては、このシンタックスは１つ以上の関連する値とともに識別子の定義を可能にし、Co nsumesに関しては、このシンタックスは対応するSuppliesにおいて定義された識別子への参照を可能にする。Consumesリファレンスの意味は、消費されたインスタンスがSuppliesステートメントにおける識別子に関連する値に従わなければならないということである。識別子の形式は２つの名前のリストであり、最初の名前が「グループ」の名前となり、２番目の名前がそのグループ内の修飾子(quali fier)となるように意図される。Suppliesリファレンスにおける値は、新しいリソースインスタンスを付与するために必要とされるたびに評価される式であり、一旦インスタンスが付与されると、その式の値は変わらない。以下のステートメントはItemの後に起こり得る。 Supplies〈resource-use〉[〈supplies-modifiers〉] このステートメントは、それを含むアイテムによって供給される指定されたリソースの量を特定する。アイテムが多数のリソースを供給すると、多数のSuppli esステートメントが与えられなければならない。アイテムの各インスタンスは挙げられたリソースをすべて供給する。 Consumes〈resource-use〉[〈consumes-modifiers〉] このステートメントは、それを含むアイテムによって消費される指定されたリソースの量を示す。アイテムが多数のリソースを消費すると、多数のConsumesステートメントが与えられなければならない。アイテムの各インスタンスは挙げられたリソースをすべて消費する。consumes-modifiersは、そのコンフィグレーションのアスペクトを制御する、リソースのプロパティを定義する。多数のconsum es-modifiersが許可される。一般的なグループ／修飾子の表示の他に、有効修飾子は、Separate、Prefer、(Mask Split)、および（Mask Extract）を含む。 Separate[until〈Property-name〉] Separateは、そうするためにはコンフィギュレーションにコンポーネントを加えなければならない場合であっても、このアイテムのインスタンスの接続を異なるリソース間で分割しなければならないことを示す。until〈Property-name〉の句は、〈Property-name〉が定義されるアイテムまで（アイテムを含む）の伝播パスで遭遇するアイテムへのSeparateの適用の範囲を制限する。 Prefer｛Separate｜〈Item-name〉｝ Preferは、必要なリソースがいずれにせよ構成される場合にはこのアイテムのインスタンス接続の分離が好ましいが、単にこの分離を達成するためだけには付加的なリソースを構成してはならないことを示す。（Mask Split）〈Label-name〉この変更子は、所与のラベルがこのインスタンスからの伝播によって生成されたインスタンスに付与される多くのピースに分割されることを意味する。生成されたインスタンスの各々には１つのピースが与えられ、それらのマスクは、それが行なわれたことを示すように調整される。たとえは、入来するラベルが（１（Ｈ１（Ｈ１Ｈ２）Ａ（）））であれば、伝播によって３つのインスタンスが生成され、それらのインスタンスにはそれぞれ（（１００）（Ｈ１（Ｈ１Ｈ２）Ａ（）））、（（０１０）（Ｈ１（Ｈ１Ｈ２）Ａ（）））、および（（００１）（Ｈ１（Ｈ１Ｈ２）Ａ（）））のラベルがつけられるであろう。（Mask Extract）〈Label-name〉この変更子は、入来するラベルのマスクがそのパターンに適用されより簡単な値を生成し、これがその後に伝播されることを示す。たとえば、入来するラベルが（（１００）（Ｈ１（Ｈ１Ｈ２）Ａ（）））であれば、得られる値はＨ１であり、入来するラベルが（（０１０）（Ｈ１（Ｈ１Ｈ２）Ａ（）））であれば、得られる値は（１（Ｈ１Ｈ２））であろう。 Classification〈superset〉〈classification-function〉アイテムにおいてClassificationステートメントが存在すると、classificati on-functionを呼出した結果によって特定されるセットにアイテムのインスタンスを入れるために生成／接続時間にこのアイテムのインスタンスを処理することが暗に呼出される。このセットがまだ存在していなければ、自動的に生成され、 supersetのサブセットにされるであろう。用いることができる予め定義されたcl assification-functionの限られた集まりがあり、これらのclassification-func tionは現在のインスタンスを含むはずであるセットの名前を戻す。 Constraints〈boolean-expression〉[,〈boolean-expression〉]… このステートメントは、それを含むアイテムのコンフィギュレーションに当て嵌まる１つ以上の制約を特定する。多数のboolean-expressionが与えられると、アイテムの各インスタンスに関してこれらの制約のすべてが満たされなければならない。 Manual Cpnstraints〈boolean-expression〉[,〈boolean-expression〉]… このステートメントは、それを含むアイテムのマニュアルコンフィギュレーションに当て嵌まる制約を特定する。これらの制約はConstraintsのもとで入力された制約よりも制限的ではないことが可能であり、これらの制約は、コンフィギュレータユーザが手動でアイテムの配置を制御する場合に、それらの制約の代わりに用いられる。 Enable〈boolean-expression〉このステートメントは、付与されたパッカーの選択プロポーザに提案を発生させることを可能にするＴまたはＮＩＬを戻す式を特定する（値がＮＩＬであれば、提案は発生されない）。このステートメントは、他のパッカーがインスタンスグラフのいくつかの前もって必要な部分を構成してしまうまで選択されたパッカーの動作を延期する手段を与える。 Property〈Property-name〉〈property-value〉[,〈property-name〉〈Property -value〉]… このステートメントは、アイテムに関してProperty-valueを特定する。コンフィギュレータデベロッパは、コンフィギュレータの要求を満たすために自由にpr operty-nameを規定する。property-valueは番号またはストリングであることが可能である。 Packer このプロパティは、配置の機能性を支持するために予め定義され、再利用してはならない。Property-valueは、このアイテムに関するパッキング能力を与えるオブジェクトの名前を特定する。 Aggregated このプロパティは、このアイテムによって消費されるリソースが、（別の場合に当て嵌まるであろう、特定の数の別々のインスタンスによってではなく）適切なカウントとともに１つの集成されたインスタンスによって表わされるべきであることを示す。このプロパティは、多くのアイテムがリクエストされる可能性がある場合に用いることができ、インスタンスグラフに関して空間および時間の含意を有する。 Beginner.Completer Ender.Completer これらのプロパティは、特殊目的用「チェーニング（chaining）」パッカーによって構成されるアイテムのチェーンの始めおよび終わりで（それぞれ）用いられるべきアイテムの名前を特定する。Beginner.Completerは、リストの形をとることが可能である。このリストの要素は、リクエストを出しているリソースとは別に動作しながら、チェーンの始めで構成されるべきコンポーネントをシーケンシャルに識別する。このリストのコンポーネントはそれ自体がリストであることが可能であり、これは、内部リストの要素はパラレルに構成されるべきであり、先行するエントリのリソースに付与されることを意味する。 Limit〈numeric-expression〉 Limit式は、構成できる含有アイテムの最大数の計算を特定する。 Absolute.Limit Absolute.Limit式は、いかなる環境下でも超えることができないアイテムの量を特定する。 Enditem このステートメントは、アイテムの定義を終了させる。Ａ．５リソースの定義ほとんどの場合、リソースは、アイテムのSuppliesおよびConsumesの節で言及されることによって暗に定義される。いくつかの環境下では、リソースのいくつかの特性を明示的に記述する必要がある場合もある。これはResourceステートメントを特定することによって達成される。このステートメントの後には、Suppli es、Consumes、またはPropertyステートメントが続き得る。 Supplies〈resource-use〉このステートメントは、それを含むリソースによって供給される指定されたアイテムの量を特定する。リソースが多数のアイテムを供給する場合、多数のSupp liesステートメントを与えなければならない。リソースの各インスタンスは挙げられたアイテムをすべて供給する。 Consumes〈resource-use〉このステートメントは、それを含むリソースによって消費される指定されたアイテムの量を特定する。リソースが多数のアイテムを消費する場合、多数のCons umesステートメントを与えなければならない。リソースの各インスタンスは挙げられたアイテムをすべて消費する。 Property〈Property-name〉〈Property-value〉有効な〈Property-name〉は以下のとおりである： Combination-rule Combination-ruleは、その〈Property-value〉としてmaximumを有することが可能である。多数のアイテムからくる１つの種類のリソースに関する要件は、デフォルトにより、加算によって組合される。このプロパティはその規則に優先するものであり、代わりに最も大きい１つの値をとることによって要件を組合せなければならないことを示す。 Positional このプロパティは、これらのリソースインスタンスのコンテナ内での配置が重要であることを示す。 Reusable このプロパティは、１回の使用で消費される１つのリソースの通常の手順に反するものとして、リソースを使い果たすことなく複数回再利用できることを示す。 No.Group このプロパティは、インスタンスグラフで伝播が起こると、このリソースのインスタンスが、パッキングの待ち行列に入れられる場合に他のリソースのインスタンスとともにグループ分けされるべきではないことを示す。これにより、所与のアイテムからのこのプロパティを有するリソースのインスタンスがすべてパッカーによって独立して扱われるという効果がある。 Into.Dev このプロパティは、「ケーブル（Cable）」パッカーに関して、（コンポーネントから出て来るのではなく）コンポーネントの「中へ」入ると考えられるべきである接続を識別する。 Endresource このステートメントは、リソースの定義を終了させる。Ａ．６セットの定義 Setは、アイテムの集まりである。その目的は、システムのコンフィギュレーションが進むに従って現在の要求に応じていくつかの類似したアイテムから１つのアイテムを選択できるようにすることである。これは、コンフィギュレーションプロセスの間に要求が変わるとその選択を再度行なうことができるようにする。定義は、Setの要素であるアイテムのリストである。ロード時間にこの定義に遭遇する効果は、これらのアイテムへのアプリオリグラフコンシュームズ（cons umes）／サプライズ（Supplies）リンクがセットに行くようにおよびセットから出ていくようにされることである。最初のリンクはセーブされ、Set．Consumes およびSet．Suppliesという名前が付けられる。セットはロジックエンジンおよびパッキングエンジンによって処理される。Setは次のように定義される。 Contains〈Item-name〉,〈Item-name〉,... Endset Ａ．７リソースーユーズ（Resource-use）の定義 Resource-useは以下のように特定される。〈Count-spec〉｛〈Resource-name〉｜〈Item-name〉｝ Resource-useが許可されると、その形式は（アイテムの）リソースのまたは（リソースの）アイテムの名前および数値カウントである。〈Count-spec〉と〈Re source-name〉または〈Item-name〉とは、適切な種類の値を戻す一般的な式であることが可能である。〈Count-spec〉がゼロであるか、〈Resource-name〉または〈Item-name〉が空であれば、インスタンスは生成されず、この接続において伝播は起こらない。式が用いられるとき、インスタンスグラフの伝播が所与のインスタンスに関してこれらの式を最初に必要とする際にこれらの式はその所与のインスタンスに関して評価され、これらの式が依存する条件が変わっても、これらの式はその後自動的には再評価されない。付録Ｃ．用語集アーク：グラフ中のノード間の接続。リンケージポインタによってコンフィギュレータソフトウェアにおいて実現される。アーギュメント：ファンクションに送られるパラメータ。バインディング：（または「再結合（Re-bound）」）変数と値との関連。変数を再結合することは、その変数に新しい値を与えることである。二部：（グラフに適用される場合）すべてのアークが一方の種類のノードを他方の種類のノードに結合するような２つの異なる種類のノードからなる。コンポーネント：順序付けされなければならないおよび／またはコンフィギュレーションプロセスに影響を及ぼす識別可能なオブジェクト（通常このコンテキストではハードウェアのピースである）。コンフィギュレーション：（１）ユーザのリクエストを満足するために必要とされるコンポーネントの集まり。（２）（１）を構成するプロセス−より正確には、「コンフィギュレーションプロセス」。制約：それによってコンポーネントを構成することができる普遍性に対する制限−たとえば、キャビネットは制限された量の占有可能な空間しか与えない。１つの制約はいくつかのコンポーネントを関わらせることが可能であり、１つのコンポーネントはいくつかの制約を有し得、１つ以上のコンポーネントに対する多数の制約は複雑な方法でインタラクトすることが可能である。消費：このコンテキストでは、別のアイテムに依存する１つのアイテムが他のアイテムのリソースのいくつかを使い果たすプロセス（ｃｆ．供給）。コントロール（制御）：プログラムの実行において、制御点は実行されている命令またはステートメントである。活性化伝播では、これは、伝播において達した最新のノードである。デッドロック：１つのプログラムアクティビティが何らかのケイパビリティＡを獲得しておりかつＢを必要とし、別のプログラムアクティビティがケイパビリティＢを獲得しておりかつＡを必要とする状況。これらのプログラムアクティビティのうちの一方または両方がその獲得しているケイパビリティを手放すまでこれらのアクティビティによってさらなる動作は行なわれない。宣言的：プロセスに関してではなく状態に関して定義が与えられるシンタックスの形式。これは、デペロッパがプログラムのシーケンシャルなロジックを定義しなくてもよいようにする。評価：式を解釈してそのリターン値を生成する際に式ハンドラによって行なわれるプロセス。実行：プログラムを実行するまたは式を解釈するプロセス。式：何らかの必要とされる結果を出すために評価することができるファンクションコールおよびアーギュメントの組合せ。「（＋１２）」は単純なプレフィックスフォーム式であり、その結果は３である。式ハンドラ：式を評価してそのリターン値を出すことができるプログラム。フロー：コントロールが１つの命令、ステートメントまたはノードから別の命令、ステートメントまたはノードに移動するとき、これは、特に点のより長いシーケンスをフローするといわれる。全体を括弧でくくられた：いくつかの表記では、評価シーケンスの一部分を明示的にではなく慣習によって定義した式を書くことが可能であり、たとえば、（１＋２＊３）は慣習的には９ではなく７を意味するとして理解される。全体を括弧で括られた形式では、すべての順序付けが明示的であり、たとえば、上述の式であれば（１＋（２＊３））と書かれるであろう。ファンクション：わずかなアーギュメントを受入れそれらを用いてリターン値を生成するプログラム。ファンクションコール：（１）ファンクションを入力するコントロールフローのプロセス。（２）（１）を起こす書込まれたコード。関数型言語：値を戻すファンクションコールを用いてすべての作業が行なわれるプログラミング言語のスタイルであり、多くのアクションがリターン値を与えずしたがって構成され得ないステートメント言語に対するものである。文法：いかにして言語の要素を組合せることができるかを定義する１組の規則。式文法は、いかにして元の値を正当な式に組合せることができるかを定義する。宣言的文法の存在により、プログラムコード以外によって計算を記述する可能性ができる。グラフ：双方向アークによって相互接続されるノードのネットワークであり、このコンテキストでは、典型的には、矩形または楕円形としてのノードと、ノードを接続する線としてのアークとで描かれる。アイテム：本明細書のコンテキストでは、コンポーネントを表わすグラフ中のノードであり、矩形として描かれる。正当な：すべての定義された制約およびリソースの制限によって許可されるアクション。コンフィギュレーションに関しては、システムは構成されることができ、これがグラフによって定義される程度まで作業するであろう。リンケージ：１つのオブジェクトを他方のオブジェクトから見つけ出すのが容易となるような２つのオブジェクト間の接続。通常、ポインタによって実現される（ｃｆ．二方向リンケージ）。リスト：不定の長さの値の順序付けられた集まりであり、慣習的にはたとえば（ＡＢＣ）のように括弧で囲んで書く。リストはリストを含むことができる。リテラル：たとえば数字または文字のストリングのようなそれ自身を表わす値のためのプログラミング用語。プログラムの実行状態に依存して、異なる時間に異なる値を表わす名前である変数とは対照的である。ローディング：永久的なファイル記憶装置から情報を読出し、その情報をプログラムでの使用のためにメモリ内で利用可能にするプロセス。単純なコピープロセスであることが可能であり、または、変形およびリンケージの構成を伴い得る。ルックアヘッド：このコンテキストでは既に仮になされている選択の予測可能な不利な結果があるかどうかを判断するために、その選択の暗示を詳細に調べるプロセス。最適に近い：満足がいくのに十分なほどよいこと。必ずしも理想であるわけではないが（しかし、理想である可能性がかなり高い）、すべての明白な問題を回避し、ほとんどの人間が達成できるであろうよりも良い。その他の場合は「満たす（満足する）」と呼ぶ。（ｃｆ．準最適の）ネストされる：関数型言語の式に適用される。１つの式が別の（副）式をその中に含み得ることを意味する。「任意にネストされる」は、たとえば（１＋２＊（３／（４−５））））のようにネスティングが所望の回数だけ何回でも起こり得ることを意味する。ノード：いくつかのアークが出会うグラフ中の点。オブジェクトによりコンフィギュレータソフトウェアにおいて実現される。オブジェクト：有用な抽象化を与えるデータおよびコードのカプセル化のためのソフトウェア用語。パッキング：（１）なんらかの適合度の基準（通常最適な方法にできるだけ近い）に基づいて、関係を左右する制約を満足するように別のコンポーネントに関してコンポーネントの何らかの組を配列するプロセス。（２）（１）の結果。パッキングバウンダリ：コンフィギュレーションパッキングプロセスの特徴は、もう１つのコンポーネントを加えても通常はその結果に大きな変化が現われないことである。もう１つのコンポーネントを繰返し加えると、結果的には大きな変化が現われるであろう（たとえば、キャビネットが一杯になり、したがって新しいキャビネットを構成しなければならなくなる）。大きな変化が必要とされる点がパッキングバウンダリである。パラダイム：パターン、例、またはモデル。コントロールパラダイムはプログラム（のピース）の全体的な制御構造であり、いかにしてプログラムの異なる部分が関連し合うか、およびどのようなアクションの組合せが可能であるかを定義する。パラメータ：何らかの動作を制御するエンティティ。ファンクションに送られ、ファンクションの動作に基づいて動作するまたはそれを制御するデータのピースである場合もある。構文解析される：その元の形態から、コンピュータ化された処理のために有用な構成要素に解析される。区分される：いくつかのピースに分割される。プログラミング技術の一部分は、それぞれの個々のピースが密接に結びつきそれだけで意味をなすように、かつ、これらのピース全体が取組まれている問題を解決するように機能およびデータを区分することである。プレフィックスフォーム：慣習的には、算術式はインフィックス形式で書かれ、この場合、たとえば（１＋２）のように演算子はそれが適用される値の間に生じる。全体を括弧でくくられたシンタックスでは、たとえば（＋１２）のように演算子をその演算子が適用されるすべての値の前におくことができる。これは、たとえば（＋１２３４）のように不定数の値に１つの演算子を適用することができるという利点と、値の数が予めわかっていなくてもよいという利点とを有する。処理シーケンス：処理動作が行なわれる固定された順序。伝播：活性化伝播におけるコントロールフローの進行を示しており、コントロールの場所（locus）がグラフ中をノードごとに伝播する。プロパティ：オブジェクトに関連する値。典型的には、プロパティは、参照する際に用いられる名前と、その名前に関連する可変の値とを有する。オブジェクトの定義特性のうちの１つは、そのオブジェクトが含むプロパティの組である。リパック：ユーザによって直接リクエストされなかったすべてのインスタンス（すなわち、これらのインスタンスを支持するように構成されたインスタンス）をインスタンスグラフから取除き、残りのインスタンスの伝播およびパッキングを再実行して新しい全体のコンフィギュレーションを生成すること。これにより、通常、インスタンスが処理されるシーケンスを選択するのにシステムが有する自由のため、より最適なコンフィギュレーションが生成される。表現：定義されたフォーマットに従ういくつかのデータにコードを適用することによってプログラムが実世界で値の結果を生成することができるようにする、コンピュータプログラムにおいてデータフォーマットおよびコードで実現される１組の概念。選択された表現は、プログラムの適用可能性の範囲を決定する。リソース：本明細書のコンテキストでは、それ自体はコンポーネントではないがコンポーネントのコンフィギュレーション（たとえばカードケージのスロット）に影響を及ぼす、アイテムにより供給され消費されるケイパビリティ。リターン：ファンクションの実行の最終ステージ。制御のフローは、ファンクションの実行が呼出されたポイントに戻り、ファンクションの結果である値はそのポイントに送り戻される。活性化伝播：処理がグラフのあるノードから始まり、そこから、アークによって開始ノードに直接接続されるノードに移動し、そこから、直接接続されるノードのその次の組に移動する（エントリのアークは無視する）等の制御パラダイム。準最適の：一般にはかなり明白な態様で、「最適に近い」の基準には達しないこと。供給：このコンテキストでは、１つのアイテムが他のアイテムによって必要とされるリソースを与えるプロセス（ｃｆ．消費）。シンタックス：情報を表現することができ、この情報が、典型的には予め定義されたキーワードを含み、必要に応じてユーザにより埋めることができるホルダを配置する言語形式。二方向リンケージ：いずれか一方のオブジェクトを他方のオブジェクトから見つけ出すことが容易であるような２つのオブジェクト間の１対の接続（ｃｆ．リンケージ）。重み：プログラムにおいて所望性または相対的な重要性を表わすために用いられる数値。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＪＰ (72)発明者グスリング，トーマス・アールアメリカ合衆国、55306 ミネソタ州、バーンズビル、バタームート・レーン、 15012 (72)発明者ネイグル，ティモシー・イーアメリカ合衆国、55425 ミネソタ州、ブルーミントン、イー・オールド・シュコッピー・ロード、1641 【要約の続き】きる。本発明によって、パッキングエンジンにより使用される制約を宣言的に定義する能力が得られ、確実に正しいコンフィギュレーションが得られるようになる。

Claims

【特許請求の範囲】１．接続されたコンポーネントからなる有効コンフィギュレーションを発生するためのエキスパートシステムであって、コンフィギュレータデベロッパにより宣言的に特定されるコンポーネントの定義を記憶するためのアプリオリデータベース手段を含み、前記コンポーネントの定義およびそれらの使用について暗示される要件が第１の二部グラフにおけるノードとして表わされ、さらにコンフィギュレータユーザによって対話的に選択される前記アプリオリデータベース手段において定義されるコンポーネントのインスタンスを記憶するためのインスタンスデータベース手段を含み、前記インスタンスおよび前記インスタンス間の相互接続が第２の二部グラフにおけるノードとして表わされ、さらに前記アプリオリデータベース手段と前記インスタンスデータベース手段とに結合されて前記コンフィギュレータユーザからの選択されたコンポーネントを構成する要求を受け入れ、前記要求を前記アプリオリデータベース手段により記憶される前記コンポーネントの定義にマッチングさせ、前記アプリオリデータベース手段における前記コンポーネントの定義および以前のコンフィギュレータユーザによる要求に基づき前記インスタンスの創出および接続が有効であれば、前記選択されたコンポーネントの前記インスタンスを創出しかつ接続し、かつ前記要求から生じるコンフィギュレーションをコンフィギュレータユーザに報告するための処理手段とを含む、エキスパートシステム。２．前記アプリオリデータベース手段に結合されてコンフィギュレータデベロッパにより特定される前記コンポーネントの定義をテキストベースの外部フォーマットからグラフベースの内部フォーマットへ変換しかつグラフベースの内部フォーマットにおいて表わされる前記コンポーネントの定義を前記アプリオリデータベース手段へロードするためのローダ手段をさらに含む、請求項１に記載のエキスパートシステム。３．前記処理手段に結合されて、コンフィギュレータユーザからの選択されたコンポーネントを構成する前記要求を受け入れ、前記要求を前記処理手段へ転送し、かつ前記処理手段から受けたコンフィギュレーションをコンフィギュレータユーザに対し表示するためのインタフェース手段をさらに含む、請求項２に記載のエキスパートシステム。４．前記ローダ手段および前記処理手段によって参照されるネット定義知識ベース手段をさらに含み、前記ネット定義知識ベース手段は前記コンポーネントの定義を表わし得る各タイプのオブジェクトに関連する少なくとも１つの知識を有する、請求項３に記載のエキスパートシステム。５．前記処理手段が、前記第１および第２の二部グラフに固有のノード間の関係を分析することによって前記選択されたコンポーネントを接続する前記要求の有効性を決定する、請求項４に記載のエキスパートシステム。６．接続されたコンポーネントからなる完全で、有効で、最適に近いコンフィギュレーションを発生するためのコンフィギュレータエキスパートシステムであって、前記コンフィギュレータエキスパートシステムはコンフィギュレータデベロッパにより所与のコンフィギュレーションドメインについてカスタマイズされておりかつコンフィギュレータユーザにより作動されて、ユーザの要求と、コンポーネントの定義に含まれる予め定められたコンポーネントの要件および接続の制約に基づきコンフィギュレーション解答を発生し、前記コンフィギュレータエキスパートシステムは、前記コンフィギュレータデベロッパにより宣言的に特定されるコンポーネントの定義を含むアプリオリデータベースを含み、前記コンポーネントの定義およびそれらの使用について暗示されている要件が第１の二部グラフにおけるノードとして表わされ、さらにコンフィギュレータユーザにより対話的に選択される前記アプリオリデータベースにおいて定義されるコンポーネントのインスタンスを含むインスタンスデータベースを含み、前記インスタンスおよび前記インスタンス間の相互接続が第２の二部グラフにおけるノードとして表わされ、さらに前記アプリオリデータベースと前記インスタンスデータベースとに結合されたロジックエンジンを含み、前記ロジックエンジンが前記コンフィギュレータユーザからの選択されたコンポーネントを接続する要求を受け入れて、前記要求を前記アプリオリデータベースに記憶される前記コンポーネントの定義にマッチングし、前記インスタンスの創出および接続が前記アプリオリデータベースにおける前記コンポーネントの定義および以前のコンフィギュレータユーザの要求に基づき有効であれば、前記インスタンスデータベースにおける前記選択されたコンポーネントの前記インスタンスを創出しかつ接続し、かつ前記要求から生じるコンフィギュレーションを前記コンフィギュレータユーザに報告する、コンフィギュレータエキスパートシステム。７．前記アプリオリデータベースに結合されて、前記コンフィギュレータデベロッパにより特定される前記コンポーネントの定義をテキストベースの外部フォーマットからグラフベースの内部フォーマットに変換し、かつ前記グラフベースの内部フォーマットにおいて表わされる前記コンポーネントの定義を前記アプリオリデータベースへロードするためのローダモジュールをさらに含む、請求項６に記載のコンフィギュレータエキスパートシステム。８．前記ローダモジュールと前記ロジックエンジンとに結合されたインタフェースモジュールをさらに含み、前記インタフェースモジュールが前記コンフィギュレータデベロッパから前記コンポーネントの定義を受け、前記コンポーネントの定義を前記ローダモジュールへ転送し、前記コンフィギュレータユーザから選択されたコンポーネントを接続する前記要求を受け入れ、前記要求を前記ロジックエンジンへ転送し、かつ前記ロジックエンジンから受けたコンフィギュレーションをコンフィギュレータユーザに対し表示する、請求項７に記載のコンフィギュレータエキスパートシステム。９．前記ローダモジュールおよび前記ロジックエンジンが参照するネット定義知識ベースをさらに含み、前記ネット定義知識ベースが前記コンポーネントの定義を表わし得るオブジェクトのタイプに関連する少なくとも１つの知識を有する、請求項８に記載のコンフィギュレータエキスパートシステム。１０．前記ロジックエンジンが前記第１および第２の二部グラフに含まれるノード間の関係を分析することによって前記選択されたコンポーネントを接続する前記要求の有効性を決定する、請求項９に記載のエキスパートシステム。１１．接続されて、コンピュータシステムを形成するコンポーネントの有効コンフィギュレーションを発生するためのコンフィギュレータエキスパートシステムであって、コンフィギュレータデベロッパにより宣言的に特定されるコンピュータシステムコンポーネントの定義を記憶するためのアプリオリデータベース手段を含み、前記コンポーネントの定義およびそれらの使用について暗示される要件が第１の二部グラフにおけるノードとして表わされ、さらにコンフィギュレータユーザにより対話的に選択される前記アプリオリデータベース手段において定義されるコンピュータシステムコンポーネントのインスタンスを記憶するためのインスタンスデータベース手段を含み、前記インスタンスおよび前記インスタンス間の相互接続が第２の二部グラフにおけるノードとして表わされ、さらに前記アプリオリデータベース手段と前記インスタンスデータベース手段とに結合されて、前記コンフィギュレータユーザからの、選択されたコンピュータシステムコンポーネントを構成する要求を受け入れ、前記要求を前記アプリオリデータベース手段により記憶される前記コンピュータシステムコンポーネントの定義にマッチングさせ、前記インスタンスの創出および接続が、前記アプリオリデータベース手段における前記コンピュータシステムコンポーネントの定義および以前のコンフィギュレータユーザの要求に基づき有効であれば、前記インスタンスデータベース手段における前記選択されたコンピュータシステムコンポーネントの前記インスタンスを創出および接続し、かつ前記要求より生じるコンフィギュレーションを前記コンフィギュレータユーザに報告する、コンフィギュレータエキスパートシステム。１２．前記アプリオリデータベースに結合されて、前記コンフィギュレーションデベロッパにより特定される前記コンピュータシステムコンポーネントの定義をテキストベースの外部フォーマットからグラフベースの内部フォーマットへ変換し、かつグラフベースの内部フォーマットにおいて表わされる前記コンピュータシステムコンポーネントの定義を前記アプリオリデータベース手段にロードするローダ手段をさらに含む、請求項１１に記載のコンフィギュレータエキスパートシステム。１３．前記処理手段に結合されて、前記コンフィギュレータユーザからの選択されたコンピュータシステムコンポーネントを構成する前記要求を受け入れ、前記要求を前記処理手段へ転送し、かつ前記処理手段から受けたコンフィギュレーションを前記コンフィギュレータユーザに対し表示するインタフェース手段をさらに含む、請求項１２に記載のコンフィギュレータエキスパートシステム。１４．前記ローダ手段と前記処理手段とに結合されたネット定義知識ベース手段をさらに含み、前記ネット定義知識ベース手段は前記コンピュータシステムコンポーネントの定義を表わし得る各タイプのオブジェクトに関連しかつ前記ローダ手段および前記処理手段によって参照される少なくとも１つの知識を有する、請求項１３に記載のコンフィギュレータエキスパートシステム。１５．前記処理手段が前記第１および第２の二部グラフに固有のノード間の関係を分析することによって前記選択されたコンピュータシステムのコンポーネントを接続する前記要求の有効性を決定する、請求項１４に記載のコンフィギュレータエキスパートシステム。１６．接続されたコンポーネントからなる完全で、有効で、最適に近いコンフィギュレーションを発生するためのコンピュータベースのコンフィギュレータエキスパートシステムであって、前記コンフィギュレータエキスパートシステムはコンフィギュレータデベロッパによる所与のコンフィギュレーションドメインについてカスタマイズされており、かつコンフィギュレータユーザにより作動されて、コンフィギュレータユーザの要求、予め定められたコンポーネントの要件およびコンポーネントの定義に含まれる接続の制約に基づきコンフィギュレーションの解答を発生し、前記コンフィギュレータエキスパートシステムは、前記コンフィギュレータデベロッパにより宣言的に特定されるコンポーネントの定義を表わすことができるアプリオリデータベースを含み、前記コンポーネントの定義が前記コンポーネント定義の使用によって暗示されるリソースに論理的に結合されて第１の活性度伝播二部グラフを構成し、さらに前記コンフィギュレータユーザにより対話的に選択された前記アプリオリデータベースにおいて定義されるコンポーネントのインスタンスを表わすことができるインスタンスデータベースを含み、前記インスタンスが前記暗示されたリソースのインスタンスに論理的に結合されて第２の二部グラフを構成し、かつさらに前記アプリオリデータベースと前記インスタンスデータベースとに結合されたロジックエンジンを含み、前記ロジックエンジンが前記コンフィギュレータユーザからの選択されたコンポーネントを接続する要求を受け入れ、前記要求を前記第１の活性度伝播二部グラフにおける前記コンポーネントの定義にマッチングし、前記インスタンスの創出および接続が前記コンポーネントの定義および以前のコンフィギュレータユーザの要求に基づき有効であれば前記選択されたコンポーネントの前記インスタンスを創出かつ接続し、有効性が前記第１の活性度伝播二部グラフおよび前記第２の二部グラフに含まれるノード間の関係を分析することによって決定され、かつ前記要求から生じるコンフィギュレーションを前記コンフィギュレータユーザに対し報告する、コンピュータベースのコンフィギュレータエキスパートシステム。１７．前記アプリオリデータベースに結合されるローダモジュールをさらに含み、前記ローダモジュールが前記コンフィギュレータデベロッパにより宣言的に特定される前記コンポーネントの定義をテキストベースの外部フォーマットから前記第１の活性度伝播二部グラフベースの内部フォーマットに変換し、かつ前記第１の活性度伝播二部グラフベースの内部フォーマットにおいて表わされる前記コンポーネントの定義を前記アプリオリデータベースへロードする、請求項１６に記載のコンピュータベースのコンフィギュレータエキスパートシステム。１８．前記ローダモジュールと前記ロジックエンジンとに結合されたインタフェースモジュールをさらに含み、前記インタフェースモジュールが前記コンフィギュレータデベロッパからの前記コンポーネントの定義を受け入れ、前記コンポーネントの定義を前記ローダモジュールへ転送し、前記コンフィギュレータユーザからの選択されたコンポーネントを接続する前記要求を入力装置を介して受入れ、前記要求を前記ロジックエンジンへ転送し、かつ前記ロジックエンジンから受けたコンフィギュレーションを表示手段上にコンフィギュレータユーザに対し表示する、請求項１７に記載のコンピュータベースのコンフィギュレータエキスパートシステム。１９．前記ローダモジュールと前記ロジックエンジンとにより参照されるネット定義知識ベースをさらに含み、前記ネット定義知識ベースが前記コンポーネントの定義を表わし得るタイプのオブジェクトに関連する少なくとも１つの知識を有する、請求項１８に記載のコンピュータベースのコンフィギュレータエキスパートシステム。２０．接続されたコンピュータシステムを構成するコンポーネントからなる完全で、有効な、最適に近いコンフィギュレーションを発生するためのコンピュータベースのコンフィギュレータエキスパートシステムであって、前記コンフィギュレータエキスパートシステムはコンフィギュレータデベロッパにより所与のコンピュータシステムコンフィギュレーションドメインについてカスタマイズされており、コンフィギュレータユーザにより作動されてコンフィギュレータユーザの要求、予め定められたコンピュータシステムコンポーネントの要件およびコンピュータシステムコンポーネントの定義に含まれる接続の制約に基づきコンフィギュレーションの解答を発生し、さらに前記コンフィギュレータデベロッパにより宣言的に特定されるコンピュータシステムコンポーネントの定義を表わすことができるアプリオリデータベースをさらに含み、前記コンピュータシステムコンポーネントの定義は前記コンピュータシステムコンポーネントの定義を使用することにより暗示されるリソースに論理的に結合されて第１の活性度伝播二部グラフを構成し、さらに前記コンフィギュレータユーザにより対話的に選択される前記アプリオリデータベースにおいて定義されるコンピュータシステムコンポーネントのインスタンスを表わすことができるインスタンスデータベースを含み、前記インスタンスが前記暗示されたリソースのインスタンスに論理的に結合されて第２の二部グラフを構成し、さらに前記アプリオリデータベースと前記インスタンスデータベースとに結合されるロジックエンジンを含み、前記ロジックエンジンが前記コンフィギュレータユーザからの選択されたコンピュータシステムコンポーネントを接続する要求を受け入れ、前記要求を前記第１の活性度伝播二部グラフにおける前記コンピュータシステムコンポーネントの定義とマッチングさせ、前記インスタンスの創出および接続が、前記コンピュータシステムコンポーネントの定義および以前のコンフィギュレータユーザの要求に基づき有効であれば、前記第２の二部グラフにおける前記選択されたコンピュータシステムコンポーネントの前記インスタンスを創出しかつ接続し、有効性が前記第１の活性度伝播二部グラフおよび前記第２の二部グラフに固有のノード間の関係を分析することによって決定され、かつ前記ロジックエンジンがさらに前記要求から生じるコンフィギュレーションをコンフィギュレータユーザに報告する、コンピュータベースのコンフィギュレータエキスパートシステム。２１．前記アプリオリデータベースに結合されたローダモジュールをさらに含み、前記ローダモジュールが前記コンフィギュレータデベロッパにより宣言的に特定される前記コンピュータシステムコンポーネントの定義をテキストベースの外部フォーマットから前記第１の活性度伝播二部グラフベースの内部フォーマットに変換し、前記第１の活性度伝播二部グラフによる内部フォーマットにおいて表わされるコンピュータシステムコンポーネントの定義を前記アプリオリデータベースへロードする、請求項２０に記載のコンピュータベースのコンフィギュレータエキスパートシステム。２２．前記ローダモジュールと前記ロジックエンジンとに結合されたインタフェースモジュールをさらに含み、前記インタフェースモジュールが前記コンフィギュレータユーザからの選択されたコンピュータシステムコンポーネントを接続する前記要求を入力装置を介して受け入れ、前記要求を前記ロジックエンジンに転送し、前記ロジックエンジンより受けたコンフィギュレーションを表示手段上に前記コンフィギュレータユーザに対し表示する、請求項２１に記載のコンピュータベースのコンフィギュレータエキスパートシステム。２３．前記ローダモジュールおよび前記ロジックエンジンにより参照されるネット定義知識ベースをさらに含み、前記ネット定義知識ベースは前記コンピュータシステムコンポーネントの定義を表わし得る各タイプのオブジェクトに関連する少なくとも１つの知識を有する、請求項２２に記載のコンピュータベースのコンフィギュレータエキスパートシステム。２４．前記インタフェースモジュールが前記コンフィギュレータユーザからの入力を受け入れかつ前記コンフィギュレータユーザに対しアイコン、メニュー、データエントリウィンドウを表示するためのグラフィカルユーザインタフェースをさらに含む、請求項２３に記載のコンピュータベースのコンフィギュレータエキスパートシステム。２５．前記エキスパートシステムが前記第１の活性度伝播二部グラフおよび前記第２の二部グラフのコンフィギュレーション知識に基づきノンルールベースシステムアーキテクチャを利用する、請求項２４に記載のコンピュータベースのコンフィギュレータエキスパートシステム。２６．前記アプリオリデータベースがテキストエディタおよび前記ローダモジュールを介して前記コンフィギュレータデベロッパにより宣言的に定義、修正、更新または維持され得る、請求項２４に記載のコンピュータベースのコンフィギュレータエキスパートシステム。２７．前記インスタンスデータベースが、前記インタフェースモジュールを介して前記コンフィギュレータユーザにより修正、更新かつ維持され得る、請求項２６に記載のコンピュータベースのコンフィギュレータエキスパートシステム。２８．接続されたコンポーネントからなる完全で、有効で最適に近いコンフィギュレーションを発生するためのコンピュータにより実現される方法であって、各コンポーネントがコンポーネントの定義によって記述可能であり、前記方法が、（ａ）構成されるコンポーネントを宣言的に定義するステップと、（ｂ）前記コンポーネントの定義とそれらの使用によって暗示されるリソースとを第１の活性度伝播二部グラフにおけるノードとして表わすステップと、（ｃ）コンフィギュレータユーザからの選択されたコンポーネントを構成する要求を受け入れるステップと、（ｄ）前記要求に応答して、前記選択されたコンポーネントのインスタンスと前記第１の活性度伝播二部グラフにおいて定義される前記リソースとを第２の二部グラフにおけるノードとして創出および接続するステップと、（ｅ）前記コンポーネントの定義、以前のコンフィギュレータユーザの要求および前記第２の二部グラフの現在の状態に基づき前記インスタンスの創出および接続が有効であるかどうかを決定するステップと、（ｆ）前記インスタンスの前記創出および接続が先行するステップにおいて無効であると決定された場合に前記インスタンスを前記第２の二部グラフから除去するステップと、（ｇ）前記要求により生じた前記第２の二部グラフにより表わされるコンフィギュレーションをコンフィギュレータユーザに報告するステップとを含む、コンピュータにより実現される方法。２９．前記表わすステップが、（ａ）前記コンフィギュレータデベロッパにより供給されるコンポーネントの定義のテキストベースのファイルから現在のコンポーネントの定義を得るステップと、（ｂ）前記現在のコンポーネントについて前記第１の活性度伝播二部グラフにおけるアイテムノードを創出するステップと、（ｃ）前記現在のコンポーネントを前記第１の活性度伝播二部グラフにおける他のコンポーネントに接続する際前記要件と制約とを記述する情報を前記アイテムノードにロードするステップと、（ｄ）前記現在のコンポーネントの使用により暗示されるリソースを表わす１以上のリソースノードを創出するステップと、（ｅ）前記アイテムノードを前記リソースノードおよび前記アイテムノードにより消費されるリソースを供給するいずれかの既に存在するアイテムノードに接続するステップと、（ｆ）前記コンフィギュレータデベロッパにより定義されるすべてのコンポーネントについて（ａ）から（ｅ）のステップを繰返すステップとを含む、請求項２８に記載のコンピュータにより実現される方法。３０．前記受けるステップが（ａ）グラフィカルユーザインタフェースの一部としてメニュー、アイコンおよびデータエントリウィンドウを前記コンフィギュレータユーザに対し表示するステップと、（ｂ）前記メニュー、アイコン、およびデータエントリウィンドウを介してエントりされたコマンドとデータとに応答することによってコンポーネントを構成するコンフィギュレータユーザの要求を受け入れるステップをさらに含む、請求項２８に記載のコンピュータにより実現される方法。３１．前記報告ステップが、（ａ）前記第２の二部グラフのノードをグラフィカルユーザインタフェースにより表示することができる表示物体へ変換するステップと、（ｂ）前記コンフィギュレータユーザによる観察のために前記表示物体をディスプレイ上に表示するステップとを含む、請求項２８に記載のコンピュータにより実現される方法。３２．接続されてコンピュータシステムを構成するコンポーネントからなる、完全で、有効で、最適に近いコンフィギュレーションを発生するためのコンピュータにより実現される方法であって、各コンピュータシステムのコンポーネントがコンピュータシステムコンポーネントの定義により記述可能で、前記方法が、（ａ）構成するコンピュータシステムのコンポーネントを宣言的に定義するステップと、（ｂ）前記コンピュータシステムコンポーネントの定義とそれらの使用により暗示されるリソースとを第１の活性度伝播二部グラフにおけるノードとして表わすステップと、（ｃ）コンフィギュレータユーザからの選択されたコンピュータシステムコンポーネントを構成する要求を受け入れるステップと、（ｄ）前記要求に応答して、前記第１の活性度伝播二部グラフにおいて定義される前記選択されたコンピュータシステムのコンポーネントと前記リソースのインスタンスを第２の二部グラフにおけるノードとして創出しかつ接続するステップと、（ｅ）前記コンピュータシステムコンポーネントの定義、以前のコンフィギュレータユーザの要求、および前記第２の二部グラフの現在の状態に基づき前記インスタンスの前記創出および接続が有効であるかどうかを決定するステップと、（ｆ）前記インスタンスの前記創出および接続が先行するステップにおいて無効であると決定された場合には前記インスタンスを前記第２の二部グラフから除去するステップと、（ｇ）前記要求から生じた前記第２の二部グラフにより表わされる前記コンピュータシステムコンフィギュレーションを前記コンフィギュレータユーザに対し報告するステップとを含む、コンピュータにより実現される方法。３３．前記表わすステップが、（ａ）前記コンフィギュレータデベロッパにより供給されるコンピュータシステムコンポーネントの定義のテキストベースのファイルから現在のコンピュータシステムコンポーネントの定義を得るステップと、（ｂ）前記現在のコンピュータシステムのコンポーネントについて前記第１の活性度伝播二部グラフにおけるアイテムノードを創出するステップと、（ｃ）前記現在のコンピュータシステムコンポーネントを前記第１の活性度伝播二部グラフにおける他のコンピュータシステムのコンポーネントに接続する際に、前記要求および制約を記述する情報を前記アイテムノードにロードするステップと、（ｄ）前記現在のコンピュータシステムコンポーネントの使用により暗示されるリソースを表わす１以上のリソースノードを創出するステップと、（ｅ）前記アイテムノードを前記リソースノードおよび前記アイテムノードにより消費されるリソースを供給するいずれかの既に存在するアイテムノードに接続するステップと、（ｆ）前記コンフィギュレータデベロッパにより定義されるすべてのコンピュータシステムコンポーネントについて（ａ）から（ｅ）のステップを繰返すステップとを含む、請求項３２に記載のコンピュータにより実現される方法。３４．前記受け入れるステップが、（ａ）グラフィカルユーザインタフェースの一部としてメニュー、アイコンおよびデータエントリウィンドウを前記コンフィギュレータユーザに対して表示するステップと、（ｂ）前記メニュー、アイコンおよびデータエントリウィンドウを介してエントリされるコマンドおよびデータに応答することによってコンピュータシステムコンポーネントを接続するコンフィギュレータユーザの要求を受け入れるステップとを含む、請求項３２に記載のコンピュータにより実現される方法。３５．前記報告するステップが、（ａ）前記第２の二部グラフのノードをグラフィカルユーザインタフェースにより表示することができる表示物体へ変換するステップと、（ｂ）前記コンフィギュレータユーザによる観察のために前記表示物体をディスプレイ上に表示するステップとを含む、請求項３２に記載のコンピュータにより実現される方法。３６．パッキング動作の実行によりパッキング問題を解決することによって接続されたコンポーネントからなるコンフィギュレーションを発生するためのコンフィギュレータエキスパートシステムであって、前記コンフィギュレータエキスパートシステムはコンフィギュレータデベロッパによりコンポーネントの所与のドメインについてカスタマイズされ、コンフィギュレータユーザにより作動されてユーザの要求、予め定められたコンボーネントの要件およびコンポーネントの定義により特定される接続の制約に基づきコンフィギュレーションの解答を発生し、前記コンフィギュレータエキスパートシステムは前記コンフィギュレータデベロッパにより宣言的に特定される前記コンポーネントの定義および制約の式を記憶するための第１のデータベースと、前記コンフィギュレータユーザにより対話的に選択された前記第１のデータベースにおいて定義されるコンポーネントのインスタンスを記憶するための第２のデータベースと、前記コンフィギュレータユーザからの要求を受け入れ、前記要求を前記第１のデータベースに記憶される前記コンポーネントの定義にマッチングし、前記コンポーネントの定義および以前のコンフィギュレータユーザの要求に基づき創出および接続が有効であれば前記第２のデータベースにおける選択されたコンボーネントのインスタンスを創出および接続し、かつ前記要求から結果として生じるコンフィギュレーションを前記コンフィギュレータユーザに対し報告することができる処理モジュールとを有し、前記コンフィギュレータエキスパートシステムが、前記処理モジュールに結合されて、前記第１のデータベースにおけるコンポーネントの定義に付加され得るパッキング動作のタイプに関連する少なくとも１つの知識を記憶しかつ検索するためのパッキング定義手段と、前記処理モジュール、前記第１のデータベースおよび前記第２のデータベースに結合されて、同時に複数のパッキング動作を行なって、前記第１のデータベースに記憶される制約式の形で前記コンフィギュレータデベロッパにより宣言的に特定される基準によって選択されたコンポーネントの他の選択されたコンポーネントへの接続を定義するパッキング処理手段とを含む、コンフィギュレータエキスパートシステム。３７．前記パッキング処理手段と前記処理モジュールとに結合されて制約式を評価しかつ前記パッキング処理手段および前記処理モジュールに結果信号を返すための式ハンドリング手段をさらに含む、請求項３６に記載のコンフィギュレータエキスパートシステム。３８．前記パッキング処理手段が、前記制約式に従い前記第２のデータベースにおけるインスタンスの状態に基づき選択されたコンポーネントを構成するコンフィギュレータユーザの要求の影響を分析するための複数のパッカー手段とを含み、前記パッカー手段の各々がコンフィギュレータユーザ要求に応答して前記第２のデータベースを修正するためのビッドを発生するための手段を含み、さらに前記パッカー手段の各々に結合されて、前記パッカー手段の各々の動作を調整制御し、かつ予め定められた基準に従い前記ビッドのうちどれを実現すべきかを選択するためのマスタスケジューラ手段とを含む、請求項３６に記載のコンフィギュレータエキスパートシステム。３９．前記マスタスケジューラ手段が、前記パッカー手段の各々に結合されて、前記ビッドのうち実現する最重要ビッドを前記予め定められた基準に従い決定するためのスーパーバイザ手段と、前記パッカー手段の各々に結合されて、前記パッカー手段の各々に質問をし、前記最重要ビッドが前記パッカー手段のすべてにとって許容可能なものであるかどうかを決定するマスタコンサルタント手段とを含む、請求項３８に記載のコンフィギュレータエキスパートシステム。４０．前記パッカー手段が、前記スーパーバイザ手段に結合されて、前記ビッドを選択しかつ前記ビッドをその望ましさと重要度の観点から数値的にレイティングするための選択プロポーザ手段と、前記スーパーバイザ手段と前記マスタコンサルタント手段とに結合されて、前記ビッドを仮に実現して前記第２のデータベースを修正し、かつ前記ビッドを実際に実現することが前記パッカー手段のすべてにとって許容可能であることを確実にするための割当プロポーザ手段と、前記選択プロポーザ手段と、前記割当プロポーザ手段と、前記マスタコンサルタント手段とに結合されて、前記第２のデータベースにおけるインスタンスのグローバル状態を検討し、前記パッカー手段に関して前記最重要ビッドを実現した後の前記第２のデータベースの現在の状態の正当性を確証し、かつ正当性の結果を前記マスタコンサルタント手段に報告するためのコンサルタント手段と、前記スーパーバイザ手段に結合されて、前記パッカー手段の各々の前記コンサルタント手段が許容可能な正当性の結果を報告する場合前記第２のデータベースにおけるインスタンスを前記最重要ビッドに従い永久的に修正するためのインプリメンタ手段とを含む、請求項３９に記載のコンフィギュレータエキスパートシステム。４１．パッキング動作を実行することによりパッキング問題を解決することによって、接続されてコンピュータシステムを形成するコンポーネントのコンフィギュレーションを発生するためのコンフィギュレータエキスパートシステムであって、前記コンフィギュレータエキスパートシステムはコンフィギュレータデベロッパにより所与のコンピュータシステムコンフィギュレーションドメインについてカスタマイズされており、かつコンフィギュレータユーザにより作動されて、ユーザの要求、予め定められたコンピュータシステムコンポーネントの要件、コンピュータシステムコンポーネントの定義により特定される接続の制約に基づきコンピュータシステムコンフィギュレーションの解答を発生し、前記コンフィギュレータエキスパートシステムは前記コンピュータシステムコンポーネントの定義と前記コンフィギュレータデベロッパにより宣言的に特定される制約式を記憶するための第１のデータベースと、前記コンフィギュレータユーザにより対話的に選択される前記第１のデータベースにおいて定義されるコンピュータシステムコンポーネントのインスタンスを記憶するための第２のデータベースと、選択されたコンピュータシステムコンポーネントを接続する前記コンフィギュレータユーザからの要求を受け入れて、前記要求を前記第１のデータベースに記憶される前記コンピュータシステムコンポーネントの定義にマッチングし、創出および接続が前記コンピュータシステムコンポーネントの定義および以前のコンフィギュレータユーザの要求に基づいて有効であれば、前記第２のデータベースにおける選択されたコンピュータシステムコンポーネントのインスタンスを創出し接続し、かつ前記要求から結果として生じる前記コンピュータシステムコンフィギュレーションを前記コンフィギュレータユーザに報告することができる処理モジュールとを有し、前記コンフィギュレータエキスパートシステムが、前記処理モジュールに結合されて、前記第１のデータベースにおける前記コンピュータシステムコンポーネントの定義に付加し得るタイプのパッキング動作に関連する少なくとも１つの知識を記憶するためのパッキング定義知識ベース手段と、前記処理モジュール、前記第１のデータベース、および前記第２のデータベースに結合されて、複数のパッキング動作を同時に実行して、前記第１のデータベースに記憶される制約式で前記コンフィギュレータデベロッパにより宣言的に特定される基準に従い選択されたコンピュータシステムコンポーネントを他のコンピュータシステムコンポーネントに接続することを定義するためのパッキング処理手段とを含む、コンフィギュレータエキスパートシステム。４２．前記パッキング処理手段と前記処理モジュールとに結合されて、前記制約式を評価しかつ結果信号を前記パッキング処理手段と前記処理モジュールとに返すための式ハンドリング手段をさらに含む、請求項４１に記載のコンフィギュレータエキスパートシステム。４３．前記パッキング処理手段が、前記制約式に従い前記第２のデータベースにおけるインスタンスの状態に対する、選択されたコンピュータシステムコンポーネントを構成するコンフィギュレータユーザの要求の影響を分析するための複数のパッカー手段を含み、前記パッカー手段の各々がコンフィギュレータユーザの要求に応答して前記第２のデータベースを修正するためのビッドを発生する手段を含み、さらに前記パッカー手段の各々の動作を調整かつ制御し、かつ前記ビッドのうちどれを行なうかを予め定められた基準に従って選択するためのマスタスケジューラ手段とを含む、請求項４１に記載のコンフィギュレータエキスパートシステム。４４．前記マスタスケジューラ手段が、前記パッカー手段の各々に結合されて、前記予め定められた基準に従い実現する前記ビッドのうち最重要ビッドを決定するためのスーパーバイザ手段と、前記パッカー手段の各々に結合されて前記パッカー手段の各々に質問をして前記最重要ビッドが前記パッカー手段のすべてにとって許容可能なものであるかどうかを決定するためのマスタコンサルタント手段とを含む、請求項４３に記載のコンフィギュレータエキスパートシステム。４５．前記パッカー手段が、前記スーパーバイザ手段に結合されて前記ビッドを選択しかつ前記ビッドを望ましさと重要度の観点から数値的にレイティングするための選択プロポーザ手段と、前記スーパーバイザ手段と前記マスタコンサルタント手段とに結合されて、前記ビッドを仮に実現して前記第２のデータベースを修正し、かつ前記ビッドを実際に実現することが前記パッキング手段のすべてにとって許容可能であることが確実になるようにするための割当プロポーザ手段と、前記選択プロポーザ手段と、前記割当プロポーザ手段と、前記マスタコンサルタント手段とに結合されて、前記第２のデータベースにおけるインスタンスのグローバル状態を検討し、前記パッカー手段に関連して、前記最重要ビッドを実現した後の前記第２のデータベースの現在の状態の正当性を確証し、かつ前記マスタコンサルタント手段に対し正当性の結果を報告するためのコンサルタント手段と、前記スーパーバイザ手段に結合されて、前記パッカー手段の各々の前記コンサルタント手段が許容可能な正当性の結果を報告する場合前記最重要ビッドに従い前記第２のデータベースにおけるインスタンスを永久的に修正するためのインプリメンタ手段とを含む、請求項４４に記載のコンフィギュレータエキスパートシステム。４６．前記パッキング処理手段がビンパッキング、ケーブリング、ラックパッキング、およびコンピュータシステムコンポーネントストリンギングコンフィギュレーション問題を同時に解決するために複数のパッキング動作を行なう、請求項４５に記載のコンフィギュレータエキスパートシステム。４７．パッキング動作を実行することによってパッキング問題を解決することにより接続されたコンポーネントからなるコンフィギュレーションを発生するためのコンピュータベースのコンフィギュレータエキスパートシステムであって、前記コンフィギュレータエキスパートシステムはコンフィギュレータデベロッパにより所与のコンフィギュレータドメインについてカスタマイズされ、かつコンフィギュレータユーザにより作動されて、コンフィギュレータユーザの要求、予め定められたコンポーネントの要件、およびコンポーネントの定義により特定される接続の制約に基づきコンフィギュレーションの解答を発生し、前記コンフィギュレータエキスパートシステムが、前記コンフィギュレータデベロッパにより宣言的に特定されるコンポーネントの定義と制約式とを含むアプリオリデータベースを含み、前記コンポーネントの定義は前記コンポーネントの定義の使用によって暗示されるリソースに論理的に結合されて第１の活性度伝播二部グラフを形成し、さらに前記コンフィギュレータユーザにより対話的に選択される前記アプリオリデータベースにおいて定義されるコンポーネントのインスタンスを含むインスタンスデータベースを含み、前記インスタンスは前記暗示されたリソースのインスタンスに論理的に結合されて第２の二部グラフを形成し、さらに前記アプリオリデータベースと前記インスタンスデータベースとに結合されたロジックエンジンを含み、前記ロジックエンジンは選択されたコンポーネントを構成する前記コンフィギュレータユーザからの要求を受け入れ、前記要求を前記第１の活性度伝播二部グラフにおける前記コンポーネントの定義にマッチングし、前記インスタンスの創出および接続が前記コンポーネントの定義と以前のコンフィギュレータユーザの要求とに基づいて有効であれば前記選択されたコンポーネントの前記インスタンスを創出かつ接続し、有効性は前記第１の活性度伝播二部グラフと前記第２の二部グラフとに固有のノード間の関係を分析することによって決定され、かつさらに前記要求から結果として生じるコンフィギュレーションを前記コンフィギュレータユーザに報告し、さらに前記ロジックエンジンに応答して前記アプリオリデータベースにおける前記アイテムに付加され得るタイプのパッキング動作に関連する少なくとも１つの知識を記憶するためのパッキング定義知識ベース手段と、前記ロジックエンジン、前記アプリオリデータベース、およびインスタンスデータベースに結合されて、前記インスタンスデータベースに記憶される前記制約式で前記コンフィギュレータデベロッパにより宣言的に特定される基準に従い前記選択されたコンポーネントを他の選択されたコンポーネントに接続することを定義するための複数のパッキング動作を同時に行なうためのパッキングエンジン手段とを含む、コンピュータベースのコンフィギュレータエキスパートシステム。４８．前記パッキングエンジン手段と前記ロジックエンジンとに結合されて、前記制約式を評価しかつ結果信号を前記パッキングエンジン手段と前記ロジックエンジンとに返すための式ハンドリング手段とをさらに含む、請求項４７に記載のコンピュータベースのコンフィギュレータエキスパートシステム。４９．前記パッキングエンジン手段が、前記選択されたコンポーネントを構成するコンフィギュレータユーザの要求の前記制約式に従う前記第２の二部グラフの状態に対する影響を分析するための複数のパッカー手段を含み、前記パッカー手段の各々がコンフィギュレータユーザ要求に応答して前記インスタンスデータベースに記憶される前記第２の二部グラフを修正するためのビッドを発生するための手段を含み、さらに前記パッカー手段の各々に結合されて前記パッカー手段の各々の動作を調整かつ制御し、かつ予め定められた基準に従って、前記ビッドのうちのどれを実現すべきかを選択するためのマスタスケジューラ手段とを含む、請求項４７に記載のコンピュータベースのコンフィギュレータエキスパートシステム。５０．前記マスタスケジューラ手段が、前記パッカー手段の各々に結合されて、前記予め定められた基準に従い実行する前記ビッドのうちの最重要ビッドを決定するためのスーパーバイザ手段と、前記パッカー手段の各々に結合されて、前記パッカー手段の各々に質問して、前記最重要ビッドが前記パッカー手段のすべてにとって許容可能であるかどうかを決定するためのマスタコンサルタント手段とを含む、請求項４８に記載のコンフィギュレータエキスパートシステム。５１．前記パッカー手段が、前記スーパーバイザ手段に結合されて前記ビッドを選択しかつ前記ビッドを望ましさと重要度の観点からレイティングするための選択プロポーザ手段と、前記スーパーバイザ手段と前記マスタコンサルタント手段とに結合されて、前記インスタンスデータベースに記憶される前記第２の二部グラフを修正するための前記ビッドを仮に実現しかつ前記ビッドの実際の実現がパッカー手段のすべてにとって許容可能であることを確実にするための割当プロポーザ手段と、前記選択プロポーザ手段と、前記割当プロポーザ手段と、前記マスタコンサルタント手段とに結合されて、前記第２の二部グラフのグローバル状態を検討し、前記パッカー手段に関連して前記最重要ビッドの実行の正当性を確証し、かつ正当性の結果を報告するためのコンサルタント手段と、前記スーパーバイザ手段に結合されて、前記パッカー手段の各々の前記コンサルタント手段が許容可能な正当性の結果を報告する場合には前記最重要ビッドに従い前記インスタンスデータベースに記憶される前記第２の二部グラフを永久的に修正するためのインプリメンタ手段とを含む、請求項５０に記載のコンピュータベースのコンフィギュレータエキスパートシステム。５２．パッキング動作を実行することによってパッキング問題を解決することにより、接続されてコンピュータシステムを構成するコンポーネントからなるコンフィギュレーションを発生するためのコンピュータベースのコンフィギュレータエキスパートシステムであって、前記コンフィギュレータエキスパートシステムはコンフィギュレータデベロッパにより所与のコンピュータシステムコンフィギュレータドメインについてカスタマイズされて、かつコンフィギュレータユーザにより作動されてコンフィギュレータユーザの要求、予め定められたコンピュータシステムのコンポーネントの要件、およびコンピュータシステムコンポーネントの定義により特定される接続の制約に基づきコンピュータシステムコンフィギュレーションの解答を発生し、前記コンフィギュレータエキスパートシステムが、前記コンフィギュレータデベロッパにより宣言的に特定されるコンピュータシステムコンポーネントの定義と制約式とを含むアプリオリデータベースを含み、前記コンピュータシステムコンポーネントの定義は前記コンピュータシステムコンポーネントの定義を使用することによって暗示されるリソースに論理的に結合されて第２の活性度伝播二部グラフを構成し、さらに前記コンフィギュレータユーザにより対話的に選択される前記アプリオリデータベースにおいて定義されるコンピュータシステムコンポーネントのインスタンスを含むインスタンスデータベースを含み、前記インスタンスは前記暗示されるリソースのインスタンスに論理的に結合されて第２の二部グラフを構成し、さらに前記アプリオリデータベースと前記インスタンスデータベースとに結合されたロジックエンジンを含み、前記ロジックエンジンは選択されたコンピュータシステムコンポーネントを構成する前記コンフィギュレータユーザからの要求を受け入れ、前記要求を前記第２の活性度伝播二部グラフにおける前記コンピュータシステムコンポーネントの定義にマッチングし、前記インスタンスの創出および接続が、前記コンピュータシステムコンポーネントの定義および以前のコンフィギュレータユーザの要求に基づき有効であれば、前記第２の二部グラフにおける前記選択されたコンピュータシステムコンポーネントの前記インスタンスを創出しかつ接続し、有効性は前記第１の活性度伝播二部グラフおよび前記第２の二部グラフに固有のノード間の関係を分析することによって決定され、かつ前記ロジックエンジンがさらに前記要求から結果として生じる前記コンピュータシステムコンフィギュレーションを前記コンフィギュレータユーザに報告し、前記ロジックエンジンに応答して前記アプリオリデータベースにおける前記アイテムに付加され得るタイプのパッキング動作に関連する少なくとも１つの知識を記憶するためのパッキング定義知識ベース手段と、前記ロジックエンジン、前記アプリオリデータベース、およびインスタンスデータベースに結合されて、複数のパッキング動作を同時に行ない、前記インスタンスデータベースに記憶される前記制約式で前記コンフィギュレータデベロッパにより宣言的に特定される基準に従い前記選択されたコンピュータシステムコンポーネントを他の選択されたコンピュータシステムコンポーネントに接続することを定義するためのパッキングエンジン手段とを含む、コンピュータベースのコンフィギュレータエキスパートシステム。５３．前記パッキングエンジン手段と前記ロジックエンジン手段とに結合されて、前記制約式を評価しかつ結果信号を前記パッキングエンジン手段と前記ロジックエンジン手段とに返すための式ハンドリング手段をさらに含む、請求項５２に記載のコンピュータベースのコンフィギュレータエキスパートシステム。５４．前記パッキングエンジン手段が、前記選択されたコンピュータシステムコンポーネントを構成するコンフィギュレータユーザの要求の、前記制約式に従い前記第２の二部グラフの状態に対する影響を分析するための複数のパッカー手段を含み、前記パッカー手段の各々がコンフィギュレータユーザの要求に応答して前記インスタンスデータベースに記憶される前記第２の二部グラフを修正するためのビッドを発生するための手段を含み、さらに前記パッカー手段の各々に結合されて、前記パッカー手段の各々の動作を調整かつ制御し、かつ予め定められた基準に従い、前記ビッドのうちどれを実現すべきかを選択するためのマスタスケジューラ手段とを含む、請求項５２に記載のコンピュータベースのコンフィギュレータエキスパートシステム。５５．前記マスタスケジューラ手段が、前記パッカー手段の各々に結合されて、前記予め定められた基準に従い実行される前記ビッドのうちの最重要ビッドを決定するためのスーパーバイザ手段と、前記パッカー手段の各々に結合されて、前記パッカー手段の各々に質問して、前記最重要ビッドが前記パッカー手段のすべてにとって許容可能なものであるかどうかを決定するマスタコンサルタント手段とを含む、請求項５４に記載のコンピュータベースのコンフィギュレータエキスパートシステム。５６．前記パッカー手段が、前記スーパーバイザ手段に結合されて、前記ビッドを選択しかつ前記ビッドを望ましさと重要度の観点からレイティングするための選択プロポーザ手段と、前記スーパーバイザ手段と前記マスタコンサルタント手段とに結合されて、前記インスタンスデータベースに記憶される前記第２の二部グラフを修正するための前記ビッドを仮に実現し、かつ前記ビッドを実際に実現することがパッカー手段のすべてにとって許容可能であることを確実にするための割当プロポーザ手段と、前記選択プロポーザ手段、前記割当プロポーザ手段、および前記マスタコンサルタント手段に結合されて、前記第２の二部グラフのグローバル状態を検討し、前記パッカー手段に関連して前記最重要ビッドの実行の正当性を確証し、かつ正当性の結果を報告するためのコンサルタント手段と、前記スーパーバイザ手段に結合されて、前記パッカー手段の各々の前記コンサルタント手段が許容可能な正当性の結果を報告する場合には前記最重要ビッドに従い前記インスタンスデータベースに記憶されている前記第２の二部グラフを永久的に修正するためのインプリメンタ手段とを含む、請求項５５に記載のコンピュータベースのコンフィギュレータエキスパートシステム。５７．複数の相互作用するパッキング処理モジュールを使用することによって接続されたコンポーネントからなるコンフィギュレーションを発生するためのコンピュータで実現される方法であって、各コンポーネントはコンポーネントの定義によって記述することが可能であり、前記方法が、（ａ）構成するコンポーネントを宣言的に定義するステップと、（ｂ）前記コンポーネントの定義とそれらの使用によって暗示されるリソースとを第１の活性度伝播二部グラフにおけるノードとして表わすステップと、（ｃ）前記第１の活性度伝播二部グラフにおける選択されたノードに対しパッキング処理モジュールを割当てるステップと、（ｄ）コンフィギュレータユーザからの選択されたコンポーネントを接続する要求を受け入れるステップと、（ｅ）前記コンフィギュレータユーザの要求に従いパッキング処理モジュールの組を選択するステップと、（ｆ）選択されたパッキング処理モジュールの前記組の各々に従い前記要求を実現するための最重要動作を識別するステップと、（ｇ）各選択されたパッキング処理モジュールについての前記最重要動作に対し、前記最重要動作の望ましさと制約の度合いを表わす数値の重みを割当てるステップと、（ｈ）前記選択されたパッキング処理モジュールによって割当てられた前記数値の重みを比較して前記選択されたパッキング処理モジュールのうちの１つを選択し前記選択されたコンポーネントのインスタンスと第２の二部グラフにおけるノードとして前記第２の活性度伝播二部グラフにおいて定義される前記リソースとを創出かつ接続することによって前記最重要動作を試験的に行なうステップと、（ｉ）前記第２の二部グラフにより表わされる前記コンフィギュレーションが各パッキング処理モジュールに従い有効であるかどうかを決定するステップと、（ｊ）選択されたパッキング処理モジュールの前記組の各々が前記最重要動作の実現を承認する場合には前記最重要動作の実現の結果として生じる前記第２の二部グラフにおける変化を永久のものにするステップと、（ｋ）前記要求により結果として生じた前記第２の二部グラフにより表わされるコンフィギュレーションを前記コンフィギュレータユーザに報告するステップとを含む、コンピュータにより実現される方法。５８．前記表わすステップが、（ａ）コンポーネントの定義から現在のコンポーネントの定義を供給するステップと、（ｂ）前記現在のコンポーネントについて前記第１の活性度伝播二部グラフにおけるアイテムノードを創出するステップと、（ｃ）第２の二部グラフにおいて前記現在のコンポーネントを他のコンポーネントに接続する際に前記要件および制約を記述する情報を前記アイテムノードにロードするステップと、（ｄ）前記リソースノードが以前に創出されたことがなければ、前記現在のコンポーネントの使用によって暗示されるリソースを表わす１以上のリソースノードを創出するステップと、（ｅ）前記リソースノードを伴う前記アイテムノードを前記アイテムノードにより消費されるリソースを供給するいずれかの既に存在するアイテムノードと接続するステップと、（ｆ）（ａ）から（ｅ）までのステップを前記コンフィギュレータデベロッパにより定義されるすべてのコンポーネントについて繰返すステップとを含む、請求項５７に記載のコンピュータにより実現される方法。５９．前記受け入れるステップが、（ａ）前記コンフィギュレータユーザに対しメニュー、アイコン、およびデータエントリウィンドウをグラフィカルユーザインタフェースの一部として表示するステップと、（ｂ）前記メニュー、アイコンおよびデータエントリウィンドウによりエントリされるコマンドとデータとに応答することによって、コンポーネントを構成するコンフィギュレータユーザの要求を受け入れるステップとを含む、請求項５７に記載のコンピュータで実現される方法。６０．前記報告するステップは、（ａ）前記第２の二部グラフのノードをグラフィカルユーザインタフェースにより表示することができる表示物体に変換するステップと、（ｂ）前記コンフィギュレータユーザによる観察のために前記表示物体をディスプレイ上に表示するステップとを含む、請求項５７に記載のコンピュータで実現される方法。６１．複数の相互作用するパッキング処理モジュールを使用することによって、接続されてコンピュータシステムを構成するコンポーネントからなるコンフィギュレーションを発生するためのコンピュータにより実現される方法であって、各コンピュータシステムコンポーネントが、コンピュータシステムコンポーネントの定義により記述可能で、前記方法が、（ａ）構成するコンピュータシステムコンポーネントを宣言的に定義するステップと、（ｂ）前記コンピュータシステムコンポーネントの定義およびそれらの使用によって暗示されるリソースを、第１の活性度伝播二部グラフにおけるノードとして表わすステップと、（ｃ）前記第１の活性度伝播二部グラフにおける選択されたノードにパッキング処理モジュールを割当てるステップと、（ｄ）コンフィギュレータユーザからの選択されたコンピュータシステムコンポーネントを接続する要求を受け入れるステップと、（ｅ）前記コンフィギュレータユーザの要求に従いパッキング処理モジュールの組を選択するステップと、（ｆ）選択されたパッキング処理モジュールの前記組の各々に従い前記要求を実現するための最重要動作を識別するステップと、（ｇ）各選択されたパッキング処理モジュールについての前記最重要動作に対し前記最重要動作の望ましさおよび制約の度合いを表わす数値の重みを割当てるステップと、（ｈ）前記選択されたパッキング処理モジュールによって割当てられた前記数値の重みを比較して前記選択されたパッキング処理モジュールのうちの１つを選択し、前記選択されたコンポーネントのインスタンスおよび第２の二部グラフにおけるノードとして前記第１の活性度伝播二部グラフにおいて定義される前記リソースを創出および接続することによって前記最重要動作を試験的に行なうステップと、（ｉ）前記第２の二部グラフにより表わされる前記コンピュータシステムコンフィギュレーションが各パッキング処理モジュールに従い有効であるかどうかを決定するステップと、（ｊ）選択されたパッキング処理モジュールの各々が前記最重要動作の実現を承認する場合には、前記最重要動作の実現の結果として生じる前記第２の二部グラフにおける変化を永久のものにするステップと、（ｋ）前記要求により結果として生じた前記第２の二部グラフにより表わされるコンピュータシステムコンフィギュレーションを前記コンフィギュレータユーザに報告するステップとを含む、コンピュータにより実現される方法。６２．前記表わすステップが、（ａ）コンピュータシステムコンポーネントの定義から現在のコンピュータシステムコンポーネントの定義を供給するステップと、（ｂ）前記現在のコンピュータシステムコンポーネントについて前記第１の活性度伝播二部グラフにおけるアイテムノードを創出するステップと、（ｃ）第２の二部グラフにおいて前記現在のコンピュータシステムコンポーネントを他のコンピュータシステムコンポーネントに接続する際に前記要件と制約とを記述する情報を前記アイテムノードにロードするステップと、（ｄ）前記リソースノードが以前に創出されたものでなければ、前記現在のコンピュータシステムコンポーネントの使用によって暗示されるリソースを表わす１以上のリソースノードを創出するステップと、（ｅ）前記リソースノードを伴う前記アイテムノードと前記アイテムノードにより消費されるリソースを供給するいずれかの既に存在するアイテムノードとを接続するステップと、（ｆ）前記コンフィギュレータデベロッパにより定義されるすべてのコンポーネントについて（ａ）から（ｅ）のステップを繰返すステップとを含む、請求項６１に記載のコンピュータにより実現される方法。６３．前記受け入れるステップが、（ａ）前記コンフィギュレータユーザに対しグラフィカルユーザインタフェースの一部としてメニュー、アイコンおよびデータエントリウィンドウを表示するステップと、（ｂ）前記メニュー、アイコンおよびデータエントリウィンドウによりエントリされたコマンドおよびデータに応答することによってコンピュータシステムコンポーネントを構成するコンフィギュレータユーザの要求を受け入れるステップとを含む、請求項６１に記載のコンピュータにより実現される方法。６４．前記報告するステップが、（ａ）前記第２の二部グラフのノードをグラフィカルユーザインタフェースにより表示することができる表示物体へ変換するステップと、（ｂ）前記コンフィギュレータユーザによる観察のために前記表示物体をディスプレイ上に表示するステップとを含む、請求項６１に記載のコンピュータにより実現される方法。