{iThome 書評—4} 極致軟體製程中譯本

極致軟體製程
— Extreme programming explained : embrace change 極致軟體製程 — Extreme programming explained : embrace change
———————————–
作者/Kent Beck/著
譯者/李潛瑞/譯
出版社/培生 出版
ISBN/9867910311

內容簡介
本書分成三大部分:

第一部份:問題
從『基本的問題』到『回歸基本面』的章節,構築出XP試圖要解決的問題,並點出評估對策的標準。這部分會告訴你整個XP的概念。

第二部份:對策
從『快速走一遍』到『測試的策略』的章節,把第一部份抽象的概念,轉變成具體方法論的實踐。這部分說的就不是大體的狀況了,而是會把每一種實際做法,跟第一部份所說的問題和原則銜接起來。

第三部份:實踐
從『XP的導入』到『XP的應用』的章節,圍繞在如何實踐XP的各式主題上—像是實踐出適合自己的XP、它對『非常專案』中各種成員角色分工的期待、以及對商業人士的意涵。

這本書談的是XP背後的一些想法—它的緣起、哲學、故事、和迷思。
本書意欲幫助你在獲得充分訊息的狀況下,做出是否導入XP的決定。

如果你 讀過本書後,正確地做出用與不用XP的決定,我都已經達到我的目標。
本書的第二個目標,是要幫助那些正在使用XP的人,能夠對它有更深入的了解。

前言

製程是否與軟體設計有關? 我以為設計本來就不能昧於現實,要能在現實與理想之間,找出調和的解決方案—這會與現實的開發環境有關;再加上設計必然會面對團隊開發時,眾多“人”觀點之間的謀和溝通等議題—這也會與製程有關。所以我也會在「軟體設計必讀經典」系列中,介紹關於製程、方法論等一些好書。其中,本次書評的主角—極致軟體製程,最會是我想推薦給讀者們的經典指標。看到這本書,就如同在舊書攤找到絕世的武功秘籍一般,講究的是心法的傳授,整本書沒有一行程式碼、只有少數幾張圖而已,全都是口述的文字,但閱讀起來完全不沈悶,非常的白話,如同閒話家常般的告訴你軟體的一些道理。

XP, eXtreme Programming (X 要大寫,凸顯了 Magic Letter),中文翻譯為“極致”軟體製程,我覺得 eXtreme 一字也可翻為“極端”,極致代表的是將軟體製程發揮到最善;極端表達的則是有些顛覆傳統開發的方法,但很有效。(例如,搭檔編程,兩個人一起寫一支程式,開發效能反而提升)

教祖康貝特 (諧音),從本書發表以後,儼然成為與 UP (Unified Process)相對立的一種教派:一為輕量級 (XP)、另一為重量級 (UP)的開發製程。(當然,事實上那是僅從方法論的角度來比較看待之,這些製程的根本精髓仍是一致的) 其後闡述 XP 的書籍如雨後春筍,眾多有經驗的軟體開發者們,提出了從 XP的根本價值與原則,來找出解決實務問題的最佳對策與方法等,有三十本以上之多,而目前中譯本也出版了有五、六本左右,但賣得好像不好,本書在某書局又是只賣 NT$ 99。

從問題的根本找出解決方案

第一章開宗明義就提到:軟體的根本問題在於風險! 諸如無法準時交付、錯蟲太多、需求變更、不合適與不必要的功能、人員流動率 …等。因為看到這些問題,XP 先找出影響軟體製程的四個變數因子,然後提出了四種價值觀,再以此訂出開發的基本原則,然後回歸到簡單的基本面,制訂因應的對策,找出實務的解決方法,然後實踐它!

四個變數因子:成本、規模、時程、品質。 你會發現有趣的一件事,其中的三個因子,成本、規模與時程,幾乎都是被控制在客戶手裡,而開發承包單位大概只能控制品質這個因子而已。而品質這個因子正是與前三個因子為反比,所以,成本越低、規模越大、時程越短,那麼,品質必然會差。這種就是根本性的問題,這些變數因子如果沒有作有效控制,那麼導入如 CMMI 等,也是枉然的 (搞不好還更糟糕,增加了太多高度儀式化的工作)。 Kent Beck 在本書中提到了,他發現到可以先專注在規模變數的控制,也就是把規模收斂,專注在客戶真正想要的,早一點釋放出版本 (Release early),如此也比較容易消弭客戶與開發單位見解上的歧異。

