JPH0969120A - ソフトウェアモデリングシステムにおけるデータ依存関係を表示する方法 - Google Patents

Abstract

(57)【要約】 【課題】ユーザーに分かりやすい方法で、結果として生
じるデザインの構造上の依存関係を表示する。 【解決手段】デザインが、デザインセッション中のソフ
トウェアシステムのファンクションのグループの実行に
より生成され（ステップ２０１）、生成されたデザイン
の依存関係グラフ表示が生成される（ステップ２０
３）。デザインの修正も、依存関係グラフを用いて、デ
ザインのどの部分が修正により影響を受けるかを判断
し、影響を受けた部分を変更するのに必要なコードのみ
を再実行することにより行われる。デザインセッション
中で実行完了後、コンピュータプログラムを標準言語で
生成する（ステップ２０５）。そしてソフトウェアシス
テム上でコンピュータプログラムを走らせてデザインを
生成する（ステップ２０９）。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ソフトウェアモデ
リングシステムにおけるデータ依存関係を表示する方法
に関する。

【０００２】

【従来の技術】ソフトウェアシステムは、多くの異なる
分野に存在する。この分野において、ユーザーは、イン
タラクティブセッション(interactiv session)中に一連
のコマンド(command) を入力することで、システムと相
互に作用し、それに応じて、ソフトウェアシステムは、
ユーザーコマンドによって定義される動作を行う多数の
ファンクション(function)を実行する。インタラクティ
ブデザインセッション中にデザインのコンピュータモデ
ルを生成するコンピュータ支援設計（ＣＡＤ）システム
は、このようなシステムの一例である。マサチューセッ
ツ州ベッドフォードにあるコンピュータビジョンコーポ
レーション（本願出願人）から入手できるＣＡＤＤＳ
ｌｉｎｅのようなＣＡＤシステムは、２次元及び／又は
３次元の機械装置のコンピュータモデルを生成するツー
ルを提供する。一般的に、製品デザインを生成する一連
のシステム定義済コマンドをユーザーインタフェースに
入力することで、ユーザーはモデルを相互作用として構
築する。例えば、ユーザーは、箱書き込みのようなある
コマンドを、その箱の所望の寸法（長さ、高さ及び幅）
と所望の位置とを共に入力して、特定の特徴のある箱
を、デザインに加えることができる。他のコマンドは、
前記箱と統合されて、製品デザインを完成することがで
きる円柱、球、穴等のような要素を加えることができ
る。従って、このようなシステム定義済コマンドを入力
することで、ユーザーは、機械装置のコンピュータモデ
ルを構築することができる。

【０００３】ＣＡＤシステムにおけるユーザーインタフ
ェースは、従来から、ユーザーから受け取ったコマンド
を処理するコマンドプロセッサを含んでいる。コマンド
プロセッサは一般的に、受信コマンドを記憶するコマン
ドファイルを生成して、ユーザーとＣＡＤシステム間の
インタラクティブセッションの記録を生成できる。コマ
ンドとコマンドプロセッサは一般的に、個々のＣＡＤシ
ステムに固有の(proprietary) ものであるので、コマン
ドファイルは本来固有言語である。コマンドを受け取る
とすぐに、ユーザーインタフェースは、アプリケーショ
ンプログラミングインタフェース（ＡＰＩ）を呼び出
す。このＡＰＩは、システムに、アクティビティ(activ
ity)を行わせるソフトウェアファンクションである。例
えば、ＣＡＤシステムにおいて、ＡＰＩは幾何学的なモ
デラー（modeler)に、固有のコマンドによって要求され
るデザインアクションを達成するための輪郭、面及び頂
点のようなエンティティ(entity)を生成させ、かつ、相
互に連結させて、データベースに前記エンティティをス
トアする。インタラクティブセッション中にユーザーか
ら受け取った一連のコマンドによって作成されるエンテ
ィティの組合せが、製品デザインを定義する。

【０００４】ユーザーが、前もって作成されたエンティ
ティ（例えば、箱の高さ）の１つのパラメータ(paramet
er) を変えて製品デザインを変更しようとする場合、ユ
ーザーはヒストリーモジュールを変更してその変更を反
映し、その後、ヒストリーモジュール中の全てのコマン
ドを再実行するシステムに、コマンドのソースとしての
ヒストリーモジュールを供給することができる。コマン
ドが再実行されると、コマンドはコマンドプロセッサに
供給され、コマンドプロセッサは再び適切なＡＰＩを呼
び出し、ＡＰＩは一般的に古いデザインエンティティを
次々に捨て、新しいヒストリーモジュールはもちろん、
新しい製品デザインをもたらす新しいエンティティを作
成する。このタイプのシステムは、コマンドが基本的な
構築ブロックであるため、”コマンドベース”システム
と呼ばれている。

【０００５】

【発明が解決しようとする課題】しかしながら、前述し
たコマンドベースシステムは、ユーザーがインタラクテ
ィブセッションを記録し、その記録を変更し、それらの
変更に基づいて再実行できるものであるが、いくつかの
不具合がある。これらのシステムによって作成されるヒ
ストリーモジュールは、インタラクティブデザインセッ
ション中に受け取られるコマンドの順序を反映し、結果
として生じるデザインの構造上の依存関係(dependency)
を表示しない。従って、例え少しであっても、デザイン
に何らかの変更がなされると、ヒストリーモジュール全
体が新しいデザインを生成するために再実行されなけれ
ばならず、この再実行がデザインプロセスを遅らせるこ
とになる。

【０００６】パラメータ能力(parametric capabilitie
s) を含むいくつかのＣＡＤシステムが開発されて、変
更がデザインパラメータになされると、変更されたパラ
メータによって影響を受けるデザイン部分だけを更新す
ることにより、システムがデザインを変更するようにし
ている。しかしながら、これらのパラメータ能力は、従
来、システムによって使用される固有のコマンド中に組
み込まれている。従って、サードパーティーベンダーが
ソフトウェアシステム上に付加能力を供給しようとする
場合、システムのパラメータ能力が維持されるべきもの
であれば、新しい能力は、システムの固有のコマンドセ
ットに統合されなければならない。

【０００７】前述したコマンドベースシステムによる他
の不具合は、システムがパラメータ能力を含んでいるか
どうかに関係なく、ヒストリーモジュールへの変更が固
有のコマンドを使用しなければならない点である。従っ
て、ユーザーは、ヒストリーモジュール中に反映された
デザインを変更するためには、新しい”プログラミング
言語”を学習しなければならない。さらに、このタイプ
のヒストリーモジュールは、ヒストリーモジュールがデ
ザインの構造上の依存関係を表示せず、むしろ、デザイ
ンプロセス中に受け取られたコマンドの順序にだけ関係
があるため、デザイナーにとっては、作業が困難であ
る。

【０００８】本発明はこのような従来の課題に鑑みてな
されたもので、ユーザーに分かりやすい方法で、結果と
して生じるデザインの構造上の依存関係を表示すること
のできるソフトウェアモデリングシステムにおけるデー
タ依存関係を表示する方法を提供することを目的とす
る。

【０００９】

【課題を解決するための手段】このため、請求項１の発
明にかかる方法は、デザインを作成する際に使用する複
数のファンクションを含むソフトウェアシステム上で、
デザインセッションから生じるデザインを表示する方法
であって、前記デザインは、対応するファンクションに
よって夫々作成される複数のデザインエンティティを含
み、前記デザインを形成する複数のデザインエンティテ
ィの依存関係を示すデザインの依存関係表示を作成する
依存関係作成ステップと、前記デザインを形成するデザ
インエンティティを作成する際に使用される対応するフ
ァンクションを呼び出して、デザインを表示するコンピ
ュータプログラムを前記依存関係表示から標準的なプロ
グラミング言語で生成するプログラム生成ステップと、
を含むようにした。

【００１０】請求項２の発明にかかる方法では、前記プ
ログラム生成ステップが、前記ソフトウェアシステム上
で、デザインを形成する複数のデザインエンティティの
依存関係に対応する構造を有するコンピュータプログラ
ムを生成するステップであるようにした。請求項３の発
明にかかる方法では、前記ソフトウェアシステムは、前
記デザインの依存関係表示を評価するために実行される
ソフトウェアルーチンであることを特徴とし、また、前
記プログラム生成ステップは、前記コンピュータプログ
ラムを生成する際にソフトウェアルーチンの少なくとも
一部を実行するステップであるようにした。

【００１１】請求項４の発明にかかる方法では、コンピ
ュータプログラムを編集し、修正されたデザインを表示
する修正コンピュータプログラムを作成するプログラム
修正ステップと、該修正コンピュータプログラムをソフ
トウェアシステム上で実行し、ソフトウェアシステム上
で修正デザインを生成するデザイン修正ステップと、を
さらに含むようにした。

【００１２】請求項５の発明にかかる方法では、前記デ
ザイン修正ステップは、前記修正されたデザインの依存
関係表示を生成するステップである。請求項６の発明に
かかる方法では、前記依存関係作成ステップは、前記デ
ザインを形成する複数のデザインエンティティのサブセ
ットを表示する少なくとも１つの階層的なデザインエン
ティティを含む依存関係表示を作成するステップであ
り、前記プログラム生成ステップは、少なくとも１つの
階層的なデザインエンティティを表示するコンピュータ
プログラムを生成するステップである。

【００１３】請求項７の発明にかかる方法では、前記プ
ログラム生成ステップは、さらに、前記階層的なデザイ
ンエンティティによって表示される複数のデザインエン
ティティのサブセットを作成する複数のファンクション
を呼び出して、少なくとも１つの階層的なデザインエン
ティティを表示するコンピュータプログラムを生成する
ステップである。

【００１４】請求項８の発明にかかる方法では、前記コ
ンピュータプログラムを格納するプログラム格納ステッ
プと、前記ソフトウェアシステムから前記デザインを削
除して格納空間を保存するデザイン削除ステップと、を
さらに含んでいる。請求項９の発明にかかる方法では、
前記ソフトウェアシステム上でコンピュータプログラム
を実行してデザインを再生するデザイン再生ステップを
さらに含んでいる。

【００１５】請求項１０の発明にかかる方法では、前記
ソフトウェアシステムから依存関係表示を削除して格納
空間をさらに保存する依存関係表示削除ステップをさら
に含んでいる。請求項１１の発明にかかる方法では、前
記ソフトウェアシステム上で依存関係表示を再生するコ
ンピュータプログラムを実行する依存関係再生ステップ
をさらに含んでいる。

【００１６】請求項１２の発明にかかる方法では、複数
のファンクションと１つのユーザーインタフェースを有
し、前記複数のファンクションの対応する１つを呼び出
すことによって複数のコマンドの各々の受領に応答する
ソフトウェアモデリングシステムに、パラメータ能力を
供給する方法であって、前記複数のファンクションは、
モデルを作成するモデリングセッション中に実行され、
ソフトウェアシステムにおいて前記複数のファンクショ
ンの各々の周囲にラッパーを供給して複数の結合ファン
クションを作成するステップであって、該複数の結合フ
ァンクションの各々は、対応するファンクションを呼び
出すことを特徴とし、さらに、その対応するファンクシ
ョンが前記モデリングセッション中に実行されたとき、
前記モデルの依存関係表示にグラフエンティティを作成
し、付加する能力を有するものである結合ファンクショ
ン作成ステップと、各々受け取ったコマンドに応じて、
該受け取ったコマンドに対応する前記ファンクションに
対応する結合ファンクションが呼び出されるように、前
記ユーザーインタフェースを修正するユーザーインタフ
ェース修正ステップと、を含んでいる。

【００１７】請求項１３の発明にかかる方法では、前記
複数のファンクションの少なくとも１つは、固有のパラ
メータ能力を有していないようにしている。請求項１４
の発明にかかる方法では、前記複数のファンクション
は、第１のフォーマットでフォーマットされた引数の第
１のセットに作用する第１のファンクションを含むこと
を特徴とし、また、前記結合ファンクション作成ステッ
プは、第１のファンクションの周囲に第１のラッパーを
供給するステップであって、該第１のラッパーは、第１
のフォーマットとは異なる第２のフォーマットでフォー
マットされた引数の第２のセットを受け取ることが可能
であり、第１のファンクションが呼び出されるとき、引
数の第２のセットを引数の第１のセットに変換するもの
である。

【００１８】請求項１５の発明にかかる方法では、前記
結合ファンクション作成ステップは、前記ラッパーの各
々を、オブジェクト指向コンピュータプログラミング言
語に供給するステップである。請求項１６の発明にかか
る方法では、修正が前記モデルになされたとき、前記依
存関係表示を使用するツールを供給して前記デザインの
修正によって影響を受けるグラフエンティティに対応す
る前記モデルを作成するのに使用されるファンクション
だけを再評価するファンクション再評価ステップをさら
に含んでいる。

【００１９】請求項１７の発明にかかる方法では、各々
の結合ファンクションのためのテーブルエントリを有す
るハッシュテーブルを作成するステップであって、各々
のテーブルエントリは、該結合ファンクションが実行さ
れたとき、依存関係表示に作成され、付加された前記グ
ラフエンティティのトポロジイを確認するものであるハ
ッシュテーブル作成ステップをさらに含んでいる。

【００２０】請求項１８の発明にかかる方法では、前記
結合ファクション作成ステップは、さらに、標準的なコ
ンピュータプログラミング言語により前記ラッパーの各
々を供給するステップである。請求項１９の発明にかか
る方法では、前記グラフエンティティを依存関係表示に
作成し、付加する前記結合ファンクションの各々と協働
する単一のプロセッサファンクションを作成する単一プ
ロセッサファンクション作成ステップをさらに含んでい
る。

【００２１】請求項２０の発明にかかる方法では、各々
の結合ファンクションのためのテーブルエントリを有す
るハッシュテーブルを作成するステップであって、各々
のテーブルエントリは、結合ファンクションが実行され
たときに、前記依存関係表示に作成され、付加されるグ
ラフエンティティのトポロジィを確認するハッシュテー
ブル作成ステップをさらに含んで構成され、また、前記
単一プロセッサファンクション作成ステップは、単一の
プロセッサファンクションを作成し、ハッシュテーブル
においてエントリにアクセスすることにより前記依存関
係表示を作成するステップであって、該単一のプロセッ
サファンクションは一般的なものであり、結合ファンク
ションによって呼び出されたときに、それに渡される引
数に応じて動作するものである。

【００２２】請求項２１の発明にかかる方法では、デザ
インを作成する際に使用する複数のファンクションを含
むソフトウェアシステム上で、デザインセッションから
生じるデザインに作用する方法であって、前記デザイン
は対応するファンクションによって各々作成される複数
のデザインエンティティであり、前記複数のファンクシ
ョンは正算と非正算に係るものであることを特徴とし、
前記デザインを形成する複数のデザインエンティティの
間で、依存関係を示すデザインの依存関係表示を作成す
るステップであって、該依存関係表示は、正算と非正算
との両者によって作成されるデザインエンティティを表
示するものである依存関係作成ステップを含んでいる。

【００２３】請求項２２の発明にかかる方法では、前記
ソフトウェアシステムは、さらに、相互に接続された非
正算の制限セットを解明するエンジンを含むことを特徴
とし、また、前記依存関係作成ステップは、さらに、デ
ザインをチェックして、相互に接続された非正算の各々
の制限セットがエンジンが解明できる型のものであるか
否か判定するデザインチェックステップを含んでいる。

【００２４】請求項２３の発明にかかる方法では、デザ
インを作成する際に使用する複数のファンクションを含
むことを特徴とするソフトウェアシステム上で、デザイ
ンセッションから生じるデザインに作用する方法であっ
て、前記デザインは、前記複数のファンクションの対応
する１つによって各々作成される複数のデザインエンテ
ィティであることを特徴とし、前記デザインを形成する
前記複数のデザインエンティティの間で、依存関係を示
すデザインの依存関係表示を作成する依存関係作成ステ
ップと、前記デザインの依存関係表示を表示する依存関
係表示ステップと、を含んでいる。

【００２５】請求項２４の発明にかかる方法では、依存
関係表示を修正し、修正されたデザインを表示する修正
依存関係表示を作成する依存関係修正ステップと、該修
正依存関係表示から修正デザインを生成するデザイン修
正ステップと、をさらに含んでいる。請求項２５の発明
にかかる方法では、デザインを作成する際に使用する複
数のファンクションを含むことを特徴とするソフトウェ
アシステム上で、デザインセッションから生じるデザイ
ンに作用する方法であって、前記デザインは、前記複数
のファンクションの対応する１つによって各々作成され
る複数のデザインエンティティであることを特徴とし、
前記デザインを形成する前記複数のデザインエンティテ
ィの依存関係を示すデザインの依存関係表示を作成する
ステップであって、該依存関係表示は、前記複数のデザ
インエンティティを表示する複数のグラフエンティティ
に特徴を有するものである依存関係作成ステップと、同
じ階層のグラフエンティティを有する複数のグラフエン
ティティの少なくとも２つを表示するグラフエンティテ
ィ表示ステップと、を含んでいる。

【００２６】請求項２６の発明にかかる方法では、前記
デザインに修正を加えるデザイン修正ステップと、前記
依存関係表示を使用して、デザインの修正によって影響
を受ける１組のデザインエンティティを確認するデザイ
ンエンティティ確認ステップと、前記修正によって影響
を受ける１組のデザインエンティティに対応するデザイ
ンを作成する際に使用されるファンクションだけを再評
価するファンクション再評価ステップと、をさらに含む
ことを特徴とする請求項１〜請求項２５のいずれか１つ
に記載のソフトウェアモデリングシステムにおけるデー
タ依存関係を表示する方法。

【００２７】

【発明の実施の形態】本発明の実施の形態によれば、モ
デリングを行う任意のソフトウェアシステムのための一
組のファンクションを、パラメータ能力を有する対応す
る一組のファンクションに変換するための方法が供給さ
れる。従って、パラメータ能力は、その一組のファンク
ションが固有のパラメータ能力を有していないソフトウ
ェアシステムに供給される。

【００２８】他の実施の形態では、本発明によって作成
されるパラメータファンクションが、インタラクティブ
ユーザーセッション中に、或いは、デザイン又はモデル
を作成するプログラムによって呼び出されると、パラメ
ータファンクションは、結果としてのモデルだけではな
く、モデルの依存関係グラフ表示をも生成する。別の実
施の形態では、本発明によって作成される依存関係グラ
フが、正算(directed)ファンクションと非正算制限(non
-directed constraint) 関係とが単一の依存関係グラフ
に混合できるように作成されて評価される。

【００２９】さらに、他の実施の形態では、変更がモデ
ルに対してなされると、本発明によって作成された依存
関係表示が使用されて、変更によって影響を受けるモデ
ルの部分だけが更新されたモデルを作成する際に再評価
される。本発明の他の実施の形態によれば、依存関係グ
ラフは、モデルの依存関係を表示するためにユーザーに
視覚的に提供される。

【００３０】本発明の他の実施の形態によれば、ソフト
ウェアシステムで実行されるファンクションは、依存関
係グラフにおける階層的なグループに分類される。従っ
て、複数のファンクションを必要とするユーザーのデザ
イン目的を、依存関係グラフにおいて単一の階層的なエ
ントリーで表示できる。本発明の他の実施の形態によれ
ば、依存関係グラフは、視覚的なプログラミング環境を
介して作成され、或いは、編集される。依存関係グラフ
に対して変更がなされるとき、グラフを再評価して、対
応する変更をモデルに編入できる。

【００３１】他の実施の形態では、本発明によって作成
された依存関係グラフは、モデルへの入力値かまたは、
モデルを作成するのに使用されるファンクションを表示
するグラフ要素を変更するために、ユーザーが変更でき
る。さらに他の実施の形態では、視覚的なプログラミン
グ環境が依存関係グラフを変更するのに使用されると
き、環境が本発明によって作成される一組のパラメータ
ファンクションを呼び出す。パラメータファンクション
は、ユーザーに依存関係グラフを図式的に生成し、編集
させる視覚的なプログラミング技術と互換性がある。

【００３２】さらに他の実施の形態では、本発明に従っ
て作成された一組のパラメータファンクションが、ソフ
トウェアシステムのファンクションの周囲にラッパー(w
rapper) を作成することで生成される。ラッパーは、前
述した視覚的なプログラミング環境のような、固有でな
いツールと互換となるように、標準的なコンピュータプ
ログラミング言語で書かれている。

【００３３】本発明のさらに他の実施の形態によれば、
ソフトウェアシステム上のモデルやデザインの表示か
ら、コンピュータプログラムを生成するための方法と装
置が供給される。この表示はモデルを形成する複数のモ
デルエンティティの間で依存関係に関してモデルを定義
する。コンピュータプログラムは、標準プログラミング
言語で書くことができる。プログラムがソフトウェアシ
ステムで実行されるとき、プログラムは依存関係表示は
もちろんモデルをも生成する。従って、コンピュータプ
ログラムは、モデリングセッションを効率的な記憶のた
めの標準言語プログラムに変換できる。コンピュータプ
ログラムは、本発明によって作成される依存関係グラフ
から生成できる。

【００３４】他の実施の形態では、コンピュータプログ
ラムは編集した後、デザインの変更バージョンを生成す
るソフトウェアシステムで実行できる。本発明の他の特
徴及び利点は、詳細な説明及び図面から明らかとなる。 I.概略 本発明によれば、方法と装置は、モデルリングシステム
内のＡＰＩを、モデルリング(modeling)セッション中に
ユーザインタフェースから又はより大きなプログラムの
一部として呼び出されたとき、モデリングセッション中
に呼び出されたＡＰＩファンクションと、ＡＰＩに対す
る引数と、ＡＰＩファンクションの結果との間の依存関
係(dependency)を表示するグラフを生成する結合ＡＰＩ
に変換するための方法と装置が提供される。依存関係グ
ラフから、本発明により、ユーザーは、（１）入力をグ
ラフに変換し、影響を受けたファンクションのみを再実
行させること、（２）グラフの構造的依存関係を表示
し、実行時に、グラフを作成するモデリングセッション
と同じ結果を生じる固有でない(non-proprietary) コン
ピュータプログラムを生成すること、（３）依存関係を
視覚化するためのグラフを見ること、（４）モデルの依
存関係構造を変更するためにグラフを編集すること、そ
して（５）モデルを生成するのに使用されるＡＰＩファ
ンクションを変換するためにグラフを編集することがで
きる。

【００３５】本発明の１つの様相によれば、デザインを
生成するソフトウェアシステムファンクションの実行に
基づいて、デザインの依存関係グラフ表示と、依存関係
グラフから生成され、そしてまたデザインの構造的依存
関係を表示する固有でないコンピュータプログラムと、
を生成する方法が提供される。この方法は、図１のフロ
ーチャートに図示されている。ステップ２０１におい
て、デザインは、デザインセッション中のソフトウェア
システムのファンクションのグループの実行により生成
され、そしてステップ２０３にて、生成されたデザイン
の依存関係グラフ表示が生成される。デザインがデザイ
ンセッション中で修正される場合、本発明は依存関係グ
ラフを用いて、デザインのどの部分が修正により影響を
受けるかを判断するとともに、デザインの影響を受けた
部分を変更するのに必要なコードのみを再実行する。ス
テップ２０５に示すように、デザインセッション中で実
行完了後、依存関係グラフは、また、実行されたとき
に、依存関係グラフと、それが表示するデザインと、を
生成するコンピュータプログラムを、標準言語で生成す
るように使用できる。ユーザーは、ステップ２０７で示
すように、コンピュータプログラムを編集して修正され
たデザインを表示し、そしてソフトウェアシステム上で
コンピュータプログラムを走らせて修正されたデザイン
を生成することができる（ステップ２０９）。コンピュ
ータプログラムは、固有でない言語で記述されているの
で、デザイナーは、それを修正するために固有の言語を
習得する必要がない。なおその上、コマンドがデザイン
セッション中にユーザーから受信されるシーケンスから
というよりもむしろ依存関係グラフからプログラムが開
発されるので、コンピュータプログラムはデザインの構
造的な依存関係を表示する。このように、ユーザーが十
分なコンピュータプログラミングの経験を有していなく
ても、プログラム構成はユーザーによって容易に理解さ
れ、プログラムを容易に修正できる。

【００３６】以上、述べられたように、ソフトウェアプ
ログラムは、従来、アプリケーションプログラミングイ
ンタフェース（ＡＰＩｓ）を含み、これは、システム定
義ユーザーコマンドと１対１の関係に一般的にマップ化
された高水準のファンクションである。本発明によれ
ば、本発明をソフトウェアシステムの中に統合する統合
プロセスの一部として、最初にソフトウェアシステムの
各ＡＰＩを通ってＡＰＩの新しいセットを生成するツー
ルが供給される。そして、ソフトウェアシステムのユー
ザーインタフェースは、ユーザーから受け取ったコマン
ドに応答してこれらの新しいＡＰＩを呼び出すように修
正される。本発明のツールによって作成された新しいＡ
ＰＩは、本質的に２つのことを行う。第１に、新しいＡ
ＰＩは、ソフトウェアシステムによって供給されたＡＰ
Ｉのセットによって実行されたファンクションの全て
を、本質的に実行する。第２に、新しいＡＰＩは、ま
た、ユーザーによって作成されたデザインの依存関係グ
ラフ表示を作成するとともに維持する。この依存関係グ
ラフ表示は、グラフへの編集を通してデザインのグラフ
的な編集ができるように、上述されたパラメータ能力を
供給するのに使用でき、そして、また、デザインの構造
的依存関係を表示する標準言語のコンピュータプログラ
ムを生成するのに使用できる。このように、本発明のツ
ールは、高水準ファンクション、あるいはＡＰＩで構成
された何らかのソフトウェアシステム上で、まず、走ら
せて、システムを本発明によって供給された上述の結合
能力を有するシステムに、ユーザーにわかりやすい方法
で変換する結合サブシステムを形成する。

【００３７】前述の内容から理解され、また下記説明か
ら明確になるように、本発明は、そのコマンドセット中
にパラメータ能力を含んでいないとしても、ＡＰＩで構
成されるどんなソフトウェアシステムにもパラメータ能
力を供給することができる。本発明のこの特徴は、サー
ドパーティに、付加的な能力をソフトウェアシステムに
供給させるには有利なものである。ソフトウェアシステ
ムに付加的な能力を供給するには、サードパーティは、
コマンドと、システムのＡＰＩと互換性のある対応する
ＡＰＩと、を供給するだけでよい。付加的なコマンドは
ソフトウェアシステムのコマンドセット内にパラメータ
能力を供給するために統合される必要はない。なぜなら
ば、本発明のツールが、サードパーティのコマンドとイ
ンストールされたＡＰＩとを有するソフトウェアシステ
ム上で実行されたとき、本発明のツールにより、そして
これらの新しいＡＰＩが使用されてデザインセッション
中に作成されたデザインの依存関係グラフ表示を生成、
維持、そして更新するようにパラメータ能力が供給され
るからである。

