{iThome 書評—3} 使用案例寫作實務中譯本

使用案例寫作實務中譯本
— Writing Effective Use Cases 使用案例寫作實務中譯本 — 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,沒錯! 你沒有看錯,國內販售軟體書籍指標的「天瓏書局」竟然將本書折扣到一折半,不到一百元可以買到寫使用案例叢書中最棒的書籍,但,卻仍舊乏人問津,我真的很難以想像,需求分析人員,省一到兩次的便當錢,總該可以吧? 好歹,本書真的可以在工作上幫助你太多太多了。

{iThome 書評} UML 與樣式徹底研究中譯本

UML與樣式徹底研究
— Applying UML and patterns 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 精華」一書,這兩本是我常掛在嘴裡,鼓勵軟體從業人員必買(當然要看)的兩本好書,又因為翻譯品質甚佳,去除了語言上的隔閡,實在沒有藉口不看。我鼓勵軟體公司至少都要擺上一本,甚至舉辦讀書會。

{iThome 書評} UML 精華第三版中譯本

UML精華第三版--標準物件模型語言
— UML Distilled Third Edition UML精華第三版–標準物件模型語言 — UML Distilled Third Edition
———————————–
作者/Marting Fowler/著
譯者/趙光正/譯
出版社/碁峰出版
ISBN/9861540393

前言

我教授軟體設計課程多年來,經常對學員建議要常看書,但不是看使用手冊這類的操作性 How-to 書籍,工具書若是因為工作需要,擺著幾本當作參考無妨;或者,若能學會如何交一位好朋友—Google 那更好。從它那裡,可以找到太多 How-to 性質的答案。而到最後你就會知道,學會快速操作使用,原來就是要懂得如何下對搜尋的關鍵字,如此而已。How-to 是越來越容易從網路上找到答案,相對來說,軟體開發人員,就可以把更多的時間與心思擺在軟體設計的思維上。而著重軟體設計的書籍,還真的是只有國外幾位頂尖軟體大師的著作可以學習。只是軟體人員一般會對原文書籍有恐懼感,以及,經常會有一種讀書的壞習慣—想要把它看懂。嗯,想要看懂是壞習慣,沒錯! 所以看書才會覺得有壓力,才會想要從第一頁看到最後一頁,然後大多數都只看到前三章就看不下去了。閱讀軟體設計書籍就是要不求甚解,沒必要想要得到所謂 “唯一的答案”。就是如同看漫畫、金庸小說般,那是一種享受,是對某一主題來作思考與體悟。當然,你起碼就要能分辨,你所選閱的軟體書籍是否原作者有自己的 “想法”,那很重要! 沒有自己想法的書籍,實在相當多,難怪乎有許多讀者 “看不懂” 坊間所謂的 “物件導向系統開發” 的書籍,我覺得是蠻正常的。當你能 “感受到” 作者想要透過書中的文字,來表達他的想法,甚而,還逐漸能猜得出作者內心中的 “假設點”,那麼,你就能知道,這是一本可以值得學習的好書!

「UML 精華(UML Distilled)」,是軟體設計叢書中,最能表達出作者自我又帶著創意性的想法。只是以閒話家常的方式,以口語白話的文字表達,只有薄薄的一本書,卻能精彩活化描述出 UML (Unified Modeling Language, 統一塑模語言) 十三張設計圖的精髓。我覺得 Kobryn (UML 規格制訂主席) 在推薦序文內說得最好:「自古以來,天縱英才的架構師與最具智慧的設計師都瞭解何謂 “簡約之道 (the law of parsimony)”。」 他甚而還引用了佛家禪宗的心法來解釋簡約之道:「禪宗的心是初學者的心」。而軟體與佛家的智慧是一樣的,是不受時空限制的,其要旨均在於如何將繁雜的表象萃取其本質 (essence),讓形體 (form)可以很協調地與功能融合在一起。

