JPH08512154A

JPH08512154A - 増分リンカ・システム

Info

Publication number: JPH08512154A
Application number: JP7502766A
Authority: JP
Inventors: ローレンス，ロジャー，ピー．; ダンス，ジョン，アール．
Original assignee: タリジェントインコーポレイテッド
Priority date: 1993-06-28
Filing date: 1994-01-06
Publication date: 1996-12-17
Also published as: US5519866A; CN1102934A; EP0693193B1; CA2144875A1; EP0693193A1; AU6086294A; DE69402539D1; WO1995000904A1

Abstract

(57)【要約】増分リンカ・システムが開示されている。具体的には、人間指向オブジェクト・プログラミング・システムは、コンピュータ・プログラムを増分的に構築していき、オペレーティング・システムや大きなアプリケーションなどの複雑なコンピュータ・プログラムの開発を、グラフィカル・ユーザ・インタフェース（ＧＵＩ）を使用して容易化する対話式、動的プロセスを提供する。プログラムは、コンポーネントと呼ばれる単位のコレクションとしてモデル化される。コンポーネントはクラスや関数などの、互換性をもつ単一言語エレメント（要素）を表わしている。主要機能はデータベース、コンパイラ、構築メカニズムおよびリンク・メカニズムである。コンパイラはプロパティのソース・コードをコンパイルし、オブジェクト・コードを生成することと同時に、コンポーネントに関連する従属関係を計算することを担当する。構築メカニズムは、コンポーネントのプロパティを、コンパイラ生成の従属関係と一緒に使用して、構築プロセス期間にコンポーネントのコンパイルを正しく、かつ効率的に順序づける。リンク・メカニズムは、コンポーネントがオブジェクト・コードをコンポーネント・データベースにストアするとき、すべてのオブジェクト・コードをリンクする。更新されたコンポーネントだけがリンキング・オペレーションを必要とする。

Description

