ラウンドトリップエンジニアリング

モデル駆動型アーキテクチャにおけるラウンドトリップエンジニアリング（RTE ）は、ソースコード、モデル、構成ファイル、ドキュメントなどの2つ以上の関連するソフトウェア成果物を相互に同期させるソフトウェア開発ツールの機能です。 ^[1]ラウンドトリップエンジニアリングの必要性は、複数の成果物に同じ情報が存在する場合や、一部の成果物が更新された場合に不整合が生じる可能性がある場合に生じます。たとえば、ある情報が1つの成果物（ソースコード）のみで追加/変更され、その結果、他の成果物（モデル）ではその情報が欠落/不整合になった場合などです。

ラウンドトリップ エンジニアリングは、フォワード エンジニアリング (仕様からソフトウェアを作成する)、リバース エンジニアリング(既存のソフトウェアから仕様を作成する)、リエンジニアリング(既存のソフトウェアを理解して変更する) といった従来のソフトウェア エンジニアリングの分野と密接に関連しています。ラウンドトリップ エンジニアリングは、フォワード エンジニアリングとリバース エンジニアリングの両方を単にサポートするものと誤って定義されることがよくあります。実際、ラウンドトリップ エンジニアリングをフォワード エンジニアリングやリバース エンジニアリングと区別する重要な特徴は、各成果物を段階的に更新して他の成果物に加えられた変更を反映させることで、同時に進化した既存の成果物を同期できることです。さらに、フォワード エンジニアリングは、仕様のみが存在する RTE の特殊なインスタンスと見なすことができ、リバース エンジニアリングは、ソフトウェアのみが存在する RTE の特殊なインスタンスと見なすことができます。多くのリエンジニアリング アクティビティは、以前にリバース エンジニアリングされた仕様に加えられた変更を反映するようにソフトウェアが更新されるときに、RTE として理解することもできます。

様々な書籍で2種類のRTEについて説明されている: ^{[2] : 459}

• 部分的または一方向のRTE: コードとモデルの高レベル表現に加えられた変更は低レベルに反映されますが、それ以外の場合は反映されません。後者は許可される可能性がありますが、高レベルの抽象化に影響を与えない可能性がある制限があります。
• 完全または双方向のRTE: 変更の有無にかかわらず、高レベルと低レベルのコードとモデル表現は、いずれかが変更された場合に同期されます。

ラウンドトリップ エンジニアリングのもう 1 つの特徴は、自動的に検出された不整合に応じて成果物を自動的に更新することです。その意味で、これはフォワード エンジニアリングやリバース エンジニアリングとは異なります。フォワード エンジニアリングやリバース エンジニアリングは、手動 (従来) と自動 (成果物の自動生成または分析経由) の両方が可能です。自動更新は、瞬時またはオンデマンドのいずれかです。瞬時 RTE では、関連する成果物はすべて、成果物の 1 つに変更が加えられるたびにすぐに更新されます。オンデマンド RTE では、成果物の作成者は (分散設定であっても) 成果物を同時に更新し、ある時点でマッチングを実行して不整合を特定し、その一部を伝播して潜在的な競合を調整することを選択できます。

ラウンド トリップ エンジニアリングには、反復的な開発プロセスが含まれる場合があります。モデルを修正されたコードと同期した後でも、コードをさらに修正するか、モデルを変更するかなど、最適な作業方法を自由に選択できます。いつでもどちらの方向にも同期でき、必要に応じてサイクルを何度でも繰り返すことができます。

多くの商用ツールや研究用プロトタイプがこの形式のRTEをサポートしています。2007年の本では、 Rational Rose、Micro Focus Together、ESS-Model、BlueJ 、Fujabaなどがサポート対象として挙げられており、Fujabaはデザインパターンも識別できると言われています。^[3]

