JP5147240B2 - リバーシブルなデザイン・ツリーの変換のための方法とシステム - Google Patents

Description

記載の技術は、概して、デザイン・ツリーの変換に関するものである。

一般に、コンピュータプログラムは、高級プログラム言語（例えば、Ｊａｖａ（登録商標）またはＣ＋＋）で記述されている。そしてコンパイラを使用して、高級プログラミング言語の命令を、コンピュータによって実行することができる機械語の命令に変換する。コンパイル処理は概して６つの段階に分けられる：
１．字句解析
２．構文解析
３．意味解析
４．中間コード生成
５．コード最適化
６．最終的なコード生成。

字句解析の間に、コンピュータプログラムのソースコードはスキャンされ、高級言語のコンポーネントまたはトークンが識別される。次に、コンパイラは、ソースコードを構文解析の間に処理されることができるトークン列に変換する。字句解析の間、たとえばコンパイラはステートメント、
ｃＴａｂｌｅ＝１．０；
を、変数（ｃＴａｂｌｅ）と演算子（＝）と定数（１．０）とセミコロンとして識別するだろう。変数と演算子と定数とセミコロンは、高級言語のトークンである。

構文解析（「ｐａｒｓｉｎｇ」とも呼ばれる）の間、コンパイラは、トークンを処理し、そのプログラム言語の構文（「ｇｒａｍｍａｒ」とも呼ばれる）に基づくプログラムを表すための構文木を生成する。構文木は、演算子は葉のないノードによって表され、オペランドは子ノードによって表される、ツリー構造である。上記の例では、演算子（＝）は、変数（ｃＴａｂｌｅ）と定数（１．０）の二つのオペランドをもつ。「解析木」と「構文木」の用語は、構文解析の結果として生成された、構文に基づくツリーについて言及するために、この説明では同義的に用いられる。例えば、そのようなツリーは、状況に応じて、コンピュータプログラムの構文解析の派生物を表すかもしれない。（例えば、それは、ある特定のトークンが識別子であることを表すかもしれない。そしてそれは構文によって定義された表現である。）構造に基づくツリーは、構文解析の派生物が含まれている時は「具象構文木」とも呼ばれ、それが含まれていないときは「抽象構文木」と呼ばれることがある。

意味解析の間、コンパイラは、意味の正確さを確保するために構文木を修正する。例えば、変数（ｃＴａｂｌｅ）が整数、かつ定数（１．０）が浮動小数点の場合、意味解析の間、浮動小数点から整数への変換が構文木へ加えられるだろう。

中間コード生成、コード最適化、最終コード生成の間、コンパイラは、構文木によって表現されたプログラムを実装するための機械語の命令を生成する。コンピュータはその後機械語の命令を実行できる。

インテンショナル・プログラム・ツリーとして表現されるコンピュータプログラムを生成し保持するためのシステムが説明されている。そしてインテンショナル・プログラム・ツリーはある種の構文木である。（例えば、特許文献１「Method and System for Generating and Displaying a Computer Program」と、特許文献２「Method and System for Reducing an Intentional Program Tree Represented by High-Level Computational Constructs,」の両方によってここに組み込まれる。）そのシステムは、インテンショナル・プログラム・ツリーの中にノードを加えて、削除して、動かすことによって、「プログラム要素」に対応するノードを直接操作するためのメカニズムを提供する。インテンショナル・プログラム・ツリーは「プログラム・ツリー」の一種である。「プログラム・ツリー」は、プログラム要素を表す演算子ノードとオペランドノードを含む、コンピュータプログラムのツリー表現である。識別子の宣言ノードからその識別子のタイプを定義するノードへの参照のように、プログラム・ツリーはノード間の参照も含んでもよい。（例えば、ツリーのノードをリンクしているグラフ構造）。例えば、整数である識別子の宣言を表すノードは、整数型を定義するノードへの参照（例えば非ツリーのポインタ）を含む。抽象構文木と具象構文木はプログラム・ツリーの例である。一旦プログラム・ツリーが生成されると、プログラム・ツリーによって表現されているコンピュータプログラムを、実行可能なコードへ変換するために、システムは、意味解析、中間コード生成、コード最適化、最終コード生成のステップを実行する。

プログラム・ツリーは、従来のコンピュータプログラミング言語（例えば、ＪａｖａやＣ＋＋）だけでなく、ドメイン特化言語（例えば、ＸＭＬ：the Extensible Markup LanguageやＵＭＬ：Universal Modeling Language）のデザインを表すために使用することができる。ドメイン特化言語を使えることで、燃焼機関のエンジンまたはスライドプレゼンテーションの画像を制御するのと同じくらい多様に、デザインを指定することができる。このように、プログラム・ツリーは、コンピュータプログラムのデザイン以外のデザインを表現するので、もっと一般的に「デザイン・ツリー」とよばれることがある。例えば、スライドプレゼンテーションは、プレゼンテーションのそれぞれのスライドのためのサブツリーを有し、そのスライドのコンテンツ（またはデザイン）を示す、デザイン・ツリーによって表現されてもよい。たとえば、スライドのためのサブツリーは、そのスライドが同じ大きさの２つの箱を含むということを指定するかもしれない。そのような指定で、一つの箱の大きさが変わったときは、デザインの「同じ大きさ」という関係性によって、もう一つの箱は自動的にサイズが変わるかもしれない。燃焼機関のエンジンの場合は、それぞれのエンジンの構成部品の機能と、ユーザー定義動作環境に基づく構成部品間の相互関係を、デザイン・ツリーは指定することができる。