Martin Fowler,正是軟體界具有真正智慧的軟體大家! 所謂的 “簡約之道”,真正在本書中發揮得淋漓盡致。他就是能用迷人、口語化的寫作風格,來寫出「UML 中最有用的一小部分」,而這一部份,正是可以幫你完成百分之八十工作的百分之二十的精髓 (8/2 法則)。 Fowler 是我在軟體業界最為景仰的大師,想想看,有誰能從架構、分析設計至實作的垂直層次寫出這麼多的經典書籍呢? 包括了 “Analysis Pattern”、”Refactoring (重構,國內由侯捷大師翻譯)”、”Patterns of Enterprise Application Architecture” 等。 對於 Martin Fowler,真的也只能想到 “天縱英才” 這樣的字眼,來表達出我個人對他的尊敬與崇仰。

先瞭解本書的架構大綱

從一本書中的目錄,大概可以知道作者所要表達的核心思維會擺在哪裡。前兩章論及了軟體開發方法論 (methodology),這裡理所當然會介紹 UML 的簡介,以及現今主流的開發流程;然後從後續的章節,就是以每一個章節來介紹 UML 十三張圖;而關於類別圖,Fowler 則是用了兩個章節來作說明。而且蠻特別的是,第三章就開始介紹類別圖了,這可是與一般軟體設計書籍最大的不同之處—先從需求分析著手。至於需求面的設計圖,包括了使用案例圖與活動圖,則是擺在中間的章節,從第九章起才開始介紹。從這樣的編排來看,你就可以知道 Fowler 最為重視的會是軟體的結構分析,而這也是本書最精彩之處,包括類別圖與循序圖的介紹與其想法的論述。

軟體開發方法論 — UML 與 開發流程

所謂的方法論包括了兩大要素:溝通的機制與開發流程。 UML 正是利用圖形標準化的模式語言,來作為團隊開發之間溝通的最佳機制。Fowler 在對 UML 的簡介裡,說明了 UML 的發展歷程—由三巨頭的統一方法論而成形的;歷史的典故瞭解一下就可以了,不過,Fowler 很幽默,還提及了在 95 年的 OOPSLA 大會上,Rumbaugh 的高聲一曲來作為慶祝 0.8 版草案的問世。嗯,大家都希望那會是最後一次聽到他的歌聲。 🙂

Fowler 也提了對 UML 的用法,有分為草稿式與藍圖式。前者是將 UML 圖形作為溝通的機制,不講究精確的語法;後者則是要求精確性高的設計,而以此可以讓程式設計師依樣畫葫蘆寫程式。嘿,我也與 Fowler 的想法是一致的,比較偏向草稿式的作法。道理很簡單:1. 你不能假設你的設計會是正確無誤的;2. 絕大部分的軟體人員,連 “畫出來” 都不太有勇氣了,更何況要求僵化的工程模式? 那可會嚇跑一堆軟體人員,而違背圖形模式開發的的本質—溝通。

雖然是介紹 UML 語法,不過 Fowler 還是特別開出一個章節來介紹開發流程。在該章節中,首先就比較了所謂反覆式(iterative)與瀑布式(waterfall)的開發風格。現今主流的開發流程都一致認同反覆的開發方式,但卻很難做得到,因為會衍生不確定性的恐懼感,與專案管理的議題。Fowler 用了一個很有趣的字眼,「偽反覆式開發方式 (原文是用 pseudo,我覺得真的很客氣,不是用 fake)」:雖然大家都宣稱正在採用反覆式開發方式,不過實際上卻仍是瀑布式的開發方式。哈,這與我經常在課堂上常提,導入如 RUP 軟體製程的開發公司,大部分是 “藍皮綠骨”,因為他們根本就作不到使用反覆的開發方式;因為,他們會重視制度與管理,卻經常忽略了人本—而這正是反覆式導入成功與否的關鍵所在。

章節後面則簡述了關於 “敏捷式(Agile)”、”極致軟體製程(XP, eXtreme Programming)”、”RUP (Rational Unified Process)” 的比較。我覺得 Fowler 在這部分道出了開發流程的本質:流程僅是框架,只是一種建議、一種範本,可千萬不要傻傻的以為導入某一開發流程就可以解決軟體的根本複雜問題。我最喜歡其內的一個字彙:裁適 (tailor)—要懂得裁減開發流程以符合專案的需要。

軟體系統的根本—結構的分析與設計

UML 最重要的一張設計圖就是類別圖 (Class Diagram),作為軟體大家,Fowler 是最為重視軟體的結構分析與設計,而這也是軟體根本所在—非從表象的需求來看待系統的開發,而是直指核心,找出軟體的本質。

