William’s Blog readings, ideas, feelings, photos, etc. by William Yeh

小啟：既然在前一篇文章聊到了 James Rumbaugh 及 CMM 等往事，乾脆把十年前的舊文找出來回味一下。

呼！真的整整十年了……當年，怎麼寫得出如此累贅但意氣風發的文字呢？這亦狂亦俠的心境，或許已遠去不復返……

為存其真，以下僅調整版面及修改一個別字，其餘文字照錄。

---

• 題目：無責任書評──很物件導向的書評
• 本文最後定稿日：1995-02-16
• 首刊於 1995-05《PC Magazine 中文版》雜誌。

　　「咦，我長這麼大，只在二月份看過很『模組化』的資訊遊俠列傳，還沒看過很『物件導向』的文章呢！」罪過罪過！諸位看到篇名，千萬不要誤會這篇書評有多麼的物件導向，我的原意是：引介一些很物件導向的資訊給各位。物件導向的是欲介紹的書籍，而不是介紹的文字本身；差之毫釐失之千里，不可不察也。

　　數月前〈C++ 面面觀〉一文，同窗看了之後，怪我了無新意，篇名取得太爛，所以這回換個較聳人聽聞的。曾xx，滿意了吧？

　　「你為什麼要介紹這些東西呢？C++ 的書籍不就夠用了嗎？」其實是不夠的。幾乎所有把玩一陣子 C++，或是其他物件導向語言的人，都會碰到一個瓶頸：「我看過很多 OOP 的書，但臨到寫程式時，卻仍有無處下箸之感。」屢戰屢敗之後，就有人開始抱怨、自暴自棄、對 OO 說抱歉了。

　　為什麼會這樣呢？那是因為基本概念並不穩固。

　　其他領域中，理想與現實可能會有較大落差，但是 OO 基本上就是滿實務導向的東西，不像其他的，如 LISP 之類的 functional programming 有 lambda calculus 的理論背景，如 PROLOG 之類的 logical programming 有數理邏輯的背景。OO 到目前為止，根本就沒有像它們一樣有這麼深刻的數學理論背景（雖然有人在從事 OO-lambda 等等的嘗試），所以概念和實踐的距離相當短。而且 OO 還號稱是最自然、最切近萬物本性呢！

　　那為什麼還是會有落差之感？這種「基本概念不穩固」的現象是程式語言入門書造成的。回想一下：當您與 C 為伍、初學結構化程式設計時，還不是會有那種「語法都會了，卻依然寫不出像樣的程式」之歎？原因何在？因為入門書籍是定位在「教會你語法工具」而已，而不在於「賦予你獨立闖蕩江湖的能力」。想要有這種能力，除了多思考、多觀摩、多練習、累積經驗這些老生常談之外，還有兩項修練：一方面得學習資料結構、演算法，以厚植學養；另一方面也得跨出寫程式的黑手層次，邁入軟體工程的領域，學會完整的軟體生命週期理論，像需求分析﹑系統分析﹑系統設計﹑程式撰寫﹑測試等等，兩方面齊頭並進，才能掌握理論與實務。

　　物件導向亦如是。

　　我不是在怪罪語言入門書，它們有特定的讀者定位及使命。我只是闡述一個觀念：您想要目窮千里的話，不更上一層樓是不行的。希望底下所提的，能做為您拾級而上的階梯。

　　這回引介的，是與物件導向方法論有關的書籍，沒有 C++ 或其他物件導向語言的基礎也無妨（老話一句：您可以平行處理），有了的話會吸收得更快。至於前面提到的資料結構、演算法之類的，大都屬於教科書，可能不適合在此地提出來（而且冼鏡光老師是更理想的人選）。真有這個需要的話，再說吧。

　　這篇書評著實不好下手。怎麼說呢？如我上回所述，因為物件導向方法論這個領域還很新，還沒有「罷黜百家，獨尊儒術」的共識，所以成天有一堆新學說出爐，大家都企圖及早卡位，取得正統的地位，就像某黨大老們紛紛表態爭取黨內總統候選人提名一樣。我也不是三頭六臂，每一本都熟讀過。不過我倒樂於效法該黨嘍嘍們紛紛揣摩上意壓寶拱豬之舉，挑出我認為最具潛力的、欲突破瓶頸的朋友最值得研究的，對它們做一番導覽。若您還意猶未盡，想再接觸其他遺珠的話，請參考這些書所列的數不清的參考文獻，或是 Internet 的 comp.object FAQ 所附的書單，洋洋灑灑列了近八十本，夠您享用了吧！

　　附帶一提：某位仁兄正在翻譯這份 FAQ，當您看到這篇書評時。祝他早日完成這項據我所知並不容易的工作。

---

作者：James Rumbaugh, etc.
書名：Object-Oriented Modeling and Design
章節：
　　　　 1. Introduction

　　　‧ Part 1: Modeling Concepts
　　　　 2. Modeling as a Design Technique
　　　　 3. Object Modeling
　　　　 4. Advanced Object Modeling
　　　　 5. Dynamic Modeling
　　　　 6. Functional Modeling

　　　‧ Part 2: Design Methodology
　　　　 7. Methodology Preview
　　　　 8. Analysis
　　　　 9. System Design
　　　　 10. Object Design
　　　　 11. Methodology Summary
　　　　 12. Comparison of Methodologies