その分野特有の、または、設計者が慣れているビューを用いてプログラムを操作または編集することは、一般的に設計者にとって最も簡単である。例えば、ＪＡＶＡに熟練しているプログラマは、ＪＡＶＡビューを使用してプログラム・ツリーを編集することを好むだろう。一方で、Ｃ＋＋に熟練しているプログラマはＣ＋＋ビューを好むだろう。設計者は、必要とする操作のタイプによって、その時々で違うビューを使うことを好みさえするかもしれない。例えば、燃焼機関のエンジンの制御は、関数ブロックビューまたは数式ビューによって示される。他の例では、「スライド・ソーター・ビュー」、プレゼンテーションビュー、中間ビュー（すなわち、小さいスライドの次に表示される大きいスライド）で、スライドプレゼンテーションを表示することができる。

コンピュータプログラムの編集を制御するのに様々な技術が使われてきた。テキストベースのエディタと、構造化エディタがこれらの技術に含まれる。プログラマは、レターや数字やその他のキャラクターを入力するのにテキストベースのエディタを使用して、コンピュータプログラムのソースコードを作り上げる。テキストベースのエディタは、ＡＳＣＩＩ形式を使い、行末文字によってそれぞれの行を区切って、ソースコードファイルの非構造化形式にこれらの文字を格納することがある。その形式が非構造化なのは、その形式のコンピュータプログラムは解析され、構文要素を識別する必要があるからである。

構文主導型エディタとして知られる構造化エディタは、コンピュータプログラムのソースコードの正しい仕様と取扱いについて、プログラマを支援する。構造化エディタは、テキストベースのエディタの機能を実行するのに加えて、プログラマがソースコードを入力している間に、字句解析と構文解析を実行するかもしれない。構造化エディタは通常、プログラム言語構文の階層に基づいたソースコードの構造化された表現を維持する。この構造化された表現は構文木であるかもしれない。プログラマがソースコードの文字を入力するのにしたがって、構造化エディタは字句解析と構文解析を実行してもよい。もし構造化エディタが字句または構文エラーを検知したら、構造化エディタは通常プログラマに通知し、プログラマがソースコードを入力し続けることができる前に訂正を要求する。構造化エディタはコンピュータプログラムを、構造化形式または非構造化形式で保存できる。もし非構造化形式で保存されると、構造化エディタはコンピュータプログラムを、編集前の構造化形式と、編集後の非構造化形式に変換する必要がある。

米国特許第５，７９０，８６３号 米国特許第６，０９７，８８８号

コンピュータプログラムの編集を制御するのに様々なアーキテクチャを使うことができる。これらのアーキテクチャは単一編集ビュー・アーキテクチャと同期モデルビュー・アーキテクチャを含む。単一編集ビュー・アーキテクチャは通常、単一つのビューを通してのみコンピュータプログラムが編集されることを許容し、そしてコンピュータプログラムがたくさんの様々なビューで読み取り専用で表示されることを許容する。例えば、編集システムはＣ＋＋ビューを用いてのみ、ユーザーのコンピュータプログラムの編集を許可するかもしれない。ところがその編集システムは、読み取り専用のそのコンピュータプログラムのＵＭＬビューまたはいくつかの階層ビューを提供するにちがいない。そのようなアーキテクチャの不利点は、プログラマは、コンピュータプログラムを編集するのに、その編集がもっと必然的かつ容易に別のビューで実行されるかもしれない時でさえ、１つのビューを使うことを強要されることである。

同期されたビューとモデルアーキテクチャはコンピュータプログラム（つまり、モデル）をビューに適した形式に変換する。例えば、ＪＡＶＡプログラムは、ＵＭＬ（Universal Markup Language）ビューを使って、表示し編集することができる。ＵＭＬビューを生成するために、ＵＭＬ操作にもっと有益である、コンピュータプログラムの新しい表現（つまり構造化された表現）が生成される。ＵＭＬ表現になされるどんな変化でも、結局はＪａｖａテキスト表現に反映される必要がある（つまり非構造化形式）。そのようなアーキテクチャの不利点は、様々な表現を生成することはとても高価となり、それぞれ異なるビューについて実行する必要があるかもしれないことである。ほかの不利点は、表現間での変換が、とても複雑なので、しばしば矛盾もしくはデータロスという結果になることである。別の不利点は、ビュー実装間の共通性が活用されていないので、このアーキテクチャを使ったシステムの実装と拡張が難しいことである。

