情節概觀：使用視覺化和模型功能變更設計

若要確定您的軟體系統能符合使用者的需要，請使用在 Visual Studio Ultimate 裡的視覺化和模型工具協助更新或變更系統的設計。這些工具包括 Unified Modeling Language (UML) 圖表、圖層圖表、程式碼架構的相依性圖形、順序圖表和類別圖表。 例如，您可以使用這些工具來執行下列工作:

• 釐清使用者的需求和商務程序。

• 視覺化和探索現有程式碼。

• 描述現有系統的變更。

• 確認系統符合其需求。

• 讓程式碼與設計保持一致。

此逐步解說使用範例案例來完成下列目標：

• 提供這些工具的高階概觀，以及對軟體專案帶來的好處。

• 說明兩個小組如何在一個範例案例中使用這些工具，不論它們的開發方法為何。

如需這些工具及其支援之案例的詳細資料，請參閱：

• 模型化應用程式

• 顯現程式碼內容及其關聯性使其更容易理解

• 開發軟體設計的模型

本主題內容

章節	描述
案例概觀	描述範例案例及其參與者。
軟體開發中架構和模型圖表的角色	描述這些工具在應用程式開發週期期間可以扮演的角色。
了解並溝通有關系統的資訊	提供本案例之參與者如何使用這些工具的高階概觀。
使用視覺化和模型更新系統	提供有關各工具以其在本案例中之用法的更深入詳細資料。

案例概觀

本案例在描述兩個虛構公司 Dinner Now 和 Lucerne Publishing 在軟體開發週期所發生的連續事件。 Dinner Now 在西雅圖提供餐點外送服務。 客戶可以在 Dinner Now 網站上訂餐和付款。 接著，訂單會傳送到合適的當地餐廳以準備外送。 Lucerne Publishing 是一家位在紐約的公司，營業項目包括幾個網路和非網路服務。 例如，客戶可以在其經營的網站張貼對餐廳的評論。

Lucerne 最近併購 Dinner Now 並想要進行下列變更：

• 整合雙方網站，在 Dinner Now 網站中加入餐廳評論功能。

• 將 Dinner Now 付款系統更換成 Lucerne 系統。

• 展開 Dinner Now 整個區域現在為服務。

Dinner Now 使用的是 SCRUM 和 eXtreme 程式設計。 它們的測試涵蓋範圍非常高，不受支援的程式碼非常低。 它們會先建立小型但可運作的系統版本，然後以累加的方式加入功能，藉此將風險降到最低。 它們採取短暫且頻繁的反覆方式來開發程式碼。 如此，它們可以對所做的變更很有信心，常常重構程式碼，以及避免「明顯龐大設計」。

Lucerne 則維持一個相當大型且複雜的系統集合，其中有些系統已超過 40 年。 鑑於舊有程式碼的複雜度和範圍，使得它們對變更相當的謹慎。 它們遵循極嚴格的開發程序，要求設計詳細的解決方案，並將開發期間所做的設計和變更記錄下來。

雙方小組都使用 Visual Studio Ultimate 的模型圖表，協助它們開發符合使用者需求的系統。 同時也使用 Team Foundation Server搭配其他工具，以協助它們規劃、組織和管理工作。

如需更多 Team Foundation Server 的詳細資訊，請參閱:

• 規劃和追蹤工作

• 在更新的程式碼中進行測試、驗證和檢查

軟體開發中架構和模型圖表的角色

下列表格描述在軟體開發週期的多個和多種階段中，這些工具所扮演的角色：

	使用者需求模型化	商務程序模型化	系統架構和設計	程式碼視覺化和探索	驗證
使用案例圖表 (UML)	√	√			√
活動圖表 (UML)	√	√	√		√
類別圖表 (UML)	√	√	√		√
元件圖表 (UML)	√	√	√		√
順序圖表 (UML)	√	√	√		√
網域特定語言 (DSL) 圖表	√	√	√
圖層圖表、圖層驗證			√	√	√
相依性圖形 (以程式碼為基礎)			√	√	√
順序圖表 (以程式碼為基礎)				√	√
類別設計工具 (以程式碼為基礎)				√
架構總管				√

若要繪製 UML 圖表和圖層圖表，您必須在現有方案或新方案中建立模型專案。 這些圖表必須建立在模型專案中。 UML 圖表上的項目是通用模型的一剖分，而 UML 圖表是該模型的檢視。 圖層圖表上的項目位於模型專案中，但不會儲存在通用模型中。 以程式碼為基礎的相依性圖形、順序圖表和類別圖表通常位在模型專案之外。

請參閱：

• HOW TO：建立 UML 模型專案和圖表

• 從程式碼建立圖層圖表

• 根據相依性圖形顯現程式碼相依性

• 藉由產生順序圖表顯現程式碼內容及其關聯性

• HOW TO：將類別圖表加入至專案 (類別設計工具)

• Visualization and Modeling SDK - 網域指定的語言

若要顯示架構的替代檢視，您可以在多個或不同圖表上重複使用相同模型中的特定項目。 例如，您可將元件拖曳到另一個元件圖表或順序圖表，此元件即可做為行動。 請參閱 HOW TO：編輯 UML 模型和圖表。

雙方小組也會使用圖層驗證以確定開發中的程式碼與設計保持一致。

請參閱：

• 讓程式碼與設計保持一致。

• 描述邏輯架構：圖層圖表

• 使用圖層圖表驗證程式碼

  注意事項
  Visual Studio Premium 支援圖層驗證和這些用於視覺化和模型化作業之圖形和圖表的唯讀版本。

了解並溝通有關系統的資訊

Visual Studio Ultimate 模型圖表並沒有規定使用順序，所以您可以依需求或方法來使用它們。 小組在整個專案進行期間，通常會頻繁地反覆重新審視其模型。 每個圖表都具有特定優勢，可協助您了解、描述和溝通開發中之系統的不同層面。

Dinner Now 和 Lucerne 在彼此溝通和與專案關係人溝通時，會使用圖表做為它們的共同語言。 例如，Dinner Now 會使用圖表執行這些工作：

• 視覺化現有程式碼。

• 與 Lucerne 溝通新的或更新的使用者劇本。