【００３８】以下の説明では、本発明が実施されるソフ
トウェアシステムに供給される具体例は、インタラクテ
ィブデザインセッション中にデザイナーからコマンドを
受け取って製品デザインを作成するＣＡＤシステムであ
る。しかしながら、本発明がＣＡＤシステム、あるいは
インタラクティブセッション中に入力を受け取るシステ
ムへの使用に限定されるものではないことは明らかであ
る。本発明は、ファンクションによって構成され、そし
て様々な方法でユーザーからの入力を受け取るどんなソ
フトウェアシステムにも使用できる。例えば、本発明
は、多数のパラメータに基づいて経済モデルを作成する
ソフトウェアシステム、あるいは他の多くのタイプのソ
フトウェアシステムに使用できる。このように、モデル
やデザインといった言葉が依存関係グラフによってモデ
ル化されたソフトウェアシステム出力を参照するために
使用されるが、これらの言葉は、ＣＡＤモデルに限定さ
れることを意図するものではなく、多数のファンクショ
ンの実行に基づいて何らかのソフトウェアシステムによ
って作成された出力を含むことを意図するものである。

【００３９】図２は、ＣＡＤシステム上で動作する本発
明によって生成される簡単な依存関係グラフ１の例であ
る。グラフ１は、デザイナーが箱をデザインの中に入
れ、箱の重量を計算するためにコマンドを入力するイン
タラクティブデザインセッション中に生成される。箱を
入れるためのコマンドに従って、デザイナーは、箱の中
心に座標を設定するとともに、箱の長さ、幅、高さを設
定する引数(argument)を供給する。これらの引数はデー
タオブジェクト３〜６としてグラフ１に夫々表示され
る。データオブジェクトは、グラフにおける数値を含む
構成要素である。データオブジェクト３〜６の夫々は関
連づけられたファンクションを示すオペレータ７、即
ち、挿入箱に接続されている。オペレータは少なくとも
１つのデータオブジェクトに作用し、ユーザーによって
与えられたデザインアクションを表示するファンクショ
ン又は評価式であるグラフにおける構成要素である。デ
ータオブジェクト３〜６は、リレーション９〜１２を経
由してオペレータ７に夫々結合されている。リレーショ
ンは、結合されたオペレータに関して各データオブジェ
クトがどのような役割を果たすかを確認するためのグラ
フにおける構成要素である。図２に示す例において、リ
レーション９〜１２は、夫々、箱の長さ、幅、高さ、そ
して中心を設定するものとして結合されたデータオブジ
ェクトを確認する。オペレータ７がデータオブジェクト
３〜６に作用した結果はリレーション１５，データオブ
ジェクト１７によりグラフに表示される。データオブジ
ェクト１７はオペレータ７によって作成されたソフトウ
ェアエンティティを表示し、リレーション１５は、オペ
レータの結果を箱として確認する。

【００４０】箱の重量を計算するコマンドは、オペレー
タ１９によってグラフ中に表示される。箱は立体として
より広く分類される多くの構成の１つである。立体の重
量を計算するために、オペレータ１９は、第１のリレー
ション２１を経由して受け取った立体の体積に、第２の
リレーション２３を経由して受け取った立体の密度を乗
算する。この例では、立体は、計算重量コマンドが引数
として供給されるというよりもむしろ、デザイン中です
でに指定されている。この依存関係は、箱を表示するデ
ータオブジェクト１７に接続されているリレーション２
１によってグラフに表示される。密度が、デザイン中で
前もって指定されていないので、箱の重量を計算するコ
マンドが引数としてユーザーによって供給される。依存
関係の不足は、密度の引数を表示するデータオブジェク
ト２５に接続されているリレーション２３によってグラ
フに表示され、グラフの中ではどのオペレータからも出
力されない。オペレータ１９がデータオブジェクト１７
と２５に作用した結果は、リレーション２７とデータオ
ブジェクト２９によってグラフに表示される。データオ
ブジェクト２９は、オペレータ１９によって作成された
ソフトウェアエンティティを表示し、リレーション２７
は、箱の重量としてオペレータの結果を確認する。

【００４１】図２に示された簡単な例から理解されるよ
うに、本発明により作成された依存関係グラフは、イン
タラクティブセッション中に作成されたデザインの構造
的依存関係を明示している。グラフは、箱の寸法を表示
しているデータオブジェクト３〜５と同様に、箱の重量
２９が密度データオブジェクト２５に依存していること
を明示している。同様に、グラフは、箱を表示している
データオブジェクト１７が密度データオブジェクト２５
に依存していないことを明示している。従って、デザイ
ナーがインタラクティブセッション中に箱の密度の修正
を選択する場合、デザインを更新するために再実行され
る必要のあるグラフの唯一の部分はオペレータ１９であ
り、オペレータ７は、再実行される必要がない。このよ
うに、デザインの修正がなされたとき、依存関係グラフ
は、本発明が、修正データオブジェクトに依存するオペ
レータのみを再実行することを可能とする。図示された
例は全く簡単なものであるが、本発明のこの特徴によっ
て提供される計算時間の節減は特に大きなデザインにつ
いて著しいことは、明らかである。

【００４２】本発明の関連サブシステムがインストール
されたＣＡＤシステムのユーザー側からの背景のグラフ
的な表示が図３に示される。このＣＡＤシステム３５
は、従来のＣＡＤコマンド３９としてユーザーからの入
力を受け取るユーザーインタフェース３７を含む。概し
て、ユーザーは、一連のＣＡＤコマンド３９を入力する
ことによってＣＡＤシステムで、インタラクティブデザ
インセッションを行う。ＣＡＤコマンドに応答して、ユ
ーザーインタフェース３７は、ＣＡＤシステムの対応固
有ＡＰＩ４３を順次呼び出す対応結合ＡＰＩ４２を呼び
出す。ＡＰＩ４３は、製品デザイン４５を作成するため
に実行される。インタラクティブデザインセッション中
に、結合ＡＰＩ４３とグラフコントローラ４７とは、共
に、図２に図示された依存関係グラフのような、製品デ
ザイン４５の構造的依存関係を表示する依存関係グラフ
を生成する。デザインセッションの最後で、ＣＡＤシス
テムは、また、依存関係グラフから、実行されたときに
製品デザイン４５の構造的依存関係をも表示するＣ＋＋
のような非固有の言語でコンピュータプログラム４９を
生成することができる。その後、ユーザーは、ＣＡＤシ
ステムのエディタ／コンパイラ／リンカ５１を用いて、
修正された製品デザインを表示するためにコンピュータ
プログラム４９を編集し、修正された製品デザイン４５
を生成するために、ＣＡＤシステムのためにプログラム
をコンパイルしリンクする。代わりに、ユーザーは、視
覚的なプログラミング環境を使って依存関係グラフをグ
ラフィカルに編集することができ、この依存関係グラフ
は修正された製品デザイン４５と修正されたコンピュー
タプログラム４９とを生成するために使用できる。視覚
的なプログラミング環境の出力は、デザインを修正する
ための望ましいデザイン動作を遂行する対応結合ＡＰＩ
に視覚的なプログラミング環境から受信された表現を翻
訳するインタプリタ５２に供給される。

【００４３】II．結合サブシステムの統合 上述したように、本発明が種々のソフトウェアシステム
のいずれにもこれらのシステムのユーザーにとって分か
りやすいように、使用可能にするために、各ソフトウェ
アシステム上で１度だけ実行して、本発明の能力を供給
するソフトウェアツールが供給される。このソフトウェ
アツールはどんな標準コンピュータ言語でも記述できる
が、Ｃ＋＋のようなオブジェクト指向プログラミング言
語で記述するのが好ましい。図４は、このツールの構成
を図示し、結合ＡＰＩ構築用ツール６１として参照され
る。ツール６１は、本発明の特徴を組み入れるためにソ
フトウェアシステムにおいて各アプリケーションプログ
ラミングインタフェース（ＡＰＩ）に関して一度だけ実
行され、各ＡＰＩについて対応ＡＰＩイタンフェースを
生成する。発明の１つの環境において、構築用ツール６
１は、ソフトウェアシステムの各ＡＰＩに個別に作用す
る。

【００４４】上述したように、ＡＰＩは、一般にユーザ
ーから受け取られることができるコマンドに対応するシ
ステム内の高水準のソフトウェアファンクションであ
る。図２の例では、ＣＡＤシステムは、箱を挿入し、そ
して、立体の重量を計算するファンクションを実行する
ＡＰＩを有している。概念的には、各ＡＰＩについて構
築用ツール６１によって生成される結合ＡＰＩは、２つ
の役割を実行する。第１に、製品デザインの生成に関し
て対応ＡＰＩが、ソフトウェアシステムに対して実行す
るのと同じ役割を実行する。例えば、箱を挿入するため
の図２の例におけるＡＰＩに対して生成される結合ＡＰ
Ｉは、製品デザイン内に箱を入れて、ＣＡＤシステム上
でそれを表示するファンクションを実行する。第２に、
各結合ＡＰＩは、対応するＡＰＩによって行われる動作
を依存関係グラフに表示する役割を実行して、ＡＰＩに
よって生成されるデザインの一部が、それらがどのよう
に製品デザインの他の様相に関連づけられるかを理解で
きるようにする。

【００４５】各結合ＡＰＩは２つの役割を実行するの
で、構築用ツール６１は、ただ単に各ＡＰＩに対する２
つのファンクション、言い換えれば各役割を実行する１
つのファンクションを生成できるだけである。しかしな
がら、本発明の好ましい実施の形態では、構築用ツール
６１は、結合ＡＰＩプロセッサとして参照され、各結合
ＡＰＩのグラフ構成を生成するための一般的ファンクシ
ョンと、製品デザインのデザインアクションを遂行する
役割を実行する各結合ＡＰＩ用の１つのソフトウェアフ
ァンクションに対する呼び出しを決定するマクロコール
を生成する。結合ＡＰＩプロセッサに供給される引数
は、結合ＡＰＩプロセッサを呼び出す結合ＡＰＩの名称
であり、その結合ＡＰＩに対する引数である。構築用ツ
ール６１は、また、各結合ＡＰＩ用のソフトウェアエン
ティティ（後述する）を作成し、ソフトウェアエンティ
ティは、前記結合ＡＰＩ用に構築されるグラフエンティ
ティのトポロジィと、結合ＡＰＩにより行われるデザイ
ンアクションを表示するためにグラフ内に生成されるオ
ペレータにより表示されるファンクションを記述する。

【００４６】図４にグラフィカルに示すように、構築用
ツール６１は、ソフトウェア内で固有のＡＰＩ６２のフ
ァンクションテンプレートに作用するとともに、各ＡＰ
Ｉに対して結合ＡＰＩ６３を生成する対応結合ＡＰＩ６
６のファンクションテンプレートに作用する。各ＡＰＩ
と結合ＡＰＩとのファンクションテンプレートは、ファ
ンクション名、その引数と結果のデータタイプ、そして
引数名と結果名とを定義する。構築用ツールによって生
成された各結合ＡＰＩは、３つの構成要素、即ち、結合
ＡＰＩマクロコール６５、結合ＡＰＩデータ構成要素６
７、そして結合ＡＰＩのオペレータエバリュエータ６９
を含む。以下に、さらに詳細に説明するように、構築用
ール６１が、各々に関して結合ＡＰＩを生成するために
新しいソフトウェアシステムのＡＰＩ上で実行されたと
き、システムのユーザーインタフェースは、また、各ユ
ーザーコマンドが対応ＡＰＩを直接呼び出すというより
もむしろ、その対応結合ＡＰＩを呼び出すように、修正
される。このように、ラッパーが、本発明の付加的な能
力がユーザーにわかりやすい方法で供給されるようにソ
フトウェアシステム内の各ＡＰＩの周囲に供給される。

【００４７】インタラクティブデザインセッション中に
ユーザーコマンドによって呼び出されたとき、各結合Ａ
ＰＩは、順次に結合ＡＰＩプロセッサ７１（図５）を呼
び出す。プロセッサ７１は、最初に、コマンドによって
行われるデザインアクションを表示するオペレータを含
むために依存関係グラフを更新し、そして製品デザイン
にデザインアクションを実際に行うファンクションが確
実に呼び出されるようにする。結合ＡＰＩ６３の構成要
素の各々によって実行される役割は結合ＡＰＩプロセッ
サ７１の役割と密接に結びつくので、本発明のこれらの
様相を図５を参照しながら説明する。図５は、ＡＡＰＩ
構成要素６３の結合ＡＰＩプロセッサ７１とＣＡＤユー
ザーインタフェース３７との関係を図示している。

【００４８】プロセッサ７１を呼び出す各結合ＡＰＩ
は、特定数のデータオブジェクトと、各々がデータオブ
ジェクトの１つのオペレータに対する関係を定義する対
応する数のリレーションと、を有するオペレータによっ
て依存関係グラフに表示されている。結合ＡＰＩプロセ
ッサは、依存関係グラフの各オペレータ、リレーショ
ン、そしてデータオブジェクトを表示するためにソフト
ウェアエンティティを作成する。このような関係におい
て、ソフトウェアエンティティという言葉は、例えばＣ
＋＋のようなオブジェクト指向プログラミング言語のオ
ブジェクト、あるいは、例えばＣのようなプログラミン
グ言語の構造であるようなソフトウェアプログラムによ
って作成されるエンティティを示すことを意図する。

【００４９】結合ＡＰＩプロセッサ７１は、ＡＡＰＩに
よって実行される特別なデザインアクションにかかわり
なく、同じ方法で全ての結合ＡＰＩからコールを扱う点
において一般的である。例えば、図２に示される依存関
係グラフを参照すると、結合ＡＰＩプロセッサ７１は、
同じ方法で箱の挿入とその重量の計算を夫々表示して、
データオブジェクトとリレーションにそれらを依存関係
グラフ内で単に結び付けるオペレータ７と１９とを取り
扱う。

【００５０】前述のソフトウェアシステムの各ＡＰＩに
ついて構築ツール６１を実行して各ＡＰＩに関する結合
ＡＰＩを生成するのに加え、本発明の統合処理は、ま
た、ユーザーから受け取った各コマンドに応答して、Ａ
ＰＩを直接呼び出すというよりもむしろ、インタフェー
ス３７が対応結合ＡＰＩを呼び出すように、システムの
ユーザーインタフェース３７を修正する。特に、ユーザ
ーインタフェースによって呼び出されるのは、各結合Ａ
ＰＩ６３のマクロコール構成要素６５である。ユーザー
インタフェースは、受け取られたコマンドに含まれるす
べてのデータ引数を結合ＡＰＩに渡す。図２に示された
具体例に関し、ユーザーが箱を挿入するためのコマンド
を入力したとき、ユーザーインタフェースは、そのコマ
ンドに対応した結合ＡＰＩを呼び出して、これらを箱の
長さ、幅、高さと中心点に関するコマンド内で受け取ら
れたデータ引数に渡す。ユーザーインタフェースによっ
て結合ＡＰＩのマクロコール６５が呼び出されると、そ
れは、順次結合ＡＰＩプロセッサ７１（図５）を呼び出
し、プロセッサに、ファンクション（例えば、挿入箱、
重量の計算）を確認するのに使われるマクロ名と同様
に、マクロ６５を呼び出したコマンドと共に受け取られ
た引数の順序リストを含むデータストリングをプロセッ
サに渡す。

【００５１】結合ＡＰＩは一般的な依存関係グラフ構築
用であり、何らかの特別な結合ＡＰＩを扱うために特に
デザインされているわけではないので、呼び出すマクロ
名と命令データのリストを含むストリングは、呼び出す
マクロに基づいて依存関係グラフが更新される方法を指
定するには不十分である。このように、プロセッサ７１
は、呼び出すストリング内のマクロ名を使ってそのデー
タ構成要素６７から呼び出すＡＡＰＩ６３についての付
加的な情報を受け取る。各結合ＡＰＩのデータ構成要素
６７は、対応するＡＰＩに関する入力データオブジェク
ト数、これらのオペレータとの夫々のリレーション、そ
して結果としてのデータオブジェクトのリレーション数
を定義する原文情報を含む。ソフトウェアシステムを立
ち上げるときはいつでも、そしてデザインセッションの
開始前に結合ＡＰＩプロセッサ７１は、（データ構成要
素６５によって供給された）各結合ＡＰＩ６３を記述す
るＡＳＣＩＩデータファイルを解読して、ＡＡＰＩ名に
よって刻まれた各ＡＡＰＩに関するエントリーを含むハ
ッシュテーブル７３を生成する。インタラクティブデザ
インセッション中にＡＡＰＩによって呼び出されると、
プロセッサ７１は、ハッシュテーブル７３内の対応エン
トリーを使って、呼び出すＡＡＰＩを依存関係グラフに
表示するオペレータ、リレーションとデータオブジェク
トを作成する。各結合ＡＰＩのためのハッシュテーブル
エントリーはソフトウェアエンティティの形態で、ＡＡ
ＰＩの入力データオブジェクトの数、ＡＡＰＩのオペレ
ータに対する夫々のリレーション、そしてＡＡＰＩの出
力データオブジェクトのリレーションを確認する。

【００５２】III.依存関係グラフの作成 結合ＡＰＩプロセッサ７１は、デザインセッション中に
マクロコール６５によって呼び出されると、プロセッサ
７１は、呼び出すマクロ名を使って、呼び出すＡＡＰＩ
の構造特性に関係する情報を含むソフトウェアエンティ
ティを出力するハッシュテーブル７３にインデックス化
する。例えば、図２に関連して記載されるような箱に挿
入するためのファンクションに関係するＡＡＰＩからの
呼び出しに関して、ハッシュテーブル７３から出力され
た対応ソフトウェアエンティティは、マクロ名に沿って
プロセッサ７１を通過したデータの命令リストにおける
第１の引数が箱の長さであり、第２の引数が幅であり、
第３の引数が高さであり、そして第４の引数が箱の中心
点であることを示す情報を含む。結合ＡＰＩプロセッサ
７１は、ハッシュテーブル７３から出力されたソフトウ
ェアエンティティを照会してプロセッサを呼び出した特
別のＡＡＰＩマクロのために依存関係グラフが更新され
る方法を判定する。このファンクションはハッシュテー
ブルから出力されたソフトウェアエンティティに、呼び
出されたＡＡＰＩに関係づけられている入力の数を尋ね
る。次に、結合ＡＰＩプロセッサ７１は、そのエンティ
ティに、命令データのリストの第１の引数に関係する名
前は何であるかを尋ね、そして（例えば、長さ、幅、高
さのような）名前を使ってオペレータに対するデータオ
ブジェクトに対するリレーションを定義する。結合ＡＰ
Ｉプロセッサ７１は、入力と出力のデータオブジェクト
のすべてのリレーションが定義されるまでこの方法を続
行する。プロセッサ７１は、プロセッサ７１に渡された
情報のストリングに含まれる呼び出すマクロ名からオペ
レータ名を引き出す。

【００５３】前述したように、結合ＡＰＩプロセッサは
依存関係グラフのオペレータ、リレーション、そしてデ
ータオブジェクトの夫々を表示するためのソフトウェア
グラフエンティティを作成する。各オペレータ（例え
ば、図２の例における挿入箱と重量の計算）のために作
成されたグラフエンティティは、リレーションを表示す
るグラフエンティティに対するポインタのリストを含ん
でいる。各ポインタは、リレーションの１つを表示する
グラフエンティティをストアするメモリ場所(location)
の アドレスを含む。各リレーションのために作成され
たグラフエンティティは、リレーション名、そして、グ
ラフ内のリレーションに接続されたデータオブジェクト
を表示するグラフエンティティをストアするメモリ場所
のアドレスを含むポインタを含む。最後に、依存関係グ
ラフにデータオブジェクトを表示する各グラフエンティ
ティは、データオブジェクトに対応する引数値がストア
されたメモリ場所に対するポインタを含む。以上から、
ＡＡＰＩに対するオペレータ、リレーション、そしてデ
ータオブジェクトの構造的な関係を判定するために結合
ＡＰＩプロセッサ７１によって照会される各ＡＡＰＩの
ためのソフトウェアエンティティのハッシュテーブルを
設けたことにより、システム内の各ＡＰＩのために個別
のグラフ処理ファンクションが生成されることが要求さ
れるというよりはむしろ、ソフトウェアシステムに付け
加えられた単一の付加的なファンクション（例えば、プ
ロセッサ７１）のみによって依存関係グラフの作成が達
成できることが理解される。

【００５４】IV. 依存関係グラフの評価の概略 結合ＡＰＩマクロコールに応答して依存関係グラフを更
新するのに加えて、結合ＡＰＩプロセッサは、また、呼
び出す結合ＡＰＩによって指定された製品デザインにデ
ザインアクションを行うために、新しく作成された各オ
ペレータ評価を開始する。依存関係グラフの各オペレー
タを表示するソフトウェアエンティティは、そのマクロ
コールがオペレータの作成という結果になるＡＡＰＩの
オペレータエバリュエータ６９（図５）に関係する２つ
のポインタを含む。第１のポインタは、オペレータエバ
リュエータ６９がストアされるライブラリを指し、そし
て第２のポインタはオペレータエバリュエータであるラ
イブラリ中のファンクション名を指す。このように、結
合ＡＰＩプロセッサ７１は、ＡＡＰＩからの呼び出しに
応答して依存関係グラフを更新した後、プロセッサ７１
は、それ自身の評価のために新しく作成されたオペレー
タを呼び出す。この処理は図５に図示されており、結合
ＡＰＩプロセッサ７１が、それ自身を評価するために図
２の重量計算オペレータ１９を呼び出しているのが示さ
れる。

【００５５】前述したように、構築用ツール６１（図
４）によって作成された各ＡＡＰＩは、ソフトウェアシ
ステム内の固有ＡＰＩの周囲のラッパーである。各ＡＡ
ＰＩのためのオペレータエバリュエータ６９は、周囲を
囲まれた固有ＡＰＩ名を呼び出すファンクションであ
る。呼び出されたとき、オペレータエバリュエータ６９
は、依存関係グラフ内のエバリュエータオペレータに接
続された入力データオブジェクトから引数を収集し、こ
れらの引数を固有のＡＰＩによって予想される形式にフ
ォーマットし、更に、望ましいデザインファンクション
を完成させるための正しい順序の引数を用いてＡＰＩを
呼び出す。再び図２を参照すると、箱を挿入するための
ＣＡＤシステム内の固有ＡＰＩは、例えば、渡されるデ
ータ引数が長さ、幅、高さ、そして中心として定められ
ることを期待する“CV＿INSERT＿BOX(l,w,h,center)"と
命名される。ユーザーが、長さを２とし、幅を３とし、
高さを４とし、そして中心座標を（０，０）として指定
する引数により箱を挿入するコマンドを入力する場合、
ユーザーインタフェースはCV＿INSERT＿BOX ＡＰＩの周
囲を囲まれたＡＡＰＩを呼び出して、依存関係グラフ内
にデータオブジェクト３〜５と１７、リレーション９〜
１２と１５、そしてオペレータ７を作成する。ＡＡＰＩ
プロセッサ７１がオペレータ７にそれ自身を評価するよ
うに命令すると、結合ＡＰＩのオペレータエバリュエー
タ６９（図５）は、データオブジェクト３〜５にストア
された引数を収集して命令し、そして“CV＿INSERT＿BO
X(2,3,4,0,0)" として固有のＡＰＩを呼び出す。この呼
び出しは、本発明のソフトウェアツールが固有ＡＰＩの
周囲のラッパーを作成するためにシステムにインストー
ルされていない場合には、ソフトウェアシステムのユー
ザーインタフェース３７により直接に行われるものに一
致する。

【００５６】プロセッサ７１がそれ自身を評価するため
にグラフオペレータを呼び出すとき、対応するオペレー
タエバリュエータ６９（図５）にとって、製品デザイン
に指定されたデザインアクションを行うために呼び出さ
れる固有ＡＰＩにより要求される順序の引数を収集して
構成することは、直截的処理である。各ＡＡＰＩのため
のオペレータエバリュエータ６９は、呼び出される対応
固有ＡＰＩの名前を含むだけでなく、ＡＰＩに供給され
る引数の名前と順序をも含む。例えば、図２に示された
オペレータ７を評価するとき、対応ＡＡＰＩエバリュエ
ータ６９は、まず、オペレータ７に、箱の長さを表示す
る引数を供給するように要求する。オペレータ７を表示
するグラフエンティティはそれ自身を確認するためにそ
のリレーションの夫々を要求するファンクションを実行
する。一旦、長さのリレーションが確認されると、オペ
レータ７に表示するグラフエンティティは、長さのリレ
ーション９に表示するグラフエンティティに箱の長さを
定義する引数を供給するように要求する。そして、長さ
のリレーション９に表示するグラフエンティティは、デ
ータオブジェクト３に表示するグラフエンティティにそ
の引数を渡すことを要求し、一旦、引数が受け取られる
と、順次、引数を、オペレータエバリュエータ６９に引
数を返す挿入箱オペレータ７を表示するグラフエンティ
ティに渡す。エバリュエータ６９は、同じ方法で残りの
引数を要求して受け取る。一旦、すべての引数が収集さ
れると、オペレータエバリュエータは、引数の順序を指
定するそれ自身の呼び出しにより、製品デザインに適当
なアクションを行うために、固有ＡＰＩ“CV＿INSERT＿
BOX"を呼び出す。

【００５７】固有ＡＰＩが呼び出されると、これは渡さ
れた引数によりデザインアクションを実行し、更に、順
次結果を、評価されたオペレータを表示するグラフエン
ティティに渡すオペレータエバリュエータに戻す。そし
て、評価されたオペレータを表示するグラフエンティテ
ィは、結果をオペレータの出力リレーションを表示する
グラフエンティティに渡し、このグラフエンティティに
より、順次結果を、そのデータオブジェクトを表示する
グラフエンティティに渡し、このグラフエンティティ
は、最終的にデータオブジェクトにより指示されたメモ
リ場所にその結果をストアする。このように、他のオペ
レータに対して引数としての役割を実行できる評価され
たオペレータの結果は、依存関係グラフに入力される。

【００５８】１．拡張コマンドのフォーマット適応性 本発明の１つの実施の形態では、１つ又はそれ以上のオ
ペレータエバリュエータ６９（図４と５）は、一定のデ
ザインアクションがユーザーのレベルで定義できる方法
に関するソフトウェアシステムの適応性を増大させる能
力を供給される。例えば、上記の例は箱の長さ、幅、高
さと中心の座標位置によって定義されるような箱を示し
ているが、箱の角の位置だけを定義するような、ユーザ
ーが箱を定義できる他の方法があることがわかる。これ
は、デザイナーによって行う方法が具体的な長さ、幅と
高さによるよりは、むしろ、この方法で箱を定義するこ
とがより利点があるような一定のデザイン環境には望ま
しい。従来、ＣＡＤシステムが、箱がその角によって定
義される固有ＡＰＩを含まない場合、ユーザーは、この
方法で箱を定義するコマンドを供給されない。しかしな
がら、本発明のオペレータエバリュエータファンクショ
ンは、ユーザーが利用できるコマンドのフォーマットに
増大した適応性を供給できる固有ＡＰＩの周囲にラッパ
ーを供給する。例えば、本発明のツールが走るＣＡＤシ
ステムが、長さ、幅、高さ、そして中心点に関して定義
された箱の作成を供給するだけである場合、本発明のオ
ペレータエバリュエータファンクションはユーザーに、
箱の角によるような付加的な方法で箱を定義させること
ができる。