いずれのアーキテクチャでも、そのコンピュータプログラム（つまり、そのモデル）と、そのコンピュータプログラムを表示するユーザーインターフェース（つまり、そのビュー）と、コンピュータプログラムのその編集（つまり、そのコントローラ）の間の区別を提供するために、ＭＶＣ（model-view-controller）デザインを使うことができる。コンピュータプログラムの様々なビューを可能するために、異なるユーザーインターフェースを開発することができる。例えば、コンピュータプログラムを表示するために、Ｃ＋＋ビューとＵＭＬビューを開発することができる。これらのビューの編集技術はとても異なるものなので、それぞれのビューのために異なったコントローラと異なったモデルを開発することもまた、通常は必要となってくるだろう。例えばＣ＋＋ビューは、コンピュータプログラムを非構造化形式で保存するモデルを使うかもしれない。そしてＵＭＬビューはコンピュータプログラムを構造化形式で保存するモデルを使うことができる。このような技術の不利点は、それぞれのビューに別のＭＶＣデザインを開発するのは、時間がかかり、複雑で高価になり得ることである。例えば、永続的な保存のために使われるモデルを、それぞれのビューのモデルへ変換するために、変換ルーチンを必要とするかもしれない。加えて、ＭＶＣデザインを使用するアーキテクチャは、マルチに編集が可能なビューへの対応は組み込まれていない。このように、そのようなアーキテクチャを使うシステムはあまりモジュラー性または拡張性があるとはいえない傾向にあり、ユーザー・エクスペリエンスは満足未満となる。

デザイン・ツリーのバージョンを変換し、デザイン・ツリー（または他の構造化された表現）のバージョンに関連して識別記述を変換するための方法とシステムが提供される。一実施例において、変換システムは、順次にデザイン・ツリーのバージョンを変換（つまり、デザイン・ツリーを画面表示するための変換のような、順方向変換）し、デザイン・ツリーのバージョンに関連する識別記述を変換（つまり、デザイン・ツリーの一部のための記述のような逆方向変換）するために変換のパイプラインを提供する。それぞれの変換は、変換のトランスフォーメーションをコントロールする状態パラメータを設定するための、それぞれの変換は、コマンド・インターフェースを提供することができる。例えば、コマンド・インターフェースを通して、変換がデザイン・ツリーの一部を削除することになることを示す、木の編集のための状態設定コマンド、または、アウトラインフォームの詳細が変換によって拡張されることになることを指定する、パラメータ設定コマンドを受け取るかもしれない。ユーザー・コマンド・プロセッサは、ユーザーからの編集コマンドを入力し、識別記述に関連するコマンドの実行をもたらす、適切な変換のコマンド・インターフェースの機能を呼び出してもよい。ユーザー・コマンド・プロセッサは変換の状態情報を取り出すことができる。たとえば、そのユーザー・コマンド・プロセッサは、木の編集コマンドのオペランドとして使うための変換の、変換された識別記述を取り出すことができる。デザイン・ツリーのバージョンを変換して、デザイン・ツリーのバージョンに関連する識別記述を変換する、変換のパイプライン構造の使用により、プログラム・タスクの論理的な再分割と、編集と画面表示と変換の構成要素の再利用を許可することによって、デザイン・ツリーの編集環境の開発を容易になる。

そのパイプラインは、ソース変換と中間変換とシンク変換を含むことができる。そのソース変換は、その状態を保存したコマンドによって、デザイン・ツリーのソースバージョンを操作し、そして次の変換による入力のために操作されたデザイン・ツリーのバージョンを出力する。デザイン・ツリーのソースバージョンは、編集され持続的に保存されているバージョンである。パイプラインは、一連の中間変換を含むことができる。そしてそれは、それぞれが、パイプラインにおける前の変換からの出力であるデザイン・ツリーのバージョンを入力し、パイプラインにおける次の変換への入力であるデザイン・ツリーの変換されたバージョンを出力する。デザイン・ツリーのソースではないバージョンは、１つまたは２以上の変換によって変換されてきたデザイン・ツリーのバージョンであり、一般的に、永続的に保存されない。それぞれの中間変換もまた、デザイン・ツリーの出力されたバージョンに関連する次の変換識別記述から入力し、デザイン・ツリーの入力されたバージョンに関連する前の変換識別記述へ出力する。識別記述は、デザイン・ツリーのバージョンのサブセットを特定する任意タイプの指定機能とすることができる。たとえば、デザイン・ツリーはクラス定義を表現し、変換の入力バージョンは論理レイアウト・ビューを表現し、そして出力バージョンは物理レイアウト・ビューを表現し、そして、変換された識別記述がその論理レイアウト・ビューを参照する一方で、変換によって受け取った識別記述は、その物理レイアウト・ビューを参照してもよい。そのパイプラインは、デザイン・ツリーのバージョンを入力して、入力されたデザイン・ツリーに関連する識別記述を逆方向へ出力する、シンク変換を含んでもよい。たとえば、シンク変換はデザイン・ツリーをユーザーへ表示し（たとえば、コンピュータのモニタ上に）、そして、デザイン・ツリーの入力されたバージョンに関連したユーザーのポインティングインタラクションに基づいて、識別記述を生成してもよい。

