JP2002527814A

JP2002527814A - コンポーネント・ベース型ソース・コード・ジェネレータ

Info

Publication number: JP2002527814A
Application number: JP2000576356A
Authority: JP
Inventors: ブラサール、ミシェル
Original assignee: コデイジェンテクノロジーズコーポレイション
Priority date: 1998-10-13
Filing date: 1999-10-12
Publication date: 2002-08-27
Also published as: EP1121637B1; DE69907714D1; CN1323415A; AU6073099A; CA2347191A1; BR9914537A; DE69907714T2; HK1040787A1; EP1121637A1; IL142587A0; WO2000022517A1; ATE239937T1

Abstract

(57)【要約】コンポーネント・ベース型ソース・コード・ジェネレータは１セットの生成命令と１セットのパラメータを使用して、準繰返しおよび繰返しソース・コードを生成する。開発者は、生成命令を使用して何を生成するかをコード・ジェネレータに指定する。１セットの生成命令内で、開発者は目的コンポーネントおよび生成すべきコードを指定する。生成プロセスは、モデリング・ツールに含まれる情報を使用する。したがって、生成されたコードを開発者が直接手直しする必要がなく、保守時間が大幅に短縮し、誤りが最小限になり、コードの一貫性が改善される。

Description

【発明の詳細な説明】

【０００１】本発明は、１９９８年１０月１３日出願の米国仮特許出願第６０／１０４，０
１４号および１９９９年７月２３日出願の米国仮特許出願第６０／１４５，２１
４号の３５ＵＳＣ１１９（ｅ）に基づく優先権を主張する。

【０００２】

【発明が属する技術分野】

本発明は、ソース・コード・ジェネレータに関し、さらに詳しくは、コンポー
ネント・ベース型プログラミングの文脈で生成されるソース・コードに関する。
特に、このジェネレータは、１セットの生成命令およびパラメータを使用して、
開発者が容易に使用できる準繰返しおよび繰返しソース・コードを生成する。

【０００３】

【発明の背景】

ソフトウェア開発プロセスは近年、プログラミング、プロジェクト管理、およ
びシステム統合にオブジェクト指向モデルを使用することが増えた結果、劇的に
変化した。

【０００４】エンタプライズ・アプリケーションは、抽象的な業務慣行を特定のプロセスお
よび事象駆動インタラクションに変える大型の複雑なシステムである。これらの
アプリケーションは、組織の方法の中核を形成する。

【０００５】企業は、これらの「最善の慣行」を多数の方法で捕捉し、純化することができ
る。多くの場合、組織全体のためのカスタム・ソフトウェアを作成することは無
駄であり、かつ企業の能力を超えている。その結果、これらの会社はソフトウェ
アの解決をエンタプライズ・アプリケーション・ソフトウェアのベンダに頼る。
ＥｎｔｅｒｐｒｉｓｅＲｅｓｏｕｒｃｅＰｌａｎｎｉｎｇ（Ｐｅｏｐｌｅｓ
ｏｆｔ、およびＳＡＰのようなベンダから出ているＥＲＰ）、Ｃｕｓｔｏｍｅｒ
ＲｅｌａｔｉｏｎｓｈｉｐＭａｎａｇｅｍｅｎｔ（Ｖａｎｔｉｖｅ、Ｃｌａ
ｒｉｆｙ、Ｓｉｅｂｅｌ）、およびＰｒｏｆｅｓｓｉｏｎａｌＳｅｒｖｉｃｅ
ｓＡｕｔｏｍａｔｉｏｎ（Ｎｉｋｕ、Ｖｉｓｔｏ）と様々な名前で呼ばれる
これらのシステムは、業務を全く簡単に実行する。

【０００６】しかし各々の会社は異なっており、これらの相違が、各企業を競合し得るもの
にしている。会社はその明確な能力を電子的プロセスに翻訳するために、そのエ
ンタプライズ・アプリケーションを彼らが作業する方法に適合させなければなら
ない。これは、時間の経過と共にアプリケーションを調整、変更、および成長さ
せることを意味する。

【０００７】このための１つの方法は、「パラメータ化（parameterization）」として知ら
れる。アプリケーションの動作を業務の性質に適合させるために、パラメータ化
では、訓練されたＥＲＰ技術者が、多くのパラメータおよび変数を構成する。

【０００８】既存のエンタプライズ・アプリケーションを修正する第２の方法は、既存の汎
用アプリケーションを使用し、そのソース・コードを直接修正することである。
最近まで、その独特な業務慣行のために高度に特殊化したアプリケーションを必
要とする企業は、ライセンス料の支払いと、これらの汎用アプリケーションの１
つから莫大な量のコードを書き換える問題に直面していた。

【０００９】会社は、既製のアプリケーションによって彼らにもたらされる制御と個別化の
欠如に対する対応として、ソース・コードの個別化を使用する。同様に、彼らは
ライセンスされたソフトウェアまたは社内で開発されたシステムの不十分な保全
および複雑なコード化に対する対応として、パラメータ化されたＥＲＰを使用す
る。これらの２つの手法に対する強力な代替策が、オブジェクト指向フレームワ
ーク方式である。

【００１０】アプリケーションの開発は常に、１セットの不完全で不正確な、そしてときに
は矛盾または相反する要求事項から始まる。複雑なシステムの開発者および分析
者にとって、作成しようとしているものを最初から明確に定義することは、困難
な仕事である。

【００１１】オブジェクト指向プログラミング方法論は、この不正確さを実世界のより正確
なモデル化を通して是正しようと努める。コード化の手続きモデルの後継者とし
て、オブジェクト指向技術は、異種オブジェクトの統合を容易にするために、共
通の語彙およびよく定義された境界を作成する。これは、開発者がアプリケーシ
ョンの範囲およびインタラクションを１セットの離散コンポーネントとして定義
するのに役立ち、設計を改善し、その後のソフトウェアの手直しを促進する。

【００１２】開発者およびシステム分析者は、特定のプログラミング言語、ならびにアプリ
ケーションがその上で実行されるオペレーティング・システムおよびハードウェ
アの物理的実現から抽象化される、アプリケーションの業務目的を論理的に記述
するために、モデリング・ツールと呼ばれる高水準設計ツールを使用する。

【００１３】アプリケーションの抽象記述を持つことにより、それがその存続期間中に経験
する、種々のソフトウェア反復を作成し維持する負担が軽減される。ジョブが１
００万行のプログラム内で１個の機能を捜し出すことである場合、モデルが提供
できる手引きは非常に貴重のものになる。

【００１４】モデリング・ベンダ間で一貫した方法論を促進するため、業界は、アプリケー
ションの分析および設計中に使用する要素を標準化するために、汎用モデル化言
語（ＵＭＬ）を開発した。ＵＭＬの幅広い受入れおよびコンポーネント・ベース
型開発の出現により、モデリング・ツールの使用は、オブジェクト指向型開発の
出発点とされるようになった。

【００１５】会社は、スクラッチからアプリケーションを設計するよりむしろ、持続性、セ
キュリティ、およびトランザクションのようなサービスを提供するフレームワー
ク・ベースの解決策を利用する多層（multi-tier）ｅコマース・アプリケーショ
ンを開発する。特定のフレームワークは、所与の問題ドメインの再使用可能な設
計解決策を構成する協力クラスの拡張可能なライブラリを提供するオブジェクト
指向抽象化である。本質的に、フレームワークは包括的解決を提供し、それに対
して開発者は、その特定のプロセスをフレームワークで指定するために、各コン
ポーネントでコンポーネント対フレームワーク統合コードとして働く特殊化コー
ドを実現する必要がある。

【００１６】フレームワーク方式は、ライセンスによる手続きソース・コードの略式代替策
の劇的改善である。フレームワークは、再使用により資本集約的なソフトウェア
投資をてこ入れし、さらにより高い水準のアプリケーション・プログラミング・
インタフェースを提供するので、アプリケーションをずっと迅速に開発すること
ができる。

【００１７】市販のフレームワークを個別化する場合、または新しい機能性を社内フレーム
ワークに追加する場合、全ての関与するコンポーネントについて、コンポーネン
ト対フレームワーク統合コードの変更がしばしば必要になる。そのような変更の
過程中にコードを維持することは、単調で誤りを生じやすいプロセスである。フ
レームワーク・ベース型解決策の人気と共に、開発者の作業でそれが占める部分
はますます大きくなっている。このコードがコード・ジェネレータによって生成
される場合でも、コード・ジェネレータは会社の要求事項がフレームワーク内で
適切に実現される程度にまで個別化することができないので、所与のフレームワ
ークに関与する全てのコンポーネントで生成された統合コードを、開発者は手動
で変更しなけれなばならない。また、一般的なコード・ジェネレータがモデリン
グ・ツールにうまく統合されることはめったにないので、たいていのフレームワ
ークは、会社がその企業レポジトリ・データを集中化したり捕獲するのを妨げる
。

【００１８】フレームワークは、いずれかの業界における総合ビジネス・アプリケーション
を作成するために使用されるだけでなく、ユーザ・インタフェース、グラフィッ
クス・ライブラリ、マルチメディア・システム、および印刷解決策；ドライバお
よびネットワーク・プロトコルなどの低水準サービス；Ｅｎｔｅｒｐｒｉｓｅ
ＪａｖａＢｅａｎｓ^TMコンポーネント・モデルおよびＣＯＲＢＡ（Ｃｏｍｍｏｎ
ＯｂｊｅｃｔＲｅｑｕｅｓｔＢｒｏｋｅｒＡｒｃｈｉｔｅｃｔｕｒｅの
略）オブジェクト・サービスなどによって提供されるものなどのインフラストラ
クチャ・サービスの共通セット、ならびにアプリケーションの作成をさらに高速
化する開発ツールの開発にも使用される。

【００１９】フレームワークはソフトウェア・コンポーネントを高水準汎用解決策にリンク
するので、フレームワークとコンポーネントが同期し続けることが肝要である。
これは一般的に、フレームワークおよびコンポーネントの両方を手動で修正する
ことによって達成される。

【００２０】しかし、幾つかの特定の場合には、モデリング・ツール内の情報を使用して、
手動的介在無しで、統合コードの部分を生成することができる。これは、コード
生成として知られる。コード生成システムは、開発者をその設計においてより抽
象的なレベルで作業させることにより、アプリケーション開発を能率化すること
を約束する。

【００２１】残念ながら、一般的なコード・ジェネレータは、不完全なコードを生成する傾
向があり、これは手動で変更するか、または完全に廃棄することさえもしなけれ
ばならない。

【００２２】開発者にとって２つの最も時間のかかる繰返し作業は、'get'および'set'選択
子として知られるコンポーネントの各プロパティに対応付けられる特殊化ソフト
ウェア方法を書くなどの繰返しコーディング方式、およびフレームワークが呼び
出す特定方式の準繰返しコーディングである。開発者がフレームワーク内の機能
性を拡張するとき、それは、既存のコンポーネントの１つを下位分類し、その機
能性を拡張することによって行われる。コンポーネント対フレームワーク統合コ
ードにおけるこれらの変更を反映するために、開発者は、新しい機能性に応じた
変更を手動的に行わなければならない。準繰返しコーディングは誤りを発生しや
すく、その単調さは開発者の満足感および生産性を低下する。

【００２３】モデリング・ツール、永続性ツール（persistence tool）、および総合開発環
境ベンダによって提供される一般的なコード生成解決策は、繰返しおよび準繰返
しコーディングの影響を軽減することを意図しているが、そうする中で、それら
はフレームワーク方式が開発者に提供する柔軟性を低下させる。この理由から、
開発者は、生成される方法名を変更できず、特定の方法に対して生成されるコー
ドを修正できず、文脈情報に基づいて同一方法名に対して異なる内容を生成でき
ず、社内で開発されたフレームワークに対して個別化されたコードを生成できず
、関連する全てのコンポーネントに対してモデリング・ツール内で事前に定義さ
れなければ、１セットのコンポーネントにまたがる方法名を生成できず、Ｅｎｔ
ｅｒｐｒｉｓｅＪａｖａＢｅａｎｓ^TM ＣｏｍｐｏｎｅｎｔＭｏｄｅｌなど
主流の解決策のための関連要求コードを持つ誘導コンポーネントを生成できない
。

【００２４】フレームワークとその関連コンポーネントとの間の統合を維持するためのコー
ドを生成する方法は幾つかある。

【００２５】（手動コーディング）アプリケーションを保守する最も簡単な方法は、アプリケーションの繰返し部
分および準繰返し部分を手動でコード化することである。これは、結果として得
られるソフトウェアに対する制御の程度が、一般的なコード・ジェネレータより
大きくなるが、それは費用が高くつき、誤りを生じやすく、単調な技法であり、
プロジェクトを危険にさらし、開発者の不満をもたらす。

【００２６】（一般的な総合コード・ジェネレータ）多くのモデリング・ツールは、総合コード・ジェネレータを含む。これらは少
量の繰返しまたは準繰返しコード、各々の意図された方法の骨組を生成し、それ
は、方法の内容のフォーマットに関し開発者を誘導する。残念ながら、結果とし
て得られるコードは、大抵の場合アプリケーションの完全な機能性を果たすため
にまだ必要とされる、以前に挿入した手動コードを喪失することなく再生される
ことはめったにない。

【００２７】そのようなコーディング・ツールによりコード生成プロセスを制御することは
、これらの限界に対する潜在的な取組みである。一部のモデリング・ツール・ベ
ンダは、そのコード生成アルゴリズムをスクリプト言語の形で公表している。

【００２８】しかし、有用なコードを生成するために、開発チームは今これらのスクリプト
を維持しなければならないので、これらのスクリプトを修正すると、開発プロセ
スはさらに複雑になり、そうするには、特定のアプリケーションおよびモデリン
グ・ツールについて、オブジェクト指向開発環境によって要求されるよりずっと
深い理解が要求される。さらに、スクリプトを修正することによって、組織は自
らをベンダのコード・ジェネレータ・サポート・スタッフから遠ざけ、モデリン
グ・ベンダが新しいソフトウェア・バージョンを発表するときに、アップグレー
ド努力を蝕む。

【００２９】（スクリプト）場合によっては、モデリング・ツールのコード生成アルゴリズムにアクセスす
ることさえ無く、開発者は依然としてスクリプト言語を使用して、特定の目的言
語のための個別化ソース・コード・ジェネレータを実際に作成することができる
。

【００３０】この手法は熟練した開発チームを必要とし、開発および保守の負担を増大し、
開発者は今、コードを手動で保守するよりむしろ、コードを生成するスクリプト
を保守しなければならない。残念ながら、結果として得られるコードは使用しに
くく、目的ソース・コードはスクリプト言語の中で分断された断片として見つか
り、適切なシーケンスに修正しなければならないので、保守と進化が困難である
。これは、これらのツールの能力をはるかに超えて広がる問題である。さらに、
新しい言語または開発環境を目的にしてスクリプトを変更することは、圧倒され
る挑戦である。

【００３１】（４ＧＬ）第４世代言語（４ＧＬ）は、開発者に、目的プログラミング言語による直接コ
ード化ではなくむしろ、完全に抽象レベルで作業させる。４ＧＬシステムは、ア
プリケーションを生成するための仕様を提供するために、ＵＭＬ表記法、所有権
のある言語、またはビジュアル・プログラミング環境のいずれかに頼る。残念な
がら、４ＧＬ開発者は、コードの効率に関して価格を支払い、生成されるコード
は所与のアルゴリズムの特定の要求に適合されないので、結果として得られる性
能は最適化できない。

【００３２】４ＧＬから生成されたコードは、既存のシステムとの乏しい統合および生成さ
れた数値変数の使用のため、保守が困難になる傾向がある。例えば、生成された
コードは、「名前」または「顧客番号」などの意味のある名前ではなく、総称名
の変数（ラベル１、ラベル２等）を含む。

