K09 做事的方法(10)──使用工具記錄減輕頭腦負擔

以前開會時總不喜歡帶筆記本，一些在會議時發派的工作就努力地記在腦子裡於會後逐一進行。年輕時感覺沒什麼不好的，雖然偶而會在主管問起時才驚覺忘記有那回事，不過卻也沒有什麼不好；當然也不會感覺到會議記錄有多重要而視記錄為苦差事。

一方面由於年歲漸長發現遺忘的項目越來越多，一方面也因為領悟到做事應有目標清單與執行內容，那些只要有缺少幾乎都會造成結果的不完整，因此慢慢養成將這些項目記錄下來的習慣。如此一來，除了可以追蹤各個項目的進度之外，還可以快速地提供我手上所有應有的工作項目。

其實頭腦的工作就像是CPU與記憶體，雖然功能強大而且容量充足，但是也偶而會發生想不起來的資料遺失狀況；在系統中為了長期保有執行的資訊，我們會使用儲存裝置來放置重要的資訊，而文字與圖表對於我們正如儲存裝置的重要。我們可以把腦袋裡暫時匯出到記錄裡，一方面可以清除腦中的記憶，另一方面可以期望未來在看到以前的記錄時立即回復到當時的記憶；然而更好的是可以把自己的記憶藉由這個方式複製到別人的腦中去。

人腦中的資料還無法複製，口述雖然快速卻有遺忘的風險，只有依靠足夠的記錄才能確保記憶的傳承。這便是我願意花時間去記錄的原因。

K08 系統的製程(4)──Activity的抽取與拆解

在Activity Diagram裡應該定義swimlane來定義Activity是誰要做的動作，這樣才能在觀看Use Case動作的同時知道各個參與者的動作與控制流向，並可以立即檢視該參與者的全部動作。通常我會用到的swimlane定義有User、Timer、System、DB與Extenal System幾種。

使用Rose製作Activity Diagram時有個好處：所有曾經製作出來的Activity都存放在Use Case View裡，在需要引用的時候只要用滑鼠拉到現在的圖表裡就能使用它。如果在引用時發現有多個Use Case都會使用到某個Use Case裡固定的幾個Activity，那表示它們應該被抽取出來成為一個include Use Case；如果在引用時發現需要的是只是某個Activity的部分內容時，這表示該把這個Activity再作切割，拆解出更適合單獨引用的Activity。

這是在系統分析時很重要的步驟，因為每個Activity代表了一個完整的獨立動作，同時若有相同意義的Activity存在，絕對要去使用它而不能另外再創建一個；而且在應該抽取或拆解的時候就要去做，雖然有點麻煩，但是該修正的地方務必要花時間去修正。這是因為每個swimlane的Activity集合就是它的所有動作集合。

看過不少人使用Visio畫出流程圖來取代Activity Diagram，最大的原因是因為美觀。但是一個純粹繪製流程圖的工具是沒法幫助我們進行上述的系統分析動作的。

K07 系統的製程(3)──Use Case的操作劇本

Use Case定義為系統提供完成獨立功能的計量單位，想要完成一個目的時會有達成目標所需要的分解動作與執行順序，這是在基本觀念裡所提到的規則。在Use Case裡的Activity Diagram就是用來表達這些內容的重要圖表。

每張圖會有一個起點，在SRS裡應記載系統在什麼樣的狀態下，於發生什麼樣的條件時會由起點開始進行；同時也會有一個終點，SRS裡也應註明結束這個Use Case後系統在什麼樣的情況會變成什麼樣的狀態。系統從起點到終點之間的落差，正是在這個Use Case裡應該完成的事情。

動作與流程的描述就如像畫流程圖一樣，動作全部由Activity圖示表示，流程控制則有branch node、merge node兩個再加上parallel line。關於流程控制的觀念大家應該都差不多，不過重點還是在Activity的定義上。Activity定義的是從概觀觀點上的一個完整動作；例如功能中需要列印資料，則Activity可以命名為列印資料，而不需要定義成open printer、print data、close printer三個Activity，因為列印的作一定需要這三個小動作一起執行的。

由於Activity Diagram可以明確地同時表達流程與動作，這是在Excel裡用文字敍述所沒法達到的，因此強烈建議使用Rose製作；如果時間很趕，可以只先畫swimlane與Activity而不畫出流程。即使用文字表達出劇本或是另外夾流程圖圖檔可以勉強表達出Activity Diagram的意境，但是接下來卻會難以完成一個很重要的程序。

K06 替代的作法(2)──Actor與Use Case的關係

由於關係沒有辦法從Excel快速地轉換到Rose裡，基本上在這時我會直接在Rose編輯Use Case Diagram。在Rose上編輯另有兩大好處：一是圖形化的介面易於檢視並釐清各個物件的關聯，一是接下來要製作的Activity Diagram是附屬在Use Case物件裡的圖表。

如果系統的規模很小或者對開發的系統熟到不能再熟，當然是可以直接寫在Excel檔案裡作為記錄。在2007/11起的這個專案由於是重寫舊系統，在爭取時間的前提下就設計了一份表格盡量記下最多的資料，不過當時思考的還不是十分清楚。下圖是根據上面提到過應有的資訊而調整過的表格，把Subsystem、Use Case與Actor的內容與關係都儘量 定義在同一個Sheet裡。

K05 系統的製程(2)──Actor與Use Case的關係