兩個章節中,基本概念是介紹了類別圖的基本語法,而在高等概念則是說明了類別之間的關係,與一些比較少見,如關連類別、範本類別等的說明。要看這兩個章節,最好能有對所謂物件導向觀念有基礎功夫,如什麼是物件、類別 (老實說,即使對老手而言,可能還不一定清楚物件與類別的區分)。高等概念其實不容易看懂,更何況,這還只是介紹語法而已,並沒有教你如何抓本質性的類別,那會是很需要抽象高層次的悟性,是與 IT 技術沒有多大關連的。

真要談到程式設計人員會關心的,反而不是類別圖,而會是表達物件互動的循序 (Sequence)圖了。Fowler 提到了所謂集中式與分散式的控制設計方式,這裡他寫的真是精彩,相當有趣! 你會發現到,Fowler 沒有說集中式控制方式的不好之處 (事實上,這是最容易的開發方式,但嚴格說來,它根本不是物件導向),他用了另外的說法:就是強烈要求寫集中控管的軟體人員採用分散式的設計風格,也不說明為什麼,但總有一天,他們會恍然大悟,這時候,他們的腦袋將彷彿重生。這真是最高段的損人不帶任何髒字:重生之前到底這些軟體人員的腦袋是長什麼樣子?

系統的外觀—需求分析

第九章以後 Fowler 才提到了需求的分析,使用案例模型 (Use Case Model) 與活動 (Activity)圖。使用案例模型包括了案例圖與敘述,Fowler 在此並沒有著墨甚多,只是針對基本的語法作說明。事實上,在案例敘述這一部份,他其實是參考了 Cockburn “Writing effective use case (中文譯名:使用案例寫作實務)” 一書。然後他還特別提了:對於使用案例,請把自己的精力放在說明文字,而不是在圖上,使用案例敘述才是全部價值之所在。喔,正是由於這段敘述,我並不那麼為然,還特別開了研討會來說明使用案例圖的價值與妙用。其實呢,要先釐清假設點:需求敘述對需求分析人員是最重要的,那沒錯;但是,使用案例圖則是軟體架構師的利器—用來界定系統開發範圍,區分內與外,決定那些要作、那些不作。

其它的設計圖

Fowler 很有意思,他不覺得重要的設計圖,即使是一個章節,大概就是一頁的文字說明,再加上一張範例圖就結束了,也不囉唆。例如部署(deployment)圖、互動概觀 (interaction overview)圖、時序(timing)圖 (讓我想起電子實習的示波器,真是噩夢)等。我是把這些設計圖稱之為 “雞肋” — 食之無味、棄之可惜。

倒是還有兩張蠻有價值的設計圖:狀態(state)圖與複合結構(composite structure)圖。 第三版改版最多的部分就是在狀態圖的說明,它會與嵌入式系統設計或者複雜的畫面狀態設計有相當的價值貢獻;而複合結構圖則是 UML 2.0 規格最有價值的一張新視圖,它同時結合了類別與元件(component)圖的優點—表達整體系統對外的介面,以及系統內部的結構組成元素。

結語

這本書目前出到了第三版,我則是每一版都買,而且你會發現到,Fowler 在每一版的制訂,並不是新增補充而已,而是會把他當下對 UML 的心得與體悟,給整個重新寫到修訂的版本內,但仍還是可以維持那麼 “薄薄的一本”。三不五時,我仍會拿出來翻閱,還不時會發出會心的微笑;而且你會發現到,新手看了本書,收穫甚多,而老手再重新看時,卻又仍有不同的深刻體會,這本書就是如此的精彩!

譯者趙光正先生,他翻譯過許多相當棒的軟體設計好書,甚而在下一期我準備介紹的書評—「UML 與樣式徹底研究」,也是由他所翻譯的。而這兩本,正是我極力推薦每位軟體從業人員都應該要必備的好書! 也因為有如此高品質的翻譯本(幫光正君掛保證,他翻譯的每一本書都很棒),使得初學人員不致因原文的學習障礙而打退堂鼓 (當然,就長期而言,軟體人員還是要學會與習慣於閱讀原文書籍)。

※參考之前寫的書評

【好書分享】我要獲利—期權贏家筆記 I, II