【００３３】（静的生成命令）静的手法は、１セットの静的生成命令を１片の個別化された目的ソース・コー
ドとして作成することから始まる。次にジェネレータは静的生成命令セットの中
にある変数を、モデリング・ツールに含まれる情報に置換する。これらの静的生
成命令セットは、モデリング・ツールに含まれる同型の情報（例えば、特定の方
法プロパティ）のみにアクセスするので、静的である。

【００３４】静的生成命令セットの手法は、クラス、属性、または役割のいずれかに位置付
けることができる情報を通常必要とするので、コンポーネント対フレームワーク
統合方法の生成によく適合しない。生成命令の静的セットは、モデルから事前お
よび事後条件などの関連プロパティを抽出する方法骨組みを作成するために、し
ばしば使用される。このやり方で生成される方法は、方法内容を完全にするため
に、開発者による手動的介在を必要とする。

【００３５】静的生成命令セットを使用するジェネレータは、１９９７年１０月７日にＬｉ
ｎｄｓｅｙに付与された米国特許第５，６７５，８０１号に記載されているよう
なシステムを使用して、プログラミング命令を１つのプログラミング言語から別
のプログラミング言語に変換することもできる。

【００３６】現在の生成技術は、図１の略ブロック図によって示すことができる。開発者は
、キーボード３６、マウス３７、または他のユーザ・インタフェース３８など既
知の入力手段を利用して、ビジュアル・モデリング・ツールまたは総合開発環境
３０とテキストまたは図形で対話し、彼のアプリケーション・ドメイン・モデル
に含まれるコンポーネントを記述する。ツール３０は、モデル宣言３１のそれ自
体の内部表現を生成する。大抵のパーサ／ジェネレータ・エンジン３３は、それ
らの対応する事前定義された静的生成命令３２のサブセットを使用して、モデル
宣言３１を目的コード３５に直接マッピングすることにより、または抽象構文木
３４のような中間表現を使用して、生成コードを生じる。この手法を使用して、
ジェネレータは、１セットの生成命令の任意のステップで、構文木の現在の横方
向ノードを持つそのジェネレータ文脈を初期化する。生成プロセスは、実行すべ
きプロセスを表す未処理ノードを持つジェネレータ文脈を変更する必要があるが
、ジェネレータ文脈は、そのノードに対応付けられる生成命令の実行中は変化し
ないので、静的である。

【００３７】モデル宣言３１は、パッケージ名によって潜在的にグループ化されるクラス、
各クラスのオペレーションおよび属性の記述、クラス間の関係、および潜在的に
特定のフレームワークに対応付けられる属性特性のリストを含む。

【００３８】静的生成命令３２は、開発者によって提供され目的ソース・コード３５とは異
なる表現または抽象で表された物を変換するために、コード生成に含まれた。事
前定義されたテンプレート３２は、どのコードを生成するかを指示するために使
用するものではなく、変換されるモデル宣言３１との関係に基づいて間接的に含
まれるので、開発者は、事前定義されたテンプレート３２のライブラリに容易に
アクセスすることができない。

【００３９】Ｓｍａｌｌｔａｌｋと呼ばれるプログラミング言語で開発されたもののような
一部のアプリケーション開発ツールは、ソース・コード生成のためのフレームワ
ークを提供し、そこでは、１つまたはそれ以上のＳｍａｌｌｔａｌｋオペレーシ
ョン内に埋め込まれたパラメータ化された目的コードを、ツールによって提供さ
れアプリケーション開発ツールの入力として使用されるモデル宣言３１のサブセ
ットを表す値と結合することによって、目的ソース・コード３５が生成される。
この種のソース・コード生成は、どこで変更を行うかを開発者が捜し出さなけれ
ばならないので、開発者が容易に修正することはできない。また、開発者はツー
ルの内部ソース・コードを変更しているので、ツール・ベンダによってサポート
されないかもしれない。

【００４０】フレームに基づく現在の技術は、ソフトウェア・モジュールを製造する自動ア
センブリラインの概念を使用してソース・コードを生成する。ソフトウェア・モ
ジュールはコンポーネントを表し、それはフレームの階層からアセンブルされる
。フレームは、いずれかの言語で表現されたデータ要素および／または方法を含
み、それはフレーム・パラメータを用いてパラメータ化される。フレーム・パラ
メータは、その値を最初に設定するフレームに限られる。フレームは一般的に（
全てのパラメータを）、目的ソース・コードを表す文字列値によって変更する必
要のあるパラメータを設定する先祖フレーム（ancestor frame）を持つために使
用するデフォルト値に初期化する。この技法では、フレーム階層を設計するため
にユーザが生成されるコードの繰返しコード部分を事前に知る必要があるので、
コード生成を達成することが困難である。

【００４１】図２は、先行技術のシステムを使用するときに必要な事象のシーケンスを示す
。モデル４０はツールで作成される。コード４１が生成され、これは前に説明し
た通り、低い活用性を持つ。このコード出力４１を有用にするには、かなりの量
の手動コーディング４２が必要である。例えばオペレーションの名前は、それが
何かを明確に表すように変更することができる。これらの手動修正４２が行われ
ると、最終コード４３をシステム内で使用することができる。

【００４２】

【発明の概要】

したがって、本発明の目的は、コンポーネント開発およびソース・コード生成
に対応付けられる開発者の繰返し作業を自動化し、所望の機能を得るために最小
限の開発者の介在を必要とするシステムを提供することである。

【００４３】本発明の別の目的は、前述のジェネレータを用いて生成されるものより完全で
あり、かつより正確に所用の機能に適合するソース・コード・ファイルを生成す
る、コンポーネント開発に対応付けられるソース・コード・ジェネレータを提供
することである。

【００４４】別の目的は、オペレーションを再生することによって、コードの保守を減少す
ることである。また、より高い百分率の生成コードを達成することにより、生成
されたコードを手動で変更する必要が無いので、保守を必要とするコードの量が
減少する。また、生成命令セットで必要とされる変更の実際の量は著しく減少す
る。

【００４５】本発明の別の目的は、同一情報を２つ以上のツールに捕捉することを回避する
ために、それを全ての主要なビジュアル・モデリング・ツールまたは主要な総合
開発環境に統合できるようにすることである。

【００４６】本発明の別の目的は、１セットの生成命令により生成する必要がある物をテキ
ストまたは図形で開発者に定義させ、目的プログラミング言語がツールに指定さ
れた後でソース・コード・ジェネレータ・オプションを開発者にカスタマイズさ
せる、ユーザ・インタフェース・ツールを提供することである。開発者が生成命
令セットおよびジェネレータ・オプションをファイルに保存すると、コンポーネ
ント開発に対応付けられるソース・コード・ジェネレータ・ツールは、開発者の
インタラクション無しで、モデリング・ツールまたは総合環境からバッチ・モー
ドで呼び出すことができる。

【００４７】本発明のさらに別の目的は、いずれかのオブジェクト指向プログラミング言語
またはいずれかのプログラミング言語支持コンポーネントのためのコードを生成
するソース・コード・ジェネレータ・ツールを提供することである。

【００４８】また、本発明の別の目的は、所望の生成命令セットを得るために開発者の最小
限の介在を必要とし、各セットの生成命令に見られる目的ソース・コードを生成
するためのインタフェースを提供することである。

【００４９】また、本発明の別の目的は、コードのブロックとその生成命令セットとの間の
トレーサビリティを提供することである。

【００５０】本発明のさらに別の目的は、ウェブ・ベース・サーバ、フレームワーク環境、
コード生成ツールまたはその他など、あらゆる種類の開発環境で使用でき、１セ
ットの生成命令のソース・コードを編集する必要性を満たす、生成命令エディタ
を提供することである。

【００５１】生成命令セットは、幾つかのタイプのプロパティへの参照を確立することによ
って、高レベルモデルの概念的コンポーネントをそれらのそれぞれのコーディン
グ実現および所与のフレームワークとのそれらの統合にリンクする。

【００５２】生成命令セットは、文脈変数でパラメータ化される目的ソース・コードを表す
。各文脈変数は、参照ノード（クラスまたは属性など）、および識別子（スーパ
クラス名、名前、またはタイプなど）を示す。スーパクラス名識別子は、参照さ
れたノードがクラスのときにだけ使用することができ、タイプ識別子は、参照さ
れたノードが属性のときにだけ使用することができる。また、名前識別子は、参
照されたノードがクラスかそれとも属性かによって、異なる種類の結果をもたら
す。言い換えると、コード・ジェネレータの文脈は動的であるので、参照される
ノードは変化できる

【００５３】ジェネレータ文脈がクラスの属性を含む場合、生成命令セットは依然としてそ
のクラスを参照することができる。「名前」と呼ばれる識別子は、参照されたノ
ードがクラスまたは属性のどちらとして見られるかによって、クラス名または属
性名を返す。

【００５４】動的な文脈感受性コード生成技法は、生成プロセス中にモデル内の情報をレバ
レッジするので、より有用なコードをより大量に生成する。開発者が保守中にコ
ードを変更したければ、彼または彼女は単に生成命令セット、またはモデリング
・ツールのクラス・ダイアグラムで捕捉された生成命令セットまたは内容を変更
するだけである。

【００５５】本発明の１つの態様によると、方法は、モデリング情報を概念データに変換し
、それをユーザが定義した１セットの生成命令と併合する。これらの生成命令セ
ットは、次のことを記述することによって、生成プロセスを支配する。・コードが生成されるコンポーネント・生成されるコードの種類（方法シグネチャおよび内容、またはインタフェー
スおよびクラスなどの導出されるコンポーネント）・生成−時間命令を使用して解決されるパラメータ化された目的ソース・コー
ド

【００５６】この方法により、開発者は、追加的種類の情報をモデルに含まれる属性および
クラスに結合する１セットの外部プロパティをも定義することができる。外部プ
ロパティは、コード内で保守すべき特殊な事例に特定的な実現詳細情報を提供し
、様々な種類の情報をモデルに統合させる。特定のモデルに対して定義された外
部プロパティは、生成命令セットによって使用されて、プロジェクトのソース・
モデルの機能性を拡張するコードを生成する。外部プロパティの名前は、グルー
プ別にクラス、属性、または役割サブセットのようなノードに割り当てられ、そ
れらの値は、割り当てられたノードの各出現に一意である。

【００５７】本発明の第１態様に従って、少なくとも１つのフィルタ変数と、少なくとも２
つの文脈変数でパラメータ化された目的ソース・コードとを表す、少なくとも１
セットの生成命令を作成するステップと、文脈変数を定義するステップと、複数
のコード・セグメントを生成するステップとを含む、コンポーネント・ベース型
言語でコンピュータ・ソース・コードを生成する方法を提供する。生成命令セッ
トは、１セットの外部プロパティ・グループおよびそれらの対応付けられた名前
を参照することができる。コード・セグメントは複数のコンポーネントを定義す
ることができる。この方法はさらに、生成命令セットが使用されたポインタ・デ
ータを生成するステップをさらに含むことができる。

【００５８】コンピュータ・ソース・コードを生成するための別の方法を提供する。そこで
は、モデル宣言が指定され、生成命令セットのグループが提供され、１セットの
生成命令を作成し、順序付けし、またはカスタマイズすることができ、コンピュ
ータ・ソース・コードが生成される。再び、生成プロセスでどのテンプレートお
よび所与のモデルのどの部分が使用されたかを識別するために、ポインタ・デー
タを生成することができる。モデル宣言は言語独立型とすることができ、生成命
令セットは、生成命令セットに見られるパラメータ化されたソース・コード・セ
グメントを書くのに使用された言語とは異なるコンポーネント・ベース型言語で
コンピュータ・ソース・コードを生成するために使用することができる。

【００５９】ポインタ・データを持つコンピュータ・ソース・コードを検索し、変更すべき
コードの部分を見つけ出し、ポインタ・データを使用して、生成命令セット、文
脈情報、またはモデル宣言を捜し出して変更し、コンピュータ・ソース・コード
を再生することを含む別の方法を提供する。

【００６０】それをジェネレータ文脈（レポジトリ）としてその宣言情報と共に処理するジ
ェネレータ・エンジンからのそのコンサルテーションを容易にするために、ビジ
ュアル・モデリング・ツールまたはジェネレータ・エンジンによって構文解析し
てデータベースまたは抽象構文木のような中間形式で保存することができるフォ
ーマットで、ビジュアル・モデリング・ツールまたは総合開発環境によって提供
される、１セットのコンポーネントの記述およびそれに対応付けられる属性およ
び相補的実現の詳細を前提として、ここで幅広く記述する本発明の目的は、上記
目的をいかに達成するかを開示する。各セットの生成命令を構文解析して、その
ためのコードを生成する必要のある目的コンポーネント、および処理すべきコー
ド生成の種類を決定するためのシステムを提供する。コード生成は、全て生成命
令セットが処理されたときに完了する。

【００６１】コード・ジェネレータでは、ビジュアル・モデリング・ツールなどのモデリン
グ・ツール、または総合ソフトウェア開発環境または類似物を使用して、大部分
は開発者の入力から作成される仕様データから、目的ソース・コードが生成され
る。本発明の幅広い態様に従って、仕様データはメタデータと生成命令データ・
セットとを含むことができる。生成命令セットは、ジェネレータ・オプションの
１つを用いて事前に指定された特定の目的プログラミング言語に対して、クラス
宣言、クラス定義、パッケージ定義、オペレーション宣言、またはオペレーショ
ン定義など、どの種類のソース・コードを生成するかを記述する完全な仕様を提
供する。生成命令データ・セットはパラメータ化された形のコード仕様を含み、
例えば同一オブジェクトまたはコンポーネントに対する異なる生成オペレーショ
ンの場合、または異なるオブジェクトまたはコンポーネントに対する同一の生成
オペレーションの場合、または別の生成命令データ・セットの場合など、多くの
場合に、１つまたはそれ以上のパラメータ化されたブロックの目的ソース・コー
ドを再使用することが可能になる。生成命令データ・セットは、オブジェクトま
たはコンポーネント文脈への参照を含むために、フィルタおよび文脈変数を使用
するパラメータ化されたコード・コマンドを含む。コード生成のプロセス中に、
仕様データは構文解析され解釈されて、レポジトリ・データが生成される。最終
目的コードは、レポジトリ・データから「抽出」されて、目的プログラミング言
語によって要求される適切な論理構造の目的コードが生み出される。したがって
、生成命令データ・セットで使用されるパラメータ化の結果として、コードの再
使用のレベルが最大になるように、目的コードは、最小限の生成命令データ・セ
ットをメタデータと共に使用して、生成することができる。

【００６２】好ましくは、いわゆる仕様データは、モデル宣言データ（つまりメタデータ）
と、適切な開発者インタフェース・ツールを使用して別個に生成される１セット
の生成命令とを含む。モデル宣言データは、各オブジェクトまたはコンポーネン
トに対応付けられる文脈に関するコンポーネント・プログラミング言語関連情報
を含む。生成命令データ・セットは、各オブジェクトまたはコンポーネントに対
応付けられる現在の文脈に応じるパラメータ化されたコード・コマンドを含み、
現在の文脈情報はレポジトリ・データ内にある。レポジトリ・データは元来、前
述したモデル宣言の構文解析によって作成され、それは、既存のものから導出さ
れ新たに生成されるオブジェクトまたはコンポーネントに関し、かつ既存のまた
は新たに生成されたオブジェクトまたはコンポーネントに対応付けられ新たに生
成されるオペレーションに関して、成長し続ける。抽出子（extractor）は、言
語要件パラメータ・データおよびレポジトリ・データに基づいて特定のプログラ
ミング言語のオブジェクト指向（またはコンポーネント）ソース・コードを生成
する。後者のレポジトリ・データは、入力としてモデル宣言データおよび生成命
令データ・セットを受け取るジェネレータ・エンジンによって作成される。生成
命令データ・セットは、繰返し文および／または準繰返し文を指定することがで
きかつ文脈データに依存するパラメータ化コードを含むことができる、ソース・
コードコマンドを含む。文脈データを提供することにより、かつ変数または文脈
データに応じるパラメータ化されたコード・コマンド持つ生成命令データ・セッ
トを提供することにより、生成命令セットは、より多数のオブジェクトまたはコ
ンポーネントのソース・コードを指定するために適用することが可能になる。