• 識別為支援新的或更新的使用者劇本所必須進行的變更。

Lucerne 會使用圖表執行這些工作：

• 了解 Dinner Now 商務程序。

• 了解系統的設計。

• 與 Dinner Now 溝通有關新的或更新的使用者需求。

• 記錄對系統所做的更新。

圖形藉由 Team Foundation Server來整合所以小組可以計劃，處理和更輕鬆地追蹤其工作。例如，它們可以使用模型來識別測試案例和開發工作以及評估其工作。 Lucerne 將Team Foundation Server工作項目連結到模型項目，如此它們可監視進度和確定系統符合使用者的需求。 例如，它們將使用案例連結到測試案例工作項目，如此在所有測試通過時即可知道使用案例已完成。

小組在簽入變更之前，會執行包含圖層驗證和自動化測試的組建，藉此根據測試和設計驗證程式碼。 這樣有助於確定更新的程式碼不會與設計衝突，且不會破壞先前可運作的功能。

請參閱：

• 了解系統在商務程序中的角色

• 說明新的或更新的使用者需求

• 從模型建立測試

• 識別現有系統的變更

• 讓程式碼與設計保持一致。

• 建立和使用模型的一般密訣

• 規劃和追蹤工作

• 在更新的程式碼中進行測試、驗證和檢查

了解系統在商務程序中的角色

Lucerne 想要了解 Dinner Now 商務程序。 它們建立下列圖表以協助它們更快了解 Dinner Now：

圖表	說明
使用案例圖表 (UML) 請參閱： UML 使用案例圖表：參考 UML 使用案例圖表：方針	Dinner Now 系統支援的活動 執行活動的人員和外部系統 支援每個活動之系統的主要元件 目前系統範圍之外的商務程序組成部分，例如食物外送
活動圖表 (UML) 請參閱： UML 活動圖表：參考 UML 活動圖表：方針	當客戶建立訂單後會發生的步驟流程
類別圖表 (UML) 請參閱： UML 類別圖表：參考 UML 類別圖表：方針	商務實體以及這些實體間的討論和關聯性所用的詞彙。 例如，「訂單」和「菜單項目」為本案例所用的詞彙。

例如，Lucerne 會建立下列使用案例圖表以了解在 Dinner Now 網站上執行的工作以及執行的人員。

UML 使用案例圖表

下列活動圖表描述客戶在 Dinner Now 網站建立訂單時，系統會進行的步驟流程。 在此版本中，註解項目會識別角色且行會建立「泳道」(Swimlane)，它們會依角色組織步驟：

UML 活動圖表

下列類別圖表描述參與訂單流程的實體：

UML 類別圖表

說明新的或更新的使用者需求

Lucerne 想要在 Dinner Now 系統中新增功能，讓客戶可以閱讀和張貼對餐廳的評論。 它們會更新下列圖表，以便與 Dinner Now 描述和討論這個新需求。

圖表	說明
使用案例圖表 (UML) 請參閱： UML 使用案例圖表：參考 UML 使用案例圖表：方針	用於「撰寫餐廳評論」的新使用案例
活動圖表 (UML) 請參閱： UML 活動圖表：參考 UML 活動圖表：方針	客戶想要撰寫餐廳評論時會發生的步驟
類別圖表 (UML) 請參閱： UML 類別圖表：參考 UML 類別圖表：方針	必須要有這些資料才能儲存評論。

例如，下列使用案例圖表包含新的「撰寫評論」使用案例以代表新的需求。 它在圖表上會以橙色醒目提示以方便使用者辨識：

UML 使用案例圖表

下列活動圖表包含新項目 (以橙色表示) 以描述新使用案例中的步驟流程。

UML 活動圖表

下列類別圖表包含新的評論類別及它與其他類別的關聯性，如此小組可以討論其詳細內容。 請注意，客戶和餐聽可以有多個評論：

UML 類別圖表

從模型建立測試

雙方小組同意在進行任何變更前，必須針對系統及其元件執行一組完整的測試。 Lucerne 有專門小組在執行系統和元件層級的測試。 它們重複使用 Dinner Now 所建立的測試，並使用 UML 圖表組織這些測試：

• 每個使用案例由一個或多個測試表示。 使用案例圖表上的項目會連結到 Team Foundation Server中的「測試案例」工作項目。

• 活動圖表或系統層級之順序圖表上的每個流程至少會連結到一個測試。 測試小組以有系統的方式確定它們會測試到整個活動圖表的每個可能路徑。

• 用來描述測試的詞彙是源自使用案例、類別和活動圖表所定義的詞彙。

當需求變更且圖表經更新以反映這些變更時，測試會隨著更新。 當所有測試通過時即表示完成需求。 當情況允許時，在實作開始前會根據 UML 圖表定義測試。

請參閱：

• 從模型開發測試

• 驗證 UML 模型

識別現有系統的變更

Dinner Now 必須評估符合新需求所需的成本。 這個部分取決於此變更對系統其他部分會造成多大的影響。 為協助它們了解，Dinner Now 其中一位開發人員從現有程式碼建立下列圖形和圖表：

圖形或圖表	顯示
相依性圖形 請參閱： 根據相依性圖形顯現程式碼相依性 瀏覽和重新排列相依性圖形 編輯和自訂相依性圖形 使用架構總管尋找程式碼	程式碼中的相依性和其他關聯性 例如，Dinner Now 可能一開始會檢閱組件相依性圖形，以綜覽組件及其相依性。 它們可以深入研究圖形，以探索這些組件中的命名空間和類別。 Dinner Now現在也可以創造一般圖形以探索程式碼中的特定區域或其他種類的關聯性。 它們可以使用 [架構總管]或[方案總管]來協助它們尋找並選取其感興趣的區域和關聯性。
以程式碼為基礎的順序圖表 請參閱 藉由產生順序圖表顯現程式碼內容及其關聯性。	執行個體間互動的順序。 順序圖表是從方法定義產生，可協助了解程式碼如何實作方法行為。
以程式碼為基礎的類別圖表 請參閱 HOW TO：將類別圖表加入至專案 (類別設計工具)。	程式碼中的現有類別

