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 與樣式徹底研究」,也是由他所翻譯的。而這兩本,正是我極力推薦每位軟體從業人員都應該要必備的好書! 也因為有如此高品質的翻譯本(幫光正君掛保證,他翻譯的每一本書都很棒),使得初學人員不致因原文的學習障礙而打退堂鼓 (當然,就長期而言,軟體人員還是要學會與習慣於閱讀原文書籍)。
※參考之前寫的書評※
Hello jackie:
yes, 我是透過 UCD 釐清整體的架構,至於使用案例敘述,那絕對是系統開發相當重要的需求依據。 🙂
好的使用案例敘述可以清楚看出需求內容,也可以看出與其他使用案例的關係, 因此整個系統的整體介面、流程、條件等都可以在使用案例敘述中得到, 唯一的缺點只是不容易看到整體的架構, 所以可以透過使用案例圖的表示來補足這個缺點。個人蠻認同作者表示的”使用案例敘述才是全部價值之所在”。