【００６３】生成命令データ・セットは、元来モデル宣言データで指定するつもりではなか
ったコンポーネントの生成を（およびオペレーションまたは属性の生成も）指定
することができることを理解されるであろう。これは、生成命令データ・セット
の中に、モデル宣言データ内にあるコンポーネントに関連したコンポーネントの
作成を指定することによって達成される。これにより、特定の生成命令セットを
使用して、特定のプログラミング・フレームワークの要求に応じることが可能に
なる。

【００６４】コンポーネント・ベース型言語でコンピュータソース・コードを生成するため
の装置も提供する。この装置は、生成命令セットを作成またはカスタマイズする
ためのテンプレート・エディタと、生成命令セットを選択して順序付け、生成パ
ラメータを設定するためのテンプレート・マネージャと、ソース・コード・ジェ
ネレータと、ソース・コード出力とを含む。この装置はさらに、ポインタ・デー
タ・ジェネレータと、生成コード・セグメントをどの言語にするかを選択するた
めの言語データベースとを含むことができる。

【００６５】ソース・コードを検索するためのソース・コード・エディタと、テンプレート
・マネージャと、テンプレート・エディタと、ソース・コード・ジェネレータと
、ソース・コード出力とを含む、生成されたコンピュータ・ソース・コードを修
正するための別の装置を提供する。

【００６６】本発明を目的として、次の用語を以下の通り定義する。

【００６７】用語「生成命令セット」とは、少なくとも１つのフィルタ変数と少なくとも１
つの文脈変数でパラメータ化される目的ソース・コードとを表する生成命令とし
て、ソース・コード・ジェネレータによって使用されるテンプレートを意味する
つもりである。

【００６８】用語「文脈変数」とは、参照ノードおよび識別子を示す変数を意味するつもり
である。

【００６９】用語「フィルタ変数」とは、それに対してコードが生成される選択されたコン
ポーネントを指定する変数を意味するつもりである。

【００７０】用語「オブジェクト指向プログラミング」とは、開発者がデータ構造のデータ
型を定義するだけでなく、データ構造に適用できるオペレーションのタイプをも
定義するプログラミング言語のタイプを意味するつもりである。さらに、開発者
は１つのオブジェクトと別のオブジェクトとの間の関係を作成することができる
。

【００７１】用語「コンポーネント」とは、オブジェクトの隠蔽および抽象化特性を持つエ
ンティティを意味するつもりである。さらに、それらは、それらの構造、能力、
およびインタラクションの標準を定義する技術枠組の一部である。

【００７２】用語「モデル宣言」とは、システム内のコンポーネント、コンポーネント間の
関係、およびコンポーネントの各クラスを特徴付ける属性およびオペレーション
を示すことによって、システムの静的構造を捕捉する表現を意味するつもりであ
る。

【００７３】用語「結合」とは、識別子または変数と、定義された範囲内に維持するその識
別子または変数の値との間の対応付けを意味するつもりである。

【００７４】用語「テンプレート」および用語「生成命令セット」は、本発明の明細書全体
を通して同義語とするつもりである。

【００７５】本発明のこれらおよび他の特徴、態様、および利点は、以下の説明および添付
の図面を顧慮することにより、いっそうよく理解されるようになるであろう。

【００７６】

【好適な実施形態の詳細な説明】

語コンポーネントおよびクラスは、検討する全ての実現言語（ＪＡＶＡ^TM、Ｃ
＋＋、およびＳｍａｌｌＴａｌｋ）がコンポーネントに対して同じ意味を共有し
ているので、つまりコンポーネントとはクラスであるので、語コンポーネントと
クラスは本節では同義語として使用する。

【００７７】本発明は、種々の既知のコンピューティング環境のどれでも実行することがで
き、それは、図３に示すようにシステム内に実現して、Ｃ＋＋、ＪＡＶＡ^TM、ま
たはＳｍａｌｌｔａｌｋなどのコンポーネント・ベース型ソース・コードを生成
することができる。図５ないし図８は、本発明の好適な実施形態による方法を表
す流れ図である。

【００７８】図４は、方法の一般的ステップの流れ図である。モデル６５は、モデリング・
ツール５０で作成される。生成命令６６は、好適な実施形態に従って、コード・
ジェネレータに与えられる。コード出力６７が得られる。このコード出力６７は
適合化され、完成されている。最終コード６８は、開発者がそれを使用する前に
、修正したり完成させる必要が無い。

【００７９】開発者は、キーボード５３、マウス５４、またはその他のユーザ・インタフェ
ース５５など既知の入力手段を利用して、テキストまたは図形によりビジュアル
・モデリング・ツールまたは総合開発環境５０と対話して、特定のドメイン・モ
デルに含まれるコンポーネントおよびそのクラス・ダイアグラムを記述する（図
５ａのステップ７５）。クラス・ダイアグラムの２つの例を、図１１および図１
２に示す。

【００８０】図５の図は、本発明の好適な実施形態の特定の実現を示す。それらは、モデル
宣言および生成命令セットに対して行われる処理を示す。図１３および図１４は
、図５の流れ図に対応するモデル宣言および生成命令セットの構文を表すＢａｃ
ｋｕｓ−Ｎａｕｒ図である。この構文は、本発明の好適な事件の特定の例として
示す。それに対する多数の変形が当業者には明らかであることは、理解されるで
あろう。したがって、流れ図およびＢａｃｋｕｓ−Ｎａｕｒ図の記述は限定の意
味としてはなく、本発明の例示として受け止めるべきである。

【００８１】図５ａのステップ７６に示すように、開発者は、現在のモデルに対応付けられ
る全ての種類の実現の詳細を捕捉する外部プロパティの名前のグループをモデル
で定義することによって、一般的なモデリング・ツールにおける情報の範囲を拡
張する。

【００８２】ステップ７７に示すように、開発者は、１セットの生成命令にあるコード文字
列を使用して目的言語を参照する。コード文字列は例えば、コード文字列の始め
と終わりに１つづつ、２つの感嘆符記号“！”によって囲まれた目的実現言語の
有効な構成体のサブセットを使用して、直接表現される。

【００８３】この好適な実施形態では、コード文字列は人間が読取り可能な構文で記述され
るが、そのような記号の使用は、システムの使用を促進するために任意の記号、
文字、または図形実現にさえも変更することができる。

【００８４】定数コード文字列とパラメータ化コード文字列の２種類のコード文字列がある
。ジェネレータ・エンジン５２は各々を様々なやり方導出する。第１事例では、
定数のコード文字列がひとたび生成命令エンジン４７によって構文解析されると
、ジェネレータ・エンジン５２はそれを操作する必要が無い。ジェネレータ・エ
ンジン５２による定数コード文字列の導出は、最初と最後の感嘆符記号を除去し
、コード文字列をを返すことによって行われる。言い換えると、ジェネレータ・
エンジン５２は、開発者によってコード化された通りのソース・コードを返す。
第２事例では、パラメータ化されたコード文字列は、ジェネレータ・エンジン５
２が、文字列％ｎの出現と提供された値を結合する必要のあるコード文字列であ
り、ここでｎは１から９の間の整数である。本発明のこの好適な実施形態では、
便宜上、ｎを１から９の間の整数としてコード文字列が文字列％ｎの出現を含む
ように設計されているが、開発者は、同じ結果を持つ異なる数字および文字の他
の出現を組み込むことを選択することができる。例えば、整数ｎは１から９９ま
での間、または１ａから９ｚまでの間とすることができる。

【００８５】出現のこの結合は、ジェネレータ・エンジン５２の一部である再帰バインダ（
Recursion binder）４８によって行われる。コード文字列に１つの値しか提供さ
れない場合、ジェネレータ・エンジン５２は％１の全ての出現を提供された値に
置換し、あるいはコード文字列にｎが２から９までの整数である文字列％ｎが出
現した場合、エンジン５２はエラーを発生し、コード生成を停止する。コード文
字列に２つの値が提供される場合、ジェネレータ・エンジン５２は％１の全ての
出現を最初に提供された値と置換し、％２の全ての出現を２番目に提供された値
と置換し、あるいはコード文字列にｎが３から９までの間の整数である文字列％
ｎが出現した場合、それはエラーを発生し、コード生成を停止する。したがって
、値のリストが提供された場合、ジェネレータ・エンジン５２は、％ｎの全ての
出現を提供されたリストのｎ番目の値と置換する。ｎの値は、１から９までの範
囲内としなければならない。ｋは提供されたリストのサイズより大きいが１０未
満の整数であり、パラメータ化されたコード文字列のいずれかの部分に％ｋが含
まれる場合、ジェネレータ・エンジン５２はエラーを発生する。再び、開発者は
、％ｋに対して異なるセットの値を提供することを選択することができる。最後
に、ジェネレータ・エンジン５２は、パラメータ化されたコード文字列内で見つ
かる全ての％ｎを提供された値に置換することから形成されるソース・コードを
返す。導出されたパラメータ化コード文字列は、定数コード文字列と同様に、目
的実現言語の構成体の構文的に有効なサブセットを含まなければならず、開発者
はパラメータ文字列とその提供値を書かなければならない。モデル宣言５１は厳
格に定数コード文字列を含むが、生成命令セット５６は、両方のタイプのコード
文字列を含むことができる。

【００８６】導出されたコード文字列と目的コードとの間の変換は無い。言い換えると、開
発者は、コード文字列内に所望する目的言語のための有効な構文ステートメント
のサブセットを書く責任がある。それは、開発者のコーディング・スタイルを使
用して効率的なコードを配付するという利点をもたらす。

【００８７】したがって、ジェネレータ・エンジン５２は、モデル宣言エンジン４６、生成
命令エンジン４７、および再帰バインダ４８で構成される。生成命令エンジン４
７は、抽象構文木５８からその文脈を検索する。再帰バインダ４８は、抽象構文
木を使用してコード文字列を再帰的に解く。モデル宣言エンジン４６はモデル宣
言５１を分析し、抽象構文木５８を作成するための情報を提供する。

【００８８】ツール４９を使用して、開発者は、次の情報の一部または全部を指定すること
によって、開発ドメインおよび実現プログラミング言語に対応付けられる実現の
詳細を完成する（ステップ７６）。

【００８９】各パッケージについて、次の事項、すなわちその記述、その名前、現在のパッ
ケージが別の１つの中に含まれる場合それが含まれるパッケージ名、および現在
のパッケージで定義された各クラスの記述のリストを与える注釈を定義すること
ができる。

【００９０】各クラスまたはインタフェースについて、その記述、専用、公衆、保護されて
いるか、パッケージかなどそのインタフェース・タイプ値、その名前、クラスが
具象か抽象かを述べる値、そのスーパクラス名およびスーパクラスが定義される
パッケージ名、現在のクラスで定義された各属性の記述のリスト、現在のモデル
に関連付けられる各外部プロパティの記述のリスト、ならびに現在のクラスで定
義された各オペレーションの記述のリストを与える注釈を指定することができる
。

【００９１】各属性について、その記述、そのインタフェース・タイプ値（専用または公衆
など）、保護されているかパッケージか、それがインスタンスかクラス属性かを
表すそのタイプ、その名前、その実現クラス名および実現クラスが定義されてい
るパッケージ名、定数コード文字列を使用して実現されかつＣ＋＋のようなプロ
グラミング言語の場合にその実現クラスに対応付けられるその前提ｔｙｐｅｄｅ
ｆ値、それがコレクションのように見えるときにそれ自体によって含まれる要素
の属性クラス名、定数コード文字列を使用して実現されるそのデフォルト値、現
在の属性に対応付けられる各外部プロパティの記述のリストを与える注釈を指定
することができる。

【００９２】各連想について、その記述、その名前、そのソース役割、および目的ロール名
、接頭辞および接尾辞、役割インタフェース・タイプ、役割が過渡か、揮発性か
、最終かを述べる値を与える注釈を指定することができる。

【００９３】各外部プロパティについて、その名前、および定数コード文字列を使用して実
現される定義のリストを指定することができる。

【００９４】各オペレーションについて、専用または公衆、保護されているかパッケージか
など、そのインタフェース・タイプ値、それがクラスかそれともインスタンス・
オペレーションかを述べる値、その名前、そのカテゴリ名（Ｓｍａｌｌｔａｌｋ
のようなプログラミング言語に使用される）、コード文字列で使用される参照ク
ラスのリストと共に定数文字列を使用して実現されるその宣言コード（Ｃ＋＋の
ようなプログラミング言語の場合ヘッダ・ファイルに使用される）、コード文字
列で使用される参照クラスのリストと共に定数コード文字列を使用して実現され
るその定義コードを指定することができる。

【００９５】フレームワークを扱う場合、開発者は実現の詳細をコード文字列の定義に分解
し、それらを外部プロパティにグループ化する必要がある。所与のフレームワー
クに必要な全ての定義を実現するには、２つ以上の外部プロパティ名が必要にな
ることがあり、１つの外部プロパティを使用して複数のフレームワークを実現す
ることができる。大抵の場合、プロパティ値は厳密に、定数コード文字列用の数
値または英数字値を含む。

【００９６】次いで、開発者は、ツール５０を使用してモデル宣言５１を生成する。モデル
宣言は、言語独立型とするか、あるいはＣ＋＋、ＪＡＶＡ^TM、またはＳｍａｌｌ
Ｔａｌｋなど特定のコンポーネント・ベース型言語用に適応させることができる
。最初の選択肢を使用する場合、一般モデル宣言５１を使用するために、生成命
令セット５６を書かなければならない。第２の選択肢を使用する場合、モデル宣
言は、３つの主要な側面、すなわち実現の詳細、コード文字列、ならびにカテゴ
リ名およびｔｙｐｅｄｅｆが異なる。パッケージ名、クラス名、属性名、および
オペレーション名は、例えばＣ＋＋対ＳｍａｌｌＴａｌｋでは命名規定が異なる
ので、異なってくる実現の詳細である。コード文字列は、言語が同一プログラミ
ング言語の構文をサポートしないために異なってくる。カテゴリ名（Ｓｍａｌｌ
Ｔａｌｋで使用される）および参照クラス（Ｃ＋＋およびＪＡＶＡ^TMでそれぞれ
包含文および移入文を生成するために使用される）のような情報は、必要な場合
にだけ使用される。

【００９７】開発者は、残りのタスクにコード・ジェネレータ・ユーザ・インタフェース４
９を使用する。ひとたびそれを呼び出すと、開発者はモデル宣言を含むファイル
をロードし、それらがすでに行われている場合、彼は生成命令セット５６を含む
ファイルをロードする。好適な実施形態の場合、開発者は、彼自身の必要に応じ
て、必要な数の生成命令セット５６を作成する（ステップ７７）。生成命令セッ
トを作成、修正、カスタマイズ、または順序付けて、生成のための適切な生成命
令セットのセットを準備することができる。

