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

WFMC Workflow Reference Model 摘要

利用 UML 複合結構圖 表達 WFMC Workflow Reference Model

圖 1、Workflow Reference Model 複合結構 (Composite Structure)圖
(點擊圖片鏈接看原圖)圖 1、Workflow Reference Model 複合結構 (Composite Structure)圖

Interface 1,2&3,5 摘要解釋

Interface1: Process Definition

  • 描述工作流程的定義—XPDL (XML Process Definition Language)
  • 提供 APIs 以操作流程定義的相關資料。
  • XPDL 係為 XML 的檔案格式,可作為流程定義開發工具之間互通的標準 (如同 UML 塑模的 XMI 交換規格)。
  • XPDL 也可作為 BPMN (Business Process Modeling Notation) 語法的檔案格式。

Interface5: Administration and Monitor Tools

  • Workflow 活動過程中,需要被捕捉、紀錄與稽核的資訊。
  • 定義了哪些資訊需要被捕捉記錄,並作為分析之用;但沒有定義資訊是如何被儲存。被捕捉的資訊稱為 CWAD (called Common Workflow Audit Data)。
  • CWAD 會被 Workflow 的管理與監視工具操作存取使用。

Interface2&3: Client Application Programming Interface

  • 提供跨產品 Workflow Engine (需符合 WFMC 認證規格) 的一致性存取方法。
  • 所提供的 APIs 稱之為 WAPI (Workflow Application Programming Interfaces)。
  • Workflow Engine 所提供的核心服務,其對象 (Client Application) 為 表單 (Form)、控制物件 (Control Object)、其它 Workflow Engine …等。
  • WAPI 群組功能分類
    • WAPI Connection Functions
    • WAPI Workflow Definition Functions
    • WAPI Process Control Functions
    • WAPI Activity Control Functions
    • WAPI Process Status Functions
    • WAPI Activity Status Functions
    • WAPI Worklist Functions
    • WAPI Administration Functions

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

※參考之前寫的書評

{程序員邀稿} 以架構為中心的主要設計產出(2)

全文均刊登於北京「程序員(Programmer)」雜誌(台灣天瓏書局可購得), 2007 7月刊, p67~p69。 感謝朱海豔(helenna)小姐用心將文稿轉為簡體專業術語,以及將 Model 重新美編,並轉為簡體。

結構面的設計產出

關於軟體結構

所謂的系統結構(System Structure)分析與設計(Analysis and Design),係指如何正確、有效地分解設計範圍內系統的元素(Element,一般泛指物件(Object)),指派每一個物件所應有的屬性(attributes)與行為(behavior, 責任的分派),抽象表達靜態類別之間的關係,動態組合物件在執行期間(run-time)的訊息(Message)傳遞,以履行系統的功能需求(ex. 來自於 Use Case 的功能分析)...。做好結構分析、捕捉有效的領域概念,以成為系統的主結構,才能建構出堅若磐石的軟體系統,來應付現實複雜系統的善變,甚而讓系統呈現有機的次序成長、生生不息。

如何找出問題領域(Problem)的概念具化成為企業物件(Business Object)、指派每一個物件應盡的責任,並以此來建構系統中的軟體規格模型,已是高階系統分析與設計人員最大的挑戰與應具備的本質學能。更為難的是,如何將企業物件配合現實面的平台,例如如何活用 J2EE Spring and Hibernate 系統框架。因為,現實上,物件的狀態(state)就是被永續(persistent)儲存在資料庫系統內,而在需要用到(企業邏輯的運算)的時候才被活化(activate)起來;同時因為物件共用的議題而需要 AP 應用伺服器的系統支援,包括交易(transaction)控管、安全性(security)、效能(performance)、分散(distribution)等議題的設計考量。兩個層次(高階概念性的分析設計;細部平台面的設計),互補且缺一不可。

系統的內,也就在於分析所組成的內部結構元素,套現在 IT 的術語來說,也就是所謂的物件導向分析與設計(Object-Oriented analysis and design)。相對於系統的外,是著重在功能性的需求分析(也就是前一期內容所介紹如利用使用案例建構的需求模型)。兩者是互補—找出內部穩定的結構元素(物件,Object),來應變外部的功能需求。

