使用案例寫作實務中譯本 — Writing Effective Use Cases ———————————– 作者／Alistair Cockburn/著 譯者／趙光正/譯 出版社／碁峰出版 ISBN／9867727681

內容簡介
完整討論使用案例的關鍵部分，包括參與者、關係人、設計範圍、情節等等。提供完整的使用案例寫作指導，包括寫作步驟與推薦格式。提供一大堆省時有效的使用案例寫作技巧。提供有用的使用案例範例，並且說明範例適用的時機。

這本書的好處就是實例超多，一般的書中對使用案例的介紹都很簡單，或者範例不足，讀一些原則如果沒有範例配合，有時候還真的像在隔靴搔癢。

這本書提出兩個概念：1.把使用案例依照設計範圍(design scope)或者系統範圍(the extent of the system )分為三個層次(第三章)1.Enterprise (business use case) 2.System(system use case) 3.Subsystem(component use case) 2.依照使用案例所達成的目的(goal )分為三層(第五章)1.Summary goal 2.User Goals 3. Subfunctionas 當你在畫使用案例時，思緒先粗再細，就我自己的經驗，高層次的使用案例，數量不會太多，容易控制，也比較能夠用巨觀看事情。管理大量的使用案例時，除了使用高層次的使用案例外，通常也會用到很多使用案例間的關係(第九章,第十章)，或者把使用案例組織一下成套件(package)管理(第十三章)。 還有，就是一般人會問使用案例是否等於需求？不過本書對這部分著墨稍嫌少了一點(第十六章)，還好，它補了一章說明使用案例與整個開發流程的關係(第十七章)，裡面提到使用案例 v.s. 系統特性(System Feature)，作者蒐集了很多的使用案例格式(第十一章)，作者把寫使用案例當成寫作文，所以整本書是在教導你如果寫出一篇篇的短文(使用案例)，當然而會有類似教作文的起承轉合(第六章,第七章,第八章)。

前言

使用案例 (Use Case) 是由 Jacobson 在易利信公司做電信系統時，所發明的一種描述系統行為的工具，並隨著 UML 規格的制訂，而成為普遍被用來作為需求捕捉最關鍵的技術。我是認為，使用案例可以說是這十來年來軟體界最了不起的創見！ 因為它簡單，使用案例圖，利用棒型人偶 (參與者)表達使用系統的使用者與系統需要外部系統的支援服務，而橢圓形的使用案例即是表達一個個系統所提供的功能服務；然後再以純文字的寫作方式，來描述每一個使用案例的需求陳述，也可以說是參與者與系統之間的互動對話，卻又不致牽涉到系統的實做面 (把系統當黑箱)。簡單的圖形，加上文字敘述，就可以建構出從使用者角度來看系統功能觀點的使用案例模型。

不過很奇怪，使用案例易學難精，沒有把握基本精要與原則，很難把圖給畫好 (不容易界定出系統範圍)，更何況是用純文字來寫出需求陳述。耶？ 純文字的寫作這麼困難嗎？ 是的，它真的不容易，我還常建議需求分析人員，多勤讀「古文觀止」，來充實散文的寫作能力。

我大概看了有五本寫使用案例的書籍了 (均為原文著作)，發現到每位作者對使用案例的闡述，歧異還蠻大的，可以說是“各自表述”，而且多少都已經有加入作者本身的觀點，擴展 Jacobson 的使用案例理論。老實說，我對使用案例的技術相當著迷，但學習該技術的前兩年完全不知所云，一點都無法體會出它的本質精髓 (只學會一些使用的功法而已)，直到吸收了兩本好書：“Use Case Requirements in Context”，以及本次書評的主角，才慢慢打開心眼。尤以本書，我起碼看了半年以上，讓我對所謂的層次、目標等級、寫作原則與風格等，可說是奠定了相當清晰的基礎功夫了。

腦力激盪的最佳工具—記錄需求、發掘需求

本書不算薄，22 個章節，外加四個附錄，內容分為三大部分—使用案例的主體、相關議題的討論、寫作提示等。一開始閱讀會有些吃力，尤其第一部份，其實內容有些零散。我是建議要隨時翻閱目錄，瞭解自己在閱讀時的主題與焦點所在，若當下無法體會，其實跳過去也無妨。

