評 “寫給 SA 的 UML / UseCase 實務手冊”

我是不喜歡用”評”這個字來評論一本書的(這在我的blog也是頭一遭)，一來好看的就好看，不好看的頂多說這是一本地雷書就算了，二來有的領域自己又不頂擅長，沒事寫個”評”字，還要引起筆戰的可能，麻煩事我多不想沾的。

但凡事總有例外，“寫給 SA 的 UML / UseCase 實務手冊”為什麼會成為例外？

因為期待造成了我內心小小地傷害。(嘆口氣先～)

還記得邱老師的＂寫給SA的UML/MDA實務手冊＂，我也曾讚揚過這本書，想說好歹國內終於有人往這塊領域發展了，值得鼓勵；後來也都有追蹤邱老師的書，只是多引不起較大的興趣，但其發表的一些文章，卻還是引起我的注意，像是ICONIX這塊 / Color UML 這些 (這是國內少有人注意的)。

於是看到“寫給 SA 的 UML / UseCase 實務手冊”這本，想說邱老師神功大進，於是連書都沒翻過，就直接先上網訂了。

可惜～ 真的可惜。
期望與失望的程度是成正比的。

簡單說，這本書的消化不夠。 (我個人認為若引用Use Case Driven Object Modeling with UML來說的話，邱老師的這本書沒有顧全到大局。)

若說要實用，也僅能用於小系統。

首先，對話式的內容，在第一章中顯得有些糟，一般對話的方式都有引導的含意在裡面，但遺憾的是，這章說故事的技巧很不高明。(不過，這是小事。)

再來，沒有教導所謂的Use Case Descrption文法，除了S+V+O之外，像 if / while / for 這樣的描述方式，不是只有替代流程就能涵蓋的，這是初學UC的人一定會遇到的撰寫問題，但作者沒有好好地歸納出文法問題。

接著，多數的Use Case內容多顯冗長。

Use Case Description最多寫幾條？寫幾頁？
作者應該要給經驗建議值才是，超過了就要切割，否則就會造成閱讀困難。

寫的人花了1小時寫一個UC，看的人需要花多久才看得懂？

我的實際經驗是，寫得又臭又長時，客戶完全不想看。那多長才不臭？

這會牽扯到另一個問題：動作複雜的敘述，是否適合使用UC？

假設替代流程過多時(有好多個選項)該怎麼辦？一條條寫必定造成閱讀人的障礙。

 
還有，實際專案中，一頁表單可能有20-30個的欄位需選擇，這時難道要在UC一個個填寫所需的欄位名稱嗎？
(在保險、銀行、醫療的系統中，比比皆是。)

ICONIX中教的Domain model的好處在此才會顯現，可是作者沒有提。

另外，商業規則太多時，一併放在UC中也是會造成閱讀跟撰寫的困難。

使用案例可以幫我們連接許多其他需求細節。它提供我們當腳架的材料，以連接需求中不同部分的資訊，幫助我們連接使用者相關說明資訊、企業規則與資料格式等需求。

第四章算是比較有提較少書會講的東西。就像＂Writing Effective Use Case＂說的：

想寫出好的使用案例，其中的最大困難可能是如何管理跳蚤的跳蚤『使用案例中的子子目標』。

不過呈現的方式，建議可以參考＂Use Case Modeling＂(Kurt Bittner, Ian Spence 2002)一書。

＂Use Case Modeling＂中所的UseCase Life Cycle也應一併參考：

不是所有的Use Case 顆粒度都應該一致，專案執行時，我們沒那麼多巴西時間。

像登入、CRUD等類的，有些可以不用寫成UC的，採用segment寫法就可了。
(理由是：Use Case 的重點在產生的價值，很明顯，本書的UC所採取的價值……很不理想)

失敗路線的著重，這也是沒有好好發揮的地方。
為了讓使用案例能夠成為好的系統行為描述、很棒的功能需求，我們應該要把焦點放在目標失敗情況與系統對失敗的回應方式。
目標失敗情況與系統對失敗的回應方式是使用案例對他們最有幫助的地方。

第五章原本也是我期待的內容，可惜著墨太少，這邊補上工具(EA)其實可以幫忙計算。

最後，Use Case是Test Case的前身，以書名來看，第六章應該也要提如何將 Use Case轉成 Test Case的技巧，可惜完全沒提。

SA的書不好寫，但看完這本真的覺得內容沒有好好地消化過就寫出來，有點像是看了其他書之後的讀書心得加上過去經驗，像五六章特別明顯，其他章節對話中也太多無謂的對白；我心疼的不是書錢，而是看這本書有沒有好好地獲得什麼。

邱老師，不可以為了奶粉錢，就匆忙出書喔。
批評，是因為有所期待。

(相信我，我不是來砸場的，我只是希望能夠看到更好的有關SA的書而已。像”寫給SA的UML/MDA實務手冊”我就會介紹給同事或學生看，但這一本……加油！好嗎！)