JP2005530238A - 動的モデル／コード結合を提供するシステム、方法、および媒体 - Google Patents

Abstract

ソース・コードを、そのソース・コードを表している、モデルの複数の要素に関連付けるシステム、方法、および媒体が提供される。コンピュータ・コードの部分が、１つまたは複数のモデル要素に関連付けられる。ソース・コードを修正して、１つまたは複数の修正されたモデル要素に対応させる。修正されたソース・コードの少なくとも一部分を、オプショナルで、表示することができる。

Description

本発明の実施形態は、主に、ソフトウェア・エンジニアリングに関し、より詳細には、ソフトウェア・コードをソフトウェア・コードのモデル・ビューに同期（または、実質的に同期）させる、かつ／または、ソフトウェア・コードのモデル・ビューをソフトウェア・コードに同期（または、実質的に同期）させるためのシステム、方法、および媒体に関する。

本出願は、参照により本明細書に組み込まれる米国特許仮出願第６０／３８７５８１号明細書（２００２年６月１２日出願）を基礎とする優先権を主張する。

知られている従来のソフトウェア開発ツールは、一般に、コードに注釈（たとえば、コメント）を埋め込み、その注釈をモデルのリポジトリの一部としてコードに関連付けることによって、モデル／コード結合を達成する。本方法は、主に、モデルとコードとの整合をとるものであるが、クラス間のＵＭＬ（商標）（統一モデリング言語）関係に対するアクセッサおよび／またはミューテータを生成するなどといった、複雑な実装スキームを使用する能力はない。ＵＭＬ（商標）は、Ｏｂｊｅｃｔ Ｍａｎａｇｅｍｅｎｔ Ｇｒｏｕｐ（商標）（在マサチューセッツ州ニードハム（Ｎｅｅｄｈａｍ、ＭＡ））で開発された仕様である。

周知のとおり、ＵＭＬ（商標）では、システムの構造（コンストラクト）やシステム間の関係を表現する複数のビューを提供することを目的として、様々なグラフィカル要素を使用してこれらを図にまとめる。この複数のビューがモデルを構成し、それによって、想定されるシステムの動作が記述される。このモデルは、システムを実装する方法を示すものではない。

ＵＭＬ（商標）モデルには、９つの図を含めることができる。即ち、クラス図、オブジェクト図、ユースケース図、状態図、シーケンス図、アクティビティ図、コラボレーション図、コンポーネント図、および配置図である。どのＵＭＬ（商標）モデルでも必ずしもすべての図が必要というわけではない。また、これら９つの基本的な図から別のＵＭＬ（商標）図を派生させることもできる（たとえば、２つ以上の図やこれらの一部を組み合わせて別の図を作成することができる）。

従来のシステムでは複雑な実装スキームを使用できない理由の１つは、コードの単一ブロックで、全タイプのＵＭＬ（商標）モデル要素（たとえば、状態マシン）を実装したり、たとえば、クラス間のＵＭＬ（商標）関係に対するアクセッサおよび／またはミューテータを生成したりできないという点にある。ツールの中には、たとえば、クラス上のマクロを呼び出して属性にｇｅｔｔｅｒ（ゲッタ）およびｓｅｔｔｅｒ（セッタ）を追加することにより、モデルを単純な構造（コンストラクト）（たとえば、属性、操作）で埋めるプロセスを自動化して、特定の制限を緩和することができるものもある。

しかしながら、本願発明者らは、これらの回避手法では別の制限や不備が生じることを確認した。特に、これらの手法では、追加コンストラクト（構造）のコンテキスト（文脈）が、全体としては、あるいは適切には維持されない。たとえば、属性名を変更したときにｇｅｔｔｅｒとｓｅｔｔｅｒのシグネチャ（署名）が更新されない可能性があり、結果として、コードとそれに関連付けられたモデルとの間の結合性、および／またはモデルとそれに関連付けられたコードとの間の結合性が低下することになる。

図１は、参照により本明細書に組み込まれる米国特許出願公開公報第２００２／０１０８１０１号で開示された従来技術のソフトウェア開発ツールの概要を示す図である。図１に示すように、ソース・コード１０２は、グラフィカル形式１０４とテキスト形式１０６との両方の形式で表示されている。このソフトウェア開発ツールは、ソース・コード１０２の言語中立表現を記憶するトランジェント・メタモデル（ＴＭＭ）１００を生成する。ソース・コード１０２のグラフィカル表現１０４およびテキスト表現１０６は、ＴＭＭ１００における言語中立表現から生成される。あるいは、ソース・コードのテキスト・ビュー１０６を、ソース・コード・ファイルから直接取得することも可能である。表示１０４および１０６上で行われる修正は、表示１０４および１０６を修正するように見えるが、実際には、すべての修正が、インクリメンタル・コード・エディタ（ＩＣＥ）１０８を介して、ソース・コード１０２に対して直接行われ、ＴＭＭ１００は、ソース・コード１０２に対する修正から、グラフィカル・ビュー１０４およびテキスト・ビュー１０６の両方での修正を生成するために使用される。

このソフトウェア開発ツールは、同時ラウンドトリップ（往復）・エンジニアリングを実現する。つまり、グラフィカル表現１０４はテキスト表現１０６と同期する。したがって、グラフィカル表現１０４を介してソース・コード１０２を変更すると、テキスト表現１０６が自動的に更新される。同様に、テキスト表現１０６を介してソース・コード１０２を変更すると、グラフィカル表現２０４が更新され、同期が維持される。

ただし、米国特許出願公開公報第２００２／０１０８１０１号は、本願明細書で説明するコードおよびモデルの更新手続きを教示も提案もしていない。本願明細書では、たとえば、モード・ベース・アプローチを用いてモデル／コード結合を達成するコードおよびモデルの更新手続きを説明している。さらに、コードをリポジトリ（格納部、貯蔵庫）の一部として組み込み、たとえば、従来行われているようにコード内における注釈を使用して設計コンテキスト（文脈）を提供することによってモデル／コード結合を達成する代わりに、本発明の１つまたは複数の実施形態は、コード変更および／またはモデル変更の検出および管理を用いることによってモデル／コード結合を達成するシステム、方法、および媒体を提供する。

本発明の１つまたは複数の実施形態によれば、動的モデル／コード結合は、たとえば、ラプソディ（Ｒｈａｐｓｏｄｙ）のＵＭＬ（商標）（統一モデリング言語）モデルとそれらの実装コードとを自動的に同期させるメカニズムを提供する。これにより、最新の実装コードを即座に表示でき、また、コードを手動で変更した場合にモデルがただちに更新されるようにすることができる。

本発明の少なくとも１つの実施形態では、標準的なブラウザと画面表示を使用できる。たとえば、画面の右側にＵＭＬ（商標）シーケンス図を表示し、画面の左上にアクティブ・コード・ビューを表示することができる。本願明細書において用いられているように、アクティブ・コード・ビューは、選択されたモデル要素に対応するコードを表示するために用い得る表示領域である。たとえば、ユーザがメソッド（たとえば、ｓｅｔｕｐ（））を選択すると、アクティブ・コード・ビューでは、（更新が必要な場合）メソッドｓｅｔｕｐ（）の実装が自動的に更新され、当該メソッドの実行が表示される。逆に、ユーザがシーケンス図内のメソッドｓｅｔｕｐ（）の名前を、たとえばｍｙＳｅｔｕｐ（）に変更すると、シーケンス図では（そのモデルの他の部分とともに）当該変更が自動的に反映される。

動的モデル／コード結合は、Ｒｈａｐｓｏｄｙ（登録商標）（商標権者：マサチューセッツ州アンドーヴァ所在のアイ−ロジックス社（Ｉ−Ｌｏｇｉｘ Ｉｎｃ．， Ａｎｄｏｖｅｒ， ＭＡ））のモデル・ベース・アプローチの実施可能な機能の１つである。「Ｒｈａｐｓｏｄｙ（登録商標）ユーザ・ガイド、リリース４．２」（２００３年）の第１５章（１５−１〜１５−５３ページ）を、付属書類Ａとして本願明細書に添付した。このアプローチでは、モデルは、ツールが、一連の作業成果物（実装ソース・コード、各種ドキュメント、テスト・スクリプト、ＵＩフロント・エンドなど）を生成し、タイミング解析やテスト・ドライブなど、様々な目的のために外部ツールと対話するもとになる、システムの完結した（または、実質的に完結した）仕様を構成する。さらに、モデル・ベース・ツールは、ステートチャート図やアクティビティ図などの振る舞い図を含む、可及的多数をＵＭＬ（商標）仕様から実装することをねらいとした綿密な実装スキームによって特徴付けられる。これにより、ＵＭＬ（商標）仕様とその実装の間の不整合性が最小化（または除去）されるとともに、生産性および製品品質が大幅に向上する。

エンド・ユーザがプログラミング言語とそれをサポートする技術プラットフォームの優位性を最大限に享受できるようにするには、モデルとコードとの間の高い（または十分な）レベルの相乗効果が必要である。これを実現するために、実装言語がモデリング言語を補強する。つまり、モデルは、コード・フラグメントをモデルの仕様の一部として含む。さらに、ユーザは、生成されたコードを高いレベルで制御して、その製造品質要件を満たすようにしなければならない。この相乗効果的アプローチの別の主要成功因子は、生成されたコードに対してユーザが直接実行した変更をラウンドトリップ（往復）させて、その変更がモデルの不可欠な部分になるようにすることができることである。このため、手動で実行したコード変更が、コードの再生成によって失われることがないことが保証される。ＤＭＣＡにより、ユーザは、標準的なコード生成機能およびラウンドトリップ機能を利用してシステムの実装を即座に表示し直接に制御することができるようになるので、動的モデル／コード結合は、前述のアプローチの優位性を押し進める重要な要素の１つである。

現在あるツールは、コードに注釈を埋め込み、その注釈をモデルのリポジトリの一部としてコードに関連付けることによってモデル／コード結合を達成する。この方法では、モデルとコードとの間の整合性は確保されるが、複雑な実装スキームを使用することができない。こうした制限がある理由は、本願発明者らが確認したところによれば、コードの単一ブロックで、全タイプのＵＭＬ（商標）モデル要素（たとえば、状態マシン）や、クラス間のＵＭＬ（商標）関係生成アクセッサ及びミューテータを実装できないという事実である。それらのツールの中には、たとえば、クラスのマクロを呼び出して属性にｇｅｔｔｅｒおよびｓｅｔｔｅｒを追加することにより、モデルを単純なコンストラクト（たとえば、属性、操作など）で埋めるプロセスを自動化して、これらの制限を回避するものもある。しかし、本願発明者らが確認したところ、そのような回避策では、通常、追加コンストラクトのコンテキスト（文脈）が維持されない（たとえば、属性名を変更しても、そのｇｅｔｔｅｒおよびｓｅｔｔｅｒのシグネチャは変わらない）ため、別の制限が生じることになる。

これから説明するように、本発明の少なくとも１つの実施形態における本願発明者らの動的モデル／コード結合のアプローチは、モデルまたはコードにおける変更を検出して、必要な更新を自動的に（または、実質的に自動的に）行うという、これまでと異なる切り口をとることによって、現行技術の限界を克服するものである。これにより、モデルとその実装を切り離したままで両者間の高レベルの相乗効果を確保して、本願発明者らのモデル・ベース・アプローチを維持および拡張（強化）することができる。代替的実施態様では、このモデルは、更新を要する変更のタイプに関係なく、所定のアクティビティおよび／または時間間隔に基づいて自動的に更新される。

本願明細書で説明するように、本発明の少なくとも１つの実施形態による動的モデル／コード結合では、関連するモデル要素を変更すると表示されているコードが更新され、逆に、コードを変更すると、モデルがＤＭＣＡによって更新される。

本発明の少なくとも１つの実施形態による動的モデル／コード結合を実装できる高レベルのアーキテクチャは、モデルのリポジトリ内または生成されたファイル内の関連する変更を検出する役割を担い、必要な更新に適したツールを呼び出すことのできるＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）を含むことができる。利用できるツールは３つある。モデル要素の実装コードを生成するコード・ジェネレータ、コードに従ってリポジトリを更新できるラウンドトリップ（ＲｏｕｎｄＴｒｉｐ）要素、およびコード内に存在する特定モデル要素の実装場所を見つけて、アクティブ・コード・ビューが関連のコード・フラグメントを表示するようにできる要素位置ファインダである。

本発明の一実施形態では、コードに対して、関連する２つのビューが存在しうる。コード・ビューとアクティブ・コード・ビューである。いずれのビューでもテキスト・ファイルの編集が可能であり、いずれのビューからも、ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）に通知を送信して、コードとモデルが同期しているかどうかをチェックさせることができる（後述）。アクティブ・コード・ビューは、コード・ビューを特化したものである。コード・ビューでは、ユーザが、クラスのコードおよび／または選択したパッケージのコードを編集できる。したがって、コード・ビューを使用すると、ユーザは、たとえば、１つまたは複数のクラスを選択して、そのコード・ファイル（単数もしくは複数）をテキスト・エディタで編集することができる。アクティブ・コード・ビューには、現在選択しているモデル要素の実装が反映される。たとえば、ＵＭＬ（商標）ビューの１つ（図示せず）に含まれる一要素をユーザが選択すると、その実装がただちにアクティブ・コード・ビュー・ウィンドウに表示される。１つのファイルに複数の要素の実装を含めることができるので、要素位置ファインダがアクティブ・コード・ビューに指示して、選択された要素の実装が視認されるようにコード内の当該行までスクロールさせることができる。また、追加的な（より多くの）ビューを使用したり、より少ないビューを使用したり、及び／または、それらを結合したりできる。たとえば、任意選択で、コード・ビューとアクティブ・コード・ビューを結合して、新たなビューまたは代替実施形態にすることができる。

一般に、リポジトリはモデル要素からなる。モデル要素の１つのタイプは、標準的なラプソディ（Ｒｈａｐｓｏｄｙ）コンポーネント（（マサチューセッツ州アンドーヴァ所在のアイ−ロジックス社（Ｉ−Ｌｏｇｉｘ Ｉｎｃ．， Ａｎｄｏｖｅｒ， ＭＡ）））である。これは、モデル要素とその実装ファイルとの間のマッピング、生成されたバイナリ・ファイルのタイプ（実行可能、静的ライブラリ、ＤＬＬなど）、メイクファイル情報などの実装情報を保持できる。好ましい実施形態では、１つのモデリング・セッションの全体を通して、コード・ジェネレータ、ラウンドトリップ・ツール、ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）、およびオプショナルで他のラプソディ（Ｒｈａｐｓｏｄｙ）ツールの現在の実装コンテキスト（文脈）を示す「アクティブ」なコンポーネントが厳密に１つ存在する。１つまたは複数の代替的実施形態では、アクティブ・コンポーネントの数を複数にすることができる。

動的モデル／コード結合は、コード生成を不必要に実行しないことが好ましい。これは、モデル要素の再生成が必要かどうかを調べるのに用い得るＩＭＣＡ（インクリメンタル・モデル／コード結合）サブシステムを使用して達成できる。ここでは完璧を期すためにＩＭＣＡについて言及したが、モデル要素の変更を検出することは他の代替メカニズムを用いることで可能になるため、ＩＭＣＡの構造および機能について言及することは、ＤＭＣＡに関しては無関係である。

ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）は、以下のアルゴリズムを用いて、モデル要素の変更の結果として生成されたファイルを更新できる。
１．ファイルの生成が必要かもしれないという通知を、ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）が取得する。この通知は、
１．１．コード・ビューがフォーカスを取得したか、コード・ビューが開いた場合は、コード・ビューが実行する。

１．２．モデル要素の新しい選択がアクティブ・コード・ビューによって遮られた場合は、アクティブ・コード・ビューが実行する。次にＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）に通知する。
２．ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）が、ファイル内の実装されているすべての要素をアクティブ・コンポーネントに照会する。このコンポーネントは、実装ファイルとモデル要素との間のマッピングを保持している。
３．ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）がＩＭＣＡを使用して、ファイル内の実装されている要素の中に修正されたものがないかどうかを調べる。
４．修正された要素がある場合は、ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）がコード・ジェネレータに指示して、そのファイルを再生成させる。
５．ファイルが再生成されたら、ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）がコード・ビューに、コード・ビューを更新するよう通知する。アクティブ・コード・ビューの場合は、アクティブ・コード・ビューが、コード内の要素の行番号を位置ファインダに照会して、当該行までスクロールする（ＣおよびＣ＋＋では、アクティブ・コードはヘッダ・ファイルおよび．ｃ＼．ｃｐｐファイルを表示するので、複数の行が呼び出される場合がある）。

ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）は、以下のアルゴリズムにより、コードの変更をモデルにラウンドトリップできる。
１．コード・ビューがフォーカスを失ったか、ユーザが修正後にその内容を保存した場合は、ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）がコード・ビューから通知を受け取る場合がある。コード・ビューがフォーカスを失い、そのビューの内容が修正された場合、コード・ビューはそのファイルを保存し、ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）に通知する。
２．そのファイルの内容が変更された場合は、そのファイルに対してリポジトリ更新（ＲｏｕｎｄＴｒｉｐ）を実行し、関連する要素を更新する。
３．コード生成マッピングは複雑な場合があるので（たとえば、ｇｅｔｔｅｒおよびｓｅｔｔｅｒを含む属性）、ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）は、コードがコード生成規則に適合するように、修正された要素に対してコード生成を実行する（本願発明者らの例では、属性を実装しているデータ・メンバの名前を変更すると、ｇｅｔｔｅｒおよびｓｅｔｔｅｒの名前も同様に変更される）。

さらに、本発明の代替的実施形態は、以下のうちの１つまたは複数を含む。

ａ．ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）が、オプショナルで、ファイルの生成が必要かもしれないという通知を、コード・ビューまたはアクティブ・コード・ビュー以外のモジュールから取得できる。

ｂ．オプショナルで、ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）が任意のタイプのメカニズムを用いてモデル要素の再生成が必要かどうかを決定できるようにしたり、或いはオプショナルで常にファイルを再生成するようにしたりできる。

ｃ．ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）が、オプショナルで、ファイル内の実装されているすべて（または、実質的にすべて）の要素の保存場所へのポインタまたは参照をアクティブ・コンポーネントに照会できる。

ｄ．アクティブ・コンポーネントが、オプショナルで、実装ファイルとモデル要素との間のマッピングの保存場所へのインデックスまたは参照を保存する。

ｅ．ビューがフォーカスを失い、ビューの内容が修正された場合でも、ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）がオプショナルでそのファイルを保存できる。

ｆ．ファイルの内容が変更されたかどうかを判断する代わりに、ファイル用のリポジトリ更新がオプショナルで自動的に呼び出され、さらに（もしあった場合には）関連要素を更新する。

ｇ．コードがコード生成規則に適合するように、ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）が、オプショナルで、（主として修正された要素を更新するために）すべて（または、実質的にすべて）の要素のコード生成を実行する。

上記に代わる他の実施形態は、本発明の範囲内であると見なされる。たとえば、ＤＣＭＡの全体的な機能を本願明細書で説明するように実行する限り、前述した具体的なシーケンスは適宜修正可能である。

さらに、本発明の１つまたは複数の実施形態の使用例を以下に示す。

１．ユーザが、クラスに属性を追加し、クラスのコード・ビューにフォーカスを置く：
ａ．ユーザが、モデル内でクラスを選択し、そのクラスに属性を追加する。

ｂ．ユーザが、コード・ビューにフォーカスを置いて、このクラスのコードを表示する。

ｃ．コード・ビューのコード・エディタが、コード・ビューが選択されたことをＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）に通知する。

ｄ．そのクラスに対してコードが生成された後にそのクラスのモデル要素が変更されたためにファイルの再生成が必要であると、ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）が判断する。

ｅ．ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）がコード・ジェネレータを起動し、ファイルの再生成を指示する。

ｆ．ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）が、コード・ビューにファイルをリロードさせる更新メッセージをコード・ビューに送る。
２．ユーザが、クラスの名前を変更し、変更したクラスと関係があるクラスのビューにフォーカスを置く：
ａ．ユーザが、モデル内のクラスを選択し、その名前を変更する。

ｂ．ユーザが、コード・ビューにフォーカスを置いて、依存クラスのコードを表示する。

ｃ．コード・ビューのコード・エディタが、コード・ビューが選択されたことをＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）に通知する。

ｄ．直接の関連がある要素に大きな変更が発生したためにそのファイルの再生成が必要であることを、ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）が認識する。

ｅ．ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）がコード・ジェネレータを起動し、ファイルの再生成を指示する。

ｆ．ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）が更新メッセージをコード・ビューに送る。コード・ビューは、返報として、ファイルをリロードする。

３．アクティブ・コード・ビューが表示されている間にユーザがモデル要素を選択する：
a.ユーザがモデル要素を選択する。

ｂ．アクティブ・コード・ビューが、選択されたことを通知される。

ｃ．アクティブ・コード・ビューがファイルをロードする（ファイルは既に存在すると仮定）。

ｄ．アクティブ・コード・ビューがＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）に、ファイルの再生成が必要であることを通知する。

ｅ．ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）が、ファイルの再生成が必要かどうかを調べ、それに基づいて処理を行う。

４．ユーザがクラスのコード・ビューを開く：
ａ．ユーザがクラスを選択し、「Ｅｄｉｔ Ｃｌａｓｓ（クラスを編集）」を選択する。

ｂ．そのファイルが存在しない場合は、生成する。ファイルが存在する場合は、コード・ビューがＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）に、そのファイルが開いていることを通知する。

ｃ．ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）が、そのファイルの再生成が必要であることを認識し、適切なコード生成を指示する。必要であれば、ビューに対し、ファイルをリロードさせる。

５．ユーザが、たとえば、コード内のクラスの名前、またはそのコードのネストされたクラスの名前を変更し、コード・ビューから離れる：
ａ．コード・ビューが、そのファイルを保存し、そのファイルを保存したことをＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）に通知する。

ｂ．ＤＭＣＡマネージャ（Ｍａｎａｇｅｒ）がラウンドトリップ（ＲｏｕｎｄＴｒｉｐ）を起動してファイルをラウンドトリップする。

ｃ．ラウンドトリップ（ＲｏｕｎｄＴｒｉｐ）が、そのクラスの名前がモデルで指定されている名前と異なることを検出し、モデル内のクラスの名前を変更する。

ｄ．ユーザがクラスの名前を手動で変更したかのように、リポジトリが依存要素を更新する。

ｅ．コード・ジェネレータが起動され、コードをモデルと再同期させる。たとえば、コンストラクタとデストラクタの名前が正しく変更される。

このように、本発明は、少なくとも１つの実施形態において、有利なことに、ソフトウェア・モデルをそのコード実装と切り離したまま、両者間の結合を維持する。本発明の少なくとも１つの実施形態による、動的モデル／コード結合（ＤＭＣＡ）のシステム、メソッド、および媒体により、モデルは、コード・ジェネレータが、たとえば、実装ソース・コード、各種ドキュメント、テスト・スクリプト、ユーザ・インターフェース・フロント・エンドなどを生成し、かつ／または、タイミング解析および／またはテスト・ドライブなどの様々な目的のために外部ツールと対話するもとになる、システムの完結した（または、実質的に完結した）仕様を構成する。さらに、本発明の少なくとも１つの実施形態は、ＵＭＬ（商標）（統一モデリング言語）を利用して、ＵＭＬ（商標）モデルとコードとの間の高い（または十分な）レベルの相乗効果をもたらすことができる。さらに、実装言語（たとえば、Ｃ＋＋、Ｊａｖａ）がモデリング言語を補強することができる。たとえば、一実施形態では、モデルは、コード・フラグメントをモデルの仕様の一部として含むことができる。

本発明の一実施形態は、有利なことに、ユーザが、生成されたコードを高いレベルで制御して、たとえば、製造品質要件を満たすことを可能にする。たとえば、本発明の少なくとも１つの実施形態はさらに、生成されたコードに対して直接行われた変更をモデルにラウンドトリップして、コードに対するそれらの変更がモデルの不可欠な部分になるようにできる。これにより、有利なことに、たとえば、コードの再生成に応答してモデルが必ず更新される。したがって、本発明の１つまたは複数の実施形態により、ユーザは、標準的なコード生成機能およびラウンドトリップ機能を利用して、システムの実装を素早く表示したり、直接制御および／または編集したりできる。

