敏捷軟體開發：原則、樣式及實務 Agile Software Development: Principles, Patterns, and Practices ———————————– 作者／Robert C.Martin /著, 林昆穎、吳京子 /譯 出版社／碁峰 ISBN／986-154-148-9 Amazon 評鑑：五顆星

內容簡介
暢銷書作者及舉世聞名的軟體開發專家Robert C. Martin展示了當今軟體開發者、專案經理與軟體專案領導者如何解決眼前最具挑戰性的難題。這是既全面又實用的敏捷開發與極致編程的教學，由敏捷開發創始人之一所撰寫。教導軟體開發者和專案經理如何使用敏捷開發的威力，讓軟體專案如期完成又能符合預算。

* 使用真實的個案研究來展示如何運用極致編程進行規劃、測試、重整、以及搭檔編程。
* 包括豐富而可復用的C++和JavaTM程式碼。
* 專注於使用統一建模語言（UML）與設計樣式（Design Patterns）來解決以客戶為導向的系統問題。

前言

本書原著在 Amazon 評鑑是極為罕見的五顆星滿分！ 書籍也是少見的厚，有近 700 頁之多。 如此深厚的內容，可不像坊間一堆可拿來當枕頭的所謂 OOP 入門書一般，盡是充斥著圖形設定教學與程式碼，沒啥內容。 套一句 John Vissides (Design Patterns 之一作者)在引言上所推薦的：「這也許是第一本將敏捷方法 (agile methods)、樣式 (patterns)，以及現代軟體開發方法交織成連貫的整體。當 Bob Martin 開口，你最好洗耳恭聽。」 六年！ 是作者在這麼多年來所深刻體會到的軟體設計和開發經驗，而本書也可說是反應了作者自身的學習成果。

本書描述了軟體開發議程的三個主題：設計原則 (principle)、設計樣式(pattern)，與開發實務(practice)。當軟體開發人員面對的是需求快速變動時，如何具備迅速的應變能力，而表現在開發的過程中，即為敏捷性的開發；為了達成敏捷性，所以開發團隊要能有某種程度的共識以及具回饋 (feedback)的實務作法；利用專家與前人所提供的設計原則，使得軟體能具有彈性與易於維護；而如何平衡這些設計原則，所以也會瞭解到在特定一再重覆的問題上應用設計樣式。作者就是嘗試著要把這三種觀念成有一個有效的整體。 我覺得書中最大的特色就是，會藉由許多案例研究來說明與示範如何應用上述三種觀念，而且這些案例並非是最終的完成品而已，而是正在進行中的開發，所以讀者也會看到這些設計者所犯下的錯誤，然後他們又如何發現錯誤，進而改正錯誤。

軟體開發的關鍵在於人，而不是製程

本書的目錄綱要編排，正是反映了上述作者想傳達的三種觀念，所以分為六個篇幅，第一、二篇論及的是軟體開發流程的最佳實務與能符合最佳實務的敏捷設計原則；後四篇則是藉三個案例研討 (薪資、氣象臺、教育測驗服務)，如何應用設計樣式，來解決一些特定的實務問題。再來就是四個附錄。前兩個附錄算是對於 UML 的語法說明；而附錄C (兩家公司的諷斥)，挺特別的寫作方式，每一頁是個別描述兩家公司各自不同的開發方式，一個採需求凍結的瀑布開發、另一個採敏捷的反覆漸增開發。是一篇挺有趣的寓言式寫實故事；附錄D則是摘錄 Jack Reeves 的一篇論文：「原始碼即設計」。我覺得該篇論文真的可以精讀，可以引導與觸發讀者思考，什麼叫做軟體設計。

每一大篇，都可以各自拆開獨立閱讀。軟體開發人員，若想對樣式作個一般性的學習，可以閱讀敏捷的設計原則；而想知道作者是如何應用書中所介紹的設計樣式，則可以參考書內的三個案例研討；而若是專案經理甚或老闆，專心研讀第一篇關於敏捷式的開發流程，絕對會對現實的專案開發與管理的議題上，有很多的體會與啟發。

尤其一開始本書所揭露出來的敏捷軟體開發宣言，我覺得是相當務實地揭露出軟體開發的本質— 流程和技術是影響專案結構的次要原因，人方是關鍵要素。 太多老闆與專案經理們總是常會把他們總是很關心人的永續成長之類的話掛在嘴邊，但是又往往想要創造或導入出一套流程，藉由許多管理工具與各階段的製程產品，用來約束開發人員的活動。而靠一些約束與產出(通常是大量的文件)，但錯誤仍持續不斷發生時，管理人員卻又在某些地方設定更多的約束和產出 …，這種造成負回饋的循環，使得軟體人員過度負荷了龐大笨重的流程，而嚴重妨礙了完成工作的能力，並因而喪失了軟體的創意設計能力。

奉勸許多老闆與專案經理們，不能再自欺欺人了，仔細審思敏捷宣言所揭露出來的價值觀吧：
o 個人及互動勝於流程與工具。
o 可用的軟體勝於詳盡的文件。
o 與客戶合作勝於合約談判。
o 回應變更更勝於墨守計畫。

敏捷開發的主張—程式碼即為設計本身？

本書在“敏捷式的設計”一篇中，所引用自附錄D Jack Reeves 所主張的：「真正能符合工程設計標準的唯一軟體文件就是源碼的列表”。本來我還以為敏捷開發的主張是將程式碼當作是設計的一切，這我當然是無法認同，這可是會給一些程式設計人員藉口，只寫程式卻不需要有其它的設計文件。 我是一直覺得，程式碼既是設計(沒錯)，但同時也是設計最現實有效的產出 (artifacts)。而程式碼的呈現是綜合了包括多個觀點與層面的設計，諸如需求、結構，甚或架構，而這些是需要透過其它如設計圖，突顯出設計的焦點而隱藏了程式碼不必要的細節。還好，後來我很用力地研讀並思考 Reeves 論文的意涵，他應該指的是，程式碼本身就是一種設計。是的，這一點我是相當認同的，還有就是千萬不要認為 “設計就是一組與程式碼分離開來的 UML 圖示。”這麼說好了，我是一直這麼認為： UML 設計圖與程式碼都是設計，是軟體系統的一體兩面。”所以，個人一直主張，設計圖要作少、作精，不要作不必要的文件，且必然要時刻在開發的過程中保持與程式碼的一致性。

對於開發人員而言，要能看得懂本書所介紹的設計樣式，那就要先瞭解本書所揭露的設計原則，書中介紹了五種設計原則—SRP, OCP, LSP, DIP, ISP 等，全名與細節我就略過不提了。其實這些就是所謂物件導向式軟體設計的基本功與思維，諸如物件的責任分派、封裝的設計、相依性的分析、多型與介面的設計等。還有，讀者要瞭解，這些設計原則不是為了協助你把東西做出來，而是讓你消除程式碼的壞味道，設計壞味是一種症狀，是某種可以被主觀而非客觀量測的東西，會讓系統僵化而難以維護。不過適可而止就好，設計原則並非可以在系統中任意地到處噴灑的香水，過度遵從原則會導致不必要的複雜度的設計壞味。

書本雖然厚，討論的主題涵蓋也廣，但是內容還蠻淺顯易懂的，翻譯的品質也是相當不錯。每一個章節前頭又有很棒很炫的插圖，甚至還有作者引以自豪，是其女兒散佈在各章節裝飾性插圖的可愛作品。還有若是像我不是那麼珍惜書本完整性的話，甚至也可以將各篇分開拆下來，這樣外出攜帶時閱讀就不會那麼厚重。 看到如此言之有物的專業書籍，又不難懂，可以說是生命的喜樂之一。

延伸閱讀：

• {iThome 書評—15} Patterns Of Enterprise Application Architecture
• {iThome 書評—14} Business Modeling With UML: Business Patterns at Work
• {iThome 書評—12} Object Models — Strategies, Patterns, and Applications
• {iThome 書評—9} Constructing the User Interface with Statecharts
• {iThome 書評—8} Object-Oriented Analysis and Design

Patterns Of Enterprise Application Architecture ———————————– 作者／Martin Fowler /著 出版社／Addison-Wesley Professional ISBN／0321127420 Amazon 評鑑：四顆半星

內容簡介
The practice of enterprise application development has benefited from the emergence of many new enabling technologies. Multi-tiered object-oriented platforms, such as Java and .NET, have become commonplace. These new tools and technologies are capable of building powerful applications, but they are not easily implemented. Common failures in enterprise applications often occur because their developers do not understand the architectural lessons that experienced object developers have learned.

Patterns of Enterprise Application Architecture is written in direct response to the stiff challenges that face enterprise application developers. The author, noted object-oriented designer Martin Fowler, noticed that despite changes in technology–from Smalltalk to CORBA to Java to .NET–the same basic design ideas can be adapted and applied to solve common problems. With the help of an expert group of contributors, Martin distills over forty recurring solutions into patterns. The result is an indispensable handbook of solutions that are applicable to any enterprise application platform.