四種價值觀:溝通、簡單、回饋、勇氣。 我覺得這就是群體生活最符合人性的恆常價值了。 團隊開發,不說出話來,如何溝通呢? 如果沒有回饋,如何知道你的問題呢? 沒有勇氣表達出你的觀點與決心,如何持續實踐下去呢? 經常性的溝通、回饋、有勇氣表達,團隊自然會造成一種良性的正回饋環路,而更容易有一致性的共識,而往往,簡單的呈現就會出來了。

當你認知到軟體開發的根本問題與所影響的變數,並有了團隊整體的開發價值觀後,就會比較容易找出開發的根本原則了。諸如,快速的回饋、把簡單視為正常、漸進式的改變、擁抱改變、作有品質的事。

把握住基本原則後,再來才是找出解決實務的方法。本書提出了十二種實務 (當然,具體實踐的作法,是在其它書籍中深入說明的),相當具有學習參考的價值,不過,可不要全盤照抄,國情、人文等因素,有些不一定行得通 (例如,要求客戶駐在承包公司),況且,方法是“How-to”,我們應該是從原則來自行找出方法來的,這才是符合 XP 的精神!

簡單的道理卻難以執行

我覺得 Kent Beck 是生活的大師,他把許多生活的哲理帶入了軟體領域來,書中也提到,他媽媽教導他開車時,不是讓車子一直保持在「正確」的方向,而是時時保持專注,這裡修正一點、那裡修正一點。嘿,這正是漸進修正的最根本道理啊。所以書中的副標題為何叫做“擁抱改變”? 因為,軟體開發中的每一件事物都會改變,而問題不在於改變本身,而是在於無法應付改變。

是的,我非常認同 XP 的智慧,不過我也不是 XP 的狂熱份子,我會動態找 How-to,所以例如,“測試先行 (XP 十二項實務之一)”,是我會主張在客戶單位堅持要導入的,而且是以使用案例(加上測試案例)作為功能測試的單位—而這就不是 XP 的方法了。 XP 是建議以 “Story board (或稱為使用者陳述)” 來作為需求的功能點,不過,我覺得使用案例實在很好用,沒必要完全拋掉 UML。 (XP 這點比較奇怪一點,幾乎不見 UML 的影子,甚至連圖形的設計表達都很少)

XP 的道理相當單純,但「執行面」可是很難執行。這在本書第二十四章有特別說明之。Kent Beck 提及,導入的難處,主要還是情感上的問題—特別是恐懼感作祟。我很認同! 所以,我從來不與客戶說我要協助你們導入某某方法論,通常就是以誘導的方式,不知不覺的融入,然後把它當成是一種習慣,團隊成員久而久之就會以為理所當然如此。

對了,為什麼簡單的道理反而不容易執行? 因為,人類往往有兩種天生的傾向:一、對於我們所碰觸的任何事物,通常會弄得過度複雜,基於這個原因,二、我們往往不能看到事物最明顯的一面。