したがって、本発明の１つまたは複数の実施形態を利用して、ソフトウェア・モデルおよび／またはソフトウェア・コードにおける変更（または、ソフトウェア・モデルおよび／またはソフトウェア・コードに対する変更）を検出し、そのモデルおよび／またはコードを自動的に（または、実質的に自動的に）更新することができる。代替的実施態様では、このソフトウェア・モデルを、たとえば、所定のアクティビティおよび／または時間間隔に基づいて自動的に更新することが可能であり、オプショナルでは、これを、更新を要する変更のタイプに任意選択で依存せずに行うことも可能である。

したがって、本発明の少なくとも１つの実施形態は、たとえば、モード・ベース・アプローチを用いてモデル／コード結合を達成し、コードの変更および／またはモデルの変更を検出および管理することによりモデル／コード結合を達成するシステム、方法、および媒体を提供する。

本発明はさらに、有利なことに、複雑なコード生成スキームおよびラウンドトリップ・スキームのモデル／コード結合を可能にする。したがって、本発明は、ユーザが、実装コードに対する十分なレベルの可視性ならびに制御性と併せ、（たとえば、ＵＭＬ（商標）を利用して）モデル・ベース開発の強みを有利に利用することを可能にすることができる。

本発明の一実施形態によれば、コンピュータに実装され、ソース・コードを、そのソース・コードを表しているモデルの複数の要素に関連付ける方法が提供される。この方法は、ソフトウェア・ソース・コードとして実装できる、モデルの複数の要素を生成するステップと、当該モデルの複数の要素に対応するソフトウェア・ソース・コードを生成するステップと、当該ソフトウェア・ソース・コードの部分を該モデルの複数の要素の少なくとも１つに関連付けるステップと、当該複数の要素の少なくとも１つが修正されていることを確認するステップと、ソフトウェア・ソース・コードを修正して、修正されている当該複数の要素の少なくとも１つまたは複数に対応させるステップとを含むことができる。

この方法はさらに、オプショナルで、ソフトウェア・ソース・コードの、修正されている少なくとも一部分を表示するステップを含むことができる。モデル要素の少なくとも一部分をブラウザの第１の表示領域に表示でき、当該修正されたソフトウェア・ソース・コードの少なくとも一部分をブラウザの第２の表示領域に表示できる。第１および第２の表示領域としては、オプショナルで、通常のブラウザ・フレームをあててもよい。

さらに、ソース・コードの特定の行番号を、そのモデル要素（ＵＭＬ（商標）（統一モデリング言語））モデル要素など）に関連付けることができる。ＵＭＬ（商標）要素として、クラス図、オブジェクト図、ユースケース図、状態図、シーケンス図、アクティビティ図、コラボレーション図、コンポーネント図、および／または配置図のうちの少なくとも１つを用いることができる。

本発明の一実施形態による別の方法は、ソース・コードを、そのソース・コードを表している、モデルの複数の要素に関連付けることができる。この方法は、ソフトウェア・ソース・コードとして実装できる、モデルの複数の要素を生成するステップと、当該モデルの複数の要素に対応するソフトウェア・ソース・コードを生成するステップと、当該ソフトウェア・ソース・コードの部分を、モデルの複数の要素の少なくとも１つに関連付けるステップと、ソフトウェア・ソース・コードの少なくとも一部分が修正されていることを確認するステップと、複数のモデル要素の少なくとも１つを修正して、当該修正されているソフトウェア・ソース・コードに対応させるステップと、ソフトウェア・ソース・コードが、当該修正されたモデルと合致するように、所定の規則に従ってソフトウェア・ソース・コードを再生成するステップとを含むことができる。

この方法はさらに、修正されているソフトウェア・ソース・コードの少なくとも一部分を表示するステップ、および／または、修正されているモデルの複数の要素の少なくとも１つを表示するステップを含むことができる。

複数のモデル要素の少なくとも１つをブラウザの第１の表示領域に表示でき、当該修正されたソフトウェア・ソース・コードの少なくとも一部分をブラウザの第２の表示領域に表示できる。第１および第２の表示領域として、通常のウェブ（Ｗｅｂ）ブラウザ・フレームを用いることができる。

さらに、ソフトウェア・ソース・コードの特定の行番号を、複数のモデル要素の少なくとも１つに関連付けることができる。モデル要素として、クラス図、オブジェクト図、ユースケース図、状態図、シーケンス図、アクティビティ図、コラボレーション図、コンポーネント図、および／または配置図を含むＵＭＬ（商標）（統一モデリング言語）モデル要素を用いることができる。

コンピュータ可読媒体に存在する、本発明による一コンピュータ・プログラム製品は、ソフトウェア・ソース・コードとして実装できる、モデルの複数の要素を生成することと、当該モデルの複数の要素に対応するソフトウェア・ソース・コードを生成することと、当該ソフトウェア・ソース・コードの部分を、モデルの複数の要素の少なくとも１つに関連付けることと、モデルの複数の要素の少なくとも１つが修正されていることを確認することと、当該ソース・コードを修正して、当該１つまたは複数の修正されたモデル要素に対応させることとを、コンピュータに実行させる命令を含むことができる。この媒体はさらに、ソース・コードの、当該修正されている少なくとも一部分をコンピュータに表示させる命令を含むことができる。

コンピュータ可読媒体に存在する、本発明による別のコンピュータ・プログラム製品は、ソフトウェア・ソース・コードとして実装できる、モデルの複数の要素を生成することと、当該モデルの複数の要素に対応するソフトウェア・ソース・コードを生成することと、当該ソフトウェア・ソース・コードの部分を、モデルの複数の要素の少なくとも１つに関連付けることと、当該ソフトウェア・ソース・コードの少なくとも一部分が修正されていることを確認することと、複数のモデル要素の少なくとも１つを修正して、該修正されているソース・コードに対応させることと、ソフトウェア・ソース・コードが、修正されたモデルと合致するように、所定の規則に従ってソフトウェア・ソース・コードを再生成することとを、コンピュータに実行させる命令を含むことができる。さらに、このコンピュータ・プログラム製品は、ソフトウェア・ソース・コードの、当該修正されている少なくとも一部分をコンピュータに表示させる命令を含むこともできる。

本発明によるソフトウェア・プロジェクトにおいて、ソース・コードのドキュメントを生成するデータ処理システムは、ソフトウェア・ソース・コードとして実装できる、モデルの複数の要素を生成する手段と、当該モデルの複数の要素に対応するソフトウェア・ソース・コードを生成する手段と、当該ソフトウェア・ソース・コードの部分を、モデルの複数の要素の少なくとも１つに関連付ける手段と、モデルの複数の要素の少なくとも１つが修正されていることを確認する手段と、ソフトウェア・ソース・コードを修正して、１つまたは複数の当該修正されたモデル要素に対応させる手段とを含むことができる。さらに、このデータ処理システムは、ソフトウェア・ソース・コードの当該修正されている少なくとも一部分を表示する手段を含むこともできる。

本発明の少なくとも１つの実施形態に係る、コンピュータに実装される方法であって、ソース・コードを、そのソース・コードを表しているモデルの複数の要素に関連付ける方法は、ソフトウェア・ソース・コードとして実装できる、モデルの複数の要素を生成するステップと、当該モデルの複数の要素に対応するソフトウェア・ソース・コードを生成するステップと、当該ソフトウェア・ソース・コードの部分を、当該モデルの複数の要素の少なくとも１つに関連付けるステップと、当該ソフトウェア・ソース・コードの少なくとも一部分が修正されていることを確認するステップと、複数のモデル要素の少なくとも１つを修正して、当該修正されているソフトウェア・ソース・コードに対応させるステップと、当該ソース・コードが、当該修正されたモデルと合致するように、所定の規則に従ってソフトウェア・ソース・コードを再生成するステップとを含むことができる。コンピュータに実装される当該方法はさらに、ソース・コードの当該修正されている少なくとも一部分を表示するステップを含むことができる。

以上のとおりなので、いわゆる当業者であれば、本発明の様々な目的を実行する他の構造、方法、およびシステムを設計するためのベースとして、本開示の基盤をなす概念を容易に利用できることが理解されよう。したがって、そのような等価な構築物は、本発明の趣旨（精神）および範囲から逸脱しない限り、本特許請求項に含まれると見なすことが重要である。

また、添付の要約書は、米国特許商標庁、ならびに広くは公衆、特に特許や法律の用語または言い回しに不慣れな当該分野の科学者、技術者、および実務家が、本出願の技術的開示の性質及び本質を一目でわかるようにすることを目的としている。この要約書は、本出願の発明を規定することを意図したものではなく（本発明は特許請求項で規定される）、いかなる形でも本発明の範囲に関する限定を意図したものでもない。

本発明を特徴付ける種々の新規な機能は、本開示に添付され、本開示の一部をなす特許請求項によって具体的に示される。本発明、本発明の運用上の優位性、ならびにその使用によって達成される具体的な目標についてよりよく理解するために、本発明の好ましい実施形態を例示した添付図面および記載事項を参照されたい。

表記と用語
以下では、たとえばスタンドアロン・コンピューティング・マシン、コンピュータ、またはコンピュータ・ネットワークなどのコンピューティング・システムや処理システムで実行されるプログラム手順の点で詳細を説明する場合がある。そうした手順上の説明および表現は、いわゆる当業者が成果の内容を他の当業者に最も効率的に伝えるために用いる手段である。

手続きは、ここでは、および一般に、所望の結果につながる一連のステップであると考えられる。それらのステップは、物理量の物理的操作（たとえば、何種類かの医薬品をパッケージにまとめる操作）を必要とする場合がある。常にそうとは限らないが、通常、それらの量は、記憶、転送、結合、比較、その他の操作が可能な電気信号、光信号、または磁気信号の形をとる。主として一般的な使い方であることから、これらの信号をビット、値、要素、記号、文字、用語、番号、その他で表すことが便利である場合がある。ただし、これらの用語および同様の用語はすべて、しかるべき物理量に関連付けられるべきものであると共に、それらの量に適用される便利なラベルに過ぎないことに注意されたい。

さらに、実行される操作を、追加や比較など、人間の操作者が実行する知的操作に共通に関連付けられる用語で表す場合が多い。本発明の一部をなす、本願明細書で説明するいかなる操作においても、そのような人間の操作者の能力は不要である（あるいは、ほとんどの場合は望ましくない）。つまり、それらの操作は機械操作である。本発明の操作を実行するマシンとして有効なものには、マイクロプロセッサを内蔵するが、それに限定されない汎用デジタル・コンピュータや同様の装置が含まれる。

種々の特徴を示す本出願の詳細説明については、添付図面を関連させて読むことにより、最大限に理解できよう。

本発明の１つまたは複数の実施形態によれば、動的モデル／コード結合は、たとえば、ラプソディ（Ｒｈａｐｓｏｄｙ）のＵＭＬ（商標）（統一モデリング言語）モデルとそれらの実装コードとを自動的に同期するメカニズムを提供する。これにより、最新の実装コードを即座に表示でき、また、コードを手動で変更した場合にモデルがただちに更新されるようにできる。

このアプローチでは、モデルは、ツールが、一連の作業成果物（実装ソース・コード、各種ドキュメント、テスト・スクリプト、ＵＩフロント・エンドなど）を生成し、タイミング解析やテスト・ドライブなど、様々な目的のために外部ツールと対話するもとになる、システムの完結した（または、ほぼ完結した）仕様を構成する。さらに、モデル・ベース・ツールは、ステートチャート図やアクティビティ図などの振る舞い図を含む、できるだけ多くをＵＭＬ（商標）仕様から実装することをねらいとした綿密な実装スキームによって特徴付けられる。これにより、ＵＭＬ（商標）仕様とその実装の間の不整合性が最小化（または除去）されるとともに、生産性および製品品質が大幅に向上する。

エンド・ユーザがプログラミング言語とそれをサポートする技術プラットフォームの優位性を最大限に享受できるようにするには、モデルとコードの高い（または十分な）レベルの相乗効果が必要である。これを実現するために、実装言語がモデリング言語を補強する。つまり、モデルは、コード・フラグメントをモデルの仕様の一部として含む。さらに、ユーザは、生成されたコードを高いレベルで制御して、その製造品質要件を満たすようにしなければならない。この相乗効果的アプローチの別の主要成功因子は、生成されたコードに対してユーザが直接実行した変更を、その変更がモデルの不可欠な部分になるように
ラウンドトリップできることである。このため、手動で実行したコード変更が、コードの再生成によって失われることがない。ＤＭＣＡにより、ユーザは、標準的なコード生成機能およびラウンドトリップ機能を利用してシステムの実装を即座に表示し、直接制御することができるので、動的モデル／コード結合は、前述のアプローチの優位性を押し進める重要な要素の１つである。

本発明の少なくとも１つの実施形態における本願発明者らの動的モデル／コード結合のアプローチは、モデルまたはコードにおける変更を検出して、必要な更新を自動的に（または、ほぼ自動的に）行うという、これまでと異なる切り口をとることによって、現行技術の制限を克服するものである。これにより、モデルとその実装を切り離したままで両者間の高レベルの相乗効果を確保して、本願発明者らのモデル・ベース・アプローチを維持および拡張することができる。代替実施態様では、このモデルは、更新を要する変更のタイプに関係なく、所定のアクティビティおよび／または時間間隔に基づいて自動的に更新される。

本発明の少なくとも１つの実施形態による動的モデル／コード結合では、関連するモデル要素を変更すると、表示されているコードが更新され、逆に、コードを変更すると、モデルが更新される。

ＤＭＣＡＭａｎａｇｅｒは、モデル要素の変更の結果として生成されたファイルを更新でき、コードの変更をモデルにラウンドトリップできる。

さらに、本発明の代替実施形態によれば、以下のうちの１つまたは複数が達成される。

ａ．ＤＭＣＡＭａｎａｇｅｒが、任意選択で、ファイルの生成が必要らしいという通知を、コード・ビューまたはアクティブ・コード・ビュー以外のモジュールから取得できる。

ｂ．任意選択で、ＤＭＣＡＭａｎａｇｅｒが任意のタイプのメカニズムを用いてモデル要素の再生成が必要かどうかを決定できるようにしたり、常にファイルを再生成するようにしたりできる。

ｃ．ＤＭＣＡＭａｎａｇｅｒが、任意選択で、ファイル内の実装されているすべて（または、ほぼすべて）の要素の保存場所へのポインタまたは参照をアクティブ・コンポーネントに照会できる。

ｄ．アクティブ・コンポーネントが、任意選択で、実装ファイルとモデル要素の間のマッピングの保存場所へのインデックスまたは参照を保存する。

ｅ．ビューがフォーカスを失い、ビューの内容が修正された場合でも、ＤＭＣＡＭａｎａｇｅｒが任意選択でそのファイルを保存できる。

ｆ．ファイルの内容が変更されたかどうかを判断する代わりに、ファイルおよび関連要素が更新されている場合には、それらについて任意選択でリポジトリ更新を自動的に実行する。

ｇ．コードがコード生成規則に適合するように、ＤＭＣＡＭａｎａｇｅｒが、任意選択で、（修正された要素を更新する前に）すべて（または、ほぼすべて）の要素のコード生成を実行する。

また、本発明の少なくとも１つの実施形態は、ＵＭＬ（商標）（統一モデリング言語）を利用して、ＵＭＬ（商標）モデルとコードの高い（または十分な）レベルの相乗効果をもたらすことができる。

本発明の一実施形態は、有利なことに、ユーザが、生成されたコードを高いレベルで制御して、たとえば、製造品質要件を満たすことを可能にする。たとえば、本発明の少なくとも１つの実施形態はさらに、生成されたコードに対して直接行われた変更をモデルにラウンドトリップして、コードに対するそれらの変更がモデルの不可欠な部分になるようにできる。これにより、有利なことに、たとえば、コードの再生成に応答してモデルが必ず更新される。したがって、本発明の１つまたは複数の実施形態により、ユーザは、標準的なコード生成機能およびラウンドトリップ機能を利用して、システムの実装を素早く表示したり、直接制御および／または編集したりできる。

したがって、本発明の１つまたは複数の実施形態を利用して、ソフトウェア・モデルおよび／またはソフトウェア・コードの変更を検出し、そのモデルおよび／またはコードを自動的に（または、ほぼ自動的に）更新することができる。代替実施態様では、このソフトウェア・モデルを、たとえば、更新を要する変更のタイプに任意選択で依存せず、所定のアクティビティおよび／または時間間隔に基づいて自動的に更新することが可能である。

本発明はさらに、有利なことに、複雑なコード生成スキームおよびラウンドトリップ・スキームのモデル／コード結合を可能にする。したがって、本発明は、ユーザが、実装コードに対する十分なレベルの可視性ならびに制御性と併せ、（たとえば、ＵＭＬ（商標）を利用して）モデル・ベース開発の強みを有利に利用することを可能にすることができる。

以下、本発明の、現時点で好ましい実施形態を詳細に説明する。これらの実施形態は、本発明の説明のために提示するものであり、本発明をこれらに限定することを意図したものではない。実際、いわゆる当業者が本明細書を読み、添付図面を見れば、様々な修正や変形が可能であることが理解されよう。

たとえば、一実施形態の一部として図示または説明した機能を他の実施形態に使用して、さらに別の実施形態を与えることができる。また、特定の機能を、同一または同等の働きをする未言及の同等の装置または機能と交換することが可能である。したがって、そのような修正や変形は本発明の全体に含まれるものと意図される。

本発明に係る動的モデル／コード結合のシステム、方法、および媒体は、好ましい一実施形態によれば、ソース・コードのモデルとそのソース・コード自体との同期を実現する。したがって、少なくとも１つの実施形態では、本発明で有利に提供され、もしくは促進されるところによれば、最新の実装コードおよび／または１つもしくは複数の関連付けられたモデルをほぼ瞬時に表示することができる。

図２および３は、本発明の一実施形態に係る動的モデル／コード結合を示す。２０６に示すように、ブラウザまたは他の標準的な表示手段でＵＭＬ（商標）（統一モデリング言語）シーケンス図を表示することができる。本発明はさらに、クラス図、オブジェクト図、ユースケース図、状態図、アクティビティ図、コラボレーション図、コンポーネント図、および／または配置図、および／またはこれらの変形および／または組み合わせなどのＵＭＬ（商標）図を利用および表示できることも理解されたい。ユーザは、本発明と組み合わせて使用できるユーザ・インターフェース（たとえば、ブラウザ）により、上述の任意のＵＭＬ（商標）図を作成、編集、および／または削除できる。２０８には、アクティブ・コード・ビューが表示される。本願明細書において用いられているように、アクティブ・コード・ビュー２０８は、選択されたモデル要素に対応するコードを表示するために使用することができる表示領域である。ユーザがメソッドｓｅｔｕｐ（） ２０２を選択すると、アクティブ・コード・ビュー２０８でメソッドｓｅｔｕｐ（） ２０４が（必要に応じて）自動的に更新され、メソッドｓｅｔｕｐ（） ２０４の実装が表示される。

さらに、図３に示すように、ユーザがメソッドｓｅｔｕｐ（）の名前をｍｙＳｅｔｕｐ（） ３０２に変更すると、シーケンス図（および、好ましくは、上述の、このモデルの他のすべてのビュー）が、その変更を反映するように自動的に更新される。結果として、３０４にｍｙＳｅｔｕｐ（）が表示される。

図４は、本発明の一実施形態の例示的なハイレベル・アーキテクチャを示している。モデル・コード・マネージャ４０１が、モデル・リポジトリ４０７および／またはコード・ジェネレータ４０９で、関連した変更を検出または特定する。モデル・コード・マネージャ４０１は、モデルおよび／またはファイルへの変更を特定すると、ただちに、たとえば３つのツールのうちの１つまたは複数を起動して、必要な更新を実行することができる。詳細には、モデル・コード・マネージャ４０１は、コード・ジェネレータ４０２を起動して、たとえば、モデル要素４０５に記憶されている要素および／またはモデル要素４０５に関連付けられた要素に対応する実装コードを生成することができる。モデル・コード・マネージャ４０１はさらに、オプショナルで、（主に修正された要素を更新するために）モデル要素４０５に記憶されているか関連付けられているすべての（または、実質的にすべての）要素に対してコード・ジェネレータ４０２を起動して、ファイル４１２、４１３、４１４、４１５にあるコードがコード生成規則に適合するようにできる。

モデル・コード・マネージャ４０１はさらに、オプショナルで、リポジトリ更新４０３を起動して、たとえば、リポジトリ４０７を、コードと合致するように更新することができる。モデル・コード・マネージャ４０１はさらに、オプショナルで、要素ファインダ４０４を起動して、たとえば、モデル要素４０５に記憶されているか、かつ／またはモデル要素４０５に関連付けられている特定モデル要素の実装が当該コード内のどこにあるかを突き止めることができる。モデル要素が見つかったら、アクティブ・コード・ビュー４１０を起動して、関連するコード・フラグメントを（たとえば、図２の２０８で示すように）表示することができる。

コード・ビュー４１１を使用して、個々の実装ファイル４１２を表示できる。これには、既存のソース・コード・ファイル４１３、メイクファイル４１４（たとえば、１つまたは複数の新規に作成したソース・コード・ファイル）、および／またはスクリプト・ファイル４１５などが含まれる。

アクティブ・コード・ビュー４１０でも、コード・ビュー４１１でも、テキスト・ファイル４１２の編集（たとえば、ソース・ファイル４１３、メイクファイル４１４、および／またはスクリプト・ファイル４１５の編集）およびモデル・コード・マネージャ４０１への通知を行うことができる。

コード・ビュー４１１の特定の実装をアクティブ・コード・ビュー４１０にすることができる。本発明の一実施形態では、モデル・コード・マネージャ４０１は、オプショナルで、ファイル４１２、４１３、４１４、４１５の生成が必要らしいという通知を、コード・ビュー４１１もしくはアクティブ・コード・ビュー４１０以外のモジュールから受け取ることができる。コード・ビュー４１１およびアクティブ・コード・ビュー４１２を、オプショナルで、結合して別のビューまたは代替的実施形態にすることができる。

アクティブ・コード・ビュー４１０は、現在選択されているモデル要素４０５の実装を反映する。たとえば、ユーザがいずれかのＵＭＬ（商標）ビューで要素（たとえば、図３のｍｙＳｅｔｕｐ ３０４）を選択した場合に、その実装を、たとえば、アクティブ・コード・ビュー・ウィンドウ２０８に表示することができる。１つのファイルに１つまたは複数の要素の実装を含めることができるので、要素位置ファインダ４０４からアクティブ・コード・ビュー４１０に指示を出して、たとえば、選択された要素の実装が、たとえば、アクティブ・コード・ビュー・ウィンドウ２０８に表示されるように、コード内の正規の行までスクロールさせることができる。

リポジトリ４０７の一実施形態には、モデル要素４０５を含めることができる。モデル要素４０５の１つのタイプは、標準的なラプソディ（Ｒｈａｐｓｏｄｙ）コンポーネント（（マサチューセッツ州アンドーヴァ所在のアイ−ロジックス社（Ｉ−Ｌｏｇｉｘ Ｉｎｃ．， Ａｎｄｏｖｅｒ， ＭＡ）））であることができる。これは、モデル要素４０５とその対応する実装ファイル（単数、複数）との間のマッピング、生成されたバイナリ・ファイルのタイプ（実行可能、静的ライブラリ、動的リンク・ライブラリなど）、メイクファイル４１４情報などの実装情報を保持できる。本発明の一実施形態では、１つのモデリング・セッションの全体を通して、コード・ジェネレータ４０２、リポジトリ更新４０３、モデル・コード・マネージャ４０１、およびオプショナルで他のツールの現在の実装文脈（コンテキスト）を示す「アクティブ（活性）」なコンポーネントが１つ存在する。一代替的実施形態では、アクティブ・コンポーネントの数を複数にすることができる。

