在開發程序中使用模型
在 Visual Studio Ultimate 中，您可以使用模型來協助您了解並變更系統、應用程式或元件。 模型可以協助您視覺化系統運作的領域、釐清使用者的需求、定義系統的架構、分析程式碼，以及確定您的程式碼符合需求。
如需觀看簡介影片，請參閱影片：Visual Studio 2010 的 UML (英文)
如何使用模型
模型可以透過許多方式協助您：
繪製模型圖表可以協助您釐清涉及需求、架構及高階設計的概念。 如需詳細資訊，請參閱模型化使用者要求。
使用模型可以協助您公開需求的不一致。
透過模型傳達可以協助您傳達重要的概念，這比使用自然語言傳達更清楚。 如需詳細資訊，請參閱模型化軟體系統的架構。
您可以偶爾使用模型來產生程式碼或其他成品，例如資料庫結構描述或文件。 例如，Visual Studio Ultimate 的模型元件就是從模型產生的。 如需詳細資訊，請參閱從模型產生及設定應用程式。
您可以在各種不同的程序中使用模型，不論是極端靈活還是高度嚴謹都可以。
使用模型來減少模稜兩可
模組化語言會比自然語言更清楚，而且它是設計來表達軟體開發過程通常需要的概念。
如果您的專案具有遵循 Agile 作法的小組，就可以使用模型來協助您釐清使用者本文。 與客戶討論有關他們的需求時，建立模型可以產生有用的問題，這比撰寫特殊圖文集或原型程式碼速度更快而且跨越更廣泛的產品領域。
如果您的專案很龐大，而且包括分佈於全球不同地點的小組，就可以使用模型來協助傳達需求和架構，這比使用純文字更有效率。
在這兩種情況下，建立模型幾乎一定會大幅減少不一致和模棱兩可之處。 不同的專案關係人通常對於系統運作的商務領域具有不同的理解，而且不同的開發人員通常對於系統的運作方式具有不同的理解。 使用模型做為討論的重點通常會公開這些差異。 如需如何使用模型來減少模稜兩可的詳細資訊，請參閱模型化使用者要求。
使用模型搭配其他成品
模型本身並非需求規格或架構。 雖然它是用來針對這些事情更清楚表達某些層面的工具，不過並無法表達軟體設計期間所需的所有概念。 因此，您應該搭配其他通訊方式使用模型，例如 OneNote 頁面或段落、Microsoft Office 文件、Team Foundation 中的工作項目或專案會議室牆上的自黏便箋。 除了最後一個項目以外，上述所有物件型別都可以連結至模型的項目部分。
通常與模型一起使用的其他規格層面包括下列項目。 根據您的專案規模和樣式，可能會使用其中許多層面，或完全不使用任何層面：
使用者本文。 使用者本文是系統行為之某個層面的簡短描述 (與使用者和其他專案關係人討論)，而且將會在其中一個專案反覆項目中傳遞。 一般使用者本文的開頭是「客戶將能夠...」。使用者本文可能會引入一組使用案例，也可能會定義先前已經開發之使用案例的擴充。 定義或擴充使用案例有助於讓使用者本文更清楚。
變更要求。 較正式專案中的變更要求非常類似於 Agile 專案中的使用者本文。 Agile 方法會將所有需求視為已在先前反覆項目中開發的項目。
使用案例描述。 使用案例代表使用者與系統互動來達成特定目標的其中一種方式。 完整描述包括目標、事件的主要和替代順序，以及例外結果。 使用案例圖表有助於摘要說明並提供使用案例的概觀。
情節。 情節是一系列事件相當詳細的描述，其中顯示系統、使用者和其他系統如何一起運作，以便為專案關係人提供價值。 它可能會採用使用者介面投影片放映或使用者介面原型的形式。 它可以描述單一使用案例或一系列使用案例。
字彙。 專案的需求字彙會描述客戶用來討論其領域的單字。 使用者介面和需求模型應該也會使用這些詞彙。 類別圖表可以協助釐清大部分詞彙之間的關聯性。 建立圖表和字彙不僅可減少使用者與開發人員之間的誤解，而且幾乎也一定會公開不同商務專案關係人之間的誤解。
商務規則。 許多商務規則都可以表達成需求類別模型中關聯和屬性的非變異條件約束，以及順序圖表的條件約束。
高階設計。 描述主要部分以及它們如何相互配合。 元件、順序和介面圖表是高階設計的主要部分。
設計模式。 描述在系統不同部分之間共用的設計規則。
測試規格。 測試指令碼和測試程式碼的設計可以充分運用活動和順序圖表來描述測試步驟的順序。 您應該根據需求模型表達系統測試，以便在需求變更時更輕易地變更系統測試。
專案計劃。 專案計劃或待處理項目會定義何時要傳遞每個功能。 您可以指出每個功能所實作或擴充的使用案例和商務規則，藉以定義每個功能。 您可以直接在計劃中參考使用案例和商務規則，也可以在個別的文件中定義一組功能，然後在計劃中使用功能標題。
在反覆項目規劃中使用模型
雖然所有專案的規模和組織都不同，不過一般專案會規劃成介於二至六週的一系列反覆項目。 請務必規劃足夠的反覆項目，以便利用早期反覆項目的意見回應來調整後期反覆項目的範圍和計劃。
您可能會發現下列建議事項有助於實現在反覆進行的專案中使用模型的優點。
在每個反覆項目進行時突顯焦點
在每個反覆項目進行時，使用模型來協助定義反覆項目結束時所傳遞的項目。
請勿在早期的反覆項目中詳細模型化所有項目。 在第一個反覆項目中，請針對使用者字彙中的主要項目建立類別圖表、繪製主要使用案例的圖表，並且繪製主要元件的圖表。 請勿詳細描述其中任何項目，因為這個詳細資料之後將在專案中變更。 使用這個模型中定義的詞彙來建立一份功能或主要使用者本文的清單。 將這些功能指派給反覆項目，以便大約平衡整個專案的預估工作量。 這些指派之後將在專案中變更。
請嘗試在早期的反覆項目中實作所有最重要使用案例的簡化版本。 在後期的反覆項目中擴充這些使用案例。 這個方法有助於降低太晚在專案中發現需求或架構缺陷而無法進行任何處置的風險。
在每個反覆項目即將結束前，召集需求研討會來詳細定義將於下一個反覆項目中開發的需求或使用者本文。 邀請可以決定優先順序的使用者和商務專案關係人，以及開發人員和系統測試人員。 提供三個小時來定義 2 週反覆項目的需求。
此研討會的目標是要讓每個人都同意下一個反覆項目結束時所完成的項目。 請使用模型做為其中一項工具來協助釐清需求。 此研討會的輸出就是反覆項目中的待處理項目：也就是，Team Foundation 中開發工作以及 Microsoft 測試管理員中測試套件的清單。
在需求研討會中，只針對您必須決定開發工作估計的範圍討論設計。 否則，請將討論主題保持在使用者可能會直接遇到的系統行為。 將需求模型與架構模型分開討論。
非技術性專案關係人通常只要透過您一些指引，就可以順利了解 UML 圖表。
將模型連結至工作項目
在需求研討會之後，請詳述需求模型的詳細資料，並且將模型連結至開發工作。 您可以將 Team Foundation 中的工作項目連結至模型中的項目，藉以完成此作業。 若要了解如何進行此作業，請參閱 HOW TO：從模型項目連結至工作項目。
雖然您可以將任何項目連結至工作項目，不過最有用的項目如下所示：
使用案例。 您可以將使用案例連結至即將實作它的開發工作。
使用案例擴充。 如果反覆項目只有實作使用案例的單一層面，您就可以將它分隔成基底使用案例以及一個或多個擴充。 這些擴充就是使用 «extend» 關聯性連結至基底案例的使用案例。 如需使用案例擴充的詳細資訊，請參閱UML 使用案例圖表：參考。
描述商務規則或服務需求品質的註解。 如需詳細資訊，請參閱 模型化使用者要求。
將模型連結至測試
您可以使用需求模型來引導接受度測試的設計。 請同時與開發工作一起建立這些測試。
若要進一步了解這項技術，請參閱從模型開發測試。
估計剩餘工作
需求模型可以協助您估計與每個反覆項目大小相關的專案總大小。 評估使用案例與類別的數目和複雜度可以協助您估計所需的開發工作。 當您已經完成前幾個反覆項目時，已涵蓋需求與待涵蓋需求的比較可以提供專案剩餘部分之成本和範圍的大約測量。
在每個反覆項目即將結束前，請檢閱未來反覆項目的需求指派。 這樣做有助於將每個反覆項目結束時的系統狀態表示成使用案例圖表中的子系統。 在進行討論時，您就可以將使用案例和使用案例擴充從其中一個子系統移至另一個子系統。
抽象層級
模型具有與軟體相關的抽象範圍。 最具體的模型直接代表程式碼，而最抽象的模型則代表不一定會展示於程式碼中的商務概念。
您可以透過許多種類的圖表檢視模型。 如需模型和圖表的詳細資訊，請參閱開發軟體設計的模型。
不同種類的圖表可用於描述不同抽象層級的設計。 許多圖表類型可用於多個層級。 下表顯示每種圖表類型的使用方式。
設計層級 |
圖表類型 |
|---|---|
商務程序 了解即將使用系統的內容可協助您了解使用者的需求。 |
|
使用者需求 使用者對於系統需求的定義。 |
|
高階設計 系統的整體結構：主要元件以及它們如何結合在一起。 |
|
設計模式 在所有設計部分中使用的設計問題解決慣例和方法 |
|
程式碼分析 您可以從程式碼產生許多圖表類型。 |
|
外部資源
分類 |
連結 |
|---|---|
視訊 |
|
論壇 |
|
網誌 |
|
技術文章和日誌 |
|
其他網站 |
.gif "視訊的連結")