上記に記したとおり、順方向変換は、デザイン・ツリーのバージョンを変換し、逆方向変換は識別記述を変換する。順方向変換は、ソースバージョンに近いデザイン・ツリーのバージョンを入力し、ディスプレイ装置または、デザイン・ツリーの変換されたバージョンを受け取るその他の物に近い、デザイン・ツリーのバージョンを出力する。たとえば、順方向変換は、アウトラインなしのバージョンを、アウトラインを伴ったバージョンへ変換してもよい。他の例は、順方向変換は、プログラムの抽象的なツリー表現であるバージョンを、ツリーが画面表示された時にＣ言語のプログラムに見えるような文字列を表現するノードで、従来のＣ言語構文に基づいたプログラムのツリー表現へ変換してもよい。逆方向変換は、デザイン・ツリーの出力されたバージョンの一部を指定する入力識別記述を変更して、そのデザイン・ツリーの入力されたバージョンの対応する一部を指定する。

図１は、一実施例における変換のパイプラインを表すブロック図である。パイプライン１００は、変換１０１から１０６までを含む。格納の変換１０１はソース変換である。そして、選択の変換１０２と、フィルター変換１０３と、生成論理レイアウト変換１０４と、生成物理レイアウト変換１０５は、中間変換である。そして、レンダリング変換１０６はシンク変換である。パイプラインは、出力装置１０８と、ユーザー・コマンド・プロセッサ１０９と、記憶装置１１１とをインターフェースしている。ユーザー・コマンド・プロセッサは、識別記述を、レンダリング変換へ提供する。そしてそれは、変換を通して逆方向に伝えられる。さらにユーザー・コマンド・プロセッサは、ユーザーからのコマンド（例えば、削除）を入力し、適切な変換のコマンド・インターフェースの機能を呼び出すことによって、そのコマンドを実行する。デザイン・ツリーの変換されたバージョンは変換を通して順方向に伝えられる。

それぞれの変換は、デザイン・ツリーに対する変更に基づいて順番にその変換を実行する。格納の変換は、記憶装置に永続的に格納されたデザイン・ツリーのバージョンへのアクセスを調整する。格納の変換は、メモリに格納され、デザイン・ツリーになされることになる変更に関連するコマンドを入力する、デザイン・ツリーのバージョンを出力する。

選択変換は、あるサブ・ツリーのように、選択された一部を示すデザイン・ツリーのバージョンを出力する。例えば、デザイン・ツリーがたくさんのモジュールを持つコンピュータプログラムを表現するとき、将来の編集のためにユーザーは、その時々でこれらのモジュールのうちの特定のものしか選択しないだろう。識別記述を使って選択されることになるデザイン・ツリーの一部を示す選択コマンドを、その選択の変換は受け取る。例えば、ユーザーが、デザイン・ツリーのある一部を選択するコマンドを指定するとき、ユーザー・コマンド・プロセッサは、選択変換の機能を呼び出し、そのパラメータを設定することによって、選択を行う。その選択の効果は、選択された部分を強調して、デザイン・ツリーのバージョンを出力することであるかもしれない。強調は、一実施例において、デザイン・ツリーの出力されたバージョンの適切なプロパティによって示すことができる。

フィルター変換は、ユーザー・コマンド・プロセッサによって設定されたパラメータに従って、あるタイプのデータを取り除くためにデザイン・ツリーをフィルターしてもよい。例えば、デザイン・ツリーがクラス定義を表す場合、フィルター変換は、そのクラスのメソッドの本文を取り除き、本文を表示しないように指定するパラメータに従ってメソッドのプロトタイプのみ残す。

生成論理レイアウト変換は、デザイン・ツリーの論理レイアウトを表すデザイン・ツリーのバージョンを生成する。論理レイアウト・ビューを表すデザイン・ツリーのバージョンは、画面表示可能な要素（例えば、行や段落）とそれらの論理配置のプロパティ（例えば、インデント、中央揃え、アライメント）を表すノードを持つかもしれない。例えば、生成論理レイアウト変換では、メソッドと、クラス定義のフィールドをパラメータ設定に基づいてアルファベット順に順序づけるか、もしくは長方形がクラスを表すことになり、下位の長方形がフィールドとクラスのメソッドを表すことになることを指定してもよい。

生成物理レイアウト変換では、その物理レイアウトをグラフィカルに表すデザイン・ツリーのバージョンを生成してもよい。物理レイアウトのビューを表すデザイン・ツリーのバージョンは、特定の座標系（例えば、ある基点に対するＸＹＺ座標）の中の特定の場所に表示可能な要素を表すノードを持つかもしれない。様々なパラメータがレイアウトを制御するのに設けられるかもしれない。たとえば、クラス定義のグラフィカルなレイアウトまたはアウトラインレイアウトを指定するために、パラメータが設けられるかもしれない。

