(57)【特許請求の範囲】
【請求項１】
コンピュータが、デザインを作成する際に使用する複数のファンクションを含むソフトウェアシステム上で、デザインセッションから生じるデザインを表示する方法であって、
前記デザインは、対応するファンクションによって夫々作成される複数のデザインエンティティを含み、
前記コンピュータは、
前記デザインを形成する複数のデザインエンティティの依存関係表示であって、前記デザインを形成する複数のデザインエンティティのサブセットを単一のデザインエンティティとする階層的なデザインエンティティを少なくとも１つ含む依存関係表示を作成する依存関係作成ステップと、
前記デザインを形成するデザインエンティティを作成する際に使用される対応するファンクションを呼び出して、前記デザインを表示するコンピュータプログラムを前記依存関係表示から標準的なプログラミング言語で生成するプログラム生成ステップと、
を実行することを特徴とするソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項２】
前記プログラム生成ステップは、前記ソフトウェアシステム上で、デザインを形成する複数のデザインエンティティの依存関係に対応する構造を有するコンピュータプログラムを生成するステップであることを特徴とする請求項１に記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項３】
前記ソフトウェアシステムは、前記デザインの依存関係表示を評価するために実行されるソフトウェアルーチンであることを特徴とし、
また、前記プログラム生成ステップは、前記コンピュータプログラムを生成する際にソフトウェアルーチンの少なくとも一部を実行するステップであることを特徴とする請求項１又は請求項２に記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項４】
前記コンピュータは、
修正されたデザインを表示する修正コンピュータプログラムが作成されたとき、該修正コンピュータプログラムをソフトウェアシステム上で実行し、ソフトウェアシステム上で修正デザインを生成するデザイン修正ステップをさらに実行することを特徴とする請求項１〜請求項３のいずれか１つに記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項５】
前記デザイン修正ステップは、前記修正されたデザインの依存関係表示を生成するステップであることを特徴とする請求項４に記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項６】
前記プログラム生成ステップは、少なくとも１つの階層的なデザインエンティティを表示するコンピュータプログラムを生成するステップであることを特徴とする請求項１〜請求項５のいずれか１つに記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項７】
前記プログラム生成ステップは、さらに、前記階層的なデザインエンティティによって表示される複数のデザインエンティティのサブセットを作成する複数のファンクションを呼び出して、少なくとも１つの階層的なデザインエンティティを表示するコンピュータプログラムを生成するステップであることを特徴とする請求項６に記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項８】
前記コンピュータは、
コンピュータプログラムを格納するプログラム格納ステップと、
前記ソフトウェアシステムから前記デザインが削除して格納空間を保存するデザイン削除ステップと、
をさらに実行することを特徴とする請求項１〜請求項７のいずれか１つに記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項９】
前記コンピュータは、
前記ソフトウェアシステム上でコンピュータプログラムを実行してデザインを再生するデザイン再生ステップをさらに実行することを特徴とする請求項１〜請求項８のいずれか１つに記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項１０】
前記コンピュータは、
前記ソフトウェアシステムから依存関係表示が削除して格納空間をさらに保存する依存関係表示削除ステップをさらに実行することを特徴とする請求項１〜請求項８のいずれか１つに記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項１１】
前記コンピュータは、
前記ソフトウェアシステム上で依存関係表示を再生するコンピュータプログラムを実行する依存関係再生ステップをさらに実行することを特徴とする請求項１０に記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項１２】
コンピュータが、複数のファンクションと１つのユーザーインタフェースを有し、前記複数のファンクションの対応する１つを呼び出すことによって複数のコマンドの各々の受領に応答するソフトウェアモデリングシステムに、パラメトリック機能を実装する方法であって、
前記複数のファンクションは、モデルを作成するモデリングセッション中に実行され、
前記コンピュータは、
ソフトウェアシステムにおいて、前記複数のファンクションの各々に適合した引数を生成するラッパーにより該複数のファンクションの各々について引数を生成し、該引数を対応するファンクションに渡して該ファンクションを呼び出す結合ファンクションであって、その対応するファンクションが前記モデリングセッション中に実行されたとき、前記モデルの依存関係表示にグラフエンティティを作成及び付加する能力を有する結合ファンクションを、前記複数のファンクションの各々に対して前記ラッパーを付加することにより複数作成する結合ファンクション作成ステップと、
各々受け取ったコマンドに応じて、該受け取ったコマンドに対応する前記ファンクションに対応する結合ファンクションが呼び出されるように、前記ユーザーインタフェースを修正するユーザーインタフェース修正ステップと、
を実行することを特徴とするソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項１３】
前記複数のファンクションの少なくとも１つは、固有のパラメトリック機能を有していないことをさらに特徴とする請求項１２に記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項１４】
前記複数のファンクションは、第１のフォーマットでフォーマットされた引数の第１のセットに作用する第１のファンクションを含むことを特徴とし、
また、前記結合ファンクション作成ステップは、第１のファンクションに対し第１のラッパーを実装するステップであって、該第１のラッパーは、第１のフォーマットとは異なる第２のフォーマットでフォーマットされた引数の第２のセットを受け取ることが可能であり、第１のファンクションが呼び出されるとき、引数の第２のセットを引数の第１のセットに変換するものであることを特徴とする請求項１２又は請求項１３に記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項１５】
前記結合ファンクション作成ステップは、前記ラッパーの各々を、オブジェクト指向コンピュータプログラミング言語で実装するステップであることを特徴とする請求項１２〜請求項１４のいずれか１つに記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項１６】
前記コンピュータは、
修正が前記モデルになされたとき、前記依存関係表示を使用するツールを供給して前記デザインの修正によって影響を受けるグラフエンティティに対応する前記モデルを作成するのに使用されるファンクションだけを呼び出し、該ファンクションを実行して前記モデルを更新するステップをさらに実行することを特徴とする請求項１２〜請求項１５のいずれか１つに記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項１７】
前記コンピュータは、
各々の結合ファンクションのためのテーブルエントリを有するハッシュテーブルを作成するステップであって、各々のテーブルエントリは、前記依存関係表示に作成及び付加された前記グラフエンティティのトポロジイが前記結合ファンクション名に対応したインデックスと共に前記ハッシュテーブルに登録されたものであり、該テーブルエントリのインデックスに対応する結合ファンクションが実行されたとき、前記グラフエンティティのトポロジイが確認されるものであるハッシュテーブル作成ステップをさらに実行することを特徴とする請求項１２〜請求項１６のいずれか１つに記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項１８】
前記結合ファンクション作成ステップは、さらに、標準的なコンピュータプログラミング言語により前記ラッパーの各々を供給するステップであることを特徴とする請求項１２〜請求項１７のいずれか１つに記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項１９】
前記コンピュータは、
前記結合ファンクションの各々から呼び出され、該結合ファンクションの各々と協働し、該結合ファンクションの各々について、前記グラフエンティティを表示するソフトウェアファンクションを作成する単一のプロセッサファンクションを作成する単一プロセッサファンクション作成ステップをさらに実行することを特徴とする請求項１２〜請求項１８のいずれか１つに記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項２０】
コンピュータが、デザインを作成する際に使用する複数のファンクションを含むソフトウェアシステム上で、デザインセッションから生じるデザインに作用する方法であって、
前記デザインは対応するファンクションによって各々作成される複数のデザインエンティティであり、
前記複数のファンクションは、演算対象となる複数のパラメータのうち、所定のパラメータを入力パラメータとして演算した結果を他のパラメータに出力する正算と、演算対象となる複数のパラメータのうち、任意のパラメータを入力パラメータとして演算した結果を他のパラメータに出力する非正算と、に係るものであることを特徴とし、
前記ソフトウェアシステムは、さらに、相互に接続された非正算の制限セットを解明するエンジンを含むことを特徴とし、
前記コンピュータは、
前記デザインを形成する複数のデザインエンティティの間で、依存関係を示すデザインの依存関係表示を作成するステップであって、該依存関係表示は、正算と非正算との両者によって作成されるデザインエンティティを表示するとともに、前記デザインをチェックして、相互に接続された各々の非正算の制限セットが、エンジンが解明できる型のものであるか否か判定するものである依存関係作成ステップを実行することを特徴とするソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項２１】
コンピュータが、デザインを作成する際に使用する複数のファンクションを含むことを特徴とするソフトウェアシステム上で、デザインセッションから生じるデザインに作用する方法であって、
前記デザインは、前記複数のファンクションの対応する１つによって各々作成される複数のデザインエンティティであることを特徴とし、
前記コンピュータは、
前記デザインを形成する複数のデザインエンティティのサブセットを単一のデザインエンティティとする階層的なデザインエンティティを含む複数のデザインエンティティの依存関係を示すデザインの依存関係表示を作成する依存関係作成ステップと、
前記デザインの依存関係表示を表示する依存関係表示ステップと、
を実行することを特徴とするソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項２２】
前記コンピュータは、
修正されたデザインを表示する修正依存関係表示が作成されたとき、該修正依存関係表示から修正デザインを生成するデザイン修正ステップをさらに実行することを特徴とする請求項２１に記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項２３】
コンピュータが、デザインを作成する際に使用する複数のファンクションを含むことを特徴とするソフトウェアシステム上で、デザインセッションから生じるデザインに作用する方法であって、
前記デザインは、前記複数のファンクションの対応する１つによって各々作成される複数のデザインエンティティであることを特徴とし、
前記コンピュータは、
前記デザインを形成する複数のデザインエンティティのサブセットを単一のデザインエンティティとする階層的なデザインエンティティを含む複数のデザインエンティティの依存関係を示すデザインの依存関係表示を作成するステップであって、該依存関係表示は、前記複数のデザインエンティティを表示する複数のグラフエンティティに特徴を有するものである依存関係作成ステップと、
同じ階層のグラフエンティティを有する複数のグラフエンティティの少なくとも２つを表示するグラフエンティティ表示ステップと、
を実行することを特徴とするソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【請求項２４】
前記コンピュータは、
前記デザインに修正が加えられたとき、前記依存関係表示を使用して、デザインの修正によって影響を受ける１組のデザインエンティティを確認するデザインエンティティ確認ステップと、
前記修正によって影響を受ける１組のデザインエンティティに対応するデザインを作成する際に使用されるファンクションだけを呼び出し、該ファンクションを実行してデザインを更新するステップと、
をさらに実行することを特徴とする請求項１〜請求項２３のいずれか１つに記載のソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法に関する。
【０００２】
【従来の技術】
ソフトウェアシステムは、多くの異なる分野に存在する。この分野において、ユーザーは、インタラクティブセッション(interactiv session)中に一連のコマンド(command) を入力することで、システムと相互に作用し、それに応じて、ソフトウェアシステムは、ユーザーコマンドによって定義される動作を行う多数のファンクション(function)を実行する。インタラクティブデザインセッション中にデザインのコンピュータモデルを生成するコンピュータ支援設計（ＣＡＤ）システムは、このようなシステムの一例である。マサチューセッツ州ベッドフォードにあるコンピュータビジョンコーポレーション（本願出願人）から入手できるＣＡＤＤＳ  ｌｉｎｅのようなＣＡＤシステムは、２次元及び／又は３次元の機械装置のコンピュータモデルを生成するツールを提供する。一般的に、製品デザインを生成する一連のシステム定義済コマンドをユーザーインタフェースに入力することで、ユーザーはモデルを相互作用として構築する。例えば、ユーザーは、箱書き込みのようなあるコマンドを、その箱の所望の寸法（長さ、高さ及び幅）と所望の位置とを共に入力して、特定の特徴のある箱を、デザインに加えることができる。他のコマンドは、前記箱と統合されて、製品デザインを完成することができる円柱、球、穴等のような要素を加えることができる。従って、このようなシステム定義済コマンドを入力することで、ユーザーは、機械装置のコンピュータモデルを構築することができる。
【０００３】
ＣＡＤシステムにおけるユーザーインタフェースは、従来から、ユーザーから受け取ったコマンドを処理するコマンドプロセッサを含んでいる。コマンドプロセッサは一般的に、受信コマンドを記憶するコマンドファイルを生成して、ユーザーとＣＡＤシステム間のインタラクティブセッションの記録を生成できる。コマンドとコマンドプロセッサは一般的に、個々のＣＡＤシステムに固有の(proprietary) ものであるので、コマンドファイルは本来固有言語である。コマンドを受け取るとすぐに、ユーザーインタフェースは、アプリケーションプログラミングインタフェース（ＡＰＩ）を呼び出す。このＡＰＩは、システムに、アクティビティ(activity)を行わせるソフトウェアファンクションである。例えば、ＣＡＤシステムにおいて、ＡＰＩは幾何学的なモデラー（modeler)に、固有のコマンドによって要求されるデザインアクションを達成するための輪郭、面及び頂点のようなエンティティ(entity)を生成させ、かつ、相互に連結させて、データベースに前記エンティティをストアする。インタラクティブセッション中にユーザーから受け取った一連のコマンドによって作成されるエンティティの組合せが、製品デザインを定義する。
【０００４】
ユーザーが、前もって作成されたエンティティ（例えば、箱の高さ）の１つのパラメータ(parameter) を変えて製品デザインを変更しようとする場合、ユーザーはヒストリーモジュールを変更してその変更を反映し、その後、ヒストリーモジュール中の全てのコマンドを再実行するシステムに、コマンドのソースとしてのヒストリーモジュールを供給することができる。コマンドが再実行されると、コマンドはコマンドプロセッサに供給され、コマンドプロセッサは再び適切なＡＰＩを呼び出し、ＡＰＩは一般的に古いデザインエンティティを次々に捨て、新しいヒストリーモジュールはもちろん、新しい製品デザインをもたらす新しいエンティティを作成する。このタイプのシステムは、コマンドが基本的な構築ブロックであるため、”コマンドベース”システムと呼ばれている。
【０００５】
【発明が解決しようとする課題】
しかしながら、前述したコマンドベースシステムは、ユーザーがインタラクティブセッションを記録し、その記録を変更し、それらの変更に基づいて再実行できるものであるが、いくつかの不具合がある。これらのシステムによって作成されるヒストリーモジュールは、インタラクティブデザインセッション中に受け取られるコマンドの順序を反映し、結果として生じるデザインの構造上の依存関係(dependency)を表示しない。従って、例え少しであっても、デザインに何らかの変更がなされると、ヒストリーモジュール全体が新しいデザインを生成するために再実行されなければならず、この再実行がデザインプロセスを遅らせることになる。
【０００６】
パラメトリック機能(parametric capabilities)を含むいくつかのＣＡＤシステムが開発されて、変更がデザインパラメータになされると、変更されたパラメータによって影響を受けるデザイン部分だけを更新することにより、システムがデザインを変更するようにしている。しかしながら、これらのパラメトリック機能は、従来、システムによって使用される固有のコマンド中に組み込まれている。従って、サードパーティーベンダーがソフトウェアシステム上に付加能力を供給しようとする場合、システムのパラメトリック機能が維持されるべきものであれば、新しい能力は、システムの固有のコマンドセットに統合されなければならない。
【０００７】
前述したコマンドベースシステムによる他の不具合は、システムがパラメトリック機能を含んでいるかどうかに関係なく、ヒストリーモジュールへの変更が固有のコマンドを使用しなければならない点である。従って、ユーザーは、ヒストリーモジュール中に反映されたデザインを変更するためには、新しい”プログラミング言語”を学習しなければならない。さらに、このタイプのヒストリーモジュールは、ヒストリーモジュールがデザインの構造上の依存関係を表示せず、むしろ、デザインプロセス中に受け取られたコマンドの順序にだけ関係があるため、デザイナーにとっては、作業が困難である。
【０００８】
本発明はこのような従来の課題に鑑みてなされたもので、ユーザーに分かりやすい方法で、結果として生じるデザインの構造上の依存関係を表示することのできるソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法を提供することを目的とする。
【０００９】
【課題を解決するための手段】
このため、請求項１の発明にかかる方法は、デザインを作成する際に使用する複数のファンクションを含むソフトウェアシステム上で、デザインセッションから生じるデザインを表示する方法であって、前記デザインは、対応するファンクションによって夫々作成される複数のデザインエンティティを含み、前記デザインを形成する複数のデザインエンティティの依存関係表示であって、前記デザインを形成する複数のデザインエンティティのサブセットを単一のデザインエンティティとする階層的なデザインエンティティを少なくとも１つ含む依存関係表示を作成する依存関係作成ステップと、前記デザインを形成するデザインエンティティを作成する際に使用される対応するファンクションを呼び出して、前記デザインを表示するコンピュータプログラムを前記依存関係表示から標準的なプログラミング言語で生成するプログラム生成ステップと、を含むようにした。
【００１０】
請求項２の発明にかかる方法では、前記プログラム生成ステップが、前記ソフトウェアシステム上で、デザインを形成する複数のデザインエンティティの依存関係に対応する構造を有するコンピュータプログラムを生成するステップであるようにした。
請求項３の発明にかかる方法では、前記ソフトウェアシステムは、前記デザインの依存関係表示を評価するために実行されるソフトウェアルーチンであることを特徴とし、また、前記プログラム生成ステップは、前記コンピュータプログラムを生成する際にソフトウェアルーチンの少なくとも一部を実行するステップであるようにした。
【００１１】
請求項４の発明にかかる方法では、前記コンピュータは、修正されたデザインを表示する修正コンピュータプログラムが作成されたとき、該修正コンピュータプログラムをソフトウェアシステム上で実行し、ソフトウェアシステム上で修正デザインを生成するデザイン修正ステップをさらに実行するようにした。
【００１２】
請求項５の発明にかかる方法では、前記デザイン修正ステップは、前記修正されたデザインの依存関係表示を生成するステップである。
請求項６の発明にかかる方法では、前記プログラム生成ステップは、少なくとも１つの階層的なデザインエンティティを表示するコンピュータプログラムを生成するステップである。
【００１３】
請求項７の発明にかかる方法では、前記プログラム生成ステップは、さらに、前記階層的なデザインエンティティによって表示される複数のデザインエンティティのサブセットを作成する複数のファンクションを呼び出して、少なくとも１つの階層的なデザインエンティティを表示するコンピュータプログラムを生成するステップである。
【００１４】
請求項８の発明にかかる方法では、前記コンピュータは、前記コンピュータプログラムを格納するプログラム格納ステップと、前記ソフトウェアシステムから前記デザインを削除して格納空間を保存するデザイン削除ステップと、をさらに実行する。
請求項９の発明にかかる方法では、前記コンピュータは、前記ソフトウェアシステム上でコンピュータプログラムを実行してデザインを再生するデザイン再生ステップをさらに実行する。
【００１５】
請求項１０の発明にかかる方法では、前記コンピュータは、前記ソフトウェアシステムから依存関係表示を削除して格納空間をさらに保存する依存関係表示削除ステップをさらに実行する。
請求項１１の発明にかかる方法では、前記コンピュータは、前記ソフトウェアシステム上で依存関係表示を再生するコンピュータプログラムを実行する依存関係再生ステップをさらに実行する。
【００１６】
請求項１２の発明にかかる方法では、複数のファンクションと１つのユーザーインタフェースを有し、前記複数のファンクションの対応する１つを呼び出すことによって複数のコマンドの各々の受領に応答するソフトウェアモデリングシステムに、パラメトリック機能を実装する方法であって、前記複数のファンクションは、モデルを作成するモデリングセッション中に実行され、ソフトウェアシステムにおいて前記複数のファンクションの各々に適合した引数を生成するラッパーにより該複数のファンクションの各々について引数を生成し、該引数を対応するファンクションに渡して該ファンクションを呼び出す結合ファンクションであって、その対応するファンクションが前記モデリングセッション中に実行されたとき、前記モデルの依存関係表示にグラフエンティティを作成及び付加する能力を有する結合ファンクションを、に対して前記ラッパーを付加することにより複数作成する結合ファンクション作成ステップと、各々受け取ったコマンドに応じて、該受け取ったコマンドに対応する前記ファンクションに対応する結合ファンクションが呼び出されるように、前記ユーザーインタフェースを修正するユーザーインタフェース修正ステップと、を含んでいる。
【００１７】
請求項１３の発明にかかる方法では、前記複数のファンクションの少なくとも１つは、固有のパラメトリック機能を有していないようにしている。
請求項１４の発明にかかる方法では、前記複数のファンクションは、第１のフォーマットでフォーマットされた引数の第１のセットに作用する第１のファンクションを含むことを特徴とし、また、前記結合ファンクション作成ステップは、第１のファンクションに対し第１のラッパーを実装するステップであって、該第１のラッパーは、第１のフォーマットとは異なる第２のフォーマットでフォーマットされた引数の第２のセットを受け取ることが可能であり、第１のファンクションが呼び出されるとき、引数の第２のセットを引数の第１のセットに変換するものである。
【００１８】
請求項１５の発明にかかる方法では、前記結合ファンクション作成ステップは、前記ラッパーの各々を、オブジェクト指向コンピュータプログラミング言語で実装するステップである。
請求項１６の発明にかかる方法では、修正が前記モデルになされたとき、前記依存関係表示を使用するツールを供給して前記デザインの修正によって影響を受けるグラフエンティティに対応する前記モデルを作成するのに使用されるファンクションだけを呼び出し、該ファンクションを実行して前記モデルを更新するステップをさらに含んでいる。
【００１９】
請求項１７の発明にかかる方法では、各々の結合ファンクションのためのテーブルエントリを有するハッシュテーブルを作成するステップであって、各々のテーブルエントリは、前記依存関係表示に作成及び付加された前記グラフエンティティのトポロジイが前記結合ファンクション名に対応したインデックスと共に前記ハッシュテーブルに登録されたものであり、該テーブルエントリのインデックスに対応する結合ファンクションが実行されたとき、前記グラフエンティティのトポロジイが確認されるものであるハッシュテーブル作成ステップをさらに含んでいる。
【００２０】
請求項１８の発明にかかる方法では、前記結合ファンクション作成ステップは、さらに、標準的なコンピュータプログラミング言語により前記ラッパーの各々を供給するステップである。
請求項１９の発明にかかる方法では、前記結合ファンクションの各々から呼び出され、該結合ファンクションの各々と協働し、該結合ファンクションの各々について、前記グラフエンティティを表示するソフトウェアファンクションを作成する単一プロセッサファンクション作成ステップをさらに含んでいる。
【００２２】
請求項２０の発明にかかる方法では、デザインを作成する際に使用する複数のファンクションを含むソフトウェアシステム上で、デザインセッションから生じるデザインに作用する方法であって、前記デザインは対応するファンクションによって各々作成される複数のデザインエンティティであり、前記複数のファンクションは正算と非正算に係るものであることを特徴とし、前記ソフトウェアシステムは、さらに、相互に接続された非正算の制限セットを解明するエンジンを含むことを特徴とし、前記デザインを形成する複数のデザインエンティティの間で、依存関係を示すデザインの依存関係表示を作成するステップであって、該依存関係表示は、正算と非正算との両者によって作成されるデザインエンティティを表示するとともに、前記デザインをチェックして、相互に接続された各々の非正算の制限セットが、エンジンが解明できる型のものであるか否か判定するものである依存関係作成ステップを含んでいる。
【００２４】
請求項２１の発明にかかる方法では、デザインを作成する際に使用する複数のファンクションを含むことを特徴とするソフトウェアシステム上で、デザインセッションから生じるデザインに作用する方法であって、前記デザインは、前記複数のファンクションの対応する１つによって各々作成される複数のデザインエンティティであることを特徴とし、前記デザインを形成する複数のデザインエンティティのサブセットを単一のデザインエンティティとする階層的なデザインエンティティを含む前記複数のデザインエンティティの間で、依存関係を示すデザインの依存関係表示を作成する依存関係作成ステップと、前記デザインの依存関係表示を表示する依存関係表示ステップと、を含んでいる。
【００２５】
請求項２２の発明にかかる方法では、依存関係表示を修正し、修正されたデザインを表示する修正依存関係表示を作成する依存関係修正ステップと、該修正依存関係表示から修正デザインを生成するデザイン修正ステップと、をさらに含んでいる。
請求項２３の発明にかかる方法では、デザインを作成する際に使用する複数のファンクションを含むことを特徴とするソフトウェアシステム上で、デザインセッションから生じるデザインに作用する方法であって、前記デザインは、前記複数のファンクションの対応する１つによって各々作成される複数のデザインエンティティであることを特徴とし、前記デザインを形成する複数のデザインエンティティのサブセットを単一のデザインエンティティとする階層的なデザインエンティティを含む前記複数のデザインエンティティの依存関係を示すデザインの依存関係表示を作成するステップであって、該依存関係表示は、前記複数のデザインエンティティを表示する複数のグラフエンティティに特徴を有するものである依存関係作成ステップと、同じ階層のグラフエンティティを有する複数のグラフエンティティの少なくとも２つを表示するグラフエンティティ表示ステップと、を含んでいる。
【００２６】
請求項２４の発明にかかる方法では、前記デザインに修正を加えるデザイン修正ステップと、前記依存関係表示を使用して、デザインの修正によって影響を受ける１組のデザインエンティティを確認するデザインエンティティ確認ステップと、前記修正によって影響を受ける１組のデザインエンティティに対応するデザインを作成する際に使用されるファンクションだけを呼び出し、該ファンクションを実行してデザインを更新するステップと、をさらに含むことを特徴とする。
【００２７】
【発明の実施の形態】
本発明の実施の形態によれば、モデリングを行う任意のソフトウェアシステムのための一組のファンクションを、パラメトリック機能を有する対応する一組のファンクションに変換するための方法が供給される。従って、パラメトリック機能は、その一組のファンクションが固有のパラメータ能力を有していないソフトウェアシステムに供給される。
【００２８】
他の実施の形態では、本発明によって作成されるパラメータファンクションが、インタラクティブユーザーセッション中に、或いは、デザイン又はモデルを作成するプログラムによって呼び出されると、パラメータファンクションは、結果としてのモデルだけではなく、モデルの依存関係グラフ表示をも生成する。
別の実施の形態では、本発明によって作成される依存関係グラフが、正算(directed)ファンクションと非正算制限(non-directed constraint) 関係とが単一の依存関係グラフに混合できるように作成されて評価される。
【００２９】
さらに、他の実施の形態では、変更がモデルに対してなされると、本発明によって作成された依存関係表示が使用されて、変更によって影響を受けるモデルの部分だけが更新されたモデルを作成する際に再評価される。
本発明の他の実施の形態によれば、依存関係グラフは、モデルの依存関係を表示するためにユーザーに視覚的に提供される。
【００３０】
本発明の他の実施の形態によれば、ソフトウェアシステムで実行されるファンクションは、依存関係グラフにおける階層的なグループに分類される。従って、複数のファンクションを必要とするユーザーのデザイン目的を、依存関係グラフにおいて単一の階層的なエントリーで表示できる。
本発明の他の実施の形態によれば、依存関係グラフは、視覚的なプログラミング環境を介して作成され、或いは、編集される。依存関係グラフに対して変更がなされるとき、グラフを再評価して、対応する変更をモデルに編入できる。
【００３１】
他の実施の形態では、本発明によって作成された依存関係グラフは、モデルへの入力値かまたは、モデルを作成するのに使用されるファンクションを表示するグラフ要素を変更するために、ユーザーが変更できる。
さらに他の実施の形態では、視覚的なプログラミング環境が依存関係グラフを変更するのに使用されるとき、環境が本発明によって作成される一組のパラメータファンクションを呼び出す。パラメータファンクションは、ユーザーに依存関係グラフを図式的に生成し、編集させる視覚的なプログラミング技術と互換性がある。
【００３２】
さらに他の実施の形態では、本発明に従って作成された一組のパラメータファンクションが、ソフトウェアシステムのファンクションに対してラッパー(wrapper) を作成することで生成される。ラッパーは、前述した視覚的なプログラミング環境のような、固有でないツールと互換となるように、標準的なコンピュータプログラミング言語で書かれている。
【００３３】
本発明のさらに他の実施の形態によれば、ソフトウェアシステム上のモデルやデザインの表示から、コンピュータプログラムを生成するための方法と装置が供給される。この表示はモデルを形成する複数のモデルエンティティの間で依存関係に関してモデルを定義する。コンピュータプログラムは、標準プログラミング言語で書くことができる。プログラムがソフトウェアシステムで実行されるとき、プログラムは依存関係表示はもちろんモデルをも生成する。従って、コンピュータプログラムは、モデリングセッションを効率的な記憶のための標準言語プログラムに変換できる。コンピュータプログラムは、本発明によって作成される依存関係グラフから生成できる。
【００３４】
他の実施の形態では、コンピュータプログラムは編集した後、デザインの変更バージョンを生成するソフトウェアシステムで実行できる。
本発明の他の特徴及び利点は、詳細な説明及び図面から明らかとなる。
I.概略
本発明によれば、方法と装置は、モデルリングシステム内のＡＰＩを、モデルリング(modeling)セッション中にユーザインタフェースから又はより大きなプログラムの一部として呼び出されたとき、モデリングセッション中に呼び出されたＡＰＩファンクションと、ＡＰＩに対する引数と、ＡＰＩファンクションの結果との間の依存関係(dependency)を表示するグラフを生成する結合ＡＰＩに変換するための方法と装置が提供される。依存関係グラフから、本発明により、ユーザーは、（１）入力をグラフに変換し、影響を受けたファンクションのみを再実行させること、（２）グラフの構造的依存関係を表示し、実行時に、グラフを作成するモデリングセッションと同じ結果を生じる固有でない(non-proprietary) コンピュータプログラムを生成すること、（３）依存関係を視覚化するためのグラフを見ること、（４）モデルの依存関係構造を変更するためにグラフを編集すること、そして（５）モデルを生成するのに使用されるＡＰＩファンクションを変換するためにグラフを編集することができる。
【００３５】
本発明の１つの様相によれば、デザインを生成するソフトウェアシステムファンクションの実行に基づいて、デザインの依存関係グラフ表示と、依存関係グラフから生成され、そしてまたデザインの構造的依存関係を表示する固有でないコンピュータプログラムと、を生成する方法が提供される。この方法は、図１のフローチャートに図示されている。ステップ２０１において、デザインは、デザインセッション中のソフトウェアシステムのファンクションのグループの実行により生成され、そしてステップ２０３にて、生成されたデザインの依存関係グラフ表示が生成される。デザインがデザインセッション中で修正される場合、本発明は依存関係グラフを用いて、デザインのどの部分が修正により影響を受けるかを判断するとともに、デザインの影響を受けた部分を変更するのに必要なコードのみを再実行する。ステップ２０５に示すように、デザインセッション中で実行完了後、依存関係グラフは、また、実行されたときに、依存関係グラフと、それが表示するデザインと、を生成するコンピュータプログラムを、標準言語で生成するように使用できる。ユーザーは、ステップ２０７で示すように、コンピュータプログラムを編集して修正されたデザインを表示し、そしてソフトウェアシステム上でコンピュータプログラムを走らせて修正されたデザインを生成することができる（ステップ２０９）。コンピュータプログラムは、固有でない言語で記述されているので、デザイナーは、それを修正するために固有の言語を習得する必要がない。なおその上、コマンドがデザインセッション中にユーザーから受信されるシーケンスからというよりもむしろ依存関係グラフからプログラムが開発されるので、コンピュータプログラムはデザインの構造的な依存関係を表示する。このように、ユーザーが十分なコンピュータプログラミングの経験を有していなくても、プログラム構成はユーザーによって容易に理解され、プログラムを容易に修正できる。
【００３６】
以上、述べられたように、ソフトウェアプログラムは、従来、アプリケーションプログラミングインタフェース（ＡＰＩｓ）を含み、これは、システム定義ユーザーコマンドと１対１の関係に一般的にマップ化された高水準のファンクションである。本発明によれば、本発明をソフトウェアシステムの中に統合する統合プロセスの一部として、最初にソフトウェアシステムの各ＡＰＩを通ってＡＰＩの新しいセットを生成するツールが供給される。そして、ソフトウェアシステムのユーザーインタフェースは、ユーザーから受け取ったコマンドに応答してこれらの新しいＡＰＩを呼び出すように修正される。本発明のツールによって作成された新しいＡＰＩは、本質的に２つのことを行う。第１に、新しいＡＰＩは、ソフトウェアシステムによって供給されたＡＰＩのセットによって実行されたファンクションの全てを、本質的に実行する。第２に、新しいＡＰＩは、また、ユーザーによって作成されたデザインの依存関係グラフ表示を作成するとともに維持する。この依存関係グラフ表示は、グラフへの編集を通してデザインのグラフ的な編集ができるように、上述されたパラメトリック機能を供給するのに使用でき、そして、また、デザインの構造的依存関係を表示する標準言語のコンピュータプログラムを生成するのに使用できる。このように、本発明のツールは、高水準ファンクション、あるいはＡＰＩで構成された何らかのソフトウェアシステム上で、まず、走らせて、システムを本発明によって供給された上述の結合能力を有するシステムに、ユーザーにわかりやすい方法で変換する結合サブシステムを形成する。
【００３７】
前述の内容から理解され、また下記説明から明確になるように、本発明は、そのコマンドセット中にパラメトリック機能を含んでいないとしても、ＡＰＩで構成されるどんなソフトウェアシステムにもパラメトリック機能を供給することができる。本発明のこの特徴は、サードパーティに、付加的な能力をソフトウェアシステムに供給させるには有利なものである。ソフトウェアシステムに付加的な能力を供給するには、サードパーティは、コマンドと、システムのＡＰＩと互換性のある対応するＡＰＩと、を供給するだけでよい。付加的なコマンドはソフトウェアシステムのコマンドセット内にパラメトリック機能を供給するために統合される必要はない。なぜならば、本発明のツールが、サードパーティのコマンドとインストールされたＡＰＩとを有するソフトウェアシステム上で実行されたとき、本発明のツールにより、そしてこれらの新しいＡＰＩが使用されてデザインセッション中に作成されたデザインの依存関係グラフ表示を生成、維持、そして更新するようにパラメトリック機能が供給されるからである。
【００３８】
以下の説明では、本発明が実施されるソフトウェアシステムに供給される具体例は、インタラクティブデザインセッション中にデザイナーからコマンドを受け取って製品デザインを作成するＣＡＤシステムである。しかしながら、本発明がＣＡＤシステム、あるいはインタラクティブセッション中に入力を受け取るシステムへの使用に限定されるものではないことは明らかである。本発明は、ファンクションによって構成され、そして様々な方法でユーザーからの入力を受け取るどんなソフトウェアシステムにも使用できる。例えば、本発明は、多数のパラメータに基づいて経済モデルを作成するソフトウェアシステム、あるいは他の多くのタイプのソフトウェアシステムに使用できる。このように、モデルやデザインといった言葉が依存関係グラフによってモデル化されたソフトウェアシステム出力を参照するために使用されるが、これらの言葉は、ＣＡＤモデルに限定されることを意図するものではなく、多数のファンクションの実行に基づいて何らかのソフトウェアシステムによって作成された出力を含むことを意図するものである。
【００３９】
図２は、ＣＡＤシステム上で動作する本発明によって生成される簡単な依存関係グラフ１の例である。グラフ１は、デザイナーが箱をデザインの中に入れ、箱の重量を計算するためにコマンドを入力するインタラクティブデザインセッション中に生成される。箱を入れるためのコマンドに従って、デザイナーは、箱の中心に座標を設定するとともに、箱の長さ、幅、高さを設定する引数(argument)を供給する。これらの引数はデータオブジェクト３〜６としてグラフ１に夫々表示される。データオブジェクトは、グラフにおける数値を含む構成要素である。データオブジェクト３〜６の夫々は関連づけられたファンクションを示すオペレータ７、即ち、挿入箱に接続されている。オペレータは少なくとも１つのデータオブジェクトに作用し、ユーザーによって与えられたデザインアクションを表示するファンクション又は評価式であるグラフにおける構成要素である。データオブジェクト３〜６は、リレーション９〜１２を経由してオペレータ７に夫々結合されている。リレーションは、結合されたオペレータに関して各データオブジェクトがどのような役割を果たすかを確認するためのグラフにおける構成要素である。図２に示す例において、リレーション９〜１２は、夫々、箱の長さ、幅、高さ、そして中心を設定するものとして結合されたデータオブジェクトを確認する。オペレータ７がデータオブジェクト３〜６に作用した結果はリレーション１５，データオブジェクト１７によりグラフに表示される。データオブジェクト１７はオペレータ７によって作成されたソフトウェアエンティティを表示し、リレーション１５は、オペレータの結果を箱として確認する。
【００４０】
箱の重量を計算するコマンドは、オペレータ１９によってグラフ中に表示される。箱は立体としてより広く分類される多くの構成の１つである。立体の重量を計算するために、オペレータ１９は、第１のリレーション２１を経由して受け取った立体の体積に、第２のリレーション２３を経由して受け取った立体の密度を乗算する。この例では、立体は、計算重量コマンドが引数として供給されるというよりもむしろ、デザイン中ですでに指定されている。この依存関係は、箱を表示するデータオブジェクト１７に接続されているリレーション２１によってグラフに表示される。密度が、デザイン中で前もって指定されていないので、箱の重量を計算するコマンドが引数としてユーザーによって供給される。依存関係の不足は、密度の引数を表示するデータオブジェクト２５に接続されているリレーション２３によってグラフに表示され、グラフの中ではどのオペレータからも出力されない。オペレータ１９がデータオブジェクト１７と２５に作用した結果は、リレーション２７とデータオブジェクト２９によってグラフに表示される。データオブジェクト２９は、オペレータ１９によって作成されたソフトウェアエンティティを表示し、リレーション２７は、箱の重量としてオペレータの結果を確認する。
【００４１】
図２に示された簡単な例から理解されるように、本発明により作成された依存関係グラフは、インタラクティブセッション中に作成されたデザインの構造的依存関係を明示している。グラフは、箱の寸法を表示しているデータオブジェクト３〜５と同様に、箱の重量２９が密度データオブジェクト２５に依存していることを明示している。同様に、グラフは、箱を表示しているデータオブジェクト１７が密度データオブジェクト２５に依存していないことを明示している。従って、デザイナーがインタラクティブセッション中に箱の密度の修正を選択する場合、デザインを更新するために再実行される必要のあるグラフの唯一の部分はオペレータ１９であり、オペレータ７は、再実行される必要がない。このように、デザインの修正がなされたとき、依存関係グラフは、本発明が、修正データオブジェクトに依存するオペレータのみを再実行することを可能とする。図示された例は全く簡単なものであるが、本発明のこの特徴によって提供される計算時間の節減は特に大きなデザインについて著しいことは、明らかである。
【００４２】
本発明の関連サブシステムがインストールされたＣＡＤシステムのユーザー側からの背景のグラフ的な表示が図３に示される。このＣＡＤシステム３５は、従来のＣＡＤコマンド３９としてユーザーからの入力を受け取るユーザーインタフェース３７を含む。概して、ユーザーは、一連のＣＡＤコマンド３９を入力することによってＣＡＤシステムで、インタラクティブデザインセッションを行う。ＣＡＤコマンドに応答して、ユーザーインタフェース３７は、ＣＡＤシステムの対応固有ＡＰＩ４３を順次呼び出す対応結合ＡＰＩ４２を呼び出す。ＡＰＩ４３は、製品デザイン４５を作成するために実行される。インタラクティブデザインセッション中に、結合ＡＰＩ４３とグラフコントローラ４７とは、共に、図２に図示された依存関係グラフのような、製品デザイン４５の構造的依存関係を表示する依存関係グラフを生成する。デザインセッションの最後で、ＣＡＤシステムは、また、依存関係グラフから、実行されたときに製品デザイン４５の構造的依存関係をも表示するＣ＋＋のような非固有の言語でコンピュータプログラム４９を生成することができる。その後、ユーザーは、ＣＡＤシステムのエディタ／コンパイラ／リンカ５１を用いて、修正された製品デザインを表示するためにコンピュータプログラム４９を編集し、修正された製品デザイン４５を生成するために、ＣＡＤシステムのためにプログラムをコンパイルしリンクする。代わりに、ユーザーは、視覚的なプログラミング環境を使って依存関係グラフをグラフィカルに編集することができ、この依存関係グラフは修正された製品デザイン４５と修正されたコンピュータプログラム４９とを生成するために使用できる。視覚的なプログラミング環境の出力は、デザインを修正するための望ましいデザイン動作を遂行する対応結合ＡＰＩに視覚的なプログラミング環境から受信された表現を翻訳するインタプリタ５２に供給される。
【００４３】
II．結合サブシステムの統合
上述したように、本発明が種々のソフトウェアシステムのいずれにもこれらのシステムのユーザーにとって分かりやすいように、使用可能にするために、各ソフトウェアシステム上で１度だけ実行して、本発明の能力を供給するソフトウェアツールが供給される。このソフトウェアツールはどんな標準コンピュータ言語でも記述できるが、Ｃ＋＋のようなオブジェクト指向プログラミング言語で記述するのが好ましい。図４は、このツールの構成を図示し、結合ＡＰＩ構築用ツール６１として参照される。ツール６１は、本発明の特徴を組み入れるためにソフトウェアシステムにおいて各アプリケーションプログラミングインタフェース（ＡＰＩ）に関して一度だけ実行され、各ＡＰＩについて対応ＡＰＩイタンフェースを生成する。発明の１つの環境において、構築用ツール６１は、ソフトウェアシステムの各ＡＰＩに個別に作用する。
【００４４】
上述したように、ＡＰＩは、一般にユーザーから受け取られることができるコマンドに対応するシステム内の高水準のソフトウェアファンクションである。図２の例では、ＣＡＤシステムは、箱を挿入し、そして、立体の重量を計算するファンクションを実行するＡＰＩを有している。概念的には、各ＡＰＩについて構築用ツール６１によって生成される結合ＡＰＩは、２つの役割を実行する。第１に、製品デザインの生成に関して対応ＡＰＩが、ソフトウェアシステムに対して実行するのと同じ役割を実行する。例えば、箱を挿入するための図２の例におけるＡＰＩに対して生成される結合ＡＰＩは、製品デザイン内に箱を入れて、ＣＡＤシステム上でそれを表示するファンクションを実行する。第２に、各結合ＡＰＩは、対応するＡＰＩによって行われる動作を依存関係グラフに表示する役割を実行して、ＡＰＩによって生成されるデザインの一部が、それらがどのように製品デザインの他の様相に関連づけられるかを理解できるようにする。
【００４５】
各結合ＡＰＩは２つの役割を実行するので、構築用ツール６１は、ただ単に各ＡＰＩに対する２つのファンクション、言い換えれば各役割を実行する１つのファンクションを生成できるだけである。しかしながら、本発明の好ましい実施の形態では、構築用ツール６１は、結合ＡＰＩプロセッサとして参照され、各結合ＡＰＩのグラフ構成を生成するための一般的ファンクションと、製品デザインのデザインアクションを遂行する役割を実行する各結合ＡＰＩ用の１つのソフトウェアファンクションに対する呼び出しを決定するマクロコールを生成する。結合ＡＰＩプロセッサに供給される引数は、結合ＡＰＩプロセッサを呼び出す結合ＡＰＩの名称であり、その結合ＡＰＩに対する引数である。構築用ツール６１は、また、各結合ＡＰＩ用のソフトウェアエンティティ（後述する）を作成し、ソフトウェアエンティティは、前記結合ＡＰＩ用に構築されるグラフエンティティのトポロジィと、結合ＡＰＩにより行われるデザインアクションを表示するためにグラフ内に生成されるオペレータにより表示されるファンクションを記述する。
【００４６】
図４にグラフィカルに示すように、構築用ツール６１は、ソフトウェア内で固有のＡＰＩ６２のファンクションテンプレートに作用するとともに、各ＡＰＩに対して結合ＡＰＩ６３を生成する対応結合ＡＰＩ６６のファンクションテンプレートに作用する。各ＡＰＩと結合ＡＰＩとのファンクションテンプレートは、ファンクション名、その引数と結果のデータタイプ、そして引数名と結果名とを定義する。構築用ツールによって生成された各結合ＡＰＩは、３つの構成要素、即ち、結合ＡＰＩマクロコール６５、結合ＡＰＩデータ構成要素６７、そして結合ＡＰＩのオペレータエバリュエータ６９を含む。以下に、さらに詳細に説明するように、構築用ツール６１が、各々に関して結合ＡＰＩを生成するために新しいソフトウェアシステムのＡＰＩ上で実行されたとき、システムのユーザーインタフェースは、また、各ユーザーコマンドが対応ＡＰＩを直接呼び出すというよりもむしろ、その対応結合ＡＰＩを呼び出すように、修正される。このように、ラッパーが、本発明の付加的な能力がユーザーにわかりやすい方法で供給されるようにソフトウェアシステム内の各ＡＰＩに対して実装される。
【００４７】
インタラクティブデザインセッション中にユーザーコマンドによって呼び出されたとき、各結合ＡＰＩは、順次に結合ＡＰＩプロセッサ７１（図５）を呼び出す。プロセッサ７１は、最初に、コマンドによって行われるデザインアクションを表示するオペレータを含むために依存関係グラフを更新し、そして製品デザインにデザインアクションを実際に行うファンクションが確実に呼び出されるようにする。結合ＡＰＩ６３の構成要素の各々によって実行される役割は結合ＡＰＩプロセッサ７１の役割と密接に結びつくので、本発明のこれらの様相を図５を参照しながら説明する。図５は、ＡＡＰＩ構成要素６３の結合ＡＰＩプロセッサ７１とＣＡＤユーザーインタフェース３７との関係を図示している。
【００４８】
プロセッサ７１を呼び出す各結合ＡＰＩは、特定数のデータオブジェクトと、各々がデータオブジェクトの１つのオペレータに対する関係を定義する対応する数のリレーションと、を有するオペレータによって依存関係グラフに表示されている。結合ＡＰＩプロセッサは、依存関係グラフの各オペレータ、リレーション、そしてデータオブジェクトを表示するためにソフトウェアエンティティを作成する。このような関係において、ソフトウェアエンティティという言葉は、例えばＣ＋＋のようなオブジェクト指向プログラミング言語のオブジェクト、あるいは、例えばＣのようなプログラミング言語の構造であるようなソフトウェアプログラムによって作成されるエンティティを示すことを意図する。
【００４９】
結合ＡＰＩプロセッサ７１は、ＡＡＰＩによって実行される特別なデザインアクションにかかわりなく、同じ方法で全ての結合ＡＰＩからコールを扱う点において一般的である。例えば、図２に示される依存関係グラフを参照すると、結合ＡＰＩプロセッサ７１は、同じ方法で箱の挿入とその重量の計算を夫々表示して、データオブジェクトとリレーションにそれらを依存関係グラフ内で単に結び付けるオペレータ７と１９とを取り扱う。
【００５０】
前述のソフトウェアシステムの各ＡＰＩについて構築ツール６１を実行して各ＡＰＩに関する結合ＡＰＩを生成するのに加え、本発明の統合処理は、また、ユーザーから受け取った各コマンドに応答して、ＡＰＩを直接呼び出すというよりもむしろ、インタフェース３７が対応結合ＡＰＩを呼び出すように、システムのユーザーインタフェース３７を修正する。特に、ユーザーインタフェースによって呼び出されるのは、各結合ＡＰＩ６３のマクロコール構成要素６５である。ユーザーインタフェースは、受け取られたコマンドに含まれるすべてのデータ引数を結合ＡＰＩに渡す。図２に示された具体例に関し、ユーザーが箱を挿入するためのコマンドを入力したとき、ユーザーインタフェースは、そのコマンドに対応した結合ＡＰＩを呼び出して、これらを箱の長さ、幅、高さと中心点に関するコマンド内で受け取られたデータ引数に渡す。ユーザーインタフェースによって結合ＡＰＩのマクロコール６５が呼び出されると、それは、順次結合ＡＰＩプロセッサ７１（図５）を呼び出し、プロセッサに、ファンクション（例えば、挿入箱、重量の計算）を確認するのに使われるマクロ名と同様に、マクロ６５を呼び出したコマンドと共に受け取られた引数の順序リストを含むデータストリングをプロセッサに渡す。
【００５１】
結合ＡＰＩは一般的な依存関係グラフ構築用であり、何らかの特別な結合ＡＰＩを扱うために特にデザインされているわけではないので、呼び出すマクロ名と命令データのリストを含むストリングは、呼び出すマクロに基づいて依存関係グラフが更新される方法を指定するには不十分である。このように、プロセッサ７１は、呼び出すストリング内のマクロ名を使ってそのデータ構成要素６７から呼び出すＡＡＰＩ６３についての付加的な情報を受け取る。各結合ＡＰＩのデータ構成要素６７は、対応するＡＰＩに関する入力データオブジェクト数、これらのオペレータとの夫々のリレーション、そして結果としてのデータオブジェクトのリレーション数を定義する原文情報を含む。ソフトウェアシステムを立ち上げるときはいつでも、そしてデザインセッションの開始前に結合ＡＰＩプロセッサ７１は、（データ構成要素６５によって供給された）各結合ＡＰＩ６３を記述するＡＳＣＩＩデータファイルを解読して、ＡＡＰＩ名によって刻まれた各ＡＡＰＩに関するエントリーを含むハッシュテーブル７３を生成する。インタラクティブデザインセッション中にＡＡＰＩによって呼び出されると、プロセッサ７１は、ハッシュテーブル７３内の対応エントリーを使って、呼び出すＡＡＰＩを依存関係グラフに表示するオペレータ、リレーションとデータオブジェクトを作成する。各結合ＡＰＩのためのハッシュテーブルエントリーはソフトウェアエンティティの形態で、ＡＡＰＩの入力データオブジェクトの数、ＡＡＰＩのオペレータに対する夫々のリレーション、そしてＡＡＰＩの出力データオブジェクトのリレーションを確認する。
【００５２】
III.依存関係グラフの作成
結合ＡＰＩプロセッサ７１は、デザインセッション中にマクロコール６５によって呼び出されると、プロセッサ７１は、呼び出すマクロ名を使って、呼び出すＡＡＰＩの構造特性に関係する情報を含むソフトウェアエンティティを出力するハッシュテーブル７３にインデックス化する。例えば、図２に関連して記載されるような箱に挿入するためのファンクションに関係するＡＡＰＩからの呼び出しに関して、ハッシュテーブル７３から出力された対応ソフトウェアエンティティは、マクロ名に沿ってプロセッサ７１を通過したデータの命令リストにおける第１の引数が箱の長さであり、第２の引数が幅であり、第３の引数が高さであり、そして第４の引数が箱の中心点であることを示す情報を含む。結合ＡＰＩプロセッサ７１は、ハッシュテーブル７３から出力されたソフトウェアエンティティを照会してプロセッサを呼び出した特別のＡＡＰＩマクロのために依存関係グラフが更新される方法を判定する。このファンクションはハッシュテーブルから出力されたソフトウェアエンティティに、呼び出されたＡＡＰＩに関係づけられている入力の数を尋ねる。次に、結合ＡＰＩプロセッサ７１は、そのエンティティに、命令データのリストの第１の引数に関係する名前は何であるかを尋ね、そして（例えば、長さ、幅、高さのような）名前を使ってオペレータに対するデータオブジェクトに対するリレーションを定義する。結合ＡＰＩプロセッサ７１は、入力と出力のデータオブジェクトのすべてのリレーションが定義されるまでこの方法を続行する。プロセッサ７１は、プロセッサ７１に渡された情報のストリングに含まれる呼び出すマクロ名からオペレータ名を引き出す。
【００５３】
前述したように、結合ＡＰＩプロセッサは依存関係グラフのオペレータ、リレーション、そしてデータオブジェクトの夫々を表示するためのソフトウェアグラフエンティティを作成する。各オペレータ（例えば、図２の例における挿入箱と重量の計算）のために作成されたグラフエンティティは、リレーションを表示するグラフエンティティに対するポインタのリストを含んでいる。各ポインタは、リレーションの１つを表示するグラフエンティティをストアするメモリ場所(location)の  アドレスを含む。各リレーションのために作成されたグラフエンティティは、リレーション名、そして、グラフ内のリレーションに接続されたデータオブジェクトを表示するグラフエンティティをストアするメモリ場所のアドレスを含むポインタを含む。最後に、依存関係グラフにデータオブジェクトを表示する各グラフエンティティは、データオブジェクトに対応する引数値がストアされたメモリ場所に対するポインタを含む。以上から、ＡＡＰＩに対するオペレータ、リレーション、そしてデータオブジェクトの構造的な関係を判定するために結合ＡＰＩプロセッサ７１によって照会される各ＡＡＰＩのためのソフトウェアエンティティのハッシュテーブルを設けたことにより、システム内の各ＡＰＩのために個別のグラフ処理ファンクションが生成されることが要求されるというよりはむしろ、ソフトウェアシステムに付け加えられた単一の付加的なファンクション（例えば、プロセッサ７１）のみによって依存関係グラフの作成が達成できることが理解される。
【００５４】
IV. 依存関係グラフの評価の概略
結合ＡＰＩマクロコールに応答して依存関係グラフを更新するのに加えて、結合ＡＰＩプロセッサは、また、呼び出す結合ＡＰＩによって指定された製品デザインにデザインアクションを行うために、新しく作成された各オペレータ評価を開始する。依存関係グラフの各オペレータを表示するソフトウェアエンティティは、そのマクロコールがオペレータの作成という結果になるＡＡＰＩのオペレータエバリュエータ６９（図５）に関係する２つのポインタを含む。第１のポインタは、オペレータエバリュエータ６９がストアされるライブラリを指し、そして第２のポインタはオペレータエバリュエータであるライブラリ中のファンクション名を指す。このように、結合ＡＰＩプロセッサ７１は、ＡＡＰＩからの呼び出しに応答して依存関係グラフを更新した後、プロセッサ７１は、それ自身の評価のために新しく作成されたオペレータを呼び出す。この処理は図５に図示されており、結合ＡＰＩプロセッサ７１が、それ自身を評価するために図２の重量計算オペレータ１９を呼び出しているのが示される。
【００５５】
前述したように、構築用ツール６１（図４）によって作成された各ＡＡＰＩは、ソフトウェアシステム内の固有ＡＰＩに対するラッパーである。各ＡＡＰＩのためのオペレータエバリュエータ６９は、対応する固有ＡＰＩ名を呼び出すファンクションである。呼び出されたとき、オペレータエバリュエータ６９は、依存関係グラフ内のエバリュエータオペレータに接続された入力データオブジェクトから引数を収集し、これらの引数を固有のＡＰＩによって予想される形式にフォーマットし、更に、望ましいデザインファンクションを完成させるための正しい順序の引数を用いてＡＰＩを呼び出す。再び図２を参照すると、箱を挿入するためのＣＡＤシステム内の固有ＡＰＩは、例えば、渡されるデータ引数が長さ、幅、高さ、そして中心として定められることを期待する“CV＿INSERT＿BOX(l,w,h,center)"と命名される。ユーザーが、長さを２とし、幅を３とし、高さを４とし、そして中心座標を（０，０）として指定する引数により箱を挿入するコマンドを入力する場合、ユーザーインタフェースはCV＿INSERT＿BOX ＡＰＩに対応するＡＡＰＩを呼び出して、依存関係グラフ内にデータオブジェクト３〜５と１７、リレーション９〜１２と１５、そしてオペレータ７を作成する。ＡＡＰＩプロセッサ７１がオペレータ７にそれ自身を評価するように命令すると、結合ＡＰＩのオペレータエバリュエータ６９（図５）は、データオブジェクト３〜５にストアされた引数を収集して命令し、そして“CV＿INSERT＿BOX(2,3,4,0,0)" として固有のＡＰＩを呼び出す。この呼び出しは、本発明のソフトウェアツールが固有ＡＰＩに対するラッパーを作成するためにシステムにインストールされていない場合には、ソフトウェアシステムのユーザーインタフェース３７により直接に行われるものに一致する。
【００５６】
プロセッサ７１がそれ自身を評価するためにグラフオペレータを呼び出すとき、対応するオペレータエバリュエータ６９（図５）にとって、製品デザインに指定されたデザインアクションを行うために呼び出される固有ＡＰＩにより要求される順序の引数を収集して構成することは、直截的処理である。各ＡＡＰＩのためのオペレータエバリュエータ６９は、呼び出される対応固有ＡＰＩの名前を含むだけでなく、ＡＰＩに供給される引数の名前と順序をも含む。例えば、図２に示されたオペレータ７を評価するとき、対応ＡＡＰＩエバリュエータ６９は、まず、オペレータ７に、箱の長さを表示する引数を供給するように要求する。オペレータ７を表示するグラフエンティティはそれ自身を確認するためにそのリレーションの夫々を要求するファンクションを実行する。一旦、長さのリレーションが確認されると、オペレータ７に表示するグラフエンティティは、長さのリレーション９に表示するグラフエンティティに箱の長さを定義する引数を供給するように要求する。そして、長さのリレーション９に表示するグラフエンティティは、データオブジェクト３に表示するグラフエンティティにその引数を渡すことを要求し、一旦、引数が受け取られると、順次、引数を、オペレータエバリュエータ６９に引数を返す挿入箱オペレータ７を表示するグラフエンティティに渡す。エバリュエータ６９は、同じ方法で残りの引数を要求して受け取る。一旦、すべての引数が収集されると、オペレータエバリュエータは、引数の順序を指定するそれ自身の呼び出しにより、製品デザインに適当なアクションを行うために、固有ＡＰＩ“CV＿INSERT＿BOX"を呼び出す。
【００５７】
固有ＡＰＩが呼び出されると、これは渡された引数によりデザインアクションを実行し、更に、順次結果を、評価されたオペレータを表示するグラフエンティティに渡すオペレータエバリュエータに戻す。そして、評価されたオペレータを表示するグラフエンティティは、結果をオペレータの出力リレーションを表示するグラフエンティティに渡し、このグラフエンティティにより、順次結果を、そのデータオブジェクトを表示するグラフエンティティに渡し、このグラフエンティティは、最終的にデータオブジェクトにより指示されたメモリ場所にその結果をストアする。このように、他のオペレータに対して引数としての役割を実行できる評価されたオペレータの結果は、依存関係グラフに入力される。
【００５８】
１．拡張コマンドのフォーマット適応性
本発明の１つの実施の形態では、１つ又はそれ以上のオペレータエバリュエータ６９（図４と５）は、一定のデザインアクションがユーザーのレベルで定義できる方法に関するソフトウェアシステムの適応性を増大させる能力を供給される。例えば、上記の例は箱の長さ、幅、高さと中心の座標位置によって定義されるような箱を示しているが、箱の角の位置だけを定義するような、ユーザーが箱を定義できる他の方法があることがわかる。これは、デザイナーによって行う方法が具体的な長さ、幅と高さによるよりは、むしろ、この方法で箱を定義することがより利点があるような一定のデザイン環境には望ましい。従来、ＣＡＤシステムが、箱がその角によって定義される固有ＡＰＩを含まない場合、ユーザーは、この方法で箱を定義するコマンドを供給されない。しかしながら、本発明のオペレータエバリュエータファンクションは、ユーザーが利用できるコマンドのフォーマットに増大した適応性を供給できる固有ＡＰＩに対してラッパーを実装する。例えば、本発明のツールが走るＣＡＤシステムが、長さ、幅、高さ、そして中心点に関して定義された箱の作成を供給するだけである場合、本発明のオペレータエバリュエータファンクションはユーザーに、箱の角によるような付加的な方法で箱を定義させることができる。
【００５９】
本発明の好ましい実施の形態では、依存関係グラフとそこから生成されたコンピュータプログラムが、デザインセッション中にユーザーによって行われるデザインアクションと非常に密接に相関する方法で製品デザインの構造的依存関係を表示する。それゆえに、付加的なコマンドフォーマットを供給する本発明の特徴が使われたとき、依存関係グラフは、ユーザーによって指定された方法で作成され、ストアされる。例えば、ユーザーが箱の角によって箱を定義するために能力が供給され、そしてユーザーがこの能力を開発すれば、箱を挿入するデザインアクションを表示する依存関係グラフオペレータは箱の角によって箱を定義するデータオブジェクトとリレーションとを含むことになる。オペレータがそれ自身を評価するために呼び出され、順次、そのＡＡＰＩオペレータエバリュエータ６９（図５）を呼び出すとき、エバリュエータは依存関係グラフ内のオペレータの表示をソフトウェアシステムの固有ＡＰＩを呼び出すために要求される形態に変換する。上記の箱を挿入する例を使うと、挿入箱オペレータに関連するオペレータエバリュエータは前述の方法で箱の角を定義する引数を収集し、それらの引数を処理して、この方法で調整され配列される引数にのみ作用する固有挿入箱コマンドに渡される長さ、幅、高さ、そして中心座標の引数を生成する。ユーザーに供給される増大した適応性は、新しい固有ＡＰＩの作成を必要としない。なぜならば、適応性は、固有ＡＰＩに対する本発明によって実装されるラッパーによって遂行されるからである。
【００６０】
本発明の好ましい実施の形態において、ユーザーに供給されるコマンドフォーマットの適応性が各コマンドに対応するＡＡＰＩオペレータエバリュエータ６９で遂行されるにもかかわらず、本発明のこの特徴は他の方法で遂行できることがわかる。例えば、ユーザーから入力されるフォーマットと固有ＡＰＩによって要求されるフォーマットとの間の変換は、ＡＡＰＩデータ構成要素で実行して、依存関係グラフが固有ＡＰＩによって予想されるフォーマットで生成できるようにする。フォーマット変換がこの方法で実行されたとき、ＡＡＰＩオペレータエバリュエータはどんなフォーマット変換の実行をも必要としない。
【００６１】
V.依存関係グラフへの加入を反映するためのソフトウェアアプリケーションエンティティの更新
ソフトウェアシステムの各固有のＡＰＩに対するＡＡＰＩラッパーを生成するのに加えて、本発明は、また、プロダクトデザインを表示するソフトウェアシステムによって生成されたソフトウェアアプリケーションエンティティを修正して、各アプリケーションエンティティが、依存関係グラフに加入しているかどうか、また、その加入している場所をわかるようにする。例えば、本発明がインストールされたソフトウェアシステムがＣＡＤシステムであれば、これにより生成されたアプリケーションエンティティは、製品デザインを表示する箱、円柱、及び他の構造を含むことができる。例えば、図２の例において、箱を挿入するためのオペレータ７の評価の結果は、箱を表示するアプリケーションエンティティであり、その記述は、本来的に箱を定義するために使われる引数（長さ、幅、高さと中心点）を含んでいる。
【００６２】
前述のように、本発明は、オブジェクト指向プログラミング言語で実施されるのが好ましい。他のプログラミング言語が本発明を実施するのに使用されることはできるが、オブジェクト指向プログラミング言語は、各アプリケーションエンティティが依存関係グラフに加入しているかどうか、また加入している場所を理解できるように、デザインセッション中にソフトウェアシステムによって作成されたアプリケションエンティティに簡単な修正ができる能力を有する点で有利である。オブジェクト指向プログラミング言語により、アプリケーションエンティティは、共通のクラスで定義されるいくつかの共通の特徴を有することができる。図２の依存関係グラフを参照すると、重量計算オペレータ１９は、立体の体積に密度を乗算することにより立体の重量を計算する。図２において操作される具体的な立体は、円柱、球等を含むより広いクラスの立体の１つの箱である。オブジェクト指向プログラミング言語で様々なタイプのアプリケーションエンティティを定義する場合、階層的な構造を使用できる。例えば、立体クラス（例えば、体積に密度を乗算することにより立体の重量を提供するファンクション）に属する特定のタイプのアプリケーションエンティティのすべてに共通のファンクションと指標は、立体のクラスの定義において一旦定義できる。そのクラス内のさらに多くの特定のアプリケーションエンティティ（たとえば箱、円柱、球等）の夫々の定義は、その立体クラスの参照を含み、ここから受け継ぐ。このように、立体クラスの定義に提供されるファンクションと指標は、クラスから受け継いだアプリケーションエンティティの夫々の定義の一部を形成し、アプリケーションエンティティのより特定のクラスの各々の定義において複製される必要がない。例えば、箱のクラスの各アプリケーションエンティティは、箱の重量を決定する特定のファンクションなしに、この決定の能力を有する。なぜならば、そのファンクションは、箱のクラスが受け継いだものから、立体の定義において定義されるからである。
【００６３】
オブジェクト指向プログラミング言語に役に立つ受け継いだ能力を使い、各アプリケーションエンティティが依存関係グラフに加入しているのであれば、加入している場所を決定するのに必要なファンクションと指標は、結合変数クラスとして参照される単一のクラスに供給でき、このクラスから、製品デザインの部分を表示するためにソフトウェアシステムによって作成された各アプリケーションエンティティに受け継がれる。ユーザーによってデザインに入力された各引数は、また、結合変数クラスから受け継ぐアプリケーションエンティティとして定義される。結合変数クラスは、依存関係グラフの特定のデータオブジェクト（例えば、図２のデータオブジェクト３〜６，１７，２５と２９）に対するポインタを確認するためのフィールドを含む。このように、製品デザインの部分を表示するため、あるいはユーザーから入力された引数を表示するためのソフトウェアシステムにより作成されたアプリケーションエンティティは、もしあれば、依存関係グラフ内でそれを表示する特定のデータオブジェクトを指し示すこのポインタを使用する。ポインタフィールドが特定のアプリケーションエンティティにない場合、アプリケーションエンティティが依存関係グラフの対応するデータオブジェクトを割り当てられてないため、グラフにまだ加入していないことを示す。もし、ポインタフィールドが値を持っているのであれば、アプリケーションエンティティは指し示されたデータオブジェクトによりグラフ中に表示される。
【００６４】
結合変数クラスは、また、クラスから受け継いだアプリケーションエンティティの各々に渡される２つのファンクションを供給する。第１のファンクションは、アプリケーションエンティティが依存関係グラフに付け加えられたとき、上記ポインタフィールドを、対応するデータオブジェクトの場所を確認する特定の値にセットする。第２のファンクションは、アプリケーションエンティティが依存関係グラフの中のどこに存在しているかが問われたとき、ポインタの値を検索し、その値を戻す。以上、述べたように、ソフトウェアプログラムによって生成されたアプリケーションエンティティに加えて、ユーザーによってシステムに入力された引数は、また、結合変数クラスに依存するアプリケーションエンティティとして表示される。それゆえに、データオブジェクトとして依存関係グラフに表示される各アプリケーションエンティティは、結合変数クラスに依存するので、各アプリケションエンティティは、データオブジェクトポインタフィールドとポインタの値をセットして検索するファンクションを含む。
【００６５】
結合変数クラスによりアプリケーションエンティティの夫々に供給される能力は、図２に示される例を参照すると、以下の方法でグラフの作成とマネージメントとに使われる。まず、ユーザーは、箱を挿入するためのコマンドを入力する。このコマンドのエントリーにより、ＡＡＰＩ６３（図５）が上述された方法で結合ＡＰＩプロセッサ７１を呼び出すことになる。ＡＰＩプロセッサ７１を呼び出す際に、ＡＡＰＩマクロコール６５は、プロセッサに、呼び出すマクロに関連する引数、例えば、箱の長さ、幅、高さ、そして中心位置を渡す。これらの引数の各々は、結合変数クラスに依存するアプリケーションエンティティの形態で渡される。このようにして、依存関係グラフ上のマクロコールの影響を決定するために、結合ＡＰＩプロセッサ７１は、各引数がグラフに表示されているか否か、そしてグラフのどこに表示されているのかを決定するために、引数を表示するアプリケーションエンティティの夫々に照会する。引数はグラフに前もって表示されていないため、引数の１つを表示するアプリケーションエンティティの夫々はそのデータオブジェクトポインタに零の値を含む。これらの零のポインタを読み出すと、ＡＰＩプロセッサ７１は、各引数のためのデータオブジェクトを表示する新しいグラフエンティティを作成し、引数アプリケーションエンティティに対し、新しく作成されたグラフエンティティのメモリ場所にそのデータオブジェクトポインタをセットすることを命令する。そして、ＡＰＩプロセッサは、上記方法で、箱を挿入するためのオペレータ７とリレーション９〜１２とを表示するグラフエンティティを作成する。加えて、ＡＰＩプロセッサ７１は、リレーション１５と結果としてのデータオジェクト１７とを表示するグラフエンティティを作成する。そして、プロセッサ７１は、オペレータ７に、それ自身を評価することを命じて、そのＡＡＰＩオペレータエバリュエータ６９の呼び出しを行う。上述の方法でオペレータエバリュエータは、挿入箱の固有ＡＰＩを呼び出し、エバリュエータに、作成した箱を表示するアプリケーションエンティティを戻す。そして、オペレータエバリュエータ６９は、箱を定義するアプリケーションエンティティのデータオブジェクト１７のためのメモリ場所を指し示すデータオブジェクトポインタを更新することによって、依存関係グラフへの加入に関する情報で箱を定義するアプリケーションエンティティを供給する。
【００６６】
図２に関する例に続いて、ユーザーから受け取られた次のコマンドは箱の重量を計算することである。このコマンドに応答して、対応ＡＡＰＩマクロコール６５は、結合ＡＰＩプロセッサ７１に、例えば、箱を定義するアプリケーションエンティティのような、重量計算ファンクションが実行されるための引数を渡す。ＡＰＩプロセッサ７１は、このアプリケーションエンティティに、依存関係グラフのそれに対応するデータオブジェクトを確認するポインタの値を特定することを要求する。このようなデータオブジェクトは前もって作成されるので、データオブジェクト１７のアドレスはプロセッサ７１に戻される。そして、プロセッサ７１は、重量計算オペレータ１９とリレーション２１を表示するグラフエンティティを生成することにより依存関係グラフを更新する。リレーション２１を表示するグラフエンティティでは、ａ′ポインタが、データオブジェクト１７を表示するグラフエンティティをストアするメモリ場所のアドレスを含むように更新される。このように、挿入箱オペレータ７上の重量計算オペレータ１９の依存関係は依存関係グラフに反映される。結合ＡＰＩプロセッサ７１は、また、上記方法で依存関係グラフを完成するために、その結合リレーションと同様に、新しいデータオブジェクト２５と２９とを作成する。
【００６７】
VI．依存関係グラフの作成と評価のための結合ＡＰＩプロセッサルーチン
依存関係グラフに加入するか否か、そしてどこに加入するのかを理解するための各引数とアプリケーションエンティティの上記能力は、ＡＡＰＩマクロによって呼び出されたときに、プロセッサ７１が実行するステップを示す図６に示された方法により依存関係グラフを作成する間、結合ＡＰＩプロセッサ７１によって利用される。まず、ステップ４０１では、結合ＡＰＩプロセッサ７１が、グラフエンティティを作成して、呼び出すマクロのデザインアクションに対応する依存関係グラフにおけるオペレータを表示する。そして、ステップ４０３では、本方法は、処理のためのマクロの引数の１番目を選択する。上述したように、各引数は、データオブジェクトにより依存関係グラフに、引数が表示されているのか、そしてどこに表示されているのかを示すポインタフィールドを含むアプリケーションエンティティとして結合ＡＰＩプロセッサ７１に渡される。
【００６８】
ステップ４０５では、本方法は、選択された引数のデータオブジェクトポインタを読み込んで、データオブジェクトポインタがないのかどうかを判定し、データオブジェクトポインタがないときは、本方法は、ステップ４０７に進み、依存関係グラフの新しいデータオブジェクトを表示するためにグラフエンティティが作成される。そして、引数を表示するアプリケーションエンティティが更新されて、そのデータオブジェクトポインタが新しく作成されたデータオブジェクトを指し示す。ステップ４０７でデータオブジェクトの作成が行われたあと、あるいはステップ４０５でデータオブジェクトがすでに引数用に存在していると判定される場合、本方法は、ステップ４０９に進み、ステップ４０１で作り出されたデータオブジェクトとオペレータとの間にリレーションが作成される。ステップ４１１では、処理されている引数が、呼び出すマクロに関連する最後の引数であるかどうかついて判定がなされ、そしてそうではないとき、本方法は、ステップ４０３に戻って処理するための他の引数を選択する。このように、本方法は、ステップ４０１で作成されたオペレータに結合される入力リレーションとデータオブジェクトを作成し、それらをオペレータに接続するためにステップ４０３〜４１１を実行する。
【００６９】
ステップ４１１で、最後の引数が処理されたと判定されたときは、本方法は、ステップ４１３と４１５に進み、結果としてのデータオブジェクトとリレーションとが、夫々、オペレータのために作成される。そして、本方法は、ステップ４１７に進み、結合ＡＰＩプロセッサ７１が、オペレータにそれ自身を評価することを要求する。データの順序リストとともに、対応する固有ＡＰＩを呼び出すＡＡＰＩオペレータエバリュエータ６９によって実行される評価は、アプリケーションエンティティの形態で結合ＡＰＩプロセッサ７１に結果を戻す。ステップ４１８では、結果は、ステップ４１３で作成された結果としてのデータオブジェクトに関連づけられるが、結果を定義するアプリケーションエンティティでデータオブジェクトポインタを更新する。最後に、ステップ４１９では、プロセッサ７１は、結果を定義するアプリケーションエンティティを、その呼び出しが方法を開始させたマクロに戻す。
【００７０】
VII ．依存関係グラフの評価
図６の方法のステップ４１７においてオペレータの評価をプロセッサ７１が要求するのに応答して、すべてのオペレータに一般的な、そして、評価されたオペレータのオペレータエバリュエータ６９を呼び出す前に、オペレータによって要求される引数のすべてが更新されることを保証する引数の収集とオペレータの評価のルーチンが呼び出される。引数の収集ルーチンのステップは図７に示されている。初めに、評価されたオペレータに関係づけられている第１の引数が処理のためにステップ５０１で選択され、この引数が「同調しない」（out of synch) か否かについてステップ５０２にて判定がなされる。「同調しない」の語句は、変更されてはいるものの、まだ再評価されていない少なくとも１つのグラフエンティティに、引数を表示するデータオブジェクトが依存していることを示すために使われる。このように、引数が同調しない場合、本方法は、ステップ５０３に進んで、引数の更新が要求される。ステップ５０３で更新が要求された後、あるいは引数が同調していることがステップ５０２において判定された場合、本方法は、ステップ５０４に進み、評価されるオペレータのための引数のすべてが収集されたかどうかに関する判定がなされる。収集されていないと判定されたときは、本方法は、ステップ５０１に戻り、新しい引数が収集されるために選択される。このように、本方法は、オペレータのための引数のすべてが収集されるまで、また、同調しなかった引数が更新されるまで、ステップ５０１〜５０４を実行する。そして、本方法は、ステップ５０５に進み、評価されるオペレータに対応するオペレータエバリュエータ６９が呼び出される。
【００７１】
オペレータエバリュエータルーチンのステップは、図８に示される。初めに、評価されたオペレータに関連する第１の引数がステップ５０６にて選択され、そして、ステップ５０７にて、選択された引数に関係する値が、依存関係グラフに引数を表示するデータオブジェクトポインタから検索される。本方法は、それから、ステップ５０７へと進み、引数の値が、オペレータエバリュエータによって呼び出される固有のＡＰＩによって要求されるデータ型にキャストされる。依存関係グラフの各データオブジェクトは一般的であり、それが指し示す引数のフォーマットに関する情報を持ってはいない。例えば、引数は整数、箱を定義するアプリケーションエンティティ、円柱を定義するアプリケーションエンティティ、等とすることができる。このため、オペレータエバリュエータがＡＰＩを呼び出す前に、ＡＰＩによって要求されるデータ型に引数をキャストする。
【００７２】
ステップ５０９では、ＡＰＩに渡される引数のすべてが処理されたかいなかに関する判定がなされ、処理されていないとき、本方法は、ステップ５０６に戻り、他の引数が処理されるために選択される。このように、本方法は、オペレータに関係する引数のすべてを処理するまで、ステップ５０６〜５０９を実行する。すべての引数が処理されたとき、本方法は、ステップ５１０へと進み、引数が、呼び出される固有のＡＰＩによって要求される方法でフォーマットされる。上述したように、本発明の１つの実施の形態において、ＡＡＰＩのためのオペレータエバリュエータは、コマンドがフォーマットされることのできる方法で付加的なオプションをユーザーに供給する。ユーザーコマンドとそれに対応する依存関係グラフのオペレータとがＡＰＩとは異なってフォーマットされる場合、本方法は、ステップ５１０における引数をＡＰＩによって要求される引数に再フォーマットする。引数がフォーマットされた後、本方法は、ステップ５１１に進み、オペレータに対応する固有のＡＰＩが呼び出され、要求する方法で整理された引数が渡される。固有ＡＰＩは、オペレータエバリュエータに、ＡＰＩによって行われたデザインアクションの結果を表示するアプリケーションエンティティを戻す。ステップ５１２では、オペレータエバリュエータは、図６のステップ４１３のオペレータの結果のために作成されたグラフエンティティのデータオブジェクトポインタを更新する。
【００７３】
VIII．非正算(Non-directed Operations) の表示
以下の説明は、正算(directed)オペレータにより本発明の依存関係グラフに記述される正算に単に関係する。正算オペレータは、１つ又はそれ以上の入力から１つの出力へと、１つの方向への流れを有する。しかしながら、本発明は、非正算を支援するソフトウェアシステムに使用されることもできる。例えば、Ａ＝Ｂ＊Ｃという関係を表示するコマンドが実行されることもできる。これが正算であった場合、ユーザーは、ＢとＣとの値を編集できるだけであり、正算は、Ａという適当な値を生み出す。しかしながら、コマンドが、非正算であった場合、ユーザーは、二者択一的にＡの値を指定するか、システムにＢとＣとの値を決定させてこれらの積がＡの値に等しくなるようにする。非正算は、そのパラメータのいくつかからの変更を伝えることができ、入力と出力の完全な概念はない。
【００７４】
本発明は、単一の依存関係グラフでの正算と非正算の両方を表示する能力を提供し、正算は、正算オペレータにより表示され、非正算は、非正算オペレータにより表示される。以下に述べられるいくつかの限定を条件として、本発明は、正算オペレータの結果が入力として非正算オペレータに供給されることができ、また、その逆についても同様に供給されることができるように、正算オペレータと非正算オペレータとが、依存関係グラフを通して同時に実行されることを可能にする。
【００７５】
相互に接続された非正算オペレータのグループを解明するために、いくつかの解明エンジンが供給されるべきことが理解される。非正算は、また、制限セットを形成する相互に依存する非正算のグループとともに、制限として共通に参照される。本発明は、正算オペレータを含むか、あるいは含まないかにかかわらず、依存関係グラフに非正算オペレータを表示する方法に関し、非正算オペレータのグループによって形成された制限セットを解明するためのどんな特定のエンジンに関するものではない。本発明は、非正算オペレータの構造的な依存性を表示し、以下に述べる方法で制限セットとともにこれらをグループ化し、そして、制限セットを、それらを解明する制限解明エンジンに供給する。
【００７６】
非正算（即ち、制限）の例は、上述された例のような代数的な制限、平行な２つの線、直角な２つの線等を設定するような２つのオブジェクト間の幾何学的な制限、そしてオブジェクトがある種の空間的な関係を維持することを要求する２つのオブジェクトに対する空間的な制限を含む。例えば、本発明は、同時に起こる方程式のグループの構造的な依存関係を表示でき、これらを一緒に制限セットとして解明エンジンに供給することもできる。しかしながら、本発明は同時に起こる方程式を解明する特定のエンジンに関するものではない。
【００７７】
以上から理解されるように、非正算オペレータを支援する本発明の実施の形態が使われると、本発明の結合サブシステムがインストールされるソフトウェアシステムに制限解明エンジンが供給される。本発明は表示されることのできるようなタイプの制限に限定されない。しかしながら、本発明の結合サブシステムがインストールされた特定のソフトウェアシステムは、解くことができるタイプの制限に限定された制限解明エンジンを有してもよい。この場合、本発明は、ユーザーによって生成されたデザインをチェックして、デザインに形成された制限の各セットが有効であるか、即ち、制限解明エンジンが形成することができるタイプであるかどうかを判定する。支援されていない制限セットが形成されると、本発明は、以下に述べる方法でエラー状態としてこれを検出する。
【００７８】
正算オペレータは、１つの方向で評価されることができるだけなので、正算オペレータと非正算オペレータとが単一の依存関係グラフで接続することができるできる方法に制限がある。それが正算オペレータの結果であれば、非正算オペレータへの入力は固定された値を有すると考えられる。非正算各オペレータの各々は、少なくとも１つの固定されない入力を有さなければならない。例えば、Ａ＝Ｂ＊Ｃである上記非正算に関しては、入力ＢとＣとの両方とも固定化できない。なぜならば、固定された場合、Ａの値が変更されると、ＢとＣの両方とも固定されているので、要求される関係を維持できなくなるからである。このように入力ＢとＣとは、両方とも正算オペレータから供給されることができない。なぜならば、両方とも固定され、過度に制限されたケース又はエラー状態となるからである。しかしながら、入力ＢとＣとの一方が制限されない限り、例えば、他方の非正算オペレータから供給される限り、エラー状態は発生しない。なぜならば、Ａの値が変更されると、制限されない入力Ｂ又はＣが対応する方法で変更できるからである。
【００７９】
単一の依存関係グラフの正算オペレータと非正算オペレータとの使用にかかる他の制限は、サイクルが正算オペレータを含めるようにグラフに形成できないということである。当業者に理解されるように、スタートポイントからグラフを通る有効なフロー経路のトレーシングが、スタートポイントに戻るように導くと、グラフでサイクルが発生する。非正算オペレータだけを含むサイクルが有効に存在できるにもかかわらず、正算オペレータを含むいくつかのサイクルは、過度に制限されたエラー状態になる。
【００８０】
非正算がデザイン中で実行されたとき、本発明のチェッキングルーチンは、依存関係グラフを分析して上述の制限の１つを妨害せずに対応する非正算オペレータが付加されることができるかどうかを判定する。特に、ルーチンは、非正算オペレータが過剰に抑制されず、そして、値が固定されない入力の少なくとも１つを有することを保証する。加えて、ルーチンは、非正算オペレータの付加が、正算オペレータを含むグラフのサイクルの形成とはならないことを保証する。これは、付加される非正算オペレータで開始し、依存関係グラフの有効な各経路を通ることによって、これらのパスのいずれかが、非正算オペレータが付加された時点で戻るかどうかを決定するルーチンによって達成される。２つの禁止された条件のいずれかが発生すると、エラー信号が、非正算オペレータがユーザーによって試みられる方法で依存関係グラフに付加できないように生成される。エラーが起こらなければ、非正算オペレータはグラフに付加される。
【００８１】
上述したように、本発明は、制限セットを解明する特定のエンジンに関するもではない。むしろ、本発明は、非正算制限セットを含むことのできるデザインの図表的な表示に関する。以下に述べる方法で、本発明は、デザインの非正算制限の各セットの境界を決定して、これらの制限セットを同時解明用の解明エンジンに供給する。非正算オペレータだけを含む各サイクルは、グラフの正算オペレータの場所によって決定される制限セットの境界、あるいはグラフ自身の境界とともに、制限セットを形成する。
【００８２】
１．記号評価パス
図７及び図８に関連して上述したように、結合ＡＰＩプロセッサ７１が、依存関係グラフのオペレータが評価されることを要求すると、すべてのオペレータに一般的な評価方法が呼び出される。評価方法は、グラフマネージャー７５（図５）によって呼び出され、このグラフマネージャー７５は、以下により詳細に説明されるソフトウェアエンティティであり、本発明によって作成される依存関係グラフのマネージングを含む仕事を実行する。評価方法によって実行される基本のステップは、図７及び図８に関連して上述されている。この方法のための特定の実行は、非正算オペレータの使用を支援する本発明の実施の形態により説明される。本発明のこの実施の形態によれば、２つのパス方法は、依存関係グラフに対して実行される。記号パスについてとして参照される第１のパスの間、グラフは、リストが評価されるべき命令と同様に、評価されるオペレータのリストを形成するために質問される。リストに含まれているオペレータは、単一の非正算オペレータであるか、制限解明エンジンによって同時に評価されるべき非正算オペレータの制限セットである。第２のステップは、記号パス間に形成されたリストによって指定された順序の各オペレータの評価であり、評価パスとして参照される。
【００８３】
記号パスは、図９のフローチャートに示され、結合ＡＰＩプロセッサ７１が、依存関係グラフのオペレータがそれ自体を評価することを要求するときは、いつでも呼び出される。まず、ステップ８００にて、オペレータと制限セットとが評価される順序を定義するための記号パス中に、作成されるオペレータ評価リストのために、スタックが開かれる。この目的のために作成されるスタックは、オペレータと制限セットが、以下の方法でプッシュされ、ポップされる先入れ先出し(first-in first-out)スタックである。スタックリストが開かれた後、本方法は、ステップ８０２に進み、評価されるオペレータのための編集された（例えば、同調しない）データオブジェクトが処理のために選択される。概して、結合ＡＰＩプロセッサ７１は、そのデータオブジェクトの１つが、編集され、再評価を要求しない限り、オペレータの評価を要求しない。しかしながら、後述する本発明の視覚的編集能力が使用されると、オペレータ自体は、そのデータオブジェクト入力の１つを変えることなく、変更できる。この場合、本発明は同調しないデータオブジェクトの各々を設定して、各々が、記号パス間に処理されるようにする。
【００８４】
ステップ８０４では、依存関係グラフが、ステップ８０２における処理のために選択されたデータオブジェクトに直接依存するすべてのオペレータのリストを形成するために質問される。正算オペレータが、データオブジェクトがオペレータに入力として供給されたときにデータオブジェクトに直接依存するのに対して、非正算オペレータは、何らかの方法でデータオブジェクトに直接接続されたときにデータオブジェクトに直接に依存する。ステップ８０４では、依存関係グラフを通して伝達するための試みはなされず、また、データオブジェクトの変更により影響されるかもしれない点において、データオブジェクトに、間接的に依存する他のオペレータの場所を見つける試みはなされない。なぜならば、これらのオペレータは、後述される方法で記号パスの反復的な性質を通して確認されるからである。
【００８５】
ステップ８０６では、ステップ８０４で形成されたリストで確認されたオペレータの１つが、処理のために選択され、そしてステップ８０８では、このオペレータが正算オペレータであるのかどうかについて判定がなされる。選択されたオペレータが正算オペレータであるときは、本方法は、ステップ８１０に進み、正算オペレータを処理するためのルーチン（図９）が呼び出される。反対に、選択されたオペレータが正算オペレータではないとき、本方法は、ステップ８１２に進み、非正算オペレータ（図１１及び図１２）を処理するルーチンが呼び出される。オペレータ処理ルーチンは、評価のための適切な順序でオペレータ評価スタック上に、処理されるオペレータをプッシュし、このルーチンは、以下、詳細に説明される。
【００８６】
最も新たに、選択されたオペレータの処理を扱うためにステップ８１０または８１２のいずれかで呼び出された適当な処理のルーチンが、記号パスに戻ると、本方法は、ステップ８１４に進み、ステップ８０４で形成されたリストのオペレータのいくつかが処理のために残っているかどうかについて判定がなされる。処理が残っている場合、本方法は、ステップ８０６に戻り、他のオペレータが処理するために選択される。このように、本方法は、ステップ８０２で処理するために選択された第の編集データオブジェクトに直接依存しているステップ８０４で作成されたリストのオペレータのすべてを処理するためにステップ８０６−８１４を実行する。
【００８７】
処理するオペレータが残っていないとステップ８１４にて判定されると、本方法は、ステップ８１６に進み、その評価が方法を呼び出したオペレータのための編集データオブジェクトが処理されるために残っているかどうかについての判定がなされる。そして、少なくとも１つが処理のために残っているとき、本方法は、ステップ８０２に戻り、他の編集データオブジェクトが処理のために選択されるか。このように、本方法は、評価されるオペレータのための編集データオブジェクトのすべてが処理されるまで、ステップ８０２−８１６を実行する。これらのデータオブジェクトのすべてが処理されたとステップ８１６にて判定されたとき、本方法は終了する。
【００８８】
図９のステップ８１０で呼び出される正算オペレータを処理するルーチンは、図１０のフローチャートによって示される。まず、ステップ８２０では、ルーチンは、処理されるオペレータが、すでにオペレータエバリュエータスタック上にプッシュされているかどうかを判定し、そうであるときは、ルーチンは、単に終了する。オペレータがスタック上にはプッシュされていないと判定されたとき、本方法はステップ８２２に進み、正算オペレータに入力されるデータオブジェクトの１つが、処理のために選択される。ステップ８２４では、選択されたデータオブジェクトが同調しないかどうかについて判定がなされ、そうであるとき、本方法は、ステップ８２６に進み、そのデータオブジェクトをソースとするオペレータが処理のために選択される。そして、本方法は、ステップ８２８に進み、ステップ８２６で処理のために選択されたオペレータが正算オペレータなのか、非正算オペレータなのかについて判定がなされる。
【００８９】
ソースオペレータが非正算オペレータであるとき、本方法は、ステップ８３０に進み、以下に記載された方法でそのオペレータを処理するために非正算オペレータを処理するルーチンが呼び出される。反対に、ソースオペレータが正算オペレータであるとき、正算オペレータを処理するルーチンは、ステップ８３２にてそのオペレータを処理するために再び呼び出される。このように、正算オペレータと非正算オペレータとを処理するルーチンは、依存関係グラフを通って進み、その評価が記号評価のパス（図９）のための呼び出しを開始するオペレータによって作用されるデータを生成するために再評価を要求するオペレータのすべてを処理する反復方法で実行される。依存関係グラフの評価または再評価が、最初にグラフの左側のオペレータ又は制限を評価し、グラフ中の左から右への方法で処理することにより実行されるべきであることが理解される。このようにオペレータを実行することにより、そのデータオブジェクトに影響を与えるオペレータがすべて更新されるまで、オペレータは評価されないことが保証される。
【００９０】
処理されるオペレータの選択されたデータオブジェクトが同調していないとステップ８２４にて判定されたとき、あるいは、データオブジェクトが同調していないときにステップ８３０又は８３２のいずれかでデータオブジェクトのためのソースオペレータを処理するために適切なルーチンが呼び出された後、本方法は、ステップ８３４に進み、選択されたオペレータのためのデータオブジェクトがいくつか処理されるために残っているかどうかについて判定がなされる。少なくとも１つのデータオブジェクトが処理されるために残っていることがステップ８３４にて判定されたとき、ルーチンは、ステップ８２２に戻り、他のデータオブジェクトが処理のために選択される。このように、本方法は、その評価が記号評価パス（図９）と、このために非正算オペレータを処理するルーチンを呼び出すオペレータのためのデータオブジェクトをすべて処理するためにステップ８２２〜８３４を実行する。
【００９１】
最後に、その評価が処理ルーチンを呼び出すオペレータのために処理されるデータオブジェクトが残っていないとステップ８３４にて判定されたとき、オペレータは、ステップ８３６にてオペレータエバリュエータスタック上にプッシュされる。
正算オペレータ処理ルーチンと非正算オペレータ処理ルーチンとの反復する性質は、依存関係グラフのオペレータが上記所望の結果を達成するために正しい順序で評価されることを保証する。図１０の上記説明から明らかなように、オペレータは、そのデータオブジェクトのすべてが処理されたことがステップ８３４で判定されるまで、ステップ８３６にてエバリュエータスタック上にはプッシュされない。さらに、データオブジェクトの処理中、同調していない各々については、正算オペレータ処理ルーチン又は非正算オペレータ処理ルーチンとが、データオブジェクトをソースとするオペレータを処理するために呼び出される。図１０の処理ルーチンがこれらのソースオペレータに作用するために呼び出されたとき、そのデータオブジェクトの夫々が更新されることを保証するために、同様に判定がなされ、更新されないとき、ルーチンが、そのソースオペレータを処理するために再び呼び出される。ルーチンのこの反復的な性質のため、他のオペレータに更新されたデータオブジェクトを供給するために評価されなければならない各オペレータは、データオブジェクトに応答するオペレータの前に、ルーチンの対応する実行の間ステップ８３６にてスタック上にプッシュされ、それゆえに、その結果に依存するオペレータの前に評価される。その評価が、記号パスのルーチン（図９）を最初に呼び出したオペレータは、最初に処理されるので、ルーチンの反復処理の最も高い水準にある。このため、このオペレータは、それが依存している結果を生成するオペレータの各々が先の反復的な処理の繰り返しの間、スタック上にプッシュされた後にのみ、オペレータエバリュエータスタック上にプッシュされる。
【００９２】
非正算オペレータを処理するルーチンは、図１１及び図１２のフローチャートにより示されている。図１０の正算オペレータルーチンと同様に、図１１及び図１２のルーチンは、結合ＡＰＩプロセッサ７１が依存関係グラフのオペレータの評価を要求するとき、最初に呼び出される。ステップ８４０では、オペレータが、先に定義された制限セットの一部としてオペレータエバリュエータスタック上にプッシュされているかどうかの判定がなされ、そして、すでにプッシュされているとき、ルーチンは終了する。オペレータがすでにスタック上にプッシュされていなければ、本方法は、ステップ８４２に進み、制限セットが現在、オープンされているかどうかの判定がなされる。オープンされていないとき、本方法は、ステップ８４４に進み、制限セットがオープンされる。
【００９３】
上述のように、本発明は、複数の非正算オペレータを含むことのできる制限セットを評価するための制限エバリュエータエンジンを含むソフトウェアシステム上にインストールできる。このような制限セットを正しく評価するために、エンジンは、硬く結合された非正算オペレータのセットをグループとして受け取る。それゆえに、正算オペレータと非正算オペレータとの両方を含む依存関係グラフを評価するとき、図９の記号パスによって構成されて、依存関係グラフが、制限セットがグループとしてエンジンに供給されるようにできる。
【００９４】
上述したように、正算オペレータは、単に、正算オペレータを処理するルーチンの反復する性質のために評価のための適切な順序で、オペレータエバリュエータスタック上にプッシュされるだけである。しかしながら、制限セットは、すべてのセットが処理されるまでオペレータエバリュエータスタック上にはプッシュされない。制限セットは、その非正算オペレータの各々が処理された後にのみ、オペレータエバリュエータスタック上にプッシュされる。各制限セットは、依存関係グラフの他の制限セットと正算オペレータに関して適切な評価順序でスタック上にプッシュされ、これは、セットがオープンされた後に適切に生じる。
【００９５】
制限セットがステップ８４４にてオープされた後、またはステップ８４２にて、セットがすでにオープンされたと判定されたときは、本方法は、ステップ８４６に進み、処理される非正算オペレータが、オープンされた制限セットに付加される。その後、ステップ８４８では、非正算オペレータに結合するデータオブジェクトの１つが、処理のために選択される。そして、本方法は、ステップ８５０に進み、ステップ８４８で選択されたデータオブジェクトを直接ソースとするオペレータにより、リストが形成される。データオブジェクトが直接接続されている場合には、非正算オペレータがデータオブジェクトを直接ソースとするのに対して、結果のデータオブジェクトである場合には、正算オペレータは、データオブジェクトを直接ソースとする。
【００９６】
ステップ８５２では、ステップ８５０で生成された直接ソースオペレータのリストが正算オペレータを含むかどうかについての判定がなされる。正算オペレータが、単一のデータオブジェクトをソースとすることもできる。直接ソースオペレータのリストが正算オペレータを含んでいると判定されたとき、本方法は、ステップ８５４に進み、選択されたデータオブジェクトが同調していないかどうかを判定する。データオブジェクトが同調していないとき、本方法はステップ８５６に進み、図１０の正算オペレータを処理するルーチンが、選択されたデータオブジェクトをソースとする正算オペレータを処理するために呼び出される。
【００９７】
図１０に関連して上述したように、正算オペレータ処理ルーチンの呼び出しは、処理するために最初に呼び出される正算オペレータだけでなく、正算又は非正算の他の全てのオペレータであって、直接的にまたは間接的に依存するデータオブジェクトを生成するオペレータを処理する結果となる。このように、制限セットの処理を完了させる前に、正算オペレータ処理ルーチンを呼び出すことにより、図１１及び図１２の非正算オペレータ処理ルーチンは、制限セットを与える正算オペレータが、制限セットの前にオペレータエバリュエータスタック上に置かれることを保証する。正算オペレータの出力は、制限セットに関しては、固定されるので、図１１及び図１２の方法は、制限セットが解決のために制限解明エンジンに渡される前に、制限セットのための固定値が評価されることを保証する。
【００９８】
正算オペレータ処理ルーチンがステップ８５６に戻ったとき、あるいはステップ８５４にて、選択されたデータオブジェクトが同調していることが判定されるか、あるいは、ステップ８５２にて、ステップ８５０にて生成されたソースオペレータのリストが正算オペレータを含んでいないことが判定されると、本方法はステップ８５８に進む。ステップ８５８では、ステップ８５０にて生成されたソースオペレータのリストが非正算オペレータを含んでいるかどうかの判定がなされ、含んでいるとき、本方法はステップ８６０に進み、非正算オペレータが処理のために選択され、そして、ステップ８６２に進み、非正算オペレータ処理ルーチンが、選択されたオペレータのために呼び出される。
【００９９】
上記から理解されるように、正算オペレータを処理するための図１０のルーチンと同様に、図１１及び図１２の非正算オペレータ処理ルーチンは、反復的な方法で作用する。しかしながら、これらのルーチンの反復する性質の間には重大な相違がある。上述したように、図１０の正算オペレータルーチンの反復する性質は、正算オペレータが実行されるための順序でオペレータエバリュエータスタック上にプッシュされる技術である。対照的に、非正算オペレータ処理ルーチンの上記ステップから明らかなように、非正算オペレータが処理されたとき、それらは、オペレータエバリュエータスタック上に個別にプッシュされるのではなく、むしろ、単にオープンした制限セットに付加されるだけである。制限解明エンジンがセットの非正算オペレータのすべてに同時に作用するので、非正算オペレータが制限セットに置かれる順序は重大なことではない。それゆえに、図１１及び図１２に示すルーチンの反復的な性質は、制限セットの非正算オペレータのすべてがそのセットに付加されることを保証するためにのみ使用され、その順序は無関係であるので、セットに付加される順序を保証するために使用されるのではない。
【０１００】
非正算オペレータ処理するルーチンが、ステップ８６０で選択された非正算オペレータの処理から戻った後、本方法はステップ８６４に進む。ステップ８６４では、いくつかの非正算オペレータが処理のために残っているかどうかの判定がなされ、そして少なくとも１つが処理されるために残っているとき、本方法は、ステップ８６０に戻り、他の非正算オペレータが処理のために選択される。このように、ルーチンは、ステップ８６４にて非正算オペレータのすべてが処理されたと判定されるまで、ステップ８５０で生成されたソースオペレータのリスト中の非正算オペレータの各々を通して進行する。
【０１０１】
処理されるべき非正算オペレータが残っていないとステップ８６４にて判定されたとき、またはソースオペレータのリストが非正算オペレータを含んでいないとステップ８５８にて判定されたとき、本方法は、ステップ８６６に進む。ステップ８６６では、ルーチンが呼び出される非正算オペレータのために処理されるためのデータオブジェクトが残っているかどうかの判定がなされ、そして、少なくとも１つのデータオブジェクトが処理されるために残っているとき、本方法は、ステップ８４８に戻り、他のデータオブジェクトが処理のために選択される。このように、ルーチンが呼び出されるオペレータのためのデータオブジェクトのすべてが処理されるまで、本方法はステップ８４８−８６６を実行する。
【０１０２】
処理されるデータオブジェクトが残っていないとステップ８６６にて判定されたとき、本方法は、ステップ８６８に進み、ルーチンが呼び出されるための非正算オペレータが制限セットをオープンしたかどうかの判定がなされる。このステップは、その実行の反復する性質のためにルーチンに含まれている。ルーチンが、現在オープンしている制限セットをオープンしなかったオペレータのために実行されるとき、制限セットに付加されるべき他の非正算オペレータは、処理のために残ることができ、それゆえに、制限セットは、まだクローズされず、オペレータエバリュエータスタックに付加されるべきである。それゆえに、ステップ８６８にて呼び出すオペレータが制限セットをオープンしなかったと判定されたとき、本方法は単に終了し、ルーチンの反復的な実行の次の高水準のステップ８５８に戻る。
【０１０３】
呼び出すオペレータが現在オープンする制限セットをオープンしたとステップ８６８にて判定されたとき、本方法は、ステップ８７０に進み、制限セットが空かどうかの判定がなされる。そして空と判定されたとき、本方法は、ステップ８７２に進み、制限セットが方法の終了に先立って削除される。制限セットが空ではないとき、本方法は、ステップ８７４に進み、制限セットがクローズされる。そしてステップ８７６では、クローズされた制限セットが、方法の終了に先立って最新のエントリーとして、オペレータエバリュエータスタック上にプッシュされる。
【０１０４】
２．評価パス
上記から理解されるように、図１０〜図１２の正算オペレータと非正算オペレータとの処理ルーチンの記号パス中の反復的な実行は、正算オペレータと非正算オペレータの制限のセットとを、それらが評価されるべき順序でオペレータエバリュエータスタック上に置く。それゆえに、グラフを更新するための実際の評価パスを実行するルーチンは、分かりやすく、そして、図１３のフローチャートによって示される。
【０１０５】
まず、ステップ８８０では、本方法は、スタックによって指定された順序オペレータと制限セットを実行する。各オペレータと制限セットのために実行された評価ルーチンは、図７と図８に関連して上述され、収集と引数のフォーマットとを必要とし、それからデザインを更新するための適切な固有ＡＰＩを呼び出す。そして、本方法はステップ８８２に進み、スタックが本発明の１実施形態に関連して再利用されることができるようにセーブされる。ユーザーによってなされる変更の性質に応じて、各再評価のために個別の記号パスを要求することなく２回以上、グラフの再評価ができる。特に、ユーザーがグラフに入力されるリーフノードデータオブジェクトを再編集するのであれば、記号パスは、オペレータエバリュエータスタック上の結果が同調しているので、再実行される必要がない。加えて、デザインの変更だけがすでにオペレータエバリュエータスタック上にある正算オペレータに入力されるデータオブジェクトの編集であれば、記号パスは、再び実行される必要がない。
【０１０６】
IX．統合処理
上記から理解されるように、本発明は、ファンクションで構成されるどんなソフトウェアシステムにも接続して使用でき、本発明のソフトウェアのインストールに続いてソフトウェアシステム上の統合処理を実行できる。結合ＡＰＩプロセッサファンクションと結合変数クラスとは、本発明がインストールできるソフトウェアシステムの詳細に関して一般的であり、それゆえに、インストールされたソフトウェアに供給される。インストールされたソフトウェアは、図１４に示される統合処理を実行する。処理の各ステップの詳細は、上述されている。まず、ステップ３０１では、製品デザインの部分を表示するためにソフトウェアシステムによって生成された各アプリケーションエンティティのクラスの定義は、デザインに入力された引数を表示するこれらと同様に、結合変数クラスから受け継ぐために修正されて、依存関係グラフに加入しているのか、そしてどこに加入するのかについての判定に使われる上述の能力を有するようにする。次に、ＡＡＰＩがステップ３０２にてソフトウェアシステムの各固有ＡＰＩのために生成される。その後、ユーザーインタフェースがステップ３０３にて修正されて、ユーザーから受け取ったコマンドに応答して、ユーザーインタフェースが、ソフトウェアシステムのＡＰＩを直接呼び出すというよりはむしろ、ステップ３０２にて生成されたＡＡＰＩを呼び出す。最後に、ステップ３０４にて、グラフマネージャーを生成し、そしてグラフマネージャーにハッシュテーブルのエントリーを形成するソフトウェアエンティティを作成させる初期化ファンクションが実行される。
【０１０７】
図１４の統合処理がソフトウェアシステム上で実行されると、システムには、ユーザーにとっては明らかな方法で本発明の能力が供給され、特別なユーザーの訓練を必要としない。加えて、このような能力が、システムの固有コマンドと対応ＡＰＩとに供給されないとしても、ソフトウェアシステム上の統合処理のオペレーションがシステムにパラメータ能力を供給することが理解される。上述したように、本発明のこの特徴は、サードパーティにソフトウェアシステムに付加的な能力を供給することを容易にする。なぜならば、サードパーティによって供給された付加的なコマンドは、パラメトリック機能を供給するソフトウェアシステムのコマンドセットに統合される必要がないからである。
【０１０８】
X.パラメトリック機能
上述したように、本発明の利点の１つは、製品デザインに修正がなされたとき、修正により影響される結果を伴うオペレータのみが再実行されるように、修正は依存関係グラフを使用するデザインの中に組み込まれる点にある。本発明のこの様相は、グラフマネージャー７５（図５）によってコントロールされる。グラフマネージャーは、ユーザーインタフェース３７からの入力を受け取るソフトウェアエンティティであり、製品デザインのためにいつ修正がなされたかを判定する。殆どのＣＡＤシステムは、アプリケーションエンティティ（例えば、箱、円柱、等）がデザインにつけ加えられた後、ユーザーが、例えば、先に作られた箱の長さ、幅、そして／または高さの変更等のデザインに関するパラメータに修正を加えることができるパラメータインタラクタを含む。
【０１０９】
本発明に関して、デザインのパラメータの変更は、システムから出力された製品デザイン４５（図３）の変更だけでなく、依存関係グラフのデータオブジェクトに関連する少なくとも１つの引数を修正することになる。このように、ソフトウェアシステムが、ユーザーコマンドにデザインのパラメータを変更させるパラメータインタラクタを供給すると、本発明は、ユーザーから受け取られたコマンドを、依存関係グラフにおいて変更されたパラメータを表示するデータオブジェクトに結合させる。特に、ユーザーがパラメータを変更するためのコマンドを入力したとき、新しい引数は、ユーザーインタフェース３７からグラフマネージャー７５に渡され、グラフマネージャー７５は、依存関係グラフの対応するデータオブジェクトにより指し示されたメモリ場所を更新して、変更された引数を反映する。
【０１１０】
その後、グラフマネージャー７５は、図９〜図１３に関連して説明した製品デザイン４５に変更を伝えるための２つのパスの処理を実行する。
発明の１実施形態では、現在のデザインパラメータに対する変更は、製品デザインに直ぐに組み込まれるわけではない。むしろ、デザインに対する更新は、ユーザーが再計算を要求しない限り、そして要求するまでは実行されない。この特徴は、デザインを更新する前に、例えばユーザーがいくつかのパラメータを変更しようとしたときに有利である。なぜならば、各パラメータを変更した後に再計算をしないことによりシステムがリソースを保存するからである。ユーザーが再計算を要求したときには、グラフマネージャー７５は、結合ＡＰＩプロセッサ７１に、変更されたパラメータに依存する依存関係グラフのオペレータに上述した方法でそれ自身を再評価させることを命令する。本発明の１つの実施形態では、再計算の２つのモードが供給される。第１のモードは、前に向けての再生として知られているものであり、変更パラメータに依存するすべてのオペレータの再計算を必要とするものである。第２のモードは、要求により再計算するモードであり、要求駆動される。この第２のモードでは、ユーザーは更新されるべきデザインのサブセットだけを指定する。例えば、ユーザーは、デザインの部分のみのパラメータの変更結果を見ることを要求することができる。図２に示される例を参照すると、ユーザーは、例えば、データオブジェクト３に関連する長さのパラメータに変更を加えることができ、そしてこのパラメータの変更が生成された箱に関してのみ与える影響を見ることを要求することができる。ユーザーがこのような要求をする場合、グラフマネージャー７５は、結合ＡＰＩプロセッサ７１に、オペレータ７だけにそれ自身を再評価させるように命令する。このように、オペレータ１９もまた、データオブジェクト３に関連したパラメータに依存しているにもかかわらず、グラフマネージャーは、ユーザーによって要求されてはいないので、結合ＡＰＩプロセッサ７１に、オペレータ１９に自身を再評価させることを命令しない。
【０１１１】
XI．階層オペレータ
本発明の１つの実施の形態において、能力が供給されて、依存関係グラフに階層的な方法で、ユーザーによって実行されるオペレーションを表示する。ユーザーのデザイン目的を表示するためのいくつかの論理的な方法で配置された１つ以上の低水準のオペレータを夫々表示する階層オペレータが作成される。以下により詳細に説明するように、階層的能力は、階層的な方法で、本発明の結合サブシステムがインストールされているソフトウェアシステムの複数のコマンドをひとまとめにするためにユーザーによって用いられ、単一の階層グループでコマンドと１つ以上のサブコマンドをまとめるソフトウェアシステムによってもまた使用される。
【０１１２】
本発明の階層的能力は、一組の低水準デザインオペレーションを、依存関係グラフにおけるユーザーのアクティビティに適応させた単一のより高水準の目的として組織させ、かつ、表示させる。例えば、ＣＡＤシステム上で自動車のロータをデザインするユーザーは、ロータの突起継手を定義するために使用される低水準のオペレータの全てをひとまとめにすることで、第１の階層オペレータを作成し、ロータに冷却水路を付加するために使用される低水準オペレータをひとまとめにすることで、第２の階層オペレータを作成する。多数の低水準オペレータをひとまとめにし、単一の階層オペレータでそれらを表示することで、デザイン用に生成される依存関係グラフが、より有意義なユーザーのアクティビティに適応させた目的を表示するために簡便になる。さらに、いったんそれらが形成されると、階層オペレータがデザインにおける他の場所での使用のため複写されるので、階層グループを作成した低水準のデザインオペレーションが複写される必要がない。
【０１１３】
本発明の結合サブシステムがソフトウェアシステムに統合されると、結果として生じる結合システムもまた、階層的能力を遂行して、コマンドと、コマンドの一定の特性を定義するコマンドと共にユーザーによって一般的に実行される一連の対応サブコマンドと、をひとまとめにする。例えば、多くのＣＡＤシステムは、ユーザーのデザイン目的と相関するより高水準の幾何学的なモデリングの一形態である特徴を用いているが、デザイン目的の詳細を定義する特徴でサブコマンドの実行を必要とする。本発明の階層的能力を用いると、本発明の結合サブシステムがインストールされているＣＡＤシステムは、特徴によって行われる潜在的に複雑な幾何学的なモデリングファンクションを定義するのに必要なメインコマンドと、その支援サブコマンドの全てのための個別のオペレータによって夫々の特徴が表示されることを必要とするよりはむしろ、階層オペレータを使用する依存関係グラフにおける高水準の特徴を表示することができる。
【０１１４】
普通のＣＡＤの特徴の一例は、多くの異なるタイプの穴である。図２１は、箱７０２に設けられたさら穴７００の一例を示している。箱７０２にさら穴を挿入するには、ユーザーは、穴が設けられる面データ７０４、面データ上の穴の中心位置、穴の深さ７０６、穴の半径Ｒ2 、さら穴の半径Ｒ1 及びさら穴の角度θを含む複数の定義用パラメータを指定する。これらのパラメータは、さら穴を作成する特徴的なコマンドと共に、サブコマンドのグループを実行することで指定される。
【０１１５】
本発明の階層的能力が用いられない場合、さら穴を有する箱を定義するユーザーのデザインアクションは、図２２に示すような依存関係グラフによって表示される。オペレータ７１６の出力は、さら穴を有する箱を定義する結果としてのアプリケーションエンティティを表示するデータオブジェクト７２４となる。図示するように、入力としての複数のリレーションとデータオブジェクトを有する箱のオペレータ７１０の結果であるデータオブジェクト７１２によって、箱自身が表示される。特徴的なコマンドと２つの支援サブコマンドとに対応する３つのオペレータ７１４〜７１６によって、箱へのさら穴の挿入が表示される。オペレータ７１４が、箱を表示するデータオブジェクト７１２に接続され、ユーザーによって実行されるサブコマンドを表示して、さら穴が設けられる部分としての箱の上面を選択する。オペレータ７１４の結果が箱の上面となる。オペレータ７１５はこの結果を受け取り、ユーザーによって実行されるサブコマンドを表示して、さら穴が加えられる上面のデータを選択する。オペレータ７１５の結果は、特徴的なコマンドを表示するさら穴オペレータ７１６に入力される。データ入力に加えて、さら穴オペレータもまた、穴の位置を表示するデータオブジェクト７１８、立体（例えば、穴が設けられた箱）を表示するデータオブジェクト７１２、及び、さら穴の半径Ｒ1 、Ｒ2 、角度θ、深さを夫々表示するデータオブジェクト７２０〜７２３に接続される。
【０１１６】
本発明の階層的能力が用いられたとき、前述したデザインアクションを表示する依存関係グラフが図２３に示す方法で生成される。図２２のオペレータ７１４〜７１６が、箱におけるさら穴の作成を表示する単一の階層オペレータ７２６によって表示される。内部オペレータ７１４及び７１６に接続する階層に、箱を表示するデータオブジェクト７１２を差し込む２つの入力と、単一結果データオブジェクト７２４と、を有するように階層オペレータ７２６が示される。オペレータ７１４〜７１６に入力されるが、階層オペレータに内在するデータオブジェクトの夫々は、グラフを簡単にするために表示されない。箱を表示する２つのリレーション７３０及び７３１を介して接続されて、このデータオブジェクトが階層オペレータ７２６内部の２つの個別オペレータ（例えば、７１４及び７１６）に供給されることを表示する。階層オペレータの結果が、オペレータ７１６から出力される同じ結果のさら穴を有する箱を定義するアプリケーションエンティティを表示するデータオブジェクト７２４に接続される。
【０１１７】
図２２及び図２３の依存関係グラフの比較からわかるように、本発明の階層オペレータの能力により、単にユーザーの意向にわずかに関係しているにすぎない多数のオペレータで依存関係グラフを取り散らかさずに、より高水準でユーザーのデザイン意向を表示できる。
本発明の結合サブシステムが統合されたソフトウェアシステムは、単一の階層オペレータを有する依存関係グラフで夫々が表示するのが好ましい多数の階層的な特徴を含んでいる。それらの特徴のため、ソフトウェアシステムは階層的な方法でそれらの特徴を表示する後述の方法で、本発明の階層オペレータの能力を用いることができる。この能力は、ユーザーのデザイン目的を遂行するための特徴的なＡＰＩと、またＡＰＩが作用するデータを定義するサブコマンドに関するいくつかの付加的なＡＰＩとの実行を必要とするコマンドに関連して、特に、有用である。本発明の階層オペレータ能力により、複数のＡＰＩのグループを、ユーザーのデザイン意向をより正確に表示する単一オペレータとして表示できる。
【０１１８】
後述するように、本発明の一つの実施の形態では、依存関係グラフはグラフィカルモードで編集できる。この能力が用いられるとき、ユーザーにはデザインの依存関係グラフ表示における詳細水準に関して適応性が供給される。例えば、階層オペレータ７２６が使用される図２３の依存関係グラフに関して、ユーザーはより詳細にグラフを見たいと所望し、図２２において示される階層オペレータのより詳細な表示を明らかにするために、階層オペレータ７２６が展開される異なったビューモードを選択することができる。この場合、展開された単一の階層ブロックに内在するグラフ要素のまわりに点線を描くことで、ある階層の境界がより詳細な表示で供給される。
【０１１９】
階層オペレータが依存関係グラフのために作成されたとき、本発明は、その入力及び出力を定義する一覧を供給する。このように、リレーションが階層境界を横切らないように、明確な境界が依存関係グラフにおける夫々のオペレータのために定義される。さらに、ユーザーには、そのより詳細な表示を見るために階層オペレータを展開する特性が供給されるので、その最上位水準より低い夫々の水準の階層もまた、階層境界を横切るリレーションなしに、他のグラフデータオブジェクトからその入力と出力とを得ることができる。これは、階層オペレータの境界外側にある依存関係グラフにおけるオペレータから入力、または、オペレータに出力される各階層オペレータの内部データオブジェクトのいずれにも、入力又は出力が各階層オペレータから供給されることを保証することで、達成される。階層境界を横切るデータオブジェクトの視覚性を注意深く扱うことで、デザインの他の場所での階層オペレータの再使用が容易になり、後述する本発明のコード生成の特徴のための支援が得られる。
【０１２０】
階層境界を横切る１つより多いオペレータによって分けられるデータオブジェクトの視覚性が維持される方法は、変数がＣのような標準的なプログラミング言語でファンクションを横切ってスコープされる方法に類似している。階層境界を横切るデータオブジェクトの処理を保証するために、２つの基準が設定される。第１に、階層オペレータが、他のオペレータによって参照されるデータオブジェクトが、その階層境界の外側にあることを参照（入力かまたは出力か）しようとすると、データオブジェクトが階層オペレータ用の引数リストに含まれる。第２に、階層オペレータとデータオブジェクトを参照する他のオペレータとの間の関係が、両方のオペレータを含む親ファンクションに供給される。親ファンクションは、両方を含むより高水準の階層オペレータであるか、または、依存関係グラフ自身の根である。
【０１２１】
階層境界を横切るデータオブジェクトの処理を容易にするには、階層オペレータのために、２つの付加的なソフトウェアエンティティが作成される。第１は、階層境界を横切る夫々の入力及び出力のために作成される入力／出力（ＩＯ）ポートである。第２は、ＩＯ＿ＯＰと呼ばれる階層オペレータのためのＩＯポートのリストである。
【０１２２】
図２２及び図２３に示される依存関係グラフの比較に関しては前述したように、本発明の一つの実施の形態では、階層オペレータからポートされる（例えば、入力又は出力として外部に持ち出される）データオブジェクトだけが、階層オペレータの境界外側にあるオペレータから、入力又は出力として参照される。従って、データオブジェクト７１８及び７２０〜７２３（図２２）が、階層オペレータ７２６に対して内部にのみ存在するので、これらは図２３の依存関係グラフにおいて表示される階層オペレータ７２６からポートされず、そのグラフの複雑さを明確にしかつ削減する。本発明の別の実施の形態では、各階層オペレータに入力されるデータオブジェクトの全ては、他のオペレータから供給されなくても、階層オペレータからポートされ、依存関係グラフにおいて表示される。
【０１２３】
前述したように、各階層オペレータはそのＩＯポートを確認するＩＯ＿ＯＰリストを有している。このリストは動的なもので、オペレータが階層オペレータ内に前もって内包されるデータオブジェクトを参照するデザインに加えられるとき、付加的なポートが必要に応じて加えられる。このＩＯ＿ＯＰリストの動的性質は、階層オペレータの中から全ての入力及び出力をポートする必要がない。しかしながら、これは後述するように、結果として生じる依存関係グラフのサイズと明確性に関して不利となる。
【０１２４】
以上のことからわかるように、階層オペレータのためのＩＯ＿ＯＰにおける特定のエントリーは、階層オペレータが用いられるデザインの状況に依存している。図２１〜図２３の例について前述したようなさら穴を生成するために、階層オペレータが作成される場合、その階層オペレータがユーザーによってコピーでき、デザインの異なる部分で使用できる。デザインにおける階層オペレータの各段階は、スコープアウトされる入力及び出力に関して、階層オペレータの各例用の異なるＩＯ＿ＯＰを必要とする依存関係グラフにおける他のオペレータと相違している。例えば、さら穴階層オペレータ７２６が、デザインにおいて複製された場合、穴の深さを定義するデータオブジェクト７２３（図２２）は、さら穴階層オペレータの境界外側で、オペレータの結果として供給される。階層オペレータのこの段階では、階層オペレータ用のＩＯポートを作成し、階層オペレータのその段階のためのＩＯ＿ＯＰにおけるＩＯポートを含むことにより、データオブジェクト７２３が階層オペレータから出力される。
【０１２５】
階層オペレータのために作成されたＩＯポートの一例を、図２４を参照して説明する。この図は、図２３の階層オペレータのためにどのようにＩＯポートが作成されるかを概念的に示している。図２４は、依存関係グラフの一形態で示されているが、ＩＯポートと支援オペレータはユーザーのデザイン目的の表示には役に立たないので、依存関係グラフには実際には表示されていない。
【０１２６】
以下により詳細に説明するように、各階層オペレータのためのＩＯポート及びＩＯ＿ＯＰは、グラフマネージャー７５（図５）によって作成される。階層オペレータのための内部データオブジェクトが、階層外側で参照（例えば、入力や出力）されるたびに、階層外側でデータオブジェクトのポーティングを表示するためにＩＯポートがＩＯ＿ＯＰに加えられる。これは図２４に概念的に示されており、階層オペレータ７２６のために４つのＩＯポートが形成されて、階層外側で参照されるその内部データオブジェクトをポートする。各ＩＯポートは、データオブジェクトと等価オペレータとを含んでいる。等価オペレータは他のオペレータと同様のグラフエンティティであり、等価オペレータの出力に結合されたデータオブジェクトが等価オペレータの入力に結合されたデータオブジェクトにおける値と等しく設定されるように、２つのデータオブジェクトが単に同等視されることを表示する。
【０１２７】
階層オペレータ７２６用のＩＯポートは、２つの入力ポート７３０及び７３６を含んでいる。入力ポート７３０は、データオブジェクト７３０Ａと等価オペレータ７３０Ｂとを含んでいる。等価オペレータはさらに、上面オペレータ７１４へのデータ入力を表示するために作成される内部データオブジェクト７３２に接続されている。同様に、ＩＯポート７３６は、データオブジェクト７３６Ａとさら穴オペレータ７１６の立体リレーションへのデータ入力を表示するために作成されるデータオブジェクト７４０に接続される等価オペレータ７３６Ｂとを含んでいる。
【０１２８】
入力ポートは、階層境界を横切ってアクセスされる階層オペレータ内部のデータオブジェクトにデータを入力するファンクションを行う。データオブジェクト７３０Ａ及び７３６Ａは、階層外側からデータオブジェクトをソースするオペレータに、親水準で接続されるポートを供給する。前述したように、親水準は、図２４の例におけるようなデザインの根であってよく、或いは、そのデータオブジェクトをソースするオペレータはもちろん、そこから入力がポートされている一方の階層オペレータを含む他方の階層オペレータでもよい。
【０１２９】
図２４において、データオブジェクト７１２を上面オペレータ７１４に、また、さら穴オペレータ７１６の立体リレーションを階層オペレータ７２６内部に夫々入力するために、２つの個別のＩＯポートが形成される。本発明の一つの実施の形態において、階層境界を横切る単一のデータオブジェクトに参照される階層オペレータの範囲内のデータオブジェクトのような２つのデータオブジェクトのために、個別のＩＯポートが形成される。個別のＩＯポートの供給は、ユーザーに、デザインの異なる部分での使用のために、予め作成された階層オペレータを、コピーさせる能力を容易にする。特に、階層オペレータの２つの内部データオブジェクトは、他の段階においてそれらの内部データオブジェクトが階層境界の外側で、別のデータオブジェクトと結合されるのに対し、階層オペレータにおける２つの内部データオブジェクトは、グラフにおける階層オペレータの１段階において、階層境界を横切る単一のデータオブジェクトに結合される。個別のＩＯポートが、これらの内部データオブジェクトを別々にポートするために作成されなければ、内部データ入力が階層外側の個別データオブジェクトに結合される所ではどこでも、階層オペレータはデザインにおいて、複製されず、使用もされない。
【０１３０】
親水準では、等価オペレータ７３４及び７３８は、データオブジェクト７１２を、階層オペレータ７２６の入力ポート７３０及び７３６に夫々結合するために供給される。等価オペレータ７３４及び７３８は、箱オペレータ７１０の結果のデータオブジェクト７１２における値を、ＩＯポート７３０及び７３６の入力データオブジェクト７３０Ａ及び７３６Ａと夫々同等視する。従って、箱オペレータの結果が、等価オペレータ７３４を経由してＩＯポート７３０まで渡され、ＩＯポート７３０は順次、等価オペレータ７３０Ｂを介して結果をデータオブジェクト７３２に渡して、結果が上面オペレータ７１４によって作用されるようにする。同様に、この結果もまた、等価オペレータ７３８を経由してＩＯポート７３６まで渡され、ＩＯポート７３６は順次、等価オペレータ７３６Ｂを介して結果をデータオブジェクト７４０に渡して、結果がさら穴オペレータ７１６によって作用されるようにする。
【０１３１】
以上のことからわかるように、さら穴階層オペレータの範囲内に、データオブジェクト７３２及び７４０のための個別のＩＯポート７３０及び７３６を作成することにより、これらの２つの内部データオブジェクトが階層外側で、同じデータオブジェクトに接続されることを必要とせずに、階層オペレータが、デザインの他の部分でコピーされ、かつ、複製される。
【０１３２】
階層オペレータ７２６もまた、階層オペレータ７２６からデータを出力する２つの出力ポート７４０及び７４２を含んでいる。これらのＩＯポートは、データオブジェクト７４０Ｂ、７４２Ｂと、これらのデータオブジェクトを、データオブジェクト７２４によって表示されるさら穴オペレータ７１６の結果と同等視する等価オペレータ７４０Ａ、７４２Ａを夫々含んでいる。２つのＩＯポートはさら穴オペレータ７１６から結果を出力するために使用される。これは、このオペレータが階層オペレータ７２６のための結果を定義するからである。第１のＩＯポート７４０は、階層からオペレータ７１６の結果の出力専用であり、オペレータ７１６の結果がもはや階層オペレータの結果を表示しないように、階層オペレータが変更されても、この結果を出力する。反対に、ＩＯポート７４２は、階層オペレータの結果の出力専用なので、変更が階層オペレータに内部的になされて、他の内部オペレータが階層オペレータの結果を生む結果となる場合、ＩＯポート７４２は、階層オペレータの新しい結果を出力するために変更され、オペレータ７１６の結果は出力されない。
【０１３３】
簡単な例により、階層オペレータのための個別のＩＯポートを供給するという利点が示される。図２３及び図２４で示される例は、非常に簡単な依存関係グラフを示し、かなり複雑なグラフが展開されることが理解される。例えば、さら穴階層オペレータ７２６の結果が、さら穴を有する箱の重量を計算する図２で示されるオペレータ１９のような他のオペレータへの入力となる。前述したように、階層オペレータはユーザーによって変更できる。例えば、ユーザーはまず、図２５及び図２６に示す方法で、さら穴階層オペレータ７２６を定義し、オペレータ７１６（図２４）から出力され、かつ、データオブジェクト７２４によって表示されるさら穴を有する箱の重量を計算しようとする。しかしながら、例えば、箱に第２のさら穴を作成することにより、ユーザーはさら穴階層オペレータを後で変更してもよい。２つのさら穴を有する箱を作成するオペレータ７１４〜７１６と類似する一連の新しいオペレータへの入力として、データオブジェクト７２４によって表示されるオペレータ７１６の結果を使用することで、この変更がなされる。このように、さら穴階層オペレータ７２６が変更されると、重量計算オペレータへ出力される階層オペレータの結果は、もはやオペレータ７１６の結果ではなく、むしろ、第２のさら穴を供給するこれに続くオペレータの結果となる。従って、結果のＩＯポート７４２は、階層オペレータの結果として第２のさら穴オペレータの結果を出力するために変更できる。しかしながら、デザインの他の部分は、第１のさら穴オペレータ７１６の結果もまた出力されることを要求できる。このため、異なるＩＯポート結果を作成することで、ちょうど階層オペレータの範囲内で変更がなされたときに、階層オペレータの結果が常に出力されることが保証されると同時に、階層境界外側のデザインの他の部分によって使用される階層オペレータの範囲内で、中間のオペレータの結果もまた出力されることが保証される。
【０１３４】
図２４に示される実施の形態では、入力及び出力ポートに供給されるオペレータは、全て等価オペレータである。しかしながら、特に出力ポートには、異なるタイプのオペレータを使用できることが理解される。これは、階層オペレータの結果が階層外側に位置する依存関係グラフのオペレータに供給されるように、付加的な適応性を供給するものである。
【０１３５】
図２２の例を参照すると、さら穴階層オペレータの出力が、さら穴を有する箱を定義するアプリケーションエンティティである。階層外側の依存関係グラフにおけるオペレータは、さら穴を有する箱に関する情報の部分だけを受け取ることできる。例えば、他のオペレータは箱の一面だけを要求できる。この場合、階層オペレータの結果のポート用のオペレータ７４２Ａが変更されて、さら穴を有する箱を階層外側に単に渡すのではなく、むしろ、所望の箱の面を決定し、これを階層外側のオペレータにソースする。
【０１３６】
上記能力を供給するには、階層オペレータの出力ポートは、図２４に示される本発明の一つの実施の形態におけるオペレータとデータオブジェクトとを含んでいる。しかしながら、代わりに、出力ポートは、出力される結果を表示するデータオブジェクト（例えば、図２４におけるデータオブジェクト７２４）から単に形成するだけでもよく、オペレータと付加的なデータオブジェクトとを含む必要はないことが理解される。しかしながら、このような方法は前述の有用な能力を供給するものではない。
【０１３７】
階層オペレータ用の入力ポートにおけるオペレータは、一般的には等価オペレータである。このため、代わりに、各入力ポートは、単に階層オペレータに入力されるデータ入力を受け取るデータオブジェクト（例えば、図２４におけるデータオブジェクト７３２）として提供できる。しかしながら、図２４に示される本発明の実施の形態では、入力ポートもまた、付加的なデータオブジェクト及びオペレータと共に実行されるので、入力及び出力ポートは、一貫した方法で定義される。
【０１３８】
前述したように、階層オペレータがデザインの範囲内でコピーされ、かつ、複製されたとき、階層オペレータの各段階は、依存関係グラフにおけるその環境に依存する異なる一組の入力及び出力ポートを有する。異なる組のＩＯポートは、階層オペレータの異なる段階へ、及び、その段階から異なる内部データオブジェクトをポートする。さらに、同じデータオブジェクトを出力する階層オペレータの２つの段階は、それらの夫々の出力ポートに異なるオペレータを含むことができる。例えば、図２４に示されるさら穴階層オペレータの一方の段階が、さら穴を有する箱を表示するアプリケーションエンティティが出力されるように、その結果の出力ポート７４２に等価オペレータを含むことができるのに対し、他方の段階は、前述したような箱の一面だけを出力するオペレータを含むことができる。
【０１３９】
ＩＯポートの作成とポートのＩＯ＿ＯＰリストの更新によって、階層オペレータの範囲内のどのデータオブジェクトが入力されかつ出力されるかの決定は、グラフマネージャー７５（図５）によってなされる。この決定は、どのデータオブジェクトが階層境界の外側のグラフの部分に接続されるかに基づいている。階層オペレータの外側でスコープされるデータオブジェクトに関し、これらの他のグラフ要素との関係は、階層オペレータを含む親ファンクションによって定義される。前述したように、階層オペレータは、多数の水準を介して入れ子構造にされる。それゆえ、階層オペレータの出力は、より大きな階層オペレータの範囲内の他のグラフ要素に接続できる。この場合には、より大きな階層オペレータは、より大きな階層オペレータの範囲内の他のグラフ要素に対するより低水準の階層オペレータからスコープされるデータオブジェクトの関係を定義する親ファンクションとしての役割を実行する。階層オペレータからスコープされた出力が、他の階層オペレータの部分を形成しないようなデザインの最上位水準にある場合、デザインの根は、階層オペレータからスコープされたデータオブジェクトが他のグラフ要素に接続される方法を定義する親ファンクションとしての役割を実行する。
【０１４０】
前述したように、各階層オペレータ用のＩＯ＿ＯＰとＩＯポートは、グラフマネージャー７５（図５）によって作成され、かつ、管理される。ＩＯ＿ＯＰは、グラフエンティティとして実行され、かつ、依存関係グラフにおけるその対応する階層オペレータへのポインタを含んでいる。グラフの階層オペレータは、同様にその対応するＩＯ＿ＯＰへのポインタを含んでいる。ＩＯ＿ＯＰは、階層オペレータへ入力され、かつ、そのオペレータから出力されるデータオブジェクトを表示するＩＯポートのリストを含んでいる。従って、ＩＯ＿ＯＰは、階層オペレータのためのリレーションの収集としての役割を実行する。ＩＯポートそれ自身は、それらのリレーションを定義する。
【０１４１】
１．階層的ＡＡＰＩ
本発明の結合サブシステムは、階層オペレータの使用を支援する複数のＡＡＰＩを供給する。前述したように、階層オペレータは、２つの方法のうちの一方で用いられる。第１に、ユーザーは好ましい方法で、自分自身の階層オペレータを作成する。このためには、ユーザーは、後述の支援ＡＡＰＩを単に用いて、階層オペレータを作成する。第２に、本発明の結合サブシステムがインストールされているソフトウェアシステムもまた、支援ＡＡＰＩを呼び出して、後述するような１つ以上のサブコマンドを含むコマンドの周囲で、階層オペレータを実行する。
【０１４２】
３つの基本的なＡＡＰＩが、階層オペレータを支援するために供給される。第１のものは、階層オペレータをオープンする。少なくとも１つの階層オペレータがオープンされているとき、その階層がデザインに引渡されるまでは、デザインに加えられる全ての依存関係グラフの要素が、最新にオープンされた階層オペレータの範囲内に含まれる。いったん階層が引渡されると、階層が再びオープンされるまでは、階層オペレータがクローズされ、新しい依存関係グラフ要素がその階層に加えられない。階層オペレータを支援する第２のＡＡＰＩは、階層引渡しコマンドであり、これは、前述したような方法で最新にオープンされた階層をデザインに引渡す。最後に、階層中止ＡＡＰＩもまた、最新にオープンされた階層オペレータの作成を中止するために供給される。中止コマンドを受け取ったとき、最新にオープンされた階層は作成されず、最新にオープンされた階層のオープンに続いて加えられるグラフ要素の夫々が、階層的な方法で集められずに、グラフ要素のグループとしてだけデザインに加えられる。
【０１４３】
前述したように、本発明は階層オペレータを入れ子構造にすることを可能にする。従って、階層オペレータのオープンに続いて、１つ以上の付加的な階層オペレータが、前もってオープンされた階層オペレータをクローズする前にオープンされる。従って、階層引渡しコマンドを受け取るたびに、最新にオープンされた階層がクローズされる。階層引渡しコマンドを、階層オープンコマンドまで追跡することで、多数の入れ子構造にされた階層オペレータが作成される。グラフマネージャーは、現在オープンしている階層オペレータの先入れ後出し(first-in last-out) スタックを持続する。従って、階層引渡しコマンド或いは階層中止コマンドが受け取られたとき、スタックに付加された最新にオープンされた階層オペレータが、夫々、完全な階層オペレータとしてデザインに引渡されるか、或いは、デザインから取り除かれて、あたかも最新にオープンされた階層オペレータが決してオープンされなかったかのように、その階層のオープンに続いて加えられたグラフ要素が単にデザインに加えられる。中止コマンドが受け取られたとき、他の階層オペレータがスタック上で現在オープンしている場合、その後グラフに引渡されたとき、グラフ要素はその階層オペレータの一部として、単にグラフに付加される。
【０１４４】
デザインセッションが開始されたときにはいつでも、最上位水準の階層オペレータは、自動的に作成されて、グラフマネージャースタックにプッシュされる。この最上位水準の階層オペレータは、デザインセッション中に作成されるデザイン全体のための根を表示する。前述したように、このデザインの根は、デザイン水準での階層オペレータの次の上位水準と非階層オペレータとの間の関係を定義する親のファンクションとしての役割を実行する。
【０１４５】
中止コマンドは、ユーザーにゴール指向アクティビティに関してユーザーの意向を変更する適応性を提供する。同様に、このコマンドもまた、本発明の結合サブシステムがインストールされたソフトウェアシステムによって用いられる。ソフトウェアシステムが本発明の階層オペレータの能力を実行しようとするとき、階層的な方法で一般的に使用される固有ＡＰＩに対応するＡＡＰＩが、それらの固有コマンドの１つがユーザーによって入力されるたびに、階層オペレータをオープンするコマンドを呼び出す。しかしながら、ユーザーは完了前に、階層的なコマンドを終了することができる。この場合には、ソフトウェアシステムは、固有コマンドのためにオープンされる階層オペレータの作成を中止する中止コマンドを用いることができる。
【０１４６】
２．オペレータの引渡
デザインに引渡された階層に加えて、ユーザーコマンドに応じて作成された各オペレータもまた、正確に実行する場合には、デザインに引渡される。オペレータをデザインに引渡すとき、グラフマネージャーは次の３つの基本的なステップを実行する。
【０１４７】
(1) オペレータを処理する
(2) オペレータの出力を処理する
(3) オペレータの入力を処理する
これらのステップは、図２５〜図２８のフローチャートに表示される。
オペレータがデザインに引渡されると、グラフマネージャーはまず、図２５のフローチャートで示されるオペレータ引渡しルーチンを実行する。ステップ６１０において、本方法はデザインに引渡されるオペレータがあるか否かを判定し、オペレータがあれば、本方法は、ステップ６１２に進み、オペレータが引渡される目標のオペレータがあるか否かの判定がなされる。これらの２つのステップは、エラーチェックをするためのものである。前述したように、デザインセッションが開始されるときはいつでも、デザインの根を表示する階層オペレータが自動的にオープンされて、グラフマネージャースタックにプッシュされる。従って、オペレータ引渡しルーチンが呼び出され、かつ、引渡されるオペレータがないか、或いは、オペレータが引渡される目標のオペレータがない場合には、エラー状態が発生し、本方法はステップ６１４に進み、エラーメッセージをユーザーに供給し、その後終了する。
【０１４８】
エラー状態が発生しないときは、本方法はステップ６１６に進み、デザインに引渡されるオペレータがグラフマネージャースタックからポップされる（即ち、読まれる）。ステップ６１８では、スタック上の次のオペレータが、ステップ６１６でスタックからポップされたオペレータが引渡される目標のオペレータとして確認される。最後に、ステップ６２０では、このルーチンが、図２６に示されるオペレータ付加ルーチンを呼び出して、ルーチンへの引数として供給されるステップ６１６でスタックからポップされたオペレータと共に、目標のオペレータに作用する。
【０１４９】
図２５及び図２６で示される一つの実施の形態では、デザインへのオペレータの引渡しは、それが引渡される目標の階層オペレータによって一部制御される。前述したように、デザインに付加された各オペレータは、デザイン自身の根の一部としてか、或いは、デザインにおけるより低水準の階層オペレータの一部として付加される。従って、オペレータがデザインに付加されたとき、オペレータ付加ルーチンは、引数として引渡されたオペレータを受け取り、そのオペレータが引渡される階層オペレータと関連して呼び出される。
【０１５０】
ステップ６２２では、オペレータ付加ルーチンは、引数として渡されたオペレータを処理して、依存関係グラフにおいて余分の階層が作成されないことを保証する。前述したように、本発明の結合サブシステムがインストールされたソフトウェアシステムは、本発明の階層的な能力を利用する。従って、階層的な方法で一般的に使用されるソフトウェアシステムにおけるコマンドに関し、ソフトウェアシステムは、コマンドのための対応ＡＡＰＩにコマンドを受け取ったときはいつでも、新しい階層をオープンさせることができる。例えば、図２１〜図２４と関連して説明されたさら穴のコマンドは、一般的に、サブコマンドで実行され、さら穴が設けられる立体の面を確認する。従って、さら穴のコマンドが実行されると、そのコマンドに関連して一般的に使用される多数のサブコマンドを受け取ることを見越して、階層がオープンされる。しかしながら、ユーザーが予期したコマンドを実行しないと、不必要な階層が作成される可能性がある。例えば、ユーザーがサブコマンドを使用せずにさら穴のコマンドを単に実行して、立体の面を定義すると、さら穴のコマンドのために作成された階層は、さら穴オペレータ７１６の周囲に単独で作成される。この階層は、単一のオペレータを含んでいるので、不必要である。
【０１５１】
オペレータ付加ルーチンのステップ６２２の間に実行されるオペレータ処理ファンクションは、このような不必要な階層を確認して、取り除く。階層が取り除かれると、取り除かれた階層に属するものとして前もって確認されたオペレータの夫々は、ステップ６２２でグラフマネージャースタックにプッシュされて、そのルーチンがオペレータ付加ルーチンのステップ６２６の間に呼び出されたときに、後述するオペレータ引渡しルーチンのステップ６１６の間に、グラフに引渡される。
【０１５２】
本発明の一つの実施の形態では、ステップ６２２の処理ファンクション用のデフォルトオプションは、単一のオペレータの周囲に作成された階層を取り除くためのものである。従って、前述した一例では、オペレータ７１６の周囲に単独で作成された階層が取り除かれる。しかしながら、本発明の結合サブシステムがインストールされたソフトウェアシステムには、このデフォルトを無効にする能力が供給され、単一のオペレータであってもその周囲に階層を作成することを選択できる。さらに、デフォルトは、有効な階層オペレータを形成するために含まれる最少数のオペレータを確立すべく変更される。このように、ソフトウェアシステムには、階層が作成される方法を制御する適応性が供給される。
【０１５３】
オペレータが処理された後で、オペレータ付加ルーチンはステップ６２４へと進み、ステップ６２２の間にオペレータ階層が消失したか否かが判定される。階層が消失したとき、本方法はステップ６２６へと進み、ステップ６２４で消失した階層にあった各オペレータのために、図２５のオペレータ引渡しルーチンが呼び出される。それらのオペレータは、ステップ６２２の間にグラフマネージャースタックにプッシュされているので、ステップ６１６（図２５）でオペレータ引渡しルーチンによって処理されるときに、前述した方法でスタックからポップされる。このように、階層オペレータが消失するときはいつでも、ステップ６２６の実行が、消失した階層の範囲内のより低水準のオペレータの夫々がデザインに引渡されることを保証する。
【０１５４】
ステップ６２２で階層オペレータが消失されなかったと、ステップ６２４で判定されると、オペレータ付加ルーチンはステップ６２８へと進み、図２７の入力処理ルーチンを呼び出す。入力処理ルーチンの目的は、依存関係グラフにおける階層の水準を介してそれらの入力をスコープすることで、階層オペレータを処理することである。前述したように、階層境界を横切る夫々の入力のためのＩＯポートを作成し、その入力を供給するグラフの親水準においてＩＯポートをデータオブジェクトに接続する階層の外側に等価オペレータを作成することで、これが達成される。従って、依存関係グラフに引渡されるオペレータのための入力処理ルーチンは、新たに引渡されるオペレータを含む階層オペレータを必要とする入力ポートを作成する。
【０１５５】
入力処理ルーチンは、まず、ステップ７５０において、処理するために引渡されたオペレータの第１の入力を選択する。ステップ７５２では、選択された入力のためのソースデータオブジェクトが同じ階層にあるか否か、即ち、データオブジェクトのソースがオペレータが引渡される目標の階層にあるか否か判定される。ソースデータオブジェクトが同じ階層にあるとき、選択された入力は、階層からスコープされる必要はなく、それゆえ、入力は更に処理される必要がない。このため、本方法はステップ７８８へと直接進み、処理されるべき付加的な入力が残っているか否か判定される。付加的な入力が残っているとき、本方法はステップ７５０に戻り、処理すべき他の入力を選択する。引渡されたオペレータのための処理すべき入力が残っていないと判定されると、本手順は終了する。
【０１５６】
ステップ７５０において処理のために選択された入力とそのソースデータオブジェクトが同じ階層にないと、ステップ７５２で判定されると、本方法はステップ７５４へと進み、オペレータが引渡される目標の階層オペレータの範囲内で、新しいデータオブジェクトが選択された入力のために作成される。このようなデータオブジェクトの一例は、図２４におけるデータオブジェクト７３２である。新しいデータオブジェクトを作成することで、ソースデータオブジェクトを、引渡されるオペレータの選択された入力に接続する関係が、目標のオペレータの階層境界を横切らないことが保証される。
【０１５７】
ステップ７５６では、階層の親のリストが、引渡されたオペレータのために生成される。階層の親のリストは、引渡されたオペレータのための先祖ツリーに類似しており、それらの階層的な関係はもちろん、引渡されたオペレータが属する階層の夫々を確認する。階層的な親のリストは後述の方法で、ルーチンによって使用されて、その階層的な水準で等価オペレータ（例えば、図２４におけるオペレータ７３４及び７３８）が選択された入力を、そのソースデータオブジェクトに接続するために供給されることを決定する。
【０１５８】
本方法は次にステップ７５８に進み、ソースデータオブジェクトを生成するオペレータが確認され、ステップ７６０で、そのオペレータのための階層の親のリストが生成される。ステップ７６２では、引渡されたオペレータのための親のリストが、ソースオペレータのための親のリストに対して比較されて、両者に共通した最も低い先祖の階層を確認する。この階層的な水準は、ソースデータオブジェクトと選択された入力との間の等価オペレータ作成のための目標の親水準として示される。これら２つを含む他の階層水準は、選択された入力のスコープを必要としない。なぜならば、選択された入力とそのソースデータオブジェクトとの間の接続が、目標の水準の階層オペレータの内部となるからである。しかしながら、ルーチンは、目標の水準及びそれより低い水準で階層オペレータから選択された入力をスコープして、選択された入力とそのソースデータオブジェクトとの間の関係が、階層境界を横切らないことを保証する。
【０１５９】
ステップ７６４では、引渡されたオペレータのための最低の階層水準、例えば、引渡されたオペレータが引渡される階層オペレータ、を処理すべく選択する。ステップ７６６では、現在処理される階層水準が目標の水準であるか否か判定される。現在処理される水準が目標でないとき、本方法はステップ７６８へと進み、ＩＯポートが作成されて、現在処理される水準で、階層オペレータから選択された入力を出力する。次に、本方法はステップ７７０に進み、処理のため次の階層水準へと進み、その後、ステップ７６６に戻る。このように、本方法は、目標の水準が達成されたとステップ７６６で判定されるまで、目標の水準より低い全ての階層水準で引渡されたオペレータの選択された入力のためのＩＯポートを作成するためにステップ７６６〜７７０を実行する。
【０１６０】
現在処理される水準が目標の水準であるとステップ７６６で判定されたとき、本方法はこの水準でＩＯポートを作成するステップ７６８には進まない。なぜならば、前述したように、目標の水準は選択された入力とソースデータオブジェクトとの両者を含むので、その入力のスコープを必要としないからである。むしろ、目標の水準がステップ７６６において検出されたとき、本方法はステップ７７４（図２８）へと進み、ソースオペレータの処理が開始される。
【０１６１】
階層オペレータから供給されたとき、本方法は、引渡されたオペレータの選択された入力に接続するために、階層オペレータの階層からの結果のデータオブジェクトをスコープする前述したステップに類似する複数のステップを実行する。特に、ステップ７７４では、本方法は処理のためのソースオペレータの最低の階層水準を選択し、その後、ステップ７７６に進んで、現在処理される階層水準が目標の水準であるか否かを判定する。ソースオペレータが階層的ではないとき、その最低水準が目標の水準となる。現在処理される階層水準が目標の水準ではないとステップ７７６で判定されると、本方法はステップ７７８へと進み、ＩＯポートが作成されて、現在処理される水準で階層オペレータから結果のデータオブジェクトを出力する。次に、本方法はステップ７８０に進み、処理のための次の階層水準に進み、その後、ステップ７７６へと戻る。このように、目標の水準が達成されたとステップ７７６で判定されるまで、本方法は目標の水準とそれ以下の夫々の水準で、ソースデータオブジェクトのためのＩＯポートを作成するためにステップ７７６〜７８０を実行する。
【０１６２】
現在処理される水準が目標の水準であるとステップ７７６で判定されると、本方法はこの水準でＩＯポートを作成するステップ７７８には進まない。なぜならば、前述したように、目標の水準は選択された入力とソースデータオブジェクトの両者を含み、それゆえ、ソースデータオブジェクトのスコープを必要としないからである。
【０１６３】
目標の水準がステップ７７６で検出されると、本方法はステップ７８４へと進み、等価オペレータ（例えば、図２４におけるＥＱＯＰｓ７３４及び７３８）が目標の水準で作成される。等価オペレータの一端は、目標のすぐ下位にある階層水準で引渡されたオペレータの選択された入力のために作成されたＩＯポートに接続され、他端が目標の水準でソースを表示するデータオブジェクトに接続される。ソースオペレータが階層的であるとき、この接続は目標のすぐ下位にある水準でソースデータオブジェクトのために作成されたＩＯポートになされる。
【０１６４】
等価オペレータがステップ７８４で作成された後、本方法はステップ７８６へと進み、等価オペレータが目標の水準のデザインに引渡される。本方法はその後、ステップ７８８（図２７）へと進み、引渡されたオペレータの入力が処理のために残っているか否か判定される。付加的な入力が残っていると判定されると、本方法はステップ７５０へと戻り、次の入力が処理のために選択される。このように、本方法が終了する時点である、全ての入力が処理されたとステップ７８８で判定されるまで、本方法は引渡されたオペレータの入力の夫々のスコープを実行する。
【０１６５】
入力処理ルーチンに戻った後、オペレータ付加ルーチンが、ステップ６３０（図２６）に進み、オペレータが引渡されている結果を処理する。オペレータが階層オペレータである場合、結果の処理はその結果のＩＯポートがオペレータの出力を正確に反映することを保証するために実行される。例えば、図２４の依存関係グラフと関連して説明したように、階層オペレータ７２６は、さら穴を有する箱を表示するアプリケーションエンティティである結果を生ずる。しかしながら、さら穴階層オペレータの範囲内での変更は、例えば、付加的なさら穴を加えることで、階層オペレータの結果を変えることができる。夫々の階層オペレータは、その内部のオペレータを指す結果のオペレータポインタを保持し、これが実行されたとき、全体の階層オペレータの結果をもたらす。このオペレータは、単に、階層オペレータの結果であるデータオブジェクトを指す結果のＩＯポート（例えば、図２４におけるオペレータ７２４Ａ）における等価オペレータである。新しいオペレータが階層に付加され、その結果が階層オペレータの結果となるとき、階層オペレータの結果の処理は、結果のオペレータの入力関係が新たに付加されたオペレータの結果を指すために調整される。
【０１６６】
異なる階層オペレータは、それらの出力が階層オペレータの結果を定義するために処理される方法に関しては、異なるようにふるまう。例えば、多くの階層オペレータに関しては、最後のオペレータ（例えば、依存関係グラフの右端の１つ）が階層の結果を定義できる。しかしながら、いくつかの階層オペレータに関しては、これは当てはまらない。例えば、図２３のさら穴階層オペレータ７２６から出力される箱のような製作品を生み出す階層オペレータに関しては、階層オペレータの結果は常に製作品である。従って、たとえ他のオペレータが階層オペレータに付加され、製作品に作用（例えば、箱の重量を計算する）するとしても、製作品は階層オペレータの結果である。本発明の一つの実施の形態では、デフォルト状態が設けられており、これは、最新に階層に引渡されたオペレータの結果であるデータオブジェクトを指す階層オペレータの結果のオペレータを生じる。しかしながら、このデフォルトは、特定の階層オペレータの作成に際して、ユーザー或いはソフトウェアシステムによって無効にすることができる。
【０１６７】
前述したように、階層的な方法でコマンドをまとめるソフトウェアシステムに供給される能力は、一連のサブコマンドと共にひとまとめにされるコマンドと関連して使用される。例えば、前述したさら穴のコマンドは、複数のサブコマンドと共に一般的に実行されて、例えば作用されている立体の面を定義する。ユーザーインタフェースは、その関連するサブコマンドがユーザーから受け取られるまで、より高水準のコマンドを一般的には実行しない。従って、高水準のコマンドのサブコマンドの全てが受け取られるまで、本発明のオペレータ引渡しルーチンは、高水準のコマンド（例えば、さら穴のオペレータ７１６）に対応するオペレータに引渡すために呼び出されない。それゆえ、高水準のコマンドがユーザーから始めに受け取られたとき、新しい階層がオープンされ、階層はサブコマンドの夫々が実行されるまでは引渡されない。このように、コマンドは階層オペレータにおいてそのサブコマンドと共にまとめられる。
【０１６８】
以上のことからわかるように、各高水準のコマンドのためのデザインにオペレータが引渡されるので、階層的なブロックにおける高水準のコマンドと関連付けられるサブコマンドのグループを定義するソフトウェアシステムの前述した能力が、１つより多い高水準のコマンドをひとまとめにするため用いられることによって、特にそのコマンドのためにオープンされる階層をクローズする。しかしながら、前述したように、この能力はユーザーに供給されて、ユーザーが複数の高水準のコマンドを含む階層を含む階層的なグループを所望の方法で指定できるようにする。
【０１６９】
XII.インタラクティブ依存関係処理
上述のように、本発明の一つの実施の形態では、ユーザーがデザインの依存関係表示と相互に作用してデザインを作成したり、既存のデザインを変更したりすることができる能力が提供される。例えば、デザインのこのグラフ表示と相互に作用することがユーザーにとってより速くかつより容易になるということが理解される。
【０１７０】
図３に示すように、本発明の結合サブシステムがソフトウェアシステム上にインストールされた場合、そのシステムにはインタプリタ５２が与えられる。インタプリタ５２は、テキストウィンドウを含み、このテキストウィンドウは、ソフトウェアシステムのディスプレイスクリーン上に表示でき、また、それによってインタプリタがユーザーからのテキストＡＡＰＩを受け取ることができる。インタプリタ５２は、テキストＡＡＰＩ表示を変換し、システム上の対応するＡＡＰＩ４２を呼び出して、テキストＡＡＰＩ表示によって指定されたデザイン動作を行う。このように、インタプリタテキストウィンドウは、テキストＡＡＰＩ表示を用いた本発明による依存関係グラフを作成、あるいは編集するために使用できる。
【０１７１】
上述した図３の説明に関連して、依存関係グラフを図表的に編集する本発明の具体例が使用される場合、システムは、また、依存関係グラフを図表的に編集するのに用いる視覚的なプログラミング環境５０も与えられる。依存関係グラフの図表的な編集を支援するための本発明の能力は、特定の視覚的なプログラミング環境に限られるものではなく、本発明は、その幾つかは商業的に利用されているような任意のタイプの視覚的なプログラミング環境で使用することが可能である。
【０１７２】
図３に示すように、視覚的なプログラミング環境５０はインタプリタ５２と結合し、インタプリタ５２は、順次、システムの結合ＡＰＩ４２と結合する。視覚的なプログラミング環境５０は、視覚的環境中でユーザーによって行われる動作をインタプリタと互換性のある語句に変換する。このようにインタプリタは、視覚的なプログラミング環境５０の言語とソフトウェアシステム上の結合ＡＰＩ４２との間を変換するパーザ（parser) として動作する。インタプリタ５２は、分解される有効なワードを定義する辞典を、その辞典を与える支援的な文法ルールと同様にして設定する。インタプリタが操作するシステム上のＡＰＰＩ４２は、階層的オペレータを支援するために用いられる上記３つのＡＡＰＩと同様に、ソフトウェアシステム中の各固有ＡＰＩ周辺にラップされたＡＡＰＩを含む。ユーザーが視覚的なプログラミング環境中でいくつかの動作を行う場合、インタプリタ５２は、視覚的なプログラミング環境５０から受け取った語句を分解し、依存関係グラフ中でユーザーのデザイン動作を実行するために正しくフォーマットされた引数と共に、対応するＡＡＰＩを呼び出す。インタプリタは、相互に作用する視覚的なプログラミング環境の中に統合されて、インタプリタによって分解される語句が、ユーザーがシステムキーボードあるいは他の入力装置を通してコマンドをタイプした結果として受け取られるようにする。
【０１７３】
インタプリタテキストウィンドウまたは視覚的なプログラミング環境５０から語句が受け取られたときに必ずインタプリタによって実行されるソフトウェアルーチンが、図２９のフローチャートに図示される。ステップ９００では、インタプリタが受け取った語句を分解して、その語句で参照されるＡＡＰＩの名前を判定する。次に、本方法はステップ９０１に進み、インタプリタスタックがクリアされる。このインタプリタスタックは、後述する方法で使用されて、インタプリタルーチンの再帰的な実行の間、サブコマンドの実行による引数を受け取る機能コマンドについての結果の値を記憶する。このようにインタプリタスタックに記憶された結果の値は、サブコマンドに関連して実行されたＡＡＰＩの結果を示し、また、再帰的ルーチンを最初に呼び出す機能コマンドのためのＡＡＰＩを呼び出す際に、引数を与えるために使用される。スタックは、インタプリタルーチンの実行について１回の再帰的サイクル中だけ使用される。しかしながら、再帰的サイクルが完了すると、そのルーチンはスタックをクリアすることなしに元に戻ることができる。従って、スタックはルーチンの最初のステップ９０１でクリアされて、その結果、そのルーチンがサブコマンドを使用しない２つのコマンドについて連続的に呼び出され、このため、インタプリタルーチンを再帰的に実行しない場合には、後述するステップ９１０において引数がスタック上で検出されない。
【０１７４】
スタックがクリアされた後、本方法はステップ９０２に進み、ステップ９００において分解されたＡＡＰＩの引数が確認される。引数は、図５に関連して上述したハッシュテーブル７３にアクセスすることによって確認され、ハッシュテーブル７３は各ＡＡＰＩのエントリーを含み、各ＡＡＰＩは、それぞれの引数、および実行のためＡＡＰＩが呼び出されたときにそれらの引数が与えられる順序を確認する。
【０１７５】
ステップ９０４では、ステップ９０２で確認された引数を、ＡＡＰＩが呼び出されたときに与えられる引数の順序リストの第１の引数として選択し、そして本方法はステップ９０６に進み、選択された引数に対してデータ値を与えるためにサブコマンドが実行されるべきかどうかの判定が行われる。この判定は、引数のリストを分解することによって行われる。引数がＡＡＰＩの名前を含むならば、その引数はサブコマンドによって与えられる。ステップ９０６でサブコマンドが実行されるべきと判定された場合には、本方法はステップ９０８に進み、引数の値を生じるＡＡＰＩの名前を使用してインタプリタルーチンが再度呼び出される。
【０１７６】
ステップ９２６〜９２８に関連して後述するように、インタプリタルーチンがＡＡＰＩを処理するために呼び出される場合、そのルーチンの最新の２つのステップは、そのＡＡＰＩを実行して、インタプリタテキストウィンドウまたは視覚的なプログラミング環境から受け取った語句で指定されたデザイン動作を実行し、そして、この実行結果をインタプリタスタック上にプッシュする。このインタプリタスタックは、テキストウィンドウまたは視覚的なプログラミング環境から受け取った語句に応じてインタプリタルーチンの再帰的な呼び出しの間に実行されたＡＡＰＩの結果を記憶する先入れ後出し方式のスタックである。このように、インタプリタルーチンが、ステップ９０６で確認されたサブコマンドを処理するステップ９０８での呼び出しから戻るとき、そのサブコマンドを実施するために実行されたＡＡＰＩの結果がインタプリタスタック上に記憶される。
【０１７７】
インタプリタルーチンがステップ９０８でのサブコマンドの処理から戻った場合、または、選択された引数についてサブコマンドを実行する必要がないことが決定された場合には、本方法はステップ９１０に進み、引数がインタプリタスタック上に記憶されているかどうかについての判定が行われる。上述のように、インタプリタルーチンが開始したとき、スタックはステップ９０１でクリアされる。従って、引数がインタプリタスタック上に記憶されている場合、それはサブコマンドの処理のために呼び出されたルーチンの反復によって引数が与えられることを示すので、本方法はステップ９１２に進み、引数の値がインタプリタスタックからポップされる。逆に、ステップ９１０で引数がスタック上にないことが判定された場合には、ステップ９１４に進み、選択された引数についての値が、インタプリタテキストウィンドウまたは視覚的なプログラミング環境５０から与えられた語句より読み取られる。
【０１７８】
引数の値が、ステップ９１２でスタックからポップされた後、あるいは、ステップ９１４でテキストウィンドウまたは視覚的なプログラミング環境から読み取られた後に、本方法はステップ９１６に進み、処理を行うために選択された引数に値が割当てられる。そして、本方法はステップ９１８に進み、引数の値が、ステップ９００で確認されたＡＡＰＩについて要求されたタイプの値であるかどうかについての判定が行われる。引数の値が要求されたタイプでない場合には、本方法はステップ９２０に進み、エラーメッセージがユーザーに対して与えられ、そして、本方法が終了する。このように、ユーザーは受入れ可能なタイプに引数の値を再定義する機会を与えられる。
【０１７９】
選択された引数に割り当てられた値が正しいタイプであることがステップ９１８で判定された場合には、本方法はステップ９２２に進み、ＡＡＰＩについて処理される他の多くの引数が残っているかどうかについての判定が行われる。他の引数が残っていると判定された場合には、本方法はステップ９２４に進み、ＡＡＰＩについて順序付けられた引数のリスト中の次の引数が、処理を行うために選択され、そして、本方法はステップ９０６に戻る。このように、ステップ９２２で全ての引数が処理されたことが判定されるまで、ＡＡＰＩについての各引数の処理が行われる。
【０１８０】
全ての引数が処理されると、本方法はステップ９２６に進み、ステップ９００で分解されたＡＡＰＩが、ルーチンによって正しい順序の位置に収集された引数の値と共に呼び出される。この方法では、インタプリタルーチンは、インタプリタテキストウィンドウまたは視覚的なプログラミング環境から受け取った語句によって要求されるデザイン動作がそのデザインとみなされることを保証する。最後に、ステップ９２８で、ＡＡＰＩから戻された結果がインタプリタスタック上にプッシュされて、ステップ９０８でＡＡＰＩのサブコマンドのためにインタプリタルーチンが呼び出された場合に、その結果が上述した方法でステップ９１２においてスタックから読み取られる。
【０１８１】
ユーザーがデザインを作成または編集しているとき、本発明は、ユーザーがそのデザインの部分を確認して、インタプリタテキストウィンドウまたは視覚的なプログラミング環境５０を用いて表示されたデザインの部分を生成するＡＡＰＩを要求する能力を提供する。例えば、図２の依存関係グラフによって表示されたデザインを変更するユーザーは、箱を表示するアプリケーションエンティティのディスプレイスクリーン表示を簡単に指すことができ、また、箱を生成するＡＡＰＩに対応するオペレータ７を含んだ図２の依存関係グラフの部分が、視覚的なプログラミング環境を用いて表示できる。あるいは、インタプリタテキストウィンドウは、ディスプレイスクリーンに、付随するデータ引数に加えてコマンド "CV INSERT BOX(l,w,h,center)"のテキスト表示が提供できるように、そのデザインの選択された部分を生成するＡＡＰＩをテキスト表示するために使用できる。
【０１８２】
テキストのＡＡＰＩまたはユーザーによって選択された依存関係グラフ表示が表示されると、デザインの部分の表示は、インタプリタテキストウィンドウまたは視覚的なプログラミング環境５０を使用して変更できる。依存関係グラフを図表的に編集することは、オペレータに入力されたデータを再定義すること、またはオペレータを置き換えることを意味する。同様に、ＡＡＰＩをテキスト的に編集することは、ＡＡＰＩの引数のうちの１つを再定義すること、またはＡＡＰＩを他のＡＡＰＩに置き換えることを意味する。
【０１８３】
ユーザーが、編集されるデザインの部分を表示したアプリケーションエンティティを選択した場合、グラフマネージャー７５（図５）によって実行される編集ルーチンが呼び出されて、編集オペレーションを処理する。編集ルーチンは図３０のフローチャートに示される。まず、ステップ９３０で、本ルーチンはユーザーによって編集するために選択されたアプリケーションエンティティを確認する。次に、ステップ９３２で、本ルーチンは、テキスト編集が実行される場合には、選択されたアプリケーションオブジェクトに対応するＡＡＰＩを発見し、また、図表的編集が実行される場合には、依存関係グラフ中の対応するオペレータを発見する。
【０１８４】
ステップ９３４では、ステップ９３２で確認されたＡＡＰＩまたはオペレータが、編集するためにユーザーに提供される。編集オペレーションが、インタプリタテキストウィンドウまたは視覚的なプログラミング環境からインタプリタを通して受け取られたとき、本ルーチンはステップ９３６に進み、テキスト編集の間にＡＡＰＩが編集されているかどうかについて、また、図表的編集の間にオペレータが編集されているかどうかについての判定が行われる。ＡＡＰＩまたはグラフオペレータのいずれかが編集されていることが判定される場合には、本ルーチンはステップ９３８に進み、図２９のインタプリタルーチンが呼び出されて、新しいＡＡＰＩまたはオペレータを処理する。上述のように、インタプリタルーチンは新しいＡＡＰＩについての全ての引数値を収集し、また、そのＡＡＰＩを引数の順序リストと共に呼び出して、ユーザーの編集によって指定されたデザイン動作を実行する。インタプリタルーチンが復帰すると、本方法はステップ９４０に進み、図３２に関連して後述する置換オペレータルーチンが呼び出され、そして、本方法は終了する。ステップ９３６でユーザーがＡＡＰＩまたはグラフオペレータのどちらも編集していないことが判定される場合には、本方法はステップ９４２に進み、ユーザーが引数を編集したかどうかについての判定が行われる。引数が編集されなかった場合には、本方法は単に終了する。しかしながら、ステップ９４２においてユーザーが引数を編集したと判定された場合には、本ルーチンは、ステップ９４４で後述する再定義入力ルーチン（図３１）を呼び出した後に終了する。
【０１８５】
再定義入力ルーチンは、図３１のフローチャートによって示され、このルーチンは、図２９のインタプリタルーチンによって実行されるステップと同様ないくつかのステップを実行する。まず、ステップ９４６で、本ルーチンは上述したインタプリタスタックと同様のスタックをクリアする。このスタックは、インタプリタスタックがインタプリタルーチンのステップ９０１で最初にクリアされたのと同様の理由で最初にクリアされる。次に、ステップ９４８で、このルーチンは編集された引数を処理するために選択する。そして、本ルーチンはステップ９４９〜９６８に進み、これらのステップ９４９〜９６８は、図２９に関連して上述したインタプリタルーチンにおけるステップ９０６〜９２６と実質的に同一である。これらステップの実行を通して、再定義入力ルーチンは１つのＡＡＰＩについて編集された引数値の全てを、その他の引数値と同様に収集し、そして、ステップ９６８でそのＡＡＰＩを引数値の順序リストと共に呼び出して、ユーザーの編集によって要求されたデザイン動作を行う。その後、ステップ９７０で、本ルーチンは後述する図３２の置換オペレータルーチンを呼び出して、終了する。
【０１８６】
図３０の編集ルーチンと図３１の再定義入力ルーチンの両方で呼び出された置換オペレータルーチンは、図３２に示すフローチャートによって表示される。置換オペレータルーチンが呼び出される前に、編集ルーチン（図３０）のステップ９３８におけるインタプリタルーチンに対する呼び出しの結果として新しいＡＡＰＩが実行されるか、または再定義入力ルーチン（図３１）のステップ９６８における新しいデータと共に現行のＡＡＰＩが再び実行される。これらの場合のいずれかにおいてもＡＡＰＩの実行結果として、付加的なグラフ要素が作成され、この付加的なグラフ要素は、新しいオペレータ、そのオペレータの入力についてのリレーション、そのオペレータの出力についてのリレーション、および新しい結果データオブジェクトを含んでいる。置換オペレータルーチンの目的は、依存関係グラフを掃除して、ユーザーのデザイン編集を正確に反映することである。
【０１８７】
初めに、ステップ９７２で、置換される古いオペレータの結果データオブジェクトにどのグラフ要素が依存するかについての判定が行われる。古いオペレータの結果に依存するものが依存関係グラフ中にないと判定された場合には、本方法はステップ９７３に進み、古いオペレータの結果データオブジェクトが依存関係グラフから削除され、そしてステップ９８４で、古いオペレータもまた削除される。この方法では、依存関係グラフが、ユーザーによって行われた編集を反映するために更新される。
【０１８８】
ステップ９７２で、いくつかのグラフ要素が古いオペレータの結果に依存することが判定された場合には、本方法はステップ９７４に進み、新しいオペレータによって生じた結果が、古いオペレータの結果に依存する各々のグラフ要素によって要求される正しいタイプであるか否かについての判定が行われる。その結果が正しいタイプでないと判定された場合には、本方法はステップ９７６に進み、新しいオペレータがデザインにおいて古いオペレータを置換できないことを示すエラーメッセージがユーザーに対して生成され、そして本方法は終了する。
【０１８９】
その結果が正しいタイプである場合には、本方法はステップ９７８に進み、新しいオペレータについての結果データオブジェクトに記憶された値が、古いオペレータについての結果データオブジェクト中に置かれる。これは、古いオペレータについての結果データオブジェクト中のポインタを、新しいオペレータの結果の値を記憶するメモリ場所を指すように単に更新することによって達成される。そして本方法はステップ９８０に進み、新しいオペレータの結果リレーションが、古いオペレータの結果データオブジェクトに接続されるように、再度ポインタを新しいオペレータの結果リレーション中に単に更新することによってスイッチされる。その後、本方法はステップ９８２に進み、新しいオペレータの結果データオブジェクトが削除される。最後に、ステップ９８４で、本方法は古いオペレータを削除し、そして終了する。
【０１９０】
前述のことからわかるように、図３２の置換オペレータルーチンは、古いオペレータを新しく実行されたオペレータに置換し、ユーザーの編集によって要求されるデザインに対する変更に影響を及ぼす依存関係グラフ中の全ての必要な関係を作る。このルーチンは、本方法に代えていくつかの異なった方法でも実施できることがわかる。例えば、古いオペレータの結果データオブジェクトを使用してその値を更新するよりもむしろ、新しいオペレータの結果データオブジェクトを依存関係グラフにフックアップすることもできる。しかしながら、図３２に示された実施の形態は、古いオペレータのデータオブジェクトが、古いオペレータに依存する全てのグラフ要素について前に接続されたリレーションをすでに有しており、従って、これらの接続を変える必要がないという点で優れている。
【０１９１】
上述したように、視覚的なプログラミング環境５０（図３）の使用を通して、本発明の結合サブシステムがインストールされたソフトウェアシステムのユーザーには、デザインの依存関係グラフ表示を図表的に編集する能力が提供される。依存関係グラフの視覚的な表示は、多くの形式をとることができる。１つの例が図３３及び図３４に示され、これは図２２及び図２３の依存関係グラフの視覚的な表示を示す。
【０１９２】
この依存関係グラフは、ソフトウェアシステムのディスプレイスクリーンのような視覚的環境カンバス９９０上に視覚的に示される。また、ＡＡＰＩ９９０のツール箱も表示され、このツール箱は、依存関係グラフを作成および編集する際にユーザーが選択するのに利用できる結合ＡＰＩのリストを含んで構成される。ＡＡＰＩの表示リストは、図３３及び図３４のツール箱９９２中に含まれる。このツール箱９９２中のＡＡＰＩは、アイコンによって、または対応するグラフエンティティをデザインに付加するために起動される他のシンボルによって表示される。
【０１９３】
図３３において、階層的さら穴オペレータ７２６がボックスオペレータ７１０に接続されて表示される。オペレータ７２６の階層性は、その境界を定義している２重線によって示される。グラフ中のデータオブジェクトは、オペレータ上のポートとして表示される。このポートは、そのポートにより要求または生成されるデータタイプを描く異なるカラーで、カラーコード化される。オペレータポートのうちの１つに対する入力リレーションを追加または変更する場合、システムは、それに接続できる依存関係グラフ中の他の有効なポートをハイライトできる。
【０１９４】
上述のようにして、ユーザーに対し、階層的オペレータを開くことができる能力が提供される。図３４は、階層的オペレータ７２６を構成する内部オペレータ７１４〜７１６を示すために階層的オペレータ７２６を開いた状態にした、図３３の依存関係グラフを表示する。この表示では、階層的オペレータの境界が１対の２重点線９９４によって限定される。
【０１９５】
ユーザーがアイコンまたはＡＡＰＩを表示する他のシンボルをツール箱から選択し、それらを視覚的環境カンバス中に結合している間、依存関係グラフを形成する実際のグラフエンティティは形成されない。しかし、ユーザーがシステムに視覚的な表示を処理するように命令する場合、インタプリタ５２（図３）は、視覚的表示を示す視覚的なプログラミング環境５０からの語句を受け取り、上述した方法で依存関係グラフを作成するためにグラフエンティティを実際に構築する対応したＡＡＰＩを呼び出す。
【０１９６】
上述のように、階層的オペレータが与えられる本発明の実施の形態において、ユーザーは階層的オペレータをデザインの他の段階において使用するためにコピーする能力を与えられる。本発明の視覚的なプログラミング環境はこの機能を支援する。階層的オペレータがコピーされる場合、そのＩＯ＿ＯＰおよびＩＯポートは維持される。従って、階層的オペレータのコピーは、単一のオペレータをＡＰＰＩのツールボックスから視覚的環境カンバス中に挿入することと同じである。階層的オペレータは、他のオペレータと全く同じように扱われ、定義された一組の入力および出力を備える。階層的オペレータがコピーされ、視覚的環境カンバス中に置かれると、ユーザーは、その階層的オペレータのＩＯポートをグラフ中の所望の接続にフックアップするだけでよい。階層的オペレータがコピーされるとき、その階層的オペレータの内部データオブジェクトもまたコピーされて、ユーザーは階層的オペレータのＩＯポートを接続する方法を定義するだけでよい。
【０１９７】
XIII．コンピュータプログラムの生成
ユーザーがソフトウェアシステムでインタラクティブデザインセッションを完了すると、本発明は結果デザインの構造的な依存関係を表示する依存関係グラフを図２に示される実施の形態のように生成する。更に、本発明は、例えばＣ++のような標準言語でコンピュータプログラムを生成するために依存関係グラフを操作するプログラム生成ツールを提供し、このツールは実行されると、依存関係グラフおよびその依存関係グラフが表示するデザインを生成する。上述のように、コンピュータプログラムは、ユーザーによって編集でき、また、変更されたデザインを生成するためにシステムの中に戻すことができる。
【０１９８】
プログラム生成ツールを説明するフローチャートが図１５〜図１９に示される。まず、ステップ１０１で、依存関係グラフ中の各々のリーフデータオブジェクトが同調しないとしてマークされる。リーフデータオブジェクトは、オペレータによって与えられないグラフ中のものであって、即ち、リーフデータオブジェクトは、オペレータの結果ではない。リーフデータオブジェクトが実際にマークされると、本方法はステップ１０３に進み、図９の記号パスルーチンが呼び出される。各々のリーフデータオブジェクトは、同調しないとしてマークされて、全てが記号パスによって処理される。前述のように、記号パスルーチンはグラフを識別して、リストが評価される順序と同様にして、評価されるオペレータのリストを形成する。このリスト中のオペレータは、正算オペレータまたは非正算オペレータの制限セットを含む。図９に関連して上述したように、オペレータのリストは、グラフマネージャースタック上でオペレータが実行される順に記憶される。このように、記号パスを呼び出して、グラフマネージャースタックに指定された順序でオペレータを処理することによって、プログラム生成コードは、対応するＡＡＰＩを同じ順序で呼び出すプログラムを生成する。
【０１９９】
記号パスが戻ると、本方法はステップ１０５に進み、グラフマネージャースタックに記憶された評価順序の次のオペレータが処理するために選択され、これは、ステップ１０５を通る第１のパスの間、第１のオペレータとなる。その後、本方法はステップ１０７に進み、選択されたオペレータが制限セットであるかどうかについての判定が行われ、制限セットであると判定された場合には、本方法はステップ１０９に進み、制限セットから１つの非正算オペレータが処理のために選択される。
【０２００】
ステップ１０９で非正算オペレータを選択した後、またはステップ１０５で選択されたオペレータが１つの正算オペレータであることがステップ１０７で判定された場合に、本方法はステップ１１１に進み、図１８の階層的ファイル準備ルーチンが、ステップ１０５で処理するために選択された正算オペレータあるいはステップ１０９で選択された非正算オペレータの親である階層的オペレータに関連して呼び出される。前述のように、依存関係グラフ中の各々のオペレータは、少なくとも１つの親の階層的オペレータに属し、最上位の階層的オペレータがデザインの根底を定義する。各オペレータの親の階層は、オペレータを定義するグラフエンティティ中のポインタに記憶され、従って、各オペレータの親の階層は、このグラフエンティティに単に問い合わせることによるプログラム生成方法によって判定できる。
【０２０１】
階層ファイル準備ルーチンが階層的オペレータに対して呼び出されると、このルーチンは、ステップ１６５でファイルがその階層的オペレータについて開かれているかどうかをまず判定する。階層的オペレータは、本発明のプログラム生成方法により生成されたコードで別のファンクションによって表示され、各ファンクションは異なるファイル中で定義されている。ファイルがまだ開かれていないと判定された場合には、本方法はステップ１６７に進み、出力ファイルが階層的オペレータファンクションを定義するコードのために開かれる。
【０２０２】
出力ファイルが、処理されている階層的オペレータのために開かれると、本方法はステップ１６９に進み、このファイルのためのポインタが目標として選択されて、続いて生成されるコードがこのファイルに置き換えられることを示す。その後ステップ１７１において、変数が階層的オペレータの各ＩＯポートについて定義される。このＩＯポートは、階層的オペレータを表示するグラフエンティティによって維持されたＩＯ＿ＯＰリストに問い合わせることで確認される。次に、ステップ１７５で、本ルーチンは階層的オペレータを表示するファンクションの定義を作成する。ファンクションの定義は、ファンクションの名前と、そのリターンタイプと、その引数についての名前およびタイプとを含む。本ルーチンは、ステップ１７１でＩＯポートのために作成された変数の名前をファンクションの引数として使用する。
【０２０３】
ファンクションが定義された後、本方法はステップ１７７に進み、開いた階層ＡＡＰＩを呼び出すための語句がファイルに書き出されて、コードが生成される場合に、処理される階層的オペレータのために階層が作成される。その後、本方法はステップ１７９に進み、親の階層が、処理される階層的オペレータに存在するかどうかについての判定が行われ、そのような親の階層が存在しない場合には、本方法はステップ１８５に進み、その階層的オペレータのためのファイルポインタが、目標として後述する理由で再び設定されて、本ルーチンが終了する。
【０２０４】
処理されている階層的オペレータが親の階層を有することがステップ１７９で判定された場合には、階層的ファイル準備ルーチンが親の階層について呼び出される。このように、ファイル準備ルーチンが再帰的に呼び出されて、プログラム生成方法（図１５）のステップ１０５の間に評価スタックから最初に処理するために選択されたオペレータを含む階層的オペレータの全てを処理する。ファイル準備ルーチンが親の階層的オペレータの処理から戻ると、本方法はステップ１８３に進み、処理されている階層的オペレータへの呼び出しが、その親の階層のためのファイル中に書き込まれる。このように、親の階層的オペレータを定義するファンクションは、その範囲内に含まれる階層的オペレータを定義するファンクションを呼び出す。
【０２０５】
最後に、階層的オペレータファンクションへの呼び出しが、ステップ１８３でその親の階層的オペレータのためのファイル中に書き込まれた後、または、ステップ１７９で処理されている階層的オペレータが親の階層的オペレータを含まないと判定された場合、あるいは、ステップ１６５で階層的オペレータのためのファイルが階層的ファイル準備ルーチンを呼び出すよりも前に開かれた場合には、本ルーチンはステップ１８５に進み、処理されている階層的オペレータのためのファイルポインタが目標として再び設定される。ステップ１８５は、それが実行される再帰的方法であるためにファイル準備ルーチンに含まれる。特に、ルーチンを初めに呼び出すための階層的オペレータが少なくとも１つの親の階層的オペレータを有する場合、目標ポインタは、親の階層的オペレータを処理するルーチンへの再帰的呼び出しのステップ１６９において、その親の階層的オペレータに設定される。プログラム生成方法（図１５）のステップ１１３に戻る前に、階層的ファイル準備ルーチンは、目標ポインタを最初に呼び出すための階層的オペレータに設定して、プログラム生成方法の間に生成された付加的コードがこのファイルに書き込まれる。
【０２０６】
階層的準備ルーチンが戻った後に、本方法はステップ１１３に進み、ステップ１０５あるいはステップ１０９の処理の間に選択されたオペレータに接続されたデータオブジェクトの全てが収集される。上述したように、各オペレータは、そのリレーションについてのポインタを含み、各々のオペレータが、順次対応するデータオブジェクトについてのポインタを含む。オペレータを表示するグラフエンティティに照会することによって、プログラム生成方法はオペレータに接続された全てのデータオブジェクトのリストを収集できる。ステップ１１５において、本方法は、処理されているオペレータに接続されたデータオブジェクトのうちの１つを処理するために選択する。ステップ１１７において、本方法は、選択されたデータオブジェクトが以前に処理されたかどうかを判定し、以前に処理されていない場合には、本方法はステップ１１９に進み、変数が選択されたデータオブジェクトに対して宣言及び命名される。
【０２０７】
ステップ１１９で選択されたデータオブジェクトに対して変数が宣言された後、あるいは、ステップ１１７で選択されたデータオブジェクトが以前に処理されたと判定された場合には、本方法はステップ１２１に進み、ステップ１１５で形成され接続されたデータオブジェクトのリスト中の全てのデータオブジェクトが処理されたかどうかについての判定が行われ、全てが処理されていない場合には、本方法はステップ１１５に戻る。このように、処理されているオペレータに接続された各データオブジェクトに対して変数名が宣言されることを保証するために、本方法はステップ１１５〜１２１を続行する。
【０２０８】
変数名が、処理されているオペレータに接続された各データオブジェクトに対して宣言された後、本方法はステップ１２３（図１６）に進み、ステップ１１５で形成されたリストに含まれる入力データオブジェクトの全てが確認される。ステップ１２３での入力としての確認のためには、プログラム生成方法は、正算オペレータへの入力だけでなく、非正算オペレータに接続されたあらゆるデータオブジェクトを確認する。
【０２０９】
入力データオブジェクトが確認された後、本方法はステップ１２５に進み、入力データオブジェクトのうちの１つが処理するために選択される。ステップ１２７では、選択された入力データオブジェクトが、処理されているオペレータの親のオペレータである階層的オペレータのためのＩＯ入力ポートであるかどうかについての判定が行われる。その入力データオブジェクトがＩＯポートであると判定された場合には、本方法はステップ１２９に進み、ステップ１１９（図１５）で選択されたデータオブジェクトに対して宣言された変数名が、図１８の階層的ファイル準備ルーチンのステップ１７１の間にＩＯポートに対して宣言された変数名に等しくされる。このように、選択されたデータオブジェクトに対する値が、処理されているオペレータの親の階層のために作成されたファンクションの中にスコープされる。
【０２１０】
ステップ１２９で変数名が等しくされた後、あるいはステップ１２７でデータオブジェクトが階層のためのＩＯポートではないと判定された場合には、本方法はステップ１３１に進み、ステップ１２３でオペレータに対して確認された入力データオブジェクトのいくつかが処理されるために残されているかどうかについての判定が行われ、少なくとも１つが処理するために残されている場合には、本方法はステップ１２５に戻る。このように、本方法がステップ１２５〜１３１を通して進み、親の階層のＩＯポートを形成する処理されたオペレータの入力データオブジェクトそれぞれの変数名を、それの対応するＩＯポートの変数名に等しくする。
【０２１１】
入力データオブジェクトの全てが処理された後、本方法はステップ１３３に進み、処理されているオペレータに対応するＡＡＰＩマクロを呼び出すための語句が、その対応する変数名と一緒に書き出される。そして、本方法はステップ１３５に進み、処理されているオペレータが正算かどうかについての判定が行われ、正算と判定された場合には、本方法はステップ１３７に進み、正算オペレータに対する１つの結果データオブジェクトが確認される。逆に、ステップ１３５で処理されているオペレータが非正算と判定された場合には、本方法はステップ１３９に進み、変数、即ち、固定されない非正算オペレータに接続されたデータオブジェクトの全てを出力として確認する。
【０２１２】
処理されているオペレータに対する出力データオブジェクトがステップ１３７または１３９のいずれかで確認された後、本方法はステップ１４１（図１７）に進み、出力データオブジェクトのうちの１つが処理するために選択される。その後、本方法はステップ１４３に進み、選択された出力データオブジェクトが、処理されているオペレータの親のオペレータである階層的オペレータのためのＩＯポートであるかどうかについての判定が行われる。この判定は、ステップ１２７に関連して前述したものに類似し、また、親の階層的オペレータのためのＩＯポートのＩＯ＿ＯＰリストに照会することによって行われる。ステップ１４１で選択されたデータオブジェクトが親の階層的オペレータのためのＩＯポートであると判定された場合には、本方法はステップ１４５に進み、ＩＯポートのための変数名が、ステップ１１９（図１５）でデータオブジェクトに対して宣言された変数名に等しくされる。このステップは、上述したステップ１２９（図１６）に類似し、また、出力データオブジェクト中の値が、対応するＩＯポートを通して親の階層的オペレータのために作成されたファンクションのうちからポートされることを保証し、そして、この値は次の階層レベルのファンクションによってアクセスできる。
【０２１３】
変数がステップ１４５で等しくされた後、または、ステップ１４３で選択された出力データオブジェクトが親の階層のＩＯポートではないと判定された場合には、本方法はステップ１４７に進み、ステップ１３９（図１６）で確認された出力データオブジェクトのいくつかが処理されるために残されているかどうかについての判定が行われ、少なくとも１つが処理されるために残されている場合に、本方法はステップ１４１に戻る。このように、本方法は選択されたオペレータのための出力データオブジェクトのそれぞれを処理して、その親の階層のＩＯポートである各々を対応するＩＯポート変数名に等しくする。
【０２１４】
ステップ１４７で選択されたオペレータに対する出力データオブジェクトが処理されるために残されていないと判定された場合には、本方法はステップ１４９に進み、そのオペレータが制限セットに属するかどうかについての判定が行われ、そのオペレータが制限セットに属する場合に、そのセットの中に何らかの付加的なオペレータが処理されるために残されているかどうかについての判定が行われる。ステップ１４９で同じ制限セットの中に付加的なオペレータが処理されるために残されている場合、本方法はステップ１０９（図１５）に戻り、制限セットからの次のオペレータが、処理するために選択される。このように、制限セット中のオペレータそれぞれを処理するために、本方法はステップ１０９〜１４９を続行する。
【０２１５】
ステップ１４９で処理されるオペレータが制限セットに属さない、あるいは、制限セット中のオペレータの各々が既に処理されていると判定された場合には、本方法はステップ１５１に進み、何らかのオペレータが評価スタック上に処理するために残されているかどうかについての判定が行われる。少なくとも１つのオペレータが処理されるために残されていると判定された場合には、本方法はステップ１０５（図１５）に戻り、スタック上の次のオペレータが処理するために選択される。このように、ステップ１０３の記号パスに対する呼び出しに起因する評価スタック上におかれたオペレータのそれぞれを処理するために、本方法はステップ１０５〜１５１を続行する。オペレータが処理するために残されていないと判定された場合には、本方法はステップ１５３に進み、階層的ファイル終了ルーチンが呼び出されて、そして本方法が終了する。
【０２１６】
階層的ファイル終了ルーチンは、図１９に示される。まず、ステップ１５５では、階層的ファイル準備ルーチン（図１８）のステップ１６７で開かれた階層的オペレータファイルの１つが、処理するために選択される。次に、選択された階層的オペレータファイルのファイルポインタが、目標としてステップ１５７で設定されて、続いて生成されたコードがこのファイルに書き込まれる。
【０２１７】
選択された階層的オペレータのファイルポインタが目標として設定された後、本方法はステップ１５９に進み、引渡し階層ＡＡＰＩがそのファイルに書き込まれる。そして、本ルーチンはステップ１６０に進み、階層的オペレータのためのファンクションリターンが、階層的オペレータファンクションによって戻される引数を含んで、書き込まれる。そして、本ルーチンはステップ１６１に進み、ステップ１５５で選択された階層的オペレータファイルが閉じられる。最後に本ルーチンはステップ１６３に進み、他の階層的オペレータファイルが処理するために残されているかどうかについての判定が行われ、少なくとも１つが処理のために残されている場合、本ルーチンはステップ１５５に戻る。このように、ステップ１６３でこれ以上開いたファイルが残されていないと判定されるまで、開いた階層的オペレータファイルそれぞれを処理するために本ルーチンは続行し、そして、本ルーチンが終了する。
【０２１８】
XIV.ハードウェアシステムの一例
図２０は、本発明を操作できるハードウェアシステムのブロック図である。本システムは、上述したユーザーインタフェース３７、プロセッサ６００および結合メモリ６０１を含む。上述のように、本発明は、ファンクションで構成される任意のソフトウェアシステム上で操作できる。従って、プロセッサ６００は、ソフトウェアファンクションを実行できる任意の変数タイプのプロセッサとすることができる。この中で説明される本発明のソフトウェアツール、ルーチンおよび方法は、それぞれメモリ６０１に記憶でき、またプロセッサ６００上で本発明を実施するために実行できる。
【０２１９】
XV．デザイン反復の方法の一例
上述のことからわかるように、本発明の種々の能力により、デザインを作成し、図表的に変更のできる依存関係グラフにそのデザインを表示し、そして、デザインの構造的依存関係を表示する標準言語でコンピュータプログラムを作成する際に、ユーザーに優れた適応性が与えられ、また、将来的にはシステム上でデザインの作成が実行され得る。例えば、本発明の結合サブシステムをインストールしたソフトウェアシステムによって実行される高水準のステップが、図３５のフローチャートに示される。
【０２２０】
ステップ９８５で、本方法はユーザーからの入力を受け取り、そして、ステップ９８６に進んで、ユーザーによって要求されたデザイン動作を実施するために対応するＡＡＰＩを呼び出す。ステップ９８７で、このＡＡＰＩのための依存関係グラフエンティティが生成され、そして、本方法はステップ９８８に進み、このグラフが評価される。そして、ユーザーは視覚的なプログラム環境を使用して、依存関係グラフを見て、結果デザインが容認できるかどうかを判定する。ステップ９８９で、結果がユーザーによって容認されなかったことが判定された場合には、本方法はステップ９９０に進み、コマンドがグラフを編集するために視覚的なプログラミング環境から受け取られる。そして、本方法はステップ９８８に進み、変更されたグラフが評価される。このように、本方法は、ユーザーが結果デザインを容認したことを示すまでステップ９８８〜９９０を続行する。
【０２２１】
結果が容認されると、本方法はステップ９９１に進み、いくつかの追加のコマンドがユーザーによって受け取られるかどうかについての判定が行われる。多くのコマンドが受け取られる場合には、本方法はステップ９８６に戻り、それらのコマンドが処理される。
これ以上コマンドがユーザーから受け取られない場合には、本方法はステップ９９２に進み、デザインの構造的依存関係を表示する標準言語コンピュータプログラムの生成をユーザーが望むかどうかについての判定が行われる。ユーザーが、コンピュータプログラムの生成を望まない場合には、本方法は単に終了する。しかしながら、プログラムが生成されることが判定された場合には、本方法はステップ９９３に進み、このプログラムが上述した方法で作成され、ステップ９９４に進んで、そのプログラムがソフトウェアシステムにコンパイルされて、リンクされる。
【０２２２】
XVI.結論
このように、本発明の種々の実施形態を説明したことで、様々な変更、修正および改良が、当業者には容易となる。このような変更、修正および改良は、本発明の意図および範囲内であると考えられる。よって、上記の説明や添付図面は、単に例として与えられたものであり、これに限られるものではない。本発明は、特許請求の範囲およびその均等物に定義されるものとしてのみ限定される。
【０２２３】
【発明の効果】
以上説明したように、請求項１〜請求項１１の発明にかかる方法によれば、対応するファンクションによって夫々作成される複数のデザインエンティティの依存関係が表示されるので、ユーザーは、該エンティティが相互に作用する関係を、視覚的により速くかつより容易にみることができ、視覚的なプログラミング環境の中でデザインを作成したり、編集したりすることができる。また、標準言語でコンピュータプログラムが生成されるので、ユーザーは、固有の言語を習得することなく、モデルを再生させることができる。
【０２２４】
請求項１２〜請求項１９の発明にかかる方法によれば、固有ＡＰＩに対してラッパーが実装されて結合ファンクションが作成され、モデルの依存関係表示にグラフエンティティが付加されるので、適応性が増大し、新しい固有ＡＰＩの作成を必要としない。そして、受け取ったコマンドに応じて、ユーザーインタフェースも修正されるので、以後、ユーザーインタフェースから新しい結合システムを呼び出すことができる。
【０２２５】
請求項２０の発明にかかる方法によれば、複数のファンクションが正算と非正算に係るものであるときは、正算と非正算との両者によって作成されるデザインエンティティが依存関係に表示されるので、ユーザーは、かかる関係を視覚的にみることができる。
請求項２１及び請求項２２の発明にかかる方法によれば、デザインが複数のファンクションの対応する１つによって各々作成される場合でも、ユーザーは、同様に該エンティティの依存関係を視覚的にみることができる。
【０２２６】
請求項２３の発明にかかる方法によれば、デザインが複数のファンクションの対応する１つによって各々作成される場合でも、ユーザーは、複数のグラフエンティティで複数のデザインエンティティの依存関係を視覚的にみることができる。
請求項２４の発明にかかる方法によれば、デザインが修正された場合に、デザインの修正による影響を確認することができ、影響を受けたファンクションだけを呼び出し、該ファンクションを実行して前記モデルを更新してデザインアクションの時間を節減することができる。
【図面の簡単な説明】
【図１】本発明による方法のステップを示す上位フローチャート
【図２】本発明により作成される依存関係グラフを示す図
【図３】本発明を使用するＣＡＤシステムのユーザー側からの配景を示す図
【図４】本発明の結合ＡＰＩ構築用ツールと、作成された結合ＡＰＩと、本発明の結合サブシステムがインストールされたソフトウェアシステムの固有ＡＰＩとの間の関係を示す図
【図５】本発明を用いるＣＡＤシステムのユーザインターフェースで受け取られるコマンドが結合ＡＰＩおよび結合ＡＰＩプロセッサを呼び出して、そのコマンドを表示する依存関係グラフを表示し、ユーザーによって要求されたデザイン動作を実行するためにそれら依存関係グラフのエンティティを評価する方法を示す図
【図６】結合ＡＰＩにより呼び出された場合の本発明の結合ＡＰＩプロセッサによって実行されるステップを示すフローチャート
【図７】依存関係グラフ中のオペレータを評価するために呼び出された場合の、本発明の結合ＡＰＩのためのオペレータエバリュエータによって実行されるステップを示すフローチャート
【図８】同上フローチャート
【図９】図７及び図８の評価方法の評価記号パスについての１つの実施形態に関するフローチャート
【図１０】本発明の正算オペレータ処理ルーチンのフローチャート
【図１１】本発明の非正算オペレータ処理ルーチンのフローチャート
【図１２】同上フローチャート
【図１３】図７及び図８の評価方法の評価パスを示すフローチャート
【図１４】ソフトウェアシステム中に本発明を統合する本発明の統合プロセスのステップを示すフローチャート
【図１５】本発明のプログラム生成方法および支援ルーチンのステップを示すフローチャート
【図１６】同上フローチャート
【図１７】同上フローチャート
【図１８】同上フローチャート
【図１９】同上フローチャート
【図２０】本発明を作動できるハードウェアシステムのブロック図
【図２１】さら穴を有する箱を示す図
【図２２】階層的オペレータを使用しない本発明の依存関係グラフを示す図
【図２３】階層的オペレータを使用する図１６の依存関係グラフを示す図
【図２４】図１６，図１７の依存関係グラフにおける階層的オペレータの実施形態についての概念図
【図２５】本発明の依存関係グラフに引渡される各オペレータに作用する方法のフローチャート
【図２６】同上フローチャート
【図２７】同上フローチャート
【図２８】同上フローチャート
【図２９】本発明のインタプリタルーチンを示すフローチャート
【図３０】視覚的なプログラミング環境を用いる本発明のデザインおよび依存関係グラフについて処理編集するための方法を示すフローチャート
【図３１】本発明の再定義入力ルーチンのステップを示すフローチャート
【図３２】本発明の置換オペレータルーチンのステップを示すフローチャート
【図３３】本発明による依存関係グラフの視覚的表示の一例を示す図
【図３４】本発明による依存関係グラフの視覚的表示の一例を示す図
【図３５】本発明による方法のステップを示す上位フローチャート
【符号の説明】
３〜６  データオブジェクト
７，１９  オペレータ
９〜１２，１５，２１，２３  リレーション
【図１】
0003962109.tif 000002
【図２】
0003962109.tif 000003
【図３】
0003962109.tif 000004
【図４】
0003962109.tif 000005
【図５】
0003962109.tif 000006
【図６】
0003962109.tif 000007
【図７】
0003962109.tif 000008
【図８】
0003962109.tif 000009
【図９】
0003962109.tif 000010
【図１０】
0003962109.tif 000011
【図１１】
0003962109.tif 000012
【図１２】
0003962109.tif 000013
【図１３】
0003962109.tif 000014
【図１４】
0003962109.tif 000015
【図１５】
0003962109.tif 000016
【図１６】
0003962109.tif 000017
【図１７】
0003962109.tif 000018
【図１８】
0003962109.tif 000019
【図１９】
0003962109.tif 000020
【図２０】
0003962109.tif 000021
【図２１】
0003962109.tif 000022
【図２２】
0003962109.tif 000023
【図２３】
0003962109.tif 000024
【図２４】
0003962109.tif 000025
【図２５】
0003962109.tif 000026
【図２６】
0003962109.tif 000027
【図２７】
0003962109.tif 000028
【図２８】
0003962109.tif 000029
【図２９】
0003962109.tif 000030
【図３０】
0003962109.tif 000031
【図３１】
0003962109.tif 000032
【図３２】
0003962109.tif 000033
【図３３】
0003962109.tif 000034
【図３４】
0003962109.tif 000035
【図３５】
0003962109.tif 000036