您可以從模型產生或配置應用程式的部分。
模型比程式碼更直接地表示需求。 透過直接從模型衍生應用程式的行為，您可以比更新程式碼更快、更可靠地回應變更的需求。 雖然設定衍生需要一些初始工作，但如果您預期需求會變更，或您計劃製作產品的數個變體，則會退還此投資。
從模型產生應用程式的程式碼
產生程式碼的最簡單方法是使用文字範本。 您可以在保留模型的相同 Visual Studio 解決方案中產生程式碼。 如需詳細資訊，請參閱：
-
這種方法很容易逐步應用。 從僅適用於特定案例的應用程式開始，然後選擇您想要與模型不同的幾個部分。 重新命名這些零件的來源檔案，使其成為文字範本 （.tt） 檔案。 此時，源.cs文件將自動從模板文件生成，因此應用程序將像以前一樣工作。
然後，您可以取得程式碼的一部分，並將其取代為文字範本運算式，以讀取模型並產生原始檔的該部分。 模型的至少一個值應該產生原始來源，以便您可以再次執行應用程式，而且它會像以前一樣運作。 測試不同的模型值之後，您可以繼續在程式碼的另一部分插入範本運算式。
這種增量方法意味著程式碼產生通常是一種低風險的方法。 生成的應用程序通常與手寫版本的性能幾乎一樣好。
不過，如果您從現有的應用程式開始，您可能會發現需要大量重構來區隔模型所控管的不同行為，以便它們可以獨立變化。 建議您在預估專案成本時，評估應用程式的這方面。
從模型設定應用程式
如果您想要在執行階段改變應用程式的行為，則無法使用程式碼產生，這會在編譯應用程式之前產生原始程式碼。 相反地，您可以設計應用程式來讀取模型，並據以改變其行為。 如需詳細資訊，請參閱：
-
這種方法也可以逐步應用，但一開始需要做更多的工作。 您需要編寫將讀取模型的程式碼，並設定一個框架，允許變數部分存取其值。 將可變部分設為泛型比程式碼產生更昂貴。
泛型應用程式的效能通常不如其特定對應應用程式。 如果績效至關重要，您的專案計劃應包括對此風險的評估。
開發衍生應用程式
您可能會發現下列一般準則很有用。
具體開始，然後泛化。 先撰寫應用程式的特定版本。 此版本應該在一組條件下運作。 當您確定它正常運作時，您可以讓其中部分基於模型來構建。 逐漸延伸衍生零件。
例如，在設計呈現模型中定義之頁面的 Web 應用程式之前，先設計具有一組特定網頁的網站。
對變體方面進行建模。 識別在不同部署之間或因需求變更而隨時間變化的方面。 這些是應該從模型中得出的方面。
例如，如果網頁集及其之間的連結發生變化，但頁面的樣式和格式始終相同，則模型應該描述連結，但不必描述頁面的格式。
單獨的關注點。 如果可變方面可以劃分為獨立的區域，請為每個區域使用單獨的模型。 使用 ModelBus，您可以定義影響兩個模型的作業，以及它們之間的條件約束。
例如，使用一個模型來定義網頁之間的導覽，並使用不同的模型來定義頁面的版面配置。
對需求進行建模，而不是解決方案。 設計模型，使其描述使用者需求。 相反地，不要根據實作的可變層面來設計符號。
例如，Web 導覽模型應該代表網頁和它們之間的超連結。 Web 導覽模型不應代表應用程式中的 HTML 片段或類別。
生成還是解釋？ 如果特定部署的需求很少變更，請從模型產生程式代碼。 如果需求可能經常變更，或可能共存於相同部署中的多個變體中，請撰寫應用程式，以便它可以讀取和解譯模型。
例如，如果你使用你的網站模型來開發一系列不同的、單獨安裝的網站，那麼你應該從模型中產生網站的程式碼。 但是，如果您使用模型來控制每天變化的站點，那麼最好編寫一個 Web 服務器來讀取模型並相應地呈現站點。
UML 還是 DSL？ 請考慮使用刻板來擴充 UML，創建您的建模表示法。 如果沒有符合目的的 UML 圖，請定義 DSL。 但要避免破壞 UML 的標準語義。
例如，UML 類別圖是方塊和箭頭的集合;使用這種符號，理論上您可以定義任何內容。 但我們不建議您使用類別圖，除非您實際上描述了一組類型。 例如，您可以調整類別圖來描述不同類型的網頁。