例如，開發人員使用 [架構總管] 選取使用者想要壓力並從程式碼建立相依性圖形的命名空間。 接著調整其範圍以便將焦點放在新案例會影響的區域。 這些區域在圖形中會處於選取和醒目提示的狀態：

命名空間相依性圖形

開發人員展開選取的命名空間以查看它們的類別、方法和關聯性：

展開的命名空間相依性圖形，包含可見的跨群組連結

開發人員檢查程式碼以找出受影響的類別和方法。 接著從程式碼產生順序圖表和類別圖表以描述和討論變更。 請參閱 顯現程式碼內容及其關聯性使其更容易理解。

提示

若要在每次變更時查看所產生的影響，請在每次變更後從程式碼重新產生相依性圖形和順序圖表。

為了描述對系統其他組成部分 (例如元件或反覆項目) 所造成的變更，小組可能會在白板上繪製這些項目。 它們可能也會在 Visual Studio中繪製下列圖表，如此雙方小組即可擷取、管理和了解相關詳細資料。

圖表	說明
活動圖表 (UML) 請參閱： UML 活動圖表：參考 UML 活動圖表：方針	當系統注意到客戶再次下訂單時所產生的步驟流程，系統會提示客戶撰寫評論。
類別圖表 (UML) 請參閱： UML 類別圖表：參考 UML 類別圖表：方針	邏輯類別及其關聯性。 例如，系統會加入新類別以便描述 [評論] 以及與其他實體 (例如 [餐廳]、[菜單] 和 [客戶]) 的關聯性。 若要將評論與客戶相關聯，系統必須儲存客戶詳細資料。 UML 類別圖表可協助釐清這些詳細資料。
以程式碼為基礎的類別圖表 請參閱 HOW TO：將類別圖表加入至專案 (類別設計工具)。	程式碼中的現有類別。
元件圖表 (UML) 請參閱： UML 元件圖表：參考 UML 元件圖表：方針	系統的高階組成部分，例如 Dinner Now 網站及其介面。 這些介面可定義元件如何透過其所提供和使用的方法或服務，與其他元件互動。
順序圖表 (UML) 請參閱： UML 順序圖表：參考 UML 順序圖表：方針	執行個體間互動的順序。

例如，下列元件圖表顯示屬於 Dinner Now 網站元件的新元件。 ReviewProcessing 元件會處理用來建立評論的功能，此元件以橙色醒目提示。

UML 元件圖表

下列順序圖表顯示當 Dinner Now 網站檢查客戶是否曾訂過餐時會發生的反覆項目順序。 如果曾訂過餐，系統即會要求客戶建立評論，然後將評論傳送到餐廳並在網站上公佈。

UML 順序圖表

讓程式碼與設計保持一致。

Dinner Now 必須確定更新的程式碼與設計保持一致。 它們建立會描述系統功能圖層的圖層圖表、指定圖層間的允許相依性，以及將方案成品與這些圖層相關聯。

圖表	說明
圖層圖表 請參閱： 從程式碼建立圖層圖表 圖層圖表：參考 圖層圖表：方針 使用圖層圖表驗證程式碼	程式碼的邏輯架構。 圖層圖表會將 Visual Studio 方案中的成品組織並對應到稱為「圖層」(Layer) 的抽象群組。 這些圖層可識別這些成品在系統中執行的角色、工作或功能。 圖層圖表有助於說明系統的預定設計，以及根據設計驗證不斷發展的程式碼。 若要建立圖層，請從方案總管、相依性圖形或架構總管拖曳項目。 若要繪製新圖層，請使用工具箱或以滑鼠右鍵按一下圖表介面。 若要檢視現有相依性，請以滑鼠右鍵按一下圖層圖表介面，然後按一下 [產生相依性]。 若要指定預定的相依性，請拖曳新相依性。

例如，下列圖層圖表會描述圖層間的相依性，以及與每個圖層相關聯的成品數目。

圖層圖表

若要確定在程式碼開發期間不會發生與設計衝突的狀況，小組可針對在Team Foundation Build上執行的組建使用圖層驗證。 它們也可以建立自訂 MSBuild工作，在簽入作業中要求圖層驗證。 它們可以使用組建報告收集驗證錯誤。

請參閱：

• 定義您的建置流程

• 定義閘道簽入建置流程來驗證變更

• 開發自訂建置流程

建立和使用模型的一般密訣

• 大部分的圖表是由以線條連結之節點所組成。 針對每個圖表類型，工具箱提供不同種類的節點和線條。

  若要開啟工具箱，請在 [檢視] 功能表上按一下 [工具箱]。

• 若要建立節點，請從工具箱將它拖曳到圖表。 特定種類的節點必須拖曳到現有節點上。 例如，在元件圖表上，新連接埠必須加入到現有元件上。

• 若要建立線條或是連接，請在工具箱中按一下適當的工具、按一下來源節點，再按一下目標節點。 某些線條只能建立在特定種類的節點之間。 當您將指標移到可能的來源或目標上，指標會指出您是否可以建立連接。

• 當您在 UML 圖表上建立項目，同時也會將這些項目加入到通用模型。 模型專案中的 UML 圖表為該模型的檢視。 圖層圖表上的項目即使不會儲存在通用模型中，仍屬於模型專案的一部分。

  若要看模型，在 [架構] 功能表中指向 [視窗]，然後按一下 [UML 模型總管]。

• 在某些情況中，您可以從 [UML模型總管] 將特定項目拖曳到 UML 圖表。 相同模型中的某些項目可以用在多個或不同的圖表，以顯示架構的替代檢視。 例如，您可將元件拖曳到另一個元件圖表或順序圖表中做為行動。

• Visual Studio Ultimate 支援 UML 2.1.2。 本概述僅描述此版本中 UML 圖表的主要功能，還有許多書籍在詳細討論 UML 及其用法。

請參閱 開發軟體設計的模型。

規劃和追蹤工作

Visual Studio Ultimate模型已經和Team Foundation Server使您可以更輕鬆的計畫、管理以及追蹤。雙方小組使用模型來識別測試案例和開發工作以及評估其工作。 Lucerne 建立Team Foundation Server工作項目並連結到模型項目，例如使用案例或元件。 這樣可協助它們針對使用者需求來監視進度和追蹤工作。 也可協助它們確定所做的變更能一直符合這些需求。

當工作進行時，小組會更新工作項目以反映實際花在工作上的時間。 它們也會使用下列Team Foundation Server功能來監視和報告工作狀態：

• 每日「待執行工作報表」(Burndown Report)，此報表會顯示它們是否會在預定時間內完成規劃的工作。 它們會從 Team Foundation Server 產生其他類似的報表追蹤 Bug 進度。

• 「反覆項目工作表」(Iteration Worksheet)，此工作表使用Microsoft Excel協助小組監視和平衡小組成員的工作量。 此工作表連結到 Team Foundation Server並在定期進度會議中提供討論重點。

• 「開發儀表板」(Development Dashboard)，此儀表板使用 Office Project 讓小組隨時獲知重要的專案資訊。

請參閱：

• 計劃和追蹤專案

• 追蹤工作和管理工作流程

• 連結模型項目和工作項目

• 建立、自訂和管理 Visual Studio ALM 的報表

• 使用 Microsoft Project 排程工作和指派資源

在程式碼中進行測試、驗證和檢查

當小組完成每項工作，如果它們忘記，它們將程式碼簽入至 Team Foundation 版本控制和接收從 Team Foundation Server 上。 在Team Foundation Server接受它們簽入的程式碼之前，小組會執行單元測試和圖層驗證以根據測試案例和設計驗證程式碼。 它們使用 Team Foundation Server 定期執行組建、自動化單元測試和圖層驗證。 這樣有助於確定程式碼符合下列準則：

• 可運作。

• 不會破壞先前可運作的程式碼。

• 不會與設計衝突。

Dinner Now 擁有大型自動化測試集合，因為這些測試幾乎仍適用，所以 Lucerne 可重複使用。 Lucerne 也可以根據這些測試進行建置，並加入新測試以涵蓋新功能。 同時也會使用 Visual Studio Ultimate 執行手動測試。

若要確定程式碼符合設計，小組將它們在 Team Foundation Build 的組建包含圖層驗證。如果發生任何衝突，產生報告詳細資料。

請參閱：

• 測試應用程式

• 在開發期間驗證您的系統

• 使用版本控制

• 建置應用程式

使用視覺化和模型更新系統

Lucerne 和 Dinner Now 必須整合它們的付款系統。 下列各節將示範 Visual Studio Ultimate 模型圖表可協助它們執行這項工作:

• 了解使用者需求：使用案例圖表

• 了解商務程序：活動圖表

• 描述系統架構：元件圖表

• 描述互動：順序圖表

• 視覺化現有程式碼：相依性圖形

• 定義型別的詞彙：類別圖表

• 描述邏輯架構：圖層圖表

請參閱：

• 開發軟體設計的模型

• 顯現程式碼內容及其關聯性使其更容易理解

• 在開發程序中使用模型

• 模型化使用者要求

• 模型化軟體系統的架構

了解使用者需求：使用案例圖表

使用案例圖表會摘要說明系統支援的活動以及執行這些活動的人員。 Lucerne 利用使用案例圖表來了解 Dinner Now 系統的下列項目。

• 客戶建立訂單。

• 餐廳收到訂單。

• 外部付款處理器閘道 (Dinner Now 付款系統用來驗證付款) 不在網站範圍內。

圖表也會顯示某些主要使用案例如何分成較小的使用案例。 Lucerne 想要使用自己的付款系統。 它們以不同顏色醒目提示「處理付款」使用案例，以表示此使用案例需要變更：

在使用案例圖表上醒目提示「處理付款」

如果開發時間短，小組可能會討論是否要讓客戶直接付款給餐廳。 若要顯示此做法，它們會將「處理付款」使用案例更換成在 Dinner Now 系統範圍之外的使用案例。 接著它們會將「客戶」直接連結到「餐廳」，表示 Dinner Now 只會處理訂單：

在使用案例圖表上重新設定「付款給餐廳」的範圍

請參閱：

• UML 使用案例圖表：參考

• UML 使用案例圖表：方針

繪製使用案例圖表

使用案例圖表具有下列主要功能：

• 「行動」(Actor) 代表人員、組織、機器或軟體系統所扮演的角色。 例如「客戶」、「餐廳」和「Dinner Now 付款系統」為行動。

• 「使用案例」(Use Case) 代表行動與開發中系統之間的互動。 它們可以代表任何規模的互動，從單一滑鼠點選或訊息到延續多天的交易皆可。

• 「關聯」(Association) 可將行動連結到使用案例。

• 大型使用案例可以「包含」(Include) 小型使用案例，例如「建立訂單」包含「選取餐廳」。 您可以「擴充」(Extend) 使用案例，將目標和步驟加入到擴充的使用案例，以表示使用案例只有在特定條件下才會發生。 使用案例也可以彼此繼承。

• 「子系統」(Subsystem) 代表開發中的軟體系統或其中的一個元件。 它是包含使用案例的大型方塊。 使用案例圖表會釐清哪些使用案例位在子系統範圍內或外。 若要表示使用者必須以其他方法完成特定目標，請繪製這些位在子系統範圍之外的使用案例。

• 「成品」(Artifact) 可將圖表上的項目連結到其他圖表或文件。

請參閱：

• UML 使用案例圖表：參考

• UML 使用案例圖表：方針

摘要：使用案例圖表的優勢

使用案例圖表可協助您視覺化：

• 系統支援或不支援的活動

• 執行這些活動的人員和外部系統

• 支援每個活動之系統的主要元件，您可將其表示為巢狀在父系統內部的子系統

• 使用案例如何分成較小的使用案例或變體

與其他圖表的關聯性

圖表	說明
活動圖表	使用案例中的步驟流程，以及在該使用案例中執行這些步驟的人員。 使用案例名稱通常會反映活動圖表中的步驟。 活動圖表支援像是決策、合併、輸入和輸出、並行的流程等項目。 請參閱： UML 活動圖表：參考 UML 活動圖表：方針
順序圖表	使用案例參與者之間的互動順序。 請參閱： UML 順序圖表：參考 UML 順序圖表：方針
類別圖表 (UML)	參與使用案例的實體或型別。 請參閱： UML 類別圖表：參考 UML 類別圖表：方針

了解商務程序：活動圖表

活動圖表描述商務程序中的步驟流程，並提供簡單的方法來溝通工作流程。 開發專案可以有多個活動圖表。 活動通常包含一個外部動作產生的所有動作，例如訂餐、更新菜單或將新餐廳加入營業。 活動可能也會描述複雜動作的詳細資料。

Lucerne 更新下列活動圖表以顯示 Lucerne 會處理付款並支付給餐廳。 它們將 Dinner Now 付款系統更換成 Lucerne 付款系統，如下醒目提示：

在活動圖表上更換 Dinner Now 付款系統

更新的圖表可協助 Lucerne 和 Dinner Now 視覺化在商務程序中放入 Lucerne 付款系統的位置。 在此版本中，註解是用來識別執行步驟的角色。 線條是用來建立「泳道」(Swimlane)，它們會依角色組織步驟。

小組可能也考慮討論替代的劇本，讓客戶付款給餐廳而不是在訂單送出後付款。 這樣會針對軟體系統建立不同的需求。

Dinner Now 之前會在白板或 PowerPoint 中繪製這些圖表。 現在它們也使用Visual Studio Ultimate 繪製這些圖表，如此雙方小組即可擷取、了解和管理詳細資料。

請參閱：

• UML 活動圖表：參考

• UML 活動圖表：方針

繪製活動圖表

活動圖表具有下列主要功能：

• 「初始節點」(Initial Node)，表示活動的第一個動作。

  圖表應該永遠要有這些節點的其中一個。

• 「動作」(Action)，描述使用者或軟體會在其中執行工作的步驟。

• 「控制流程」(Control Flow)，顯示動作之間的流程。

• 「決策節點」(Decision Node)，代表流程中的條件分支。

• 「分岔節點」(Fork Node)，將單一流程分成並行的流程。

• 「活動的最後節點」(Activity Final Node)，顯示活動的終點。

  雖然這些節點是選擇性的，將它們加入到圖表以顯示活動在何處結束，這種做法會很有幫助。

請參閱：

• UML 活動圖表：參考

• UML 活動圖表：方針

摘要：活動圖表的優勢

活動圖表可協助您視覺化和描述控制流程以及商務、系統或程式之動作間的資訊。 這是與他人溝通描述工作流程的簡單實用方法。

與其他圖表的關聯性

圖表	描述
使用案例圖表	摘要說明每個行動執行的活動。 請參閱： UML 使用案例圖表：參考 UML 使用案例圖表：方針
元件圖表	將系統視覺化為可重覆使用的組件集合，透過一組妥善定義的介面來提供或使用行為。 請參閱： UML 元件圖表：參考 UML 元件圖表：方針

描述系統架構：元件圖表

元件圖表將系統描述為可分隔的組件集合，透過一組妥善定義的介面來提供或使用行為。 這些組件可以是任何規模且可以採用任何方式連接。

為協助 Lucerne 和 Dinner Now 視覺化和討論系統的元件及其介面，它們建立下列元件圖表：

Dinner Now 付款系統的元件

此圖表顯示不同的元件型別及其「相依性」(Dependency)。 例如，Dinner Now 網站和 Lucerne 付款系統需要「外部付款處理器閘道」來驗證付款。 元件之間的箭號代表相依性，指出哪些元件需要其他元件的功能。

為使用 Lucerne 付款系統，Dinner Now 網站必須更新以使用 Lucerne 付款系統的 PaymentApproval 和 PayableInsertion 介面。

下列圖表顯示 Dinner Now 網站的特定元件組態。 這個組態表示網站的任一執行個體是由四個「組件」(Part) 組成的。

• CustomerProcessing

• OrderProcessing

• ReviewProcessing

• PaymentProcessing

這些組件是指定之元件型別的執行個體，會以下列方式連接：

Dinner Now 網站內部的元件

Dinner Now 網站將其行為委派給這些組件，這些組件會處理網站的功能。 父元件及其成員元件間的箭號其作用在顯示「委派」(Delegation)，表示哪些組件會處理父元件透過其介面接收或傳遞的訊息。

在這個組態中，PaymentProcessing 元件會處理客戶付款。 因此，這個元件必須更新以與 Lucerne 付款系統整合。 其他案例中，相同父元件中可能存在同一元件型別的多個執行個體。

請參閱：

• UML 元件圖表：參考

• UML 元件圖表：方針

繪製元件圖表

元件圖表具有下列主要功能：

• 「元件」(Component)，代表系統功能的組成部分，可加以分隔。

• 「提供的介面連接埠」(Provided Interface Port)，代表訊息或呼叫群組，由元件實作並由其他元件或外部系統使用。

• 「必要的介面連接埠」(Required Interface Port)，代表訊息或呼叫群組，元件會傳送給其他元件或外部系統。 這種連接埠描述元件預期其他元件或外部系統至少會使用的作業。

• 「組件」(Part) 是元件的成員，通常是其他元件的執行個體。 組件是父元件內部設計的組成部分。

• 「相依性」(Dependency)，表示元件需要其他元件的功能。

• 「委派」(Delegation)，表示元件的組件會處理父元件傳送或接收的訊息。

請參閱：

• UML 元件圖表：參考

• UML 元件圖表：方針

摘要：元件圖表的優勢

元件圖表可協助您視覺化：

• 以一組可分隔組件表示的系統，不論其實作語言或樣式為何。

• 具有定義妥善之介面的元件，在變更需求時讓設計更易於了解和更新。

與其他圖表的關聯性

圖表	描述
相依性圖形	視覺化現有程式碼中的組織和關聯性。 若要識別候選元件，請建立相依性圖形，並依其在系統中的功能群組項目。 請參閱： 根據相依性圖形顯現程式碼相依性 編輯和自訂相依性圖形
順序圖表	視覺化元件或元件內部組件間的互動順序。 若要在順序圖表上從元件建立生命線，請以滑鼠右鍵按一下元件，然後按一下 [建立生命線]。 請參閱： UML 順序圖表：參考 UML 順序圖表：方針
類別圖表 (UML)	定義提供連接埠或必要連接埠上的介面，以及定義實作元件功能的類別。 請參閱： UML 類別圖表：參考 UML 類別圖表：方針
圖層圖表	描述與元件相關的系統邏輯架構。 使用圖層驗證以確定程式碼與設計一致。 請參閱： 從程式碼建立圖層圖表 圖層圖表：參考 圖層圖表：方針 使用圖層圖表驗證程式碼
活動圖表	視覺化元件為回應傳入訊息所執行的內部處理。 請參閱： UML 活動圖表：參考 UML 活動圖表：方針

視覺化現有程式碼：相依性圖形

相依性圖形顯示程式碼的目前組織和關聯性。 物件是以「節點」(Node) 表示項目，以「連結」(Link) 表示關聯性。 相依性圖形可協助您執行下列種類的工作：

• 探索不熟悉的程式碼。

• 了解建議的變更可能會影響現有程式碼的哪個部分以及如何影響。

• 尋找具複雜度的區域、自然圖層或模式，或是可能因改善而受惠的其他區域。

例如，Dinner Now 必須評估更新 PaymentProcessing 元件所需的成本。 這個部分取決於此變更對系統其他部分會造成多大的影響。 為協助它們了解，Dinner Now 開發人員從程式碼產生相依性圖形，並將範圍焦點調整在可能受變更影響的區域：

下列圖形顯示 PaymentProcessing 類別和 Dinner Now 系統其他部分之間的相依性，以選取狀態顯示：

Dinner Now 付款系統的相依性圖形

開發人員探索圖形，方法是展開 PaymentProcessing 類別並選取其成員，以查看可能受影響的區域。

PaymentProcessing 類別內部方法及其相依性

他們針對 Lucerne 付款系統產生下列圖形以查看其類別、方法和相依性。 小組發現 Lucerne 系統可能也需要與 Dinner Now 系統其他部分互動：

Lucerne 付款系統的相依性圖形

雙方小組合作以確定為整合雙方系統所需進行的變更。 它們決定重構部分程式碼，以方便更新。 PaymentApprover 類別將移到 DinnerNow.Business 命名空間，且需要一些新方法。 處理交易的 Dinner Now 類別將擁有自己的命名空間。 小組建立並使用工作項目以規劃、組織和追蹤工作。 它們將工作項目連結到模型項目，這樣做很有用。

在重新組織程式碼之後，小組產生新的相依性圖形以查看更新的結構和關聯性：

內含經重新組織之程式碼的相依性圖形

這個圖形顯示 PaymentApprover 類別目前已位於 DinnerNow.Business 命名空間中，且具有一些新方法。 Dinner Now 交易類別現在已擁有自己的 PaymentSystem 命名空間，之後處理該程式碼會變得更容易。

建立相依性圖形

• 若要快速綜覽原始程式碼，請遵循這些步驟產生相依性圖形：

  在 [架構] 功能表上，指向 [產生相依性圖形]，然後按一下 [For Solution] (依包含的檔案)。

  若要快速綜覽已編譯的程式碼，請建立空白相依性圖形，然後將組件檔或二進位檔拖曳到圖形介面。

  請參閱 根據相依性圖形顯現程式碼相依性。

• 若要探索特定程式碼或方案項目，請使用 [架構總管] 或[方案總管]來選取想要視覺化的項目和關聯性。 然後您可以產生新圖形，或將所選項目加入到現有圖形。

  請參閱根據相依性圖形顯現程式碼相依性和使用架構總管尋找程式碼。

• 若要易於探索圖形，請重新整理配置，以適合您要執行的工作種類。

  例如，若要視覺化程式碼圖層，請選取樹狀配置。 請參閱 瀏覽和重新排列相依性圖形。

• 若要易於將焦點放在圖形的特定區域，請篩選出項目或自訂物件外觀以調整圖形範圍。 請參閱 編輯和自訂相依性圖形。

摘要：相依性圖形的優勢

相依性圖形可協助您：

• 了解現有程式碼的組織和關聯性。

• 識別可能受建議的變更影響的區域。

• 尋找具複雜度的區域、模式、圖層，或是可加以改善而讓程式碼更易於維護、變更和重複使用的其他區域。

與其他圖表的關聯性

圖表	說明
圖層圖表	系統的邏輯架構。 使用圖層驗證以確定程式碼與設計一致。 若要易於識別現有圖層或預定圖層，請建立相依性圖形並群組相關項目。 若要建立圖層圖表，請從圖形或 [架構總管] 拖曳項目。 請參閱： 從程式碼建立圖層圖表 圖層圖表：參考 圖層圖表：方針 使用圖層圖表驗證程式碼
元件圖表	元件、其介面和關聯性。 若要易於識別元件，請建立相依性圖形，並依其在系統中的功能群組項目。 請參閱： UML 元件圖表：參考 UML 元件圖表：方針
類別圖表 (UML)	類別、其屬性與作業和關聯性。 若要易於識別這些項目，請建立會顯示這些項目的圖形文件。 請參閱： UML 類別圖表：參考 UML 類別圖表：方針
類別圖表 (以程式碼為基礎)	程式碼中的現有類別。 若要視覺化和修改程式碼中的現有類別，請使用 [類別設計工具]。 請參閱 HOW TO：將類別圖表加入至專案 (類別設計工具)。

描述互動：順序圖表

順序圖表描述系統組成部分之間的一系列互動。 組成部分可以是任何規模。 例如，它們的範圍可從程式的個別物件到大型子系統或外部行動。 互動可以是任何規模和類型。 例如，它們的範圍可從個別訊息到擴充的交易，而且可做為函式呼叫或 Web 服務訊息。

為協助 Lucerne 和 Dinner Now 描述和討論「處理付款」使用案例中的步驟，它們從元件圖表建立下列順序圖表。 生命線反映 Dinner Now 網站元件及其組件。 出現在生命線之間的訊息遵循元件圖表上的連接。

「處理付款」使用案例的順序圖表

順序圖表顯示客戶建立訂單時，Dinner Now 網站會在 OrderProcessing 執行個體上呼叫 ProcessOrder。 接著，OrderProcessing 會在 PaymentProcessing 上呼叫 ProcessPayment。 這項作業會一直持續直到「外部付款處理器閘道」驗證付款。 唯有如此，控制權才會回到 Dinner Now 網站。