　　　‧ Part 3: Implementation
　　　　 13. From Design to Implementation
　　　　 14. Programming Style
　　　　 15. Object-Oriented Languages
　　　　 16. Non-Object-Oriented Languages
　　　　 17. Relational Databases

　　　‧ Part 4: Applications
　　　　 18. Object Diagram Compiler
　　　　 19. Computer Animation
　　　　 20. Electrical Distribution Design System
————————————————–

　　不知道各位對舊書有何看法？上回我介紹的第一本 C++ 爸爸的聖經本，對極度喜新厭舊的人來說，可算屆齡中古了，科技用書的半衰期又比四書五經短上許多，蠻擔心讀者會來信抗議。所幸沒有，且據說該書還曾一度缺貨呢（不知小弟我有沒有引薦的功勞或苦勞）！所以這回再介紹一本「中古書」。請放心，一本能被許多書籍論文參考引用的文獻，肯定會比店頭展示空間保衛戰的常勝軍來得有價值。在媚俗的後現代，這兩項指標不見得是若且唯若、能直接劃上等號的；「內行看門道，外行看熱鬧」，我是寧受一時之寂寞的。

　　這本書由五位通用電氣研發中心工程師所撰，以他們浸淫 OO 系統多年的經驗，融合行之有年的傳統方法與後勢看好的物件觀念之特長，提出了一套 OMT (Object Modeling Technique) 方法論。幾年下來，儘管新學說不斷出現，它仍然屹立不搖，研究 OO 的人，大概很少沒看過這本書的。

　　或許是作者們的背景使然，這本書較偏向於實務層面，不過，一般人應具備的基礎理論也無一或缺，較能接受吸收。所以，“Don’t Fear!”（天主教宗若望保祿二世就職大典時的名言）拿這本書做為「跨越希望的門檻」，有我的道理在，看了後面的介紹便知。嗯，最重要的一點是：就是這本書讓我對 OO 品嘗出一點點心得，對它一直有股感恩之情，總是希望有更多朋友認識它，一齊跨越希望的門檻（對不起，我實在太喜歡教宗的這本書了，書名更是一級棒，嘿，要學起來）。

　　整本書分成四大部份：第一部份介紹他們這套 OMT 方法論的基本觀念，做為後續內容的基礎；第二部份將這些觀念應用到軟體生命週期中，讓中大型系統的發展有可資依循的步驟；第三部份談到程式設計的細節，這大概是一般人最熟悉也最感興趣的部份；第四部份則以三個作者從事的中型個案做為 OMT 應用的實例，以證明他們不是紙上談兵。

　　第一章簡單介紹物件導向的概念，以及全書的組織大要。對物件的四個要素：個體識別性 (identity)、分類性 (classification)、多型 (polymorphism)、繼承 (inheritance)，對物件導向的幾個優點：抽象化 (abstraction)、封裝性 (encapsulation)、資料與行為合一、共享軟體元件、穩固性等等，也都有扼要的說明。

　　但是要注意：並不是非得「同時」滿足這些要素，才算得上是 OO 的程式，而是要考查該問題是不是很自然地就該用這些要素來實現。千萬不能為賦新詞強說愁，硬把這些特性強加入程式中，那就物極必反了。還記得上回提過的「繼承發燒症」現象嗎？

　　第二章開始介紹 OMT 的核心技術：建立模型。

　　各位發展軟體時，是不是一拿到問題，就開始在螢幕鍵盤前埋頭苦幹，一行行程式碼就不可扼抑，行於所當行、止於所不可不止？小程式或許還可以，但是大一點的複雜系統，如果還能這樣做的話，恐怕只能用天才來形容您了。

　　建築師不會一下子就蓋房子，他們會先起草藍圖；電機工程師不會一下子就佈電路，他們會先畫模組方塊圖；軍事將領不會貿然開戰，他們會先做兵棋沙盤推演。那為什麼寫軟體不像他們一樣？難道軟體生產比較單純，不必做事前的模擬與規劃？孫子兵法把〈始計篇〉擺在第一，不是沒有道理的。因此，幾乎所有的 OO 方法論，一開始都是建立模型，將所要解決的問題轉換成一定的規格，一方面讓終端用戶與系統分析師有共通的溝通基礎，以利於釐清問題、確定需求；一方面也讓系統設計人員有可供測試、評估、精鍊的樣板，並確定程式設計的目標。

　　「我從不用這種麻煩的方法，也寫出不少大程式呀！」有兩種可能，其一：您眼中的樑木，可能只是別人眼中的木屑；其二：國父曾說人類天賦才能有三，您或許就是先知先覺的發明家。

　　那麼到底需要哪些模型呢？這回我所介紹的第三本書第五章曾提到，一般說來，系統有三個層面的複雜度：資料、時間及功能。不同系統有不同的偏重角度，任何軟體方法論，必須對這三種模式提供完全的解決方案，才稱得上完整。所以，OMT 以物件模型 (object model)、動態模型 (dynamic model)、功能模型 (functional model) 三者，一一對應到那三個層面。本書第三到第六章，就分別介紹這些模型。