レンダリング変換では、物理レイアウトのデザイン・ツリーを入力し、出力デバイスへそのレイアウトをレンダーする。レンダリング変換では、ユーザー・コマンド・プロセッサによって生成されたデザイン・ツリーの一部の識別記述（例えば、ＸＹ座標）の入力もする。

ユーザー・コマンド・プロセッサは、変換のコマンド・インターフェースの機能を呼び出すことによって、コマンドを実行し、パラメータを設定する。ユーザー・コマンド・プロセッサは、初期のパラメータ設定または構成情報１０７を、パイプラインにおけるそれぞれの変換へ提供するかもしれない。例えば、フィルターの変換のための構成情報は、デザイン・ツリーのどの情報（例えば、コメント）が常にフィルターされるかを示してもよい。当業者にとって、他の変換と、その変換の様々な順序付けが使用可能なことは、理解するだろう。例えば、一実施例において、パイプラインは、格納とドメイン表記と選択とアウトライン化とフィルタリングとソートと抽象レイアウトと具象レイアウトと、保留と物理レイアウトとスクロールとレンダリングをこの順序で含む。（保留機能は、「Method and System for Storing Pending Changes to Data」というタイトルで２００３年５月９日に登録された米国特許出願第１０／４３５，４９７号に書かれている。）
一実施例において、ソース・ドキュメント（例えば、デザイン・ツリーのソースバージョン）の「永続バージョン管理」をサポートするために、変換システムを使うことができる。ユーザー・コマンド・プロセッサによって、格納の変換へ提供されたコマンドは、ソース・ドキュメントを作成し、修正する必要があるすべてのコマンドを表す。例えば、追加コマンドは、挿入箇所にあるドキュメントへ追加する要素を指定する（たとえば、識別記述）。一方で、削除コマンドは、識別記述によって示されている削除する要素を指定する。これらのコマンドの完全な設定は、ドキュメントを定義する。変換システムはこれらのコマンドを、それぞれのコマンドについて、タイムスタンプやバージョンなどと共に格納してもよい。変換システムは、その時までのコマンドを実行することによって、またはその時の後に実行されたコマンドの成果を取消すことによって、ある時間（または、ソース・ドキュメントのバージョン）についてのドキュメントの状態を生成することができる。コマンドのシーケンスは、様々なユーザーによってドキュメントになされた編集をマージするときにも使うことができる。

図２は、一実施例における、変換のコンポーネントを示すブロック図である。次の例はデザイン・ツリーの単なる一例として、プログラム・ツリーに関して記述されている。変換２００は、プログラム・ツリー２０１と識別記述２０２と構成データ２０５とコマンド２０６を入力し、プログラム・ツリー２０３と識別記述２０４を出力する。変換は検証コンポーネント２１０を含み、それはプログラム・ツリーの入力されたバージョンが、プログラム・ツリーのスキーマに対応するかどうかを検証する。変換は、順方向（またはプログラム・ツリーの）変換の構成要素２２１と、逆方向（または識別記述の）変換の構成要素２２２を含む。順方向変換の構成要素は、プログラム・ツリーのバージョンの入力を、プログラム・ツリーの出力バージョンへ変換し、出力されたプログラム・ツリーの要素から、入力されたプログラム・ツリーの要素へのマッピングを生成し、その状態で格納する。逆方向変換の構成要素は、マッピングに従って識別記述２０２を、出力されたデザイン・ツリーの要素を識別することから、入力されたデザイン・ツリーの要素を識別することへ、変換する。順方向変換と逆方向変換の構成要素は、状態格納２２３に状態情報（例えば、そのマッピングとパラメータ）を格納する。状態格納は、そのプログラム・ツリーの入力されたバージョンと、そのプログラム・ツリーの出力されたバージョンのメモリ内表現を含んでもよい。コマンド・インターフェース２２５は、コマンド・プロセッサからのユーザー・コマンドを入力し、コマンドに従って入力されたプログラム・ツリーを操作するインターフェースを提供し、パラメータを設定して、変換処理を制御する。