This book is actually two books in one. The first section is a short tutorial on developing enterprise applications, which you can read from start to finish to understand the scope of the book’s lessons. The next section, the bulk of the book, is a detailed reference to the patterns themselves. Each pattern provides usage and implementation information, as well as detailed code examples in Java or C#. The entire book is also richly illustrated with UML diagrams to further explain the concepts.

Armed with this book, you will have the knowledge necessary to make important architectural decisions about building an enterprise application and the proven patterns for use when building them.

The topics covered include:

• Dividing an enterprise application into layers
• The major approaches to organizing business logic
• An in-depth treatment of mapping between objects and relational databases
• Using Model-View-Controller to organize a Web presentation
• Handling concurrency for data that spans multiple transactions
• Designing distributed object interfaces

前言

每次研讀 Martin Fowler 的著作，直覺馬上就浮現出一個成語：天縱英才！ 從極高度抽象的「分析模式(analysis pattern)」，對程式碼實作階段時的結構重整的 「重構(refactoring)」，以及本次書評所介紹的，關於企業層級系統平台設計議題的 「企業應用架構模式 (patterns of enterprise application architecture, 簡稱 PEAA)。 我是從來沒有看過有人可以如此像他這般，務虛與務實的不同層次都能是軟體業界的第一把交椅，著作的每一本書都是鉅作，然後又能在抽象分析、平台設計、程式碼實作等各層次整理出所謂的 “模式(pattern)”，供我輩軟體人員學習並再利用於現實的軟體開發工作。 前述的這三本書每一本都蠻厚的，但是 Fowler 也能寫出薄薄的那麼一本 「UML 精華(uml distilled)」，真正道盡 UML 的本質精髓，而熱銷全球數十萬本以上。 在我的心目中，Martin Fowler 有如神人一般，可以說是引領我在軟體業界持續奮進與學習的精神導師。

不僅如此，他寫的書，總是能以很淺顯易懂的白話來解釋看起來很深奧的道理。寫到這突然讓我想起，也算是有感而發，想當初我在啟蒙軟體領域的學習時，當然也會先從國內一些所謂的名家作者的著作來研讀。 可明明就是中文字，但閱讀起來就是很吃力，本想說是不是我真的有比較笨，領悟力差。 而後先從接觸 Fowler 的中文翻譯著作(感謝高水平的翻譯)，耶！ 我看得懂啊，甚至一看再看也不覺得煩，還能讀得津津有味，每一次的重讀又有不同的體會。後來再轉而看他的原文著作，雖然多少有些英文字彙的障礙，但是真的，絕對是比國內那些寫軟工書籍的作者，輕鬆易讀太多了，可以說閱讀 Fowler 的論著，就是一種享受。後來我才逐漸體悟到，太多所謂的軟工技術人，就是常賣弄太多 IT 的專業術語，而把單純的觀念表達的很複雜；還有一點，就是不容易從文字感受到這些 IT技術人 的想法，好像內容就是東拼西湊般，沒有真正自己主觀的想法。 的確，言之有物的好書能帶軟體人員上天堂；太多艱深術語、沒有自己體悟的書籍真的會讓你下地獄。

本次書評的主角，PEAA，所涉及相關軟體設計的議題可是相當廣泛，焦點是全擺在平台面系統設計的諸多議題，包括 分層結構、O-R(Object-Relation) Mapping、WebUI 的狀態控管、多人同時上線時的交易機制處理、分散式的設計策略等。 500 多頁，書本是蠻厚的，不過內容其實不會難懂 (前面說過，作者的風格就是總能以很淺顯的白話表達某一個所討論的主題)。 因為本書真的比較厚一些，我也不可能如同書摘般來記錄每一章的重點，在這裡我是想分享一下我是如何來閱讀本書的。

從書名思考本書的核心關鍵內容，找出自己的體悟

閱讀一本書籍，我總是會先從書名開始思考，本書的核心關鍵字有三個：企業應用程式(簡稱 企業AP)、架構(architecture)、模式(pattern)。 企業AP 會有什麼樣的特性，又與一般的 Web-based AP 有何差異？ 我的心中大概就是浮現出大規模的企業AP特性有三：穩定、效能與彈性，三者缺一不可！ 而因為有這些各個構面的考量，所以在設計議題上要相當慎重嚴謹，對於開發團隊甚或客戶而言，那種整體性的架構觀是要能有共識的。再來，由於構面與涉及的各類設計議題太多，從無到有是很辛苦的，是否可以借重 “前人” 的設計經驗來應用在現實的開發上，所以，所謂的 “模式”，包括分析、設計、乃至於實作類，期能可以協助我們來解決一再重覆發生的問題。

從關鍵字去推論目前心中的一些想法，其實也沒有什麼對或錯，心中先有個底，再去研讀內容，就會比較有感覺，也可以比較一下作者與自己想法上可能是相同也有可能是不同見解的落差。 本書從大綱的編排上，是分為兩大部分，第一部份是作者稱之為 “Narratives” 的敘述，就是我所說的，Fowler 總是以閒話家常的方式，來表達出他對某些主題的主觀想法。真的是很充分表達出他的觀感，但讀者又不會覺得有壓迫感或那種不是對就是錯的二分邏輯，實在高明之至；再來就是第二部分的 "模式”，這裡如同「重構」那本書一樣，是把每一個模式先歸納在某一個大類內，然後再給予一個名字，成為所謂的模式名錄。 本書我強烈建議的是，要先看 前言與介紹 的部分，價值非凡。 從前言你可以知道作者寫這本書的動機與所要討論的主要議題為何；而介紹也算是作者的一個導讀，也是各個主題的精要解說，甚而是會讓讀者知道可以先從哪裡看起，哪些地方又可以先略過不看，事半功倍。

前言與介紹的部分真的是太精彩了，讓我是逐字細讀來品味作者的想法。Fowler 說他是一位物件導向的狂熱份子，他也不說教，而是從敘述的過程中，讓讀者去瞭解到物件的主要優點在於對複雜的邏輯易於處理。 然後他又提到了一個很有趣的想法，他認為所謂的企業邏輯(business logic)是最沒有邏輯可言的，因為企業邏輯的複雜性，是無法被套用在任何的邏輯性模式，它就是被用在企業人(business people)來贏得商業利益的；任何一點的小改變都有可能贏得商業上的交易，而這也意味著，每一次的小改變都會導致系統的複雜度。為了應付這種 “瞬變” 的無邏輯性，企業AP 就是要被設計成很能禁得起變動，所以本書會討論的設計議題有六大項：企業AP的分層(layering)結構, 企業(領域)邏輯的結構, WebUI 的結構, O-R Mapping 的設計議題, 在 Stateless(無狀態)環境中處理 session(會談) state, 分散的原則。 在介紹這一部份，Fowler 提到了他對一些字彙(術語)的看法，我印象最深刻的就是他說他不懂架構該如何解釋，也不敢去冒犯這個詞彙 (我在想，如果連他都不敢去解釋架構的話，那還有誰能？)。 不過，他還是盡其所能說明架構對他的認知而言，第一個想到的就是 “分層(Layering)” (例如常談及的展示層、企業邏輯層、資料來源層)。 嗯，這裡我倒是也可以分享一下我對架構的看法，我以為架構是一種整體觀，整體需要時常凝聚各種不同角度的觀點，那是一種動態的調和。 另外，作者還有談及包括 效能(performance) 的設計議題，以及對於模式的應用想法。 Fowler 提到了，模式的關鍵點在於具體的實踐，是觀察人們於日常生活與工作中，觀察發現到某一個特定的解決方案；使用模式的關鍵是不能盲目去使用它，所以好像會看到同一個解決方案，但沒有一次是相同的。

設計是務實，是要能調和理想與現實的

500 多頁看來好像好多的內容，其實作者有說只要研讀第一部份即可。這一部份是屬於觀念上的引導，才一百頁而已，而每一個主題又都能分開去看它，其實讀起來並不費力。建立了在平台面設計議題的相關基礎知識與觀念後，就可以參考第二部分作者所整理提供的各類模式，例如 O-R Mapping 的相關設計模式，讓你知道如何建立 Data Mapper 的機制，來橋接領域模型的物件與關連式資料庫的表格。有需要再去看、去查這些模式，否則會很悶，這是作者對讀者的中肯建議。

