副標題：懂得從各問題領域的表象中跳脫，而能直指其核心的本質，才是軟體結構分析的根本所在！！

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.讓系統更有彈性，來順應變化。 第一個只要有不錯的實作能力，以及功能需求的分析能力即可；第二個則需要有對平台的專業知識能力，能充分發揮系統的效能特性；第三個那可真的需要對軟體的“道”有著長期持續的信仰與熱情方可。我是以為，若能進入到第三個層次，修練該層次所傳授的法，那絕對會是一種無以言語的喜樂。不過，現今國內軟體產業重視速食文化，大約只要求在前兩個層次，第三個層次，曠時廢日，不太容易短時間內有著顯著的實質回饋，因而堅持者甚少，殊為可惜。