我要獲利II─期權贏家筆記 我要獲利II──期權贏家筆記
———————————–
作者: 熊傳慧、賴育漣、嚴雅芳、曹佳琪/著
出版社:聯經出版公司
ISBN: 9789570831559

內容簡介
不管行情波動,不管交易多寡,只要選對操作心法,就有獲利機會!

12位國內期權高手,有工程師、傳產員工,也有設計師、專職操盤者;有人勇於挑戰,有人穩健操作;有的把「期權市場當作提款機」,有的只拿閒錢去操作。儘管背景不同,個性迥異,他們的共同心聲是:市場有的是機會。他們究竟怎麼贏的?他們在本書暢談投資歷程與比賽心得,公開突破100%高報酬率的祕訣。

2006年11月,台灣期貨市場總成交量正式突破1億口。這是一個具備代表性的里程碑!

1億口的背後,呈現了哪些意義?

2006年期貨交易量首次突破1億口,其結構為期貨商品1,400萬口,選擇權商品1億口。2005年的統計是9,265萬口,成長23.68%。

數字展現了齊全交易的活力。同時,期貨新商品陸續冒出頭,也讓台灣期貨市場的活力十足。

期貨市場高槓桿、高風險的特性,有人卻步,但是也有投資者透過操作,證明自己的實力,也因此累積財富。寶來曼氏2005年開始舉辦競賽,部分投資人以不到100萬元本金,比賽結束時獲得資金逾千萬元。

2006年,參賽者超過1萬人,年度累積獲利率超過100%以上者有50人。冠軍獲利24倍,亞軍獲利9.69倍,季軍獲利8.1倍。

數字證明,不管行情波動,不管交易多寡,只要選對操作心法,就有獲利機會。他們是期權頂尖高手,投資人更想了解他們的投資經驗和心得。

他們是誰?有哪些特色?

這本書,介紹2006年12位參賽贏家。從他們的投資行為和績效,以及營業員的分析,你可以發現,經驗豐富、個性沉穩,是致勝關鍵。12位贏家與讀者分享致勝秘訣,你也可以成為期權贏家。

去年八月初,出版了「我要獲利:期權贏家筆記」,我還記得,當時在博客來訂購時還因大賣缺貨而拖延甚久;不到一年的時間,又出版了同一系列的第二集,均是介紹由「寶來曼氏期貨」所舉辦的「期權競賽」,在為期 10 個月的競賽期間,頂尖操盤手的獲利記述。

這兩本我都精讀過多次,發現到,其內所介紹的頂尖投機者,十之七八都是極短線。多短呢? 一天交易五次以上屬於極短線;一天交易一至五次,是被定義為中線;而一天交易一次以下,在本書竟是被定義為長線。 哇! 這與我從「短線交易秘訣」,以及其他諸多投機名家諄諄教誨的完全不同:交易不要太頻繁!

但他們卻都是具有實績的高勝率(獲利率超過 100% 以上)贏家,事實就是擺在眼前! 我為此的確納悶許久,但也不得承認:短線當沖操作,的確仍可以具有相當的獲利。

第一、二集的書中主角,有一位都是列在排行榜內,也是一位軟體工程師,轉換專職期權操作後,獲利率均相當驚人成功。他的名字是 Genin,從書中內容介紹與 Video(第二集內附的光碟)的寶來所舉辦的期權研討大會的心得發表,感覺他是生活規律、交易紀律嚴謹的操盤手—這也是這兩本書所有交易人一致的心法:嚴守交易紀律。

個人相當欣賞 Genin 對工作的認知與態度:工作對一般人而言佔了三分之一的時間,有三分之一在休閒娛樂或是充實自己,另外三分之一在睡覺。而這些職場工作者(原文是寫成投資人,我覺得怪怪的)覺得他們每天三分之一的時間過得很痛苦,卻又不轉換自己的心情,不尋找真正適合自己的工作,也不熱愛自己的工作,只是很單純的浪費時間,工作只是純粹為了獲取金錢。浪費自己三分之一生命的人,想要成功的機率實在是太低。

講得可真好,這與我的看法是不謀而合,你所做的工作是要你覺得會投入熱忱,是會樂在其中的。諸多軟體人,在職場並不開心,抱怨雖然連連,卻又為了一份死薪水甘願忍受不快樂的環境。Genin 在工作上,是很持正面與積極的態度,無奈超長的工時(常常一天工作超過十六個小時)與健康因素,才轉換到期貨市場裡來。