先前我曾提過，許多所謂的物件導向基本教義派就是掛在無法把他們所認知那種理想美好的那一面(例如，建立純粹是領域的物件模型)，給應用在現實的平台環境中。因為，現實上，沒有如此大的記憶體可以容納都是活生生的物件，所以需要給 “冬眠(hibernate)” 到如關連式的資料庫內；因為系統的資源有限，所以需要作資源的控管，包括資料庫連線與物件數量等管理；因為 WebUI 要服務更多廣眾的 Internet 用戶，所以被設計為 “無狀態(stateless)”，但是企業用戶需要的是 “stateful” 服務，如何把 stateless 作成像 stateful，就是考驗了設計者對資源與狀態控管上能否權衡的好。

這是一本專注在系統平台面設計議題的書籍，是討論關於如何把理想美好、能表達出軟體主結構的物件領域模型，橋接至利用現實系統業者所提供對企業層級的開發平台框架與應用伺服器等。對於想要瞭解企業層級的應用系統是如何調和彈性、延展度、穩定與效能等，本書絕對是必備參考的經典鉅作。

延伸閱讀：

• {iThome 書評—14} Business Modeling With UML: Business Patterns at Work
• {iThome 書評—12} Object Models — Strategies, Patterns, and Applications
• {iThome 書評—9} Constructing the User Interface with Statecharts
• {iThome 書評—8} Object-Oriented Analysis and Design
• {iThome 書評} UML 精華第三版中譯本

Business Modeling With UML: Business Patterns at Work ———————————– 作者／Hans-Erik Eriksson/Managus Penker /著 出版社／Wiley ISBN／ 0471295515 Amazon 評鑑：四顆星

內容簡介
Until now, the Unified Modeling Language (UML) has been primarily used to design software, but should you use it to model your entire business as well? That’s the intriguing argument of Business Modeling with UML, a text that combines leading-edge enhancements to UML with some solid thinking about business. Written for any manager with some technical background, this book looks at the possibilities of UML used to model entire organizations.

The book makes a strong case for the advantages of modeling businesses in UML. With models, an organization can provide better software, define and implement new goals, and even decide whether to outsource certain operations. The Erickson-Penker Business Extensions for UML, invented by the authors and presented within the text, permit UML to document the entire business enterprise. This book shows how to model businesses, from business architecture to processes, business rules, and goals. Short case studies–for Web-centric and more traditional companies–are used to illustrate key concepts here.

Later sections of the book will perhaps take a little more background in software engineering to appreciate fully as the book presents a handful of business patterns, which offer reusable solutions to common problems (just like software patterns). The authors also look at how to leverage a business model to create better software.

In engineering, a new car is modeled and thoroughly tested on a computer before any physical prototype is ever built. As the authors point out, a business that has accurate models can test out new ideas cheaply and then adapt to changing market conditions quickly. This title makes a case that UML–a tool traditionally used by software developers–is ready to tackle the job. Read this notably informative and intelligent book to see the possible benefits of business modeling in UML for your organization. –Richard Dragan

Topics covered: Business modeling basics, UML notation and Erickson-Penker Business Extensions, class diagrams and powertypes, object diagrams, statecharts, activity diagrams and swimlanes, sequence and collaboration diagrams, collaboration and use case diagrams, component and deployment diagrams, stereotypes, business architectures, business processes, resources, goals, business rules, Object Constraint Language (OCL) and collections, business views and patterns, business goal allocation, business goal decomposition, business goal-problem, and software architectures

Review
"…excellent value for money." (Computer Bulletin, September 2000)

前言

一般軟體設計人員以為UML 塑模 (modeling) 的範圍僅限於軟體資訊系統，其實不然，我們也可以把企業當成是塑模的對象，利用物件導向的手法，有效地來保存企業重要的資產。企業塑模的意義就是在於將企業當成是一個系統 (system)，把系統視為是一個整體 (whole)，我們就可以區分外部的需求觀點與內部的結構觀點。確立了系統範圍的好處在於可以找出系統 (企業)的主要參與者 (primary actor)與支援性的參與者 (supporting actor)，前者會需要企業來提供整體性的服務，而它也往往是企業主要的經濟來源與命脈；後者則是企業需要其它關係企業、或子公司的服務支援，以提升企業整體服務的能力。然後，我們再透過觀察內部的組成結構，找出共用性的部分，藉以來支撐外部的需求。企業內部包括靜態的結構元素，可能會有內部工作人員 (internal worker)、軟體資訊系統 (information system)、企業內部經常溝通的術語、概念、實體 (entity)等；還有以及觀察在動態行為期間，為了服務需求，這些元素是如何互動的合作，而構築成所謂的企業流程 (business process)—包括了供應鍊 (supply chain)與內部行政事務的流程等。

可以發現到，應用物件導向分析與設計 (OOAD)的思維與技巧，以及利用標準的 UML 語法與視覺化的圖形表達，簡單又易學、幾乎沒有學習曲線，就可以將企業與軟體資訊系統用一致性的分析手法很平順地互補與轉移，而且可以協助從各種不同的角度來看待組織與企業，不僅只看流程 (這是比較傳統的紀錄方式)，還能找出企業核心的本質 (結構)。可以說，企業塑模的價值遠大於軟體資訊系統。除了瞭解企業的運作與規則，也可以知道哪些活動或製程需要資訊系統的支援，如此可以提昇企業的效率與整體競爭力，這也是 BPR (business process re-engineering)，企業流程再造的範疇，同時又可以成為專案委外 (outsourcing) 規劃與管理重要的參考依據。

企業塑模真的很有趣，同時又可以擴展軟體人員的視野與格局，不會只是單純僅考量到實作技術面的議題而已。那麼，又如何能建立企業塑模的正知與正覺呢？ 我是強烈建議研讀本次書評的主角，它除了說明了 business modeling 的真諦，還教導讀者如何保有多重的觀點 (multiple views)來看待系統，以及如何利用物件以及流程，表達出各個觀點之下的設計圖 (diagrams)，不是只有涵蓋理論而已，是絕對可以應用在實務的開發。本書可以說是作者的經典代表作，也是 OMG 系列強力推薦的實用叢書。

從架構與觀點著手，才能掌握整體，瞭解企業塑模的精要

本書我是買精裝硬皮的，質感甚佳，也比一般書籍的 size 大了些，而且看起來好像很厚，約 450 頁左右，這也使得許多讀者望而卻步。但其實印刷的字體還算大，且有著大量豐富的設計圖。我是建議不要逐字細讀 (那太辛苦且沒效率，而且往往很難堅持從頭看完)，要能觀其大略。例如我會一開始先研究一下本書的大綱，大概知道一下每一章節要表達的重點為何；在我的心中建構了整體觀之後，然後就會先翻閱到與整體比較有關的章節，然後再看重點標題，當然，基本上圖形大概就可以讓你瞭解到該節想要表達的意義為何。而若是不懂該設計圖的意涵，再去佐以看看那些文字敘述的解釋，大致上瀏覽、能瞭解其意就可以了。我是覺得，本書的編排非常好，讓我閱讀起來是真的很輕鬆。

本書共分為十一個章節。第1章開宗明義，解釋了企業塑模的意義與價值，以及為何是利用 UML 設計與規劃企業流程、企業規則等。第2章是對 UML 語法的簡單介紹，諸如靜態結構的類別圖，以及表達動態行為包括活動圖、狀態圖等，尤其是活動圖，這會是本書後續所常用的。第3章最重要了，它揭露出企業架構的塑模手法。本書最有價值的一張設計圖，正是由兩位作者所自創的語法構成的，由於長得很像火箭，我常把它戲稱為 火箭圖 (其實正確的學名為 Eriksson-Penker Business Extensions，也可以把它視為是活動圖的擴展)，用來表達鉅觀的企業流程。而事實上，它也成為我在輔導比較大型 ERP 系統開發時所常用的流程設計圖。一般我經常看到系統分析人員常常把流程畫得很複雜，細細麻麻的長得好像電路圖。其實這就是因為比較沒有層次的觀念，來適時地封裝不必要的細節。火箭圖正是用來表達更高層級的流程活動，它甚至封裝了活動圖所表達的業務流程，只表達出火箭的輸入、輸出、參考與支援的資訊，更有價值的是，它還凸顯出流程處理完之後所能達成的目標 (goal)為何。火箭圖會應用在如 ERP 常講的業務循環，當訂購循環處理完之後 (訂購火箭)，輸出會轉到如採購循環或出貨循環 (出貨火箭)等。然後當要觀察每一個火箭內部的作業時，只要打開它，再利用活動圖來瞭解其活動的細節。層次分明、簡單呈現，這正是塑模的精要 (essential)。

