在 Visual Studio 中，您可以使用模型來協助您瞭解和變更系統、應用程式或元件。 模型可以幫助您視覺化系統運作的世界、明確使用者的需求、定義系統的架構、分析程式碼並確保您的程式碼符合要求。
若要查看哪些版本的 Visual Studio 支援每種類型的模型，請參閱 架構和模型化工具的版本支援。
模型可以通過多種方式為您提供幫助：
繪製建模圖可協助您釐清需求、架構及高階設計中涉及的概念。 如需詳細資訊，請參閱 模型使用者需求。
使用模型可協助您揭露需求中的不一致。
與模型進行通訊可協助您以比自然語言更不模糊的方式傳達重要概念。 如需詳細資訊，請參閱 建立應用程式架構模型。
您有時可以使用模型來產生程式碼或其他成品，例如資料庫結構描述或文件。 例如，Visual Studio 的模型化元件是從模型產生的。 如需詳細資訊，請參閱 從模型產生和設定您的應用程式。
您可以在各種流程中使用模型，從極度敏捷到高級儀式。
使用模型減少歧義
建模語言比自然語言不那麼模糊，它旨在表達軟體開發過程中通常需要的想法。
如果您的專案有一個遵循敏捷實踐的小型團隊，您可以使用模型來幫助您澄清使用者故事。 在與客戶討論他們的需求時，建立模型可以比編寫尖峰或原型程式碼更快地產生有用的問題，並且跨越更廣泛的產品領域。
如果您的專案規模較大，且包含全球不同地區的團隊，您可以使用模型來協助傳達需求和架構，比純文字更有效。
在這兩種情況下，建立模型幾乎總是會顯著減少不一致和歧義。 不同的利害關係人通常對系統運作的商業世界有不同的理解，不同的開發人員通常對系統運作方式有不同的理解。 使用模型作為討論的焦點通常會暴露這些差異。 如需如何使用模型來減少不一致的詳細資訊，請參閱 模型使用者需求。
將模型與其他構件搭配使用
模型本身不是需求規範或架構。 它是更清楚地表達這些事物的某些方面的工具，但並不是軟體設計過程中所需的所有概念都可以表達出來。 因此，模型應該與其他通訊方式一起使用，例如 OneNote 頁面或段落、Microsoft Office 檔、Team Foundation 中的工作專案，或專案會議室牆上的自黏便箋。 除了最後一項之外，所有這些物件類型都可以連結至模型的元素部分。
通常與模型一起使用的規範的其他方面包括以下內容。 根據專案的規模和風格，您可以使用以下幾個方面，或者根本不使用任何方面：
用戶故事。 使用者故事是對系統行為某一方面的簡短描述，這些描述會在與使用者及其他利害關係人討論後，於專案的其中一次迭代中交付。 典型的使用者故事開頭是「客戶將能夠...」使用者劇本可能會引進一組使用案例，或可以定義先前已開發的使用案例的延伸。 定義或擴展用例有助於使用戶故事更加清晰。
變更請求。 更正式的專案中的變更請求與敏捷專案中的使用者故事非常相似。 敏捷方法將所有需求視為對先前疊代中開發的內容的變更。
使用案例描述。 用例代表用戶與系統交互以實現特定目標的一種方式。 完整的描述包括目標、事件的主要和替代順序以及特殊結果。 使用案例圖有助於摘要並提供使用案例的概述。
案例。 場景是對一系列事件的相當詳細的描述，顯示系統、用戶和其他系統如何協同工作，為利益相關者提供價值。 它可能採用使用者介面的投影片放映或使用者介面原型的形式。 它可以描述一個用例或一系列用例。
辭典。 專案的需求詞彙表描述了客戶討論他們的世界的詞語。 使用者介面和需求模型也應該使用這些術語。 類別圖可以幫助澄清大多數這些術語之間的關係。 建立圖表和詞彙表不僅可以減少使用者和開發人員之間的誤解，而且幾乎總是暴露不同業務利害關係人之間的誤解。
商務規則。 許多商業規則可以被表示為需求類別模型中關聯與屬性的恆定約束，以及在時序圖上的約束。
高級設計。 描述主要部分以及它們如何組合在一起。 元件圖、序列圖和介面圖是高階設計的主要部分。
設計模式。 描述系統不同部分共用的設計規則。
測試規格。 測試腳本和測試代碼的設計可以充分利用活動和序列圖來描述測試步驟的序列。 系統測試應該用需求模型來表達，以便在需求發生變化時可以輕鬆更改它們。
項目計劃。 專案計劃或待辦專案會定義每個功能的交付時間。 您可以透過說明其實作或擴充的使用案例和業務規則來定義每個功能。 您可以直接在計劃中參照使用案例和商業規則，也可以在個別文件中定義一組功能，並在計劃中使用功能標題。
在疊代規劃中使用模型
儘管所有專案的規模和組織都不同，但典型的專案被規劃為兩到六週的一系列迭代。 請務必規劃足夠的反覆專案，以允許使用早期反覆專案的意見反應來調整稍後反覆專案的範圍和計劃。
您可能會發現下列建議有助於在疊代專案中實現建模的好處。
隨著每次迭代的臨近而銳化焦點
當每次疊代臨近時，請使用模型來協助定義在疊代結束時要傳遞的內容。
不要在早期迭代中詳細建模所有內容。 在第一次迭代中，為使用者詞彙表中的主要項目建立類別圖，繪製主要用例的圖表，並繪製主要組件的圖表。 不要詳細描述其中任何一個，因為細節將在項目後期更改。 使用此模型中定義的術語來建立功能或主要使用者劇本的清單。 將功能指派給迭代，以便在整個專案中使預估的工作量大致平衡。 這些指派將在專案稍後變更。
嘗試在早期迭代中實作所有最重要使用案例的簡化版本。 在後續的迭代中擴展這些使用案例。 這種方法有助於降低在專案中發現需求或架構缺陷而無法採取任何措施的風險。
在每次迭代接近尾聲時，舉辦需求研討會，詳細定義將在下一次迭代中開發的需求或使用者故事。 邀請可以決定優先順序的使用者和業務利害關係人，以及開發人員和系統測試人員。 允許三個小時來定義 2 週反覆專案的需求。
研討會的目標是讓每個人都同意在下一次迭代結束時將完成什麼。 使用模型作為幫助澄清需求的工具之一。 研討會的輸出是迭代待辦清單：也就是 Team Foundation 中的開發工作清單，以及 Microsoft Test Manager 中的測試套件。
在需求研討會中，僅在您需要確定開發任務的估計值時討論設計。 否則，請將討論保留在使用者可以直接體驗的系統行為上。 將需求模型與架構模型分開。
非技術利益相關者通常可以毫無問題地理解 UML 圖，並得到您的一些指導。
將模型連結至工作專案
需求研討會結束後，詳細闡述需求模型的細節，並將模型與開發任務連結。 您可以將 Team Foundation 中的工作專案連結至模型中的元素來執行此動作。
您可以將任何元素連結至工作專案，但最有用的元素如下：
- 描述商務規則或服務品質需求的註解。 如需詳細資訊，請參閱 模型使用者需求。
將模型連結至測試
使用需求模型來指導驗收測試的設計。 在開發工作的同時建立這些測試。
若要深入瞭解此技術，請參閱 從模型開發測試。
預估剩餘工時
需求模型可以幫助估計專案的總大小與每個疊代的大小相關。 評估使用案例和類別的數量和複雜性可以幫助您估計所需的開發工作。 當您完成前幾次迭代時，比較涵蓋的需求和仍要涵蓋的需求，可以大致衡量專案其餘部分的成本和範圍。
在每次疊代接近尾聲時，檢閱需求分配至未來的疊代。 在每個迭代結束時將軟體的狀態表示為用例圖中的子系統會很有用。 在討論中，您可以將使用案例和使用案例延伸從其中一個子系統移至另一個子系統。
抽象層級
模型具有與軟體相關的一系列抽象。 最具體的模型直接表示程式代碼，而最抽象的模型則表示程式碼中可能表示或可能不表示的業務概念。
模型可以透過數種圖表來檢視。 如需模型和圖表的相關資訊，請參閱 為您的應用程式建立模型。
不同類型的圖表可用於在不同的抽象層級描述設計。 許多圖表類型在多個層級都很有用。 下表顯示如何使用每種類型的圖表。
| 設計層次 | 圖表類型 |
|---|---|
| 商務程序 瞭解系統將使用的環境定義，有助於您瞭解使用者需要從中取得什麼。 |
- 概念類別圖說明商業程序內使用的商業概念。 |
| 使用者需求 定義使用者需要從系統取得的內容。 |
- 業務規則和服務品質要求可以在單獨的文件中描述。 |
| 高級設計 系統的整體結構：主要組件以及它們如何耦合在一起。 |
- 相依關係圖描述系統如何建構成相互依賴的部分。 您可以根據相依性圖表驗證程式代碼，以確保它符合架構。 |
| 程式碼分析 可以從程式碼產生圖表。 |
- 相依關係圖會顯示類別之間的相依關係。 更新的程式碼可以根據相依性圖表進行驗證。 - 類別圖顯示程式碼中的類別。 |
外部資源
相關內容
備註
文字範本轉換元件會自動安裝為 Visual Studio 延伸模組開發工作負載的一部分。 您也可以從 Visual Studio 安裝程式的 [個別元件] 索引標籤在 [SDK、程式庫和架構] 類別下安裝它。 從 個別元件 索引標籤安裝 Modeling SDK 元件。