　　物件模型，顧名思義，是用來表達物件的，也是 OO 之所以為 OO 的根據。這裡面最基本的元素就是物件和類別，它們都有內部屬性及外部行為，可用來代表真實世界或虛擬環境的個體。如同現實世界一樣，物件與物件之間會有種種關連，除了最一般化的 relationship 之外，還有舊人類熟悉的聚集結構、OO 新人類成天掛在嘴邊的繼承了。藉由這些東西，可以捕捉（幾乎）任何系統的靜態結構。OMT 提供了一套圖形表示法，讓您能夠以圖形來思考、溝通，甚至不必親自動筆，現成的 CASE 工具就能處理這些瑣事，這已是軟體界普遍的趨勢。

　　如果您有資料庫基本概念的話，是否對這些物件模型似曾相識？沒錯！它們正是 ER model、ER diagram 的進一步延伸，事實上，資料庫也開始融入物件觀念，也有種種的 ER 變種。所以，從資料庫背景來進入 OO，理應不難；反之亦然，像我就是。

　　剛才提過，這本書較偏實務，所以對 OO 沒有比較形上一點的討論，等介紹第二本書時再談吧。

　　動態模型，是用來表達系統的依時行為。一般說來，系統的狀態，會隨著內在或外在的事件而改變，而且不論同步與否，都是和時間相關的。因此狀態、事件和時序，就足以捕捉系統的動態行為。OMT 採用狀態圖 (state diagram) 來表達動態模型，很明顯的，這是離散數學的有限狀態機 (FSM)、數位邏輯的狀態轉移圖、時序圖的延伸應用。

　　功能模型，是用來表達系統所欲呈現的功能。以資料處理的本質來看，計算系統就是透過內在功能函數，把輸入轉換成合適的輸出。將適當的輸入與輸出子系統相互串接，就可組合出想要的計算功能。因此，OMT 採用了在傳統結構化方法論已發展成熟的資料流程圖 (DFD) 做為它的功能模型。

　　這三個模型，等於是以三個正交的角度，來審視我們所面對的問題。學習時，應著眼於它們的內涵，而不是它們的圖形表示法；能解決軟體危機的是 OO 的本質，而不是它的圖形，切忌捨本逐末。認清了這點，就不會被各家各派的畫法所迷惑了。

　　有了 OMT 基本概念之後，第七到第十一章提出可行的步驟，將上述三個模型應用到軟體發展的分析與設計上，第十二章則將 OMT 與其他傳統的方法論做一番比較。

　　OMT 的「系統分析」階段，目標是透過三種系統模型，以及資料字典的定義，將欲解決問題的輪廓勾勒出來，以利於進一步的處理。接下來是「系統設計」階段，將系統模型分解成一個個子系統，分析各子系統間的相依關係，並對軟硬體系統資源做統合規劃，可說是對電腦相關的架構事項做高階的決策。接下來的「物件設計」階段，開始對前面的模型及決策做細部處理，所有資料結構、演算法、最佳化等等的細部決策，都在這裡實施。要注意的是：以上這些步驟都是和程式語言相獨立的，程式撰寫的細節應該留到下一個階段才考慮，才能保持系統規劃作業的純粹性，才不會限制將來的發展可能。

　　傳統的結構化方法論裡，系統分析和系統設計是截然不同的，前一個階段的輸出，必須經過一番轉換，才能做為下一個階段的輸入，所以兩者之間有很大的鴻溝。這種有如瀑布般的發展過程，一旦上游規格定案了，再回頭修改可是戛戛乎其難哉！這正是傳統方法的主要缺陷之一。新的 OO 則在程式語言層次，就已經對現實世界做相當程度的模擬對應，所以它能以一套一致性的模型、相同的溝通語言，從系統分析到程式撰寫一路沿用到底，不必再透過額外的轉換手續，頂多在過程中層層精鍊模型罷了。也正由於 OO 的這種特性，使各步驟之間的界限較為 fuzzy，可逆性也較高，軟體生產方式不再受限於傳統的瀑布模式，遞增式、螺旋式、原型式等理念較易實現。

　　如此一來，越後期的生產步驟越顯得順理成章、理所當然，極端一點的情形，甚至一看到系統分析的結果就可以開始寫程式了；但相對的，系統分析的角色便加重許多。某方面來說，這並不算是壞事，反而更能藉著深入分析問題，讓軟體更能反映問題，再配合 OO 的穩固性、可重用性，軟體將有更長的壽命。所以這回我所介紹的第三本書第二章就曾說：「我們應該對分析、設計、企業策略方面的問題，付出比對程式撰寫問題更多的關心。」

　　第十三章開始，正式介紹程式設計的細節。

　　不要以為 OOP 是萬靈丹，一吃就靈，要是亂用的話，空有九陽真經也打不過滅絕師太。所以第十四章提出些程式設計的原則，使得OOP 的特點：可重用性、擴充性、穩固性、可大可小，能夠正確地發揮出來。第十五、十六章，將 OO 的各種元素分別以物件導向及非物件導向語言實作出來。可能很多人會驚訝：「用非 OO 的語言也能寫出 OO 的程式？」但不要忘了：主流的物件導向語言也是由傳統語言演進過來的，都是植基於 “imperative” 這個族系，因此兩者的功能是等價的，只不過一個可以走捷徑，一個得繞遠路罷了；就好比沒有人能說您用組合語言，寫不出 C++、MFC、OWL 這些東西一樣。