一実施形態では、モデル・コード・マネージャ４０１は、ＩＭＣＡ（インクリメンタル・モデル／コード結合）４０８と通信するか、またはこれにアクセスして、モデル要素４０５に記憶されているか関連付けられている要素について、たとえば最終更新以来、この要素における変更もしくはこの要素に対する変更がないかどうかを調べることができる。モデル要素４０５に記憶されているか関連付けられている要素に変更があった場合は、モデル・コード・マネージャ４０１が、リポジトリ更新４０３を起動してファイル（単数もしくは複数）４１２を更新または作成することができる。本発明の一実施形態では、ファイル４１２、４１３、４１４、４１５の内容が変更されているかどうかを調べる代わりに、オプショナルで、リポジトリ更新４０３をファイル４１２、４１３、４１４、４１５に対して自動的に起動し、関連する（もしくは関連付けられた）要素がモデル要素４０５に記憶されているか関連付けられていれば、それらを更新する。

モデル・コード・マネージャ４０１は、オプショナルで、任意のタイプのメカニズムを用いて、モデル要素４０５に記憶されているか関連付けられている要素の再生成が必要或いは必須かどうかを調べることができ、または、オプショナルで、モデル要素４０５を常に再生成するようにできる。さらにモデル・コード・マネージャ４０１は、オプショナルで、たとえば、モデル要素４０５に実装されている、すべての要素、または実質的にすべての要素の記憶場所を示すポインタもしくは参照を、コンポーネント４０６に照会できる。さらに、コンポーネント４０６は、オプショナルで、たとえば、ファイル４１２、４１３、４１４、４１５と、モデル要素４０５に記憶されているか関連付けられている要素との間のマッピングを示すインデックス（索引）もしくは参照を記憶できる。

図５は、モデル要素４０５に記憶されているか関連付けられている１つまたは複数のモデル要素への変更に関連するコード・ファイル更新手続きの例示的なフロー図である。ステップ５０２では、モデル・コード・マネージャ４０１が、ファイル４１２、４１３、４１４、４１５の更新または生成が必要かもしれないという通知を受け取ることができる。モデル・コード・マネージャ４０１は、たとえば、コード・ビュー４１１がフォーカスを取得したとき（たとえば、ファイルを開いたとき）に、コード・ビュー４１１から通知を受け取ることができる。また、モデル・コード・マネージャ４０１は、アクティブ・コード・ビュー４１０が、たとえば、モデル要素４０５の新たな選択を検出したときに通知を受け取ることができる。

ステップ５０４では、モデル・コード・マネージャ４０１が、個々のファイル４１２、４１３、４１４、４１５に実装された要素をコンポーネント４０６に照会できる。コンポーネント４０６は、ファイル４１２、４１３、４１４、４１５と、モデル要素４０５に記憶されているか関連付けられている、関連または対応するモデル要素との間のマッピングを保持または記憶する。

判断ステップ５０６では、モデル・コード・マネージャ４０１が、ＩＭＣＡ ４０８を起動するか、これにアクセスして、ファイル４１２、４１３、４１４、４１５に実装されている要素のうち、修正されているものがあるかどうかを調べることができる。修正されている要素がない場合は、プロセスが終了する。修正されている要素がある場合は、ステップ５０８でコード・ジェネレータ４０２を使用して、ファイル４１２、４１３、４１４、４１５を再生成することができる。一実施形態では、モデル・コード・マネージャ４０１が、コード・ジェネレータ４０２にコードを生成するよう指示するか、生成させることができる。さらに、モデル・コード・マネージャ４０１は、コード・ビュー４１１が自身を更新するよう通知するか、更新させるか、更新するよう指示することができる。アクティブ・コード・ビュー４１０の場合は、アクティブ・コード・ビュー４１０が、たとえば、コード内の特定要素の行番号を要素位置ファインダ４０４に照会して、図２の２０８に示すように、当該（正規）行までスクロールすることができる。

図６は、ファイル４１２、４１３、４１４、４１５への変更に関連するモデル更新手続きの例示的なフロー図である。本発明の一実施形態では、モデル・コード・マネージャ４０１が以下の例示的アルゴリズムを用いて、モデル要素４０５によって保持または記憶されているモデル要素を更新することができる。

判断ステップ６０２では、コード・ビュー４１１がファイル４１２、４１３、４１４、４１５のフォーカスを失っていないかどうか（たとえば、ファイルが閉じていないかどうか、あるいはさもなくばファイルを編集する権限が失われていないかどうか）を調べる。フォーカスが失われている場合は、コード・ビュー４１１が判断ステップ６０６で、ファイル４１２、４１３、４１４、４１５の内容が変更されているかどうかを調べることができる。ファイルの内容が変更されている場合は、ステップ６０８でそのファイルを保存する。ステップ６１０では、モデル・コード・マネージャ４０１が、たとえば、ファイル４１２、４１３、４１４、４１５の内容が変更されているという通知をコード・ビュー４１１から受けることができる。ステップ６１２では、ステップ６０８で保存したコード内容と対応するように、モデル要素４０５を更新する。ステップ６１４では、モデル・コード・マネージャ４０１がコード・ジェネレータ４０２を起動して、コードをコード生成規則に適合させる。たとえば、Ｊａｖａ言語においては、コード・ジェネレータ４０２は、コードに対する他の変更と併せてｇｅｔｔｅｒおよびｓｅｔｔｅｒの名前を変更することができる。判断ステップ６０６で、ファイル４１２、４１３、４１４、４１５の内容が変更されていないことが判明した場合は、プロセスが終了する。

判断ステップ６０２で、コード・ビュー４１１のフォーカスが失われていないことが判明した場合は、判断ステップ６０４で、ファイル４１２、４１３、４１４、４１５が保存されているかどうかを調べる。ファイルが保存されていないことが判明した場合は、ステップ６０８でファイルを保存し、ステップ６１０、６１２、および６１４を上述のとおりに実行する。判断ステップ６０２で、ファイルが保存されていることが判明した場合は、ステップ６１０、６１２、および６１４を上述のとおりに実行する。

以下は、本発明の例示的な使用法である。第１に、ユーザが、クラスに属性を追加し、クラスのコード・ビューにフォーカスを置くことを望んでいるとする。ユーザは、これを行うために、モデル要素４０５に記憶されているか関連付けられているモデル中のクラスを選択し、それに、たとえば、属性を追加することができる。ユーザは、コード・ビューにフォーカスを置いて、そのクラスのコードを表示することができる。コード・ビュー４１１のコード・エディタは、コード・ビュー４１１が選択されたことをモデル・コード・マネージャ４０１に通知できる。次に、モデル・コード・マネージャ４０１は、たとえば、図５を参照して説明した方法を用いて、そのクラスの、モデル要素４０５に記憶されているか関連付けられている１つまたは複数のモデル要素が、そのクラスのコードをコード・ジェネレータ４０２が生成した後に変更されているかどうか、およびファイル４１２、４１３、４１４、４１５の再生成が必要かどうかを調べることができる。変更されたモデル要素がある場合は、モデル・コード・マネージャ４０１がコード・ジェネレータ４０２を起動し、これに指示して、当該モデルに関連付けられた１つまたは複数のファイル４１２、４１３、４１４、４１５を再生成させることができる。モデル・コード・マネージャ４０１はさらに、コード・ビュー４１１にファイル４１２、４１３、４１４、４１５をリロードさせる更新メッセージをコード・ビュー４１１に送ることができる

第２の例として、ユーザは、たとえば、クラスの名前を変更し、修正したクラスとの関連があるクラスのビューにフォーカスを置くことができる。特に、ユーザは、モデル要素４０５に記憶されているか関連付けられているクラスをモデルから選択し、そのクラスの名前を変更することができる。ユーザは、コード・ビュー４１１にフォーカスを置いて、依存クラスのコードを表示することができる。コード・ビュー４１１との組み合わせで使用できるコード・エディタは、コード・ビュー４１１が選択されていることをモデル・コード・マネージャ４０１に通知できる。モデル・コード・マネージャ４０１は、たとえば、図５に関連して説明し示した方法を用いて、直接の関連がある要素に大きな変更（たとえば、承認された変更や、他のモデル要素またはコード・オブジェクトに影響を与えそうな変更）が発生したこと、およびファイル４１２、４１３、４１４、４１５の再生成が必要であることを確認できる。モデル・コード・マネージャ４０１は、コード・ジェネレータ４０２を起動して、コード・ジェネレータ４０２にファイル４１２、４１３、４１４、４１５を再生成させるか、再生成するよう指示することができる。モデル・コード・マネージャ４０１は、ファイル４１２、４１３、４１４、４１５をリロードするよう指示するかリロードさせる更新メッセージをコード・ビュー４１１に送ることができる。リロードしたファイルは、オプショナルで、表示させることができる。

第３の例として、ユーザは、図２のように、アクティブ・コード・ビュー４１０が表示されている間に、アクティブ・コード・ビュー２０８で、モデル要素４０５に記憶されているか関連付けられている要素を選択できる。特に、ユーザがモデル要素を選択すると、アクティブ・コード・ビュー４０５が、その選択の通知を受け、１つまたは複数のファイル４１２、４１３、４１４、４１５をロードするか、オプショナルで作成することが可能になる。アクティブ・コード・ビュー４１０は、ファイル４１２、４１３、４１４、４１５の再生成が必要かもしれないということをモデル・コード・マネージャ４０１に通知できる。モデル・コード・マネージャ４０１は、ファイル４１２、４１３、４１４、４１５の再生成が必要かどうかを調べ、１つまたは複数のファイル４１２、４１３、４１４、４１５を、オプショナルで、図５を参照して説明した方法を用いて、再生成することができる。

第４の例として、ユーザはクラスのコード・ビュー４１１を開くことができる。具体的には、ユーザは、編集するクラスを選択できる。そのクラスのファイル４１２、４１３、４１４、４１５が存在しない場合は、コード・ジェネレータ４０２がファイル４１２、４１３、４１４、４１５を生成できる。そのクラスのファイル４１２、４１３、４１４、４１５が１つまたは複数存在する場合は、コード・ビュー４１１がモデル・コード・マネージャ４０１に、ファイル４１２、４１３、４１４、４１５が開いていることを通知できる。たとえば、図５で説明した方法によれば、モデル・コード・マネージャ４０１は、ファイル４１２、４１３、４１４、４１５の再生成が必要かどうかを調べ、その結果に適した処理をコード・ジェネレータ４０２に指示することができる。モデル・コード・マネージャ４０１はさらに、オプショナルで、コード・ビュー４１１および／またはアクティブ・コード・ビュー４１０に、そのファイルをリロードさせ、つづいて、再生成されたコードを表示させることができる。

第５の例として、ユーザは、コード内のクラスの名前を変更し、コード・ビュー４１１を終了することができる。具体的には、コード・ビュー４１１は、ファイル４１２、４１３、４１４、４１５を保存し、モデル・コード・マネージャ４０１に、ファイル４１２、４１３、４１４、４１５を修正および保存したことを通知することができる。モデル・コード・マネージャ４０１はリポジトリ更新４０３を起動でき、リポジトリ更新４０３は、クラスの名前が、モデル要素４０５で指定されている名前と異なることを検出し、モデル要素４０５内でクラスの名前を変更することができる。リポジトリ更新４０３は、コード・ジェネレータ４０２がコードを生成した後と、生成されたコードにユーザが変更を加えた後とに起動できる。リポジトリ４０７は、任意の依存要素を、オプショナルで、ユーザがクラスの名前を手動で変更したかのように更新できる。コード・ジェネレータ４０２は、ファイル４１２、４１３、４１４、４１５内のコードと、モデル要素４０５に記憶されているか関連付けられているモデル要素とを再同期させるために起動できる。たとえば、Ｊａｖａプログラミング言語では、コンストラクタとファイナライザの名前を正しく変更できる。たとえば、Ｃ＋＋プログラミング言語では、コンストラクタとデストラクタの名前を正しく変更できる。

図７は、本発明の、コンピュータに実装される実施形態に係るコンピュータ処理を実装するためのコンピュータ７００を例示した図である。前述した手続きは、たとえば、コンピュータまたはコンピュータ・ネットワーク上で実行されるプログラム手続き（手順）の形で表すことができる。

図８では外部的に示しているが、コンピュータ７００は、ディスク・ドライブ７０４、７０６を有するＣＰＵ（中央処理ユニット）７０２を有する。ディスク・ドライブ７０４、７０６は、コンピュータ７００に収容できるいくつかのディスク・ドライブの単なる象徴である。通常、それらのディスク・ドライブは、フロッピーディスク・ドライブ７０４、および７０６においてスロットで示されるＣＤ−ＲＯＭディスクおよびデジタル・ビデオ・ディスクの１つまたは複数である。ドライブの数と種類は、通常、コンピュータの構成によって異なる。ドライブ７０４、７０６は、実際にはオプション（任意選択）であり、スペースの条件により、本願明細書で説明している処理に関係して使用されるコンピュータ・システムから省くことが可能である。

コンピュータ７００はさらに、情報を表示できるディスプレイ７０８を有する。このディスプレイは、本願明細書で説明しているシステムに関連して使用されるコンピュータに対してオプション（任意選択）である。キーボード７１０および／またはポインティング・デバイス７１２（マウス７１２、タッチ・パッド制御装置、トラック・ボール装置、またはその他のポインティング・デバイスなど）を、中央処理ユニット７０２とインターフェースするための入力装置として備えることができる。入力の効率を高めるために、スキャナ、カード・リーダ、またはその他のデータ入力装置をキーボード７１０の補助として追加したり、或いはそれらの装置でキーボード７１０を置き換えたりできる。

図８は、図７のコンピュータの内部ハードウェアのブロック図である。バス８０４は、コンピュータの他のコンポーネントを相互接続する主要情報ハイウェイとして動作する。これは、インターフェース８０６によってコンピュータ７００に接続される。これにより、キーボード７１０またはポインティング・デバイス（マウス７１２など）を使用するデータ入力が可能である。

ＣＰＵ７０２は、システムの中央処理ユニットであり、プログラムの実行に必要な計算および論理演算を行う。ＲＯＭ（読み出し専用メモリ）８１２およびＲＡＭ（ランダム・アクセス・メモリ）８１４は、コンピュータのメイン・メモリを構成する。

ディスク・コントローラ８１６は、１つまたは複数のディスク・ドライブをシステム・バス８０４にインターフェースする。それらのディスク・ドライブとして、７０４などのフロッピーディスク・ドライブ、７０６として示されるＣＤ−ＲＯＭドライブまたはＤＶＤ（デジタル・ビデオ／多用途ディスク）ドライブ、または、内蔵または外付けのハードディスク・ドライブ（単数もしくは複数）８１８を使用できる。既述のとおり、これらの各種ディスク・ドライブおよびディスク・コントローラは、オプショナル（任意選択）の装置である。

ディスプレイ・インターフェース８２０は、バス８０４からの情報をディスプレイ７０８上に表示することを可能にする。既述のとおり、ディスプレイ７０８はオプショナルな（任意選択）アクセサリであり、たとえば、赤外線レシーバおよびトランスミッタ（図示せず）を使用できる。外部装置との通信は、通信ポート８２２を使用して行うことができる。

従来の処理システムのアーキテクチャについては、「コンピュータ組織と構成（Ｃｏｍｐｕｔｅｒ Ｏｒｇａｎｉｚａｔｉｏｎ ａｎｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）」（ウィリアム・スターリングス（Ｗｉｌｌｉａｍ Ｓｔａｌｌｉｎｇｓ）著、マクミラン出版社（ＭａｃＭｉｌｌａｎ Ｐｕｂｌｉｓｈｉｎｇ Ｃｏ．）刊（第３版、１９９３年））に詳細に説明されている。従来の処理システムのネットワーク設計については、「データ・ネットワーク設計（Ｄａｔａ Ｎｅｔｗｏｒｋ Ｄｅｓｉｇｎ）」（ダレン・エル・スポーン（Ｄａｒｒｅｎ Ｌ． Ｓｐｏｈｎ）著、マグローヒル社（ＭｃＧｒａｗ−Ｈｉｌｌ，Ｉｎｃ．）刊（１９９３年））に詳細に説明されている。従来のデータ通信については、「データ通信原理（Ｄａｔａ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｐｒｉｎｃｉｐｌｅｓ）」（アール・デー・ギトリン（Ｒ．Ｄ．Ｇｉｔｌｉｎ）、ジェイ・エフ・ハイエス（Ｊ．Ｆ．Ｈａｙｅｓ）、エス・ビー・ワインシュタイン（Ｓ．Ｂ．Ｗｅｉｎｓｔａｉｎ）ら著、プレナム出版社（Ｐｌｅｎｕｍ Ｐｒｅｓｓ）刊（１９９２年））および「イルウィンの通信ハンドブック（Ｔｈｅ Ｉｒｗｉｎ Ｈａｎｄｂｏｏｋ ｏｆ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ）」（ジェイムズ・ハリー・グリーン（Ｊａｍｅｓ Ｈａｒｒｙ Ｇｒｅｅｎ）著、イルウィン専門書出版社（Ｉｒｗｉｎ Ｐｒｏｆｅｓｓｉｏｎａｌ Ｐｕｂｌｉｓｈｉｎｇ）刊（第２版、１９９２年））により詳細に説明されている。上記の各出版物は、参照により本明細書に組み込まれる。

上述の詳細説明は、具体的な詳細を多く含んでいる。そのような詳細を含むことの目的は、例示することのみであり、本発明を限定することではないことを理解されたい。また、一実施形態における特徴は、本発明の他の実施形態における特徴と組み合わせることができる。添付の特許請求項で定義される本発明の範囲から逸脱することなく、様々な変更が可能である。

一例として、パーソナル・コンピュータ、汎用コンピュータ、特別にプログラムされた特定用途コンピュータなどを、ユーザのコンピュータとして使用できる。同様に、装置アプリケーションは、埋め込みシステムのほか、その装置と密に接続され、かつ／またはその装置を制御する、汎用コンピュータ或いは特別にプログラムされた専用コンピュータ上でも実行できる。これらはいずれも、単一コンピュータではなく分散コンピュータ・システムとして実装できる。同様に、本発明は、インターネット、イントラネット、ワールド・ワイド・ウェブ（Ｗｏｒｌｄ Ｗｉｄｅ Ｗｅｂ）、ＰＯＴＳ回線経由のモデム、および／または他の任意の、コンピュータ間および／または装置間の通信手段方法などのネットワークにおいて使用できる。さらに、この処理を、１つまたは複数のコンピュータ・システムまたはプロセッサ上のソフトウェア・プログラムで制御したり、或いはこの処理を部分的に、または全面的にハードウェアに実装したり、一部の処理を種々の装置に埋め込んだりすることもできる。

本発明は、たとえば、埋め込みシステムを有する特定タイプの装置と関連しての使用に限定されない。さらに本発明は、特定の通信プロトコルに限定されない。適切であればどのようなプロトコルでも、この計測装置で使用できる。

ユーザ表示は、ＨＴＭＬ表示フォーマットで開発できる。ＨＴＭＬは好ましい表示フォーマットであるが、別の表示フォーマットを利用して、レポートを表示したり、ユーザ命令を取得したりすることも可能である。本発明については、特定の例との関連で説明した。しかし、その原理は、他の例にも等しく当てはまる。当然ながら、関連するデータは適宜異なる。

さらに、本発明については、単一サイトを有する単一カスタマに対してプロバイダが提供し得るかのような形の例で説明した。本発明は、もしそれが好ましいのであれば、多数のカスタマで使用できる。また、本発明は、複数のサイトおよび／またはユーザを擁するカスタマも使用できる。さらに、上記に代わる他の実施形態は、本発明の範囲内であると見なされる。たとえば、モデル・コード・マネージャ４０１および関連コンポーネントの全体的な機能が本願明細書での説明のとおりに（または、実質的にそのとおりに）実行される限り、前述した具体的なシーケンスを適宜変更することができる。

本発明に関連して用いられるシステムは、ハードウェア・サーバおよびソフトウェア・サーバ、アプリケーション・ソフトウェア、データベース・エンジン、ファイアウォール、セキュリティ、本番バックアップ・システム、および／またはアプリケーション・インターフェース・ソフトウェアを適宜および／または必要に応じて含む種々のコンポーネントの組み合わせになる。構成はネットワーク・ベースにすることができ、オプショナル（任意選択）でインターネットを、情報配信のための、カスタマとの例示的主要インターフェースとして利用することができる。

ユーザの視点で言えば、いくつかの実施形態では、ユーザは、インターネットへのアクセス権や他の適切なアクセス権を有する限り、公共のインターネットや他の適切なネットワークにアクセスして、いつでもどこからでも、個々に必要な具体的な情報を参照することができる。

付属書類
ユーザ・ガイド
アイ−ロジックス（Ｉ−Ｌｏｇｉｘ）
ラプソディ（Ｒｈａｐｓｏｄｙ（登録商標））
ユーザ・ガイド
リリース４．２
アイ−ロジックス（Ｉ−Ｌｏｇｉｘ）

第１５章 コード生成
ラプソディ（Ｒｈａｐｓｏｄｙ）は、ＵＭＬモデルから実装コードを生成する。コンフィグレーション全体に対しても、選択したクラスに対しても、コードを生成することができる。コード・ジェネレータへの入力は、モデルと、コード生成（＜ｌａｎｇ＞＿ＣＧおよびＣＧ）プロパティである。コード・ジェネレータからの出力は、ターゲット言語でのソース・ファイル（仕様ファイル、実装ファイル、およびメイクファイル）である。

この章では、ラプソディ（Ｒｈａｐｓｏｄｙ）がＵＭＬモデルからコードを生成する動作について説明する。この章は、以下のトピックについての情報を含む。
・概要 １５−２頁
・コードを生成する １５−４頁
・ターゲットを樹立（ビルド）する １５−６頁
・実行可能ファイルを実行する １５−７頁
・個々の要素のコードを生成する １５−８頁
・コード生成の結果 １５−９頁
・コードを表示および編集する １５−１０頁
・ラウンドトリップ １５−１２頁
・重複したコード・ファイルを削除する １５−２２頁
・アクタのコードを生成する １５−２２頁
・コンポーネント図のコードを生成する １５−２３頁
・クロスパッケージの初期設定 １５−２５頁
・クラス・コード構造 １５−２６頁
・＃ｉｆｄｅｆ−＃ｅｎｄｉｆでコードをラップする １５−３６頁
・演算子をオーバーロードする １５−３６頁
・匿名インスタンスを使用する １５−４１頁
・関係を使用する １５−４３頁
・静的アーキテクチャのサポート １５−４５頁
・標準操作を用いる １５−４８頁

概要
ラプソディ（Ｒｈａｐｓｏｄｙ）は、コード・ジェネレータと、１組のライブラリとして提供されるリアルタイムＯＸＦ（オブジェクト実行フレームワーク（Ｏｂｊｅｃｔ Ｅｘｅｃｕｔｉｏｎ Ｆｒａｍｅｗｏｒｋ））との間に、最低レベルの設計判断をユーザに代わって実装できる。この判断には、関連、関係オブジェクトの多重度、スレッド、状態マシンなどの設計要素の実装方法が含まれる。

コードを生成するには、以下の２つの方法がある。
・精緻的（ｅｌａｂｏｒａｔｉｖｅ）方法 関係、状態マシン生成、その他のすべてを無効にした状態で、ラプソディ（Ｒｈａｐｓｏｄｙ）を単にコード・ブラウザとして使用することができる。インスタンスの初期設定やリンクは生成されない。すべてを手動で行う。
・変換的（ｔｒａｎｓｌａｔｉｖｅ）方法 コンポーネント、リンク、および状態マシンを有するコンポジットを描き、ボタンをクリックして、アプリケーションを実行することができる。作成するコードは最小限でよい（少なくともいくつかのアクションをステートチャートに書く必要がある）。

