JPH08512152A

JPH08512152A - インクリメンタル生成システム

Info

Publication number: JPH08512152A
Application number: JP7502762A
Authority: JP
Inventors: マッキナーニィ，ピーター，ジョセフ; ギボンズ，ビル
Original assignee: タリジェントインコーポレイテッド
Priority date: 1993-06-28
Filing date: 1994-01-03
Publication date: 1996-12-17
Also published as: JP4195479B2; EP0688448B1; AU6018794A; JP2007012088A; WO1995000901A1; CA2144874A1; EP0688448A1; CA2144874C; DE69406113D1; CN1105802A; US5758160A

Abstract

(57)【要約】人間指向オブジェクト・プログラミング・システムは、対話的でダイナミックな処理と増分的コンピュータ・プログラム生成を提供する。このシステムは、オペレーション・システムやグラフィック・ユーザ・インターフェース(GUI)を有する大きなアプリケーション・プログラムのような複雑なコンピュータ・プログラムの開発を容易にする。プログラムは、構成要素と呼ばれる単位の集合としてモデル化される。構成要素は、クラスや関数のようなコンパイル可能な単一の言語要素を表わしている。３つの主要な機能は、データベース、コンパイラそして生成機構である。データベースは、構成要素と特性を格納している。コンパイラは、特性のソース・コードをコンパイルすると共に、構成要素に関連する従属性を計算する責任を負っている。生成機構は、構成要素の特性と共に、コンパイラが作成した従属性を、正確におよび効率的に構成要素のコンパイルする順序に対して、生成処理中に使用する。

Description