【００９８】コード・ジェネレータ・ユーザ・インタフェース４９を使用して、開発者は生
成される目的コードのプログラミング言語を選択し、それは、開発者がモデルお
よび生成命令セットにある全てのコード文字列を定義するときに開発者が使用し
たのと同じとするか、または生成命令セットの変換が必要な場合、異なるものと
することができる。次いで、彼は、以下の設定：すなわち属性、クラス、外部プ
ロパティ、オペレーション、およびパッケージ名の第１文字がロアケースまたは
アッパケースのどちらか、またはどちらにもすることができること；属性、クラ
ス、外部プロパティ、オペレーション、またはパッケージ名に含めることができ
る特殊文字のリスト；モデル宣言で明示的に示されない場合にクラス、属性、ま
たはオペレーションに対応付けられるインタフェース・タイプに使用されるデフ
ォルト値；クラス、属性、またはオペレーションに対応付けられる有効なインタ
フェース・タイプ値；有効な外部識別子のリスト；ジェネレータがモデル宣言に
新しい外部識別子を見つけたときにそれを外部識別子のリストに追加すべきかど
うかを述べるブール値について、それらを有効にするために、コード・ジェネレ
ータ・ユーザ・インタフェース４９を使用して、コードの生成（ステップ７８）
に影響するジェネレータのオプション５７を検討する。

【００９９】開発者は、抽出オプション５７も検討する。ここでは、例として３つのコンポ
ーネント・ベース型言語の設定を取り上げる。ジェネレータの一部はフロントエ
ンド・ツール４９のサブメニュを「優先」するので、Ｃ＋＋をジェネレータとし
て使用する場合、開発者は生成されるコードの抽出プロセスに対し次のオプショ
ンを変更する。

【０１００】「宣言コード・ディレクトリ」は、ドライブおよびルート・ディレクトリ名を
指定するために使用される。デフォルトでは、値はｄ：＼ｉｎｃｌｕｄｅである
。

【０１０１】「定義コード・ディレクトリ」は、ドライブおよびルート・ディレクトリなを
指定するために使用される。デフォルトでは、値はｄ：＼ｓｏｕｒｃｅである。

【０１０２】「宣言コードのためのファイル拡張」は、現在のパッケージに属するクラスに
マップする各ファイル名のファイル拡張を指定するために使用される。デフォル
トでは、値はｈｐｐである。

【０１０３】「定義のためのファイル拡張」は、現在のパッケージに属するクラスにマップ
する各ファイル名のファイル拡張を指定するために使用される。デフォルトでは
、値はｃｐｐである。

【０１０４】「１ファイル当り１クラス」はデフォルトでは真に設定されるが、それは変更
することができる。

【０１０５】ジェネレータの一部はフロントエンド・ツール４９のサブメニュを優先するの
で、ＪＡＶＡ^TMをジェネレータとして使用する場合、開発者は生成されるコード
の抽出プロセスに対して次のオプションを変更する。

【０１０６】「ルート・ディレクトリ」は、ドライブおよびルート・ディレクトリ名を指定
するために使用される。デフォルトでは、値はｄ：＼である。

【０１０７】「パッケージ名をマップするディレクトリ」は、それが真に設定されていると
きに、２つの期間の間に見られる各サブストリングのサブディレクトリ名を作成
するために使用される。デフォルトは真である。

【０１０８】「クラス拡張」は、現在のパッケージに属するクラスにマップする各ファイル
名のファイル拡張を指定するために使用される。デフォルトでは、値はＪＡＶＡ ^TM である。

【０１０９】「１ファイル当り１クラス」はデフォルトでは真に設定されるが、それは変更
することができる。

【０１１０】ジェネレータの一部はフロントエンド・ツール４９のサブメニュを優先するの
で、ＳｍａｌｌＴａｌｋをジェネレータとして使用する場合、開発者は生成され
るコードの抽出プロセスに対して次のオプションを変更する。

【０１１１】「定義コード・ディレクトリ」は、ドライブおよびルート・ディレクトリ名を
指定するために使用される。デフォルトでは値はｄ：＼である。

【０１１２】「定義のためのファイル拡張」は、現在のパッケージに属するクラスにマップ
する各ファイル名のファイル拡張を指定するために使用される。デフォルトでは
、値はａｐｐである。

【０１１３】「１ファイル当り１パッケージ」はデフォルトでは偽に設定されるが、それは
変更することができる。

【０１１４】ステップ７９で、開発者は、フロントエンド・ツール４９を用いてジェネレー
タ・エンジン５２を呼び出す。エンジン５２は、第１モデル宣言５１を構文解析
することによって始動し（ステップ８０）、そのレポジトリ・データを作成し（
ステップ８１）、それは抽象構文木５８に格納される。言い換えると、モデル・
パーサによって構文解析された情報を使用して、ジェネレータ・エンジン５２は
、モデル宣言５１に見られる全てのパッケージ、クラス、属性、外部プロパティ
、連想、役割、およびオペレーション、ならびに前述したそれらの間の関係に対
して、抽象構文木５８にノードを作成する（ステップ８１）。

【０１１５】パッケージ、クラス、属性、またはオペレーションを表す各ノードは、それに
対応付けられる生成された定義ソース・コードを含む定義テキスト（definition
Text）と呼ばれる属性を持つ。また、Ｃ＋＋のようなプログラミング言語の場合
、クラス・ノード、属性ノード、およびオペレーション・ノードは、それに対応
付けられる生成された宣言ソース・コードを含む、宣言テキスト（declarationT
ext）と呼ばれる属性を持つ。

【０１１６】ステップ８１で、モデル宣言５１内で見つかる宣言されたオペレーションまた
は属性は、その宣言されたクラス・ノードに対応付けられるオペレーション・ノ
ードまたは属性ノードになる。そのステップの間、ジェネレータ・エンジン５２
は、それをそれらのそれぞれの定数コード文字列から抽出することによって、提
供された定義および宣言ソース・コードにより属性定義テキストおよび宣言テキ
ストを初期化する。

【０１１７】ジェネレータ・エンジン５２によって処理すべき別のモデル宣言があるかどう
かを決定する（ステップ８２）前、およびそれを構文解析する（ステップ８３）
前に、エンジン５２は、見つかった最初のエラーで構文解析を停止し、エラーに
関するトークンによりモデル宣言内でエラーを文脈的に表示するようにフロント
エンド・ツール４９に要求する。エンジン５２が現在のモデル宣言に照らしてジ
ェネレータおよびエクストラクタ・オプション５７を妥当性検査したときに、ま
たは同一パッケージ内で同一クラス名が２回定義されるか、同一属性名が同一ク
ラスに対して２回定義されている（主としてスーパクラスから同一属性名が継承
されるため）ことが分かったときに、エラーが発生する。

【０１１８】ステップ８５で、ジェネレータ・エンジン５２は第１セットの生成命令５６を
構文解析して、コードを生成する必要のある目的クラスまたはパッケージ（ステ
ップ８６）、および処理すべきコード生成の種類（ステップ８９）を決定する。

【０１１９】目的クラス（ステップ８９）は、抽象構文木５８に見られる宣言されたクラス
のサブセットであり、それらはそのサブセットから導出される。生成命令セット
５６のレシーバ宣言部分で宣言クラスのサブセットを指定するために、開発者は
、クラス自体またはその属性、そのノード、もしくはその外部プロパティに対応
付けられる選択基準を指定する。例えば、開発者はキーワード＆ｃｌａｓｓを指
定することによって全てのクラスを選択し、キーワード＆ｃｌａｓｓの後にキー
ワードａｂｓｔｒａｃｔを続けて指定することによって全ての抽象クラスを選択
し、キーワード＆ｃｌａｓｓの後にキーワードｃｏｎｃｒｅｔｅを続けて指定す
ることによって全ての具象クラスを選択し、キーワード＆ｃｌａｓｓｓｕｂｃ
ｌａｓｓＯｆの後に任意のクラス名を続けて指定することによって任意のクラス
名のサブクラスである全てのクラスを選択し、あるいはキーワード＆ｃｌａｓｓ
ｅｓｈａｖｉｎｇａｔｔｒｉｂｕｔｅｏｆｔｙｐｅの後に任意のクラス
名を続けて指定することによって任意のタイプの属性を持つ全てのクラスを選択
することができる。

【０１２０】導出されたクラスは、ステップ８８で検索するために、作成されるやいなや抽
象構文木５８に追加される９９。

【０１２１】パッケージに対応付けられる生成コードは、それに含まれるクラスの１つに対
応付けられる生成コードを抽出するときに、間接的に使用されるので（さらに詳
しくはステップ９７を参照されたい）、目的パッケージ（ステップ８６）は、キ
ーワード＆ｐａｃｋａｇｅｓを指定することによって常に全てのパッケージを参
照する。

【０１２２】ステップ８７で、第１目的ノードが処理され、ステップ８８で、目的ノードが
厳密にクラスまたはパッケージをそれぞれ含むかどうかによって、それは現在の
クラス文脈または現在のパッケージ文脈になる。現在の生成命令セット５６がパ
ッケージ定義のためのコードを生成し、構文解析された使用キーワードが、以下
で説明するようにｐａｃｋａｇｅＤｅｆｉｎｉｔｉｏｎである場合にだけ、目的
ノードはパッケージを表す。

【０１２３】ステップ８９で、ジェネレータ・エンジン５２は、生成命令５６セットの次の
構文解析されたキーワードに基づいて、生成するコードのタイプを弁別する。

【０１２４】ｏｐｅｒａｔｉｏｎキーワードは、生成されたコードを現在のクラス文脈のた
めの１つまたはそれ以上のオペレーションとして処理しなければならないことを
、ジェネレータ・エンジン５２に示す。ジェネレータ・エンジン５２は、オプシ
ョナル・キーワードｄｅｃｌａｒｅｄＡｓに対応付けられる生成されたコードを
、新たに作成されたオペレーション・ノードのｄｅｃｌａｒａｔｉｏｎＴｅｘｔ
属性に追加する。エンジン５２は、オプションのｄｅｃｌａｒｅｄＡｓキーワー
ドに対応付けられる生成コードを同じ新たに生成されたオペレーション・ノード
のｄｅｆｉｎｉｔｉｏｎＴｅｘｔ属性に追加する。ジェネレータ・エンジン５２
は、新たに作成されたオペレーション・ノードを現在のクラス文脈に追加する。

【０１２５】ｃｌａｓｓＤｅｃｌａｒａｔｉｏｎキーワードは、ジェネレータ・エンジン５
２に、生成されたコードを現在のクラス文脈のクラス宣言として処理させる。こ
れは、ヘッダ・ファイルに位置するコードをパッケージするために、Ｃ＋＋のよ
うなプログラミング言語に使用される。エンジン５２は、生成されたコードを現
在のクラス文脈に対応付けられるｄｅｃｌａｒａｔｉｏｎＴｅｘｔ属性に追加す
る（ステップ９２）。

【０１２６】ｃｌａｓｓＤｅｆｉｎｉｔｉｏｎキーワードは、ジェネレータ・エンジン５２
に、生成されたコードを現在のクラス文脈のクラス定義として処理するように指
示する。これは、クラスに属する属性およびオペレーション定義をグループ化す
るために、どのプログラミング言語でも使用される（Ｃ＋＋およびＪＡＶＡ^TMの
場合のように）。一部のプログラミング言語は、その対応付けられるクラスによ
りその属性の名前だけをグループ化するために、ｃｌａｓｓＤｅｆｉｎｉｔｉｏ
ｎを使用する（Ｓｍａｌｌｔａｌｋの場合のように）。ジェネレータ・エンジン
５２は、生成されたコードを現在のクラス文脈に対応付けられるｄｅｆｉｎｉｔ
ｉｏｎＴｅｘｔ属性に追加する（ステップ９２）。

【０１２７】ｐａｃｋａｇｅＤｅｆｉｎｉｔｉｏｎキーワードは、ジェネレータ・エンジン
５２に、生成されたコードを現在のパッケージ文脈のパッケージ定義として処理
するように指示する。Ｃ＋＋のようなプログラミング言語は、１つのファイルに
つき１つのクラスだけを使用してコードをファイルに抽出するので、パッケージ
定義を使用しない。ＪＡＶＡ^TMまたはＳｍａｌｌｔａｌｋのようなプログラミン
グ言語はそれを使用する。ジェネレータ・エンジン５２は、生成されたコードを
、現在のパッケージ文脈に対応付けられるｄｅｆｉｎｉｔｉｏｎＴｅｘｔ属性に
追加する（ステップ９２）。

【０１２８】開発者は、次の順序でその生成命令セット５６を書かなければならない。第一
に、キーワードｃｌａｓｓＤｅｃｌａｒａｔｉｏｎまたはｃｌａｓｓＤｅｆｉｎ
ｉｔｉｏｎを用いた生成命令セットを任意の順序で指定することができるが、そ
れらはキーワードｏｐｅｒａｔｉｏｎまたはｐａｃｋａｇｅＤｅｆｉｎｉｔｉｏ
ｎを持つものに先行しなければならない。次に、キーワードｐａｃｋａｇｅＤｅ
ｆｉｎｉｔｉｏｎを用いた生成命令セットが、キーワードｏｐｅｒａｔｉｏｎを
使用するものに先行しなければならない。最後に、キーワードｏｐｅｒａｔｉｏ
ｎを使用する生成命令セットが含まれる。

【０１２９】上記のキーワードの１つが順番に並んでいない場合、ジェネレータ・エンジン
５２はエラーを発生する。

【０１３０】ステップ９８で、ジェネレータは、生成されるコードが新しいコンポーネント
を作成するかどうかを検査する。そうである場合、新しいノードが作成される９
９。３種類のノードを作成することができる。すなわち、導出されたクラス用の
新しいノード、導出されたインタフェース用の新しいノード、そして導出された
属性用の新しいノードである。新しいノードに対し、注釈記述を含めることがで
き、インタフェース・タイプ、値「具象」または「抽象」および値「最終」も含
めることができる。導出されたクラスおよび導出されたインタフェースについて
は、クラス・ロケーション句、スーパクラス・ロケーション句、インタフェース
句を定義することができる。導出された属性については、値「過渡」、値「揮発
性」、属性タイプ、属性内容句、および属性クラス名を含めることができる。

【０１３１】生成されるコードが新しいノードを生成しない場合、生成されるコードのタイ
プの検査がステップ９０で行われる。ジェネレータ・エンジン５２は、構文解析
されたキーワードに基づいて、異なるタイプの生成命令セットを区別する。

【０１３２】ステップ９１で、ジェネレータ・エンジン５２は、オペレーション名変数の有
無に基づいて、１クラス当たり１つの、１つだけのオペレーションを作成しなけ
ればならないかどうかを決定する。オペレーション名変数内の文字列％１の出現
は、提供される値で置換されるので、オペレーション名変数はクラス名変数と同
様である。単一の変数作成プロセスは、それぞれ図５ｃおよび図５ｄに関連して
、より詳細に説明する。

【０１３３】ステップ９２で、ジェネレータ・エンジン５２は、生成されたソース・コード
をキャッシュから現在の文脈ノードに保存する。キャッシュにソース・コードを
生成するために使用されるプロセスについては、図５ｅを使用して変数オペレー
ションの解について説明するときにさらに詳しく説明する。現在の生成命令セッ
トにｐａｃｋａｇｅＤｅｆｉｎｉｔｉｏｎキーワードがある場合には、現在の文
脈ノードはパッケージ・ノードである。現在の生成命令にｃｌａｓｓＤｅｆｉｎ
ｉｔｉｏｎまたはｃｌａｓｓＤｅｃｌａｒａｔｉｏｎキーワードがある場合には
、現在の文脈ノードはクラス・ノードである。

【０１３４】ステップ９３で、ジェネレータ・エンジン５２は、現在の生成命令セットで処
理すべき別の目的ノードがあるかどうかを決定し、ステップ９５でそれを処理す
る。