【発明の詳細な説明】増分リンカ・システム著作権表記本特許出願の一部には、著作権保護の対象となる内容が含まれている。著作権所有者は、米国特許商標局の特許ファイルに登録されている特許文書または特許開示事項を第三者がファクシミリで複製することを妨げるものではないが、その他の場合には一切の著作権を所有することを留保する。関連特許出願の相互参照本特許出願は、「ローダ・システム(Loader System)」という名称の特許出願（発明者Russell NakanoおよびAndrew G．Heninger、承継人Taligent）の関連出願であり、その開示事項は引用により本明細書の一部を構成するものである。発明の分野本発明は、一般的には、コンピュータ支援ソフトウェア・エンジニアリング(c omputer aided software engineering‐CASE)に関し、より具体的には、コンピュータ・プログラム構築のための対話式(interactive‐インタラクティブ)、動的環境を提供する人間指向オブジェクト・プログラミング・システム(human ori ented object programming‐HOOPS)に関する。ＨＯＯＰＳによると、プログラマは、最適化増分(incremental)コンパイラを備えたコンピュータ・プログラムで、ソース・コードの編集をきめ細かく行なうことができる。本発明は、ＨＯＯＰＳ内部で動作し、ローダで使用されるファイルを作成する増分リンカ(increment al linker)に係るものである。本発明は、ポピュラーなオブジェクト指向プログラミング(object oriented programming‐OOP)言語である、Ｃ＋＋を使用する好適実施例を例にして開示されているが、本発明の原理は、オブジェクト指向であるか、手続向き(procedural)であるかに関係なく、他のコンピュータ・プログラミング言語にも応用可能であり、従来の言語とＯＯＰ言語のどちらを使用しても、プログラムを構築するために使用することができる。発明の背景オブジェクト指向プログラミング（ＯＯＰ）は、ユーザ・フレンドリなインテリジェント・コンピュータ・ソフトウェアを構築するための好適な環境である。ＯＯＰの中心となる要素は、カプセル化(encapsulation)、継承(inheritance)および多態(polymorphism)である。これらの要素は、アイコン、マウス・カーソル、およびメニューをもつウィンドウ操作環境で特徴づけられている、グラフィカル・ユーザ・インタフエース(graphical user interface‐GUI)を生成するために使用することができる。これらの３つの主要要素は、ＯＯＰ言語に共通しているが、大部分のＯＯＰ言語では、これらの３主要要素の実現方法が異なっている。ＯＯＰ言語の例としては、Smalltalk、Object PascalおよびＣ＋＋がある。Sm alltalkは実際には言語を越えており、正確には、プログラミング環境と特徴づけることができる。Smalltalkは、１９７０年代の初期に、ゼロックス社のAlto Research Center(PARC)のLearning Research Groupによって開発されたものである。Smalltalkでは、メッセージがオブジェクトに送られ、そのオブジェクト自身が評価される。メッセージは、従来のプログラミング言語におけるファンクション（関数）コールのそれと似たタスクを実行する。プログラマはデータのタイプを気にする必要がなく、むしろ、プログラマは、メッセージを正しい順序で作成し、正しいメッセージを使用することだけを気にすればよい。Object Pascal は、アップル・マッキントッシュ（登録商標）コンピュータ用に使用されている言語である。アップル社は、Pascalの設計者であるNiklaus Wirthの協力を得てO bject Pascalを開発した。Ｃ＋＋は、１９８３年にAT&T Bell LaboratoriesのBjarne StroustrupによってＣの拡張版として開発されたものである。Ｃ＋＋の中心となる概念はクラス(class)であり、これはユーザが定義するタイプである。クラスはオブジェクト指向プログラミンの特徴を備えている。Ｃ＋＋モジュールはＣモジュールと互換性があり、自由にリンクできるので、既存のＣライブラリをＣ＋＋プログラムで使用できるようになっている。最も普及しているオブジェクト・ベースのプログラミング言語とオブジェクト指向プログラミング言語の起源は、１９６０年代にノルウェーのO-J．Dahl、B．Myhrha ugおよびK．Nygardによって開発されたSimulaである。ＯＯＰの主題に関する詳細説明は、Grady Booch著「オブジェクト指向設計とその応用(Object Oriented Design and Applications)」(The Benjamin/Cummings Publishing Co.，Inc.，R eadwood City，Calif.(1991))に記載されている。コンピュータ・プログラムを実行するプロセス全体は、プログラマが書いたソース・コードを、オブジェクト・コードと呼ばれるマシン実行可能形体に変換（翻訳）し、オブジェクト・コードを実行することにより行なわれる。変換プロセスは、インタプリータまたはコンパイラによって実行される。インタプリータの場合には、変換はプログラムの実行時に行なわれ、これに対してコンパイラの場合には、プログラム実行に先立って変換が行なわれ、オブジェクト・コードとしてストアされる。つまり、通常のコンパイルと実行システムでは、変換と実行の２フェーズは別々であり、コンパイルは一度だけ行なわれている。Smalltalkインタプリータのような、インタプリータ・システムでは、これらの２フェーズはシーケンスに行なわれている。Smalltalkでインタプリータが必要であるのは、そのプログラミング環境の性質上、オブジェクトが実現されるまでは特定のレジスタまたはアドレス空間(address space)を指定できないためである。コンパイラは、レキシカル・アナライザ(lexical analyzer−字句解析)、シンタックス（構文）アナライザ、およびコード・ジェネレータの３部分からなっている。レキシカル・アナライザへの入力は、高水準言語プログラムを表わす文字のシーケンス（文字列）である。レキシカル・アナライザはこのシーケンスをトークンのシーケンスに分割し、これはシンタックス・アナライザへの入力となる。シンタックス・アナライザはトークンを命令に分割し、文法ルールを使用して、各命令が文法的に正しいかどうかを判断する。正しければ、命令は基本的命令のシーケンスに分解され、これはコード・ジェネレータへ転送されて低水準言語が得られる。コード・ジェネレータは、それ自身が３部分に分割されているのが代表的である。つまり、中間コード生成、コード最適化、およびコード生成である。基本的には、コード・ジェネレータはシンタックス・アナライザからの出力を受け取り、マシン言語コードを生成する。ソフトウェア開発を支援するために、増分コンパイラが開発されたが、これによれば、コンパイラは、ステートメントまたはステートメント群を受け取った時点で、そのあとで生成される他のステートメントのコードに関係なく、バッチ処理オペレーションでそのコードを生成している。増分コンパイルの利点は、変更によって影響を受けたコードだけがコンパイルされることである。この結果、コードをコンパイルし、デバッグするときのターンアラウンド時間が大幅に高速化している。最適化コンパイラは、高度に最適化されたオブジェクト・コードを生成するので、多くの場合、ソース・コード・レベルでのデバッグが非最適化コンパイラによる場合よりも、非常に困難になっている。問題点は、ルーチンが正しい解が得られるようにコンパイルされたとしても、そのルーチンがその解を計算する正確な仕方が、ソース・コードに記述されているものと大幅に異なるということである。最適化コンパイラができるものとしては、最終結果に影響しないことが分かっているコードや変数を除去すること、不変コードを移動してループから出すこと、共通コードを結合すること、変数に割り当てられたレジスタをその変数が不要になったとき再使用することなどがある。従って、ソース・コードからオブジェクト・コードへのマッピングまたはその逆のマッピングは、これらの最適化のいくつかが行なわれた場合、困難になることがある。変数の値がルーチン内の任意のロケーションで常に使用可能であるとは限らないため、変数の値を調べることが困難になることがある。最適化コード内の変数の値を変更することは、不可能ではないにもても、特に困難である。揮発性(volatile)と明示に宣言されていなければ、コンパイラは変数に割り当てられた値を「記憶」しており、その変数を再読み取りすることなく、コードの後半で「既知の」値を使用するおそれがある。従って、その値が変更されると、エラーのあるプログラム結果が得られることになる。コンピュータ・プログラム構築、テストおよび開発の分野では、多数の進歩が行なわれているが、公知のソフトウェア開発ツールは、依然として、プログラマに大きな負担をかけており、洞察力のある直感が要求されることがしばしばである。さらに、従来のバッチ向きプログラミング・システムでは、編集−コンパイル−テストのサイクルが非常に長いために、創造的なプログラミングを行なうのに大きな支障となっている。従来のプログラミング・システムでは、コンパイルを終えても、アプリケーションをリンクし、ロードすることがまだ残っている。リンカと呼ばれるプログラムは、再配置可能(relocatable)マシン・コードのいくつかのファイルから１つのプログラムを作り出す。これらのファイルは、いくつかのコンパイルの結果である場合がある。そのあと、プログラムはロードされるが、これは、再配置可能マシン・コードを取り出し、再配置可能アドレスを変更し、変更された命令とデータをメモリ内の正しいロケーションに置くことにより行なわれる。発明の概要以上に鑑みて、本発明の目的は、コンピュータ・プログラム構築のための人間指向で、対話式かつ動的なプロセス内で動作する増分リンカ(incremental linke r)を提供することである。対話式、動的構築プロセスでは、プログラム構築は、プロジェクト(project) と呼ばれる増分プログラム・モデル(incremental program model)と３つの主要機能とがやりとりすることによって可能になっている。プログラムは、コンポーネント(component)と呼ばれるセマンティック単位(semantic unit)としてモデル化され、これらは、プロパティ(property)と呼ばれる、名前付きデータ・アイテム（項目）のリストから構成されている。従来のシステムで行なわれているように、プログラムを、結合の弱いファイルのコレクション(loose collection)としてストアするのではなく、本発明の人間指向オブジェクト・プログラミング・システム（ＨＯＯＰＳ）によれば、プログラムに関するすべての情報はプロジェクトにストアされる。コンピュータ構築プロセス(computer builder process)によると、プログラマの注意力と集中力が向上するので、生産性を向上することができる。本発明によれば、ＨＯＯＰＳ内で動作する増分リンク機能が提供されており、この増分リンク機能では、関数は既存の実行可能ファイル(executables)にリンクされるので、オブジェクト・ファイル・セット全体を再処理する必要がなくなっている。本発明を実施する際には、コンピュータ・プログラムはコンポーネントのコレクションとしてモデル化される。コンピュータ・プログラムのモデルとなるコンポーネントは、構築プロセスの実行時にアクセスされるようにストアされている。ストアされたコンポーネントはシーケンス（順番）にアクセスされ、各コンポーネントに関連する従属関係(dependencies)は、コンパイラを使用して計算され、従属関係リストが作成される。次に、コンポーネントは従属関係リストに基づいてコンパイルされ、更新されたオブジェクト・モジュールが生成される。最後に、更新されたオブジェクト・モジュールは既存の実行可能ファイルを更新することによってリンクされる。本発明の好適実施例はＣ＋＋で書かれており、現在使用されている最もポピュラーな言語である、Ｃ＋＋、Ｃおよびアセンブラでプログラムを構築するために使用される。本発明を使用して構築されるプログラムは、これらの３言語すべてを使用するのが代表的である。従って、本発明は、それ自体がオブジェクト指向プログラミング言語で書かれたオブジェクト指向プログラムであるが、オブジェクト指向プログラミング言語でプログラムを構築することだけに限定されるものではなく、手続き向き言語でプログラムを構築する場合にも同じく有用である。さらに、本発明はＣ＋＋言語に限定されるものではなく、他のプログラミング言語で実現することも可能である。また、本発明はそのアプリケーションが前記３言語に限定されるものではない。つまり、本発明の教示事項は、より一般的なアプリケーションの人間指向オブジェクト・プログラミング・システムで利用することが可能である。図面の簡単な説明上記およびその他の目的、側面および利点は、その理解を容易にするために、以下、添付図面を参照して本発明の好適実施例について詳しく説明する。なお、添付図面において、図１は、高解像度グラフィックス・ディスプレイ・デバイスおよびマウスなどのカーソル・ポインティング・デバイスをサポートする機能を備え、本発明を実現することができる汎用コンピュータ・システムを示す絵図である。図２は、図１に示す汎用コンピュータ・システムにおいて、コンピュータ・システムの主要エレメントの詳細を示すブロック図である。図３は、プログラムを構成するコンポーネントのコレクションを概念化して示すブロック図である。図４は、本発明の主要機能を示すブロック図である。図５Ａから図５Ｄまでは１つに連結されて、編集した変更をBuildStatesを通して登録するロジックを示すフローチャートである。図６は、本発明による構築メカニズムのオペレーションの第１ステージで、可能とされるコンポーネントを判断するロジックを示すフローチャートである。図７は、本発明による構築メカニズムのオペレーションの第２ステージで、インタフェース(Interfaces)を処理するロジックを示すフローチャートである。図８は、本発明による構築メカニズムのオペレーションの第３ステージで、インプリメンテーション(Implementations)を処理するロジックを示すフローチャートである。図９は、本発明によるコンパイラから呼び出されるGetDeclarations関数のロジックを示すフローチャートである。図１０Ａと図１０Ｂは１つに連結されて、Conditionally Compile関数のロジックを示すフローチャートである。図１１は、本発明を使用しているときの代表的なメンバ・ビュワー(members v iewer)示しているコンピュータ・スクリーンの絵図である。図１２は、本発明によるブラウザ(browser)を示しているコンピュータ・スクリーンの絵図である。図１３は図１２に示すコンピュータ・スクリーンにおいて、ブラウザ・ワイヤリングがオンになっている様子を示す絵図である。図１４は、部分的に展開したプロジェクトをツリー・ビュワーで示しているコンピュータ・スクリーンの絵図である。図１５から図１８までは、コンポーネントを編集している過程で表示されるスクリーンの一部を示す図である。図１９は、好適実施例による内部クロスライブラリ・コール(internal and cr oss library call)を示す図である。図２０は、好適実施例によるフィックスアップ・クラス(fixup class)のセットを示す図である。図２１は、好適実施例によるリンケージ・エリアを示す図である。図２２は、好適実施例によるオブジェクト・コードのストーレッジを示す図である。図２３は、好適実施例によるロードされたライブラリを示す図である。図２４は、好適実施例によるロード・モジュールのメモリ・マップを示す図である。図２５は、好適実施例による種々のタイプの参照およびリンカによる参照の変更を示す図である。図２６，図２７，図２８および図２９は、好適実施例によるリンキングに関連するロジックを示すフローチャートである。本発明の好適実施例の詳細な説明以下、添付図面、特に、図１を参照して説明する。図１は汎用コンピュータ１０を示したものである。コンピュータ１０はシステム・ユニット１２と陰極線管（ＣＲＴ）などの高解像度ディスプレイ・デバイス１４を備えいる。なお、ＣＲＴは液晶ディスプレイ（ＬＣＤ）にすることも可能である。ディスプレイのタイプは、グラフィックス・ユーザ・インタフェース（ＧＵＩ）を代表とするウィンドウ操作システムに要求される高解像度ディスプレイであることを除けば、重要でない。コンピュータへのユーザ入力はキーボード１６およびマウス１８などのカーソル・ポインティング・デバイスを通して行なわれる。マウス１８はキーボード１６に接続され、キーボードの方はシステム・ユニット１２に接続されている。別の方法として、マウス１８をシステム・ユニット１２内の専用ポートまたはシリアル・ポートに接続することも可能である。図１に示すタイプの汎用コンピュータの例としては、アップル・マッキントッシュ（アップル・コンピュータ社の登録商標）およびＩＢＭＰＳ／２がある。その他の例としては、ＩＢＭＲＩＳＣシステム／６０００およびサン・マイクロシステムズ社コンピュータなどの種々ワークステーションがある。図２は、図１に示す汎用コンピュータ・システムの主要エレメントの詳細を示す図である。システム・ユニット１２は中央演算処理ユニット（ＣＰＵ）２１、ランダム・アクセス・メモリ（ＲＡＭ）２２、およびリードオンリ・メモリ（ＲＯＭ）２３を装備し、これらはバス２４に接続されている。ＣＰＵ２１は、いくつかの市販マイクロプロセッサにすることができる。そのようなものとして、アップル・マッキントッシュ（登録商標）コンピュータで広く使用されているモトローラ68030と68040マイクロプロセッサや、ＩＢＭＰＳ／２コンピュータで広く使用されているインテル80386と80486マイクロプロセッサがある。代表例としてワークステーションで使用されているＲＩＳＣ(reduced instruction set com puter−縮小命令セット・コンピュータを意味する)マイクロプロセッサなどの、他のマイクロプロセッサを使用することも可能である。ＲＯＭ２４は、基本入出力システム(basic input/output system‐BIOS)を含めて、ＣＰＵ２１用の基本マイクロコードをストアしている。コンピュータ・システム１０用のオペレーティング・システム（ＯＳ）をＲＯＭ２４にストアしておくことも可能であるが、別の方法として、ＯＳは初期プログラム・ロード(initial program load‐IPL )の一部としてＲＡＭ２２にストアされている。ＲＡＭ２２は、アプリケーション・プログラムの一部と、プログラムの実行時に生成される一時データをストアするためにも使用されている。バス２４としては、アップルＮｕＢｕｓ（登録商標）、ＩＢＭマイクロチャネル (MicroChannel−登録商標)またはＩＳＡ（業界標準アダプタ）やＥＩＳＡ（拡張業界標準アダプタ）などの業界標準の１つにすることができる。バス２４には、ユーザ・インタフェース・アダプタ２５および入出力アダプタ２６を含む、種々の入出力（Ｉ／Ｏ）アダプタも接続されている。キーボード１６はユーザ・インタフェース・アダプタ２５に接続され、入出力アダプタ２６はフロッピ・ディスク・ドライブ２７とハードディスク・ドライブ２８に接続している。フロッピ・ディスク・ドライブ２７はデータとプログラムを取外し可能媒体に読み書きするのを可能にし、他方、ハードディスク・ドライブ２８は、ＲＡＭ２２との間でページインされ、ページアウトされるデータとプログラムをストアしているのが代表的である。ディスプレイ・デバイス１４はディスプレイ・アダプタ２９を介してバス２４に接続されている。通信アダプタ３０はネットワークとのインタフェースとなるものである。集積回路（ＩＣ）チップの形体になった、その他のサポート回路（図示せず）はバス２４および／またはＣＰＵ２１に接続されている。このような回路としては、例えば、バス２４上のトラフィックを制御するバス・マスタ・チップがある。バス２４は、一部のコンピュータでは、２バスになっている場合がある。データ・バスと、グラフィック・ユーザ・インタフェースで望まれているディスプレイ・オペレーションの高速化を可能にするディスプレイ・バスである。定義プログラム(program) 本発明の説明で用いられているときの、ＨＯＯＰＳプログラムは、プロジェクト(project)と呼ばれる１つの構築不能コンポーネント(non-buildable componen t)と、「構築可能コンポーネント」(buildable component)のコレクション（集合）とで構成されている。構築不能コンポーネントをストアすることも可能であるが、以下の説明では、未修飾のコンポーネントが言及されるときは、その意味は「構築可能コンポーネント」のことである。構築不能コンポーネントは構築オペレーションのときコンパイルされない。コンポーネント(component) コンポーネントは固有の識別子をもち、名前が付けられている。異種のコンポーネントは、ＩＤと呼ばれる、ある種の固有識別子(unique identifier)によって区別される。ＮｕｌｌＩＤと呼ばれる特別なＩＤがあり、これはどのコンポーネントにも属していない。ＩＤはコンポーネントの作成時に割り当てられ、そのコンポーネントが存在する間変更されることはない。コンポーネントが削除されると、そのＩＤは再使用されることがない。実際には、ＩＤは数字になっているのが通常である。コンポーネントは、テキスト・ストリングからなる名前ももっている。異なるコンポーネントが異なる名前をもたなければならないという要件はない。ある与えられたテキスト・ストリングに一致する名前をもつ、すべてのコンポーネントのリスト（空であることもある）を得ることが可能である。コンポーネントの名前は、そのコンポーネントが存在する間、なん回でも変更することができる。各構築可能コンポーネントは特定のコンピュータ言語が関連づけられている。実際には、コンピュータ言語はテキスト・ストリングによって識別されるのが通常である。各コンピュータ言語は、その言語でいずれかのコンポーネントをコンパイルするとき使用されるコンパイラが関連づけられている。実際には、あるコンピュータ言語を２つ以上のコンパイラと関連づけることが可能になっている。その場合には、コンポーネントは言語のほかに、特定コンパイラを識別するなんらかの方法も記録していなければならない。特定の言語は、特定のコンポーネント種類(component kind)のセットが関連づけられており、特定のプロパティ・インプリメンテーションのセットをもち、これは種類ごとに異なる場合がある。従って、特定の言語の中の個々のセマンティック・エレメントは、要求に応じて異なった構造にすることが可能である。コンポーネントはBuildStatesをもっている。BuildStateは、リストNeverComp ile、Compile、NeedToComplile、Uncertain、BeingCompiled、CompilerError、およびUncertainErrorからの値である。実際には、これらの値は数値であるのが通常である。各コンポーネントは、InterfaceBuildStateおよびImplementationBuildStateと呼ばれるペアのBuildStatesをもっている。すべてのコンポーネントは、それが構築可能であるか、構築不能であるかに関係なく、両方のBuildStateをもっている。構築不能コンポーネントの場合は、これらの BuildStateは共にNeverCompileである。 BuildStateはアクセスして変更することができる。コンポーネントのBuildSta teを再度同じ値にセットすることは許されるが、セットしても、なにも作用しない。BuildStateを変更すると、同じまたは異なるコンポーネントの別のプロパティのBuildStateが変更されるという副作用が生じることが、明確に定義されている。つまり、例えば、変更リストやエラー・リストなどの、ある種のリストに参照が追加されたり、そのリストから削除されることになる。コンポーネントはセマンティック言語エレメントを表わすために使用される。これがどのように行なわれるかは、モデル化される特定コンピュータ言語によって決まる。例えば、Ｃ＋＋では、コンポーネントで表わされた言語エレメントのの一部を挙げると、グローバル・データ、グローバル関数、クラス、データ・メンバ、メンバ関数、typedefs、enums、enumerator、マクロ、unionおよびstruct などがある。代表例として、各セマンティック・エレメントは独自の種類が関連づけられている。プロパティ(property) コンポーネントは名前付きプロパティのコレクションからなっている。プロパティは、コンポーネントに関連づけられた、一部のデータを表わしている。コンポーネントのＩＤとプロパティ名が分かっていれば、データを取り出したり、ストアしたりできる。実際には、プロパティ名は、名前を識別する数字で内部表現されているのが通常である（このような数字はトークン(token)と呼ばれることがある）。NullPropetyと呼ばれる独特なプロパティ名があり、これはどのプロパティにも属していない。あるプロパティに関連づけられたデータは、コンポーネントが異なるごとに異なっている。あるコンポーネントのあるプロパティのデータを変更しても、そのことは、他のいずれかのコンポーネントの同じプロパティのデータが変更されることを意味しない。しかし、あるコンポーネントのあるプロパティが変化すると、同じまたは異なるコンポーネントの別のプロパティが変化することは起こり得る。ＩＤとプロパティ名からなるペアは参照(reference)と呼ばれる。参照は、プロパティ・データの特定の断片を固有に識別している。参照は、それが参照するコンポーネントおよび／またはプロパティであるかのように、ゆるやかに使用されることがよくある。実際には、参照はプログラム構築の際に直接に使用されない他の情報を含んでいて、データのどのバージョンおよびプロパティ内のデータのどのサブセクションが参照されているのかを示しているのが代表的である。すべてのコンポーネントはName（名前）プロパティとContainer（コンテナ）プロパティをもっていなければならない。Nameプロパティはコンポーネントの名前をストアしている。Containerプロパティは、プロパティ名がNullPropertyになっている単一の参照を収めている。いずれかのコンポーネントから始まり、そのコンテナＩＤが参照するコンポーネントでそのコンポーネントを連続的に置き換えていくと、最終的には、常にProject（プロジェクト）コンポーネントが得られることになる。プロジェクトのコンテナＩＤはNullIDである。従って、すべてのコンポーネントはプロジェクト内にあるものと記述されている。 "Component Built"プロパティ（コンポーネント構築リストとも呼ばれる）は最後の構築で正しくコンパイルされたプロパティのリストを、プロパティが構築された順に記録している。同じプロパティは多くても１回だけこのリストに現われるはずである。このリストはテストとデバッグを行なうとき使用される。プロジェクト・コンポーネント(Project Component) プロジェクトは、さらに、ChangeListプロパティとErrorListプロパティをもつコンポーネントである。ChangeListプロパティは参照リストである。参照は最後の構築以降に変更されたコンポーネントとプロパティを記述している。実際には、ChangeListは、プログラム構築の効率化のためになんらかの方法でソートされた２つ以上のリストで表わすことが可能になっている。ErrorListプロパティも参照リストである。これらの参照は、最後のプログラム構築期間にエラーがあるとリストされたコンポーネントを記述している。参照はすべてErrorsをそのプロパティとしてもっている。各参照には数値キーが関連づけられている。このキーは特定のErrorsプロパティと一緒に使用され、特定のメッセージとコンポーネントの特定プロパティの特定サブレンジを探し出す。ライブラリ・コンポーネント(Library Component) ライブラリはすべての構築可能コンポーネントのコンテナである。これは"Loa dModuleProperty"のプロパティをもっている。このプロパティは以下で詳しく説明する。複数のライブラリ・コンポーネントがプロジェクト内に存在することが可能である。各構築可能コンポーネントはライブラリ・コンポーネントによって収容されていなければならない。構築可能コンポーネント(Buildable Component) 構築可能コンポーネントは、Declaration、ObjectCode、Clients、SourceRefe rences、Errorsのプロパティももっていなければならないが、Interface、Imple mentation、およびMembersのプロパティをもつこともできる。 Declarationプロパティは、コンパイラ用のデータ・キャッシュを表わしている。これは、例えば、コンポーネントがコンパイルされる前のように、空になっている場合がある。実際には、これは、ストアされた表現がコンパイラの内部表現と異なることがあっても、コンパイラの記号テーブルのエントリと考えることができる。 ObjectCodeプロパティはコンポーネントの実行可能コードを表わしている。これは、例えば、コンポーネントがコンパイルされる前のように、あるいはこのコンポーネントに関連するオブジェクト・コードがないと、空になっている場合がある。実際には、これは、他の場所にストアされている実際のコードを指している手段となっているのが普通である。 ClientsとSourceReferencesプロパティは、参照と従属関係(dependency)からなるペアのコレクションである。従属関係は変更リストである。変更は、独特の有限ストリング・リスト(distinguished finite list of strings)から選択されたテキスト・ストリングで表わすことが可能である。Public（公開）と呼ばれる独特の変更があり、これは、Interfaceプロパティでの使用とは対照的に、Imple mentationプロパティだけのコンポーネントへの参照を区別するために使用されている。従属関係はビット・ベクトルで表わすことができ、ｎ番目のビットは、リスト内のｎ番目の変更が存在すれば“１”に、そうでなければ“０”になっている。 Errorsプロパティはトリプル(triple)のリストからなっている。各トリプルはキー、プロパティ名、およびメッセージからなっている。キーは数値識別子である。どのキーも、特定のErrorsプロパティの中に一度に一回だけ現われることができる。プロパティ名は、InterfaceまたはImplementationであるのが通常である。メッセージはテキストおよび／またはグラフィックスの一断片である。 InterfaceとImplementationプロパティは、コンポーネントのソース・テキストを表わすプロパティである。ソース・テキストはテキストではなく、トークンとしてストアしておき、必要ならば、異なる方法でアクセスすることができる。これらのプロパティで表わされたテキストは、プログラミング環境で手操作で編集することにより変更することができる。１つの方法として、Interfaceデータを構造化フィールド(structured fields)としてストアしておき、そこからソース・テキストを必要に応じて再構築することができる。 Membersプロパティは参照のコレクション（空である場合もある）であり、参照は、プロジェクト内の各コンポーネントごとに１つあり、このコンポーネントをそのコンテナとしてもっている。属性(attribute) コンポーネントはいくつかの属性をもっている。属性は真か偽のどちらかになっている。実際には、属性はメモリの１ビットで表わされるのが普通であり、真と偽の値は“１”と“０”の数字で表されている。すべてのコンポーネントは、 Isbuildableの属性をもっている。この属性が真であれば、コンポーネントは構築可能である。偽ならば、構築不能である。コンポーネントは常時構築不能にすることも、一時的に構築不能（なんらかの一時的条件のアクションにより）にすることもできる。構築可能コンポーネントは属性IsInlineももっている。この属性が真であるときは、コンポーネントのインプリメンテーションは公開(public)であり、このことは、他のコンポーネントがインプリメンターションの変更に従属できることを意味する。この属性が偽であるときは、インプリメンテーションが変更されても、他のコンポーネントが変更されることはない。構築可能コンポーネントは属性IsSyntheticももっている。この属性は、構築プロセス期間にコンパイラによって作成されたコンポーネントでは真になっている。これは、プログラマによって手作業で作成されたコンポーネントでは偽になっている。合成(synthetic)コンポーネントは、必要であるが、プログラマが明示的に作成する必要のない、デフォルト（省略時）の言語エレメントに対応するコンポネーントを、コンパイラが作成できるように用意されたものである。実際には、例えば、合成されたコンポーネントが手作業で編集される場合には、IsSy nthetic属性を真から偽へ変更する必要が起こるが、偽から真への逆の変更は許されない。合成コンポーネントは、InterfaceまたはImplementationプロパティをもたないことがよくあるが、どのような場合も、InterfaceとImplementation BuildStates Compiledは常にもっている。種類(kind) 各コンポーネントは種類をもっている。種類は、例えば、同じプロパティまたは同じ言語固有の作用(behavior)を共有するグループにコンポーネントを分類するために使用されるテキスト・ストリングである。大部分の種類は特定のコンピュータ言語に固有になっており、意味的に異なる言語エレメントを示すために使用される。しかし、システムによって定義された種類がいくつかある。これらはProject 、LibraryおよびContainerの種類である。これらの種類は構築不能コンポーネントだけに適用される。Project種類はProjectコンポーネントの種類である。Libr ary種類は、共有ライブラリやアプリケーションのような、オブジェクト・コードの単一外部ブロックにリンクされるコンポーネントのコレクションに適用される。Container種類は、編成目的のために他のコンポーネントをグループ化するために使用されるコンポーネントに適用される。実際には、種類は数値で内部表現されているのが普通である。発明の概要図３は、１組のコンポーネント３１で構成されたプログラムを概念化した図である。各コンポーネントは１組のプロパティで構成され、プロパティは、外部から見える（public：公開）部分３１１（インタフェースと呼ばれる）とインプリメンテーション３１２（privatepart：私有部分）の２つの部分に分かれている。図３に示すように、コンポーネントは別のコンポーネントのインタフェースだけに従属する。プロジェクト内のすべてのコンポーネントはツリー構造に編成されており、ツリーのベースはプロジェクト・コンポーネントと呼ばれるルート(r oot)コンポーネント３２になっている。この分野の当業者ならば理解されるように、コンポーネントは必ずしも自己完結エンティティ(self-containedentity)である必要がないが、実際のコードの記憶ロケーションを指すポインタを含むことができる。それにもかかわらず、ツリー構造表現はプログラムの編成を表わすときに便利であるので、下述するユーザ・スクリーンの１つでは類似のツリー構造表現が使用されている。図４は、本発明の主要機能を示すブロック図である。これらはデータベース４１、コンパイラ４２、および構築メカニズム４３である。データベース４１は、ここではプロジェクト・コンポーネント４１１として示されている１組のコンポーネントと、構築されるプログラムをモデル化する構築可能コンポーネントのコレクション４１２とで構成されている。コンパイラ４２はデータベース４１内のコンポーネントに関連する従属関係を計算する。構築メカニズム４３はコンパイラ生成の従属関係と一緒に、コンポーネントのプロパティを使用して、プログラムを構築する。リンク・メカニズム４５は更新されたコンポーネントを増分的にリンクし、ロードされたアプリケーションを更新することもできる。リンク・メカニズムは、コンパイラによって生成されたオブジェクト・コードを収集して実行可能ファイルとする。プログラマはエディタ４４を使用してプログラムを変更する。エディタはコンポーネントを作成し、削除し、代表例として、コンポーネントをカットし、コピーし、ペーストし、移動する機能を備えていなければならない。また、エディタは、InterfaceとImplementationプロパティ内のデータを、通常はテキストの直接的操作を可能にすることによって変更できる機能を備えていなければならないが、メニューからの選択といった、他のもっと構造化されたアプローチによることも可能である。実際には、エディタ４４はいくつかのエディタから構成されていることがよくあり、場合によっては、InterfaceまたはImplementationプロパティの各タイプごとに１つのエディタが、場合によっては、これらのプロパティ内のデータのサブフィールドにさえも１つのエディタが用意されている。編集した変更を登録するメソッド以下では、増分構築に関連するエディタ４４で実行される機能のロジックを示すフローチャートを示している図５Ａ〜図５Ｄを参照して説明する。構築可能な非合成コンポーネントの場合は、BuildStatesは、構築プロセスの外でCompiled とNeedToCompileの値に限定されている。Interfaceプロパティが存在しなければ、InterfaceBuildStateはCompiledになっている。Implementationプロパティが存在しなければ、ImplementationBuildStateはCompiledになっている。図５Ａには、種々の編集ステート変更が示されている。ラベル５００に示すように、システムがcreateComponent、RenameComponent、pasteComponentまたはEditInterfac eコマンドであることを認識すると、制御が機能ブロック５１０へ移り、インタフェース変更が処理される。この変更の詳細ロジックは図５Ｂに示されている。図５Ｂに示すように、処理は判定ブロック５１１から開始され、そこでテストが行なわれ、インタフェース構築ステート(interface build state)がNeedToCom pileであるかどうかが判断される。そうであれば、制御はラベル５１４から渡されて編集が続行される。これらのアクションは、再構築時にではなく、編集時に行なわれる。次のアクションとしては、別の編集アクションが行なわれるのが普通である。そうでなければ、機能ブロック５１２で、インタフェース構築ステートはNeedToCompileにセットされ、インタフェース変更リストがそのことを反映するように更新される。次に、機能ブロック５１３で、インプリメンテーション変更およびコンテナ変更処理が行なわれる。インプリメンテーション変更オペレーションの詳細は、図５Ｃに示されており、コンテナ変更オペレーションの詳細は、図５Ｄに示されている。図５Ｃは、インプリメンテーシヨン変更に関連する詳細処理を示している。判定ブロック５７１で、テストが行なわれ、インプリメンテーション構築ステートがすでにNeedToCompileにセットされているかどうかが判断される。そうであれば、制御はラベル５７２から渡されて編集が続行される。そうでなければ、機能ブロック５７３で、インプリメンテーション構築ステートはNeedToCompileにセットされ、インプリメンテーション変更リストがそのことを反映するように更新される。次に、制御はラベル５７４から返却される。図５Ｄはコンテナ変更オペレーションに関連する詳細ロジックを示している。テストが判定ブロック５４２で行なわれ、変数が構築可能であるかどうかが判断される。そうであれば、機能ブロック５４３で、図５Ｂの説明で詳しく上述したように、インタフェース変更がコンポーネントのコンテナと一緒にコールされる。そのあと、制御はラベル５４４から返却される。 Edit Implementationコマンドが図５Ａのラベル５６０で検出されると、機能ブロック５７０に示すように、また図５Ｃの説明で上述したように、処理はインプリメンテーション変更アクションを実行する。 Delete Componentコマンドが図５Ａの５３０で検出されると、機能ブロック５４０に示すように、また図５Ｄの説明で上述したように、コンポーネントＡのコンテナ変更処理が開始される。そのあと、コンポーネントＡは削除され、制御はラベル５５０から返却される。 Move Componentコマンドが図５Ａの５８０で検出されると、機能ブロック５９０に示すように、または図５Ｄで詳述したように、コンポーネントＡのコンテナ変更処理が開始される。そのあと、コンポーネントのコンテナは新しいコンテナにセットされ、図５Ｂで詳述したように、コンポーネントＡのインタフェース変更処理が開始される。最後に、処理はラベル５９５から返却される。構築のコンポーネントを判断するメソッドプログラム構築期間には、Projectコンポーネントは、CompileListと呼ばれる参照の私有リストを維持している。InterfaceCompileListとImplementationComp ileListがある。Projectは、InternalErrorListと呼ばれる参照の私有リストも維持している。実際には、これらのリストの各々は、効率上の理由から２つ以上のリストによって物理的に表わすことが可能である。プロセスは図６に示されている。機能ブロック６０１に示すように、プロジェクトのChangeList内の各参照ごとに、参照はリストの先頭から選択される。リストに参照が残っていなければ、処理は、機能ブロック６０２に示すように完了する。参照がInterfaceであるとブロック６０３で判断されると、参照のコピーがI nterfaceCompileListに入れられ、関数AddClientsが機能ブロック６０４で参照に対してコールされてから、処理がブロック６０１から続行される。そのプロパティ名がInterfaceでなければ、そのプロパティ名は、ブロック６０５に示すようにImplementationであるので、テストが判定ブロック６０６で行なわれ、IsIn line属性が真であるかどうかが判断される。そうであれば、参照のコピーがInte rfaceCompileListに入れられ、その参照で関数AddClientsが機能ブロック６０７でコールされてから、処理がブロック６０１から続行される。そうでなければ、そのプロパティ名はImplementationでなければならず、そのIsInline属性は偽でなければならないので、参照のコピーが機能ブロック６０８でImplementationCo mpileListに入れられてから、処理がブロック６０１から続行される。関数CreateCompileListsの擬似コードは次のとおりである。関数AddCleintsは、パラメータ参照クライアント・プロパティ内の各参照ごとに、参照を調べ、そのBuildStateがCompiledであれば、参照のBuildStateをUnce rtainにセットし、参照のコピーを該当のCompileListに追加し、その参照に対してAddClientsをコールする。このプロセスは、ChangeListのクライアント・クロージャ(Client Closure)の作成と呼ばれる。クライアント・クロージャは、構築の結果として、再コンパイルが必要になるコンポーネントのサブセットを表わしている。実際には、構築の進行と共にコンパイラによって生成される従属関係と変更は、クライアント・クロージャ内の多くのコンポーネントに対して、できるかぎりコンパイルを避けるように使用される。以下は、AddClients関数の擬似コードである。インタフェースを処理するメソッドこれは構築プロセスの第２ステージである。InterfaceCompileList上のアイテムがとり得るBuildStatesはCompliled．BeingCompiled、NeedToCompile、Uncert ain、CompileErrorまたはUncertainErrorである。 InterfaceCompiledListは、図７のフローチャートに示すように空になるまで処理される。このプロセスにはブロック７０１から入り、そこで、参照がInterfac eCompileListの先頭から選択される。リストに参照が残っていなければ、処理はブロック７０２で完了する。その参照に関連するコンポーネントのインタフェースBuildStateがブロック７０３に示すように、Compiled、CompileErrorまたはUn certainErrorであれば、参照がリストの先頭から除去され、処理はブロック７０１で続行される。参照に関連するコンポーネントのインタフェースBuildStateが、ブロック７０４に示すようにBeingCompiledまたはNeedToCompileであれば、コンポーネントのBuildStateは機能ブロック７０５でBeingCompiledにセットされる。次に、Compile関数（これはコンパイラ４２を呼び出す）がコンポーネントのインタフェースに対してコールされる。この関数はAbort（打切り）、Done（完了）およびError（エラー）の値の１つを返却する。返却された値がブロック７０６でAbortであれば、処理はブロック７０１から続行される。返却された値がブロック７０７でDoneであれば、コンポーネントのインタフェースBuildStateは Compiledにセットされ、参照がブロック７０８でリストの先頭から除去されてから処理がブロック７０１から続行される。返却された値がブロック７０９でErro rであれば、コンポーネントのインタフェースBuildStateがCompileErrorにセットされ、参照がリストの先頭から除去され、関数PropageteErrorが機能ブロック７１０で、コンポーネントに対してコールされてから、処理がブロック７０１から続行される。参照に関連するコンポーネントのインタフェースBuildStateがUn certainであるとブロック７１１で判断されていれば、コンポーネントのBuildSt ateは機能ブロック７１２でBeingCompiledにセットされる。次に、ConditionallyCompile関数（これはコンパイラ４２をコールする場合とコールしない場合がある）がコンポーネントのインタフェースに対してコールされる。この関数も、Abort、DoneまたはErrorの値の１つを返却する。返却された値がAbortであれば、処理はステップ１から続行される。返却された値がブロック７１３でDoneであれば、参照が機能ブロック７０８でリストの先頭から除去され、処理がブロック７０１から続行される。返却された値がブロック７１４でEr rorであれば、参照がリストの先頭から除去され、関数PropagateErrorが機能ブロック７１５でコンポーネントに対してコールされてから、処理がブロック７０１で続行される。 ProcessInterface関数の擬似コードは次のとおりである。関数PropagateErrorは、コンポーネントに対応する参照をプロジェクトのInte rnalErrorListに追加し、コンポーネントのクライアント・リスト上のすべての参照について、以下のことを実行する。参照のBuildStateがCompileErrorまたは UncertainErrorであれば、プロセスは次の参照から続行される。参照のBuildSta teがNeedToCompileであれば、プロセスは、そのBuildStateをCompileErrorにセットし、参照をInternalErrorListに追加し、その参照でPropagateErrorをコールしてから、次の参照から続行する。参照のBuildStateがUncertainであれば、プロセスはそのBuildStateをUncertainErrorにセットし、参照をInternalErrorL istに追加し、その参照でPropagateErrorをコールしてから次の参照から続行する。関数PropagateErrorの擬似コードは次のとおりである。インプリメンテーションを処理するメソッドこれは構築プロセスの第３ステージである。ImplementationCompileList内の各参照は図８のフローチャートに示すように処理される。プロセスにはブロック８０１から入り、そこで参照がImplementationCompileListの先頭から選択される。リストに参照が残っていなければ、処理はブロック８０２で完了する。参照のBuildStateがUncertainであるとブロック８０３で判断されていれば、参照のB ui1dStateが機能ブロック８０４でCompiledにセットされてから、処理がブロック８０１から続行される。参照のBuildStateがNeedToCompileであるとブロック８０５で判断されていれば、コンポーネントは機能ブロック８０６でコンパイルされる。コンパイラ４２から返却される可能性のある値としては、DoneとError がある。返却された値がブロック８０７でDoneであれば、参照のBuildStateが機能ブロック８０４でCompiledにセットされてから処理がブロック８０１から続行される。返却された値がブロック８０８でErrorであれば、参照のBuildStateがC ompileErrorにセットされ、関数PropagateErrorが機能ブロック８０９でコンポーネントに対してコールされてから、処理がブロック８０１から続行される。参照のBuildStateがCompileErrorまたはUncertainErrorであれば、なにも行なわれない。ここで注意すべきことは、インプリメンテーションの処理がこのステージでは順序に依存しないのは、そのIsInline属性が真であるインタフェースまたはインプリメンテーションだけに依存することができ、これらはすでに処理されているからである。 ProcessImplementationsの擬似コードは次のとおりである。構築プロセスをサポートするコンパイラコンパイラ４２はCompile関数からコールされ、これらの２つはシノニム（同義語）として使用できる。コンパイラ４２はソース・テキストを処理し、起こり得る外部コンポーネントの名前を識別する。コンパイラ４２は、次に、すべてのコンポーネントへの参照リストを取得する。コンパイラはコンポーネント種類などの言語固有の知識を使用してリストから参照を除去することができる。次に、コンパイラはテキストに示された各外部コンポーネントごとにGetDeclarationと呼ばれる関数をコールする。Compile関数はコンポーネントにエラーがあれば、それをクリアしてからコンパイラ４２を呼び出す。これにより、Errorsプロパティからのエラーをクリアし、プロジェクトのErrorListプロパティから参照を除去する。コンパイラは、まず、GetDeclaration関数をコールする。これは図９のフローチャートに示されている。GetDeclaration関数はAbort、Done、Circulardepende ncyまたはErrorの値の１つを返却し、さらに、デクラレーションのデータを返却する場合もある。プロセスにはブロック９０１から入り、そこで各参照はそのBu ildStateが調べられる。処理すべき参照が残っていなければ、ブロック９０２に示すように、処理は完了し、リターンが行なわれる。コンポーネントのBuildSta teがブロック９０３に示すようにCompiledであれば、関数は機能ブロック９０４でDoneを返却し、ストアされたデクラレーション・データも返却されてから、処理はブロック９０１から続行される。コンポーネントのBuildStateがブロック９０５に示すように、NeedToCompileまたはUncertainであれば、コンポーネントに対応する参照が機能ブロック９０６でInterfaceCompileListの先頭に追加され、関数が機能ブロック９０７でAbortを返却してから、処理はブロック９０１から続行される。この場合には、デクラレーション・データは返却されない。コンポーネントのBuildStateがブロック９０８に示すようにBeingCompiledであれば、関数が機能ブロック９０９でCirculardependencyを返却してから処理はブロック９０１から続行される。この場合も、デクラレーション・データは返却されない。コンポーネントの Bui1dStateがブロツク９１０に示すように、CompileErrorまたはUncertainError であれば、関数が機能ブロック９１１でErrorを返却してから処理はブロック９０１から続行される。この場合も、デクラレーション・データは返却されない。 GetDeclaration関数の擬似コードは次のとおりである。 GetDeclarationをコールしたあと、コンパイラは次のように続行する。返却された値がAbortであれば、コンパイラは処理を中止して、値Abortを返却しなければならない。別のインプリメンテーションでは、コンパイラはコンパイルを一時中止し、返却されたコンポーネントをコンパイルしたあと再始動されるか、断念されることになる。このためには、コンパイラを再入可能（リエントラント）にする必要があるが、それ以外は、上述したプロシージャに基本的な変更を加える必要はない。返却された値がCompiledであれば、コンパイラは処理を続行することができる。Declarationが使用されている場合は、これはSourceReference 従属関係を構成するので、コンパイラはその従属関係とその性質の両方を記録にとっておく必要がある。返却された値がCirculardependencyまたはErrorであれば、コンパイラは処理を中止し、コンポーネントに対してSetError関数をコールし、値Errorを返却しなければならない。コンパイラは、別のエラーを見つけるために任意的に処理を続行してから中止することもできる。 GetDeclarationへのコールからCompiledが返却されたときは、コンパイラは従来と同じようにソース・テキストの処理を続けることになる。処理の途中でエラーが見つかると、コンパイラはコンポーネントでSetError関数をコールし、値Er rorを返却する。エラーが見つからなければ、コンパイラは値Doneを返却する。コンパイラがインタフェースを処理していたときは、Declarationプロパティの新しい値をストアする。エラーを処理するメソッドコンパイラがコールされてインタフェースまたはインプリメンテーションをコンパイルする前に、エラーがあれば、そのエラーがクリアされる。これは、すべてのエラー・メッセージを最新のものにするために行なわれる。インタフェースとインプリメンテーションの間には組み込まれた従属関係があり、エラーがプロパゲートされることから、インタフェースとインプリメンテーションの両方で同じ構築を行なっているときコンパイラ・エラーが起こることはあり得ない。コンパイラはエラーを出会うと、SetError関数をコールし、エラーの発生箇所とエラーを記述したメッセージを含む、エラーに関する情報をエラーのあるコンポーネントへ送り返す。この情報はErrorsプロパティと、コンポーネントの該当ソース・プロパティ（インタフェースまたはインプリメンテーション）とにストアされる。また、参照がProjectによって維持されているグローバル・エラー・リストにストアされるので、すべてのエラーが都合よくアクセスできるようになっている。エラーは従属するコンポーネントにプロパゲートされるので、これらのコンポーネントをあとでコンパイルしないですむ。これらのコパイルは失敗することが分かっているからである。さらに、構築はエラーが見つかった後も続けられ、それ自体にエラーがないことが明らかであるか、あるいはエラーのあるコンポーネントに従属しているコンポーネントを可能な限り多く、正しく構築することになる。 SetError関数は、コンパイラ４２から送られてきたエラー・メッセージを受け取ると、該当のプロパティ（インタフェースまたはインプリメンテーション）に対応するErrorsプロパティの中にエントリを作成する。また、エラーに対応するプロジェクトのErrorListプロパティの中にもエントリを作成する。このように作成された２つのエントリは同じキーを共有するので、これらは「リンク」されたままになっている。この関数は、プログラム・ソース内のエラーの位置も、「スティッキ・マーカ(sticky marker)」を使用して記録しておくのが代表的であり、このマーカは、あとでユーザが編集を行なうとき同じ文字範囲に付着したままになっている。コンパイラはソース・テキストの処理を正常に完了すると、オブジェクト・コードを生成し、その結果のオブジェクト・コードをオブジェクト・コード・プロパティにストアする。オブジェクトをストアすると、そのオブジェクトは以下で説明するように、増分的にリンクされていく。ここで、コンパイラはコンポーネントのSourceReferenceおよび各SourceRefer enceのClientsプロパティを更新する。例えば、コンポーネントＡのSourceRefer ence内の、例えば、コンポーネントＢへの各参照ごとに、コンポーネントＢのCl ientsプロパティ内のコンポーネントＡへの対応する参照（これは同じ従属関係情報をもっている）が必要になる。コンパイラは、デクラレーションがその以前の値からどのように変化したかを記述した変更(change)を生成する。コンパイラはコンポーネントに対して関数Pr opagateChangeをコールして、計算した値をその関数へ渡す。次に、コンパイラはデクラレーションの新しい値をセットする。関数PropagateChangeはその変更を、コンポーネントのClient List内の各参照の従属関係と突き合わせる。参照されたコンポーネントが変更によって影響を受けたことが、その突合わせで分かり、そのBuildStateがCompileErrorまたはUncertainErrorでないと、その BuildStateはNeedToCompileにセットされる。コンパイラはSetError関数を使用して、種々のフォームの警告メッセージまたは提案を出すことがある。その場合、警告メッセージだけが返されたときは、Co mpile関数は、Doneを返却しているはずである。この警告メッセージはErrorプロパティに追加され、参照がプロジェクトのErrorListプロパティに追加される。しかし、その他の場合は、コンパイラは正常に完了したものと扱われる。該当の BuildStateはCompiledにセットされ、エラーはプロパゲートされない。警告または提案だけが出されたときは、プログラムは完全に、しかも正しく構築されることになる。コンポーネントを条件付きでコンパイルするプロセス関数ConditionallyCompileのフローチャートは図１０Ａと図１０Ｂに示されているが、以下、これらの図を参照して説明する。コンポーネントＡのSourceRefe rences内の各コンポーネントＢはブロック１００１で処理される。すべてのコンポーネントＢがブロック１００２に示すように処理されると、処理はコンポーネントＢに関して完了したことになり、プロセスは図１０Ｂへ移ってコンポーネントＡをコンパイルする。コンポーネントＢのBuildStateがブロック１００３に示すようにBeingCompiledまたはNeedToCompileであれば、コンポーネントのBuildS tateはBeingComipledにセットされ、コンポーネントは機能ブロック１００４でコンパイルされる。Compile関数からは、Done、AbortまたはErrorの値の１つが返却され得る。値Doneがブロック１００５で返却されると、処理はブロック１００１から続行される。返却された値がブロック１００６でAbortであれば、関数は中止され、Abortが機能ブロック１００７で返却される。返却された値がブロック１００８でError であれば、オリジナル・コンポーネントのBuildStateはUncertainErrorにセットされ、関数は中止され、Errorが機能ブロック１００９で返却される。コンポーネントＢのBuildStateがブロック１０１０に示すようにUncertainであれば、Bui ldStateはBeingCompiledにセットされ、コンポーネントは機能ブロック１０１１で条件付きでコンパイルされる。この場合も、ConditionallyCompile関数からDone、AbortまたはErrorの値の１つが返却され得る。値Doneがブロック１００５で返却されたときは、処理はブロック１００１から続行される。Errorがブロック１０１２で返却されたときは、コンポーネントのBuildStateはUncertai nErrorにセットされ、コンポーネントＡはInterfaceCompileListから除去され、 PropagateError関数が機能ブロック１０１４でコールされてから、関数は中止される。Abortがブロック１０１５で返却されたときは、Abortが機能ブロック１００７で返却されてから関数は中止される。次に、図１０Ｂを参照して説明する。すべての参照の処理を終えていれば、すべてのBuildStateはCompiledになっている。しかし、Sourcereferencesの１つがこの時点までの処理の間に変更をコンポーネントにプロパゲートしている可能性があるので、そのBuileStateがBeingCompiledまたはNeedToCompileのどちらかになっていることがある。従って、コンポーネントＡのBuildStateがブロック１０１６で判断される。BuildStateがブロック１０１７に示すようにNeedToCompile であれば、BuildStateはBeingCompiledにセットされ、コンポーネントＡは機能ブロック１０１８でコンパイルされる。コンパイラからは、ErrorまたはDoneのどちらかが返却される可能性がある。Abortが出されることがないのは、すべてのSourceReferencesがこのステージでコンパイルされているからである。Error がブロック１０１９で返却されると、BuildStateはCompileErrorにセットされ、 Errorが機能ブロック１０２０で返却される。Doneがブロック１０２１で返却されると、BuildStateはCompiledにセットされ、Doneが機能ブロック１０２３で返却される。コンポーネントＡのBuildStateがブロック１０２４に示すようにBein gCompiledであれば、BuildStateはCompiledにセットされ、Doneが機能ブロック１０２３で返却される。関数ConditionallyCompileの擬似コードは次のとおりである。エラーを事後処理するメソッドエラーを事後処理するメソッドは構築プロセスの第４ステージである。構築期間にエラーが発生すると、構築の終了時に関数PostProcessErrorsがコールされる。InternalErrorList内の各参照ごとに、参照のBuidStateがCompileErrorであれば、BuildStateはNeedToCompileに変更される。参照のBuildStateがUncertain Errorであれば、BuildStateはCompiledに変更される。 InternalErrorList上のすべての参照が処理されると、リストからすべてのエントリがクリアされる。プログラマの便宜のために、プロジェクトのErrorList がいずれかのエントリを含んでいると、ウィンドウまたはBrowser（ブラウザ）がプロジェクトのErrorListに対してオープンされる。 PostProcessErrors関数の擬似コードは次のとおりである。ＨＯＯＰＳの使用本発明による人間指向オブジェクト・プログラミング・システム(Human Orien ted Object Programming System‐HOOPS)は、新しいプログラムを構築するのか、既存のプログラムを編集するのかに応じて、プロジェクト名または既存のプロジェクト名を入れると、コンピュータ上で始動する。ＨＯＯＰＳが始動すると、ウィンドウがオープンし、図１１に示すものと類似する初期スクリーンが表示される。ＨＯＯＰＳがオープンする初期スクリーンは、プロジェクト・コンポーネントのMembersプロパティとその直属メンバを表示する。初期には直属メンバだけが表示されるが、プロジェクト・コンポーネントから始まるすべてのコンポーネントを表示するために同じウィンドウが使用される。図１１に示す例では、「給与計算(Payroll)」と名づけたプロジェクトがインポートされている。ビュワービュワー(viewer)とは、コンポーネントの特定のプロパティを表示することを目的としたグラフィカル表現である。しかし、そのプロパティを表示する過程では、ビュワーは、他のプロパティからのデータを含む、附属的情報を表示する必要が起こる場合がある。ビュワーは入力と出力をもっている。入力は少なくともコンポーネントとプロパティを指定している。プロパティの情報のサブレンジを指定することも可能である。出力は最低限でもコンポーネントを指定している。プロパティと、プロパティのデータのサブレンジを指定することも可能である。出力は、ユーザのアクションとシステム内のステート変化に応じて、時間の経過と共に変化して行く。ビュワー・リストはビュワー仕様の名前付きリストであり、そこでは各仕様はビュワー名とインプリメンテーション・クラスを定義している。空のビュワー・リストと呼ばれる特殊なビュワー・リストがあり、このリストにはビュワー仕様が入っていない。ビュワー・リスト名は各プロパティと関連づけられている。プロパティは、リスト内で指定されたビュワーのいずれかによって表示することができる。プロパティが空のビュワー・リストと関連づけられているときは、そのプロパティにはビュワーがないので、そのプロパティは表示不能とみなされる。好ましいビュワーは各プロパティと関連づけられている。好ましいビュワーは、プロパティに関連づけられたビュワー・リストに指定されたビュワーの１つでなければならない。好ましいビュワーは、表示目的のために各コンポーネントと関連づけられている。ペインビュワーはペイン(pane)内に表示される。ペインは入力と出力をもっている。入力は最低限でもコンポーネントを指定している。コンポーネントのプロパティと、プロパティのデータのサブレンジを指定することも可能である。出力は最低限でもコンポーネントを指定しており、任意的に、プロパティと、プロパティのデータのサブレンジを指定している。出力は、ユーザのアクションとシステム内のステート変更に応じて、時間の経過と共に変化して行く。ペインは、ビュワーの入力を定め、一般的にはペイン入力からビュワーの入力を派生することによって行う。この派生は、動的にはシステムのステートに基づいて、静的にはペインのインプリメンテーションを変更することにより、ペインごとに異なる。最も単純な派生では、ビュワーの入力はペインの入力と同じになっている。同様に、ペインの出力は、ビュワーのペインの出力から派生される。この派生の性質は、動的にはシステムのステートに基づいて、静的にはペインのインプリメンテーションを変更することにより、ペインごとに異なる。最も単純な派生では、ペインの出力はそのビュワーの出力と同じになっている。ウィンドウペインはウィンドウに表示される。ウィンドウは１つまたは２つ以上のペインに細分化されている。ウィンドウ内のペインのレイアウトと数は、ユーザが動的に制御することができる。好適実施例では、ペイン・スプリッタ・コントロール (pane splitter control)が用意されているので、複数のペインの作成と管理が容易になっている。コントロールは単一のペインを１つまたは複数のペインに分割するために使用される。図１２は本発明によるブラウザ(browser)を示す図である。ＨＯＯＰＳでのすべてのウィンドウはブラウザである。ブラウザは、プロジェクト内の情報を眺めるための一時的表示および編集ツールである。これらは、ウィンドウのクローズ (close)アイコン１２１０をクリックすると、いつでも削除することができる。ブラウザに入っている間に、プロジェクトに行なった変更は自動的にセーブされる。ブラウザはプロジェクト・ルート・コンポーネント(project root componen t)１２００をもち、これはそのオープン時に指定される。コンテナ・コンポーネントの例は１２０２に示されており、選択されたコンポーネントは１２０３に示され、ペイン・プロパティ・ロック１２１１、ペイン・プロパティ・ポップアップ・メニュー・コントロール１２２０および拡大(expand)または縮小(collapse) コントロールは１２０４に示されている。このコントロールを使用すると、ユーザはペインを特定のプロパティにアンカ(anchor)することができる。入力コンポーネントのプロパティ２１３０はペイン１２６０に表示され、各ペーン１２６０は１２６０に示すように、１つのプロパティ・ビュワー１２０５を表示するか、ブランクになっている。新しいペインは、ペインの右上隅のスプリット(split) アイコン１２５０の１つを選択することでブラウザに追加される。ペイン・スプリッタ・コントロール１２５０を使用すると、ユーザはペインを２つのペインに分割し、ペインの大きさを制御することができる。ペインとブラウザ・ズーム・ボックス１２４２、１２４３があり、これを使用すると、ユーザはウィンドウ一杯を埋めるようにペインを動的にズームすることができる。また、これを使用すると、ユーザはズームしたペインを元の寸法に戻すようにアンズームすることができる。水平方向と垂直方向のスクロール・コントロール１２５２も用意されているので、ビュワーの内容をペイン内でスクロールすることができる。ペイン・タイトル・バー１２４１には、ペインに表示されたコンポーネントとプロパティの名前が表示される。ビュワー・メニュー１２５１も用意されているので、ユーザは選択したプロパティを表示するために使用されるビュワーを選択することができる。ビュワー・メニューには、選択したプロパティに関連するビュワー・リストの中で指定された各ビュワーのエントリがある。ペインと共に表示される特定のビュワーを組合わせて定める３つの要因として、コンポーネント、そのコンポーネントのプロパティ、そのプロパティのビュワーの３つがある。コンポーネントはペインの入力から派生される。プロパティもペインの入力から派生され、あるいはユーザによってオーバライドされる。ペイン入力が入力コンポーネントの特定のプロパティを指定していれば、このプロパティは、プロパティの関連ビュワー・リストによって定義された通りに、適格ビュワーのセットを定める。ペイン入力がプロパティを指定していなければ、表示されるプロパティはコンポーネントのデフォルト・プロパティである。ユーザは、ペインを表示し、またはペインを特定のプロパティにアンカするための別の入力コンポーネント・プロパティを選択することにより、選択したプロパティをオーバライドすることができる。アンカされたときは、ペインは入力コンポーネントに関係なく、アンカされたプロパティを表示する。ペインのコンポーネントまたはプロパティが変わると、新しいビュワーがペインに表示される。このビュワーはプロパティのデフォルト・ビュワーであるが、ユーザは、表示されたプロパティに関連するビュワー・リストにリストされたアイテムの１つに、そのビュワーをあとで変更することが可能である。新しいペインが作成されたときは、新しいペインに分割されているペインからデフォルトのワイヤリング(wiring)が作成される。ワイヤリングは、ペイン間を論理的に関係づけたものである。ペインはゼロ個または１個のワイヤ入力と、出力としてゼロ個または１個以上のワイヤをもつことができるが、ワイヤリングはループを作ることができない。コンポーネントがペインで選択されると、その選択はプロジェクト内のコンポーネントへの参照に変換され、そのペインから出たワイヤのデスティネーションへの新しい入力となる。ワイヤリングは、メニュー・バーから選択されたBrowserメニューからTurning on Wiringを選択することによりオンにすることができ、オンになると、図１３に示すように、上から重ね合わされたグラフィック・ワイヤが表示されることになる。このディスプレイを使用すると、新しい入力ロケーションをマウスでクリックダウンしてターゲット・ペインまでドラッグすることにより、２ワイヤ間のワイヤリングを変更することができる。ワイヤはその入力を変換してからワイヤ出力を生成する。コネクションを確立するために使用されるワイヤのインプリメンテーションは種々のものがあり、各インプリメンテーションに異なるタイプの変換を組み込むことができる。最も単純なインプリメンテーションでは、ワイヤの入力は未変更のままワイヤからその出力へ渡される。ペインの出力を任意の数のワイヤに接続すると、単一のペインが任意の数の他のペインの入力を制御するメカニズムが得られる。ユーザはペイン間のコネクションを動的に制御することができ、コネクションはウィンドウ間を結合するように作ることができる。 Members(メンバ)、Clients(クライアント)およびReferences（参照）のように、多くのビュワーでは、コンポーネントはその名前とアイコンで区別することができるが、これらがコンポーネントの種類別に異なっているからである。他のビュワーでは、コンポーネントの名前は、Source（ソース）やImplementation（インプリメンテーション）などのテキストで現われるだけである。コンポーネント階層は、Membersプロパティ・ビュワーでコンテナ・コンポーネントを拡大し、縮小することによりブラウズしていくと、ツリー・ビューが得られる。その例を示したのが図１４である。コンポーネントのサブツリーの１レベルは、コンポーネントの円形トグル・スイッチをクリックすることにより拡大または縮小することができる。アイコンがあれば、そのアイコンをクリックすることにより、あるいはその名前をテキスト・ディスプレイで選択することによってコンポーネントがビュワーで選択されると、グローバル・メニュー・バー上のPropertyメニューは、そのタイプのコンポーネントのプロパティをリストするように調整される。任意のコンポーネントの任意のプロパティは、ビュワーでそのコンポーネントを選択し、次に、Propertyメニューからプロパティを選択することにより表示することができる。これにより、単一のビュワーを収めている新しいブラウザがオープンし、選択したコンポーネントの選択したプロパティが表示される。コンポーネントは、新しいコンポーネントをどこに作成し、どの種類のコンポーネントにするかを指定することにより、MembersまたはInterfaceビュワー内から作成される。新しいコンポーネントのロケーションは、既存のコンポーネントを選択するか、あるいはコンポーネント間に挿入ポイントを置くことにより指定される。どの種類のコンポーネントが作成されるかは、Newビュワー・メニューからどのメニュー・アイテムを選択したかによって決まる。すべての編集は自動的にストアされる。変更されたコンポーネントと、その変更の影響を受けたクライアントだけがコンパイルされる。再コンパイルされたコンポーネントは、Buil d メニューからShowComponents Builtメニュー・アイテムを選択すると表示される。最後の構築以後に変更されたコンポーネントを見るには、BuildメニユーからShow Components Changedを選択する。BuildメニューからBuildを選択すると、プログラムがコンパイルされ、リンクされる。Build & Runメニューはプログラムの実行も行なう。図１５から図１８までは、コンポーネントを編集している途中で表示されるスクリーンの一部を示している。図１５は、"main"と名づけた関数のインプリメンテーションのソース・コードのディスプレイを示している。図１６では、関数"m ain"はnumberDisksを"7"から"9"に変更することにより編集されている。ここで、プログラマが図１７に示すBuildメニューからShow Components Changedを選択すると、図１８に示すものと似たブラウザが表示される。 "Implementation Changes"ビュワー（右側）では、関数"main"が表示され、それが変更されたことを示している。オブジェクト指向リンキング以下では、ＨＯＯＰＳリンキング・メカニズムの重要な特徴を列挙し、そのあとで、好適実施例の実行時環境の背景を説明し、リンキングが行なわれるコンテキストを提供するＨＯＯＰＳデータベースについて説明する。最後に、コンポーネント・リンケージについて説明すると共に、コンポーネントがＨＯＯＰＳコンパイラ、ＨＯＯＰＳデータベース、およびシステム・ローダとどのようなやりとり（インタアクション）をするかについて好適実施例を参照して説明する。リンカの特徴・リンキングはコンパイル・プロセス期間に行なわれる。余分のリンキング・パスはない。・構築期間には、新しくコンパイルされた関数およびデータだけが再リンクされる。・増分開発期間には、一部の共有ライブラリ・スペースとスピードとの間にトレードオフの関係がある。・コンパイラはコンポーネントおよびプロパティとやりとりして、すべてのオブジェクト・コードとその他のリンキング情報を生成する。・プログラムがリリースの準備状態になったとき、"publish"ステップは、増分開発期間に使用された余分のスペースと情報を除去し、アプリケーションをＨＯＯＰＳから切り離す。・リンカは、次のような理由で拡張可能である。１）コンパイラは、リンカが通常では取り扱わない新しいフィックスアップ (fixup)を指定できる。２）loadModuleの新しいクラスが使用できる。・一時中止(suspend)されたプログラムは修正したあとで、再ロードすることなく実行を再開できる。（ある種の変更は再ロードが必要になる。）背景リンカはＨＯＯＰＳの内部で動作して、ローダによって使用されるファイルを作成する。リンカ・メカニズムを理解する上で重要なことは、実行時システムとＨＯＯＰＳの両方がもつ独特な側面を理解することである。実行可能ファイル(executable file)は、他の実行時システムとはまったく異なった仕方で実行時システムとやりとりする。通常は、ローダ・プログラムは実行可能ファイルのフォーマットを理解していなければならない。実行可能ファイルは、プログラムの様々な側面を記述した、公知のフィールドを有している。そのフィールドには、必要なメモリ量、mainのアドレス、再配置情報がロード時に必要であればその情報、および実行可能ファイルにパッケージされているデバッガ情報といったようなものがある。好適実施例の実行時では、ローダは抽象TLoa dModuleクラス・インタフェースを通して実行可能ファイルとやりとりする。TLo adModuleには、すべてのローディング・オペレーションに関するプロトコルが用意されている。例えば、必要メモリ量の指定、メタデータ情報の作成、他の共有ライブラリとのリンクといったオペレーションは、すべてTLoadModuleのメソッドによって行なわれる。このアプローチによると、ロード・モジュールはローディング要求に様々な方法で応じることができる。実行時定義は共有ライブラリを提供するので、クロスライブラリ・コールをロード時に解決することができる。ライブラリはどのメモリ・ロケーションにもロードされることがあるので、すべてのコードは位置から独立しているか、あるいはロード時にパッチしなければならない。位置独立コードであるほかに、他の共有ライブラリへのコールは、ロード時に解決しなければならない。これは、外部ライブラリがメモリのどこに置かれるかを、つまり、相対オフセットをスタチック（静的）リンカが知らないからである。各TLoadModuleクラスはクロスライブラリ・コールを様々な方法で実現できるが、標準的メソッドでは、ロード時にパッチされるリンケージ・エリアを介してジャンプしている。このリンケージ・エリアは、ライブラリ間の間接的ジャンプ・テーブルの働きをする。外部コールはリンケージ・エリアへＪＳＲし、そのあと、リンケージ・エリアはコールされた関数へＪＭＰする。内部コールはコールされた関数へ直接にＪＳＲすることができる。内部コールとクロスライブラリ・コールの例は図１９に示されているが、これは下述する。 f1()1900へのコールは内部コールであるので、ＪＳＲはf1()1910へ直接に移る。f2()1920へのコールはクロスライブラリ・コールであるので、コールはロード時にパッチされて外部リンケージ・エリアへ移る。ＨＯＯＰＳ環境には、リンカのために独特なコンテキストも用意されている。プログラムはコンポーネントのコレクション（集合）として表わされる。各コンポーネントは１組のプロパティが関連づけられている。各コンポーネントのコンパイル期間に、コンパイラはそのコンポーネントに適用可能なプロパティを生成し、ストアする。ＨＯＯＰＳ構築プロセスは、すべてのインタフェース（デクラレーション）がインプリメンテーション（定義）の前にコンパイルされるようにコンポーネントの構築を順序づける。ＨＯＯＰＳのプロジェクトは複数のライブラリ・コンポーネントで構成することができる。すべてのソース・メンバはこれらのライブラリ・コンポーネントの１つのメンバである。各ライブラリ・コンポーネントは共有ライブラリの構築を表わしている。概要増分リンキングをサポートし、最終的アプリケーションを可能な限り小さくし、高速化するために、２種類の異なったロード・モジュールが作成される。開発期間に、ＨＯＯＰＳはTIncrementalLoadModuleを生成し、それに修正を加える。ロード・ファイルTStandardLoadModuleがあり、これはアプリケーションのパブリッシュ時に作成される。好適実施例では、開発期間にコードを作成し、更新するためのアプローチが開示されている。TIncrementalLoadModueをTStandardLoadModuleに変換するためには、余分の"publish"（パブリッシュ）ステップが必要になる。このステップは、各関数またはデータ・アイテムが再配置され、パッチされる点で、通常のリンク・ステップと非常によく似ている。しかし、外部参照はロード時までは解決されない。コンパイラとのやりとりコンパイラはコンポーネントに対するコードを生成すると、そのコードを、オブジェクト・コードをパッチするために使用される１組のフィックスアップと一緒にオブジェクト・コード・プロパティに引き渡す。コンパイルされたコンポーネントはそのオブジェクト・コード・プロパティが埋め込まれている。コンパイラは「オブジェクト・グループ」モデルを使用する。つまり、コンポーネントは複数タイプのオブジェクト・コードで構成することができる。例えば、関数はそれと関連づけられた私有静的データ・エリアを、その静的データ・エリアのデストラクタ・シーケンス(destructor sequence)と一緒にもつことも可能である。静的データ・アイテムはそれと関連づけられたコンストラクタ(constructor)とデストラクタ・シーケンスをもつことにより、それを実行時に初期化することができる。例えば、次のようなコンポーネントがコンパイルされたとする。コンパイラはオブジェクト・コードの２つの断片を生成し、それらをコンポーネントTFoo::Printと関連づける。関数のオブジェクト・コードと、静的変数tim esCalledの４バイト私有データが得られる。これを示すと、次のようになる。オブジェクト・コードと一緒に、コンパイラはコードが再配置されるとき適用すべき異なるフィックスアップを指定する。これらを示すと、次のようになる。 timesCalled @ offset OxOcへの参照 cout @ offset Ox14への参照 ostream::operator<<(const char *)@ offset Ox18への参照 ostream::operator<<(int)@ offset Ox22への参照 ostream::operator<<(const char *)@ offset Ox2cへの参照 timesCalled @ offset Ox34への参照上記に示すように、フィックスアップはこの同一コンポーネント（私有静的変数timesCalled）に関連するオブジェクトの他の断片、または他のコンポーネント（coutなど）への参照を指定することができる。コンパイラがコンポーネントに関連する全セットのオブジェクトとフィックスアップの指定を完了すると、オブジェクト・コード・プロパティはその断片のすべてを再配置し、同時に自身をリンクする。すべてのコンポーネントがコンパイルされたあと実行される第２リンク・パスはない。各コンポーネントがコンパイルされると、コンポーネントも完全にリンクされる。フィックスアップ・リストリンキングは、基本的には、フィックスアップ・リストを繰り返していき、コードを適切な方法でパッチすることである。異種タイプのフィックスアップがクラス階層を通して指定され、各フィックスアップはパッチ値をどのように計算するかを知っている。例えば、ｐｃ相対フィックスアップは、そのロケーションのアドレスと、それが参照するコンポーネントとの差を計算しなければならないことを知っている。絶対フィックスアップは、計算をロード時まで延ばさなければならないことを知っている。リンカは１組のフィックスアップ・クラスを指定しているのに対し、新しいコンパイラは新しいタイプのフィックスアップを指定することができる。図２０は、好適実施例によるフィックスアップ・クラスのセットを示している。アドレス計算各コンポーネントをコンパイルと同時にリンクするとき起こる主要問題は、それが参照する一部のコンポーネントがまだコンパイルされていない可能性があることである。各ソース・コンポーネントは正確に１つのライブラリ・コンポーネントのメンバである。各ライブラリ・コンポーネントと関連づけられているのがロード・モジュール・プロパティである。ロード・モジュール・プロパティは、共有ライブラリに属するすべてのコンポーネントのクリアリング・ハウス(clearing house) の働きをする。フィックスアップはパッチ値を計算する準備状態になると、コンポーネントのアドレスをロード・モジュール・プロパティに問い合わせる。ロード・モジュール・プロパティは、コンポーネントがコンパイルされたかどうかを調べる。コンパイルされていれば、コンポーネントのアドレスを返却する。しかし、コンポーネントがまだコンパイルされていなければ、ロード・モジュール・プロパティはコンポーネントのタイプに応じて２つのアクションを実行する。コンポーネントのタイプがデータ・コンポーネントであれば、定数アドレスを返却するだけである。コンポーネントのタイプが関数コンポーネントであれば、その関数のためのリンケージ・エリアを作成し、そのリンケージ・エリアのアドレスを返却する。オブジェクトの配置上述したように、各コンポーネントはコンパイルされるとき、共有ライブラリ内の位置が割り当てられる。これが行なわれるとき、すべての参照が統一性を保つようにある種の余分の作業が必要になる。コンポーネントがデータ・コンポーネントであれば、その位置がすべてのクライアントに通知される。いくつかのクライアントは初期状態で一時的アドレスとリンクされている可能性があるので、このプロセスはすべてのクライアントをクリーンアップして、クライアントに正しいアドレスを与える。コンポーネントが関数コンポーネントであれば、その関数のためのリンケージ・エリアは新しいアドレスで更新される。以上から理解されるように、この２スタイル・アプローチによると、関数は間接的にアクセスされ、データは直接的にアクセスされる。さらに、余分のスペースが割り振られるので、オブジェクト・コードの将来の更新が同じエリアを使用できる確率が高くなっている。スペースと構築時間との間のトレードオフは、特定の環境に見合うものにすることができる。リンケージ・エリア上述したように、ロード・モジュール・プロパティに関数のアドレスを要求すると、リンケージ・エリアのアドレスが返却される。このことは、すべての関数参照が間接的であることを意味する。図２１は好適実施例によるリンケージ・エリアを示している。以上から理解されるように、内部ライブラリ・コールだけが間接的に内部リンケージ・エリアを通して受け渡しされるが、関数へのクロスライブラリ・コールは間接的にライブラリ・リンケージ・エリアを介して行く（つまり、ライブラリ B,2100,2110,2115,2120内のf2へのコール）。これは、f2がその内部クライアントと外部クライアントを共に更新しなくても位置を変更できるように行なう必要があり、また、関数ポインタなどのアイテムが正しく働くように統一性を保つように行なう必要がある。さらに、すべてのバーチャル（仮想）テーブル関数ポインタは内部リンケージ・エリアも指している。参照されたが、定義されていない関数は、いずれも共通のUnimplemented()関数を指している。すべての未コンパイル関数がUnimplemented()関数を指すようにすると、プログラマにスタブ関数を作成させなくても、部分的なアプリケーションのロードと実行が容易化される。内部リンケージ・エリアをもつことのもう１つの利点は、このエリアがすべての関数に対してボトルネックとなることである。開発期間には、デバッグやパフォーマンス・モニタリングなどの関数トレーシング（追跡）を必要とする作業で内部リンケージ・エリアを使用すると、好都合である。増分リンキングこれまでの説明は、増分リンキングの詳細説明の基礎となるものであった。コンポーネントが再度コンパイルされるとき、新しいコンポーネント・サイズは旧コンポーネント・サイズと比較され、新しいコンポーネントが現在のロケーションに収まるかどうかが判断される。収まれば、そこにストアされ、オブジェクトに関連するフィックスアップ・リストが繰り返される。これで、リンキングが完了する。新しいコンポーネントのオブジェクト・コードを再配置する必要がある時は、旧スペースにガベージ(garbage)のマークが付けられ、新しいオブジェクト・コードは新しいエリアに再配置される。そのあと、フィックスアップ・リストが繰り返される。コンポーネントが関数であれば、リンケージ・エントリが更新される。これで、リンキングが完了する。しかるに、コンポーネントがデータ・アイテムであるときは、コンポーネントはクライアント・リストを繰り返して、そのコンポーネントへの参照を更新しなければならない。これで、リンキングはデータについて完了する。上記から理解されるように、初期リンクと増分リンクはまったく同じステップをたどって行く。増分更新で行なわれる余分のステップは、データ・アイテムがロケーションを変更しなければならないときそれを処理することだけである。オブジェクト・コードのストアオブジェクト・コード・プロパティとロード・モジュール・プロパティは通常のコンポーネント・プロパティであるので、他のすべてのプロパティと同じようにＨＯＯＰＳデータベースにストアされる。しかし、オブジェクト・コード・プロパティはオブジェクト・コードを記述しているが、実際のビットを含んでいない。実際のビットはロード・モジュール・プロパティが所有するセグメントにストアされる。ロード・モジュール・プロパティは４つの異なるセグメントを維持している。これらのセグメントとは、コード、未初期化データ、初期化データ、およびリンケージである。図２２は好適実施例によるオブジェクト・コードのストレージを示している。関数（ここでは、グラフィック・クラス・ボックスのメンバとして示されている）２２００の各々は関連のロード・モジュール・プロパティ２２５０をもち、そこにはグラフィック・オブジェクト２２１０、２２２０、２２３０および２２４０と関連づけられた個々のオブジェクト・コードが収められている。すべてのコードはそのコンパイル時にリンクされ、変更と増分構築のためのサポートが用意されているので、ロード・モジュール・プロパティは各セグメント内に割り振られた、すべてのオブジェクトのマップを維持している。また、余分のスペースを拡張に備えて残しておく。この余分のスペースは一部の仮想メモリ空間を浪費することになるが、バッキング・ストア(backing store)または実メモリを占有することはない。アプリケーションを繰返し変更し、構築する過程で、余分のスペースが使用尽くされたときは、追加のスペースが割り振られるが、影響を受けたセグメントを再配置する必要があり、そのセグメントから出入りするすべての参照を更新する必要がある。さらに、未初期化データ・セグメントには、バッキング・ストアまたは仮想メモリは割り振られない。このエリアはロードされたアプリケーション内で作成され、初期化される。図２３は、好適実施例によるロードされたライブラリを示している。白いセクション２３００、２３１０、２３２０および２３３０は空きスペースを表わしている。４つのセクションは未初期化データ２３４０、初期化データ２３５０、コード２３６０およびリンケージ・エリア２３７０用である。ＨＯＯＰＳでは、セグメントは空間的関係がない。リンキングで使用されるのは、ロードされた関係となるものであって、ＨＯＯＰＳ自体内でもつことができる関係ではない。ローディングプログラムを実行するには、ストリーム化TLoadModuleクラスをローダに渡さなければならない。プログラム構築期間に、ストリーム化TLoadModuleクラスが作成される。これがロードされると、ＨＯＯＰＳで作成されたセグメントをロードする。セグメントはロードされたアプリケーションとＨＯＯＰＳの間で共有される。これには２つの利点がある。１つは、行なう必要のあるコピー量が大幅に低減されることであり、もう１つは、プログラムのロード時に増分更新ができることである。ストリームは最初から最後まで書かなければならない。ローダはストリーム化 TLoadModuleクラスを必要とし、TIncrementalLoadModuleはストリーム化される情報を減少することを試みるからである。このことは、プログラムの大部分の変更では、TIncrementalLoadModuleを再ストリーム化する必要がないことを意味する。TIncrementalLoadModuleはクロスアプリケーション共有メモリ・ヒープの使用を通してＨＯＯＰＳからすべてのマッピング情報を受け取る。その他の場合は、データ・ロケーション、または関数のサイズが変更されると、新しいTIncreme ntalLoadModuleを構築し、ストリーム化することが必要になる。図２４は、好適実施例によるロード・モジュールのメモリ・マップを示す図である。ラベル２４００は未初期化データ・エリア、２４１０は初期化データ・エリア、２４２０はリンケージ・エリア、２４３０はコード・エリアである。これらのエリアは、ロードされたアプリケーション空間２４６０にマッピングされる。アプリケーションはストリーム化ロード・モジュール２４４０を使用して、マップ情報２４５０を含んでいる共有メモリ・エリアをアクセスする。増分更新増分リンキングは、ロードされたライブラリを実行から除かなくても、その変更が行なえるようにする。このためには、ＨＯＯＰＳで行なわれた変更を、実行中のアプリケーションのアドレス空間に反映させる必要がある。これは、ライブラリを共有セグメントとしてロードすることにより処理される。ＨＯＯＰＳ側で行われた変更は実行中のアプリケーション側に反映される。ここで注意すべきことは、ＨＯＯＰＳ側では、セグメントはＨＯＯＰＳデータベースの一部と解釈されるのに対して、アプリケーション側では、そのセグメントはオブジェクト・コードを収めているセグメントとだけ解釈されることである。アクティブ・プログラム変更のモデルは次の通りである。デバッガがまず実行を中止し、変更された関数がコンパイルされ、現在のロケーションに収まる場合であっても異なるロケーションにロードされ、内部リンケージ・エリアが更新され、プログラムが続行される。変更された関数がスタック上でアクティブになっていれば、その関数の次回の呼出しまで旧バージョンが実行される。別の方法では、プログラムを中止するか、あるいはアクティブ関数が変更されていれば、変更されたすべての関数の前にスタック・フレームの上位にあるプログラムを再始動する。プログラムのパブリッシングアプリケーションがパブリッシュされるとき、リンカはすべてのオブジェクト・コードを、データベースの外にあるファイルにコピーする。セグメントが外部ファイルにコピーされると、リンカはすべての関数を再配置し、そのパッチを行なう。さらに、すべての内部コールは直接コールになり、内部リンケージ・エリアが除去される。なお、このステップは基本的に再リンクであるので、コンパイラは介入しない。オブジェクト・コード・プロパティはフィックスアップ作業を個々のフィックスアップ・オブジェクトに委任する。 TFixupから派生したクラスとして、TPCRelativeFixup、TAbsoluteFixup、およびTDataRelativeFixupがある。各フィックスアップ・クラスは、そのタイプに見合うパッチをどのように行なうべきかを理解している。これは、リンカは異なるビットを解釈してどのアクションをとるべきかを判断しなければならない点で、通常のコンパイラとリンカの相互作用とはまったく異なっている。このアプローチのもう１つの利点は、新しいアーキテクチャの新しいコンパイラは、リンカでサポートされないフィックスアップ・タイプについて気にしないで済むことである。参照のタイプリンカは４タイプの参照を処理しなければならない。それは、コードからコードへ(code-to-code)、コードからデータへ(code-to-data)、データからコードへ (data-to-code)、およびデータからデータへ(data-to-data)である。各タイプの参照がどのように処理されるかを（６８Ｋの場合）以下で説明する。コードからコードへ例： Foo()；コンパイラは、コンテキストに応じてこのケースを２通りの方法で処理する。コンパイラはｐｃ相対(pc-relative)でFoo()へ移ることも、Foo()のアドレスをロードし、間接的にレジスタを介することもできる。内部コールはどちらのスタイルも使用できる。リンカは常にリンケージ・エリアのアドレスを報告する。クロスライブラリ・コールはアドレス・ロード・スタイルを使用しなければならない。これらは、ロード時にパッチされる絶対アドレスを使用する。コードからデータへ例： gValue=1；コンパイラはgValueへのｐｃ相対アドレスを生成する。しかし、gValueが異なる共有ライブラリにあるときは、コンパイラは自動的に間接アドレス(indirecti on)を生成する。リンカは間接的参照をキャッチして、ローカル・アドレスを生成し、これはロード時に外部アドレスでパッチされる。データからコードへおよびデータからデータへ例（データからコードへ）： void(*pfn)()=&Foo；例（データからデータへ）： int& pi=i；これらの参照はどちらも絶対アドレスを必要とするので、これらはローディング時に処理される。ロード時のデータ参照のパッチは外部参照のパッチとまったく同じように処理される。図２５は、各タイプの参照でなにが行なわれるかを示している。外部ライブラリがこれらの同じコンポーネントを参照していれば、このライブラリはロード時に複数のGetExportAddress()を受け取る。GetExportAddress()に応答して、ライブラリは関数の内部リンケージ・エリア・アドレスとデータの実アドレスを返却する。これにより、ライブラリがロードされている間に関数を動き回すことができる。図２６、図２７、図２８および図２９は、好適実施例によるリンキングに関連するロジックを示すフローチャートである。図２６は全体的制御の流れを示している。構築オペレーションが前述したように開始されると、処理が端子２６０２から開始され、処理は機能ブロック２６１０へ移り、コンパイルが行なわれる。コンパイルに続いて、コードが端子２６２０に示すように生成される。この処理は機能ブロック２６３０から開始され、そこでオブジェクト・コードが受け取られ、フィックスアップがコンポーネントのために収集される。次に、機能ブロック２６４０で、オブジェクト・コードがストアされ、機能ブロック２６５０で、新たに変更された各々のオブジェクト・モジュールについてフィックスアップが行なわれる。機能ブロック２６４０に関連する処理の詳細は図２７に示され、機能ブロック２６５０の詳細は図２８と図２９に示されている。図２７は、好適実施例によるオブジェクト・コードのストアに関連するロジックを示すフローチャートである。処理は端子２７００から開始され、即時に判定ブロック２７１０へ移り、これが初期ストア・オペレーションであるかどうかが判断される。そうであれば、ストレージが機能ブロック２７４０に示すように割り振られ、エントリが機能ブロック２７４４に示すように、またその詳細を図２９に示すようにマップに作成され、あるいは更新され、オブジェクトが機能ブロック２７５０でストアされる。別のコンポーネントがこのオブジェクトを、そのコンパイル前に参照していれば、更新が行なわれる。これが更新オペレーションであると判定ブロック２７１０で判断されていれば、テストが判定ブロック７２０で行なわれ、コードが既存のロケーションに収まるかどうかが判断される。コードが収まれば、オブジェクトは機能ブロック２７５０でストアされる。コードが収まらなければ、現在のストレージが機能ブロック２７３０で解放され、別のテストが機能ブロック２７６０で行なわれ、データがオブジェクト・データであるかどうかが判断される。そうであれば、ストレージが機能ブロック２７６２で割り振られ、エントリが機能ブロック２７７０に示すように、またその詳細を図２９に示すようにマップに作成され、あるいは更新され、オブジェクトに対するすべてのクライアント・フィックスアップが機能ブロック２７８０に示すように行なわれ、オブジェクトが機能ブロック２７５０に示すようにストアされる。データがオブジェクト・データでないと、判定ブロック２７６０で判断されていれば、ストレージが機能ブロック２７４０で割り振られ、エントリが機能ブロック２７４４に示すように、またその詳細を図２９に示すようにマップに作成され、あるいは更新され、オブジェクトが機能ブロック２７５０に示すようにストアされる。図２８は、フィックスアップの処理および参照ブロックのアドレスの取得に関連する処理の詳細ロジックを示す図である。フィックスアップを行なう処理は、端子２８００から開始され、即時に機能ブロック２８１０へ移り、参照ブロックのアドレスが取得される。次に、判定ブロック２８２０で、テストが行なわれ、絶対フィックスアップが必要であるかどうかが判断される。そうであれば、機能ブロック２８３０で、絶対フィックアップがロード・オペレーションのために記録される。そうでなければ、機能ブロック２８４０に示すように、相対位置を用いてコードをパッチする。参照オブジェクトのアドレス取得処理は機能ブロック２８５０から開始され、即時テストが判定ブロック２８６０で行なわれ、オブジェクトがすでにマップにあるかどうかが判断される。そうであれば、アドレスが機能ブロック２８８０で返却される。そうでなければ、エントリが機能ブロック２７４４に示すように、またその詳細を図２９に示すようにマップに作成され、あるいは更新され、そのあとでアドレスが機能ブロック２８８０で返却される。図２９は、好適実施例に従いエントリをマップに作成し、あるいは更新する詳細ロジックを示すフローチャートである。処理は端子２９００から開始され、即時に判定ブロック２９１０へ移り、オブジェクトがすでにマップにあるかどうかが判断される。オブジェクトがあれば、テストが判定ブロック２９３０で行なわれ、オブジェクトがデータであるかどうかが判断される。オブジェクトがデータであれば、マップが機能ブロック２９４０に示すように新しいアドレスで更新される。そうでなければ、ジャンプ・ロケーションが機能ブロック２９２０に示すように新しいアドレスで更新される。オブジェクトがまだマップになければ、別のテストが判定ブロック２９５０で行なわれ、オブジェクトがデータであるかどうかが判断される。オブジェクトがデータであれば、マップが機能ブロック２９６０に示すように該当のアドレスを使用して作成される。そうでなければ、ジャンプ・ロケーションがあとで定義されるロケーションへジャンプするように、機能ブロック２９８０に示すようにリンケージ・エリアに作成され、エントリがリンケージ・エリア・アドレスをもつマップに入れられる。以上、特定のプログラミング環境における好適実施例を参照して本発明を説明してきたが、この分野の精通者ならば理解されるように、本発明は、請求の範囲に記載の本発明の精神と範囲内で変更を加えて実施することが可能である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ，ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＧＢ，ＨＵ，ＪＰ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＵ，ＬＶ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＫ，ＵＡ，ＵＺ，ＶＮ