【００５９】本発明の好ましい実施の形態では、依存関
係グラフとそこから生成されたコンピュータプログラム
が、デザインセッション中にユーザーによって行われる
デザインアクションと非常に密接に相関する方法で製品
デザインの構造的依存関係を表示する。それゆえに、付
加的なコマンドフォーマットを供給する本発明の特徴が
使われたとき、依存関係グラフは、ユーザーによって指
定された方法で作成され、ストアされる。例えば、ユー
ザーが箱の角によって箱を定義するために能力が供給さ
れ、そしてユーザーがこの能力を開発すれば、箱を挿入
するデザインアクションを表示する依存関係グラフオペ
レータは箱の角によって箱を定義するデータオブジェク
トとリレーションとを含むことになる。オペレータがそ
れ自身を評価するために呼び出され、順次、そのＡＡＰ
Ｉオペレータエバリュエータ６９（図５）を呼び出すと
き、エバリュエータは依存関係グラフ内のオペレータの
表示をソフトウェアシステムの固有ＡＰＩを呼び出すた
めに要求される形態に変換する。上記の箱を挿入する例
を使うと、挿入箱オペレータに関連するオペレータエバ
リュエータは前述の方法で箱の角を定義する引数を収集
し、それらの引数を処理して、この方法で調整され配列
される引数にのみ作用する固有挿入箱コマンドに渡され
る長さ、幅、高さ、そして中心座標の引数を生成する。
ユーザーに供給される増大した適応性は、新しい固有Ａ
ＰＩの作成を必要としない。なぜならば、適応性は、固
有ＡＰＩ周囲の本発明によって供給されるラッパーによ
って遂行されるからである。

【００６０】本発明の好ましい実施の形態において、ユ
ーザーに供給されるコマンドフォーマットの適応性が各
コマンドに対応するＡＡＰＩオペレータエバリュエータ
６９で遂行されるにもかかわらず、本発明のこの特徴は
他の方法で遂行できることがわかる。例えば、ユーザー
から入力されるフォーマットと固有ＡＰＩによって要求
されるフォーマットとの間の変換は、ＡＡＰＩデータ構
成要素で実行して、依存関係グラフが固有ＡＰＩによっ
て予想されるフォーマットで生成できるようにする。フ
ォーマット変換がこの方法で実行されたとき、ＡＡＰＩ
オペレータエバリュエータはどんなフォーマット変換の
実行をも必要としない。

【００６１】V.依存関係グラフへの加入を反映するため
のソフトウェアアプリケーションエンティティの更新 ソフトウェアシステムの各固有のＡＰＩの回りのＡＡＰ
Ｉラッパーを生成するのに加えて、本発明は、また、プ
ロダクトデザインを表示するソフトウェアシステムによ
って生成されたソフトウェアアプリケーションエンティ
ティを修正して、各アプリケーションエンティティが、
依存関係グラフに加入しているかどうか、また、その加
入している場所をわかるようにする。例えば、本発明が
インストールされたソフトウェアシステムがＣＡＤシス
テムであれば、これにより生成されたアプリケーション
エンティティは、製品デザインを表示する箱、円柱、及
び他の構造を含むことができる。例えば、図２の例にお
いて、箱を挿入するためのオペレータ７の評価の結果
は、箱を表示するアプリケーションエンティティであ
り、その記述は、本来的に箱を定義するために使われる
引数（長さ、幅、高さと中心点）を含んでいる。

【００６２】前述のように、本発明は、オブジェクト指
向プログラミング言語で実施されるのが好ましい。他の
プログラミング言語が本発明を実施するのに使用される
ことはできるが、オブジェクト指向プログラミング言語
は、各アプリケーションエンティティが依存関係グラフ
に加入しているかどうか、また加入している場所を理解
できるように、デザインセッション中にソフトウェアシ
ステムによって作成されたアプリケションエンティティ
に簡単な修正ができる能力を有する点で有利である。オ
ブジェクト指向プログラミング言語により、アプリケー
ションエンティティは、共通のクラスで定義されるいく
つかの共通の特徴を有することができる。図２の依存関
係グラフを参照すると、重量計算オペレータ１９は、立
体の体積に密度を乗算することにより立体の重量を計算
する。図２において操作される具体的な立体は、円柱、
球等を含むより広いクラスの立体の１つの箱である。オ
ブジェクト指向プログラミング言語で様々なタイプのア
プリケーションエンティティを定義する場合、階層的な
構造を使用できる。例えば、立体クラス（例えば、体積
に密度を乗算することにより立体の重量を提供するファ
ンクション）に属する特定のタイプのアプリケーション
エンティティのすべてに共通のファンクションと指標
は、立体のクラスの定義において一旦定義できる。その
クラス内のさらに多くの特定のアプリケーションエンテ
ィティ（たとえば箱、円柱、球等）の夫々の定義は、そ
の立体クラスの参照を含み、ここから受け継ぐ。このよ
うに、立体クラスの定義に提供されるファンクションと
指標は、クラスから受け継いだアプリケーションエンテ
ィティの夫々の定義の一部を形成し、アプリケーション
エンティティのより特定のクラスの各々の定義において
複製される必要がない。例えば、箱のクラスの各アプリ
ケーションエンティティは、箱の重量を決定する特定の
ファンクションなしに、この決定の能力を有する。なぜ
ならば、そのファンクションは、箱のクラスが受け継い
だものから、立体の定義において定義されるからであ
る。

【００６３】オブジェクト指向プログラミング言語に役
に立つ受け継いだ能力を使い、各アプリケーションエン
ティティが依存関係グラフに加入しているのであれば、
加入している場所を決定するのに必要なファンクション
と指標は、結合変数クラスとして参照される単一のクラ
スに供給でき、このクラスから、製品デザインの部分を
表示するためにソフトウェアシステムによって作成され
た各アプリケーションエンティティに受け継がれる。ユ
ーザーによってデザインに入力された各引数は、また、
結合変数クラスから受け継ぐアプリケーションエンティ
ティとして定義される。結合変数クラスは、依存関係グ
ラフの特定のデータオブジェクト（例えば、図２のデー
タオブジェクト３〜６，１７，２５と２９）に対するポ
インタを確認するためのフィールドを含む。このよう
に、製品デザインの部分を表示するため、あるいはユー
ザーから入力された引数を表示するためのソフトウェア
システムにより作成されたアプリケーションエンティテ
ィは、もしあれば、依存関係グラフ内でそれを表示する
特定のデータオブジェクトを指し示すこのポインタを使
用する。ポインタフィールドが特定のアプリケーション
エンティティにない場合、アプリケーションエンティテ
ィが依存関係グラフの対応するデータオブジェクトを割
り当てられてないため、グラフにまだ加入していないこ
とを示す。もし、ポインタフィールドが値を持っている
のであれば、アプリケーションエンティティは指し示さ
れたデータオブジェクトによりグラフ中に表示される。

【００６４】結合変数クラスは、また、クラスから受け
継いだアプリケーションエンティティの各々に渡される
２つのファンクションを供給する。第１のファンクショ
ンは、アプリケーションエンティティが依存関係グラフ
に付け加えられたとき、上記ポインタフィールドを、対
応するデータオブジェクトの場所を確認する特定の値に
セットする。第２のファンクションは、アプリケーショ
ンエンティティが依存関係グラフの中のどこに存在して
いるかが問われたとき、ポインタの値を検索し、その値
を戻す。以上、述べたように、ソフトウェアプログラム
によって生成されたアプリケーションエンティティに加
えて、ユーザーによってシステムに入力された引数は、
また、結合変数クラスに依存するアプリケーションエン
ティティとして表示される。それゆえに、データオブジ
ェクトとして依存関係グラフに表示される各アプリケー
ションエンティティは、結合変数クラスに依存するの
で、各アプリケションエンティティは、データオブジェ
クトポインタフィールドとポインタの値をセットして検
索するファンクションを含む。

【００６５】結合変数クラスによりアプリケーションエ
ンティティの夫々に供給される能力は、図２に示される
例を参照すると、以下の方法でグラフの作成とマネージ
メントとに使われる。まず、ユーザーは、箱を挿入する
ためのコマンドを入力する。このコマンドのエントリー
により、ＡＡＰＩ６３（図５）が上述された方法で結合
ＡＰＩプロセッサ７１を呼び出すことになる。ＡＰＩプ
ロセッサ７１を呼び出す際に、ＡＡＰＩマクロコール６
５は、プロセッサに、呼び出すマクロに関連する引数、
例えば、箱の長さ、幅、高さ、そして中心位置を渡す。
これらの引数の各々は、結合変数クラスに依存するアプ
リケーションエンティティの形態で渡される。このよう
にして、依存関係グラフ上のマクロコールの影響を決定
するために、結合ＡＰＩプロセッサ７１は、各引数がグ
ラフに表示されているか否か、そしてグラフのどこに表
示されているのかを決定するために、引数を表示するア
プリケーションエンティティの夫々に照会する。引数は
グラフに前もって表示されていないため、引数の１つを
表示するアプリケーションエンティティの夫々はそのデ
ータオブジェクトポインタに零の値を含む。これらの零
のポインタを読み出すと、ＡＰＩプロセッサ７１は、各
引数のためのデータオブジェクトを表示する新しいグラ
フエンティティを作成し、引数アプリケーションエンテ
ィティに対し、新しく作成されたグラフエンティティの
メモリ場所にそのデータオブジェクトポインタをセット
することを命令する。そして、ＡＰＩプロセッサは、上
記方法で、箱を挿入するためのオペレータ７とリレーシ
ョン９〜１２とを表示するグラフエンティティを作成す
る。加えて、ＡＰＩプロセッサ７１は、リレーション１
５と結果としてのデータオジェクト１７とを表示するグ
ラフエンティティを作成する。そして、プロセッサ７１
は、オペレータ７に、それ自身を評価することを命じ
て、そのＡＡＰＩオペレータエバリュエータ６９の呼び
出しを行う。上述の方法でオペレータエバリュエータ
は、挿入箱の固有ＡＰＩを呼び出し、エバリュエータ
に、作成した箱を表示するアプリケーションエンティテ
ィを戻す。そして、オペレータエバリュエータ６９は、
箱を定義するアプリケーションエンティティのデータオ
ブジェクト１７のためのメモリ場所を指し示すデータオ
ブジェクトポインタを更新することによって、依存関係
グラフへの加入に関する情報で箱を定義するアプリケー
ションエンティティを供給する。

【００６６】図２に関する例に続いて、ユーザーから受
け取られた次のコマンドは箱の重量を計算することであ
る。このコマンドに応答して、対応ＡＡＰＩマクロコー
ル６５は、結合ＡＰＩプロセッサ７１に、例えば、箱を
定義するアプリケーションエンティティのような、重量
計算ファンクションが実行されるための引数を渡す。Ａ
ＰＩプロセッサ７１は、このアプリケーションエンティ
ティに、依存関係グラフのそれに対応するデータオブジ
ェクトを確認するポインタの値を特定することを要求す
る。このようなデータオブジェクトは前もって作成され
るので、データオブジェクト１７のアドレスはプロセッ
サ７１に戻される。そして、プロセッサ７１は、重量計
算オペレータ１９とリレーション２１を表示するグラフ
エンティティを生成することにより依存関係グラフを更
新する。リレーション２１を表示するグラフエンティテ
ィでは、ａ′ポインタが、データオブジェクト１７を表
示するグラフエンティティをストアするメモリ場所のア
ドレスを含むように更新される。このように、挿入箱オ
ペレータ７上の重量計算オペレータ１９の依存関係は依
存関係グラフに反映される。結合ＡＰＩプロセッサ７１
は、また、上記方法で依存関係グラフを完成するため
に、その結合リレーションと同様に、新しいデータオブ
ジェクト２５と２９とを作成する。

【００６７】VI．依存関係グラフの作成と評価のための
結合ＡＰＩプロセッサルーチン 依存関係グラフに加入するか否か、そしてどこに加入す
るのかを理解するための各引数とアプリケーションエン
ティティの上記能力は、ＡＡＰＩマクロによって呼び出
されたときに、プロセッサ７１が実行するステップを示
す図６に示された方法により依存関係グラフを作成する
間、結合ＡＰＩプロセッサ７１によって利用される。ま
ず、ステップ４０１では、結合ＡＰＩプロセッサ７１
が、グラフエンティティを作成して、呼び出すマクロの
デザインアクションに対応する依存関係グラフにおける
オペレータを表示する。そして、ステップ４０３では、
本方法は、処理のためのマクロの引数の１番目を選択す
る。上述したように、各引数は、データオブジェクトに
より依存関係グラフに、引数が表示されているのか、そ
してどこに表示されているのかを示すポインタフィール
ドを含むアプリケーションエンティティとして結合ＡＰ
Ｉプロセッサ７１に渡される。

【００６８】ステップ４０５では、本方法は、選択され
た引数のデータオブジェクトポインタを読み込んで、デ
ータオブジェクトポインタがないのかどうかを判定し、
データオブジェクトポインタがないときは、本方法は、
ステップ４０７に進み、依存関係グラフの新しいデータ
オブジェクトを表示するためにグラフエンティティが作
成される。そして、引数を表示するアプリケーションエ
ンティティが更新されて、そのデータオブジェクトポイ
ンタが新しく作成されたデータオブジェクトを指し示
す。ステップ４０７でデータオブジェクトの作成が行わ
れたあと、あるいはステップ４０５でデータオブジェク
トがすでに引数用に存在していると判定される場合、本
方法は、ステップ４０９に進み、ステップ４０１で作り
出されたデータオブジェクトとオペレータとの間にリレ
ーションが作成される。ステップ４１１では、処理され
ている引数が、呼び出すマクロに関連する最後の引数で
あるかどうかついて判定がなされ、そしてそうではない
とき、本方法は、ステップ４０３に戻って処理するため
の他の引数を選択する。このように、本方法は、ステッ
プ４０１で作成されたオペレータに結合される入力リレ
ーションとデータオブジェクトを作成し、それらをオペ
レータに接続するためにステップ４０３〜４１１を実行
する。

【００６９】ステップ４１１で、最後の引数が処理され
たと判定されたときは、本方法は、ステップ４１３と４
１５に進み、結果としてのデータオブジェクトとリレー
ションとが、夫々、オペレータのために作成される。そ
して、本方法は、ステップ４１７に進み、結合ＡＰＩプ
ロセッサ７１が、オペレータにそれ自身を評価すること
を要求する。データの順序リストとともに、対応する固
有ＡＰＩを呼び出すＡＡＰＩオペレータエバリュエータ
６９によって実行される評価は、アプリケーションエン
ティティの形態で結合ＡＰＩプロセッサ７１に結果を戻
す。ステップ４１８では、結果は、ステップ４１３で作
成された結果としてのデータオブジェクトに関連づけら
れるが、結果を定義するアプリケーションエンティティ
でデータオブジェクトポインタを更新する。最後に、ス
テップ４１９では、プロセッサ７１は、結果を定義する
アプリケーションエンティティを、その呼び出しが方法
を開始させたマクロに戻す。

【００７０】VII ．依存関係グラフの評価 図６の方法のステップ４１７においてオペレータの評価
をプロセッサ７１が要求するのに応答して、すべてのオ
ペレータに一般的な、そして、評価されたオペレータの
オペレータエバリュエータ６９を呼び出す前に、オペレ
ータによって要求される引数のすべてが更新されること
を保証する引数の収集とオペレータの評価のルーチンが
呼び出される。引数の収集ルーチンのステップは図７に
示されている。初めに、評価されたオペレータに関係づ
けられている第１の引数が処理のためにステップ５０１
で選択され、この引数が「同調しない」（out of sync
h)か否かについてステップ５０２にて判定がなされる。
「同調しない」の語句は、変更されてはいるものの、ま
だ再評価されていない少なくとも１つのグラフエンティ
ティに、引数を表示するデータオブジェクトが依存して
いることを示すために使われる。このように、引数が同
調しない場合、本方法は、ステップ５０３に進んで、引
数の更新が要求される。ステップ５０３で更新が要求さ
れた後、あるいは引数が同調していることがステップ５
０２において判定された場合、本方法は、ステップ５０
４に進み、評価されるオペレータのための引数のすべて
が収集されたかどうかに関する判定がなされる。収集さ
れていないと判定されたときは、本方法は、ステップ５
０１に戻り、新しい引数が収集されるために選択され
る。このように、本方法は、オペレータのための引数の
すべてが収集されるまで、また、同調しなかった引数が
更新されるまで、ステップ５０１〜５０４を実行する。
そして、本方法は、ステップ５０５に進み、評価される
オペレータに対応するオペレータエバリュエータ６９が
呼び出される。

【００７１】オペレータエバリュエータルーチンのステ
ップは、図８に示される。初めに、評価されたオペレー
タに関連する第１の引数がステップ５０６にて選択さ
れ、そして、ステップ５０７にて、選択された引数に関
係する値が、依存関係グラフに引数を表示するデータオ
ブジェクトポインタから検索される。本方法は、それか
ら、ステップ５０７へと進み、引数の値が、オペレータ
エバリュエータによって呼び出される固有のＡＰＩによ
って要求されるデータ型にキャストされる。依存関係グ
ラフの各データオブジェクトは一般的であり、それが指
し示す引数のフォーマットに関する情報を持ってはいな
い。例えば、引数は整数、箱を定義するアプリケーショ
ンエンティティ、円柱を定義するアプリケーションエン
ティティ、等とすることができる。このため、オペレー
タエバリュエータがＡＰＩを呼び出す前に、ＡＰＩによ
って要求されるデータ型に引数をキャストする。

【００７２】ステップ５０９では、ＡＰＩに渡される引
数のすべてが処理されたかいなかに関する判定がなさ
れ、処理されていないとき、本方法は、ステップ５０６
に戻り、他の引数が処理されるために選択される。この
ように、本方法は、オペレータに関係する引数のすべて
を処理するまで、ステップ５０６〜５０９を実行する。
すべての引数が処理されたとき、本方法は、ステップ５
１０へと進み、引数が、呼び出される固有のＡＰＩによ
って要求される方法でフォーマットされる。上述したよ
うに、本発明の１つの実施の形態において、ＡＡＰＩの
ためのオペレータエバリュエータは、コマンドがフォー
マットされることのできる方法で付加的なオプションを
ユーザーに供給する。ユーザーコマンドとそれに対応す
る依存関係グラフのオペレータとがＡＰＩとは異なって
フォーマットされる場合、本方法は、ステップ５１０に
おける引数をＡＰＩによって要求される引数に再フォー
マットする。引数がフォーマットされた後、本方法は、
ステップ５１１に進み、オペレータに対応する固有のＡ
ＰＩが呼び出され、要求する方法で整理された引数が渡
される。固有ＡＰＩは、オペレータエバリュエータに、
ＡＰＩによって行われたデザインアクションの結果を表
示するアプリケーションエンティティを戻す。ステップ
５１２では、オペレータエバリュエータは、図６のステ
ップ４１３のオペレータの結果のために作成されたグラ
フエンティティのデータオブジェクトポインタを更新す
る。

【００７３】VIII．非正算(Non-directed Operations)
の表示 以下の説明は、正算(directed)オペレータにより本発明
の依存関係グラフに記述される正算に単に関係する。正
算オペレータは、１つ又はそれ以上の入力から１つの出
力へと、１つの方向への流れを有する。しかしながら、
本発明は、非正算を支援するソフトウェアシステムに使
用されることもできる。例えば、Ａ＝Ｂ＊Ｃという関係
を表示するコマンドが実行されることもできる。これが
正算であった場合、ユーザーは、ＢとＣとの値を編集で
きるだけであり、正算は、Ａという適当な値を生み出
す。しかしながら、コマンドが、非正算であった場合、
ユーザーは、二者択一的にＡの値を指定するか、システ
ムにＢとＣとの値を決定させてこれらの積がＡの値に等
しくなるようにする。非正算は、そのパラメータのいく
つかからの変更を伝えることができ、入力と出力の完全
な概念はない。

【００７４】本発明は、単一の依存関係グラフでの正算
と非正算の両方を表示する能力を提供し、正算は、正算
オペレータにより表示され、非正算は、非正算オペレー
タにより表示される。以下に述べられるいくつかの限定
を条件として、本発明は、正算オペレータの結果が入力
として非正算オペレータに供給されることができ、ま
た、その逆についても同様に供給されることができるよ
うに、正算オペレータと非正算オペレータとが、依存関
係グラフを通して同時に実行されることを可能にする。

【００７５】相互に接続された非正算オペレータのグル
ープを解明するために、いくつかの解明エンジンが供給
されるべきことが理解される。非正算は、また、制限セ
ットを形成する相互に依存する非正算のグループととも
に、制限として共通に参照される。本発明は、正算オペ
レータを含むか、あるいは含まないかにかかわらず、依
存関係グラフに非正算オペレータを表示する方法に関
し、非正算オペレータのグループによって形成された制
限セットを解明するためのどんな特定のエンジンに関す
るものではない。本発明は、非正算オペレータの構造的
な依存性を表示し、以下に述べる方法で制限セットとと
もにこれらをグループ化し、そして、制限セットを、そ
れらを解明する制限解明エンジンに供給する。

【００７６】非正算（即ち、制限）の例は、上述された
例のような代数的な制限、平行な２つの線、直角な２つ
の線等を設定するような２つのオブジェクト間の幾何学
的な制限、そしてオブジェクトがある種の空間的な関係
を維持することを要求する２つのオブジェクトに対する
空間的な制限を含む。例えば、本発明は、同時に起こる
方程式のグループの構造的な依存関係を表示でき、これ
らを一緒に制限セットとして解明エンジンに供給するこ
ともできる。しかしながら、本発明は同時に起こる方程
式を解明する特定のエンジンに関するものではない。

【００７７】以上から理解されるように、非正算オペレ
ータを支援する本発明の実施の形態が使われると、本発
明の結合サブシステムがインストールされるソフトウェ
アシステムに制限解明エンジンが供給される。本発明は
表示されることのできるようなタイプの制限に限定され
ない。しかしながら、本発明の結合サブシステムがイン
ストールされた特定のソフトウェアシステムは、解くこ
とができるタイプの制限に限定された制限解明エンジン
を有してもよい。この場合、本発明は、ユーザーによっ
て生成されたデザインをチェックして、デザインに形成
された制限の各セットが有効であるか、即ち、制限解明
エンジンが形成することができるタイプであるかどうか
を判定する。支援されていない制限セットが形成される
と、本発明は、以下に述べる方法でエラー状態としてこ
れを検出する。

【００７８】正算オペレータは、１つの方向で評価され
ることができるだけなので、正算オペレータと非正算オ
ペレータとが単一の依存関係グラフで接続することがで
きるできる方法に制限がある。それが正算オペレータの
結果であれば、非正算オペレータへの入力は固定された
値を有すると考えられる。非正算各オペレータの各々
は、少なくとも１つの固定されない入力を有さなければ
ならない。例えば、Ａ＝Ｂ＊Ｃである上記非正算に関し
ては、入力ＢとＣとの両方とも固定化できない。なぜな
らば、固定された場合、Ａの値が変更されると、ＢとＣ
の両方とも固定されているので、要求される関係を維持
できなくなるからである。このように入力ＢとＣとは、
両方とも正算オペレータから供給されることができな
い。なぜならば、両方とも固定され、過度に制限された
ケース又はエラー状態となるからである。しかしなが
ら、入力ＢとＣとの一方が制限されない限り、例えば、
他方の非正算オペレータから供給される限り、エラー状
態は発生しない。なぜならば、Ａの値が変更されると、
制限されない入力Ｂ又はＣが対応する方法で変更できる
からである。

【００７９】単一の依存関係グラフの正算オペレータと
非正算オペレータとの使用にかかる他の制限は、サイク
ルが正算オペレータを含めるようにグラフに形成できな
いということである。当業者に理解されるように、スタ
ートポイントからグラフを通る有効なフロー経路のトレ
ーシングが、スタートポイントに戻るように導くと、グ
ラフでサイクルが発生する。非正算オペレータだけを含
むサイクルが有効に存在できるにもかかわらず、正算オ
ペレータを含むいくつかのサイクルは、過度に制限され
たエラー状態になる。

【００８０】非正算がデザイン中で実行されたとき、本
発明のチェッキングルーチンは、依存関係グラフを分析
して上述の制限の１つを妨害せずに対応する非正算オペ
レータが付加されることができるかどうかを判定する。
特に、ルーチンは、非正算オペレータが過剰に抑制され
ず、そして、値が固定されない入力の少なくとも１つを
有することを保証する。加えて、ルーチンは、非正算オ
ペレータの付加が、正算オペレータを含むグラフのサイ
クルの形成とはならないことを保証する。これは、付加
される非正算オペレータで開始し、依存関係グラフの有
効な各経路を通ることによって、これらのパスのいずれ
かが、非正算オペレータが付加された時点で戻るかどう
かを決定するルーチンによって達成される。２つの禁止
された条件のいずれかが発生すると、エラー信号が、非
正算オペレータがユーザーによって試みられる方法で依
存関係グラフに付加できないように生成される。エラー
が起こらなければ、非正算オペレータはグラフに付加さ
れる。

【００８１】上述したように、本発明は、制限セットを
解明する特定のエンジンに関するもではない。むしろ、
本発明は、非正算制限セットを含むことのできるデザイ
ンの図表的な表示に関する。以下に述べる方法で、本発
明は、デザインの非正算制限の各セットの境界を決定し
て、これらの制限セットを同時解明用の解明エンジンに
供給する。非正算オペレータだけを含む各サイクルは、
グラフの正算オペレータの場所によって決定される制限
セットの境界、あるいはグラフ自身の境界とともに、制
限セットを形成する。

【００８２】１．記号評価パス 図７及び図８に関連して上述したように、結合ＡＰＩプ
ロセッサ７１が、依存関係グラフのオペレータが評価さ
れることを要求すると、すべてのオペレータに一般的な
評価方法が呼び出される。評価方法は、グラフマネージ
ャー７５（図５）によって呼び出され、このグラフマネ
ージャー７５は、以下により詳細に説明されるソフトウ
ェアエンティティであり、本発明によって作成される依
存関係グラフのマネージングを含む仕事を実行する。評
価方法によって実行される基本のステップは、図７及び
図８に関連して上述されている。この方法のための特定
の実行は、非正算オペレータの使用を支援する本発明の
実施の形態により説明される。本発明のこの実施の形態
によれば、２つのパス方法は、依存関係グラフに対して
実行される。記号パスについてとして参照される第１の
パスの間、グラフは、リストが評価されるべき命令と同
様に、評価されるオペレータのリストを形成するために
質問される。リストに含まれているオペレータは、単一
の非正算オペレータであるか、制限解明エンジンによっ
て同時に評価されるべき非正算オペレータの制限セット
である。第２のステップは、記号パス間に形成されたリ
ストによって指定された順序の各オペレータの評価であ
り、評価パスとして参照される。