ラプソディ（Ｒｈａｐｓｏｄｙ）コード・ジェネレータは、様々なレベルで精緻的にも変換的にもなることができる。ラプソディ（Ｒｈａｐｓｏｄｙ）は変換を強制しないが、ラプソディ（Ｒｈａｐｓｏｄｙ）を使用すれば、コード生成プロセスを、必要なレベルまで洗練させることができる。ラプソディ（Ｒｈａｐｓｏｄｙ）はいずれのモードでも実行でき、また、これら２つのモードの間の任意の中間的な状態でも実行できる。

注記：マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）は、ラプソディ（Ｒｈａｐｓｏｄｙ）のデフォルト作業環境である。コンフィグレーションの環境設定で、他の「即時利用可能な」環境を指定することもできる。詳細については、第１２章の「ブラウザ中のコンポーネント・フィグレーションの設定（Ｓｅｔｔｉｎｇ Ｃｏｍｐｏｎｅｎｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎｓ ｉｎ ｔｈｅ Ｂｒｏｗｓｅｒ）」の項を参照されたい。

図１５．１は、ラプソディ（Ｒｈａｐｓｏｄｙ）でのコードの生成およびコンポーネントの樹立（ビルド）に関与する要素を示している。依存性矢印は、どのファイルがコード・ジェネレータによって生成され、どのファイルがコンパイラによって包含されるかを表す。コード・ジェネレータおよびコンパイラを囲む太い枠線は、これらがアクティブ・クラスであることを表す。

コードを生成する
コードを生成する前に、アクティブ・コンフィグレーションを設定しなければならない（詳細については、第１２章の「アクティブ・コンフィグレーションの設定（Ｓｅｔｔｉｎｇ ｔｈｅ Ａｃｔｉｖｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）」の項を参照されたい）。コード・ジェネレータは、自動的にチェッカを実行して、コードの生成やコンパイルにおいて問題を引き起こすおそれのある不整合性がないかどうかをチェックする。チェッカが実行するチェックのうちのいくつかは、コード生成前に修正されていないとコード生成が中断されるおそれのある潜在的に致命的な状況を検出する。実行するチェックの選択については、第１４章「チェック（Ｃｈｅｃｋｓ）」を参照されたい。

アクティブ・コンフィグレーションのコードを生成するには、次のいずれかを行う。
・Ｃｏｄｅ ＞ Ｇｅｎｅｒａｔｅ ＞ ＜アクティブ・コンフィグレーション＞を選択する。
・Ｃｔｒｌ＋Ｆ７キーを押す。

タスク間通信およびラプソディ（Ｒｈａｐｓｏｄｙ）からのイベント・ディスパッチを行わなくてもコードを生成することは可能だが、その場合は、アニメーション機能や可視デバッグ機能が無効になることに注意されたい。この影響は、インハウスのタスク間通信およびイベント・ディスパッチのルーチンを、モデル内で定義された操作の中にラップすることによって軽減できる。この場合は、その操作が、「実際の」タスク間通信およびイベント・ディスパッチの代わりに可視化される。

コード生成を中断する
長いコード生成セッションを終了するには、Ｃｏｄｅ ＞ Ｓｔｏｐ Ｘを選択する。たとえば、コードをビルドしている途中の場合のオプション名はＳｔｏｐ Ｂｕｉｌｄである。

コード生成を中断する別の方法は、コンフィグレーションのルート生成ディレクトリにａｂｏｒｔ＿ｃｏｄｅ＿ｇｅｎ（拡張子なし）というファイルを作成することである。ラプソディ（Ｒｈａｐｓｏｄｙ）は、コード生成中にそのファイルがないかどうかチェックする。そのファイルが見つかった場合、ラプソディ（Ｒｈａｐｓｏｄｙ）はそのファイルを削除してコード生成を中断する。

インクリメンタル・コード生成
ラプソディ（Ｒｈａｐｓｏｄｙ）は、コンフィグレーションのための初期コード生成の後、最後に生成された後に変更された要素についてのみコードを生成する。これにより、コード生成に要する時間が減り、性能が大幅に向上する。

インクリメンタル・コード生成のサポートのために、ラプソディ（Ｒｈａｐｓｏｄｙ）は、＜コンフィグレーション（ｃｏｎｆｉｇｕｒａｔｉｏｎ）＞．ｃｇ＿ｉｎｆｏというファイルをコンフィグレーション・ディレクトリに作成する。このファイルは、ラプソディ（Ｒｈａｐｓｏｄｙ）の内部用であり、コンフィグレーション管理下に置く必要はない。

全コード生成を強制する
場合によっては、変更した要素だけでなく、モデル全体の生成が必要になる。

モデルの完全な再生成を強制するには、Ｃｏｄｅ ＞ Ｒｅ Ｇｅｎｅｒａｔｅ ＞ ＜コンフィグレーション＞を選択する。

コンフィグレーション・ファイルを再生成する
モデルからクラスまたはパッケージを削除したり、パッケージに第１グローバル・インスタンスを追加したりした場合は、コンフィグレーション・ファイル（メイン・ファイルとメイクファイル）を再生成する必要がある。
コンフィグレーション・ファイルの再生成を強制するには、次のいずれかを行う。
・Ｃｏｄｅ ＞ Ｒｅ Ｇｅｎｅｒａｔｅ ＞ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｆｉｌｅｓを選択する。
・ブラウザでアクティブ・コンフィグレーションを右クリックし、ポップアップ・メニューからＧｅｎｅｒａｔｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｍａｉｎ ａｎｄ Ｍａｋｅｆｉｌｅｓを選択する。

パッケージのスマートな生成
ラプソディ（Ｒｈａｐｓｏｄｙ）は、パッケージに意味のある情報（インスタンス、型、関数など）が含まれている場合のみ、そのパッケージのコードを生成する。この動作は、不要なパッケージ・ファイルを生成しないことによって、コード生成プロセスを合理化する。

この動作を変更するには、ＣＧ：：Ｐａｃｋａｇｅ：：ＧｅｎｅｒａｔｅＰａｃｋａｇｅＣｏｄｅプロパティを使用する。詳細については、「プロパティ参照ガイド（Ｐｒｏｐｅｒｔｉｅｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）」を参照されたい。

意味のある情報を含まない既存のパッケージ・ファイルを除去するには、Ｃｏｄｅ ＞ Ｃｌｅａｎ Ｒｅｄｕｎｄａｎｔ Ｆｉｌｅｓを選択する。

コードを生成する際の考慮事項
コードを生成する際には、以下の点を考慮されたい。
・非リアクティブ・クラスから継承したリアクティブ・クラスは、インストルメンテーション・モードでコンパイル警告を発生させる可能性がある。この警告は無視してよい。
・トリガされる操作を自己（循環）起動することは、フラットな（再利用不可の）ステートチャートでのみ可能である。これを再利用可能なステートチャートで行うと、生成されたアプリケーションはそれらを無視する。コード・ジェネレータは、こうした状況をチェックしない。
・コンポーネントの範囲外にある別のクラスに依存するクラスがある場合、ラプソディ（Ｒｈａｐｓｏｄｙ）は、その外部クラスに対する＃ｉｎｃｌｕｄｅ文を自動生成しない。その依存クラスのＳｐｅｃＩｎｃｌｕｄｅプロパティを＜ｌａｎｇ＞＿ＣＧ：：Ｃｌａｓｓの下に設定しなければならない。

自動コード生成
Ｃｏｄｅ ＞ Ｄｙｎａｍｉｃ Ｍｏｄｅｌ Ｃｏｄｅ Ａｓｓｏｃｉａｔｉｖｉｔｙ（ＢｉｄｉｒｅｃｔｉｏｎａｌまたはＯｎｌｉｎｅ Ｃｏｄｅ Ｇｅｎｅｒａｔｉｏｎ設定）を選択した場合は、要素が変更され、その再生成が必要になると、ラプソディ（Ｒｈａｐｓｏｄｙ）が自動的にコードを生成する。この変更には以下のものが含まれる。
・要素自体の変更（要素の名前やプロパティの変更、要素の一部の追加または削除による変更など）
・要素の所有者、関連する要素、プロジェクト、選択されたコンポーネント、またはコンフィグレーションの変更
・Ａｄｄ ｔｏ Ｍｏｄｅｌ機能による、モデルへの要素の追加
・ＣＭツールによる要素のチェックアウト
・要素の編集中のＵｎｄｏコマンドの使用
次のいずれかのことを行うと、要素のコードが自動的に生成される。
・内部テキスト・エディタまたは外部エディタを使用して、要素のＣｏｄｅ Ｖｉｅｗウィンドウを開く。「コードを表示および編集する」の項を参照されたい。
・その要素の既存のＣｏｄｅ Ｖｉｅｗウィンドウにフォーカスを置く。

動的モデル／コード結合をＮｏｎｅまたはＲｏｕｎｄｔｒｉｐに設定した場合は、ＣｏｄｅメニューのＧｅｎｅｒａｔｅコマンドを使用して、変更した要素のコードを生成する必要がある。詳細については、「動的モデル／コード結合」の項を参照されたい。

メイクファイルを生成する
ラプソディ（Ｒｈａｐｓｏｄｙ）は、コンパイルおよびリンクするファイル、それらの依存、およびコンパイルとリンクのコマンドの、それぞれのリストを含む簡単（プレーン）なメイクファイルを生成する。

ラプソディ（Ｒｈａｐｓｏｄｙ）は、ターゲット・ファイルを生成するときにメイクファイルを生成する。＜ｌａｎｇ＞＿ＣＧ：：＜環境（Ｅｎｖｉｒｏｎｍｅｎｔ）＞の下のＩｎｖｏｋｅＭａｋｅプロパティは、メイクファイルの実行方法を定義する。メイクファイルの内容は、＜ｌａｎｇ＞＿ＣＧ：：＜環境（Ｅｎｖｉｒｏｎｍｅｎｔ）＞の下のＭａｋｅＦｉｌｅＣｏｎｔｅｎｔプロパティを変更することによってカスタマイズできる。詳細については、「プロパティ参照ガイド（Ｐｒｏｐｅｒｔｉｅｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）」を参照されたい。

ターゲットをビルド（樹立）する
コードが正しく生成されたら、ターゲット・コンポーネントをビルドできる。次のいずれかの方法を用いる。
・Ｃｏｄｅ ＞ Ｂｕｉｌｄ ＜ターゲット名（ｔａｒｇｅｔｎａｍｅ）＞．ｅｘｅを選択する。
・ＣｏｄｅツールバーのＢｕｉｌｄ Ｔａｒｇｅｔアイコンをクリックする。

ラプソディ（Ｒｈａｐｓｏｄｙ）がコードをコンパイルするにつれ、Ｏｕｔｐｕｔウィンドウにコンパイラ・メッセージが表示される。コンパイルが完了すると、「Ｂｕｉｌｄ Ｄｏｎｅ」というメッセージが表示される。

アプリケーションをビルドする前に古いオブジェクトを削除する
場合によっては、リンカが古いオブジェクトを使用してアプリケーションをリンクする可能性がある。

古いオブジェクトを一掃するには、次のいずれかの方法を用いる。
・Ｃｏｄｅ ＞ Ｃｌｅａｎコマンドを使用して、現在のコンフィグレーションに関するすべてのコンパイル済みオブジェクト・ファイルを削除する。推奨されるのは、この方法である。
・毎回、Ｃｏｄｅ ＞ Ｒｅｂｕｉｌｄコマンドを使用する。複雑なシステムの場合は時間がかかる場合がある。
・ｅｔｃ／ｍｓｍａｋｅ．ｂａｔ内でメイクの開始を変更し、／Ｉオプションを外す。これにより、最初にエラーがあったソースでビルドが中止される。
・ｓｉｔｅ．ｐｒｐファイル内で、ＣＰＰＣｏｍｐｉｌｅＣｏｍｍａｎｄプロパティをＳｔｒｉｎｇからＭｕｌｔｉＬｉｎｅに変更し、その内容を、ファイルがコンパイルされる前に既存の．ｏｂｊファイルが削除されるように変更する。

例：
ＣＰＰＣｏｍｐｉｌｅＣｏｍｍａｎｄプロパティ
メタクラスＭｉｃｒｏｓｏｆｔ：
Property CPPCompileCommand MultiLine
" if exist $OMFileObjPath
erase $0MfileObjPath
$ (CPP)
$OMFileCPPCompileSwitches
/Fo＼"$OMFileObjPath＼"
＼"$OMFileImpPath＼" "
Metaclass VxWorks:
Property CPPCompileCommand MultiLine
" @echo Compiling
$OMFileImpPath
@$(RM) $OMFileObjPath
@$(CXX) $ (C++FLAGS)
$OMFileCPPCompileSwitches-o
$OMFileObjPath
$OMFileImpPath"

実行可能ファイルを実行する
ターゲット・ファイルをビルドしたら、次のいずれかの方法で実行できる。
・Ｃｏｄｅ ＞ Ｒｕｎ ＜コンフィギュレーション（ｃｏｎｆｉｇ）＞．ｅｘｅを選択する。
・ＣｏｄｅツールバーのＲｕｎツールをクリックする。

デフォルトの実行可能アプリケーションは、コンソール・アプリケーションである。このアプリケーションが起動されると、そのインストルメンテーション・レベルに関係なく、コンソール・ウィンドウが表示される。アプリケーションがテキスト・メッセージを標準出力装置に送ると、それらがコンソール・ウィンドウに表示される。

実行可能ファイル作成用ショートカット
コードおよびメイクファイルを生成し、ターゲットをビルドし、そのすべてを１つのステップで実行するには、次のいずれかを行う。
・Ｃｏｄｅ ＞ Ｇｅｎｅｒａｔｅ／Ｍａｋｅ／Ｒｕｎを選択する。
・ＣｏｄｅツールバーのＧｅｎｅｒａｔｅ／Ｍａｋｅ／Ｒｕｎツールをクリックする。

インストルメンテーション
コードにアニメーション・インストルメンテーションを含めた場合は、コードを実行すると、Ａｎｉｍａｔｉｏｎツールバーが表示される。コードにトレース・インストルメンテーションを含めた場合は、コードを実行すると、Ｔｒａｃｅウィンドウが表示される。コンフィグレーションのパラメータを設定するときに、アニメーション・インストルメンテーションまたはトレース・インストルメンテーションを選択できる。第１２章の「コンフィグレーション（Ｃｏｎｆｉｇｕｒａｔｉｏｎｓ）」の項を参照されたい。

インストルメンテーションの詳細については、第１８章「アニメーション（Ａｎｉｍａｔｉｏｎ）」および第１９章「トレーシング（Ｔｒａｃｉｎｇ）」を参照されたい。

モデル実行を中止する
進行中のモデル実行を中止するには、次のいずれかの方法を用いる。
・Ｃｏｄｅ ＞ Ｓｔｏｐを選択する。
・ＣｏｄｅツールバーのＳｔｏｐ Ｍａｋｅ／Ｅｘｅｃｕｔｉｏｎツールをクリックする。

個々の要素のコードを生成する
パッケージとそのすべてのクラスのコード、またはパッケージ内の選択したクラスのコードを生成することができる。コードの生成は、Ｃｏｄｅメニュー、ブラウザ、またはＯＭＤから行うことができる。

クラスまたはパッケージのコードを生成する前に、モデル全体の実行可能ファイルを生成する場合とまったく同じように、アクティブ・コンフィグレーションを設定しなければならない。詳細については、第１２章の「アクティブ・コンフィグレーションの設定（Ｓｅｔｔｉｎｇ ｔｈｅ Ａｃｔｉｖｅ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）」の項を参照されたい。

Ｃｏｄｅメニューを使用する
Ｃｏｄｅメニューを用いてコードを生成するには、以下を行う。
１．ブラウザからクラスを選択するか、ＯＭＤで１つまたは複数のクラスを選択する。
２．Ｃｏｄｅ ＞ Ｇｅｎｅｒａｔｅ ＞ Ｓｅｌｅｃｔｅｄ Ｃｌａｓｓｅｓを選択する。

モデル全体のコードを少なくとも一度生成したことがある場合は、Ｇｅｎｅｒａｔｅコマンドによって、最後のコード生成の後に変更された要素のコードだけが生成される。

変更されているかどうかに関係なく、選択したすべての要素のコードを生成するには、以下を行う。
１．ブラウザからクラスを選択するか、ＯＭＤで１つまたは複数のクラスを選択する。
２．Ｃｏｄｅ ＞ Ｒｅ Ｇｅｎｅｒａｔｅ ＞ Ｓｅｌｅｃｔｅｄ Ｃｌａｓｓｅｓを選択する。

ブラウザを使用する
ブラウザからコードを生成するには、以下を行う。
１．ブラウザで、パッケージまたはクラスを右クリックする。
２．パッケージの場合は、ポップアップ・メニューからＧｅｎｅｒａｔｅ Ｐａｃｋａｇｅを選択して、該パッケージ内のすべてのクラスのコードを生成する。

クラスの場合は、ポップアップ・メニューからＧｅｎｅｒａｔｅ Ｃｌａｓｓを選択して、そのクラスのコードだけを生成する。

オブジェクト・モデル図を使用する
ＯＭＤでクラスのコードを生成するには、そのクラスを右クリックし、ポップアップ・メニューからＧｅｎｅｒａｔｅ Ｃｌａｓｓを選択する。

コード生成の結果
コード生成が完了すると、ラプソディ（Ｒｈａｐｓｏｄｙ）が結果を表示する。コード生成メッセージがＯｕｔｐｕｔウィンドウに表示される。メッセージをクリックすると、モデル内の該当位置が表示される。

出力メッセージ
コードを生成し、ターゲットをビルドすると、操作の正常終了を伝えるメッセージか、エラーを知らせるメッセージがＯｕｔｐｕｔウィンドウに表示される。

モデリング・コンストラクトによっては、コード生成エラーが発生する可能性がある。こうしたエラーのほとんどは、コードを生成する前にモデルをチェックすれば、深刻な問題が発生する前に発見して修正することができる。

エラーの強調表示と修正
ラプソディ（Ｒｈａｐｓｏｄｙ）では、メイク処理中にコンパイル・エラーを表示できる。コンパイル・エラーの原因を知るには、そのエラー・メッセージをダブルクリックする。エラーの原因に応じて、次のいずれかの結果が発生する。
・ステートチャート・エディタが開き、遷移または状態が強調表示されている。これは、その遷移または状態に正しくない表現を入力したことを意味する。ステートチャート・エディタでエラーを修正する。
・ブラウザが開き、属性または操作が強調表示されている。これは、属性または操作の定義に正しくない表現を入力したことを意味する。ブラウザでエラーを修正する。
・ソース・ファイルが開き、ある行が強調表示されている。これは、修正する必要がある設計内のアイテムをラプソディが表示できなかったことを意味する。この場合は、手動開発サイクルの場合のように、以下に示す方法でエラーの原因を識別する必要がある。

−エラーの原因が、ラウンドトリップ可能な注釈セクション内で見つかった場合は、ソース・ファイルでエラーを修正し、それをラウンドトリップする。

−エラーの原因がラウンドトリップ不可である場合は、そのエラーを引き起こす、モデル内のコンストラクト（操作パラメータ定義など）を修正する。

−モデル内に明らかな問題が見あたらず、選択したクラスについてコードを生成していた場合は、Ｃｏｄｅ／Ｃｌｅａｎメニュー・コマンドを使用してコンフィグレーション全体をクリーンにする。様々なバージョンのモデルでファイルが生成されていると、コンパイル・エラーが発生する可能性がある。

−あまりないことだが、モデル内になんら悪いところがなく、なおもコード生成の問題によってエラーが発生する場合は、アイ−ロジックス（Ｉ−Ｌｏｇｉｘ）カスタマ・サポートに連絡されたい。

コードを表示および編集する
Ｃｏｄｅ Ｖｉｅｗ機能により、クラスや選択したパッケージ（ただし、コンフィグレーションではない）のコードを編集できる。１つまたは複数のクラスを選択し、好みのテキスト・エディタを起動して、そのコード・ファイルを直接編集することができる。

コード・ビュー・エディタの範囲を設定する
コードを表示および編集するためには、コード・ビュー・エディタの範囲を設定しなければならない。以下を行う。
１．表示したいコードを有するパッケージまたはクラスを含むコンポーネントを右クリックする。
２．ポップアップ・メニューからＳｅｔ ａｓ Ａｃｔｉｖｅ Ｃｏｍｐｏｎｅｎｔ領域を選択する。
３．Ｃｕｒｒｅｎｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ領域（フィールド）で、使用したいコンフィグレーションを選択する。

コードを編集する
生成されたコードを編集するには、次のいずれかを行う。
・要素を強調表示し、Ｃｏｄｅ ＞ Ｅｄｉｔ ＞ Ｓｅｌｅｃｔｅｄ ｃｌａｓｓｅｓを選択する。
・要素を右クリックし、Ｅｄｉｔ ＜要素（ｅｌｅｍｅｎｔ）＞を選択する。

選択したクラスまたはパッケージの仕様ファイルと実装ファイルが別々のウィンドウで開く。ファイルの編集には、内部テキスト・エディタまたは外部エディタを使用できる。詳細については、「外部エディタを使用する」の項を参照されたい。

動的モデル／コード結合（ＤＭＣＡ）の設定に応じて、コードに加えた変更を、自動的にラウンドトリップされるようにしたり、モデルに組み込まれるようにしたりできる。詳細については、「自動ラウンドトリップと強制ラウンドトリップ」の項を参照されたい。

さらに、外部エディタまたはコード・ジェネレータによってコードが変更されたときに、開いているコード・ビューが更新されるかどうかも、ＤＭＣＡ設定で決まる。コード生成の場合、コードが大幅に変更されている可能性がある。そうなった場合は、次のようなメッセージが表示される。
＜ファイル名（ｆｉｌｅｎａｍｅ）＞：このファイルはソース・エディタ以外で変更されています。リロードしますか？
Ｙｅｓをクリックすると、コード・ビューが新しいファイル内容で更新される。実装ファイルが古い情報で置き換えられることはない。

エディタ内でコードを再生成する
エディタで現在開いているファイルのコードを再生成するには、Ｃｏｄｅ ＞ Ｒｅ Ｇｅｎｅｒａｔｅ ＞ Ｆｏｃｕｓｅｄ Ｖｉｅｗｓを選択する。

ファイルをエディタに関連付ける
特定のエディタを、ソース・ファイルの拡張子に関連付けることができる。以下を行う。
１．（Ｇｅｎｅｒａｌ：：Ｍｏｄｅｌの下の）ＣｌａｓｓＣｏｄｅＥｄｉｔｏｒプロパティをＡｓｓｏｃｉａｔｅに設定する。
２．ＯＫをクリックして変更を適用し、ダイアログ・ボックスを消す。
３．ＯＫをクリックして変更を適用し、ダイアログ・ボックスを消す。

注記：Ｍｉｃｒｏｓｏｆｔ Ｖｉｓｕａｌ Ｃ＋＋ ６．０は、＊．ｃｐｐファイルおよび＊．ｈファイルに関連付けられた操作のリストに「Ｏｐｅｎ ｗｉｔｈ ＭＳＤＥＶ（ＭＳＤＥＶでオープンする）」操作を含む。ＭＶＣ＋＋ ６．０がインストールされている場合、ラプソディ（Ｒｈａｐｓｏｄｙ）は、ソース・ファイルを、「Ｏｐｅｎ」操作にではなく誤って「Ｏｐｅｎ ｗｉｔｈ ＭＳＤＥＶ」操作に関連付ける可能性がある。

ラプソディ（Ｒｈａｐｓｏｄｙ）がＭＶＣ＋＋の「Ｏｐｅｎ」操作をソース・ファイルに確実に関連付けるようにするには、以下を行う。
１．Ｗｉｎｄｏｗｓエクスプローラから、Ｖｉｅｗ ＞ Ｏｐｔｉｏｎｓ ＞ Ｆｉｌｅ Ｔｙｐｅｓを選択する。
２．ファイル・タイプ（たとえば、ファイル拡張子Ｈに関連付けられたＣ Ｈｅａｄｅｒ Ｆｉｌｅ）を選択し、Ｅｄｉｔを選択する。