それぞれの処理は、出力されたプログラム・ツリーに関係する識別記述は、入力されたプログラム・ツリーに関係する識別記述へ変換されうるようにマッピングを維持する。たとえば、プログラム・ツリーは、２つの引数（例えば、ｆ（１，２））をもつ機能を表すかもしれない。この入力されたプログラム・ツリーは、それぞれの引数のための子ノードとともにこの機能の親ノードを含むかもしれない。出力されたプログラム・ツリーもまた、それぞれの引数のための子ノードと親ノードを含むかもしれない。しかし左括弧とコンマと右括弧のための子ノードも持つかもしれない。マッピングは、引数に対応する親ノードと子ノードを、マップするだろう。マッピングもまた、出力されたプログラム・ツリーの括弧とコンマを表すノードを、それぞれ入力されたプログラム・ツリーのノードへマップするかもしれない。例えば、括弧とコンマを、それぞれ入力されたプログラム・ツリーの親ノードへマップするかもしれない。しかし、そのような多から一へのマッピングは、一つの変換から前の処理の間に情報が脱落するかもしれない。そのような脱落を防止するために変換は、もっと詳細化されたマッピングを提供する仮想の識別子を識別記述へ追加してもよい。例えば、マッピングは２つの部分の仮想の識別記述を提供するかもしれない。第一の部分は、入力されたツリーのノードを特定することができ、第二の部分は、マップされた出力プログラム・ツリーのノード間の、特有のノードを特定する、仮想の識別子かもしれない。（例えば、「ｆ」または「（」。）このように、ユーザー・コマンド・プロセッサは、識別されたノードに基づいてだけでなく、どのようにノードが特定されたかに基づいて、コマンドを実行することができる。

いくつかの変換は、すべての出力がパイプラインにおける次の変換に適切になるまでのように、パイプラインにおいて不特定回数、適用されるかもしれない。たとえば、デザイン・ツリーの一部は、その処理のために、その同じ変換の２回の適用を必要とするかもしれない。変換の最初の適用は、入力されたデザイン・ツリーを構成要素のグリッドに変換するかもしれない。そして二つ目の適用はグリッドを構成要素のリストへ変換するかもしれない。それぞれの変換の適用はそれ自身のマッピングを維持するだろうが、コマンド・インターフェースは一つしかないだろう。現在の変換に適切であるが、次の変換には適切でない出力を（前述の例のグリッドのように）生成するであろう、デザイン・ツリーの一部に出くわすとき、マッピングの新しいインスタンスが、インスタンス化されるだろう。一実施例において、変換のためのノードの適合性は、「スキーマ」と呼ばれる定義の使用によって決定される。そしてそれらもまたデザイン・ツリーに格納される。
変換システムにより、コマンドが上記のコマンド処理装置を通して、またはプログラム・ツリーそれ自身の選択を通して、指定され得るようになる。プログラム・ツリーがレンダリングされる時、それは画面表示を制御し、要素を編集するためのハンドルを含んでもよい。例えば、レベルが拡大または縮小されることになるかどうかを示すために、アウトラインがそれぞれのレベルで、「＋」または「−」ハンドルで画面表示することができる。「＋」が選択される時、「＋」の識別記述は、フィルター変換のように、「＋」選択に関連づけられたコマンドを変換が処理できるまで、その変換を通して逆方向に伝えられる。フィルター変換は、選択されたレベルの拡張とそのレベルに関連付けられた「−」ハンドルで、新しいプログラム・ツリーを出力してもよい。もしそれからその「−」ハンドルが選択されると、その識別記述はもう一度逆方向に伝えられ、次にフィルター変換は、「＋」ハンドルでその縮小されたレベルを出力するだろう。対照的に、コマンド処理装置は、メニューを通して、またはプログラム・ツリーの一部の選択に直接結びつけられない他の方法によって指定することができるコマンドを受け取る。コマンド処理装置またはプログラム・ツリーの一部の選択を通して指定されたかに関わらず、拡張／縮小コマンドのようないくつかのコマンドは短命で、プログラム・ツリーの永続的変更という結果にはならない。そのような変更は、変換のパラメータとして表現されてもよい。たとえば、アウトラインのそれぞれのレベルは、その出力バージョンを生成する時にフィルター変換が使う、拡張／縮小パラメータを有することができる。しかし、そのようなパラメータは逆方向の格納の変換へ伝えられない。

図３から６は、一実施例におけるプログラム・ツリーのバージョンを表す図である。図３は、一実施例における選択変換によって出力されたプロラム・ツリーのバージョンを表す図である。プログラム・ツリー３００は、メソッド「Ａ」と「Ｂ」と、フィールド「Ｘ」と「Ｙ」を含むクラス定義を表す。プログラム要素３２０はメソッド「Ａ」を表し、プログラム要素３２１から３２５まではメソッドを定義する。この例において、プログラム・ツリーはクラス「Ｃ」に対応する。図４は一実施例においてフィルター変換による出力であるプログラム・ツリーのバージョンを表す図である。この例において、フィルター変換は、メソッドの本文とメソッドに関連付けられたコメントを、コマンド処理装置によって設定されたパラメータに応答してフィルターした。図５は、一実施例において、生成論理レイアウト変換によって出力されたプログラム・ツリーのバージョンを表す図である。この例において変換は、コマンド処理装置によって設定されたパラメータに応答し、プログラム・ツリーのプログラム要素を再配置して、メソッドの前にフィールドを位置づけ、そしてフィールドとメソッドをアルファベット順にした。図６は、一実施例において、生成物理レイアウト変換によって出力されたプログラム・ツリーのバージョンを表す図である。この例において、長方形６０１がクラス「Ｃ」とサブ長方形６０４から６０７までを表すことになるか、またはクラスのフィールドのメソッドを表すことになることを、変換は指定する。それぞれの長方形は、座標とラベルを関連付けた。図７は物理レイアウトのレンダリングされた表現を表す。