看看 Genin 先生約六個月的交易記錄,呼! 期貨交易量是 50,00~100,00 口;選擇權交易量是 5,000 口以下,實際獲利率是 140.11%(第二屆第二名)。其他短線的交易人,也是差不多這樣的交易量。 真是可怕!! 我可怕的不是獲利率,而是如此龐大的交易量。以 5千口來說就好了,如果每一口的交易稅+手續費為 $300 的話,那麼半年就要耗費掉 一百五十萬的 交易稅+手續費 支出。 88|

我持續在思考這些相關的問題:每年寶來舉辦的期權競賽約有 1、2 萬人參加,獲利率超過 100% 以上的約有 50 來人,不過卻沒提到獲利率 100%~1% (正獲利) 以內的參賽者有幾人,假設獲利率為正的人數有 500 人好了,然後除以 15000 人的參賽者,所以在這個競賽約只有 3~5% 的交易人是有獲利的;對比這個期貨市場,應該也與我本來的推論差不多,一百個交易的散戶,只有不到五個人有獲利!

這兩本「期權贏家筆記」的文筆寫來不錯,均能描述出每個交易贏家的性格與其操作的想法等,甚至還會去訪談負責每個交易人的業務,從她們的角度來看贏家的特質。我是覺得買來當作小說閱讀,也是相當精采與易讀的,更何況也可以好好學習這些交易贏家們的交易心法、策略與紀律等。

「寶來」舉辦的這種競賽實在太成功了,還著文揭露出極短線也能有高勝率。我後來才想到,其實真正最大的贏家,應該就是「寶來」他們自己,坐享有這些眾多交易人的手續費,而且還完全沒有任何風險的~ 所以呢,一、兩百萬的冠軍獎金似乎太少了些呢,這些獎金,還不夠付手續費呢。 🙂

{iThome 書評} 從需求到設計—Exploring Requirements

從需求到設計:如何設計出客戶想要的產品 從需求到設計:如何設計出客戶想要的產品
Exploring Requirements: Quality Before Design

———————————–
作者: 唐納德.高斯,傑拉爾德.溫伯格/著
譯者:褚耐安
出版社:經濟新潮社
ISBN: 9789867889584

內容簡介
大約有90%的產品開發案是失敗的,其中30%並沒有開發出任何產品,其他的雖然有產品問世,但人們不喜歡,或從來不使用;即便使用了,也是毛病一大堆。

做好需求分析,是新產品成功的關鍵

暢銷書《你想通了嗎?》兩位作者又一傑作。他們總結與各大小企業合作60餘年的經驗,來探討新產品開發過程中,最困難的部分——如何設計出「高品質」的產品或系統。在本書裡「品質」的定義是:「符合客戶的需求」。

但是,為什麼有那麼多新產品專案會胎死腹中?……為什麼新東西要符合我們的需求這麼難?由此看來,客戶需求、品質、與客戶溝通、設計等等環節,都大有學問。而且,可能客戶「自己都說不清楚自己要什麼」。

因此,要做出客戶想要的產品或系統,不僅需要專案管理的技巧,還要先做好「客戶需求分析」,這就是本書的主題,內容包括:需求要件(requirements)、減少語意曖昧(ambiguity)、使用者參與、激發概念的會議、專案命名、調和衝突、客戶要什麼(功能、特性、限制、偏好、期望)、技術審查、測試使用者滿意度、黑箱測試等等。還有實際案例貫穿全書,以及豐富的心得分享與建議。書中提到的技巧,曾經成功運用於許多產品或系統──包括電腦硬體、電腦軟體、家具、建築物、書籍等。

本書對於新產品專案的所有利害關係人——團隊成員、客戶、使用者、還有必須綜觀全局掌控進度的經理人,都大有幫助。「工業設計」正在流行,本書可以幫助你有效帶領團隊,讓專案邁向成功!

作者簡介
唐納德.高斯(Donald C. Gause)和傑拉爾德.溫伯格(Gerald M. Weinberg)是國際知名的顧問,也同為美國計算機協會﹝ACM﹞的講師。他們長期合作各式各樣的計畫,還合著有《你想通了嗎?》(經濟新潮社出版)。