【０１３５】ステップ９４で、ジェネレータ・エンジン５２は、処理すべき別の生成命令セ
ットがあるかどうかを決定し、ステップ９６でそれを処理する。

【０１３６】エンジン５２は、最初に見つかるエラーでコード生成を停止し、エラーに関す
るトークンにより生成命令セット内で文脈的にエラーを表示するようにフロント
エンド・ツール４９に要求する。エラーはまた、エンジン５２が現在の生成命令
セットに照らして、または提供された値に照らしてジェネレータおよびエクスト
ラククタ・オプション５７を妥当性検査し、結果が妥当でない場合にも発生する
。

【０１３７】ひとたびジェネレータ・エンジン５２がコード生成を正常に完了すると、フロ
ントエンド・ツール４９は、抽象構文木５８に定義されたノードから生成された
ソース・コード６０を検索するために、ソース・コード・エクストラクタ５９を
呼び出す。各ソース・コード・エクストラクタ５９は、コードをファイルに移出
するそれ独自のやり方を持ち、抽出プロセスを開始する前にジェネレータおよび
エクストラクタ・オプション５７を読出す（ステップ９７）。

【０１３８】ジェネレータによって行われるステップを今、Ｃ＋＋、ＪＡＶＡ^TM、およびＳ
ｍａｌｌＴａｌｋにおける３つの例を用いて説明する。

【０１３９】Ｃ＋＋ソース・コード・エクストラクタ５９は、生成されたコードを抽出する
ために、以下のステップを実行する。最初に、それは、ジェネレータおよびエク
ストラクタ・オプション５７で指定された値に基づいて、包含サブディレクトリ
（include subdirectory）を作成する。このディレクトリは、ヘッダ・ファイル
を含む（ファイル名は拡張子ｈｐｐで終わる）。次にそれは、ジェネレータおよ
びエクストラクタ・オプション６０に指定された値に基づいて、ソース・サブデ
ィレクトリを作成する。このディレクトリは、定義ファイルを含む（ファイル名
は拡張子ｃｐｐで終わる）。次いで、抽象構文木５８に見られる各クラス・ノー
ドに対して、そのｄｅｃｌａｒａｔｉｏｎＴｅｘｔ属性が空でない場合にのみ、
包含ディレクトリに＜ｃｌａｓｓＮａｍｅ＞．ｈｐｐと呼ばれるファイルを作成
し、その内容をファイルに書き込む。それは、そのｄｅｆｉｎｉｔｉｏｎＴｅｘ
ｔ属性が空でない場合にのみ、ソース・ディレクトリに＜ｃｌａｓｓＮａｍｅ＞
．ｃｐｐと呼ばれるファイルを作成し、その内容をファイルに書き込む。

【０１４０】ＪＡＶＡ^TMソース・コード・エクストラクタ５９は、各クラスの属性ｄｅｆｉ
ｎｉｔｉｏｎＴｅｘｔの空でない内容を抽出して、クラスと同じ名前を有しファ
イル拡張子として．ｊａｖａを有するファイルにそれを入れる。最初に、それは
サブディレクトリを作成し、そこではクラスは、ジェネレータおよびエクストラ
クタ・オプション５７で指定される値に基づいて定義される。次に、それはその
パッケージ名の属性ｄｅｆｉｎｉｔｉｏｎＴｅｘｔの内容を抽出し、それをファ
イルに書き込む。次いで、それは、クラスの属性ｄｅｆｉｔｉｏｎＴｅｘｔの内
容を抽出し、それをファイルに書き込む。

【０１４１】Ｓｍａｌｌｔａｌｋ環境は、ｆｉｌｅｏｕｔフォーマットと呼ばれる特定の
フォーマットを有するテキスト・ファイルを読み出すことによって、クラスおよ
びオペレーションの定義をサポートし、Ｓｍａｌｌｔａｌｋエクストラクタはソ
ース・コードを抽出するときにそれを使用することを知ることが重要である。

【０１４２】Ｓｍａｌｌｔａｌｋソース・コード・エクストラクタ５９は、以下のステップ
を実行する。最初に、それは、ジェネレータおよびエクストラクタ・オプション
５７で指定された値に基づいて、ｆｉｌｅｏｕｔディレクトリを作成する。次
に、それは、ジェネレータおよびエクストラクタ・オプション５７で指定された
値によって、１パッケージにつき１つのファイル、または１つの総合ファイルを
作成する。次いで、各クラスについて、エクストラクタは、それが前に処理した
クラスと異なる場合、そのパッケージの属性ｄｅｆｉｎｉｔｉｏｎＴｅｘｔの内
容を書き、そのクラスの属性ｄｅｃｌａｒａｔｉｏｎＴｅｘｔに見られるクラス
宣言を書き、各グループのオペレーションの内容を書くために、各クラスに２回
繰り返し、最後にＳｍａｌｌｔａｌｋエクストラクタは、Ｓｍａｌｌｔａｌｋコ
ードおよび一部のヘッダを区切るために感嘆符文字“！”を書き、オペレーショ
ンがクラスまたはインスタンスとして、かつ公衆または専用として定義されるか
どうかを指定する。

【０１４３】図５ｃを参照して、定数作成について今から説明する。開発者は、１つの目的
クラスにつき１つのオペレーションを生成したい場合、以下の情報を書く必要が
ある。指定しなければならないものは、次のキーワード値すなわちｐｕｂｌｉｃ
、ｐｒｉｖａｔｅ、ｐｒｏｔｅｃｔｅｄまたはｐａｃｋａｇｅのうちの１つを使
用するオペレーションのインタフェース・タイプ値と、キーワード値＆ｉｎｓｔ
ａｎｃｅまたは＆ｃｌａｓｓのうちの１つを使用するオペレーション・タイプ値
と、オペレーション名と、Ｓｍａｌｌｔａｌｋのようなプログラミング言語に使
用されるオプショナル・カテゴリ名と、Ｃ＋＋のようなプログラミング言語に使
用され、ｄｅｃｌａｒｅｄＡｓキーワードを用いて開発者によって指定され、１
つだけのコード文字列をそのコード文字列内で使用される参照クラスのオプショ
ナル・リストと共に使用して実現されるオプショナル宣言句と、ｄｅｆｉｎｅｄ
Ａｓキーワードを用いて開発者によって指定され、１つまたはそれ以上のコード
文字列を各コード文字列に対応付けられる参照クラスのオプショナル・リストと
共に使用して実現されるオプショナル定義句である。

【０１４４】ジェネレータ・エンジン５２は構文解析された情報を得（ステップ１００）、
新しいオペレーション・ノードを作成する（ステップ１０１）。これはステップ
１０８で現在のクラス文脈に追加される。宣言および定義句が省略された場合、
ジェネレータ・エンジン５２はエラーを知らせない。しかし、役に立たない生成
命令セット５６が不要である場合、それらの１つは提供しなければならない。大
抵の場合、宣言句は、Ｃ＋＋のようなプログラミング言語の場合にのみ提供され
、定義句は常に提供される。保守の観点からは、宣言コードに行われた変更を反
映するように決定することができ、その特定のシナリオの場合、意味をなすのは
、定義句無しで宣言コードのみを提供するであろう。

【０１４５】ステップ１０２で、宣言句が提供されると、図５ｆに示すコード文字列の解の
記述で説明するように、ジェネレータ・エンジン５２は提供されたコード文字列
を解き、エンジン５２は生成されたソース・コードを得、新たに作成されたオペ
レーションのｄｅｃｌａｒａｔｉｏｎＴｅｘｔ属性にそれを保存する（ステップ
１０４）。

【０１４６】ステップ１０５で、定義句が提供されると、図５ｅに示す複数のコード文字列
の解の記述で説明するように、ジェネレータ・エンジン５２は提供されたコード
文字列を解き、エンジン５２はキャッシュから生成されたソース・コードを得、
新たに作成されたオペレーションのｄｅｆｉｎｉｔｉｏｎＴｅｘｔ属性にそれを
保存する（ステップ１０７）。

【０１４７】オペレーション作成を扱う各生成命令セット５６に対し、システムは、構文解
析結果に基づいて、各目的クラスごとに１つのオペレーション、または各目的ク
ラスの各修飾属性ごとに１つのオペレーションを作成する。

【０１４８】ジェネレータ・エンジン５２は次の構文解析情報、すなわち、次のキーワード
値つまりｐｕｂｌｉｃ、ｐｒｉｖａｔｅ、ｐｒｏｔｅｃｔｅｄまたはｐａｃｋａ
ｇｅの１つを使用するオペレーションのインタフェース・タイプ値、次のキーワ
ード値つまり＆ｉｎｓｔａｎｃｅまたは＆ｃｌａｓｓの１つを使用するオペレー
ション・タイプ値、オペレーション名変数とその後に続くキーワードｒｅｐｅａ
ｔＦｏｒＥａｃｈとその後に続くその関連属性フィルタ変数とその後に続くキー
ワードｕｓｉｎｇとその後に続く属性文脈変数（ステップ１１６で記述する）、
Ｓｍａｌｌｔａｌｋのようなプログラミング言語に使用されるオプショナル・カ
テゴリ名、Ｃ＋＋のようなプログラミング言語に使用され、ｄｅｃｌａｒｅｄＡ
ｓキーワードを用いて開発者によって指定され、１つだけのコード文字列をその
コード文字列で使用される参照クラスのオプショナル・リストと共に使用して実
現されるオプショナル宣言句、およびｄｅｆｉｎｅｄＡｓキーワードを用いて開
発者によって指定され、１つまたはそれ以上のコード文字列を各コード文字列に
対応付けられる参照クラスのオプショナル・リストと共に使用して実現されるオ
プショナル定義句を得る（ステップ１１１）。

【０１４９】ジェネレータ・エンジン５２は、現在のクラス文脈ノードおよび提供された属
性フィルタ変数を選択基準として使用して、属性サブセットを得る（ステップ１
１２）。属性フィルタ変数は、次のキーワードの組合わせで構成される。すなわ
ち、キーワード＆ａｔｔｒｉｂｕｔｅの後に、値ａｌｌ、ｐｒｉｖａｔｅ、ｐｕ
ｂｌｉｃ、ｐｒｏｔｅｃｔｅｄ、ｐａｃｋａｇｅなど属性インタフェース・タイ
プの現在値に基づく選択基準キーワードが続き、その後にｉｎｓｔａｎｃｅ、ｃ
ｌａｓｓ、またはｃｌａｓｓＡｎｄＩｎｓｔａｎｃｅなど属性タイプの現在値に
基づく選択基準キーワードが続き、その後に次のキーワード・セット、すなわち
ｄｅｆａｕｌｔＶａｌｕｅと呼ばれるオプショナル・プロパティに対応付けられ
る定義値を持つ属性の場合はｈａｖｉｎｇｄｅｆａｕｌｔＶａｌｕｅ、ｔｙｐ
ｅｄｅｆと呼ばれるオプショナル・プロパティに対応付けられる定義値を持つ属
性の場合にはｈａｖｉｎｇｔｙｐｅｄｅｆ、ｏｆｔｙｐｅとその後に続く
提供されたクラス名である。

【０１５０】ジェネレータ・エンジン５２によって作成され結果的に得られる属性サブセッ
トは、提供された選択基準を満足するゼロまたはそれ以上の属性で構成される。

【０１５１】ジェネレータ・エンジン５２は、属性サブセットが空であるかどうかを検出し
（ステップ１１３）、空である場合、現在のクラス文脈のオペレーションを作成
しない。空ではない場合、それは第１属性ノードを処理し（ステップ１１４）、
それを現在のノード文脈として処理する（ステップ１１５）。

【０１５２】ステップ１１６では、ジェネレータ・エンジン５２は、オペレーション名変数
内の文字列％１の全ての出現を、提供された属性文脈変数および現在のノード文
脈と対応付けられるプロパティ値と置換することによって、オペレーション名を
得る。属性文脈変数は、キーワード＆ａｔｔｒｉｂｕｔｅとその後に続く、その
識別子の１つを記述する次のキーワードの１つである。すなわち、ｎａｍｅは属
性名を表す文字列であり、ｉｎｔｅｒｆａｃｅＴｙｐｅは文字列ｐｕｂｌｉｃ、
ｐｒｉｖａｔｅ、ｐｒｏｔｅｃｔｅｄまたはｐａｃｋａｇｅであり、ａｔｔｒｉ
ｂｕｔｅＣｌａｓｓＮａｍｅまたはｃｌａｓｓＮａｍｅは同義語であって、それ
らは属性タイプの名前を表す文字列であり、ｃｏｍｍｅｎｔＤｅｓｃｒｉｐｔｉ
ｏｎは属性の記述を表す文字列であり、ｄｅｆａｕｌｔＶａｌｕｅは属性のデフ
ォルト値を実現するために使用される解かれたコード文字列を表す文字列であり
、ｎａｍｅＡｓＣｌａｓｓＮａｍｅは最初の文字がアッパケースである以外はｎ
ａｍｅと同じであり、ｔｙｐｅｄｅｆは前提条件のｔｙｐｅｄｅｆ構成体を実現
するために使用される解かれたコード文字列を表す文字列であり、ｄｅｆａｕｌ
ｔＶａｌｕｅＯｒＳｐａｃｅは属性に定義されたｄｅｆａｕｌｔＶａｌｕｅが無
い場合にはそれがスペースを表すこと以外はｄｅｆａｌｕｔＶａｌｕｅと同じで
あり、ａｔｔｒｉｂｕｔｅＣｏｎｔｅｎｔｓＣｌａｓｓＮａｍｅは属性がコレク
ションである場合に属性に含まれる要素のｃｌａｓｓＮａｍｅを表す文字列であ
り、ｔｙｐｅＡｓＳｔａｔｉｃＯｒＳｐａｃｅは、属性がクラス属性であるとき
は値ｓｔａｔｉｃを表し、それがインスタンス属性であるときは値ｓｐａｃｅを
表す文字列であり、ｄｅｃｌａｒｅｄＣｌａｓｓＮａｍｅは属性が属するクラス
名を表す文字列である。

【０１５３】属性文脈変数の値は、現在の属性ノード文脈の識別子の値を抽出することによ
って見つけられる。

【０１５４】明らかに、全ての予約語は例として示される。本発明のこの好適な実施形態の
本質を変えることなく、他の予約語を使用することができる。

【０１５５】ジェネレータ・エンジン５２は、前のノード文脈を現在のノード文脈として使
用する（ステップ１１７）。現在のノード文脈は今は、図５ｂで作成された現在
のクラス文脈である。

【０１５６】読み易くするために、ひとたびオペレーション名変数がジェネレータ・エンジ
ン５２によって処理されると（ステップ１１６）、それは定数生成に等しくなる
ので、ステップ１１８ないし１２５はそれぞれステップ１０１ないし１０８と同
一である。

【０１５７】ステップ１２５で、ジェネレータ・エンジン５２は、属性サブセットに別の属
性ノードがあるかどうかを検出する。ある場合、それは次の属性ノードを処理す
る（ステップ１２６）。無い場合、図５ｂの元の位置に戻る。

【０１５８】ジェネレータ・エンジン５２は、図５ｅに示すやり方でパッケージ、クラス、
またはオペレーション・ノードのｄｅｆｉｎｉｔｉｏｎＴｅｘｔ属性に対応付け
られるソース・コードを生成する。

【０１５９】ステップ１３０で、ジェネレータ５２は、構文解析された現在の生成命令セッ
トから指定されたコード文字列のリストから最初のコード文字列を得る。次いで
、図５ｆに示すように、それを単一コード文字列の解と同様に処理する。