第一部份最重要的是當然要瞭解使用案例的本質，以及寫使用案例的格式，Cockburn 提供多種寫作的格式供參考，如單欄/兩欄/RUP，甚至利用 Occam 程式語言、圖形呈現的另類寫作風格，相當有意思！ 另外最有價值的部分，也是 Cockburn 自創的三個目標等級—白雲、海平面、海平面下，來說明使用案例的精確程度，以及適合的目標層級對象。第二部分算是 FAQ 性質的一些主題性的討論。例如最常見的 CRUD (Create, Read, Update, Delete) 與 可參數化 的使用案例該如何描述比較恰當；開發流程中，使用案例所扮演的角色與其它製程產出的關連性；常見的寫使用案例所發生的錯誤 …等，對於實務已經在應用使用案例開發的人員來說，相當具有參考價值。第三部份是我覺得本書最實用的部分了，尤其第 20 章，單一寫使用案例的相關寫作提示，就足以讓需求分析人員受用無窮了，因為以我所看過太多位 SA 所寫的使用案例，幾乎所犯的錯誤，在本章都有提到。所以只要依循本章所列出的十一個寫作提示，要寫出中規中矩的案例敘述，也就不會是什麼難事了。

有意思的是，即使你寫的是中等程度的使用案例，都還來得比其它種類的需求文件還有用，事實上，只要能具可讀性，對整個專案就會有相當的貢獻；再則，使用案例不僅僅只是記錄需求的工具而已，它更可以成為專案成員的腦力激盪工具，來發掘出新的或潛在性的需求，這更是價值斐然！

順應國內短線專案型態—Use Case First

一般而言，使用案例會成為「物件導向」式專案開發的最佳前導工具，雖然它與物件導向一點都沒有關係。本書在國外的評價相當高，但在國內卻不賣座，這多少與本書完全沒有提到如何將使用案例與系統的結構設計至實做的橋接有關，純粹就是在談使用案例的寫作而已。而事實上，國內 95% 以上的專案都是偏以功能導向的開發為主，至於系統內部的結構分析設計，因為時程的壓縮與抽象基礎的素養不足，往往無法做好。功能會直接影響到專案能否被“做出來”；結構則是影響系統的彈性與穩定度。所以個人是主張“務實一點”，先順應國內短線的專案生態，利用使用案例，快速的給直接 mapping 到實做面。

我在實際輔導的經驗中，效果與接受度相當高；雖然是“Quick”，但可不“Dirty”，兩個配套措施是一定要做的：測試案例到測試程式碼，隨時驗證功能的正確性；分析類別的規劃，以符合 3-tier 的 MVC (Model-View-Control) 框架。系統做的出來，開發能力也有比較提升，老闆也比較願意投入更多資源的情況下，再施以結構重整，慢慢粹取出系統最穩定、共用的那一部份。有了使用案例後，我好像就再也沒擔心過能不能“做”得出來，那根本已經不是問題了。

五顆星級的好書，價值多少？

在 Amazon 評價四顆半星的好書，你猜猜看台灣賣多少錢？ NT$ 99，沒錯！ 你沒有看錯，國內販售軟體書籍指標的「天瓏書局」竟然將本書折扣到一折半，不到一百元可以買到寫使用案例叢書中最棒的書籍，但，卻仍舊乏人問津，我真的很難以想像，需求分析人員，省一到兩次的便當錢，總該可以吧？ 好歹，本書真的可以在工作上幫助你太多太多了。

UML與樣式徹底研究 — Applying UML and patterns ———————————– 作者／Craig Larman/著 譯者／趙光正/譯 出版社／碁峰出版 ISBN／986779026X

內容簡介
這是全世界介紹物件導向分析與設計、反覆式開發方式與UML的書當中，銷售量最好的一本書！「UML與樣式徹底研究」可幫助任何開發人員精通物件導向分析與設計的核心開發原則與最佳實務經驗，讓大家不只是畫畫UML而已，而是真的能把它活用在軟體設計情境中。