在Actor與Use Case之間的箭頭中包含了二者的使用關係，在UML裡這層關係是使用Use Case Diagram來表達的；我的習慣是以一個Subsystem的Use Case畫成一張圖來表達與Actor的關係。這裡所需要的資訊是從使用者那裡得到的，如果在畫圖的時候感到迷惑就要儘快再與使用者確認。

在製作Use Case Diagram時可以明顯拆解的Use Case要先拆開，該平行列示視作數個Use Case或是垂直使用像include、extend關係的也要確定，接著就依需求拉妥Actor與其能操作的Use Case使用關聯。Use Case大致分為兩種，一種是與Actor有直接關聯的，另一種則是與Use Case有關聯的，這些都會在繪製Use Case Diagram的同時建立在Rose Model裡。

這層是系統直接與使用者有關的最High Level關聯。垂直關係表示系統的Actor各自可以操作哪些Use Case以及Use Case允許被哪些Actor使用；水平關係則表示了各個Use Case之間的關聯。

K04 保持Excel與Rose間的一致

由於Rose與Excel之間的內容並無法藉由簡單的方式百分之百的轉換，所以我們得另外花功夫才能維持二者資料的一致。但是從另一方面來說，採用把Excel內容使用Robot輸入Rose的方法時，如果可以的話盡可能地在Excel上整理資料，等到有接近十成的把握時再做轉換的動作可以有效延後開始維護兩份資料的動作。

如果很不幸地在轉換後發生了改變，維護通常會有兩種方式：一種是將改變在Rose上與Excel裡都做一次，另一種是先在Rose上修改變更並在告一段落時使用SoDA產生對應的段落，再將內容貼回Excel保存。之所以要在Rose上操作是因為把Excel的改變傳入Rose幾乎是無解的，所以不應該在Excel裡操作。

在初期的Actor與Use Case列示出來後，理應要有二者間追溯關係的記錄。不過接著我們會作Use Case Diagram的Refine，雖然可以使用初期得到的對應關係再作擴展，但是基於節省時間的前提，我會等到所有Actor、Use Case都定義妥當時再花時間一次做好。

K03 輔助的文件(3)──用Robot模擬大量UI操作

曾經遇到需要大量建立Actor與Use Case的情況，詢問公司內負責推廣Rational的人Rose是否有提供程式使用的API，答案是沒有。那時就覺得很頭痛，因為要把Excel裡的資料一一建立到Rose裡可是要花不少時間的。

因為“想偷懶”而暫時使用Excel作記錄，如今為了要彌補把資料從Excel搬回Rose的差距，我必須投入時間以敉平之。我把Rose在畫面上最大化後反覆建立與輸入的使用者操作動作並記錄其順序，然後寫一個小程式用JXL讀出使用Robot物件來做這個重覆輸入大量資料的工作。

UI的動作不外乎是鍵盤與滑鼠與鍵盤。鍵盤的動作只有對某個鍵的壓下與放開，有時會有Alt、Ctrl、Shift的組合鍵；滑鼠的動作則僅是指標位置的移動與按鈕的壓下與放開而已。唯一的限制是在輸入Documentation時由於無法直接輸入中文字串，所以必須先切換到Unicode輸入法逐一把中文字元的四個unicode模擬鍵盤操作。

這個小程式幫了我很大的忙，在系統開發的初期可以專心在Excel裡快速建立清單，在建立後再交給Robot立即在Rose裡重現這些資訊。

K02 替代的作法(1)──初期Actor與Use Case清單

雖然Rose + SoDA可以快速地輸入資料並產出自訂形式的報表，但還是有不方便的地方。例如想要邊檢查清單邊編輯的時候、還有需要蒐尋Documentation內的資料等，都必須在操作Rose的同時，再檢查SoDA產生報表；對我而言，這就類似在兩個thread切換。如果可以在編輯的同時就能夠立即獲得需要的資料該有多好？

最初期的需求動作是列出所有的Actor、Use Case並決定Use Case所屬的Subsystem，這是需要編輯的三個對象。Actor與Subsystem需要的資訊是Name與Documentation、Use Case除了Name與Documentation外還需要所屬的Subsystem名稱。那麼就準備一個Excel檔案，建立Actor、Subsystem與Use Case三個Sheet並像下圖這樣建立欄位資訊，接下來就暫時忘記有Rose這件事而把收集到的資訊都全部填入到Excel檔案裡。

在Use Case的那一頁有一欄是要記錄所屬Subsystem名稱，將那一欄用不同的顏色標記以提醒填寫的人要參考Subsystem的定義填寫。

K01 系統的製程(1)──初期Actor與Use Case清單

系統的原始想法都在使用者的腦袋中，他們是沒法自己寫出系統的，所以才會找廠商協助開發他們想要的內容；正因為如此，我們必須經由需求訪談來盡量發掘使用者的想法。不過使用者通常只能夠概述要系統幫他們完成什麼樣的工作，一方面沒法明確描述系統功能，一方面也沒法有條理地整理需求。

需求的訪談就是協助客戶更完整地描述系統的需求，並在收集資料之後加以整理與分析。初期得到的資料內容應該有Actor List、Use Case List，以及Actor vs Use Case的使用關係表；而在這裡Use Case指的是System所提供的所有功能。
系統的規模到一定程度後Use Case會多到難以管理與維護，此時會建議定義一些Subsystem並將Use Case依內容特性予以歸類。在這裡的子系統會要求在特定的系統架構之下可以單獨執行的功能集合，當然它們是可以有依賴關係的，但是基本上是聚合力高的Use Case放在同一個Subsystem裡。