【０１６０】それは解かれたコード文字列をキャッシュに追加し（ステップ１３１）、リス
トに処理すべき別のコード文字列があるかどうかを検出する（ステップ１３２）
。別のコード文字列がある場合には、ジェネレータ・エンジン５２はそれを得て
（ステップ１３３）、単一コード文字列の解と同様にそれを処理する。無ければ
、キャッシュから生成されたソース・コードを返す。

【０１６１】図５ｆないし５ｈは、コード文字列の解の流れ図を含む。

【０１６２】図５ｆで、ジェネレータ・エンジン５２は、コード文字列辞書の中を見てそれ
に割り当てられた文字列を持つ提供されたコード文字列名のエントリがあるかど
うかを調べる（ステップ１３５）ことによって、現在のコード文字列がもう解か
れたかどうかを検出する。開発者は、コード文字列を定義するときに、キーワー
ド＆ｂｌｏｃｋＯｆＣｏｄｅとその後に続く名前を用いて、コード文字列の名前
を提供することができる。それが解かれると、ジェネレータはコード文字列辞書
からその値を得る（ステップ１３６）。それが解かれたコード文字列でない場合
には、文脈変数の有無を検出することによって、コード文字列が定数コード文字
列であるかどうかを決定する（ステップ１３７）。

【０１６３】クラス文脈変数および属性文脈変数は、導出されたクラス名または導出された
オペレーション名をそれぞれクラス変数名およびオペレーション変数名から得る
ためにカバーされている。それらは、パラメータ化されたコード文字列と同様の
やり方で適用することができる。

【０１６４】下に列記するように全部で５種類の文脈変数がある。すなわち、クラス文脈変
数、属性文脈変数、オペレーション文脈変数、パッケージ文脈変数、コード文字
列文脈変数である。

【０１６５】オペレーション文脈変数は、キーワード＆ｏｐｅｒａｔｉｏｎとその後に続く
、その識別子の１つを記述する次のキーワードの１つである。すなわち、ｄｅｆ
ｉｎｉｔｉｏｎＴｅｘｔは、オペレーションに対応付けられるｄｅｆｉｎｉｔｉ
ｏｎＴｅｘｔ属性の内容を表す文字列であり、ｄｅｃｌａｒａｔｉｏｎＴｅｘｔ
はオペレーションに対応付けられるｄｅｃｌａｒａｔｉｏｎＴｅｘｔ属性の内容
を表す文字列である。

【０１６６】パッケージ文脈変数は、キーワード＆ｐａｃｋａｇｅとその後に続く、その識
別子の１つを記述する次のキーワードの１つによって表現される。すなわち、ｎ
ａｍｅはパッケージ名を表す文字列であり、ｐａｒｅｎｔＮａｍｅはその親のパ
ッケージ名を表す文字列であり、ｃｏｍｍｅｎｔＤｅｓｃｒｉｐｔｉｏｎはパッ
ケージの記述を表す文字列である。

【０１６７】コード文字列文脈変数は、現在のコード文字列と結合するための提供値として
使用するために、解く必要のある別のコード文字列である。

【０１６８】ステップ１３８で、ジェネレータ・エンジン５２は、文脈変数にキーワードｗ
ｉｔｈが付いているかどうかを検出する。付いている場合、図５ｇに示すように
、パラメータ化されたコード文字列の解が必要である。付いていない場合、それ
は、文脈変数にキーワードｒｅｐｅａｔＦｏｒＥａｃｈが付いていることを意味
し、それについては、図５ｈに示す繰返しパラメータ化コード文字列の解で詳細
に取り上げる。

【０１６９】ひとたびコード文字列が解かれると、ジェネレータ・エンジン５２は、現在の
コード文字列が提供された名前を持つかどうかを決定する（ステップ１３９）。
そうである場合、ジェネレータ・エンジン５２は、提供されたコード文字列名を
キーとして、また解かれたコード文字列を値として使用して、コード文字列辞書
のエントリを追加する（ステップ１４０）。

【０１７０】ステップ１４１で、ジェネレータ・エンジン５２は、現在のコード文字列を備
えた参照クラスがあるかどうかを検出する。ある場合（ステップ１４２）、それ
は参照クラスを現在のノード文脈に追加する。ステップ１４３で、それは、現在
のノード文脈がクラス・ノードかどうかを検出する。そうでない場合、それは、
親ノードがクラス・ノードになるまで、参照クラスをその親ノードに再帰的に追
加する（ステップ１４４）。

【０１７１】今から説明するのは、図５ｇに示すパラメータ化されたコード文字列を解くこ
とである。ジェネレータ・エンジン５２は、コンマによって他から分離された第
１文脈変数を得る（ステップ１５０）。それは、現在の文脈変数が別のコード文
字列であるかどうかを検出する（ステップ１５１）。そうである場合、それは、
図５ｆに示した方法を用いてそれを解き、解かれたコード文字列を提供値として
処理する（ステップ１５２）。文脈変数が別のコード文字列でない場合、それは
現在のノード文脈からその識別子の値を抽出することによって、文脈変数の提供
値を得る（ステップ１５３）。ジェネレータ５２は、文字列％ｎの出現を、前に
示したようにその提供値と結合する（ステップ１５４ないし１５６）。ここでｎ
は１から９の間の整数である。２つ以上の文脈変数がある場合、それらはセミコ
ロンで分離される。

【０１７２】図５ｈでは、指定されたフィルタ変数に対して現在のノード文脈から結果的に
ノードが得られるまで何回も繰り返される、コード文字列を解くプロセスが記述
されている。この種のコード文字列は、行いたいことが、フィルタ変数が現在の
ノード文脈に対して空のセットを返さない場合にだけコード文字列を挿入するこ
とである場合に、便利である。

【０１７３】ステップ１６０で、ジェネレータ・エンジン５２は、次のフィルタ変数、すな
わち属性フィルタ変数、外部プロパティフィルタ変数、オペレーション・フィル
タ変数、スーパクラス・フィルタ変数、参照クラス・フィルタ変数の１つを構文
解析することができる。

【０１７４】外部プロパティ・フィルタ変数は、次のキーワードの組合わせ、すなわちｏｐ
ｅｒａｔｉｏｎｏｆ＆ｄｅｐｅｎｄｅｎｔＣｏｎｃｅｐｔとその後に続く概
念名で構成される。

【０１７５】オペレーション・フィルタ変数は、次のキーワードの組合わせ、すなわちキー
ワード＆ｏｐｅｒａｔｉｏｎと、その後に続く値ａｌｌ、ｐｒｉｖａｔｅ、ｐｕ
ｂｌｉｃ、ｐｒｏｔｅｃｔｅｄ、ｐａｃｋａｇｅなどオペレーションのインタフ
ェース・タイプの現在値に基づく選択基準キーワードと、その後に続く値ｉｎｓ
ｔａｎｃｅ、ｃｌａｓｓ、またはｃｌａｓｓＡｎｄＩｎｓｔａｎｃｅなどオペレ
ーション・タイプの現在値に基づく選択基準キーワードで構成される。

【０１７６】スーパクラス・フィルタ変数は、記号＆ｓｕｐｅｒｃｌａｓｓで構成される。

【０１７７】参照クラス・フィルタ変数は、次のキーワードの組合わせ、すなわち＆ｒｅｆ
ｅｒｒｅｄＣｌａｓｓｎｏｔＫｎｏｗｎＢｙＣｕｒｒｅｎｔと、その後に続く
キーワードｐａｃｋａｇｅまたはｃｌａｓｓで構成される。

【０１７８】ステップ１６１で、ジェネレータ・エンジン５２は、現在のノード文脈に対す
る選択基準となる提供されたフィルタ変数に基づき、結果的に得られるノード・
サブセットを得る。ステップ１６１で、それは、コードを生成する必要が無いか
どうかを検出し、それに該当する場合、空の文字列を返す。それは、最初のノー
ドを新しいノード文脈（ステップ１６３）として処理し、解かれたコード文字列
をキャッシュ（ステップ１６４）に追加し（ステップ１６５）、それを処理する
（ステップ１６６）。それは、結果として得られた生成コードをキャッシュから
返す。

【０１７９】図６は、本発明の好適な実施形態による方法を示す。新しい生成命令セットが
作成される１７０。生成に必要なパラメータが定義され１７１、コード・セグメ
ントが生成される１７２。これらのコード・セグメントを集めて、完全なプログ
ラムを形成することができる。

【０１８０】図７は、本発明の好適な実施形態による別の方法を示す。モデル宣言が指定さ
れる１７５。これは、システム内のオブジェクト、オブジェクト間の関係、およ
び各クラスのオブジェクトを特徴付ける属性およびオペレーションを示すことに
よって、システムの構造をモデル化する。モデルは、生成のために必要なパラメ
ータを提供する。モデル宣言の指定中に、次のエンティティ、すなわちパッケー
ジ、インタフェース、クラス、スーパクラス、外部プロパティ、その関係役割と
の対応付け、属性、オペレーション、およびサブクラスを作成することができる
。次いで、１セットの生成命令が、生成命令セットのグループと共に作成、カス
タマイズ、または順序付けられる１７６。最後に、完全なコンピュータ・ソース
・コードが生成され１７７、ユーザが修正したり適応させる必要はない。

【０１８１】図８は、好適な方法によって生成されたソース・コードがユーザによるコード
の過度な操作無しで修正され、再生される、本発明の別の好適な実施形態による
方法を示す。コードはテキスト・エディタまたはユーザ・インタフェースで検索
される１８０。ユーザは、どんな修正がソース・コードに必要かを評価する１８
１。生成命令セットへのポインタが得られる１８２。必要ならば、モデル宣言お
よび生成パラメータへのポインタも得られる。次いで、生成命令セット、モデル
宣言、および生成パラメータ（フィルタ変数、文脈変数、および使用される各種
のコードのブロック数）の少なくとも１つに変更が行われる１８３。この変更は
自動的に、またはユーザが手動で行うことができる。行われた変更により、生成
命令セットの順序が変化したり、再順序付けが発生することがある。最終的に、
適切な変更が行われたときに、コンピュータ・ソース・コードを再生することが
できる。

【０１８２】図９は、本発明の好適な実施形態による装置のブロック図である。生成命令セ
ットを作成または修正するために、エディタ１８５が使用される。これらのセッ
トはマネージャ１８６で管理することができ、そこでそれらは順序付けることが
できる。文脈情報エディタ１９３も含まれる。生成命令セットおよび文脈情報は
ソース・コード・ジェネレータ１８７に送られ、これは文脈情報およびソース・
コード出力１８８に生成されたソース・コードを用いて、生成命令セットを処理
する。オプショナル言語データベース１８９は、プログラミング言語をサポート
するために、ジェネレータ１８７をカスタマイズする１セットのオプションを提
供することができる。オプショナル・ポインタ・データ・ジェネレータ１９０も
また含めることができ、これはどの生成命令セットが生成中に使用されたかを識
別するポインタ・データ１９１を生成する。それはまた、文脈情報のどの部分が
生成に使用されたかを識別することもできる。ポインタとソース・コードの複合
出力１９２を生成することができる。ポインタ・データは、生成されたソース・
コード中の注釈行として、またはコンサルテーションのために別個のファイルと
して含めることができる。

【０１８３】図１０は、本発明の好適な実施形態による別の装置を示す。複合ポインタ・デ
ィスプレイおよびソース・コード・エディタ１９５が提供される。前に生成され
たソース・コードに変更を行わなければならないときに、生成命令マネージャ１
９６は、指摘された生成命令を検索し、生成命令エディタ１９７でそれらを表示
することができる。必要ならば、モデル宣言のポインタをして、モデル・エディ
タ２０１でモデル宣言を検索することもできる。生成命令およびモデル宣言の変
更は手動で、または前に生成されたソース・コードに行われた変更を使用して自
動的に行うことができる。次いで、生成命令セットおよびモデル宣言はソース・
コード・ジェネレータ１９８に送られ、これはソース・コード出力１９９を生成
する。しかし、使用した最新バージョンのソース・コードがいつでも最新バージ
ョンの生成命令セットおよびモデル宣言を使用して再生できることを確実にする
ために、ソース・コードに直接行われた変更は全て、生成命令セットおよびモデ
ル宣言に反映されることが重要である。再び、オプショナル言語データベース２
００を含めることができる。複合ポインタ・データおよびソース・コード出力２
０３を生成するために、オプショナル・ポインタ・データ・ジェネレータ２０２
を追加することもできる。

【０１８４】構文を本発明の好適な実施形態と完全に一貫させるために、図１３および図１
４に示す構文に関するさらなる詳細が必要である。

【０１８５】図１３では、ＰａｃｋａｇｅＮａｍｅＣｌａｕｓｅの定義で、Ｐａｃｋａｇｅ
Ｎａｍｅ１を完全に修飾しなければならない。ＰａｃｋａｇｅＮａｍｅ２は、Ｊ
ＡＶＡ^TMでは使用されない。

【０１８６】ｉｎｔｅｒｆａｃｅＣｌａｕｓｅおよびｃｌａｓｓＣｌａｕｓｅの定義では、
ｉｎｔｅｒｆａｃｅＮａｍｅおよびｃｌａｓｓＮａｍｅはピリオド記号を含むこ
とはできない。

【０１８７】ｓｕｐｅｒｃｌａｓｓＣｌａｕｓｅの定義では、「；」記号は、２つ以上のス
ーパクラスをインタフェースに含めることができないことを意味する。

【０１８８】ｏｐｅｒａｔｉｏｎＮａｍｅの定義で、オペレーション・シグネチャ選択子（
オペレーション名ではなく）は、次の情報を含むオペレーション・シグネチャ全
体を含まなければならない。・ｉｎｔｅｒｆａｃｔＴｙｐｅ・Ｓｔａｔｉｃ（オプション）・Ｓｙｎｃｈｒｏｎｉｚｅｄ（オプション）・Ｎａｔｉｖｅ（オプション）・返されるタイプまたはボイド（無い場合）・オペレーション名・ ´（´ ・パラメータ・タイプから始まりその後にパラメータ名が続くパラメータの
リスト・ ´）´

【０１８９】図１４で、ｇｅｎｅｒａｔｉｏｎＩｎｓｔｒｕｃｔｉｏｎの定義で、モデリン
グ・ツールから存在した既存のｃｌａｓｓＲｅｃｅｉｖｅｒＥｘｐｒｅｓｓｉｏ
ｎを生成するときに、ｎｅｅｄＴｏＢｅＧｅｎｅｒａｔｅｄキーワードが使用さ
れる。デフォルトでは、既存のノード（クラスまたはインタフェース）は生成さ
れず、新しいノードが生成される。

【０１９０】ａｔｔｒｉｂｕｔｅＳｕｂＥｘｐｒｅｓｓｉｏｎの定義で、他に何も付けずに
使用される＆ａｔｔｒｉｂｕｔｅを含めることは、インタフェースまたはクラス
が属性を含む場合に、生成命令セットを処理する必要があることを意味する。ｓ
ｉｎｇｌｅＣｏｎｓｔａｎｔＣｒｅａｔｉｏｎＤｅｃｌａｒａｔｉｏｎの定義お
よびｖａｒｉａｂｌｅＣｒｅａｔｉｏｎＤｅｃｌａｒａｔｉｏｎの定義で、ｄｅ
ｆｉｎｉｔｉｏｎＣｌａｕｓｅは、インタフェースおよびクラスを作成するとき
にスーパクラス名を定義するため、および属性を作成するときにそのデフォルト
値を定義するために使用される。