【発明の詳細な説明】インクリメンタル生成システム発明の分野本発明は、一般に、コンピュータ支援ソフトウェア・エンジニアリング(CASE) 、特にコンピュータ・プログラムを生成するための対話型でダイナミック環境に提供する人間指向オブジェクトプログラミング・システム(HOOPS)に関する。本発明は、オペレーティング・システム(OS)ソフトウェアおよびグラフィック・ユーザ・インターフェース(GUI)を有する多数のアプリケーションのような複合プログラムを開発する際に特に有用である最適インクリメンタル・コンパイラでコンピュータ・プログラムを編集する細粒度ソース・コードをプログラマが、実行することを可能にする。本発明は、通常用いられているオブジェクト指向プログラミング(OOP)言語、C⁺⁺を用いた実施例で説明されているが、この原理は、オブジェクト指向および手続の両方の他のコンピュータ・プログラミング言語に適用可能であり、従来の言語およびOOP言語の両方を使用するプログラムを生成するために使用することができる。従来技術の説明オブジェクト指向プログラミング(OOP)は、ユーザ・フレンドリーなインテリジェント・コンピュータ・ソフトウェアを生成するための好ましい環境である。 OOPの主な要素は、データ遮蔽性(data encapsulation)、継承(inheritance)および多相性(polymorphism)である。これらの要素は、アイコン、マウスカーソルおよびメニューを有するウインドウイング環境によって一般に特徴づけられるグラフィック・ユーザ・インターフェース（GUIを生成するために使用することができる。これらの３つの主な要素はOOP言語に共通であるのに対して、大抵のOOP言語は３つの重要な要素を違ったふうに実装する。 OOP言語の例は、Smalltalk、Object PascalおよびC⁺⁺である。Smalltalk実際に言語以上のものである。すなわち、それはプログラミング環境とするとより正確に特徴づけられる。Smalltalkは、1970年初期にゼロックス社のパロアルト研究センター(PARC)の学習研究グループで開発された。Smalltalkでは、メッセージは、オブジェクト自体で評価するためにオブジェクトに送られる。メッセージは、従来のプログラミング言語の関数呼出しと同様な役割を行っている。プログラマはデータタイプに注意する必要がない。どちらかといえば、プログラマは、メッセージの正しい順序を生成することおよび正しいメッセージを使用することに注意することだけ必要である。Object Pascalは、アップル社のマッキントッシュ（登録商標）コンピュータのために使用される言語である。アップル社は、パスカルの設計者、ニクラウス・ウィルス(Niklaus Wirth)と共同でオブジェクトパスカルを開発した。C⁺⁺は、Ｃの拡張として1983年AT&Tのベル研究所で、ビョーン・ストラウストラップ(Bjarne Stroustrup)によって開発された。主なC⁺⁺ のコンセプトはクラスであり、それは、ユーザ定義タイプである。クラスがオブジェクト指向プログラミング機能を提供している。C⁺⁺モジュールは、Ｃモジュールと互換性があり、現在のＣライブラリがC⁺⁺プログラムとともに使用されることができるように自由にリンクできる。最も広く使用されるオブジェクトに基づくプログラミング言語およびオブジェクト指向プログラミング言語は、ノルウェーのＯ−Ｊ・ダール(O−J.Dahl)、Ｂ・ミーラウ(B.Myhrhaug)およびＫ・ニガード(K.Nygard)によって1960年に開発されたSimulaまでその祖先をさかのぼることができる。OOPの主体に関する他の情報は、1991年、カリフォルニア州レッドウッド市のベンジャミン／カミングス出版社発行のGrady Booch著“Object Orie nted Design with Application”を参照することによって得られる。コンピュータ・プログラムを実行することに関する全処理には、オブジェクト・コードと称される機械で実施可能な形式に、プログラマによって記述されたソース・コードを翻訳すること、そのオブジェクト・コードを実行することが含まれる。翻訳処理は、インタプリタまたはコンパイラによって実行される。インタプリタの場合、プログラムが実行されるときに翻訳が行われるのに対して、コンパイラの場合、プログラムを実行する前に翻訳が行われ、オブジェクト・コードとして記憶される。すなわち、通常のコンパイルおよび実行システムでは、翻訳および実行の２つのフェーズは独立していて、コンパイルが一度だけ行われる。Smalltalkインタプリタのようなインタプリティブ・システムでは、２つのフェーズが順次実行される。そのプログラミング環境の特質が、オブジェクトが実行されるまで特定のレジスタまたはアドレス空間の指定を行うことができないので、Smalltalkためのインタプリタが必要とされる。コンパイラは、３つの部分、すなわち、字句解析部、構文解析部およびコード生成部から構成される。字句解析部への入力は高レベル言語プログラムを表す一連の文字である。この字句解析部は、シーケンスを構文解析部への入力である一連のトークンに分割する。この構文解析部はトークンを命令に分割し、文法規則のデータベースを使用して各命令が文法的に正しいか否かを決定する。正しくないならば、エラーメッセージが発生される。正しいならば、命令は、一連の基本命令に分解され、低レベル言語を発生するためにコード生成部に転送される。コード生成部そのものは、３つの部分、すなわち、中間コード生成、コード最適化およびコード生成に一般に分割される。基本的に、コード生成部は、構文解析部からの出力を受取り、マシン言語コードを生成する。ソフトウェアの開発を支援するために、インクリメンタル・コンパイラが開発され、このコンパイラは、バッチ処理動作において、他のステートメントに対して後で生成されるコードとは独立に、受取られたときの一つのステートメントまたはステートメント・グループに対してコードを生成する。インクリメンタル・コンパイルの長所は、必要なデバッグ処理が全プログラムが記述されるまで後回しされるのではなく、コードが記述ごとに、プログラムの一部分のコードに対してコンパイルおよびテストすることができることにある。しかしながら、伝統的なインクリメンタル・コンパイラは、毎回全モジュールを再処理しなければならない。最適化コンパイラは、多くの場合、非最適化コンパイラの場合よりソース・レベルでデバッグをすることがもっと困難である非常に最適化されたオブジェクト・コードを生成する。この問題は、ルーチンは適切な応答をするようにコンパイルされるけれども、それがその応答を計算する正確な方法がソース・コードで記述された方法と著しく異なっているという事実にある。最適化コンパイラが行うことができるいくつかのことは、最終結果に影響を及ぼさないことが知られているコードまたは変数を除去すること、不変コードをループの中から外に移動させること、共通コードを結合すること、変数がもはや必要としないとき変数に割当たられたレジスタを再使用すること等を含んでいる。したがって、ソースからオブジェクト・コードへのおよびオブジェクト・コードからソースへのマッピングは、これらの最適化のために難しいことがある。変数値を検査することは、変数値が必ずしもルーチン内のいかなるロケーションでも使用可能ではないので、難しいことがある。最適化されたコードの変数値を修正することは、不可能でないとしても、特に困難である。特にvolatile（揮発性）であるとして宣言されていなければ、コンパイラは変数に割当てられた値を“覚えておき”、変数を再読出しをせずに、後でコード中の“覚えている”値を使用する。したがって、その値の変化は誤りのあるプログラム結果を生じることがあった。コンピュータ・プログラムを生成し、テストおよび開発する技術には多くの進歩があったが、公知のソフトウェア・ツールは、しばしば洞察力のある直感を必要とし、今だにプログラマに相当な負担を負わせる。さらに、伝統的なバッチ指向プログラミング・システムは、プログラミングの創造的な活動に対して非常に破壊的である、非常に長い編集−コンパイルーテストのサイクルを提供している。発明の要約したがって、本発明の目的は、より良いプログラマに焦点および集中を増進し、これにより、より大きな生産性を得るコンピュータ・プログラムの生成のための人間指向の対話型でかつダイナミック処理を提供するとともに、コンピュータ・プログラムの生成で必要とされる編集ーコンパイルーテストのサイクルを最小にする自動プログラム生成機構(build mechanism)を提供することにある。本発明によれば、プログラム生成は、プロジェクトと呼ばれるインクリメンタル・プログラム・モデルの相互作用および３つの主要な機能性によって可能となる。プログラムは、属性と呼ばれる名前付けられたデータ項目(named dataite nes)のリストからなる構成要素(component)と呼ばれる意味単位(semanticunit) としてモデル化される。伝統的なシステムで行われるファイルのゆるやかなコレクションとしてプログラムを記憶するよりもむしろ、本発明の人間指向オブジェクトプログラミング・システム(HOOPS)は、このプロジェクトのプログラムについての全ての情報を記憶する。本発明の実施にあたっては、コンピュータ・プログラムは、プロジェクト構成要素および生成可能な構成要素のコレクションとしてモデル化される。それぞれは、単一のコンパイル可能な言語要素を表し、かつ増加性(incrementality)のレベルを規定している。コンピュータ・プログラムのためのモデルを提供する構成要素(component)は、生成処理中はアクセスするために記憶される。この記憶された構成要素は、順次にアクセスされ、構成要素に関連する従属性は、コンパイラを使用してクライアント・リストおよび参照リストを発生させるように計算される。最後に、構成要素は、コンパイラ生成の従属性に加えて構成要素の特性を使用してコンピュータ・プログラムを生成するようにコンパイルされる。本発明の好ましい実施例は、C⁺⁺で記述され、C⁺⁺、Ｃおよびアセンブラでプログラムを生成するために使用される。これらは現在最も使用されている言語である。本発明を使用して生成されるプログラムは、一般にこれらの言語の３つ全てを使用する。したがって、本発明そのものはオブジェクト指向プログラミング言語で記述されているオブジェクト指向プログラムであるが、本発明は、オブジェクト指向プログラミング言語でプログラムを生成することに限定されず、手続言語でプログラムを生成する際にも同様に有用である。さらに、本発明は、C⁺⁺言語に限定されず、他のプログラミング言語で実施されることができ、かつ本発明はこれらの３つの言語への応用に限定されない。すなわち、本発明の教示するところにより、もっと一般的なアプリケーションの人間指向オブジェクト・プログラミング・システムで使用することができる。図面の簡単な説明上述の事項および他の目的、態様および利点は、図面に関して本発明の好ましい実施例の下記の詳細な説明から、よりよく理解されるだろう。第１図は、本発明が実施される、高分解能グラフィック・ディスプレイ装置およびマウスのようなカーソル指示装置をサポートすることができる汎用コンピュータ・システムを示す図である。第２図は、コンピュータシステムの主要な要素をより詳細に示す、第１図に示された汎用コンピュータシステムのブロック図である。第３図は、プログラムを構成する構成要素のコレクションを概念形式で示すブロック図である。第４図は、本発明の主要な機能性を示すブロック図である。第5A図〜第5D図は、一緒にまとめて、BuildStateによる編集変化を登録するための論理のフローチャートである。第６図は、本発明による生成機構(build mechanism)の動作の第１ステージの可能な要素を決定するための論理を示すフローチャートである。第７図は、本発明による生成機構の動作の第２ステージの処理インターフェースの論理を示すフローチャートである。第８図は、本発明による生成機構の動作の第３ステージの処理実行の論理を示すフローチャートである。第９図は、本発明によるコンパイラによって呼出されたGetDeclarations機能の論理を示すフローチャートである。第10A図および第10B図は、一緒にまとめて、条件付きコンパイル機能の論理を示すフローチャートである。本発明の好ましい実施例の詳細な説明発明の概観本発明による人間指向オブジェクトプログラミング・システム(HOOPS)では、構成要素(Component)は、インクリメンタル・コンパイルのための粒度である。すなわち、構成要素は、クラス(Class)または関数(Function)のような単一のコンパイル可能な言語要素を表している。構成要素は、２つの部分、すなわちインターフェース(Interface)と呼ばれる外部から認識できる部分（すなわち公開(pu blic)部分）およびインプリメンテーション(Implementation)（非公開(private) 部分）に分割される特性セットからなる。これは、構成要素(Component)が他の構成要素のインターフェースに従属しているだけのこともあることを意味する。プロジェクト(Project)の全構成要素はツリー構造に組織され、プロジェクト構成要素と呼ばれるルート構成要素であるツリーのベースを有する。３つの主要な機能性は、データベース、コンパイラおよび生成機構である。データベースは、構成要素およびその特性(Property)を、持続的に記憶し、検索する。特性のソース・コードをコンパイルするとともに、コンパイラは、構成要素に関連する従属性を計算する責任を負う。生成機構は、生成処理中要素を正確かつ効率的に一定の順序に配列するために、コンパイラ生成従属性に加えて構成要素の特性を使用する。生成機構は、いつもプログラムに関するグローバルな視野を有する。これは、プログラムが互いに独立してコンパイルされる、ファイルのセットによって表されている伝統的な方法と対照をなしている。伝統的なプログラミング環境に使用されるファイルは、ファイルに含まれる意味ユニットに処理の特定の固定的順序を負わせている。本システムは、変化が、インターフェース(Interface)またはインプリメンテーション(Inplementation)であったかどうかを含む、構成要素の編集変化の経過を自動的に追う。これは、ファイルレベルでのみ追跡する従来のシステムと対照的である。従属性解析は自動的であり、構成要素間の関係に基づいている。このシステムは、従属性が存在する事実ばかりでなく、それがいかなる種類の従属性であるかを記録することをコンパイラが可能にする機構を含んでいる。これにより、再コンパイルが必要であろとなかろうと従属性が存在する全ての構成要素を再コンパイルするよりも、このシステムを有効にするコンパイルをどの構成要素が実際必要とするかを、生成機構がより正確に決定することを可能にしている。従来のコンパイラは、ソフトウェアを生成することを容易にするために、プログラミング環境のソフトウェア構造ツールを使用する。例えば、全てのプログラムを個々のファイル内に記憶されているモジュールに分割することは、従来のプログラム構造では通例である。そして、個々のモジュールは、それぞれ別々に処理される。Makeコマンドは、コンピュータ・プログラムを構成するモジュールを管理および保持するために使用される。すなわち、Make機能は、プログラムのモジュール間の関係の経過を追い、変化がなされた後モジュールを一貫性があるようにするのに必要とされるコマンドのみを発生する。しかしながら、プログラマが、モジュール間の関係（従属性）を規定するMakefile仕様を生成することが必要である。Makefile仕様に対する要求は、プログラマが、いつ従属性が発生するかを決定することができなければならないこと、およびプログラマに同期化従属性を同期化する負担をかけていることを意味している。実際、これは通常、不必要な従属性の存在および必要な従属性の省略の両方を意味する。不必要な従属性の存在および必要な従属性の省略の両者は、コンピュータ・プログラムの生成のエラー源であることが多い。 Make機能と対照的に、本発明による生成機構は、プログラマがMakefile仕様のような仕様を生成しないことで異なっている。この生成機構は、従属性のいかなる予備知識も想定していない。すなわち、実際には、それは、要素の従属性を“ 見いだし”、これらの従属性の経過を追う。これは、生成機構が、予め存在する従属性情報がない状態からプログラムを生成することを意味する。初期の生成動作では、全ての構成要素は変更リストに列挙される。変更リスト上の構成要素のコンパイルが試みられるが、もしそのコンパイルが他の構成要素のコンパイルに従属するならば、第１の構成要素のコンパイルが中断されるかまたは打ち切られるかのいずれかである。そして第２の構成要素のコンパイルが試みられる。このようにコンパイルすることができる構成要素が見つけだされるまで続けられる。次に、コンパイルが中断されたかまたは打切られた構成要素に対して、処理で既に作成された情報を用いて、生成機構が再度働く。生成機構は、全てのインターフェース(Interface)が、全てのインプリメンテーション(Inplementation)の前にコンパイルされるように、コンパイルに指令する。これは、潜在的な相互従属性の数を減少するので、したがって効率を増加する。この生成機構は、構成要素(Component)の処理を制御するために、有限状態機械(finite state machine)の形成を用いている。そして、中断されたかまたは打切られた構成要素のコンパイルを最少にするために、正しい指令を確実にするのに役立てている。変更（構成要素の編集または構成要素の付加あるいは削除）が行われた後の生成動作は、変更リストが変更されたこれらの構成要素のみを含むことを除いて、初期の生成動作と同様であり、再コンパイルを必要とするこれらの構成要素のみを再コンパイルするために、予め開発されたクライアントおよびソース参照リストを使用する。本発明によって実施される機能レベルのインクリメンタル・コンパイルは、通常、プログラムのより小さい部分に対して再生成された後にテストするために、プログラム変更からのターン・アラウンド・タイムを大いに減少する。プログラム・モデルは、インターフェースのための内部処理された様式（宣言 (Declaration)特性と呼ばれる）を記憶および再使用するための方法を提供する。コンパイラは、インターフェース(Interface)の処理された内部様式を記憶する。そして、他の構成要素をコンパイルする時に使用されることにより効率的になる。これは、使用されるためのインターフェースが、使用される毎に全てのファイルに含まれて(include)、コンパイラによって内部様式に再処理される伝統的なシステムとは対照的である。さらに、構成要素および特性のプログラム・モデルは、特定の構成要素と密接に結合した情報を記憶するのに自然な方法を提供する。この情報は、プログラマにより直接または他のツールにより間接のいずれかによって使用することができる。伝統的なシステムでは、このようなデータは、コンパイルの終了で忘れられるかまたはプログラム・ソースとゆるく結合されるのみかのいずれかである。エラー処理は、生成機構が、エラーを有する構成要素に従属する構成要素に対してコンパイルすることを避けることを可能にする。生成機構は、できるだけ多くのプロジェクトを正確に生成する。この双方の生成は、最初の誤りのあるファイルで中止するか、または、続行しても、誤りを含んだファイルを繰り返して処理する伝統的なシステムと対照的である。エラー処理は、エラーである特定の構成要素を間違って処理されないように、警告メッセージがコンパイラによって発生することを可能にする。この処理により、プログラムが警告を発生しているときでさえ正確に生成することを可能にする。ハードウェア・プラットホームここで、図面を参照するに、特に第１図を参照とすると、汎用コンピュータ10 が示されている。コンピュータ10は、システム・ユニット12、陰極線管(CRT)または液晶ディスプレイ(LCD)のような高解像度ディスプレイ装置14を有する。ディスプレイの種類は、それがグラフィック・ユーザ・インターフェース(GUI)のウィンドウ・システムのために必要とされる高解像が可能なディスプレイであるべきであることを除いて重要ではない。コンピュータへのユーザ入力は、キーボード16およびマウス18のようなカーソル指示装置による。マウス18はキーボード 16に接続される。このキーボード16は、次にシステム・ユニット12に接続される。マウス18は、その代りに、システム・ユニット12の専用または直列ポートに接続されてもよい。第１図に示されたタイプの汎用コンピュータの例は、アップル社のマッキントッシュ（アップルコンピュータの登録商標）およびIBM社のPS/V である。他の例として、IBM社のRISCシステム/6000およびサン・マイクロ・システムズ社のコンピュータのような種々のワークステーションが含まれる。第２図は、第１図に示された汎用コンピュータの主要な構成要素を詳細に示している。システム・ユニット12は、中央処理装置(CPU)21、ランダム・アクセス・メモリ(RAM)22およびバス24に接続される読出し専用メモリ(ROM)23を含んでいる。CPU21は、アップル社のマッキントッシュ（登録商標）コンピュータに一般に使用されているモトローラ社の68030および68040マイクロプロセッサまたはIB M社のPS/Vコンピュータに一般に使用されているインテル社の80386および80486 マイクロプロセッサのようないくつかの商用マイクロプロセッサのいずれでもよい。ワークステーションに一般に使用されるRISC(reduced instruction set computers)コンピュータのような他のマイクロプロセッサもまた、使用することができる。ROM24は、CPU21のために基本入出力システム(BIOS) を含む基本マイクロコードを記憶する。コンピュータ・システム10のためのオペレーティング・システム(OS)はROM24に記憶されてもよいし、またはそのOSは初期プログラムロード(IPL)の一部としてRAM22に記憶されてもよい。RAM22はまた、アプリケーション・プログラムの一部およびプログラムの実行で発生される一時的データを記憶するために使用される。バス24は、アップル社のNuBus（登録商標）、IBM社のマイクロチャネル（登録商標）またはISA(industrial standard adapter)あるいはEISA(extended industrial standard adapter)バスのような工業規格の一つでもよい。バス24には、ユーザ・インターフェース・アダプタ25およびI/Oアダプタ26を含む種々の入出力(I/O)アダプタもまた、接続されている。キーボード16はユーザ・インターフェース・アダプタ25に接続され、I/Oアダプタ26は、フロッピーディスク駆動装置27およびハードディスク駆動装置28に接続する。フロッピーディスク駆動装置27は、取外し可能な媒体へのデータおよびプログラムの読出しおよび書込みを可能にするのに対し、ハードディスク駆動装置28は、RAM22にページインおよびページアウトされるデータおよびプログラムを一般に記憶する。ディスプレイ装置14は、ディスプレイ・アダプタ29を介してバス24に接続されている。通信アダプタ30はネットワークへのインターフェースを提供する。集積回路 (IC)チップの形の他のサポート回路（図示せず）は、バス24および／またはCPU2 1に接続されている。これらは、例えば、バス24上のトラフィックを制御するバス・マスタ・チップを含んでいる。あるコンピュータにおいては、バス24は２つのバス、すなわちデータ・バスおよびディスプレイ・バスであり、ディスプレイ・バスは、グラフィック・ユーザ・インターフェースで望ましい高速ディスプレイ動作を可能にしている。定義プログラム本発明の説明で使用されるように、HOOPSプログラムは、「プロジェクト (Project)」と呼ばれる一つの生成不可能な構成要素(non-buidable component) および“生成可能な構成要素(buildable component)”の集合(Collection)からなる。それはまた、生成不可能な構成要素(non-buidablecomponent)を格納することが可能であるが、この説明では、形容詞がない構成要素について言及されている時はいつでも、意味しているものは“生成可能な構成要素(buildable comp onent)”である。生成不可能な構成要素(non-buidable component)は生成動作中コンパイルされない。構成要素(Component) 構成要素(Component)は独特な識別を有し、名前を付けられる。異なる構成要素は、IDと呼ばれるいくらかの様式の独特な識別子(Identifer)によって識別される。いかなる構成要素にも属しないNullIDと呼ばれる、他とは異なるIDがある。構成要素が形成されると、このIDが割当てられ、構成要素の存在中決して変更されない。構成要素が削除されると、その構成要素のIDは決して再使用されない。実際には、IDは通常数字である。構成要素はまた、余白を含まないテキスト・ストリング（文字列）からなる名前を有する。異なる構成要素が異なる名前を有する必要はない。その名前が、ある所与のテキスト・ストリングにマッチする全ての構成要素のリスト（多分、空）を得ることは可能である。構成要素の名前は、構成要素の存在中何回変更してよい。各生成可能な構成要素は特定のコンピュータ言語に関連している。実際には、コンピュータ言語は、通常テキスト・ストリング（文字列）によって識別される。各コンピュータ言語は、その言語の全ての構成要素をコンパイルするときに使用する関連したコンパイラを有する。実際には、所与のコンピュータ言語が一つ以上のコンパイラと関連することは可能である。この場合、構成要素は、言語と特定のコンパイラを識別するための何かの両者を記録しなければならない。特定の言語は、種類(Kind)に対してそれに関連した特定の構成要素の種類(Kin d)のセットおよび特定の特性インプリメンテーションのセットを有する。したがって、ある言語の特定意味構成要素は、必要に応じて異なる方法で構成される。構成要素は「BuildState（生成状態）」を有する。BuildStateは、リスト、Ne verCompile（コンパイル不可）、Compiled（コンパイル済み）、NeedToCompile （要コンパイル）、Uncertain（不確定）、BeingCompiled（コンパイル中）、Co mpileError（コンパイル・エラー）、UncertainError（不確定エラー）からの値である。実際には、これらの値は通常数値である。各構成要素は、「InterfaceB uildState（インターフェース生成状態）」および「ImplementationBuildState （インプリメンテーション生成状態）」と呼ばれる一対のBuildStateを有する。あらゆる構成要素は、それが生成可能(buildable)であれ生成不可能(non-builda ble)あれ、これらのBuildStateの両方を有する。生成不可能構成要素に対しては、これらのBuildStateは、両者共NeverCompile（コンパイル不可）である。 BuildStateはアクセスされても、および変更されてもよい。構成要素のBuildS tateを同一値に再度設定することは可能であり、いかなる影響も引き起こさない。BuildStateを変更することは、同一または異なる構成要素の他の特性のBuildS tateを変更するかまたは例えば、変更リストもしくはエラー・リストのようなあるリストからの参照を付加あるいは削除するような、明確な副作用を有するかもしれない。構成要素は、意味言語構成要素を表すために使用される。これが行われる方法は、モデル化されている特定のコンピュータ言語に依存する。例えば、C⁺⁺では、構成要素によって表される言語構成要素の部分リストは、グローバル・データ (global data)、グローバル関数(global function)、クラス(class)、データメンバー(data member)、メンバー関数(member function)、型定義(typedef)、列挙(enum)、列挙子(enumerator)、マクロ(macro)、ユニオン(union)および構造体 (struct)を含んでいる。一般に、各意味構成要素は関連する異なる種類を有する。特性(Property) 構成要素(Component)は名前を付けられた「特性(Property)」の集合からなる。特性は、構成要素に関連されたいくつかのデータに対応する。実際には、特性名は、名前を識別する番号（このような番号は、ときにはトークンと呼ばれる）によって通常、内部的に表される。いかなる特性にも属しない「NullProperty（ヌル特性）」と呼ばれる他とは異なる特性名がある。所定の特性に関連するデータは、異なる構成要素(Component)に対して異なっている。一つの構成要素に対するある特性のためのデータを変更することは、他の構成要素の同一の特性のためのデータを変更することを意味しない。しかしながら、構成要素の一つの特性の変更により、同一または他の構成要素の他の特性の変更を引き起こすことは可能である。 IDと特性名からなる一対は、リファレンス(Reference)と呼ばれる。リファレンスは、特定の特性データをユニークに識別する。しばしば、リファレンスは、それが構成要素および／またはそれが参照する特性であるかのように漠然と使用される。実際には、リファレンスは、プログラム生成に直接使用されない、データのどのバージョンが参照されているかおよびデータのどの細区分(subsection) が参照されているかを識別する他の情報を通常含んでいる。全ての構成要素は、特性の「名前(Name)」および「コンテナ(Container)」を有しなければならない。名前特性は構成要素名を記憶する。コンテナ特性は特性名がNullProperty（ヌル特性）である単一のリファレンスを含んでいる。ある構成要素から開始して、そのContainer ID（コンテナID）によって参照される構成要素とを連続して置換えて行くと、常に最後にはプロジェクト構成要素(Project component)となる。プロジェクトのコンテナIDはNullID（ヌルID）である。したがって、全ての構成要素は、プロジェクトにあるものとして記述されている。生成特性（また構成要素生成リスト(eomponent built list)と呼ばれる）は、構成要素が生成された順序の最後の生成で、正しくコンパイルされた特性リストを記録する。同一の特性は、多くても一度リスト上に出現するだけである。それは、テストおよびデバッグのために使用される。プロジェクト構成要素(Project Component) プロジェクトは、さらに特性「ChangeList（変更リスト）」および「ErrorLis t（エラー・リスト）」を有する構成要素である。ChangeList（変更リスト）特性はリファレンスのリストである。このリファレンスは、構成要素および最後の生成以来変更された特性を記述する。実際には、ChangeList（変更リスト）は、プログラムを生成する際の効率のために、いくらかの方法で分類された一つ以上のリストによって表されてもよい。ErrorList（エラー・リスト）特性もまた、リファレンスのリストである。これらのリファレンスは、最後のプログラム生成中エラーを有するものとしてリストされた構成要素を記述している。リファレンスは、全てその特性としてエラーを有する。各リファレンスと関連しているのは数値キーである。このキーは、特定のメッセージおよび構成要素の特定特性の特定サブレンジを位置付けるために、特定のエラー特性とともに使用される。生成可能な構成要素(Buildable Component) 生成可能な構成要素はまた、特性である「宣言(Declaration)」、「オブジェクトコード(Objectcode)」、「クライアント(Clients)」、「ソースリファレンス(SourceReferences)」、「エラー(Errors)」を有しなければならないし、特性「インターフェース(Interface)」、「インプリメンテーション(Implementation )」および「メンバー(Members)」を有してもよい。宣言特性は、コンパイラのためのデータキャッシュを表す。これは、構成要素が、例えばコンパイルされてしまう前のように、空でもよい。実際には、記憶された表現は、コンパイラの内部表現とは異なってもよいが、それはコンパイラのシンボル・テーブルのエントリとして考えられることができる。オブジェクト・コード特性は、構成要素のための実行可能なコードを表す。これは、構成要素が、例えばコンパイルされてしまう前のように、または、すかなるオブジェクト・コードもこの構成要素と関連していないため、空でもよい。実際には、それは、通常、ほかの所に記憶される実際のコードを指示するための手段を提供している。クライアントおよびソース・リファレンス特性は、リファレンスおよび「従属性(dependency)」からなるペアの集合である。従属性は変更リストである。変更は、特定の有限ストリング・リストから選択されたテキスト・ストリングとして表することができる。インターフェース特性における使用とは反対に、インプリメンテーション特性のみに対する構成要素に対して、リファレンスを区別するために使用される「パブリック(Public)」と呼ばれる特定の変更がある。リストのｎ番目の変更があるならば、ｎ番目のビットが“１”であり、なければ“０”であるビット・ベクトルとして、従属性は表すことができる。「エラー」特性は複数の三つ組みのリストからなる。各三つ組みは「キー」、特性名およびメッセージからなる。キーは数値識別子である。所定のキーは、特定のエラー特性に一度だけ現れることができる。特性名は、通常インターフェースまたはインプリメンテーションである。メッセージは、テキストおよび／またはグラフィックの一部分である。インターフェースおよびインプリメンテーション特性は、構成要素のソース・テキストを表す特性である。ソース・テキストは、テキストよりもむしろトークンとして記憶され、もし必要とされるならば、異なる様式でアクセスすることができる。これらの特性によって表されるテキストは、プログラミング環境においてそれをマニュアルで編集することによって変更することができる。構成されたフィールドとして記憶されているインターフェース・データが可能であり、それからソース・テキストが必要に応じて再構成することができる。メンバー特性は、リファレンスの集合で（多分、空）、プロジェクト中の各構成要素に対する特性であり、そのコンテナとしてこの構成要素を有している。属性(Attribute) 構成要素は多数の「属性(attribute)」を有する。属性は「真」または「偽」のいずれかである。実際には、属性は、数値“１”および“０”によって表される値、「真」および「偽」で、メモリの単一ビットによって通常表されている。全ての構成要素は属性「IsBuildable」を有する。もしこの属性が「真」ならば、この構成要素は生成可能(buildable)であり、さもなければ、それは生成不可能(non-buildable)である。構成要素は、常に生成不可能かまたは一時的生成不可能（ある一時的条件の動作のために）であってもよい。生成可能な構成要素はまた、属性「IsInline」を有する。この属性が「真」であるとき、構成要素のインプリメンテーションは公開(public)であり、これは、他の構成要素がインプリメンテーションの変化に従属され得ることを意味する。もしそれが偽であるならば、インプリメンテーションの変更により、他の構成要素は決して変更しない。生成可能な構成要素はまた、属性「IsSynthetic」を有する。この属性は、コンパイラによって生成処理中、形成される構成要素に対して「真」である。それは、プログラマによってマニュアルで作成される構成要素に対して「偽」である。合成構成要素(synthetie component)は、コンパイラがデフォルト言語要素に対応する構成要素を形成することを可能にするように設けられている。このデフォルト言語要素は、必要ではあるが、プログラマにより明示的に作成する必要のないものである。実際には、例えば合成された構成要素がマニュアルで編集されるならば、属性IsSyntheticを真から偽へ変更することが可能であるかもしれないが、偽から真への逆の変更は決して可能ではない。合成構成要素はしばしばインターフェースまたはインプリメンテーション特性を有しないが、いかなる場合でも、常にそのInterface BuildStateおよびImplementation Bui1dStateはコンパイル済み(Compiled)である。種類(Kinds) 各構成要素は種類(kind)を有する。種類は、例えば、同一特性または同一言語特有の動作を共有するグループに、構成要素を分類するために使用されるテキスト・ストリングである。大部分の種類は特定のコンピュータ言語に特有であり、意味的に特定言語要素を指定するように使用される。しかしながら、システムによって規定されるいつくかの種類がある。これらは、プロジェクト(Project)、ライブラリ(Library)およびコンテナ(Container)の種類(kind)である。これらの種類は生成不可能な構成要素に適用されるのみである。プロジェクト種類はプロジェクト構成要素の種類である。ライブラリ種類は、共有ライブラリまたはアプリケーションのようなオブジェクトコードの単一の外部ブロックの中にリンクされるべきである構成要素の集合に適用される。コンテナ種類は、編成上の目的のために他の構成要素をグループ化するために適用される。実際には、種類は、通常内部的には数値で表される。プログラム表現第３図は、構成要素セット31から構成されるようなプログラムの概念的表現を提供する。各構成要素は、２つの部分、すなわち、インターフェース(Interface )311と呼ばれる外部から認識できる部分（すなわちpublic：公開）およびインプリメンテーション(Implementation)（private part：非公開部分）312に分割される特性セットからなる。第３図に示されるように、構成要素は、他の構成要素のインターフェースにのみ従属する。プロジェクトにおける全構成要素は、ツリー構造に編成されており、プロジェクト構成要素と呼ばれるルート構成要素32であるツリーのベースを有する。当業者によって理解されるように、構成要素は、必ずしも自分自身を含むエンティティある必要はなく、実コードのための記憶位置を指示するポインタを含んでいてもよい。それにもかかわらず、このツリー構造表現はプログラムの編成を表現するのに有用であり、したがって、同様なツリー構造表現は、後述される複数のユーザ・スクリーンの一つで使用される。第４図は、本発明の３つの主要な機能性を示すブロック図である。これらは、データベース41、コンパイラ42および生成機構(build mechanism)43である。データベース41は、ここで、プロジェクト構成要素411、および生成されるべきであるプログラムをモデル化する生成可能な構成要素412の集合として示される構成要素のセットからなる。コンパイラ42は、データベース41中の構成要素に関連する従属性を計算する。生成機構43は、プログラムを生成するために、コンパイラが生成した従属性と一緒に構成要素の特性を使用する。プログラマは、エディタ44によってプログラムを変更する。エディタは、構成要素を形成および削除し、通常は構成要素をカット、コピー、ペーストおよび移動することができなければならない。メニューからの選択のような他のより構造化された方法が可能であるけれども、エディタは、テキストの直接修正を可能にすることによってインターフェース(Interface)特性およびインプリメンテーション(Implementation)特性のデータを変更することができなければならない。実際には、エディタ44はしばしば、インターフェース特性またはインプリメンテーション特性の各タイプと同じ数のエディタか、あるいはこれらの特性のデータのサブフィールドに対するのと同じ数のエディタからなる可能性もある。編集変更を登録するための方法インクリメンタル生成44に関連するエディタによって実行される、機能の論理を表現しているフローチャートを示す第5A図〜第5D図を参照する。生成可能な非合成構成要素(non-synthetic component)に関しては、BuildStates（生成状態）は、生成処理以外では、値Compiled（コンパイル済み）およびNeedToCompile（コンパイルを要する）に制限される。もしInterface（インターフェース）特性が存在しないならば、InterfaceBuildState（インターフェース生成状態）はCom piled（コンパイル済み）である。Implementation（インプリメンテーション）特性が存在しないならば、ImplementationBuildState（インプリメンテーション生成状態）はCompiled（コンパイル済み）である。第5A図では、種々の編集状態変更が示される。ラベル500で、システムが、CreateComponent（構成要素の形成）、RenameComponent（構成要素のリネーム）、PasteComponent（構成要素のペースト）またはEditInterface（インターフェースの編集）のコマンドを識別するとき、制御は、インターフェース変更を処理するために、機能ブロック510に渡される。変更のための詳細な論理は第5B図に詳述されている。第5B図では、インターフェース生成状態がNeedToCompile（コンパイルを要する）であるかどうかを決定するためにテストが実行される判断ブロック511で処理が開始する。そうであるならば、ラベル514を介して制御が渡され、編集を継続する。これらの動作は編集中に生じ、再生成中には生じない。次の動作は多分他の編集動作である。そうでないならば、機能ブロック512で、インターフェース生成状態がNeedToCompile（コンパイルを要する）とセットされ、したがって、インターフェース変更リストが更新される。それから、機能ブロック513で、インプリメンテーション変更処理およびコンテナ変更処理が終了される。インプリメンテーション変更動作は第5C図に示され、コンテナ変更動作は第5D図に詳述される。第5C図は、変更されたインプリメンテーションと関連した詳細な処理を詳述している。判断ブロック571で、インプリメンテーション生成状態が既にNeedToCom pile（コンパイルを要する）とセットされているかどうかを決定するためにテストが実行される。もしそうであるならば、ラベル572を介して制御が渡され、編集を継続する。もしそうでないならば、機能ブロック573で、インプリメンテーション生成状態がNeedToCompile（コンパイルを要する）とセットされて、インプリメンテーション変更リストが更新される。それから、制御はラベル574を介して元に渡される。第5D図は、コンテナ変更動作と関連した詳細な論理を詳述する。変数が生成可能であるかどうかを決定するために、テストが判断ブロック542で実行される。そうならば、機能ブロック543で、変更されたインターフェースが、第5B図の議論で上記に詳述したような構成要素のコンテナによって、呼出される。それから、制御はラベル544を介して戻される。 Edit Implementation（編集インプリメンテーション）コマンドが第5A図のラベル560で検出されるならば、処理は機能ブロック570で詳述され、第5C図の議論で上記に詳述されたような変更された動作インプリメンテーションを実行する。 Delete Component（削除構成要素）コマンドが第5A図の530で検出されるならば、構成要素Ａのためのコンテナ変更処理は機能ブロック540で示され、かつ第5 D図の議論で詳述されたように開始される。それから、コンテナＡは削除され、制御はラベル550を介して戻される。 Move Component（移動構成要素）コマンドが第5A図の580で検出されるならば、構成要素Ａのためのコンテナ変更処理は機能ブロック590で示され、かつ第5D 図で詳述されたように開始される。それから、構成要素のコンテナは新しいコンテナに等しくセットされ、構成要素Ａのためのインターフェース変更処理は、第 5B図で詳述されるように開始される。最後に、処理はラベル595を介して戻される。生成構成要素を決定するための方法プログラム生成中、プロジェクト構成要素(Project Component)はCompileList （コンパイル・リスト）と呼ばれるリファレンスの非公開リスト(private list) を保持する。InterfaceCompileList（インターフェース・コンパイル・リスト）およびImplementationCompileList（インプリメンテーション・コンパイル・リスト）がある。プロジェクトはまた、InternalErrorList（内部エラー・リスト）と呼ばれるリファレンスの専用リストを保持する。実際には、これらのリストのそれぞれは効率の理由で１つ以上のリストで物理的に表されてもよい。この処理は第６図に示される。機能ブロック601で示されるようなプロジェクトのChangeList（変更リスト）の各リファレンスに関しては、リファレンスはリストの最前部から選択される。リスト上にリファレンスがもうこれ以上はないならば、処理はブロック602で示されるように終了される。リファレンスがブロック603で決定されるようなInterface（インターフェース）であるならば、リファレンスのコピーはInterfaceCompileList（インターフェース・コンパイル・リスト）の中に置かれ、機能AddClient（クライアントの付加）は、処理がブロック6 01で継続される前に機能ブロック604のリファレンスに呼出される。その特性名がInterface（インターフェース）でないならば、その特性名はブロック605で示されているようにImplementation（インプリメンテーション）であり、そのIs Inline属性が「真」かどうかを決定するために判断ブロック606でテストが行われる。もしそうであるならば、リファレンスのコピーはInterfaceCompileList（インターフェース・コンパイル・リスト）に置かれ、機能AddClientクライアントの付加）は、処理がブロック601で継続される前に機能ブロック607のリファレンス上に呼出される。さもなければ、その特性名はImplementation（インプリメンテーション）でなければならないし、かつそのIsInline属性は「偽」でなければならないし、リファレンスの複写は、処理がブロック601で継続される前に機能ブロック608のImplementationCompileList（インプリメンテーション・コンパイル・リスト）上に置かれる。機能CreateCompileList（コンパイルリストの形成）のための擬似コードは次のようになる。パラメータ・リファレンスのクライアントの各リファレンスに対して、機能Ad dClient（クライアントの付加）が、リファレンスを正確に調べ、そのBuildStat e（生成状態）がCompiled（コンパイル済み）であるならば、リファレンスのBui ldState（生成状態）をUncertain（不確定）とセットし、リファレンスの複写を適当なCompileList（コンパイル・リスト）に付加し、リファレンス上にAddClie nt（クライアントの付加）を呼出す。この処理は、ChangeList（変更リスト）の Client Closure（クライアント終了）の形成と呼ばれる。このClient Closure（クライアント終了）は生成の結果として再コンパイルされる必要があるかもしれない構成要素のサブセットを表す。実際には、生成経過のようにコンパイラによって発生された従属性および変更は、Client Closure（クライアント終了）において出来る限り多くの構成要素をコンパイルしなければならないことを回避するために使用される。下記は、AddClient（クライアントの付加）機能のための擬似コードである。インターフェースを処理するための方法これはBuild（生成）処理の第２段階である。InterfaceCompileList（インターフェース・コンパイル・リスト）に関する項目に対する可能なBuildStates（生成状態）は、Compiled（コンパイル済み）、BeingCompiled（コンパイル中）、NeedToCompile（コンパイルを要する）、Uncertain（不確定）、CompileError （コンパイルエラー）またはUncertainError（不確定エラー）である。Interfac eCompileList（インターフェース・コンパイル・リスト）は、それが第７図のフローチャートに示されるように、空になるまで処理される。この処理はブロック 701から入り、ここでリファレンスがInterfaceCompileList（インターフェース・コンパイル・リスト）の最前列から選択される。リストにリファレンスがこれ以上存在しないならば、処理はブロック702で終了する。リファレンスに関連した構成要素(Component)のInterface（インターフェース）のBuildState（生成状態）が、ブロック703で示されるように、Compiled（コンパイル済み）、Compile Error（コンパイル・エラー）またはUncertainError（不確定エラー）であるならば、リファレンスはリストの最前列から取除かれ、処理はブロック701に継続する。リファレンスに関連された構成要素のInterface（インターフェース）のB uildState（生成状態）が、ブロック704で示されるように、BeingCompiled（コンパイル中）またはNeedToCompile（コンパイルを要する）であるならば、構成要素のBuildState（生成状態）は機能ブロック705でBeingCompiled（コンパイル中）とセットされる。したがって、コンパイル機能（コンパイラ42を呼出す）は構成要素のInterface（インターフェース）に対して呼出される。この機能は、A bort（打切り）、Done（実行）およびError（エラー）の一つの値を返す。ブロック706において返された値がAbort（打切り）であるならば、処理はブロック70 1で継続される。ブロック707において返された値がDone（実行）であるならば、構成要素のInterface BuildState（インターフェース生成状態）はCompiled（コンパイル済み）とセットされ、かつリファレンスは、処理がブロック701で継続される前に、ブロック708でリストの最前列から取除かれる。ブロック709において返された値がError（エラー）であるならば、構成要素のInterface BuildStat e（インターフェース生成状態）は CompileError（コンパイル・エラー）とセットされ、このリファレンスはリストの前部から取除かれる。機能PropagateError（エラー伝播）は、処理がブロック 701で継続される前に機能ブロック710で構成要素に呼出される。リファレンスに関連する構成要素のInterface BuildState（インターフェース生成状態）が、ブロック711で決定されるように、Uncertain（不確定）であるならば、構成要素の BuildState（生成状態）は機能ブロック712でBeingCompiled（コンパイル中）にセットされる。したがって、ConditionallyCompile（条件付きコンパイル）機能（コンパイラ42を呼出すか、呼出さないか）は構成要素のInterface（インターフェース）に対して呼出される。この機能はまた、Abort（打切り）、Done（実行）およびError（エラー）の一つの値を返す。返された値がAbort（打切り）であるならば、処理はステップ１で継続される。返された値がブロック713でDone （実行）であるならば、リファレンスは機能ブロック708でリストの最前列から取除かれ、処理は701に継続される。返された値がブロック714でError（エラー）であるならば、リファレンスがリストから取除かれ、機能PropagateError（エラー伝播）は、処理がブロック701に継続される前に、機能ブロック715で構成要素に呼出される。 ProcessInterface（インターフェースの処理）機能ための擬似コードは、次のようになる。機能PropagateError（エラー伝播）は、プロジェクトのInternalErrorList（内部エラー・リスト）に構成要素に対応するリファレンスを加え、構成要素のCl ient（クライアント）リストの全てのリファレンスに対して下記のことを実行する。すなわち、リファレンスのBuildState（生成状態）がCompileError（コンパイルエラー）またはUncertainError（不確定エラー）であるならば、処理は次のリファレンスに対して続ける。リファレンスのBuildState（生成状態）がNeedTo Compile（コンパイルを要する）であるならば、処理はそのBuildState（生成状態）をCompileError（コンパイル・エラー）とセットし、リファレンスにIntern alErrorList（内部エラー・リスト）を加え、次のリファレンスに対して続ける前にリファレンスに対してPropagateError（エラー伝播）を呼出す。リファレンスのBuildState（生成状態）がUncertain（不確定）であるならば、処理はそのB uildState（生成状態）をUncertainErrors（不確定エラー）とセットし、リファレンスにInternalErrorList（内部エラーリスト）を加え、次のリファレンスに対して続ける前にリファレンスに対してPropagateError（エラー伝搬）を呼出す。機能PropagateError（エラー伝播）の擬似コードは次のとおりである。インプリメンテーションを処理するための方法これはBuild（生成）処理の第３段階である。ImplementationCompileList（インプリメンテーション・コンパイル・リスト）の各リファレンスは、第８図のフローチャートに示されるように処理される。この処理はブロック801から入り、リファレンスがImplementationCompileList（インプリメンテーション・コンパイル・リスト）の最前列から選択される。リストにリファレンスがこれ以上ないならば、処理はブロック802で終了する。リファレンスのBuildState（生成状態）が、ブロック803で決定されたようにUncertain（不確定）であるならば、Buil dState（生成状態）は、処理がブロック801に継続される前に、機能ブロック804 でCompiled（コンパイル済み）とセットされる。リファレンスのBuildState（生成状態）が、ブロック805で決定されたようにNeedToCompile（コンパイルを要する）ならば、構成要素は機能ブロック806でコンパイルされる。コンパイラ42から返される値は、Done（実行）およびErrors（エラー）である。返された値がブロック807でDone（実行）であるならば、リファレンスのBuildState（生成状態）は、処理がブロック801に継続される前に、機能ブロック804でCompiled（コンパイル済み）とセットされる。返された値がブロック808でError（エラー）であるならば、リファレンスのBuildState（生成状態）はCompileError（コンパイル・エラー）とセットされ、機能PropagateError（エラー伝播）は、処理がブロック801に継続される前に、機能ブロック809で構成要素に呼出される。リファレンスのBuildState（生成状態）がCompileError（コンパイルエラー）またはUncert ainError（不確定エラー）であるならば、何も実行されない。Implementation（インプリメンテーション）の処理はこの段階では順序に対して独立であることに留意されたい。これは、従属性がInterface（インターフェース）またはImpleme ntation（インプリメンテーション）に対してのみあり得、そのIsInline属性は真であり、これらは処理が完了しているからである。 ProcessImplementation（インプリメンテーションの処理）のための擬似コードは次のとおりである。生成処理をサポートするコンパイラコンパイラ42は、Compile（コンパイル）機能を介して呼出され、これらの２つは同義語として使用されてもよい。コンパイラ42は、ソース・テキストを処理し、可能な外部構成要素の名前を識別する。コンパイラ42は、次に、全ての構成要素に対するリファレンスのリストを得る。コンパイラは、構成要素の種類のような言語特有の知識を使用して、リストからリファレンスを除去する。それから、コンパイラは、テキストで識別された各外部構成要素のために、GetDeclarati on（宣言の取得）と呼ばれる機能を呼出す。Compile（コンパイル）機能は、コンパイラ42を呼出す前に、構成要素に関する存在する全てのエラーをクリアする。これは、エラー特性から全てのエラーメッセージをクリアし、プロジェクトの ErrorList特性から全てのリファレンスも取除く。コンパイラは最初に、第９図のフローチャートによって示される GetDeclaration（宣言の取得）機能を呼出す。GetDeclaration（宣言の取得）機能は、Abort打切り）、Done（実行）、Circulardependency（循環従属性）またはError（エラー）の一つの値を返し、さらに、Declaration（宣言）のデータを返すことができる。この処理はブロック901から入り、各リファレンスがそのBui ldState（生成状態）に対して調べられる。ブロック902で示されるように、処理に対するリファレンスがもうこれ以上はないならば、処理は終了し、リターンが行われる。構成要素のBuildState（生成状態）がCompiled（コンパイル済み）であるならば、この機能は機能ブロック904でDone（実行）を返し、処理がブロック901に継続される前に、記憶されたDeclaration（宣言）データもまた、返される。構成要素のBuildState（生成状態）がブロック905で示されるように、NeedT oCompile（コンパイルを要する）またはUncertain（不確定）であるならば、構成要素に対応するリファレンスは、機能、ブロック906でInterfaceCompileList （インターフェース・コンパイル・リスト）の最前列に加えられ、この機能は、処理がブロック901に継続される前に、機能ブロック907でAbort（打切り）を返す。Declaration（宣言）データはこの場合、返されない。構成要素のBuildStat e（生成状態）がブロック908で示されるようにBeingCompiled（コンパイル中）であるならば、この機能は、処理がブロック901に継続される前に、機能ブロック909でCirculardependency（循環従属性）を返す。Declaration（宣言）データは、この場合には返されない。構成要素のBuildState（生成状態）が、ブロック 910で示されるように、CompileError（コンパイル・エラー）またはUncertain（不確定エラー）であるならば、この機能は、処理がブロック901に継続される前に、機能ブロック911でError（エラー）を返す。また、Declaration宣言）データは返されない。 GetDeclaration（宣言の取得）機能のための擬似コードは、次のようになる。 GetDeclaration（宣言の取得）を呼出した後、コンパイラは次のように続ける。返された値がAbort（打切り）であったならば、コンパイラは処理を終了して、Abort（打切り）値を返さなければならない。別の実装方法としては、コンパイルをコンパイラは中断し返された構成要素をコンパイルした後、再開または放棄することである。これは、コンパイラがリエントラントである必要があるが、前述のような手順に対するいかなる本質的な変更も別に必要としない。返された値がCompiled（コンパイル済み）であったならば、コンパイラは処理を継続することができる。Declaration（宣言）が使用されているならば、これはSourceRef erence（ソース・リファレンス）従属性を構成し、コンパイラは従属性およびその性質の両方について常に追跡しているべきである。返された値がCirculardepe ndency（循環従属性）またはError（エラー）であったならば、コンパイラは処理を終了し、構成要素に関するSetError（エラーのセット）機能を呼出し、値Er ror（エラー）に返さなければならない。コンパイラは、終了前にできるだけ多くのエラーを見つけだすために、処理を任意に継続してもよい。 GetDeclaration（宣言の取得）に対する呼出しがCompiled（コンパイル済み）を返すならば、コンパイラは、従来と同様ソース・テキストを処理し続ける。この処理でエラーにも出会うと、コンパイラは構成要素に対するSetError（エラーのセット）を呼出し、値Error（エラー）を返す。エラーに出会わないなら、コンパイラは値Done（実行）を返す。コンパイラがインターフェースを処理したならば、それはDeclaration（宣言）特性の新しい値を記憶する。エラーを処理する方法コンパイラが、Interface（インターフェース）またはImplementation（インプリメンテーション）をコンパイルするために呼出される前に、全ての存在する Errors（エラー）はクリアされる。これは、全てのエラー・メッセージを更新していることを保証する。Interface（インターフェース）とImplementation（インプリメンテーション）間の組込み従属性およびエラーが伝播されるという事実のために、同一の生成においてInterface（インターフェース）およびImplement ation（インプリメンテーション）の両者のコンパイラ・エラーを得ることは決してできない。コンパイラがエラーに出会うとき、コンパイラは、エラーの位置およびエラーを記述するメッセージを含むエラーについての情報を、誤りのある構成要素に返して伝える機能であるSetError（エラーのセット）を呼出す。この情報は、構成要素のErrors（エラー）特性および適切なソース特性（Interface（インターフェース）またはImplementation（インプリメンテーション））に記憶される。また、リファレンスは、Project（プロジェクト）によって保有されたグローバル・エラー・リストに記憶され、全てのエラーに対する手近なアクセスを可能にしている。エラーが全ての従属する構成要素に伝播するため、構成要素は後でコンパイルされることはない。これは、これらのコンパイルが失敗することが分っているからである。さらに、生成はエラーに出会った後も継続され、それ自身明白にエラーがない構成要素またはエラーを有する構成要素に従属していない構成要素を、できるだけ多く正確に生成する。 SetError（エラーのセット）機能は、コンパイラ42によって渡されたエラー・メッセージを処理し、特性（Interface（インターフェース）またはImplementat ion（インプリメンテーション））に対応する構成要素のエラー特性中のエントリを形成する。それはまた、エラーに対応するプロジェクトのErrorList特性のエントリを形成する。この方法で形成された２つのエントリは、同一のキーを共有をし、それらは「リンク」されている。この機能はまた、その後のユーザ編集の間、同一文字の範囲に添付されたままである“粘着性のあるマーカ”を使用して、プログラム・ソースのエラーの位置を記録する。コンパイラが、首尾よくソース・テキストの処理を完了すると、オブジェクト・コードを生成し、増分的に(incrementally)リンクするようにリンカ機能にオブジェクト・コードを渡す。その代わりに、オブジェクト・コードを生成処理の終了まで記憶し、伝統的な方法でリンクすることもできる。コンパイラは、いま構成要素のSourceReference（ソース・リファレンス）特性および各SourceReference（ソース・リファレンス）のClients（クライアント）特性を更新する。例えば構成要素ＡのSourceReference（ソース・リファレンス）特性における、例えば構成要素Ｂに対する各リファレンスに関しては、構成要素ＢのClients（クライアント）特性における構成要素Ａに対応するリファレンス（同一の従属性情報を有している）である必要がある。コンパイラは、Declaration（宣言）が、その前の値から変更した方法を記述している変化(change)を形成する。コンパイラは、構成要素に対して機能Propag ateChange（変化の伝播）を呼出し、それに計算された変化を渡す。それから、コンパイラはDeclaration（宣言）の新しい値をセットする。機能PropagateChan ge（変化の伝播）は、構成要素のClient List（クライアント・リスト）の各リファレンスの従属性に対して変化を合致させる。この合致が、参照された構成要素は変化によって影響されて、そのBuildState（生成状態）がCompileList（コンパイル・エラー）またはUncertainError（不確定エラー）でないことを示す場合は、そのBuildState（生成状態）はNeedToCompile（コンパイルを要する）とセットされる。コンパイラは、種々の様式の警告メッセージまたは提案を発するために、SetE rror（エラーのセット）機能を使用することができる。この場合、警告メッセージのみが戻されるならば、Compile（コンパイル）機能はDone（実行）を返す。この警告メッセージはErrors（エラー）特性に加えられ、リファレンスはプロジェクトのErrorList特性に加えられる。しかしながら、これ以外の場合、コンパイルは、成功とみなされる。BuildState（生成状態）はCompiled（コンパイル済み）とセットされ、エラーは伝播されない。警告または提案のみが出されるならば、プログラムは、完全にそして正確に生成される。構成要素を条件付きコンパイルするための処理機能ConditionallyCompile（条件付きコンパイル）は、第10A図および第10B図に示されており、これを参照する。構成要素ＡのSourceReference（ソース・リファレンス）における各構成要素Ｂが1001で処理される。全ての構成要素Ｂは、ブロック1002によって示されるように、処理されると、処理は構成要素Ｂについては完了し、処理は、構成要素Ａをコンパイルするために第10B図に進む。構成要素ＢのBuildState（生成状態）が、ブロック1003に示されるように、BeingCom piled（コンパイル中）またはNeedToCompile（コンパイルを要する）ならば、構成要素のBuildState（生成状態）はBeingCompiled（コンパイル中）とセットされ、構成要素は機能ブロック1004でコンパイルされる。Compile（コンパイル）機能は、Done（実行）、Abort（打切り）またはError（エラー）の一つの値を返すことができる。値Done（実行）がブロック1005で返されると、処理はブロック 1001に継続する。返された値が、ブロック1006でAbort（打切り）であるならば、この機能は終了され、Abort（打切り）は機能ブロック1007で返される。返された値がブロック1008でError（エラー）であるならば、原構成要素のBuildState（生成状態）はUncertainError（不確定エラー）とセットされ、この機能は終了され、Error （エラー）が機能ブロック1009で返される。構成要素ＢのBuildState（生成状態）がブロック1010に示されるようにUncertain（不確定）であるならば、BuildSt ate（生成状態）はBeingCompile（コンパイル中）とセットされ、この構成要素は機能ブロック1011で条件付きでコンパイルされる。また、ConditionallyCompile （条件付きコンパイル）は、Done（実行）、Abort（打切り）またはError（エラー）の一つの値を返すことができる。値Done（実行）がブロック1005で返されるならば、処理はブロック1001に継続する。Error（エラー）がブロック1012で返されるならば、構成要素のBuildState（生成状態）がUncertainError（不確定エラー）とセットされ、構成要素ＡはInterfaceCompileList（インターフェース・コンパイル・リスト）から取除かれ、PropagateError（エラーの伝播）機能が、この機能が終了される前に機能ブロック1014で呼出される。Abort（打切り）がブロック1015で返されるならば、Abort（打切り）は、この機能が終了される前に、機能ブロック1007で返される。いま、第10B図を参照すると、全てのリファレンスが処理されたならば、全てC ompiled（コンパイル済み）BuildState（生成状態）を有する。しかしながら、S ourceReference（ソース・リファレンス）の一つが、この処理中の構成要素に対する変化をこの点に伝搬する可能性があるので、それで、そのBuildState（生成状態）は、BeingCompiled（コンパイル中）またはNeedToCompile（コンパイルを要する）のいずれでもよい。したがって、構成要素ＡのBuildState（生成状態）がブロック1016で決定される。BuildState（生成状態）がブロック1017で示されるように、NeedToCompile（コンパイルを要する）ならば、BuildState（生成状態）はBeingCompiled（コンパイル中）とセットされ、構成要素Ａは機能ブロック1018でコンパイルされる。コンパイラは、Error（エラー）またはDone（実行）のいずれかを返すことができる。全てのSourceReference（ソース・リファレンス）はこの段階ではCompiled（コンパイル済み）であるため、Abort（打切り）は決して生じないことに注意されたい。Error（エラー）がブロック1019で返されるならば、BuildState（生成状態）はCompileError（コンパイルエラー）とセットされ、Error（エラー）が機能ブロック1020で返される。Done（実行）がブロック1021で返されるならば、BuildState（生成状態）はCompiled（コンパイル済み）とセットされ、かつDone（実行）が機能ブロック1023で返される。構成要素ＡのBuildState（生成状態）が、ブロック1024に示されるように、BeingCom piled（コンパイル中）であるならば、BuildState（生成状態）はCompiled（コンパイル済み）とセットされ、かつDone（実行）が機能ブロック1023で返される。機能ConditionallyCompile（条件付きコンパイル）のための擬似コードは次のとおりである。エラーを後処理するための方法エラーを後処理するための方法はBuild（生成）処理の第４段階である。どのようなエラーでも生成中に発生したならば、PostProcessEroors（エラーの後処理）は生成の終わりで呼出される。InternalErrorList（内部エラー・リスト）の各リファレンスに関しては、リファレンスのBuildState（生成状態）がCompil eError（コンパイル・エラー）ならば、このBuildState（生成状態）はNeedToCo mpileコンパイルを要する）に変更される。リファレンスのBuildState（生成状態）がUncertainError（不確定エラー）ならば、BuildState（生成状態）はComp iled（コンパイル済み）に変更される。 InternalErrorList（内部エラー・リスト）に関する全てのリファレンスが処理されたとき、このリストの全てのエントリはクリアされる。プログラマのための便宜として、プロジェクトのErrorListがあるエントリを含む場合、ウィンドウまたはBrower（ブラウザ）がプロジェクトのErrorList（プロジェクトのエラーリスト）に対して開かれる。 PostProcessEroors（エラーの後処理）機能のための擬似コードは次のとおりである。本発明は、特定のプログラミング環境で好ましい実施例に関して記載されているが、当業者は、本発明が添付の請求の範囲の精神および範囲内において変更して実施され得ることを理解できるであろう。

