ソース要素とターゲット要素の関係は、変換に含まれるルールのセットによって 定義されています。 これらのルールの実行は、 要素のソース・セットのトラバース方法を理解するルール・セットに基づいています。 変換は、そのルールにより多くの情報を適用するためにプロファイルに依存している場合があります。
変換サービス (およびパターン) によって、UML モデルとコード間、および、 異なる抽象化レベルのモデル間のギャップを埋めることができます。変換は、特に以下のように行われます。
また、変換はパターンを実装して、フォーム間で要素を変換することができます。 本製品に付随してインストールされる変換は、 Rational® Software Architect のコマンドを 介して使用可能です。
最も一般的な変換の開始点は、 クラス・モデルなどのプラットフォーム独立モデル (PIM) です。 クラス・モデルには、実装の仕様書への参照がない設計要素が含まれています。 クラス・モデルの作成、変更、および注釈付けを行い、次に変換を使用して、 Java™ トピック図やコード・レベルのテキストなどの、プラットフォーム特化モデル (PSM) を生成することができます。
パッケージ化の一部として、パターンは、 固有のレベルの抽象化または固有のメタモデルを行き来する場合に 実行される追加ルールを定義する、変換の拡張を定義して提供することもできます。 この概念の一般的な実装は、 特定コードを生成する変換ルールを提供するデザイン・パターンです。 これらのルールは、コード変換 (例えば、 Java または C++ 変換) を拡張して、 生成される出力にパターン固有のコードを提供することになります。
特定の変換を適用するには、以下の 4 つの情報が必要です。
モデル変換の基本プロセスには、以下のステップがあります。
変換が完了した結果、ターゲット・モデルまたは テキスト、および追跡の目的のための変換のレコードが 生成されます。 モデルからテキストへの変換では、その出力は、 Java または C++ コード、 データベース作成および取り込み用の DDL ファイル、単体テスト、または対応するモデル図に一致 する可視化図になります。 変換のレコードには、ソース・モデルの要素からターゲットの対応する要素へのマップ が含まれています。このマップは、マッピングのどの部分が変換の各部分に使用されたかを示しています。
変換 API を使用して、変換を新規作成することができます。変換サービスは汎用であり、ソース・モデル、
ターゲット・モデル、または変換自身の実装に関する
前提事項はありません。
変換サービスにはデフォルトの変換エンジンが内蔵されていますが、
変換の作成者はまったく別のエンジンを使用することができます。
しかし、デフォルトのエンジンで変換をビルドすることによって、
変換の作成者は論理デバッグ環境、拡張性機構、
およびそのアーキテクチャーに対する将来の改善点のすべてを利用することができます。