　　第十七章介紹 OMT 於資料庫系統的應用，可惜的是，它只談到關連式資料庫系統，而沒談到物件導向式的，或許是當時的研究成果有限吧。所以這兒多半是早已熟知的正規化、ER model 轉換成關連表格之類的技巧，沒什麼新義，有點失望。沒學過資料庫的人，更懷疑這短短的一章能帶給他們什麼。

　　第十八章到二十章，分別以三則中型案例：物件圖形編譯器、三維空間動畫系統、電氣配置系統，做為 OMT 方法論的應用，相當值得一讀，照著流程一路走下來，會有不少收穫。如果能把各章的習題，與這三則案例好好研究一遍，對 OO 應該就不會有茫茫然之感。

　　從上面的介紹可看出：OMT 將許多行之有年的技術整合在內，對已熟悉傳統方法的人而言，會有如魚得水之感，可減少典範轉移 (paradigm shift) 的陣痛。而且書中到處都有作者提供的寶貴經驗，入門者較不會有歧路亡羊之惑。我認為這是它最大的優點。

　　不過 Object-Oriented Development: The Fusion Method 一書認為：OMT 方法論的三個模型過於分散，整合性不夠，沒有確保「三位一體」的機制，又過於依賴經驗法則，較不符工業生產線的制度化要求。但它的 OOA 頗有價值，所以 Fusion 方法論的 OOA 採用了一部份 OMT的觀點。

　　幾年下來，Rumbaugh 不斷在 Object Magazine 等期刊上發表新的看法，所以一直有風聲說這本書會出新版，可是某年某月的某一天，這位老兄投奔 Booch（下一本書的作者）所在的公司 Rational 了，不太樂觀。近年來 OO 界的新進展，本書亦弗如。所以科技狂熱者，若想從比較新的角度來看 OO 的話，不妨參考下面要為您介紹的書。

背景資料：

• 書名：Object-Oriented Modeling and Design.
• 作者：James Rumbaugh, Michael Blaha, William Premerlani, Frederick Eddy, William Lorensen.
• Prentice-Hall. 1991. ISBN 0-13-630054-5.
• 20 章，500 頁。

---

作者：Grady Booch
書名：Object-Oriented Analysis and Design with Applications, 2nd Edition.
章節：
　　　‧ Section 1: Concepts
　　　　 1. Complexity
　　　　 2. The Object Model
　　　　 3. Classes and Objects
　　　　 4. Classification

　　　‧ Section 2: The Method
　　　　 5. The Notation
　　　　 6. The Process
　　　　 7. Pragmatics

　　　‧ Section 3: Applications
　　　　 8. Data Acquisition: Weather Monitoring Station
　　　　 9. Frameworks: Foundation Class Library
　　　　 10. Client/Server Computing: Inventory Tracking
　　　　 11. Artificial Intelligence: Cryptanalysis
　　　　 12. Command and Control: Traffic Management
————————————————–

　　這本書已經是第二版了。它的前一版 Object-Oriented Design with Applications 是 1991 年出的，也是在 OOD 領域中「被引用次數」的佼佼者，不輸給上一本 OMT 的書，C++ 的爸爸就曾對它讚譽有加：「這是到目前為止唯一可觀的 OOD 書籍！」

　　作者 Booch 是位傳奇人物，以前對 Ada 語言貢獻良多，對軟體工程亦頗有建樹，後來卻一頭栽入 OO 領域，成為 OO 的先驅，還以一套物件程式庫 “C++ Booch Components” 賺到了名（把自己的大名放在產品上，連 Bill Gates、Steve Jobs 都未曾有呢，大概只有 Peter Norton 與他相互輝映），賺到了金錢也就不在話下了。學理與實務兼具的背景，也充份反映在這本書裡。

　　物件導向系統進展得太快了，稍一不慎就得大歎「廉頗老矣」。所以三年下來，隨著 Booch 他經驗的累積，並不斷吸收其他後起之秀的優點，終於改了書名，加了兩個英文字－－喔，這不是重點，重點是：它的廣度及深度都增加了，對物件系統涵蓋得更完整也更周延了。手頭有舊版的朋友趕快去買新版，絕對值得。可惜的是：書本不像軟體有昇級優惠。

　　和其他書比起來，它的學術味重了一點兒，用字比較考究，旁徵博引的程度令人咋舌，單從前一版的 46 頁到這一版整整 58 頁的參考書目便不難看出。這種書頗合我的胃口，看一本書，可以多翻好幾回字典，多學幾個術語，多懂幾個典故，一舉數得，有如孔子對詩經的評語。不敢奢求諸位有和我一樣的雅好，所以把它列在第二順位介紹，不過這不代表它比較差喲！如果這方面的書只能選一本，我會選它。

　　本來想再介紹一本 Robert Martin 所寫、Prentice-Hall 出版的 Designing Object-Oriented C++ Applications Using the Booch Method 這本書，將 Booch 這套方法論（俗稱為 “the Booch method”）實際應用在 C++ 程式設計上，應該能為那些基礎不足的人，縮短理論與實作之間的鴻溝。可惜自去年十一月在 Internet 看到他提供的消息起，截至我寫這篇書評為止，書都還沒進口。只有等以後再說了。