唐納德.高斯是紐約州立大學賓漢頓分校Thomas J. Watson工程學院的系統科學教授。他的研究重點是:複雜系統的設計與開發,以及大企業的創新。

傑拉爾德.溫伯格是美國軟體工程界大師級人物。在40多年的軟體業生涯中,他曾任職於IBM、Ethnotech、水星計畫(美國第一個載人太空計畫),並曾任教於多所大學。他更是傑出的軟體專業作家和軟體管理思想家,因對技術問題與人性問題所提出的創新思考法而為世人所推崇。1997年,溫伯格因其在軟體領域的傑出貢獻,入選為美國計算機博物館的「計算機名人堂」成員。他也榮獲J.-D. Warnier獎項中的「資訊科學類卓越獎」,此獎每年一度頒發給在資訊科學領域對理論與實際應用有傑出貢獻者。

溫伯格共寫了30幾本書,包括《顧問成功的祕密》、《領導的技術》(以上由經濟新潮社出版)、《程式設計的心理學(25週年紀念版)》、一共四冊的《溫伯格的軟體管理學》等。他的著作主要涵蓋兩個主題:人與技術的結合;人的思維模式、思維習慣與解決問題的方法。在西方國家,溫伯格擁有大量忠實的讀者群。溫伯格現為Weinberg and Weinberg顧問公司的負責人,他的網站是www.geraldmweinberg.com

我在看一本書的內文之前,一定會先對書名來思考該書背後蘊藏的內涵,本書的英文全名是:「Exploring Requirements: Quality Before Design」, 這讓我會聯想到:需求是什麼、為什麼要探索需求、哪時候需要探索需求、誰需要探索需求,需求的對象是誰、又該如何探索…;然後從副標題顯然可以知道,需求是在設計之前必要的階段,需求的品質,會影響到設計的好壞,它甚至是決定最終產品成敗的最要關鍵,因為畢竟,需求是直接貼近使用者端,是站在客戶的角度來看待產品的好用與否。

本書的兩位作者:Gause(高斯)、Weinberg(溫伯格),前年我正巧買了他們合著的一本:「你想通了嗎?(Are Your Lights On)」,是探索表面浮現出的問題,其背後所蘊含的問題本質,再從根本進而找到解決方案(Solution),寫得可真好。而在書局,尤其是在賣軟體叢書的書店,出現了多本溫伯格的著作,從「系統化思考」到「顧問成功的秘密」。我發現到,溫伯格早期雖然是從事電腦軟體系統的技術性開發,但他也瞭解技術所不能涵蓋的層面,所以進而研究與探索在人文方面的領域,後期的著作,已經是被歸類為企管與專案管理方面了。我個人非常欣賞溫伯格的寫作風格,更是讚嘆他在書中所表現出的智慧。利用一些淺顯易懂的幾個案例,來探討所討論的主題,再釐清該主題的本質,然後來找出一些方法與手段來解決問題。不像坊間一般專案管理的書籍,是偏向功法,沒有先釐清問題的本質,就直接往工具與方法來尋找,這會造成見樹不見林,那個根本就不見了,如此而會形成整體性的複雜;而本書則是兼具了心法與功法,先從需求的根本談起,然後利用一些簡單的對話案例,來探索各種技巧與方法,淺顯好懂,又能釐清需求的本質。

本書前言,一開始即引用馮紐曼的名言:「如果你不了解自己所說的事物,即使你遣詞用字精確,也毫無意義。」 如果設計產品的設計者並沒有試圖去瞭解使用者真正的需求與期望,或如何來引導顧客發掘出潛在的需求,那麼,無論你設計的多好,多麼有效率,問題是,沒有切中要點(顧客想要的),一切都是枉然,這也就是我們為何要進行需求分析作業,這樣,我們才不至於設計出人們不想要的系統。 我覺得,需求就是一種目標導向的工作,若是設錯了靶,射擊者即使是神射手也是徒然的。「不值得做的事情,就不值得把它作好。」,我個人非常喜歡這句話,這句話可以延伸出太多的意義,如本書提到在探索需求的程序上:「產品不重要,重要的是過程。」/「文件不重要,重要的是建立文件這件事。」 我更是想延伸這句話為:「專案不重要,重要的是專案開發的過程。」嗯,不過這句話可是又要引起諸多專案管理者的抨擊與批判了。  從此句話也就帶出了本書的目的:「發現什麼並不重要,重要的是發現(探索)的過程。」這本書要討論的就是,在需求作業的程序,也就是開發過程中,人們試圖發掘什麼是人們想要(people attempt to discover what is desired)的過程。