著名的物件技術與反覆式開發方法先驅Craig Larman在本書中用單一、具有一致性的個案研究，具體呈現開發過程中的三個反覆。透過這三個反覆，逐步介紹物件導向分析與設計中的關鍵技能，並且點出最必要的開發活動、開發原則與樣式。

本書內容涵蓋了：
l.需求與使用案例：發掘需求並記錄
2.產生領域物件模型：了解領域中「有興趣的物件」、它們的屬性以及它們之間的關係
3.架構：為了讓應用程式具有最大的彈性、強固性與可維護性，採用分層式架構設計系統
4.必要的物件設計技巧：專精一些如分配物件責任及根據一些開發原則設計物件間的合作關係的關鍵技能
5.設計樣式：用很流行、常用的樣式產生強固的物件與框架，如策略樣式、代工廠樣式、轉接器樣式、觀察者樣式、範本方法樣式與命令樣式
6.反覆式開發方式與「敏捷式統一流程」：用UP（一種很風行的反覆式流程）中簡單、不可或缺的開發活動與最佳實務經驗組織建立模型與開發系統的流程
教師資源：http://www.phptr.com/larman/. Includes PowerPoint lectures, sample exam, and more

前言

中譯本是翻譯自「Applying UML and Patterns 2nd edition」 (目前原文已出至第三版)。本書可以說是所謂物件導向分析與設計最為暢銷的入門教科書，事實上，也是我踏入軟體設計領域的第一本入門書，也可以說是與我最有緣份的一本書。想當年我是擔任系統與資料庫管理者，其實與軟體開發實在扯不上關係，是因為興趣，想寫圍棋軟體的關係，當時硬K了 Java 程式設計入門，花了三天的時間，寫出一大串、可以點選下子的圍棋程式(當然，不含 AI)。寫完後，一點成就感都沒有，我一直很疑惑的是，Java 的程式單位是 .class，那麼，圍棋的棋盤與棋子是分為一個還是兩個 class 呢？ 問了幾個程式開發的高手朋友們，得到的答案都很不滿意，他們都認為分為幾個都無所謂，能寫出來就好。我還記得很清楚，我聽到有所謂的物件導向式的開發技術後，為了能解除心中的疑惑，某天晚上下班時特地到重慶南路的「巨擘書局」翻書。找了約三個小時，抱回四、五本 OO 書籍，花了有五千餘元，而其中有一本，就是本次書評的主角。當然，沒有一本我看得懂，所以，後來還到了國內主推物件導向的宗師—MISOO 物件教室上課。而在上課之前，我就是把本書(當時是第一版，原文，沒有中譯本)給整本硬K完畢，然後，就其中的內容與問題，逐條的請教當時授課的講師(他們對我蠻頭痛，一直想追到答案)。而也因為此，讓我對軟體產生的莫大的興趣，並因此而轉行，從此踏入軟體設計這極為深奧的殿堂。

本書的大綱架構安排得非常之棒，可以說是最為標準典型軟體工程式的教科書，所以國內已有幾所大學，將其作為資管/資工科系的教材。作者 Craig Larman(我都稱他為 拉麵，諧音)，可以說是把他多年來豐富的教學經驗，全都給濃縮在本書內。尤其自第二版後，還導入了 UP(Unified Process) 流程框架至本書的大綱目錄內，讓讀者大概瞭解一下 UP 的 Milestone 階段目標，與每次反覆(Iteration)的產出(artifacts)有哪些。本書是界定為入門書，也的確獲得眾多軟體人員的喜愛，覺得它容易閱讀且淺顯易懂；不過有趣的是，我也問過許多 SA/SD，看完本書後，還是不知道如何寫程式。除了它僅用一個章節展示如何從設計轉成片段的 Java 程式碼，使得讀者並不知道系統實作涵蓋 n-tier 應用程式的全貌，還有，本書充斥了許多的假設點，若讀者不知道的話，其實很容易誤解其原意。

系統開發的基本—瞭解需求