【００８３】記号パスは、図９のフローチャートに示さ
れ、結合ＡＰＩプロセッサ７１が、依存関係グラフのオ
ペレータがそれ自体を評価することを要求するときは、
いつでも呼び出される。まず、ステップ８００にて、オ
ペレータと制限セットとが評価される順序を定義するた
めの記号パス中に、作成されるオペレータ評価リストの
ために、スタックが開かれる。この目的のために作成さ
れるスタックは、オペレータと制限セットが、以下の方
法でプッシュされ、ポップされる先入れ先出し(first-i
n first-out)スタックである。スタックリストが開かれ
た後、本方法は、ステップ８０２に進み、評価されるオ
ペレータのための編集された（例えば、同調しない）デ
ータオブジェクトが処理のために選択される。概して、
結合ＡＰＩプロセッサ７１は、そのデータオブジェクト
の１つが、編集され、再評価を要求しない限り、オペレ
ータの評価を要求しない。しかしながら、後述する本発
明の視覚的編集能力が使用されると、オペレータ自体
は、そのデータオブジェクト入力の１つを変えることな
く、変更できる。この場合、本発明は同調しないデータ
オブジェクトの各々を設定して、各々が、記号パス間に
処理されるようにする。

【００８４】ステップ８０４では、依存関係グラフが、
ステップ８０２における処理のために選択されたデータ
オブジェクトに直接依存するすべてのオペレータのリス
トを形成するために質問される。正算オペレータが、デ
ータオブジェクトがオペレータに入力として供給された
ときにデータオブジェクトに直接依存するのに対して、
非正算オペレータは、何らかの方法でデータオブジェク
トに直接接続されたときにデータオブジェクトに直接に
依存する。ステップ８０４では、依存関係グラフを通し
て伝達するための試みはなされず、また、データオブジ
ェクトの変更により影響されるかもしれない点におい
て、データオブジェクトに、間接的に依存する他のオペ
レータの場所を見つける試みはなされない。なぜなら
ば、これらのオペレータは、後述される方法で記号パス
の反復的な性質を通して確認されるからである。

【００８５】ステップ８０６では、ステップ８０４で形
成されたリストで確認されたオペレータの１つが、処理
のために選択され、そしてステップ８０８では、このオ
ペレータが正算オペレータであるのかどうかについて判
定がなされる。選択されたオペレータが正算オペレータ
であるときは、本方法は、ステップ８１０に進み、正算
オペレータを処理するためのルーチン（図９）が呼び出
される。反対に、選択されたオペレータが正算オペレー
タではないとき、本方法は、ステップ８１２に進み、非
正算オペレータ（図１１及び図１２）を処理するルーチ
ンが呼び出される。オペレータ処理ルーチンは、評価の
ための適切な順序でオペレータ評価スタック上に、処理
されるオペレータをプッシュし、このルーチンは、以
下、詳細に説明される。

【００８６】最も新たに、選択されたオペレータの処理
を扱うためにステップ８１０または８１２のいずれかで
呼び出された適当な処理のルーチンが、記号パスに戻る
と、本方法は、ステップ８１４に進み、ステップ８０４
で形成されたリストのオペレータのいくつかが処理のた
めに残っているかどうかについて判定がなされる。処理
が残っている場合、本方法は、ステップ８０６に戻り、
他のオペレータが処理するために選択される。このよう
に、本方法は、ステップ８０２で処理するために選択さ
れた第の編集データオブジェクトに直接依存しているス
テップ８０４で作成されたリストのオペレータのすべて
を処理するためにステップ８０６−８１４を実行する。

【００８７】処理するオペレータが残っていないとステ
ップ８１４にて判定されると、本方法は、ステップ８１
６に進み、その評価が方法を呼び出したオペレータのた
めの編集データオブジェクトが処理されるために残って
いるかどうかについての判定がなされる。そして、少な
くとも１つが処理のために残っているとき、本方法は、
ステップ８０２に戻り、他の編集データオブジェクトが
処理のために選択されるか。このように、本方法は、評
価されるオペレータのための編集データオブジェクトの
すべてが処理されるまで、ステップ８０２−８１６を実
行する。これらのデータオブジェクトのすべてが処理さ
れたとステップ８１６にて判定されたとき、本方法は終
了する。

【００８８】図９のステップ８１０で呼び出される正算
オペレータを処理するルーチンは、図１０のフローチャ
ートによって示される。まず、ステップ８２０では、ル
ーチンは、処理されるオペレータが、すでにオペレータ
エバリュエータスタック上にプッシュされているかどう
かを判定し、そうであるときは、ルーチンは、単に終了
する。オペレータがスタック上にはプッシュされていな
いと判定されたとき、本方法はステップ８２２に進み、
正算オペレータに入力されるデータオブジェクトの１つ
が、処理のために選択される。ステップ８２４では、選
択されたデータオブジェクトが同調しないかどうかにつ
いて判定がなされ、そうであるとき、本方法は、ステッ
プ８２６に進み、そのデータオブジェクトをソースとす
るオペレータが処理のために選択される。そして、本方
法は、ステップ８２８に進み、ステップ８２６で処理の
ために選択されたオペレータが正算オペレータなのか、
非正算オペレータなのかについて判定がなされる。

【００８９】ソースオペレータが非正算オペレータであ
るとき、本方法は、ステップ８３０に進み、以下に記載
された方法でそのオペレータを処理するために非正算オ
ペレータを処理するルーチンが呼び出される。反対に、
ソースオペレータが正算オペレータであるとき、正算オ
ペレータを処理するルーチンは、ステップ８３２にてそ
のオペレータを処理するために再び呼び出される。この
ように、正算オペレータと非正算オペレータとを処理す
るルーチンは、依存関係グラフを通って進み、その評価
が記号評価のパス（図９）のための呼び出しを開始する
オペレータによって作用されるデータを生成するために
再評価を要求するオペレータのすべてを処理する反復方
法で実行される。依存関係グラフの評価または再評価
が、最初にグラフの左側のオペレータ又は制限を評価
し、グラフ中の左から右への方法で処理することにより
実行されるべきであることが理解される。このようにオ
ペレータを実行することにより、そのデータオブジェク
トに影響を与えるオペレータがすべて更新されるまで、
オペレータは評価されないことが保証される。

【００９０】処理されるオペレータの選択されたデータ
オブジェクトが同調していないとステップ８２４にて判
定されたとき、あるいは、データオブジェクトが同調し
ていないときにステップ８３０又は８３２のいずれかで
データオブジェクトのためのソースオペレータを処理す
るために適切なルーチンが呼び出された後、本方法は、
ステップ８３４に進み、選択されたオペレータのための
データオブジェクトがいくつか処理されるために残って
いるかどうかについて判定がなされる。少なくとも１つ
のデータオブジェクトが処理されるために残っているこ
とがステップ８３４にて判定されたとき、ルーチンは、
ステップ８２２に戻り、他のデータオブジェクトが処理
のために選択される。このように、本方法は、その評価
が記号評価パス（図９）と、このために非正算オペレー
タを処理するルーチンを呼び出すオペレータのためのデ
ータオブジェクトをすべて処理するためにステップ８２
２〜８３４を実行する。

【００９１】最後に、その評価が処理ルーチンを呼び出
すオペレータのために処理されるデータオブジェクトが
残っていないとステップ８３４にて判定されたとき、オ
ペレータは、ステップ８３６にてオペレータエバリュエ
ータスタック上にプッシュされる。正算オペレータ処理
ルーチンと非正算オペレータ処理ルーチンとの反復する
性質は、依存関係グラフのオペレータが上記所望の結果
を達成するために正しい順序で評価されることを保証す
る。図１０の上記説明から明らかなように、オペレータ
は、そのデータオブジェクトのすべてが処理されたこと
がステップ８３４で判定されるまで、ステップ８３６に
てエバリュエータスタック上にはプッシュされない。さ
らに、データオブジェクトの処理中、同調していない各
々については、正算オペレータ処理ルーチン又は非正算
オペレータ処理ルーチンとが、データオブジェクトをソ
ースとするオペレータを処理するために呼び出される。
図１０の処理ルーチンがこれらのソースオペレータに作
用するために呼び出されたとき、そのデータオブジェク
トの夫々が更新されることを保証するために、同様に判
定がなされ、更新されないとき、ルーチンが、そのソー
スオペレータを処理するために再び呼び出される。ルー
チンのこの反復的な性質のため、他のオペレータに更新
されたデータオブジェクトを供給するために評価されな
ければならない各オペレータは、データオブジェクトに
応答するオペレータの前に、ルーチンの対応する実行の
間ステップ８３６にてスタック上にプッシュされ、それ
ゆえに、その結果に依存するオペレータの前に評価され
る。その評価が、記号パスのルーチン（図９）を最初に
呼び出したオペレータは、最初に処理されるので、ルー
チンの反復処理の最も高い水準にある。このため、この
オペレータは、それが依存している結果を生成するオペ
レータの各々が先の反復的な処理の繰り返しの間、スタ
ック上にプッシュされた後にのみ、オペレータエバリュ
エータスタック上にプッシュされる。

【００９２】非正算オペレータを処理するルーチンは、
図１１及び図１２のフローチャートにより示されてい
る。図１０の正算オペレータルーチンと同様に、図１１
及び図１２のルーチンは、結合ＡＰＩプロセッサ７１が
依存関係グラフのオペレータの評価を要求するとき、最
初に呼び出される。ステップ８４０では、オペレータ
が、先に定義された制限セットの一部としてオペレータ
エバリュエータスタック上にプッシュされているかどう
かの判定がなされ、そして、すでにプッシュされている
とき、ルーチンは終了する。オペレータがすでにスタッ
ク上にプッシュされていなければ、本方法は、ステップ
８４２に進み、制限セットが現在、オープンされている
かどうかの判定がなされる。オープンされていないと
き、本方法は、ステップ８４４に進み、制限セットがオ
ープンされる。

【００９３】上述のように、本発明は、複数の非正算オ
ペレータを含むことのできる制限セットを評価するため
の制限エバリュエータエンジンを含むソフトウェアシス
テム上にインストールできる。このような制限セットを
正しく評価するために、エンジンは、硬く結合された非
正算オペレータのセットをグループとして受け取る。そ
れゆえに、正算オペレータと非正算オペレータとの両方
を含む依存関係グラフを評価するとき、図９の記号パス
によって構成されて、依存関係グラフが、制限セットが
グループとしてエンジンに供給されるようにできる。

【００９４】上述したように、正算オペレータは、単
に、正算オペレータを処理するルーチンの反復する性質
のために評価のための適切な順序で、オペレータエバリ
ュエータスタック上にプッシュされるだけである。しか
しながら、制限セットは、すべてのセットが処理される
までオペレータエバリュエータスタック上にはプッシュ
されない。制限セットは、その非正算オペレータの各々
が処理された後にのみ、オペレータエバリュエータスタ
ック上にプッシュされる。各制限セットは、依存関係グ
ラフの他の制限セットと正算オペレータに関して適切な
評価順序でスタック上にプッシュされ、これは、セット
がオープンされた後に適切に生じる。

【００９５】制限セットがステップ８４４にてオープさ
れた後、またはステップ８４２にて、セットがすでにオ
ープンされたと判定されたときは、本方法は、ステップ
８４６に進み、処理される非正算オペレータが、オープ
ンされた制限セットに付加される。その後、ステップ８
４８では、非正算オペレータに結合するデータオブジェ
クトの１つが、処理のために選択される。そして、本方
法は、ステップ８５０に進み、ステップ８４８で選択さ
れたデータオブジェクトを直接ソースとするオペレータ
により、リストが形成される。データオブジェクトが直
接接続されている場合には、非正算オペレータがデータ
オブジェクトを直接ソースとするのに対して、結果のデ
ータオブジェクトである場合には、正算オペレータは、
データオブジェクトを直接ソースとする。

【００９６】ステップ８５２では、ステップ８５０で生
成された直接ソースオペレータのリストが正算オペレー
タを含むかどうかについての判定がなされる。正算オペ
レータが、単一のデータオブジェクトをソースとするこ
ともできる。直接ソースオペレータのリストが正算オペ
レータを含んでいると判定されたとき、本方法は、ステ
ップ８５４に進み、選択されたデータオブジェクトが同
調していないかどうかを判定する。データオブジェクト
が同調していないとき、本方法はステップ８５６に進
み、図１０の正算オペレータを処理するルーチンが、選
択されたデータオブジェクトをソースとする正算オペレ
ータを処理するために呼び出される。

【００９７】図１０に関連して上述したように、正算オ
ペレータ処理ルーチンの呼び出しは、処理するために最
初に呼び出される正算オペレータだけでなく、正算又は
非正算の他の全てのオペレータであって、直接的にまた
は間接的に依存するデータオブジェクトを生成するオペ
レータを処理する結果となる。このように、制限セット
の処理を完了させる前に、正算オペレータ処理ルーチン
を呼び出すことにより、図１１及び図１２の非正算オペ
レータ処理ルーチンは、制限セットを与える正算オペレ
ータが、制限セットの前にオペレータエバリュエータス
タック上に置かれることを保証する。正算オペレータの
出力は、制限セットに関しては、固定されるので、図１
１及び図１２の方法は、制限セットが解決のために制限
解明エンジンに渡される前に、制限セットのための固定
値が評価されることを保証する。

【００９８】正算オペレータ処理ルーチンがステップ８
５６に戻ったとき、あるいはステップ８５４にて、選択
されたデータオブジェクトが同調していることが判定さ
れるか、あるいは、ステップ８５２にて、ステップ８５
０にて生成されたソースオペレータのリストが正算オペ
レータを含んでいないことが判定されると、本方法はス
テップ８５８に進む。ステップ８５８では、ステップ８
５０にて生成されたソースオペレータのリストが非正算
オペレータを含んでいるかどうかの判定がなされ、含ん
でいるとき、本方法はステップ８６０に進み、非正算オ
ペレータが処理のために選択され、そして、ステップ８
６２に進み、非正算オペレータ処理ルーチンが、選択さ
れたオペレータのために呼び出される。

【００９９】上記から理解されるように、正算オペレー
タを処理するための図１０のルーチンと同様に、図１１
及び図１２の非正算オペレータ処理ルーチンは、反復的
な方法で作用する。しかしながら、これらのルーチンの
反復する性質の間には重大な相違がある。上述したよう
に、図１０の正算オペレータルーチンの反復する性質
は、正算オペレータが実行されるための順序でオペレー
タエバリュエータスタック上にプッシュされる技術であ
る。対照的に、非正算オペレータ処理ルーチンの上記ス
テップから明らかなように、非正算オペレータが処理さ
れたとき、それらは、オペレータエバリュエータスタッ
ク上に個別にプッシュされるのではなく、むしろ、単に
オープンした制限セットに付加されるだけである。制限
解明エンジンがセットの非正算オペレータのすべてに同
時に作用するので、非正算オペレータが制限セットに置
かれる順序は重大なことではない。それゆえに、図１１
及び図１２に示すルーチンの反復的な性質は、制限セッ
トの非正算オペレータのすべてがそのセットに付加され
ることを保証するためにのみ使用され、その順序は無関
係であるので、セットに付加される順序を保証するため
に使用されるのではない。

【０１００】非正算オペレータ処理するルーチンが、ス
テップ８６０で選択された非正算オペレータの処理から
戻った後、本方法はステップ８６４に進む。ステップ８
６４では、いくつかの非正算オペレータが処理のために
残っているかどうかの判定がなされ、そして少なくとも
１つが処理されるために残っているとき、本方法は、ス
テップ８６０に戻り、他の非正算オペレータが処理のた
めに選択される。このように、ルーチンは、ステップ８
６４にて非正算オペレータのすべてが処理されたと判定
されるまで、ステップ８５０で生成されたソースオペレ
ータのリスト中の非正算オペレータの各々を通して進行
する。

【０１０１】処理されるべき非正算オペレータが残って
いないとステップ８６４にて判定されたとき、またはソ
ースオペレータのリストが非正算オペレータを含んでい
ないとステップ８５８にて判定されたとき、本方法は、
ステップ８６６に進む。ステップ８６６では、ルーチン
が呼び出される非正算オペレータのために処理されるた
めのデータオブジェクトが残っているかどうかの判定が
なされ、そして、少なくとも１つのデータオブジェクト
が処理されるために残っているとき、本方法は、ステッ
プ８４８に戻り、他のデータオブジェクトが処理のため
に選択される。このように、ルーチンが呼び出されるオ
ペレータのためのデータオブジェクトのすべてが処理さ
れるまで、本方法はステップ８４８−８６６を実行す
る。

【０１０２】処理されるデータオブジェクトが残ってい
ないとステップ８６６にて判定されたとき、本方法は、
ステップ８６８に進み、ルーチンが呼び出されるための
非正算オペレータが制限セットをオープンしたかどうか
の判定がなされる。このステップは、その実行の反復す
る性質のためにルーチンに含まれている。ルーチンが、
現在オープンしている制限セットをオープンしなかった
オペレータのために実行されるとき、制限セットに付加
されるべき他の非正算オペレータは、処理のために残る
ことができ、それゆえに、制限セットは、まだクローズ
されず、オペレータエバリュエータスタックに付加され
るべきである。それゆえに、ステップ８６８にて呼び出
すオペレータが制限セットをオープンしなかったと判定
されたとき、本方法は単に終了し、ルーチンの反復的な
実行の次の高水準のステップ８５８に戻る。

【０１０３】呼び出すオペレータが現在オープンする制
限セットをオープンしたとステップ８６８にて判定され
たとき、本方法は、ステップ８７０に進み、制限セット
が空かどうかの判定がなされる。そして空と判定された
とき、本方法は、ステップ８７２に進み、制限セットが
方法の終了に先立って削除される。制限セットが空では
ないとき、本方法は、ステップ８７４に進み、制限セッ
トがクローズされる。そしてステップ８７６では、クロ
ーズされた制限セットが、方法の終了に先立って最新の
エントリーとして、オペレータエバリュエータスタック
上にプッシュされる。

【０１０４】２．評価パス 上記から理解されるように、図１０〜図１２の正算オペ
レータと非正算オペレータとの処理ルーチンの記号パス
中の反復的な実行は、正算オペレータと非正算オペレー
タの制限のセットとを、それらが評価されるべき順序で
オペレータエバリュエータスタック上に置く。それゆえ
に、グラフを更新するための実際の評価パスを実行する
ルーチンは、分かりやすく、そして、図１３のフローチ
ャートによって示される。

【０１０５】まず、ステップ８８０では、本方法は、ス
タックによって指定された順序オペレータと制限セット
を実行する。各オペレータと制限セットのために実行さ
れた評価ルーチンは、図７と図８に関連して上述され、
収集と引数のフォーマットとを必要とし、それからデザ
インを更新するための適切な固有ＡＰＩを呼び出す。そ
して、本方法はステップ８８２に進み、スタックが本発
明の１実施形態に関連して再利用されることができるよ
うにセーブされる。ユーザーによってなされる変更の性
質に応じて、各再評価のために個別の記号パスを要求す
ることなく２回以上、グラフの再評価ができる。特に、
ユーザーがグラフに入力されるリーフノードデータオブ
ジェクトを再編集するのであれば、記号パスは、オペレ
ータエバリュエータスタック上の結果が同調しているの
で、再実行される必要がない。加えて、デザインの変更
だけがすでにオペレータエバリュエータスタック上にあ
る正算オペレータに入力されるデータオブジェクトの編
集であれば、記号パスは、再び実行される必要がない。

【０１０６】IX．統合処理 上記から理解されるように、本発明は、ファンクション
で構成されるどんなソフトウェアシステムにも接続して
使用でき、本発明のソフトウェアのインストールに続い
てソフトウェアシステム上の統合処理を実行できる。結
合ＡＰＩプロセッサファンクションと結合変数クラスと
は、本発明がインストールできるソフトウェアシステム
の詳細に関して一般的であり、それゆえに、インストー
ルされたソフトウェアに供給される。インストールされ
たソフトウェアは、図１４に示される統合処理を実行す
る。処理の各ステップの詳細は、上述されている。ま
ず、ステップ３０１では、製品デザインの部分を表示す
るためにソフトウェアシステムによって生成された各ア
プリケーションエンティティのクラスの定義は、デザイ
ンに入力された引数を表示するこれらと同様に、結合変
数クラスから受け継ぐために修正されて、依存関係グラ
フに加入しているのか、そしてどこに加入するのかにつ
いての判定に使われる上述の能力を有するようにする。
次に、ＡＡＰＩがステップ３０２にてソフトウェアシス
テムの各固有ＡＰＩのために生成される。その後、ユー
ザーインタフェースがステップ３０３にて修正されて、
ユーザーから受け取ったコマンドに応答して、ユーザー
インタフェースが、ソフトウェアシステムのＡＰＩを直
接呼び出すというよりはむしろ、ステップ３０２にて生
成されたＡＡＰＩを呼び出す。最後に、ステップ３０４
にて、グラフマネージャーを生成し、そしてグラフマネ
ージャーにハッシュテーブルのエントリーを形成するソ
フトウェアエンティティを作成させる初期化ファンクシ
ョンが実行される。

【０１０７】図１４の統合処理がソフトウェアシステム
上で実行されると、システムには、ユーザーにとっては
明らかな方法で本発明の能力が供給され、特別なユーザ
ーの訓練を必要としない。加えて、このような能力が、
システムの固有コマンドと対応ＡＰＩとに供給されない
としても、ソフトウェアシステム上の統合処理のオペレ
ーションがシステムにパラメータ能力を供給することが
理解される。上述したように、本発明のこの特徴は、サ
ードパーティにソフトウェアシステムに付加的な能力を
供給することを容易にする。なぜならば、サードパーテ
ィによって供給された付加的なコマンドは、パラメータ
能力を供給するソフトウェアシステムのコマンドセット
に統合される必要がないからである。

【０１０８】X.パラメータ能力 上述したように、本発明の利点の１つは、製品デザイン
に修正がなされたとき、修正により影響される結果を伴
うオペレータのみが再実行されるように、修正は依存関
係グラフを使用するデザインの中に組み込まれる点にあ
る。本発明のこの様相は、グラフマネージャー７５（図
５）によってコントロールされる。グラフマネージャー
は、ユーザーインタフェース３７からの入力を受け取る
ソフトウェアエンティティであり、製品デザンのために
いつ修正がなされたかを判定する。殆どのＣＡＤシステ
ムは、アプリケーションエンティティ（例えば、箱、円
柱、等）がデザインにつけ加えられた後、ユーザーが、
例えば、先に作られた箱の長さ、幅、そして／または高
さの変更等のデザインに関するパラメータに修正を加え
ることができるパラメータインタラクタを含む。

【０１０９】本発明に関して、デザインのパラメータの
変更は、システムから出力された製品デザイン４５（図
３）の変更だけでなく、依存関係グラフのデータオブジ
ェクトに関連する少なくとも１つの引数を修正すること
になる。このように、ソフトウェアシステムが、ユーザ
ーコマンドにデザインのパラメータを変更させるパラメ
ータインタラクタを供給すると、本発明は、ユーザーか
ら受け取られたコマンドを、依存関係グラフにおいて変
更されたパラメータを表示するデータオブジェクトに結
合させる。特に、ユーザーがパラメータを変更するため
のコマンドを入力したとき、新しい引数は、ユーザーイ
ンタフェース３７からグラフマネージャー７５に渡さ
れ、グラフマネージャー７５は、依存関係グラフの対応
するデータオブジェクトにより指し示されたメモリ場所
を更新して、変更された引数を反映する。

【０１１０】その後、グラフマネージャー７５は、図９
〜図１３に関連して説明した製品デザイン４５に変更を
伝えるための２つのパスの処理を実行する。発明の１実
施形態では、現在のデザインパラメータに対する変更
は、製品デザインに直ぐに組み込まれるわけではない。
むしろ、デザインに対する更新は、ユーザーが再計算を
要求しない限り、そして要求するまでは実行されない。
この特徴は、デザインを更新する前に、例えばユーザー
がいくつかのパラメータを変更しようとしたときに有利
である。なぜならば、各パラメータを変更した後に再計
算をしないことによりシステムがリソースを保存するか
らである。ユーザーが再計算を要求したときには、グラ
フマネージャー７５は、結合ＡＰＩプロセッサ７１に、
変更されたパラメータに依存する依存関係グラフのオペ
レータに上述した方法でそれ自身を再評価させることを
命令する。本発明の１つの実施形態では、再計算の２つ
のモードが供給される。第１のモードは、前に向けての
再生として知られているものであり、変更パラメータに
依存するすべてのオペレータの再計算を必要とするもの
である。第２のモードは、要求により再計算するモード
であり、要求駆動される。この第２のモードでは、ユー
ザーは更新されるべきデザインのサブセットだけを指定
する。例えば、ユーザーは、デザインの部分のみのパラ
メータの変更結果を見ることを要求することができる。
図２に示される例を参照すると、ユーザーは、例えば、
データオブジェクト３に関連する長さのパラメータに変
更を加えることができ、そしてこのパラメータの変更が
生成された箱に関してのみ与える影響を見ることを要求
することができる。ユーザーがこのような要求をする場
合、グラフマネージャー７５は、結合ＡＰＩプロセッサ
７１に、オペレータ７だけにそれ自身を再評価させるよ
うに命令する。このように、オペレータ１９もまた、デ
ータオブジェクト３に関連したパラメータに依存してい
るにもかかわらず、グラフマネージャーは、ユーザーに
よって要求されてはいないので、結合ＡＰＩプロセッサ
７１に、オペレータ１９に自身を再評価させることを命
令しない。

【０１１１】XI．階層オペレータ 本発明の１つの実施の形態において、能力が供給され
て、依存関係グラフに階層的な方法で、ユーザーによっ
て実行されるオペレーションを表示する。ユーザーのデ
ザイン目的を表示するためのいくつかの論理的な方法で
配置された１つ以上の低水準のオペレータを夫々表示す
る階層オペレータが作成される。以下により詳細に説明
するように、階層的能力は、階層的な方法で、本発明の
結合サブシステムがインストールされているソフトウェ
アシステムの複数のコマンドをひとまとめにするために
ユーザーによって用いられ、単一の階層グループでコマ
ンドと１つ以上のサブコマンドをまとめるソフトウェア
システムによってもまた使用される。

