JP2000507373A

JP2000507373A - インタラクティブソフトウェア開発システム

Info

Publication number: JP2000507373A
Application number: JP9530969A
Authority: JP
Inventors: ガスタフソン，ニクラス; ハンビー，ジョン; ロウ，パトリック
Original assignee: アシメトリックス・コーポレイション
Priority date: 1996-02-29
Filing date: 1997-02-26
Publication date: 2000-06-13
Also published as: WO1997032250A1; US5764989A; AU1956897A; EP0883844A1; CA2248181A1

Abstract

(57)【要約】従来のソフトウェア開発に関して必要とされていたコンパイラ及びリンカ、デバッガを置き換えるインタラクティブプログラム開発システムである。本発明は、コードオブジェクト（４）と呼ばれる新規な形式の変換構造を作り出すための新しいプログラム編集システムを含み、コードオブジェクト及び持続シンボルテーブル（５）内に格納されるそれらのそれぞれの中間言語シンボルからプログラムメージを形作るインクリメンタルイメージ（６）を含む。この新しいプログラム編集システムは、ＣＰＵ及びモニタ、メモリシステム、入力装置を有する従来のコンピュータ上で操作される。本発明は、開発下においてもしくはプログラム作成エラーを訂正する保守更新に際して、プログラムの実行を停止させる必要を回避する。

Description