Ｅｄｉｔ Ｆｉｌｅ Ｔｙｐｅダイアログが開く。通常、最初にリストされているアクションは「Ｏｐｅｎ ｗｉｔｈ ＭＳＤＥＶ」である。
３．Ｎｅｗをクリックし、「Ｏｐｅｎ」アクションを追加し、そのＯｐｅｎアクションを好みのエディタ・アプリケーションに関連付ける。
４．「Ｏｐｅｎ ｗｉｔｈ ＭＳＤＥＶ」アクションを削除する。

外部エディタを使用する
コードの編集の際に外部エディタを指定するには、以下を行う。
１．Ｆｉｌｅ ＞ Ｐｒｏｊｅｃｔ Ｐｒｏｐｅｒｔｉｅｓを選択する。
２．Ｐｒｏｐｅｒｔｉｅｓタブを選択する。
３．Ｇｅｎｅｒａｌ：：Ｍｏｄｅｌ：：ＥｄｉｔｏｒＣｏｍｍａｎｄＬｉｎｅプロパティに移動する。
４．右カラムのプロパティ値呼び出しをクリックしてそのフィールドをアクティブにし、省略符号（．．．）をクリックしてＢｒｏｗｓｅ ｆｏｒ Ｆｉｌｅダイアログ・ボックスを開く。
５．使用したいエディタ（たとえば、Ｎｏｔｅｐａｄ）の場所まで移動し、そのエディタを選択する。ＯＫをクリックしてダイアログ・ボックスを消す。ラプソディによりプロパティ値フィールドにそのパスが入る。
６．ＯＫをクリックしてダイアログ・ボックスを消す。

生成された操作を表示する
ラプソディ（Ｒｈａｐｓｏｄｙ）は、モデルごとに、属性および関係に対するｓｅｔｔｅｒ操作とｇｅｔｔｅｒ操作、イニシャライザ操作とクリーンアップ操作、およびｓｔａｒｔＢｅｈａｖｉｏｒ（）と呼ばれる操作を提供する。ただし、ラプソディ（Ｒｈａｐｓｏｄｙ）がこれらの自動生成された操作をブラウザに表示するのは、（ＣＧ：：ＣＧＧｅｎｅｒａｌの下の）ＧｅｎｅｒａｔｅｄＣｏｄｅＩｎＢｒｏｗｓｅｒプロパティがＴｒｕｅに設定されている場合だけである。このプロパティを変更し、コードを再生成すると、自動生成された操作をブラウザに表示することができる。

ラウンドトリップ
ラウンドトリップは、ラプソディ（Ｒｈａｐｓｏｄｙ）が以前に生成したＵＭＬコードが変更されたときに、その変更に基づいてモデルを更新する処理である。ラウンドトリップをバッチ・モードでアクティブにするには、ファイル・システム内でコードを更新し、モデルを明示的に同期させる。また、ラウンドトリップをオンライン（オン・ザ・フライ）・モードでアクティブにするには、いずれかのラプソディ（Ｒｈａｐｓｏｄｙ）指定ビューの中でモデルを変更する。

動的モデル／コード結合
ラプソディ（Ｒｈａｐｓｏｄｙ） ＵＩを介してモデルを変更すると、その変更に対応するように動的モデル／コード結合（ＤＭＣＡ）がモデルのコードを変更する。逆に、モデルのコードを直接編集すると、その編集結果に対応するようにＤＭＣＡがモデルを再描画する。このようにして、ラプソディ（Ｒｈａｐｓｏｄｙ）は、モデルとコードとの間の緊密な関係およびトレーサビリティ（追跡可能性）を維持する。つまり、コードはモデルの別の姿である。

ＤＭＣＡ機能を設定するには、Ｃｏｄｅ ＞ Ｄｙｎａｍｉｃ ｍｏｄｅｌ／ｃｏｄｅ ａｓｓｏｃｉａｔｉｖｉｔｙを選択する。プルダウン・メニューから以下のいずれかのオプションを選択する。
・Ｂｉｄｉｒｅｃｔｉｏｎａｌ（双方向性）−変更が双方向で自動的に処理される。すなわち、モデルを変更すると、新しい、更新されたコードが生成され、コードを直接編集すると、その編集結果がラプソディ（Ｒｈａｐｓｏｄｙ）モデルに自動的に反映される。
・Ｃｏｄｅ Ｇｅｎｅｒａｔｉｏｎ（コード生成）−モデルを変更すると新しいコードが自動的に生成されるが、コードを編集してもモデルは自動的には変更されない。
・Ｒｏｕｎｄｔｒｉｐｐｉｎｇ（ラウンドトリップ）−コードを直接変更するとその結果がラプソディ（Ｒｈａｐｓｏｄｙ）モデルに反映されるが、モデルを変更しても新しいコードが自動的には生成されない。ラウンドトリップできるのは、ラプソディ（Ｒｈａｐｓｏｄｙ）によって以前に生成されたコードだけである。すなわち、ラプソディ（Ｒｈａｐｓｏｄｙ）によって以前に生成されたコードに限り、そのコードを編集して、その変更をモデルに組み込むことができる。詳細については、「ラウンドトリップ処理」の項を参照されたい。
・Ｎｏｎｅ（否）−ＤＭＣＡが無効である。

これらの設定は、以下のプロパティに格納される。
・ｒｈａｐｓｏｄｙ．ｉｎｉファイルのＭｏｄｅｌＣｏｄｅＡｓｓｏｃｉａｔｉｖｉｔｙＭｏｄｅ
・Ｇｅｎｅｒａｌ：：Ｍｏｄｅｌの下のＭｏｄｅｌＣｏｄｅＡｓｓｏｃｉａｔｉｖｉｔｙＦｉｎｅＴｕｎｅ

ラウンドトリップ処理
ソース・ファイルを直接変更し、Ｃｏｄｅ ＞ Ｇｅｎｅｒａｔｅ Ｃｏｄｅを選択すると、ラプソディにより、コードをラウンドトリップするよう求められる。このセクションでは、ラウンドトリップ手続きにおけるオプションについて説明する。

自動ラウンドトリップと強制ラウンドトリップ
自動ラウンドトリップ（Ｂｉｄｉｒｅｃｔｉｏｎａｌ設定またはＲｏｕｎｄｔｒｉｐｐｉｎｇ設定）を選択した場合は、次のいずれかを行うと、コードの変更に合わせてモデルが自動的に更新される。
・フォーカスをＣｏｄｅ Ｖｉｅｗウィンドウから別のウィンドウに移す。
・編集中のファイルを保存する。
・Ｃｏｄｅ Ｖｉｅｗウィンドウを閉じる。

強制的にラウンドトリップする場合は、次のいずれかを行う。
・Ｃｏｄｅ ＞ Ｒｏｕｎｄｔｒｉｐを選択する。変更した要素についてコードがラウンドトリップされる。
・Ｃｏｄｅ ＞ Ｆｏｒｃｅ Ｒｏｕｎｄｔｒｉｐを選択する。すべての要素についてコードがラウンドトリップされる。

強制ラウンドトリップはいつでも行うことができる。ＤＭＣＡをＮｏｎｅまたはＣｏｄｅＧｅｎｅｒａｔｉｏｎに設定している場合、変更したコードをモデルにラウンドトリップするには、強制ラウンドトリップによるのが唯一の方法である。

クラスをラウンドトリップする
コンフィグレーション内の変更されたすべてのクラスをラウンドトリップするには、Ｃｏｄｅ ＞ Ｒｏｕｎｄｔｒｉｐ ＞ ＜現在のコンフィグレーション（ｃｕｒｒｅｎｔ＿ｃｏｎｆｉｇ）＞を選択する。

変更の有無に関係なく、コンフィグレーション内のすべてのクラスをラウンドトリップするには、Ｃｏｄｅ ＞ Ｆｏｒｃｅ Ｒｏｕｎｄｔｒｉｐ ＞ ＜現在のコンフィグレーション（ｃｕｒｒｅｎｔ＿ｃｏｎｆｉｇ）＞を選択する。

複数のクラスについて変更をラウンドトリップするには、以下を行う。
１．ＯＭＤで、それらのクラスを左クリックする。
２．Ｃｏｄｅ ＞ Ｒｏｕｎｄｔｒｉｐ ＞ Ｓｅｌｅｃｔｅｄ ｃｌａｓｓｅｓを選択するか、それらのクラスを右クリックして、ポップアップ・メニューからＲｏｕｎｄｔｒｉｐを選択する。

現在のコード・ビューでコードを強制的にラウンドトリップするには、Ｃｏｄｅ ＞ Ｆｏｒｃｅ Ｒｏｕｎｄｔｒｉｐ ＞ Ｆｏｃｕｓｅｄ Ｖｉｅｗｓを選択する。

ラプソディ（Ｒｈａｐｓｏｄｙ）からの応答として、ラウンドトリップしたすべてのクラスについて、「Ｒｏｕｎｄｔｒｉｐｐｉｎｇ ｃｌａｓｓ ｘ」という形式のメッセージがリストアップされる。コードが生成されていないクラス（または実装ファイルが消去されたクラス）をラウンドトリップしようとすると、ラプソディ（Ｒｈａｐｓｏｄｙ）からの応答として、しかるべきエラー・メッセージが返され、そのクラスは変更されないことに注意されたい。

ラウンドトリップのためにコード・セグメントを変更する
ステートチャートで操作およびアクションとして入力された手続き的な振る舞いであるラウンドトリップのために、コード・セグメントを変更することができる。

実装コード内のセグメントはすべて、次のフォーマットを有する。
... generated code
//#[ セグメント型 セグメント識別子
C++ code you entered
//#]
... generated code continues
これらのコード・セグメントはすべて、実装ファイル内にある。

ラウンドトリップが可能なままで変更できるセグメントは、以下のものだけである。
・静的リアクション
//#[ リアクション リアクションＩＤ
// このコードは修正可能
someReactionCode();
// ／／＃］ 記号の先は修正しない
//#]
・出口アクション
//#[ exitAction ROOT.idle.(入力)
someExitAction();
//#]
・入口アクション
//#[ entryAction ROOT.idle.(入力)
someEntryAction();
//#]
・遷移アクション
//#[ 遷移 遷移ＩＤ
someTransitionCode();
//#]
プリミティブ操作（手続き的な振る舞い）
//#[ operation doit()
someOperationCode();
someMoreOperationCode();
//#]

失われたラウンドトリップ注釈を復元する
ラプソディ（Ｒｈａｐｓｏｄｙ）では、コードをラウンドトリップするために、コード・ジェネレータが実装ファイルに挿入した特別な注釈を使用する。これらの注釈には、プレフィックス「／／＃」が含まれる。これらの注釈を編集または削除すると、ラプソディ（Ｒｈａｐｓｏｄｙ）はコードをトレースしてモデルに反映することができない。

損なわれたラウンドトリップ注釈を復元するには、以下を行う。
１．損なわれたファイルの名前を変更する。
２．このクラスのコードを再生成する。これにより、正しい注釈を有する新しいファイルが生成される。
３．損なわれたファイルから、新しく生成されたファイルに変更内容をコピーする。
４．ラウンドトリップを再試行する。

いずれかのファイルを変更すると、次のメッセージが表示される。
ファイル＜ファイル名＞が外部から変更されています。ラウンドトリップしますか？
ファイルの内容を変更した場合は、ラウンドトリップにより、修正内容をモデルに加えなければならない。Ｙｅｓを選択すると、ラウンドトリップが確定される。モデルが更新され、生成されたコードは、手動の変更内容を反映したものになる。

Ｎｏを選択すると、変更したファイルが上書きされ、変更内容が失われる。

サポートされる要素
一般に、ラウンドトリップできるコンポーネントは以下のとおりである。
・クラスおよびクラスの集約（テンプレート・クラス、型、ネストされたクラス）
・クラス要素（属性、プリミティブ操作の本体、引数、型）
・クラス・メンバ関数（名前、戻り型、引数）
・グローバル要素（関数、変数、型、テンプレート関数）
・パッケージ
・遷移ラベル上に配置されたアクション
・状態内部に配置されたアクション：入口に、出口に、または静的リアクションとして）
・注釈内のコード
・あらかじめコンパイルされた命令、＃ｄｅｆｉｎｅ
依存、継承、ステレオタイプ、状態、遷移、あらかじめコンパイルされた命令（＃ｐｒａｇｍａ、マクロ）、ファイルのヘッダ情報及びフッタ情報、およびファイル・マッピングに対して行われた変更については、ラウンドトリップがサポートされない。また、ラプソディ（Ｒｈａｐｓｏｄｙ）識別子でサポートされていないデータ（たとえば、可変データや揮発性データ）に対して行われた変更についてもサポートされない。

注記：ラプソディ（Ｒｈａｐｓｏｄｙ）には、ラウンドトリップによるモデルの変更を制限または制御するプロパティがある。「ラウンドトリップ・プロパティ」の項を参照されたい。

Ｒｈａｐｓｏｄｙ ｉｎ Ｃ＋＋／Ｊでは、Ｒｈａｐｓｏｄｙ ｉｎ Ｃより多くのラウンドトリップ機能を提供している。それらはプロパティによって制御される。

この後のセクションでは、Ｒｈａｐｓｏｄｙ ｉｎ Ｃ＋＋でラウンドトリップできる、クラスおよびパッケージへの変更について説明する。現時点でＲｈａｐｓｏｄｙ ｉｎ ＪおよびＲｈａｐｓｏｄｙ ｉｎ Ｃがサポートしているのは、この機能のサブセットだけである。

クラスをラウンドトリップする
次の表は、クラス実装ファイルでの、ラウンドトリップが可能な変更のリストである。

アクションはコード中に複数回現れる場合があることに注意されたい。ラプソディ（Ｒｈａｐｓｏｄｙ）は、そのアクション・コードの最初のオカレンス（発生セグメント）をラウンドトリップする。２つ以上のオカレンス（発生セグメント）を変更した場合は、最初に変更したオカレンスがラウンドトリップされる。１つの手法は、状態、状態アクション、および遷移アクションにおいて操作を呼び出すことである。それによって、アクション・コードの重複や、ラウンドトリップがあいまいになる可能性を排除できる。

次の表は、クラス仕様ファイルでの、ラウンドトリップが可能な変更のリストである。

パッケージをラウンドトリップする
ラプソディ（Ｒｈａｐｓｏｄｙ）は、パッケージ実装ファイル内の関数の引数名の変更をラウンドトリップする。ただし、引数型の変更はラウンドトリップされない。この名前を変更すると、この引数の記述が失われる。

ラプソディ（Ｒｈａｐｓｏｄｙ）は、変数の初期値の変更をラウンドトリップしない。

次の表は、パッケージ仕様ファイルでの、ラウンドトリップが可能な変更のリストである。

ＤＭＣＡが有効の状態で、関数、変数、またはインスタンスを削除するには、以下を行う。
１．．ｈファイルまたは．ｃｐｐファイルからその要素を削除する。
２．＜Ｓｈｉｆｔ＞キーを押したまま、フォーカスを．ｃｐｐファイルまたは．ｈファイルに切り替える。
３．２番目のファイルから要素を削除する。

＜Ｓｈｉｆｔ＞キーを押したままにすることで、２番目のファイルを変更し終えるまでＤＭＣＡの発効が抑えられる。

ＤＭＣＡをＮｏｎｅに設定した状態で、関数、変数、またはインスタンスを削除するには、以下を行う。
１．．ｈファイルまたは．ｃｐｐファイルからその要素を削除し、このファイルを保存する。
２．．ｃｐｐファイルまたは．ｈファイルからその要素を削除し、このファイルを保存する。

ラウンドトリップ・プロパティ
ラプソディ（Ｒｈａｐｓｏｄｙ）は、ラウンドトリップを制御するプロパティを多数含む。それらは、＜ｌａｎｇ＞＿Ｒｏｕｎｄｔｒｉｐで指定される（＜ｌａｎｇ＞はプログラミング言語）。
たとえば、Ｒｈａｐｓｏｄｙ ｉｎ Ｃでは、これらのプロパティはＣ＿Ｒｏｕｎｄｔｒｉｐにある。Ｒｈａｐｓｏｄｙ ｉｎ Ｃ＋＋では、ＣＰＰ＿Ｒｏｕｎｄｔｒｉｐにある。

これらのプロパティの詳細については、「プロパティ参照ガイド（Ｐｒｏｐｅｒｔｉｅｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）」を参照されたい。

次の表は、ラウンドトリップを制御するプロパティのリストである。

重複したコード・ファイルを削除する
以下の理由でファイルが重複する場合がある。
・ファイルにマッピングされた要素が削除されたか、名前変更された。
・コンポーネントの範囲内で変更が行われた。
・ファイルへの要素のマッピングが変更された。

変更はコンポーネント・レベルの要素（コンポーネント、コンフィグレーション、フォルダ、およびファイル）で行われる。

重複したソース・ファイルをアクティブ・コンフィグレーションから削除するには、Ｃｏｄｅ ＞ Ｃｌｅａｎ Ｒｅｄｕｎｄａｎｔ Ｓｏｕｒｃｅ Ｆｉｌｅｓを選択する。

アクタのコードを生成する
コンフィグレーションの作成のときに、アクタのコードを生成するよう選択できる（第１２章の「コンフィグレーションの機能の定義（Ｄｅｆｉｎｉｎｇ Ｆｅａｔｕｒｅｓ ｏｆ ａ Ｃｏｎｆｉｇｕｒａｔｉｏｎ）」の項を参照されたい）。アクタのコードを生成するようアクティブ・コンフィグレーションを設定すると、ラプソディ（Ｒｈａｐｓｏｄｙ）がアクタ・コードを、システムの他の部分と同じライブラリまたは実行可能ファイルに生成、コンパイル、およびリンクする。これにより、システム・テストの間じゅうアクタを使用して、システムに対する入力および応答をシミュレートできるようになる。

アクタについて生成されたコードにはいくつかの制限がある。これについては、「制限」の項を参照されたい。

コンポーネント内でアクタを選択する
クラスには、ラプソディ（Ｒｈａｐｓｏｄｙ）がアクタとクラスとの間の関係および依存についてコードを生成すべきかどうかを決定するコード生成プロパティがある。

コンポーネント内でのアクタのコード生成を選択するには、以下を行う。
１．ブラウザでそのコンポーネントを右クリックし、ポップアップ・メニューからＦｅａｔｕｒｅｓを選択する。
２．Ｉｎｉｔｉａｌｉｚａｔｉｏｎタブを選択する。
３．Ｉｎｉｔｉａｌ Ｉｎｓｔａｎｃｅｓで、そのコンポーネントに関与させるアクタを選択する。
４．Ｇｅｎｅｒａｔｅ Ｃｏｄｅ ｆｏｒ Ａｃｔｏｒｓが選択されていることを確認する。

Ｇｅｎｅｒａｔｅ Ｃｏｄｅ ｆｏｒ Ａｃｔｏｒｓは、デフォルトでは選択されているが、下位互換性を確保するためにバージョン３．０より古いモデルをロードすると選択解除される。

デフォルトでは、アクタが生成された場合のみ、アクタとクラスとの間の関係が生成される。この点は、ＣＧ：：Ｒｅｌａｔｉｏｎの下のＧｅｎｅｒａｔｅＲｅｌａｔｉｏｎＷｉｔｈＡｃｔｏｒｓプロパティにより、クラス内で微調整できる。詳細については、「プロパティ参照ガイド（Ｐｒｏｐｅｒｔｉｅｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）」を参照されたい。

制限
アクタの作成方法にはいくつかの制限があり、これがコード生成に影響を及ぼす。その制限は以下のとおりである。
・ＯＭＤ上では、アクタをコンポジットとして指定できない。したがって、ラプソディ（Ｒｈａｐｓｏｄｙ）は、そのコンポーネント間の関係を初期設定するコードを生成しない。
・アクタのベースは別のアクタでなければならない。クラスのベースは別のクラスでなければならない。
・アクタは、ネストされたアクタだけを埋め込むことができる。クラスは、ネストされたクラスだけを埋め込むことができる。
・アクタの名前は、クラス名のコード標準に適合していなくてもよい。ただし、アクタ名が不正な場合（すなわち、コンパイル可能な名前でない場合）は、コード生成の際にエラーが生成される。

コンポーネント図のコードを生成する
コンポーネント図には、以下のコード生成セマンティクス（意味論）が適用される。
・コード生成は、ライブラリ・ビルド・タイプおよび実行可能ビルド・タイプのコンポーネントに対して行われる。
・コード生成は、フォルダ・コンポーネントおよびファイル・コンポーネントに関連するメタタイプに対して行われる。
・コードは、バイナリ・コンポーネント（ライブラリおよび実行可能ファイル）間の関係に関してのみ生成される。
・コンポーネント図の以下の部分はコード生成を行わない。

−ファイルおよびフォルダが関与する関係
−コンポーネントによって実現されるインターフェース
−ステレオタイプ化された＜＜Ｌｉｂｒａｒｙ＞＞または＜＜Ｅｘｅｃｕｔａｂｌｅ＞＞ではない、他のすべてのコンポーネント・タイプ
・コンポーネント間の依存は、以下の規制および制限の下で、＜＜Ｕｓａｇｅ＞＞ステレオタイプを有する場合のみコードを生成する。

−関連コンポーネントは同名のコンフィグレーションを有していなければならない。

−２つの関連コンポーネントが同じ要素をマッピングする場合、コード生成では、最初にチェックされた関連コンポーネントを用いる。

−（単一バイナリ・コンポーネントの範囲内で）要素が一意にマッピングされている場合、その要素のファイル名はそのコンポーネントからとられる。

−要素が、生成されたコンポーネント（関連コンポーネント）の範囲内で見つからないか、他の何らかのコンポーネントに一意にマッピングされている場合は、要素のファイル名が合成される。

名前の合成を無効にするには、（ＣＧ：：Ｃｏｍｐｏｎｅｎｔの下の）ＵｓｅＤｅｆａｕｌｔＮａｍｅＦｏｒＵｎｍａｐｐｅｄＥｌｅｍｅｎｔｓプロパティをＦａｌｓｅに設定する。

（ＣＧ：：Ｃｏｍｐｏｎｅｎｔの下の）ＣｏｍｐｏｎｅｎｔｓＳｅａｒｃｈＰａｔｈプロパティは、関連コンポーネントの名前を指定する（ただし、このプロパティの前に依存がチェックされる）。たとえば、コンポーネントＡからコンポーネントＢへの依存は、ＣｏｍｐｏｎｅｎｔｓＳｅａｒｃｈＰａｔｈプロパティ内に「Ｂ」を置くことと等価である（ただし、名前変更の復元に関しては明らかな優位性がある）。

次の図の中に示した図を考える。

クラスＣ１およびＣ２は互いに関係（関連）がある。このモデルには２つのコンポーネント（ｃｏｍｐｏｎｅｎｔ＿１およびｃｏｍｐｏｎｅｎｔ＿２）があり、それぞれが同名のコンフィグレーションを有する。Ｃｏｍｐｏｎｅｎｔ＿１は、ステレオタイプ＜＜Ｕｓａｇｅ＞＞により、ｃｏｍｐｏｎｅｎｔ＿２に依存している。クラスＣ１は、ｃｏｍｐｏｎｅｎｔ＿１の範囲内にある。

クラスＣ２は、ｃｏｍｐｏｎｅｎｔ＿１の範囲内にないが、ｃｏｍｐｏｎｅｎｔ＿２内のファイルＦ１にマッピングされる。

このステレオタイプが適用された場合、これは以下のコード生成セマンティクス（意味論）を反映する。
・関連コンポーネント内で要素のファイル名を探す（要素が現在のコンポーネントの範囲内にない場合）。