例えば、2005 年のVisual Studioに関する書籍では、RTE ツールの一般的な問題は、ツールがソース コードに面倒な注釈を残して支援されない限り、リバースされたモデルが元のモデルと同じではないことであると指摘されています。^[4] UML の動作部分は、RTE にとってさらに多くの課題を課します。

通常、UML クラス図はある程度サポートされていますが、関連付けや包含などの特定の UML 概念は多くのプログラミング言語で簡単に表現できないため、作成されたコードの使いやすさやコード分析/リバース エンジニアリングの精度が制限されます (たとえば、包含はコード内で認識するのが困難です)。

より扱いやすい形式のラウンドトリップ エンジニアリングは、フレームワークのアプリケーション プログラミング インターフェイス(API)のコンテキストで実装されます。これにより、アプリケーションによるフレームワーク API の使用法を記述したモデルが、そのアプリケーションのコードと同期されます。この設定では、API はアプリケーションでフレームワークを使用するためのすべての正しい方法を規定するため、コード内の API の使用法を正確かつ完全に検出できるほか、正しい API の使用法を実装する便利なコードを作成できます。このカテゴリの 2 つの主要な RTE 実装は、フレームワーク固有のモデリング言語とSpring Roo (Java) です。

ラウンドトリップ エンジニアリングは、Object Management Group (OMG) のモデル駆動型アーキテクチャにおいて、複数のモデル間およびモデルとコード間の一貫性を維持するために重要です。OMG は、 MDA に必要なモデル変換を処理するためにQVT (クエリ/ビュー/変換) 標準を提案しました。現在まで^{[いつ? ]}、この標準の実装がいくつか作成されています。(RTE に関連して MDA の実際の経験を示す必要があります)。

モデルからのコード生成(フォワードエンジニアリング) とは、ユーザーがモデルデータによって暗示されるソリューションを抽象的にモデル化し、自動化ツールがモデルからソフトウェアシステムのソースコードの一部または全部を派生させることを意味します。一部のツールでは、ユーザーはソースコードテンプレートの形式でプログラムソースコードのスケルトンを提供でき、コード生成プロセス中に定義済みのトークンがプログラムソースコードの一部に置き換えられます。

UML（MDA に使用される場合）ダイアグラム仕様は、プログラムソースでカバーされているのと同じ情報を含めるために必要な詳細が欠けていると批判されました。開発者の中には、「コードが設計である」と主張する人もいます。[ ^{5] [6]}

生成されたコードがモデルと急速に異なる、またはリバースエンジニアリングされたモデルがコードへの反映を失う、あるいは循環的なリエンジニアリングの取り組みの結果としてこれら2つの問題が混在するといった重大なリスクがあります。^[7]

ステートチャート図のような機能に対するUMLの振る舞い/動的部分に関しては、プログラミング言語に同等のものはありません。コード生成中にそれらを翻訳すると、共通のプログラミングステートメント（.eg ）が欠落するか、誤って解釈されます。編集してインポートし直すと、異なるモデルまたは不完全なモデルになる可能性があります。^{[8] [9 ]}パターン実装とユーザー固有のロジックのコード生成段階で使用されるコードスニペットについても同様です。混在すると、簡単にリバースエンジニアリングできない場合があります。^{[8] [9]}if,switch,enum

また、汎用プログラミング言語やドメイン固有言語向けの最新のIDE（テスト、デバッグ、ナビゲーションなど）に匹敵するモデリング用の高度なツールも一般的に不足しています。^[9]

おそらく、ラウンドトリップ エンジニアリングの最も一般的な形式は、UML ( Unified Modeling Language ) モデルと、データ モデリングおよびデータベース モデリングにおける対応するソース コードおよびエンティティ リレーションシップ ダイアグラムとの間の同期です。

統一モデリング言語(UML)に基づくラウンドトリップエンジニアリングには、ソフトウェア開発のための 3 つの基本ツールが必要です。^{[引用が必要]}

• ソースコードエディター;
• 属性とメソッド用の UML エディター。
• UML構造の視覚化