図８は、一実施例において、プログラム・ツリーの一部を強調するための変換パイプラインの処理を表すブロック図である。この例において、ユーザーは、長方形内の点を選択することによって画面表示された長方形を選んでいる。コマンド処理装置は、座標を指定する識別記述でレンダリング変換を提供する。レンダリング変換は、物理レイアウトに関係付けるために識別記述を変換し、それを生成物理レイアウト変換へ提供する。物理レイアウト生成変換は、論理レイアウトに関連付けるために識別記述を変換し、それを生成論理レイアウト変換へ提供する。識別記述を変換するために、その生成物理レイアウト変換は物理レイアウトのプログラム・ツリーを検索し、座標を持つ長方形を特定する。この例において、その変換は、座標がメソッド「Ａ」のラベルを含む長方形に対応させることを示すために、マッピングを使用することができたかもしれない。生成物理レイアウト変換はそれから、生成論理レイアウト変換へ、変換された識別記述を提供する。生成論理レイアウト変換は、コマンド処理装置からの強調コマンドを入力し、論理レイアウトのプログラム・ツリーを更新し、識別記述によって示されたようにメソッド「Ａ」を強調されるべきものであることを示す。生成物理レイアウト変換は、強調表示をもたらすために、更新された物理レイアウトのプログラム・ツリーを生成する。そしてレンダリング変換は、メソッド「Ａ」に対応する長方形を強調するビットマップを出力する。

図９は、一実施例において、プログラム・ツリーの一部を削除するための、変換パイプラインの処理を示すブロック図である。この例において、ユーザーがプログラム・ツリーの一部を削除することを指定する時、プログラム・ツリーの現在選択されている部分は削除されることになる。ユーザーが削除することを指定するとき、ユーザー・コマンド・プロセッサは、変換された識別記述を渡して、格納変換の削除機能を呼び出す。識別記述は、削除機能のオペランド（または引数）として使うために、コマンド処理装置によって、格納の変換から取り出されるかもしれない。格納の変換はプログラム・ツリーを削除メソッド「Ａ」に変える。格納の変換は、その変更を永続的に格納、またはコミット命令を受け取るまで一時的に格納するかもしれない。格納の変換は、それから、メソッドが削除されたということを反映するクラスの表現をレンダリング変換が出力するまで、パイプラインを通って伝えられる選択の変換へ、更新されたプログラム・ツリーを提供する。コマンド処理装置によって格納変換へ提供されたコマンドのシーケンスが、プログラム・ツリーを定義する。図１０は、一実施例における、プログラム・ツリーへ変更をコミットする変換パイプラインの処理を示すブロック図である。

一実施例において、変換は、パイプラインにおける後続の変換によって現在必要とされる出力のバージョンの一部のみ生成するのに、据置きまたは遅延の評価技術を使ってもよい。たとえば、物理レイアウト変換は、画面表示上で可視になることになるデザイン・ツリーの一部について、変換を実行するだけかもしれない。ウィンドウの大きさ、またはデザイン・ツリーの中の現在の位置を示すパラメータ設定に基づいて可視である一部を、変換は指定するかもしれない。ウィンドウが拡大されるとき、または現在の位置が移動されるとき、変換は、例えば、ユーザー・コマンド・プロセッサが適切なパラメータを設定した後に新しく可視になる部分の変換を実行するだろう。いくつかの処理は、ノードのサブツリー上に変換を実行するよりむしろ、出力バージョンのノードとしてスタブまたはプロキシを追加するかもしれない。後続の変換がスタブにアクセスする時、スタブは変換に、デザイン・ツリーの出力バージョンの一部を生成させる。

変換システムは、ＣＰＵ（中央演算処理装置）やメモリや入力装置（例えば、キーボードや、ポインティング・デバイス）や出力装置（例えば、画面表示装置）や記憶装置（例えば、ディスクドライブ）を含むコンピュータシステム上に実装されるかもしれない。メモリと記憶装置は、コンピュータ可読メディアであり、それは変換システムを実装する命令を含むかもしれない。加えて、データ構造とメッセージ構造は、格納または、通信回線上の信号のようなデータ伝達媒体を介して伝えられるかもしれない。インターネットまたはＬＡＮ（ローカルエリア・ネットワーク）またはＷＡＮ（広域ネットワーク）またはポイント・ツー・ポイント（２点間）ダイヤルアップ接続などの様々な通信回線が使われてよい。