たとえば、ｃｏｍｐｏｎｅｎｔ＿１の生成のときに、Ｃ２を含める必要があれば、Ｆ１（ｃｏｍｐｏｎｅｎｔ＿２内のファイル）を含める。
・関連コンポーネントをメイクファイルのインクルード・パスに追加する。たとえば、ｃｏｍｐｏｎｅｎｔ＿１メイクファイル内で、ｃｏｍｐｏｎｅｎｔ＿２の場所を含むインクルード・パスに対して新しい行が追加される。
・現在のコンポーネントのビルド・タイプが実行可能ファイルであり、関連コンポーネントのビルド・タイプがライブラリの場合は、現在のコンポーネントのビルドにライブラリを追加する。たとえば、ｃｏｍｐｏｎｅｎｔ＿１のビルド・タイプが実行可能ファイルであり、ｃｏｍｐｏｎｅｎｔ＿２のビルド・タイプがライブラリであれば、ｃｏｍｐｏｎｅｎｔ＿１メイクファイルは、ｃｏｍｐｏｎｅｎｔ＿２のライブラリをそのビルドに含める。

クロスパッケージの初期設定
ラプソディ（Ｒｈａｐｓｏｄｙ）の、いくつかのプロパティでは、パッケージ・インスタンスの初期設定後で、かつ、これらのインスタンスがイベントに反応する前に、パッケージ関係を初期設定するコードを指定することができる。より一般的に言うと、これらのプロパティにより、モデル内のパッケージごとに、他の任意の初期設定コードを特定することができる。それらのプロパティにより、パッケージ関係に関与している任意のパッケージや、パッケージ関係に関与していないパッケージによるクロスパッケージ関係を初期設定することができる。

パッケージ初期設定コードを制御するプロパティは以下のとおりである。
・ＣＧ：：Ｐａｃｋａｇｅ：：ＡｄｄｉｔｉｏｎａｌＩｎｉｔｉａｌｉｚａｔｉｏｎＣｏｄｅ−パッケージｉｎｉｔＲｅｌａｔｉｏｎｓ（）メソッドの実行後に実行する追加的初期設定コードを指定する。
・ＣＧ：：Ｃｏｍｐｏｎｅｎｔ：：ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｃｈｅｍｅ−初期設定を行うレベルを指定する。とりうる値は以下のとおりである。

−ＢｙＰａｃｋａｇｅ−各パッケージが自身の初期設定の役割を担う。コンポーネントは、各パッケージ・クラスの属性を宣言するだけでよい。これは、デフォルトのオプションであり、Ｖ３．０より古いラプソディ（Ｒｈａｐｓｏｄｙ）モデルとの下位互換性がある。

−ＢｙＣｏｍｐｏｎｅｎｔ−コンポーネントが、そのすべてのパッケージで宣言されているすべてのグローバル関係を初期設定しなければならない。これは、各パッケージのｉｎｉｔＲｅｌａｔｉｏｎｓ（）、追加初期設定、およびｓｔａｒｔＢｅｈａｖｉｏｒ（）に対するコンポーネント・クラス・コンストラクタにおける明示的な呼び出しによって行われなければならない。

以下は、ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｃｈｅｍｅプロパティがＢｙＰａｃｋａｇｅに設定されている場合に、上記の図のモデルから生成されたＣ＋＋コードの例である。

コンポーネント・コードは以下のとおりである。
class DefaultComponent {
private:
P1_OMInitializer
initializer_P1;
P2_OMInitializer
initializer_P2;
};
Ｐ１パッケージ・コードは以下のとおりである。
P1_OMInitializer::P1_OMInitializer() {
P1_initRelations();

< P1 AdditionalInitializationCode value>
P1_startBehavior();
}
以下は、ＩｎｉｔｉａｌｉｚａｔｉｏｎＳｃｈｅｍｅプロパティがＢｙＣｏｍｐｏｎｅｎｔに設定されている場合に生成されたＣ＋＋コンポーネント・コードの例である。
DefaultComponent::DefaultComponent() {
P1_initRelations();
P2_initRelations();

< P1 AdditionalInitializationCode value>

< P2 AdditionalInitializationCode value>
P1_startBehavior();
P2_startBehavior();
}

クラス・コード構造
このセクションでは、モデルがどのようにコードにマッピングされるか、およびモデル・マッピングをどのように制御できるかを含め、生成されたコードの構造について説明する。生成されたソース・コードは、モデル要素のほかに、注釈と、インストルメンテーション・マクロ（装備されている場合）を含む。

注記：注釈は、コード・コンストラクトを設計コンストラクトにマッピングする。注釈は、両者間のトレースに重要な役割を果たす。注釈を改変したり、削除したりしてはならない。それを行うと、モデルとコードとの間のトレースを妨げることになる。注釈は、２つのスラッシュとシャープ記号（／／＃）で始まるコメント行である。

インストルメンテーション・マクロは、アニメーション／トレース・フレームワークをサービスするフックおよびユーティリティ関数になる。これらは、ソース・コードへの影響を最小限にするマクロとして実装される。インストルメンテーション・マクロを削除すると、アニメーションが正しく動作しない。

示すコード構造は汎用的なものであり、ｃｌａｓｓやｓｔａｔｅなどの一般的な名前を使用している。実際に使用するコードには、実際の名前を使用することになる。

クラス・ヘッダ・ファイル
クラス・ヘッダ・ファイルには以下のセクションが含まれる。
・プロローグ
・前方宣言
・インストルメンテーション
・仮想継承とプライベート継承
・ユーザ定義の属性および操作
・可変長引数並び（リスト）
・関係情報
・ステートチャート実装
・イベント・インターフェース
・シリアル化インストルメンテーション
・状態クラス

プロローグ
プロローグ・セクションは、フレームワーク・ファイルと、ヘッダ・ファイルまたはフッタ・ファイル（適用可能な場合）を含む。
＜ｌａｎｇ＞＿ＣＧ：：Ｃｌａｓｓ／Ｐａｃｋａｇｅ：：ＳｐｅｃＩｎｃｌｕｄｅｓプロパティを使用して新たなインクルード・ファイルを追加することができる。これは、ラプソディ（Ｒｈａｐｓｏｄｙ）設計に含まれないモジュールへの依存を作成するときに必要になる場合がある。
例：
#ifndef class_H
#define class_H
#include <oxf/oxf.h> // フレームワーク・ヘッダ・ファイル
//------------------------------------------------------
// class.h
//------------------------------------------------------

他のクラスとの関係
ヘッダ・ファイルのこのセクションは、すべての関連クラスに対する前方宣言を含む。これらは、モデル内で指定された、クラスと他のクラスとの関係に基づく。

例：
class forwarded-class1;
class forwarded-class2;

class class : public OMReactive {
// クラス定義、およびフレームワーク・クラスからの継承（必要な場合！）
//

インストルメンテーション
インストルメンテーションを用いてコンパイルした場合は、システムのランタイム状態に関する情報がインストルメンテーション・マクロからアニメーションにもたらされる。

例：
ＤＥＣＬＡＲＥ−ＭＥＴＡ ／／ クラスのインストルメンテーション

継承
仮想継承を用いると、サブクラスは、複数の継承を経て、共通アンセスタから１組のメンバだけを継承する。

仮想継承を用いるには、サブクラスのＶｉｒｔｕａｌＩｎｈｅｒｉｔｓプロパティを、そのサブクラスが仮想として継承する源であるスーパクラスの名前に設定する。複数のスーパクラス名はカンマで区切る。

たとえば、クラスＢがスーパクラスＡを有し、ＢのＶｉｒｔｕａｌＩｎｈｅｒｉｔｓプロパティが「Ａ」に設定されている場合は、Ｂについて以下の宣言が生成される。
ｃｌａｓｓ Ｂ ： ｖｉｒｔｕａｌ ｐｕｂｌｉｃ Ａ ｛．．．｝；
プライベート継承を用いると、サブクラスは、スーパクラスのパブリック・メンバだけを継承する。継承されたメンバは、サブクラス内でプライベートになる。

プライベート継承を用いるには、サブクラスのＰｒｉｖａｔｅＩｎｈｅｒｉｔｓプロパティを、そのサブクラスがプライベートとして継承する源であるスーパクラスの名前に設定する。複数のスーパクラス名はカンマで区切る。

たとえば、クラスＢがスーパクラスＡを有し、ＢのＰｒｉｖａｔｅＩｎｈｅｒｉｔｓプロパティが「Ａ」に設定されている場合は、Ｂについて以下の宣言が生成される。
ｃｌａｓｓ Ｂ ： ｐｒｉｖａｔｅ Ａ ｛．．．｝；

ユーザ定義の属性および操作
このセクションでは、すべての操作および属性データ・メンバが定義される。このセクションのコードは、クラスの操作および属性の直接変換である。これを制御するには、モデルに対して操作および属性を追加または削除する。

例：
//// ユーザの明示的なエントリ ////
public :
//## operation
op1() // 操作の注釈
void
op1();
// 操作の定義
protected :
// 属性：
//## attribute
attr1 // 属性の注釈
attrType1
attr1; // 属性の定義
//// ユーザの暗黙的なエントリ
////
public :
// コンストラクタとデストラクタ：
class(OMThread* thread =
theMainThread);
virtual〜class();
// 生成されたデストラクタ

可変長引数並び（リスト）
可変長引数並び（．．．）を、操作の最後の引数として追加するには、その操作のＰｒｏｐｅｒｔｉｅｓダイアログ・ボックスを開き、ＣＧ：：Ｏｐｅｒａｔｉｏｎ：：ＶａｒｉａｂｌｅＬｅｎｇｔｈＡｒｇｕｍｅｎｔＬｉｓｔプロパティをＴｒｕｅに設定する。

たとえば、操作ｖｏｉｄ ｆｏｏ（ｉｎｔ ｉ）についてＶａｒｉａｂｌｅＬｅｎｇｔｈＡｒｇｕｍｅｎｔＬｉｓｔプロパティがＴｒｕｅに設定されている場合は、ｆｏｏ（）について次の宣言が生成される。
ｖｏｉｄ ｆｏｏ（ｉｎｔ ｉ，．．．） ;

関係に関して合成された方法およびデータ・メンバ
ヘッダ・ファイルのこのセクションは、モデル内で定義されているクラスのすべての関係を含む。必要に応じて、データ・メンバや、関係を操作する１組のアクセッサ関数およびミューテータ関数を含む。

このセクションは、関係プロパティおよびコンテナ・プロパティを変更することによって制御できる。ＣＧプロパティの詳細については、「プロパティ参照ガイド（Ｐｒｏｐｅｒｔｉｅｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）」を参照されたい。

例：

OMIterator<rclass1*> getrelation1()const;
void
addrelation1(rclass* p);
void removerelation1(rclass*
p);
void clearrelation1();
protected :
//

OMCollection<rclass*> relation1;
attrType1
getattr1()const;
void
setattrType1(attrType1 p);

ステートチャート実装
ヘッダ・ファイルのこのセクションは、クラスのステートチャート動作のデータ・メンバおよび関数定義を含む。このセクションの内容は、ステートチャートの実装ストラテジによって異なる。このセクションは、以下のいずれかの方法で制御できる。
・ステートチャート実装ストラテジを再利用可能からフラットに変更する。
・ステートチャートのコード生成を無効にする。

例：
//// フレームワーク・エントリ
////
public :
State*
state1; //状態変数

State* state2;
void
rootStateEntDef(); //初期遷移メソッド
//
int
state1Takeevent1(); //イベント・テイカ
int state2Takeevent2();
private :
void
initRelations(); //フレームワーク・メンバを初期設定

//するためにＩｎｉｔＲｅｌａｔｉｏｎｓ

//またはＩｎｉｔＳｔａｔｅｃｈａｒｔ

//が生成される。
void
cleanUpRelations(); //破壊されたフレームワーク・メンバを

//クリーンアップするために

//ＣｌｅａｎｕｐＲｅｌａｔｉｏｎｓまたは

//ＣｌｅａｎｕｐＳｔａｔｅｃｈａｒｔが

//生成される。

注記：ｉｎｉｔＲｅｌａｔｉｏｎｓ（）操作およびｃｌｅａｎＵｐＲｅｌａｔｉｏｎｓ（）操作は、プロパティＣＧ：Ｃｌａｓｓ：ＩｎｉｔＣｌｅａｎＵｐＲｅｌａｔｉｏｎｓがｔｒｕｅに設定されている場合のみ生成される。詳細については、「プロパティ参照ガイド（Ｐｒｏｐｅｒｔｉｅｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）」を参照されたい。

イベント・インターフェース
コードのこのセクションは、クラスで消費されたイベントを示す。これはドキュメンテーション専用である。イベントはすべて、ＯＭＲｅａｃｔｉｖｅにある共通インターフェースを介して処理されるからである。このセクションは、イベント処理を自力で実装したい場合に有用である。

例：
//// 消費されたイベント
////
public :
// イベント群：
// event1
// event2
コード生成がイベント内の配列タイプをサポートすることに注意されたい。次のＧＥＮ（）を作成することが可能である。

Ｃｌｉｅｎｔ−＞ＧＥＮ（Ｅ（“Ｈｅｌｌｏ ｗｏｒｌｄ ！”））；
この呼び出しにおいて、Ｅは次のように定義される。
class E : public OMEvent {
Char message[13];
};

シリアル化インストルメンテーション
インストルメンテーションを含めると、次のインストルメンテーション・マクロがヘッダ・ファイルに含まれる。
DECLARE_META_EVENT
};
これは、アニメーションのシリアル化サービスを実装するメソッド定義まで拡張される。

状態クラス
この状態は、クラスのステートチャートを構成する状態クラスを定義する。状態クラスは、再利用可能な状態実装ストラテジで生成される。

例：
class state1 : public ComponentState {
public :
// 状態クラス実装
};
class state2 : public Orstate {
public :
// 状態クラス実装
};
#endif
フラットな実装ストラテジを選択することによって状態クラスを排除できる。この場合、状態は列挙型としてマニフェストされる。

実装ファイル
クラス実装ファイルは、仕様ファイルで定義されたメソッドの実装を含む。さらに、クラス実装ファイルは、インストルメンテーション・マクロ及び注釈を含む。前述したとおり、インストルメンテーション・マクロと注釈のいずれかを排除または変更すると、モデルとコードとの間のトレースおよび機能性を妨げる可能性がある。

ヘッダとフッタ
生成されたファイルに対し、独自のヘッダおよびフッタを定義できる。詳細については、「プロパティ参照ガイド（Ｐｒｏｐｅｒｔｉｅｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）」を参照されたい。

プロローグ
実装ファイルのプロローグ・セクションは、すべての関連クラスのヘッダ・ファイルを含む。Ｃ＿およびＣＰＰ：：Ｃｌａｓｓ／Ｐａｃｋａｇｅ：：ＩｍｐＩｎｃｌｕｄｅｓプロパティを用いて、新たな＃ｉｎｃｌｕｄｅファイルを追加できる。このプロパティの詳細については、「プロパティ参照ガイド（Ｐｒｏｐｅｒｔｉｅｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）」を参照されたい。

コードのセクションを＃ｉｆｄｅｆ ＃ｅｎｄｉｆ命令でラップし、コンパイラ固有のキーワードを追加し、プロローグ・プロパティとエピローグ・プロパティとを用いて＃ｐｒａｇｍａ命令を追加することができる。詳細については、「＃ｉｆｄｅｆ−＃ｅｎｄｉｆでコードをラップする」を参照されたい。

以下のコードは、プロローグ・セクションのサンプルである。
//## package package
//## class class
#include "class.h"
#include <package.h>
#include <rclass1.h>
#include <rclass2.h>
//-------------------------------------------------------
//class.cpp
//-------------------------------------------------------
DECLARE_META_PACKAGE(Default)
#define op1_SERIALIZE

コンストラクタとデストラクタ
各クラスに対し、デフォルトのコンストラクタとデストラクタが生成される。新たなコンストラクタ（群）を明示的に指定したり、新たなコンストラクタ（群）をモデルに明示的に追加してデフォルトのコンストラクタまたはデストラクタを無効にしたりできる。

例：
class::class(OMThread* thread) {

NOTIFY_CONSTRUCTOR(class, class(), 0,

class_SERIALIZE);
setThread(thread);
initRelations();
};
状態を定義する場合は、ｉｎｉｔＲｅｌａｔｉｏｎｓの代わりにｉｎｉｔＳｔａｔｅｃｈａｒｔを用いる。
class::〜class() {
NOTIFY_DESTRUCTOR(〜class);
cleanUpRelations();
};
同様に、状態を定義する場合は、ｃｌｅａｎＵｐＲｅｌａｔｉｏｎｓの代わりにｃｌｅａｎＵｐＳｔａｔｅｃｈａｒｔを用いる。

操作
以下のコード・パターンは、すべてのプリミティブ（ユーザ定義）操作に対して作成される。
void class::op1() {
NOTIFY_OPERATION(op1,
op1(), 0, op1_SERIALIZE);

//インストルメンテーション
//#[ operation
op1() // 入力した、操作の注釈本体

//
//#]
};

属性および関係に対するアクセッサとミューテータ
アクセッサとミューテータは、クラスの各属性および関係に対して自動的に生成される。それらの内容および生成は、関係プロパティと属性プロパティを設定することによって制御できる。

例：
attr1Type class::getattr1()const {
return attr1;
};
void class::setattr1(attr1type p) {
attr1 = p;
};
OMIteratorrclass*
class::getItsrclass()const {
OMIteratorrclass*
iter(itsrclass);
return iter;
};
void Referee::_addItsRclass(Class* p_Class)
{
NOTIFY_RELATION_ITEM
ADDED("itsRClass",p_Class,
FALSE, FALSE);

itsRclass->add(p_Class);
};
void class::removeItsrclass(rclass* p) {

NOTIFY_RELATION_ITEM_REMOVED();
rclass.remove(p);
};
void class::clearItsPing() {
};

インストルメンテーション
このセクションは、アニメーションで使用されるインストルメンテーション・マクロとシリアル化ルーチンを含む。

例：
void class::serializeAttributes()const {
// 属性をシリアル化する
};
void class::serializeRelations()const {
// 関係をシリアル化する
};
IMPLEMENT_META(class, FALSE)
IMPLEMENT_GET_CONCEPT(state)

状態イベント・テイカ
これらのメソッドは、状態、イベント、および遷移の動作を実装する。これらは、ステートチャートに基づいて合成される。クラスのＣＧ：：Ａｔｔｒｉｂｕｔｅ／Ｅｖｅｎｔ／Ｆｉｌｅ／Ｇｅｎｅｒａｌｉｚａｔｉｏｎ／Ｏｐｅｒａｔｉｏｎ／Ｒｅｌａｔｉｏｎ：：Ｇｅｎｅｒａｔｅプロパティをｆａｌｓｅに設定すると、それらは生成されない。

例：
int class::state1Takeevent1() {
int res = eventNotConsumed;
SETPARAMS(hungry);

NOTIFY_TRANSITION_STARTED("2");
Transition code

NOTIFY_TRANSITION_TERMINATED("2");
res = eventConsumed;
return res;
}；

初期設定とクリーンアップ
これらのメソッドは、フレームワーク関連の初期設定およびクリーンアップを実装する。

例：
void class::initRelations() {
state1 = new
state1Class(); //状態を作成する
};
void class::cleanUpRelations() {
};

状態クラスの実装
このセクションは、各状態オブジェクトのディスパッチ・メソッドとコンストラクタを実装する。これは、状態クラスを生成しない、フラットな実装ストラテジを選択することによって変更できる。

例：
class_state1::class_state1(class* c, State*
p,
State* cmp) :
LeafState(p, cmp) {
// 状態コンストラクタ
};
int class_state1::takeEvent(short id)
{
int res =
eventNotConsumed;
switch(id) {

case event1_id: {

res = concept->state1Takeevent1();

// 遷移メソッドのディスパッチ

break;

};
};
};

＃ｉｆｄｅｆ−＃ｅｎｄｉｆでコードをラップする
操作を＃ｉｆｄｅｆと＃ｅｎｄｉｆのペアでラップするか、コンパイラ固有のキーワードを追加するか、＃ｐｒａｇｍａ命令を追加する必要がある場合は、その操作のＳｐｅｃｉｆｉｃａｔｉｏｎＰｒｏｌｏｇ、ＳｐｅｃｉｆｉｃａｔｉｏｎＥｐｉｌｏｇ、ＩｍｐｌｅｍｅｎｔａｔｉｏｎＰｒｏｌｏｇ、ＩｍｐｌｅｍｅｎｔａｔｉｏｎＥｐｉｌｏｇの各プロパティを設定できる。

たとえば、コードが＿ＤＥＢＵＧでコンパイルされた場合のみ操作が可能であるよう指定するには、以下を行う。
・ＳｐｅｃｉｆｉｃａｔｉｏｎＰｒｏｌｏｇを＃ｉｆｄｅｆ ＿ＤＥＢＵＧに設定する。
・ＳｐｅｃｉｆｉｃａｔｉｏｎＥｐｉｌｏｇを＃ｅｎｄｉｆに設定する。
・ＩｍｐｌｅｍｅｎｔａｔｉｏｎＰｒｏｌｏｇを＃ｉｆｄｅｆ ＿ＤＥＢＵＧに設定する。
・ＩｍｐｌｅｍｅｎｔａｔｉｏｎＥｐｉｌｏｇを＃ｅｎｄｉｆに設定する。

コンフィグレーション、パッケージ、クラス、および属性についても、同じプロパティが使用可能である。

注記：ラプソディ（Ｒｈａｐｓｏｄｙ）では、後続の新規行が暗黙のうちに追加されることがない。このため、同じ行にプロローグとエピローグを追加できる。プロローグとエピローグが異なる行にあるようにするには、Ｅｎｔｅｒキーを押す。

演算子をオーバーロードする
ラプソディ（Ｒｈａｐｓｏｄｙ）で作成されたクラスに対する演算子をオーバーロードできる。たとえば、Ｓｔａｃｋクラスに対しては、「＋」演算子を、自動的にｐｕｓｈ（）操作を実行するようにオーバーロードでき、「−」演算子を、自動的にｐｏｐ（）操作を実行するようにオーバーロードできる。

ストリーム出力演算子ｏｐｅｒａｔｏｒ＜＜を除き、オーバーロードされた演算子（演算子（ｏｐｅｒａｔｏｒ）＋や演算子（ｏｐｅｒａｔｏｒ）−など）はすべて、メンバ関数としてモデル化できる（ストリーム出力演算子は、メンバ関数ではなくグローバル関数であり、フレンド関数として宣言されなければならない）。クラス・メンバであるオーバーロードされた演算子はすべて、プリミティブ操作として定義される。

演算子のオーバーロードを例示するために、２つのクラスＣｏｍｐｌｅｘおよびＭａｉｎＣｌａｓｓを以下のように定義する。

クラスＣｏｍｐｌｅｘ
Attributes:
double imag;
double real;
Operations:

Complex()
//単純なコンストラクタ
Body:
{

real = imag = 0. 0;
}
Complex(const
Complex& c) //コピー・コンストラクタ
Arguments:const
Complex& c
Body:
{

real = c.real;

imag = c.imag;
}
Complex(double r, double
i) //変換コンストラクタ
Arguments: double
r

double i = 0.0
Body:
{
real = r;
imag = i;
}
operator-(Complex
c) //減算
Return type: Complex
Arguments: Complex c
Body:
{

return Complex(real -c.real, imag - c.imag);
}
operator[](int
index) //配列サブスクリプト
Return type:
Complex&
Arguments: int
index //ダミー演算子（インストル

//メンテーション・チェック

//専用）
Body:
{

return *this;
}
operator+ (Complex&
c) // 値の追加
Return type: Complex
Arguments: Complex&
c
Body:
{

return Complex(real + c.real,imag + c.imag);
}
operator+(Complex*
c) // 参照の追加
Return type: Complex*
Arguments: Complex *c
Body:
{

cGlobal = new Complex (real + c->real,

imag + c->imag);

return cGlobal;
}

