効果的なバージョン管理と構成管理は、ソフトウェア開発プロジェクトにおいて常に非常に重要です。
1. バージョン管理の概念
MDSD プロジェクトでは、次の側面を管理し、バージョン管理する必要があります。
- ツールを生成します。現在、ツール自体はまだ開発中であるため、バージョン管理することは理にかなっています。
- ジェネレーター構成: ドメイン アーキテクチャの生成された部分。これには、DSL/構成ファイル定義、メタモデル、テンプレート、変換が含まれます。
- ドメイン アーキテクチャの非生成部分: MDSD プラットフォーム。
- アプリケーション自体: モデル、仕様、および手作業で開発されたコード。
理想的には、生成されたコードは、いつでもモデルから再現でき、実際のプログラム ソース コードを構成しないため、バージョン管理されません。もちろん、この考え方は、ファイル システム内で手動で作成されたコードと生成されたコードが構造的に分離されている場合にのみ現実的に適用できます。
モデル駆動開発の 1 つの目標は、同じドメイン アーキテクチャに基づいていくつかのアプリケーションを開発することです。したがって、プラットフォームとジェネレーターの構成をアプリケーションから完全に分離する必要があります。
2. プロジェクトと依存関係
焦点は、さまざまなプロジェクトのバージョンを含む依存関係の管理にあります。アプリケーション プロジェクトの場合、プロジェクトがどのバージョンのドメイン アーキテクチャに基づいているかを指定する必要があります。基盤となるプラットフォームが改善された場合、ドメイン アーキテクチャ、場合によってはアプリケーション プロジェクトも同時に改善する必要がある可能性があります。フレームワークのメタファーを使用してこれを実証できます。ドメイン アーキテクチャをフレームワークとして想像してください。フレームワークを改善する場合は、クライアント アプリケーションを変更する必要があります。これらは同じ関連性があるため、ドメイン アーキテクチャの改善にも同じアプローチが適用されます。
3. アプリケーションプロジェクトの構造
プロジェクト、アーティファクト、およびリポジトリ
上の図は、アプリケーション プロジェクトが最上位レベルでどのように設定され、ジェネレーターとコンパイラーがそれをどのように利用するかを示しています。
アプリケーションのモデルと手動で作成したコードは、アプリケーション リポジトリに存在します。ジェネレーターは、構成ファイルなどを含むジェネレーター構成に基づいて生成されたコードを作成します。構成ファイルはドメイン アーキテクチャ リポジトリにあります。次に、ビルド スクリプトを使用してアプリケーションが生成されます。このステップでは、アプリケーションとプラットフォームの手作りコードを使用し、ドメイン アーキテクチャ リポジトリからプラットフォームの手作りコードを取得します。
4. 混合ファイルのバージョン管理と構築プロセス
生成されたコードと生成されていないコードを完全に分離することが常に可能または現実的であるとは限りません。関連する例としては次のようなものがあります。
- J2EE デプロイメント記述子のカスタム コード。
- JSP ファイル内のカスタム コード。
- プロパティ ファイルまたはその他の構成ファイル内のカスタム コード。
一般に、これらはターゲット言語が適切な委任メカニズムを提供していない場所です。
明らかに、この保護領域を使用すると、生成されたコードと生成されていないコードが混在するファイルが作成されます。ここでの問題は、これらのファイルは通常、全体としてのみバージョン管理できることです。結局のところ、生成されたコードはソースではなく、ソースがコードの生成元のモデルとなるため、これは冗長なコードが登録されるという事実につながります。
この冗長なコードは、チーム開発中に不整合を引き起こす可能性があります。この矛盾は、チームが進化するにつれてさらに大きな問題になるでしょう。
開発者間のマージ競合は、リポジトリ内のアプリケーション ソースのみを使用して検出されます。
私たちの意見では、生成されたコードと生成されていないコードを分離することが望ましいアプローチであり、どのような場合でも試みられるべきであることを再度強調しておく必要があります。
5. チーム内でのモデリングと一部のモデルのバージョン管理
大規模なシステムはパーティション化する必要があります。それらの構成部分またはサブシステムは、多かれ少なかれ互いに独立して開発されます。インターフェイスは、システムがどのように対話するかを定義します。通常の統合ステップでは、各部分を統合します。このアプローチは、パーツが別の場所または別のチームによって開発されている場合に特に役立ちます。もちろん、これは主に開発プロセスとチーム内のコミュニケーションに影響を与え、おそらくシステム アーキテクチャにも影響します。
1. パーティションとサブドメイン
まず、パーティショニングとサブドメインの使用の違いを指摘することが重要です。
サブドメインは、システム全体を分離する側面です。各サブドメインには独自のメタモデルと DSL があります。さまざまなメタモデルは、ゲートウェイ メタクラスを通じて概念的に統合されます。エンタープライズ システムのコンテキストでは、これらはサブドメインのビジネス プロセス、永続性、GUI などです。
代わりに、パーティションはシステムの部分の定義を記述します。プロジェクトの効率的な構成や複雑さの理由から、技術的に類似した多数の要件を、インターフェイスを使用して統合できる個別の部分に分解します。
2. 生成されたさまざまなソフトウェア アーキテクチャ
プロジェクトの異なるパーティションで異なるビルド アーキテクチャが使用されている場合、生成されたアーティファクトが連携して動作するかどうかという疑問が生じます。一般に、これは、生成されたコード レベルで統合が行われる必要があることを意味します。例として、さまざまなバージョンのビルド インフラストラクチャが利用され、そのすべてが包括的な J2EE アプリケーションの一部を作成すると仮定します。
3. DSLの開発
DSL は通常、プロジェクト全体にわたって開発を続けます。DSL は、ドメインに関する知識と理解が成長し深まるにつれて進化します。作業を容易にするために、DSL の開発中に下位互換性が維持されるようにする必要があります。
4. 分割と統合
おそらく、あるチームが別のチームのコードを使用するコンポーネントを実装しているため、異なるチームが同じインターフェイスを必要としているとします。
実行される作業がモデル駆動型である場合、少なくとも 2 つのモデルにインターフェイスを備えたモデルを適用する必要があります。ただし、両方のモデルで情報を複製する際に一貫性の問題が発生するため、このアプローチは理想的ではありません。ツールによっては、他のオプションも存在します。
1). モデルへの統合
モデリング ツールがサポートしている場合は、インターフェイスが 1 か所のみに存在し、両方のモデルから参照されるようにする必要があります。ジェネレーターの観点から見ると、これにより一貫したモデルが生成されます。
このアプローチが可能かどうかは、モデリング ツールによって異なります。UML ツールの中でも、離散モデリングをサポートするリポジトリ ベースのツールが理想的な選択肢です。
2). ジェネレーターでのモデル同期による統合
モデリング ツールが適切な統合の選択肢を提供しない場合、統合はジェネレーター レベルで行われることもあります。ジェネレーターは、各行に特定のモデル要素が含まれるいくつかの入力モデルを読み取ります。
この場合、ジェネレーターのタスクは、考えられる一貫性の問題を解決することです。
3). ジェネレーターでの参照による統合
さらなる統合オプションは、参照を使用することです。