変換オーサリングのリリース情報

© Copyright International Business Machines Corporation 2006. All rights reserved.

リリース情報

1.0 制限
   1.1 モデルから UML へのマッピングの作成時にデフォルトの UML プロファイルが自動的にマップされない
   1.2 モデル間変換で、ヒューズ・サポートは contentTypes 拡張を持つターゲット・モデルに対してのみ使用可能である
   1.3 モデル間変換のオーサリングの際に、 入力または出力として指定する Ecore モデルに対応する genmodel がなければならない
   1.4 モデル間変換構成で、ファイルをターゲット・コンテナーとして指定する必要がある
   1.5 変換オーサリングと JET 変換の統合は自動ではない
2.0 既知の問題と回避方法
   2.1 UML メタモデルはモデル間マッピングに自動的に追加されない
   2.2 フィルター済みプロパティーとの間の変換はマッピング・エディターで破損と表示される場合がある
   2.3 マッピング・ファイルでモデルへの参照のみを削除すると、マッピング・ファイルからモデルが除去される
   2.4 マージ・モードが自動または可視の場合、モデル間変換構成エディターで runSilent オプションを選択できる
   2.5 プロファイルの登録 ID が使用されない場合、モデルから登録済みプロファイルを持つ uml へのマッピングの際にマージ・エラーが発生する場合がある
   2.6 マッピング・モデルからコードを生成する際に、「plugin.xml」および「MANIFEST.MF」を含む基本プロジェクト・ファイルは再生成されない

1.0 制限

1.1 モデルから UML へのマッピングの作成時にデフォルトの UML プロファイルが自動的にマップされない

モデル間変換のオーサリングの際に、ターゲットが UML 2 モデルである場合、デフォルトの UML プロファイルは自動的にマップされません。例えば、default.epx  UML プロファイルは自動的にマップされません。これらのプロファイルを手動でマップするか、UMLDefaultLibrariesAddRule フレームワークを使用する必要があります。ターゲットが UML モデル EClass である場合、このフレームワークは変換に手動で追加できます。

フレームワークを変換に追加するには、以下のコードを変換に追加します。

    /**
     * <!-- begin-user-doc -->
     * <!-- end-user-doc -->
     * @generated NOT
     */
    protected void addTransformElements(Registry registry) {
 add(new UMLDefaultLibrariesAddRule());
     addGeneratedTransformElements(registry);
      // ここで、生成済みの変換要素の後にさらに変換要素を追加できます
      // @generated タグを除去するか、NOT を追加することを覚えておいてください
    }

1.2 モデル間変換で、ヒューズ・サポートは contentTypes 拡張を持つターゲット・モデルに対してのみ使用可能である

モデル間変換オーサリングで、ご使用のターゲット・モデルで「ヒューズ」サポートを持つには、 Eclipse ワークスペース内のプラグインに「org.eclipse.core.runtime.contentTypes」拡張がなければなりません。この拡張は、ターゲット・モデル・ドメインから派生したドメイン名を持つプラグインで指定できます。この拡張について詳しくは、比較/マージ・プロジェクトの拡張ポイント文書を参照してください。これにより、ターゲット・モデル用に高度なヒューズ戦略をビルドすることができます。よりシンプルな EMF 戦略の場合、以下の拡張を指定できます (「xxx」をターゲット・ファイル拡張子に置き換えます)。

<extension
  point="org.eclipse.core.runtime.contentTypes">
  <file-association
   content-type="com.ibm.xtools.comparemerge.emf.emfContentType"
  file-extensions="xxx"/>
 </extension>

1.3 モデル間変換のオーサリングの際に、入力または出力として指定する Ecore モデルに対応する genmodel がなければならない

モデル間変換のオーサリングの際に、入力または出力として指定する Ecore モデルに対応する genmodel がなければなりません。genmodel を作成する場合、 EMF モデル・ウィザードを使用できます。必ず genmodel を作成した後でコードを生成してください。genmodel は開発ワークベンチに登録するか、対応する Ecore モデルと同じパスになければなりません。genmodel は、.genmodel ファイル名拡張子、類似した名前、および Ecore モデルと同じケースを持つ必要があります。そうでない場合、変換オーサリング・エンジンは genmodel を見つけることができません。変換オーサリング・エンジンが必要な genmodel を見つけられない場合、コード生成は使用不可になります。

1.4 モデル間変換構成で、ファイルをターゲット・コンテナーとして指定する必要がある

モデル間変換の変換構成を作成する場合、ターゲット・モデルを表すファイルが空であっても、このファイルを指定する必要があります。URI をターゲット・コンテナーとして指定することはできません。

空の Ecore モデルを作成するには、変換構成エディターまたはウィザードのメインページで、「新規ターゲット・コンテナーの作成」ボタンをクリックし、ターゲット・モデルの拡張子を持つファイルを指定します。