operator++()
// プレフィックスのインクリメント
Return type:
Complex&
Body:
{

real += 1.0;

imag += 1.0;

return *this;
}
operator=(Complex&
c) // 値の代入
Return type:
Complex&
Arguments: Complex&
c
Body:
{

real = c.real,

imag = c.imag;

return *this;
}
operator=(Complex*
c) // 参照の代入
Return type: Complex*
Arguments: Complex *c
Body:
{

real = c->real;

imag = c->imag;

return this;
}
以下、これらのオーバーロードされた演算子の生成されたコードの例をいくつか示す。

これは、オーバーロードされたプレフィックス・インクリメント演算子の生成されたコードである。
Complex& Complex::operator++() {
NOTIFY_OPERATION(operator++,
operator++(), 0,

operator_SERIALIZE);
//#[ operation
operator++()
real += 1.0;
imag += 1.0;
return *this;
//#]
};
これは、オーバーロードされた＋演算子の生成されたコードである。
Complex Complex::operator+(Complex& c)
{
NOTIFY_OPERATION(operator+,
operator+(Complex&), 1,

OM_operator_1_SERIALIZE);
//#[ operation
operator+(Complex&)
return Complex(real +
c.real, imag + c.imag);
//#]
};
これは、最初のオーバーロードされた代入演算子の生成されたコードである。
Complex&
Complex::operator=(Complex& c) {

NOTIFY_OPERATION(operator=, operator=(Complex&), 1,

OM_operator_2_SERIALIZE);
//#[ operation
operator=(Complex&)
real = c.real;
imag = c.imag;
return *this;
//#]
};
ブラウザには、３つのＣｏｍｐｌｅｘクラスをインスタンス化するコンポジットであるＭａｉｎＣｌａｓｓがリストされる。

その属性は以下のとおりである。
Complex* c1
Complex* c2
Complex* c3
その操作は以下のとおりである。
〜MainClass()
// デストラクタ
Body
{
delete c1;
delete c2;
delete c3;
}
e()
// イベント
ストリーム出力演算子＜＜は、これを用いようとするクラスに対するフレンドとして宣言されなければならないグローバル関数である。これは以下のように定義される。
operator<<
Return type: ostream&
Arguments: ostream& s

Complex& c
Body:
{
s << "real
part = " "<< c.real<<

"imagine part = " << c.imag << "＼n" <<
flush;
return s;
}
種々のコンストラクタおよびオーバーロードされた演算子を、それらが呼び出されるときに監視するには、以下を行う。
１．Ｃｏｄｅ ＞ Ｓｅｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ ＞ Ｅｄｉｔ ＞ Ｓｅｔｔｉｎｇ ｔａｂを選択して、プロジェクトにアニメーション・インストルメンテーションを割り当てる。
２．ＤｅｆａｕｌｔＣｏｎｆｉｇ．ｅｘｅを作って実行する。
３．アニメータを用いて、ＭａｉｎＣｌａｓｓとインスタンスＣｏｍｐｌｅｘ ［０］：Ｃｏｍｐｌｅｘ、Ｃｏｍｐｌｅｘ ［１］：Ｃｏｍｐｌｅｘ、およびＣｏｍｐｌｅｘ ［２］：Ｃｏｍｐｌｅｘを含む、アニメートされたシーケンス図（ＡＳＤ）を作成する。
４．ＡｎｉｍａｔｉｏｎバーのＧｏをクリックして、ＭａｉｎＣｌａｓｓとそのパート・インスタンスとの間で渡される、コンストラクタおよびオーバーロードされた演算子のメッセージを監視する。

ＡＳＤは次の図のように表示される。

匿名インスタンスを使用する
ラプソディ（Ｒｈａｐｓｏｄｙ）では、ユーザが自分で管理する匿名インスタンスを作成したり、コンポジット・フレームワークで管理されるコンポジット・インスタンスのコンポーネントとしてインスタンスを作成したりできる。

匿名インスタンスを作成する
匿名インスタンスを作成し、従来の任意のＣ＋＋プログラムと同様に、Ｃ＋＋の新しい演算子を適用することができる。ラプソディ（Ｒｈａｐｓｏｄｙ）は、システム内のすべてのクラスについて、デフォルトのコンストラクタ（ｃｔｏｒ）を生成する。ユーザは、ブラウザを用いて、新たなコンストラクタを追加できる。

たとえば、デフォルトのコンストラクタを用いてクラスＡの新しいインスタンスを作成するには、次のコードを入力する。
Ａ ＊ａ ＝ ｎｅｗ Ａ（）；
リアクティブ・クラスおよびコンポジット・クラスの場合、デフォルトのコンストラクタは、デフォルトでシステムのメイン・スレッドに設定されるスレッド・パラメータをとる。インスタンスを、システムのメイン・スレッドではなく特定のスレッドに関連付けるには、このパラメータを明示的にコンストラクタに渡す必要がある。

次の例は、クラスＡのインスタンスを作成し、これをスレッドＴに割り当てるものである。
Ａ ＊ａ ＝ ｎｅｗ Ａ（Ｔ）；
新しいインスタンスを作成したら、通常は、その関係ミューテータを呼び出して、それをそのピアに接続することになる（「関係を使用する」の項を参照されたい）。クラスがリアクティブであれば、通常は、そのｓｔａｒｔＢｅｈａｖｉｏｒ（）メソッドを次に呼び出すことになる。

コンポジット・インスタンスは、新しいコンポーネントの作成のための専用操作を提供することにより、コンポーネントの作成を管理する。各コンポーネントについて、Ｐｈｉｌｏｓｏｐｈｅｒ型の操作ｐｈｉｌが存在する。新しいｐｈｉｌ操作は、新しいインスタンスを作成し、これをコンポーネント関係に追加し、そのスレッドを新しいコンポーネントに渡す。

次のコードは、コンポジットｓｙｓが新しいコンポーネントｐｈｉｌを作成する方法を示す。
Ｐｈｉｌｏｓｏｐｈｅｒ ＊ｐＰｈｉｌ ＝ ｓｙｓ−＞ｎｅｗＰｈｉｌ（）；
新しいインスタンスを作成したら、通常は、その関係ミューテータを呼び出して、それをそのピアに接続することになる。クラスがリアクティブであれば、通常は、そのｓｔａｒｔＢｅｈａｖｉｏｒ（）メソッドを次に呼び出すことになる。

匿名インスタンスを削除する
ラプソディ（Ｒｈａｐｓｏｄｙ）では、ユーザが自分で匿名インスタンスを管理する。したがって、それらを削除するのもユーザの責任である。コンポジット・インスタンスのコンポーネントは、コンポジットによって管理される。それを削除するには、コンポジット・オブジェクトの明示的な要求を行う必要がある。

従来の任意のＣ＋＋プログラムと同様に、Ｃ＋＋の削除演算子を適用する。インスタンスの削除は、そのインスタンスのデストラクタの適用を伴う。ラプソディ（Ｒｈａｐｓｏｄｙ）は、システム内のすべてのクラスについてデフォルトのデストラクタを生成する。このデストラクタに対しては、ブラウザを用いてコードを追加することができる。

たとえば、ａＢでポイントされるインスタンスを削除するには、次の呼び出しを用いる。
ｄｅｌｅｔｅ ａＢ；

コンポジットのコンポーネントを削除する
コンポジットの各コンポーネントに対し、そのコンポーネントのインスタンスを削除する専用操作が存在する。

たとえば、コンポジットＣ内のｃｏｍｐＢというコンポーネントから、ａＢでポイントされるインスタンスを削除するには、次の呼び出しを用いる。
Ｃ−＞ｄｅｌｅｔｅＣｏｍｐＢ（ａＢ）；

関係を使用する
関係は、他のオブジェクトを参照するための基本的な手段である。関係は、コンテナ・クラスを用いてコードに実装される。ラプソディ（Ｒｈａｐｓｏｄｙ）フレームワークは、デフォルトで使用される１セットのコンテナ・クラスを含む。プロパティを用いて、このデフォルトを、たとえば、Ｓｔａｎｄａｒｄ Ｔｅｍｐｌａｔｅ Ｌｉｂｒａｒｙ （ＳＴＬ）（商標）コンテナを使用するように変更できる。詳細については、「プロパティ参照ガイド（Ｐｒｏｐｅｒｔｉｅｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）」を参照されたい。

この章で説明するコレクションと関係アクセッサ関数および関係ミューテータ関数は、ラプソディ（Ｒｈａｐｓｏｄｙ）で提供されるデフォルトのセットを参照する。

対１関係
対１関係は、単純なポインタとして実装される。これらの扱いは、属性の扱いと非常によく似ている。すなわち、対１関係にもアクセッサ関数とミューテータ関数がある。

Ｂが、ロール名ｒｏｌｅによってＡに関連付けられたクラスであるとすれば、Ａは次のデータ・メンバを含む。
Ｂ＊ ｒｏｌｅ；
これは次のメソッドを含む。
B* getRole();
void setRole(B* p_B);
これらのデフォルトは、そのロールのプロパティによって変更できる。詳細については、「プロパティ参照ガイド（Ｐｒｏｐｅｒｔｉｅｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）」を参照されたい。

対多関係
対多関係は、ＯＭＣｏｌｌｅｃｔｉｏｎテンプレートを用いるポインタのコレクションによって実装される。

Ｆが、ロール名ｒｏｌｅによってＥに多様に関連付けられたクラス名であれば、Ｅは次のデータ・メンバを含む。
ＯＭＣｏｌｌｅｃｔｉｏｎ＜Ｆ＊＞ ｒｏｌｅ；
この関係を操作するために、次のメソッドがＥ内に生成される。
・この関係を最初から最後まで繰り返すには、次のアクセッサを用いる。
ＯＭＩｔｅｒａｔｏｒ＜Ｆ＊＞ ｇｅｔＲｏｌｅ（） ｃｏｎｓｔ；
たとえば、関連付けられたＦオブジェクトのそれぞれにイベントｘを送るには、以下のコードを用いる。
OMIterator<F*>
iter(anE->getRole());
while(*iter)
{
*iter->GEN();
iter++;
}
このコードでは、ａｎＥがＥのインスタンスである。
・コレクションにインスタンスを追加するには、次の呼び出しを用いる。
ｖｏｉｄ ａｄｄＲｏｌｅ（Ｆ＊ ｐ＿Ｆ）；
・コレクションからインスタンスを削除するには、次の呼び出しを用いる。
ｖｏｉｄ ｒｅｍｏｖｅＲｏｌｅ（Ｆ＊ ｐ＿Ｆ）；
・コレクションをクリアするには、次の呼び出しを用いる。
ｖｏｉｄ ｃｌｅａｒＲｏｌｅ（）；
これらのデフォルトは、そのロールのプロパティによって変更できる。詳細については、「プロパティ参照ガイド（Ｐｒｏｐｅｒｔｉｅｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）」を参照されたい。

順序付き対多関係
順序付き対多関係は、ＯＭＬｉｓｔテンプレートを用いるポインタのコレクションによって実装される。

対多関係に順序を付けるには、その関係のＯｒｄｅｒｅｄプロパティをＴｒｕｅにする。

操作メソッドはすべて、「対多関係」の項で述べたものと同じである。

好適化された対多関係
好適化された対多関係は、関連クラス内の属性によって好適化された対多関係である。好適化された対多関係は、ＯＭＭａｐテンプレートを用いるポインタのコレクションによって実装される。

操作メソッドはすべて、「対多関係」の項で述べたものと同じである。さらに、以下の鍵修飾（キーによって好適化）されたメソッドが提供される。
F* getRole(type key) const;
void addRole(type key, F* p_F);
void removeRole(type key);

ランダム・アクセス対多関係
ランダム・アクセス対多関係は、コレクション内のアイテムへのランダム・アクセスが可能であるよう拡張された対多関係である。

対多関係をランダム・アクセス可能にするには、その関係のＧｅｔＡｔＧｅｎｅｒａｔｅプロパティをＴｒｕｅにする。これにより、新しいアクセッサが生成される。
Ｆ＊ ｇｅｔＲｏｌｅ（ｉｎｔ ｉ） ｃｏｎｓｔ；

静的アーキテクチャのサポート
メモリに制約があり、過酷で、リアルタイムかつ安全性重視のアプリケーションでは、静的なアーキテクチャがよく用いられる。メモリ管理を行わないアプリケーションや、非決定性およびメモリ・フラグメンテーションによって問題が発生するアプリケーションを、ラプソディ（Ｒｈａｐｓｏｄｙ）は、（初期設定後の）実行中に汎用メモリ管理（即ち、ヒープ）機能をまったく用いないことによってサポートする。これは、安全性重視システムの典型的な要件である。

ラプソディ（Ｒｈａｐｓｏｄｙ）では、汎用ヒープ機能を用いないようにするために、指定されたクラスに対する特別なアロケータ（即ち、ローカル・ヒープ）を作成する。ローカル・ヒープは、ユーザが定義した数のオブジェクトを収容できる、あらかじめアロケートされた、連続的な境界付きメモリ・チャンクである。ローカル・ヒープのアロケーションは、安全かつ単純なアルゴリズムによって行う。ローカル・ヒープを用いることは、イベントやトリガされる操作では特に重要である。

ラプソディ（Ｒｈａｐｓｏｄｙ）アプリケーションは、以下の場合には、暗黙的にも明示的にも動的メモリ操作になる。
・イベント生成（暗黙的）−任意選択でローカル・ヒープによって解決される
・関係の追加−静的配列を用いて実装することにより解決される（動的コンテナは動的のまま）
・新しい演算子によるアプリケーション・オブジェクトの明示的作成−アプリケーションが実際にはオブジェクトを動的に作成する場合に、ローカル・ヒープによって解決される。

ローカル・ヒープを、クラス、トリガされる操作、イベント、およびスレッド・イベント・キューのすべてに適用するか、それらの一部だけに適用するかを指定することができる。

注記：バージョン２．０でｏＭＬｉｓｔを用いて実装されたイベント・キューは、バージョン２．１ではＯＭＡｒｒａｙに変更されている。リンクされた並び（リスト）ではなく動的配列を使用してイベント・キューを実装すると、メモリ動作や時間的動作が変わる。

静的メモリ・アロケーションのプロパティ
以下の表は、生成されたコードに対する静的アロケーションのコンフィグレーションを行うことができるいくつかのプロパティのリストである。これらのうちのいずれかのプロパティを、個々のインスタンスより高いレベルで設定すると、すべてのインスタンスについてデフォルトが設定される。たとえば、クラス・プロパティをコンポーネント・レベルで設定すると、すべてのクラス・インスタンスについてデフォルトが設定される。いずれの場合でも、インスタンスの実際の数が、宣言されている最大数を超えると、動作が定義されない。

これらのプロパティの詳細については、「プロパティ参照ガイド（Ｐｒｏｐｅｒｔｉｅｓ Ｒｅｆｅｒｅｎｃｅ Ｇｕｉｄｅ）」を参照されたい。

割り込みハンドラ内で生成されたイベントは、リスケジューリングに頼らないようにすべきであり、したがって、オペレーティング・システムのミューテックスを使用することにならないようにすべきである。つまり、ProtectStaticMemoryPoolはFalseでなければならない。メモリ・プールがスレッド・セーフでないことの確認はユーザが行わなければならない。アニメーション・フレームワークは、この制限の対象ではない。

フレームワーク・ファイルは、動的アロケーションでも静的アロケーションでも使用可能なコードを含む。実際の使い方は、生成されたコードに基づく。GENおよびgenマクロの使い方は、両モードで同じである。

（<lang>_CG:Relationの下の）ImplementWithStaticArrayプロパティを介して、固定の境界付き関係を静的配列に実装すると、初期設定から逸脱した静的アロケーションが暗黙的に使用される。

静的メモリ・アロケーション・アルゴリズム
ラプソディ（Ｒｈａｐｓｏｄｙ）は、ローカル・ヒープを用いる各イベントおよびクラスについてｎｅｗ演算子とｄｅｌｅｔｅ演算子を再定義することによって、静的メモリ・アロケーションを実装する。メモリ・アロケータは、特定要素のｎ個のインスタンスを保持するのに十分なメモリを割り当てる（アロケートする）（ｎは、ＢａｓｅＮｕｍｂｅｒＯｆＩｎｓｔａｎｃｅｓプロパティの値である）。メモリ・アロケーションは、システム構築中に実行され、動的メモリを使用する。メモリ・アロケータは、次のようなＬＩＦＯ（スタック）アルゴリズムを用いる。
・要求されたメモリはスタックの最上位から取り出され、最上位ポインタが次のアイテムをポイントするよう移動する。
・返されたメモリはスタックの最上位に格納され、最上位ポインタが、返されたアイテムをポイントするよう移動する。

生成されたクラスは、クラスであれ、イベントであれ、トリガされる操作であれ、メモリ・アロケータ（特にｎｅｘｔポインタ）が使用するための必要な追加的コードを導入するように配備される。

メモリ・プールが空になったクラスをインスタンス化しようとすると、（ブレークポイントを設定できる）ＯＭＭｅｍｏｒｙＰｏｏｌＩｓＥｍｐｔｙ（）操作が呼び出され、トレーサ・メッセージが表示される。インスタンス化に失敗すると、トレーサ・メッセージが表示される。

静的アーキテクチャを介しての値による束縛
通常、ラプソディ（Ｒｈａｐｓｏｄｙ）は、１−ｔｏ−ＭＡＸ関係については、関係の種類（図で設定される）にかかわらず、値による束縛ではなく、参照による束縛を生成する。ただし、静的アーキテクチャ機能を用いれば、クラス・インスタンスおよびイベント・インスタンスの最大数を静的アーキテクチャ・プロパティで定義し、したがって、デフォルトの非決定的なｎｅｗ（）演算子を使用しないことによって、値による束縛の効果を実現することができる。

静的メモリ・アロケーション条件
アプリケーションが静的メモリ・アロケーションを用いる場合は、チェッカが、以下の条件が満たされるかどうかを検証する。
・クラス・インスタンスの最大数がゼロでない。
・ステートチャート実装がフラットである。
・ローカル・ヒープを用いる各イベントおよびクラスについて、ｎｅｗ演算子とｄｅｌｅｔｅ演算子が明示的に指定されている。

レポートは、インスタンスの数について設定されている制限を含む。

すべてのプロパティが、要素定義の一部として、ロードされ、リポジトリに保存される。

制限
以下の制限が静的メモリ・アロケーションに適用される。
・配列のアロケーションはまだサポートされていない。インスタンスは１つずつアロケートされなければならない。これは、配列のアロケーションに関連するメモリ・オーバーヘッド（が不明）のためである。
・tm()タイムアウト関数はまだサポートされていない。

標準操作を用いる
標準操作は、特定のフレームワークまたはプログラミング・スタイルによって標準化されたクラス操作である。顕著な例は、分散フレームワークの一部であるシリアル化メソッド（「例」の項を参照）と、コピー・コンストラクタまたは変換コンストラクタである。このような操作は、一般に、（属性、操作、スーパクラスなどの）クラス機能に集約関数を適用する。以下のセクションでは、クラスおよびイベントについて生成されたコードに標準操作を追加する方法を説明する。

標準操作の用途
以下のことを行うために標準操作を用いることができる。
・イベントをシリアル化するメソッドを作成する。
・クラスの標準形式をサポートする。
・クラスを永続的にする。
・特定のフレームワークをサポートする。

イベントのシリアル化
イベントは、通常、次の２つのステップで生成され、これらのステップは、ラプソディ（Ｒｈａｐｓｏｄｙ）フレームワークのＧＥＮマクロ内でカプセル化される。
１．Ｅｖｅｎｔクラスがインスタンス化され、イベントへのポインタが生成される。
２．その新しいイベント・ポインタを受け側のイベント・キューに追加することによって、そのイベントがキューイングされる。

イベントがインスタンス化され、受け側のイベント・キューに追加されると、そのイベントを「送る」準備が整う。送る操作が成功するためには、送り側と受け側のメモリ・アドレス空間が同じでなければならない。しかし、いつもそうであるとは限らない。

たとえば、以下のような場合には、送り側と受け側のアドレス空間が異なるのが普通である。
・同じホストにある、異なるプロセス間でイベントを送る場合。
・分散アプリケーション間でイベントを送る場合。
・送り側と受け側が、異なるメモリ・パーティションにマッピングされている場合。

この問題を解決する一般的な方法の１つは、情報をマーシャリングすることである。マーシャリングは、イベントを生（ロー）データに変換し（またはイベントをシリアル化し）、それを、ｐｕｂｌｉｓｈ／ｓｕｂｓｃｒｉｂｅなどのフレームワークを用いて送り、受け側でそのロー・データを元の形式に変換する（戻す）ことを意味する。ＣＯＲＢＡのような高レベルのソリューションでは、必要なコードが自動的に生成されるが、低レベルのソリューションでは、明示的な処置が必要である。標準操作を用いると、イベントやインスタンスのマーシャリングおよびアンマーシャリングをどのように行うかを、詳細なレベルまで指定できる。

クラスの標準形式
すべてのクラスに含めるべき操作のリストが、多くのスタイル・ガイドや作成規約によって指定されている。よくある例は、コピー・コンストラクタ、変換コンストラクタ、代入演算子などである。ラプソディ（Ｒｈａｐｓｏｄｙ）では、これらのような標準操作をすべてのクラスに対して定義できる。

永続性
クラスを永続的にすることは、通常、あらかじめ定義されたシグネチャを有する操作をすべてのクラスに追加することによって実現される。これは、標準操作を用いて行うことができる。

フレームワークのサポート
多くのオブジェクト指向フレームワークは、基本クラスからサブクラスを抽出し、仮想操作を無効にすることによって、用いられる。たとえば、ＭＦＣコンストラクトは、ＣＯｂｊｅｃｔクラスから継承され、次のような操作を無効にする。
ｖｉｒｔｕａｌ ｖｏｉｄ Ｄｕｍｐ（ＣＤｕｍｐＣｏｎｔｅｘｔ＆ ｄｃ） ｃｏｎｓｔ；
これは、標準操作を用いて行うことができる別の例である。
フレームワーク基本クラスの追加は、＜ｌａｎｇ＞＿ＣＧ：：Ｃｌａｓｓ：：ＡｄｄｉｔｉｏｎａｌＢａｓｅＣｌａｓｓｅｓプロパティを用いて行うことができる。

標準操作を作成する
標準操作はすべて、論理名に関連付けられている。標準操作の論理名を定義するには、ＳｔａｎｄａｒｄＯｐｅｒａｔｉｏｎｓプロパティを無効にする。

定義されているすべての標準操作について、操作の宣言および定義を指定しなければならない。これを行うには、次の２つのプロパティをｓｉｔｅ．ｐｒｐファイルに追加して、必要な関数テンプレートを指定する。
・＜論理名（ＬｏｇｉｃａｌＮａｍｅ）＞Ｄｅｃｌａｒａｔｉｏｎ−操作宣言のテンプレートを指定する
・＜論理名（ＬｏｇｉｃａｌＮａｍｅ）＞Ｄｅｆｉｎｉｔｉｏｎ−操作実装のテンプレートを指定する
たとえば、ｍｙＯｐという論理名に対し、（ｓｉｔｅ．ｐｒｐファイルまたはＣＯＭ ＡＰＩ（ＶＢＡ）を用いて）次のプロパティを追加できる。
Subject CG
Metaclass Class

Property myOpDeclaration MultiLine ""

Property myOpDefinition MultiLine ""
end
標準操作に関連付けられるすべてのプロパティを、それぞれのＣＧサブジェクトおよびメタクラスの下にあるｓｉｔｅ．ｐｒｐファイルに追加する。これらのプロパティはすべて、ＭｕｌｔｉＬｉｎｅ型を含んでいなければならない。