【手続補正書】特許法第１８４条の８【提出日】１９９５年７月７日【補正内容】請求の範囲１．複数のコンポーネント(412)からコンピュータ・プログラムをインクレメンタルに構成する方法において、 (a)前記複数のコンポーネントの各々をモデル化し、コンパイルされる言語要素の少なくとも１つとモデル化されたコンポーネントの従属関係を包含し、前記従属関係は前記モデル化されたコンポーネントに関連する少なくとも１つのクライアント・コンポーネントと少なくとも１つのリファレンスとを定義し、前記リファレンスが前記モデル化されたコンポーネントの前記クライアント・コンポーネント使用形態を定義するステップと、 (b)前記リファレンスのリストを形成(701)するステップと、 (c)前記コンピュータ・プログラムが構築されるまで、前記リファレンスのリストに準拠して前記複数のコンポーネントの１つを反復して選択しかつコンパイル(705または712)するステップと、 (d)ステップ(c)の各実行とコンカレント（並列）に、前記１つのコンポーネントがコンパイルされるリファレンスを定める(708,710または715)ステップと、 (e)再びコンカレント（並列）にステップ(c)および(d)を実行する前に現在定められたリファレンス(701)を包含するステップとからなることを特徴とするコンピュータ・プログラムを生成する方法。２．(f)構成要素を生成、変更または削除する編集(603,605,606)ステップと、 (g)編集による構成要素の変更を変更リストに記憶(604,607)するステップとを含む請求の範囲第１項に記載の方法。３．前記各構成要素が、前記変更リスト中の編集による変更に基づいた構成要素の状態を示すBuildState（生成状態）値を有する請求の範囲第２項に記載の方法。４．生成処理(build operation)の可能な構成要素を決定するために、前記変更リストを評価(609)するステップを含む請求の範囲第３項に記載の方法。５．コンパイル・リスト中の各変更リスト項目を記憶(604,607)し、コンパイル・リストに変更リスト項目が追加されるときに変更リスト項目を処理し、変更された構成要素に従属する構成要素を識別し、従属する構成要素をコンパイル・リストに追加するステップを含む請求の範囲第４項に記載の方法。６．Uncertrain（不確定）の値を有する従属する構成要素を付加(905)するステップを含む請求の範囲第５項に記載の方法。７．前記コンパイル・リストに付加される各項目を再帰的に処理(601)するステップを含む請求の範囲第５項に記載の方法。８．各構成要素が、インターフェース(Interface)(311)とよばれる公開(public) 部分およびインプリメンテーション(Implementation)(312)とよばれる非公開(pr ivate)部分に分割される特性セットからなり、構成要素の従属性がインターフェース部分にのみ関連され、従属性リストを保持するステップは、前記構成要素の前記公開部分および非公開部分に対してInterfaceCompileList（インターフェース・コンパイル・リスト）(701)およびImplementationCompileList（インプリメンテーション・コンパイル・リスト）(801)をそれぞれ保持することによって実行される請求の範囲第１項に記載の方法。９．コンパイルするステップが、ImplementationCompileList（インプリメンテーション・コンパイル・リスト）で参照される前記構成要素をコンパイル(806) する前に、最初に前記InterfaceCompileList（インターフェース・コンパイル・リスト）で保持される前記構成要素を最初にコンパイル(705)することによって実行される請求の範囲第８項に記載の方法。 10．構成要素がBuildState（生成状態）値を有し、InterfaceCompileList（インターフェース・コンパイル・リスト）に関する前記BuildState（生成状態）値が、BeingCompiled（コンパイル中）またはNeedToCompile（コンパイルを要する）またはUncertrain（不確定）を含んでおり、InterfaceCompileList（インターフェース・コンパイル・リスト）に関する各リファレンスに対して、前記BuildSta te（生成状態）がBeingCompiled（コンパイル中）またはNeedToCompile（コンパイルを要する）の場合、前記BuildState（生成状態）をBeingCompiled（コンパイル中）とセット(705)し、次に前記構成要素をコンパイルし、前記BuildState （生成状態）がUncertrain（不確定）の場合前記BuildState（生成状態）をBein gCompiled（コンパイル中）とセットし、次に前記構成要素を条件付きでコンパイルするステップを含む請求の範囲第９項に記載の方法。 11．コンパイラが前記構成要素に対してコンパイルを成功した場合、次の構成要素を処理する前に前記構成要素の前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(708)するステップを実行する請求の範囲第10項に記載の方法。 12．コンパイラがAbort（打ち切り）の値を返す(706)場合、次の構成要素を処理する請求の範囲第10項に記載の方法。 13．コンパイラがコンパイルするステップで、Error（エラー）(709)の値を返す場合、前記構成要素の前記BuildState（生成状態）値をCompileError（コンパイル・エラー）とセットし、かつ次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加(710)する請求の範囲第10項に記載の方法。 14．コンパイラが値Error（エラー）を返す場合、前記構成要素の前記BuildStat e（生成状態）値をUncertrainError（不確定エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加 (715)する請求の範囲第10項によるコンピュータ・プログラムを生成する方法。 15．コンパイラが前記構成要素をコンパイルするとき、次の構成要素を処理(701 )する前に前記構成要素の前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(708)するステップを実行するが、コンパイラがAbort（打ち切り）の値を返す場合、前記構成要素の前記BuildState（生成状態）値をCompileE rror（コンパイル・エラー）とセットし、次の構成要素を処理(701)する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加し、コンパイラが値Error（エラー）を返す場合、前記BuildState（生成状態）値をUncertrainE rror（不確定エラー）とセット(710)し、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加する請求の範囲第10項によるコンピュータ・プログラムを生成する方法。 16．ImplementationCompileList（インプリメンテーション・コンパイル・リスト）に関する前記BuildState（生成状態）値が、NeedToCompile（コンパイルを要する）またはUncertrain（不確定）を含み、ImplementationCompileList（インプリメンテーション・コンパイル・リスト）に関する各リファレンスに対して、 (a)前記BuildState（生成状態）値が、NeedToCompile（コンパイルを要する）である場合、前記BuildState（生成状態）をBeingCompiled（コンパイル中）とセットし、つぎに前記構成要素をコンパイル(806)するステップと、 (b)前記BuildState（生成状態）値がUncertrain（不確定）である場合、つぎに前記構成要素を処理する前に前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(804)するステップとを含んでいる請求の範囲第10項に記載の方法。 17．コンパイラがコンパイルするステップで、前記構成要素に対してコンパイルが成功した場合、次の前記構成要素を処理する前に前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(708)するステップをさらに実行する請求の範囲第14項によるコンピュータ・プログラムを生成する方法。 18．コンパイラがコンパイルするステップで、値Error（エラー）を返す場合、前記BuildState（生成状態）値をCompileError（コンパイル・エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加(710)する請求の範囲第14項によるコンピュータ・プログラムを生成する方法。 19．コンパイラが前記構成要素に対してコンパイルが成功した場合、次の前記構成要素を処理する前に前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(705)するステップをさらに実行するが、コンパイラがコンパイルするステップで値Error（エラー）を返す場合、前記構成要素の前記BuildState （生成状態）値をCompileError（コンパイル・エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加(710)する請求の範囲第14項によるコンピュータ・プログラムを生成する方法。 20．前記変更リストの各構成要素に対して、インターフェース部分が変更された場合、前記構成要素は前記InterfaceCompileList（インターフェース・コンパイル・リスト）(708)に付加され、Implementation（インプリメンテーション）部分が変更され、この変更が他の構成要素に影響を及ぼす場合は、前記構成要素は InterfaceCompileList（インターフェース・コンパイル・リスト）に付加(906) され、それ以外の場合は、前記構成要素はImplementationCompileList（インプリメンテーション・コンパイル・リスト）に付加される請求の範囲第14項に記載の方法。 21．コンパイラが前記コンパイル(705)するステップまたは条件付きでコンパイル(712)するステップのいずれかで前記リファレンスがコンパイルに成功した場合、すべてのリファレンスが処理(701)されるまで次のリファレンスを処理していく請求の範囲第19項によるコンピュータ・プログラムを生成する方法。 22．少なくとも１つの名前をコンパイルし検出するステップ(c)による請求の範囲第１項に記載のコンピュータ・プログラムを生成する方法において、さらに (f)宣言(901)のデータベースに問い合わせをしてコンポーネントの宣言の少なくとも１つの名前を決定するステップと、 (g)コンポーネントの宣言の状態を決定(903,910,905または908)するステップとからなることを特徴とするコンピュータ・プログラムを生成する方法。 23．前記状態がCompiled（コンパイル済み）状態を示すならば、前記構成要素の宣言の前記状態を使用することによってコンパイルを継続(903)するステップを含んでいる請求の範囲第22項に記載の方法。 24．Error値（エラー）を返し、前記状態がエラー状態を示すならば、前記構成要素の宣言の現在の構成要素状態の処理を停止(910)するステップを含んでいる請求の範囲第23項に記載の方法。 25．abort（打ち切り）値を返し、かつ前記状態が打ち切り状態を示すならば、前記構成要素の宣言の現在の構成要素状態の処理を停止(905)するステップを含んでいる請求の範囲第22項に記載の方法。 26．構成要素の宣言の少なくとも１つの名前を決定するように宣言のデータベースに問い合わせをするステップが、 (h)前記構成要素の状態がCompiled（コンパイル済み）状態であるかどうかを決定(903)するステップと、 (i)前記状態がコンパイル済みであるならば、前記Compiled（コンパイル済み）宣言および関連するコンパイル(Compile)状態を返す(904)ステップとを含んでいる請求の範囲第22項に記載の方法。 27．前記コンパイル状態がエラーと宣言された場合、エラーのCompile（コンパイル）状態を返すことを含んでいる請求の範囲第26項に記載の方法。 28．(h)前記構成要素の状態がUncertrain（不確定）であるかまたはNeedtocompi le（コンパイルを要する）であるかどうかを決定(910)するステップと、 (i)前記構成要素をコンパイル・リストに関する第一の項目として記憶(906)し、かつabort（うちきり）状態を返すステップとを含んでいる請求の範囲第22項に記載の方法。 29．複数のコンポーネント(412)からコンピュータ・プログラムをインクレメンタルに構成するシステムにおいて、 (a)前記複数のコンポーネントの各々をモデル化し、コンパイルされる言語要素の少なくとも１つとモデル化されたコンポーネントの従属関係を包含し、前記従属関係は前記モデル化されたコンポーネントに関連する少なくとも１つのクライアント・コンポーネントと少なくとも１つのリファレンスとを定義し、前記リファレンスが前記モデル化されたコンポーネントの前記クライアント・コンポーネント使用形態を定義する手段と、 (b)前記リファレンスのリストを形成(701)する手段と、 (c)前記コンピュータ・プログラムが構築されるまで、前記リファレンスのリストに準拠して前記複数のコンポーネントの１つを反復して選択しかつコンパイル(705または712)する手段と、 (d)手段(c)の各実行とコンカレント（並列）に、前記１つのコンポーネントがコンパイルされるリファレンスを定める(708,710または715)手段と、 (e)再びコンカレント（並列）に手段(c)および(d)を実行する前に現在定められたリファレンス(701)を包含する手段とからなることを特徴とするコンピュータ・プログラムを生成するシステム。 30．(f)構成要素を生成し、変更または削除するように編集(603,605,606)する手段と、 (g)変更リストに構成要素における編集による変更を記憶(604,607)する手段とを含む請求の範囲第29項に記載のシステム。 31．前記構成要素が、前記変更リストにおける編集変更に基づいた構成要素状態を示すBuildState（生成状態）値を有する請求の範囲第30項に記載のシステム。 32．生成処理(build operation)の可能な構成要素を決定するために、前記変更リストを評価(609)するための手段を含む請求の範囲第31項に記載のシステム。 33．コンパイル・リスト中の各変更リスト項目を記憶(604,607)し、コンパイル・リストに変更リスト項目が追加されるときに変更リスト項目を処理し、変更された構成要素に従属する構成要素を識別し、従属する構成要素をコンパイル・リストに追加する手段を含む請求の範囲第32項に記載のシステム。 34．Uncertrain（不確定）の値を有する従属構成要素を付加(905)する手段を含む請求の範囲第33項に記載のシステム。 35．前記コンパイル・リストに付加される各項目を再帰的に処理(601)する手段を含む請求の範囲第33項に記載のシステム。 36．各構成要素が、インターフェース(Interface)(311)とよばれる公開(public) 部分およびインプリメンテーション(Implementation)(312)とよばれる非公開(pr ivate)部分に分割される特性セットからなり、構成要素の従属性が前記インターフェース部分にのみ関連され、従属性リストを保持することは、前記構成要素の前記公開部分および非公開部分に対してInterfaceCompileList（インターフェース・コンパイル・リスト）(701)およびImplementationCompileList（インプリメンテーション・コンパイル・リスト）(801)をそれぞれ保持することによって実行される請求の範囲第29項に記載のシステム。

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

