Loading article…
モデル駆動型アーキテクチャのコンテキストにおけるラウンドトリップエンジニアリング（RTE ）は、ソースコード、モデル、構成ファイル、ドキュメントなど、関連する 2 つ以上のソフトウェア成果物を相互に同期するソフトウェア開発ツールの機能です。 [ 1 ]ラウンドトリップエンジニアリングの必要性は、同じ情報が複数の成果物に存在し、一部の成果物が更新された場合に不整合が生じる可能性がある場合に発生します。たとえば、ある情報が 1 つの成果物 (ソースコード) にのみ追加または変更され、その結果、他の成果物 (モデル) ではその情報が欠落したり、不整合が生じたりします。
ラウンドトリップエンジニアリングは、従来のソフトウェアエンジニアリングの分野、すなわちフォワードエンジニアリング（仕様からソフトウェアを作成する）、リバースエンジニアリング（既存のソフトウェアから仕様を作成する）、およびリエンジニアリング（既存のソフトウェアを理解して修正する）と密接に関連しています。ラウンドトリップエンジニアリングは、フォワードエンジニアリングとリバースエンジニアリングの両方をサポートするものと誤って定義されることがよくあります。実際には、フォワードエンジニアリングやリバースエンジニアリングとラウンドトリップエンジニアリングを区別する重要な特徴は、各アーティファクトを段階的に更新して他のアーティファクトに加えられた変更を反映させることで、同時に進化してきた既存のアーティファクトを同期できる点にあります。さらに、フォワードエンジニアリングは仕様のみが存在するRTEの特殊なケースと見なすことができ、リバースエンジニアリングはソフトウェアのみが存在するRTEの特殊なケースと見なすことができます。ソフトウェアが以前にリバースエンジニアリングされた仕様に加えられた変更を反映するように更新される場合、多くのリエンジニアリング活動もRTEとして理解できます。
様々な書籍で2種類のRTEについて説明されている：[ 2 ]： 459
ラウンドトリップエンジニアリングのもう1つの特徴は、自動的に検出された不整合に応じて成果物が自動的に更新されることです。この点で、ラウンドトリップエンジニアリングは、手動（従来）と自動（成果物の自動生成または分析による）の両方が可能なフォワードエンジニアリングやリバースエンジニアリングとは異なります。自動更新は、即時またはオンデマンドのいずれかです。即時RTEでは、関連するすべての成果物が、いずれかの成果物に変更が加えられるたびに即座に更新されます。オンデマンドRTEでは、成果物の作成者は（分散環境であっても）成果物を同時に更新し、ある時点でマッチングを実行して不整合を特定し、その一部を送信して潜在的な競合を解消することを選択できます。
往復エンジニアリングでは、反復的な開発プロセスが必要となる場合があります。モデルを改訂されたコードと同期させた後も、コードのさらなる修正やモデルの変更など、最適な作業方法を自由に選択できます。同期はいつでもどちらの方向にも行うことができ、必要な回数だけサイクルを繰り返すことができます。
多くの商用ツールや研究プロトタイプがこの種の RTE をサポートしています。2007 年の書籍では、Rational Rose、Together、ESS-Model、BlueJ、Fujabaなどが対応可能とされており、Fujaba はデザインパターンも識別できるとされています。[ 3 ]
2005年に出版されたVisual Studioに関する書籍では、例えば、RTEツールの一般的な問題として、ソースコードに面倒な注釈を残してツールを支援しない限り、反転されたモデルが元のモデルと同じにならないことが挙げられると指摘されている。[ 4 ] UMLの振る舞いの部分は、RTEにとってさらに多くの課題を突きつける。
通常、UMLクラス図はある程度サポートされていますが、関連や包含関係といったUMLの概念は、多くのプログラミング言語では直接表現できないため、作成されたコードの使いやすさやコード分析/リバースエンジニアリングの精度が制限されます（例えば、コード内で包含関係を認識するのが難しいなど）。
より扱いやすいラウンドトリップエンジニアリングの形態は、フレームワークのアプリケーションプログラミングインターフェース（API）のコンテキストで実装されます。これは、アプリケーションによるフレームワークAPIの使用方法を記述するモデルが、そのアプリケーションのコードと同期されるというものです。この設定では、APIはアプリケーションでフレームワークを使用できるすべての正しい方法を規定するため、コード内のAPI使用箇所を正確かつ完全に検出できるだけでなく、正しいAPI使用方法を実装する有用なコードを作成することも可能になります。このカテゴリにおける代表的なRTE実装としては、フレームワーク固有のモデリング言語とSpring Roo（Java）が挙げられます。
オブジェクト管理グループ（OMG）のモデル駆動型アーキテクチャでは、複数のモデル間、およびモデルとコード間の一貫性を維持するために、ラウンドトリップエンジニアリングが不可欠です。OMGは、MDAに必要なモデル変換を処理するために、 QVT （クエリ/ビュー/変換）標準を提案しました。現在までに、この標準の実装はいくつか作成されています。（ラウンドトリップエンジニアリングと関連付けたMDAの実践的な経験を示す必要があります。）
モデルからのコード生成（フォワードエンジニアリング）とは、ユーザーがモデルデータによって示されるソリューションを抽象的にモデル化し、自動化ツールがそのモデルからソフトウェアシステムのソースコードの一部または全部を生成することを意味します。一部のツールでは、ユーザーがプログラムのソースコードの骨組みをソースコードテンプレートの形で提供することができ、コード生成プロセス中に、あらかじめ定義されたトークンがプログラムのソースコードの一部に置き換えられます。
UML（MDAで使用される場合）図の仕様は、プログラムソースでカバーされている情報と同じ情報を含めるために必要な詳細が欠けているとして批判された。一部の開発者は「コードが設計である」とさえ主張している。 [ 5 ] [ 6 ]
繰り返しの再設計作業の結果、生成されたコードがモデルと急速に異なる、あるいはリバースエンジニアリングされたモデルがコードに反映されなくなる、あるいはこれら2つの問題が混在する深刻なリスクがある。[ 7 ]
UMLのステートチャート図などの機能の振る舞い/動的な部分に関しては、プログラミング言語には同等のものはありません。コード生成中にそれらを翻訳すると、一般的なプログラミングステートメント (.eg if,switch,enum) が欠落するか、誤って解釈されることになります。編集してインポートし直すと、異なるモデルまたは不完全なモデルになる可能性があります。[ 8 ] [ 9 ]パターン実装とユーザー固有のロジックのコード生成段階で使用されるコードスニペットについても同様です。これらが混在すると、簡単にリバースエンジニアリングできない可能性があります。[ 8 ] [ 9 ]
また、汎用プログラミング言語やドメイン固有言語向けの最新のIDE（テスト、デバッグ、ナビゲーションなど）に匹敵する高度なモデリングツールが一般的に不足している。[ 9 ]
おそらく最も一般的な往復エンジニアリングの形態は、UML（統一モデリング言語）モデルと、データモデリングおよびデータベースモデリングにおける対応するソースコードおよびエンティティ関係図との間の同期です。
統一モデリング言語（UML）に基づく往復エンジニアリングでは、ソフトウェア開発のために3つの基本的なツールが必要です。