第4章則是提及了上述所講的企業觀點問題 (business views)。我這裡再次提醒讀者，記得當把企業當整體單一系統時，起碼保有兩種觀點—外部的需求觀點 (用的角度)；內部的結構觀點 (靜態的結構元素關連與分類，動態的流程互動行為)。第五章則是提及如何利用 OCL (Object Constraint Language)來記錄企業規則 (business rule)，這倒不是絕對的方法，我個人本身就不太願意被限制如何表達這些規則。6~8 章則是揭露出各種對企業的設計模式 (business patterns)，包括了結構、流程、資源、規則與目標規劃等模式。我會建議不用先去看它，等到有身體力行，應用在實務遇到一些想法或問題時，再回來翻閱，會比較有感覺。第 10 章是討論如何從企業塑模轉移到軟體架構的設計階段。我是覺得，本章並沒有一個很明確的轉移規則，算是一種觀念的引導而已。如何從企業轉移到軟體塑模，在我所實際顧問的專案中，是已經釐出一些規則出來。簡單的說，無論什麼領域 (domain)，只要能“想辦法”轉移到資訊系統的使用案例圖，那實作上就絕對不會是什麼問題了。最後第11章，是提供一個案例分析，從企業願景 (vision)，到結構的結構、行為與流程等，這些設計是如何被產出，以及這些產出之間的關係又是為何。

企業的資產，是由領域與軟體專家們的合作所累積而成的

從企業塑模的層級可以得知，領域專家 (domain expert)是可以與軟體專家合作完成在企業面的設計。對領域專家而言，流程的設計與規劃，是屬於 "企業流程再造的範疇，而對於軟體專家，是可以把 "企業當系統" 來看待，然後利用 企業塑模 的技巧，來協助企業流程、規則等的設計與記錄，真正企業的資產，就是將領域專家們的智慧，經過“企業塑模”所粹取之後的產出(Artifacts)！！ 而後參考企業塑模的產出，就可以很清楚地瞭解與規劃，哪一些企業流程的活動，是可以經由資訊系統的協助，來達成自動化或減輕工作人員的負擔。

延伸閱讀：

• {iThome 書評—13} Object-Oriented Methods—A Foundation 2nd Edition
• {iThome 書評—12} Object Models — Strategies, Patterns, and Applications
• {iThome 書評—9} Constructing the User Interface with Statecharts
• {iThome 書評—8} Object-Oriented Analysis and Design
• {iThome 書評—7} 重構—改善既有程式的設計中譯版

Object-Oriented Methods A Foundation ———————————– 作者／James Martin/James J.Odell /著 出版社／Prentice Hall PTR ISBN／ 013-905597-5

內容簡介
This book presents those concepts and techniques that support almost any system development approach–whether it involves computers, people, or machines. It considers object structure, object behavior and more advanced concepts such as composition, structural constraints, rules, using rules and diagrams, meta-modeling, and power types. Shows how to represent OOA constructs–modeling object structure, modeling object behavior, modeling state transitions and event diagrams, scenarios. Outlines considerations for design, discusses object-oriented programming, and considers object-oriented design and "instant" CASE. –This text refers to an out of print or unavailable edition of this title.

前言

截至目前為止的書評，我發現到並沒有真正介紹到適合於初學者的軟體入門書籍。大部分所介紹的還是偏向實用性的設計類叢書，即使如 Booch 那本 OOAD，雖然是理論基礎用書，但那本其實難度不低，用字又艱深。事實上，所謂的「物件導向」基礎入門書，要能寫得好，其實非常困難。作者除了觀念要相當透徹外，用字遣詞又要言簡意賅，把複雜的事情簡單的呈現，並不是一件容易的事。不過本次的書評— {Object-Oriented Methtods}，兩位作者均同名為 James 的 Martin and Odell，寫出了絕對會是留名軟體青史的代表性著作。即使許多讀者會恐懼於閱讀原文書籍，但本書的英文用句，真的相當淺顯，不太懂文法也是可以讀起來毫不費力。誠如作者在前言裡所提及適合於本書的讀者程度，並不需要具備任何的前置知識，包括程式語言等。更為誇張的是，他們說書中諸多元素用語，已被用來教導約七歲年齡的孩童。這讓我想起，曾經在某購書網站看到，{UML 精華} 那一本書，適用對象竟然是寫為國小程度，哈，許多軟體人員真的是有夠汗顏的了。(其實那是網站筆誤的)

Martin & Odell 可是 OO軟體業界早期相當具知名度的先驅，他們的著作甚多，Odell 除了是物件導向社群的領導者外，也是 OMG UML 規格制訂的主席；而 Martin 看他寫作的資歷，你真的會嚇一大跳，從 1960 年代開始，我都還沒出生的時候，就已經出書了，至今已發表超過 100 本以上的專業書籍，包括軟體、資料庫、電傳通訊、即時性系統等，所涉獵的專業範圍實在廣泛。至今他除了在知名大學教授外，還仍茲茲不倦地研究與寫作。我真的好是佩服，這才是真正致力於軟體之道的大家啊。

清晰明確的術語定義，才能奠定 OO 紮實的基礎

本書共分為六大部分，剛好整整 400 頁，厚薄適中。最後一部份為附錄，除了語法的說明，還有一個訂購系統的分析範例。另外最值得推薦的是附錄D (Toward a Formalization of OO Analysis)，是以論文的型態闡述了關於分類的關係、一般化/特殊化、功能/屬性/角色 等在分析過程中，經常會運用到的基礎技能。

第一章是對泛OO系統的概念性介紹。而在前兩部分章節，則為 基本OO的基礎知識。第一部份(2~11 )介紹物件的結構(structure)、第二部分(12~17)介紹的是物件的行為(behavior)。我覺得第一部份可以精讀，那真的是奠定最為紮實的理論基礎了。例如，我們經常說開發的是所謂的物件導向式系統，好吧，那你能否明確的說明出分析的物件從何而來？ 再問一個更“俗”的，能不能定義出什麼是物件呢？ 嘿，許多軟體人員還會愣住，無法回答出來呢。第二章開宗明義就指出，物件源自於概念(concept)，“An Object is anything to which a concept applies. It is an instance of a concept. (物件是概念可以被應用的任何事物，它是概念所呈現的個體)”。 由此定義也可以得知，“物件”與“個體(instance)”這兩個術語，其實是具同義詞性質的。將“概念(concept)”作為認知的對象時，所產出的“個體(instance)”即為物件。但概念會牽涉到人們對於觀點、角度等認知，而會有不同的體認。例如站在遊客的角度，他所看到在森林裡面的樹木，是一個個的“個體”，會從樹木之外的角度來欣賞樹木的茂盛與宏偉，是一種整體性的認知；但站在植物學家的角度，他要研究組成樹木的結構元素，所以會把樹木分為“樹幹”、“樹枝”、“樹葉”、“樹根” 等多個組成樹木的“物件”，從結構的觀點來研究樹木的內部組成。這同時也就代表了，雖然到處都是物件，但並不是任意地將物件給“塞”入軟體系統內，物件導向的設計，是將問題領域(problem domain)的概念，呈現與對映(mapping)至軟體系統內，那麼，如何正確地捕捉(capture)問題領域的概念成為物件，就成為是軟體設計中，最為重要的技能與素養了。 你可以看看，當你能對這些基礎概念術語有很明確的定義時，你就可以很容易地衍生出諸多看來好像很複雜的呈象，但卻又不會違背這些基本的原則。我常戲說，練好這些軟體蹲馬步的基本功，才真正夠得上是武當名門正派的正宗內功！

當能分辦出 物件與類別的區別後，然後再進而瞭解類別之間普遍的三種關係：關連、整體/局部、一般化/特殊化 。透過關連，我們可以分析類別的相依性(dependency)，以瞭解耦合(coupling)的程度；透過 整體/局部，我們可以封裝(encapsulate)細節，並以整體的服務呈現給 client；透過 一般化/特殊化，我們把相同的部分抽象出一般化類別，而把特殊或需要擴展的行為分別實現在特殊化的類別，而造成所謂多型(polymorphism)的效果(這也是程式語言中常稱之所謂的繼承)。再來論及的是物件的行為面。從對狀態(state)的說明，然後到狀態的轉移，而發生轉移的觸發(trigger)即是所謂的事件(event)。所以當然就會需要瞭解到事件的種類、事件的處理等，而這也是在當今元件化的系統，在動態期間常會需要用到的機制，在設計上也是相當重要的範疇。

第三部分(18~23)是OO進階的介紹，這裡提及到了限制(Constraints)，也就是在類別關係之間如多重性是如何的表示；還有提到了規則(Rules)的表達，是如何呈現在設計圖上。我是覺得這類議題反而比較偏向細節性，倒是不一定要規範如此嚴謹，我是比較主張設計盡量活潑彈性一點，再慢慢地抓出團隊設計的共識即可，至於嚴謹性，倒不如在程式碼驗證即可。

第四部分(24~29)是關於物件導向分析(OOA)的說明。由於這裡涵蓋的議題太過廣泛了，諸如需求面的功能分析、結構面的類別設計、實作面的物件互動等，短短幾個章節不可能詳述清楚的。這裡我也只是大概瀏覽過即可，然後再對上述各個主題，從別的專書中再深入去探究。

