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

© 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 マージ・モードが automatic または visual の場合、モデルからモデルへの変換構成エディター内で 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 はルート変換です
     * @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 メタモデルは自動的には追加されません。

回避方法: 「モデルからモデルへの変換マッピング (Model-to-Model Transformation Mapping)」ウィザードおよびエディターの「モデルの追加」ボタンをクリックして、UML メタモデルを追加します。

2.2 フィルターされたプロパティー「への」変換およびそのプロパティー「からの」変換の場合、マッピング・エディターでのその表示が壊れることがある

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

回避方法: マッピングの作成時に有効であったフィルター・モードを指定すると、マッピングの外観を訂正できます。

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

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

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

2.4 マージ・モードが automatic または visual の場合、モデルからモデルへの変換構成エディター内で runSilent オプションを選択できる

生成後のモデルからモデルへの変換用の変換構成エディターでは、automatic や visual を含め、任意のマージ・モードを使用して runSilent オプションを指定することができます。マージ・モードを automatic または visual に設定してから、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 などの基本プロジェクト・ファイルが見つからない場合、これらのファイルは生成されます。これらのファイルは、生成後に編集しなければならない場合があります。

回避方法: