1. はじめに
この章では、プロジェクトでのモデル駆動コンポーネント開発の使用を可能にし、サポートする重要で実証済みのプロセス成果物を紹介します。
ほとんどのプロセスと実践は、一般的な (つまり、アーキテクチャ中心ではない) MDSD に非常に簡単に移行できます。アーキテクチャ中心の場合にのみ意味をなすテクニック、または特定の解釈を必要とするテクニックも、明示的にマークされています。
これらのベスト プラクティスを、反復的で柔軟な開発プロセスにネストすることをお勧めします。MDSD は後者と矛盾するものではなく、実際にはその利点を高めるのに適しています。理論的には、MDSD をウォーターフォール開発プロセスと組み合わせることもできます。ただし、ウォーターフォール手法のよく知られたリスクは依然として存在するため、MDSD とはまったく関係のない私たちがその使用を推奨しません。
2. アプリケーション開発とドメインアーキテクチャ開発の分離
1. 基本原則
形式モデルの基礎としてのドメイン依存分析とドメイン アーキテクチャ
MDSD をサポートする最も重要なアイデアの 1 つは、正式なモデリングのステップには、相互に関連していないものの、ほぼ並行して開発できる 2 つの前提条件が含まれていることです。
- 特定のアプリケーションの反復的または定期的な機能/特殊なニーズを把握しておく必要があります。
- モデリング用の形式言語 (DSL) を定義する必要があります。さらに、自動でさらなる処理を行うには、言語を変換ルールの形式で具体的な MDSD プラットフォームにバインドする必要があります。これが「ドメイン アーキテクチャ」という用語の概要です。
その名前が示すように、ドメイン アーキテクチャは構造化され、ドメインをサポートします。原則として、このドメインは個々のアプリケーションから独立しています。つまり、ソフトウェア システムのファミリーをカバーします。
上に示したアクティビティ図をウォーターフォール プロセスとして誤解しないでください。これは主に、各反復の基礎となる基本原則を示しています。
フォーマル モデリングは、アプリケーション固有の概念をドメイン アーキテクチャによって提供される概念に結び付けるために使用されます。より正確には、ドメイン アーキテクチャによって提供される言語 (DSL) を使用して機能を表現します。ジェネレーターのサポートを使用して形式モデルを変換し、プラットフォームにマッピングします。
2. ドメイン アーキテクチャ開発スレッド
ドメイン アーキテクチャの作成を支援するには、いくつかのアーティファクトとアクティビティが必要です。MDSD アーキテクチャ開発スレッドの目標は、再利用可能な行と品質と効率の向上です。プロセスの観点から見ると、これは MDSD の中心的な側面です。したがって、次の図は、まずドメイン アーキテクチャの作成アクティビティを拡大して示しています。
ドメインアーキテクチャの作成
図に示されているパーティションは、アクティビティをドメイン、変換、プラットフォームの 3 つのカテゴリに分割します。各カテゴリで、ドメイン アーキテクチャのアーティファクト (濃い緑色で表示) が生成されます。ここでは、最も重要な関連性を持つ通常のケースの状況のみが表示されます。これは、私たちの経験では、他のすべてを含めると本質的な問題を表示から取り除くことが不可能になるためです。特に、反復ループは示されていません。
1) プロトタイピング
プロジェクトの開発時には、通常、J2EE や特定のフレームワークなど、期待されるプラットフォームがすでに存在しています。MDSD アーキテクチャ開発スレッドの 1 つの目標は、これらのアーティファクトを意味的に豊富なドメイン固有の MDSD プラットフォームとマージすることです。したがって、最初に概念実証としてプロトタイプに関する関連する経験を収集することが常に意味があります。さらに、このプロトタイプは MDSD プラットフォームに向けた最初のステップと考えることもできます。
2) 開発プラットフォーム
プラットフォームは、生成されたコードと生成されていないコードの両方の基礎を形成し、移行をシンプルに保つために使用されます。ドメイン アーキテクチャの生成された部分は、使用されるランタイム システム コンポーネントに依存しますが、その逆は当てはまりません。
プラットフォームの開発も反復的に進める必要があります。この環境で成犬のテクニックを適用すると、メリットが得られます。
さらに、プラットフォームと生成されたコードの間の境界は、ドメイン アーキテクチャの進化中にどちらの方向にも変化する可能性があります。
3) リファレンス実装を作成する
リファレンス実装は、MDSD アーキテクチャ開発スレッドの中間結果にすぎませんが、ドメイン アーキテクチャの作成を開始する場合には非常に重要です。
リファレンス実装は、必要に応じて実装に関するアドバイスを導き出すことができる単純な孤立した例と誤解されるべきではありません。参照実装はプロトタイピングによって作成できますが、その参照実装はより重要な目的を果たします。つまり、参照モデル/設計と組み合わせて、用語ドメインの DSL のアプリケーションと実装をマスクします。この大気への二部構成の参照は、各プラットフォームでのモデルから実装への移行を例示しています。新しいソフトウェア システム ファミリの場合、リファレンス実装は最初に手動で作成されます。その後、その参照実装から変換を導出します。参照モデルの生成実装は、おそらく手動でプログラムされたドメイン ロジックと組み合わせて、完全な実行可能な参照実装を生成する必要があります。
リファレンス実装の完全な付加価値は、リファレンス実装とリファレンス モデルの間の相互作用を通じてのみ得られます。参照される実装の特定の機能内容は本質的には無関係であり、単にドメインの問題です。
4) ドメイン分析・設計
このアクティビティは主に、ドメインのメタモデルと適切な具体的な DSL を見つけるために役立ちます。ここには、DSL を構築するためのベスト プラクティスのみがリストされています。
アーキテクチャ中心の DSL は、デザイン言語としても知られています。この設計言語の基礎として UML がよく使用されます。ただし、GUO レイアウトのモデリングなど、UML がまったく使用できない領域があるため、別の表記法を使用する必要がある場合があります。結局のところ、具象構文は常に、抽象構文ほど重要ではないオレンジの存在を前提としています。
DSL の概念によれば、アーキテクトは生成されたコードとドメイン ロジックの間に境界線を引く必要もあり、これにより開発者の自由度が得られます。
適切なモデリング言語の定義は、間違いなく MDSD における最も重要な課題です。
5) 参照モデル/デザインを作成する
参照モデルは、DSL のメソッドを通じてドメイン インスタンスを表現するため、DSL のインスタンスです。
参照実装の相互作用は非常に重要です。参照モデルと参照実装は一緒に DSL の構文とセマンティクスをインスタンス化し、ドメイン アーキテクチャの概念を具体的に記述します。
6) アーカイブプログラミングモデル
プログラミング モデルの定義は、ドメイン アーキテクチャに、実行可能なアプリケーションの作成を可能にするために、アプリケーション開発者がプログラミング言語で補完する必要があるモデル変換を通じて現れるコード フレームワークを表す「セマンティック ギャップ」が含まれている場合にのみ関係します。
MDSD のコンテキストでは、プログラミング モデルは、ドメイン アーキテクチャに対するアプリケーション開発者の見解を記述します。
プログラミング モデルは、表の形式で文書化するのが非常に簡単です。この表には、DSL のそれぞれの構成に加えて、参照モデルおよび参照実装の適切な抜粋への参照が含まれています。
DSL を使用して特定のアプリケーションを開発する方法を開発者に説明するウォークスルー形式のガイドが、最も適切なアプローチであることがわかりました。このようなガイダンスでは、DSL や、手動で記述する必要があるコードやジェネレーター ツールの操作/統合方法など、プログラミング モデルのその他の側面をカバーする必要があります。
7) 派生変換
このアクティビティは、自動変換によって特定のアプリケーション モデルを実装モデルまたはプログラム モデルに変換できる範囲で、プラットフォームおよびプログラミング モデルへの DSL のマッピングを形式化します。
アプリケーションのドメイン ロジックを DSL で完全に表現できない場合は、生成されたコードと生成されていないコードを統合する技術が必要になります。
8) DSL エディタを作成する
標準ツールを適用できるため、有効性の程度はさまざまですが、すべての DSL が UML プロファイルであるわけではありません。非常に特殊なドメインでは、DSL 準拠のドメイン モデルを定義するための特定のツールを作成することが非常に実用的で望ましいため、人間工学と MDSD アプローチの有効性がさらに高まります。これはコストと価値の比率の問題である可能性があり、個々の状況でのみ答えることができます。
3. アプリケーション開発スレッド
アプリケーション開発スレッドのアクティビティ
ここでは、反復ループを使用しない、非常に単純で通常のケースを示します。ステップの強度に応じて、サイクルは数日から数分になることがあります。
1) 正式なモデリング/デザイン
このステップには分析スレッドとアーキテクチャ スレッドが関与します。機能要件はドメイン アーキテクチャ言語 (DSL) で表現されます。参照モデルは、この環境における方向性のガイドとして機能します。このステップには情報のフィードバックと人間の判断が必要なため、自動化することはできません。
2) 生成する
このステップは完全に機械化して実行できます。正式なモデルと比較すると、情報の利得は生成されません。ドメイン アーキテクチャの変換を通じて、MDSD プラットフォームに適した形式に自動的に変換されます。
3) 手動による実装
DSL で表現できないドメイン ロジックは、生成後に手動で追加する必要があります。私たちのケーススタディでは、これらは完全に実装者フレームワークの保護領域内にあります。
ドメイン アーキテクチャの相互作用は、実装中にも発生する可能性があります。プロジェクトの組織化では、必要なフィードバック ループを考慮する必要があります。
4) 組織的側面
理想的には、アプリケーション開発とドメイン アーキテクチャ開発の分離は、適切な開発構造だけでなく、チーム、プロジェクト、または会社の組織構造を変更することによってもサポートされます。
3. 二重軌道の反復開発
次に、アプリケーション開発とドメイン アーキテクチャ開発の間の役割と成果物の分離について説明します。このセクションでは、2 つのスレッドの同期について説明します。使用されるすべてのフレームワークと同様に、アプリケーション開発からドメイン アーキテクチャ開発までは明らかに相関関係があります。要件管理の観点から見ると、これは、アプリケーション開発チームがドメイン アーキテクチャの開発における顧客の役割を引き受けることを意味します。
二重軌道の反復開発
同期されたタイムボックスに基づく増分反復プロセスは、反復ループに入る前のドメイン分析を妨げるものではないことに注意してください。実際には、ドメインの基本概念をよく理解することが必要です。アプリケーション開発が継続している限り、アーキテクチャ分析の一部としてさらなるドメイン分析が繰り返し行われますが、現在は独自のプロジェクトに委任されています。
4. ターゲットアーキテクチャの開発プロセス
ドメイン アーキテクチャ開発プロセスのベスト プラクティスは 1 つの側面にすぎません。考慮すべきその他の重要な側面は次のとおりです。
- 適切なターゲット アーキテクチャを考え出すにはどうすればよいでしょうか?
- 「MDSD対応」にする方法は?
- 重要なプロジェクトでそれをどのように実装するか?
1.3段階
ソフトウェア アーキテクチャの開発、特に MDSD 環境での使いやすさの開発は 3 つの段階に分ける必要があります。コアの種類のアーティファクトが各フェーズで作成されます。これらについては、以下で簡単に説明します。
- 詳細な説明
- 繰り返します。
- オートメーション。
2. フェーズ 1: 詳細な説明
このフェーズのベスト プラクティスは、ドメイン アーキテクチャ開発スレッドのプロトタイピング、プログラミング モデルの文書化、プラットフォーム開発などのアクティビティに関連しています。
1) テクノロジーに依存しないアーキテクチャ
2) プログラミングモデル
テクノロジーに依存しないアーキテクチャが定義され展開されたら、開発者はそのアーキテクチャに従って機能を実装する必要があります。
3) テクノロジーマッピング
ソフトウェアは、ある程度のサービス品質を提供する必要があります。プロジェクトの一部として QOS を実装するのは非常に高度なコードです。チームに適切なテクノロジーが存在していない可能性もあります。
4) プラットフォームを模倣する
開発者はプログラミング モデルに基づいて、アプリケーションを構築する方法を理解できるようになりました。さらに、開発者は、少なくとも単体テストを実行するために、システムをローカルで実行できる必要があります。
5) 垂直プロトタイプ
アーキテクチャが達成する必要がある肺機能要件の多くは、テクノロジー マップで最近選択されたばかりのテクノロジー プラットフォームに依存します。マッピング メカニズムが有効でない可能性さえあります。
3. フェーズ 2: 反復
基本的なメカニズムが整ったので、それらがプロジェクトで実際に機能することを確認する必要があります。したがって、適度に安定して使用できるようになるまで、上記の手順を繰り返してください。
次に、大規模なプロジェクト チームがある場合は、アーキテクチャをチーム全体に展開します。モデル駆動開発プロセスを開始する必要がある場合は、フェーズ 3 に進みます。
4. フェーズ 3: 自動化
この段階のベスト プラクティスは、ドメイン アーキテクチャとスレッド派生の参照実装/モデル、派生変換、ドメイン分析/設計などのアクティビティに関連します。
テクノロジーに依存しないアーキテクチャを備えています。ソフトウェア開発プロセスのさまざまなタスクを自動化する必要があります。自動化を有効にするには、テクノロジー マッピングのルールをエンコードし、DSL ベースのプログラミング モデルを定義する必要があります。
したがって、正式なアーキテクチャメタモデルが定義されます。アーキテクチャ メタモデルは、テクノロジに依存しないアーキテクチャの概念を正式に定義します。理想的には、このメタモデルは、開発を自動化するためのトランスフォーマー/ジェネレーターでも使用できます。
形式化は両刃の剣です。
1) ペーストコード生成
実装側では、テクノロジ マッピングは、十分に安定している場合でも、一般的に反復的なものであるため、退屈でエラーが発生しやすくなります。同様に、プログラミング モデルのアーティファクトで既に定義されている情報は、多くの場合、テクノロジ マッピング コードでフラッシュする必要があります。繰り返し行われる標準化されたテクノロジー マッピングは、よく考えられたアーキテクチャを反映しているため、優れています。重複した実装はエラーや失敗につながる傾向があります。
2) DSL ベースのプログラミング モデル
プログラミング モデルが定義されました。ただし、ドメイン固有のアルゴリズムが多数再実装されているため、プログラミング モデルは依然として複雑すぎます。ドメインの専門家が日常業務でプログラミング モデルを使用することは困難です。
3) モデルベースのアーキテクチャの検証
現在、適切なアーティファクトがすべて揃っており、そのアーキテクチャが多くの開発者に展開されています。計画どおりにプログラミング モデルを使用していることを確認する必要があります。人によって資格も異なります。アーキテクチャが QOS の約束を満たすためには、プログラミング モデルを適切に使用することも重要です。
5. 製品ラインエンジニアリング
プロダクト ライン エンジニアリング (PLE) は、ドメインのシステム分析とソフトウェア製品ラインの設計を扱います。その目標は、ソフトウェア システム開発中の自動化と再利用の可能性のバランスを適切に取ることです。したがって、製品ライン エンジニアリングは、分析手法として MDSD 環境にシームレスに統合されます。
言い換えれば、ドメイン アーキテクチャ開発スレッドのドメイン部分のすべてのアクティビティに確かな背景を提供します。
1. ソフトウェア システム ファミリと製品ライン
ソフトウェア システム ファミリの初期定義は次のとおりです。
アセンブリの共通特性が最初に研究され、次に個々のファミリー メンバーの特殊な特性が決定される場合、アセンブリはファミリーを形成するとみなされます。
一方、製品ラインは、共通のターゲット市場を共有する機能的に関連した製品のグループで構成され、その構成は顧客グループに固有です。理想的には、製品ラインはソフトウェア システム ファミリの助けを借りて実現されます。
2. MDSDプロセスとの統合
MDSD は、製品ライン エンジニアリングの実装手法と考えることができます。同様に、この製品ラインは MDSD の分析方法とみなすことができます。製品ラインの実践は、反復的かつ段階的に使用することができ、また使用する必要があります。PLE は、MDSD プロジェクトの初期段階では実際に優れたアプローチであるとしても、MDSD の個別の先行段階としてではなく、むしろ付随的なアプローチとして見なされるべきです。
3. 方法論
製品ラインエンジニアリングのプロセスは 3 つのフェーズで構成されます。
製品ラインエンジニアリングの段階
1) ドメイン分析
ドメイン分析の最初のステップはドメインのスコープ設定です。ここでドメインの境界が決定されます。
2) ドメインの設計と実装
ソフトウェア構造の定義はドメイン設計の一部です。まず、ドメイン製品の共通機能をプラットフォームの形で実装します。これらの共通機能はすべての製品で同じであるため、どのような方法でも繰り返し実装する必要はありません。共通のターゲット アーキテクチャの基礎を形成します。
4. ドメインモデリング
ドメインは、ドメイン固有の抽象化、概念、ルールで構成されます。定義された DSL、つまりモデル化されたアプリケーションがドメインの正しいサブセットを形成していることを確認するにはどうすればよいでしょうか?
DSL のメタモデルは制約され、可能な限りドメインに近づける必要があります。この点では、機能モデルが役に立ちます。必要に応じて、メタモデルは、基本メタモデルの不必要なプロパティ (UML プロパティなど) を省略する必要があります。制約は、この環境に強力なメカニズムを提供します。
ドメインの用語集やオントロジーは、適切なメタモデルを実装するための有用な最初のステップとなり、その後、反復開発中に変換できます。