　　全書分成三大部份：第一部份介紹 OO 的基本概念，十分詳盡，我還沒見過比它更精彩的，徹底消化吸收後，做一番專題演講、說服死硬派幡然來歸，皆易如反掌；第二部份介紹 Booch 這套方法論，一一臚列各步驟及注意事項；第三部份則是五則中型應用實例，佔了近半本書的篇幅。

　　本書第一章就點出軟體生產的本質：複雜。

　　為什麼會有 OO 理念的動機？傳統方法不就夠用了嗎？那是因為我們面臨更複雜的軟體，傳統方法力有未逮，產生新的軟體危機，才促使人們找尋更好的方法，而 OO 正是目前所知最好的解決方案。那為什麼軟體會這麼複雜呢？一言以蔽之：因為這個婆娑世界本來就是複雜的！

　　本章開頭提到一則發人深省的笑話。醫生說：「舊約記載，上帝取出亞當的肋骨製造了夏娃，這是外科手術，所以醫生是最古老的行業。」土木工程師反駁：「更早以前，上帝自混沌中創造了天地，這是土木工程，所以我們才是最古老的。」電腦科學家就笑著說：「那麼，是誰創造了混沌呢？」

　　那麼，是否複雜就是我們的原罪呢？雖然如此，但是深入觀察各種複雜系統，就可看出混沌中另有秩序。天下譯的《複雜》、牛頓譯的《渾沌魔鏡》都提到，在物理、生物、社會組織……各種複雜系統中，基本元素與法則都很簡單（或是說：相對起來較為簡單），複雜是存在於系統各元素間無數可能的合作互動方式之中。他們更發現到：藉由正向回饋、報酬遞增、非線性效應、適應性演化、突現行為這些不同學域裡都有的類似效應，造成千變萬化的世界。

　　從上述的複雜系統本質可知：如果我們還像過去一樣，將軟體系統建構在「它所要表現的功能」這種變異性最大的變因上，猶如夸父追日，難以有效反應需求的增加、功能的變動、軟體的成長，系統自然無法穩固，只有終日隨複雜起舞。反之，在 OO 眼中，世界是由物件構成的（不要問我這算不算唯物論），物件與物件之間有關連、有互動，並藉此產生組織與系統的整體行為。如果我們的軟體系統建構在這種物件模型的基礎上，不僅較自然，也更為穩固。正如 Bertrand Meyer 所說：「這正是物件導向的智慧。」

　　Booch 從電腦系統、動植物組織、近代物理、心理學、社會組織等領域，找出一堆佐證這種觀點的學理，甚至還遠溯至古希臘哲學家赫拉克利圖斯和德謨克利圖斯的唯心唯物論，真佩服他的博學與熱誠。總之，他就是要告訴您：以 OO 角度來發展軟體，是最符合萬物內在脈絡的，如同庖丁解牛一般，能自然又有效地處理軟體系統的複雜度。

　　第二章從比較巨觀的角度，介紹物件模型的演進及特性。從物件模型的主要要素：抽象化、封裝性、模組化、階層組織，以及次要要素：型別系統、並行性、持續性 (persistence) 看來，這些都是電腦科學界早就熟知的原則，只不過今天物件模型總其大成，畢其功於一役。Booch 又不厭其煩地列出幾個可考的學術領域：硬體與作業系統、程式語言、軟體設計理念、資料庫模型、人工智慧、認知心理學，各從不同角度啟發了物件觀。所以我一直很贊同 Objective-C 爸爸 Cox 對於物件觀的說法：“evolution, not revolution”。

　　有時我們會發現，不同作者對物件模型有不同的定義，其實核心理念及要素多半可互通，只是名詞涵攝性不同、強調之處不同而已。

　　第三章從比較微觀的角度，用圖形和程式例子，詳細介紹 OO 的主角：物件與類別，以及它們之間種種的靜態和互動關係。

　　許多人聽了一堆 OO 的廣告詞，覺得蠻有道理的，興致勃勃躍躍欲試，可是不久就會遇到一大問題：「到底我要挑出哪些物件與類別呀？到底有哪些東西能讓我挑呀？」不要緊張，不只你有過這種疑惑！這就是第四章的主題：分類。

　　不要小看這問題，它可是哲學中「知識論」的主題之一，以 Booch 列的書目來看，早在柏拉圖的《政治家》、亞里斯多德的《工具書：範疇論》等典籍，對概念、共相、殊相、範疇、實體、屬性這些東西，就已有深入的探討。此外還有……喔，不能再寫下去了，否則會變成《哲學傳真雜誌》。

　　回到軟體上。分類的理論，可說是各門派的殺戮戰場，作者在此也使出渾身解數，包羅諸家學說、提出自己的看法。可是大家要知道：一流的軟體是科技與藝術的結晶，固然可找出不少科學般明確的反應方程式，但更多地方需要敏銳的藝術心靈來雕琢。「分類」應用之妙存乎一心，沒有標準答案，偏偏它又是物件系統的根本，所以本章要用「心」體會，還要佐以經驗的增長。