【０１１２】本発明の階層的能力は、一組の低水準デザ
インオペレーションを、依存関係グラフにおけるユーザ
ーのアクティビティに適応させた単一のより高水準の目
的として組織させ、かつ、表示させる。例えば、ＣＡＤ
システム上で自動車のロータをデザインするユーザー
は、ロータの突起継手を定義するために使用される低水
準のオペレータの全てをひとまとめにすることで、第１
の階層オペレータを作成し、ロータに冷却水路を付加す
るために使用される低水準オペレータをひとまとめにす
ることで、第２の階層オペレータを作成する。多数の低
水準オペレータをひとまとめにし、単一の階層オペレー
タでそれらを表示することで、デザイン用に生成される
依存関係グラフが、より有意義なユーザーのアクティビ
ティに適応させた目的を表示するために簡便になる。さ
らに、いったんそれらが形成されると、階層オペレータ
がデザインにおける他の場所での使用のため複写される
ので、階層グループを作成した低水準のデザインオペレ
ーションが複写される必要がない。

【０１１３】本発明の結合サブシステムがソフトウェア
システムに統合されると、結果として生じる結合システ
ムもまた、階層的能力を遂行して、コマンドと、コマン
ドの一定の特性を定義するコマンドと共にユーザーによ
って一般的に実行される一連の対応サブコマンドと、を
ひとまとめにする。例えば、多くのＣＡＤシステムは、
ユーザーのデザイン目的と相関するより高水準の幾何学
的なモデリングの一形態である特徴を用いているが、デ
ザイン目的の詳細を定義する特徴でサブコマンドの実行
を必要とする。本発明の階層的能力を用いると、本発明
の結合サブシステムがインストールされているＣＡＤシ
ステムは、特徴によって行われる潜在的に複雑な幾何学
的なモデリングファンクションを定義するのに必要なメ
インコマンドと、その支援サブコマンドの全てのための
個別のオペレータによって夫々の特徴が表示されること
を必要とするよりはむしろ、階層オペレータを使用する
依存関係グラフにおける高水準の特徴を表示することが
できる。

【０１１４】普通のＣＡＤの特徴の一例は、多くの異な
るタイプの穴である。図２１は、箱７０２に設けられた
さら穴７００の一例を示している。箱７０２にさら穴を
挿入するには、ユーザーは、穴が設けられる面データ７
０４、面データ上の穴の中心位置、穴の深さ７０６、穴
の半径Ｒ₂ 、さら穴の半径Ｒ₁ 及びさら穴の角度θを含
む複数の定義用パラメータを指定する。これらのパラメ
ータは、さら穴を作成する特徴的なコマンドと共に、サ
ブコマンドのグループを実行することで指定される。

【０１１５】本発明の階層的能力が用いられない場合、
さら穴を有する箱を定義するユーザーのデザインアクシ
ョンは、図２２に示すような依存関係グラフによって表
示される。オペレータ７１６の出力は、さら穴を有する
箱を定義する結果としてのアプリケーションエンティテ
ィを表示するデータオブジェクト７２４となる。図示す
るように、入力としての複数のリレーションとデータオ
ブジェクトを有する箱のオペレータ７１０の結果である
データオブジェクト７１２によって、箱自身が表示され
る。特徴的なコマンドと２つの支援サブコマンドとに対
応する３つのオペレータ７１４〜７１６によって、箱へ
のさら穴の挿入が表示される。オペレータ７１４が、箱
を表示するデータオブジェクト７１２に接続され、ユー
ザーによって実行されるサブコマンドを表示して、さら
穴が設けられる部分としての箱の上面を選択する。オペ
レータ７１４の結果が箱の上面となる。オペレータ７１
５はこの結果を受け取り、ユーザーによって実行される
サブコマンドを表示して、さら穴が加えられる上面のデ
ータを選択する。オペレータ７１５の結果は、特徴的な
コマンドを表示するさら穴オペレータ７１６に入力され
る。データ入力に加えて、さら穴オペレータもまた、穴
の位置を表示するデータオブジェクト７１８、立体（例
えば、穴が設けられた箱）を表示するデータオブジェク
ト７１２、及び、さら穴の半径Ｒ₁ 、Ｒ₂ 、角度θ、深
さを夫々表示するデータオブジェクト７２０〜７２３に
接続される。

【０１１６】本発明の階層的能力が用いられたとき、前
述したデザインアクションを表示する依存関係グラフが
図２３に示す方法で生成される。図２２のオペレータ７
１４〜７１６が、箱におけるさら穴の作成を表示する単
一の階層オペレータ７２６によって表示される。内部オ
ペレータ７１４及び７１６に接続する階層に、箱を表示
するデータオブジェクト７１２を差し込む２つの入力
と、単一結果データオブジェクト７２４と、を有するよ
うに階層オペレータ７２６が示される。オペレータ７１
４〜７１６に入力されるが、階層オペレータに内在する
データオブジェクトの夫々は、グラフを簡単にするため
に表示されない。箱を表示する２つのリレーション７３
０及び７３１を介して接続されて、このデータオブジェ
クトが階層オペレータ７２６内部の２つの個別オペレー
タ（例えば、７１４及び７１６）に供給されることを表
示する。階層オペレータの結果が、オペレータ７１６か
ら出力される同じ結果のさら穴を有する箱を定義するア
プリケーションエンティティを表示するデータオブジェ
クト７２４に接続される。

【０１１７】図２２及び図２３の依存関係グラフの比較
からわかるように、本発明の階層オペレータの能力によ
り、単にユーザーの意向にわずかに関係しているにすぎ
ない多数のオペレータで依存関係グラフを取り散らかさ
ずに、より高水準でユーザーのデザイン意向を表示でき
る。本発明の結合サブシステムが統合されたソフトウェ
アシステムは、単一の階層オペレータを有する依存関係
グラフで夫々が表示するのが好ましい多数の階層的な特
徴を含んでいる。それらの特徴のため、ソフトウェアシ
ステムは階層的な方法でそれらの特徴を表示する後述の
方法で、本発明の階層オペレータの能力を用いることが
できる。この能力は、ユーザーのデザイン目的を遂行す
るための特徴的なＡＰＩと、またＡＰＩが作用するデー
タを定義するサブコマンドに関するいくつかの付加的な
ＡＰＩとの実行を必要とするコマンドに関連して、特
に、有用である。本発明の階層オペレータ能力により、
複数のＡＰＩのグループを、ユーザーのデザイン意向を
より正確に表示する単一オペレータとして表示できる。

【０１１８】後述するように、本発明の一つの実施の形
態では、依存関係グラフはグラフィカルモードで編集で
きる。この能力が用いられるとき、ユーザーにはデザイ
ンの依存関係グラフ表示における詳細水準に関して適応
性が供給される。例えば、階層オペレータ７２６が使用
される図２３の依存関係グラフに関して、ユーザーはよ
り詳細にグラフを見たいと所望し、図２２において示さ
れる階層オペレータのより詳細な表示を明らかにするた
めに、階層オペレータ７２６が展開される異なったビュ
ーモードを選択することができる。この場合、展開され
た単一の階層ブロックに内在するグラフ要素のまわりに
点線を描くことで、ある階層の境界がより詳細な表示で
供給される。

【０１１９】階層オペレータが依存関係グラフのために
作成されたとき、本発明は、その入力及び出力を定義す
る一覧を供給する。このように、リレーションが階層境
界を横切らないように、明確な境界が依存関係グラフに
おける夫々のオペレータのために定義される。さらに、
ユーザーには、そのより詳細な表示を見るために階層オ
ペレータを展開する特性が供給されるので、その最上位
水準より低い夫々の水準の階層もまた、階層境界を横切
るリレーションなしに、他のグラフデータオブジェクト
からその入力と出力とを得ることができる。これは、階
層オペレータの境界外側にある依存関係グラフにおける
オペレータから入力、または、オペレータに出力される
各階層オペレータの内部データオブジェクトのいずれに
も、入力又は出力が各階層オペレータから供給されるこ
とを保証することで、達成される。階層境界を横切るデ
ータオブジェクトの視覚性を注意深く扱うことで、デザ
インの他の場所での階層オペレータの再使用が容易にな
り、後述する本発明のコード生成の特徴のための支援が
得られる。

【０１２０】階層境界を横切る１つより多いオペレータ
によって分けられるデータオブジェクトの視覚性が維持
される方法は、変数がＣのような標準的なプログラミン
グ言語でファンクションを横切ってスコープされる方法
に類似している。階層境界を横切るデータオブジェクト
の処理を保証するために、２つの基準が設定される。第
１に、階層オペレータが、他のオペレータによって参照
されるデータオブジェクトが、その階層境界の外側にあ
ることを参照（入力かまたは出力か）しようとすると、
データオブジェクトが階層オペレータ用の引数リストに
含まれる。第２に、階層オペレータとデータオブジェク
トを参照する他のオペレータとの間の関係が、両方のオ
ペレータを含む親ファンクションに供給される。親ファ
ンクションは、両方を含むより高水準の階層オペレータ
であるか、または、依存関係グラフ自身の根である。

【０１２１】階層境界を横切るデータオブジェクトの処
理を容易にするには、階層オペレータのために、２つの
付加的なソフトウェアエンティティが作成される。第１
は、階層境界を横切る夫々の入力及び出力のために作成
される入力／出力（ＩＯ）ポートである。第２は、ＩＯ
＿ＯＰと呼ばれる階層オペレータのためのＩＯポートの
リストである。

【０１２２】図２２及び図２３に示される依存関係グラ
フの比較に関しては前述したように、本発明の一つの実
施の形態では、階層オペレータからポートされる（例え
ば、入力又は出力として外部に持ち出される）データオ
ブジェクトだけが、階層オペレータの境界外側にあるオ
ペレータから、入力又は出力として参照される。従っ
て、データオブジェクト７１８及び７２０〜７２３（図
２２）が、階層オペレータ７２６に対して内部にのみ存
在するので、これらは図２３の依存関係グラフにおいて
表示される階層オペレータ７２６からポートされず、そ
のグラフの複雑さを明確にしかつ削減する。本発明の別
の実施の形態では、各階層オペレータに入力されるデー
タオブジェクトの全ては、他のオペレータから供給され
なくても、階層オペレータからポートされ、依存関係グ
ラフにおいて表示される。

【０１２３】前述したように、各階層オペレータはその
ＩＯポートを確認するＩＯ＿ＯＰリストを有している。
このリストは動的なもので、オペレータが階層オペレー
タ内に前もって内包されるデータオブジェクトを参照す
るデザインに加えられるとき、付加的なポートが必要に
応じて加えられる。このＩＯ＿ＯＰリストの動的性質
は、階層オペレータの中から全ての入力及び出力をポー
トする必要がない。しかしながら、これは後述するよう
に、結果として生じる依存関係グラフのサイズと明確性
に関して不利となる。

【０１２４】以上のことからわかるように、階層オペレ
ータのためのＩＯ＿ＯＰにおける特定のエントリーは、
階層オペレータが用いられるデザインの状況に依存して
いる。図２１〜図２３の例について前述したようなさら
穴を生成するために、階層オペレータが作成される場
合、その階層オペレータがユーザーによってコピーで
き、デザインの異なる部分で使用できる。デザインにお
ける階層オペレータの各段階は、スコープアウトされる
入力及び出力に関して、階層オペレータの各例用の異な
るＩＯ＿ＯＰを必要とする依存関係グラフにおける他の
オペレータと相違している。例えば、さら穴階層オペレ
ータ７２６が、デザインにおいて複製された場合、穴の
深さを定義するデータオブジェクト７２３（図２２）
は、さら穴階層オペレータの境界外側で、オペレータの
結果として供給される。階層オペレータのこの段階で
は、階層オペレータ用のＩＯポートを作成し、階層オペ
レータのその段階のためのＩＯ＿ＯＰにおけるＩＯポー
トを含むことにより、データオブジェクト７２３が階層
オペレータから出力される。

【０１２５】階層オペレータのために作成されたＩＯポ
ートの一例を、図２４を参照して説明する。この図は、
図２３の階層オペレータのためにどのようにＩＯポート
が作成されるかを概念的に示している。図２４は、依存
関係グラフの一形態で示されているが、ＩＯポートと支
援オペレータはユーザーのデザイン目的の表示には役に
立たないので、依存関係グラフには実際には表示されて
いない。

【０１２６】以下により詳細に説明するように、各階層
オペレータのためのＩＯポート及びＩＯ＿ＯＰは、グラ
フマネージャー７５（図５）によって作成される。階層
オペレータのための内部データオブジェクトが、階層外
側で参照（例えば、入力や出力）されるたびに、階層外
側でデータオブジェクトのポーティングを表示するため
にＩＯポートがＩＯ＿ＯＰに加えられる。これは図２４
に概念的に示されており、階層オペレータ７２６のため
に４つのＩＯポートが形成されて、階層外側で参照され
るその内部データオブジェクトをポートする。各ＩＯポ
ートは、データオブジェクトと等価オペレータとを含ん
でいる。等価オペレータは他のオペレータと同様のグラ
フエンティティであり、等価オペレータの出力に結合さ
れたデータオブジェクトが等価オペレータの入力に結合
されたデータオブジェクトにおける値と等しく設定され
るように、２つのデータオブジェクトが単に同等視され
ることを表示する。

【０１２７】階層オペレータ７２６用のＩＯポートは、
２つの入力ポート７３０及び７３６を含んでいる。入力
ポート７３０は、データオブジェクト７３０Ａと等価オ
ペレータ７３０Ｂとを含んでいる。等価オペレータはさ
らに、上面オペレータ７１４へのデータ入力を表示する
ために作成される内部データオブジェクト７３２に接続
されている。同様に、ＩＯポート７３６は、データオブ
ジェクト７３６Ａとさら穴オペレータ７１６の立体リレ
ーションへのデータ入力を表示するために作成されるデ
ータオブジェクト７４０に接続される等価オペレータ７
３６Ｂとを含んでいる。

【０１２８】入力ポートは、階層境界を横切ってアクセ
スされる階層オペレータ内部のデータオブジェクトにデ
ータを入力するファンクションを行う。データオブジェ
クト７３０Ａ及び７３６Ａは、階層外側からデータオブ
ジェクトをソースするオペレータに、親水準で接続され
るポートを供給する。前述したように、親水準は、図２
４の例におけるようなデザインの根であってよく、或い
は、そのデータオブジェクトをソースするオペレータは
もちろん、そこから入力がポートされている一方の階層
オペレータを含む他方の階層オペレータでもよい。

【０１２９】図２４において、データオブジェクト７１
２を上面オペレータ７１４に、また、さら穴オペレータ
７１６の立体リレーションを階層オペレータ７２６内部
に夫々入力するために、２つの個別のＩＯポートが形成
される。本発明の一つの実施の形態において、階層境界
を横切る単一のデータオブジェクトに参照される階層オ
ペレータの範囲内のデータオブジェクトのような２つの
データオブジェクトのために、個別のＩＯポートが形成
される。個別のＩＯポートの供給は、ユーザーに、デザ
インの異なる部分での使用のために、予め作成された階
層オペレータを、コピーさせる能力を容易にする。特
に、階層オペレータの２つの内部データオブジェクト
は、他の段階においてそれらの内部データオブジェクト
が階層境界の外側で、別のデータオブジェクトと結合さ
れるのに対し、階層オペレータにおける２つの内部デー
タオブジェクトは、グラフにおける階層オペレータの１
段階において、階層境界を横切る単一のデータオブジェ
クトに結合される。個別のＩＯポートが、これらの内部
データオブジェクトを別々にポートするために作成され
なければ、内部データ入力が階層外側の個別データオブ
ジェクトに結合される所ではどこでも、階層オペレータ
はデザインにおいて、複製されず、使用もされない。

【０１３０】親水準では、等価オペレータ７３４及び７
３８は、データオブジェクト７１２を、階層オペレータ
７２６の入力ポート７３０及び７３６に夫々結合するた
めに供給される。等価オペレータ７３４及び７３８は、
箱オペレータ７１０の結果のデータオブジェクト７１２
における値を、ＩＯポート７３０及び７３６の入力デー
タオブジェクト７３０Ａ及び７３６Ａと夫々同等視す
る。従って、箱オペレータの結果が、等価オペレータ７
３４を経由してＩＯポート７３０まで渡され、ＩＯポー
ト７３０は順次、等価オペレータ７３０Ｂを介して結果
をデータオブジェクト７３２に渡して、結果が上面オペ
レータ７１４によって作用されるようにする。同様に、
この結果もまた、等価オペレータ７３８を経由してＩＯ
ポート７３６まで渡され、ＩＯポート７３６は順次、等
価オペレータ７３６Ｂを介して結果をデータオブジェク
ト７４０に渡して、結果がさら穴オペレータ７１６によ
って作用されるようにする。

【０１３１】以上のことからわかるように、さら穴階層
オペレータの範囲内に、データオブジェクト７３２及び
７４０のための個別のＩＯポート７３０及び７３６を作
成することにより、これらの２つの内部データオブジェ
クトが階層外側で、同じデータオブジェクトに接続され
ることを必要とせずに、階層オペレータが、デザインの
他の部分でコピーされ、かつ、複製される。

【０１３２】階層オペレータ７２６もまた、階層オペレ
ータ７２６からデータを出力する２つの出力ポート７４
０及び７４２を含んでいる。これらのＩＯポートは、デ
ータオブジェクト７４０Ｂ、７４２Ｂと、これらのデー
タオブジェクトを、データオブジェクト７２４によって
表示されるさら穴オペレータ７１６の結果と同等視する
等価オペレータ７４０Ａ、７４２Ａを夫々含んでいる。
２つのＩＯポートはさら穴オペレータ７１６から結果を
出力するために使用される。これは、このオペレータが
階層オペレータ７２６のための結果を定義するからであ
る。第１のＩＯポート７４０は、階層からオペレータ７
１６の結果の出力専用であり、オペレータ７１６の結果
がもはや階層オペレータの結果を表示しないように、階
層オペレータが変更されても、この結果を出力する。反
対に、ＩＯポート７４２は、階層オペレータの結果の出
力専用なので、変更が階層オペレータに内部的になされ
て、他の内部オペレータが階層オペレータの結果を生む
結果となる場合、ＩＯポート７４２は、階層オペレータ
の新しい結果を出力するために変更され、オペレータ７
１６の結果は出力されない。

【０１３３】簡単な例により、階層オペレータのための
個別のＩＯポートを供給するという利点が示される。図
２３及び図２４で示される例は、非常に簡単な依存関係
グラフを示し、かなり複雑なグラフが展開されることが
理解される。例えば、さら穴階層オペレータ７２６の結
果が、さら穴を有する箱の重量を計算する図２で示され
るオペレータ１９のような他のオペレータへの入力とな
る。前述したように、階層オペレータはユーザーによっ
て変更できる。例えば、ユーザーはまず、図２５及び図
２６に示す方法で、さら穴階層オペレータ７２６を定義
し、オペレータ７１６（図２４）から出力され、かつ、
データオブジェクト７２４によって表示されるさら穴を
有する箱の重量を計算しようとする。しかしながら、例
えば、箱に第２のさら穴を作成することにより、ユーザ
ーはさら穴階層オペレータを後で変更してもよい。２つ
のさら穴を有する箱を作成するオペレータ７１４〜７１
６と類似する一連の新しいオペレータへの入力として、
データオブジェクト７２４によって表示されるオペレー
タ７１６の結果を使用することで、この変更がなされ
る。このように、さら穴階層オペレータ７２６が変更さ
れると、重量計算オペレータへ出力される階層オペレー
タの結果は、もはやオペレータ７１６の結果ではなく、
むしろ、第２のさら穴を供給するこれに続くオペレータ
の結果となる。従って、結果のＩＯポート７４２は、階
層オペレータの結果として第２のさら穴オペレータの結
果を出力するために変更できる。しかしながら、デザイ
ンの他の部分は、第１のさら穴オペレータ７１６の結果
もまた出力されることを要求できる。このため、異なる
ＩＯポート結果を作成することで、ちょうど階層オペレ
ータの範囲内で変更がなされたときに、階層オペレータ
の結果が常に出力されることが保証されると同時に、階
層境界外側のデザインの他の部分によって使用される階
層オペレータの範囲内で、中間のオペレータの結果もま
た出力されることが保証される。

【０１３４】図２４に示される実施の形態では、入力及
び出力ポートに供給されるオペレータは、全て等価オペ
レータである。しかしながら、特に出力ポートには、異
なるタイプのオペレータを使用できることが理解され
る。これは、階層オペレータの結果が階層外側に位置す
る依存関係グラフのオペレータに供給されるように、付
加的な適応性を供給するものである。

【０１３５】図２２の例を参照すると、さら穴階層オペ
レータの出力が、さら穴を有する箱を定義するアプリケ
ーションエンティティである。階層外側の依存関係グラ
フにおけるオペレータは、さら穴を有する箱に関する情
報の部分だけを受け取ることできる。例えば、他のオペ
レータは箱の一面だけを要求できる。この場合、階層オ
ペレータの結果のポート用のオペレータ７４２Ａが変更
されて、さら穴を有する箱を階層外側に単に渡すのでは
なく、むしろ、所望の箱の面を決定し、これを階層外側
のオペレータにソースする。

【０１３６】上記能力を供給するには、階層オペレータ
の出力ポートは、図２４に示される本発明の一つの実施
の形態におけるオペレータとデータオブジェクトとを含
んでいる。しかしながら、代わりに、出力ポートは、出
力される結果を表示するデータオブジェクト（例えば、
図２４におけるデータオブジェクト７２４）から単に形
成するだけでもよく、オペレータと付加的なデータオブ
ジェクトとを含む必要はないことが理解される。しかし
ながら、このような方法は前述の有用な能力を供給する
ものではない。

【０１３７】階層オペレータ用の入力ポートにおけるオ
ペレータは、一般的には等価オペレータである。このた
め、代わりに、各入力ポートは、単に階層オペレータに
入力されるデータ入力を受け取るデータオブジェクト
（例えば、図２４におけるデータオブジェクト７３２）
として提供できる。しかしながら、図２４に示される本
発明の実施の形態では、入力ポートもまた、付加的なデ
ータオブジェクト及びオペレータと共に実行されるの
で、入力及び出力ポートは、一貫した方法で定義され
る。

【０１３８】前述したように、階層オペレータがデザイ
ンの範囲内でコピーされ、かつ、複製されたとき、階層
オペレータの各段階は、依存関係グラフにおけるその環
境に依存する異なる一組の入力及び出力ポートを有す
る。異なる組のＩＯポートは、階層オペレータの異なる
段階へ、及び、その段階から異なる内部データオブジェ
クトをポートする。さらに、同じデータオブジェクトを
出力する階層オペレータの２つの段階は、それらの夫々
の出力ポートに異なるオペレータを含むことができる。
例えば、図２４に示されるさら穴階層オペレータの一方
の段階が、さら穴を有する箱を表示するアプリケーショ
ンエンティティが出力されるように、その結果の出力ポ
ート７４２に等価オペレータを含むことができるのに対
し、他方の段階は、前述したような箱の一面だけを出力
するオペレータを含むことができる。

【０１３９】ＩＯポートの作成とポートのＩＯ＿ＯＰリ
ストの更新によって、階層オペレータの範囲内のどのデ
ータオブジェクトが入力されかつ出力されるかの決定
は、グラフマネージャー７５（図５）によってなされ
る。この決定は、どのデータオブジェクトが階層境界の
外側のグラフの部分に接続されるかに基づいている。階
層オペレータの外側でスコープされるデータオブジェク
トに関し、これらの他のグラフ要素との関係は、階層オ
ペレータを含む親ファンクションによって定義される。
前述したように、階層オペレータは、多数の水準を介し
て入れ子構造にされる。それゆえ、階層オペレータの出
力は、より大きな階層オペレータの範囲内の他のグラフ
要素に接続できる。この場合には、より大きな階層オペ
レータは、より大きな階層オペレータの範囲内の他のグ
ラフ要素に対するより低水準の階層オペレータからスコ
ープされるデータオブジェクトの関係を定義する親ファ
ンクションとしての役割を実行する。階層オペレータか
らスコープされた出力が、他の階層オペレータの部分を
形成しないようなデザインの最上位水準にある場合、デ
ザインの根は、階層オペレータからスコープされたデー
タオブジェクトが他のグラフ要素に接続される方法を定
義する親ファンクションとしての役割を実行する。

【０１４０】前述したように、各階層オペレータ用のＩ
Ｏ＿ＯＰとＩＯポートは、グラフマネージャー７５（図
５）によって作成され、かつ、管理される。ＩＯ＿ＯＰ
は、グラフエンティティとして実行され、かつ、依存関
係グラフにおけるその対応する階層オペレータへのポイ
ンタを含んでいる。グラフの階層オペレータは、同様に
その対応するＩＯ＿ＯＰへのポインタを含んでいる。Ｉ
Ｏ＿ＯＰは、階層オペレータへ入力され、かつ、そのオ
ペレータから出力されるデータオブジェクトを表示する
ＩＯポートのリストを含んでいる。従って、ＩＯ＿ＯＰ
は、階層オペレータのためのリレーションの収集として
の役割を実行する。ＩＯポートそれ自身は、それらのリ
レーションを定義する。

【０１４１】１．階層的ＡＡＰＩ 本発明の結合サブシステムは、階層オペレータの使用を
支援する複数のＡＡＰＩを供給する。前述したように、
階層オペレータは、２つの方法のうちの一方で用いられ
る。第１に、ユーザーは好ましい方法で、自分自身の階
層オペレータを作成する。このためには、ユーザーは、
後述の支援ＡＡＰＩを単に用いて、階層オペレータを作
成する。第２に、本発明の結合サブシステムがインスト
ールされているソフトウェアシステムもまた、支援ＡＡ
ＰＩを呼び出して、後述するような１つ以上のサブコマ
ンドを含むコマンドの周囲で、階層オペレータを実行す
る。

【０１４２】３つの基本的なＡＡＰＩが、階層オペレー
タを支援するために供給される。第１のものは、階層オ
ペレータをオープンする。少なくとも１つの階層オペレ
ータがオープンされているとき、その階層がデザインに
引渡されるまでは、デザインに加えられる全ての依存関
係グラフの要素が、最新にオープンされた階層オペレー
タの範囲内に含まれる。いったん階層が引渡されると、
階層が再びオープンされるまでは、階層オペレータがク
ローズされ、新しい依存関係グラフ要素がその階層に加
えられない。階層オペレータを支援する第２のＡＡＰＩ
は、階層引渡しコマンドであり、これは、前述したよう
な方法で最新にオープンされた階層をデザインに引渡
す。最後に、階層中止ＡＡＰＩもまた、最新にオープン
された階層オペレータの作成を中止するために供給され
る。中止コマンドを受け取ったとき、最新にオープンさ
れた階層は作成されず、最新にオープンされた階層のオ
ープンに続いて加えられるグラフ要素の夫々が、階層的
な方法で集められずに、グラフ要素のグループとしてだ
けデザインに加えられる。

