用UML呈現系統分析到設計的變化（下）

利用UML技術，可以繪製出衝刺期間的每一項待辦項目的使用案例圖，將產品待辦任務清單視覺化。另外也使用類別圖表達系統關係，以利後續用循序圖來表達子系統之間的互動狀況。

上一回文章中，我們已經示範了「查詢基金公司基本資料」待辦項目在設計階段和分析階段的差異，這一回，我們繼續來看更多的例子。

任務：編寫程式碼（新增）
接下來，我們繼續來比較新增基金公司基本資料的循序圖，圖1是分析階段的循序圖，而圖2則是設計階段的循序圖。此外，還是列出了兩者的訊息對應表，如表1所示。

圖1 新增基金公司基本資料[分析階段的循序圖]

圖2 新增基金公司基本資料[設計階段的循序圖]

表1 訊息的對應

相較於分析階段和設計階段的循序圖，主要的變動之處在於：增刪改查基金公司UCO不再需要新增基金公司實體物件，而是由前端的增刪改查基金公司UI直接產生一個基金公司實體物件，一旦確定資料庫中沒有這筆基金公司的資料，就直接呼叫基金公司DAO新增。

因此，原先分析階段的循序圖中，4號訊息和6號訊息可以刪去，如圖3所示。此處，我們同步回頭過去修改分析階段的循序圖，如圖4所示。

圖3 新增基金公司基本資料[變更]

圖4 新增基金公司基本資料[修改過的分析圖]


任務：編寫程式碼（刪除）
接著，我們繼續看到刪除基金公司基本資料的循序圖，分析階段與設計階段的圖，分別如圖5和圖6所示。至於，對應的訊息，記錄在表2中。

圖5 刪除基金公司基本資料[分析階段的循序圖]

圖6 刪除基金公司基本資料[設計階段的循序圖]

表2 訊息的對應

任務：編寫程式碼（修改）
最後，請你看到修改基金公司基本資料的循序圖，分析階段與設計階段的圖，分別如圖7和圖8所示。還有，對應的訊息，則放置在表3中。

圖7 修改基金公司基本資料[分析階段的循序圖]

圖8 修改基金公司基本資料[設計階段的循序圖]

表3 訊息的對應

在修改基金公司基本資料的部份，比較大的變動在於：增刪改查基金公司UCO並不需要修改已經存在的基金公司實體物件，而是直接由前端的增刪改查基金公司UI傳來更新的基金公司實體物件，然後請基金公司DAO進行更新。

因此，原先分析階段的循序圖中，3號訊息可以刪去，如圖9所示。此處，我們同步回頭過去修改分析階段的循序圖，如圖10所示。

圖9 修改基金公司基本資料[變更]

圖10 修改基金公司基本資料[修改過的分析圖]


編寫單元測試不是這一回文章的重點，所以我們就省略，不加以描述了。程式設計師：麥克（Michael）在寫完程式之後，自行測試程式，認為一切功能皆符合設計。同時，麥克（Michael）還認為目前程式還很簡單，並沒有需要重構程式的地方，所以此項任務實際上並沒有花費任何工時。

至於，展示準備（含測試）的部份，同樣也非這系列文章的重點，所以此處我們僅示範性地列出簡單的測試案例（test case）和基本資料畫面，如表4所示。

表4 測試案例

圖11 增刪改查基金公司基本資料畫面


示範了基金公司基本資料的「查詢」、「新增」、「修改」等待辦項目，其實不同任務的循序圖也有類似之處，例如要繪製更新基金基本資料的循序圖時，其實一開始可以模仿前面的循序圖，如圖12所示。當然，還需要進步針對不一樣的地方再修改。

圖12 模仿


同樣情況，「查詢基金基本資料」的使用案例擁有雙介面，我們要針對這兩個不同的介面，繪製出兩張循序圖時，同樣可以參考先前查詢基金公司的循序圖，依樣畫葫蘆繪製出2張不同介面的循序圖。

其實，模仿前頭的循序圖，我個人認為有三個好處，分別條列如下：

1. 容易下手：從0到1是最難的，先模仿、再修改，這樣比較容易下手，工作效率更高。

2. 風格一致：因為模仿前面的設計，所以前後的設計風格，不會差異太大，容易趨向一致。

3. 再次檢驗：也就是因為要模仿前面的設計，所以有機會再一次檢驗前頭的設計，這樣可以讓設計的品質愈來愈高。

我自己有個快速繪製循序圖的口訣：一仿（模仿）、二修（修改）、三加參（加參數）。前面，我們已經執行了一仿、二修，接著可以在自己腦袋中開始「執行」，看看是否還需要加上什麼樣的參數。