モデルからのアプリケーションの生成および構成
アプリケーションの各部分は、モデルから生成または構成することができます。 モデルには UML と DSL があります。
モデルは、コードよりも直接的に要求を表します。 アプリケーションの振る舞いをモデルから直接派生させる方が、コードを更新するよりも、要求の変更への対応をはるかに迅速かつ確実に行うことができます。 派生を設定するためにはいくつかの初期作業が必要ですが、要求の変更が想定される場合や、製品のバリアントを複数作成する予定がある場合には、この作業が後で役に立ちます。
モデルからのアプリケーションのコードの生成
コードを生成する最も簡単な方法は、テキスト テンプレートを使用することです。 コードは、モデルの格納先と同じ Visual Studio ソリューション内に生成できます。 詳細については、次のトピックを参照してください。
このメソッドは簡単かつ段階的に適用できます。 まず、固有のケースでのみ動作するアプリケーションを作成し、モデルとは異なるようにしたい部分をいくつか選択します。 選択した部分のソース ファイルがテキスト テンプレート (.tt) ファイルになるように、名前を変更します。 この時点で、ソースの .cs ファイルがテンプレート ファイルから自動的に生成されるため、アプリケーションは以前と同じように動作します。
次に、コードの一部分を取り除き、テキストのテンプレート式で置き換えます。この式は、モデルを読み込んで、置き換えた部分のソース ファイルを生成します。 アプリケーションをもう一度実行できるようにするためには、モデルの少なくとも 1 つの値で元のソースを生成する必要があります。これにより、アプリケーションが以前と同じように実行できるようになります。 モデルの各種の値をテストしたら、次の段階に進んで、コードの別の部分にテンプレート式を挿入することができます。
この段階的なメソッドを使用すると、通常、低リスクでコードを生成できます。 生成されたアプリケーションのパフォーマンスは、多くの場合、手動で記述したアプリケーションとほぼ同等になります。
ただし、既存のアプリケーションを利用する場合、モデルの影響を受ける振る舞いを分離するために、何度もリファクタリングを行わなければならない場合があります。そのため、各動作は個別に変更することができます。 プロジェクトの費用を見積もるときには、アプリケーションのこのような側面を評価することをお勧めします。
モデルからのアプリケーションの構成
アプリケーションの振る舞いを実行時に変更する場合は、アプリケーションがコンパイルされる前にソース コードを生成するコード生成を使用することができません。 その代わり、UML モデルまたは DSL モデルを読み込み、その内容に応じてアプリケーションの振る舞いを変更するように、アプリケーションを設計することができます。 詳細については、次のトピックを参照してください。
このメソッドも段階的に適用することができます。ただし、最初に、 モデルを読み込むコードの作成とフレームワークの設定を追加の作業として行う必要があります。これにより、フレームワークの値から可変部分にアクセスできるようになります。 可変部分を汎用にすると、コード生成よりも負荷が大きくなります。
通常、汎用アプリケーションは、固有のアプリケーションよりもパフォーマンスが低くなります。 パフォーマンスを重視する場合は、このリスクの評価をプロジェクト計画に含める必要があります。
派生アプリケーションの開発
次の一般的なガイドラインが役に立つ場合があります。
**固有のアプリケーションを作成してから汎用化する。**まず、固有のバージョンのアプリケーションを作成します。 このバージョンのアプリケーションは、一定の条件下で動作する必要があります。 正常に動作することを確認したら、その一部をモデルから派生させ、 徐々に派生部分を拡張します。
たとえば、特定の Web ページのセットを持つ Web サイトをデザインしてから、モデルで定義されているページを表示する Web アプリケーションを設計します。
**変動要素をモデル化する。**配置によって変化する要素、または要求の変更に応じて変化する要素を特定します。 これらは、モデルから派生させる必要がある要素です。
たとえば、Web ページのセットとそれらの間のリンクは変更されるが、ページのスタイルと形式が常に同じ場合は、モデルでリンクを記述する必要がありますが、ページの形式を記述する必要はありません。
**関心を分離する。**可変要素を独立した区分に分割できる場合は、区分ごとに個別のモデルを使用します。 ModelBus を使用すると、それぞれのモデルに影響を与える操作と、それらの間の制約を定義することができます。
たとえば、あるモデルでは Web ページ間のナビゲーションを定義し、別のモデルではページのレイアウトを定義します。 詳細については、「方法: UML モデルを他のモデルおよびツールと統合する」を参照してください。
**ソリューションではなく、要求をモデル化する。**DSL を定義するか、または UML を編集して、ユーザー要求を記述します。 反対に、実装の可変要素に準じた表記の設計は行わないでください。
たとえば、Web ナビゲーション モデルでは、Web ページとそれらの間のハイパーリンクを表す必要がありますが、 HTML のフラグメントやアプリケーションのクラスを表す必要はありません。
**生成または解釈する。**特定の配置に対する要求がほとんど変更されない場合は、プログラム コードをモデルから生成します。 要求が頻繁に変更される可能性がある場合や、同じ配置内の複数のバリアントで要件が共存する可能性がある場合は、モデルを読み込んで解釈できるようにアプリケーションを作成します。
たとえば、Web サイト モデルを使用して、一連の個別にインストールされた Web サイトを開発する場合は、サイトのコードをモデルから生成する必要があります。 ただし、毎日変更されるサイトをモデルを使用して制御する場合は、モデルを読み込み、その内容に応じてサイトを表示する Web サーバーを作成する方が適しています。
**UML または DSL を使用する。**ステレオタイプを使用して UML を拡張することにより、モデリング表記を生成することを検討します。 目的に適合する UML 図がない場合は、DSL を定義します。 ただし、UML の標準セマンティクスに違反しないようにしてください。
たとえば、UML クラス図はボックスと矢印の集まりですが、この表記を使用すると、理論的には何でも定義することができます。 ただし、実際には、型のセットを記述する場合以外は、クラス図を使用することは推奨されません。 たとえば、クラス図を使用して、各種の Web ページを記述することができます。