キーワード
テンプレートは、以下のキーワードを含むことができる。
・＄Ａｔｔｒｉｂｕｔｅｓ−クラス内のすべての属性について、このキーワードは、その属性のプロパティＣＧ：：Ａｔｔｒｉｂｕｔｅ：：＜論理名（ＬｏｇｉｃａｌＮａｍｅ）＞で特定されるテンプレートの内容に置き換えられる。たとえば、＜ｌａｎｇ＞＿ＣＧ：：Ａｔｔｒｉｂｕｔｅ：：ｍｙＯｐ。
・＄Ｒｅｌａｔｉｏｎｓ−クラス内のすべての関係について、このキーワードは、その関係のプロパティＣＧ：：Ｒｅｌａｔｉｏｎ：：＜論理名（ＬｏｇｉｃａｌＮａｍｅ）＞で特定されるテンプレートの内容に置き換えられる。たとえば、＜ｌａｎｇ＞＿ＣＧ：：Ｒｅｌａｔｉｏｎ：：ｍｙＯｐ。
・＄Ｂａｓｅ （ｖｉｓｉｂｉｌｉｔｙ（視認性））−すべてのスーパークラス／イベントについて、このキーワードは、そのスーパークラス／イベントのプロパティＣＧ：：Ｃｌａｓｓ／Ｅｖｅｎｔ：：＜論理名（ＬｏｇｉｃａｌＮａｍｅ）＞Ｂａｓｅで特定されるテンプレートの内容に置き換えられる。たとえば、ＣＧ：：Ｃｌａｓｓ：：ｍｙＯｐＢａｓｅ。
・＄Ａｒｇｕｍｅｎｔｓ−クラス内のすべてのイベントについて、このキーワードは、そのイベントのプロパティＣＧ：：Ｅｖｅｎｔ：：＜論理名（ＬｏｇｉｃａｌＮａｍｅ）＞Ａｒｇｓで特定されるテンプレートの内容に置き換えられる。たとえば、＜ｌａｎｇ＞＿ＣＧ：：Ｅｖｅｎｔ：：ｍｙＯｐＡｒｇｓ。

これらのプロパティを拡張すると、以下のキーワードを使用できる。
・＄Ｎａｍｅ−キーワードのコンテキスト（文脈）に応じて、クラス（属性、関係、操作、または基本クラス）のモデル名を指定する。適用可能であれば、＄Ｔｙｐｅは、このモデル要素に関連付けられた型となる。
・＄ＩｍｐｌＮａｍｅ−（生成された）コピーの名前を指定する。通常、これは、このモデル要素に関連付けられたデータ・メンバである。
これは、生成されたコードにおいて論理名をより複雑な名前に置き換えることができるＲｉＣで有用である。

さらに、規約＄＜プロパティ名＞を用いて、コンテキスト内の任意のプロパティに関連付けられるカスタム・キーワードを作成できる。たとえば、プロパティＣＧ：：Ｃｌａｓｓ：：Ｆｏｏを追加した場合は、＄Ｆｏｏによって、ＣＧ：：Ｃｌａｓｓ：：ｍｙＯｐＤｅｆｉｎｉｔｉｏｎ内のプロパティ内容に関連付けることができる。

パワー・ユーザが、この機能を、ステレオタイプ・ベースのコード生成と組み合わせて使用すれば、標準操作のセットを定義し、それをステレオタイプに関連付け、チームの他のメンバが（プロパティのことを気にかけずに）そのステレオタイプを適用して標準操作を取得できるようにすることができる。

例
特定パッケージ内のすべてのイベントについてイベントのシリアル化を実装する必要がある場合は、そのパッケージのＣＧ：：Ｅｖｅｎｔ：：ＳｔａｎｄａｒｄＯｐｅｒａｔｉｏｎｓプロパティに「ｓｅｒｉａｌｉｚｅ， ｕｎｓｅｒｉａｌｉｚｅ」を含める。strstreamの内部にイベント引数値を配置してシリアル化を行うと、対応するプロパティとその値は以下のようになる。
ＣＧ：：Ｅｖｅｎｔ：：ＳｅｒｉａｌｉｚｅＤｅｃｌａｒａｔｉｏｎ
ｐｕｂｌｉｃ：
ｓｔｒｓｔｒｅａｍ ＆ ｓｅｒｉａｌｉｚｅｒ（ｓｔｒｓｔｒｅａｍ ＆ ｔｈｅＳｔｒＳｔｒｅａｍ） ｃｏｎｓｔ；
ＣＧ：：Ｅｖｅｎｔ：：ＳｅｒｉａｌｉｚｅＤｅｆｉｎｉｔｉｏｎ
strstream & $Name::serialize(strstream
& theStrStream) {
$Base
$Arguments
return theStrStream;
}
ＣＧ：：Ｅｖｅｎｔ：：ＳｅｒｉａｌｉｚｅＡｒｇｓ
ｔｈｅＳｔｒＳｔｒｅａｍ ＜＜ ＄Ｎａｍｅ；
ＣＧ：：Ｅｖｅｎｔ：：ＳｅｒｉａｌｉｚｅＢａｓｅ
＄Ｎａｍｅ：：ｓｅｒｉａｌｉｚｅ（ｔｈｅＳｔｒＳｔｒｅａｍ）；
２つの引数であるｓｅｖｅｒｉｔｙおよびｐｒｉｏｒｉｔｙを有するイベントＶｏｉｃｅＡｌａｒｍを定義し、ＶｏｉｃｅＡｌａｒｍをＡｌａｒｍから継承した場合、結果として、そのテンプレートのコードは以下のようになる。
strstream &
VoiceAlarm::serialize(strstream &
theStrStream) {
Alarm::serialize
(theStrStream);
theStrStream <<
severity;
theStrStream <<
priority;
return theStrStream;
}
ｕｎｓｅｒｉａｌｉｚｅ部分についても同じ処理が行われる。

Ｊａｖａ初期設定ブロックをサポートする（ＲｉＪ）
Ｊａｖａ初期設定ブロックは、クラスをインスタンス化する前に、クラスで使用するネイティブ・ライブラリをロードするなどの初期設定を実行するために使用される。標準操作を用いると、以下のように、この言語コンストラクトにとって便利なエントリ・ポイントを備えることができる。
１．ｓｉｔｅ．ｐｒｐファイルを開き、以下のプロパティを追加する。
Subject CG
Metaclass Class

Property StandardOperations String "InitializationBlock"
end
end
２．ｓｉｔｅＪａｖａ．ｐｒｐファイルを開き、以下のプロパティを追加する。
Subject JAVA_CG
Metaclass Class

Property InitializationBlockDeclaration MultiLine ""
end
end
３．初期設定ブロックを必要とするすべてのクラスについて、そのクラスのＩｎｉｔｉａｌｉｚａｔｉｏｎＢｌｏｃｋＤｅｃｌａｒａｔｉｏｎプロパティにテキストを入力する。たとえば、次のようになる。
static {

System.loadLibrary("MyNativeLib");
}
このテキストは、クラス宣言の下に入力される。

本発明の１つまたは複数の実施形態によれば、動的モデル／コード結合は、たとえば、ラプソディ（Ｒｈａｐｓｏｄｙ）のＵＭＬ（商標）（統一モデリング言語）モデルとそれらの実装コードとを自動的に同期するメカニズムを提供する。これにより、最新の実装コードを即座に表示でき、また、コードを手動で変更した場合にモデルがただちに更新されるようにできる。

このアプローチでは、モデルは、ツールが、一連の作業成果物（実装ソース・コード、各種ドキュメント、テスト・スクリプト、ＵＩフロント・エンドなど）を生成し、タイミング解析やテスト・ドライブなど、様々な目的のために外部ツールと対話するもとになる、システムの完結した（または、ほぼ完結した）仕様を構成する。さらに、モデル・ベース・ツールは、ステートチャート図やアクティビティ図などの振る舞い図を含む、できるだけ多くをＵＭＬ（商標）仕様から実装することをねらいとした綿密な実装スキームによって特徴付けられる。これにより、ＵＭＬ（商標）仕様とその実装の間の不整合性が最小化（または除去）されるとともに、生産性および製品品質が大幅に向上する。

エンド・ユーザがプログラミング言語とそれをサポートする技術プラットフォームの優位性を最大限に享受できるようにするには、モデルとコードの高い（または十分な）レベルの相乗効果が必要である。これを実現するために、実装言語がモデリング言語を補強する。つまり、モデルは、コード・フラグメントをモデルの仕様の一部として含む。さらに、ユーザは、生成されたコードを高いレベルで制御して、その製造品質要件を満たすようにしなければならない。この相乗効果的アプローチの別の主要成功因子は、生成されたコードに対してユーザが直接実行した変更を、その変更がモデルの不可欠な部分になるように
ラウンドトリップできることである。このため、手動で実行したコード変更が、コードの再生成によって失われることがない。ＤＭＣＡにより、ユーザは、標準的なコード生成機能およびラウンドトリップ機能を利用してシステムの実装を即座に表示し、直接制御することができるので、動的モデル／コード結合は、前述のアプローチの優位性を押し進める重要な要素の１つである。

本発明の少なくとも１つの実施形態における本願発明者らの動的モデル／コード結合のアプローチは、モデルまたはコードにおける変更を検出して、必要な更新を自動的に（または、ほぼ自動的に）行うという、これまでと異なる切り口をとることによって、現行技術の制限を克服するものである。これにより、モデルとその実装を切り離したままで両者間の高レベルの相乗効果を確保して、本願発明者らのモデル・ベース・アプローチを維持および拡張することができる。代替実施態様では、このモデルは、更新を要する変更のタイプに関係なく、所定のアクティビティおよび／または時間間隔に基づいて自動的に更新される。

本発明の少なくとも１つの実施形態による動的モデル／コード結合では、関連するモデル要素を変更すると、表示されているコードが更新され、逆に、コードを変更すると、モデルが更新される。

ＤＭＣＡＭａｎａｇｅｒは、モデル要素の変更の結果として生成されたファイルを更新でき、コードの変更をモデルにラウンドトリップできる。

さらに、本発明の代替実施形態によれば、以下のうちの１つまたは複数が達成される。

ａ．ＤＭＣＡＭａｎａｇｅｒが、任意選択で、ファイルの生成が必要らしいという通知を、コード・ビューまたはアクティブ・コード・ビュー以外のモジュールから取得できる。

ｂ．任意選択で、ＤＭＣＡＭａｎａｇｅｒが任意のタイプのメカニズムを用いてモデル要素の再生成が必要かどうかを決定できるようにしたり、常にファイルを再生成するようにしたりできる。

ｃ．ＤＭＣＡＭａｎａｇｅｒが、任意選択で、ファイル内の実装されているすべて（または、ほぼすべて）の要素の保存場所へのポインタまたは参照をアクティブ・コンポーネントに照会できる。

ｄ．アクティブ・コンポーネントが、任意選択で、実装ファイルとモデル要素の間のマッピングの保存場所へのインデックスまたは参照を保存する。

ｅ．ビューがフォーカスを失い、ビューの内容が修正された場合でも、ＤＭＣＡＭａｎａｇｅｒが任意選択でそのファイルを保存できる。

ｆ．ファイルの内容が変更されたかどうかを判断する代わりに、ファイルおよび関連要素が更新されている場合には、それらについて任意選択でリポジトリ更新を自動的に実行する。

ｇ．コードがコード生成規則に適合するように、ＤＭＣＡＭａｎａｇｅｒが、任意選択で、（修正された要素を更新する前に）すべて（または、ほぼすべて）の要素のコード生成を実行する。

また、本発明の少なくとも１つの実施形態は、ＵＭＬ（商標）（統一モデリング言語）を利用して、ＵＭＬ（商標）モデルとコードの高い（または十分な）レベルの相乗効果をもたらすことができる。

本発明の一実施形態は、有利なことに、ユーザが、生成されたコードを高いレベルで制御して、たとえば、製造品質要件を満たすことを可能にする。たとえば、本発明の少なくとも１つの実施形態はさらに、生成されたコードに対して直接行われた変更をモデルにラウンドトリップして、コードに対するそれらの変更がモデルの不可欠な部分になるようにできる。これにより、有利なことに、たとえば、コードの再生成に応答してモデルが必ず更新される。したがって、本発明の１つまたは複数の実施形態により、ユーザは、標準的なコード生成機能およびラウンドトリップ機能を利用して、システムの実装を素早く表示したり、直接制御および／または編集したりできる。

したがって、本発明の１つまたは複数の実施形態を利用して、ソフトウェア・モデルおよび／またはソフトウェア・コードの変更を検出し、そのモデルおよび／またはコードを自動的に（または、ほぼ自動的に）更新することができる。代替実施態様では、このソフトウェア・モデルを、たとえば、更新を要する変更のタイプに任意選択で依存せず、所定のアクティビティおよび／または時間間隔に基づいて自動的に更新することが可能である。

本発明はさらに、有利なことに、複雑なコード生成スキームおよびラウンドトリップ・スキームのモデル／コード結合を可能にする。したがって、本発明は、ユーザが、実装コードに対する十分なレベルの可視性ならびに制御性と併せ、（たとえば、ＵＭＬ（商標）を利用して）モデル・ベース開発の強みを有利に利用することを可能にすることができる。

関連技術による開発ツールの概要を示す図である。 モデル・ビューとアクティブ・コード・ビューを示す例示的な画面表示である。 コードの変更に基づいてモデルが更新される様子を示す例示的な画面表示である。 本発明の一実施形態のアーキテクチャの例示的なハイレベルの概要を示す図である。 コード・ファイルが、関連付けられたモデルへの変更に基づいて更新される様子を示す例示的なフロー図である。 モデルが、関連付けられたコード・ファイルへの変更に基づいて更新される様子を示す例示的なフロー図である。 本発明に係る動的モデル／コード結合を実装するために使用できるコンピュータのブロック図である。 図７のコンピュータの内部ハードウェアのブロック図である。

符号の説明

１００ トランジェント・メタモデル
１０２ ソース・コード
１０８ インクリメンタル・コード・エディタ
４０１ モデル・コード・マネージャ
４０２ コード・ジェネレータ
４０３ リポジトリ更新／ラウンドトリップ
４０４ 要素位置ファインダ
４０５ モデル要素
４０６ コンポーネント
４０７ リポジトリ
４０８ ＩＭＣＡ
４０９ 生成されたファイル
４１０ アクティブ・コード・ビュー
４１１ コード・ビュー
４１２ テキスト・ファイル
４１３ ソース・ファイル
４１４ メイク・ファイル
４１５ スクリプト
７００ コンピュータ
７０２ ＣＰＵ
７０４ フロッピー・ドライブ
７０６ ＣＤ−ＲＯＭ
７０８ ディスプレイ
７１０ キーボード
７１２ マウス
８１２ ＲＯＭ
８１４ ＲＡＭ
８１６ ディスク・コントローラ
８１８ ハード・ドライブ
８２０ ディスプレイ・インターフェース
８２２ 通信ポート
８２４ インターフェース

Claims (29)

1. コンピュータに実装され、ソース・コードを、該ソース・コードを表している、複数のモデル要素に関連付ける方法において、
   ソフトウェア・ソース・コードとして実装できる、モデルの複数の要素を生成するステップと、
   前記モデルの前記複数の要素に対応する前記ソフトウェア・ソース・コードを生成するステップと、
   前記ソフトウェア・ソース・コードの部分を、前記モデルの前記複数の要素の少なくとも１つに関連付けるステップと、
   前記複数の要素の少なくとも１つが修正されていることを確認するステップと、
   前記ソフトウェア・ソース・コードの一部分および前記ソフトウェア・ソース・コード全体のうちの少なくとも一方を修正して、前記修正されている複数の要素の前記少なくとも１つまたは複数に対応させるステップと
   を具備することを特徴とする方法。
2. 前記修正されているソース・コードの、少なくとも一部分を表示するステップをさらに具備することを特徴とする請求項１記載の方法。
3. 前記モデル要素の少なくとも一部分がブラウザの第１の表示領域に表示され、前記修正されたソース・コードの少なくとも一部分が前記ブラウザの第２の表示領域に表示されることを特徴とする請求項１記載の方法。
4. 前記ソース・コードの特定の行番号が前記モデル要素に関連付けられることを特徴とする請求項３記載の方法。
5. 前記第１および第２の表示領域がフレームを具備することを特徴とする請求項３記載の方法。
6. 前記ソース・コードの特定の行番号が前記モデル要素に関連付けられることを特徴とする請求項１記載の方法。
7. 前記モデル要素が統一モデリング言語（ＵＭＬ）モデル要素であることを特徴とする請求項１記載の方法。
8. 前記ＵＭＬ要素が、クラス図、オブジェクト図、ユースケース図、状態図、シーケンス図、アクティビティ図、コラボレーション図、コンポーネント図、および配置図のうちの少なくとも１つを含むことを特徴とする請求項７記載の方法。
9. コンピュータに実装され、ソース・コードを、該ソース・コードを表している、複数のモデル要素に関連付ける方法において、
   ソフトウェア・ソース・コードとして実装できる、モデルの複数の要素を生成するステップと、
   前記モデルの前記複数の要素に対応する前記ソフトウェア・ソース・コードを生成するステップと、
   前記ソフトウェア・ソース・コードの部分を、前記モデルの前記複数の要素の少なくとも１つに関連付けるステップと、
   前記ソフトウェア・ソース・コードの少なくとも一部分が修正されていることを確認するステップと、
   前記複数のモデル要素の前記少なくとも１つを修正して、前記修正されているソフトウェア・ソース・コードに対応させるステップと、
   前記ソフトウェア・ソース・コードが前記修正されたモデルと合致するように、所定の規則に従って前記ソフトウェア・ソース・コードの一部分および前記ソフトウェア・ソース・コード全体のうちの少なくとも一方を再生成するステップと
   を具備することを特徴とする方法。
10. 前記修正されているソフトウェア・ソース・コードの、少なくとも一部分を表示するステップをさらに具備することを特徴とする請求項９記載の方法。
11. 修正されている前記モデルの前記複数の要素の少なくとも１つを表示するステップをさらに具備することを特徴とする請求項１０記載の方法。
12. 前記複数のモデル要素の少なくとも１つがブラウザの第１の表示領域に表示され、前記修正されたソフトウェア・ソース・コードの少なくとも一部分が前記ブラウザの第２の表示領域に表示されることを特徴とする請求項１１記載の方法。
13. 前記ソフトウェア・ソース・コードの特定の行番号が前記複数のモデル要素の少なくとも１つに関連付けられることを特徴とする請求項１２記載の方法。
14. 前記第１および第２の表示領域がフレームを含むことを特徴とする請求項１２記載の方法。
15. 前記ソース・コードの特定の行番号が前記モデル要素に関連付けられることを特徴とする請求項１１記載の方法。
16. 前記モデル要素が統一モデリング言語（ＵＭＬ）モデル要素であることを特徴とする請求項１１記載の方法。
17. 前記ＵＭＬ要素が、クラス図、オブジェクト図、ユースケース図、状態図、シーケンス図、アクティビティ図、コラボレーション図、コンポーネント図、および配置図のうちの少なくとも１つを含むことを特徴とする請求項１６記載の方法。
18. コンピュータ可読媒体上に存在するコンピュータ・プログラム製品において、
    ソフトウェア・ソース・コードとして実装できる、モデルの複数の要素を生成することと、
    前記モデルの前記複数の要素に対応するソフトウェア・ソース・コードを生成することと、
    前記ソフトウェア・ソース・コードの部分を、前記モデルの前記複数の要素の少なくとも１つに関連付けることと、
    前記モデルの前記複数の要素の少なくとも１つが修正されていることを確認することと、
    前記ソース・コードの一部分とソース・コード全体の少なくとも一方を修正して、前記１つまたは複数の修正されたモデル要素に対応させることと
    をコンピュータに実行させる命令を具備することを特徴とするコンピュータ・プログラム製品。
19. 前記修正されているソース・コードの、少なくとも一部分を前記コンピュータに表示させる命令をさらに具備することを特徴とする請求項１８記載のコンピュータ・プログラム製品。
20. コンピュータ可読媒体上に存在するコンピュータ・プログラム製品において、
    ソフトウェア・ソース・コードとして実装できる、モデルの複数の要素を生成することと、
    前記モデルの前記複数の要素に対応するソフトウェア・ソース・コードを生成することと、
    前記ソフトウェア・ソース・コードの部分を、前記モデルの前記複数の要素の少なくとも１つに関連付けることと、
    前記ソフトウェア・ソース・コードの少なくとも一部分が修正されていることを確認することと、
    前記複数のモデル要素の前記少なくとも１つを修正して、前記修正されているソフトウェア・ソース・コードに対応させることと、
    前記ソフトウェア・ソース・コードが前記修正されたモデルと合致するように、所定の規則に従って前記ソフトウェア・ソース・コードの一部分および前記ソフトウェア・ソース・コード全体のうちの少なくとも一方を再生成することと
    をコンピュータに実行させる命令を具備することを特徴とするコンピュータ・プログラム製品。
21. 前記修正されているソース・コードの、少なくとも一部分をコンピュータに表示させる命令をさらに具備することを特徴とする請求項２０記載のコンピュータ・プログラム製品。
22. ソフトウェア・プロジェクトにおいて、ソース・コードのドキュメントを生成するためのデータ処理システムにおいて、
    ソフトウェア・ソース・コードとして実装できる、モデルの複数の要素を生成する手段と、
    前記モデルの前記複数の要素に対応するソフトウェア・ソース・コードを生成する手段と、
    前記ソフトウェア・ソース・コードの部分を、前記モデルの前記複数の要素の少なくとも１つに関連付ける手段と、
    前記モデルの前記複数の要素の少なくとも１つが修正されていることを確認する手段と、
    前記ソフトウェア・ソース・コードの一部分とソフトウェア・ソース・コード全体の少なくとも一方を修正して、１つまたは複数の前記修正されたモデル要素に対応させる手段と
    を具備することを特徴とするデータ処理システム。
23. 前記修正されているソース・コードの、少なくとも一部分を表示する手段をさらに具備することを特徴とする請求項２２記載のデータ処理システム。
24. コンピュータに実装され、ソース・コードを、該ソース・コードを表している、モデルの複数の要素に関連付ける方法において、
    ソフトウェア・ソース・コードとして実装できる、モデルの複数の要素を生成するステップと、
    前記モデルの前記複数の要素に対応するソフトウェア・ソース・コードを生成するステップと、
    前記ソフトウェア・ソース・コードの部分を、前記モデルの前記複数の要素の少なくとも１つに関連付けるステップと、
    前記ソフトウェア・ソース・コードの少なくとも一部分が修正されていることを確認するステップと、
    前記複数のモデル要素の前記少なくとも１つを修正して、前記修正されているソフトウェア・ソース・コードに対応させるステップと、
    前記ソフトウェア・ソース・コードが前記修正されたモデルと合致するように、所定の規則に従って前記ソフトウェア・ソース・コードの一部分とソフトウェア・ソース・コード全体の少なくとも一方を再生成するステップと
    を具備することを特徴とする方法。
25. 前記修正されているソース・コードの、少なくとも一部分を表示するステップをさらに具備することを特徴とする請求項２４記載の方法。
26. ソース・コードを、該ソース・コードを表している、モデルの複数の要素に関連付けるためのシステムにおいて、
    モデル・リポジトリに保存されている要素と、要素に関連付けられているソース・コードとのうちの少なくとも一方に対する変更を検出または決定するためのモデル・コード・マネージャと、
    前記モデル・リポジトリに保存されている修正された要素及び関連付けられたすべての要素のうちの少なくとも一方に対応するコードを生成するコード・ジェネレータと、
    既存の関連付けられた要素を更新することと、修正されたソース・コードに対応する新しい要素を少なくとも１つ生成することとの、少なくとも一方を行うモデル更新ジェネレータと
    を具備することを特徴とするシステム。
27. 特定の要素に対応する、少なくとも一部のソース・コードを検出する要素ファインダをさらに備えることを特徴とする請求項２６記載のシステム。
28. 選択された要素の対応するコード・フラグメントを表示するためのアクティブ・コード・ビュー・モジュールをさらに備えることを特徴とする請求項２７記載のシステム。
29. コード更新が最後に行われてから少なくとも１つの要素が修正されているかどうかを調べるインクリメンタル・モデル・コード結合モジュールをさらに備え、前記モデル・コード・マネージャが前記修正を反映するために１つまたは複数のファイルの作成もしくは更新を行わせることを特徴とする請求項２６記載のシステム。

Images