図１１は、一実施例における、生成物理レイアウト変換の、逆方向変換の処理を表すフロー図である。この変換は、識別記述としての座標を通される。その変換は、座標と論理レイアウトのプログラム・ツリーの対応する要素を含む、物理レイアウトのプログラム・ツリーの要素を特定し、その要素をマップする。ブロック１１０１では、変換は、物理レイアウトのプログラム・ツリーのルート・ノードを選択する。ブロック１１０２では、変換は、座標へ対応する物理プログラム・ツリーの要素を検出する構成要素を呼び出す。ブロック１１０３では、変換は、物理プログラム・ツリーの要素に対応する論理プログラム・ツリーの要素を検出する。変換がはじめに物理レイアウトのプログラム・ツリーを生成するとき、それは、物理レイアウトのプログラム・ツリーの要素と、論理レイアウトのプログラム・ツリーの要素の間のマッピングを生成したのかもしれない。ブロック１１０４では、識別記述としての論理レイアウトのプログラムの要素の識別表示にそって演算子を出力し、そして終了する。

図１２は、一実施例における、物理レイアウト・コンポーネントの要素を検出することを示すフロー図である。そのコンポーネントは、座標を含む物理レイアウトのプログラム・ツリーのサブツリーのルート・ノードを通される。そのコンポーネントは、座標を含む最内部の要素へ見つけるために、再帰的に呼び出される。決定ブロック１２０１にて、もしルート・ノードが子要素を持つと、コンポーネントはブロック１２０２に続き、そうでなければ、コンポーネントは、最内部の要素なので、ルートを返す。ブロック１２０２から１２０４において、コンポーネントは、ループして座標を含むその子要素を特定する。ブロック１２０２では、コンポーネントは次の子要素を選択する。決定ブロック１２０３では、もしすべての子要素が既に選択されていたら、コンポーネントはエラーを返し、そうでなければ、そのコンポーネントはブロック１２０４へ続く。決定ブロック１２０４では、座標が選択された要素中であれば、そのコンポーネントはブロック１２０５へ続き、そうでなければ、コンポーネントは次の子要素を選択するためにブロック１２０２へループする。ブロック１２０５では、コンポーネントは、選ばれた要素を渡して、それ自身を再帰的に呼び出す。その後、そのコンポーネントは、ブロック１２０５の再帰呼出しによって返される要素を返す。

当業者にとって、変換システムの具体的な実施例が、例示の目的のためにここに記述されてきたが、様々な変更が、発明の趣旨と範囲から外れることなくなされ得ることは、理解されるだろう。一実施例において、変換とパイプラインの状態を様々なビューによって共有することができる。たとえば、Ｃ＋＋ビューとＵＭＬビューは、図１の格納と選択の変換を共有できる。選択の変換は、Ｃ＋＋ビューとＵＭＬビューのフィルター変換に接続されるだろう。プログラマは両方のビューを使って同時に見て編集できる。ＵＭＬを通してのプログラマの入力は、共有された選択の変換に対する命令としてＵＭＬパイプラインの逆方向に伝搬することができる。それから選択の変換は、ＵＭＬパイプラインとＣ＋＋パイプラインの両方を通して順方向に伝搬することができる、プログラム・ツリーの変換されたバージョンを出力することができる。このように、パイプラインは様々な変換で生じる枝をもつ、ツリー構造として表現されうる。当業者は、その記述された変換はただ単に表現にすぎないこともわかるだろう。幅広い種類の機能が変換によって実行され、変換は異なるレベルの細分性で開発することができる。たとえば、コンピュータプログラムが暗号化された形式で格納されていると、暗号化／復号化変換が使われるかもしれない。もう一つの例では、コンピュータプログラムが非構造化形式で格納されていると、構造化形式へ変換する変換が使われるかもしれない。また、それぞれのビューが同じシーケンスの機能を使うとき、様々な変換の機能を組み合わせることができる。その機能はパイプラインのモジュールアーキテクチャによって、拡張され、他の変換機能と組み合わされる。このように本発明は添付の特許請求の範囲によって定義される。

一実施例における、変換のパイプラインを示すブロック図である。 一実施例における、変換の構成要素を示すブロック図である。 一実施例における、選択の変換によって出力されたプログラム・ツリーのバージョンを示す図である。 一実施例における、フィルター変換によって出力のプログラム・ツリーのバージョンを示す図である。 一実施例における、生成論理レイアウト変換によって出力されたプログラム・ツリーのバージョンを示す図である。 一実施例における、生成物理レイアウト変換によって出力されたプログラム・ツリーのバージョンを示す図である。 物理レイアウトのレンダリングされた表現を示す。 一実施例における、プログラム・ツリーの一部を選択する変換パイプラインの処理を示すブロック図である。 一実施例における、プログラム・ツリーの一部を削除する変換パイプラインの処理を示すブロック図である。 一実施例における、プログラム・ツリーに対する変更をコミットする変換パイプラインの処理を示すブロック図である。 一実施例における、生成物理レイアウト変換のバックワード変換の処理を示すフロー図である。 一実施例における、物理レイアウト構成要素内の検出プログラム要素を示すフロー図である。

Claims (25)

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. 前記編集コマンドは削除コマンドであることを特徴とする、請求項２１に記載のコンピュータシステム。

Images