1.5 変換オーサリングと JET 変換の統合は自動ではない

モデル間変換を JET (モデル - テキスト間) 変換のフロントエンドとして統合するには、JETRule フレームワークのインスタンスを、変換プロバイダーにある RootTransformation の「postProcessing」ルールに手動で追加する必要があります。以下の例に、変換提供クラスに含む必要があるコードを示します。「xxx」をご使用の JET 変換の ID に置き換える必要があります。

    /**
     * ルート変換を作成します。ここで、変換にさらにルールを追加することができます
     * <!-- begin-user-doc -->
     * <!-- end-user-doc -->
     * @param transform The root transformation
     * @generated NOT
     */
    protected RootTransformation createRootTransformation(ITransformationDescriptor descriptor) {
        return new RootTransformation(descriptor, new MainTransform()) {
                   protected void addPostProcessingRules() {
                            add(new JETRule("xxx"));
                   }
        };
   }

2.0 既知の問題と回避方法

2.1 UML メタモデルはモデル間マッピングに自動的に追加されない

UML モデルを入力または出力する変換を生成するには、UML メタモデルをマッピング仕様のルート入力、ルート出力、またはその両方として指定します。マッピング仕様へ UML プロファイルを追加しても、UML メタモデルは自動的に追加されません。

回避方法: モデル間変換マッピング・ウィザードおよびエディターで「モデルの追加」ボタンをクリックして、UML メタモデルを追加します。

2.2 フィルター済みプロパティーとの間の変換はマッピング・エディターで破損と表示される場合がある

ユーザーがフィーチャー・フィルター処理を「Basic」から「Intermediate」または「Advanced」のいずれかのモードに切り替え、マッピングを作成してから、「Basic」フィルター・モードに戻した場合、マッピング・コネクターのエンドポイントは表示されなくなる場合があります。これにより、どこにも接続しないエンドポイントを持つマッピング・コネクターが表示されるようになります。これによって影響を受けるのはマッピングの表示のみです。マッピング、および変換がマッピングから生成するソース・コードは影響を受けません。

回避方法: マッピングが作成されたときに有効であったフィルター・モードを指定して、マッピングの表示を訂正します。

2.3 マッピング・ファイルでモデルへの参照のみを削除すると、マッピング・ファイルからモデルが除去される

モデルからの要素をマッピング入力または出力として指定するマッピングがマッピング・ファイルに含まれなくなると、そのモデルはマッピング・ファイルから「除去」されます。未使用のモデルの検査は、マッピング入力または出力が削除されると行われます。分離リストは、入力および出力用のマッピング・ファイルで保守されます。

回避方法: マッピング入力または出力としてモデルから要素を選択する前に、モデルをマッピング・ファイルに追加する必要があります。マッピング・エディターで「モデルの追加」ボタンをクリックして、モデルをマッピング・ファイルに追加します。

2.4 マージ・モードが自動または可視の場合、モデル間変換構成エディターで runSilent オプションを選択できる

生成済みのモデル間変換用の変換構成エディターで、runSilent オプションは「自動」または「可視」を含む任意のマージ・モードで指定できます。マージ・モードが自動または可視に設定される場合、ターゲット・モデルに対するヒューズ・サポートが見つかれば、runSilent オプションではサイレント・マージ戦略が強制されます。それ以外の場合は、オーバーライド・マージ戦略が使用されます。

2.5 プロファイルの登録 ID が使用されない場合、モデルから登録済みプロファイルを持つ uml へのマッピングの際にマージ・エラーが発生する場合がある

Ecore メタモデルからプロファイルを持つ UML メタモデルへの変換マッピング・モデルを作成する場合、ターゲット UML モデルで使用されるプロファイル URI を検査する必要があります。デフォルトでは、マッピング・エディターで指定するプロファイルの URI が使用されます。リソース URI を指定する場合、同等のプラグイン URI に変換されます。

回避方法: プロパティー・ページの profileURI オーバーライド・プロパティーで異なる URI を指定することができます。マッピング・エディターでルート・セクションをクリックし、プロパティー・ページを表示します。注: 登録済みプロファイルを使用している場合、それが自動的に使用されるプロファイルと異なっていれば、そのプロファイルが登録されている URI を指定できます。これに従わないと、登録済みプロファイルがリソース・セットで複数回ロードする場合があり、これによってマージまたはヒューズの問題が発生する場合があります。

2.6 マッピング・モデルからコードを生成する際に、「plugin.xml」および「MANIFEST.MF」を含む基本プロジェクト・ファイルは再生成されない

モデル間変換でマッピング・モデルからコードを生成する際に、plugin.xml および manifest.mf などの基本プロジェクト・ファイルが見つからない場合は生成されます。これらのファイルは、生成された後で編集する必要がある場合があります。

回避方法: