使用Visual Studio 2010 Team System中的架構師工具（設計與建模）
Lab 1: 應用程式建模
實驗目標
這個實驗的目的是展示如何在Visual Studio 2010旗艦版中進行應用程式建模。團隊中的架構師會通過建模確定應用程式是否滿足客戶的需求。 你可以建立不同級別的詳細模型，並將它們彼此結合、測試然後釋出到你的開發計劃裡。
在這個實驗中, 我們將重點放在如何建立一系列簡單的系統建模圖形上.
每個練習應該在 30分鐘內完成.
繪製活動、類以及其他UML圖形能幫助架構師清晰辨別客戶的習慣、業務規則以及其他需求，從而使設計與客戶需求保持一致。
微軟Visual Studio 2010旗艦版可以讓你繪製關於客戶的活動以及你的系統如何幫助客戶達到他們的預期，這樣有助於你理解使用者需求，並能夠與客戶進行良好的溝通和討論。
需求模型可以幫助你：
l 專注於系統的外部行為，並與系統內部設計分離。
l 使用比自然語言更少的更精準的方法描述客戶以及投資者的需求。
l 定義一個可以由客戶、開發人員以及測試人員一致使用的術語詞彙。
l 減少需求中的差距和分歧。
l 降低針對需求變化的響應所付出的工作量。
l 規劃哪些功能需要開發。
l 使用模型作為系統測試的基礎，使其成為客戶需求與測試人員之間的紐帶。當需求變更時，這種紐帶可以幫助你迅速更新測試。這樣可以使系統儘快滿足新的需求。
如果你將重點放在每次迭代開始時與客戶的討論上，那麼需求模型會給你提供很大的便利。而且你不能在完成設計之前編寫詳細程式碼。部分應用程式功能，即使它非常簡單，通常也是構成與使用者討論時最敏感的需求基礎。模型可以有效地總結討論結果。
Task 1 –使用者需求建模——用例圖
建立用例圖來描述誰使用該系統，以及他們如何使用。用例圖代表一個系統使用者的目標，以及他們執行程式的流程。
這個任務中，客戶需要一個線上餐飲銷售系統。該系統必須允許客戶從選單中選擇食品，而且必須提供銷售商更新食品品種的選單。你可以使用以下步驟實現該用例圖：
1. 啟動 Microsoft Visual Studio 2010.
2. 選擇 檔案->新建->專案，如下所示：.
Figure 1: 開啟新建專案對話方塊
3. 在新建專案對話方塊中, 選擇專案型別下的建模專案，然後在右側專案模板中選擇建模專案.
修改專案名稱為ModelingProjectDinnerNow. 保持預設專案路徑.
Figure 2: 建立新建模專案
4. 單擊確定，應用你的選擇，開啟一個空的建模專案.
5. 在解決方案瀏覽器中右鍵單擊ModelingProjectDinnerNow專案根節點，在彈出選單中選擇新增->新增新項
Figure 4: 新增新項選單
6. 在彈出的新增新項對話方塊中，選擇UML用例圖模板，並修改用例圖的名稱為UMLUseCaseDiagramDinnerNow.usecasediagram
Figure 5: 新增新項對話方塊
7. 單擊新增，此時會開啟空白用例圖
Figure 6: 空白用例圖UMLUseCaseDiagramDinnerNow.usecasediagram
8. 根據案例使用者需求，從左側工具箱中的UML用例圖節點下拖拽兩個用例圖示到右側設計介面。
Figure 7: 從工具箱中拖拽兩個用例圖示
9. 點選用例圖示的”UseCase1”文字部分，使其變為可編輯狀態，然後將其內容修改為Order a Meal
10. 重複步驟9的操作，將用例2的用例內容修改為Update Menu。
Figure 8: 用例定義修改後的效果
11. 根據案例使用者需求，從左側工具箱中的UML用例圖節點下拖拽兩個活動者圖示到右側用例圖設計介面
Figure 9: 從工具箱中新增活動者
12. 點選用活動者圖示的”Actor1”文字部分，使其變為可編輯狀態，然後將其內容修改為Customer
13. 重複步驟12的操作，將活動者2的定義修改為Restaurant
Figure 10: 定義活動者後的效果
14. 在工具箱中選中Association圖示，然後在設計介面中首先點選Customer圖示，並保持滑鼠按下，拖拽到Order a Meal用例上。
Figure 11: 選擇Association圖示後的效果
Figure 12: 拖拽過程中的效果
Figure 13: 拖拽完成的效果
15. 按照步驟14的方法，為Restaurant活動者與Update Menu用例建立聯絡
Figure 14: 用例圖初步完成效果
16. 還可以生成更精確的用例圖。例如，訂餐只是購買活動的一個步驟。整個購買活動應該還包含付款和交貨等。
17. 在工具箱中選擇子系統圖示，並將其拖拽到設計介面中，放置於前一步驟中完成的用例圖的下方
Figure 15: 新增子系統圖示
18. 點選子系統圖示中左上角的“SubSystem1”文字，使其可以編輯。將“SubSystem1”文字修改為“Dinner Now System”
Figure 16: 修改子系統名稱
19. 選中上面我們定義的兩個用例：Order a Meal、Update Menu。將其拖拽到子系統圖示內，並調整相互位置。
Figure 17: 將用例拖拽到子系統內
Figure 18: 目前為止完成的更精確的用例圖
20. 從工具箱中拖拽兩次用例圖示到子系統圖示內，分別定義為Buy a Meal、Pay for Meal
Figure 19: 新增子系統內部用例後的效果
21. 由於訂餐和付款共同屬於購買行為的組成部分，所以Order a Meal、Pay for Meal都包含在Buy a Meal中。需要在工具箱中選中包含圖示，分別在Buy a Meal 與 Order a Meal ；Buy a Meal 與Pay for Meal之間建立包含關係。
Figure 20: 建立Buy a Meal包含關係後的效果
22. 由於Buy a Meal 作為客戶使用的總用例，所以這裡刪除Customer活動者與Order a Meal用例的聯絡，建立Customer活動者與Buy a Meal用例的聯絡。調整用例之間的位置。
Figure 21: 修改Customer活動者關係後的效果
23. 由於送餐並不屬於Dinner Now System的功能，可能會有專門的物流或快遞系統負責，這裡，將送餐定義在Dinner Now System系統的外部。在Dinner Now System子系統圖示外部新增一個新的用例，定義為Deliver Meal。並指定它與Restaurant活動者之間的聯絡。
Figure 22: 新增送餐用例後的效果
24. 送餐用例雖不屬於Dinner Now System系統的功能，但是也是購買行為的組成部分，這裡需要建立Buy a Meal用例與Deliver Meal用例之間的包含關係
Figure 23: 最終用例圖完成的效果
25. 到此用例圖設計完成，儲存並關閉當前設計介面。
你還可以定義哪些用例包含在你係統的開發範圍之內。例如，我們案例中的Deliver Meal用例就不需要開發。這就幫助開發人員界定了他們的工作內容。一般用例圖中的子系統圖示用來代表系統或組成部份。
用例圖還可以幫助你的團隊討論功能釋出的連續性。如，你可以決定是否在最初的版本中包括付費功能，或者可以不包含。如果系統中不包含付費功能，那麼也可以由客戶在餐廳直接支付，而不經過系統。這樣，你就可能不在你的系統最初版本中包含付費功能。
用例圖只是一個總體的描述，而要想得到更詳細的用例描述，你可以將你的用例圖中的每個用例都導航到一個用例文件中。用詳細的用例文件來描述用例。
你可以使用UML 類圖來開發用於下列用途的概念模型：
l 客戶可以自己參與到系統的開發過程中
l 描述使用者的需求，例如，在描述用例、業務規則以及使用者使用習慣方面。
l 系統中的API或使用者介面的資訊型別變更
l 描述系統或驗收測試
出於這樣的目的，UML類圖的概念就被定義為概念類圖。
在一個概念類圖中，你只需要展示必要的需求描述，而不需要展示系統內部的設計。概念模型中不應該出現操作或介面。
你可以使用如下步驟定義概念模型：
1. 在解決方案瀏覽器中右鍵單擊ModelingProjectDinnerNow專案根節點，在選單中選擇新增->新增新項
Figure 24: 新增新項對話方塊中選擇UML類圖
2. 在新增新項對話方塊中選擇UML類圖模板，並定義名稱為UMLClassDiagramDinnerNow.classdiagram. 效果如上圖所示。
3. 點選新增按鈕，開啟空白UML類圖設計介面.
Figure 25: 空白UML類圖設計介面
4. 在Task 1中我們設計到了兩個物件：訂單、選單。根據經驗我們知道，訂單和選單分別都要有各自的小項，即訂單小項、選單小項。所以我們首先從工具箱中拖拽四個類圖示到設計介面，分別定義為Menu、MenuItem、Order、OrderItem。
Figure 26: 建立四個物件
5. 由於選單和選單小項、訂單與訂單小項是1對多的包含關係，所以我們需要在Menu與MenuItem、Order與OrderItem之間建立“構成”關係.從工具箱中選中Composition圖示，然後點選Menu物件。保持滑鼠按下狀態，拖拽到MenuItem物件上，生成Menu與MenuItem物件之間“構成”關係
Figure 27: 拖拽關係
Figure 28: 建立Menu與MenuItem的構成關係
6. 由於Menu與MenuItem是1對多的包含關係，所以，選中設計介面中在上一步驟生成的Composition圖示，點選右側下方的1文字，使其可以編輯。將其更改為*。選中左側下方的MenuItem文字，將其修改為Contents
Figure 29: Menu物件與MenuItem物件之間的Composition關係
7. 重複5、6步驟，設定Order物件與OrderItem物件之間的Composition關係
Figure 30: Order物件與OrderItem物件之間的Composition關係
8. Menu物件與Order物件之間存在1對多的聯絡，同樣，MenuItem與OrderItem之間也存在著1對多的聯絡。所以，重複5、6步，在Menu與Order之間和MenuItem與OrderItem之間分別建立Association關係
Figure 31: 建立Association關係
9. 由於MenuItem和OrderItem在資料上有一個明顯的不同就是，OrderItem必須包含數量，而MenuItem不需要包含。所以我們要在OrderItem中定義一個數量屬性。在OrderItem物件中的屬性一欄上點選右鍵，在彈出的選單中選擇新增->屬性
Figure 32: 為OrderItem物件新增屬性
10. 此時OrderItem物件中出現可編輯的屬性，其文字為Attribute1。將Attribute1文字修改為quantity，然後右鍵選擇quantity屬性，在屬性選項卡中修改屬性的資料型別為Integer
Figure 33: 定義quantity屬性
11. 至此 ，我們完成了概念模型的設計。儲存並關閉當前概念類模型設計介面
Figure 34: 初步完成概念模型設計
概念模型提供了一系列你在整個需求建模階段需要使用的詞彙和條件。例如，在Order a Meal用例的詳細描述中，可以這樣寫：
客戶可以選擇選單來生成訂單。通過在選單中選擇一個選單項，系統在訂單中生成訂單項。
注意，上面描述中使用的詞彙就是我們在模型中使用的類名。現在刪除概念模型中類與類之間的不準確的關係。例如，圖中明確顯示了每個訂單隻關聯一個選單。
對客戶需求的誤解可以追溯到對詞彙詳細解釋的誤解。例如，大多數餐館都有約定俗成的選單和訂單，但是訂單項與選單項的不同卻區分並不明顯。當與客戶討論需求時，暴露這些分歧是很重要的。類圖是一個很有用的工具，它可以幫助你明確物件以及物件之間的關係。
業務規則是一個不與特定用例相關的需求，應該是從整個系統層面考慮。
許多業務規則是對概念模型中類之間關係的約束。你可以為概念類圖中的相關類，定義一些通用靜態業務規則。例如：
在概念模型中右鍵單擊Order物件，在選單中選擇新增->添加註釋新增如下約束：“在任何訂單中，所有的訂單項只能來自於同一個選中的選單”
Figure 35: 對概念模型新增約束註釋
動態業務規則限制的是事件發生的順序。例如，你可以使用一個順序或活動圖來展示：一個使用者必須登入才能執行你的系統上的操作。
因此，許多動態規則能夠取代動態規則更有效更通用的執行約束。例如，你也許能新增一個布林型別的屬性“Logged In”到概念類模型中。你還會將登入成功作為登入用例的後置條件，還可以將登入成功作為其它用例的前置條件。這種方法可以讓你定義一系列事件的組成順序。當你需要新增新的用例到用例模型時，動態約束更加靈活。
你可以使用活動圖來顯示不同用例之間的工作流程。在需求建模的開始階段繪製活動圖是非常有用的。它可以展示使用者執行的主要任務——包含系統內外的互動。
這裡以訂餐為例：客戶訂餐時首先需要選擇一個選單，然後在選單中選擇某樣菜品。客戶可以在某個選單內部重複多次的選擇相同或不同的菜品。當菜品選擇完畢後，客戶可以將選中的菜品一併結賬付款。
1. 在解決方案瀏覽器中右鍵單擊ModelingProjectDinnerNow專案根節點，在選單中選擇新增->新增新項.
2. 在新增新項對話方塊中選擇UML活動圖模板，並定義名稱為UMLActivityDiagramDinnerNow.activitydiagram. 效果如上圖示.
Figure 36: 新增新項->UML活動圖
3. 此時會開啟活動圖設計介面。點選設計介面的空白處，在屬性選項卡中修改活動圖的名稱屬性為Order Meal.此時活動圖左上角的標籤應該變為act Order Meal
Figure 37: 修改活動圖的名稱屬性
4. 任何活動都從一個初始化節點開始的，所以從工具箱中的UML 活動圖節點下選擇初始節點圖示，並拖拽到設計介面中.
Figure 38: 拖拽初始節點圖示
5. 根據案例的描述，訂餐活動中應該有選擇選單、選擇菜品、付款三項主要活動。這裡從工具箱中拖拽三個活動圖示到設計介面，分別定義活動內容為“Choose Menu”、“Select Menu Item”、“Pay”.
Figure 39: 定義活動
6. 活動圖定義的結尾，應該是活動的結束節點。從工具箱中拖拽活動結束節點到設計介面
Figure 40: 定義活動結束
7. 在工具箱中選中聯結器圖示，在設計介面點選初始圖示並保持滑鼠按下，拖拽到右側Choose Menu活動圖示上。
Figure 41: 拖拽活動之間的聯結器
Figure 42: 定義第一個聯結器後的效果
8. 根據任務中需求的描述，客戶選擇選單後，可以再瀏覽選擇菜品，即選單項。而且客戶可以反覆瀏覽選單和菜品。這樣在選擇菜品和選擇選單兩個活動之間就形成了迴圈的關係。所以我們需要在Choose Menu活動的下方放置一個合併節點，然後在Select Menu Item活動的下方放置一個分支節點
Figure 43: 新增合併節點和分支節點
9. 從Choose Menu活動開始，以此向下新增聯結器，直到Pay活動
Figure 44: 新增正常流程聯結器
10. 為了說明客戶可以在選單中反覆選擇菜品，我們需要從分支節點到合併節點新增一個聯結器，用來表示迴圈，並對迴圈活動添加註釋。在分支節點的指向下方活動的聯結器的Guard屬性中新增如下提示：Customer has finished choosing.在返回上方的聯結器的Guard屬性中新增如下提示：Customer wants to choose more.
