モデルからアプリケーションの一部を生成または構成できます。
モデルは、コードよりも直接要件を表します。 モデルから直接アプリケーションの動作を派生させることで、コードを更新するよりもはるかに迅速かつ確実に、変更された要件に対応できます。 派生の設定には初期作業が必要ですが、要件の変更が予想される場合、または製品のいくつかのバリアントを作成する予定の場合は、この投資が返されます。
モデルからアプリケーションのコードを生成する
コードを生成する最も簡単な方法は、テキスト テンプレートを使用することです。 モデルを保持するのと同じ Visual Studio ソリューションでコードを生成できます。 詳細については、以下を参照してください。
-
この方法は、段階的に簡単に適用できます。 特定のケースに対してのみ機能するアプリケーションから始めて、モデルとは異なる部分をいくつか選択します。 これらのパーツのソース ファイルの名前を変更して、テキスト テンプレート (.tt) ファイルになるようにします。 この時点で、ソース .cs ファイルはテンプレート ファイルから自動的に生成されるため、アプリケーションは以前と同じように動作します。
その後、コードの 1 つの部分を取得し、モデルを読み取ってソース ファイルのその部分を生成するテキスト テンプレート式に置き換えることができます。 モデルの少なくとも 1 つの値で元のソースが生成されるため、アプリケーションを再度実行でき、以前と同様に動作します。 さまざまなモデル値をテストしたら、次に進んでコードの別の部分にテンプレート式を挿入できます。
この増分メソッドは、通常、コード生成がリスクの低いアプローチであることを意味します。 結果として得られるアプリケーションは、通常、手書きのバージョンとほぼ同様に実行されます。
ただし、既存のアプリケーションから開始する場合は、モデルによって管理されるさまざまな動作を分離して個別に変更できるように、多くのリファクタリングが必要になる場合があります。 プロジェクトのコストを見積もるときに、アプリケーションのこの側面を評価することをお勧めします。
モデルからのアプリケーションの構成
実行時にアプリケーションの動作を変更する場合は、アプリケーションのコンパイル前にソース コードを生成するコード生成を使用することはできません。 代わりに、モデルを読み取り、それに応じて動作を変更するようにアプリケーションを設計できます。 詳細については、以下を参照してください。
-
このメソッドは段階的に適用することもできますが、最初にさらに多くの作業があります。 モデルを読み取るコードを記述し、変数部分から値にアクセスできるようにするフレームワークを設定する必要があります。 変数パーツをジェネリックにすることは、コード生成よりもコストがかかります。
一般的なアプリケーションは、通常、その特定のアプリケーションよりもパフォーマンスが低くなります。 パフォーマンスが重要な場合は、プロジェクト計画にこのリスクの評価を含める必要があります。
派生アプリケーションの開発
次の一般的なガイドラインが役立つ場合があります。
特定を開始し、一般化します。 最初にアプリケーションの特定のバージョンを記述します。 このバージョンは、1 つの条件セットで動作する必要があります。 正常に動作していることを確認したら、その一部をモデルから派生させることができます。 派生パーツを徐々に拡張します。
たとえば、モデルで定義されているページを表示する Web アプリケーションを設計する前に、特定の Web ページセットを含む Web サイトを設計します。
バリアントの側面をモデル化します。 1 つのデプロイと別のデプロイの間で、または要件の変化に応じて時間の経過と同時に変化する側面を特定します。 これらは、モデルから派生する必要がある側面です。
たとえば、Web ページとそれらの間のリンクのセットが変更されても、ページのスタイルと形式が常に同じである場合、モデルはリンクを記述する必要がありますが、ページの形式を記述する必要はありません。
個別の懸念事項。 変数の側面を独立した領域に分割できる場合は、領域ごとに個別のモデルを使用します。 ModelBus を使用すると、両方のモデルとそれらの間の制約に影響する操作を定義できます。
たとえば、1 つのモデルを使用して Web ページ間のナビゲーションを定義し、別のモデルを使用してページのレイアウトを定義します。
ソリューションではなく、要件をモデル化します。 ユーザー要件を説明するようにモデルを設計します。 これに対し、実装の可変的な側面に従って表記を設計しないでください。
たとえば、Web ナビゲーション モデルは、Web ページとそれらの間のハイパーリンクを表す必要があります。 Web ナビゲーション モデルは、アプリケーション内の HTML またはクラスのフラグメントを表すべきではありません。
生成または解釈しますか? 特定のデプロイの要件がほとんど変更されない場合は、モデルからプログラム コードを生成します。 要件が頻繁に変更される場合や、同じデプロイ内の複数のバリアントに共存する可能性がある場合は、モデルを読み取って解釈できるようにアプリケーションを記述します。
たとえば、Web サイト モデルを使用して、個別にインストールされた一連の異なる Web サイトを開発する場合は、モデルからサイトのコードを生成する必要があります。 ただし、モデルを使用して毎日変更されるサイトを制御する場合は、モデルを読み取り、それに応じてサイトを表示する Web サーバーを作成することをお勧めします。
UML または DSL ステレオタイプを使用して UML を拡張してモデリング表記を作成することを検討してください。 目的に合った UML 図がない場合は、DSL を定義します。 ただし、UML の標準的なセマンティクスを破らないようにしてください。
たとえば、UML クラス図はボックスと矢印のコレクションです。この表記法を使用すると、理論上は何でも定義できます。 ただし、実際に一連の型を記述する場合を除き、クラスダイアグラムを使用することはお勧めしません。 たとえば、クラス図を調整して、さまざまな種類の Web ページを記述できます。