【０１４３】前述したように、本発明は階層オペレータ
を入れ子構造にすることを可能にする。従って、階層オ
ペレータのオープンに続いて、１つ以上の付加的な階層
オペレータが、前もってオープンされた階層オペレータ
をクローズする前にオープンされる。従って、階層引渡
しコマンドを受け取るたびに、最新にオープンされた階
層がクローズされる。階層引渡しコマンドを、階層オー
プンコマンドまで追跡することで、多数の入れ子構造に
された階層オペレータが作成される。グラフマネージャ
ーは、現在オープンしている階層オペレータの先入れ後
出し(first-inlast-out) スタックを持続する。従っ
て、階層引渡しコマンド或いは階層中止コマンドが受け
取られたとき、スタックに付加された最新にオープンさ
れた階層オペレータが、夫々、完全な階層オペレータと
してデザインに引渡されるか、或いは、デザインから取
り除かれて、あたかも最新にオープンされた階層オペレ
ータが決してオープンされなかったかのように、その階
層のオープンに続いて加えられたグラフ要素が単にデザ
インに加えられる。中止コマンドが受け取られたとき、
他の階層オペレータがスタック上で現在オープンしてい
る場合、その後グラフに引渡されたとき、グラフ要素は
その階層オペレータの一部として、単にグラフに付加さ
れる。

【０１４４】デザインセッションが開始されたときには
いつでも、最上位水準の階層オペレータは、自動的に作
成されて、グラフマネージャースタックにプッシュされ
る。この最上位水準の階層オペレータは、デザインセッ
ション中に作成されるデザイン全体のための根を表示す
る。前述したように、このデザインの根は、デザイン水
準での階層オペレータの次の上位水準と非階層オペレー
タとの間の関係を定義する親のファンクションとしての
役割を実行する。

【０１４５】中止コマンドは、ユーザーにゴール指向ア
クティビティに関してユーザーの意向を変更する適応性
を提供する。同様に、このコマンドもまた、本発明の結
合サブシステムがインストールされたソフトウェアシス
テムによって用いられる。ソフトウェアシステムが本発
明の階層オペレータの能力を実行しようとするとき、階
層的な方法で一般的に使用される固有ＡＰＩに対応する
ＡＡＰＩが、それらの固有コマンドの１つがユーザーに
よって入力されるたびに、階層オペレータをオープンす
るコマンドを呼び出す。しかしながら、ユーザーは完了
前に、階層的なコマンドを終了することができる。この
場合には、ソフトウェアシステムは、固有コマンドのた
めにオープンされる階層オペレータの作成を中止する中
止コマンドを用いることができる。

【０１４６】２．オペレータの引渡 デザインに引渡された階層に加えて、ユーザーコマンド
に応じて作成された各オペレータもまた、正確に実行す
る場合には、デザインに引渡される。オペレータをデザ
インに引渡すとき、グラフマネージャーは次の３つの基
本的なステップを実行する。

【０１４７】(1) オペレータを処理する (2) オペレータの出力を処理する (3) オペレータの入力を処理する これらのステップは、図２５〜図２８のフローチャート
に表示される。オペレータがデザインに引渡されると、
グラフマネージャーはまず、図２５のフローチャートで
示されるオペレータ引渡しルーチンを実行する。ステッ
プ６１０において、本方法はデザインに引渡されるオペ
レータがあるか否かを判定し、オペレータがあれば、本
方法は、ステップ６１２に進み、オペレータが引渡され
る目標のオペレータがあるか否かの判定がなされる。こ
れらの２つのステップは、エラーチェックをするための
ものである。前述したように、デザインセッションが開
始されるときはいつでも、デザインの根を表示する階層
オペレータが自動的にオープンされて、グラフマネージ
ャースタックにプッシュされる。従って、オペレータ引
渡しルーチンが呼び出され、かつ、引渡されるオペレー
タがないか、或いは、オペレータが引渡される目標のオ
ペレータがない場合には、エラー状態が発生し、本方法
はステップ６１４に進み、エラーメッセージをユーザー
に供給し、その後終了する。

【０１４８】エラー状態が発生しないときは、本方法は
ステップ６１６に進み、デザインに引渡されるオペレー
タがグラフマネージャースタックからポップされる（即
ち、読まれる）。ステップ６１８では、スタック上の次
のオペレータが、ステップ６１６でスタックからポップ
されたオペレータが引渡される目標のオペレータとして
確認される。最後に、ステップ６２０では、このルーチ
ンが、図２６に示されるオペレータ付加ルーチンを呼び
出して、ルーチンへの引数として供給されるステップ６
１６でスタックからポップされたオペレータと共に、目
標のオペレータに作用する。

【０１４９】図２５及び図２６で示される一つの実施の
形態では、デザインへのオペレータの引渡しは、それが
引渡される目標の階層オペレータによって一部制御され
る。前述したように、デザインに付加された各オペレー
タは、デザイン自身の根の一部としてか、或いは、デザ
インにおけるより低水準の階層オペレータの一部として
付加される。従って、オペレータがデザインに付加され
たとき、オペレータ付加ルーチンは、引数として引渡さ
れたオペレータを受け取り、そのオペレータが引渡され
る階層オペレータと関連して呼び出される。

【０１５０】ステップ６２２では、オペレータ付加ルー
チンは、引数として渡されたオペレータを処理して、依
存関係グラフにおいて余分の階層が作成されないことを
保証する。前述したように、本発明の結合サブシステム
がインストールされたソフトウェアシステムは、本発明
の階層的な能力を利用する。従って、階層的な方法で一
般的に使用されるソフトウェアシステムにおけるコマン
ドに関し、ソフトウェアシステムは、コマンドのための
対応ＡＡＰＩにコマンドを受け取ったときはいつでも、
新しい階層をオープンさせることができる。例えば、図
２１〜図２４と関連して説明されたさら穴のコマンド
は、一般的に、サブコマンドで実行され、さら穴が設け
られる立体の面を確認する。従って、さら穴のコマンド
が実行されると、そのコマンドに関連して一般的に使用
される多数のサブコマンドを受け取ることを見越して、
階層がオープンされる。しかしながら、ユーザーが予期
したコマンドを実行しないと、不必要な階層が作成され
る可能性がある。例えば、ユーザーがサブコマンドを使
用せずにさら穴のコマンドを単に実行して、立体の面を
定義すると、さら穴のコマンドのために作成された階層
は、さら穴オペレータ７１６の周囲に単独で作成され
る。この階層は、単一のオペレータを含んでいるので、
不必要である。

【０１５１】オペレータ付加ルーチンのステップ６２２
の間に実行されるオペレータ処理ファンクションは、こ
のような不必要な階層を確認して、取り除く。階層が取
り除かれると、取り除かれた階層に属するものとして前
もって確認されたオペレータの夫々は、ステップ６２２
でグラフマネージャースタックにプッシュされて、その
ルーチンがオペレータ付加ルーチンのステップ６２６の
間に呼び出されたときに、後述するオペレータ引渡しル
ーチンのステップ６１６の間に、グラフに引渡される。

【０１５２】本発明の一つの実施の形態では、ステップ
６２２の処理ファンクション用のデフォルトオプション
は、単一のオペレータの周囲に作成された階層を取り除
くためのものである。従って、前述した一例では、オペ
レータ７１６の周囲に単独で作成された階層が取り除か
れる。しかしながら、本発明の結合サブシステムがイン
ストールされたソフトウェアシステムには、このデフォ
ルトを無効にする能力が供給され、単一のオペレータで
あってもその周囲に階層を作成することを選択できる。
さらに、デフォルトは、有効な階層オペレータを形成す
るために含まれる最少数のオペレータを確立すべく変更
される。このように、ソフトウェアシステムには、階層
が作成される方法を制御する適応性が供給される。

【０１５３】オペレータが処理された後で、オペレータ
付加ルーチンはステップ６２４へと進み、ステップ６２
２の間にオペレータ階層が消失したか否かが判定され
る。階層が消失したとき、本方法はステップ６２６へと
進み、ステップ６２４で消失した階層にあった各オペレ
ータのために、図２５のオペレータ引渡しルーチンが呼
び出される。それらのオペレータは、ステップ６２２の
間にグラフマネージャースタックにプッシュされている
ので、ステップ６１６（図２５）でオペレータ引渡しル
ーチンによって処理されるときに、前述した方法でスタ
ックからポップされる。このように、階層オペレータが
消失するときはいつでも、ステップ６２６の実行が、消
失した階層の範囲内のより低水準のオペレータの夫々が
デザインに引渡されることを保証する。

【０１５４】ステップ６２２で階層オペレータが消失さ
れなかったと、ステップ６２４で判定されると、オペレ
ータ付加ルーチンはステップ６２８へと進み、図２７の
入力処理ルーチンを呼び出す。入力処理ルーチンの目的
は、依存関係グラフにおける階層の水準を介してそれら
の入力をスコープすることで、階層オペレータを処理す
ることである。前述したように、階層境界を横切る夫々
の入力のためのＩＯポートを作成し、その入力を供給す
るグラフの親水準においてＩＯポートをデータオブジェ
クトに接続する階層の外側に等価オペレータを作成する
ことで、これが達成される。従って、依存関係グラフに
引渡されるオペレータのための入力処理ルーチンは、新
たに引渡されるオペレータを含む階層オペレータを必要
とする入力ポートを作成する。

【０１５５】入力処理ルーチンは、まず、ステップ７５
０において、処理するために引渡されたオペレータの第
１の入力を選択する。ステップ７５２では、選択された
入力のためのソースデータオブジェクトが同じ階層にあ
るか否か、即ち、データオブジェクトのソースがオペレ
ータが引渡される目標の階層にあるか否か判定される。
ソースデータオブジェクトが同じ階層にあるとき、選択
された入力は、階層からスコープされる必要はなく、そ
れゆえ、入力は更に処理される必要がない。このため、
本方法はステップ７８８へと直接進み、処理されるべき
付加的な入力が残っているか否か判定される。付加的な
入力が残っているとき、本方法はステップ７５０に戻
り、処理すべき他の入力を選択する。引渡されたオペレ
ータのための処理すべき入力が残っていないと判定され
ると、本手順は終了する。

【０１５６】ステップ７５０において処理のために選択
された入力とそのソースデータオブジェクトが同じ階層
にないと、ステップ７５２で判定されると、本方法はス
テップ７５４へと進み、オペレータが引渡される目標の
階層オペレータの範囲内で、新しいデータオブジェクト
が選択された入力のために作成される。このようなデー
タオブジェクトの一例は、図２４におけるデータオブジ
ェクト７３２である。新しいデータオブジェクトを作成
することで、ソースデータオブジェクトを、引渡される
オペレータの選択された入力に接続する関係が、目標の
オペレータの階層境界を横切らないことが保証される。

【０１５７】ステップ７５６では、階層の親のリスト
が、引渡されたオペレータのために生成される。階層の
親のリストは、引渡されたオペレータのための先祖ツリ
ーに類似しており、それらの階層的な関係はもちろん、
引渡されたオペレータが属する階層の夫々を確認する。
階層的な親のリストは後述の方法で、ルーチンによって
使用されて、その階層的な水準で等価オペレータ（例え
ば、図２４におけるオペレータ７３４及び７３８）が選
択された入力を、そのソースデータオブジェクトに接続
するために供給されることを決定する。

【０１５８】本方法は次にステップ７５８に進み、ソー
スデータオブジェクトを生成するオペレータが確認さ
れ、ステップ７６０で、そのオペレータのための階層の
親のリストが生成される。ステップ７６２では、引渡さ
れたオペレータのための親のリストが、ソースオペレー
タのための親のリストに対して比較されて、両者に共通
した最も低い先祖の階層を確認する。この階層的な水準
は、ソースデータオブジェクトと選択された入力との間
の等価オペレータ作成のための目標の親水準として示さ
れる。これら２つを含む他の階層水準は、選択された入
力のスコープを必要としない。なぜならば、選択された
入力とそのソースデータオブジェクトとの間の接続が、
目標の水準の階層オペレータの内部となるからである。
しかしながら、ルーチンは、目標の水準及びそれより低
い水準で階層オペレータから選択された入力をスコープ
して、選択された入力とそのソースデータオブジェクト
との間の関係が、階層境界を横切らないことを保証す
る。

【０１５９】ステップ７６４では、引渡されたオペレー
タのための最低の階層水準、例えば、引渡されたオペレ
ータが引渡される階層オペレータ、を処理すべく選択す
る。ステップ７６６では、現在処理される階層水準が目
標の水準であるか否か判定される。現在処理される水準
が目標でないとき、本方法はステップ７６８へと進み、
ＩＯポートが作成されて、現在処理される水準で、階層
オペレータから選択された入力を出力する。次に、本方
法はステップ７７０に進み、処理のため次の階層水準へ
と進み、その後、ステップ７６６に戻る。このように、
本方法は、目標の水準が達成されたとステップ７６６で
判定されるまで、目標の水準より低い全ての階層水準で
引渡されたオペレータの選択された入力のためのＩＯポ
ートを作成するためにステップ７６６〜７７０を実行す
る。

【０１６０】現在処理される水準が目標の水準であると
ステップ７６６で判定されたとき、本方法はこの水準で
ＩＯポートを作成するステップ７６８には進まない。な
ぜならば、前述したように、目標の水準は選択された入
力とソースデータオブジェクトとの両者を含むので、そ
の入力のスコープを必要としないからである。むしろ、
目標の水準がステップ７６６において検出されたとき、
本方法はステップ７７４（図２８）へと進み、ソースオ
ペレータの処理が開始される。

【０１６１】階層オペレータから供給されたとき、本方
法は、引渡されたオペレータの選択された入力に接続す
るために、階層オペレータの階層からの結果のデータオ
ブジェクトをスコープする前述したステップに類似する
複数のステップを実行する。特に、ステップ７７４で
は、本方法は処理のためのソースオペレータの最低の階
層水準を選択し、その後、ステップ７７６に進んで、現
在処理される階層水準が目標の水準であるか否かを判定
する。ソースオペレータが階層的ではないとき、その最
低水準が目標の水準となる。現在処理される階層水準が
目標の水準ではないとステップ７７６で判定されると、
本方法はステップ７７８へと進み、ＩＯポートが作成さ
れて、現在処理される水準で階層オペレータから結果の
データオブジェクトを出力する。次に、本方法はステッ
プ７８０に進み、処理のための次の階層水準に進み、そ
の後、ステップ７７６へと戻る。このように、目標の水
準が達成されたとステップ７７６で判定されるまで、本
方法は目標の水準とそれ以下の夫々の水準で、ソースデ
ータオブジェクトのためのＩＯポートを作成するために
ステップ７７６〜７８０を実行する。

【０１６２】現在処理される水準が目標の水準であると
ステップ７７６で判定されると、本方法はこの水準でＩ
Ｏポートを作成するステップ７７８には進まない。なぜ
ならば、前述したように、目標の水準は選択された入力
とソースデータオブジェクトの両者を含み、それゆえ、
ソースデータオブジェクトのスコープを必要としないか
らである。

【０１６３】目標の水準がステップ７７６で検出される
と、本方法はステップ７８４へと進み、等価オペレータ
（例えば、図２４におけるＥＱＯＰｓ７３４及び７３
８）が目標の水準で作成される。等価オペレータの一端
は、目標のすぐ下位にある階層水準で引渡されたオペレ
ータの選択された入力のために作成されたＩＯポートに
接続され、他端が目標の水準でソースを表示するデータ
オブジェクトに接続される。ソースオペレータが階層的
であるとき、この接続は目標のすぐ下位にある水準でソ
ースデータオブジェクトのために作成されたＩＯポート
になされる。

【０１６４】等価オペレータがステップ７８４で作成さ
れた後、本方法はステップ７８６へと進み、等価オペレ
ータが目標の水準のデザインに引渡される。本方法はそ
の後、ステップ７８８（図２７）へと進み、引渡された
オペレータの入力が処理のために残っているか否か判定
される。付加的な入力が残っていると判定されると、本
方法はステップ７５０へと戻り、次の入力が処理のため
に選択される。このように、本方法が終了する時点であ
る、全ての入力が処理されたとステップ７８８で判定さ
れるまで、本方法は引渡されたオペレータの入力の夫々
のスコープを実行する。

【０１６５】入力処理ルーチンに戻った後、オペレータ
付加ルーチンが、ステップ６３０（図２６）に進み、オ
ペレータが引渡されている結果を処理する。オペレータ
が階層オペレータである場合、結果の処理はその結果の
ＩＯポートがオペレータの出力を正確に反映することを
保証するために実行される。例えば、図２４の依存関係
グラフと関連して説明したように、階層オペレータ７２
６は、さら穴を有する箱を表示するアプリケーションエ
ンティティである結果を生ずる。しかしながら、さら穴
階層オペレータの範囲内での変更は、例えば、付加的な
さら穴を加えることで、階層オペレータの結果を変える
ことができる。夫々の階層オペレータは、その内部のオ
ペレータを指す結果のオペレータポインタを保持し、こ
れが実行されたとき、全体の階層オペレータの結果をも
たらす。このオペレータは、単に、階層オペレータの結
果であるデータオブジェクトを指す結果のＩＯポート
（例えば、図２４におけるオペレータ７２４Ａ）におけ
る等価オペレータである。新しいオペレータが階層に付
加され、その結果が階層オペレータの結果となるとき、
階層オペレータの結果の処理は、結果のオペレータの入
力関係が新たに付加されたオペレータの結果を指すため
に調整される。

【０１６６】異なる階層オペレータは、それらの出力が
階層オペレータの結果を定義するために処理される方法
に関しては、異なるようにふるまう。例えば、多くの階
層オペレータに関しては、最後のオペレータ（例えば、
依存関係グラフの右端の１つ）が階層の結果を定義でき
る。しかしながら、いくつかの階層オペレータに関して
は、これは当てはまらない。例えば、図２３のさら穴階
層オペレータ７２６から出力される箱のような製作品を
生み出す階層オペレータに関しては、階層オペレータの
結果は常に製作品である。従って、たとえ他のオペレー
タが階層オペレータに付加され、製作品に作用（例え
ば、箱の重量を計算する）するとしても、製作品は階層
オペレータの結果である。本発明の一つの実施の形態で
は、デフォルト状態が設けられており、これは、最新に
階層に引渡されたオペレータの結果であるデータオブジ
ェクトを指す階層オペレータの結果のオペレータを生じ
る。しかしながら、このデフォルトは、特定の階層オペ
レータの作成に際して、ユーザー或いはソフトウェアシ
ステムによって無効にすることができる。

【０１６７】前述したように、階層的な方法でコマンド
をまとめるソフトウェアシステムに供給される能力は、
一連のサブコマンドと共にひとまとめにされるコマンド
と関連して使用される。例えば、前述したさら穴のコマ
ンドは、複数のサブコマンドと共に一般的に実行され
て、例えば作用されている立体の面を定義する。ユーザ
ーインタフェースは、その関連するサブコマンドがユー
ザーから受け取られるまで、より高水準のコマンドを一
般的には実行しない。従って、高水準のコマンドのサブ
コマンドの全てが受け取られるまで、本発明のオペレー
タ引渡しルーチンは、高水準のコマンド（例えば、さら
穴のオペレータ７１６）に対応するオペレータに引渡す
ために呼び出されない。それゆえ、高水準のコマンドが
ユーザーから始めに受け取られたとき、新しい階層がオ
ープンされ、階層はサブコマンドの夫々が実行されるま
では引渡されない。このように、コマンドは階層オペレ
ータにおいてそのサブコマンドと共にまとめられる。

【０１６８】以上のことからわかるように、各高水準の
コマンドのためのデザインにオペレータが引渡されるの
で、階層的なブロックにおける高水準のコマンドと関連
付けられるサブコマンドのグループを定義するソフトウ
ェアシステムの前述した能力が、１つより多い高水準の
コマンドをひとまとめにするため用いられることによっ
て、特にそのコマンドのためにオープンされる階層をク
ローズする。しかしながら、前述したように、この能力
はユーザーに供給されて、ユーザーが複数の高水準のコ
マンドを含む階層を含む階層的なグループを所望の方法
で指定できるようにする。

【０１６９】XII.インタラクティブ依存関係処理 上述のように、本発明の一つの実施の形態では、ユーザ
ーがデザインの依存関係表示と相互に作用してデザイン
を作成したり、既存のデザインを変更したりすることが
できる能力が提供される。例えば、デザインのこのグラ
フ表示と相互に作用することがユーザーにとってより速
くかつより容易になるということが理解される。

【０１７０】図３に示すように、本発明の結合サブシス
テムがソフトウェアシステム上にインストールされた場
合、そのシステムにはインタプリタ５２が与えられる。
インタプリタ５２は、テキストウィンドウを含み、この
テキストウィンドウは、ソフトウェアシステムのディス
プレイスクリーン上に表示でき、また、それによってイ
ンタプリタがユーザーからのテキストＡＡＰＩを受け取
ることができる。インタプリタ５２は、テキストＡＡＰ
Ｉ表示を変換し、システム上の対応するＡＡＰＩ４２を
呼び出して、テキストＡＡＰＩ表示によって指定された
デザイン動作を行う。このように、インタプリタテキス
トウィンドウは、テキストＡＡＰＩ表示を用いた本発明
による依存関係グラフを作成、あるいは編集するために
使用できる。

【０１７１】上述した図３の説明に関連して、依存関係
グラフを図表的に編集する本発明の具体例が使用される
場合、システムは、また、依存関係グラフを図表的に編
集するのに用いる視覚的なプログラミング環境５０も与
えられる。依存関係グラフの図表的な編集を支援するた
めの本発明の能力は、特定の視覚的なプログラミング環
境に限られるものではなく、本発明は、その幾つかは商
業的に利用されているような任意のタイプの視覚的なプ
ログラミング環境で使用することが可能である。

【０１７２】図３に示すように、視覚的なプログラミン
グ環境５０はインタプリタ５２と結合し、インタプリタ
５２は、順次、システムの結合ＡＰＩ４２と結合する。
視覚的なプログラミング環境５０は、視覚的環境中でユ
ーザーによって行われる動作をインタプリタと互換性の
ある語句に変換する。このようにインタプリタは、視覚
的なプログラミング環境５０の言語とソフトウェアシス
テム上の結合ＡＰＩ４２との間を変換するパーザ（pars
er) として動作する。インタプリタ５２は、分解される
有効なワードを定義する辞典を、その辞典を与える支援
的な文法ルールと同様にして設定する。インタプリタが
操作するシステム上のＡＰＰＩ４２は、階層的オペレー
タを支援するために用いられる上記３つのＡＡＰＩと同
様に、ソフトウェアシステム中の各固有ＡＰＩ周辺にラ
ップされたＡＡＰＩを含む。ユーザーが視覚的なプログ
ラミング環境中でいくつかの動作を行う場合、インタプ
リタ５２は、視覚的なプログラミング環境５０から受け
取った語句を分解し、依存関係グラフ中でユーザーのデ
ザイン動作を実行するために正しくフォーマットされた
引数と共に、対応するＡＡＰＩを呼び出す。インタプリ
タは、相互に作用する視覚的なプログラミング環境の中
に統合されて、インタプリタによって分解される語句
が、ユーザーがシステムキーボードあるいは他の入力装
置を通してコマンドをタイプした結果として受け取られ
るようにする。

【０１７３】インタプリタテキストウィンドウまたは視
覚的なプログラミング環境５０から語句が受け取られた
ときに必ずインタプリタによって実行されるソフトウェ
アルーチンが、図２９のフローチャートに図示される。
ステップ９００では、インタプリタが受け取った語句を
分解して、その語句で参照されるＡＡＰＩの名前を判定
する。次に、本方法はステップ９０１に進み、インタプ
リタスタックがクリアされる。このインタプリタスタッ
クは、後述する方法で使用されて、インタプリタルーチ
ンの再帰的な実行の間、サブコマンドの実行による引数
を受け取る機能コマンドについての結果の値を記憶す
る。このようにインタプリタスタックに記憶された結果
の値は、サブコマンドに関連して実行されたＡＡＰＩの
結果を示し、また、再帰的ルーチンを最初に呼び出す機
能コマンドのためのＡＡＰＩを呼び出す際に、引数を与
えるために使用される。スタックは、インタプリタルー
チンの実行について１回の再帰的サイクル中だけ使用さ
れる。しかしながら、再帰的サイクルが完了すると、そ
のルーチンはスタックをクリアすることなしに元に戻る
ことができる。従って、スタックはルーチンの最初のス
テップ９０１でクリアされて、その結果、そのルーチン
がサブコマンドを使用しない２つのコマンドについて連
続的に呼び出され、このため、インタプリタルーチンを
再帰的に実行しない場合には、後述するステップ９１０
において引数がスタック上で検出されない。

【０１７４】スタックがクリアされた後、本方法はステ
ップ９０２に進み、ステップ９００において分解された
ＡＡＰＩの引数が確認される。引数は、図５に関連して
上述したハッシュテーブル７３にアクセスすることによ
って確認され、ハッシュテーブル７３は各ＡＡＰＩのエ
ントリーを含み、各ＡＡＰＩは、それぞれの引数、およ
び実行のためＡＡＰＩが呼び出されたときにそれらの引
数が与えられる順序を確認する。

【０１７５】ステップ９０４では、ステップ９０２で確
認された引数を、ＡＡＰＩが呼び出されたときに与えら
れる引数の順序リストの第１の引数として選択し、そし
て本方法はステップ９０６に進み、選択された引数に対
してデータ値を与えるためにサブコマンドが実行される
べきかどうかの判定が行われる。この判定は、引数のリ
ストを分解することによって行われる。引数がＡＡＰＩ
の名前を含むならば、その引数はサブコマンドによって
与えられる。ステップ９０６でサブコマンドが実行され
るべきと判定された場合には、本方法はステップ９０８
に進み、引数の値を生じるＡＡＰＩの名前を使用してイ
ンタプリタルーチンが再度呼び出される。

【０１７６】ステップ９２６〜９２８に関連して後述す
るように、インタプリタルーチンがＡＡＰＩを処理する
ために呼び出される場合、そのルーチンの最新の２つの
ステップは、そのＡＡＰＩを実行して、インタプリタテ
キストウィンドウまたは視覚的なプログラミング環境か
ら受け取った語句で指定されたデザイン動作を実行し、
そして、この実行結果をインタプリタスタック上にプッ
シュする。このインタプリタスタックは、テキストウィ
ンドウまたは視覚的なプログラミング環境から受け取っ
た語句に応じてインタプリタルーチンの再帰的な呼び出
しの間に実行されたＡＡＰＩの結果を記憶する先入れ後
出し方式のスタックである。このように、インタプリタ
ルーチンが、ステップ９０６で確認されたサブコマンド
を処理するステップ９０８での呼び出しから戻るとき、
そのサブコマンドを実施するために実行されたＡＡＰＩ
の結果がインタプリタスタック上に記憶される。

