軟體設計必讀經典(1)以簡約之道介紹UML最實用的部分

教授軟體設計課程多年來，我經常建議學員要常看書，但不是看使用手冊這類操作性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軟體設計顧問團隊擔任架構師／顧問／講師。興趣為整體架構性的思考與學習、期貨投機操作與閱讀。

熱門新聞