　　講了那麼多學理，第五章開始，正式介紹這套方法論的圖示模型。作者的這套圖示法，向有「包羅萬象」之譽，表現力比其他方法論來得豐富，幾乎涵蓋了物件系統的各種層面。我最喜歡他的圖形了，十分靈動，不像其他人的那麼匠氣。可惜上一版的稍嫌繁複，易使人卻步，所以這回他一方面保留以前的優點，一方面也吸收他人的長處、簡化圖形、加強一致性，讓它更容易學習。

　　作者以邏輯上與實體上、靜態與動態的角度來考量系統，提出了四個主要模型：類別圖、物件圖、模組圖、處理器配置圖，提出了兩個次要模型：狀態轉移圖、交互作用圖。從這麼多視角來審視待解決的問題，無怪乎要包羅萬象、表現力強了。

　　第六章介紹這套方法論的應用程序。作者將生產過程分成兩部份：微觀與巨觀。微觀的角度，是以反覆式的流程，找出系統的物件與類別、彼此之間的關係，並賦予它們實質的意義。巨觀的角度，是以較為循序的流程，側重於專案的管理與控制，對專案做分析、設計、調整、程式撰寫、維護。

　　第七章說明種種 OO 技術應用的課題。對大型專案而言，不光是知道上面這些東西就夠了，還須考量許多軟體工程的議題，沒留意的話，再先進的科技也只是美麗的錯誤罷了。這一章，作者談到專案管理、重用性、內部文件、輔助開發工具、再教育、品管、評估等等，都是較高階的人員該照顧好的管理項目。對它們有興趣的話，請再參考我要介紹的下一本書。

　　學了 OO 概念後，不少人會問：「它適用於哪種場合？」說實在的，很難回答，就像你去問畫家：「水彩適合畫哪些物體？」就像你去問音樂家：「鋼琴適合演奏哪些音樂？」你能期望有個簡單的答案嗎？我只能建議你：在你還沒有能力判斷它適用場合之前，最好各種可能性都去嘗試，這樣才知道自己的盲點，才知道該如何補強，對 OO 的限制也較能體會。

　　當然啦！純 OO 信徒會信誓旦旦的說：到目前為止，我還沒碰到不適用的場合。Booch 似乎就是這種人，硬是要秀給你看，本書上一版的第三部份，他就端出一道豐盛大餐：

乖乖，不僅主題廣泛，連使用的語言也一籮筐，好像是想向您證明：他的方法論不但適用於各種領域，更適用於各種語言！讓我又不由得佩服起他的博學了。所幸他大發慈悲，這一版只用 C++ 一種語言，善哉善哉！

　　不過他可沒換湯不換藥，這回端出的可是滿漢全席：第八章改成氣象觀測站系統，第九章改成建構一個 container class library，第十章則改成主從式庫存管理系統，個個燙手。這麼多類型，為了避免讀者們大歎「五色令人目盲」，我只挑出第九章來談，這也是一般人最感興趣的。

　　什麼叫 container class library？如果還不健忘的話，上回我提到的那些中文英文書都有這些主題。簡單的說，就是一些常用資料結構的集合體，如堆疊、佇列、連結串列、樹、圖、集合、雜湊表等等。異於傳統的是，它是以 OO 方式架構起來的，有什麼優點自不待多言。有經驗的程式設計師都知道，幾乎大一點的程式，骨子裡都離不開這些資料結構，所以 OO 使用者，總是在尋找或創造更好的 container class library，像是 BC++ 附的 BIDS、前面提到的 Booch Components、已成為 C++ 標準的 STL，都是這類的佼佼者。

　　想對 OOP 有點「感覺」的，我常建議他們碰碰資料結構的題材，一方面這是玩家升格為專家必經的課程，一方面可藉資料結構的課題體會 OO 的實作。像是 container class，就是個標準的 OOP 練功題，許多 OOP 的概念都能自然地應用上去。以本章來說，等於是以 Booch 為名的那個產品的迷你版，內容堪稱詳盡，不僅學到了觀念，對這套頗獲業界好評的類別程式庫是如何組織起來的，也有番清晰的體認。

　　這本書在闡明抽象觀念時，時有和主題相關、將概念具象化、又易引人會心一笑的漫畫，水準相當高。「物件導向的貓」是 OO 界習用的雙關語、反諷語，Booch 本人也養了許多貓，在這本談 OO 的書裡頭自然少不了這種很 OO 的動物。讓它不只是一本枯燥的技術性書籍，Tony Hall 的巧筆居功厥偉。或許這篇很物件導向的書評該請加菲貓當特別來賓？

　　講到漫畫，不禁想起一則過猶不及的案例。微軟的 Writing Solid Code 一書，此間中譯本譯得不錯，還替原著加了點綴：每頁都有佔正文五分之一篇幅的漫畫，每一章換一種。姑不論出發點，咱們就事論事。千篇一律的漫畫與文章內容無啥關聯，沒有輔佐詮釋的作用；且多了漫畫，篇幅加倍，你還能指望價格不變嗎？借用一下 OO 的貓吧：貓毛可是出在貓身上的！

背景資料：

• 書名：Object-Oriented Analysis and Design with Applications, 2nd Edition.
• 作者：Grady Booch.
• Benjamin/Cummings. 1994. ISBN 0-8053-5340-2.
• 12 章，589 頁。