【０１７７】インタプリタルーチンがステップ９０８で
のサブコマンドの処理から戻った場合、または、選択さ
れた引数についてサブコマンドを実行する必要がないこ
とが決定された場合には、本方法はステップ９１０に進
み、引数がインタプリタスタック上に記憶されているか
どうかについての判定が行われる。上述のように、イン
タプリタルーチンが開始したとき、スタックはステップ
９０１でクリアされる。従って、引数がインタプリタス
タック上に記憶されている場合、それはサブコマンドの
処理のために呼び出されたルーチンの反復によって引数
が与えられることを示すので、本方法はステップ９１２
に進み、引数の値がインタプリタスタックからポップさ
れる。逆に、ステップ９１０で引数がスタック上にない
ことが判定された場合には、ステップ９１４に進み、選
択された引数についての値が、インタプリタテキストウ
ィンドウまたは視覚的なプログラミング環境５０から与
えられた語句より読み取られる。

【０１７８】引数の値が、ステップ９１２でスタックか
らポップされた後、あるいは、ステップ９１４でテキス
トウィンドウまたは視覚的なプログラミング環境から読
み取られた後に、本方法はステップ９１６に進み、処理
を行うために選択された引数に値が割当てられる。そし
て、本方法はステップ９１８に進み、引数の値が、ステ
ップ９００で確認されたＡＡＰＩについて要求されたタ
イプの値であるかどうかについての判定が行われる。引
数の値が要求されたタイプでない場合には、本方法はス
テップ９２０に進み、エラーメッセージがユーザーに対
して与えられ、そして、本方法が終了する。このよう
に、ユーザーは受入れ可能なタイプに引数の値を再定義
する機会を与えられる。

【０１７９】選択された引数に割り当てられた値が正し
いタイプであることがステップ９１８で判定された場合
には、本方法はステップ９２２に進み、ＡＡＰＩについ
て処理される他の多くの引数が残っているかどうかにつ
いての判定が行われる。他の引数が残っていると判定さ
れた場合には、本方法はステップ９２４に進み、ＡＡＰ
Ｉについて順序付けられた引数のリスト中の次の引数
が、処理を行うために選択され、そして、本方法はステ
ップ９０６に戻る。このように、ステップ９２２で全て
の引数が処理されたことが判定されるまで、ＡＡＰＩに
ついての各引数の処理が行われる。

【０１８０】全ての引数が処理されると、本方法はステ
ップ９２６に進み、ステップ９００で分解されたＡＡＰ
Ｉが、ルーチンによって正しい順序の位置に収集された
引数の値と共に呼び出される。この方法では、インタプ
リタルーチンは、インタプリタテキストウィンドウまた
は視覚的なプログラミング環境から受け取った語句によ
って要求されるデザイン動作がそのデザインとみなされ
ることを保証する。最後に、ステップ９２８で、ＡＡＰ
Ｉから戻された結果がインタプリタスタック上にプッシ
ュされて、ステップ９０８でＡＡＰＩのサブコマンドの
ためにインタプリタルーチンが呼び出された場合に、そ
の結果が上述した方法でステップ９１２においてスタッ
クから読み取られる。

【０１８１】ユーザーがデザインを作成または編集して
いるとき、本発明は、ユーザーがそのデザインの部分を
確認して、インタプリタテキストウィンドウまたは視覚
的なプログラミング環境５０を用いて表示されたデザイ
ンの部分を生成するＡＡＰＩを要求する能力を提供す
る。例えば、図２の依存関係グラフによって表示された
デザインを変更するユーザーは、箱を表示するアプリケ
ーションエンティティのディスプレイスクリーン表示を
簡単に指すことができ、また、箱を生成するＡＡＰＩに
対応するオペレータ７を含んだ図２の依存関係グラフの
部分が、視覚的なプログラミング環境を用いて表示でき
る。あるいは、インタプリタテキストウィンドウは、デ
ィスプレイスクリーンに、付随するデータ引数に加えて
コマンド "CV INSERT BOX(l,w,h,center)"のテキスト表
示が提供できるように、そのデザインの選択された部分
を生成するＡＡＰＩをテキスト表示するために使用でき
る。

【０１８２】テキストのＡＡＰＩまたはユーザーによっ
て選択された依存関係グラフ表示が表示されると、デザ
インの部分の表示は、インタプリタテキストウィンドウ
または視覚的なプログラミング環境５０を使用して変更
できる。依存関係グラフを図表的に編集することは、オ
ペレータに入力されたデータを再定義すること、または
オペレータを置き換えることを意味する。同様に、ＡＡ
ＰＩをテキスト的に編集することは、ＡＡＰＩの引数の
うちの１つを再定義すること、またはＡＡＰＩを他のＡ
ＡＰＩに置き換えることを意味する。

【０１８３】ユーザーが、編集されるデザインの部分を
表示したアプリケーションエンティティを選択した場
合、グラフマネージャー７５（図５）によって実行され
る編集ルーチンが呼び出されて、編集オペレーションを
処理する。編集ルーチンは図３０のフローチャートに示
される。まず、ステップ９３０で、本ルーチンはユーザ
ーによって編集するために選択されたアプリケーション
エンティティを確認する。次に、ステップ９３２で、本
ルーチンは、テキスト編集が実行される場合には、選択
されたアプリケーションオブジェクトに対応するＡＡＰ
Ｉを発見し、また、図表的編集が実行される場合には、
依存関係グラフ中の対応するオペレータを発見する。

【０１８４】ステップ９３４では、ステップ９３２で確
認されたＡＡＰＩまたはオペレータが、編集するために
ユーザーに提供される。編集オペレーションが、インタ
プリタテキストウィンドウまたは視覚的なプログラミン
グ環境からインタプリタを通して受け取られたとき、本
ルーチンはステップ９３６に進み、テキスト編集の間に
ＡＡＰＩが編集されているかどうかについて、また、図
表的編集の間にオペレータが編集されているかどうかに
ついての判定が行われる。ＡＡＰＩまたはグラフオペレ
ータのいずれかが編集されていることが判定される場合
には、本ルーチンはステップ９３８に進み、図２９のイ
ンタプリタルーチンが呼び出されて、新しいＡＡＰＩま
たはオペレータを処理する。上述のように、インタプリ
タルーチンは新しいＡＡＰＩについての全ての引数値を
収集し、また、そのＡＡＰＩを引数の順序リストと共に
呼び出して、ユーザーの編集によって指定されたデザイ
ン動作を実行する。インタプリタルーチンが復帰する
と、本方法はステップ９４０に進み、図３２に関連して
後述する置換オペレータルーチンが呼び出され、そし
て、本方法は終了する。ステップ９３６でユーザーがＡ
ＡＰＩまたはグラフオペレータのどちらも編集していな
いことが判定される場合には、本方法はステップ９４２
に進み、ユーザーが引数を編集したかどうかについての
判定が行われる。引数が編集されなかった場合には、本
方法は単に終了する。しかしながら、ステップ９４２に
おいてユーザーが引数を編集したと判定された場合に
は、本ルーチンは、ステップ９４４で後述する再定義入
力ルーチン（図３１）を呼び出した後に終了する。

【０１８５】再定義入力ルーチンは、図３１のフローチ
ャートによって示され、このルーチンは、図２９のイン
タプリタルーチンによって実行されるステップと同様な
いくつかのステップを実行する。まず、ステップ９４６
で、本ルーチンは上述したインタプリタスタックと同様
のスタックをクリアする。このスタックは、インタプリ
タスタックがインタプリタルーチンのステップ９０１で
最初にクリアされたのと同様の理由で最初にクリアされ
る。次に、ステップ９４８で、このルーチンは編集され
た引数を処理するために選択する。そして、本ルーチン
はステップ９４９〜９６８に進み、これらのステップ９
４９〜９６８は、図２９に関連して上述したインタプリ
タルーチンにおけるステップ９０６〜９２６と実質的に
同一である。これらステップの実行を通して、再定義入
力ルーチンは１つのＡＡＰＩについて編集された引数値
の全てを、その他の引数値と同様に収集し、そして、ス
テップ９６８でそのＡＡＰＩを引数値の順序リストと共
に呼び出して、ユーザーの編集によって要求されたデザ
イン動作を行う。その後、ステップ９７０で、本ルーチ
ンは後述する図３２の置換オペレータルーチンを呼び出
して、終了する。

【０１８６】図３０の編集ルーチンと図３１の再定義入
力ルーチンの両方で呼び出された置換オペレータルーチ
ンは、図３２に示すフローチャートによって表示され
る。置換オペレータルーチンが呼び出される前に、編集
ルーチン（図３０）のステップ９３８におけるインタプ
リタルーチンに対する呼び出しの結果として新しいＡＡ
ＰＩが実行されるか、または再定義入力ルーチン（図３
１）のステップ９６８における新しいデータと共に現行
のＡＡＰＩが再び実行される。これらの場合のいずれか
においてもＡＡＰＩの実行結果として、付加的なグラフ
要素が作成され、この付加的なグラフ要素は、新しいオ
ペレータ、そのオペレータの入力についてのリレーショ
ン、そのオペレータの出力についてのリレーション、お
よび新しい結果データオブジェクトを含んでいる。置換
オペレータルーチンの目的は、依存関係グラフを掃除し
て、ユーザーのデザイン編集を正確に反映することであ
る。

【０１８７】初めに、ステップ９７２で、置換される古
いオペレータの結果データオブジェクトにどのグラフ要
素が依存するかについての判定が行われる。古いオペレ
ータの結果に依存するものが依存関係グラフ中にないと
判定された場合には、本方法はステップ９７３に進み、
古いオペレータの結果データオブジェクトが依存関係グ
ラフから削除され、そしてステップ９８４で、古いオペ
レータもまた削除される。この方法では、依存関係グラ
フが、ユーザーによって行われた編集を反映するために
更新される。

【０１８８】ステップ９７２で、いくつかのグラフ要素
が古いオペレータの結果に依存することが判定された場
合には、本方法はステップ９７４に進み、新しいオペレ
ータによって生じた結果が、古いオペレータの結果に依
存する各々のグラフ要素によって要求される正しいタイ
プであるか否かについての判定が行われる。その結果が
正しいタイプでないと判定された場合には、本方法はス
テップ９７６に進み、新しいオペレータがデザインにお
いて古いオペレータを置換できないことを示すエラーメ
ッセージがユーザーに対して生成され、そして本方法は
終了する。

【０１８９】その結果が正しいタイプである場合には、
本方法はステップ９７８に進み、新しいオペレータにつ
いての結果データオブジェクトに記憶された値が、古い
オペレータについての結果データオブジェクト中に置か
れる。これは、古いオペレータについての結果データオ
ブジェクト中のポインタを、新しいオペレータの結果の
値を記憶するメモリ場所を指すように単に更新すること
によって達成される。そして本方法はステップ９８０に
進み、新しいオペレータの結果リレーションが、古いオ
ペレータの結果データオブジェクトに接続されるよう
に、再度ポインタを新しいオペレータの結果リレーショ
ン中に単に更新することによってスイッチされる。その
後、本方法はステップ９８２に進み、新しいオペレータ
の結果データオブジェクトが削除される。最後に、ステ
ップ９８４で、本方法は古いオペレータを削除し、そし
て終了する。

【０１９０】前述のことからわかるように、図３２の置
換オペレータルーチンは、古いオペレータを新しく実行
されたオペレータに置換し、ユーザーの編集によって要
求されるデザインに対する変更に影響を及ぼす依存関係
グラフ中の全ての必要な関係を作る。このルーチンは、
本方法に代えていくつかの異なった方法でも実施できる
ことがわかる。例えば、古いオペレータの結果データオ
ブジェクトを使用してその値を更新するよりもむしろ、
新しいオペレータの結果データオブジェクトを依存関係
グラフにフックアップすることもできる。しかしなが
ら、図３２に示された実施の形態は、古いオペレータの
データオブジェクトが、古いオペレータに依存する全て
のグラフ要素について前に接続されたリレーションをす
でに有しており、従って、これらの接続を変える必要が
ないという点で優れている。

【０１９１】上述したように、視覚的なプログラミング
環境５０（図３）の使用を通して、本発明の結合サブシ
ステムがインストールされたソフトウェアシステムのユ
ーザーには、デザインの依存関係グラフ表示を図表的に
編集する能力が提供される。依存関係グラフの視覚的な
表示は、多くの形式をとることができる。１つの例が図
３３及び図３４に示され、これは図２２及び図２３の依
存関係グラフの視覚的な表示を示す。

【０１９２】この依存関係グラフは、ソフトウェアシス
テムのディスプレイスクリーンのような視覚的環境カン
バス９９０上に視覚的に示される。また、ＡＡＰＩ９９
０のツール箱も表示され、このツール箱は、依存関係グ
ラフを作成および編集する際にユーザーが選択するのに
利用できる結合ＡＰＩのリストを含んで構成される。Ａ
ＡＰＩの表示リストは、図３３及び図３４のツール箱９
９２中に含まれる。このツール箱９９２中のＡＡＰＩ
は、アイコンによって、または対応するグラフエンティ
ティをデザインに付加するために起動される他のシンボ
ルによって表示される。

【０１９３】図３３において、階層的さら穴オペレータ
７２６がボックスオペレータ７１０に接続されて表示さ
れる。オペレータ７２６の階層性は、その境界を定義し
ている２重線によって示される。グラフ中のデータオブ
ジェクトは、オペレータ上のポートとして表示される。
このポートは、そのポートにより要求または生成される
データタイプを描く異なるカラーで、カラーコード化さ
れる。オペレータポートのうちの１つに対する入力リレ
ーションを追加または変更する場合、システムは、それ
に接続できる依存関係グラフ中の他の有効なポートをハ
イライトできる。

【０１９４】上述のようにして、ユーザーに対し、階層
的オペレータを開くことができる能力が提供される。図
３４は、階層的オペレータ７２６を構成する内部オペレ
ータ７１４〜７１６を示すために階層的オペレータ７２
６を開いた状態にした、図３３の依存関係グラフを表示
する。この表示では、階層的オペレータの境界が１対の
２重点線９９４によって限定される。

【０１９５】ユーザーがアイコンまたはＡＡＰＩを表示
する他のシンボルをツール箱から選択し、それらを視覚
的環境カンバス中に結合している間、依存関係グラフを
形成する実際のグラフエンティティは形成されない。し
かし、ユーザーがシステムに視覚的な表示を処理するよ
うに命令する場合、インタプリタ５２（図３）は、視覚
的表示を示す視覚的なプログラミング環境５０からの語
句を受け取り、上述した方法で依存関係グラフを作成す
るためにグラフエンティティを実際に構築する対応した
ＡＡＰＩを呼び出す。

【０１９６】上述のように、階層的オペレータが与えら
れる本発明の実施の形態において、ユーザーは階層的オ
ペレータをデザインの他の段階において使用するために
コピーする能力を与えられる。本発明の視覚的なプログ
ラミング環境はこの機能を支援する。階層的オペレータ
がコピーされる場合、そのＩＯ＿ＯＰおよびＩＯポート
は維持される。従って、階層的オペレータのコピーは、
単一のオペレータをＡＰＰＩのツールボックスから視覚
的環境カンバス中に挿入することと同じである。階層的
オペレータは、他のオペレータと全く同じように扱わ
れ、定義された一組の入力および出力を備える。階層的
オペレータがコピーされ、視覚的環境カンバス中に置か
れると、ユーザーは、その階層的オペレータのＩＯポー
トをグラフ中の所望の接続にフックアップするだけでよ
い。階層的オペレータがコピーされるとき、その階層的
オペレータの内部データオブジェクトもまたコピーされ
て、ユーザーは階層的オペレータのＩＯポートを接続す
る方法を定義するだけでよい。

【０１９７】XIII．コンピュータプログラムの生成 ユーザーがソフトウェアシステムでインタラクティブデ
ザインセッションを完了すると、本発明は結果デザイン
の構造的な依存関係を表示する依存関係グラフを図２に
示される実施の形態のように生成する。更に、本発明
は、例えばＣ++のような標準言語でコンピュータプログ
ラムを生成するために依存関係グラフを操作するプログ
ラム生成ツールを提供し、このツールは実行されると、
依存関係グラフおよびその依存関係グラフが表示するデ
ザインを生成する。上述のように、コンピュータプログ
ラムは、ユーザーによって編集でき、また、変更された
デザインを生成するためにシステムの中に戻すことがで
きる。

【０１９８】プログラム生成ツールを説明するフローチ
ャートが図１５〜図１９に示される。まず、ステップ１
０１で、依存関係グラフ中の各々のリーフデータオブジ
ェクトが同調しないとしてマークされる。リーフデータ
オブジェクトは、オペレータによって与えられないグラ
フ中のものであって、即ち、リーフデータオブジェクト
は、オペレータの結果ではない。リーフデータオブジェ
クトが実際にマークされると、本方法はステップ１０３
に進み、図９の記号パスルーチンが呼び出される。各々
のリーフデータオブジェクトは、同調しないとしてマー
クされて、全てが記号パスによって処理される。前述の
ように、記号パスルーチンはグラフを識別して、リスト
が評価される順序と同様にして、評価されるオペレータ
のリストを形成する。このリスト中のオペレータは、正
算オペレータまたは非正算オペレータの制限セットを含
む。図９に関連して上述したように、オペレータのリス
トは、グラフマネージャースタック上でオペレータが実
行される順に記憶される。このように、記号パスを呼び
出して、グラフマネージャースタックに指定された順序
でオペレータを処理することによって、プログラム生成
コードは、対応するＡＡＰＩを同じ順序で呼び出すプロ
グラムを生成する。

【０１９９】記号パスが戻ると、本方法はステップ１０
５に進み、グラフマネージャースタックに記憶された評
価順序の次のオペレータが処理するために選択され、こ
れは、ステップ１０５を通る第１のパスの間、第１のオ
ペレータとなる。その後、本方法はステップ１０７に進
み、選択されたオペレータが制限セットであるかどうか
についての判定が行われ、制限セットであると判定され
た場合には、本方法はステップ１０９に進み、制限セッ
トから１つの非正算オペレータが処理のために選択され
る。

【０２００】ステップ１０９で非正算オペレータを選択
した後、またはステップ１０５で選択されたオペレータ
が１つの正算オペレータであることがステップ１０７で
判定された場合に、本方法はステップ１１１に進み、図
１８の階層的ファイル準備ルーチンが、ステップ１０５
で処理するために選択された正算オペレータあるいはス
テップ１０９で選択された非正算オペレータの親である
階層的オペレータに関連して呼び出される。前述のよう
に、依存関係グラフ中の各々のオペレータは、少なくと
も１つの親の階層的オペレータに属し、最上位の階層的
オペレータがデザインの根底を定義する。各オペレータ
の親の階層は、オペレータを定義するグラフエンティテ
ィ中のポインタに記憶され、従って、各オペレータの親
の階層は、このグラフエンティティに単に問い合わせる
ことによるプログラム生成方法によって判定できる。

【０２０１】階層ファイル準備ルーチンが階層的オペレ
ータに対して呼び出されると、このルーチンは、ステッ
プ１６５でファイルがその階層的オペレータについて開
かれているかどうかをまず判定する。階層的オペレータ
は、本発明のプログラム生成方法により生成されたコー
ドで別のファンクションによって表示され、各ファンク
ションは異なるファイル中で定義されている。ファイル
がまだ開かれていないと判定された場合には、本方法は
ステップ１６７に進み、出力ファイルが階層的オペレー
タファンクションを定義するコードのために開かれる。

【０２０２】出力ファイルが、処理されている階層的オ
ペレータのために開かれると、本方法はステップ１６９
に進み、このファイルのためのポインタが目標として選
択されて、続いて生成されるコードがこのファイルに置
き換えられることを示す。その後ステップ１７１におい
て、変数が階層的オペレータの各ＩＯポートについて定
義される。このＩＯポートは、階層的オペレータを表示
するグラフエンティティによって維持されたＩＯ＿ＯＰ
リストに問い合わせることで確認される。次に、ステッ
プ１７５で、本ルーチンは階層的オペレータを表示する
ファンクションの定義を作成する。ファンクションの定
義は、ファンクションの名前と、そのリターンタイプ
と、その引数についての名前およびタイプとを含む。本
ルーチンは、ステップ１７１でＩＯポートのために作成
された変数の名前をファンクションの引数として使用す
る。

【０２０３】ファンクションが定義された後、本方法は
ステップ１７７に進み、開いた階層ＡＡＰＩを呼び出す
ための語句がファイルに書き出されて、コードが生成さ
れる場合に、処理される階層的オペレータのために階層
が作成される。その後、本方法はステップ１７９に進
み、親の階層が、処理される階層的オペレータに存在す
るかどうかについての判定が行われ、そのような親の階
層が存在しない場合には、本方法はステップ１８５に進
み、その階層的オペレータのためのファイルポインタ
が、目標として後述する理由で再び設定されて、本ルー
チンが終了する。

【０２０４】処理されている階層的オペレータが親の階
層を有することがステップ１７９で判定された場合に
は、階層的ファイル準備ルーチンが親の階層について呼
び出される。このように、ファイル準備ルーチンが再帰
的に呼び出されて、プログラム生成方法（図１５）のス
テップ１０５の間に評価スタックから最初に処理するた
めに選択されたオペレータを含む階層的オペレータの全
てを処理する。ファイル準備ルーチンが親の階層的オペ
レータの処理から戻ると、本方法はステップ１８３に進
み、処理されている階層的オペレータへの呼び出しが、
その親の階層のためのファイル中に書き込まれる。この
ように、親の階層的オペレータを定義するファンクショ
ンは、その範囲内に含まれる階層的オペレータを定義す
るファンクションを呼び出す。

【０２０５】最後に、階層的オペレータファンクション
への呼び出しが、ステップ１８３でその親の階層的オペ
レータのためのファイル中に書き込まれた後、または、
ステップ１７９で処理されている階層的オペレータが親
の階層的オペレータを含まないと判定された場合、ある
いは、ステップ１６５で階層的オペレータのためのファ
イルが階層的ファイル準備ルーチンを呼び出すよりも前
に開かれた場合には、本ルーチンはステップ１８５に進
み、処理されている階層的オペレータのためのファイル
ポインタが目標として再び設定される。ステップ１８５
は、それが実行される再帰的方法であるためにファイル
準備ルーチンに含まれる。特に、ルーチンを初めに呼び
出すための階層的オペレータが少なくとも１つの親の階
層的オペレータを有する場合、目標ポインタは、親の階
層的オペレータを処理するルーチンへの再帰的呼び出し
のステップ１６９において、その親の階層的オペレータ
に設定される。プログラム生成方法（図１５）のステッ
プ１１３に戻る前に、階層的ファイル準備ルーチンは、
目標ポインタを最初に呼び出すための階層的オペレータ
に設定して、プログラム生成方法の間に生成された付加
的コードがこのファイルに書き込まれる。

【０２０６】階層的準備ルーチンが戻った後に、本方法
はステップ１１３に進み、ステップ１０５あるいはステ
ップ１０９の処理の間に選択されたオペレータに接続さ
れたデータオブジェクトの全てが収集される。上述した
ように、各オペレータは、そのリレーションについての
ポインタを含み、各々のオペレータが、順次対応するデ
ータオブジェクトについてのポインタを含む。オペレー
タを表示するグラフエンティティに照会することによっ
て、プログラム生成方法はオペレータに接続された全て
のデータオブジェクトのリストを収集できる。ステップ
１１５において、本方法は、処理されているオペレータ
に接続されたデータオブジェクトのうちの１つを処理す
るために選択する。ステップ１１７において、本方法
は、選択されたデータオブジェクトが以前に処理された
かどうかを判定し、以前に処理されていない場合には、
本方法はステップ１１９に進み、変数が選択されたデー
タオブジェクトに対して宣言及び命名される。

【０２０７】ステップ１１９で選択されたデータオブジ
ェクトに対して変数が宣言された後、あるいは、ステッ
プ１１７で選択されたデータオブジェクトが以前に処理
されたと判定された場合には、本方法はステップ１２１
に進み、ステップ１１５で形成され接続されたデータオ
ブジェクトのリスト中の全てのデータオブジェクトが処
理されたかどうかについての判定が行われ、全てが処理
されていない場合には、本方法はステップ１１５に戻
る。このように、処理されているオペレータに接続され
た各データオブジェクトに対して変数名が宣言されるこ
とを保証するために、本方法はステップ１１５〜１２１
を続行する。

【０２０８】変数名が、処理されているオペレータに接
続された各データオブジェクトに対して宣言された後、
本方法はステップ１２３（図１６）に進み、ステップ１
１５で形成されたリストに含まれる入力データオブジェ
クトの全てが確認される。ステップ１２３での入力とし
ての確認のためには、プログラム生成方法は、正算オペ
レータへの入力だけでなく、非正算オペレータに接続さ
れたあらゆるデータオブジェクトを確認する。

【０２０９】入力データオブジェクトが確認された後、
本方法はステップ１２５に進み、入力データオブジェク
トのうちの１つが処理するために選択される。ステップ
１２７では、選択された入力データオブジェクトが、処
理されているオペレータの親のオペレータである階層的
オペレータのためのＩＯ入力ポートであるかどうかにつ
いての判定が行われる。その入力データオブジェクトが
ＩＯポートであると判定された場合には、本方法はステ
ップ１２９に進み、ステップ１１９（図１５）で選択さ
れたデータオブジェクトに対して宣言された変数名が、
図１８の階層的ファイル準備ルーチンのステップ１７１
の間にＩＯポートに対して宣言された変数名に等しくさ
れる。このように、選択されたデータオブジェクトに対
する値が、処理されているオペレータの親の階層のため
に作成されたファンクションの中にスコープされる。

【０２１０】ステップ１２９で変数名が等しくされた
後、あるいはステップ１２７でデータオブジェクトが階
層のためのＩＯポートではないと判定された場合には、
本方法はステップ１３１に進み、ステップ１２３でオペ
レータに対して確認された入力データオブジェクトのい
くつかが処理されるために残されているかどうかについ
ての判定が行われ、少なくとも１つが処理するために残
されている場合には、本方法はステップ１２５に戻る。
このように、本方法がステップ１２５〜１３１を通して
進み、親の階層のＩＯポートを形成する処理されたオペ
レータの入力データオブジェクトそれぞれの変数名を、
それの対応するＩＯポートの変数名に等しくする。

【０２１１】入力データオブジェクトの全てが処理され
た後、本方法はステップ１３３に進み、処理されている
オペレータに対応するＡＡＰＩマクロを呼び出すための
語句が、その対応する変数名と一緒に書き出される。そ
して、本方法はステップ１３５に進み、処理されている
オペレータが正算かどうかについての判定が行われ、正
算と判定された場合には、本方法はステップ１３７に進
み、正算オペレータに対する１つの結果データオブジェ
クトが確認される。逆に、ステップ１３５で処理されて
いるオペレータが非正算と判定された場合には、本方法
はステップ１３９に進み、変数、即ち、固定されない非
正算オペレータに接続されたデータオブジェクトの全て
を出力として確認する。