本書內容大綱分為五大部分:先有一點共識;起步的方式;探索各種可能性;釐清客戶的期望;大幅提升成功機率。
閱讀全文 »

【好書分享】抓緊時機

抓緊時機  抓緊時機
 ———————————–
 作者: 邱一平/著
 出版社:大益文化
 ISBN: 9868253012

內容簡介
傳統的技術分析偏重於量、價的分析,事實上,技術分析應該包含「量、價、時間」三要素。然而費伯納西時間序列、甘氏矩陣、星座理論……雖然一直是「時間」追求者奉為圭皋的典範,但是這些理論有的艱澀難懂,有的雖然簡潔扼要,不過得到的結論,經常莫衷一是。可以說在技術分析的領域中,「時間」的概念僅聊備一格罷了,然而對大部分投資人而言,它是真正未來交易勝算的絕對關鍵。

作者累積了二十年經驗,發現不論投資人採用哪種類型的技術分析,如果時機不對,即使績效再好的指標訊號也會徒勞無功。只有在真正的交易時機出現時,技術指標的交易訊號才能夠發揮它的關鍵作用。

在這本書中,作者將和投資人一起剖析傳統技術交易訊號的盲點,共同探討交易時機的重要性,並且首度向投資人介紹交易時機的三大構成要素:終極指標、XTD指標、XJC指標。

當然!利潤是金融交易最重要的目的,但是在循環交易尚無法確定交出漂亮成績單之前,投資人仍然必須考慮自己是否具備堅忍的意志?是否耐得住人性考驗?否則,技術分析永無止境的循環交易,永遠只是理論上的紙上談兵。任何再完美的技術理論,如果只是看得到卻吃不到,還不如務實的面對它。人性與現實環境是必然無法迴避的因素,如何創造一個符合人性並且符合人生節奏的交易規則,才是技術派投資人必須思考的方向。

本書內容是作者多年領悟與心血的結晶,期待投資人在金融交易領域的節奏,也能像把握人生的機會一般,敏銳的等待機會來臨,時機到了才進場交易。換言之,「時機」會變成決定交易與否的第一關鍵要素。在對的時間點做對的事,正符合所有投資人對於人生的期待。如果過去你也曾經盲目的相信技術分析交易訊號,如果過去你不斷在技術分析操作中遭受挫折,那麼這本書的內容,希望能為你帶來新的領悟與獲利的機遇。

這一本書是 邱一平 先生繼 「技術分析‧靈活一點」、「頭部與底部的秘密」一口氣在 2006 年所著作的第三本書。 其實年前我就在書局看到「頭部與底部的秘密」該書,但甚不欣賞,也就沒有再去留心,後來是我的好朋友希望我能幫他寫「抓緊時機」書中的兩個指標程式,翻閱了書的標題與內容後,倒是覺得對於本書,個人倒就蠻能接受與認同,所以乾脆後來在「博客來書店」把三本書給全訂購回來。結果「抓緊時機」這本書缺貨,所以是前兩本先拿到。再仔細翻閱了「頭部與底部的秘密」,沒錯,這本書我真的就是不能認同接受,事實上,該書試圖想要去解釋「波浪理論」,本來就不容易。

倒是「抓緊時機」一書,我就非常認同本書作者在前言就直接提到,時機才是交易關鍵!
是的,想要掌握波段利潤的投機者,卻往往會陷入在 70% 的盤整期中,耗費許多隨機與頻繁的買賣,而造成人力與精力的耗損。這也是我為什麼一直無法認同程式交易的原因,因為,程式交易太容易會產生假象了。試問,一個交易人連續四次的虧損後,然後第五次可能全賺回來,但問題是:1.第五次那個時機剛剛你就是不在,沒有投入交易;2.前四次的虧損,投機人的精神力是否能持續屹立不搖呢? 我一直很懷疑這些… 如同本書作者所提:其實傳統流水式的交易模式,只是包裹著糖衣的技術陷阱而已。 我更是作者這句話:等待時機是穩健投資人明智的選擇,亂槍打鳥只是無意義的人力與財力耗損。因此【時機+訊號】不僅是技術分析的最佳境界,「時機」更是決定交易與否的第一關鍵要素