Claims

【特許請求の範囲】１．コンピュータ・プログラムをリンクする方法であって、（a）コンピュータ・プログラムをコンポーネントのコレクションとしてモデル化するステップと、（b）コンポーネントをメモリにストアするステップと、（c）ストアされたコンポーネントをアクセスし、各コンポーネントに関連する従属関係を計算して、従属関係のリストを作成するステップと、（d）コンポーネントを前記従属関係リストに基づいてコンパイルして、更新されたオブジェクト・モジュールを生成するステップと、（e）既存の実行可能ファイルを更新することによって前記更新されたオブジェクト・モジュールをリンクするステップとを含むことを特徴とする方法。２．請求項１に記載の方法において、更新されたオブジェクト・モジュールをリンクするステップは、コンポーネントをコンパイルするステップと並行に行なわれることを特徴とする方法。３．請求項１に記載の方法において、更新されたオブジェクト・モジュールだけがリンクされることを特徴とする方法。４．請求項１に記載の方法において、オブジェクト・コードを、コンポーネント・プロパティとしてメモリにストアするステップを含むことを特徴とする方法。５．請求項１に記載の方法において、リンケージ情報を含んでいるデータベースをストアするステップを含むことを特徴とする方法。６．請求項１に記載の方法において、リンキング・オペレーションが完了したときストレージを解放するステップを含むことを特徴とする方法。７．請求項１に記載の方法において、（a）外部リンケージ・エリアをメモリにストアするステップと、（b）外部リンケージ・エリアをロード時に外部コール情報でパッチするステップとを含むことを特徴とする方法。８．コンピュータ・プログラムをリンクする装置であって、（a）コンピュータ・プログラムをコンポーネントのコレクションとしてモデル化する手段と、（b）コンポーネントをメモリにストアする手段と、（c）ストアされたコンポーネントをアクセスし、各コンポーネントに関連する従属関係を計算して従属関係のリストを作成する手段と、（d）コンポーネントを前記従属関係リストに基づいてコンパイルして、更新されたオブジェクト・モジュールを生成する手段と、（e）既存の実行可能ファイルを更新することによって前記更新されたオブジェクト・モジュールをリンクする手段と具備することを特徴とする装置。９．請求項８に記載の装置において、更新されたオブジェクト・モジュールをリンクする手段は、コンポーネントをコンパイルする手段と並行に行なわれることを特徴とする装置。１０．請求項８に記載の装置において、リンクする手段は、更新されたオブジェクト・モジュールだけをリンクすることを特徴とする装置。１１．請求項８に記載の装置において、オブジェクト・コードをコンポーネント・プロパティとしてメモリにストアする手段を含むことを特徴とする装置。１２．請求項８に記載の装置において、リンケージ情報を含んでいるデータベースをストアする手段を含むことを特徴とする装置。１３．請求項８に記載の装置において、リンキング・オペレーションが完了したときストレージを解放する手段を含むことを特徴とする装置。１４．請求項８に記載の装置において、（a）外部リンケージ・エリアをメモリにストアする手段と、（b）外部リンケージ・エリアをロード時に外部コール情報でパッチする手段とを含むことを特徴とする装置。１５．コンピュータ・プログラムをリンクする方法であって、（a）コンピュータ・プログラムをコンポーネントのコレクションとしてモデル化するステップと、（b）コンポーネントをメモリにストアするステップと、（c）ストアされたコンポーネントをアクセスし、各コンポーネントに関連する従属関係を計算して従属関係のリストを作成するステップと、（d）コンポーネントを前記従属関係リストに基づいてコンパイルして、更新されたオブジェクト・モジュールを生成するステップと、（e）既存の実行可能ファイルを更新することによって前記更新されたオブジェクト・モジュールをリンクするステップと、（f）ロードされた実行可能ファイルを更新するステップとを含むことを特徴とする方法。１６．請求項１５に記載の方法において、オブジェクト・モジュールをオブジェクトとしてストアし、実行可能ファイルの自己リンキングを容易にするステップを含むことを特徴とする方法。１７．請求項１５に記載の方法において、オブジェクト・モジュールがストアされるときオブジェクトの自己リンキングを実行するステップを含むことを特徴とする方法。１８．コンピュータ・プログラムをリンクする方法であって、（a）コンピュータ・プログラムをコンポーネントのコレクションとしてモデル化するステップと、（b）コンポーネントをメモリにストアするステップと、（c）ストアされたコンポーネントをアクセスし、各コンポーネントに関連する従属関係を計算して従属関係のリストを作成するステップと、（d）コンポーネントを前記従属関係リストに基づいてコンパイルして、更新されたオブジェクト・モジュールを生成するステップと、（e）既存の実行可能ファイルを更新することによって前記更新されたオブジェクト・モジュールをリンクするステップと、（f）ロードされた実行可能ファイルを更新するステップとを含むことを特徴とする方法。１９．請求項１８に記載の方法において、オブジェクト・モジュールをオブジェクトとしてストアし、実行可能ファイルの自己リンキングを容易にするステップを含むことを特徴とする方法。２０．請求項１８に記載の方法において、オブジェクト・モジュールがストアされるときオブジェクトの自己リンキングを実行するステップを含むことを特徴とする方法。