Claims

【特許請求の範囲】１．コンピュータ・プログラムを生成する方法において、 (a)コンピュータ・プログラムを構成要素の集合としてモデル化するステップと、 (b)メモリに前記構成要素を記憶するステップと、 (c)前記記憶された構成要素をアクセスし、かつ従属性のリストを発生させるために各構成要素に関連する従属性を計算するステップと、 (d)前記コンピュータ・プログラムを生成するために、前記従属性のリストに基づいて構成要素をコンパイルするステップとからなるコンピュータ・プログラムを生成する方法。２．(a)構成要素を生成、変更または削除する編集するステップと、 (b)編集による構成要素の変更を変更リストに記憶するステップとを含む請求の範囲第１項に記載の方法。３．前記構成要素が、前記変更リスト中の編集による変更に基づいた構成要素の状態を示すBuildState（生成状態）値を有する請求の範囲第２項に記載の方法。４．生成処理(build operation)の可能な構成要素を決定するために、前記変更リストを処理するステップとを含む請求の範囲第３項に記載の方法。５．コンパイル・リスト中の各変更リスト項目を記憶し、コンパイル・リストに変更リスト項目が追加されるときに変更リスト項目を処理し、変更された構成要素に従属する構成要素を識別し、従属する構成要素をコンパイル・リストに追加するステップを含む請求の範囲第４項に記載の方法。６．Uncertain（不確定）の値を有する従属する構成要素を付加するステップとを含む請求の範囲第５項に記載の方法。７．前記コンパイル・リストに付加される各項目を再帰的に処理するステップとを含む請求の範囲第５項に記載の方法。８．各構成要素が、インターフェース(Interface)と呼ばれる公開(public)部分およびインプリメンテーション(Implementation)と呼ばれる非公開(private)部分に分割される特性セットからなり、構成要素の従属性がインターフェース部分にのみ関連され、従属性リストを保持するステップは、前記構成要素の前記公開部分および非公開部分に対してInterfaceCompileList（インターフェース・コンパイル・リスト）およびImplementation（インプリメンテーション・コンパイル・リスト）をそれぞれ保持することによって実行される請求の範囲第１項に記載の方法。９．コンパイルするステップが、ImplementationCompileList（インプリメンテーション・コンパイル・リスト）で参照される前記構成要素をコンパイルする前に、最初に前記ImplementationCompileList（インターフェース・コンパイル・リスト）で参照される前記構成要素を最初にコンパイルすることによって実行される請求の範囲第８項に記載の方法。 10．構成要素がBuildState（生成状態）値を有し、InterfaceCompileList（インターフェース・コンパイル・リスト）に関する前記BuildState（生成状態）値が、BeingCompiled（コンパイル中）、NeedToCompile（コンパイルを要する）またはUncertain（不確定）を含んでおり、InterfaceCompileList（インターフェース・コンパイル・リスト）に関する各リファレンスに対して、前記BuildState（生成状態）がBeingCompiled（コンパイル中）またはNeedToCompile（コンパイルを要する）の場合、前記BuildState（生成状態）をBeingCompiled（コンパイル中）とセットし、次に前記構成要素をコンパイルし、前記BuildState（生成状態）値がUncertain（不確定）の場合、前記BuildState（生成状態）をBeingCompil ed（コンパイル中）とセットし、次に前記構成要素を条件付きでコンパイルするステップを含む請求の範囲第９項に記載の方法。 11．コンパイラが前記構成要素に対してコンパイルを成功した場合、次の構成要素を処理する前に前記構成要素の前記BuildState（生成状態）値をCompiled（コンパイル済み）とセットするステップを実行する請求の範囲第10項に記載の方法。 12．コンパイラがAbort（打切り）の値を返す場合、次の構成要素を処理する請求の範囲第10項に記載の方法。 13．コンパイラがコンパイルするステップで、Error（エラー）の値を返す場合、前記構成要素の前記BuildState（生成状態）値をCompileError（コンパイル・エラー）とセットし、かつ次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加する請求の範囲第10項に記載の方法。 14．コンパイラが値Error（エラー）を返す場合、前記構成要素の前記BuildStat e（生成状態）値をUncertainError（不確定エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加する請求の範囲第10項によるコンピュータ・プログラムを生成する方法。 15．コンパイラが前記構成要素をコンパイルするとき、次の構成要素を処理する前に前記構成要素の前記BuildState（生成状態）値をCompiled（コンパイル済み）とセットするステップを実行するが、コンパイラがAbort（打切り）の値を返す場合、前記構成要素の前記BuildState（生成状態）値をCompileError（コンパイル・エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加し、コンパイラが値Error（エラー）を返す場合、前記構成要素のBuildState（生成状態）値をUncertainError（不確定エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加する請求の範囲第10項によるコンピュータ・プログラムを生成する方法。 16．ImplementationCompileList（インプリメンテーション・コンパイル・リスト）に関する前記BuildState（生成状態）値が、NeedToCompile（コンパイルを要する）またはUncertain（不確定）を含み、ImplementationCompileList（インプリメンテーション・コンパイル・リスト）に関する各リファレンスに対して、 (a)前記BuildState（生成状態）値がNeedToCompile（コンパイルを要する）である場合、前記BuildState（生成状態）をBeingCompiled（コンパイル中）とセットし、次に前記構成要素をコンパイルするステップと、 (b)前記BuildState（生成状態）値がUncertain（不確定）である場合、次の構成要素を処理する前に前記BuildState（生成状態）値をCompiled（コンパイル済み）とセットするステップとを含んでいる請求の範囲第10項に記載の方法。 17．コンパイラがコンパイルするステップで、前記構成要素に対してコンパイルが成功した場合、次の構成要素を処理する前に前記構成要素の前記BuildState（生成状態）値をCompiled（コンパイル済み）とセットするステップをさらに実行する請求の範囲第14項によるコンピュータ・プログラムを生成する方法。 18．コンパイラがコンパイルするステップでError（エラー）の値を返す場合、前記構成要素の前記BuildState（生成状態）値をCompileError（コンパイル・エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加する請求の範囲第14項によるコンピュータ・プログラムを生成する方法。 19．コンパイラが前記構成要素に対してコンパイルを成功した場合、次の構成要素を処理する前に前記構成要素の前記BuildState（生成状態）値をCompiled（コンパイル済み）とセットするステップをさらに実行するが、コンパイラがコンパイルするステップでError（エラー）の値を返す場合、前記構成要素の前記Build State（生成状態）値をCompileError（コンパイル・エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素におけるエラー・リストにリファレンスを付加する請求の範囲第14項によるコンピュータ・プログラムを生成する方法。 20．前記変更リストの各構成要素に対して、Interface（インターフェース）部分が変更された場合、前記構成要素は前記InterfaceCompileList（インターフェース・コンパイルリスト）に付加され、Implementation（インプリメンテーション）部分が変更され、この変更が他の構成要素に影響を及ぼす場合は、前記構成要素はInterfaceCompileList（インターフェース・コンパイル・リスト）に付加され、それ以外の場合は、前記構成要素はImplementationCompileList（インプリメンテーション・コンパイル・リスト）に付加される請求の範囲第14項に記載の方法。 21．コンパイラが前記コンパイルするステップまたは条件付きでコンパイルするステップのいずれかで前記リファレンスをコンパイルを成功した場合、全てのリファレンスが処理されるまで次のリファレンスを処理して行く請求の範囲第19項によるコンピュータ・プログラムを生成する方法。 22．コンピュータ・プログラムを生成する方法において、 (a)コンピュータ・プログラムを構成要素の集合として生成するステップと、 (b)前記構成要素をメモリに記憶するステップと、 (c)前記記憶された構成要素をアクセスし、かつ従属性のリストを発生させるために各構成要素に関連した従属性を計算するステップと、 (d)構成要素をコンパイルし、かつ構成要素の少なくとも一つの名前を検出するステップと、 (e)構成要素の宣言の少なくとも一つの名前を決定するように宣言のデータベースに問合わせをするステップと、 (f)前記構成要素の宣言の状態を決定するステップとからなるコンピュータ・プログラムを生成する方法。 23．前記状態がcompiled（コンパイル済み）状態を示すならば、前記構成要素の宣言の前記状態を使用することによってコンパイルを継続するステップを含んでいる請求の範囲第22項に記載の方法。 24．error（エラー）値を返し、前記状態がエラー状態を示すならば、前記構成要素の宣言の現在の構成要素状態の処理を停止するステップを含んでいる請求の範囲第23項に記載の方法。 25．abort（打切り）値を返し、かつ前記状態が打切り状態を示すならば、前記構成要素の宣言の現在の構成要素状態の処理を停止するステップを含んでいる請求の範囲第22項に記載の方法。 26．構成要素の宣言の少なくとも一つの名前を決定するように宣言のデータベースに問合わせをするステップが、 (a)前記構成要素の状態がcompiled（コンパイル済み）であるかどうかを決定するステップと、 (b)前記状態がコンパイル済みであるならば、前記compiled（コンパイル済み）宣言および関連するコンパイル（compile）状態を返すステップとを含む請求の範囲第22項に記載の方法。 27．前記コンパイル状態がエラーと宣言された場合、エラーのcompile（コンパイル）状態を返すことを含んでいる請求の範囲第26項に記載の方法。 28．(a)前記構成要素の状態がimcertain（不確定）であるかまたはneedtocompil e（コンパイルを要する）であるかどうかを決定するステップと、 (b)前記構成要素をコンパイル・リストに関する第１の項目として記憶し、かつabort（打切り）状態を返すステップとを含んでいる請求の範囲第22項に記載の方法。 29．コンピュータ・プログラムを生成するシステムにおいて、 (a)構成要素の集合としてコンピュータ・プログラムをモデル化する手段と、 (b)メモリに前記構成要素を記憶する手段と、 (c)前記記憶された構成要素をアクセスし、かつ従属性のリストを発生させるために各構成要素と関連した従属性を計算する手段と、 (d)前記コンピュータプログラムを生成するために前記従属性のリストに基づいて構成要素をコンパイルする手段とを備えたコンピュータ・プログラムを生成するシステム。 30．(a)構成要素を生成し、変更または削除するように編集する手段と、 (b)変更リストに構成要素における編集による変更を記憶する手段とを含む請求の範囲第29項に記載のシステム。 31．前記構成要素が、前記変更リストにおける編集変更に基づいた構成要素状態を示すBuildSate（生成状態）値を有する請求の範囲第30項に記載のシステム。 32．生成処理（buildoperation）の可能な構成要素を決定するために、前記変更リストを処理するための手段を含む請求の範囲第31項に記載のシステム。 33．コンパイル・リスト中の各変更リスト項目を記載し、コンパイル・リストに変更リスト項目が追加されるときに変更リスト項目を処理し、変更された構成要素に従属する構成要素を識別し、従属する構成要素をコンパイル・リストに追加する手段を含む請求の範囲第32項に記載のシステム。 34．Uncertain（不確定）の値を有する従属構成要素を付加する手段を含む請求の範囲第33項に記載のシステム。 35．前記コンパイルリストに付加される各項目を再帰的に処理する手段を含む請求の範囲第33項に記載のシステム。 36．各構成要素が、Interface（インターフェース）と呼ばれる公開(bublic)部分およびImplementation（インプリメンテーション）と呼ばれる非公開(private )部分に分割される特性セットからなり、構成要素の従属性は前記Interface（インターフェース）部分にのみ関連し、従属性リストを保持することは、前記構成要素の前記公開部分および非公開部分に対してInterfaceCompileList（インターフェース・コンパイル・リスト）およびImplementationCompileList（インプリメンテーション・コンパイル・リスト）をそれぞれ保持することによって実行される請求の範囲第29項に記載のシステム。