インクリメンタル生成システム
【課題】人間指向オブジェクト・プログラミング・システムは、対話的でダイナミックな処理と増分的コンピュータ・プログラム生成を提供する。
【解決手段】このシステムは、オペレーション・システムやグラフィック・ユーザ・インターフェース(GUI)を有する大きなアプリケーション・プログラムのような複雑なコンピュータ・プログラムの開発を容易にする。プログラムは、構成要素と呼ばれる単位の集合としてモデル化される。構成要素はクラスや関数のようなコンパイル可能な単一の言語要素を表している。３主要機能はデータベース、コンパイラ及び生成機構である。データベースは構成要素と特性を格納している。コンパイラは特性のソース・コードをコンパイルすると共に、構成要素に関連する従属性を計算する役目を負う。生成機構は構成要素の特性とコンパイラ作成従属性とを使用し、生成処理中の構成要素のコンパイルを正確に且つ効率的に順序付ける。
【解決手段】このシステムは、オペレーション・システムやグラフィック・ユーザ・インターフェース(GUI)を有する大きなアプリケーション・プログラムのような複雑なコンピュータ・プログラムの開発を容易にする。プログラムは、構成要素と呼ばれる単位の集合としてモデル化される。構成要素はクラスや関数のようなコンパイル可能な単一の言語要素を表している。３主要機能はデータベース、コンパイラ及び生成機構である。データベースは構成要素と特性を格納している。コンパイラは特性のソース・コードをコンパイルすると共に、構成要素に関連する従属性を計算する役目を負う。生成機構は構成要素の特性とコンパイラ作成従属性とを使用し、生成処理中の構成要素のコンパイルを正確に且つ効率的に順序付ける。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、コンピュータ支援ソフトウェア・エンジニアリング(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 Oriented Design with Application”を参照することによって得られる。
【０００６】
コンピュータ・プログラムを実行することに関する全処理には、オブジェクト・コードと称される機械で実施可能な形式に、プログラマによって記述されたソース・コードを翻訳すること、そのオブジェクト・コードを実行することが含まれる。翻訳処理は、インタプリタまたはコンパイラによって実行される。インタプリタの場合、プログラムが実行されるときに翻訳が行われるのに対して、コンパイラの場合、プログラムを実行する前に翻訳が行われ、オブジェクト・コードとして記憶される。すなわち、通常のコンパイルおよび実行システムでは、翻訳および実行の２つのフェーズは独立していて、コンパイルが一度だけ行われる。Smalltalkインタプリタのようなインタプリティブ・システムでは、２つのフェーズが順次実行される。そのプログラミング環境の特質が、オブジェクトが実行されるまで特定のレジスタまたはアドレス空間の指定を行うことができないので、Smalltalkためのインタプリタが必要とされる。
【０００７】
コンパイラは、３つの部分、すなわち、字句解析部、構文解析部およびコード生成部から構成される。字句解析部への入力は高レベル言語プログラムを表す一連の文字である。この字句解析部は、シーケンスを構文解析部への入力である一連のトークンに分割する。この構文解析部はトークンを命令に分割し、文法規則のデータベースを使用して各命令が文法的に正しいか否かを決定する。正しくないならば、エラー・メッセージが発生される。正しいならば、命令は、一連の基本命令に分解され、低レベル言語を発生するためにコード生成部に転送される。コード生成部そのものは、３つの部分、すなわち、中間コード生成、コード最適化およびコード生成に一般に分割される。基本的に、コード生成部は、構文解析部からの出力を受取り、マシン言語コードを生成する。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ソフトウェアの開発を支援するために、インクリメンタル・コンパイラが開発され、このコンパイラは、バッチ処理動作において、他のステートメントに対して後で生成されるコードとは独立に、受取られたときの一つのステートメントまたはステートメント・グループに対してコードを生成する。インクリメンタル・コンパイルの長所は、必要なデバッグ処理が全プログラムが記述されるまで後回しされるのではなく、コードが記述ごとに、プログラムの一部分のコードに対してコンパイルおよびテストすることができることにある。しかしながら、伝統的なインクリメンタル・コンパイラは、毎回全モジュールを再処理しなければならない。
【０００９】
最適化コンパイラは、多くの場合、非最適化コンパイラの場合よりソース・レベルでデバッグをすることがもっと困難である非常に最適化されたオブジェクト・コードを生成する。この問題は、ルーチンは適切な応答をするようにコンパイルされるけれども、それがその応答を計算する正確な方法がソース・コードで記述された方法と著しく異なっているという事実にある。最適化コンパイラが行うことができるいくつかのことは、最終結果に影響を及ぼさないことが知られているコードまたは変数を除去すること、不変コードをループの中から外に移動させること、共通コードを結合すること、変数がもはや必要としないとき変数に割当たられたレジスタを再使用すること等を含んでいる。したがって、ソースからオブジェクト・コードへのおよびオブジェクト・コードからソースへのマッピングは、これらの最適化のために難しいことがある。変数値を検査することは、変数値が必ずしもルーチン内のいかなるロケーションでも使用可能ではないので、難しいことがある。最適化されたコードの変数値を修正することは、不可能でないとしても、特に困難である。特にvolatile（揮発性）であるとして宣言されていなければ、コンパイラは変数に割当てられた値を“覚えておき”、変数を再読出しをせずに、後でコード中の“覚えている”値を使用する。したがって、その値の変化は誤りのあるプログラム結果を生じることがあった。
【００１０】
コンピュータ・プログラムを生成し、テストおよび開発する技術には多くの進歩があったが、公知のソフトウェア・ツールは、しばしば洞察力のある直感を必要とし、今だにプログラマに相当な負担を負わせる。さらに、伝統的なバッチ指向プログラミング・システムは、プログラミングの創造的な活動に対して非常に破壊的である、非常に長い編集−コンパイル−テストのサイクルを提供している。
【００１１】
したがって、本発明の目的は、プログラマに対してより良く集中し専念することを促進させる処理であって、コンピュータ・プログラムの生成のための人間指向の対話型でかつダイナミック処理を提供すること、これにより、より大きな生産性を得て、コンピュータ・プログラムの生成で必要とされる編集−コンパイル−テストのサイクルを最小にする自動プログラム生成機構(build mechanism)を提供することにある。
【課題を解決するための手段】
【００１２】
本発明によれば、プログラム生成は、プロジェクトと呼ばれるインクリメンタル・プログラム・モデルの相互作用および３つの主要な機能性によって可能となる。プログラムは、特性（property）と呼ばれる名前付けられたデータ項目(named dataitemes)のリストからなる構成要素(component)と呼ばれる意味単位(semanticunit)としてモデル化される。伝統的なシステムで行われるファイルのゆるやかなコレクションとしてプログラムを記憶するよりもむしろ、本発明の人間指向オブジェクトプログラミング・システム(HOOPS)は、このプロジェクト中にプログラムについての全ての情報を記憶する。
【００１３】
本発明の実施にあたっては、コンピュータ・プログラムは、プロジェクト構成要素および生成可能な構成要素のコレクションとしてモデル化される。それぞれは、単一のコンパイル可能な言語要素を表し、かつ増加性(incrementality)のレベルを規定している。コンピュータ・プログラムのためのモデルを提供する構成要素(component)は、生成処理中はアクセスするために記憶される。この記憶された構成要素は、順次にアクセスされ、構成要素に関連する従属性（従属関係）は、コンパイラを使用してクライアント・リストおよび参照（リファレンス）リストを発生させるように計算される。最後に、構成要素は、コンパイラ生成の従属性に加えて構成要素の特性（properties）を使用してコンピュータ・プログラムを生成するようにコンパイルされる。
【００１４】
本発明の好ましい実施例は、C++で記述され、C++、Ｃおよびアセンブラでプログラムを生成するために使用される。これらは現在最も使用されている言語である。本発明を使用して生成されるプログラムは、一般にこれらの言語の３つ全てを使用する。したがって、本発明そのものはオブジェクト指向プログラミング言語で記述されているオブジェクト指向プログラムであるが、本発明は、オブジェクト指向プログラミング言語でプログラムを生成することに限定されず、手続型言語でプログラムを生成する際にも同様に有用である。さらに、本発明は、C++言語に限定されず、他のプログラミング言語で実施されることができ、かつ本発明はこれらの３つの言語への応用に限定されない。すなわち、本発明の教示するところにより、もっと一般的なアプリケーションの人間指向オブジェクト・プログラミング・システムで使用することができる。
【００１５】
上述の事項および他の目的、態様および利点は、図面に関して本発明の好ましい実施例の下記の詳細な説明から、よりよく理解されるだろう。
【発明を実施するための最良の形態】
【００１６】
（発明の概観）
本発明による人間指向オブジェクトプログラミング・システム(HOOPS)では、構成要素(Component)は、インクリメンタル・コンパイルのための粒度である。すなわち、構成要素は、クラス(Class)または関数(Function)のような単一のコンパイル可能な言語要素を表している。構成要素は、２つの部分、すなわちインターフェース(Interface)と呼ばれる外部から認識できる部分（すなわち公開(public)部分）およびインプリメンテーション(Implementation)（非公開(private)部分）に分割される特性セットからなる。これは、構成要素(Component)が他の構成要素のインターフェースに従属しているだけのこともあることを意味する。プロジェクト(Project)の全構成要素はツリー構造に組織され、プロジェクト構成要素と呼ばれるルート構成要素であるツリーのベースを有する。
【００１７】
３つの主要な機能性は、データベース、コンパイラおよび生成機構である。データベースは、構成要素およびその特性(Property)を、持続的に記憶し、検索する。特性のソース・コードをコンパイルするとともに、コンパイラは、構成要素に関連する従属性を計算する責任を負う。生成機構は、生成処理中、構成要素のコンパイル処理を正確かつ効率的に一定の順序に配列するために、コンパイラ生成従属性に加えて構成要素の特性を使用する。生成機構は、いつもプログラムに関するグローバルな視野を有する。これは、プログラムが互いに独立してコンパイルされる、ファイルのセットによって表されている伝統的な方法と対照をなしている。伝統的なプログラミング環境に使用されるファイルは、ファイルに含まれる意味ユニットに処理の特定の固定的順序を負わせている。
【００１８】
本システムは、編集変更（editing change）が、インターフェース(Interface)にあるのか、またはインプリメンテーション(Inplementation)にあるのかどうかを含む、構成要素の編集変更（editing change）の経過を自動的に追う。これは、ファイルレベルでのみ追跡する従来のシステムと対照的である。従属性解析は自動的であり、構成要素間の関係に基づいている。このシステムは、従属性が存在する事実ばかりでなく、それがいかなる種類の従属性であるかを記録することをコンパイラが可能にする機構を含んでいる。これにより、生成（組立）機構が、どの構成要素が実際にコンパイルを必要としているかをより正確に決定して、再コンパイルが必要であろうとなかろうと従属性が存在する全ての構成要素を再コンパイルするよりも、このシステムを効率的にすることを可能にしている。
【００１９】
従来のコンパイラは、ソフトウェアを生成することを容易にするために、プログラミング環境のソフトウェア構造ツールを使用する。例えば、全てのプログラムを個々のファイル内に記憶されているモジュールに分割することは、従来のプログラム構造では通例である。そして、個々のモジュールは、それぞれ別々に処理される。Makeコマンドは、コンピュータ・プログラムを構成するモジュールを管理および保持するために使用される。すなわち、Make機能は、プログラムのモジュール間の関係の経過を追い、変化がなされた後モジュールを一貫性があるようにするのに必要とされるコマンドのみを発生する。しかしながら、プログラマが、モジュール間の関係（従属性）を規定するMakefile仕様を生成することが必要である。Makefile仕様に対する要求は、プログラマが、いつ従属性が発生するかを決定することができなければならないこと、およびプログラマに同期化従属性を同期化する負担をかけていることを意味している。実際、これは通常、不必要な従属性の存在および必要な従属性の省略の両方を意味する。不必要な従属性の存在および必要な従属性の省略の両者は、コンピュータ・プログラムの生成におけるエラー源であることが多い。
【００２０】
Make機能と対照的に、本発明による生成機構は、プログラマがMakefile仕様のような仕様を生成しないと言う点で異なっている。この生成機構は、従属性のいかなる予備知識も想定していない。すなわち、実際には、それは、要素の従属性を“見いだし”、これらの従属性の経過を追う。これは、生成機構が、予め存在する従属性情報がない場合に、最初からプログラムを生成することを意味する。初期の生成動作では、全ての構成要素は変更リストに列挙される。変更リスト上の構成要素のコンパイルが試みられるが、もしそのコンパイルが他の構成要素のコンパイルに従属するならば、第１の構成要素のコンパイルが中断されるかまたは打ち切られるかのいずれかである。そして第２の構成要素のコンパイルが試みられる。このようにコンパイルすることができる構成要素が見つけだされるまで続けられる。次に、コンパイルが中断されたかまたは打切られた構成要素に対して、処理で既に作成された情報を用いて、生成機構が再度働く。
【００２１】
生成機構は、全てのインターフェース(Interface)が、全てのインプリメンテーション (Inplementation)の前にコンパイルされるように、コンパイルを順序付ける。これは、潜在的な相互従属性の数を減少させるので、したがって効率を増加する。この生成機構は、構成要素(Component)の処理を制御するために、有限状態機械(finite state machine)のフォームを用いている。そして、中断されたかまたは打切られた構成要素のコンパイルを最少にするために、正しい順序付け（ordering）を確実にするのに役立てている。
【００２２】
変更（構成要素の編集または構成要素の付加あるいは削除）が行われた後の生成動作は、変更リストが変更されたこれらの構成要素のみを含むことを除いて、初期の生成動作と同様であり、再コンパイルを必要とするこれらの構成要素のみを再コンパイルするために、生成機構は予め開発されたクライアントおよびソース参照リストを使用する。本発明によって実施される機能レベルのインクリメンタル・コンパイルは、通常、プログラムのより小さい部分が再生成されることになるので、プログラム変更からのテストまでのターン・アラウンド・タイムを大いに減少する。
【００２３】
プログラム・モデルは、インターフェースのための内部処理された様式（宣言(Declaration)特性と呼ばれる）を記憶および再使用するための方法を提供する。コンパイラは、他の構成要素をコンパイルする時に効率的に使用されるように、インターフェース(Interface)の処理された内部様式（form）を記憶する。そして、になる。これは、使用されるインターフェースが、使用される全てのファイルに含まれて(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マイクロプロセッサまたはIBM社のPS/Vコンピュータに一般に使用されているインテル社の80386および80486マイクロプロセッサのようないくつかの商用マイクロプロセッサのいずれでもよい。ワークステーションに一般に使用されるRISC(reducedinstruction 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および／またはCPU21に接続されている。これらは、例えば、バス24上のトラフィックを制御するバス・マスタ・チップを含んでいる。あるコンピュータにおいては、バス24は２つのバス、すなわちデータ・バスおよびディスプレイ・バスであり、ディスプレイ・バスは、グラフィック・ユーザ・インターフェースで望ましい高速ディスプレイ動作を可能にしている。
【００２８】
定義
プログラム
本発明の説明で使用されるように、HOOPSプログラムは、「プロジェクト(Project)」と呼ばれる一つの生成不可能な構成要素(non-buidable component)および“生成可能な構成要素(buildable component)”の集合(Collection)からなる。それはまた、生成不可能な構成要素(non-buidablecomponent)を格納することが可能であるが、この説明では、形容詞がない構成要素について言及されている時はいつでも、意味しているものは“生成可能な構成要素(buildable component)”である。生成不可能な構成要素(non-buidable component)は生成動作中コンパイルされない。
【００２９】
構成要素(Component)
構成要素(Component)は独特な識別を有し、名前を付けられる。異なる構成要素は、IDと呼ばれるいくらかの様式の独特な識別子(Identifer)によって識別される。いかなる構成要素にも属しないNullIDと呼ばれる、他とは異なるIDがある。構成要素が形成されると、このIDが割当てられ、構成要素の存在中決して変更されない。構成要素が削除されると、その構成要素のIDは決して再使用されない。実際には、IDは通常数字である。
【００３０】
構成要素はまた、余白を含まないテキスト・ストリング（文字列）からなる名前を有する。異なる構成要素が異なる名前を有する必要はない。その名前が、ある所与のテキスト・ストリングにマッチする全ての構成要素のリスト（多分、空）を得ることは可能である。構成要素の名前は、構成要素の存在中何回変更してよい。
【００３１】
各生成可能な構成要素は特定のコンピュータ言語に関連している。実際には、コンピュータ言語は、通常テキスト・ストリング（文字列）によって識別される。各コンピュータ言語は、それに関連付けられたコンパイラを有し、そのコンパイラは、その言語の全ての構成要素をコンパイルするときに使用される。実際には、所与のコンピュータ言語が一つ以上のコンパイラと関連付けられることは可能である。この場合、構成要素は、言語と特定のコンパイラを識別するための方法をともに記録しなければならない。
【００３２】
特定の言語は、それに関連した特定の構成要素の種類(Kind)からなる特定セットおよびインプリメンテーション特性の特定セットを有し、それらは全ての種類は異なっている。したがって、ある言語の特定意味構成要素は、必要に応じて異なる方法で構成される。
【００３３】
構成要素は「BuildState（生成状態）」を有する。BuildStateは、NeverCompile（コンパイル不可）、Compiled（コンパイル済み）、NeedToCompile（要コンパイル）、Uncertain（不確定）、BeingCompiled（コンパイル中）、CompileError（コンパイル・エラー）、UncertainError（不確定エラー）のリストからの値である。実際には、これらの値は通常数値である。各構成要素は、「InterfaceBuildState（インターフェース生成状態）」および「ImplementationBuildState（インプリメンテーション生成状態）」と呼ばれる一対のBuildStateを有する。あらゆる構成要素は、それが生成可能(buildable)であれ生成不可能(non-buildable)あれ、これらのBuildStateの両方を有する。生成不可能構成要素に対しては、これらのBuildStateは、両者共NeverCompile（コンパイル不可）である。
【００３４】
BuildStateはアクセスされても、および変更されてもよい。構成要素のBuildStateを同一値に再度設定することは可能であり、いかなる影響も引き起こさない。BuildStateを変更することは、同一または異なる構成要素の他の特性のBuildStateを変更するかまたは例えば、変更リストもしくはエラー・リストのようなあるリストからの参照（リファレンス）を付加あるいは削除するような、明確な副作用を有するかもしれない。
【００３５】
構成要素は、意味言語構成要素を表すために使用される。これが行われる方法は、モデル化されている特定のコンピュータ言語に依存する。例えば、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）である。したがって、全ての構成要素は、プロジェクトにあるものとして記述されている。
【００４０】
生成特性（また構成要素生成リスト(component built list)と呼ばれる）は、構成要素が生成された順序の最後の生成で、正しくコンパイルされた特性リストを記録する。同一の特性は、多くても一度リスト上に出現するだけである。それは、テストおよびデバッグのために使用される。
【００４１】
プロジェクト構成要素(Project Component)
プロジェクトは、さらに特性「ChangeList（変更リスト）」および「ErrorList（エラー・リスト）」を有する構成要素である。ChangeList（変更リスト）特性はリファレンスのリストである。このリファレンスは、構成要素および最後の生成以来変更された特性を記述する。実際には、ChangeList（変更リスト）は、プログラムを生成する際の効率のために、いくらかの方法で分類された一つ以上のリストによって表されてもよい。ErrorList（エラー・リスト）特性もまた、リファレンスのリストである。これらのリファレンスは、最後のプログラム生成中エラーを有するものとしてリストされた構成要素を記述している。リファレンスは、全てその特性としてエラーを有する。各リファレンスと関連しているのは数値で表されたキーである。このキーは、特定のメッセージおよび構成要素の特定された特性の特定サブレンジの位置を突きとめるために、特定のエラー特性とともに使用される。
【００４２】
生成可能な構成要素(Buildable Component)
生成可能な構成要素はまた、特性である「宣言(Declaration)」、「オブジェクト・コード(Objectcode)」、「クライアント(Clients)」、「ソース・リファレンス(SourceReferences)」、「エラー(Errors)」を有しなければならないし、特性「インターフェース(Interface)」、「インプリメンテーション(Implementation)」および「メンバー(Members)」を有してもよい。
【００４３】
宣言特性は、コンパイラのためのデータキャッシュを表す。これは、構成要素が、例えばコンパイルされてしまう前、空でもよい。実際には、記憶された表現は、コンパイラの内部表現とは異なってもよいが、それはコンパイラのシンボル・テーブルのエントリとして考えられることができる。
【００４４】
オブジェクト・コード特性は、構成要素のための実行可能なコードを表す。これは、構成要素が、例えばコンパイルされてしまう前、または、いかなるオブジェクト・コードもこの構成要素と関連していない場合、空でもよい。実際には、それは、通常、ほかの所に記憶される実際のコードを指示するための手段を提供している。
【００４５】
クライアントおよびソース・リファレンス特性は、リファレンスおよび「従属性(dependency)」からなるペアの集合である。従属性は変更リストである。変更は、特定の有限ストリング・リストから選択されたテキスト・ストリングとして表することができる。インターフェース特性における使用とは反対に、インプリメンテーション特性のみに対する構成要素に対して、リファレンスを区別するために使用される「パブリック(Public)」と呼ばれる特定の変更がある。リストのｎ番目の変更があるならば、ｎ番目のビットが“１”であり、なければ“０”であるビット・ベクトルとして、従属性は表すことができる。
【００４６】
「エラー」特性は複数の三つ組みのリストからなる。各三つ組みは「キー」、特性名およびメッセージからなる。キーは数値識別子である。所定のキーは、特定のエラー特性に一度だけ現れることができる。特性名は、通常インターフェースまたはインプリメンテーションである。メッセージは、テキストおよび／またはグラフィックの一部分である。
インターフェースおよびインプリメンテーション特性は、構成要素のソース・テキストを表す特性である。ソース・テキストは、テキストよりもむしろトークンとして記憶され、もし必要とされるならば、異なる様式でアクセスすることができる。これらの特性によって表されるテキストは、プログラミング環境においてそれをマニュアルで編集することによって変更することができる。インターフェース・データは、それからソース・テキストが必要に応じて再構成することができる構造化フィールドとして記憶されるようにするが可能である。
【００４７】
メンバー特性は、リファレンスの集合で（多分、空）、そのコンテナとしてこの構成要素を有しているプロジェクト中の各構成要素に対する特性である。
【００４８】
属性(Attribute)
構成要素は多数の「属性(attribute)」を有する。属性は「真」または「偽」のいずれかである。実際には、属性は、数値“１”および“０”によって表される値、「真」および「偽」で、メモリの単一ビットによって通常表されている。
【００４９】
全ての構成要素は属性「IsBuildable」を有する。もしこの属性が「真」ならば、この構成要素は生成可能(buildable)であり、さもなければ、それは生成不可能(non-buildable)である。構成要素は、常に生成不可能かまたは一時的生成不可能（ある一時的条件の動作のために）であってもよい。
【００５０】
生成可能な構成要素はまた、属性「IsInline」を有する。この属性が「真」であるとき、構成要素のインプリメンテーションは公開(public)であり、これは、他の構成要素がインプリメンテーションの変化に従属され得ることを意味する。もしそれが偽であるならば、インプリメンテーションの変更により、他の構成要素は決して変更しない。
【００５１】
生成可能な構成要素はまた、属性「IsSynthetic」を有する。この属性は、コンパイラによって生成処理中、形成される構成要素に対して「真」である。それは、プログラマによってマニュアルで作成される構成要素に対して「偽」である。合成構成要素(synthetic 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（インターフェース生成状態）はCompiled（コンパイル済み）である。Implementation（インプリメンテーション）特性が存在しないならば、ImplementationBuildState（インプリメンテーション生成状態）はCompiled（コンパイル済み）である。第5A図では、種々の編集状態変更が示される。ラベル500で、システムが、CreateComponent（構成要素の形成）、RenameComponent（構成要素のリネーム）、PasteComponent（構成要素のペースト）またはEditInterface（インターフェースの編集）のコマンドを識別するとき、制御は、インターフェース変更を処理するために、機能ブロック510に渡される。変更のための詳細な論理は第5B図に詳述されている。
【００５８】
第5B図では、インターフェース生成状態がNeedToCompile（コンパイルを要する）であるかどうかを決定するためにテストが実行される判断ブロック511で処理が開始する。そうであるならば、ラベル514を介して制御が渡され、編集を継続する。これらの動作は編集中に生じ、再生成中には生じない。次の動作は多分他の編集動作である。そうでないならば、機能ブロック512で、インターフェース生成状態がNeedToCompile（コンパイルを要する）とセットされ、したがって、インターフェース変更リストが更新される。それから、機能ブロック513で、インプリメンテーション変更処理およびコンテナ変更処理が終了される。インプリメンテーション変更動作は第5C図に示され、コンテナ変更動作は第5D図に詳述される。
【００５９】
第5C図は、変更されたインプリメンテーションと関連した詳細な処理を詳述している。判断ブロック571で、インプリメンテーション生成状態が既にNeedToCompile（コンパイルを要する）とセットされているかどうかを決定するためにテストが実行される。もしそうであるならば、ラベル572を介して制御が渡され、編集を継続する。もしそうでないならば、機能ブロック573で、インプリメンテーション生成状態がNeedToCompile（コンパイルを要する）とセットされて、インプリメンテーション変更リストが更新される。それから、制御はラベル574を介して元に渡される。
【００６０】
第5D図は、コンテナ変更動作と関連した詳細な論理を詳述する。変数が生成可能であるかどうかを決定するために、テストが判断ブロック542で実行される。そうならば、機能ブロック543で、変更されたインターフェースが、第5B図の議論で上記に詳述したような構成要素のコンテナによって、呼出される。それから、制御はラベル544を介して戻される。
【００６１】
Edit Implementation（編集インプリメンテーション）コマンドが第5A図のラベル560で検出されるならば、処理は機能ブロック570で詳述され、第5C図の議論で上記に詳述されたような変更された動作インプリメンテーションを実行する。
【００６２】
Delete Component（削除構成要素）コマンドが第5A図の530で検出されるならば、構成要素Ａのためのコンテナ変更処理は機能ブロック540で示され、かつ第5D図の議論で詳述されたように開始される。それから、コンテナＡは削除され、制御はラベル550を介して戻される。
【００６３】
Move Component（移動構成要素）コマンドが第5A図の580で検出されるならば、構成要素Ａのためのコンテナ変更処理は機能ブロック590で示され、かつ第5D図で詳述されたように開始される。それから、構成要素のコンテナは新しいコンテナに等しくセットされ、構成要素Ａのためのインターフェース変更処理は、第5B図で詳述されるように開始される。最後に、処理はラベル595を介して戻される。
【００６４】
生成構成要素を決定するための方法
プログラム生成中、プロジェクト構成要素(Project Component)はCompileList（コンパイル・リスト）と呼ばれるリファレンスの非公開リスト(private list)を保持する。InterfaceCompileList（インターフェース・コンパイル・リスト）およびImplementationCompileList（インプリメンテーション・コンパイル・リスト）がある。プロジェクトはまた、InternalErrorList（内部エラー・リスト）と呼ばれるリファレンスの専用リストを保持する。実際には、これらのリストのそれぞれは効率の理由で１つ以上のリストで物理的に表されてもよい。
【００６５】
この処理は第６図に示される。機能ブロック601で示されるようなプロジェクトのChangeList（変更リスト）の各リファレンスに関しては、リファレンスはリストの最前部から選択される。リスト上にリファレンスがもうこれ以上はないならば、処理はブロック602で示されるように終了される。リファレンスがブロック603で決定されるようなInterface（インターフェース）であるならば、リファレンスのコピーはInterfaceCompileList（インターフェース・コンパイル・リスト）の中に置かれ、機能AddClient（クライアントの付加）は、処理がブロック601で継続される前に機能ブロック604のリファレンスに呼出される。その特性名がInterface（インターフェース）でないならば、その特性名はブロック605で示されているようにImplementation（インプリメンテーション）であり、そのIsInline属性が「真」かどうかを決定するために判断ブロック606でテストが行われる。もしそうであるならば、リファレンスのコピーはInterfaceCompileList（インターフェース・コンパイル・リスト）に置かれ、機能AddClientクライアントの付加）は、処理がブロック601で継続される前に機能ブロック607のリファレンス上に呼出される。さもなければ、その特性名はImplementation（インプリメンテーション）でなければならないし、かつそのIsInline属性は「偽」でなければならないし、リファレンスの複写は、処理がブロック601で継続される前に機能ブロック608のImplementationCompileList（インプリメンテーション・コンパイル・リスト）上に置かれる。
【００６６】
機能CreateCompileList（コンパイル・リストの形成）のための擬似コードは次のようになる。
【００６７】
【表１】
【００６８】
パラメータ・リファレンスのクライアント特性における各リファレンスに対して、機能AddClient（クライアントの付加）が、リファレンスを正確に調べ、そのBuildState（生成状態）がCompiled（コンパイル済み）であるならば、リファレンスのBuildState（生成状態）をUncertain（不確定）とセットし、リファレンスの複写を適当なCompileList（コンパイル・リスト）に付加し、リファレンス上にAddClient（クライアントの付加）を呼出す。この処理は、ChangeList（変更リスト）のClient Closure（クライアント終了）の形成と呼ばれる。このClient Closure（クライアント終了）は生成の結果として再コンパイルされる必要があるかもしれない構成要素のサブセットを表す。実際には、生成の進行にしたがって、コンパイラによって発生された従属性および変更が使用されて、Client Closure（クライアント終了）において可能性があるとされた多くの構成要素をコンパイルしなければならないことが回避される。
【００６９】
下記は、AddClient（クライアントの付加）機能のための擬似コードである。
【００７０】
【表２】
【００７１】
インターフェースを処理するための方法
これはBuild（生成）処理の第２段階である。InterfaceCompileList（インターフェース・コンパイル・リスト）に関する項目に対する可能なBuildStates（生成状態）は、Compiled（コンパイル済み）、BeingCompiled（コンパイル中）、NeedToCompile（コンパイルを要する）、Uncertain（不確定）、CompileError（コンパイル・エラー）またはUncertainError（不確定エラー）である。InterfaceCompileList（インターフェース・コンパイル・リスト）は、それが第７図のフローチャートに示されるように、空になるまで処理される。この処理はブロック701から入り、ここでリファレンスがInterfaceCompileList（インターフェース・コンパイル・リスト）の最前列から選択される。リストにリファレンスがこれ以上存在しないならば、処理はブロック702で終了する。リファレンスに関連した構成要素(Component)のInterface（インターフェース）のBuildState（生成状態）が、ブロック703で示されるように、Compiled（コンパイル済み）、CompileError（コンパイル・エラー）またはUncertainError（不確定エラー）であるならば、リファレンスはリストの最前列から取除かれ、処理はブロック701に継続する。リファレンスに関連された構成要素のInterface（インターフェース）のBuildState（生成状態）が、ブロック704で示されるように、BeingCompiled（コンパイル中）またはNeedToCompile（コンパイルを要する）であるならば、構成要素のBuildState（生成状態）は機能ブロック705でBeingCompiled（コンパイル中）とセットされる。したがって、コンパイル機能（コンパイラ42を呼出す）は構成要素のInterface（インターフェース）に対して呼出される。この機能は、Abort（打切り）、Done（実行）およびError（エラー）の一つの値を返す。ブロック706において返された値がAbort（打切り）であるならば、処理はブロック701で継続される。ブロック707において返された値がDone（実行）であるならば、構成要素のInterface BuildState（インターフェース生成状態）はCompiled（コンパイル済み）とセットされ、かつリファレンスは、処理がブロック701で継続される前に、ブロック708でリストの最前列から取除かれる。ブロック709において返された値がError（エラー）であるならば、構成要素のInterface BuildState（インターフェース生成状態）は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（内部エラー・リスト）に構成要素に対応するリファレンスを加え、構成要素のClient（クライアント）リストの全てのリファレンスに対して下記のことを実行する。すなわち、リファレンスのBuildState（生成状態）がCompileError（コンパイル・エラー）またはUncertainError（不確定エラー）であるならば、処理は次のリファレンスに対して続ける。リファレンスのBuildState（生成状態）がNeedToCompile（コンパイルを要する）であるならば、処理はそのBuildState（生成状態）をCompileError（コンパイル・エラー）とセットし、リファレンスにInternalErrorList（内部エラー・リスト）を加え、次のリファレンスに対して続ける前にリファレンスに対してPropagateError（エラー伝播）を呼出す。リファレンスのBuildState（生成状態）がUncertain（不確定）であるならば、処理はそのBuildState（生成状態）をUncertainErrors（不確定エラー）とセットし、リファレンスにInternalErrorList（内部エラー・リスト）を加え、次のリファレンスに対して続ける前にリファレンスに対してPropagateError（エラー伝搬）を呼出す。
【００７６】
機能PropagateError（エラー伝播）の擬似コードは次のとおりである。
【００７７】
【表５】
【００７８】
インプリメンテーションを処理するための方法
これはBuild（生成）処理の第３段階である。ImplementationCompileList（インプリメンテーション・コンパイル・リスト）の各リファレンスは、第８図のフローチャートに示されるように処理される。この処理はブロック801から入り、リファレンスがImplementationCompileList（インプリメンテーション・コンパイル・リスト）の最前列から選択される。リストにリファレンスがこれ以上ないならば、処理はブロック802で終了する。リファレンスのBuildState（生成状態）が、ブロック803で決定されたようにUncertain（不確定）であるならば、BuildState（生成状態）は、処理がブロック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（コンパイル・エラー）またはUncertainError（不確定エラー）であるならば、何も実行されない。Implementation（インプリメンテーション）の処理はこの段階では順序に対して独立であることに留意されたい。これは、従属性がInterface（インターフェース）またはIsInline属性は真であるImplementation（インプリメンテーション）に対してのみあり得、これらは処理が完了しているからである。
【００７９】
ProcessImplementation（インプリメンテーションの処理）のための擬似コードは次のとおりである。
【００８０】
【表６】
【００８１】
生成処理をサポートするコンパイラ
コンパイラ42は、Compile（コンパイル）機能を介して呼出され、これらの２つは同義語として使用されてもよい。コンパイラ42は、ソース・テキストを処理し、可能な外部構成要素の名前を識別する。コンパイラ42は、次に、全ての構成要素に対するリファレンスのリストを得る。コンパイラは、構成要素の種類のような言語特有の知識を使用して、リストからリファレンスを除去する。それから、コンパイラは、テキストで識別された各外部構成要素のために、GetDeclaration（宣言の取得）と呼ばれる機能を呼出す。Compile（コンパイル）機能は、コンパイラ42を呼出す前に、構成要素に関する存在する全てのエラーをクリアする。これは、エラー特性から全てのエラー・メッセージをクリアし、プロジェクトのErrorList特性から全てのリファレンスも取除く。
【００８２】
コンパイラは最初に、第９図のフローチャートによって示されるGetDeclaration（宣言の取得）機能を呼出す。GetDeclaration（宣言の取得）機能は、Abort打切り）、Done（実行）、Circulardependency（循環従属性）またはError（エラー）の一つの値を返し、さらに、Declaration（宣言）のデータを返すことができる。この処理はブロック901から入り、各リファレンスがそのBuildState（生成状態）に対して調べられる。ブロック902で示されるように、処理に対するリファレンスがもうこれ以上はないならば、処理は終了し、リターンが行われる。構成要素のBuildState（生成状態）がCompiled（コンパイル済み）であるならば、この機能は機能ブロック904でDone（実行）を返し、処理がブロック901に継続される前に、記憶されたDeclaration（宣言）データもまた、返される。構成要素のBuildState（生成状態）がブロック905で示されるように、NeedToCompile（コンパイルを要する）またはUncertain（不確定）であるならば、構成要素に対応するリファレンスは、機能、ブロック906でInterfaceCompileList（インターフェース・コンパイル・リスト）の最前列に加えられ、この機能は、処理がブロック901に継続される前に、機能ブロック907でAbort（打切り）を返す。Declaration（宣言）データはこの場合、返されない。構成要素のBuildState（生成状態）がブロック908で示されるようにBeingCompiled（コンパイル中）であるならば、この機能は、処理がブロック901に継続される前に、機能ブロック909でCirculardependency（循環従属性）を返す。Declaration（宣言）データは、この場合には返されない。構成要素のBuildState（生成状態）が、ブロック910で示されるように、CompileError（コンパイル・エラー）またはUncertain（不確定エラー）であるならば、この機能は、処理がブロック901に継続される前に、機能ブロック911でError（エラー）を返す。また、Declaration宣言）データは返されない。
【００８３】
GetDeclaration（宣言の取得）機能のための擬似コードは、次のようになる。
【００８４】
【表７】
【００８５】
GetDeclaration（宣言の取得）を呼出した後、コンパイラは次のように続ける。返された値がAbort（打切り）であったならば、コンパイラは処理を終了して、Abort（打切り）値を返さなければならない。別の実装方法としては、コンパイルをコンパイラは中断し返された構成要素をコンパイルした後、再開または放棄することである。これは、コンパイラがリエントラントである必要があるが、前述のような手順に対するいかなる本質的な変更も別に必要としない。返された値がCompiled（コンパイル済み）であったならば、コンパイラは処理を継続することができる。Declaration（宣言）が使用されているならば、これはSourceReference（ソース・リファレンス）従属性を構成し、コンパイラは従属性およびその性質の両方について常に追跡しているべきである。返された値がCirculardependency（循環従属性）またはError（エラー）であったならば、コンパイラは処理を終了し、構成要素に関するSetError（エラーのセット）機能を呼出し、値Error（エラー）に返さなければならない。コンパイラは、終了前にできるだけ多くのエラーを見つけだすために、処理を任意に継続してもよい。
【００８６】
GetDeclaration（宣言の取得）に対する呼出しがCompiled（コンパイル済み）を返すならば、コンパイラは、従来と同様ソース・テキストを処理し続ける。この処理でエラーにも出会うと、コンパイラは構成要素に対するSetError（エラーのセット）を呼出し、値Error（エラー）を返す。エラーに出会わないなら、コンパイラは値Done（実行）を返す。コンパイラがインターフェースを処理したならば、それはDeclaration（宣言）特性の新しい値を記憶する。
【００８７】
エラーを処理する方法
コンパイラが、Interface（インターフェース）またはImplementation（インプリメンテーション）をコンパイルするために呼出される前に、全ての存在するErrors（エラー）はクリアされる。これは、全てのエラー・メッセージを更新していることを保証する。Interface（インターフェース）とImplementation（インプリメンテーション）間の組込み従属性およびエラーが伝播されるという事実のために、同一の生成においてInterface（インターフェース）およびImplementation（インプリメンテーション）の両者のコンパイラ・エラーを得ることは決してできない。
【００８８】
コンパイラがエラーに出会うとき、コンパイラは、エラーの位置およびエラーを記述するメッセージを含むエラーについての情報を、誤りのある構成要素に返して伝える機能であるSetError（エラーのセット）を呼出す。この情報は、構成要素のErrors（エラー）特性および適切なソース特性（Interface（インターフェース）またはImplementation（インプリメンテーション））に記憶される。また、リファレンスは、Project（プロジェクト）によって保有されたグローバル・エラー・リストに記憶され、全てのエラーに対する手近なアクセスを可能にしている。
【００８９】
エラーが全ての従属する構成要素に伝播するため、構成要素は後でコンパイルされることはない。これは、これらのコンパイルが失敗することが分っているからである。さらに、生成はエラーに出会った後も継続され、それ自身明白にエラーがない構成要素またはエラーを有する構成要素に従属していない構成要素を、できるだけ多く正確に生成する。
【００９０】
SetError（エラーのセット）機能は、コンパイラ42によって渡されたエラー・メッセージを処理し、特性（Interface（インターフェース）またはImplementation（インプリメンテーション））に対応する構成要素のエラー特性中のエントリを形成する。それはまた、エラーに対応するプロジェクトのErrorList特性のエントリを形成する。この方法で形成された２つのエントリは、同一のキーを共有し、それらは「リンク」されている。この機能はまた、その後のユーザ編集の間、同一文字の範囲に添付されたままである“粘着性のあるマーカ”を使用して、プログラム・ソースのエラーの位置を記録する。
【００９１】
コンパイラが、首尾よくソース・テキストの処理を完了すると、オブジェクト・コードを生成し、増分的に(incrementally)リンクするようにリンカ機能にオブジェクト・コードを渡す。その代わりに、オブジェクト・コードを生成処理の終了まで記憶し、伝統的な方法でリンクすることもできる。
【００９２】
コンパイラは、いま構成要素のSourceReference（ソース・リファレンス）特性および各SourceReference（ソース・リファレンス）のClients（クライアント）特性を更新する。例えば構成要素ＡのSourceReference（ソース・リファレンス）特性における、例えば構成要素Ｂに対する各リファレンスに関しては、構成要素ＢのClients（クライアント）特性における構成要素Ａに対応するリファレンス（同一の従属性情報を有している）である必要がある。
【００９３】
コンパイラは、Declaration（宣言）が、その前の値から変更した方法を記述している変化(change)を形成する。コンパイラは、構成要素に対して機能PropagateChange（変化の伝播）を呼出し、それに計算された変化を渡す。それから、コンパイラはDeclaration（宣言）の新しい値をセットする。機能PropagateChange（変化の伝播）は、構成要素のClient List（クライアント・リスト）の各リファレンスの従属性に対して変化を合致させる。この合致が、参照された構成要素は変化によって影響されて、そのBuildState（生成状態）がCompileList（コンパイル・エラー）またはUncertainError（不確定エラー）でないことを示す場合は、そのBuildState（生成状態）はNeedToCompile（コンパイルを要する）とセットされる。
【００９４】
コンパイラは、種々の様式の警告メッセージまたは提案を発するために、SetError（エラーのセット）機能を使用することができる。この場合、警告メッセージのみが戻されるならば、Compile（コンパイル）機能はDone（実行）を返す。この警告メッセージはErrors（エラー）特性に加えられ、リファレンスはプロジェクトのErrorList特性に加えられる。しかしながら、これ以外の場合、コンパイルは、成功とみなされる。BuildState（生成状態）はCompiled（コンパイル済み）とセットされ、エラーは伝播されない。警告または提案のみが出されるならば、プログラムは、完全にそして正確に生成される。
【００９５】
構成要素を条件付きコンパイルするための処理
機能ConditionallyCompile（条件付きコンパイル）は、第10A図および第10B図に示されており、これを参照する。構成要素ＡのSourceReference（ソース・リファレンス）における各構成要素Ｂが1001で処理される。全ての構成要素Ｂは、ブロック1002によって示されるように、処理されると、処理は構成要素Ｂについては完了し、処理は、構成要素Ａをコンパイルするために第10B図に進む。構成要素ＢのBuildState（生成状態）が、ブロック1003に示されるように、BeingCompiled（コンパイル中）またはNeedToCompile（コンパイルを要する）ならば、構成要素のBuildState（生成状態）はBeingCompiled（コンパイル中）とセットされ、構成要素は機能ブロック1004でコンパイルされる。Compile（コンパイル）機能は、Done（実行）、Abort（打切り）またはError（エラー）の一つの値を返すことができる。値Done（実行）がブロック1005で返されると、処理はブロック1001に継続する。
【００９６】
返された値が、ブロック1006でAbort（打切り）であるならば、この機能は終了され、Abort（打切り）は機能ブロック1007で返される。返された値がブロック1008でError（エラー）であるならば、原構成要素のBuildState（生成状態）はUncertainError（不確定エラー）とセットされ、この機能は終了され、Error（エラー）が機能ブロック1009で返される。構成要素ＢのBuildState（生成状態）がブロック1010に示されるようにUncertain（不確定）であるならば、BuildState（生成状態）はBeingCompile（コンパイル中）とセットされ、この構成要素は機能ブロック1011で条件付きでコンパイルされる。また、ConditionallyCompile（条件付きコンパイル）は、Done（実行）、Abort（打切り）またはError（エラー）の一つの値を返すことができる。値Done（実行）がブロック1005で返されるならば、処理はブロック1001に継続する。Error（エラー）がブロック1012で返されるならば、構成要素のBuildState（生成状態）がUncertainError（不確定エラー）とセットされ、構成要素ＡはInterfaceCompileList（インターフェース・コンパイル・リスト）から取除かれ、PropagateError（エラーの伝播）機能が、この機能が終了される前に機能ブロック1014で呼出される。Abort（打切り）がブロック1015で返されるならば、Abort（打切り）は、この機能が終了される前に、機能ブロック1007で返される。
【００９７】
いま、第10B図を参照すると、全てのリファレンスが処理されたならば、全てCompiled（コンパイル済み）BuildState（生成状態）を有する。しかしながら、SourceReference（ソース・リファレンス）の一つが、この処理中の構成要素に対する変化をこの点に伝搬する可能性があるので、それで、その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に示されるように、BeingCompiled（コンパイル中）であるならば、BuildState（生成状態）はCompiled（コンパイル済み）とセットされ、かつDone（実行）が機能ブロック1023で返される。
【００９８】
機能ConditionallyCompile（条件付きコンパイル）のための擬似コードは次のとおりである。
【００９９】
【表８】
【０１００】
【表９】
【０１０１】
エラーを後処理するための方法
エラーを後処理するための方法はBuild（生成）処理の第４段階である。どのようなエラーでも生成中に発生したならば、PostProcessEroors（エラーの後処理）は生成の終わりで呼出される。InternalErrorList（内部エラー・リスト）の各リファレンスに関しては、リファレンスのBuildState（生成状態）がCompileError（コンパイル・エラー）ならば、このBuildState（生成状態）はNeedToCompileコンパイルを要する）に変更される。リファレンスのBuildState（生成状態）がUncertainError（不確定エラー）ならば、BuildState（生成状態）はCompiled（コンパイル済み）に変更される。
【０１０２】
InternalErrorList（内部エラー・リスト）に関する全てのリファレンスが処理されたとき、このリストの全てのエントリはクリアされる。プログラマのための便宜として、プロジェクトのErrorListがあるエントリを含む場合、ウィンドウまたはBrower（ブラウザ）がプロジェクトのErrorList（プロジェクトのエラー・リスト）に対して開かれる。
【０１０３】
PostProcessEroors（エラーの後処理）機能のための擬似コードは次のとおりである。
【０１０４】
【表１０】
【０１０５】
本発明は、特定のプログラミング環境で好ましい実施例に関して記載されているが、当業者は、本発明が添付の請求の範囲の精神および範囲内において変更して実施され得ることを理解できるであろう。
【図面の簡単な説明】
【０１０６】
【図１】第１図は、本発明が実施される、高分解能グラフィック・ディスプレイ装置およびマウスのようなカーソル指示装置をサポートすることができる汎用コンピュータ・システムを示す図である。
【図２】第２図は、コンピュータ・システムの主要な要素をより詳細に示す、第１図に示された汎用コンピュータ・システムのブロック図である。
【図３】第３図は、プログラムを構成する構成要素のコレクションを概念形式で示すブロック図である。
【図４】第４図は、本発明の主要な機能性を示すブロック図である。
【図５Ａ】第５Ａ図は、一緒にまとめて、BuildStateによる編集変化を登録するための論理のフローチャートである。
【図５Ｂ】第５Ｂ図は、一緒にまとめて、BuildStateによる編集変化を登録するための論理のフローチャートである。
【図５Ｃ】第５Ｃ図は、一緒にまとめて、BuildStateによる編集変化を登録するための論理のフローチャートである。
【図５Ｄ】第５Ｄ図は、一緒にまとめて、BuildStateによる編集変化を登録するための論理のフローチャートである。
【図６】第６図は、本発明による生成機構(build mechanism)の動作の第１ステージの可能な要素を決定するための論理を示すフローチャートである。
【図７】第７図は、本発明による生成機構の動作の第２ステージのインターフェース処理の論理を示すフローチャートである。
【図８】第８図は、本発明による生成機構の動作の第３ステージのインプリメンテーション処理の論理を示すフローチャートである。
【図９】第９図は、本発明によるコンパイラによって呼出されたGetDeclarations機能の論理を示すフローチャートである。
【図１０Ａ】第１０Ａ図は、一緒にまとめて、条件付きコンパイル機能の論理を示すフローチャートである。
【図１０Ｂ】第１０Ｂ図は、一緒にまとめて、条件付きコンパイル機能の論理を示すフローチャートである。
【技術分野】
【０００１】
本発明は、一般に、コンピュータ支援ソフトウェア・エンジニアリング(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 Oriented Design with Application”を参照することによって得られる。
【０００６】
コンピュータ・プログラムを実行することに関する全処理には、オブジェクト・コードと称される機械で実施可能な形式に、プログラマによって記述されたソース・コードを翻訳すること、そのオブジェクト・コードを実行することが含まれる。翻訳処理は、インタプリタまたはコンパイラによって実行される。インタプリタの場合、プログラムが実行されるときに翻訳が行われるのに対して、コンパイラの場合、プログラムを実行する前に翻訳が行われ、オブジェクト・コードとして記憶される。すなわち、通常のコンパイルおよび実行システムでは、翻訳および実行の２つのフェーズは独立していて、コンパイルが一度だけ行われる。Smalltalkインタプリタのようなインタプリティブ・システムでは、２つのフェーズが順次実行される。そのプログラミング環境の特質が、オブジェクトが実行されるまで特定のレジスタまたはアドレス空間の指定を行うことができないので、Smalltalkためのインタプリタが必要とされる。
【０００７】
コンパイラは、３つの部分、すなわち、字句解析部、構文解析部およびコード生成部から構成される。字句解析部への入力は高レベル言語プログラムを表す一連の文字である。この字句解析部は、シーケンスを構文解析部への入力である一連のトークンに分割する。この構文解析部はトークンを命令に分割し、文法規則のデータベースを使用して各命令が文法的に正しいか否かを決定する。正しくないならば、エラー・メッセージが発生される。正しいならば、命令は、一連の基本命令に分解され、低レベル言語を発生するためにコード生成部に転送される。コード生成部そのものは、３つの部分、すなわち、中間コード生成、コード最適化およびコード生成に一般に分割される。基本的に、コード生成部は、構文解析部からの出力を受取り、マシン言語コードを生成する。
【発明の開示】
【発明が解決しようとする課題】
【０００８】
ソフトウェアの開発を支援するために、インクリメンタル・コンパイラが開発され、このコンパイラは、バッチ処理動作において、他のステートメントに対して後で生成されるコードとは独立に、受取られたときの一つのステートメントまたはステートメント・グループに対してコードを生成する。インクリメンタル・コンパイルの長所は、必要なデバッグ処理が全プログラムが記述されるまで後回しされるのではなく、コードが記述ごとに、プログラムの一部分のコードに対してコンパイルおよびテストすることができることにある。しかしながら、伝統的なインクリメンタル・コンパイラは、毎回全モジュールを再処理しなければならない。
【０００９】
最適化コンパイラは、多くの場合、非最適化コンパイラの場合よりソース・レベルでデバッグをすることがもっと困難である非常に最適化されたオブジェクト・コードを生成する。この問題は、ルーチンは適切な応答をするようにコンパイルされるけれども、それがその応答を計算する正確な方法がソース・コードで記述された方法と著しく異なっているという事実にある。最適化コンパイラが行うことができるいくつかのことは、最終結果に影響を及ぼさないことが知られているコードまたは変数を除去すること、不変コードをループの中から外に移動させること、共通コードを結合すること、変数がもはや必要としないとき変数に割当たられたレジスタを再使用すること等を含んでいる。したがって、ソースからオブジェクト・コードへのおよびオブジェクト・コードからソースへのマッピングは、これらの最適化のために難しいことがある。変数値を検査することは、変数値が必ずしもルーチン内のいかなるロケーションでも使用可能ではないので、難しいことがある。最適化されたコードの変数値を修正することは、不可能でないとしても、特に困難である。特にvolatile（揮発性）であるとして宣言されていなければ、コンパイラは変数に割当てられた値を“覚えておき”、変数を再読出しをせずに、後でコード中の“覚えている”値を使用する。したがって、その値の変化は誤りのあるプログラム結果を生じることがあった。
【００１０】
コンピュータ・プログラムを生成し、テストおよび開発する技術には多くの進歩があったが、公知のソフトウェア・ツールは、しばしば洞察力のある直感を必要とし、今だにプログラマに相当な負担を負わせる。さらに、伝統的なバッチ指向プログラミング・システムは、プログラミングの創造的な活動に対して非常に破壊的である、非常に長い編集−コンパイル−テストのサイクルを提供している。
【００１１】
したがって、本発明の目的は、プログラマに対してより良く集中し専念することを促進させる処理であって、コンピュータ・プログラムの生成のための人間指向の対話型でかつダイナミック処理を提供すること、これにより、より大きな生産性を得て、コンピュータ・プログラムの生成で必要とされる編集−コンパイル−テストのサイクルを最小にする自動プログラム生成機構(build mechanism)を提供することにある。
【課題を解決するための手段】
【００１２】
本発明によれば、プログラム生成は、プロジェクトと呼ばれるインクリメンタル・プログラム・モデルの相互作用および３つの主要な機能性によって可能となる。プログラムは、特性（property）と呼ばれる名前付けられたデータ項目(named dataitemes)のリストからなる構成要素(component)と呼ばれる意味単位(semanticunit)としてモデル化される。伝統的なシステムで行われるファイルのゆるやかなコレクションとしてプログラムを記憶するよりもむしろ、本発明の人間指向オブジェクトプログラミング・システム(HOOPS)は、このプロジェクト中にプログラムについての全ての情報を記憶する。
【００１３】
本発明の実施にあたっては、コンピュータ・プログラムは、プロジェクト構成要素および生成可能な構成要素のコレクションとしてモデル化される。それぞれは、単一のコンパイル可能な言語要素を表し、かつ増加性(incrementality)のレベルを規定している。コンピュータ・プログラムのためのモデルを提供する構成要素(component)は、生成処理中はアクセスするために記憶される。この記憶された構成要素は、順次にアクセスされ、構成要素に関連する従属性（従属関係）は、コンパイラを使用してクライアント・リストおよび参照（リファレンス）リストを発生させるように計算される。最後に、構成要素は、コンパイラ生成の従属性に加えて構成要素の特性（properties）を使用してコンピュータ・プログラムを生成するようにコンパイルされる。
【００１４】
本発明の好ましい実施例は、C++で記述され、C++、Ｃおよびアセンブラでプログラムを生成するために使用される。これらは現在最も使用されている言語である。本発明を使用して生成されるプログラムは、一般にこれらの言語の３つ全てを使用する。したがって、本発明そのものはオブジェクト指向プログラミング言語で記述されているオブジェクト指向プログラムであるが、本発明は、オブジェクト指向プログラミング言語でプログラムを生成することに限定されず、手続型言語でプログラムを生成する際にも同様に有用である。さらに、本発明は、C++言語に限定されず、他のプログラミング言語で実施されることができ、かつ本発明はこれらの３つの言語への応用に限定されない。すなわち、本発明の教示するところにより、もっと一般的なアプリケーションの人間指向オブジェクト・プログラミング・システムで使用することができる。
【００１５】
上述の事項および他の目的、態様および利点は、図面に関して本発明の好ましい実施例の下記の詳細な説明から、よりよく理解されるだろう。
【発明を実施するための最良の形態】
【００１６】
（発明の概観）
本発明による人間指向オブジェクトプログラミング・システム(HOOPS)では、構成要素(Component)は、インクリメンタル・コンパイルのための粒度である。すなわち、構成要素は、クラス(Class)または関数(Function)のような単一のコンパイル可能な言語要素を表している。構成要素は、２つの部分、すなわちインターフェース(Interface)と呼ばれる外部から認識できる部分（すなわち公開(public)部分）およびインプリメンテーション(Implementation)（非公開(private)部分）に分割される特性セットからなる。これは、構成要素(Component)が他の構成要素のインターフェースに従属しているだけのこともあることを意味する。プロジェクト(Project)の全構成要素はツリー構造に組織され、プロジェクト構成要素と呼ばれるルート構成要素であるツリーのベースを有する。
【００１７】
３つの主要な機能性は、データベース、コンパイラおよび生成機構である。データベースは、構成要素およびその特性(Property)を、持続的に記憶し、検索する。特性のソース・コードをコンパイルするとともに、コンパイラは、構成要素に関連する従属性を計算する責任を負う。生成機構は、生成処理中、構成要素のコンパイル処理を正確かつ効率的に一定の順序に配列するために、コンパイラ生成従属性に加えて構成要素の特性を使用する。生成機構は、いつもプログラムに関するグローバルな視野を有する。これは、プログラムが互いに独立してコンパイルされる、ファイルのセットによって表されている伝統的な方法と対照をなしている。伝統的なプログラミング環境に使用されるファイルは、ファイルに含まれる意味ユニットに処理の特定の固定的順序を負わせている。
【００１８】
本システムは、編集変更（editing change）が、インターフェース(Interface)にあるのか、またはインプリメンテーション(Inplementation)にあるのかどうかを含む、構成要素の編集変更（editing change）の経過を自動的に追う。これは、ファイルレベルでのみ追跡する従来のシステムと対照的である。従属性解析は自動的であり、構成要素間の関係に基づいている。このシステムは、従属性が存在する事実ばかりでなく、それがいかなる種類の従属性であるかを記録することをコンパイラが可能にする機構を含んでいる。これにより、生成（組立）機構が、どの構成要素が実際にコンパイルを必要としているかをより正確に決定して、再コンパイルが必要であろうとなかろうと従属性が存在する全ての構成要素を再コンパイルするよりも、このシステムを効率的にすることを可能にしている。
【００１９】
従来のコンパイラは、ソフトウェアを生成することを容易にするために、プログラミング環境のソフトウェア構造ツールを使用する。例えば、全てのプログラムを個々のファイル内に記憶されているモジュールに分割することは、従来のプログラム構造では通例である。そして、個々のモジュールは、それぞれ別々に処理される。Makeコマンドは、コンピュータ・プログラムを構成するモジュールを管理および保持するために使用される。すなわち、Make機能は、プログラムのモジュール間の関係の経過を追い、変化がなされた後モジュールを一貫性があるようにするのに必要とされるコマンドのみを発生する。しかしながら、プログラマが、モジュール間の関係（従属性）を規定するMakefile仕様を生成することが必要である。Makefile仕様に対する要求は、プログラマが、いつ従属性が発生するかを決定することができなければならないこと、およびプログラマに同期化従属性を同期化する負担をかけていることを意味している。実際、これは通常、不必要な従属性の存在および必要な従属性の省略の両方を意味する。不必要な従属性の存在および必要な従属性の省略の両者は、コンピュータ・プログラムの生成におけるエラー源であることが多い。
【００２０】
Make機能と対照的に、本発明による生成機構は、プログラマがMakefile仕様のような仕様を生成しないと言う点で異なっている。この生成機構は、従属性のいかなる予備知識も想定していない。すなわち、実際には、それは、要素の従属性を“見いだし”、これらの従属性の経過を追う。これは、生成機構が、予め存在する従属性情報がない場合に、最初からプログラムを生成することを意味する。初期の生成動作では、全ての構成要素は変更リストに列挙される。変更リスト上の構成要素のコンパイルが試みられるが、もしそのコンパイルが他の構成要素のコンパイルに従属するならば、第１の構成要素のコンパイルが中断されるかまたは打ち切られるかのいずれかである。そして第２の構成要素のコンパイルが試みられる。このようにコンパイルすることができる構成要素が見つけだされるまで続けられる。次に、コンパイルが中断されたかまたは打切られた構成要素に対して、処理で既に作成された情報を用いて、生成機構が再度働く。
【００２１】
生成機構は、全てのインターフェース(Interface)が、全てのインプリメンテーション (Inplementation)の前にコンパイルされるように、コンパイルを順序付ける。これは、潜在的な相互従属性の数を減少させるので、したがって効率を増加する。この生成機構は、構成要素(Component)の処理を制御するために、有限状態機械(finite state machine)のフォームを用いている。そして、中断されたかまたは打切られた構成要素のコンパイルを最少にするために、正しい順序付け（ordering）を確実にするのに役立てている。
【００２２】
変更（構成要素の編集または構成要素の付加あるいは削除）が行われた後の生成動作は、変更リストが変更されたこれらの構成要素のみを含むことを除いて、初期の生成動作と同様であり、再コンパイルを必要とするこれらの構成要素のみを再コンパイルするために、生成機構は予め開発されたクライアントおよびソース参照リストを使用する。本発明によって実施される機能レベルのインクリメンタル・コンパイルは、通常、プログラムのより小さい部分が再生成されることになるので、プログラム変更からのテストまでのターン・アラウンド・タイムを大いに減少する。
【００２３】
プログラム・モデルは、インターフェースのための内部処理された様式（宣言(Declaration)特性と呼ばれる）を記憶および再使用するための方法を提供する。コンパイラは、他の構成要素をコンパイルする時に効率的に使用されるように、インターフェース(Interface)の処理された内部様式（form）を記憶する。そして、になる。これは、使用されるインターフェースが、使用される全てのファイルに含まれて(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マイクロプロセッサまたはIBM社のPS/Vコンピュータに一般に使用されているインテル社の80386および80486マイクロプロセッサのようないくつかの商用マイクロプロセッサのいずれでもよい。ワークステーションに一般に使用されるRISC(reducedinstruction 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および／またはCPU21に接続されている。これらは、例えば、バス24上のトラフィックを制御するバス・マスタ・チップを含んでいる。あるコンピュータにおいては、バス24は２つのバス、すなわちデータ・バスおよびディスプレイ・バスであり、ディスプレイ・バスは、グラフィック・ユーザ・インターフェースで望ましい高速ディスプレイ動作を可能にしている。
【００２８】
定義
プログラム
本発明の説明で使用されるように、HOOPSプログラムは、「プロジェクト(Project)」と呼ばれる一つの生成不可能な構成要素(non-buidable component)および“生成可能な構成要素(buildable component)”の集合(Collection)からなる。それはまた、生成不可能な構成要素(non-buidablecomponent)を格納することが可能であるが、この説明では、形容詞がない構成要素について言及されている時はいつでも、意味しているものは“生成可能な構成要素(buildable component)”である。生成不可能な構成要素(non-buidable component)は生成動作中コンパイルされない。
【００２９】
構成要素(Component)
構成要素(Component)は独特な識別を有し、名前を付けられる。異なる構成要素は、IDと呼ばれるいくらかの様式の独特な識別子(Identifer)によって識別される。いかなる構成要素にも属しないNullIDと呼ばれる、他とは異なるIDがある。構成要素が形成されると、このIDが割当てられ、構成要素の存在中決して変更されない。構成要素が削除されると、その構成要素のIDは決して再使用されない。実際には、IDは通常数字である。
【００３０】
構成要素はまた、余白を含まないテキスト・ストリング（文字列）からなる名前を有する。異なる構成要素が異なる名前を有する必要はない。その名前が、ある所与のテキスト・ストリングにマッチする全ての構成要素のリスト（多分、空）を得ることは可能である。構成要素の名前は、構成要素の存在中何回変更してよい。
【００３１】
各生成可能な構成要素は特定のコンピュータ言語に関連している。実際には、コンピュータ言語は、通常テキスト・ストリング（文字列）によって識別される。各コンピュータ言語は、それに関連付けられたコンパイラを有し、そのコンパイラは、その言語の全ての構成要素をコンパイルするときに使用される。実際には、所与のコンピュータ言語が一つ以上のコンパイラと関連付けられることは可能である。この場合、構成要素は、言語と特定のコンパイラを識別するための方法をともに記録しなければならない。
【００３２】
特定の言語は、それに関連した特定の構成要素の種類(Kind)からなる特定セットおよびインプリメンテーション特性の特定セットを有し、それらは全ての種類は異なっている。したがって、ある言語の特定意味構成要素は、必要に応じて異なる方法で構成される。
【００３３】
構成要素は「BuildState（生成状態）」を有する。BuildStateは、NeverCompile（コンパイル不可）、Compiled（コンパイル済み）、NeedToCompile（要コンパイル）、Uncertain（不確定）、BeingCompiled（コンパイル中）、CompileError（コンパイル・エラー）、UncertainError（不確定エラー）のリストからの値である。実際には、これらの値は通常数値である。各構成要素は、「InterfaceBuildState（インターフェース生成状態）」および「ImplementationBuildState（インプリメンテーション生成状態）」と呼ばれる一対のBuildStateを有する。あらゆる構成要素は、それが生成可能(buildable)であれ生成不可能(non-buildable)あれ、これらのBuildStateの両方を有する。生成不可能構成要素に対しては、これらのBuildStateは、両者共NeverCompile（コンパイル不可）である。
【００３４】
BuildStateはアクセスされても、および変更されてもよい。構成要素のBuildStateを同一値に再度設定することは可能であり、いかなる影響も引き起こさない。BuildStateを変更することは、同一または異なる構成要素の他の特性のBuildStateを変更するかまたは例えば、変更リストもしくはエラー・リストのようなあるリストからの参照（リファレンス）を付加あるいは削除するような、明確な副作用を有するかもしれない。
【００３５】
構成要素は、意味言語構成要素を表すために使用される。これが行われる方法は、モデル化されている特定のコンピュータ言語に依存する。例えば、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）である。したがって、全ての構成要素は、プロジェクトにあるものとして記述されている。
【００４０】
生成特性（また構成要素生成リスト(component built list)と呼ばれる）は、構成要素が生成された順序の最後の生成で、正しくコンパイルされた特性リストを記録する。同一の特性は、多くても一度リスト上に出現するだけである。それは、テストおよびデバッグのために使用される。
【００４１】
プロジェクト構成要素(Project Component)
プロジェクトは、さらに特性「ChangeList（変更リスト）」および「ErrorList（エラー・リスト）」を有する構成要素である。ChangeList（変更リスト）特性はリファレンスのリストである。このリファレンスは、構成要素および最後の生成以来変更された特性を記述する。実際には、ChangeList（変更リスト）は、プログラムを生成する際の効率のために、いくらかの方法で分類された一つ以上のリストによって表されてもよい。ErrorList（エラー・リスト）特性もまた、リファレンスのリストである。これらのリファレンスは、最後のプログラム生成中エラーを有するものとしてリストされた構成要素を記述している。リファレンスは、全てその特性としてエラーを有する。各リファレンスと関連しているのは数値で表されたキーである。このキーは、特定のメッセージおよび構成要素の特定された特性の特定サブレンジの位置を突きとめるために、特定のエラー特性とともに使用される。
【００４２】
生成可能な構成要素(Buildable Component)
生成可能な構成要素はまた、特性である「宣言(Declaration)」、「オブジェクト・コード(Objectcode)」、「クライアント(Clients)」、「ソース・リファレンス(SourceReferences)」、「エラー(Errors)」を有しなければならないし、特性「インターフェース(Interface)」、「インプリメンテーション(Implementation)」および「メンバー(Members)」を有してもよい。
【００４３】
宣言特性は、コンパイラのためのデータキャッシュを表す。これは、構成要素が、例えばコンパイルされてしまう前、空でもよい。実際には、記憶された表現は、コンパイラの内部表現とは異なってもよいが、それはコンパイラのシンボル・テーブルのエントリとして考えられることができる。
【００４４】
オブジェクト・コード特性は、構成要素のための実行可能なコードを表す。これは、構成要素が、例えばコンパイルされてしまう前、または、いかなるオブジェクト・コードもこの構成要素と関連していない場合、空でもよい。実際には、それは、通常、ほかの所に記憶される実際のコードを指示するための手段を提供している。
【００４５】
クライアントおよびソース・リファレンス特性は、リファレンスおよび「従属性(dependency)」からなるペアの集合である。従属性は変更リストである。変更は、特定の有限ストリング・リストから選択されたテキスト・ストリングとして表することができる。インターフェース特性における使用とは反対に、インプリメンテーション特性のみに対する構成要素に対して、リファレンスを区別するために使用される「パブリック(Public)」と呼ばれる特定の変更がある。リストのｎ番目の変更があるならば、ｎ番目のビットが“１”であり、なければ“０”であるビット・ベクトルとして、従属性は表すことができる。
【００４６】
「エラー」特性は複数の三つ組みのリストからなる。各三つ組みは「キー」、特性名およびメッセージからなる。キーは数値識別子である。所定のキーは、特定のエラー特性に一度だけ現れることができる。特性名は、通常インターフェースまたはインプリメンテーションである。メッセージは、テキストおよび／またはグラフィックの一部分である。
インターフェースおよびインプリメンテーション特性は、構成要素のソース・テキストを表す特性である。ソース・テキストは、テキストよりもむしろトークンとして記憶され、もし必要とされるならば、異なる様式でアクセスすることができる。これらの特性によって表されるテキストは、プログラミング環境においてそれをマニュアルで編集することによって変更することができる。インターフェース・データは、それからソース・テキストが必要に応じて再構成することができる構造化フィールドとして記憶されるようにするが可能である。
【００４７】
メンバー特性は、リファレンスの集合で（多分、空）、そのコンテナとしてこの構成要素を有しているプロジェクト中の各構成要素に対する特性である。
【００４８】
属性(Attribute)
構成要素は多数の「属性(attribute)」を有する。属性は「真」または「偽」のいずれかである。実際には、属性は、数値“１”および“０”によって表される値、「真」および「偽」で、メモリの単一ビットによって通常表されている。
【００４９】
全ての構成要素は属性「IsBuildable」を有する。もしこの属性が「真」ならば、この構成要素は生成可能(buildable)であり、さもなければ、それは生成不可能(non-buildable)である。構成要素は、常に生成不可能かまたは一時的生成不可能（ある一時的条件の動作のために）であってもよい。
【００５０】
生成可能な構成要素はまた、属性「IsInline」を有する。この属性が「真」であるとき、構成要素のインプリメンテーションは公開(public)であり、これは、他の構成要素がインプリメンテーションの変化に従属され得ることを意味する。もしそれが偽であるならば、インプリメンテーションの変更により、他の構成要素は決して変更しない。
【００５１】
生成可能な構成要素はまた、属性「IsSynthetic」を有する。この属性は、コンパイラによって生成処理中、形成される構成要素に対して「真」である。それは、プログラマによってマニュアルで作成される構成要素に対して「偽」である。合成構成要素(synthetic 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（インターフェース生成状態）はCompiled（コンパイル済み）である。Implementation（インプリメンテーション）特性が存在しないならば、ImplementationBuildState（インプリメンテーション生成状態）はCompiled（コンパイル済み）である。第5A図では、種々の編集状態変更が示される。ラベル500で、システムが、CreateComponent（構成要素の形成）、RenameComponent（構成要素のリネーム）、PasteComponent（構成要素のペースト）またはEditInterface（インターフェースの編集）のコマンドを識別するとき、制御は、インターフェース変更を処理するために、機能ブロック510に渡される。変更のための詳細な論理は第5B図に詳述されている。
【００５８】
第5B図では、インターフェース生成状態がNeedToCompile（コンパイルを要する）であるかどうかを決定するためにテストが実行される判断ブロック511で処理が開始する。そうであるならば、ラベル514を介して制御が渡され、編集を継続する。これらの動作は編集中に生じ、再生成中には生じない。次の動作は多分他の編集動作である。そうでないならば、機能ブロック512で、インターフェース生成状態がNeedToCompile（コンパイルを要する）とセットされ、したがって、インターフェース変更リストが更新される。それから、機能ブロック513で、インプリメンテーション変更処理およびコンテナ変更処理が終了される。インプリメンテーション変更動作は第5C図に示され、コンテナ変更動作は第5D図に詳述される。
【００５９】
第5C図は、変更されたインプリメンテーションと関連した詳細な処理を詳述している。判断ブロック571で、インプリメンテーション生成状態が既にNeedToCompile（コンパイルを要する）とセットされているかどうかを決定するためにテストが実行される。もしそうであるならば、ラベル572を介して制御が渡され、編集を継続する。もしそうでないならば、機能ブロック573で、インプリメンテーション生成状態がNeedToCompile（コンパイルを要する）とセットされて、インプリメンテーション変更リストが更新される。それから、制御はラベル574を介して元に渡される。
【００６０】
第5D図は、コンテナ変更動作と関連した詳細な論理を詳述する。変数が生成可能であるかどうかを決定するために、テストが判断ブロック542で実行される。そうならば、機能ブロック543で、変更されたインターフェースが、第5B図の議論で上記に詳述したような構成要素のコンテナによって、呼出される。それから、制御はラベル544を介して戻される。
【００６１】
Edit Implementation（編集インプリメンテーション）コマンドが第5A図のラベル560で検出されるならば、処理は機能ブロック570で詳述され、第5C図の議論で上記に詳述されたような変更された動作インプリメンテーションを実行する。
【００６２】
Delete Component（削除構成要素）コマンドが第5A図の530で検出されるならば、構成要素Ａのためのコンテナ変更処理は機能ブロック540で示され、かつ第5D図の議論で詳述されたように開始される。それから、コンテナＡは削除され、制御はラベル550を介して戻される。
【００６３】
Move Component（移動構成要素）コマンドが第5A図の580で検出されるならば、構成要素Ａのためのコンテナ変更処理は機能ブロック590で示され、かつ第5D図で詳述されたように開始される。それから、構成要素のコンテナは新しいコンテナに等しくセットされ、構成要素Ａのためのインターフェース変更処理は、第5B図で詳述されるように開始される。最後に、処理はラベル595を介して戻される。
【００６４】
生成構成要素を決定するための方法
プログラム生成中、プロジェクト構成要素(Project Component)はCompileList（コンパイル・リスト）と呼ばれるリファレンスの非公開リスト(private list)を保持する。InterfaceCompileList（インターフェース・コンパイル・リスト）およびImplementationCompileList（インプリメンテーション・コンパイル・リスト）がある。プロジェクトはまた、InternalErrorList（内部エラー・リスト）と呼ばれるリファレンスの専用リストを保持する。実際には、これらのリストのそれぞれは効率の理由で１つ以上のリストで物理的に表されてもよい。
【００６５】
この処理は第６図に示される。機能ブロック601で示されるようなプロジェクトのChangeList（変更リスト）の各リファレンスに関しては、リファレンスはリストの最前部から選択される。リスト上にリファレンスがもうこれ以上はないならば、処理はブロック602で示されるように終了される。リファレンスがブロック603で決定されるようなInterface（インターフェース）であるならば、リファレンスのコピーはInterfaceCompileList（インターフェース・コンパイル・リスト）の中に置かれ、機能AddClient（クライアントの付加）は、処理がブロック601で継続される前に機能ブロック604のリファレンスに呼出される。その特性名がInterface（インターフェース）でないならば、その特性名はブロック605で示されているようにImplementation（インプリメンテーション）であり、そのIsInline属性が「真」かどうかを決定するために判断ブロック606でテストが行われる。もしそうであるならば、リファレンスのコピーはInterfaceCompileList（インターフェース・コンパイル・リスト）に置かれ、機能AddClientクライアントの付加）は、処理がブロック601で継続される前に機能ブロック607のリファレンス上に呼出される。さもなければ、その特性名はImplementation（インプリメンテーション）でなければならないし、かつそのIsInline属性は「偽」でなければならないし、リファレンスの複写は、処理がブロック601で継続される前に機能ブロック608のImplementationCompileList（インプリメンテーション・コンパイル・リスト）上に置かれる。
【００６６】
機能CreateCompileList（コンパイル・リストの形成）のための擬似コードは次のようになる。
【００６７】
【表１】
【００６８】
パラメータ・リファレンスのクライアント特性における各リファレンスに対して、機能AddClient（クライアントの付加）が、リファレンスを正確に調べ、そのBuildState（生成状態）がCompiled（コンパイル済み）であるならば、リファレンスのBuildState（生成状態）をUncertain（不確定）とセットし、リファレンスの複写を適当なCompileList（コンパイル・リスト）に付加し、リファレンス上にAddClient（クライアントの付加）を呼出す。この処理は、ChangeList（変更リスト）のClient Closure（クライアント終了）の形成と呼ばれる。このClient Closure（クライアント終了）は生成の結果として再コンパイルされる必要があるかもしれない構成要素のサブセットを表す。実際には、生成の進行にしたがって、コンパイラによって発生された従属性および変更が使用されて、Client Closure（クライアント終了）において可能性があるとされた多くの構成要素をコンパイルしなければならないことが回避される。
【００６９】
下記は、AddClient（クライアントの付加）機能のための擬似コードである。
【００７０】
【表２】
【００７１】
インターフェースを処理するための方法
これはBuild（生成）処理の第２段階である。InterfaceCompileList（インターフェース・コンパイル・リスト）に関する項目に対する可能なBuildStates（生成状態）は、Compiled（コンパイル済み）、BeingCompiled（コンパイル中）、NeedToCompile（コンパイルを要する）、Uncertain（不確定）、CompileError（コンパイル・エラー）またはUncertainError（不確定エラー）である。InterfaceCompileList（インターフェース・コンパイル・リスト）は、それが第７図のフローチャートに示されるように、空になるまで処理される。この処理はブロック701から入り、ここでリファレンスがInterfaceCompileList（インターフェース・コンパイル・リスト）の最前列から選択される。リストにリファレンスがこれ以上存在しないならば、処理はブロック702で終了する。リファレンスに関連した構成要素(Component)のInterface（インターフェース）のBuildState（生成状態）が、ブロック703で示されるように、Compiled（コンパイル済み）、CompileError（コンパイル・エラー）またはUncertainError（不確定エラー）であるならば、リファレンスはリストの最前列から取除かれ、処理はブロック701に継続する。リファレンスに関連された構成要素のInterface（インターフェース）のBuildState（生成状態）が、ブロック704で示されるように、BeingCompiled（コンパイル中）またはNeedToCompile（コンパイルを要する）であるならば、構成要素のBuildState（生成状態）は機能ブロック705でBeingCompiled（コンパイル中）とセットされる。したがって、コンパイル機能（コンパイラ42を呼出す）は構成要素のInterface（インターフェース）に対して呼出される。この機能は、Abort（打切り）、Done（実行）およびError（エラー）の一つの値を返す。ブロック706において返された値がAbort（打切り）であるならば、処理はブロック701で継続される。ブロック707において返された値がDone（実行）であるならば、構成要素のInterface BuildState（インターフェース生成状態）はCompiled（コンパイル済み）とセットされ、かつリファレンスは、処理がブロック701で継続される前に、ブロック708でリストの最前列から取除かれる。ブロック709において返された値がError（エラー）であるならば、構成要素のInterface BuildState（インターフェース生成状態）は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（内部エラー・リスト）に構成要素に対応するリファレンスを加え、構成要素のClient（クライアント）リストの全てのリファレンスに対して下記のことを実行する。すなわち、リファレンスのBuildState（生成状態）がCompileError（コンパイル・エラー）またはUncertainError（不確定エラー）であるならば、処理は次のリファレンスに対して続ける。リファレンスのBuildState（生成状態）がNeedToCompile（コンパイルを要する）であるならば、処理はそのBuildState（生成状態）をCompileError（コンパイル・エラー）とセットし、リファレンスにInternalErrorList（内部エラー・リスト）を加え、次のリファレンスに対して続ける前にリファレンスに対してPropagateError（エラー伝播）を呼出す。リファレンスのBuildState（生成状態）がUncertain（不確定）であるならば、処理はそのBuildState（生成状態）をUncertainErrors（不確定エラー）とセットし、リファレンスにInternalErrorList（内部エラー・リスト）を加え、次のリファレンスに対して続ける前にリファレンスに対してPropagateError（エラー伝搬）を呼出す。
【００７６】
機能PropagateError（エラー伝播）の擬似コードは次のとおりである。
【００７７】
【表５】
【００７８】
インプリメンテーションを処理するための方法
これはBuild（生成）処理の第３段階である。ImplementationCompileList（インプリメンテーション・コンパイル・リスト）の各リファレンスは、第８図のフローチャートに示されるように処理される。この処理はブロック801から入り、リファレンスがImplementationCompileList（インプリメンテーション・コンパイル・リスト）の最前列から選択される。リストにリファレンスがこれ以上ないならば、処理はブロック802で終了する。リファレンスのBuildState（生成状態）が、ブロック803で決定されたようにUncertain（不確定）であるならば、BuildState（生成状態）は、処理がブロック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（コンパイル・エラー）またはUncertainError（不確定エラー）であるならば、何も実行されない。Implementation（インプリメンテーション）の処理はこの段階では順序に対して独立であることに留意されたい。これは、従属性がInterface（インターフェース）またはIsInline属性は真であるImplementation（インプリメンテーション）に対してのみあり得、これらは処理が完了しているからである。
【００７９】
ProcessImplementation（インプリメンテーションの処理）のための擬似コードは次のとおりである。
【００８０】
【表６】
【００８１】
生成処理をサポートするコンパイラ
コンパイラ42は、Compile（コンパイル）機能を介して呼出され、これらの２つは同義語として使用されてもよい。コンパイラ42は、ソース・テキストを処理し、可能な外部構成要素の名前を識別する。コンパイラ42は、次に、全ての構成要素に対するリファレンスのリストを得る。コンパイラは、構成要素の種類のような言語特有の知識を使用して、リストからリファレンスを除去する。それから、コンパイラは、テキストで識別された各外部構成要素のために、GetDeclaration（宣言の取得）と呼ばれる機能を呼出す。Compile（コンパイル）機能は、コンパイラ42を呼出す前に、構成要素に関する存在する全てのエラーをクリアする。これは、エラー特性から全てのエラー・メッセージをクリアし、プロジェクトのErrorList特性から全てのリファレンスも取除く。
【００８２】
コンパイラは最初に、第９図のフローチャートによって示されるGetDeclaration（宣言の取得）機能を呼出す。GetDeclaration（宣言の取得）機能は、Abort打切り）、Done（実行）、Circulardependency（循環従属性）またはError（エラー）の一つの値を返し、さらに、Declaration（宣言）のデータを返すことができる。この処理はブロック901から入り、各リファレンスがそのBuildState（生成状態）に対して調べられる。ブロック902で示されるように、処理に対するリファレンスがもうこれ以上はないならば、処理は終了し、リターンが行われる。構成要素のBuildState（生成状態）がCompiled（コンパイル済み）であるならば、この機能は機能ブロック904でDone（実行）を返し、処理がブロック901に継続される前に、記憶されたDeclaration（宣言）データもまた、返される。構成要素のBuildState（生成状態）がブロック905で示されるように、NeedToCompile（コンパイルを要する）またはUncertain（不確定）であるならば、構成要素に対応するリファレンスは、機能、ブロック906でInterfaceCompileList（インターフェース・コンパイル・リスト）の最前列に加えられ、この機能は、処理がブロック901に継続される前に、機能ブロック907でAbort（打切り）を返す。Declaration（宣言）データはこの場合、返されない。構成要素のBuildState（生成状態）がブロック908で示されるようにBeingCompiled（コンパイル中）であるならば、この機能は、処理がブロック901に継続される前に、機能ブロック909でCirculardependency（循環従属性）を返す。Declaration（宣言）データは、この場合には返されない。構成要素のBuildState（生成状態）が、ブロック910で示されるように、CompileError（コンパイル・エラー）またはUncertain（不確定エラー）であるならば、この機能は、処理がブロック901に継続される前に、機能ブロック911でError（エラー）を返す。また、Declaration宣言）データは返されない。
【００８３】
GetDeclaration（宣言の取得）機能のための擬似コードは、次のようになる。
【００８４】
【表７】
【００８５】
GetDeclaration（宣言の取得）を呼出した後、コンパイラは次のように続ける。返された値がAbort（打切り）であったならば、コンパイラは処理を終了して、Abort（打切り）値を返さなければならない。別の実装方法としては、コンパイルをコンパイラは中断し返された構成要素をコンパイルした後、再開または放棄することである。これは、コンパイラがリエントラントである必要があるが、前述のような手順に対するいかなる本質的な変更も別に必要としない。返された値がCompiled（コンパイル済み）であったならば、コンパイラは処理を継続することができる。Declaration（宣言）が使用されているならば、これはSourceReference（ソース・リファレンス）従属性を構成し、コンパイラは従属性およびその性質の両方について常に追跡しているべきである。返された値がCirculardependency（循環従属性）またはError（エラー）であったならば、コンパイラは処理を終了し、構成要素に関するSetError（エラーのセット）機能を呼出し、値Error（エラー）に返さなければならない。コンパイラは、終了前にできるだけ多くのエラーを見つけだすために、処理を任意に継続してもよい。
【００８６】
GetDeclaration（宣言の取得）に対する呼出しがCompiled（コンパイル済み）を返すならば、コンパイラは、従来と同様ソース・テキストを処理し続ける。この処理でエラーにも出会うと、コンパイラは構成要素に対するSetError（エラーのセット）を呼出し、値Error（エラー）を返す。エラーに出会わないなら、コンパイラは値Done（実行）を返す。コンパイラがインターフェースを処理したならば、それはDeclaration（宣言）特性の新しい値を記憶する。
【００８７】
エラーを処理する方法
コンパイラが、Interface（インターフェース）またはImplementation（インプリメンテーション）をコンパイルするために呼出される前に、全ての存在するErrors（エラー）はクリアされる。これは、全てのエラー・メッセージを更新していることを保証する。Interface（インターフェース）とImplementation（インプリメンテーション）間の組込み従属性およびエラーが伝播されるという事実のために、同一の生成においてInterface（インターフェース）およびImplementation（インプリメンテーション）の両者のコンパイラ・エラーを得ることは決してできない。
【００８８】
コンパイラがエラーに出会うとき、コンパイラは、エラーの位置およびエラーを記述するメッセージを含むエラーについての情報を、誤りのある構成要素に返して伝える機能であるSetError（エラーのセット）を呼出す。この情報は、構成要素のErrors（エラー）特性および適切なソース特性（Interface（インターフェース）またはImplementation（インプリメンテーション））に記憶される。また、リファレンスは、Project（プロジェクト）によって保有されたグローバル・エラー・リストに記憶され、全てのエラーに対する手近なアクセスを可能にしている。
【００８９】
エラーが全ての従属する構成要素に伝播するため、構成要素は後でコンパイルされることはない。これは、これらのコンパイルが失敗することが分っているからである。さらに、生成はエラーに出会った後も継続され、それ自身明白にエラーがない構成要素またはエラーを有する構成要素に従属していない構成要素を、できるだけ多く正確に生成する。
【００９０】
SetError（エラーのセット）機能は、コンパイラ42によって渡されたエラー・メッセージを処理し、特性（Interface（インターフェース）またはImplementation（インプリメンテーション））に対応する構成要素のエラー特性中のエントリを形成する。それはまた、エラーに対応するプロジェクトのErrorList特性のエントリを形成する。この方法で形成された２つのエントリは、同一のキーを共有し、それらは「リンク」されている。この機能はまた、その後のユーザ編集の間、同一文字の範囲に添付されたままである“粘着性のあるマーカ”を使用して、プログラム・ソースのエラーの位置を記録する。
【００９１】
コンパイラが、首尾よくソース・テキストの処理を完了すると、オブジェクト・コードを生成し、増分的に(incrementally)リンクするようにリンカ機能にオブジェクト・コードを渡す。その代わりに、オブジェクト・コードを生成処理の終了まで記憶し、伝統的な方法でリンクすることもできる。
【００９２】
コンパイラは、いま構成要素のSourceReference（ソース・リファレンス）特性および各SourceReference（ソース・リファレンス）のClients（クライアント）特性を更新する。例えば構成要素ＡのSourceReference（ソース・リファレンス）特性における、例えば構成要素Ｂに対する各リファレンスに関しては、構成要素ＢのClients（クライアント）特性における構成要素Ａに対応するリファレンス（同一の従属性情報を有している）である必要がある。
【００９３】
コンパイラは、Declaration（宣言）が、その前の値から変更した方法を記述している変化(change)を形成する。コンパイラは、構成要素に対して機能PropagateChange（変化の伝播）を呼出し、それに計算された変化を渡す。それから、コンパイラはDeclaration（宣言）の新しい値をセットする。機能PropagateChange（変化の伝播）は、構成要素のClient List（クライアント・リスト）の各リファレンスの従属性に対して変化を合致させる。この合致が、参照された構成要素は変化によって影響されて、そのBuildState（生成状態）がCompileList（コンパイル・エラー）またはUncertainError（不確定エラー）でないことを示す場合は、そのBuildState（生成状態）はNeedToCompile（コンパイルを要する）とセットされる。
【００９４】
コンパイラは、種々の様式の警告メッセージまたは提案を発するために、SetError（エラーのセット）機能を使用することができる。この場合、警告メッセージのみが戻されるならば、Compile（コンパイル）機能はDone（実行）を返す。この警告メッセージはErrors（エラー）特性に加えられ、リファレンスはプロジェクトのErrorList特性に加えられる。しかしながら、これ以外の場合、コンパイルは、成功とみなされる。BuildState（生成状態）はCompiled（コンパイル済み）とセットされ、エラーは伝播されない。警告または提案のみが出されるならば、プログラムは、完全にそして正確に生成される。
【００９５】
構成要素を条件付きコンパイルするための処理
機能ConditionallyCompile（条件付きコンパイル）は、第10A図および第10B図に示されており、これを参照する。構成要素ＡのSourceReference（ソース・リファレンス）における各構成要素Ｂが1001で処理される。全ての構成要素Ｂは、ブロック1002によって示されるように、処理されると、処理は構成要素Ｂについては完了し、処理は、構成要素Ａをコンパイルするために第10B図に進む。構成要素ＢのBuildState（生成状態）が、ブロック1003に示されるように、BeingCompiled（コンパイル中）またはNeedToCompile（コンパイルを要する）ならば、構成要素のBuildState（生成状態）はBeingCompiled（コンパイル中）とセットされ、構成要素は機能ブロック1004でコンパイルされる。Compile（コンパイル）機能は、Done（実行）、Abort（打切り）またはError（エラー）の一つの値を返すことができる。値Done（実行）がブロック1005で返されると、処理はブロック1001に継続する。
【００９６】
返された値が、ブロック1006でAbort（打切り）であるならば、この機能は終了され、Abort（打切り）は機能ブロック1007で返される。返された値がブロック1008でError（エラー）であるならば、原構成要素のBuildState（生成状態）はUncertainError（不確定エラー）とセットされ、この機能は終了され、Error（エラー）が機能ブロック1009で返される。構成要素ＢのBuildState（生成状態）がブロック1010に示されるようにUncertain（不確定）であるならば、BuildState（生成状態）はBeingCompile（コンパイル中）とセットされ、この構成要素は機能ブロック1011で条件付きでコンパイルされる。また、ConditionallyCompile（条件付きコンパイル）は、Done（実行）、Abort（打切り）またはError（エラー）の一つの値を返すことができる。値Done（実行）がブロック1005で返されるならば、処理はブロック1001に継続する。Error（エラー）がブロック1012で返されるならば、構成要素のBuildState（生成状態）がUncertainError（不確定エラー）とセットされ、構成要素ＡはInterfaceCompileList（インターフェース・コンパイル・リスト）から取除かれ、PropagateError（エラーの伝播）機能が、この機能が終了される前に機能ブロック1014で呼出される。Abort（打切り）がブロック1015で返されるならば、Abort（打切り）は、この機能が終了される前に、機能ブロック1007で返される。
【００９７】
いま、第10B図を参照すると、全てのリファレンスが処理されたならば、全てCompiled（コンパイル済み）BuildState（生成状態）を有する。しかしながら、SourceReference（ソース・リファレンス）の一つが、この処理中の構成要素に対する変化をこの点に伝搬する可能性があるので、それで、その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に示されるように、BeingCompiled（コンパイル中）であるならば、BuildState（生成状態）はCompiled（コンパイル済み）とセットされ、かつDone（実行）が機能ブロック1023で返される。
【００９８】
機能ConditionallyCompile（条件付きコンパイル）のための擬似コードは次のとおりである。
【００９９】
【表８】
【０１００】
【表９】
【０１０１】
エラーを後処理するための方法
エラーを後処理するための方法はBuild（生成）処理の第４段階である。どのようなエラーでも生成中に発生したならば、PostProcessEroors（エラーの後処理）は生成の終わりで呼出される。InternalErrorList（内部エラー・リスト）の各リファレンスに関しては、リファレンスのBuildState（生成状態）がCompileError（コンパイル・エラー）ならば、このBuildState（生成状態）はNeedToCompileコンパイルを要する）に変更される。リファレンスのBuildState（生成状態）がUncertainError（不確定エラー）ならば、BuildState（生成状態）はCompiled（コンパイル済み）に変更される。
【０１０２】
InternalErrorList（内部エラー・リスト）に関する全てのリファレンスが処理されたとき、このリストの全てのエントリはクリアされる。プログラマのための便宜として、プロジェクトのErrorListがあるエントリを含む場合、ウィンドウまたはBrower（ブラウザ）がプロジェクトのErrorList（プロジェクトのエラー・リスト）に対して開かれる。
【０１０３】
PostProcessEroors（エラーの後処理）機能のための擬似コードは次のとおりである。
【０１０４】
【表１０】
【０１０５】
本発明は、特定のプログラミング環境で好ましい実施例に関して記載されているが、当業者は、本発明が添付の請求の範囲の精神および範囲内において変更して実施され得ることを理解できるであろう。
【図面の簡単な説明】
【０１０６】
【図１】第１図は、本発明が実施される、高分解能グラフィック・ディスプレイ装置およびマウスのようなカーソル指示装置をサポートすることができる汎用コンピュータ・システムを示す図である。
【図２】第２図は、コンピュータ・システムの主要な要素をより詳細に示す、第１図に示された汎用コンピュータ・システムのブロック図である。
【図３】第３図は、プログラムを構成する構成要素のコレクションを概念形式で示すブロック図である。
【図４】第４図は、本発明の主要な機能性を示すブロック図である。
【図５Ａ】第５Ａ図は、一緒にまとめて、BuildStateによる編集変化を登録するための論理のフローチャートである。
【図５Ｂ】第５Ｂ図は、一緒にまとめて、BuildStateによる編集変化を登録するための論理のフローチャートである。
【図５Ｃ】第５Ｃ図は、一緒にまとめて、BuildStateによる編集変化を登録するための論理のフローチャートである。
【図５Ｄ】第５Ｄ図は、一緒にまとめて、BuildStateによる編集変化を登録するための論理のフローチャートである。
【図６】第６図は、本発明による生成機構(build mechanism)の動作の第１ステージの可能な要素を決定するための論理を示すフローチャートである。
【図７】第７図は、本発明による生成機構の動作の第２ステージのインターフェース処理の論理を示すフローチャートである。
【図８】第８図は、本発明による生成機構の動作の第３ステージのインプリメンテーション処理の論理を示すフローチャートである。
【図９】第９図は、本発明によるコンパイラによって呼出されたGetDeclarations機能の論理を示すフローチャートである。
【図１０Ａ】第１０Ａ図は、一緒にまとめて、条件付きコンパイル機能の論理を示すフローチャートである。
【図１０Ｂ】第１０Ｂ図は、一緒にまとめて、条件付きコンパイル機能の論理を示すフローチャートである。
【特許請求の範囲】
【請求項１】
複数のコンポーネント(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)し、コンパイル・リストに変更リスト項目が追加されるときに変更リスト項目を処理し、変更された構成要素に従属する構成要素を識別し、従属する構成要素をコンパイル・リストに追加するステップを含む特許請求の範囲第４項に記載の方法。
【請求項６】
Uncertain（不確定）の値を有する従属する構成要素を付加(905)するステップを含む特許請求の範囲第５項に記載の方法。
【請求項７】
前記コンパイル・リストに付加される各項目を再帰的に処理(601)するステップを含む特許請求の範囲第５項に記載の方法。
【請求項８】
各構成要素が、インターフェース(Interface)(311)とよばれる公開(public)部分およびインプリメンテーション(Implementation)(312)とよばれる非公開(private)部分に分割される特性セットからなり、構成要素の従属性がインターフェース部分にのみ関連され、従属性リストを保持するステップは、前記構成要素の前記公開部分および非公開部分に対してInterfaceCompileList（インターフェース・コンパイル・リスト）(701)およびImplementationCompileList（インプリメンテーション・コンパイル・リスト）(801)をそれぞれ保持することによって実行される特許請求の範囲第１項に記載の方法。
【請求項９】
コンパイルするステップが、ImplementationCompileList（インプリメンテーション・コンパイル・リスト）で参照される前記構成要素をコンパイル(806)する前に、最初に前記InterfaceCompileList（インターフェース・コンパイル・リスト）で保持される前記構成要素を最初にコンパイル(705)することによって実行される特許請求の範囲第８項に記載の方法。
【請求項１０】
構成要素がBuildState（生成状態）値を有し、InterfaceCompileList（インターフェース・コンパイル・リスト）に関する前記BuildState（生成状態）値が、BeingCompiled（コンパイル中）またはNeedToCompile（コンパイルを要する）またはUncertain（不確定）を含んでおり、InterfaceCompileList（インターフェース・コンパイル・リスト）に関する各リファレンスに対して、前記BuildState（生成状態）がBeingCompiled（コンパイル中）またはNeedToCompile（コンパイルを要する）の場合、前記BuildState（生成状態）をBeingCompiled（コンパイル中）とセット(705)し、次に前記構成要素をコンパイルし、前記BuildState（生成状態）がUncertrain（不確定）の場合前記BuildState（生成状態）をBeingCompiled（コンパイル中）とセットし、次に前記構成要素を条件付きでコンパイルするステップを含む特許請求の範囲第９項に記載の方法。
【請求項１１】
コンパイラが前記構成要素に対してコンパイルを成功した場合、次の構成要素を処理する前に前記構成要素の前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(708)するステップを実行する特許請求の範囲第１０項に記載の方法。
【請求項１２】
コンパイラがAbort（打ち切り）の値を返す(706)場合、次の構成要素を処理する特許請求の範囲第１０項に記載の方法。
【請求項１３】
コンパイラがコンパイルするステップで、Error（エラー）(709)の値を返す場合、前記構成要素の前記BuildState（生成状態）値をCompileError（コンパイル・エラー）とセットし、かつ次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加(710)する特許請求の範囲第１０項に記載の方法。
【請求項１４】
コンパイラが値Error（エラー）を返す場合、前記構成要素の前記BuildState（生成状態）値をUncertainError（不確定エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加(715)する請求の範囲第10項によるコンピュータ・プログラムを生成する方法。
【請求項１５】
コンパイラが前記構成要素をコンパイルするとき、次の構成要素を処理(701)する前に前記構成要素の前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(708)するステップを実行するが、コンパイラがAbort（打ち切り）の値を返す場合、前記構成要素の前記BuildState（生成状態）値をCompileError（コンパイル・エラー）とセットし、次の構成要素を処理(701)する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加し、コンパイラが値Error（エラー）を返す場合、前記BuildState（生成状態）値をUncertrainError（不確定エラー）とセット(710)し、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加する特許請求の範囲第１０項によるコンピュータ・プログラムを生成する方法。
【請求項１６】
ImplementationCompileList（インプリメンテーション・コンパイル・リスト）に関する前記BuildState（生成状態）値が、NeedToCompile（コンパイルを要する）またはUncertain（不確定）を含み、ImplementationCompileList（インプリメンテーション・コンパイル・リスト）に関する各リファレンスに対して、
(a)前記BuildState（生成状態）値が、NeedToCompile（コンパイルを要する）である場合、前記BuildState（生成状態）をBeingCompiled（コンパイル中）とセットし、つぎに前記構成要素をコンパイル(806)するステップと、
(b)前記BuildState（生成状態）値がUncertain（不確定）である場合、つぎに前記構成要素を処理する前に前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(804)するステップと
を含んでいる特許請求の範囲第１０項に記載の方法。
【請求項１７】
コンパイラがコンパイルするステップで、前記構成要素に対してコンパイルが成功した場合、次の前記構成要素を処理する前に前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(708)するステップをさらに実行する特許請求の範囲第１４項によるコンピュータ・プログラムを生成する方法。
【請求項１８】
コンパイラがコンパイルするステップで、値Error（エラー）を返す場合、前記BuildState（生成状態）値をCompileError（コンパイル・エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加(710)する特許請求の範囲第１４項によるコンピュータ・プログラムを生成する方法。
【請求項１９】
コンパイラが前記構成要素に対してコンパイルが成功した場合、次の前記構成要素を処理する前に前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(705)するステップをさらに実行するが、コンパイラがコンパイルするステップで値Error（エラー）を返す場合、前記構成要素の前記BuildState（生成状態）値をCompileError（コンパイル・エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加(710)する特許請求の範囲第１４項によるコンピュータ・プログラムを生成する方法。
【請求項２０】
前記変更リストの各構成要素に対して、インターフェース部分が変更された場合、前記構成要素は前記InterfaceCompileList（インターフェース・コンパイル・リスト）(708)に付加され、Implementation（インプリメンテーション）部分が変更され、この変更が他の構成要素に影響を及ぼす場合は、前記構成要素はInterfaceCompileList（インターフェース・コンパイル・リスト）に付加(906)され、それ以外の場合は、前記構成要素はImplementationCompileList（インプリメンテーション・コンパイル・リスト）に付加される特許請求の範囲第１４項に記載の方法。
【請求項２１】
コンパイラが前記コンパイル(705)するステップまたは条件付きでコンパイル(712)するステップのいずれかで前記リファレンスがコンパイルに成功した場合、すべてのリファレンスが処理(701)されるまで次のリファレンスを処理していく請求の範囲第19項によるコンピュータ・プログラムを生成する方法。
【請求項２２】
少なくとも１つの名前をコンパイルし検出するステップ(c)による請求の範囲第１項に記載のコンピュータ・プログラムを生成する方法において、さらに
(f)宣言(901)のデータベースに問い合わせをしてコンポーネントの宣言の少なくとも１つの名前を決定するステップと、
(g)コンポーネントの宣言の状態を決定(903,910,905または908)するステップと
からなることを特徴とするコンピュータ・プログラムを生成する方法。
【請求項２３】
前記状態がCompiled（コンパイル済み）状態を示すならば、前記構成要素の宣言の前記状態を使用することによってコンパイルを継続(903)するステップを含んでいる特許請求の範囲第２２項に記載の方法。
【請求項２４】
Error値（エラー）を返し、前記状態がエラー状態を示すならば、前記構成要素の宣言の現在の構成要素状態の処理を停止(910)するステップを含んでいる特許請求の範囲第２３項に記載の方法。
【請求項２５】
abort（打ち切り）値を返し、かつ前記状態が打ち切り状態を示すならば、前記構成要素の宣言の現在の構成要素状態の処理を停止(905)するステップを含んでいる特許請求の範囲第２２項に記載の方法。
【請求項２６】
構成要素の宣言の少なくとも１つの名前を決定するように宣言のデータベースに問い合わせをするステップが、
(h)前記構成要素の状態がCompiled（コンパイル済み）状態であるかどうかを決定(903)するステップと、
(i)前記状態がコンパイル済みであるならば、前記Compiled（コンパイル済み）宣言および関連するコンパイル(Compile)状態を返す(904)ステップと
を含んでいる特許請求の範囲第２２項に記載の方法。
【請求項２７】
前記コンパイル状態がエラーと宣言された場合、エラーのCompile（コンパイル）状態を返すことを含んでいる特許請求の範囲第２６項に記載の方法。
【請求項２８】
(h)前記構成要素の状態がUncertain（不確定）であるかまたはNeedtocompile（コンパイルを要する）であるかどうかを決定(910)するステップと、
(i)前記構成要素をコンパイル・リストに関する第一の項目として記憶(906)し、かつabort（うちきり）状態を返すステップとを
含んでいる特許請求の範囲第２２項に記載の方法。
【請求項２９】
複数のコンポーネント(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)し、コンパイル・リストに変更リスト項目が追加されるときに変更リスト項目を処理し、変更された構成要素に従属する構成要素を識別し、従属する構成要素をコンパイル・リストに追加する手段を含む特許請求の範囲第３２項に記載のシステム。
【請求項３４】
Uncertain（不確定）の値を有する従属構成要素を付加(905)する手段を含む特許請求の範囲第３３項に記載のシステム。
【請求項３５】
前記コンパイル・リストに付加される各項目を再帰的に処理(601)する手段を含む特許請求の範囲第３３項に記載のシステム。
【請求項３６】
各構成要素が、インターフェース(Interface)(311)とよばれる公開(public)部分およびインプリメンテーション(Implementation)(312)とよばれる非公開(private)部分に分割される特性セットからなり、構成要素の従属性が前記インターフェース部分にのみ関連され、従属性リストを保持することは、前記構成要素の前記公開部分および非公開部分に対してInterfaceCompileList（インターフェース・コンパイル・リスト）(701)およびImplementationCompileList（インプリメンテーション・コンパイル・リスト）(801)をそれぞれ保持することによって実行される特許請求の範囲第２９項に記載のシステム。
【請求項１】
複数のコンポーネント(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)し、コンパイル・リストに変更リスト項目が追加されるときに変更リスト項目を処理し、変更された構成要素に従属する構成要素を識別し、従属する構成要素をコンパイル・リストに追加するステップを含む特許請求の範囲第４項に記載の方法。
【請求項６】
Uncertain（不確定）の値を有する従属する構成要素を付加(905)するステップを含む特許請求の範囲第５項に記載の方法。
【請求項７】
前記コンパイル・リストに付加される各項目を再帰的に処理(601)するステップを含む特許請求の範囲第５項に記載の方法。
【請求項８】
各構成要素が、インターフェース(Interface)(311)とよばれる公開(public)部分およびインプリメンテーション(Implementation)(312)とよばれる非公開(private)部分に分割される特性セットからなり、構成要素の従属性がインターフェース部分にのみ関連され、従属性リストを保持するステップは、前記構成要素の前記公開部分および非公開部分に対してInterfaceCompileList（インターフェース・コンパイル・リスト）(701)およびImplementationCompileList（インプリメンテーション・コンパイル・リスト）(801)をそれぞれ保持することによって実行される特許請求の範囲第１項に記載の方法。
【請求項９】
コンパイルするステップが、ImplementationCompileList（インプリメンテーション・コンパイル・リスト）で参照される前記構成要素をコンパイル(806)する前に、最初に前記InterfaceCompileList（インターフェース・コンパイル・リスト）で保持される前記構成要素を最初にコンパイル(705)することによって実行される特許請求の範囲第８項に記載の方法。
【請求項１０】
構成要素がBuildState（生成状態）値を有し、InterfaceCompileList（インターフェース・コンパイル・リスト）に関する前記BuildState（生成状態）値が、BeingCompiled（コンパイル中）またはNeedToCompile（コンパイルを要する）またはUncertain（不確定）を含んでおり、InterfaceCompileList（インターフェース・コンパイル・リスト）に関する各リファレンスに対して、前記BuildState（生成状態）がBeingCompiled（コンパイル中）またはNeedToCompile（コンパイルを要する）の場合、前記BuildState（生成状態）をBeingCompiled（コンパイル中）とセット(705)し、次に前記構成要素をコンパイルし、前記BuildState（生成状態）がUncertrain（不確定）の場合前記BuildState（生成状態）をBeingCompiled（コンパイル中）とセットし、次に前記構成要素を条件付きでコンパイルするステップを含む特許請求の範囲第９項に記載の方法。
【請求項１１】
コンパイラが前記構成要素に対してコンパイルを成功した場合、次の構成要素を処理する前に前記構成要素の前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(708)するステップを実行する特許請求の範囲第１０項に記載の方法。
【請求項１２】
コンパイラがAbort（打ち切り）の値を返す(706)場合、次の構成要素を処理する特許請求の範囲第１０項に記載の方法。
【請求項１３】
コンパイラがコンパイルするステップで、Error（エラー）(709)の値を返す場合、前記構成要素の前記BuildState（生成状態）値をCompileError（コンパイル・エラー）とセットし、かつ次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加(710)する特許請求の範囲第１０項に記載の方法。
【請求項１４】
コンパイラが値Error（エラー）を返す場合、前記構成要素の前記BuildState（生成状態）値をUncertainError（不確定エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加(715)する請求の範囲第10項によるコンピュータ・プログラムを生成する方法。
【請求項１５】
コンパイラが前記構成要素をコンパイルするとき、次の構成要素を処理(701)する前に前記構成要素の前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(708)するステップを実行するが、コンパイラがAbort（打ち切り）の値を返す場合、前記構成要素の前記BuildState（生成状態）値をCompileError（コンパイル・エラー）とセットし、次の構成要素を処理(701)する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加し、コンパイラが値Error（エラー）を返す場合、前記BuildState（生成状態）値をUncertrainError（不確定エラー）とセット(710)し、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加する特許請求の範囲第１０項によるコンピュータ・プログラムを生成する方法。
【請求項１６】
ImplementationCompileList（インプリメンテーション・コンパイル・リスト）に関する前記BuildState（生成状態）値が、NeedToCompile（コンパイルを要する）またはUncertain（不確定）を含み、ImplementationCompileList（インプリメンテーション・コンパイル・リスト）に関する各リファレンスに対して、
(a)前記BuildState（生成状態）値が、NeedToCompile（コンパイルを要する）である場合、前記BuildState（生成状態）をBeingCompiled（コンパイル中）とセットし、つぎに前記構成要素をコンパイル(806)するステップと、
(b)前記BuildState（生成状態）値がUncertain（不確定）である場合、つぎに前記構成要素を処理する前に前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(804)するステップと
を含んでいる特許請求の範囲第１０項に記載の方法。
【請求項１７】
コンパイラがコンパイルするステップで、前記構成要素に対してコンパイルが成功した場合、次の前記構成要素を処理する前に前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(708)するステップをさらに実行する特許請求の範囲第１４項によるコンピュータ・プログラムを生成する方法。
【請求項１８】
コンパイラがコンパイルするステップで、値Error（エラー）を返す場合、前記BuildState（生成状態）値をCompileError（コンパイル・エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加(710)する特許請求の範囲第１４項によるコンピュータ・プログラムを生成する方法。
【請求項１９】
コンパイラが前記構成要素に対してコンパイルが成功した場合、次の前記構成要素を処理する前に前記BuildState（生成状態）値をCompiled（コンパイル済み）とセット(705)するステップをさらに実行するが、コンパイラがコンパイルするステップで値Error（エラー）を返す場合、前記構成要素の前記BuildState（生成状態）値をCompileError（コンパイル・エラー）とセットし、次の構成要素を処理する前に前記プロジェクト構成要素のエラー・リストにリファレンスを付加(710)する特許請求の範囲第１４項によるコンピュータ・プログラムを生成する方法。
【請求項２０】
前記変更リストの各構成要素に対して、インターフェース部分が変更された場合、前記構成要素は前記InterfaceCompileList（インターフェース・コンパイル・リスト）(708)に付加され、Implementation（インプリメンテーション）部分が変更され、この変更が他の構成要素に影響を及ぼす場合は、前記構成要素はInterfaceCompileList（インターフェース・コンパイル・リスト）に付加(906)され、それ以外の場合は、前記構成要素はImplementationCompileList（インプリメンテーション・コンパイル・リスト）に付加される特許請求の範囲第１４項に記載の方法。
【請求項２１】
コンパイラが前記コンパイル(705)するステップまたは条件付きでコンパイル(712)するステップのいずれかで前記リファレンスがコンパイルに成功した場合、すべてのリファレンスが処理(701)されるまで次のリファレンスを処理していく請求の範囲第19項によるコンピュータ・プログラムを生成する方法。
【請求項２２】
少なくとも１つの名前をコンパイルし検出するステップ(c)による請求の範囲第１項に記載のコンピュータ・プログラムを生成する方法において、さらに
(f)宣言(901)のデータベースに問い合わせをしてコンポーネントの宣言の少なくとも１つの名前を決定するステップと、
(g)コンポーネントの宣言の状態を決定(903,910,905または908)するステップと
からなることを特徴とするコンピュータ・プログラムを生成する方法。
【請求項２３】
前記状態がCompiled（コンパイル済み）状態を示すならば、前記構成要素の宣言の前記状態を使用することによってコンパイルを継続(903)するステップを含んでいる特許請求の範囲第２２項に記載の方法。
【請求項２４】
Error値（エラー）を返し、前記状態がエラー状態を示すならば、前記構成要素の宣言の現在の構成要素状態の処理を停止(910)するステップを含んでいる特許請求の範囲第２３項に記載の方法。
【請求項２５】
abort（打ち切り）値を返し、かつ前記状態が打ち切り状態を示すならば、前記構成要素の宣言の現在の構成要素状態の処理を停止(905)するステップを含んでいる特許請求の範囲第２２項に記載の方法。
【請求項２６】
構成要素の宣言の少なくとも１つの名前を決定するように宣言のデータベースに問い合わせをするステップが、
(h)前記構成要素の状態がCompiled（コンパイル済み）状態であるかどうかを決定(903)するステップと、
(i)前記状態がコンパイル済みであるならば、前記Compiled（コンパイル済み）宣言および関連するコンパイル(Compile)状態を返す(904)ステップと
を含んでいる特許請求の範囲第２２項に記載の方法。
【請求項２７】
前記コンパイル状態がエラーと宣言された場合、エラーのCompile（コンパイル）状態を返すことを含んでいる特許請求の範囲第２６項に記載の方法。
【請求項２８】
(h)前記構成要素の状態がUncertain（不確定）であるかまたはNeedtocompile（コンパイルを要する）であるかどうかを決定(910)するステップと、
(i)前記構成要素をコンパイル・リストに関する第一の項目として記憶(906)し、かつabort（うちきり）状態を返すステップとを
含んでいる特許請求の範囲第２２項に記載の方法。
【請求項２９】
複数のコンポーネント(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)し、コンパイル・リストに変更リスト項目が追加されるときに変更リスト項目を処理し、変更された構成要素に従属する構成要素を識別し、従属する構成要素をコンパイル・リストに追加する手段を含む特許請求の範囲第３２項に記載のシステム。
【請求項３４】
Uncertain（不確定）の値を有する従属構成要素を付加(905)する手段を含む特許請求の範囲第３３項に記載のシステム。
【請求項３５】
前記コンパイル・リストに付加される各項目を再帰的に処理(601)する手段を含む特許請求の範囲第３３項に記載のシステム。
【請求項３６】
各構成要素が、インターフェース(Interface)(311)とよばれる公開(public)部分およびインプリメンテーション(Implementation)(312)とよばれる非公開(private)部分に分割される特性セットからなり、構成要素の従属性が前記インターフェース部分にのみ関連され、従属性リストを保持することは、前記構成要素の前記公開部分および非公開部分に対してInterfaceCompileList（インターフェース・コンパイル・リスト）(701)およびImplementationCompileList（インプリメンテーション・コンパイル・リスト）(801)をそれぞれ保持することによって実行される特許請求の範囲第２９項に記載のシステム。
【図１】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図５Ｄ】
【図６】
【図７】
【図８】
【図９】
【図１０Ａ】
【図１０Ｂ】
【図２】
【図３】
【図４】
【図５Ａ】
【図５Ｂ】
【図５Ｃ】
【図５Ｄ】
【図６】
【図７】
【図８】
【図９】
【図１０Ａ】
【図１０Ｂ】
【公開番号】特開２００７−１２０８８（Ｐ２００７−１２０８８Ａ）
【公開日】平成１９年１月１８日（２００７．１．１８）
【国際特許分類】
【出願番号】特願２００６−２３９３７０（Ｐ２００６−２３９３７０）
【出願日】平成１８年９月４日（２００６．９．４）
【分割の表示】特願平７−５０２７６２の分割
【原出願日】平成６年１月３日（１９９４．１．３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
【出願人】（５００２６９９５６）オブジェクト テクノロジー ライセンシング コーポレイション (12)
【Ｆターム（参考）】
【公開日】平成１９年１月１８日（２００７．１．１８）
【国際特許分類】
【出願日】平成１８年９月４日（２００６．９．４）
【分割の表示】特願平７−５０２７６２の分割
【原出願日】平成６年１月３日（１９９４．１．３）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．フロッピー
【出願人】（５００２６９９５６）オブジェクト テクノロジー ライセンシング コーポレイション (12)
【Ｆターム（参考）】
[ Back to top ]