本書的作者邱一平先生,他的寫作風格讓我聯想到了 Larry Williams,我非常的欣賞與讚佩,邱先生也是與 Williams 大師一樣,會對現有的指標或現狀感到不足或困惑,然後他們會在心中有個假設的問題,再去找解決的方法(可能是寫出指標),具體化出來,並且透過統計數據來驗證。我覺得從本書收穫最大的,不是我又得看到了許多神奇的指標,而是邱先生做學問的方法,懷疑、提問、假設、解決、驗證。

邱先生很有創意,他從三個構面:天時、地利、人和,來解釋如何掌握時機。「天時」所提出的假設是,大盤終有「時間的循環」,當觀察到可能是「週期共振」或「均線共振」,也就是諸多均線糾纏一起時,也就暗示了可能下一波的循環即將出現(只是,不一定知道轉多或轉空)。這裡邱先生提出了兩個指標來代表「天時」,一個是 Larry Williams 在 1989 發表的「終極指標」;另一個則是邱先生自己對該指標修正其參數後的 XTD 指標。在「地利」方面,很有意思,邱先生利用整座山脈的觀念,來解釋登山客(投機者)目前所處的位置,是在山頭、谷底,還是鞍部。當然,這些是相對位置,而不是絕對,否則若能透過指標就可以知道大盤的頭部與底部,那不是神話嗎? 作者是做了一個技術指標綜合評分表,可能是 10 個,也可能是 27種,包括趨勢型、超買超賣型、成交量型等各類指標,並命名為 XJC 指標,來協助判讀波段目前是處在相對高點、還是在相對低點上。「人和」方面,當然就是看人氣,而人氣最重要的參考就是成交量了。邱先生發明了一個 XSV 指標,來改良傳統凹凸不平的成交量,並且加入了價格的考量,是屬於趨勢型的量能指標;另外他也針對如台指期並沒有成交量的考量,而運用了 Williams 的 WVAD 指標,來衡量當時的「人氣」的多空性。

這些指標都不難寫,但是我發現到,作者有「留一手」的感覺,並不是很大方。我在寫 XSV 指標時發生了問題,因為在書中作者所公開的公式,有兩個參數,N 與 N1,但他都沒有提這兩個參數的預設值為何,然後透過在「聚財網」發短信詢問,邱先生是很客氣,但也是很客套化,不是那麼願意告訴你參數為何;還有,我發現到我寫出來的指標有正負值,但書中的圖形卻都是 0 以上,我還以為我寫錯了,後來是邱先生有告訴我有負值是沒錯的,但如此的話,那書中那些 XSV 圖形是否有問題呢? 我是很懷疑那些圖形是邱先生早期所寫的「邱式量法」成交量型的指標,但與 XSV 不太相同。「留一手」的眾多邱式自創指標,尤其是在第一本書「技術分析‧靈活一點」更是明顯。這點沒有如 Larry Williams 的泱泱大師風範,是其可惜之處。

我把 WVAD 與 XSV 寫在 HTS 的程式碼公佈出來,也請有經驗的朋友們,看看 XSV 這方面的邏輯是否有問題?

//WVAD 指標
Parameters: N(14)
Variables: C(0),WVAD(0)

C = ((CLOSE-OPEN)/(HIGH-LOW))*Volume
WVAD = SUM(C,N)

Draw1(WVAD)
DrawBase2(0, "分界", DarkGray, 1)
//XSV 指標
//P%=((收盤價/N天平均價)-1)*100
//V%=((成交量/N天平均量)-1)*100
//XSV = ((RMA*N1)-N1天M% + 次一日M%)/N1

Parameters: N(30), N1(6)
Variables: P(0),V(0),M(0),RMA(0),XSV(0)

P = ((CLOSE/AVERAGE(CLOSE,N))-1) * 100
V = ((VOLUME/AVERAGE(VOLUME,N))-1) * 100
M = V-P
RMA = SUM(M,N1)/N1
XSV = ((RMA*N1)-M[N1]+M[-1])/N1

Draw1(XSV)

twt_day_line_070422

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal