從模型產生及設定應用程式
您可以從模型產生或設定應用程式的組成部分。 模型可以是 UML 或 DSL 模型。
模型比程式碼更直接代表需求。 您可以直接從模型衍生應用程式行為，藉此回應變更的需求，此做法比更新程式碼更快也更穩固。 雖然必須進行一些初始工作來設定衍生作業，但是如果您預期需求會變更，或您計劃要建立產品的幾個不同版本，這項投資就很值得。
從模型產生應用程式的程式碼
產生程式碼最輕鬆的方式就是使用文字範本。 您可在內含模型的相同 Visual Studio 方案中產生程式碼。 如需詳細資訊，請參閱：
此方法很容易以累加方式應用。 一開始先建立僅適用特定案例的應用程式，然後從中選擇一些要從模型加以變化的組成部分。 重新命名這些組成部分的原始程式檔，將它們變成文字範本 (.tt) 檔。 此時，原始程式檔 .cs 會自動從範本檔產生，如此應用程式仍然會如往常般運作。
接著您可以將程式碼的一部分更換成文字範本運算式，此運算式會讀取模型並產生原始程式檔的該部分。 至少有一個模型值應該產生原來的原始程式碼，如此您可再次執行應用程式，而其仍然會如往常般運作。 在您測試不同的模型值之後，您可以再將範本運算式插入程式碼的另一個部分。
這個累加方式意謂程式碼產生是一項風險很低的方法。 產生的應用程式其執行效能幾乎和手寫版本一樣好。
然而，如果您處理的是現有應用程式，您可能發現必須進行很多重構工作，才能將模型所管理的不同行為分開，以便個別加以改變。 建議您在估計專案成本時，要評估應用程式的這個層面。
從模型設定應用程式
如果您要在執行階段改變應用程式行為，就不能使用程式碼產生，它會在應用程式編譯前產生原始程式碼。 您可以改為將應用程式設計成會讀取 UML 或 DSL 模型並隨之改變其行為。 如需詳細資訊，請參閱：
您也可以採累加方式應用此方法，但一開始需進行較多工作。 您必須撰寫會讀取模型的程式碼，並設定架構允許可變組成部分存取其值。 將可變組成部分設定成泛型，此做法的花費比程式碼產生高。
泛型應用程式執行效能通常比特定應用程式差。 如果執行效能很重要，則專案計劃應該要評估這個風險。
開發衍生的應用程式
您可能會發現下列一般方針很有用。
先特定，再一般化。 先撰寫特定的應用程式版本。 這個版本應該會在一組條件下運作。 當您滿意它可正常運作時，可以將其中一部分設定成衍生自模型。 再逐漸擴大衍生的部分。
例如，先設計具有特定一組網頁的網站，再設計 Web 應用程式，其所呈現的網頁是定義在模型中。
將易變層面模型化。 識別會因不同部署而改變，或一段時間後因需求變化而改變的層面。 這些層面應該要衍生自模型。
例如，如果一組網頁和這些網頁間的連結發生變更，但這些網頁的樣式和格式都不會變，則模型應該描述這些網頁的連結，而不需描述網頁的格式。
將重點分開。 如果可變層面可分成各自獨立的區域，請為每個區域使用個別的模型。 您可以使用 ModelBus 定義會同時影響模型和模型間之約束條件的作業。
例如，使用某個模型來定義網頁間的巡覽作業，而使用另一個模型來定義網頁的配置。 如需詳細資訊，請參閱HOW TO：整合 UML 模型與其他模型和工具。
模型化需求，而不是方案。 設計 DSL 或修改 UML 以描述使用者需求。 相反地，不要根據實作的可變層面來設計標記法。
例如，Web 巡覽模型應該代表網頁和網頁間的超連結。 Web 巡覽模型不應該代表 HTML 片段或應用程式中的類別。
產生或解譯？ 如果特定部署的需求很少變更，則從模型產生程式碼。 如果需求可能常常變更，或可能同時存在於相同部署中的多個變體，則撰寫應用程式使其能讀取和轉譯模型。
例如，如果您使用網站模型開發一系列不同且分開安裝的網站，那麼應該從模型產生網站的程式碼。 但是，如果您使用模型來控制每天會變更的網站，那麼最好撰寫會讀取模型並隨之呈現網站的 Web 伺服器。
UML 或 DSL？ 請考慮使用造型擴充 UML 來建立您的模型標記法。 如果沒有適合的 UML 圖表，請定義 DSL。 但是要避免破壞 UML 標準語意。
例如，UML 類別圖表是一組方塊和箭號，理論上，您可使用此標記法定義任何項目。 但是，我們不建議您使用類別圖表，除非您實際上是要描述一組型別。 例如，您可以修改類別圖表以描述不同網頁類型。