次の方法で共有

モデルからアプリを生成し構成する

  • [アーティクル]

モデルからアプリケーションのパーツを生成または構成できます。

このモデルは、コードと比べて、要求をより直接的に表します。 アプリケーションの動作をモデルから直接派生させることで、コードを更新するよりも迅速かつ確実に、要求の変更に対応できます。 派生を設定するには特定の初期作業が必要ですが、要求の変更が予想される場合、または製品のバリエーションを複数予定している場合、この投資は取り戻すことができます。

モデルからアプリケーション コードを生成する

コードを生成する最も簡単な方法は、テキスト テンプレートを使用することです。 モデルを維持するのと同じ Visual Studio ソリューションで、コードを生成できます。 詳細については、次を参照してください。

  • T4 テキスト テンプレートを使用したデザイン時コード生成

  • ドメイン固有言語からのコード生成

    このメソッドは、段階的に適用することが簡単にできます。 特定のケースに対してのみ動作するアプリケーションから始めて、モデルから変更する部分をいくつか選択します。 テキスト テンプレート (.tt) ファイルになるように、対象部分のソース ファイル名を変更します。 この時点で、ソースの .cs ファイルはテンプレート ファイルから自動的に生成されるため、アプリケーションは以前と同じように動作します。

    次にコードの 1 つの部分を取り出して、テキスト テンプレート式に置き換えることができます。これにより、モデルが読み込まれ、ソース ファイルの対象部分が生成されます。 モデルの 1 つ以上の値によって元のソースが生成されるため、アプリケーションをもう一度実行しても、以前と同じように動作します。 複数のモデル値をテストした後、コードの別の部分にテンプレート式を挿入できます。

    このような増分方式が意味することは、コード生成は通常の場合、危険度の低いアプローチであるということです。 結果として得られるアプリケーションは通常、手動で作成したバージョンとほぼ同じくらい正常に機能します。

    ただし、既存のアプリケーションで始めた場合、モデルによって制御されているさまざまな動作を分離し、独立して変化させることができるようにするには、数多くのリファクタリングが必要となる可能性があります。 プロジェクトのコストを見積もる際に、アプリケーションのこの側面を評価することをお勧めします。

モデルからアプリケーションを構成する

実行時にアプリケーションの動作を変化させる場合は、コードの生成を使うことはできません。これは、アプリケーションをコンパイルする前に、ソース コードが生成されるためです。 その代わりに、モデルを読み取り、それに応じて動作を変更するアプリケーションを設計できます。 詳細については、次を参照してください。

  • 方法: プログラム コード内のファイルからモデルを開く

    この方法は、インクリメント方式で適用することもできますが、最初に必要となる作業量が増加します。 モデルを読み取るコードを作成し、可変部から値にアクセスできるフレームワークを設定する必要があります。 可変部を汎用化すると、コード生成よりもコストが高くなります。

    汎用アプリケーションは通常、固有アプリケーションと比べて性能が低くなります。 パフォーマンスが非常に重要である場合は、プロジェクト計画にこのようなリスクの評価を含める必要があります。

派生アプリケーションの開発

次の一般的なガイドラインが役に立つことがあります。

  • 固有から始めて、汎用化する。 まず、アプリケーションの特定のバージョンを作成します。 このバージョンは、特定の条件セットで動作します。 正常に動作していることを確認した後、その一部をモデルから派生させることができます。 派生の部分を徐々に拡張します。

    たとえば、固有の Web セット ページが存在する Web サイトを設計してから、モデル内で定義されているページを提供する Web アプリケーションを設計します。

  • 少しずつ異なる側面をモデル化する。 特定のデプロイと別のデプロイ間の違い、または時間経過による要求の変化など、さまざまに異なる側面を識別します。 これらは、モデルから派生させる必要があります。

    たとえば、一連の Web ページとページ間のリンクが変更されても、ページのスタイルと形式は同じ場合は、モデルでリンクを記述する必要はありますが、ページの形式を記述する必要はありません。

  • 懸案事項を分離する。 変化する側面を独立した複数の領域に分割できる場合、各領域に対して別個のモデルを使用してください。 ModelBus を使用すると、モデル、およびモデル間の制約の両方に影響する操作を定義できます。

    たとえば、1 つのモデルを使って Web ページ間の移動を定義し、次に別のモデルを使ってページのレイアウトを定義します。

  • ソリューションではなく、要求をモデル化する。 ユーザー要件を説明するようにモデルを設計します。 これとは対照的に、実装の可変部分に従って、表記を設計しないでください。

    たとえば、Web ナビゲーション モデルは、Web ページと Web ページ間のハイパーリンクを表す必要があります。 Web ナビゲーション モデルでは、HTML のフラグメントやアプリケーションのクラスを表さないでください。

  • 生成か、解釈か? 特定のデプロイに対する要求がほとんど変わらない場合は、モデルからプログラム コードを生成してください。 要求が頻繁に変わる場合、または同じデプロイ内に 1 つ以上のバリエーションが存在する場合、モデルを読み取って解釈できるようにアプリケーションを作成してください。

    たとえば、Web サイト モデルを使って、個別にインストールされる一連の異なる Web サイトを開発する場合は、モデルからサイトのコードを生成してください。 しかし、モデルを使って、毎日変わるサイトを制御する場合は、モデルを読み取り、それに従ってサイトを表現する Web サーバーを作成することをお勧めします。

  • UML か、DSL か? ステレオタイプを使用してモデリングを拡張することで、モデリングの表記法を作成することを検討してください。 目的に合った UML 図が存在しない場合は、DSL を定義します。 しかし、UML の標準のセマンティクスに違反しないようにしてください。

    たとえば、UML クラス図は一連のボックスと矢印で構成されていて、この表記法を使用すると、理論的には何でも定義できます。 一連の型を実際に記述する場合を除き、クラス図を使用することはお勧めしません。 たとえば、クラス図を適用して、さまざまな種類の Web ページを記述できます。

関連するコンテンツ