對於入門者而言，需求是本書最有價值的部分。讀者會發現到，這本書可以說就是以需求作為系統開發的初端，再進而導出系統內部的結構分析、設計至實作等。使用案例模型 (use case model)的建立，是功能性需求最重要，用來發掘並記錄需求的一種機制。而且，它還會影響到系統開發爾後的諸多環節。UP 所倡導的“4+1 View”，即是以使用案例作為驅動並涵蓋整個專案的重心所在。我覺得本書在使用案例敘述的部分寫得相當好，同時也揭露出多種不同的寫作格式與風格，讓讀者得以選擇適當的需求寫作方式。除了使用案例外，作者也介紹了輔助規格(記錄非功能性需求)、企業規則、字彙表、專案願景等其它性的功能需求，其實，這也是 UP 所建議，在需求製程的產出。(參考一下其範例的寫作方式也不錯，但，可不要全盤照收，而造成軟體開發諸多不必要的儀式與負擔)

物件導向分析設計的精髓—物件責任的分派

這是本書最為精彩之處，也是我在其它書籍所看不到的—物件責任的分派 (responsibility assign)。事實上，對老手而言，光看這一部份就值回票價了。對SA/SD，責任的分派，是最被為忽略、不受重視的；但相對來說，要能真的把軟體作軟，可以說這一部份才真正是所謂物件導向分析設計的精髓。舉個例，誰有責任負責訂購總額的計算？ 訂購物件。 一般 SA 可不重視這，可能就寫在 表單(Form)、stored-procedure、或者在功能性的物件上。因為行為的分散，其實就是造就系統混亂、複雜的主因。

由於如何熟練指派責任是 SA 在物件設計中最為重要的事，Larman 提出了 GRASP 的設計原則 (General Responsibility Assignment Software Patterns)，裡面提出五種重要的責任設計樣式。我覺得其中兩個—高內聚力 (high cohesion)與低耦合 (low coupling)性，其實就是決定軟體核心的穩定與否。而此兩者樣式也經常相互衝突，它們之間的關係，可以說就是軟體工程的陰與陽，它們會彼此牽制且影響對方。

系統內部的靜態結構分析—找出物件

需求分析與物件責任的分派，是本書最有價值之處；但 如何找出物件 這一部份，也就是建構領域模型，進而產出軟體規格設計圖，我是覺得寫得不太好。 Larman 仍是以傳統的方式—利用找名詞的方式，來找出概念性類別。雖然他又列出了概念性類別分類清單，來協助 SA 找物件，但這仍不是好方法，因為這是從需求的片段記錄來找尋物件，但需求並不穩定，相對來說，也不容易找出最具本質性(essential)的核心物件。當初我在看這一部份時，著實疑惑甚久，後來閱讀了 Peter Coad“Object Modeling” 一書，揭露出以交易為核心，來找出本質性的領域物件，才總算得到滿意的解決方案。

結語

後面幾個章節，其實可以忽略不看，如果你不知道它的假設點的話。例如利用設計樣式設計出永續性框架 (persistent framework)。請記得，你是在開發領域層級的應用系統，而不是在開發應用伺服器(application server)。永續性框架，系統廠商，如 .NET 的 ADO.NET，以及 J2EE 的 Hibernate 等，都會幫我們作得很好，我們只要學會如何用就好，瞭解內部 O-R mapping 設計，意義其實不大。還有，關於四人幫的設計樣式 (design pattern)，本書也有介紹一些，也是看看就好，因為這方面，倒不如直接看四人幫的原著。

本書共 600 餘頁，而且是以一個案例研討 — POST 系統的開發，作為涵蓋整本書的內容。從需求分析記錄、領域模型建立、物件責任分派、至系統規格模型設計 …等。讓讀者因為有實際案例一步步作下來，而能對本書有一致且流暢地串連起所有章節。

與前一期所介紹的「UML 精華」一書，這兩本是我常掛在嘴裡，鼓勵軟體從業人員必買(當然要看)的兩本好書，又因為翻譯品質甚佳，去除了語言上的隔閡，實在沒有藉口不看。我鼓勵軟體公司至少都要擺上一本，甚至舉辦讀書會。