【０１９１】ｖａｒｉａｂｌｅＣｒｅａｔｉｏｎＤｅｃｌａｒａｔｉｏｎの定義で、ｖａｒ
ｉａｂｌｅＣｒｅａｔｉｏｎＤｅｃｌａｒａｔｉｏｎは１つの項目だけを作成す
るか、あるいは「ｗｉｔｈ」または「ｒｅｐｅａｔＦｏｒＥａｃｈ−ｕｓｉｎｇ
」句を用いて繰返し使用されるときには、多くの項目を作成することに注意しな
ければならない。ｖａｒｉａｂｌｅＮａｍｅＣｌａｕｓｅのオペレーション名は
、次の情報を含むオペレーション・シグネチャ全体を含まなければならない。・ｉｎｔｅｒｆａｃｔＴｙｐｅ・Ｓｔａｔｉｃ（オプション）・Ｓｙｎｃｈｒｏｎｉｚｅｄ（オプション）・Ｎａｔｉｖｅ（オプション）・返されるタイプまたはボイド（無い場合）・オペレーション名・ ´（´ ・パラメータ・タイプから始まりその後にパラメータ名が続くパラメータの
リスト・ ´）´

【０１９２】ｖａｒｉａｂｌｅＮａｍｅＣｌａｕｓｅ定義で、ｃｏｄｅＳｔｒｉｎｇＳｔａ
ｔｅｍｅｎｔＣｌａｕｓｅは、ｇｒｏｕｐＣｏｎｔｅｘｔＶａｒｉａｂｌｅを使
用できる唯一の場所である。

【０１９３】ｖａｒｉａｂｌｅＮａｍｅはスペースを含めてはならないが、２つ以上の文脈
変数を参照することができる。

【０１９４】ｉｎｔｅｒｆａｃｅＮａｍｅＦｉｌｔｅｒは、２つ以上のインタフェースを返
すことができる。

【０１９５】ｃｏｎｓｔａｎｔＮａｍｅは、次の情報を含むオペレーション・シグネチャ全
体を含まなければならない。・ｉｎｔｅｒｆａｃｔＴｙｐｅ・Ｓｔａｔｉｃ（オプション）・Ｓｙｎｃｈｒｏｎｉｚｅｄ（オプション）・Ｎａｔｉｖｅ（オプション）・返されるタイプまたはボイド（無い場合）・オペレーション名・ ´（´ ・パラメータ・タイプから始まりその後にパラメータ名が続くパラメータの
リスト・ ´）´

【０１９６】ｆｉｌｔｅｒＶａｒｉａｂｌｅの定義では、ジェネレータのデフォルト文脈が
常にｒｅｆｅｒｅｎｃｅｓＮｏｄｅであり、これはｄｅｒｉｖｅｄＣｌａｓｓの
場合ｂａｓｅｄＣｌａｓｓであり、ｂａｓｅｄＣｌａｓｓの場合それ自体である
ことに注意しなければならない。＆ｓｕｐｅｒｃｌａｓｓおよび＆ｓｕｂｃｌａ
ｓｓは、デフォルト文脈から１レベル進むだけである。＆ｓｕｂｃｌａｓｓは２
つ以上のクラスを返すことができ、＆ｉｍｐｌｅｍｅｎｔｅｄＩｎｔｅｒｆａｃ
ｅはクラス定義にのみ使用される。

【０１９７】ｇｒｏｕｐＯｆＦｉｌｔｅｒＶａｒｉａｂｌｅの定義で、このフィルタ変数は
、＆ｇｒｏｕｐと呼ばれる文脈変数に対応付けられる１ブロックのコードを生成
する。

【０１９８】ａｓｓｏｃｉａｔｉｏｎＦｉｌｔｅｒＶａｒｉａｂｌｅの定義で、他に何も付
けずに役割を伴う＆Ａｓｓｏｃｉａｔｉｏｎを使用することは、インタフェース
またはクラスが連想を含むときに生成命令が処理されることを意味する。

【０１９９】ｅｘｔｅｒｎａｌＰｒｏｐｅｒｔｙＣｏｎｔｅｘｔＶａｒｉａｂｌｅｓの定義
で、“＋”符合は、ＢｌｏｃｋＯｆＣｏｄｅに対応付けられるｂａｓｅＩｎｃｒ
ｅｍｅｎｔを外部プロパティの値に加算する。“＋＋”符合は同じことを行い、
加算の結果をｂａｓｅＩｎｃｒｅｍｅｎｔの新しい値として維持する。

【０２００】ｃｏｍｍｕｎＣｏｎｔｅｘｔＶａｒｉａｂｌｅの定義では、文字“＃”は文脈
変数の内容に対応付けられるパッケージ・ロケーションをそのＢｌｏｃｋＯｆＣ
ｏｄｅに対応付けられるｒｅｆｅｒｒｅｄｌｏｃａｔｉｏｎ句に追加する。

【０２０１】ｆｉｌｔｅｒＶａｒｉａｂｌｅＣｏｎｔｅｘｔＶａｒｉａｂｌｅの定義におい
て、ＢｌｏｃｋＯｆＣｏｄｅは、現在のフィルタ変数式に関連付けられる各々の
結果的に得られるノードに対して繰り返してはならない唯一の文脈変数であるの
で、ユーザは、ｎｕｂｅｒＯｆＩｔｅｍｓを使用するときに、別個のＢｌｏｃｋ
ＯｆＣｏｄｅを作成しなければならない。インデックスの開始値は、その中に含
まれる繰返しコード文字列の基本増分である。

【０２０２】

【実施例１】本発明は、本発明の範囲を限定するためではなく、発明を解説するために提示
する次の例を特に参照することにより、いっそうよく理解されるであろう。この
例で取り扱うコードは、アプリケーションを実行するのに充分ではないが、生成
できる類いのコードについての概念を与える。

【０２０３】本発明の好適な実施形態に従って、ＪＡＶＡ^TMのジェネレータは、任意のフレ
ームワークのＪＡＶＡ^TMコードの生成を可能にする。この例は、アプリケーショ
ン・コンポーネントとデータベースに格納されたそれらに対応付けられるデータ
との間で実現される持続性サービスによりＥｎｔｅｒｐｒｉｓｅＪａｖａＢｅ
ａｎｓ^TM（ＥＪＢ）の生成を例証する。この例で取り扱うモデルおよびアプリケ
ーション・コードは、ＩＢＭＶｉｓｕａｌＡｇｅｆｏｒＪＡＶＡ^TM２．０
から取ったものであり、これはＥＪＢの仕様を実現するコードを生成する。残念
ながら、ＶｉｓｕａｌＡｇｅｆｏｒＪＡＶＡ^TMは、インプリメンテーション
・データを捕獲するために固有のグラフィカル・ユーザ・インタフェースを使用
しているので、生成されるコードの単一のデータ源として会社がモデリング・ツ
ールを使用することは妨げられる。

【０２０４】本発明の好適な実施形態によるジェネレータは、モデルから同一コードを生成
することができ、それにより、好適な実施形態に従ってジェネレータによって生
成されたコードを、生成された後で手動的に介入する必要がないので、保守努力
が軽減される。ジェネレータは生成命令セットを利用して、生成する必要のある
クラスおよび方法を生成し、調整する。

【０２０５】ＲａｔｉｏｎａｌＲｏｓｅ９８ｉＥｎｔｅｒｐｒｉｓｅＥｄｉｔｉｏ
ｎで生成された次のサンプル・モデルは、バンキング・アプリケーションの中核
サービスを定義する。それを図５ｇに図示し、それに対応する宣言を表１に示す
。ＲａｔｉｏｎａｌＲｏｓｅ９８ｉアドインとして実装された好適な実現に
係るジェネレータにより利用可能な機能を使用して、上記モデルは外部プロパテ
ィの定義を含み、これはこの場合、各属性をアプリケーション・データベースに
含まれるフィールドにマッピングすることができる。開発者は、外部プロパティ
のグループを作成し、それらを１セットのクラスまたは属性に割り当てることが
できる。ひとたび外部プロパティが定義されると、開発者は、これらのプロパテ
ィに対応付けられた値にアクセスして、生成命令セットを作成することができる
。

【表１の１】

【表１の２】

【表１の３】

【表１の４】

【０２０６】（ＥＪＢクラスの生成）モデルに含まれるクラスは、ＥｎｔｅｒｐｒｉｓｅＪａｖａＢｅａｎｓ^TM仕
様を実現する１組の対応するクラスを各々生成するために使用される。モデルか
ら取られた各クラスについて、ＪＡＶＡ^TM用のジェネレータは、次の導出クラス
を生成する。・ＥＪＢクラスおよびインタフェースのリスト・ＮＡＭＥＢｅａｎ（ＥＪＢＢｅａｎ用）・ＮＡＭＥ（ＥＪＢＲｅｍｏｔｅＩｎｔｅｒｆａｃｅ用）・ＮＡＭＥＨｏｍｅ（ＥＪＢＨｏｍｅＩｎｔｅｒｆａｃｅ用）・ＮＡＭＥＫｅｙ（ＥＪＢＫｅｙクラスまたはフィールド用）・および前述のＥＪＢインタフェースを実現する以下のクラス・ＮＡＭＥｌｍｐ（ＥＪＢＲｅｍｏｔｅＩｎｔｅｒｆａｃｅの実現用）・ＮＡＭＥＨｏｍｅＩｍｐＩ（ＥＪＢＨｏｍｅＩｎｔｅｒｆａｃｅの実現用
）

【０２０７】ここで、ＮＡＭＥは、モデルＥＪＢＢＥＡＮから取った各クラスの名前を表
す。

【０２０８】これらの導出クラスを生成するために使用した幾つかの生成命令セットを、表
２に示す。

【表２】

【０２０９】エンティティ・ビーン・クラスのビジネス方法は、インスタンスをどのように
操作できるかを定義する。ＥＪＢＢｅａｎクラスは、ＥＪＢＢｅａｎエンテ
ィティに次の標準的方法を実現するＶａｐＥｎｔｉｔｙＢｅａｎＩｍｐｌｅのサ
ブクラスである。・ｅｊｂＡｃｔｉｖａｔｅ・・ｅｊｂＣｒｅａｔｅ・ｅｊｂＬｏａｄ・ｅｊｂＰａｓｓｉｖａｔｅ・ｅｊｂＰｏｓｔＣｒｅａｔｅ・ｅｊｂＲｅｍｏｖｅ・ｓｅｔＥｎｔｉｔｙＣｏｎｔｅｘｔ・ｕｎｓｅｔＥｎｔｉｔｙＣｏｎｔｅｘ
ｔ

【０２１０】上記の方法は、ＶａｐＥｎｔｉｔｙＢｅａｎＩｍｐｌによって実現されるので
、生成されたクラスのためにこれらの方法を実現する必要は無いことに注意され
たい。

【０２１１】ＪＡＶＡ^TMのジェネレータは、ＥＪＢＢｅａｎクラスに対して以下の方法を
生成する。・各属性に対して、属性のＧｅｔおよびＳｅｔ法を生成する１セットの生成命令
・ナビゲーション可能（navigable）であり、上限が´１´の基数を有する連想
の各目的役割に対して、役割のＧｅｔおよびＳｅｔ法を生成する１セットのナビ
ゲーション可能な生成命令・ナビゲーション可能（navigable）であり、上限が´ｎ´の基数を有する連想
の各目的役割に対して、役割のＧｅｔおよびＳｅｔ法のみならず、導出されたク
ラスＬｉｎｋおよびＫｅｙのＧｅｔおよびＳｅｔ法、つまりＢｒａｎｃｈ役割の
場合ｓｅｔＢｒａｎｃｈＬｉｎｋおよびｓｅｔＢｒａｎｃｈＫｅｙをも生成する
１セットの生成命令・役割を隠蔽するオブジェクトを初期化するｉｎｉｔｉａｌｉｚｅＲｅｌａｔｉ
ｏｎｓｈｉｐｓ法・ＥＪＢＯｂｊｅｃｔの実現のためのＡＮＡＭＥＩｍｐｌクラス

【０２１２】これらの生成された部分の幾つかのための生成命令セットを、表３および表４
に示す。

【表３】

【表４】

【０２１３】（ＥＪＢリモート・インタフェース）クライアントは、エンティティ・ビーンのリモート・インタフェースを介して
エンティティ・オブジェクトにアクセスする。リモート・インタフェースは、ク
ライアントが利用できるビジネス方法を定義する。ＪＡＶＡ^TM用のジェネレータ
は、リモート・インタフェースで定義しなければならない方法を生成する。

【０２１４】したがって、次のものがある。・各属性に対して、属性のＧｅｔおよびＳｅｔ法を生成する１セットの生成命令
・ナビゲーション可能（navigable）であり、上限が´１´の基数を有する連想
の各目的役割に対して、役割のＧｅｔおよびＳｅｔ法を生成する１セットの生成
命令・ナビゲーション可能（navigable）であり、上限が´ｎ´の基数を有する連想
の各目的役割に対して、役割のＧｅｔおよびＳｅｔ法のみならず、導出されたク
ラスＬｉｎｋおよびＫｅｙのＧｅｔおよびＳｅｔ法、つまりＢｒａｎｃｈ役割の
場合ｓｅｔＢｒａｎｃｈＬｉｎｋおよびｓｅｔＢｒａｎｃｈＫｅｙをも生成する
１セットの生成命令

【０２１５】（ＥＪＢホーム・インタフェース）ホーム・インタフェースは、クライアントがエンタプライズ・ビーンのインス
タンスを作成したり除去するため、およびインスタンスに関するメタデータを得
るために使用される方法を定義する。ＪＡＶＡ^TM用のジェネレータでは、次のも
のがある。・一次キーを提示する属性をパラメータとして使用することにより、Ｃｒｅａｔ
ｅ方法を生成する１セットの生成命令・一次キーを提示する属性をパラメータとして使用することにより、Ｆｉｎｄ方
法を生成する１セットの生成命令・上限がＷの基数を持つ目的役割のｇｅｔＲＯＬＥＬｉｔｅＣｏｌｌｅｃｔｉｏ
ｎアクセス方法を生成する１セットの生成命令・ホーム・インタフェースを実現するクラスを生成する１セットの生成命令ホーム・インタフェースで示した方法シグネチャに対応付けられる方法の内容は
完全に生成され、開発者が手動で介入する必要はない。

【０２１６】（ＥＪＢキー・クラス）このクラスは、ＥＪＢＯｂｊｅｃｔの一次キーを管理するために使用される。
Ｋｅｙクラスに対応付けられる生成コードは、次のものにより生成される。・デフォルト構成体を生成する１セットの生成命令・ｐｒｉｍａｒｙＫｅｙおよびｌａｓｔＮａｍｅを引数とする構成体を生成する
１セットの生成命令・等値法（equal method）を生成する１セットの生成命令・ハッシュ法を生成する１セットの生成命令

【０２１７】（ＥＪＢリモート・インタフェースを実現するクラス）ＮＡＭＥＩｍｐｌと呼ばれるクラスに必要な方法を生成するには、１セットの
生成命令が必要である。一例として、図５ｈのクラス・ダイアグラムに示したＶ
ａｐＡｃｃｏｕｎｔｌｍｐｌクラスの全ての方法を生成し、ｆｉｒｅＰｒｏｐｅ
ｒｔｙＣｈａｎｇｅ（）方法の生成コードを表１０に記載する。ｆｉｒｅＰｒｏ
ｐｅｒｔｙＣｈａｎｇｅ（）コードの幾つかを生成するために使用される生成命
令セットを、表５に示す。

【表５】

【０２１８】（ＥＪＢホーム・インタフェースを実現するクラス）ＮＡＭＥＨｏｍｅＩｍｐｌと呼ばれるクラスに必要な方法を生成するには、１
セットの生成命令が必要である。一例として、図５ｈのクラス・ダイアグラムに
示したＶａｐＡｃｃｏｕｎｔＨｏｍｅｌｍｐｌクラスの全ての方法を生成し、ｉ
ｎｉｔｉａｌｉｚｅＲｅｌａｔｅＨｏｍｅ（）方法の生成コードを表１１に記載
する。

