教授軟體設計課程多年來,我經常建議學員要常看書,但不是看使用手冊這類操作性How-to書籍,若是因為工作需要,工具書擺著幾本當作參考無妨;或者,學會在Google下對搜尋關鍵字那更好,可以更快找到How-to 性質的答案。
拜搜尋技術發達之賜,我們越來越容易從網路上找到How-to答案,相對來說,軟體開發人員就可以把更多的時間與心思用在軟體設計的思維上。不過,著重軟體設計的書籍,只有國外幾位頂尖軟體大師的著作可以學習。只是軟體人員一般會對原文書有恐懼感,加上經常會有一種閱讀的壞習慣──想要從第一頁看到最後一頁,結果大多數人只看到前三章就看不下去了。
讀軟體設計書籍要「不求甚解」,沒必要追求所謂「唯一的答案」,要如同看漫畫、金庸小說般去享受,對某一主題作思考與體悟。不過,前提是你必須要能分辨出作者是否有自己的「想法」,沒有自己想法的作者相當多,導致許多讀者看不懂坊間所謂的「物件導向系統開發」書籍。當你能「感受到」作者想要透過書中的文字,表達他的想法,甚而,還逐漸能猜得出作者內心中的「假設點」,那麼,這就是一本可以值得學習的好書!
用UML 20%的精髓完成80%工作
《UML精華(UML Distilled)》,是軟體設計叢書中,最能表達作者自我又帶著創意性想法的好書。作者以口語化、精簡的文字,活化描述UML(Unified Modeling Language,統一塑模語言)13張設計圖的精髓。
我覺得Kobryn(UML 規格制訂主席)為本書所寫的推薦序形容得最好:「自古以來,天縱英才的架構師與最具智慧的設計師都瞭解何謂「簡約之道 (the law of parsimony)」。」 他甚而還引用佛家禪宗的心法來解釋簡約之道:「禪宗的心是初學者的心」。而軟體與佛家的智慧是一樣的,是不受時空限制的,其要旨都在於如何從繁雜的表象萃取其本質(Essence),讓形體(Form)可以很協調地與功能融合在一起。
Martin Fowler,正是軟體界具有真正智慧的軟體大家,能將「簡約之道」,真正在本書中發揮得淋漓盡致。他就是能用迷人、口語化的寫作風格,來寫出「UML 中最有用的一小部分」,而這一部分,正是可以幫你完成80%工作的20%的精髓。
以軟體結構分析為重點
本書前二章談軟體開發方法論(methodology);後續的章節,則分別介紹UML的13張圖;關於類別圖,Fowler 則用2個章節說明,其中,與一般軟體設計書最大的不同,是在第三章就談類別圖,先從需求分析著手。至於需求面的設計圖,包括使用案例圖與活動圖,則擺在中間的章節。
從編排來看,可以知道 Fowler 最重視軟體的結構分析,而這也是本書最精彩之處,包括類別圖與循序圖的介紹與其想法的論述。
軟體開發方法論:UML與開發流程
方法論包含二大要素:溝通的機制與開發流程。UML正是利用圖形標準化的模式語言,作為團隊開發之間溝通的最佳機制。Fowler 在UML簡介裡,說明了UML的發展歷程,這部分只要稍微了解就可以。
Fowler也提到對UML的用法,分為草稿式與藍圖式。前者是將UML圖形作為溝通的機制,不講究精確的語法;後者則是要求精確性高的設計,讓程式設計師能依樣畫葫蘆地寫程式。我的作法與Fowler的想法一致,比較偏向草稿式。道理很簡單:一、你不能假設你的設計會是正確無誤的;二、絕大部分的軟體人員,連「畫出來」都不太有勇氣了,更何況要求僵化的工程模式?那可會嚇跑一堆軟體人員,也違背了圖形模式開發的本質──溝通。
雖然是介紹UML語法,不過Fowler 還是特別開出一個章節介紹開發流程,比較往覆式(Iterative)與瀑布式(Waterfall)的開發風格。
現今主流的開發流程都一致認同往覆的開發方式,但很難做到,因為往覆式開發會衍生出不確定性的恐懼感與專案管理的議題。Fowler 用了一個很有趣的字眼,「偽往覆式開發方式(原文是用 pseudo,我覺得真的很客氣,不是用fake)」:雖然大家都宣稱採用往覆式開發方式,不過實際上卻仍是瀑布式開發方式。如同我在課堂上常提的,導入如RUP軟體製程的開發公司,大部分都是「藍皮綠骨」──重視制度與管理,卻忽略了人本──而人本正是往覆式導入成功與否的關鍵,所以根本作不到往覆式開發。
另外,關於「敏捷式(Agile)」、「極致軟體製程(XP,Extreme Programming)」、「RUP (Rational Unified Process)」的比較。我覺得Fowler在這部分道出開發流程的本質:流程僅是框架,只是建議、範本,不要以為導入某一開發流程就可以解決軟體的根本複雜問題。我最喜歡書中的一個字彙:裁適(tailor)──要懂得裁減開發流程以符合專案的需要。
軟體系統的根本:結構分析與設計
UML最重要的一張設計圖就是類別圖(Class Diagram),Fowler最重視軟體的結構分析與設計,而這也是軟體根本所在──不從表象的需求看待系統的開發,而是直指核心,找出軟體的本質。
本書用兩個章節介紹類別圖,基本概念是介紹類別圖的基本語法,高等概念則是說明類別之間的關係,與關連類別、範本類別等比較少見的說明。要看這2個章節,最好有物件導向觀念的基礎,如:什麼是物件、類別 (老實說,老手可能也不一定清楚物件與類別的區分)。高等概念不容易看懂,雖然只介紹語法,並沒有教你如何抓本質性的類別,那部分需要抽象高層次的悟性,與IT技術沒有多大關連。
真要談到程式設計人員會關心的,反而不是類別圖,而是表達物件互動的序 (Sequence)圖。Fowler 提到集中式與分散式的控制設計方式,這裡他寫的很精彩。你會發現,Fowler不直接談集中式控制方式的缺點(事實上,這是最容易的開發方式,但嚴格說來,它根本不是物件導向),他的說法是:「就是強烈要求寫集中控管的軟體人員採用分散式的設計風格,也不說明為什麼,但總有一天,他們會恍然大悟,這時候,他們的腦袋將彷彿重生。」這真是最高段的損人不帶髒字。
系統的外觀:需求分析
針對需求分析,Fowler使用案例模型(Use Case Model)與活動(Activity)圖。使用案例模型包括案例圖與敘述,Fowler只簡單針對基本的語法作說明。在案例敘述這部分,他其實參考了Cockburn的《Writing effective use cases》(使用案例寫作實務)。
他還特別提到:對於使用案例,請把自己的精力放在說明文字,而不是在圖上,使用案例敘述才是全部價值之所在。對於這段敘述,我不太同意,應該要先釐清假設點:需求敘述對需求分析人員是最重要的;但是,案例圖則是軟體架構師的利器,用來界定系統開發範圍,區分內與外,決定那些要作、那些不作。
狀態圖與複合結構圖
Fowler很有意思,他覺得不重要的設計圖,大概就以一頁說明,再加上一張範例圖就結束。我把這些設計圖稱為「雞肋」── 食之無味、棄之可惜。
其中,狀態(State)圖與複合結構(Composite Structure)圖算是比較重要的設計圖。本書第三版改版最多的部分就是狀態圖的說明,狀態圖會與嵌入式系統設計或複雜的畫面狀態設計有相當的貢獻;而複合結構圖則是UML 2.0規格最有價值的一張新視圖,它同時結合類別與元件(Component)圖的優點,來表達整體系統對外的介面,以及系統內部的結構組成元素。
這本書目前出到第三版,Fowler針對每一版本的制訂,並不只是新增補充,而是把他當下對UML的心得與體悟,重新編寫到新版本內,但還是只有「薄薄的一本」。
我三不五時仍會翻閱本書,新手看了本書,可以收穫甚多,而老手重新再看本書,仍會有不同的體會,這就是本書的精彩之處!
UML精華第三版:增訂嵌入式系統與工作流程概念
Martin Fowler /著
趙光正/譯
碁峰出版
480元
《作者簡介》
王克明
台北工專五專部電子科畢業。現於HSDc軟體設計顧問團隊擔任架構師/顧問/講師。興趣為整體架構性的思考與學習、期貨投機操作與閱讀。
相關閱讀:
軟體設計必讀經典(2)物件導向分析與設計入門
軟體設計必讀經典(3)洞悉易學難精的Use Case
軟體設計必讀經典(4)知易行難的極致軟體製程
軟體設計必讀經典(5)用科學化方式搞懂設計模式
軟體設計必讀經典(6)RUP活用,也可以是敏捷開發
軟體設計必讀經典(7)重構讓程式回到應有位置
軟體設計必讀經典(8)由生活出發,輕鬆領會物件導向
軟體設計必讀經典(9)優質使用者介面,源自好的狀態圖設計
軟體設計必讀經典(10)幫助SA紮穩UML底子的實務手冊
軟體設計必讀經典(11)反覆測試與修正,讓錯誤消失
熱門新聞
2024-09-02
2024-09-02
2024-09-02
2024-09-06
2024-09-02
2024-09-03
2024-09-02
2024-09-04