第五部分只有一章(30)，主題更是嚴肅，設計與實作的考量。開玩笑，一大堆所謂的物件基本教義派就是“掛”在無法將他們理想中的設計具體化呈現在現實的技術平台上，例如所謂的“O-R (Object-Relation) Mapping”，每種平台的實作都不一樣，那也是要相當去深入研究的；還有諸如交易控管、權限控管、分散式 …等，這些都是在實作上必然要面對的挑戰，10 本書都不一定介紹得完，遑論僅有一章？

軟體非“以用為本”

本書在 Amazon 也是頗受佳評的四顆半好書，印刷尤為精美，是我目前唯一有著紅與黑的兩色印刷書。除了 UML 設計圖外，還有許多生動有趣的插圖，佐以解釋主題的呈現。最好是不要抱著從“用”的角度來看待此書，那麼你可能會失望，因為它不一定能馬上讓你可以應用在現實的工作上。當你好奇於為什麼主流的程式語言都採用物件導向式的實作機制、為什麼系統分析/設計也強調所謂的 OO 思維，到底 OO 是要協助來解決什麼樣的軟體設計議題 …，還有當你真正有志於從事軟體專業之路時，本書絕對是修習基礎內功的必備聖典。

延伸閱讀：

• {iThome 書評—12} Object Models — Strategies, Patterns, and Applications
• {iThome 書評—9} Constructing the User Interface with Statecharts
• {iThome 書評—8} Object-Oriented Analysis and Design
• {iThome 書評—7} 重構—改善既有程式的設計中譯版
• {iThome 書評—5} 深入淺出設計模式中譯本

Object Models — Strategies, Patterns, and Applications ———————————– 作者／Peter Coad with David North and Mark Mayfield /著 出版社／Prentice Hall 出版 ISBN／ 013-840117-9

內容簡介
Object programmers can now learn how to get faster results using the strategies and patterns (templates) uncovered in this book. Without them, however, the much-needed expertise is only acquired by trail-and- error. Using sufficiently detailed, real-life examples, this book/disk package shows how to build effective object models–using applications that occur in nearly every industry. Presents six chapter- length application examples of how effective, real-life object-models are build–e.g., point-of-sale, warehousing, order-processing, data acquisition and control, and sensors and diverters. Each application reveals specific "how-to" strategies (101 total) and patterns (22 total) that will help readers develop an intuitive feel for building object models. The diskette features an on-line verison of the strategies and patterns summary (in the form of a Windows help file); as well as C++ course files, illustrating a reasonable (but not the only way) to implement each pattern. –This text refers to an out of print or unavailable edition of this title.

前言

我擔任多家公司，包括各類領域(金融、鋼鐵、保險、零售、股票 …等)的系統開發顧問期間，遇到最常見的“通識”就是資訊主管幾乎清一色要求 SA 要能懂得相關領域知識 (domain knowledge)，認為這樣才能作得好系統分析。殊不知，SA 最多只能代表著操作人員 (operator)層級的功能需求分析而已，領域知識的核心，包括企業流程的制訂改善等，是由領域專家 (domain expert)所掌握的。 SA/SD 太偏重領域知識的結果 (在台灣，SA/SD 的分界一向不明顯，可能是 SA 與客戶訪談需求，然後由 SD 作 E-R Model 資料庫表格的結構分析)，卻忽略於軟體結構分析的技能培養，所抓出來的 Entity (經常呈現為資料庫表格)，往往就是耦合性 (coupling)太重，牽一髮而動全身，無法應付變動性。

個人經常奉勸 SA/SD 並不是具備領域知識，而是應該要懂得如何與領域專家的溝通合作，將其核心知識抽象而成為軟體系統的結構，所以要具備的應該是結構分析的萃取能力，那是一種可以獨立於各個問題領域 (domain)與 IT 平台技術的一種技能，我常之為“純”軟體的抽象分析的專業技能。聽起來很玄？ 好吧，套一句軟體界常用的術語，就是所謂的物件導向分析與設計的技術，但是那卻非從程式語言、平台技術、或者領域知識等從之學習而來的，那種抽象 (abstract)能力的培養，是需要懂得對事物本質的體悟、感知能力與大量的觀察及動態學習等才能獲得的。老實說，軟體的樂趣正在於此！

以筆者所擔任各大企業軟體顧問為例，起碼接觸到有 2、30 種各類不同的領域，我們是不可能具備各專業領域知識的，但總是能與各領域的專家合作，從三言兩語的對談當中，就能很輕易的抓出該領域的核心結構，並可以馬上就利用如物件圖的案例來檢驗其結構的正確性以及變動的彈性度等，是相當經得起考驗的。對這種跨領域與平台技術的抽象能力的建立，說真的，我們顧問的利器，最早是源自於對本次書評要介紹的主角，是有花了許多功夫的學習，並從實戰當中的印證體悟，才慢慢得以建立起這樣的技能。光是透過書中介紹的“交易樣式”，就得以讓我們橫跨各領域，抓出最穩固的核心結構元素，實在受用無窮。

直指企業核心的本質—交易樣式

本書主要的作者為 Peter Coad，最早研究所教科用書，有許多就是採用他的著作：“Object Oriented Analysis、Design ”兩本經典 OO 著作；不過軟體人員對他仍很陌生，那麼說出 Borland Together，就會恍然大悟，原來就是他創立的公司研發的主力產品 (後被 Borland 花了兩億美金併購)。

先讓讀者瞭解一下，結構分析主要就是抓各領域的穩定元素來建構軟體系統，而那往往就是常在溝通的概念術語 (concept terminology)。在設計階段一般是以 UML 類別圖 (class diagram) 來呈現，而具體化在應用系統中的就是所謂的企業物件 (business object)；與在資料庫的表格 (table)。兩者的差別主要在於企業物件尚需分析各個物件所應負擔的責任 (在程式語言則稱之為 方法, method)。分析領域物件與明確分派物件的責任，正是影響軟體結構彈性度的主要關鍵。

有別於絕大部分 SA/SD 是透過需求訪談記錄一個一個的抓“名詞”，雖然是行之有年，但那實在不是一種好方法，所抓出來的類別往往見樹不見林，無法有效的將相關的類別關連於一起。 Peter Coad 是直接直指領域核心，觀察企業行為的本質源自於交易。交易為商業利益交換的一種契約 (contract)，是一種非常必要保存的事件 (event)記錄，再由此為中心，來串連其它相關類別包括 參與者 (actor)，地點 (place)，物品 (item)，以及所包含的交易細項 (line-item) 等。這種先抓主幹，再抓枝葉的方式，正是相當著名由 Peter Coad 所揭露的 “交易樣式 (transaction pattern)”。

以最常見的訂購系統來說好了，“訂購(order)”就是核心的交易類別，再由其串連出來，就可以找出“訂購細項(transaction lineitem)”、“客戶(actor)”、“訂購地點 (place)”、“商品項目(item)”等；再轉分析另一個領域如保險業，“保險”絕對是一個顯而易見的交易類別，而“對保”則是與之有相關連後續的交易類別 (subsequent transaction class)；好啦，如果是要分析一個運動彩券投注系統，要你馬上抓出第一個類別，應該就知道該怎麼抓吧？ (投注, 派彩 均為該領域的核心類別)

不同層次，傳不同層次的法

我是從 amazon 購買 a4-size 的硬本精裝版，本書可是有著四顆半星的高評價，讀者對之推崇甚高。封面為樂高玩具，甚是有趣，看起來其隱喻應該是意指軟體的結構組成，就如同樂高積木般，一個個地給聚合組裝起來的。共有七個章節，前五章均為各自獨立的案例分析，後兩章為策略與樣式的整理列表。印刷很不錯，字體大小恰當且清晰，也有很豐富有趣的插圖。不過內容可是相當艱深，沒有充分的抽象與想像力，是不容易理解的。獨立閱讀本書可說是非常吃力，我是建議能有幾位同好們一起研讀，甚至以角色扮演的方式，來思考所抓出來的類別，以及所賦予其責任的合理性與正確性。

本書的類別表示法均是採用作者自創的語法 (Coad Notation)，它可說是自成一格，例如多重性(multiplicity)就剛好是與 UML 類別圖的表示法完全相反，所以一定要先閱讀附錄的語法說明。再則從每個案例研討的過程當中，作者總是會列出他在某個分析階段時所使用的策略或樣式，並將之編號整理在後兩個章節。這個相當的有參考價值，但不要直接就是翻閱這些策略與樣式列表，那可是相當的枯燥乏味，最好就是配合著這些案例的過程說明，久而久之，你閱讀起來才會習慣也比較能有感覺。