---

作者：Edward Yourdon
書名：Decline & Fall of the American Programmer
章節：1. Introduction
　　　2. The Lure of the Silver Bullet
　　　3. Peopleware
　　　4. Software Process
　　　5. Software Methodologies
　　　6. CASE
　　　7. Software Metrics
　　　8. Software Quality Assurance
　　　9. Software Reusability
　　　10. Software Reengineering
　　　11. Future Trends
————————————————–

　　Edward Yourdon，哇，又是位大師級人物。他是八十年代結構化方法論的要角，這領域的文獻常有他的大名；他成立了訓練諮詢機構，是位世界級的知名顧問；Prentice-Hall 旗下的 “Yourdon Press Computing Series” 包辦許多軟體工程的名著。更難得的是：近年來還寫了 OO 三書：OOA、OOD、OO System Design，頗獲好評，真不簡單。

　　不過這回我不是要介紹他的 OOA/OOD，而是他對軟體工業的深入檢視，和對軟體科技的前瞻觀點。對這些都不感興趣的話，那麼底下這段序言，或可留住您的視線：「就算沒別的貢獻，這本書對於那些整天夢想將擁有一份軟體界的終生工作，陶醉在沒有裁員及外求人才問題之幻想中的學生而言，不啻為當頭棒喝。」

　　書名有 “decline” 的，通常都很有份量，像本世紀初 Oswald Spengler 的 The Decline of the West，名列影響二十世紀名著之林。Yourdon 這本書，第一章就以一則預言來吸引大家的注意：「美國的程式設計師將面臨和已絕種的渡渡鳥相同的命運，就像我們曾引以為傲的汽車工業一樣。」

　　他列舉了許多事實支持這項驚世駭俗的論點，歸納起來，可分為內外兩大因素。內在因素可多著呢：再教育缺乏、管理不善、品質不良、生產力低落、成本高漲等等，導致的結果自然顯而易見。就以最常被消遣的微軟為例，VC++ 2.0 成為吃記憶體的怪物，Windows 95 成了典型的 vaporware，偏偏兩者都不是技術領先者，都早有更好的同級產品，成為眾矢之的也就不足為奇。外在的因素則來自開發中國家，他們有足夠的教育，有吸收英文資訊的能力，有向上的企圖心，工資又低廉，所以比美國更有競爭力，後來居上並非不可能。

　　不過大家不要沾沾自喜，以為美國就此完了，彼可趁機取而代之。要知道：「過則勿憚改」，有 bug 並不可恥，有 bug 卻看不到才叫可憐；最悲哀的是：明明知道有 bug 了，卻還裝作沒有 bug，面不改色地蓋上正字標記。去年底的 Pentium 事件、台北捷運、正副議長賄選，今年的衛爾康西餐廳大火，才真算是台灣人的悲哀。拿這本書看看美國，想想自己，別人的過去式現在式，可能就是我們的未來式，可不慎乎？

　　Yourdon 可不只是軟體病理家而已，他還是位軟體生理家，在第二章裡，列了一些起沈痾的藥方，並帶起後續幾章的主題。他認為：只要能掌握這些科技，你就能享受十倍的改善成果，成為世界級的軟體機構。

　　第三章很有趣，他在 CompuServe 加值網路中，對程式設計師廣發英雄帖：「如果你有機會和公司資深經理會談一小時，你的意見也會受到重視，那麼你會把哪些基層苦幹人員的心聲反應出來？」兩個禮拜以內，收到了一堆 “I Want…”、“I Don’t Want…”，閱畢，感慨萬千。

　　大家都知道：高科技產業裡，人力資源是最重要的。可是當你聽到一堆這種抱怨：「告訴他們學習做個領導者，而不是獨裁者，並且把我們當成人而不是零件。公司以『人員是最重要的資源』為格言，但『資源』卻是指用來徹底壓榨的東西。」你就能體會作者先前的預言不是沒有道理的。本章裡，他以多年顧問的經驗，提出許多人性化管理的建議，以期從根本改善人力配備，生產力也才能提升。

　　第四章介紹企業成熟度的觀念。許多人有鴻鵠之志，想一口氣引進所有最先進的軟硬體設備及技術，企圖來個大躍進、一步登天。不幸的是，「成熟度」多半是文化問題，需要扎實的體質適應與轉化過程，越級發展往往徒勞無功。卡內基‧美濃大學軟體工程學會 (SEI)，就曾針對軟體發展的特徵，提出一套 CMM (Capability Maturity Model) 評估標準，以五個成熟度階段定位企業體。從混亂到井井有條，各階段都有各階段的特徵，企業體就可先據此自我定位，將他們所該改善的事務排定輕重緩急的優先順序。缺乏這種認知，較低層級的公司就可能將大筆金錢投資在昂貴的工具上，最後卻只有將它束諸高閣，因為沒有人會用它，又沒有人願意背負當初決策錯誤、勞民傷財的罪名。

