實驗目標
這個實驗的目的是展示如何在Visual Studio 2010旗艦版中進行應用程序建模。團隊中的架構師會通過建模確定應用程序是否滿足客戶的需求。 你可以創建不同級別的詳細模型，并將它們彼此結合、測試然后發布到你的開發計劃里。
在這個實驗中, 我們將重點放在如何創建一系列簡單的系統建模圖形上.
每個練習應該在 30分鐘內完成.
繪制活動、類以及其他UML圖形能幫助架構師清晰辨別客戶的習慣、業務規則以及其他需求，從而使設計與客戶需求保持一致。
微軟Visual Studio 2010旗艦版可以讓你繪制關于客戶的活動以及你的系統如何幫助客戶達到他們的預期，這樣有助于你理解用戶需求，并能夠與客戶進行良好的溝通和討論。
需求模型可以幫助你：
l 專注于系統的外部行為，并與系統內部設計分離。
l 使用比自然語言更少的更精準的方法描述客戶以及投資者的需求。
l 定義一個可以由客戶、開發人員以及測試人員一致使用的術語詞匯。
l 減少需求中的差距和分歧。
l 降低針對需求變化的響應所付出的工作量。
l 規劃哪些功能需要開發。
l 使用模型作為系統測試的基礎，使其成為客戶需求與測試人員之間的紐帶。當需求變更時，這種紐帶可以幫助你迅速更新測試。這樣可以使系統盡快滿足新的需求。
如果你將重點放在每次迭代開始時與客戶的討論上，那么需求模型會給你提供很大的便利。而且你不能在完成設計之前編寫詳細代碼。部分應用程序功能，即使它非常簡單，通常也是構成與用戶討論時最敏感的需求基礎。模型可以有效地總結討論結果。
創建用例圖來描述誰使用該系統，以及他們如何使用。用例圖代表一個系統用戶的目標，以及他們執行程序的流程。
這個任務中，客戶需要一個在線餐飲銷售系統。該系統必須允許客戶從菜單中選擇食品，而且必須提供銷售商更新食品品種的菜單。你可以使用以下步驟實現該用例圖：
1. 啟動?Microsoft Visual Studio 2010.
2. 選擇?文件->新建->項目，如下所示：.
?
3. 在新建項目對話框中, 選擇項目類型下的建模項目，然后在右側項目模板中選擇建模項目.
修改項目名稱為ModelingProjectDinnerNow. 保持默認項目路徑.
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.
Figure?45:?添加循環活動
11. 當客戶選擇完所須的菜品后，任務就完結。這里我們從Pay活動到活動結束節點添加連接器。
Figure?46:?訂餐活動終結
12. 至此，訂餐功能的活動圖我們就構建完成。
你可以利用用例圖和活動圖來展示針對相同信息的不同觀點。用例圖可以有效地顯示在大的功能中的嵌套的小的活動，但它不包含活動之間的流程。
例如，同樣是描述訂餐功能，使用用例圖描述如下
Figure?47:?用例圖中的訂餐活動
?
你可以使用順序圖來顯示你的系統與外部活動者之間，或者系統與系統之間的信息交互。順序圖提供了一種用例，它可以非常清晰地展示系統模塊之間的互操作步驟。順序圖在描述多個用例之間的交互時非常有效，而且為你的系統提供一些API。
1. 在解決方案瀏覽器中右鍵單擊ModelingProjectDinnerNow項目根節點，在菜單中選擇添加->添加新項.
2. 在添加新項對話框中選擇UML順序圖模板，并定義名稱為UMLSequenceDiagramDinnerNow.sequencediagram.
Figure 48 新建UML 順序圖界面
3. Dinner Now系統中的功能主要是四個對象之間的交互，他們是客戶、Dinner Now 系統、餐廳、銀行。打開UML模型瀏覽器，可以看到已經包含客戶活動者、Dinner Now子系統以及餐廳活動者，所以可以直接拖拽這三個用例到順序圖設計界面
Figure 49 添加客戶、DinnerNow子系統、餐廳三個生命線
4. 由于我們之前設計的用例中暫時不包含銀行用例，所以我們需要從工具箱中拖拽一個生命線圖標到設計界面，并在空生命線的屬性面板中修改名稱屬性為Bank，修改Type屬性為None。
Figure 50 從工具箱中拖拽生命線圖標到設計界面
Figure?51?修改Bank生命線屬性
5. 根據需求我們知道客戶需要在菜單中不斷的瀏覽，不斷的選擇，系統也是不斷的將客戶選中的菜品添加到訂單中。所以我們首先在Dinner Now System生命線上添加一個異步的調用。首先在工具箱中選中異步圖標，然后在設計界面上選中客戶生命線，保持鼠標按下，拖拽到Dinner Now System生命線上
Figure?52?拖拽異步圖標從Customer生命線到Dinner Now System生命線
Figure?53?建立異步調用后的效果
6. 單擊Message1文本，使其可編輯，將Message1文本修改為?Add Order Item
Figure?54?修改調用的名稱
7. 因為客戶挑選菜品的過程是一個循環往復的過程，所以需要標注循環。右鍵單擊Add Order Item調用，在彈出的菜單中選擇包圍->循環組件片段。
Figure?55?添加循環組件片段菜單
Figure?56?添加循環片段的效果
8. 在循環片段左上角的Loop文本下方單擊空白區域，出現可編輯文本框，定義文本內容為until complete
Figure?57?編輯循環標簽
9. 當客戶選擇完菜品后，需要最終確認并提交訂單。重復步驟5、6，從客戶生命線到Dinner Now?系統生命線建立異步調用，并修改調用名稱為Confirm Order
Figure?58?添加Confirm Order異步調用
10. 客戶確認訂單后，系統會將訂單發送給餐廳等待處理，此時，餐廳需要通過系統反饋給客戶一個訂單發送是否成功的確認。我們需要從工具箱中拖拽一個同步調用。在設計界面中，從Dinner Now系統生命線上生成的矩形圖標，拖拽到右側的餐廳生命線上
Figure?59?在Confirm Order調用與餐廳生命線之間建立同步調用
11. 將指向右側的調用文本Message1，修改為Send Order。將下方指向左側的回調文本return，修改為OK
Figure?60?修改回調方法名稱
12. 系統收到餐廳的確認后，客戶就可以付款了。系統會請求客戶提交付款的詳細信息。付款成功的信息會直接返回給客戶。重復步驟10、11，從客戶生命線?到Dinner Now系統生命線之間建立同步調用，將指向右側的調用名稱修改為Payment detail，將指向左側的消息回調名稱修改為confirmed
Figure?61?添加付款功能調用和確認
13. 客戶提交付款詳細信息后，系統會直接與銀行之間執行付款操作流程。而系統與銀行之間的付款流程完成后，銀行也會返回給Dinner Now 系統一個確認信息。所以重復步驟10、11，從Dinner Now系統上的Payment detail調用矩形圖標，到銀行生命線建立同步調用。將指向右側的調用名稱修改為Process Payment，將指向左側的回發調用名稱修改為OK
Figure?62?添加執行付款調用和確認
14. Dinner Now系統收到銀行的付款確認后，會將確認信息和最終訂單發送給餐廳。而餐廳收到訂單這個調用應該先于系統給客戶的確認。所以我們需要在Dinner Now系統生命線中的Payment detail調用矩形圖標上，在銀行反饋給系統付款確認信息之后，建立一個到餐廳生命線的異步調用。并將異步調用的名字改為Confirm Order
Figure?63?添加確認訂單調用
15. 當Dinner Now系統向客戶返回了訂餐成功的最終確認后，餐廳就可以為客戶送餐了。而送餐的動作不需要經過Dinner Now系統，所以，在Payment detail 調用結束后，直接從餐廳生命線上的Confirm Order調用上，向客戶生命線添加一個返回的異步調用Deliver Food。且confirmed回發，和Deliver Food調用應該是并行的 。
Figure?64?添加送餐調用
總結
創建模型往往可以大幅減少需求分析中與客戶的需求相矛盾或含糊不清的地方。不同的利益相關者往往對系統運行的業務流程有不同的理解。因此你的第一個任務就是解決這些你和客戶之間的分歧。
你會發現 ，
圖形建模可以幫助你了解、澄清你的系統必須實現的客戶需求，并使你的代碼能夠與客戶進行良好的意見溝通。例如，你可以使用統一建模語言（UML）的用例圖、活動圖、類圖以及順序圖來描述用戶需求。你可以使用UML的組件圖、類圖、活動圖、順序圖來描繪系統的功能。
這個案例中我們需要參考在需求分析建模中構建的活動圖UMLActivityDiagramDinnerNow.activitydiagram。但是在軟件設計階段和需求分析階段的活動圖略有不同，例如UMLActivityDiagramDinnerNow.activitydiagram中的Pay活動其實并不經過Dinner Now系統，所以我們需要對需求分析建模中的Pay活動進行修改。將其換成一個行為調用活動，并命名為Confirm Order
Figure?65?修改調用活動
通過需求分析建模中用例圖和活動圖的描述，我們得知，創建訂單時，配貨與付款是并發的兩件事。所以我們需要在軟件設計建模中的活動途中對其加以細化。
1. 在解決方案瀏覽器中右鍵單擊ModelingProjectDinnerNow項目根節點，在菜單中選擇添加->添加新項
2. 在添加新項對話框中選擇UML活動圖模板，并定義名稱為UMLActivityDiagramCreateOrder.activitydiagram.
Figure?66?新建創建訂單活動圖
3. 從工具箱中拖拽活動的起點圖標到設計界面，命名為InitialCreateOrder，然后再拖拽第一個活動到設計界面，命名為Create Order
Figure?67?創建訂單活動圖的起始階段
4. 從工具箱中拖拽一個并行分支節點到設計界面并命名為ForkCreateOrder，以此來表示任何進入這里的處理流程都會被分解為若干個并行的處理進程。然后添加從Create Order活動到并行分支節點的連接器。
Figure?68?添加并行分支節點
5. 在并行分支節點的右側，首先建立配貨活動的進程。從工具箱中拖拽一個活動到設計界面中，放置在并行分支節點的下方偏右側區域，命名為Dispatch goods。建立分支節點指向Dispatch goods活動的連接器。
Figure?69?添加配貨活動
6. 在并行分支節點的左側，建立與配貨進程并行的付款進程。通過需求分析建模中順序圖的描述，我們 了解到，付款行為并不真正由系統完成，而是客戶首先出發系統的付款事件，然后系統會直接將事件請求發送到銀行，并同樣利用事件機制監聽銀行端發回的付款確認。由此我們需要兩個新的活動。一個是用來發送請求的事件活動，一個是用來接收回發的事件活動。因此，從工具箱中首先拖拽一個發送請求活動到設計界面中并行分支活動的左側，命名為Send invoice。并建立從并行分支活動到Send invoice活動的連接器。
Figure?70?添加與配貨活動并行的發送請求活動
7. 在發送請求Send invoice活動的下方，再從工具箱中拖拽一個接收事件活動，命名為Receive payment。建立從Send invoice活動到Receive payment活動的連接器。
Figure?71?添加接收付款確認事件
8. 兩個并行處理進程定義好之后，需要最終匯集到主要處理流程上繼續執行，所以需要從工具箱中拖拽一個并行匯總圖標到設計界面的下方，命名為JoinCreateOrder。分別從Receive payment活動和Dispatch goods活動向并行匯總圖標建立連接器
Figure?72?添加并行匯總節點
9. 最后是關閉訂單，也代表著訂單處理成功。所以需要從工具箱中拖拽一個活動到設計界面的下方，命名為Close Order。在Close Order活動的下方再放置一個活動終結圖標。分別從上到下建立連接線。
Figure?73?完成創建訂單活動圖
到此創建訂單的活動就完成了。保存并關閉當前設計界面。
Task?2?–?數據流圖
你還可以使用數據流圖來描述數據從一個動作流向另一個動作。這個任務中，我們模擬訂單生成過程中數據的流向及其對存儲介質以及活動的影響。在生成訂單過程中，訂單小項和客戶地址分別會有不同的數據流向，也會影響不同的活動，所以我們以訂單中的這兩部分數據作為任務的開始。
1. 在解決方案瀏覽器中右鍵單擊ModelingProjectDinnerNow項目根節點，在菜單中選擇添加->添加新項
2. 在添加新項對話框中選擇UML活動圖模板，并定義名稱為UMLActivityDiagramOrderDataflows.activitydiagram.
3. 從工具箱中拖拽兩個活動參數圖標到設計界面，水平并排放置，通過單擊圖標上的文本，使其可編輯。分別命名為Item list和Customer Address。
4. 訂單生成的過程首先會按照當前訂單中的商品列表，在商品庫存中找到相應的商品。所以需要從工具箱中拖拽一個活動到設計界面中，Item list的下方。命名為Find goods in warehouse。
Figure?74?添加查找庫存貨物活動
5. 由于Item list是以參數的形式進入Find goods in warehouse活動的。所以我們需要給Find goods in warehouse活動定義輸入接口。右鍵單擊Find goods in warehouse活動，在右鍵菜單中選擇添加->Input pin。通過單擊接口上的文本Input1，使其可編輯，并將文本定義為Item list。然后從Item list參數圖標，到新建的輸入接口添加連接器。
Figure?75?添加輸入參數接口的右鍵菜單
Figure?76?為Find goods in warehouse活動添加輸入參數Item list
6. 客戶的地址需要生成為派送貨物時的地址標簽。所以Customer Address應該是Print address label活動的輸入參數。所以，重復步驟4、5。添加Print address label活動，并為其添加輸入參數接口Customer Address。
Figure?77?添加Print address label活動，并定義它的Customer Address輸入參數
7. 當系統在物品庫存中找到了客戶選擇的物品后，會完成兩個工作。一是把每個購買物品的數量從庫存數量中減去。二是生成訂單號，以便唯一記錄或查閱訂單。要完成第一個任務，我們需要定義一個對象，來保存需要修改的物品數量記錄。所以，從工具箱中拖拽一個對象節點圖標到設計界面中Find goods in warehouse活動的下方，單擊文本Object1將其內容修改為Stock Update Record。由于不存在參數的關系，所以只需直接從Find goods in warehouse活動到Stock Update Record對象建立連接器。
Figure?78?添加Stock Update Record對象
8. 系統會使用專門的活動來將Stock Update Record對象中保留的數據，更新到實際的數據庫中。從工具箱中拖拽一個活動到設計界面，放置在Stock Update Record對象的下方，并將其命名為Update stock database。并建立從Stock Update Record對象到Update stock database活動的連接器。（這里不使用參數的原因是由于Stock Update Record是對象，可以擁有并調用自己專屬的方法，而不是將自己作為參數傳遞給別人的活動）
Figure?79?添加Update stock database活動
9. 步驟7中提到的第二件事就是生成訂單號，而訂單號會與打印的地址標簽一同成為配送物品的重要依據。所以從工具箱中拖拽一個 新的活動，放置在Find goods in warehouse活動和Print address label活動的下方。將其命名為pack goods。
Figure?80?添加Pack goods活動
10. Pack goods活動需要的兩個輸入參數：訂單號和地址標簽，分別來自于Find goods in warehouse活動和Print address label活動。所以可以參照步驟4、5分別為Find goods in warehouse活動和Print address label活動添加輸出參數接口，分別命名為Order Id和Address label。與之對應的，要在Pack goods活動上建立兩個輸入參數接口用來接收Order Id和Address label。最后，分別從Order Id輸出參數接口和Address label接口，到Pack goods活動上各自給定的輸入參數接口，建立連接器。
Figure?81?為Pack goods活動提供參數來源
11. 當Pack goods活動完成后，就可以發貨給客戶。此時在Pack goods活動下方簡單添加一個活動，命名為Ship goods to customer。
Figure?82?添加送貨活動
12. 到此，關于生成訂單與送貨的數據流程圖就完成了，保存并關閉當前設計界面。
Task?3?–?組件圖
在Visual Studio 旗艦版中，組件圖展示的是軟件系統設計的組成部分。組件圖可以幫助你可視化的定義高層次的系統結構以及服務行為的接口與調用。這個任務中我們模擬客戶使用Web瀏覽器與我們的Dinner Now系統完成訂餐過程的組件間關系。
1. 在解決方案瀏覽器中右鍵單擊ModelingProjectDinnerNow項目根節點，在菜單中選擇添加->添加新項
2. 在添加新項對話框中選擇UML組件圖模板，并定義名稱為UMLComponentDiagramDinnerNow.componentdiagram.點擊添加，進入組件圖設計界面。
Figure?83?新建組件圖
3. 從工具箱中拖拽一個組件圖標到設計界面，單擊文本Component1，將其修改為Web Browser。單擊Web Browser組件左上角的收放箭頭，將其收縮。
Figure?84?添加Web Browser組件
4. 從工具箱中拖拽另一個組件圖標到設計界面，單擊Component1文本，將其修改為DinnerNow Web Service。調整其大小如下圖所示
Figure?85?添加Web Browser組件
5. 在 DinnerNow Web Service組件中應該提供了餐廳所擁有的功能，如招待客戶訂餐的服務和進行餐飲烹飪的服務。所以，模仿步驟3，在DinnerNow Web Service組件中放置兩個小的組件，分別命名為Customer Web Server和Kitchen Server。在屬性選項卡中，修改名稱屬性為相應的名稱。
Figure?86?在DinnerNow Web Server組件中添加Customer Web Server?組件和Kitchen Server?組件，并重命名
6. 客戶通過瀏覽器請求訪問到DinnerNow Web Service組件中的Customer Web Server組件，進行餐飲相關的檢索和訂餐。所以右鍵單擊Web Browser組件，選擇添加->請求接口。
Figure?87?添加請求接口菜單項
7. 由于瀏覽器請求DinnerNow Web Service使用HTTP協議，單擊請求接口的文本Interface1，修改為HTTP，并在屬性選項卡中將HTTP請求接口名稱Port1修改為HTTP。
Figure?88?添加HTTP請求接口
8. Web Browser組件的請求要想進入DinnerNow Web Service組件，后者必須提供一個提供程序接口用來響應。所以右鍵單擊DinnerNow Web Service組件，選擇添加->提供程序接口。
Figure?89?為DinnerNow WebService添加提供程序接口
9. 單擊提供程序接口上的文本Interface2，將其修改為Customer Web Site。在屬性選項卡中，將名稱Port1修改為Customer Web Site
Figure?90?定義DinnerNow WebService提供程序接口的名稱
10.?右鍵單擊Web Browser組件的HTTP請求接口，選擇添加->依賴。
Figure?91?添加依賴關系的右鍵菜單
11. 將依賴關系的另一頭拖放到DinnerNow Web Service組件的Customer Web Site提供程序接口，并單擊。
Figure?92?拖放依賴關系
Figure?93?建立依賴關系后的效果
12. 客戶的訂餐請求經過Customer Web Site接收后，進入DinnerNow Web Service執行，但是要想讓內部的組件獲得外部的請求，同樣需要在內部組件上建立提供程序接口用來接收進入DinnerNow Web Service的請求。參考步驟10，為Customer Web Server組件添加一個名稱為Sales的提供程序接口。
Figure?94?建立Sales接口
13. 在組件內部的各個部分之間，存在著消息或事件的傳遞，就是委托。所以，在消息內部的接口之間使用委托關系來表示消息的流向和事件的響應。參考步驟11，在Customer Web Site接口與Sales接口之間建立委托關系.
Figure?95?建立從Customer Web Site接口到Sales接口的委托關系
14. 進入Customer Web Server組件的訂餐請求，經過處理之后，會執行兩件事。一是向銀行發送付款驗證，二是將客戶的菜單發送到廚房進行加工。由于銀行屬于DinnerNow Web Service組件的外部，且DinnerNow Web Service只需向銀行發送付款驗證請求即可。所以，參考步驟6、7，為Customer Web Server組件添加PaymentAuthorization請求接口
Figure?96?為Customer Web Server組件添加PaymentAuthorization請求接口
15. DinnerNow Web Service組件內部的部件要想將消息發送到組件外部的其他系統中，也需要一個向外的請求接口。所以參考步驟8、9，在DinnerNow Web Service組件左側?邊框上添加一個PaymentAuthorization請求接口，用來將Customer Web Server組件的PaymentAuthorization接口發送的消息傳遞到DinnerNow Web Service組件外部
Figure?97?為DinnerNow Web Service組件添加PaymentAuthorization請求接口
16. 參考步驟13，從Customer Web Server組件的PaymentAuthorization請求接口到DinnerNow Web Service組件的PaymentAuthorization請求接口建立委托關系。這樣就完成了Customer Web Server向外部銀行的消息傳遞。
Figure?98?從內部PaymentAuthorization接口到外部PaymentAuthorization接口建立委托關系
17. Customer Web Server組件的另一個功能是將客戶的菜單送到廚房進行加工。所以，參考步驟14，為Customer Web Server組件建立另一個請求接口，名稱為MealOrdering。
Figure?99?為Customer Web Server組件添加MealOrdering接口
18. 參考步驟12，為Kitchen Server組件添加一個提供程序接口，命名為MealOrdering。
Figure?100?為Kitchen Server組件添加MealOrdering接口
19. 由于Customer Web Server和Kitchen Server 兩個組件同處在DinnerNow Web Service組件內部，所以 不需要消息的傳遞和事件機制，而應該建立直接的調用關系。右鍵單擊Customer Web Server組件的MealOrdering請求接口，選擇添加->部件引用。然后將鼠標拖放到Kitchen Server組件的MealOrdering提供程序接口上，建立 直接的程序集調用關系。
Figure?101?從?Customer Web Server組件的?請求接口?到?Kitchen Server組件的?MealOrdering提供程序接口建立部件程序集引用關系
20. Kitchen Server組件將接受來自廚房提交的菜品制作順序，而Kitchen Server會按照制作順序進行制作。真實的廚房應該屬于DinnerNow Web Service組件外部的元素。所以，參考步驟8、9，在DinnerNow Web Service組件的右邊界，添加一個提供程序接口，命名為Kitchen Web Site。再參照步驟18，在Kitchen Server組件上添加一個提供程序接口，命名為KitchenWorkQueue。并參考步驟13，從前者到后者建立委托關系。
Figure?102?建立Kitchen Web Site提供程序接口和KitchenWorkQueue提供程序接口，并建立二者之間的委托關系
21. 至此，我們完成了客戶訂餐到廚房加工幾個環節的組件圖，保存并關閉設計界面
Task?4?–?類圖
軟件設計建模中的UML類圖描述了你的應用程序中使用的對象和消息結構。這些對象和消息，既包括系統內部的調用，又包含系統與用戶的交互信息。它所描述的信息沒有任何實現。它的類和關系可以使用多種方式實現，如數據庫表、XML節點、或者軟件對象組件。這個案例中，我們需要對用戶需求建模中的概念類圖進行一定的修改
1. 在解決方案瀏覽器中的ModelingProjectDinnerNow解決方案下，雙擊類圖UMLClassDiagramDinnerNow.classdiagram，在設計界面中打開類圖。
2. 由于菜單與菜單項之間是所有權的關系，而訂單與訂單項是整體與部分的關系，所以這里要修改Menu與MenuItem之間的關系為所有權關系。單擊選中Menu類與MenuItem類之間的關系，并保持選中狀態。打開屬性選項卡，依次展開Navigation->First Role組。在First Role組中，找到Aggregation屬性，并在下拉列表選項中將值Composite，修改為Shared，此時效果如下圖所示，Menu與MenuItem類之間的關系變成了空心菱形的所有權關系
Figure?103?修改Menu類與MenuItem類之間的關系為所有權關系
3. 通常訂單總是需要一個訂單總價，所以我們為Order類添加一個保存總價的屬性。單擊Order類左上角的擴展箭頭，展開Order類。
Figure?104?展開Order類
4. 右鍵單擊Order類的Attributes組，在彈出的菜單中選擇添加->屬性
Figure?105?添加屬性右鍵菜單
5. 此時，在Order類的屬性組內出現一個可編輯的屬性，文本為+Attribute1。保持可編緝狀態，將文本+Attribute1修改為+TotalPrice。然后按下回車，確認修改。
Figure?106?修改TotalPrice屬性名
6. 再次單擊選中TotalPrice屬性，在屬性窗口中的常用屬性組中找到類型屬性。在下拉列表中輸入Money。表示這個總價屬性是貨幣類型。
Figure?107?修改TotalPrice屬性的數據類型
7. 在Order類中，常用的對訂單的操作，這里舉兩個例子。一個是添加訂單項，一個是刪除訂單項。右鍵單擊Order類的操作組，在右鍵菜單中選擇添加->操作
Figure?108?為Order類添加方法菜單
8. 此時，在操作組內會出現一個可編輯的操作，文本為+ Operation1()，將其修改為+ AddItem()。按下回車，確認修改。
Figure?109?為Order類添加AddItem方法
9. Order類中的添加訂單項方法，如果要執行，必須接受一個訂單項，作為待插入的資源。單擊AddItem操作，在屬性選項卡中找到參數列表屬性，單擊屬性值文本框中的省略號按鈕，打開
Figure?110?打開參數列表屬性的省略號按鈕
Figure?111?操作參數集合編輯器
10. 如上圖所示，點擊左下角的添加按鈕。在成員列表中選中自動添加的Parameter1參數，在右側屬性列表中，找到Name屬性，將其修改為MenuItem，在Type屬性的下拉列表中，選擇ModelingProjectDinnerNow::MenuItem。單擊確定完成參數的定義
Figure?112?為AddItem方法添加MenuItem參數
11. 參照步驟9、10，為Order類添加DeleteItem方法，并添加MenuItem參數。
Figure?113?添加DeleteItem方法
12. 通常餐廳除了支持網上下單外，更靈活的方式是電話訂餐。此時生成的訂單是電話訂單。而電話訂單中包含了普通訂單的所有數據，但是卻擁有一個特殊的屬性，就是訂單反饋的電話。在設計界面的右下角空白處，單擊右鍵，選擇添加->類
Figure?114?添加新類
13. 單擊Class1類名部分，使其可編輯。將文本Class1修改為PhoneOrder。
Figure?115?修改PhoneOrder類名
14. 參照步驟4、5、6，為PhoneOrder類添加一個字符串類型屬性：CallbackNumber
Figure?116?為PhoneOrder類添加CallbackNumber屬性
15.?右鍵單擊PhoneOrder類，在菜單中選擇添加->繼承。
Figure?117?添加繼承菜單
16. 將鼠標移動到Order類上，直到出現連接標識。點擊Order類，確認建立繼承關系
Figure?118?建立PhoneOrder類到Order類的繼承關系
Figure?119?建立PhoneOrder類到Order類的繼承關系完成
17. 至此，更詳細的類圖的設計就完成了。保存并關閉當前設計界面
概述
當你需要修改現有軟件系統時，Visual Studio旗艦版可以幫助你以可視化的方式理解組織結構、關系以及代碼中的行為。在你修改代碼之前，使用Visual Studio 旗艦版來瀏覽這些更改如何影響代碼，從而幫助你評估風險和工作量。
?
Task 1 –?從現有代碼生成圖形化文檔——查看Visual Studio解決方案中的源代碼概要
1. 打開需要查看的Visual Studio 解決方案，這里我們使用PetShop.
2. 在Visual Studio 2010的頂部菜單中選擇架構菜單。在架構菜單中選擇生成依賴圖形。接下來可選擇以下選項之一執行
| 生成依賴圖形 | 圖形顯示的內容 |
| 按照程序集引用 | 解決方案中的所有程序集間，以及內部程序集與外部依賴項之間的聚集依賴關系。 為了查看命名空間、類和內部方法，以圖形化的方式展開引用。外部組件，只顯示在項目中使用到的。 |
| 按照命名空間 | 解決方案中的所有命名空間之間，以及內部命名空間與外部依賴的命名空間之間的聚集依賴關系。 為了查看命名空間里的類和方法，以圖形化的方式展開命名空間。外部命名空間，只顯示在項目中使用到的。 |
| 按照類 | 解決方案中的所有類之間的聚集依賴關系。不會出現用到的外部類的信息。 |
Figure?120?生成依賴圖形的菜單項
Figure?121?按程序集引用瀏覽的架構圖
Figure?122?按命名空間瀏覽的架構圖
Figure?123?按類結構瀏覽的架構圖
Task 2 –從現有代碼生成圖形化文檔——查看Visual Studio 解決方案中的源代碼的特定依賴
利用架構資源管理可視化的查看你需要的代碼和關系。
1. 打開需要查看的Visual Studio 解決方案，這里我們使用PetShop.
2. 如果架構瀏覽器沒有打開，在架構菜單中，點擊Windows->架構瀏覽器
Figure?124?從菜單打開架構瀏覽器
3. 在架構瀏覽器的第一列中的Visual Studio節點下選擇如下兩項：
l 類視圖：用來查看代碼的邏輯結構。以命名空間、類、方法等形式瀏覽。
Figure?125?類視圖效果
l 解決方案視圖：用來查看代碼的物理結構。以項目、源文件等形式瀏覽。
Figure?126?解決方案視圖效果
4. 選中類視圖/解決方案視圖，右側會出現命名空間/項目列表。在列表選擇你想查看的命名空間/項目。全選使用Ctrl+A。多選時，按住Ctrl。在第二列選擇要查看的對象同時，第三列會彈出類/文件列表
5. 重復步驟4，選中你想要查看的對象。這里我們在命名空間/項目列表中選中：BLL。并使用Ctrl+A全選類型和成員列表中的所有項。
Figure?127?創建新的圖形文檔的按鈕
6. 需要為你選中的對象建立新的關系圖，請在架構瀏覽器的左上角標題欄下方，單擊為你選擇的節點創建一個新的圖形文檔按鈕。此時Visual Studio 就會創建一個向導圖形文檔（.dgml）,并打開它。
Figure?128?生成的向導圖形文檔
7. 到此，我們就成功將現有代碼展示成了可視化文檔。保存并關閉當前設計界面。
?
原文地址：http://www.cnblogs.com/Phoenix-Rock/archive/2010/08/11/VS2010-Model.html
 XORerr1 -修改)
)
)
![[Spring]01_環境配置](http://pic.xiahunao.cn/[Spring]01_環境配置)