Lucerne 必須針對更新其付款系統以與 Dinner Now 系統整合這項工作，評估其成本。 為協助它們了解，其中一位開發人員從程式碼產生順序圖表，以視覺化現有互動。

請參閱：

• UML 順序圖表：參考

• UML 順序圖表：方針

• 藉由產生順序圖表顯現程式碼內容及其關聯性

繪製順序圖表

順序圖表具有下列主要功能：

• 垂直「生命線」(Lifeline) 代表行動或軟體物件的執行個體。

  若要加入行動符號 (表示參與者在開發中系統之外)，請按一下生命線。 在 [屬性] 視窗中，將 [行動] 設為 [True]。 如果 [屬性] 視窗未開啟，請按 F4。

• 水平「訊息」(Message) 代表方法呼叫、Web 服務訊息或一些其他通訊。 「執行出現次數」(Execution Occurrence) 是出現在生命線上帶有垂直陰影的矩形，代表接收物件處理呼叫的期間。

• 在「同步」(Synchronous) 訊息期間，傳送者物件會等待控制權移到 <<return>>，如同一般函式呼叫。 在「非同步」(Asynchronous) 訊息期間，傳送者可立即繼續。

• 使用 <<create>> 訊息以表示物件由其他物件建構。 這應該是第一個傳送到物件的訊息。

請參閱：

• UML 順序圖表：參考

• UML 順序圖表：方針

摘要：順序圖表的優勢

順序圖表可協助您視覺化：

• 在使用案例執行期間於行動或物件間傳送的控制流程。

• 方法呼叫或訊息的實作。

與其他圖表的關聯性

圖表	描述
類別圖表 (UML)	定義生命線代表的類別，以及定義參數和傳回值，此參數和傳回值用於在生命線之間傳送的訊息中。 若要從生命線建立類別，請以滑鼠右鍵按一下生命線，然後按一下 [建立類別] 或 [建立介面]。 若要在類別圖表上從型別建立生命線，請以滑鼠右鍵按一下型別，然後按一下 [建立生命線]。 請參閱： UML 類別圖表：參考 UML 類別圖表：方針
元件圖表	描述生命線代表的元件，以及描述會提供和使用訊息代表之行為的介面。 若要從元件圖表建立生命線，請以滑鼠右鍵按一下元件，然後按一下 [建立生命線]。 請參閱： UML 元件圖表：參考 UML 元件圖表：方針
使用案例圖表	將順序圖表上使用者和元件之間的互動摘要說明為使用案例，其代表使用者的目標。 請參閱： UML 使用案例圖表：參考 UML 使用案例圖表：方針

定義型別的詞彙：類別圖表

類別圖表定義參與系統的實體、詞彙或概念，以及彼此的關聯性。 例如，您可以在開發期間使用這些圖表描述每個類別的屬性和作業，不論其實作語言或樣式為何。

為協助 Lucerne 描述和討論參與「處理付款」使用案例的實體，它們繪製下列類別圖表：

類別圖表上的「處理付款」實體

這個圖表顯示「客戶」可以有多個訂單和不同的付款方式。 BankAccount 和 CreditCard 都繼承自 Payment。

在開發期間，Lucerne 使用下列類別圖表描述和討論每個類別的詳細資料：

類別圖表上的「處理付款」詳細資料

請參閱：

• UML 類別圖表：參考

• UML 類別圖表：方針

繪製類別圖表

類別圖表具有下列主要功能：

• 型別，例如類別、介面和列舉：

  • 「類別」(Class) 是物件的定義，這些物件共用特定的結構和行為特性。

  • 「介面」(Interface) 會定義物件外部可見行為的一部分。

  • 「列舉」(Enumeration) 是包含一列常值的分類器。

• 「屬性」(Attribute) 是特定型別的值，其描述「分類器」(Classifier) 的每個執行個體。 分類器是型別、元件、使用案例和對等行動的一般名稱。

• 「作業」(Operation) 是分類器執行個體可以執行的方法或函式。

• 「關聯」(Association) 表示兩個分類器之間的某種關聯性。

  • 「彙總」(Aggregation) 是一種關聯，表示兩個分類器之間的共用擁有權。

  • 「複合」(Composition) 是一種關聯，表示兩個分類器之間的整體-部分關聯性。

  若要顯示彙總或複合，請在關聯上設定 [彙總] 屬性。 [共用] 顯示彙總，[複合] (Composite) 則顯示複合 (Composition)。

• 「相依性」(Dependency) 表示變更某個分類器的定義，可能會變更另一個分類器的定義。

• 「一般化」(Generalization) 表示特定分類器的部分定義繼承自一般分類器。 「實現」(Realization) 表示類別實作介面提供的作業和屬性。

  若要建立這些關聯性，請使用 [繼承] 工具。 另外，實現可以用「棒棒糖符號」(Lollipop) 表示。

• 「封裝」(Package) 是分類器、關聯、生命線、元件和其他封裝的群組。 「匯入」(Import) 關聯性表示某個封裝包含另一個封裝的所有定義。

您可以使用 [類別設計工具] 從程式碼建立類別圖表，來開始探索和討論現有類別。

請參閱：

• UML 類別圖表：參考

• UML 類別圖表：方針

• HOW TO：將類別圖表加入至專案 (類別設計工具)

摘要：類別圖表的優勢

類別圖表可協助您定義：

• 討論使用者需求和參與系統的實體時可使用的常用詞彙。 請參閱 模型化使用者要求。

• 系統組成部分 (例如元件) 使用的型別，不論其實作為何。 請參閱 模型化軟體系統的架構。

• 型別之間的關聯性 (例如相依性)。 例如，您可以顯示某個型別可以與另一個型別的多個執行個體相關聯。

與其他圖表的關聯性

圖表	描述
使用案例圖表	定義用於描述使用案例中目標和步驟的型別。 請參閱： UML 使用案例圖表：參考 UML 使用案例圖表：方針
活動圖表	定義會通過物件節點、輸入連接、輸出連接和活動參數節點的資料型別。 請參閱： UML 活動圖表：參考 UML 活動圖表：方針
元件圖表	描述元件、其介面和關聯性。 類別可能也會描述完整元件。 請參閱： UML 元件圖表：參考 UML 元件圖表：方針
圖層圖表	定義與類別相關的系統邏輯架構。 使用圖層驗證以確定程式碼與設計一致。 請參閱： 從程式碼建立圖層圖表 圖層圖表：參考 圖層圖表：方針 使用圖層圖表驗證程式碼
順序圖表	定義生命線的型別，以及生命線可以接收之所有訊息的作業、參數和傳回值。 若要在類別圖表上從型別建立生命線，請以滑鼠右鍵按一下型別，然後按一下 [建立生命線]。 請參閱： UML 順序圖表：參考 UML 順序圖表：方針
相依性圖形	視覺化現有程式碼中的組織和關聯性。 若要識別類別、其關聯性和方法，請建立會顯示這些項目的圖形文件。 請參閱： 根據相依性圖形顯現程式碼相依性 編輯和自訂相依性圖形

描述邏輯架構：圖層圖表

圖層圖表將您方案中的成品組織成抽象群組 (也就是「圖層」(Layer))，來描述系統的邏輯架構。 成品可以是很多項目，例如命名空間、專案、類別、方法等等。 圖層代表和描述成品在系統中執行的角色或工作。 您也可以在組建中加入圖層驗證並簽入作業，以確定程式碼與設計一致。

為讓程式碼與設計一致，Dinner Now 和 Lucerne 使用下列圖層圖表來驗證不斷發展的程式碼：

描述 Dinner Now 與 Lucerne 整合的圖層圖表

這個圖表上的圖層會連結對應的 Dinner Now 和 Lucerne 方案成品。 例如，商務圖層會連結到 DinnerNow.Business 命名空間及其成員，目前已包含 PaymentApprover 類別。 資源存取圖層會連結到 DinnerNow.Data 命名空間。 箭號 (也就是「相依性」(Dependency)) 會指定只有商務圖層可以使用資源存取圖層中的功能。 小組在更新程式碼時，圖層驗證會定期執行，以便在發生衝突時加以攔截並協助小組立即解決衝突。

小組共同合作以逐步進行整合並測試這兩個系統。 它們首先確定 PaymentApprover 與 Dinner Now 其餘部分彼此可順利運作，才會處理 PaymentProcessing。

下列相依性圖形顯示 Dinner Now 和 PaymentApprover 之間的新呼叫：

內含已更新方法呼叫的相依性圖形

在確定系統如預期運作之後，Dinner Now 將 PaymentProcessing 程式碼標示為註解。 圖層驗證報表結果無誤，產生的相依性圖表顯示沒有任何 PaymentProcessing 相依性存在：

未含 PaymentProcessing 的相依性圖表

請參閱：

• 從程式碼建立圖層圖表

• 圖層圖表：參考

• 圖層圖表：方針

• 使用圖層圖表驗證程式碼

繪製圖層圖表

圖層圖表具有下列主要功能：

• 「圖層」(Layer) 在描述成品的邏輯群組。

• 「連結」(Link) 是圖層和成品之間的關聯。

  若要從成品建立圖層，請從方案總管、相依性圖形或架構總管拖曳項目。 若要繪製新圖層再連結到成品，請使用工具箱或以滑鼠右鍵按一下圖表介面以建立圖層，然後將項目拖曳到這些圖層。

  圖層上的數字顯示圖層連結的成品數目。 這些成品可以是命名空間、專案、類別、方法等等。 當您將成品數目解譯到圖層上時，請記得下列事項：

  • 如果圖層連結的成品有包含其他成品，但圖層未直接連結這些其他成品，則數字將只包含連結的成品。 然而，在圖層驗證期間會加入其他成品以進行分析。

    例如，如果圖層連結到單一命名空間，即使命名空間包含類別，連結的成品數目仍為 1。 如果圖層也有命名空間中每個類別的連結，則數字將包含這些已連結的類別。

  • 如果圖層包含已連結到成品的其他圖層，即使此容器圖層上的數字未包含那些成品，容器圖層也會連結到那些成品。

  若要查看連結到圖層的成品，請以滑鼠右鍵按一下圖層，然後按一下 [檢視連結] 開啟 [圖層總管]。

• 「相依性」(Dependency) 表示某個圖層可以使用另一個圖層中的功能，但反過來則不行。 「雙向相依性」(Bidirectional Dependency) 表示某個圖層可以使用另一個圖層中的功能，反過來也可以。

  若要在圖層圖表上顯示現有相依性，請以滑鼠右鍵按一下圖表介面，然後按一下 [產生相依性]。 若要描述預定的相依性，請繪製新的相依性。

請參閱：

• 從程式碼建立圖層圖表

• 圖層圖表：參考

• 圖層圖表：方針

• 使用圖層圖表驗證程式碼

摘要：圖層圖表的優勢

圖層圖表可以協助您：

• 根據成品功能描述系統的邏輯架構。

• 確定開發中的程式碼符合指定的設計。

與其他圖表的關聯性

圖表	描述
相依性圖形	視覺化現有程式碼中的組織和關聯性。 若要建立圖層，請產生相依性圖形，然後在圖形上群組項目做為可能的圖層。 將群組從圖形拖曳到圖層圖表。 請參閱： 根據相依性圖形顯現程式碼相依性 瀏覽和重新排列相依性圖形 編輯和自訂相依性圖形
元件圖表	描述元件、其介面和關聯性。 若要視覺化圖層，請建立會描述系統中不同元件之功能的元件圖表。 請參閱： UML 元件圖表：參考 UML 元件圖表：方針

外部資源

分類	連結
論壇	Visual Studio 視覺化和模型工具 (英文) Visual Studio 視覺化和模型 SDK (DSL 工具) (英文)
網誌	Visual Studio ALM + Team Foundation Server 部落格
技術文章和日誌	架構日誌 - 第 23 期：架構模型和流程
其他網站	MSDN Architecture Center

請參閱

概念

顯現程式碼內容及其關聯性使其更容易理解

開發軟體設計的模型

在開發程序中使用模型

在 Agile 開發中使用模型

在開發期間驗證您的系統

擴充 UML 模型與圖表