誰需要閱讀本書呢？ 我是覺得想立志當個真正的“軟體人”是必備的。要知道，軟體設計大概可以分為三個層次；1.把系統“做”出來；2.讓系統效能好一些；3.讓系統更有彈性，來順應變化。 第一個只要有不錯的實作能力，以及功能需求的分析能力即可；第二個則需要有對平台的專業知識能力，能充分發揮系統的效能特性；第三個那可真的需要對軟體的“道”有著長期持續的信仰與熱情方可。我是以為，若能進入到第三個層次，修練該層次所傳授的法，那絕對會是一種無以言語的喜樂。不過，現今國內軟體產業重視速食文化，大約只要求在前兩個層次，第三個層次，曠時廢日，不太容易短時間內有著顯著的實質回饋，因而堅持者甚少，殊為可惜。

延伸閱讀：

• {iThome 書評—9} Constructing the User Interface with Statecharts
• {iThome 書評—8} Object-Oriented Analysis and Design
• {iThome 書評—7} 重構—改善既有程式的設計中譯版
• {iThome 書評—5} 深入淺出設計模式中譯本
• {iThome 書評—4} 極致軟體製程中譯本

Test Driven Development By Examples ———————————– 作者／Kent Beck /著 出版社／Addison-Wesley Professional 出版 ISBN／ 0321146530

內容簡介
Clean code that works–now. This is the seeming contradiction that lies behind much of the pain of programming. Test-driven development replies to this contradiction with a paradox–test the program before you write it.

A new idea? Not at all. Since the dawn of computing, programmers have been specifying the inputs and outputs before programming precisely. Test-driven development takes this age-old idea, mixes it with modern languages and programming environments, and cooks up a tasty stew guaranteed to satisfy your appetite for clean code that works–now.

Developers face complex programming challenges every day, yet they are not always readily prepared to determine the best solution. More often than not, such difficult projects generate a great deal of stress and bad code. To garner the strength and courage needed to surmount seemingly Herculean tasks, programmers should look to test-driven development (TDD), a proven set of techniques that encourage simple designs and test suites that inspire confidence.

By driving development with automated tests and then eliminating duplication, any developer can write reliable, bug-free code no matter what its level of complexity. Moreover, TDD encourages programmers to learn quickly, communicate more clearly, and seek out constructive feedback.

Readers will learn to:

• Solve complicated tasks, beginning with the simple and proceeding to the more complex.
• Write automated tests before coding.
• Grow a design organically by refactoring to add design decisions one at a time.
• Create tests for more complicated logic, including reflection and exceptions.
• Use patterns to decide what tests to write.
• Create tests using xUnit, the architecture at the heart of many programmer-oriented testing tools.

This book follows two TDD projects from start to finish, illustrating techniques programmers can use to easily and dramatically increase the quality of their work. The examples are followed by references to the featured TDD patterns and refactorings. With its emphasis on agile methods and fast development strategies, Test-Driven Development is sure to inspire readers to embrace these under-utilized but powerful techniques.

前言

我一位軟體設計的夥伴，是我在這個業界看過上千軟體人員以來，唯一我認為是最為天才的。不是只有 IT 技術的學習能力快速而已，他更具備的是柔軟的頭腦與身段，抽象能力極高，擅長把軟體作軟，令人讚嘆與嘆為觀止。但是我還是覺得他與國外軟體先驅的大師們仍有一段差距，並非是實作，也不是學習的能力之差，最最主要的差距就在於：創新能力！ 當然，我與他非常熟，才敢這樣說，而他也能認同此點。我更期勉如此有天分的人能往更高段的軟體設計殿堂，使得有能力的人可以有更多的貢獻，幫助更多人。

什麼叫做創新能力？ 舉個例子，我輩之流如我是可以看得出早期 EJB 規格的問題點(簡單的說，軟體結構被該規格綁得死死的)，所以會批判與避免使用它。但是 Rod Johnson 卻不是只有批判反對而已，而且還身體力行，寫出了 Spring Framework，實現 IoC (Inversion of Control), AOP (Aspect-Oriented Programming) 的輕量級開發框架，真正釐清 Developer 與 系統層級服務的責任； 再如本次書評要介紹的： Kent Beck 因為在輔導專案的過程中，深深感於測試應伴隨著所開發的程式碼，而不是延遲 (太多大型單位都把測試當作一個重要的製程，卻是交給另外的部門，在開發後才展開測試，這樣能應變測得好？ 我很懷疑)，所以主張“測試先行 (Test First)”。而為了實現與主張他的理念，甚至設計出 免費開放的 JUnit Framework 等測試框架，以及寫出如本書“TDD (Test Driven Development by Example)”，造福諸位大德。我輩之流雖無法創建如此了不起的框架，但起碼也要作一些推廣，讓 Developer 們瞭解什麼才真正是維繫軟體品質的重要關鍵。

測試先行！先行測試！

我實在是太欣賞 Kent Beck 的寫作風格了。本書才 200 頁初頭，卻共分為 32 個章節。怎麼會這麼多章節？ 原來作者根本沒有分小節，然後就是完全以例子，每一章只完成一個小目標、解決一個小問題就結束了。全平面的寫法，沒有艱澀難懂的術語，簡約的風格，真正夠得上是“俗又有力”!

全書共分為三大部分，前兩大部分就是範例，第三部分則是 TDD 的設計模式(Patterns)。第一部份以一個“幣值轉換”的程式範例(本書開頭的介紹中特別有說明到該實際案例的緣由)，利用 Java 程式碼範例，來逐漸揭露出 TDD 的設計意涵。這個範例，你初一眼看到時，會覺得怎麼有那麼白癡的寫法？ 是的，Kent Beck 盡量模仿初學者剛寫程式碼的程度，這也同時說明了 TDD 是多麼的簡單明瞭，初學者一學就會，也懂得如何慢慢來修正自己的程式碼 (這其實已經逐漸走向設計之道了)。這一部份會讓你瞭解到什麼才叫做是“Test First”？ 還沒寫類別程式碼之前就先寫測試程式碼了！ 相當之令人驚訝。當然，測試一定不會過，再來才是開始寫你的主題程式，新增類別、編輯屬性、修改參數 …等，請記得，每次只修改一個地方，然後測試它，逐漸讓錯誤減至零，測試亮綠燈為止 (測試有錯會亮紅燈)。簡單的設計、列出工作清單、一次只解決一個問題、測試它、讓它正確，反覆修正．．． 正是 TDD 最重要的精神。

第二部份則是藉由 Python 語法來探索 xUnit 測試框架的設計過程。是的，這一部份真的是在教你如何撰寫所屬自己的測試框架，本以為開發 Framework 是相當困難且嚴謹的設計工作，但你看 Kent beck 又是近乎白癡的作法，但竟然三兩下就可以開發出測試框架，而且在設計的過程中，還仍能秉持著“測試先行”，真是神奇！ 會使用 Python 作為範例的原因，我猜想除了語法易懂之外，它本身是屬於“script-based”的語言，藉此來證明這樣也是能實現測試框架的實作。事實上，目前已知有 30 餘種程式語言支援 xUnit Framework，那麼為何作者還要鼓勵程式人員開發所屬自己的測試框架呢？ 兩個理由：1.讓你有對測試工具自我主宰的感覺；2. 藉以探索測試內部的機制。

第三部分是 TDD 的設計模式。這裡談及到了測試的策略思考，包括到底測試的意涵為何、那個時候測試、如何選擇什麼樣的邏輯與資料來作測試。如何測試？ 不要紙上談兵，只寫那些測試案例，就是一定要寫自動化 (automated)的測試程式；那個時候測試？ 無庸置疑，測試先行！ 甚至主題程式還沒有寫出來、資料也還沒備妥之前；測試什麼？ 功能性 (針對需求)與單元性(Unit)的測試 (針對本質性的領域類別)。 TDD 崇尚簡潔 (Simplicity)，擺脫那些無謂的高度儀式化吧，從簡單的地方開始做起，為自己所寫的程式負責任，維繫最基本的程式品質，並期能持續演化而又不影響既有功能正確性的前提下。

Simplicity is the Power！

TDD 只有一個核心精髓與兩個原則。精髓為：讓程式碼可以運行並能保持純潔無暇 (Clean code that works)。而原則是：1. 只有自動化測試失敗時，才寫新的程式碼；2. 消除重覆 (duplication)。尤以後者，又與系統架構中的相依性 (dependency)設計有相當密切的關係，當消除掉重覆的程式碼後，往往系統的耦合 (coupling)程度降低，也使得可再利用性的價值提昇。

Kent Beck 還特別在序文中提及了“勇氣 (Courage)”，把 TDD 與之關連一起。他認為測試驅動是一種可以在開發過程中控制憂慮感的開發方法，它可以讓你：盡快具體的學習，而不是一直處於試驗性的階段；取代沈默寡言，讓溝通更多的交流；不是躲開回報，而是更能尋求具體有幫助的回饋 (feedback)。當讀者閱讀完本書後，應該就能準備：1. 從簡單開始做起；2. 寫自動化的測試程式；3. 重構 (refactor)，每次只增加一個新的設計。