而系統的結構分析,正是現今軟體人員們最大的罩門所在。在速成短線的專案開發生態,軟體人員只會看到現在所看到的—找出一個一個的功能,快速地利用所提供的平台技術(如 .NET, J2EE),疊床架屋的方式,Quick and Dirty 快速的給開發出來。不要以為利用 .NET 或 Java 等 OOP 語言,就是所謂的物件導向開發模式,這是兩回事,如果沒有用心地萃取具本質性(Essential)的物件(再一次強調,源自於問題領域的概念術語),而只是看到一個功能就成為一個 Class,那麼,這樣的系統完全會受限於需求性的變動而導致震盪不穩,是不會具軟體系統的彈性(flexibility)、穩定性(stability)與延展性(extensibility)!

什麼是軟體的結構?

軟體系統的整體呈現是來自於問題領域(Problem Domain),也就是把該領域中經常溝通的術語(terminology) 對映至軟體系統的物件,稱之為領域物件(Domain Object)或企業物件(Business Object)。 例如,”人事資源(Human Resource) 管理” 系統的開發,其核心的問題領域當然是以 “人事” ,經常溝通的術語會有 “員工(Employee)”、”部門(Department)”、”請假”、”請假細項(AskLeave Lineitem)”、”考績” …等,而這些術語自然地就會被捕捉(capture)至軟體系統內,而成為構成軟體系統主結構(main-structure)的成分元素了。

將組成軟體系統結構的元素組織在一起,並利用視覺化的方式來呈現,稱之為 “領域模型(domain model)”。領域模型代表真實世界中的概念性類別,呈現的是領域中的概念性類別或真實世界中的物件。在 UML 的模型中,最重要也是最必要的一張結構圖也就是類別圖(Class Diagram)。

參考下圖 1,通常使用 UML 表示法呈現的領域模型,凸顯的是概念(concept),再來則是以及概念之間的關連(association)與屬性(attributes)。例如 “Order”, “OrderLineItem”, “Customer” 都是屬於在該領域中的概念; Customer 與 Order 之間則存在著 1 對 1..多 的關連(一個客戶會有 1到 1..多筆訂購交易); Product(產品) 具有 description, price 的屬性。在概念性的分析時,細節(包括操作,屬性,資料型態等)在目前並不重要,最重要的是能突顯出概念的呈現,也就是找出類別(Class)。

圖 1、範例—訂購系統的類別圖(Class Diagram)
(點擊圖片鏈接看原圖)圖 1、範例—訂購系統的類別圖(Class Diagram)

那個時候最能表現出結構設計的應變能力? 筆者常說,當 SA(System Analyst) 遇到 有點像又不太像 這類的需求時,也就是結構設計發揮的時機了。 舉個例,訂購 若會視訂購的類型,可能是書籍、雜誌、百貨商品等,而有不同的訂購流程與處理邏輯,此時,懂得虛與實互補設計之道的 SA,會很自然地把訂購分為一般化與特殊化(generalization-specialization)—把已知的部分放在一般化;而未來要具體實現的部分放在特殊化。事實上,這也才只是利用到多型(polymorphism)的基本技巧而已,就已經足以解決為何程序員經常會為了訂購類型寫了一堆的 switch, if…then…else 這種的條件敘述,而造成程式碼混雜,難以維護了。

如何找出軟體的穩定結構元素,是系統分析人員最大的挑戰。SA 並不需要具備領域知識(Domain Knowledge),但卻要懂得如何與領域專家(Domain Expert)溝通合作,萃取其知識,並抽象(abstract)成為軟體的主結構。這相當不容易,那並非是純技術面,真正的軟體設計行家,絕對是具高度的抽象的能力,要能懂得從多個構面觀察,時常在反思與找問題(不是找答案)。筆者正是被這在 虛 與 實 均要能互補、一輩子也學不完的軟體設計領域,給深深地著迷,才從原來是系統管理與 Oracle 資料管理師,而至中年才轉到軟體一職來,並已把此視為是終身之職,是要窮究一輩子、甚至帶至下一輩子繼續來修行的。

回歸正題,關於結構設計的好書相當稀少,筆者這裡特別推薦 Peter Coad 軟體大師,從早期 1990年的 “Object-Oriented Analysis”,“Object-Oriented Design”,至 1998 年的 “Object Models”、1999年 ” Java Modeling In Color with UML” 等著作。尤其是 “Object Models” 一書所揭露出以交易為核心的 交易樣式(Transaction Pattern),更是軟體結構分析人員必讀的聖經。在筆者經常訪問與輔導各領域的公司時,經常在當場就直接展現與證明不用懂領域知識,也能馬上抓出該領域的核心結構,所使用的利器即是 交易樣式(Transaction Pattern)

閱讀全文 »

軟體思維顧問

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

Personal