【発明の詳細な説明】インタラクティブソフトウェア開発システム著作権の告示この特許出願の一部分は、著作権保護を受ける題材を含む。著作権の所有者は、全ての著作権の権利を確保してはいるがしかしながら、それが特許及び商標庁において特許の提出もしくは記録が明らかであるように、特許の文書もしくは特許の開示の何れかによる複製の模造品に異議を唱えるものではない。発明の分野本発明は、コンピュータ援助ソフトウェア技術に関し、より詳しくは従来技術のコンパイラ及びリンカ、デバッガを単一プログラムに置き換えるインタラクティブプログラム開発システムに関する。本発明は、特にオブジェクト指向プログラム作成に適用される。本発明のプログラム作成システムは、従来技術のコンパイラよりもはるかに速い速度で操作するばかりではなく、より重要なことにはソフトウェアの開発及び保守に際してプログラム上のエラーを訂正する目的でプ口グラムの実行を停止する必要を排除する。換言すれば、本発明は、バッチ再編集、再リンク、再ロードを必要とせず、又は開発者がエラー状態を再現する必要がなく、それが編集される（「組立てられる」）ようにプログラムのインタラクティブ「リアルタイム」デバッグを可能とする。発明の背景コンピュータソフトウェア製品（以降「ソフトウェア」）の開発は、ソフトウェア開発チーム（以降「開発者」）の方では著しい時間の消費を必要とする複雑な循環プロセスである。この開発プロセスは、開発プロセスの主要なステッブの一部を参照する、「エディット−コンパイル−リンク−ラン」もしくは「エディット−コンパイル−テスト」に基づいてしばしば参照される。実用上の優位及びプログラマーの生産性の理由で、相当な量の商用生産ソフトウェアが、最近オブジェクト指向プログラム作成言語（ＯＯＬ）を利用して開発されている。一例として、制限はしないが、このようなオブジェクト指向プログラム作成を支援する言語としてＣ++及びスモールトークを挙げることができる。これらのオブジェクト指向言語を利用して開発されるプログラムは、機械コードフォーマットで書かれてはおらず、したがってそれらが書かれているＯＯＬソースコードから機械実行可能なオブジェクトコードに変換されなければならない。このような機械コードプログラムは、効率良く、したがって与えられた計算プラットフォーム上で迅速に機能する。これは典型的には、コンパイルもしくは翻訳のプロセスを介してなされる。コンパイラは、ハードウェアによって実行される機械レベルの命令にソースコードを変換する。インタプリタは、ソースコードを擬似コード（以降ＰＣＯＤＥ）に変換し、これはＰＣＯＤＥインタプリタを利用して実行される。インタプリタは、それが実行される際にプログラマがプログラムに効果的な変換を可能とすると同時に、ＰＣＯＤＥインタプリタは、プログラマとハードウェアの間の特別なレベルを導入し、さらに性能を低下させる。最も単純なプログラムを除いてセクション例えばモジュールで書かれているために、ソースコードモジュールの各々は、完全なプログラムのイメージ（以降「イメージ」）を形成するのに関連付けられなければならない。この関連付けプロセスは典型的には、他のものの中でモジュールの各々が正しくアドレスされること及び正しくアドレス可能であることを確実とする、「フィックスアップ」を含む。一度関連付けられると、イメージはロードされて実行されなければならない。実行に際して、及び開発者がイメージ内のエラー（もしくは「バグ」）に遭遇すると、プログラムは典型的には、実行を停止されもしくは不規則にふるまう。伝統的には、分離したプログラム、デバッガ、が欠陥のある実行プログラムにエラーを決定するのに助けとなるように引き出される以前に、プログラムの実行が停止されもしくは停止されなければならないことを意味する。開発者がデバッガを利用してエラーの源を確認した後、開発者は、エラーを排除するようにソースコードを編集し、コードを再コンパイルし、それを再リンクし、さらにそれを再ロードする。さらにプログラマーは、フィックスの効率を確かめるために破損を結果として生じさせる正確なエラー状態を再現しなければならない。結局従来技術のコンパイラは、有効な機械コード実行可能ファイルを作り出す一方で、デバッグする際にこのようなファイルの使用は、扱いにくくもあり時間の浪費ともなった。これは、実際には、他のソースコードファイルによって引き出されるソースコードファイルに変更することであり、この他のソースコードファイルは最小限、影響を受けたファイルの各々の再コンパイル及びプログラムイメージ内に全ての結果オブジェクトコードファイルの再リンクを予め必要とする。前述のソフトウェア開発のステップの各々が、有能な演算の専門家によって処理されなければならないために、ステップの各々に対するコストは高い。それによって、開発サイクルの効率を増すような方法及びシステムを開発することが、長い間のそして依然としてソフトウェア開発業界の主目的である。このために、改良が多くの開発ステッブに対してなされている。 McKeemanらに対する一連の米国特許（Nos.5,170,465；5,182,806；5,201,050 ；とりわけ5,325,531）は、「ＲＣＡＳＥ」と呼ばれるコンピュータ支援ソフトウェア技術システムを教示する。ＲＣＡＳＥシステムは、インクリメンタルスキャナ及びインクリメンタルリンカ、インクリメンタル構造ファシリティ、スラッシングを減少させる仮想メモリマネージャーを含む細粒度インクリメンタルコンパイラを使用する。この技法はソフトウェア開発サイクルに際して実施の経済性を提供するが一方で、いくつかのそれの持つサイクルを加えると同時に、従来の開発サイクルの多くのステップを持ち続ける。したがってＲＣＡＳＥは、新しい開発システムよりはむしろ従来の開発サイクルに対するインクリメンタル改良を意味するようである。米国特許第5,193,191号においてMcKeemanらは、先に議論したインクリメンタルリンカを教示する。他のインクリメンタルコンパイラは、Smithらによって米国特許第5,204,960号において教示される。この米国特許第5,204,960号のコンパイラはシステムを教示し、それによってソース及びオブジェクトファイルが論理ブロックに組織化されて格納される。中間ファイルは、これら論理ブロックに関しては情報を含んで作り上げられ、同様に格納される。変更がソースファイルの一部分に対してなされるならば、単に複雑にされた論理ブロックが、再コンパイルされてオブジェクトファイルにパッチされる。再度、Smithは従来のソフトウェア開発サイクルの１段階に対してインクリメンタル改良を示した。 Taligent,Inc.に対するWO95/00901及びWO95/00904は、インクリメンタル構造システム及びリンカシステムを教示する。要するにこれらの参照は、従来のバッチモードプログラム作成システムを置き換えることを試みる。代表的なコンパイラシンボルテーブルにおいて、他のデータに対する参照は、データアイテムの内容の半分よりも多くしばしば作り上げられる。したがって参照変換は、計算のオーバーヘッドの有効なソースを示す。変換の問題に対する１つの解決は、参照WO95 /00901に教示されるように、Ｉｄを使用することである。参照WO95/00901によって教示されるインクリメンタルビルダーは、プロジェクトコンポーネント及び形成コンポーネントの収集のようなコンピュータプログラムのモデル化を教示し、それぞれ単一のコンパイル可能な言語要素を示す。コンピュータプログラムにモデルを提供するこれらのコンポーネントは、形成プロセスの際のアクセスのために格納される。格納されたコンポーネントは、決まった手順により、クライアントの開発に適合するコンポーネント及び参照リストに関連した従属物である、コンパイラを使用して、アクセスされる。最後にコンポーネントは、コンパイラの従属物と一緒にコンポーネントのプロパティーを使用してコンピュータプログラムを形成するようにコンパイルされる。したがって参照WO95/00901は、プログラムがファイル内に画定されるのではなく、Ｉｄの手段によってアドレス可能に、コンポーネントのアイテム内に画定されるシステム上を読む。このように、参照WO95/00901は、先に議論された変換問題を有さずに、多くの独立したアドレス可能な（及び妥当な複雑さの）コンポーネントにそれを置き換えるシステムを教示し、これらは計算の経費の主要な原因である形成すること及び利用することである。これらはこのシステムの計算の効率の不足に一因となる。参照WO95/00904は、開発サイクルのエディット段階に際して修正されるこれらのコンポーネントにのみリンクする、参照WO95/00901のインクリメンタルビルダーによって作り上げられる独立したアドレス可能なコンポーネントを利用するインクリメンタルリンカを教示する。要するに、参照WO95/00901及び参照WO95/009 04によって教示されるシステムが、従来のソフトウェア開発サイクルのステップに対してインクリメンタル改良を再度示す、そのことが評価される。これらのステップを実行する必要は変わらずに残る。前述の議論から、相当な努力がソフトウェア開発サイクルのいくつかのステップの効率のために費やされてきていることが評価される。現在までに、実現されていないものは、開発サイクルのステップ数を減らすことにより起こらなければならない、プログラマーの効率における相当な増加である。さらに、前述の発明のいくつかは、それらのどれもが少なくともそれらのステップのいくつかを別々に；すなわちバッチモードにおいてある程度までは、実行するための必要を完全に排除していないが、従来のソフトウェア開発サイクルの「バッチ処理メンタリティー」のいくつかを克服していることが評価されるであろう。よって１つの根源的な状態は：一度エラーが発見されると、プログラムの実行が停止されなければならず、さらにデバッグに際して何らかの発見された実際のエラー及び、その後エディットに際して何らかの訂正される実際のエラーが取り除かれるであろうことを克服する。ファイルのエディット（すなわちフィックスがバグを取り除くのに有効である）に際してエラーが実際に訂正されることを確実にする目的で、プログラムの正確な状態、そのエラー状態が再現されなければならない。プログラムの実行が停止されていると、開発者は再度走らせるプログラムを再ロードしなければならず、破損におけるそのエラー状態を正確に再現して各々の及び全ての変数がエラーの発生したその時の以前の値に設定されることを確実にしなければならない。したがって開発者が複雑なソフトウェアシステムの再現に取り組んでいるときに、エラー状態は非トリビアルタスクである。さらにこのステップは、エラー状態が実際に繰り返されているならば、画定するのが困難であるより一層の問題のあることを示し、さらに後置の妥当性検査は時間を消費し、高価であり、エラーしがちであるようにする。サイクルの各繰り返しの際、開発者を示すことにより開発サイクルを少数のステップに再画定する開発システムは、従来技術のスキーマを越えて時間及び価格において相当に経済的であることを示すであろう。さらにこのシステムが従来の編集スキームよりも一層効果的であり、一層高速の実行速度を示すならば、経済性は実現可能である。プログラムの実行を停止することなく、開発者がソーステキストを相互に作用し合ってデバッグ及びエディットすることが可能であることをただある方法論が見出すのであれば、その方法論は一度にエラー状態を再現すること必要性を回避し、フィックスの効果を実証するであろう。したがって開発者の生産性の深く今まで達成できないレベルが実現される。発明の開示本発明の一局面によれば、インタラクティブコンピュータプログラム開発システムが提供され、このシステムは、バッチ再コンパイルもしくは再リンク、再ロード、開発者がエラー状態を再現する必要性を必要とせずにコンパイルされるような、プログラムのリアルタイムデバッグが可能である。本発明の原則に従えば、このインタラクティブシステムは、デバッガレジデントを備え、ソースコードファイルの所定のセットを有する、コンピュータシステムを含む。開発者は最初にソースコードファイルの所定のセットをデバッガに呼び出し、システム内のインクリメンタルビルダーレジデントは、ソースコードファイルをコードオブジェクトに変換するものを呼び出され、それらは中間言語（ＩＬ）シンボルに対応する。コードオブジェクト及びＩＬは、常駐の持続するシンボルテーブル内に格納される。常駐インクリメンタルイメージャはコードオブジェクト及びＩＬシンボルを利用してランタイムコードオブジェクトを形成する。さらにインクリメンタルイメージャは、実行可能なプログラムイメージを形成するランタイムコードオブジェクトにリンクする。プログラムイメージ及びコンピュータプログラムの動作は、プローブ及びランナを介して調整される。プローブはインクリメンタルイメージャプロセス内で実行し、ランナは構成プログラムのプロセス内で実行する。よってイメージは実行され、イメージは、メモリマップデータを利用する実行の２つの分離したスレッド内で同時にプログラムを具象化する。本発明の原理によれば、新しいコンパイラシステムの手段（以降インクリメンタルビルダーと称される）によって遂行され、これは変換構造の新しい型、コードオブジェクト；及びインクリメンタルイメージャを作り出し、インクリメンタルイメージャはコードオブジェクトからブログラムイメージを形成し、それぞれの中間言語（ＩＬ）は持続するシンボルテーブル内に格納される。イメージが形成された後、プログラムは分離して保護されるアドレス空間の実行分離スレッド内で実行される。プロプラエタリデバッガは、形成されたイメージ及び実行可能なプログラムを利用する仮想リアルタイムにおける開発下で、プログラムをデバッグすることにおいて、相互に作用して開発者を助ける。最終的に所定のプログラムが構成され、完全にデバッグされた後、開発者は実行可能ファイル（例えば「ＥＸＥ」ファイル）に転換するエクストラクタを引き出す。「実行のスレッド」は、以降プログラムの論理構造と称され、実行の各スレッドは、実行される命令のそれ自身の決まった手順を有する。「アドレス空間」は、スレッドの空間設定に対して独特であるメモリアドレスのマップである。各アドレス空間及びスレッドのそれに関連した設定は「プロセス」を画定する。コードオブジェクトは、Ｉｄに対比されるような直接メモリ参照の手段によって他のコードオブジェクトを示すＩＬシンボルを参照する、機能定義もしくは可変の初期値の完全に変換された機械語実施である。コードオブジェクト及びＩＬシンボルは、イメージすなわち「プログラム」を作り出すのに使用される低いレベルのデータ構造である。コードオブジェクトは、機能が参照するそれらのシンボルの記述を含む。ＩＬシンボルは、機能を参照するそれらのコードオブジェクトの記述を含む。コードオブジェクト及びそれらそれぞれのＩＬシンボルは、言語シンボルテーブルオブジェクトと同様に、持続するシンボルテーブル内に格納される。本発明のシステムの動作の概観は次の通りである：所定の実行可能ファイル（例えば全てのプログラム）もしくは未解決な外部参照（例えばダイナミックリンクライブラリィ）を備えないプログラムの独立部分を確定するソースコードファイルを作り出した後、開発者はソースファイルをデバッグするようにデバッガーを引き出す。さらにデバッガーは本発明のインクリメンタルビルダーをプログラムに基づいて引き出し、インクリメンタルビルダーは、ソースコードが持続するシンボルテーブル内に予めコンパイルされセーブされているならば、最初に決定する。ソースコードが予めインクリメンタルにコンパイルされていない（以降「コンパイルされた」なる用語は「形成された」という語に置き換えられ、後者の語は実際のプロセスを一層説明するものである）限りにおいては、インクリメンタルビルダーは、持続するシンボルテーブル内に予め形成されたバージョンが存在しないということを決定し、全体としてファイルを変換するであろう。ソースコードがエディットされ、したがって予めインクリメンタルに形成されている限りにおいては、インクリメンタルビルダーは、持続するシンボルテーブル内に予め形成されたバージョンが存在するということを決定して、オリジナルソースコードのエディットされた部分によって影響を受けたコードオブジェクトのソースコードのそれらの部分を変換するのみであろう。持続するシンボルテーブルは、オブジェクト指向データベースの形態を取る。この前後関係から、持続するということは持続するデータ格納装置に格納することが可能であるということを意味し、このような格納が実際に起こる必要がないということが注目される。もちろん、例えば作業日の終わりにおいて、開発者が開発下にあるプロジェクトの作業を中止するとき、持続するシンボルテーブルは、持続する格納装置のようなものの中にうまく格納されるであろう。慎重な計算の実施は常にそのように指示されるであろう。オブジェクト指向データベースの使用は、ファイル内の正確な同様の構造を利用して、インクリメンタルビルダーがデータ構造を形成することを可能とし、この構造はそれが実行される際にインクリメンタルビルダーによってシステムメモリ内で使用される。これはファイルフォーマットとメモリフォーマットの間の変換において時間の浪費がないという結果を生じ、したがって冗長を排除して以前のコンパイラを越えて実行速度を相当に増加させる。データベースはシステム動作が終了しても破棄されない。インクリメンタルビルダーによってそれらが形成された後、コードオブジェクトに対応するＩＬシンボル及びそれらはメモリ内に格納される。イメージ形成の際、コードオブジェクトは、インクリメンタルイメージャによって複製されてランタイムコードオブジェクトとしてイメージを形成される。イメージが形成された後、プログラムは分離して保護されるアドレス空間の実行分離スレッドの下で実行される。プローブ及びランナは、開発システム及びイメージ（プログラム開発を具体化する）の動作を調整する。プローブはイメージャプロセスにおいて実行し、ランナは形成されたプログラムのプロセスにおいて実行する。プログラムが実行されているときにエラーが検出されると、ランナの下のプ口グラムの実行は停止される。オペレーティングシステムは、プログラム破損に関するデータをデバッガに伝達し、デバッガはソースコードのラインが破損の原因となるそれに関する情報にこのデータを伝達する。デバッガが開発者に破損を知らせると、この情報は彼又は彼女に伝えられる。開発者がソースコードファイルをエディットしてプログラムの破損を得た後に、彼はシステムにインクリメンタルにコンパイルしてプログラムの変更部分を更新するように指示することができ、この変更部分は、これらの修正を実行する新しいＩＬシンボル及びコードオブジェクト内に結果として生じる。ビルダーは、エディットされたソースコードに関連するこれらのプログラムユニットのみをインクリメンタルにコンパイルする。新しいコードオブジェクト及びＩＬシンボルから、インクリメンタルイメージャは、プログラムの更新されたイメージを形成して、プログラムの実行を続ける。従来の技術によって必要とされるステップが最初に.ＥＸＥファイルを更新してソースコードにリンクしてロードし、さらに破損が排除されることを生じる正確なエラー状態を再現するということであることが注目される。所定のプログラムが形成されて完全にデバッグされた後、プログラマーは、分離したモジュールの手段、エクストラクタによって実行可能ファイル（例えば「 .ＥＸＥ」ファイル）内にそれを転換する。この.ＥＸＥファイルは、従来の開発システムによって及びアプリケーションプロセスを開始させる基本的な動作システムによって利用されるイメージである。.ＥＸＥファイルは、ソフトウェアの製造レベルの分配にとって大変に有効であり：独立のソフトウェア製品を製造する目的において以前としてこれらは確かに必要である。それらがほとんど変化しない性質であるためにうまく適合しないので、ソフトウェア開発プロセスにおいて.ＥＸＥファイルの使用の必要性は、長くは必要とされない。持続するテーブル内に常駐するコードオブジェクトは持続し、システム終了もしくはデバッグ、他のプログラマーの動作の結果変更されない。機能（もしくはデータ）定義が再コンパイルされると、新しい定義を示す新しいコードオブジェクトが持続するシンボルテーブルに格納され、機能（もしくはデータ）のＩＬシンボルが新しいコードオブジェクトにポイントに更新される。本発明のシステムは、従来技術の翻訳プログラムを超えるいくつかの生産性の利点を示す。主な利点は、プログラムプロセスが依然として「ライブ」である時、発明のシステムはプログラマーがプログラムの変更することを可能とする。これは、プログラムを停止すること及びそれのデバッグ、ソースコードのエディット、バッチコンパイル、フィックスの有効性を実証するために「バグ」を生じるエラー状態を再現することの必要性を回避する。さらにこれは、プログラムの再リンク及び再ロードに対する必要性を完全に回避する。ここに詳細に記載されるイメージ形成スキームの第２の主要な利点は、プログラムがクラッシュして、クラッシュの結果生じるこれらのラインを修正するまで、プログラム開発者はプログラムを実行し、続けることが可能であることである。一度プログラムのクラッシュの結果生じるソースコードラインが変更されて修正されると、次にクラッシュするまで開発者がさらに入力することなく、システムは動作を続ける。この方法により、一度開発者がソースコードエラーを修正すると、クラッシュは実質的に起こらなかったと言えるであろう。少なくとも２つの重要な概念が本発明のシステムの画定を助ける。第１に、インクリメンタルビルダーが、オブジェクトファイルと対比するようにコードオブジェクトを発生する。この事実は、ファイルの断片をコンパイル可能とする本発明のシステムの中心であり、コードオブジェクトは新しい宣言もしくは変更されたこれらのソースコードラインに対してのみ生み出される。本発明のインクリメンタルビルダーの動作に対する第２の概念の中心は、ソースファイル内に示される構造を引き出すことであり、さらに有効にインクリメンタルに再コンパイルすることができるプログラムユニットにソースファイルを分割することである。メモリの要件が現在のコンピュータシステムに対して十分に実用的であるほど小さく、非常に速い応答に対して十分に細かい、そのためにプログラムユニットへの分割は十分に粗い。デバッグすることに関しては、従来のデバッガは通常、開発者によって要求される、プログラムの実行に際して表現式を評価する、インタプリタを含む。ある特殊な場合の表現式（例えば機能呼び出し）は、機械指示の実行によって実際のアプリケーションプロセス内で実際上評価される。比較すると、本発明のデバッガは、実際のコンパイラを使用してインクリメンタルイメージに力学的に挿入され、直接実行される、小さなコードオブジェクトを作り出す。これはプログラマーが単純な表現式の単なるインタラクティブな評価を越えることを可能にし、表現式評価を備える彼のプログラム及び彼のプログラム内で統合されるステートメント実行を変更する可能性を彼に与える。これはプログラムの他の部分と同じ速度で実行される。例としては：条件付のブレークポイントの実行のために（「状況が真であればここで止まる」のような）、全ての他の公知のデバッガは、要求される場所でブレークポイントを設定し、そこでそれを得るまでプログラムを実行し、表現式（複雑過ぎることはでない）を説明する。状況が偽であるならば、プログラムのポイントが再度到達するまで、実行が再度続けられる。さらに状況は再度テスト等される。これらのテストはプログラマーから隠されているので、それにもかかわらず実行するのに長い実行時間が必要である。比較すると、本発明のデバッガはコンパイラを使用して、状況に対するコードオブジェクトを形成し、イメージをインクリメンタルに更新し、フルスピードでアプリケーションプロセス内の状況を直接評価するように、デバッガがブレークを仮定するプログラムのポイントにコードを挿入する。状況が真であるときにのみアプリケーションは実際に止まり、デバッガを必要とする。ユーザから隠れているものは何もなく、デバッガは「彼の後ろに隠れて」何ごとかを行うのではない。さらに状況は任意の複雑さとすることができる。従来のソフトウェア開発サイクルにおいてアプリケーションとデバッガの間の前後のスイッチの切り替えは、多くの時間を必要としてシステムの性能を相当に低下させる。また伝統的に状況の翻訳は状況の実行よりもかなり遅い。比較すると、本発明のデバッガは状況をアプリケーションの一部としてテストし、このいくつかの性能の不利益を被ることはない。これは条件付のブレークポイントに対してかなり良好なターンアラウンド時間をもたらし、この時間はさらにその低い性能のためにまた利用できる状況がしばしばそれを使用するには平凡であるという事実のためにプログラマーにより通常回避される。本発明のデバッガの特徴は、システム設計に固有であり、分離したモジュールではない。そのためにコンパイラとデバッガは、何らかの理由で一致しないことがある。その上にこのデバッグするスキーマは従来技術のデバッガのスキーマよりもかなり速い。本発明のデバッグするスキーマの他の特徴は、効果的なデバッグのためにプログラムの実行の終了を必要とせず、すなわち一度デバッグが完了すると再始動が必要とされない。本発明のシステムは、プログラム開発に際してあらゆるポイントにおいて開始及び停止のためのデバッグを可能とする。例えば、プログラムが不明確な機能を実行することを試みられると、システムは、開発者に機会を与える対話を発生させて、機能を画定する。開発者は機能に入り込み、システムは、それをコンパイルし、イメージを更新し、全プログラムではなく、機能コール指示のみを再始動させることにより実行を続ける。前述から、コンパイルし、リンクし、デバッグすることが本発明のシステムによって全て実行されるということが評価される。さらに、開発下においてシステムの「バグ」の発生に関して、コンパイルプロセスを中止して、ソースコードをエディットし、オブジェクトコードにソースコードを再コンパイルし、実行可能なイメージを形成するようにオブジェクトコードを再リンクし、実行可能イメージをロードし、バグを結果として生じさせたエラー状態を再現するということが、プログラムの実行がそのメモリ状態を修復できないだめなものとするまで、全て完全に回避されるということが評価される。その上に、フィックスの効率を実証するのに必要な時間が著しく減少する。なぜならばとりわけ、プログラム実行は決して中止されず、エラーの始まりにおけるプログラムの正確な状態が保持されるからである。本発明の他の特徴は、「本発明を実行する最良の形熊」と呼ばれる欄において開示されて明らかにされる。図面の簡単な説明本発明のより完全な理解のために、以下の発明を実行する最良の形態の詳細な説明に関連して添付の図面が参照される。図面は：図１は、本発明に従うソフトウェア開発サイクルの時間的な比較を図解する図であり、このようなサイクルの従来の視点とインクリメンタル技術のみを使用して獲得できる従来技術の改良とをともに比較する。図２Ａは、本発明のソフトウェア開発システムが動作するコンピュータシステムのブロック図である。図２Ｂは、本発明のソフトウェア開発システムの流れ図である。図３は、本発明の原理に従う総称プログラムオブジェクトのプロパティを図解する図である。図４は、総称プログラムユニットのプロパティを図解する図である。図５は、宣言プログラムユニットのプロパティを図解する図である。図６は、ソースファイルプログラムユニットのプロパティの図である。図７は、典型的な第１ソースファイルＡのタビュレーション表である。図８は、典型的な第２ソースファイルＢのタビュレーション表である。図９は、典型的なソースファイルＡの変更バージョンのタビュレーションである。図10は、プログラムユニット及びプログラムオブジェクト、ソースファイルＡに応答するＩＬシンボルのインクリメンタル形成を図解する図である。図11は、プログラムユニット及びプログラムオブジェクト、ＩＬシンボル、ソースファイルＡのインクリメンタル形成に続いて起こるソースファイルＢに応答するコードオブジェクトのインクリメンタル形成を図解する図である。図12は、影響を受けたプログラムユニット及びプログラムオブジェクト、ＩＬシンボル、ソースファイルＡの変更に応答するコードオブジェクトのインクリメント再形成を図解する図である。図13、プログラムイメージを形成することにおけるコードオブジェクト及びＩＬシンボルの使用を図解する図である。図14は、コードオブジェクト及び再ロケーションアレイ、ＩＬシンボルに応答するランタイムコードオブジェクトの決まった手順の形を線図で示すものである。図15は、プローブ及びランナを使用する共用記憶域割当てを線図で示すものである。図16は、プログラムのランタイムイメージの作成を線図で示すものである。図17は、変更がランタイムコードオブジェクトの従属によって適切にアドレス可能であるコードオブジェクトを作ることを確実にするための機構を線図で示すものである。参照番号は、図面の複数の図を通して、発明の同様もしくは等しい部分に当てはめられる。本発明を実行する最良の形態定義本発明のシステムのより完全な理解を提供することを目的として、他の仕事から何らかの概念及び構造の違いを区別するために、以下の定義が提供される：ファイルここで使用される限りでは、最も幅の広い意味において、ファイルは、プログラムテキスト例えばソーステキストの流れを具体化する。これは、当業界の通常の技術者に直ちに識別され、この定義は従来のファイル指向構造を含むが、さらに例えば画一的なデータの流れも含む。プログラム本発明のシステムの詳細な説明で使用される限りでは、プログラムは、その中に宣言が含まれるファイルの集合を含み、プログラムファイル間の関係を開発者によって提供される記述を含む。宣言Ｃ+ +もしくは何らかの宣言するプログラム言語における宣言は、全ファイルよりもプログラム記述ユニットは一層小さい。典型的にはプログラム記述は、各々他を参照し、ここで従属グラフと呼ばれる従属ネットワークを形成する。この語は、コンパイラ最適化理論において通常使用される用語「従属グラフ」とは完全に違う意味を有するということに注目されなければならない。宣言は、２つの根本的に異なる形式を持ち：これらの宣言は単にコンパイルタイムの表現を有し、またランタイムの表現を有する。所定の宣言の形式は、言語の従属するが、Ｃ++プログラム言語において、前者の例はタイプデフ及び列挙型規則子、機能宣言である。同様の言語において、後者は可変定義及び機能定義、ある程度はクラス定義形式によって例示される。プログラムユニット一度にコンパイルされる最も小さな実体である。しかしながらプログラムユニットは単純な宣言以上である。各プログラムユニットは１以上の宣言を含む。プログラムユニットは、ソースファイルの一部を示すが、独立プログラム実体ではない。プログラムユニットは、前述のWO95/00901及びWO95/00904参照の「コンポーネント」に類似するが、等しくはない。等しくないこれらの「コンポーネント」、プログラムユニットは独立アーティクルではなく、この独立アーティクルは、何らかの理由により他のプログラムユニットからは違った名称をつけられもしくは称される。したがってプログラムユニットは、コンポーネントがなすよりもはるかに少数のプロパティを有し、それゆえにより高い形成効率及び利用効率である。さらにプログラムユニットは、コンポーネントが主体ではないのに反して、ファイル内の厳密に決まった手順の順序のための主体である。 WO95/00901参照のコンポーネント間のもう１つの相違は、プログラムユニットがＩＤによって参照されないということである。その代わりにプログラムユニットは、ダイレクトメモリ参照によって参照される。この相違は、電話帳の電話番号を検索するのに似ており、WO95/00901参照が所定の状況において呼び出すためにある人物の名前のノートを作り、したがって電話番号はある人物を呼び出すのにそれが必要とされるときにはいつも検索されなければならないのに対して、本発明はある人物の電話番号を書きとめ、正しい番号が呼び出されることがわかるので、誰が呼びされるか注意しない。シンボルテーブルシンボルテーブルは、コンパイラがファイル間の関連用語のプログラム構造から集める、もしくはそのプログラムユニットをコンパイルする際にプログラムテキストそれ自体から推定するプログラムに関する情報の中心をなし基礎となるリポジトリである。全ての公知のコンパイルシステムがシンボルテーブルを持っている一方で、本発明のシステムはシンボルテーブルを利用して如何なる公知の従来のコンパイラよりもその中により多くの情報を格納する。用語「テーブル」は、例えばリレーショナルデータベース理論における、それの持つ従来の意味ではここで使用されないということが注目される。テーブルは普通は、同次記録のベクトルであり、各記録は他と同様の的確なフィールドを備える。しかしながらコンパイラシンボルテーブルは、単に異質のデータオブジェクトの大きな集合であり、記述された関係に対するものである。これらの関係は、ダイレクトメモリ参照によって画定される。持続的な有効性ランダムアクセスコンピュータメモリ（例えばＲＡＭ）のような主メモリは普通、一度第１プログラムが終了するとメモリは、例えば第２のプログラムに割り当てられ、メモリの内容が失われるというような方式で、実行プログラムに割り当てられて利用される。しかし第１のプログラムが再始動され、同一のメモリがもはやそのプログラムに利用されないのであれば、再割り当てされねばならない。しかしながらメモリは、おそらくもはや同一内容を有さないであろう。事実、多くのオペレーティングシステムは、そうならないことを確かめるように注意し、それによってコンピュータ上のいくつかのプログラムは、呼び出しの間のその内容を持ち続けるメモリを誤って信頼されないであろう。しかしながらハードディスクもしくはテープのような大容量記憶装置を含む多くの第２のメモリ装置は、このプロパティを有さない。第２のメモリ装置（例えば「大容量記憶装置」）は、しばしば持続するメモリと称され、ほとんどの多くの取るに足らないプログラムによって一貫して利用され、呼び出しから呼び出しへのデータを格納する。本発明のシステムはこのような取るに足らないプログラムではなく；多くのコンパイルシステムである。最近のコンパイルシステムは典型的には、リンク可能なオブジェクトファイル及び他の呼びファイルの形での大容量記憶装置内のコンパイルの最終結果のみを格納する。本発明のシステムは、ＩＬシンボルの形及びコードオブジェクトの形でコンパイルプロセスの最終結果のみを格納するのではなく、その上に多くの中間のデータ構造を格納する。中間の言語本発明のシステムは、同時に１つのプログラムユニットをコンパイルすることによってプログラムの定義を内部で処理し、この結果ここで「中間の言語（ＩＬ）」と称される異質のデータ構造を作り出す。この言語は、最適化及び機会コードの発生のような内部操作に対してソーステキストよりも一層適する。本発明によれば、ＩＬデータ構造の２つの主要なグループ：シンボル及び演算子がある。後者は記述機能定義及び変数の初期値として使用される。前者は機能及び変数双方の記述宣言として使用される。コードオブジェクトコードオブジェクトは、機能及びデータ定義をターゲットプロセッサのＣＰＵアーキテクチャによって要求される形の決まった手順のバイトとして示す。コードオブジェクトは再配置の集合を含み、各再配置の集合は、実行可能プログラムの一部であるコードオブジェクトをロードする目的で、コードオブジェクト内のポインタ値が明確なＩＬシンボルの定義であるコードオブジェクトに向けられなければならないということを指定する。本発明のシステムにおいて、コードオブジェクト及び中間の言語シンボルは、持続するシンボルテーブルとして持続するメモリ内に格納される。全体のプログラムに対して１つの持続するシンボルテーブルが存在する。コードオブジェクトは、ＩＬシンボルを名称もしくはＩｄによるのとはとは対照的にダイレクトメモリ参照によって参照する。再度これは、従来のシステム及び前述のインクリメンタル技術の双方を超えて、相当な性能上の利点を有する。本発明のシステムは、コードオブジェクトが形成されるようなダイレクトメモリ参照を利用するので、リンクプロセスの必要がない。その結果本発明のシステムは、コンパイルの副産物としてリンクを実行し、それによってリンカを完全に排除する。実行可能ファイル実行可能ファイルは、決定されたコードオブジェクト間の全ての参照を備える変換されたプログラムの完全な表現であり、基本的なＣＰＵアーキテクチャ及びオペレーティングシステムによって予想される形である。換言すれば、実行可能ファイルは、そのデータであるよりはむしろプログラムそれ自体の持続する表現である。典型的には従来のリンカもしくはインクリメンタルリンカが作り出すということである。本発明のシステムにおいて、一度プログラムのエディットが完了すると、開発者は実行可能ファイルを作り出すエクストラクタの実行を結果として生じさせる。したがってエクストラクタは、従来技術が教える分離したリンカと同様の機能のいくつかを実行する。エクストラクタ従来のリンカは、内部データ構造の中にオブジェクトファイルを収集する。その後リンカは、データ構造をトラバースして実行ファイルを発生する。比較すると、本発明のエクストラクタは、エクストラクタへの入力がオブジェクトファイルに対してコードオブジェクト及びＩＬシンボルである点を除いては、従来のリンカの第２のフェーズと本質的に同じように本質的に同じ機能及び動作を実行する。プログラムローダプログラムローダは、主メモリに実行可能ファイルを取り入れる多くのオペレーションシステムの特別な機能性であり、開発下でプログラムを開始する。この機能性は典型的には、オペレーションシステムによって提供され、他のコンパイルシステムと同様に本発明のシステムによってレバレージされる。本発明のシステムは、開発下においてプロプラエタリ実行可能フォーマット内でプログラムを具象化し、後に明らかにされるであろう理由でファイル内で具象化するのではない。このプロプラエタリフォーマット内でプログラムをロードするために、さらに本発明のシステムはランナと称されるプログラム要素を含み、これはロードする機能を実行するようにここで教示されるイメージャと共同して動作する。ここで、プロプラエタリ実行可能フォーマット及び対応するローダは、プログラムが開発されているときにのみ使用される。完成したプログラムを配置するように望まれると、ターゲットアーキテクテャ（例えば「.ＥＸＥ」ファイル）に適した予め画定した実行可能フォーマット及び対応するオペレートシステムに供給されるプログラムローダが使用される。プロセス本発明のシステムが適用する全てのオペレーションシステムを含む、最も最近のオペテーションシステムでは、各プログラムは、通例それの持つ「プロセス」と称されるものの中で実行する。プロセスは、３つの主なプロパティを有する：プログラムイメージ、これはプログラムの実行のパスを画定する：エントリポイント、これは実行が開始されるプログラムイメージの位置である：アドレス空間、これはプロセスに対して固有であるメモリ位置の範囲であり、他のプロセスに使用されない。同じ時にもしくは決まった手順内のどちらかで実行される異なるプロセスが共有のあるデータを必要とするならば、これは通常、先に議論したようにファイルを使用して行われる。持続する格納ファイルは、１つのプログラムに対して固有である必要はない。２つの同時に起こるプロセスは、同時に同じ持続する格納ファイルにアクセスすることができ、そこに格納されるデータを操作して情報を共有する。共有メモリ例示であって限定するものではないが、ユニックスやウインドウズＮＴ/ウインドウズ９５を含む、近頃のオペレーションシステムは、共有される主メモリによる共有されるデータのもう１つの手段を有する。この概念は、通例「共有メモリ」と称される。本発明のシステムは、ファイル内よりはむしろ共有メモリ内に実行可能イメージを配置する。ここに教示されるプロプラエタリプログラムローダは、コンパイラシステムを備える共有メモリとしてそれ自体設定されるのみではなく、イメージファイル内の代わりに共有メモリ内の指定された位置にプロセスエントリポイントを位置させることが可能である。ランタイムコードオブジェクト依然に議論したように、コードオブジェクトは持続して格納され、プログラムファイルを形成するように使用される。コードオブジェクト間の参照はコンピュータハードウェアで実行するのに都合の良い形ではない。したがってこれらの参照は再度変換されなければならない。実行されるプログラムイメージを形成するためのコードオブジェクトの変更の必要がないようにすることを目的として、及びさらにそれらの元の内容をコードオブジェクトに再格納する必要がないようにすることを目的として、この発明はそれらの複製をプログラムイメージが形成される、非持続メモリ内に作る。これらの非持続コードオブジェクトは、ランタイムコードオブジェクトと呼ばれる。機能定義に対する各ランタイムコードオブジェクトは、１つの命令それ以上の対応するコードオブジェクトを有し、命令はプログラムそれ自体に欠くことのできないものでなく、インクリメンタル形成プロセスに大変に欠くことのできないものである。このようなランタイムコードオブジェクトの開始において、分岐命令が、機能自体の最初の命令である、始めに次の命令に分岐するということをそこに書かれる。したがって命令はプログラム論理に全く影響を及ぼさない。ランタイムオブジェクトがコンパイルによって対応する機能に対する新しい定義に更新されると、新しいコードオブジェクトは、それが適合しないのであれば、最初と同じランタイムコードオブジェクトに複写されるか、もしくは最初のランタイムコードオブジェクトの活動が存在するのであれば、他のランタイムコードオブジェクトに複写されるかである。後者の場合には、最初のランタイムコードオブジェクトの分岐命令は、新しいランタイムコードオブジェクトの最初の命令（やはり分岐命令）に分岐するように変更される。そこで分岐がされて以降、古いランタイムコードオブジェクトに対する全てのセーブされた参照が依然有効であり、プログラムは直ちに新しいランタイムコードオブジェクトに分岐するであろう。インクリメンタルイメージャ共有メモリ内でプログラムイメージを形成するために、本発明のシステムは、ここでインクリメンタルイメージャと称されるあるものを使用する。これはコードオブジェクトを取り、それらを共有メモリ内に配置されるランタイムコードオブジェクトに複写し、それらにリンクして実行の準備がされるプログラムイメージを形成する。イメージの完了に対して受動的に待ちそしてそれをロードするプログラムローダを有するよりはむしろ、本発明のプログラムローダはイメージ形成プロセスにおいて能動的に機能する。デバッガ用語「デバッガ」は伝統的に、それ自体のプロセスにおいて、他のプログラムの実行を制御するのに使用されるプログラムに関連する。これはこの名称をえらーもしくは「バグ」のプログラムを取り除くに使用されたという事実から引き出される。従来のコンパイルシステムでは、コンパイラはソーステキストを、リンカによって実行可能イメージファイルに共にリンクされるオブジェクトファイルに変換する。コンパイラ及びリンカは、独立したプログラムであり、各々異なるプロセスで実行する。さらにプログラムは、プログラムローダもしくはデバッガの制御下のプログラムローダのどちらかによって直接実行される。一度バグが見つけられると、プログラムはデバッガによって停止され、さらにソーステキストは開発者によって変更もしくはエディットされることができ、プロセスがすっかり開始する。プログラムが停止されなければならない理由は、プロセスによって使用されている際に通常のプログラムローダがイメージファイルを変更することができないからである。本発明のシステムにおいて、インクリメンタルビルダーは、コンパイラの役割及びリンカの役割の多くを実行する。インクリメンタルビルダー、インクリメンタルイメージャ、デバッガは全て同じプロセス内で実行し、本発明のプログラムローダは、ファイル内ではなくイメージを、プログラムを停止させることなく変更することを可能とする。このように本発明のインクリメンタルビルダーは、コンパイル時間を減少させることによってプログラム破損をフィックスするのに必要とされる時間を相当に減少させ、リンクすること及びロードすること（イメージが共有メモリ内に形成されてから）、エラー状態の再現時間（プログラムが再始動されてはならないときから、適所にフィックスされるまでエラー状態で置かれる）を実行する時間を排除する。一度フィックスが達成されると、プログラムの実行はあたかもエラーが起きなかったかのように続けられる。本発明のシステムによって示される利点のタイムラインの比較が図１に示される。従来技術のシステムは、プログラムプロセスが依然として「ライブ」である際に、実行可能イメージが変更（更新）できないファイル内に保持されることが必要である。その結果、システムに何らかの変更を有効とする目的で、プログラムは停止され、プログラムの更新を有効とするために再始動することが必要である。一方で本発明のシステムは、ファイル内に実行可能なイメージを配置させず、共有マップメモリ内に配置する。このようにイメージは、同時の操作（イメージャによる）及び実行（ランナによる）を利用可能とする。図２Ａを参照すると、本発明のシステムはＣＰＵ50及び表示モニタ52、メモリシステム54、入力装置56上で動作する。好ましくはＣＰＵ50はインテルペンティアムであり、好ましくはディスプレイ52はスーパーＶＧＡモニタであり、好ましくはメモリ54はＤＲＡＭ及び磁気ディスク記憶装置を含み、入力装置56はキーボード及びマウスと関連インターフェースサブシステムを含む。さらに図２Ｂを参照すると、本発明のプログラムの概略が示される。開発者が始めてソースコードファイル３の所定の集合に対してデバッガ１を呼び出すと、インクリメンタルビルダー４は、ソースコードファイル３をコードオブジェクト及びそれらに対応するＩＬシンボルに変換するものを呼び出される。コードオブジェクト及びＩＬシンボルは持続するシンボルテーブル５に格納される。持続するシンボルテーブル５は、メモリ装置のあらゆる形式のもので実行される。インクリメンタルマネージャ６は、コードオブジェクト及びＩＬシンボルをランタイムコードオブジェクトに形成するのに使用される。さらにインクリメンタルイメージャ６は、実行可能なプログラムイメージを形成するランタイムコードオブジェクトにリンクする。イメージャ及びプログラムの動作は、プローブ７及びランナ８を介して調整される。プローブ７はインクリメンタルイメージャプロセス内で実行し、ランナ８は形成プログラムのプロセス内で実行する。このようにしてイメージ及びプログラムは、同時にメモリマップデータを利用する実行の２つの分離したスレッド内で実行される。本発明のインクリメンタルビルダーの主要な目的は、プログラムソースの特殊な表現（例えばデータベースオブジェクトとして実行されるプログラムソーステキスト）もしくは初期のコンパイルにおいて過度の経費を必要とせずに、編集努力及びプログラムのソーステキストに対する変更の後コンピュータプログラムの完全にコンパイルされた表現を構築するのに要する時間を最小とすることである。これらの欠点は、例えばWO95/00901及びWO95/00904によって教示される発明に明らかである。それらにひとまとめにして教示されるシステムは、プログラムソーステキストがデータベースオブジェクトとして実行されることが必要である。その上、これらの及び他の先に開発されたインクリメンタルコンパイラは再コンパイルにおいて利点を提供するが、一方で全プログラムの形成が非常に複雑な内部構造を使用しているため遅く、ソースファイルを操作するのに多くの必要なツールの使用を制限する。比較して、本発明のインクリメンタルビルダーは、再小量の再コンパイルとしてこれ以降称されるプロセスによりその主要な目的を達成する。本発明のインクリメンタルビルダーは、データベースオブジェクトとして実行されるソーステキストを使用しないために、先のインクリメンタルコンパイラよりもかなり高速の初期形成を可能とする。その上さらにプログラムの再形成において、データベースオブジェクトのＩｄとは対照的にポインタの使用が結果としてインクリメンタル再形成をより高速とする。典型的にはプログラムソーステキストが、インターフェース、実施、もしくは両方を指定する。インターフェースはプログラムの１つの部分の作用を指定し、それによって他のものに使用されることが可能となる。実施は指定された作用を提供する。多くのプログラム言語は、分離したコンパイルソースに使用されるインターフェースを作る方法を提供する。本発明の原理は、１つのコンパイルにおいて他に中に指定されるインターフェースを必然的に含むための機能を備える、すべてのコンピュータプログラム言語のコンパイルに適応できる。この機能は名前付きの変換取り込みと呼ばれ、多くのプログラム言語内に含まれている。例示を目的として、制限はしない、このような言語はＡｄａ及びＭｏｄｕｌａ−３、Ｊａｖａを含む。本発明の１つの特徴は、名前付き変換取り込みにＣ++プログラム言語を加えることである。標準のＣ+ +は辞書ファイル取り込みを使用する。これは、１より多いコンパイルに含まれるソースコードが各そのようなコンパイルの部分としてコンパイルされることを意味する。独創的なＣ++の実施は、いくつかのコンパイルにおいて辞書取り込みファイルの集合をコンパイルする結果を再使用することが可能であり、しかし何らかの１つの辞書取り込みファイルが変更されるならば全ての集合を完全に再コンパイルしなければならない。ここに教えられるように、最小量の再コンパイルは以下の原則を含んで幅広く言うことができる： (a)ここではプログラムユニットと称される、ソースファイルを比較的小さな断片に分割する。この小さなファイルの断片が、単純で速い再コンパイルを可能とする。 (b)ここではプログラムオブジェクトと称される、プログラムユニットが同等の小ささのコンポーネントの断片を有する、従属状態のトラックを保有する。プログラムユニットは、それらが参照するプログラムオブジェクトに従属していると言われる。 (c)プログラムの部分の再コンパイルの後、プログラムオブジェクトが論理的な変更をして、その結果従属プログラムユニットが再コンパイルを必要とすることをすばやく決定する。部分的な順序付けは、グループ内の如何なる順序も認める実体のグループを順序付ける。本発明の好適な実施例は、ソースファイルに対する部分的なコンパイル順序が具象化され、典型的にはいくつかのファイルが同時にコンパイル可能であり、そして多重処理コンピュータにおいて全ての使用可能なプロセスを有効に使用する。プログラムオブジェクトの選択されたプロパティが図３に示される。各プログラムオブジェクトＰは、以下のプロパティを有する：プログラムオブジェクトに従属するコンパイルのプログラムユニットを含む、従属集合。ここでサインと称される、プログラムオブジェクトの意味の記号化。本発明の好適な実施例では、サインはプログラムオブジェクトの論理的なプロパティを列表示の64ビットハッシングである。同様のサインに対する２つの異なる列ハッシングの可能性は、統計上取るに足らないように十分に起こりそうもない。１つのサイン作成技法の擬似コード表示は以下のようである：サイン作成：重要な論理的なプロパティの記号化を表示するテキスト列を構築する；テキスト列の細分化；エンド。例えば：フィギュアＸに対応するソースファイルＡに宣言されるデータメンバＸに関して作り出されるプログラムオブジェクトを考察する。フィギュアＸはここに宣言される： classＣ｛ intＸ｝：Ｘの論理的なプロパティは「Ｘ」と名付けられ、クラス「Ｃ」のデータメンバであり、割り込み符号付の形式であり、ゼロのオフセットを有し、専用の保護を有する。これらのプロパティの１つの可能な符号化は列であり：「Ｘ専用符号付割り込みＣデータ０」である。より多くのコンパクトな表示は可能でもあり望ましくもある。実例として、しかし制限せずに、本発明の好適な実施例として、このデータメンバのプロパティの符号化が「ＸｐＳＩＣＤ０」として表示可能である。実例として、しかし制限せずに、Ｃ++プログラム言語に対して、以下の各々がプログラムオブジェクトを構成する：すべての（辞書取り込み）ソースファイル；マクロ；タグ、機能、タイプデフ、テンプレートもしくはネーム空間適用範囲で宣言される変数；エヌメレータ；さらにタグ、機能、タイプデフもしくはクラスのデータメンバ。各プログラムオブジェクトは、プログラムユニットによって含まれる。前述のようにプログラムユニットは、本発明の好適な実施例によって一度に完了する最小の実体である。異なるプログラム言語は、プログラムユニットの形成を必要とする異なる構造を強いる。一般的な場合、以下のものがプログラムユニットを構成する：全てのファイル；さらに他の構文宣言内に含まれない構文宣言。実例として、しかし制限せずに、Ｃ++プログラム言語において以下の各々がプログラムユニットを構成する：全てのファイル；ファイル適用範囲宣言；もしくはネーム空間適用範囲宣言。本発明のインクリメンタルビルダーの必要条件の１つは、全プログラムオブジェクトを認識することである。各プログラムオブジェクトに関して、ビルダーは、プログラムオブジェクトと呼ばれるプログラムオブジェクトの内部表示を作りだし、収容されるプログラムユニットのプログラムユニットオブジェクトと呼ばれる収容されるプログラムユニットの内部表示にそれを関連付ける。総称プログラムユニットの選択されたプロパティが図４に示される。本発明の好適な実施例において、さらにプログラムユニットが、宣言プログラムユニットもしくはソースファイルプログラムユニットの何れかとして分類されるであろうことが注目される。各プログラムユニットは以下のプロパティを有する：要求コンパイルフラッグ、これは真もしくは偽を有することができる。依存集合、これはプログラムユニットのコンパイルで使用されるプログラムオブジェクトを含む。さらに図５を参照すると、宣言プログラムユニットの付加的なプロパティが、宣言プログラムユニット内に含まれるプログラムオブジェクトのリストを含む。図６を参照することにより、ソースファイルプログラムユニットの付加的なプロパティが次のものを含む：ソースファイルプログラムユニット内に含まれるマクロのリスト；さらにそれが含まれる宣言プログラムユニットのリスト。プログラムソーステキストは、何らかのテキストエディタによってエディットされ得る分離したコンパイル可能テキストファイル（ソースファイル）からなる。他のソースファイルによって使用可能なインタフェースを指定するソースファイルは、名前付き変換を画定する。他のソースファイルによって指定されるインタフェースを使用するソースファイルは、そのコンパイルに関連した名前付き変換（名前によって）を含む。各コンパイルされたソースファイルに関して、本発明の好適な実施例のインクリメンタルビルダーは変換を作り出す。この変換は適宜名前を付けられもしくは名前を付けられない。コンパイルに再帰的に含まれる変換は、変換のコンパイルに含まれる全ての変換を含む。変換ＡＡを画定するソースファイルＡは、ＢのコンパイルがＡＡを含むのであれば、ソースファイルＢ以前に、コンパイルされなければならない。この規則は、プログラムのソースファイルに対して部分的なコンパイルの順序を画定する。この規則によって順序付けされないコンパイルのソースファイルの如何なる集合も、何らかの順序もしくは同時にコンパイルされ得る。ソースファイル内で、構文要素はプログラム言語定義によって指定される順序付けで形成される。Ｃ++プラグラム言語に関しては、これはソーステキストの語彙順序に一致する。ソースコードファイルの初期形成に関しては、全てのソースファイルプログラムユニットが形成を要求する。インクリメンタルビルダーは、部分的な形成の順序に応じる順序で、形成されない名前付き変換が含まれない形成されないソースファイルが維持されないと、停止する、各ソースファイルプログラムユニットによって示されるソースファイルを形成する。エラーなしに形成される各ソースファイルに関して、プログラムビルダーは、対応するソースファイルプログラムユニットをビルダーを要求しないで作る。各このようなソースファイルプログラムユニット内の全ての宣言プログラムユニットは、ビルダーを要求しないように作られる。ソースファイルが変更されると、例えばデバッグプロセスの際に続きエディットされると、本発明の好適な実施例のインクリメンタルビルダーは、ソーステキストがエディットされる、もしくは論理的なプロパティが変更される１以上のプログラムユニットに依存する、それらプログラムユニットのみを再形成する。これは、テキストがコンパイルを要求されるように変更する（もしくテキストが変更されるソースファイルを辞書的に含む）各ソースファイルのソースファイルプログラムユニットを作ることによってなされる。これは、要求コンパイルフラッグを真に設定することによってなされる。さらにインクリメンタルビルダーは、コンパイル順序で全てのソースファイルプログラムユニットをトラバースする。各ソースファイルプログラムユニットに関して：１．ソースファイルプログラムユニットが形成を必要とするならば、全体として再形成される。２．さもなければ、コンパイラが語彙順序でソースファイルプログラムユニット内の全ての宣言プログラムユニットをトラバースする。コンパイルを必要とする各宣言プログラムユニットは再コンパイルされる。ソースファイルプログラムユニットを再形成する際に以下のステップが実行される：１．ソースファイルプロラムユニットＳＦ１内の各宣言プログラムユニットに関して、その依存集合の各要素の従属集合から宣言プログラムユニットを削除し、さらに依存集合を放棄する。２．新しいソースファイルプログラムユニットＳＦ２（及び新しい変換）を作り出すようにソースファイルのテキストをコンパイルする。３．ＳＦ２内の全てのプログラムユニット内のシグネチャによって指標を付けられたプログラムオブジェクトの全てを含むテーブルＴを構築する。４．ＳＦ１内のプログラムオブジェクトをトラバースする。（これは宣言プログラムユニットのリストをトラバースすることを要求する。）各プログラムオブジェクトＯに関して、Ｔ内のＯのシグネチャを探し出す。エントリＯ１が存在すれば、Ｏの従属集合の各要素をＯ１の従属集合に複写し、ＴからＯ１を削除する。エントリが存在しなければ、Ｏの従属集合の各要素に、真に要求コンパイルフラッグを設定することにより再形成する必要があると、印を付ける。５．ステッブ２が、奇形のソースコードを含み、宣言の何らかの部分が決定されないのであれば、形成が不必要であると宣言プログラムユニットに印をつける。宣言プログラムユニットの再形成は以下のように達成される：１．宣言プログラムユニットをそれの依存集合の各要素の従属集合から削除し、さらに依存集合をクリアする。２．宣言プログラムユニットのテキストをコンパイルしてプログラムオブジェクトのリストを作り出す。３．シグネチャによって指標を付けられた、新しいプログラムオブジェクトの全てを含むテーブルＴを構築する。４．古いプログラムオブジェクトのリストをトラバースする。各プログラムオブジェクトＯに関して、Ｔ内のＯのシグネチャを探し出す。エントリＯ１が存在すれば、Ｏの従属集合をＯ１に複写し、ＴからＯ１を削除する。エントリが存在しなければ、Ｏの従属集合の各要素に、真に再コンパイルが必要であると、印を付ける。５．プログラムオブジェクトの古いリストを新しいものと置き換える。６．ステップ２が、奇形のソースコードを含み、宣言の何らかの部分が決定されないのであれば、形成が不必要であると宣言プログラムユニットに印をつける。プログラムオブジェクト及びＩＬシンボル、コードオブジェクト、プログラムユニットの作成のためのプロセスは、以下のような擬似コード形態で示すことができる：パーズプログラムテキスト、ファイル適用範囲もしくはネーム空間適用範囲構文宣言の確認すること、各このような宣言のための抽象構文ツリー（ＡＳＴ）を発生すること；各ＡＳＴに対して行う：プログラムユニットＵの生成；以下のようにＡＳＴの意味解析の実行；Ｕ内の実体を示すプログラムオブジェクトを含む、再コンパイル従属物が意味あるように、シンボルテーブルノードの生成；実在プログラムオブジェクト上の従属物の認定；各依存プログラムＰＯに対する実行；ＰＯをＵの依存集合に付加； End do；Ｕ内で宣言される各機能（もしくは静的記憶装置データ）ＦＤに対する実行；ＦＤがＩＬシンボルを持たないのであれば、それに対して１つ生成。ＡＳＴがＦＤを画定するならば、定義を示してＩＬを発生；そしてさらにコードオブジェクト作り出すようにＩＬ上のコード生成の実行； End do； End perform： End do； End。さらに図７から12を参照すると、本発明のインクリメンタルビルダーの原理を代表例の例示が、先に議論されたように示される。これらのソーステキスト例は、Ｃ++プログラム言語で書かれている。図10及び11、12に明らかなシグネチャ値は任意であり、何らかのアルゴリズムを利用して引き出されない。図７を参照すると、最初のソースファイルＡ、1098はクラスＣを宣言してデータメンバＸを宣言して、整数型であり、メンバ機能フレッド及びバニイを宣言して、引数を取らずに整数を返す。図８を参照すると、第２のソースファイルＢが示される。ソースファイルＢは、機能フレッド及びバニイを画定する。機能フレッドは、フレッドが引き出されることに対して、ＣオブジェクトのＸメンバの値を返して画定される。機能バニイは、バニイが引き出されることに対して、Ｃオブジェクトに対して引き出されるフレッドの結果を返して画定される。図９は、エディットの際にソースファイルがそこで変更される、図７に先に示されたソースファイルＡに変更を加えることを示す。この例では、型がこれまでは整数であった、Ｘの宣言された型が、浮動小数点に変更される。フレッド及びバニイの原文の定義は変更されないままである。さらに図10を参照すると、ソースＡ、1098のコンパイルが示される。ソースファイルＡ、1098、の形成は、最初のプログラムユニット1100を発生する。プログラムユニット1100は、ソースファイルＡ、1098内に含まれる最小の各々にコンパイル可能な要素を示す。プログラムユニット1100の生成は、結果としてプログラムオブジェクト1110及び1120、1130の生成する。プログラムオブジェクト1110は、データメンバＸの宣言を示してシグネチャを含み、この例101では、初期状態が空である従属集合を含む。機能フレッドに関する宣言は、またシグネチャを有し、この例37では、初期状態が空である従属集合を含む、プログラムオブジェクト1120内で具象化される。プログラムオブジェクト1120が機能宣言を示されるので、これは結果としてＩＬシンボルを生成する。それゆえに、プログラムオブジェクト1120内のＩＬシンボルフィールドのポインタはＩＬシンボル1140に向けるように設定される。ＩＬシンボル1140は、古い定義に対するポインタ及び同時にヌルに設定される新しい定義に対するポインタを含む。類似した方法で、機能バニイに対する機能宣言は、この例のように、シグネチャ値483を有し、初期値が空である従属集合を有する、プログラムオブジェクト1 130を結果として生成する。要約すると、ソースファイルＡの形成は、３つのプログラムオブジェクトの生成を結果として生じる、１つのプログラムユニットの生成に終わる。機能を宣言するプログラムオブジェクトはＩＬシンボルの生成を結果として生じる。データメンバの宣言であるプログラムオブジェクトは、結果としてＩＬシンボルの形成を生じない。さらに図11を参照すると、ソースファイルＢ、1099の形成は、２つのプログラムユニット1160及び1170の生成を結果として生じる。プログラムユニット1160は、図８に先に示した、機能フレッドの構文定義を示す。またプログラムユニット 1170は、ソースファイルＢ内に示される機能バニイの構文定義を示す。例として、続けて図11を参照すると、プログラムユニット1160及び1170は、それぞれ１つのプログラムオブジェクト1180及び1190を生成し、プログラムユニットの1160及び1170のプログラムオブジェクトフィールドで画定されるポインタはプログラムオブジェクト1180及び1190に向けられる。プログラムオブジェクト11 80は、プログラムオブジェクト1120により先に宣言される機能フレッドの定義を示すプログラムオブジェクトであり、またそのような機能として、プログラムオブジェクト1120によって機能フレッドの宣言に応答して生成された、再度呼び出されるであろう、ＩＬシンボル1140に向ける。類似した方法で、プログラムオブジェクト1190は、プログラムオブジェクト1130によって先に宣言された機能バニイの定義を示し、再度プログラムオブジェクト1130及び1190は機能バニイに関してＩＬシンボル1150に対するポインタをそれぞれ含む。このような機構が、それによって本発明がコンパイルに際してリンクを達成するということが十分に注意される。この特徴は、多くのコンパイルシステムで見出される共通の機能の利点を獲得し、１つの機能もしくは静的データの断片を示すための独自の中間言語シンボルを生成する利点を獲得する。しかしながら本発明はコンパイルユニットを横切ってシンボルテーブルをトラックすることができるために、全てのコンパイルユニット内の所定の機能に関する１つのＩＬシンボルを有することが可能であり、したがって分離したリンカは必要ではない。プログラムユニット1160の形成において、インクリメンタルビルダーはプログラムオブジェクト1110及び1120の従属物を検知する。したがってプログラムユニット1160の依存集合は、プログラムオブジェクト1110及び1120（ポインタ線Ｄに沿って示されるように）に対するポインタを含み、各1110及び1120の従属集合は、プログラムユニット1160に対するポインタが含まれるのを増大させる。類似の方法で、プログラムユニット1170はプログラムオブジェクト1120及び1130に依存する。したがってプログラムユニット1170の依存集合は、プログラムオブジェクト 1120及び1130（ポインタ線Ｃに沿って示されるように）に対するポインタを含み、各1120及び1130の従属集合は、プログラムユニット1170に対するポインタが含まれるのを増大させる。システム実行におけるこの点に対する動作の要点は、データメンバＸが宣言されて、機能フレッド及びバニイが宣言されて画定される。したがって先にヌルである、ＩＬシンボル1140及び1150の定義フィールドが、さらにそれぞれコードオブジェクト1200及び1210に対して向けられることを設定する。コードオブジェクト1200及び1210は、それぞれフレッド及びバニイの定義として生成される。この点で、本発明のインクリメンタルビルダーは、ソースファイルＡ及びＢから、ＩＬシンボル及びコードオブジェクト形成して、このプログラムのプログラムイメージを形成する。ＩＬシンボル及びコードオブジェクトは持続するシンボルテーブルに格納される。さらに図12を参照すると、プログラムのソースファイルの１つをエディットする結果が示される。再度図９を参照すると、ソースファイルＡはここで修正されて、データメンバＸの型を整数から浮動小数点に変更される。従来のコンピュータ技術では、この変更は、ソースファイルＡ及びＢを含む、プログラム内の全てのコードの再コンパイルを必要とする。しかしながら本発明の利点の１つは、エディットされる、もしくは変更手段を有するプログラムオブジェクトに依存する、これらのプログラムユニットの再形成のみが必要であるということである。図12には、図９で形成されたエディットの結果が示される。データメンバＸを小数点浮動型とする変更は、図７に含まれるデータメンバ宣言が図９に示されるように更新されることを必要とする。これは、プログラムユニット1100の再形成及びプログラムオブジェクト1110、1120、1130の再形成の結果生じる。したがってこれらの要素は同時に再形成される。プログラムオブジェクト1120及び1130と同様にプログラムユニット1100それ自体は、データメンバＸの型の変更の結果として変更されないままである。したがって、しかし新しいプログラムユニット11 00及びプログラムオブジェクト1120が再形成プロセスの際に形成されるので、それらはそれらの以前の値と同一である。しかしながらプログラムオブジェクト11 10は変更されて、データメンバＸの新しい型を反映する。したがってプログラムオブジェクト1110は、さらに値409として示される新しいシグネチャを発生する。ＩＬシンボル1150は変更されないままである。プログラムオブジェクト1110が同一のシグネチャに再形成されないので、その従属集合内の各プログラムユニットは再形成されねばならない。それゆえにプログラムユニット1160は、プログラムオブジェクト1180を結果として再形成してコードオブジェクト1220を結果として生成する、再形成が行われる。ＩＬシンボル1140は次のように更新される：その古い定義フィールドがその定義フィールドの前の値（すなわちコードオブジェクト1200に向けられる）に設定され、この定義フィールドがコードオブジェクト1200に向けられて設定される。プログラムユニット1170及びプログラムオブジェクト1190は再形成されない。プログラムオブジェクト1180が再形成された後、ＩＬシンボル1140が次のように更新される：定義ポインタが、コードオブジェクト1200の再配置フィールドから新しいコードオブジェクト1220の、更新されたオブジェクトコードを含む、再配置フィールドに変更される。同時にＩＬシンボル1140の古い定義フィールドは、ヌルの値から先に画定されたコードオブジェクト1200の再配置値に再設定される。全プログラムオブジェクト及びプログラムユニット、ＩＬシンボル、コードオブジェクトは、データベース内で実行されるさらにメモリ装置内で実行される、先に議論された持続するシンボルテーブルに格納される。システム効率の結果、オブジェクト指向データベースは本発明の好適な実施例で利用される。図10〜12に関しては、プログラムオブジェクト（例えば1110）の従属フィールド及びプログラムユニット（例えば1160）の依存フィールドが、好適な実施例では、効率的なソートを準備するポインタの２本木として実行される。これらの図で明瞭とするために、ポインタの実際のリスト及びこれらの中で参照されるいくつかのポインタは、プログラムユニットを示す図の要素から向けられている。ポインタの２本木を含むフィールドの概念は、当業の通常の技術を持つ者にとっては十分に公知である。先に議論されたエディットプロセスの正味の結果は、ＩＬシンボル1140及び11 50がそれぞれコードオブジェクト1220及び1210に向けられ、これらのＩＬシンボル及びコードオブジェクト対がさらに、本発明のインクリメンタルイメージャによって使用されるように、持続するシンボルテーブル内で利用されてそれによって画定されるプログラムイメージを形成して実行するということである。従来のコンパイルシステムでは、リンカは引き出されて、オブジェクトファイルの形成及びオブジェクトコード内のオブジェクト間の全ての参照を決定においてオブジェクトコードを獲得して、異なるイメージがオブジェクトファイルを使用する新しいものを作り出す。この新しいイメージは、全てのプログラム（例えば実行可能ファイル）もしくはプログラムの自己収容部分を示すであろう。このような自己収容部分は、解決されない外部参照を有さず、しばしばダイナミックリンクライブラリもしくはＤＬＬとして参照される。本発明のシステムにおいては、インクリメンタルイメージャは、リンカによって実行される通常のこれらタスクのいくつかを実行する。インクリメンタルイメージャは、オブジェクトファイル上でこれらタスクを実行せず、予め画定されるコードオブジェクト上で実行する。オブジェクトコード要素は、それらが元の型であるように、同じ順序でもしくは起こり得るイメージ内の同じアドレスで配置される必要はない。これは、機能及びデータ定義（例えばコードオブジェクト）のアドレスが単にファイルの開始に関連したそれらの位置である、オブジェクトファイルの場合において、明らかに起こり得る。それゆえに定義がついに、それがオブジェクトファイル内に有するように、実行ファイル内の同じ位置を占めるという機会はない。ファイルのヘッダ情報のサイズが典型的に実行可能イメージとオブジェクトファイル間で大変に異なるゆえに、リンカが単に１つのオブジェクトファイルを必要として実効可能イメージを作り出す場合においてもあてはまる。本発明のシステムにおいては、コードオブジェクトは、イメージャによってランタイムコードオブジェクト内に複写され、元のコードオブジェクトが行ったように全く確かに同じアドレスを有することはない。コードオブジェクト及びランタイムコードオブジェクトは同じアドレス空間に同時に存在し、したがって異なるアドレス有さねばならない。また実行可能ファイルの開始に関してコードオブジェクトが有するアドレスと、プログラムローダによってメモリ内にロードされる際にコードオブジェクトが有するであろうアドレスとの間に、相当な差異がある。イメージャプロセス内のランタイムコードオブジェクトのアドレスと、ランナプロセス内のアドレスとの間にここに教示するシステムのさらなる差異が存在する。これは、物理的メモリのある断片が、それが占有される全てのプロセス内の同じ論理的なアドレスを有する必要のない、共有記憶域の本来的なプロパティである。いくつかの、しかし全てではない、オペレションシステムは、共有記憶域ブロックのアドレスの同一を保証する。しかしながら、これは典型的にはアプリケーションプログラマーに関して関係なく行われるものではなく、それがオペレーションシステムの単純な実行であるためである。さらにまとめると、イメージを形成する際に取り扱われるオブジェクトの２つの種類がある：Ａ．コードオブジェクト、これはこれらの非再配置形における変換プログラムアイテムを示す。Ｂ．ランタイムコードオブジェクト、これはこれらの再配置形における変換プログラムアイテムを示す。また先の議論から、オブジェクトアドレスの３つのカテゴリーが存在し、それらは次のように記載されねばならない：ａ．イメージャ／デバッガのアドレス空間内のコードオブジェクトのアドレス。ｂ．イメージャ／デバッガのアドレス空間内のランタイムコードオブジェクトのアドレス。ｃ．ランナのアドレス空間内のランタイムコードオブジェクトのアドレス。換言すれば、各コードオブジェクトＴはアドレスＴａに位置し、それに対応するランタイムコードオブジェクトＲは、イメージャによってアドレスＲ_b及びランナによってアドレスＲ_cで見出されるメモリ内に位置する。アドレスは、通例ポインタ（この用語はＣ及びＰａｓｃａｌ、Ｃ+ +のようなプログラム言語において使用される）の手段によるソフトウェアによって使用される、もしくは参照（Ｐａｓｃａｌ及びＣ+ +のようなプログラム言語において使用される）される。どちらの形もオブジェクトの十分な絶対アドレスを容易に持ち続ける。またハードウェア（例えばコンピュータのＣＰＵ）がアドレスを使用すると、これは典型的にはソフトウェアがなすよりも一層複雑になる。所定のハードウェアのアーキテクチャを実行するトランジスタの論理を単純にする目的で、ハードウェアによって利用されるアドレスは、無数の異なるスキームによって形成され、そのスキームの各々はハードウェアそれ自体に依存する。例示することを目的として、しかし制限せずに、これらのハードウェアアドレスは、異なる構造に位置するもしくはアドレスを利用する命令のアドレスに関連して作られる、２つの部分に分離できる。したがって、アドレスの３つの消費物があると考えられる：Ｉ．オブジェクト（コードオブジェクト及びランタイムコードオブジェクト）内でデータを読み書きする際にカテゴリーａ及びｂからのアドレスを使用することが必要なイメージャ／デバッガ。 II．オブジェクト（まさにランタイムコードオブジェクト及びそれらの支持構造）内でデータを読み書きする際にカテゴリーｃからのアドレスを使用することが必要なランナ。 III．データにアクセスする際にカテゴリーｃからのアドレスを使用するのに必要であって、しかししばしばランナソフトウェアであるのと同じ形（ポインタ）でそれらを使用することが可能ではない、ＣＰＵすなわちハードウェア。この点をさらに複雑にすると、ＣＰＵは、ランタイムコードオブジェクトそれ自体のアドレスにおいて関与しておらず、あるオフセットでその中に含まれている変換オブジェクトコードのアドレスにおいて関与している。この発明におけるコードオブジェクト横断及び再配置のプロセスの目的は、ランタイムコードオブジェクトの必要ような集合を確立することであり、それらのアドレスＲ_b及びＲ_cを確立することであり、消費物II及びIII（ランナ及びＣＰＵ）にそれらを使用することであり、ＣＰＵがＲ_c＋ｋに事実上関与するということが注目され、ここでｋは、ランタイムコードオブジェクト内で変換コードオブジェクトをオフセットする定数（すなわち全てのランタイムコードオブジェクトに対して同じ）である。本発明では、多くのリンカ技術においてそうであるように、再生成レコードは、プログラム内の所定の点で獲得されなければいけないアドレスを形成することを記述する、データの断片である。形は参照アドレスを変更せずに、参照の発生する場所を変更する。例えば、機能のアドレスを含むデータアイテムは通常、アドレスがソフトウェアによって使用されるのに適当（確実ではない）であるために、機能に対する確実なポインタを保持する必要がある。ＣＰＵは、ブランチテーブルと呼ばれるものを使用すると、もしくはプログラムによってダイナミックに（ランタイムで）確立されるアドレスを呼び出すと、確実なアドレスが使用される。参照されるアドレスが最初に参照されなければならないデータのある断片に含まれるために、これは間接アドレスと称される。またハードウェアはデータを参照すると直接アドレスをするのが適当であって、他の機能から機能への直接参照を作る際により複雑な形を通常使用することは適当でない。例はサブルーチンを実行する際のものである。手順によると、本発明における再配置のプロセスは、参照の各点において形が必要である、ランタイムコードオブジェクトの変換される完全なアドレスの１つである。コードオブジェクトが、本発明のシステムにおいて、プログラムイメージとして実際に実行されるものではないので、再配置はランタイムコードオブジェクト上にのみ再形成される。しかしながら再配置レコードは、コードオブジェクトに結び付けられ、ランタイムコードオブジェクトには結び付けられない。再配置レコードがイメージを形成（始めにもしくはインクリメンタルに）すると完全なランタイムコードオブジェクトを形成するのに使用されるために、これは形式的である。再配置を実行するには、イメージャが対応するランタイムコードオブジェクトが生成されるように全コードオブジェクトにわたって、反復適用する。各コードオブジェクトに関して、これは以下のように各再配置レコードを処理する：１．再配置Ｌの型（ＣＰＵによって使用される際に獲得されるアドレスを形成する）に注目する。２．参照が発生するＴ内のオフセットＯ_Lに注目する。３．Ｔに対応するコードオブジェクトのアドレスＲ_b及びＲ_cに注目する。４．Ｏ_Lにおいて参照されるコードオブジェクトのＳ_cのアドレスに注目する。５．アドレスＲ_b空間において、Ｓ_c＋ｋに対するポインタを配置する、ここでｋはランタイムコードオブジェクト内の変換コードオブジェクトのオフセット定数である。このポインタが最新の配地に関係するのであれば、最新の配置としてＲ_c＋Ｏ_L＋ｋを使用する。イメージャ／デバッガは、ハードウェアに対して情報を作り出すのみ出なく、またこれは、ランナに対しても情報を作り出す。そのプロセスにおいて、全てのイメージャ／デバッガが、ランナと連絡する時にはいつも、カテゴリーｃからのアドレスを使用することを確実とする必要があるために、再配置の形及び他の複雑性に関して心配する必要がない。空間が関わる、情報の重複を回避する必要のある、ある事情において、ランナは事実カテゴリーｂからのアドレスを受け入れ、さらにカテゴリーｃにそれらをそれ自体変換するであろう。図13〜17は、本発明の原理に従うインクリメンタルイメージ形成の好適な実施例を図解する。さらに図13を参照すると、プログラムイメージを形成する際のコードオブジェクト及びＩＬシンボルの使用が示されている。持続するシンボルテーブル内に予め格納されたＩＬシンボルが2000に示される。各ＩＬシンボル2000 は、定義フィールド2001を含み、これは直接メモリアドレスの手段によって対応するコードオブジェクト2010に向けて指示するコードオブジェクトポインタ2004 を含む。定義フィールド2001は、ＩＬ命令ストリーム1999によって画定される。さらにＩＬシンボル2000は、従属フィールド2002及び古い定義フィールド2003を含む。随意に、さらにＩＬシンボル2000はＩＬ名前2005を画定する。名前2005が、プログラマーに対して例えばデバッグモードにおいて情報を表示することのみに使用され、イメージ生成に際して画定される、ということが特に注目される。各ＩＬシンボル2000は、本発明のインクリメンタルビルダーによってＩＬストリーム1999の部分から形成される。コードオブジェクトポインタ2004は、ＩＬシンボル2000に対応するコードオブジェクト2010に向けて指示する。各コードオブジェクト2010は、サイズフィールド2011及び再配置フィールド2012、コード区域2013を含む。コード区域2013は、機能の定義及び変数の初期値の先に議論された完全に変換された機械語の実施を含む。再配置フィールド2012は、再配置領域2020に向けて指示する、再配置ポインタ2014を画定する。再配置領域2020は、再配置オフセットのベクトル及びＩＬシンボル参照を含む。再配置ポインタ2014が指示するＩＬシンボルは、帰納的なプロセスの場合には、コードオブジェクト2010の機能を引き出した同じＩＬシンボルであり、もしくは全く異なるＩＬシンボルに向けて指示するであろう。更新テーブルは、イメージャに関するビルダーによって状態を維持され、それによって変更されているコードオブジェクトをイメージャが配置可能なエディットもしくはソースファイルに対する他の変更が以下に続く。さらに図14を参照すると、ランタイムコードオブジェクトの形成が議論される。各ＩＬシンボル1000は、結果としてランタイムコードオブジェクト1010の形成を生じる。本発明のインクリメンタルイメージャ200が解析コードオブジェクト1 010を含むので、付加ＩＬシンボル1000がイメージに加えられる。これらのコードオブジェクトの各々が、先に議論したように、再配置テーブル1020に対するポインタを含み、これは順番にＩＬシンボル1000を指示し、細かい細分性の典型としては、これは順番にそのコードオブジェクト1010その他を指示する。さらなるＩＬシンボル1000が付加されない点では、プログラムを画定する全てのコードオブジェクト1020が形成される。イメージ内の全てのコードオブジェクトが形成されると、推移閉包の状態が存在することが命じられる。ランタイムコードオブジェクトは、それらの構造の中に含まれる付加作業用記憶領域を有し、再配置に際して機械依存形に変更される参照を備える、コードオブジェクトの複写である。コードオブジェクトの複写が作られる以前に、プローブ及びランナを始動することが必要である。ランタイムローダは、ランタイムコードオブジェクトにコードオブジェクトを複写する前に、始動する。共有メモリの使用が２つのプロセスが、すなわちプローブ及びランナが、２つのプロセス間にメモリ上で割り当てられることに適台しなければならないからである。各ランタイムコードオブジェクトは、各プロセスに対して１つの、２つのアドレスに対する参照を含む。さらに図15を参照すると、持続するアドレス例えば100、を有する各コードオブジェクト1020に対して、インクリメンタルイメージャ200がプローブ300に指令しメモリを割り当てる。さらにプローブ300はランナ400に指令してメモリを割り当てる。プローブ300及びランナ400が、２つの別個のプロセスにおける実行の２つの分離したスレッド下で操作され、プロセス境界399によって論理的に分離されるということが重要であり、思い出される。コマンドに応答してメモリを割り当てる、ランナ400は、機械アドレス例えば550を割り当てて、このアドレス横断プロセス境界399をプローブ300に返す。プローブ300は、それをランタイムコードオブジェクトに関連付けるインクリメンタルイメージャ200にアドレスを渡す。本発明の好適な実施例において、プローブは以下の擬似コード表現にしたがって実行される： while（真）do イメージャ、ランナからのコマンドを受け入れるイメージャ＝＞コミュニケーションパイプ内にデータを流すランナにデータを送るランナ＝＞ストリームデータランナを集めるイメージャにデータを送る end while 本発明の好適な実施例において、ランナは以下の擬似コード表現にしたがって実行される： Startup Thread：コミュニケーションスレッドを始動するアプリケーションスレッドを始動するプログラム終了を待つ Application Thread：アプリケーション始動を待つプログラムエントリポイントを探すプログラムエントリポイントから実行するスタートアップスレッドにプログラム終了を送るアプリケーションスレッドを終了する Communication Thread： terminate-false while(not terminate)loop プローブからのコマンドを受け入れる＝＞ＳＵＩＣＩＤＥ＝＞ terminate=true ＤＥＦＩＮＥＥＮＴＲＹ＝＞プログラムエントリポイントを設定するＡＬＬＯＣＡＴＥ＝＞共有メモリのブロックを割り当てるＤＥＡＬＬＯＣＡＴＥ＝＞共有メモリブロックの割り当てを解除するＲＥＭＡＰ＝＞再度メモリ内にすでに割り当てられたブロックをマップするＡＣＴＩＶＡＴＥ＝＞フィックスアップを実行して、プログラム内の静的データを初期化するアプリケーションスレッドに始動アプリケーションを送るＲＥＡＤＭＥＭＯＲＹ＝＞デバッガにランナメモリからのデータを送るＷＲＩＴＥＭＥＭＯＲＹ＝＞ランナメモリ内にデバッガからのデータを書き込む end accept プローブに応答データを送る end while コミュニケーションスレッドの終了プログラムのランタイムイメージを生成するために、各コードオブジェクトに関して、図16に示されるように、このプロセスが繰り返される。その図を参照すると、プログラムイメージを生成するために、開発者がデバッガ600に指令して、ステップ１において指導される。デバッガ600はイメージャ200をステップ２において順序付けて、先に議論したように形成する。各コードオブジェクト（図示せず）に関して、イメージャ200はプローブ300に指令して、ステップ４においてメモリを割り当てる。プローブ300は、ランナ400を順序付け、ステップ５においてメモリを割り当てる。ランナ400は、機械メモリを割り当てて、プローブ300にアドレスを返す。プローブ300は、イメージャ200にアドレスを返す。これは、結果として、次のコードオブジェクトを要求して生じさせる。ステップ２〜５は、ファイル内の各コードオブジェクトに関して繰り返される。ランナが、最終のコードオブジェクトに対して機械メモリの割り当てを終了すると、それが６においてメモリの割り当てが終了しているということをプローブ300に知らせる。応答して、プローブ300は、全てのメモリが割り当てられたことをステップ７においてイメージャ200に知らせる。イメージャはステップ８において形成が完了したことをデバッガに知らせる。この点で、イメージがメモリ内に完全に形成され、プログラムが実行され得る。続いて図16を参照すると、イメージが形成される、ステップ８におけるデバッガ600による受け取りに応答して、デバッガ600はステップ９においてプローブ30 0に直接指令して、アプリケーションを始動する。この指令は、ステップ10において順にランナ400に伝達される。これはイメージが実行されるときに、メモリマップデータを利用する実行の２つの分離したスレッドにおいて、プログラムを同時に具象化するイメージを結果として生じる。このプロセスの際に、アプリケーションが機能しなくなると、コンピュータのオペレーションシステムが、機能の停止の機械アドレス及び機能の停止の本質に関連する他の情報に加えて、随意にオペレーションシステムに依存するデバッガに機能の停止を報告する。デバッガは、機械アドレスをコードアドレスに変換して、他の機能の停止情報に加えて、開発者に機能の停止及びそのコードアドレス、機能停止のデータを知らせる。開発者は、この情報を使用して、ソースコードファイルのエディットを行う。一度ソースファイルがエディットされると、開発者はデバッガに指令して、プログラムの実行を再開する。デバッガは、ステップ11において、イメージャ200に指令して、図17に示されるようにエディットによって影響を及ぼされたコードオブジェクトを更新する。その図を参照すると、ＩＬシンボル901は、順にランタイムコードオブジェクト9 03の生成を引き出すコードオブジェクト902の生成を結果として生じる。説明の目的で、この例では、ランタイムコードオブジェクト903は第２のランタイムコードオブジェクト904によって参照される。開発者が、プログラムの機能の停止例えば不適当に画定された機能901を結果として生じるソースコードの部分をエディットした後、機能を表すＩＬシンボル901からのポインタは、古いコードオブジェクト902から修正機能を具象化する新しいコードオブジェクト905へと再設定される。この機能をもたらすために、古いランタイムコードオブジェクト903 のポインタ910は、それの収容されるコードのライン０から新しいランタイムコードオブジェクト906の収容されるコードのライン０へ再設定される。本発明は、当業の通常の技術者にとって公知である、如何なるデータの格納及び変換手段においても実行され得る。例示を目的として、しかし制限せずに、このような手段は、制限される必要はないが、磁気ディスク及びテープ、ハードドライブ等を含む磁気手段；ＲＡＭ及びフラッシュメモリ等を含む電子式メモリ手段；パンチテープ及びホリレスカードを含む機械的なデータ格納材料；さらにＣＤ−ＲＯＭ及び「floptical」装置等の光学手段を含む。その上、本発明の原理は、インターネットに制限されず、電話回線もしくは狭い範囲及び広い範囲でのネットを含む他の電子式ネットワークを含む何らかの手段にわたってそれの転送を特に意図する。さらに本発明の原理は、格納もしくは使用、搬送、売り出し、リース、貸し出し、何らかの及び全てのそれの他の処理に関してこのような実行を特に意図する。本発明は、その特徴のある好適な実施例を考慮して詳細に示され、記述された。しかしながら、添付される特許請求の範囲に述べられるような本発明の精神及び範囲を逸脱することなく、原型及び細部において様々な変化及び変更をなすことが、当業の通常の熟練した者にとっては明白なことである。ここに開示される発明は、特にここに開示されていない何らかの要素なしに実践され得る。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＺ，ＵＧ)，ＵＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＵＡ，ＵＧ，ＵＺ，ＶＮ (72)発明者ハンビー，ジョンアメリカ合衆国ワシントン州98077，イサクォー，サウス・イースト・42・プレイス・18151 (72)発明者ロウ，パトリックアメリカ合衆国ワシントン州98058，レントン，サウス・イースト・170・コート・ 16045

