変換構成は、ファイル名拡張子 .tc を持ち、変換が予想通りの出力を生成するために使用する情報が含まれます。また、変換構成には、 特定のタイプの変換に固有の情報も含まれています。既存の変換構成を編集するには、ワークスペース・リソースを示すビューで変換構成ファイルをダブルクリックし、変換構成エディターを開きます。
このオプションによって、後方変換の「getter と setter メソッドを生成」オプションと同じ変換プロパティーが変更されます。 チェック・ボックスのどちらか一方かを選択すると、他方のチェック・ボックスはクリアしたことになります。 後方変換を実行する際には Java getter および setter を生成し、前方変換を実行する際には Java getter および setter の UML 操作をターゲット UML モデルに表示しない場合は、このチェック・ボックスをクリアしてください。
変換ターゲットが既存の UML モデルである場合、ターゲット・モデルと同じパッケージ構造を指定してください。これにより、ターゲット・モデルと変換によって生成された一時モデル間で解決する必要のある差異の数を減らします。
例えば、ソース Java プロジェクトにクラス a.b.Y および a.b.c.Z が含まれているとします。 このチェック・ボックスを選択した場合、変換によって UML パッケージ a.b および a.b.c が生成されます。 これらのパッケージは階層になっていません。 UML クラス Y は UML パッケージ「a.b」内に作成され、UML クラス Z は、UML パッケージ 「a.b.c」内に作成されます。変換によりフラット・パッケージ構造を生成させるようにした場合は、UML パッケージ a が作成されます。UML パッケージ b は UML パッケージ a 内に作成され、UML パッケージ c は UML パッケージ b 内に作成されます。また、UML クラス Z はパッケージ c 内に作成され、UML クラス Y はパッケージ b 内に作成されます。
ログ・ファイルは、ソース要素、ターゲット要素、および変換によってソース要素が変換されるときに適用される規則に関する情報を提供します。変換が多数の要素を変換する場合、変換がログ・ファイルを生成している間はパフォーマンスが低下することがあります。そのため、ログ・ファイルを生成するのは、デバッグ目的の場合のみにしてください。
サイレント・モードで変換を実行すると、変換によって生成されるすべてのダイアログ・ボックスが抑制されます。 変換ではデフォルトの規則と振る舞いが適用され、予期しない変換出力や不正確な変換出力が生成されることがあります。サイレント・モードでの変換の実行は、変換出力の検証ではなく、変換の実行を検証する場合のみ実行してください。例えば、自動化されたタスクや自動化されたテスト・スイートの一部として、変換をサイレント・モードで実行することがあります。
変換がサイレント・モードで実行されるよう設定すると、指定したファイル上書きオプションがオーバーライドされ、必要に応じてファイルが上書きされます。
UML から Java変換が使用可能な場合、「サイレント・モードで後方変換を実行」チェック・ボックスを選択することができます。サイレント・モードで UML から Java 変換、または後方変換を実行するように指定すると、変換構成で指定したファイル上書きオプションがオーバーライドされます。 UML から Java 変換では、必要に応じて、ファイルを上書きします。
トレース関係とビジュアル開発ツールを使用して、ソース・モデル要素と変換出力の関係を理解することができます。 この機能は、複数のモデルおよび変換構成を持つような大規模なプロジェクトの場合に便利です。 ソース・モデルは変換によって変更されません。
列挙型リテラルの名前と値を保持する UML 列挙を生成するには、「com.ibm.xtools.transform.java.enumext.j2u.transform」チェック・ボックスを選択します。 カスタム Java 列挙のプロパティーは、UML への変換時に保持されます。
ソース・プロジェクトの Java コレクション型ごとに、変換によって生成される UML コレクション型を指定できます。1 つの Java コレクション型は、1 つの UML コレクション型にマップできます。デフォルトの選択では、Java の Collection、SortedSet、List、および Set クラスが、UML の Bag、OrderedSet、Sequence、および Set コレクション型にマップされます。変換を実行する際、コードで Java コレクションまたは配列を識別でき、しかもコレクションまたは配列の タイプも識別できる場合、変換では、生成済み UML 要素に «JavaCollection» または «JavaArray» ステレオタイプを適用し、それらのステレオタイプ・プロパティーの値を取り込みます。 その他の場合、変換により、適応可能な参照が生成され、生成済み UML 要素にステレオタイプは適用されません。
例えば、Java Vector クラスを UML シーケンスに変換する場合、Java List クラスではなく、「シーケンス」リストから「java.util.Vector」を選択します。 ソースの Java プロジェクトの Java List クラスごとに、変換により、ターゲット UML モデル内に適応可能な参照が生成され、生成された UML 要素の「順序付け」プロパティーおよび「固有」プロパティーは false に設定されます。この例では、変換によって Java List コレクション型が UML コレクション型に変換されないため、変換によってこれらのプロパティーが false に設定されます。
Java コレクションを変換する際に変換で UML コレクション・プロパティーがどのように取り込まれるかについて詳しくは、以下の関連リファレンスのトピックを参照してください。
Java から UML への変換では、マッピング・モデルを使用して、変換によって生成された UML 要素の該当する名前を判別します。例えば、UML モデルは PackageA を含み、PackageA は Class1 を含む場合を考えてみます。UML から Java 変換にマッピング・モデルを作成する場合、Class1 が、 MappedClass1 という代替ファイル名を持つように指定できます。UML から Java への変換を実行する場合、PackageA.MappedClass1.java という名前の Java ファイルが生成されます。 Java から UML への変換を実行する場合、変換により、Java 要素のオリジナルの UML パスが PackageA.Class1 であると判別され、PackageA という UML パッケージに Class1 という UML クラスが生成されます。
マッピング・モデルで指定する成果物のファイル名が無効な Java ファイル名である場合、変換により、Java コード要素の作成時にそのファイルの名前が変更されます。例えば、マッピング・モデルが MappedClass1 ではなく、「Mapped Class1」という代替ファイル名を指定する場合、変換によって Mapped_Class1.java という名前の Java ファイルが生成されます。変換は、これらの変更記録を保持しないので、Java から UML への変換では、Mapped_Class1 ファイルはオリジナルの UML 要素にマップされません。この例では、Java から UML への変換で、Mapped_Class1 Java ソース・オブジェクトが、Class1 ではなく、Mapped_Class1 という名前の UML クラスに変換されます。