【０２１９】（ＶＡＰＡＣＣＯＵＮＴに生成されたＥＪＢクラス）図５ｈは、ＶａｐＡｃｃｏｕｎｔクラスに生成されたクラスとインタフェース
のセットを示す。ＪＡＶＡ^TM用の好適な実施形態に係るジェネレータは、モデリ
ング・ツールに含まれる各クラスについて、対応付けられる属性および役割によ
って異なる方法およびクラスの等価的セットを生成する。

【０２２０】表６ないし１１は、モデル宣言および命令セットの完全なセットを用いて生成
されたコードを示す。

【表６】

【表７】

【表８】

【表９】

【表１０】

【表１１】

【０２２１】本発明を、例で示した実施形態を特に参照しながら説明したが、それに対する
多くの変形が当業者には明白であることは理解されるであろう。したがって、上
記説明および添付の図面は、限定としてではなく、本発明の解説として受け止め
るべきである。使用したプログラミング言語はＪＡＶＡ^TMであるが、ジェネレー
タは、例えばＣ＋＋およびＳｍａｌｌＴａｌｋなど、他の言語でも使用すること
ができる。

【０２２２】本発明を、その特定の実施形態に関連して説明したが、さらなる変形が可能で
あり、本願が、一般的に本発明の原理に従っており、本発明が関係する技術分野
内で周知または習慣的な慣行の範囲内に入るような本発明からの逸脱を含んでお
り、ここに記載する本質的な特徴に適用され、かつ請求の範囲に従うような発明
の変形、使用、または適用を網羅するつもりであることは理解されるであろう。

【図面の簡単な説明】

【図１】先行技術を表すブロック図である。

【図２】先行技術を表す流れ図である。

【図３】本発明の環境についての一般ブロック図である。

【図４】本発明の一般ブロック図である。

【図５ａ】ソース・コード生成の概要の第１流れ図である。

【図５ｂ】ソース・コード生成の概要の第２流れ図である。

【図５ｃ】定数生成の流れ図である。

【図５ｄ】変数生成の流れ図である。

【図５ｅ】複数のコード文字列の解の流れ図である。

【図５ｆ】コード文字列の解の流れ図である。

【図５ｇ】パラメータ化コード文字列の解の流れ図である。

【図５ｈ】繰返しパラメータ化コード文字列の解の流れ図である。

【図６】生成命令のセットおよびパラメータを使用したソース・コードの生成の流れ図
である。

【図７】モデル宣言および生成命令のセットを使用したソース・コードの生成の流れ図
である。

【図８】生成命令のセットまたはモデルを修正することによって行われるソース・コー
ドの修正の流れ図である。

【図９】ソース・コード・ジェネレータのブロック図である。

【図１０】修正ツールのブロック図である。

【図１１】バンキング・アプリケーションのためのモデル宣言を示すブロック図である。

【図１２】ＶａｐＡｃｃｏｕｎｔのために生成されたＥＪＢクラスを示すブロック図であ
る。

【図１３】好適な実施形態を実現するために使用できる、Ｂａｃｋｕｓ−Ｎａｕｒフォー
マットのモデル宣言のための特定の構文を示すブロック図である。

【図１４】好適な実施形態を実現するために使用できる、Ｂａｃｋｕｓ−Ｎａｕｒフォー
マットの生成命令セットのための特定の構文を示すブロック図である。

───────────────────────────────────────────────────── フロントページの続き (81)指定国ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＣＹ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＧＷ，ＭＬ，ＭＲ，ＮＥ，ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＧＨ，ＧＭ，ＫＥ，ＬＳ，ＭＷ，ＳＤ，ＳＬ，ＳＺ，ＴＺ，ＵＧ，ＺＷ )，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ，ＲＵ，ＴＪ，ＴＭ)，ＡＥ，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ，ＢＡ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＲ，ＣＵ，ＣＺ，ＤＥ，ＤＫ，ＤＭ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＤ，ＧＥ，ＧＨ，ＧＭ，ＨＲ，ＨＵ，ＩＤ，ＩＬ，ＩＮ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＣ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＡ，ＭＤ，ＭＧ，ＭＫ，ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＳＬ，ＴＪ，ＴＭ，ＴＲ，ＴＴ，ＴＺ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ，ＹＵ，ＺＡ，ＺＷ (71)出願人Ｓｕｉｔｅ 1020， 2075 ＵｎｉｖｅｒｓｉｔｙＳｔｒｅｅｔ，Ｍｏｎｔｒｅａｌ，ＱｕｅｂｅｃＨ３Ａ２Ｌ１ＣＡＮＡＤＡ

Claims

【特許請求の範囲】

【請求項１】コンポーネント・ベース型言語でコンピュータ・ソース・コ
ードを生成するための方法であって、少なくとも１つのフィルタ変数と少なくとも２つの文脈変数によりパラメータ
化された目的ソース・コードとを表す少なくとも１セットの生成命令を作成する
ステップであって、各々の前記少なくとも１つのフィルタ変数は生成の動的文脈
を指示するために使用され、各々の前記少なくとも２つの文脈変数は参照ノード
および参照ノード識別子を示し、前記少なくとも２つの文脈変数は少なくとも２
つの異なる参照ノードを指示するように構成されたステップと、前記少なくとも１組の生成命令のための前記少なくとも２つの文脈変数の前記
参照ノードおよび前記参照ノード識別子を定義するステップと、前記生成命令セット内で前記少なくとも２つの文脈変数を、前記少なくとも１
つのフィルタ変数によって定義された前記動的文脈に見られる前記参照ノード識
別子の値と置換することによって、コンポーネント要素に対して前記コンポーネ
ント・ベース型ソース・コード言語で複数のコード・セグメントを生成するステ
ップとを含む方法。
【請求項２】前記参照ノード識別子の前記値がジェネレータの現在の文脈
の参照ノードから得られる、請求項１に記載の方法。
【請求項３】前記参照ノード識別子の前記値がジェネレータの現在の文脈
の参照ノードの親ノードから得られる、請求項１に記載の方法。
【請求項４】複数のコード・セグメントを生成する前記ステップが新しい
コンポーネントを生成することを含む、請求項１に記載の方法。
【請求項５】複数のコード・セグメントを生成する前記ステップが新しい
方法を生成することを含む、請求項１に記載の方法。
【請求項６】複数のコンポーネントを定義する１セットのコード・セグメ
ントが得られるまで、前記ステップが繰り返される、請求項１に記載の方法。
【請求項７】前記コンポーネント・ベース型言語がオブジェクト指向言語
である、請求項１に記載の方法。
【請求項８】前記参照ノードがクラスである、請求項１に記載の方法。
【請求項９】前記参照ノードが属性である、請求項１に記載の方法。
【請求項１０】前記識別子が名前である、請求項１に記載の方法。
【請求項１１】前記識別子がタイプである、請求項１に記載の方法。
【請求項１２】前記生成ステップが、前記コード・セグメントのプログラ
ミング言語を選択することを含む、請求項１に記載の方法。
【請求項１３】各々の前記コード・セグメントについて、前記コード・セ
グメント生成ステップで使用された前記生成命令セットを指すポインタ・データ
を生成するステップをさらに含む、請求項１に記載の方法。
【請求項１４】文脈変数のリストから前記少なくとも１つの文脈変数を選
択するステップをさらに含む、請求項１に記載の方法。
【請求項１５】前記少なくとも１つの文脈変数が、それを文脈変数パラメ
ータとして識別する先行記号文字を使用して、前記少なくとも１セットの生成命
令で表現される、請求項１に記載の方法。
【請求項１６】前記ポインタ・データが前記複数のコード・セグメントか
ら別個のファイルに格納される、請求項１３に記載の方法。
【請求項１７】前記ポインタ・データが前記コード・セグメント全体にわ
たって注釈行として示される、請求項１３に記載の方法。
【請求項１８】コンポーネント・ベース型言語でコンピュータ・ソース・
コードを生成するための方法であって、各コンポーネントのモデル宣言を指定するステップと、少なくとも１つのフィルタ変数と少なくとも２つの文脈変数によりパラメータ
化された目的ソース・コードとを表す１グループの生成命令セットを提供するス
テップであって、各々の前記少なくとも１つのフィルタ変数は生成の動的文脈を
指示するために使用され、各々の前記少なくとも２つの文脈変数は参照ノードお
よび識別子を指示するように構成されたステップと、前記グループに統合すべき１セットの生成命令の作成、順序付け、およびカ
スタマイズの少なくとも１つを実行するステップと、前記モデル宣言および生成命令セットの前記セットから前記ソース・コード言
語の完全なコンピュータ・ソース・コードを生成するステップとを含み、それにより前記モデル宣言が文脈データに変換され、生成命令セットの前記セ
ットと結合されて完全なコンピュータ・ソース・コードを生成する方法。
【請求項１９】前記生成ステップが、前記コンピュータ・ソース・コード
のプログラミング言語を選択することを含む、請求項１８に記載の方法。
【請求項２０】前記グループに統合すべき生成命令セットの作成、順序付
け、およびカスタマイズのうちの少なくとも１つを実行する前記ステップが、少
なくとも作成することを含む、請求項１８に記載の方法。
【請求項２１】前記グループに統合すべき生成命令セットの作成、順序付
け、およびカスタマイズのうちの少なくとも１つを実行する前記ステップが、少
なくとも順序付けることを含む、請求項１８に記載の方法。
【請求項２２】前記グループに統合すべき生成命令セットの作成、順序付
け、およびカスタマイズのうちの少なくとも１つを実行する前記ステップが、少
なくともカスタマイズすることを含む、請求項１８に記載の方法。
【請求項２３】各コード・セグメントについて、前記生成ステップで使用
された生成命令セットを指すポインタ・データを生成するステップをさらに含む、請求項１８に記載の方法。
【請求項２４】各コード・セグメントについて、前記生成ステップで使用
されたモデル宣言の部分を指すポインタ・データを生成するステップをさらに含
む、請求項２３に記載の方法。
【請求項２５】前記ポインタ・データが前記完全なコンピュータ・ソース
・コードから別個のファイルに格納される、請求項２３に記載の方法。
【請求項２６】前記ポインタ・データが前記コード・セグメント全体にわ
たって注釈行として示される、請求項２３に記載の方法。
【請求項２７】前記モデル宣言が自己記述木構造を含み、前記生成命令セ
ットが、前記生成命令セット内に見られる文脈変数の各参照ノードおよび識別子
について、前記モデル宣言内に見られる対応するサブ構造を示すマッピング・テ
ーブルにより前記モデル宣言に結合される、請求項１８に記載の方法。
【請求項２８】前記モデル宣言が複数のコンポーネント・ベース型言語に
汎用である、請求項１８に記載の方法。
【請求項２９】第１コンポーネント・ベース型言語で書かれた前記少なく
とも１セットの生成命令を第２コンポーネント・ベース型言語に翻訳するステッ
プをさらに含み、それによりコンピュータ・ソース・コードが第２コンポーネン
ト・ベース型で生成される、請求項２８に記載の方法。
【請求項３０】前記第１コンポーネント・ベース型言語がＪＡＶＡ^TMであ
り、前記第２コンポーネント・ベース型がＣ＋＋である、請求項２９に記載の方
法。
【請求項３１】前記翻訳が自動化される、請求項２９に記載の方法。
【請求項３２】少なくとも１つのフィルタ変数と少なくとも１つの文脈変
数によりパラメータ化された目的ソース・コードとを表す生成命令を含む１セッ
トの動的生成を使用して生成されたコンピュータ・ソース・コードを修正するた
めの方法であって、各々の前記少なくとも１つのフィルタ変数は生成の動的文脈
を指示するために使用され、各々の前記文脈変数は参照ノードおよび識別子なら
びに生成パラメータおよびモデル宣言の１つを示し、前記方法が、使用された生成命令セットおよびモデル宣言を指示したポインタ・データを検
索することを含めて、前記生成されたコンピュータ・ソース・コードを検索し、変更を必要とする前記ソース・コードの少なくとも一部分を見つけ出し、前記部分から前記検索されたポインタを使用して、生成命令セット、文脈情報
、およびモデル宣言のうちの少なくとも１つを捜し出して変更し、前記生成命令セットならびに前記パラメータおよびモデル宣言の１つから完全
なコンピュータ・ソース・コードを生成することを含む方法。
【請求項３３】前記ポインタ・データが前記コード・セグメント全体にわ
たって注釈行として示される、請求項３２に記載の方法。
【請求項３４】コンポーネント・ベース型言語でコンピュータ・ソース・
コードを生成するための装置であって、少なくとも１つのフィルタ変数と少なくとも１つの文脈変数によりパラメータ
化された目的ソース・コードとを表す生成命令を含む少なくとも１セットの生成
命令の作成およびカスタマイズの１つを実行するためのテンプレート・エディタ
であって、各々の前記少なくとも１つのフィルタ変数は生成の動的文脈を指示す
るために使用され、各々の前記文脈変数は参照ノードおよび識別子を指示するよ
うに構成されたテンプレート・エディタと、前記少なくとも１セットの生成命令を選択し順序付け、かつ生成パラメータを
設定するためのテンプレート・マネージャと、前記少なくとも１セットの生成命令、前記少なくとも１つのフィルタ変数、お
よび前記少なくとも１つの文脈変数を使用して、コンポーネント要素に対して前
記ソース・コード言語で複数のコード・セグメントを生成するソース・コード・
ジェネレータとを含む装置。
【請求項３５】ジェネレータのソース・コード言語を選択するために１セ
ットのソース・コード言語データベースをさらに含む、請求項３４に記載の装置
。
【請求項３６】各々の生成されたコード・セグメントに使用された生成命
令セットを識別するポインタ・データを生成するためのポインタ・データ・ジェ
ネレータをさらに含む、請求項３４に記載の装置。
【請求項３７】前記ポインタ・データ・ジェネレータが前記ポインタ・デ
ータを、生成されたコード・セグメント全体にわたって注釈行として導入する、
請求項３６に記載の装置。
【請求項３８】少なくとも１つのフィルタ変数と少なくとも１つの文脈変
数によりパラメータ化された目的ソース・コードとを表す生成命令を含む１セッ
トの生成命令セットを使用して生成されたコンポーネント・ベース型言語のコン
ピュータ・ソース・コードを修正するための装置であって、各々の前記少なくと
も１つのフィルタ変数は生成の動的文脈を指示するために使用され、各々の前記
文脈変数は参照ノードおよび識別子を示し、前記装置が、各々の生成されたコード・セグメントに対して使用された生成命令セットを識
別して実現すべき変更を見つけるポインタ・データを検索することを含めて、前
記生成されたコンピュータ・ソース・コードを検索するためのソース・コード・
エディタと、生成命令セットの前記ポインタ・データを使用して変更の場所を見つけ出すテ
ンプレート・マネージャと、前記変更を実現するためのテンプレート・エディタと、生成命令セットの前記セット、前記フィルタ変数、および前記少なくとも１つ
の文脈変数を使用して、コンポーネント要素に対して前記ソース・コード言語で
複数のコード・セグメントを生成するソース・コード・ジェネレータとを含む装置。
【請求項３９】ジェネレータのソース・コード言語を選択するために１セ
ットのソース・コード言語データベースをさらに含む、請求項３８に記載の装置
。
【請求項４０】各々の生成されたコード・セグメントに使用された生成命
令セットを識別するポインタ・データを生成するためのポインタ・データ・ジェ
ネレータをさらに含む、請求項３８に記載の装置。
【請求項４１】前記ポインタ・データ・ジェネレータが前記ポインタ・デ
ータを、生成されたコード・セグメント全体にわたって注釈行として導入する、
請求項４０に記載の装置。