　　作者講的雖然是軟體企業體，對個人也一併適用。許多人認為成功是即溶品，大眾傳播媒體的一堆傳奇報導，更讓他們深信「有為者亦若是」。我要澆盆冷水。就我所知，只有兩種人能行此道，第一種人是五歲就無師自通作鋼琴協奏曲的莫札特，但也別忘了他日後無數的苦練，您能嗎？第二種人則平凡如你我，只是他們真積力久，內涵飽滿充實，「君子務本，本立而道生」，學新事物自然快些。須知學習無法躐等以進。不要驚訝張無忌數個時辰就學會乾坤大挪移，莫忘他有九陽真經為底；輕輕鬆鬆快快樂樂速成九陰真經的背後，可能只學到九陰白骨爪。您想當梅超風或周芷若嗎？

　　第五章檢視幾種著名的軟體方法論，不僅指出傳統方法的缺失，也對時下風行的加以批評，處處充滿真知灼見，值得頑固的守舊派與冒進的激進派好好思索。有時停下腳步，回顧所來徑，也蠻不錯的。這是我最喜歡的一章。

　　第六章講到 CASE 系統，也就是電腦輔助軟體工程系統。程式設計師終日為其他行業的自動化而努力，他們卻很少將自己的工作自動化，還是鎮日與紙筆為伍、手工打造每一行程式碼，很諷刺吧！於是 80 年代中期起，軟體界開始為自己著想了，試著將軟體生產過程納入電腦自動化。一般人有種誤解，以為 CASE 只是畫一堆圖表的工具、只是程式產生器而已，這種認知過於狹隘。事實上，它的範圍應該涵蓋整個軟體生命週期。本章裡作者介紹了 CASE 的沿革和重要特徵，評估產品的持平角度，說明該如何實施它，該如何讓各階層人士接受它的觀念，最後再談到它未來可能的發展。

　　第七章談到軟體評估。藉由客觀的評估制度，像是軟體規模、良率、生產力、顧客反應、軟體工具、生產程序等，你才能掌握軟體生產的狀況，才有量化的指標，做為改進的參考依據，這和各機關內部打考績的作用是一樣的。

　　第八章談到軟體品質保證。顧名可思義，重要性也人盡皆知，可是做起來還真不容易！現在普遍的趨勢是：利用數學味濃厚的 formal method 來作證明。這領域還有待開墾。

　　第九章介紹軟體再使用，第十章介紹軟體再生。兩者很像，只不過前者著重於未雨綢繆，在開發新軟體時，就得考量未來再使用的可能；後者則是收拾殘局，在維護老舊系統時，設法以新科技予以重生，使它消極的可以繼續存活下來，積極的可以改頭換面，成為新系統的養料。它們也是近幾年來才開始受到重視的技術。

　　最後一章介紹些軟體界未來的趨勢，附錄Ａ以印度的軟體科技現況為例，說明開發中國家的電腦工業潛力。附錄Ｂ則提出一些作者認為成熟的從業人員必讀的、世界級軟體中心的圖書館必備的書籍，共約 90 冊。唉！我只「聽」過五分之一，只「看」過十分之一。不亦遠乎？

　　看了本書最大的收穫，應該是擴展視野，了解軟體工業的新科技，至少也對軟體工業的現況有所認識。我想這不光是對工程師重要，對學生也很重要。如果您的興趣被激發了（這也是我介紹此書的目的之一），還是該去看一看軟體工程概論的書，彼此互補。

　　這本書的中譯本《美國軟體界將面臨的衰亡》，翻譯品質很好，版面編排得當，讀起來通體暢快。這麼正面的評語，出自這麼挑剔的人之手，太不尋常、太不正常了，所以特地挑出兩個缺點。第一個是各章結尾「引用參考文獻」的英文字體，洋人學術論文的慣例是：書名、刊物名要用斜體，刊物裡的篇名用正體，但前後要加雙引號。看遍中譯本，很少有這麼細緻的，大都草草了事，所以當我看到這譯本時，眼睛為之一亮；再仔細看，原來是拿原書直接剪貼的，所以有些地方手工不巧，排得「波浪起伏」，特別是中英夾雜處，字距行距不一，英文字體也沒照規矩來了。第二個比較大的遺憾是：原著索引不見了。關於這一點，不想再提了。

　　或許真如我上回所說：國內只有教科類書才會為讀者設想得到吧。

背景資料：

• 書名：Decline & Fall of the American Programmer.
• 作者：Edward Yourdon.
• Prentice-Hall. 1992. ISBN 0-13-203670-3.
• 11 章，352 頁。
• 松崗有中譯本。

◤建議您一併閱讀以下文章：

• 中文電腦書也有復刻版
• 琳瑯滿目的孫子兵法
• 幾則關於動態型別語言的事件
• 技術對談：看 Google 怎麼用 Java
• 當 Java 遇見 PHP

著作授權方式：Creative Commons 條款。



追蹤留言回應：以 RSS 2.0 方式。
文章永久網址：
  » http://william.cswiz.org/blog/archives/2005-06-08/pcmag-bookrev2/
引用通告 (trackback)：
  » http://william.cswiz.org/blog/archives/2005-06-08/pcmag-bookrev2/trackback/


     
本站歡迎您以合乎創用CC 的方式，將文章選錄至網路書籤或社群網站，也別忘了將您寶貴的意見（尤其是延伸的評論、補充、彙整、反駁等）留言在本站。謝謝！