【０２１２】処理されているオペレータに対する出力デ
ータオブジェクトがステップ１３７または１３９のいず
れかで確認された後、本方法はステップ１４１（図１
７）に進み、出力データオブジェクトのうちの１つが処
理するために選択される。その後、本方法はステップ１
４３に進み、選択された出力データオブジェクトが、処
理されているオペレータの親のオペレータである階層的
オペレータのためのＩＯポートであるかどうかについて
の判定が行われる。この判定は、ステップ１２７に関連
して前述したものに類似し、また、親の階層的オペレー
タのためのＩＯポートのＩＯ＿ＯＰリストに照会するこ
とによって行われる。ステップ１４１で選択されたデー
タオブジェクトが親の階層的オペレータのためのＩＯポ
ートであると判定された場合には、本方法はステップ１
４５に進み、ＩＯポートのための変数名が、ステップ１
１９（図１５）でデータオブジェクトに対して宣言され
た変数名に等しくされる。このステップは、上述したス
テップ１２９（図１６）に類似し、また、出力データオ
ブジェクト中の値が、対応するＩＯポートを通して親の
階層的オペレータのために作成されたファンクションの
うちからポートされることを保証し、そして、この値は
次の階層レベルのファンクションによってアクセスでき
る。

【０２１３】変数がステップ１４５で等しくされた後、
または、ステップ１４３で選択された出力データオブジ
ェクトが親の階層のＩＯポートではないと判定された場
合には、本方法はステップ１４７に進み、ステップ１３
９（図１６）で確認された出力データオブジェクトのい
くつかが処理されるために残されているかどうかについ
ての判定が行われ、少なくとも１つが処理されるために
残されている場合に、本方法はステップ１４１に戻る。
このように、本方法は選択されたオペレータのための出
力データオブジェクトのそれぞれを処理して、その親の
階層のＩＯポートである各々を対応するＩＯポート変数
名に等しくする。

【０２１４】ステップ１４７で選択されたオペレータに
対する出力データオブジェクトが処理されるために残さ
れていないと判定された場合には、本方法はステップ１
４９に進み、そのオペレータが制限セットに属するかど
うかについての判定が行われ、そのオペレータが制限セ
ットに属する場合に、そのセットの中に何らかの付加的
なオペレータが処理されるために残されているかどうか
についての判定が行われる。ステップ１４９で同じ制限
セットの中に付加的なオペレータが処理されるために残
されている場合、本方法はステップ１０９（図１５）に
戻り、制限セットからの次のオペレータが、処理するた
めに選択される。このように、制限セット中のオペレー
タそれぞれを処理するために、本方法はステップ１０９
〜１４９を続行する。

【０２１５】ステップ１４９で処理されるオペレータが
制限セットに属さない、あるいは、制限セット中のオペ
レータの各々が既に処理されていると判定された場合に
は、本方法はステップ１５１に進み、何らかのオペレー
タが評価スタック上に処理するために残されているかど
うかについての判定が行われる。少なくとも１つのオペ
レータが処理されるために残されていると判定された場
合には、本方法はステップ１０５（図１５）に戻り、ス
タック上の次のオペレータが処理するために選択され
る。このように、ステップ１０３の記号パスに対する呼
び出しに起因する評価スタック上におかれたオペレータ
のそれぞれを処理するために、本方法はステップ１０５
〜１５１を続行する。オペレータが処理するために残さ
れていないと判定された場合には、本方法はステップ１
５３に進み、階層的ファイル終了ルーチンが呼び出され
て、そして本方法が終了する。

【０２１６】階層的ファイル終了ルーチンは、図１９に
示される。まず、ステップ１５５では、階層的ファイル
準備ルーチン（図１８）のステップ１６７で開かれた階
層的オペレータファイルの１つが、処理するために選択
される。次に、選択された階層的オペレータファイルの
ファイルポインタが、目標としてステップ１５７で設定
されて、続いて生成されたコードがこのファイルに書き
込まれる。

【０２１７】選択された階層的オペレータのファイルポ
インタが目標として設定された後、本方法はステップ１
５９に進み、引渡し階層ＡＡＰＩがそのファイルに書き
込まれる。そして、本ルーチンはステップ１６０に進
み、階層的オペレータのためのファンクションリターン
が、階層的オペレータファンクションによって戻される
引数を含んで、書き込まれる。そして、本ルーチンはス
テップ１６１に進み、ステップ１５５で選択された階層
的オペレータファイルが閉じられる。最後に本ルーチン
はステップ１６３に進み、他の階層的オペレータファイ
ルが処理するために残されているかどうかについての判
定が行われ、少なくとも１つが処理のために残されてい
る場合、本ルーチンはステップ１５５に戻る。このよう
に、ステップ１６３でこれ以上開いたファイルが残され
ていないと判定されるまで、開いた階層的オペレータフ
ァイルそれぞれを処理するために本ルーチンは続行し、
そして、本ルーチンが終了する。

【０２１８】XIV.ハードウェアシステムの一例 図２０は、本発明を操作できるハードウェアシステムの
ブロック図である。本システムは、上述したユーザーイ
ンタフェース３７、プロセッサ６００および結合メモリ
６０１を含む。上述のように、本発明は、ファンクショ
ンで構成される任意のソフトウェアシステム上で操作で
きる。従って、プロセッサ６００は、ソフトウェアファ
ンクションを実行できる任意の変数タイプのプロセッサ
とすることができる。この中で説明される本発明のソフ
トウェアツール、ルーチンおよび方法は、それぞれメモ
リ６０１に記憶でき、またプロセッサ６００上で本発明
を実施するために実行できる。

【０２１９】XV．デザイン反復の方法の一例 上述のことからわかるように、本発明の種々の能力によ
り、デザインを作成し、図表的に変更のできる依存関係
グラフにそのデザインを表示し、そして、デザインの構
造的依存関係を表示する標準言語でコンピュータプログ
ラムを作成する際に、ユーザーに優れた適応性が与えら
れ、また、将来的にはシステム上でデザインの作成が実
行され得る。例えば、本発明の結合サブシステムをイン
ストールしたソフトウェアシステムによって実行される
高水準のステップが、図３５のフローチャートに示され
る。

【０２２０】ステップ９８５で、本方法はユーザーから
の入力を受け取り、そして、ステップ９８６に進んで、
ユーザーによって要求されたデザイン動作を実施するた
めに対応するＡＡＰＩを呼び出す。ステップ９８７で、
このＡＡＰＩのための依存関係グラフエンティティが生
成され、そして、本方法はステップ９８８に進み、この
グラフが評価される。そして、ユーザーは視覚的なプロ
グラム環境を使用して、依存関係グラフを見て、結果デ
ザインが容認できるかどうかを判定する。ステップ９８
９で、結果がユーザーによって容認されなかったことが
判定された場合には、本方法はステップ９９０に進み、
コマンドがグラフを編集するために視覚的なプログラミ
ング環境から受け取られる。そして、本方法はステップ
９８８に進み、変更されたグラフが評価される。このよ
うに、本方法は、ユーザーが結果デザインを容認したこ
とを示すまでステップ９８８〜９９０を続行する。

【０２２１】結果が容認されると、本方法はステップ９
９１に進み、いくつかの追加のコマンドがユーザーによ
って受け取られるかどうかについての判定が行われる。
多くのコマンドが受け取られる場合には、本方法はステ
ップ９８６に戻り、それらのコマンドが処理される。こ
れ以上コマンドがユーザーから受け取られない場合に
は、本方法はステップ９９２に進み、デザインの構造的
依存関係を表示する標準言語コンピュータプログラムの
生成をユーザーが望むかどうかについての判定が行われ
る。ユーザーが、コンピュータプログラムの生成を望ま
ない場合には、本方法は単に終了する。しかしながら、
プログラムが生成されることが判定された場合には、本
方法はステップ９９３に進み、このプログラムが上述し
た方法で作成され、ステップ９９４に進んで、そのプロ
グラムがソフトウェアシステムにコンパイルされて、リ
ンクされる。

【０２２２】XVI.結論 このように、本発明の種々の実施形態を説明したこと
で、様々な変更、修正および改良が、当業者には容易と
なる。このような変更、修正および改良は、本発明の意
図および範囲内であると考えられる。よって、上記の説
明や添付図面は、単に例として与えられたものであり、
これに限られるものではない。本発明は、特許請求の範
囲およびその均等物に定義されるものとしてのみ限定さ
れる。

【０２２３】

【発明の効果】以上説明したように、請求項１〜請求項
１１の発明にかかる方法によれば、対応するファンクシ
ョンによって夫々作成される複数のデザインエンティテ
ィの依存関係が表示されるので、ユーザーは、該エンテ
ィティが相互に作用する関係を、視覚的により速くかつ
より容易にみることができ、視覚的なプログラミング環
境の中でデザインを作成したり、編集したりすることが
できる。また、標準言語でコンピュータプログラムが生
成されるので、ユーザーは、固有の言語を習得すること
なく、モデルを再生させることができる。

【０２２４】請求項１２〜請求項２０の発明にかかる方
法によれば、固有ＡＰＩの周囲にラッパーが供給されて
結合ファンクションが作成され、モデルの依存関係表示
にグラフエンティティが付加されるので、適応性が増大
し、新しい固有ＡＰＩの作成を必要としない。そして、
受け取ったコマンドに応じて、ユーザーインタフェース
も修正されるので、以後、ユーザーインタフェースから
新しい結合システムを呼び出すことができる。

【０２２５】請求項２１及び請求項２２の発明にかかる
方法によれば、複数のファンクションが正算と非正算に
係るものであるときは、正算と非正算との両者によって
作成されるデザインエンティティが依存関係に表示され
るので、ユーザーは、かかる関係を視覚的にみることが
できる。請求項２３及び請求項２４の発明にかかる方法
によれば、デザインが複数のファンクションの対応する
１つによって各々作成される場合でも、ユーザーは、同
様に該エンティティの依存関係を視覚的にみることがで
きる。

【０２２６】請求項２５の発明にかかる方法によれば、
デザインが複数のファンクションの対応する１つによっ
て各々作成される場合でも、ユーザーは、複数のグラフ
エンティティで複数のデザインエンティティの依存関係
を視覚的にみることができる。請求項２６の発明にかか
る方法によれば、デザインが修正された場合に、デザイ
ンの修正による影響を確認することができ、影響を受け
たファンクションだけを再評価してデザインアクション
の時間を節減することができる。

【図面の簡単な説明】

【図１】本発明による方法のステップを示す上位フロー
チャート

【図２】本発明により作成される依存関係グラフを示す
図

【図３】本発明を使用するＣＡＤシステムのユーザー側
からの配景を示す図

【図４】本発明の結合ＡＰＩ構築用ツールと、作成され
た結合ＡＰＩと、本発明の結合サブシステムがインスト
ールされたソフトウェアシステムの固有ＡＰＩとの間の
関係を示す図

【図５】本発明を用いるＣＡＤシステムのユーザインタ
ーフェースで受け取られるコマンドが結合ＡＰＩおよび
結合ＡＰＩプロセッサを呼び出して、そのコマンドを表
示する依存関係グラフを表示し、ユーザーによって要求
されたデザイン動作を実行するためにそれら依存関係グ
ラフのエンティティを評価する方法を示す図

【図６】結合ＡＰＩにより呼び出された場合の本発明の
結合ＡＰＩプロセッサによって実行されるステップを示
すフローチャート

【図７】依存関係グラフ中のオペレータを評価するため
に呼び出された場合の、本発明の結合ＡＰＩのためのオ
ペレータエバリュエータによって実行されるステップを
示すフローチャート

【図８】同上フローチャート

【図９】図７及び図８の評価方法の評価記号パスについ
ての１つの実施形態に関するフローチャート

【図１０】本発明の正算オペレータ処理ルーチンのフロ
ーチャート

【図１１】本発明の非正算オペレータ処理ルーチンのフ
ローチャート

【図１２】同上フローチャート

【図１３】図７及び図８の評価方法の評価パスを示すフ
ローチャート

【図１４】ソフトウェアシステム中に本発明を統合する
本発明の統合プロセスのステップを示すフローチャート

【図１５】本発明のプログラム生成方法および支援ルー
チンのステップを示すフローチャート

【図１６】同上フローチャート

【図１７】同上フローチャート

【図１８】同上フローチャート

【図１９】同上フローチャート

【図２０】本発明を作動できるハードウェアシステムの
ブロック図

【図２１】さら穴を有する箱を示す図

【図２２】階層的オペレータを使用しない本発明の依存
関係グラフを示す図

【図２３】階層的オペレータを使用する図１６の依存関
係グラフを示す図

【図２４】図１６，図１７の依存関係グラフにおける階
層的オペレータの実施形態についての概念図

【図２５】本発明の依存関係グラフに引渡される各オペ
レータに作用する方法のフローチャート

【図２６】同上フローチャート

【図２７】同上フローチャート

【図２８】同上フローチャート

【図２９】本発明のインタプリタルーチンを示すフロー
チャート

【図３０】視覚的なプログラミング環境を用いる本発明
のデザインおよび依存関係グラフについて処理編集する
ための方法を示すフローチャート

【図３１】本発明の再定義入力ルーチンのステップを示
すフローチャート

【図３２】本発明の置換オペレータルーチンのステップ
を示すフローチャート

【図３３】本発明による依存関係グラフの視覚的表示の
一例を示す図

【図３４】本発明による依存関係グラフの視覚的表示の
一例を示す図

【図３５】本発明による方法のステップを示す上位フロ
ーチャート

【符号の説明】

３〜６ データオブジェクト ７，１９ オペレータ ９〜１２，１５，２１，２３ リレーション

───────────────────────────────────────────────────── フロントページの続き (72)発明者 ステファノ マルナティ アメリカ合衆国、マサチューセッツ 01845、エヌ． アンドバー、メイン ス トリート 148、ユニット ビー．533

Claims (26)

【特許請求の範囲】
1. 【請求項１】デザインを作成する際に使用する複数のフ
   ァンクションを含むソフトウェアシステム上で、デザイ
   ンセッションから生じるデザインを表示する方法であっ
   て、 前記デザインは、対応するファンクションによって夫々
   作成される複数のデザインエンティティを含み、 前記デザインを形成する複数のデザインエンティティの
   依存関係を示すデザインの依存関係表示を作成する依存
   関係作成ステップと、 前記デザインを形成するデザインエンティティを作成す
   る際に使用される対応するファンクションを呼び出し
   て、デザインを表示するコンピュータプログラムを前記
   依存関係表示から標準的なプログラミング言語で生成す
   るプログラム生成ステップと、を含むことを特徴とする
   ソフトウェアモデリングシステムにおけるデータ依存関
   係を表示する方法。
2. 【請求項２】前記プログラム生成ステップは、前記ソフ
   トウェアシステム上で、デザインを形成する複数のデザ
   インエンティティの依存関係に対応する構造を有するコ
   ンピュータプログラムを生成するステップであることを
   特徴とする請求項１に記載のソフトウェアモデリングシ
   ステムにおけるデータ依存関係を表示する方法。
3. 【請求項３】前記ソフトウェアシステムは、前記デザイ
   ンの依存関係表示を評価するために実行されるソフトウ
   ェアルーチンであることを特徴とし、 また、前記プログラム生成ステップは、前記コンピュー
   タプログラムを生成する際にソフトウェアルーチンの少
   なくとも一部を実行するステップであることを特徴とす
   る請求項１又は請求項２に記載のソフトウェアモデリン
   グシステムにおけるデータ依存関係を表示する方法。
4. 【請求項４】コンピュータプログラムを編集し、修正さ
   れたデザインを表示する修正コンピュータプログラムを
   作成するプログラム修正ステップと、 該修正コンピュータプログラムをソフトウェアシステム
   上で実行し、ソフトウェアシステム上で修正デザインを
   生成するデザイン修正ステップと、をさらに含むことを
   特徴とする請求項１〜請求項３のいずれか１つに記載の
   ソフトウェアモデリングシステムにおけるデータ依存関
   係を表示する方法。
5. 【請求項５】前記デザイン修正ステップは、前記修正さ
   れたデザインの依存関係表示を生成するステップである
   ことを特徴とする請求項４に記載のソフトウェアモデリ
   ングシステムにおけるデータ依存関係を表示する方法。
6. 【請求項６】前記依存関係作成ステップは、前記デザイ
   ンを形成する複数のデザインエンティティのサブセット
   を表示する少なくとも１つの階層的なデザインエンティ
   ティを含む依存関係表示を作成するステップであり、 前記プログラム生成ステップは、少なくとも１つの階層
   的なデザインエンティティを表示するコンピュータプロ
   グラムを生成するステップであることを特徴とする請求
   項１〜請求項５のいずれか１つに記載のソフトウェアモ
   デリングシステムにおけるデータ依存関係を表示する方
   法。
7. 【請求項７】前記プログラム生成ステップは、さらに、
   前記階層的なデザインエンティティによって表示される
   複数のデザインエンティティのサブセットを作成する複
   数のファンクションを呼び出して、少なくとも１つの階
   層的なデザインエンティティを表示するコンピュータプ
   ログラムを生成するステップであることを特徴とする請
   求項６に記載のソフトウェアモデリングシステムにおけ
   るデータ依存関係を表示する方法。
8. 【請求項８】前記コンピュータプログラムを格納するプ
   ログラム格納ステップと、 前記ソフトウェアシステムから前記デザインを削除して
   格納空間を保存するデザイン削除ステップと、をさらに
   含むことを特徴とする請求項１〜請求項７のいずれか１
   つに記載のソフトウェアモデリングシステムにおけるデ
   ータ依存関係を表示する方法。
9. 【請求項９】前記ソフトウェアシステム上でコンピュー
   タプログラムを実行してデザインを再生するデザイン再
   生ステップをさらに含むことを特徴とする請求項１〜請
   求項８のいずれか１つに記載のソフトウェアモデリング
   システムにおけるデータ依存関係を表示する方法。
10. 【請求項１０】前記ソフトウェアシステムから依存関係
    表示を削除して格納空間をさらに保存する依存関係表示
    削除ステップをさらに含むことを特徴とする請求項１〜
    請求項８のいずれか１つに記載のソフトウェアモデリン
    グシステムにおけるデータ依存関係を表示する方法。
11. 【請求項１１】前記ソフトウェアシステム上で依存関係
    表示を再生するコンピュータプログラムを実行する依存
    関係再生ステップをさらに含むことを特徴とする請求項
    １０に記載のソフトウェアモデリングシステムにおける
    データ依存関係を表示する方法。
12. 【請求項１２】複数のファンクションと１つのユーザー
    インタフェースを有し、前記複数のファンクションの対
    応する１つを呼び出すことによって複数のコマンドの各
    々の受領に応答するソフトウェアモデリングシステム
    に、パラメータ能力を供給する方法であって、 前記複数のファンクションは、モデルを作成するモデリ
    ングセッション中に実行され、 ソフトウェアシステムにおいて前記複数のファンクショ
    ンの各々の周囲にラッパーを供給して複数の結合ファン
    クションを作成するステップであって、該複数の結合フ
    ァンクションの各々は、対応するファンクションを呼び
    出すことを特徴とし、さらに、その対応するファンクシ
    ョンが前記モデリングセッション中に実行されたとき、
    前記モデルの依存関係表示にグラフエンティティを作成
    し、付加する能力を有するものである結合ファンクショ
    ン作成ステップと、 各々受け取ったコマンドに応じて、該受け取ったコマン
    ドに対応する前記ファンクションに対応する結合ファン
    クションが呼び出されるように、前記ユーザーインタフ
    ェースを修正するユーザーインタフェース修正ステップ
    と、を含むことを特徴とするソフトウェアモデリングシ
    ステムにおけるデータ依存関係を表示する方法。
13. 【請求項１３】前記複数のファンクションの少なくとも
    １つは、固有のパラメータ能力を有していないことをさ
    らに特徴とする請求項１２に記載のソフトウェアモデリ
    ングシステムにおけるデータ依存関係を表示する方法。
14. 【請求項１４】前記複数のファンクションは、第１のフ
    ォーマットでフォーマットされた引数の第１のセットに
    作用する第１のファンクションを含むことを特徴とし、 また、前記結合ファンクション作成ステップは、第１の
    ファンクションの周囲に第１のラッパーを供給するステ
    ップであって、該第１のラッパーは、第１のフォーマッ
    トとは異なる第２のフォーマットでフォーマットされた
    引数の第２のセットを受け取ることが可能であり、第１
    のファンクションが呼び出されるとき、引数の第２のセ
    ットを引数の第１のセットに変換するものであることを
    特徴とする請求項１２又は請求項１３に記載のソフトウ
    ェアモデリングシステムにおけるデータ依存関係を表示
    する方法。
15. 【請求項１５】前記結合ファンクション作成ステップ
    は、前記ラッパーの各々を、オブジェクト指向コンピュ
    ータプログラミング言語に供給するステップであること
    を特徴とする請求項１２〜請求項１４のいずれか１つに
    記載のソフトウェアモデリングシステムにおけるデータ
    依存関係を表示する方法。
16. 【請求項１６】修正が前記モデルになされたとき、前記
    依存関係表示を使用するツールを供給して前記デザイン
    の修正によって影響を受けるグラフエンティティに対応
    する前記モデルを作成するのに使用されるファンクショ
    ンだけを再評価するファンクション再評価ステップをさ
    らに含むことを特徴とする請求項１２〜請求項１５のい
    ずれか１つに記載のソフトウェアモデリングシステムに
    おけるデータ依存関係を表示する方法。
17. 【請求項１７】各々の結合ファンクションのためのテー
    ブルエントリを有するハッシュテーブルを作成するステ
    ップであって、各々のテーブルエントリは、該結合ファ
    ンクションが実行されたとき、依存関係表示に作成さ
    れ、付加された前記グラフエンティティのトポロジイを
    確認するものであるハッシュテーブル作成ステップをさ
    らに含むことを特徴とする請求項１２〜請求項１６のい
    ずれか１つに記載のソフトウェアモデリングシステムに
    おけるデータ依存関係を表示する方法。
18. 【請求項１８】前記結合ファクション作成ステップは、
    さらに、標準的なコンピュータプログラミング言語によ
    り前記ラッパーの各々を供給するステップであることを
    特徴とする請求項１２〜請求項１７のいずれか１つに記
    載のソフトウェアモデリングシステムにおけるデータ依
    存関係を表示する方法。
19. 【請求項１９】前記グラフエンティティを依存関係表示
    に作成し、付加する前記結合ファンクションの各々と協
    働する単一のプロセッサファンクションを作成する単一
    プロセッサファンクション作成ステップをさらに含むこ
    とを特徴とする請求項１２〜請求項１８のいずれか１つ
    に記載のソフトウェアモデリングシステムにおけるデー
    タ依存関係を表示する方法。
20. 【請求項２０】各々の結合ファンクションのためのテー
    ブルエントリを有するハッシュテーブルを作成するステ
    ップであって、各々のテーブルエントリは、結合ファン
    クションが実行されたときに、前記依存関係表示に作成
    され、付加されるグラフエンティティのトポロジィを確
    認するハッシュテーブル作成ステップをさらに含んで構
    成され、 また、前記単一プロセッサファンクション作成ステップ
    は、単一のプロセッサファンクションを作成し、ハッシ
    ュテーブルにおいてエントリにアクセスすることにより
    前記依存関係表示を作成するステップであって、該単一
    のプロセッサファンクションは一般的なものであり、結
    合ファンクションによって呼び出されたときに、それに
    渡される引数に応じて動作するものであることを特徴と
    する請求項１９に記載のソフトウェアモデリングシステ
    ムにおけるデータ依存関係を表示する方法。
21. 【請求項２１】デザインを作成する際に使用する複数の
    ファンクションを含むソフトウェアシステム上で、デザ
    インセッションから生じるデザインに作用する方法であ
    って、 前記デザインは対応するファンクションによって各々作
    成される複数のデザインエンティティであり、 前記複数のファンクションは正算と非正算に係るもので
    あることを特徴とし、 前記デザインを形成する複数のデザインエンティティの
    間で、依存関係を示すデザインの依存関係表示を作成す
    るステップであって、該依存関係表示は、正算と非正算
    との両者によって作成されるデザインエンティティを表
    示するものである依存関係作成ステップを含むことを特
    徴とするソフトウェアモデリングシステムにおけるデー
    タ依存関係を表示する方法。
22. 【請求項２２】前記ソフトウェアシステムは、さらに、
    相互に接続された非正算の制限セットを解明するエンジ
    ンを含むことを特徴とし、 また、前記依存関係作成ステップは、さらに、デザイン
    をチェックして、相互に接続された非正算の各々の制限
    セットがエンジンが解明できる型のものであるか否か判
    定するデザインチェックステップを含むことを特徴とす
    る請求項２１に記載のソフトウェアモデリングシステム
    におけるデータ依存関係を表示する方法。
23. 【請求項２３】デザインを作成する際に使用する複数の
    ファンクションを含むことを特徴とするソフトウェアシ
    ステム上で、デザインセッションから生じるデザインに
    作用する方法であって、 前記デザインは、前記複数のファンクションの対応する
    １つによって各々作成される複数のデザインエンティテ
    ィであることを特徴とし、 前記デザインを形成する前記複数のデザインエンティテ
    ィの間で、依存関係を示すデザインの依存関係表示を作
    成する依存関係作成ステップと、 前記デザインの依存関係表示を表示する依存関係表示ス
    テップと、を含むことを特徴とするソフトウェアモデリ
    ングシステムにおけるデータ依存関係を表示する方法。
24. 【請求項２４】依存関係表示を修正し、修正されたデザ
    インを表示する修正依存関係表示を作成する依存関係修
    正ステップと、 該修正依存関係表示から修正デザインを生成するデザイ
    ン修正ステップと、をさらに含むことを特徴とする請求
    項２３に記載のソフトウェアモデリングシステムにおけ
    るデータ依存関係を表示する方法。
25. 【請求項２５】デザインを作成する際に使用する複数の
    ファンクションを含むことを特徴とするソフトウェアシ
    ステム上で、デザインセッションから生じるデザインに
    作用する方法であって、 前記デザインは、前記複数のファンクションの対応する
    １つによって各々作成される複数のデザインエンティテ
    ィであることを特徴とし、 前記デザインを形成する前記複数のデザインエンティテ
    ィの依存関係を示すデザインの依存関係表示を作成する
    ステップであって、該依存関係表示は、前記複数のデザ
    インエンティティを表示する複数のグラフエンティティ
    に特徴を有するものである依存関係作成ステップと、 同じ階層のグラフエンティティを有する複数のグラフエ
    ンティティの少なくとも２つを表示するグラフエンティ
    ティ表示ステップと、を含むことを特徴とするソフトウ
    ェアモデリングシステムにおけるデータ依存関係を表示
    する方法。
26. 【請求項２６】前記デザインに修正を加えるデザイン修
    正ステップと、 前記依存関係表示を使用して、デザインの修正によって
    影響を受ける１組のデザインエンティティを確認するデ
    ザインエンティティ確認ステップと、 前記修正によって影響を受ける１組のデザインエンティ
    ティに対応するデザインを作成する際に使用されるファ
    ンクションだけを再評価するファンクション再評価ステ
    ップと、をさらに含むことを特徴とする請求項１〜請求
    項２５のいずれか１つに記載のソフトウェアモデリング
    システムにおけるデータ依存関係を表示する方法。