Claims

【特許請求の範囲】１．バッチ再コンパイル、再リンク、再ロードの必要もしくは開発者がエラー状態を再現する必要がない、プログラムのリアルタイムデバッグをコンパイルとして可能とする、インタラクティブコンピュータプログラム開発システムであって、このシステムは：コンピュータシステムが、ソースコードファイルの所定の集合を有し、第１及び第２の内部プロセスを有し；デバッガが、ソースコードファイルの前記所定の集合をデバッグするために前記コンピュータシステム内に内在し；インクリメンタルビルダーが、引き出されると、前記ソースコードファイル及びそれらの対応する中間言語（ＩＬ）シンボルをコードオブジェクト内に変換する前記コンピュータシステム内に内在し、前記インクリメンタルビルダーは前記コードオブジェクト及びプログラムユニットを実行可能である形成プログラム内に形成するように、前記第１の内部プロセスに結び付けられ；持続するシンボルテーブルが、前記コードオブジェクト及びＩＬシンボルを格納するように前記コンピュータシステム内に内在し；インクリメンタルイメージャが、前記コードオブジェクト及びＩＬシンボルを利用してランタイムコードオブジェクト形成する前記コンピュータシステム内に内在し、前記インクリメンタルイメージャは、実行可能なプログラムイメージを形成して前記ランタイムコードオブジェクトと結合するように、前記第１の内部プロセスと結び付けられ、前記インクリメンタルイメージャは、前記ランタイムコードオブジェクトの各エー々の開始に当たり分岐命令を導入し；ランナが、前記形成プログラムを前記第２の内部プロセス内で実行する前記コンピュータシステム内に内在し、前記ランナは、前記第２の内部プロセス内で、前記プログラムイメージを仕上げて、前記プログラムイメージを実行し；プローブモジュールが、前記インクリメンタルイメージャ及び前記ランナの動作を調整するように、前記コンピュータシステム内及び前記第１の内部プロセス内に内在し；それによって前記プログラムを画定して共有メモリデータを使用する前記プログラムイメージが、同時に実行されて前記プログラムを画定する前記ソースコード内の変更を反映するようにインクリメンタルに操作される、ことを特徴とするシステム。２．前記コードオブジェクト及び前記ＩＬシンボルが、オブジェクトコードファイルを置き換え、前記ランタイムコードオブジェクトが実効可能ファイルを置き換える、請求項１記載のシステム。３．前記ランナが、前記イメージャと共同してロードする機能を実行するように動作する、請求項２記載のシステム。４．オブジェクトファイルもしくは何らかの実行可能ファイルを作り出すことなく、結果として生じるプログラムの実行後に、記憶のためのメモリ内にコードを形成する方法。５．前記コードがコードオブジェクトであり、前記メモリが持続するメモリである、請求項４記載の方法。６．少なくともコードオブジェクト及び中間言語シンボルを持続するシンボルテーブル内に格納するステップをさらに含む、請求項５記載の方法。７．プログラムユニット及びプログラムオブジェクト、他のデータ構造を前記持続するシンボルテーブル内に格納するステップをさらに含む、請求項６記載の方法。８．前記実行するプログラムが更新することを目的として同時に操作されることが可能で、前記プログラムが前記操作の際に終了もしくは再始動しない、請求項７記載の方法。９．同時に操作される前記ステッブが、イメージの更新を容易にするようにランタイムコードオブジェクトの開始に当たり、ジャンプ命令を使用する、請求項８記載の方法。１０．同じ内部データ構造が、インクリメンタルイメージが使用されるように実行可能ファイルを作り出すために使用される、請求項１記載のシステム。１１．前記コードオブジェクト及び中間言語シンボルから実行可能ファイルを作り出すようにエクストラクタをさらに含み、それによってソースファイルに返す必要が排除される、請求項１０記載のシステム。１２．コードオブジェクトに表現式もしくは命令文を変換するステップ；ランタイムコードオブジェクトに対応する実行するイメージを更新するステップ；さらにインタラクティブ表現式評価もしくは命令文実行の目的で、デバッグにおいて、ランタイムコードオブジェクトを実行するステッブ；とをさらに含む、請求項６記載の方法。１３．条件付ブレークポイントに関して使用される変換及び更新、実行のステップをさらに含む、請求項１２記載の方法。