{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 與樣式徹底研究」,也是由他所翻譯的。而這兩本,正是我極力推薦每位軟體從業人員都應該要必備的好書! 也因為有如此高品質的翻譯本(幫光正君掛保證,他翻譯的每一本書都很棒),使得初學人員不致因原文的學習障礙而打退堂鼓 (當然,就長期而言,軟體人員還是要學會與習慣於閱讀原文書籍)。

※參考之前寫的書評

{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)的過程。

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

{程序員邀稿} 從軟體架構師(Architect)的觀點來看軟體開發流程

前言

筆者多年來輔導過諸多不同類型與不同領域的軟體開發專案,本身的職務是擔任軟體架構師(Architect)與顧問輔導。架構師不是只負責技術面的問題,更要兼顧到專案開發的過程中, 」人」 的互動所衍生而來的諸多問題,包括想法的歧異、見解的落差、不同的觀點與角度,甚至情緒問題等等,這些都需要與專案經理協同合作,一同來解決問題。

軟體的開發,最終目標雖然是 「完成高品質」 的軟體系統,但在進行階段過程中,所衍生出的兩大議題—專案管理(Project Management)與開發流程(Development Process),卻是首要需克服的階段目標。而該兩大議題,均是係以 「人」 為核心的考量,專案管理講究的是 「領導統御」、」人和」;開發流程重視的是 「調和 (凝聚團隊成員的觀點、角度,保持產出的一致性)」。專案管理的部分,筆者的角色比較不方便闡述(此一部份由專案管理者來論文比較妥當),倒是相關於開發流程的議題,筆者倒是可以把藉由所觀察到諸多各形的開發型態,以及個人的一些研究、學習、思考與體悟的心得提供給讀者參考之,文中內容會是筆者比較偏以 「主觀意義」 的表達。

變動無常的軟體專案

軟體系統的專案開發,特別的是,需求往往不明確,更何況是經常處於變動中,所以導致專案的範圍與規模無法界定,連帶也引起時程無法估算(人月? 神話吧)。那麼,是不是開發成本的成本也無法預估,而往往也因為成本與時程的低估,更容易導致品質不佳、粗製濫造的軟體系統。

正是由於軟體別於如硬體產業的變動性問題,使得在其它成熟領域的專案管理經驗,並不容易全盤導入至純粹是軟體的系統開發上。若是把軟體開發當成是知識與創新的產業,那麼一成不變且僵化的專案管理方式,並不妥當;除非是將軟體產業當成是軟體工廠,需求固定且明確,工作者(worker) 各司其職,負責實做局部的小功能,再由 「大一點」 的工作者,來組裝成大功能。請記得,這樣的方式,其假設前提是需求不容易變動,工作者也不太需要具備創新獨立思考的能力。

個人是很難相信需求不會變動,同時也認為正是因為軟體的多變性,才造就了更多的好機會,所以軟體的開發,不應該視善變為畏途,反而是把變動看成是理所當然,更是多添了許多的好機會。我們所要作的事情只是,如何將變動抑制或收斂在某一程度可以被控管的範圍內,同時,學會如何在某一問題領域(Problem Domain),重覆性、同質性高的軟體系統,來找出不容易變動的部分,成為系統的框架(framework),或稱之為主結構(Main-Structure)。而容易變動的部分,又是如何從主結構中抽離出來,爾後只花少許的 「工作量(effort)」,就可以輕而易舉的滿足客戶的需求。

很難嗎? 只要有兩個滿足的要素即可:一為開發的資源(包括成本與時程)多一點;另一為團隊對軟體的基礎養成與默契好一點。 但是好像要能滿足這兩點可真是困難,該如何才有可能達成這種 「夢幻」 的要件呢?

這就回到最現實 「人」 的因素了,要能爭取到多一點的開發資源,如果你沒有什麼誘因吸引老闆或業主(兩者可統稱為關係利益人, stakeholder),是不太容易的。專案的領導者總是要有 「實績」 才能讓關係利益人信賴並願意投入資源,而資源越多,當然專案成功的機會就更大。後文會提及,「反覆與漸增(I&I, Iteration and Incremental) 」,會是提升專案開發 「實績」 的好手段。

再探討另外一點,如何才能讓團隊成員對軟體的基礎養成與默契好一點? 默契要好,溝通必然要多,要能溝通多,當然就是要勇於把自己的想法給表達出來,而這些,則是有賴於專案領導者的支援與協調。總之,好的專案領導者是要能懂得 「觀察」 在整個專案開發的過程中,成員之間互動所衍生出的種種問題,然後找出 「解決方案」 來謀和 「人」 的問題;另外回到最根本的是,畢竟這是軟體的開發,軟體的基礎養成功夫不足,當然也不太可能作得好軟體開發,軟體人員持續的學習與成長,更會是軟體產業的命脈。

幾個可能是軟體開發流程的問題點

正是由於 「變動無常」 的軟體開發專案,有些人的想法是想要 「凍結」 住需求,然後依照固定不變的製程,一個階段接續下一個階段以循序式 (Sequential)的開發產出 (artifacts),例如預估一年開發期的專案,三個月的系統分析(SA, System Analysis)、三個月的系統設計(SD, System Design),六個月的實做與測試(Implement and Test),這樣的開發方式稱之為 「瀑布式(Waterfall)」 的開發流程,參考如圖1。 閱讀全文 »

軟體思維顧問

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

Personal