B16 理論串接實作的瓶頸(3)──從Activity Diagram再refine Use Case

Activity Diagram只有流程圖的意義嗎？如果僅是這樣的話，那就不用浪費時間畫圖了吧。

在製作Activity Diagram的時候，除了Activity的順序與swim lane之外，我們還必須決定Activity的分類。原則上Activity屬於現在製作的Use Case，但是如果某個或某些特定順序的Activity已經出現在別的Use Case裡時，這表示這些Activity有reuse的現象發生。此時應該進行抽出共同部分的動作，意即把這些Activity另行放到一個新的Use Case裡，再讓現在的Use Case去參照拉出Use Case裡的Activity。

很多人都沒有發現這層意義，在表面上誤以為Activity Diagram只是表達流程概念，用漂亮的流程圖工具為每個Use Case畫了一張Activity Diagram後交差。由於UML定義的是表達想法的模型語言，大多數的人就只拘泥在表相的Language，而忘記Model才是它最深層的含意。

為每個Use Case表達流程概念、區分每個Activity所屬的swim lane、拉出共用的Activity為特定功能Use Case，經由表達、分析與提取，慢慢地找出隱含的關聯並為系統建立適當而完善的Use Case List，這是Activity Diagram在這裡的重要性。

一般人通常的想法是，因為系統要這個功能，所以這裡應該有什麼什麼才對；可是某甲認為該切成三個，某乙說應該有五個，這時要怎麼辦才好？如果沒法用科學化的方式分析出有幾個比較適當，那麼開發人員的想法會因為各自的主觀而難以同步。