延伸閱讀：

• {iThome 書評—10} 寫給SA的UML/MDA實務手冊
• {iThome 書評—9} Constructing the User Interface with Statecharts
• {iThome 書評—8} Object-Oriented Analysis and Design
• {iThome 書評—7} 重構—改善既有程式的設計中譯版
• {iThome 書評—5} 深入淺出設計模式中譯本

內容簡介
UML發展至今，已經成為軟體發展的通用語言。現今的應用層面廣泛，從即時系統、嵌入式系統到晶片設計，都可以見到UML的身影。本書與其他UML書籍最大的不同，就是本書不僅止於觀念與學理的論述。而且透過一個開發基金交易平台的案例進行闡述，逐步說明從需求訪談到如何利用UML/MDA，利用一套名為StarUML的開放源碼工具，產出相對應的使用案例圖文、活動圖、類別圖、循序圖和狀態圖。

本書內容兼顧入門及進階、觀念與實務，適合作為初學UML的入門書，也可作為系統分析師實務手冊。對於大專院校學生、初入資訊界之新鮮人、程式設計師、及其他非專事系統分析的開發人員，也可以藉由此書溫故知新，更加熟悉UML。

前言

本書是由國內目前應該是最為資深的 UML 研究員邱郁惠小姐所著作的。邱小姐本身沈浸在物件導向領域已有 12 年的時間，直至今年 11 月初總算出版了她的第一本著作，也可以說，這本書就像是她的小孩一樣，從孵化到誕生，據我所知，起碼花了兩年左右的時間，用心可謂良苦。事實上，我與她曾是同事，再推溯往前一些，其實她也算是我的導師之一，我對她在以前上課時所撰寫的教材，印象深刻，她總是會引用許多國外軟體名家的著作或論文，這對我當時在軟體設計啟蒙的學習上，收穫實在甚多！

本書內容對我現在而言，可能稍嫌淺顯了一些，我是花了約一個下午就把這本書給全翻閱看完了。不過的確對郁惠小姐在 UML 領域底子之深厚感到佩服，基礎理論與語法等絕不會弄錯。例如 UC 的寫作敘述上，一定是稟持著每一個動作步驟必然會有參與者 (Actor)或系統當成主詞 (這是 UC 寫作常犯的錯誤，沒有標示主詞)；不會在 UC 敘述上描述所有的細節，而是以參考附件或註記欄的方式，來關連以 UC 為首的一連串相關需求文件 (包括畫面等)；還有如在循序圖的表達上，作者也展露出女孩子細心的一面，對於同步或非同步的訊息傳遞，是以帶實心箭頭，還是以待開放箭頭的表達，都相當講究，並且詳細的說明兩者的差異與其應用之處。

七個層次的分析步驟，來降低 SA 對 UML 的學習門檻

先瞭解一下，本書的目標讀者為 SA (System Analyst)，也就是所謂的系統分析師，而系統分析包括對系統外部的功能需求與企業流程分析，以及對系統內部的結構分析，諸如資料庫表格、欄位明細等，還有以物件導向為分析主軸的類別圖與循序圖設計等。如同其它 UML 書籍一般，本書的案例與假設環境仍以企業層級的MIS 資訊系統為主，諸如 ERP, 進銷存 等。

本書共 11 個章節，文字敘述相當簡潔優雅，才 300 多頁，但內容卻也豐富，足夠讓 SA 俱備系統分析的基礎知識。作者在書本的內容編排上，是先介紹基礎概念，包括 OO, UML 與 MDA 等；再來就是把作者所創建的七個 SA 步驟，先濃縮在一個章節，快速地跑完一個案例，讓讀者可以看到每一個階段的設計產出；然後根據每一個步驟，共七個章節分別詳細闡述之；最後則以一個完整的個案，來模擬系統分析師與企業人員之間的對話情形，以及其更詳細的產出；最後一章算是附錄了，係以嵌入式系統為主軸，來展示不同的應用領域，但仍可以利用相同的分析步驟，來產出設計文件。

在 OO 與 UML 的概念介紹上，本書僅是點綴一番，並沒有著墨太深，所以讀者最好能佐以物件導向基礎理論的書籍一同研讀較佳；倒是作者在 SA 階段是以 MDA (Model-Driven Architecture) 的開發程序為依據，蠻有意思的。 MDA 主要將 UML 產出分為 CIM (Computation Independent Model), PIM (Platform Independent Model), PSM (Platform Specific Model)等三個階段。 CIM 比較接近以企業主體為主的塑模，包括企業案例、企業流程等；PIM 偏向領域概念模型 (Conceptual Model)，較不涉及實做系統的平台；PSM 則落實到系統實現時的特定平台，如以 Spring, EJB2 或 .NET 等 IT 技術。 本書因對象是 SA，所以只涵蓋到 CIM 與 PIM，並未涉及到 PSM，所以自然本書也就不會有程式碼了。

饒富創意的是，作者將她對原來輔導包括陸總部、中科院的美國 DoD AF (Department of Defense Architecture Framework) 規格的研究，帶到 MDA 的開發程序，並依觀點與層次共分為 CIM 1~3, PIM 1-4 等共七個層次 (p.1-35)。每一個階段的產出，皆有相當明確的定義，例如 CIM-3, 是定義系統範圍，產出系統的 UC (Use Case) 圖；PIM-2, 分析企業規則，產出狀態圖；PIM-3，定義靜態結構，產出類別圖 …等。對於習慣能有規範指導方針的 SA 而言，這蠻不錯的，可以很清楚知道每一個階段的主要產出為何，它們彼此之間又是如何的關連與橋接。我比較感興趣的倒是作者以狀態圖來描述企業規則，這點倒是在我所輔導的專案中少以應用到 (我將狀態圖大部分用在 UI 與 Controller 的設計上)，而且所引用自 Gray 對企業規則的分類結構 (p.7-2) 定義，包括限制規則與衍生規則等，在第七章均有詳細的說明與應用，這一部份可以說是我從本書所得到最大的收穫。

本書另外較有特色的一部份是在完整的個案分析上，作者是以模擬 SA 與企業人員之間的對話，來導出各個階段的設計。可不要以為那只是模擬而已，其實對話的內容是作者在自身實際輔導的經驗中所粹取出來的，在作者每一次的輔導過程中，她總是拿著一本空白小筆記本，寫下她所碰到的各類情況與問題，相當認真，參考價值自然是甚高。藉由這些對話案例，也可以讓 SA 瞭解需求當事人他們的想法與原作者作為 SA 時的思考推理過程。

作者的用心與考究，從本書可以很明顯的感受到

看完本書後的感想是：創新仍嫌不足，但守成絕對有餘！

可以說是中規中矩的教科用書，雖然沒有讓我有感到很驚豔有趣的想法，但看來很平淡鋪陳的內容，理論基礎可是相當紮實，即使我想雞蛋挑骨頭，還真找不太出有特別顯著的謬論假設，我可以感覺得出郁惠小姐在寫這些內容時，應該是戒慎戰兢，是熟讀並參考了包括 UML 規格與諸多相關書籍及論文等著作後才下筆的。

本書應該是定位在資淺或入門的 SA 為對象，對於作為大學教科用書，我更是強烈推薦給資訊科系相關的大學或研究生。老實說，我看過國內幾本標榜 UML/OO 的軟體工程教科用書，都沒有如本書考究如此嚴謹與用心，基本上就是以如樹狀功能模組來解釋 UC, 物件循序圖等，很典型的 DFD (Data-Flow Diagram)功能分解的思維，只是藉由 UML 的“殼”來解釋而已，與所謂的物件導向式的分析設計思維根本是兩回事。這樣的教科用書，對於學生在軟體設計理論基礎知識的建立上，誤導成分反而居多，實在不甚理想。

延伸閱讀：

• {iThome 書評—9} Constructing the User Interface with Statecharts
• {iThome 書評—8} Object-Oriented Analysis and Design
• {iThome 書評—7} 重構—改善既有程式的設計中譯版
• {iThome 書評—5} 深入淺出設計模式中譯本
• {iThome 書評—4} 極致軟體製程中譯本

內容簡介
Behind most non-trivial user interface screens lie complex webs of code that many practitioners in the software industry find difficult to control. Despite the obvious power and sophistication of user interface development tools, the majority of user interface software is difficult to understand because it is coded without an overall design. In this book, Ian Horrocks presents a proven technique for designing event-driven software using the UCM architecture and the statechart notation. The statechart approach to constructing user interface software results in code that can be:

* written quickly and easily,
* tested using white box techniques,
* repeatedly enhanced over the lifetime of a system,
* modified with a minimal risk of introducing unwanted side-effects,
* regression tested without the need for full re-tests.

This book provides a practical guide to constructing real user interfaces for real projects. It is primarily written for practising software engineers, but will also be invaluable to students wishing to gain an insight into user interface construction.

前言

狀態機圖 (state-machine diagram) 是描述系統行為時常見的一種技術。事實上自 1960 年代以來，狀態機圖的設計就已被廣泛運用在即時、嵌入式系統的狀態設計上，而 UML 規格的制訂，更將其納入成為標準重要的設計圖之一。物件導向的技術經常使用狀態機圖來表示系統中的各種行為，如針對單一類別畫出它的狀態機圖，秀出單一物件在生命期中的行為。

我是覺得一般 UML 書籍對狀態機圖的論述，仍是著墨甚少，且焦點還是擺在對單一物件的行為描述，而領域性的物件 (domain object)，如“訂購 (order)”，其狀態的變化可能還是少了些，利用簡單的欄位值描述就可以了。
事實上，利用狀態機圖來捕捉某一個體複雜狀態，威力可是非常強大，它有助於讓我們釐清狀態之間轉移 (transition)的變化情形。最常被運用到的範疇，包括控制器 (controller)，例如十字路口的紅綠燈，或者捷運站閘門、販賣機等，都是內嵌了控制器；以及使用者介面 (UI)，尤以後者，它呈現了因為事件 (event)的觸發，而導致諸多 UI 元件彼此之間的狀態連動，該如何對其作有效的控管，並期能追蹤與測試，以維持 UI 一定的品質。

本期書評的主角，正是運用狀態圖 (statechart)的技術來建構使用者介面。包括傳統的 Windows Form，至現以 Web-based 介面開發的 ASP.NET, JSF, 乃至於最熱門的 AJAX 等 UI 技術，其本質都是一樣的—均為以事件驅動 (event-driven)的介面開發。

本書道盡了狀態設計的精髓與本質

這一本書薄薄的，含附錄也才 250 頁，不過字體實在甚小，閱讀起來實在傷眼，還有，內容也稍微艱澀了一些，可要耐下性子，你才能逐漸理解狀態機用在 UI 設計的觀念與技巧，以及寫出程式碼。

本書共分為四大部分。第一部份是對 UI 建構上的概念引導。從命列列模式的 UI 開始講起，到 windows-based 多樣化的 UI 畫面，以能更提供人性化的操作介面。雖然系統廠商提供了諸多豐富的 UI 元件，並呈現給 developer 直覺式的 UI 開發環境，似乎拉一拉圖形元件 (widget) 就可以就建構出美美的畫面，你也不用再管到這些視窗之間的互動細節。這些工具的確幫助開發者不少，但是，在幫你定義好個別 UI 元件所相對應的事件處理函式之後，在其內的實作程式碼，仍是需要由開發者自行撰寫，並且往往也需要在此寫上關連與其它 UI 元件的狀態操作等。UI 元件彼此之間的狀態連動可能會牽涉到很廣，若沒有一個好的規範，則常會出錯，而這往往也是造成複雜畫面凌亂難以維護的主因。這裡 Horrocks 提出了對 UI 設計極為重要的 UCM (user interface-control-model) 架構 (p.28)，藉以釐清在 UI 元件、事件處理者 (event handler)與控制物件 (control object)三層之間的責任分派，你會發現到層次分明的好處就在於 Event handler 並不直接處理邏輯，而是交給控制物件來統一維護所有 UI 元件的狀態，而讓 UI 元件回歸到最單純的責任—視覺化的呈現。其實 UCM 就是等同於現在 Java Struts 所提出的 MVC 框架 (Model-View-Controller)，只是名稱不一樣而已。 不過切記，這可是僅此在 UI 展示層 (presentation-tier)對 UI 設計的 MVC 而已，而非對企業整體系統的三層式 (3-tier)的 MVC 架構喔，可千萬不要把兩者混淆在一起，而導致 UI 層與企業邏輯層的耦合性 (coupling)太重。本部分最後一個章節則開始介紹狀態機的設計語法，並藉此來比較有限狀態機 (finite-state machine)與本書所揭露出狀態圖 (statecharts)的不一樣之處。其實說真的，有限狀態機仍是與狀態圖本質是一樣的，均是捕捉狀態的轉移，差別主要是在於有限狀態機並沒有層次的觀念，所以會在一張設計圖上表達出太多的細節，這並不妥，我們可以把許多呈現出好像很複雜的狀態轉移，群組起來，再抽象出更上一層，而封裝了內部複雜的狀態轉移，成為超狀態 (super state)與子狀態 (sub state)的層次關係。

第二部分是對 statecharts 基礎技術的建立。包括了構成狀態圖的諸多表達語法，以及也要瞭解到現實上狀態的各種變化情形，包括了上述所提的層次深度、並行、延遲與逾時、瞬變 (transient)狀態、事件的優先、參數化的狀態等。這裡我覺得最有意思的是歷史機制 (在狀態圖上是以 H 加上圓框符號構成的)，在轉移出超狀態、又再次轉移進入後，到底是要進入哪一個子狀態，這就端賴於“H”這個歷史狀態記錄了，是非常實用的一個技巧。本部分後半章節，開始教你 step-by-step，如何從畫出狀態圖開始，並對每一個狀態命名、給予狀態變數，再整理成一張“事件-行動表 (event-action table)”，未來即是可以依據該表格來轉化為程式碼的。第九章則是提供給讀者在設計狀態圖上的提示與原則，未來在實作設計上，可是經常回頭翻閱本章，會帶給設計人員許多的啟發。
第三部分提供了三個案例分析，從計算器、But Reporting 到學生資料庫應用程式等，讓你實際看到這些應用程式的畫面呈現，以及是該如何利用狀態圖來捕捉這些複雜畫面的狀態轉移情形。大致瀏覽一下，也讓你可以知道頂尖的 UI 技術團隊，在設計 UI 畫面時所用到的技巧與其開發程序。

看到四分之三的內容，讓許多讀者會挫折的是，怎麼還是不知道該如何將狀態圖轉移到實作的階段？ 第四部分總算揭露出轉移到實作程式碼的階段與步驟了。不過 Horrocks 僅列出實作狀態圖的程式設計步驟 (p.187)，以及以虛擬程式碼呈現而已 (看起來應該是以 Pascal 語法來表達的)。並沒有列出相當完整的程式碼範例，這讓許多想要“眼見為憑”的讀者會大失所望的。不過真的要堅持，當初我整整花了一個星期以一個“紅綠燈+方向燈”的控制器案例，從狀態圖的塑模，到實作出 Java 程式碼，當在畫面上可以秀出紅綠燈號的狀態轉移，並且是依循狀態圖的設計規格來實作，這也代表者我即使在 C#.NET 實作，設計圖都不用變動，那種成就感真的是相當喜悅。

高品質的 UI 畫面從狀態圖設計開始

我對本書相當著迷，也為此實作狀態機圖的程式開發，並將之整理成教材納入在 我所教授的 UML 的課程教育上。但是在實務上是否有必要利用狀態圖來設計畫面呢？ 我是以為若產品開發是要能呈現在多個平台的畫面上，那真的是有必要，它可以讓可攜性與維護性提高。還有曾有讀者問過我，UI 設計該如何作測試呢？ 當你作好 UI 的狀態圖設計後，也就代表了可以針對 UI controller 撰寫測試程式碼，依據測試案例來作自動化的測試，達成高品質的 UI 設計，無論是對 ASP.NET, JSF, AJAX 等 UI 框架，道理都是一樣的，好處真的是多多。
我發現到本書在 Amazon 評價是四顆星，有趣的是，11 位評論者有 6 位給滿分五顆星，3位給四顆星，另外兩位則只給 1 顆星。給一顆星的理由是因為看不懂，所以無法應用在實務上。這實在可惜，那6位給滿分的可是評價甚高，而事實上，能專注於狀態機圖的設計書籍，實在少之又少，況且又能協助你在 UI 畫面的設計上，並以釐清複雜事件處理的狀態控管，實在了不得。喔，還有，本來我以為眼花了，當初我在「天朧書局」買本書時只有 NT$ 750，但在 Amazon 看到的價錢是 U$ 200 元，二手書也要 US$ 180 呢。看來應該是絕版書籍，物以稀為貴吧，同時也證明本書的價值的確是經得起考驗的。

延伸閱讀：

• {iThome 書評—8} Object-Oriented Analysis and Design
• {iThome 書評—7} 重構—改善既有程式的設計中譯版
• {iThome 書評—5} 深入淺出設計模式中譯本
• {iThome 書評—4} 極致軟體製程中譯本
• {iThome 書評—3} 使用案例寫作實務中譯本