上上個星期，應國防某單位要求，希望由我們利用 EA(Enterprise Archiect) UML 工具，藉由一個案例，來展示在順應 DoDAF 規格下，如何從架構規劃、到依循每一個包括 Operation 與 System View 的設計圖，以及又該如何導出到實作，尤以後者，對他們很困擾，一直不知道該如何將 DoDAF 設計與實作順利地橋接在一起。

其實原來是上個月初過去介紹的是 EA 的 UML 工具，因為 EA 其中一個 Plugin 產品，稱為 MDG for DoDAF-MODAF，兩者的搭配，應用的是 UML Profile 機制，可以充分完整支援 DoDAF 1.5 的設計規格。 說真的，工具沒啥好介紹的，況且席間諸多長官與教授們問最多的問題就是有沒有 "自動化" 的機制，可以從某一個 View 的設計圖，自動轉化到另外一個 View 的設計圖。這個... 我總覺得他們研究的方向會不會有問題？ 我只能反問：1. 如果規則明確，例如 OV-2(作業節點連結) 轉 OV-5(作業活動流程)有很明確轉換規格的話，那麼工具當然可以支援。 (可想而知的答案是，當然沒有那種必然明確的規則) 2.能不能轉到程式碼？ 這些我都覺得都不是問題耶，前提是有沒有那種確定的規則？ 有趣的是，他們用來比較 EA UML 工具的是另一套 T牌、要價 100 萬的工具，也沒有支援他們 "心目中" 的自動化啊。 所以我開玩笑的說，好吧，把那個 T牌與 EA (EA+DoDAF Plugin 才 1萬初頭)的差價，用來委託我們開發那個自動化的 Transform 機制，保證可以幫你們生的出來，不過前提是要能給我們明確的轉換規則。 :-)

我可不會想賺工具的錢啦，要能懂得設計符合 DoDAF 架構規格的系統，要具備的是軟體設計基礎功夫的底子；要能有整體性的架構觀，要知道什麼時候該封裝、什麼時候該打開，分析系統的內部；要懂得如何把一個看起來好像很大的系統(關於系統的定義，可不一定指軟體系統，在這種大格局下，包括企業單位，都可能是一個系統)，該如何大題小作；又懂得那個時候該具焦在某一個焦點上，然後小題大作。 這一種整體性的設計思維，正是架構規劃與設計箇中的竅門之所在。

我想要傳達的是，我們可以協助國防某單位，如何具備能具有規劃 DoDAF 架構設計的技能(Skill)，與相關軟體設計的基礎功夫，以及所該具有的技術實作能力。當然就是以顧問輔導與教育訓練為主，如果可以的話，規劃成一個外包的專案更是好，然後從實作的過程中帶著學習，作中學的效果會更好的。 不過前提是，我們總是要能先證明我們懂得如何規劃這類超大格局符合 DoDAF 規格的系統，一般當然就是出個題目了，這一向是我個人最為意願的了，比較容易在短時間內取得雙方之間彼此的信賴與共識；也比較現實，會就會，不會的話早一點出局，最不囉唆了。 喔，還有，這是繼我十餘年前從志願役中尉預官退伍後，再一次能回到軍中，為國效勞的好機會呢，哈。

由於國防某單位最近忙了些，等了幾星期，還是沒拿出案例讓我們來演練，所以只好我們團隊內部自行構思一個與軍事相關的案例。 所以呢，這個案例是沒有與軍事任何單位有關連(正因如此，才能拿出來公開分享)，完全是充滿想像；也沒有軍事專家的協助，所以需求必然是謬誤百出。不過這也不是什麼困擾，因為我們要做的是如何能捕捉出 DoDAF 的架構規劃與橋接到實做階段的那個精髓之所在。只要未來能有軍事領域專家的協助，那麼就很容易可以調整修正，來符合正確的需求了。

整整花了四天的時間，投入了約 2.3 個人力，以一個我們所想像創造出來的案例，也算是規劃了一個類似 C4ISR(Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance) 的聯合作戰指揮系統，透過偵測與防衛系統，發現到敵人即將進軍來襲時，是如何即時協同陸、海、空三軍暨後勤補給中心，來達成防衛作戰的目標。 包括了 Operation、System View 共約 17 張設計圖、再加上利用 .NET 程式碼來模擬諸多系統間的即時互動(透過 Web-Service)。 喔，甚至連那個表達 OV-1 的概念視圖，都還是請美工畫出來的呢，效果十足！ 老實說，個人對我們團隊能在如此短的時間內，就能規劃出如此大的架構格局，甚至還產出程式碼來驗證架構的完整性。藉此而能解開 DoDAF 這個算是軍中資訊人員們的 "潘朵拉密盒"，可說是成就感十足，也算頗引以為傲。

圖 1、 利用 EA-DoDAF 開發的 SV-1 設計圖

所完成的案例在上上星期至國防某單位的 Seminar 展示效果相當不錯！ 在座許多高級長官以及教授們在會後的許多問題透過我們的解說，也算能得到合理的解釋。也讓許多中、上尉的資訊官們，見識到我們是如何從某一些 View 再轉到微觀(Micro)的實做階段。 由於沒有軍事機密等的問題存在(案例全都是想像的)，所以到是可以藉由公開發表這一個案例，除了展示是如何實現 DoDAF 規格，並大概解釋一下每一個 View 的 精要(essential)設計意涵為何，同時也算是藉由此，來看看這種偏多個節點(Node)、多個資訊系統是如何做架構規劃的。

對了，還是要簡單說明一下 DoDAF/MoDAF 架構框架到底是幹什麼呢？ DoDAF(Department of Defense Architecture Framework) 是美國國防部、MoDAF(UK Ministry of Defence Architectural Framework) 則是大英國協軍方的規格。 其目的旨在規範承包包括武器、資訊技術系統等的外包廠商，透過多個層次的角度(Multiple Views)，能夠以標準化、一致性，來組織包括企業架構(Enterprise Architect)，以及系統架構(System Architecture，這裡意指資訊系統)，而能有具標準、一致性、多層次的設計視圖與文件等符合軍事要求的規格。 DoDAF/MoDAF (因為國軍主要仍以美軍的規範為主，所以整個架構規格，均以 DoDAF 為主，但其實兩者的規格差不多)的規格是公開的，可以自由下載來研究參考的，下列鍊結提供了這些規格的說明與下載位置：
　o DoDAF Wiki。
　o MODAF Wiki。
　o DoDAF 1.5 Volume 1(pdf)。
　o DoDAF 1.5 Volume 2(pdf)。
　o DoDAF 1.5 Volume 3(pdf)。
　o DoDAF 1.0 Deskbook。

至於關於如何使用 MDG for DoDAF/MoDAF Plugin (前提是要先安裝 EA UML Tool)，參考 這裡。
安裝完這個 Plugin 的好處是可以看到完整的 DoDAF 案例。(雖然我覺得裡面有些視圖的設計不太正確，但還是需要參考這個工具所提供的案例，才能知道如何使用 EA 工具來規劃設計。)

圖 2、 EA-DoDAF 所提供的 DoDAF 樣版(Template)

DoDAF 主要包括了兩個大層次： Operation View and System View。 Operation View 包括從 OV-1 到 OV-7； System View 包括從 SV-1 到 SV-11。 在我們所演練的案例內的設計產出擷取部分精要的設計視圖，參考下面兩個表。

我想爾後就會針對我們所設計每一個 View 的設計視圖，來簡單地說明該視圖的設計意涵為何。 另外，我們並沒有表達 TV (Technical View)，主因在於這個 View 幾乎都只是表達技術規格的詳細文件報告而已。

對啦，一個有趣的問題可以思考看看。參考一下底下這張是給指揮官層級看的概念視圖(OV-1, Conceptual View)。考驗一下，作為一個架構師(Architect)，看到這張圖的時候，是否可以腦海中馬上浮現，可以如何以 UML 2.0 規格中的那一張設計圖來設計表達呢？ (提示一下，即使從如此大的概念視圖，也要能看得出你要規劃的系統那個整體(Whole)是什麼？ 誰會觸發這個系統的反應？ 這個系統有無外部系統的支援？ 系統內部的組成主要結構元素為何？ )

圖 3、 EA-DoDAF 範例中的 OV-1 概念視圖

副標題：運用物件導向思維與 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)！！ 而後參考企業塑模的產出，就可以很清楚地瞭解與規劃，哪一些企業流程的活動，是可以經由資訊系統的協助，來達成自動化或減輕工作人員的負擔。

上個星期六開始，連著週六、日與本星期六(昨天)共三日，是對高雄某家大型醫院的資訊中心教授軟體設計課程，這已經是連續三個星期到高雄授課了，而其中兩個單位都是醫院，還真是巧。

透過兩個醫院的授課，才讓我瞭解到，原來醫療系統幾乎都是內部的資訊中心自行開發的，這與我原來想像系統大部分是委外開發的，大有不同，而據他們告訴我的原因，主要在於維護性的問題，所以無法全權委外，因為變動性的問題，委外單位不足以快速反應變更。

然後再更進一步瞭解，開發的系統範圍很廣，從典型的門診掛號系統、看診系統、藥劑管理系統，到甚至是人事系統，都需要自行開發。喔，這就是典型的醫療 ERP 系統啊。我常戲稱，什麼叫做 ERP(Enterprise Resource Planning) 系統呢？ 不知道開發範圍的，就是 ERP 系統啦。

此次該單位找我授課的主要原因是，他們希望透過所謂的 OO 物件導向技術，來協助他們改善系統的難以維護。因為他們導入了 OOP，但是怎麼覺得用 OO 設計出來的元件，一方面很難開發，二方面好像沒有感受到 OO 的美好，好像系統也沒那麼有彈性，所以希望我透過教學，並檢視他們的開發成果，能給予他們一些建議。

原來上星期的授課，是與之協調後決定要講授 「UML 三劍客」的課程內容，那是以使用案例的需求為優先，然後快速導出到實作，是很有效的一種務實的作法。 不過上課了一天後，該單位包括較資深的技術長等資訊人員，問了很多現實他們遇到的問題，也拿出了部分的開發成果請我協助檢視。 我發現到，他們更在乎的是系統的共用性議題，當然還有關於物件的實作議題。 這些反而不是需求性的議題了，而是在於系統內部的結構性設計議題，以及實作面如 O-R Mapping 的系統設計問題了。

我對課程內容的態度是，一切都是彈性可以調整的，不會是一成不變，是可以視各單位現實的需求，動態甚至利用他們的案例當場馬上作分析並導出到實作。所以第三天的課程呢，我就給它調到了對結構分析這部分的重點來了，並且此次也請了我們另一位講師 Steve，協助來講授從領域模型轉到 .NET Coding 實作的部分。

嗯嗯，為 OO 而 OO，一向是我最反對的。我發現到，有太多所謂 OO 的開發，對於物件在中間層的實作，幾乎都僅在於對資料的存取。 所以設計出來所謂的企業物件(business object)，根本就是資料物件(data object)而已，而為了資料存取，去設計與實作出這麼多的資料物件，實在沒啥意義的。 設計企業物件的重點是在於對於企業邏輯的處理，如何分門別類、然後把責任(企業規則)分派在適當的物件上，才是所謂物件導向的精髓。 這可是相當不容易耶，領域概念轉成軟體物件，要能抓得好，又要能適切地分派責任，再加上還要能轉成到現實平台上，包括 O-R Mapping 的設計議題，以及包括對 Performance 的資源控管等，這可是要結合領域專家、IT平台專家、與軟體專家的，缺一不可。

仔細分析，若絕大部分只是資料的存取，而且一般仍對企業規則到底要分派到那個物件上，其實沒那麼重視 (若是產品的開發，這個就很重要了)；不過他們很渴望能將分散在 UI表單(script-based)與資料庫(stored-procedure)內的企業邏輯，給集中控管到中間層來，這是相當合理的，也可以說是許多傳統 Client-Server 2-tier 的軟體系統，來轉移(migrate)到所謂 3-tier，降低 UI 與 資料庫的耦合(coupling)性，是最必然的設計開發議題。 將企業邏輯集中在中間層是正確的作法，只是倒不是要絕對馬上就設計所謂的企業物件，那個難度真的相當高，可是要耗費掉相當多的開發成本的。

嗯嗯，有兩個字彙，倒是軟體人員也可以思考一下。 一為 Revolution；另一為 Evolution。前者我把它翻譯叫做 "革命"，後者我是稱之為 "革新"。兩者哪裡不一樣？ 革命是要抱著不成功便成仁的二分法；而革新是採漸進的作法，一次只改一點點，有了成效後再往前推進。 前者當然會比較快，但要相當有決心。只是，說真的，我幾年來看到的幾位是物件基本教義派的先烈們，似乎．．． 要求老闆給他們資源，來導入所謂的 OO 系統開發，但好像不幸都壯烈成仁了，專案毀了，人也跟著離開軟體業界了～

喔喔，聽了我的說法，他們好像不願意採取革命的作法，所以問我革新的作法如何作？ 其實呢，並不難，為每一個需求的案例設計一個控制型(control)的物件，先讓其真的有實體三層的結構，把從 UI 與資料庫的企業邏輯給集中起來。 事實上，控制物件往往也具有 BPO(business process object)物件的性質，它可以針對某一個特定的需求功能，至資料庫撈出所需要的關連資料作處理；也可以具有 "wrapper" 物件的角色，可以呼叫原來就已經寫好放在資料庫的 stored-procedure，"ReUse" 原來就有的企業邏輯。 要光是能做到這一個階段，算是功德無量了，這起碼已經進展了一大步(從實體的 2-tier 到 3-tier)，風險也不高。 下一階段待老闆真的相信(不要太期待老闆會看得遠，大部分是很現實，他們要能眼見為憑)，且肯願意投入更多的資源，此時真的要去找出所謂 "共用" 超穩定的企業物件，或是要從原來寫在 stored-procedure 的企業邏輯，抽絲剝繭，這就是結構重整的範疇了，從程式碼的角度來看，好像就是最近很熱的重構(Re-Factoring)—不影響既有功能的前提下，對系統內部的結構元素作重整，使得系統更有彈性。

很多問題，其實根本不是問題，常常是因為局部雜亂無章、沒有整體性考量，才去衍生出來的問題。只有透視問題的本質，找出根本的原因，釐清對的方向後，再來就是審視現有的資源與環境，採取務實的作法，一次只解決一個問題，而不是把所有的問題來拿出想要一次解決，這比較有可能把事情做好。沒這麼困難、沒這麼困難的啦。

昨天，最後一天星期六的課程結束後，我還與那個 Steve 走到高雄火車站附近的「六合夜市」吃小吃。 其實夜市規模不大耶，甚至還比我們家中和附近的「興南夜市」還小一些、人潮還少一些呢。 我們先是吃了有家是店面的「台南擔仔麵」，客人很多，哇！ 麵與小菜等真是相當好吃，在台北還沒吃過哪麼好吃的，只是麵量蠻少的，而價錢其實還有些小高。 還吃了那個什麼 蛋蛋魚，以前都沒聽說過，那個攤位還有與人手臂一樣粗的花枝，開玩笑，對於大的東西，我一向不敢吃。然後又買了烤蝦、菱角酥、新疆烤肉、酪梨牛乳等，拿到高鐵火車內享受。 只是，不好吃，那個烤蝦啊，看來是先用開水燙過，然後客人要點時烤一下作個樣子而已，很不實在。 回程從夜市坐計程車到左營高鐵站， Steve 說，怎麼每條路都比台北的忠孝東路還寬，人潮又很少。 喔，高雄真的地大人少，天氣又好，真是個居住的好地方。

※ 延伸參考：
　o 連著三天在三個單位的輔導與授課 (2008/04/15~17)

從使用案例圖中，可以明確地定義出系統的設計範圍—系統需提供哪些服務(每一個功能點服務即為使用案例)、誰會來使用系統、系統是否需要其它系統的支援。這對開發團隊的每一個成員，能具有整體性的共識，是相當有助益的。 再來就是決定優先開發的使用案例，通常那是對系統的利益關係人(stakeholder)而言，最有價值的，優先開發！ 屬於企業服務層級的系統，屬於商業交易型的使用案例，通常是最具有價值的。 以「博X來訂購系統」為例，《訂購商品》與 《結帳商品》兩個使用案例，會是該系統最有價值的需求服務，參考如下圖1。

圖 1、找出價值最高的使用案例優先開發

對於需求分析師(requirement analyst,RA)而言，為每一個使用案例來寫出使用案例的需求陳述(use case description)才是最重要的。 使用案例敘述要能寫得好的訣竅就在於，只專注描述參與者(actor)與系統的互動對話；也可以這麼說，當參與者(一般為使用者)在使用系統上線的期間(session)，RA 要能觀察出參與者與系統會有幾次的訊息傳遞(message passing)，然後將之寫成具散文格式的動作步驟，到完成最後一個步驟時，系統即能滿足參與者使用系統的目的。

下表是針對上圖1 的每一個橢圓型使用案例來寫作使用案例敘述。 使用案例敘述的格式並沒有標準，不過最主要的欄位是必然會有一個表達正常情節(scenario)的事件流程(flow of events)，以及一到多個表達例外(exception)或擴展(extend)情節的處理陳述。

看起來好像有許多個使用案例敘述？ 其實不然，這就是圖形的迷思，雖然 UML 規格是定義被《include》或《extend》的每一個橢圓也算是一個使用案例，不過當從參與者的角度來看時，上圖1非常明顯，只有兩個目的：《訂購商品》與《結帳商品》，所以其實 RA 只要寫出兩個完成的需求案例敘述即可。若是堅持要遵守從圖形中為每一個橢圓來寫需求敘述，如此可能會太分散而造成沒有一致性閱讀的感覺，不過這到不是絕對的，每一個團隊可以找出適合自己風格的寫作方式。 在此例我是以後者的方式來寫作的，原因是在於可以利用 UML 工具的文件產出(document generazation)功能來快速整理出符合客戶或公司所需的需求規格報表(requirement specification report)。

還有一點要留意的是，使用案例的敘述內不要詳細的去記錄如 欄位明細、查詢條件、企業規則(business rule) 等，參考下表，我會把這些經常會變動的細節中括號起來，然後會註明在另一份的文件，或是利用如 EA UML 工具，可以將這些細節整理在在該使用案例其它欄位內(如 constraint 欄位)。

訂購商品
Pre Condition
1.	使用者已登入 (Logon)系統。
Basic Course of Events
1.	使用者可以瀏覽各類商品資訊。
2.	Inclue <<放入購物車>>。
Alternatives and Exceptions

放入購物車
Pre Condition
Basic Course of Events
1.	使用者選擇一件商品放入購物車內。
2.	系統列出 [購物車明細]。
Alternatives and Exceptions
*取消購物車內商品
2a. 使用者可以取消購物車內的商品。
Require
[購物車明細]
商品明細、優惠價、數量、小計、庫存數、商品總額。

結帳商品
Pre Condition
Basic Course of Events
1.	Inclue <<選擇付款方式>>。
2.	extension point <<更新基本資料>>。
3.	系統列出本次 [訂購明細], [付款方式與寄送資訊]。
4.	使用者確認並送出訂購資訊。
Alternatives and Exceptions
Require
[訂購明細]
商品明細、優惠價、數量、小計、現貨庫存、訂購總額
[付款方式與寄送資訊]
付款方式、聯絡人、寄送資訊

選擇付款方式
Pre Condition
Basic Course of Events
1.	使用者可以選擇系統列出其中之一的付款方式。
2.	extension point: <<選擇付款方式>>。

選擇7-11門市 
Pre Condition
Basic Course of Events
1.	使用者輸入 [選擇7-11查詢條件]。
2.	系統請 統X EC 系統列出符合條件的 7-11 門市資訊。
3.	使用者選擇其一欲取貨的 7-11 門市。
4.	系統記錄使用者所選擇的 7-11 門市。
Alternatives and Exceptions
Require
[選擇7-11查詢條件]
查詢條件可以是以縣市、路名或門市名稱。

※ 延伸參考：
　o 三論「博X來」— 訂購商品與結帳是否是同一個使用案例？
　o 再論 博X來「選擇 7-11 門市」功能設計
　o 實在難以忍受的網路購書流程

這一次倒不是要 "批判" 博X來的訂購系統，而是想藉由該資訊系統，來聊聊需求分析的設計議題．．．

我們知道，博X來的訂購系統，存在的最大價值，就是提供客戶「訂購商品」的服務，而為了滿足客戶最終能買到所訂購的商品，所以會有包括如「放入購物車」、「快速結帳」等程序。如果妳是一位需求分析師(RA, Requirement Analyst)，那麼在分析以使用案例 (use case)為功能點單位 (functional point)的時候，妳會分析出 "多少顆" 使用案例呢 (只涉及到上述討論訂購商品的範圍)？

我經常思考這類的需求分析議題，也曾就該問題與其他資深分析師討論，有人認為是兩個，也有人認為是一個，當然也有人認為是三個、四個...等。 好像是見仁見智，沒有所謂標準明確的答案。 我是在想，能否有一種簡易判斷的 "準則"，來決定使用案例是一個或多個呢？ 老實說，從諸多國外名家 (包括創始者 Ivar Jacobson)對使用案例的定義，我仍不容易釐出那個準則，所以我是想透過觀察使用案例的行為，來找出那個判斷的原則為何。

先觀察實體書店一般的購物程序：客戶走入書店，瀏覽與選擇欲購買的商品 (書籍)，並放入購物籃內 (拿在手裡也算，代表已準備好欲購買的商品)，並拿到櫃臺，結帳並付款。

所以幾個使用案例呢？ 我肯定是認為一個：《購買商品》，因為客戶來這個系統 (實體書店)的主要目的就是 購買商品，而為了滿足該目的，他必須經常放入購物籃、結帳等程序，而且整個交易事件的程序 (從放入購物籃到結帳)是有持續的，約幾分鐘到幾個小時就可以完成 (＊注意此點)。關於傳統書店使用案例圖的表達，可以參考下圖1。

圖 1、實體書店購買商品的使用案例圖

在使用案例圖的表達上，看起來好像是三個使用案例，其實本質上只有一個：《購買商品》。這裡利用《include》這個 stereo type，只是來凸顯《放入購物籃》與《結帳商品》這兩個子程序而已。

再回到博X來網路訂購系統來看，那麼是否訂購商品的程序與傳統實體書店的購買商品程序是一樣的呢？ 看起來很像，都有 放入購物籃 (網路上稱為購物車) 與 結帳 兩個程序。只有一點不一樣，放入購物車 與 結帳 可以是兩個不同時間點的交易事件。什麼意思呢？ 當客戶瀏覽商品資訊，若是看到打算購買的商品，就把它放入到購物車內，但是客戶並不需要馬上結帳，他可以等過幾天再決定是否結帳。所以很明顯的觀察到，這是兩個可以在不同時間點個別可以獨立完成的交易 (＊這一點與實體書店不一樣)。 (不過，這兩個交易事件好像又有些關連存在，要 結帳 前必須先有商品 放入購物車，關於此點，留待後述來討論。)

所以，我的觀察與心得是什麼？ 我會以為，若是可以獨立在某個時間點可以完成的交易事件，我會把它就視為是一個使用案例。或者再用更通俗的一句話來說，就是參與者在使用這個系統，從上線到離開的過程，可以 "一氣呵成" 地來完成一個功能案例，該功能案例就可以獨立成為一個使用案例。 所以，博X來訂購系統對於 訂購商品 的主要目標上，會有幾個使用案例？ 我是會把它切為兩個：《訂購商品》與《結帳商品》，參考下圖2。

圖 2、博X來訂購商品與結帳的使用案例圖

為何使用案例是命名為《訂購商品》而不是 放入購物車？ 我會從 參與者 (Actor,本案例為客戶)的角度來看，客戶的目的是訂購商品，而放入購物車只是在訂購程序中的其中一個子程序。同樣地，這裡也是利用《include》來特別凸顯 放入購物車 這個重要且必要的程序； 而在《結帳商品》這個使用案例，客戶的目的的確就是要處理結帳，所以命名上這樣是適合的。但是因為如前所述，這兩個使用案例又有某些關連存在，可否使用《include》來表達這兩個使用案例的關係？ 不可，絕對不可！！ 我很肯定此點，從使用案例圖來看時的一個最大迷思就是，許多 RA 會以為被《include》的那個使用案例是另外一個使用案例，其實不是。 再強調一次，參考如圖2所示，《訂購商品》 "包含 (include)" 《放入購物車》，它們是同一個使用案例！ 要表達兩個完整獨立使用案例的先後順序關係其實很簡單，就是在《結帳商品》這個使用案例敘述的 precondition 欄位中，說明使用該使用案例前，必須先完成《訂購商品》的使用案例即可。或者也可以直接這樣描述：要使用這個使用案例前，在該用戶的購物車內必須要有待結帳的商品。

另外，依照該訂購系統的實際結帳程序來看，我也會在案例圖上特別來凸顯兩個子程序： 選擇付款方式 與 更新基本資料。 前者是必然需要執行的程序，所以是利用《include》來表達；而 更新基本資訊 則是不一定需要執行，所以是利用《extend》來表達它是一個可具選擇性 (option)的子程序。 然後在 選擇付款方式 這個子程序上，因為它可以具有多樣化的付款方式，所以在該子程序的文字敘述上，只會在這個子程序上描述付款的基本行為，然後會在各種的付款案例上再來描述個別的付款行為。利用《extend》來關連主程序會來得有彈性許多，未來若是又有新的付款方式的需求，那麼只要再加上一個特殊化的子案例即可。

利用 "一氣呵成" 這個原則來判斷是否為獨立的使用案例時，要注意的前提是：系統必須是軟體資訊系統，而不能是企業，也就是把企業當作系統來看待。 探究其原因就是對於所謂什麼才叫做是一個完整獨立的交易事件，軟體資訊系統與企業的界定方式並不一樣。 在軟體資訊系統，一個獨立的交易事件可以是幾分鐘到幾小時，但是再長似乎就不適合了 (事實上，對於 EC 系統，連幾個小時都可能不恰當，交易時間仍嫌太長)。而對於企業層級的使用案例，所延續的時間會相當長，甚至可能長達數十天、數個月。例如把「信仁慈善醫院」當系統，《看病》是一個完整的使用案例，但是看病的過程可能包括了掛號、看診、領藥等，這些程序可以綿延好幾天，所以利用 "一氣呵成" 來判斷就不適用了。那麼要如何判斷企業層級的使用案例呢？ 我是以為，從使用案例的 "價值" 來判斷，可能會比較恰當。想想看，雖然是「信仁慈善醫院」，但它仍需要要營收，而營收的主要來源正是病人來看病所得來的，所以 "看病"，會是一個很明顯有價值的企業層級的使用案例。

※ 延伸參考：
　o 再論 博X來「選擇 7-11 門市」功能設計
　o 實在難以忍受的網路購書流程

先前因為在 博X來 訂購書籍的過程時，卡在選擇 7-11 門市的小功能這邊(據稱當日有部 Server 故障)，有感而發寫了篇：「實在難以忍受的網路購書流程」。不過不滿歸不滿，後來我還是在該網站陸續訂購了有約 10 來本書籍，可以說是他們的忠實客戶。倒是後來該篇文章有許多網友們的諸多回應，其中也有提到了 EC系統整合 的議題。 系統整合？ 一開始看到我還稍微愣了下，雖然我本身的工作就是專注在軟體系統的架構整合，不過我倒是沒想過 {選擇 7-11 門市} 這個小功能有如此慎重。因為，從單一目的來看，真的很單純，就只是 {提供 7-11 門市} 的資訊，在這個時間點可沒有涉及到還有物流出貨什麼的，那是等系統收集到完整的訂購資訊之後，也就是真正客戶按下 {確認訂購} 按鍵之後，訂購系統才需要去處理的工作。但在收集訂購資訊的過程中，只要能取得如 門市代號, 門市名稱等未來可供出貨參考的資訊即可。可不要在此時就把出貨流程給牽扯在一起，諸多熟悉領域知識的 SA，有時候就是想太遠了，常常會把簡單的事情給複雜化。

不過，平心而論，該功能雖小，但就從系統責任分派 (responsibility assign)的角度來看，誰需要提供 {7-11 門市} 的資訊？ 統X EC系統。所以自然這就牽涉到了 「博X來訂購系統」 與 「統X資訊EC系統」兩者系統之間的整合，這是合理的。只是，以目前 統X資訊 是尋求從 Web 端網頁之間的互通來達成擴展服務的目的，技術上是可行沒錯，但就是給我一種 "說不出的古怪" 的感覺。思考系統整合的意義：「 系統整合，講究的是以服務為導向 (service-oriented)，透過標準界面 (interface)讓系統彼此之間互通，以達成能擴展更多樣化、效率、彈性的服務為目的。」 統X資訊 是服務的提供者 (service provider)沒有錯，但是，它是提供 "透過各種查詢的方式來取得 7-11 門市 的資訊"，卻沒有必要連 Web UI 使用者介面都要干涉參與。這感覺好像是本來是在 博X來 填寫結帳程序表單時，給 "綁架" 到了 統X EC系統，逼著點選門市資訊後，再給你送回原來的表單畫面，相當的不協調。 UI 最好是由提供主要服務的系統來統籌管理比較理想。在此例明顯就是由 博X來 的訂購系統來負責；而使用者在填寫表單與取得相關服務的過程中，不需要也不會知道這些服務是由哪些系統提供的，使用者只要知道現在幫他統籌服務的那一個系統 (訂購系統)能協助完成他的目的即可，而未來服務的提供者在後端換掉，也不會去影響到前端的 UI 畫面，這是系統整合設計的基本思維。 我是這麼以為，系統整合重視的不是在 UI 層的整合，而是回到源本，系統服務是由擔負企業邏輯 (business logic) 的中間 (Middleware) 層來負責的，自然，整合的焦點應該就是位於系統的中間層，這會比較合理，也會來得有彈性得多。 透過本案例，我想也可以分享一下，所謂的中間層是大概如何的作法，未來又可以有什麼樣的擴展彈性。

參考圖1，這是利用 使用案例圖 (use case diagram)來表達功能需求的觀點。使用者的主要目的是 "訂購書籍"，訂購的程序必然會 "包含 (include)" 《結帳》 的程序。而在《結帳》這個程序中，只有當你選擇 "至門市取貨" 時，才會使用《選擇 7-11 門市》這個子功能，所以在圖上的表達是利用 "extend" 這個 stereotype 來表達《結帳》與《選擇 7-11 門市》案例之間的關係。 當使用者要選擇門市時，門市的資訊是由 統X EC 系統來負責，在圖上是利用表達外部系統的參與者 (actor)來表示。

圖 1、博X來訂購系統《選擇7-11 門市》使用案例圖

先來看一下目前 博X來與統X 的作法，參考圖2 的循序圖。結帳的表單是由 博X來 訂購系統提供的，當要選擇 7-11 門市時，它會重導向 (Redirect)到 統X EC系統 所提供的網頁表單，讓使用者選擇完門市後再將所點選的門市資訊傳回原來的結帳表單。

圖 2、博X來利用網頁重導向方式選擇 7-11

再來看看透過中間層的作法，參考圖3 (這是一個比較精簡的作法，只凸顯加上一個控制物件而已，而在實務上，我是還會再加上如 "Query7-11_Adapter" 這樣的 Boundary 物件。另外，這裡也先忽略了與內部的資料庫溝通，只凸顯與外部系統的溝通。)。 只要 博X來 訂購系統需要外部系統的服務，不會是由表單畫面直接呼叫，一定會透過中間層的控制物件(在此例為 OrderControl)傳達需求的訊息。博X來 的訂購表單畫面可以設定查詢的過濾條件，查詢條件可以是 "縣市鄉鎮路名" 或者 "門市名稱" 等，這是為了避免實際去外部系統 (統X EC系統)一次就撈太多資訊，耗費不必要的頻寬。例如，我輸入 "興南" 或 "三民路" 等，控制物件就會依其查詢條件至外部系統回傳一到多筆資料，然後再選擇其中一筆確認後存回表單畫面的狀態。 統X EC系統只要界定好呼叫的介面就可以了，不用去提供 Web表單畫面 在那繞來繞去的。呼叫的介面可以是 Web Service, Message Queue, 自訂的傳輸協定 ...等，都可以的，大概就是注意一下傳輸效能、穩定與安全性等即可。

圖 3、利用控制物件連結統X EC系統，符合 MVC 結構

控制物件是用什麼寫的？ 那是 博X來 的決定，一般是建議用最簡單、可以使用最久的程式語言規格。例如，在 J2EE 系統，那就是 POJO —最 Pure 的 Java 物件；在 .NET，如標準的 C# or VB.NET 等物件。但不會是 ASP.NET 或者是 JSP, Struts, Servlet 等，那些是屬於展示層 (Presentation)的物件類型。可以發現到，加上一顆中間層的控制物件比想像得還簡單，而且透過該控制物件，最起碼已經隔閡了表單的變動 (未來變換 AJAX 技術或傳統 Windoes Form 呼叫，不會影響到控制物件與其內部)與內部的服務呼叫(是呼叫外部系統或內部資料庫，表單不需要知道)，而這其實只是 MVC (Model-View-Control)的基本應用而已。還有值得注意一點的是，控制物件必然會設計為 "Stateful"，也就是該物件的生命週期 (life-cycle)會持續一直保存狀態至該 session 的結束為止，如此它就可以 "keep" 住所查詢回來的 7-11 資訊，供使用者隨時點選或查詢更詳細的門市資訊 (如果有這樣需求的話)。

控制物件這裡我是設計為兩次性的呼叫，也就是表單第一次先以查詢條件過濾後會列出多筆的門市資訊。我想這裡 統X資訊 其實不用太過擔心效能頻寬等問題，統X EC系統可以設定過濾的把關條件，可能可以限制一次性的呼叫不得超過 100 筆等，這些都是可以規劃的。我是覺得以 "路名" 或 "門市名稱" 來設定條件最普遍理想了，輸入最普遍的 "三民路" 總該不會超過 100 筆吧？

真的很擔心效能？ 我是會視現實環境與未來變動性的考量等，可能估其 7-11 門市未來會成長到上萬家，而目前是五千多家，其實是可以乾脆一次就先把所有門市資訊一次給撈到內部的資料庫的，而成為內部系統的 "快照 (snapshot)"。假如估計每天門市成長一家，那麼可以設定一天或半天由排程系統定期去更新門市資料即可。此時需求的使用案例模型就會變為圖4。然後在內部訂購系統的設計上，只要再加上一顆共用性的 _虛擬DB (Virtual DB) 物件，而 虛擬DB，也沒那麼神奇，它就只是把資料以 RDB 的關連型態，儲存於記憶體而已，在實作上，會使用如 .NET 的 DataSet 物件來實現即可。參考圖5，這是反應加了 "Virtual DB" 後的設計，可以發現到，控制物件對外，根本不需要變動，而內部的變化，也不會去影響到表單的操作等。

圖 4、非同步更新 7-11 門市資訊的使用案例圖

圖 5、利用虛擬DB(Virtual DB)物件提供7-11門市資訊

也有人說，使用 AJAX 技術，可以解決上述所討論的問題。這裡我一併說明，無論是 ASP.NET, Struts, 或 AJAX 等，目的只有一個：就是如何將原來是 Stateless 的 Web 表單模擬成如傳統 Statefule 的 Windows Form。 因為，表單在按下 [Submit] 之前，仍然有許多需要與後端系統互動的機會，所以在互動的過程中，表單的狀態 (state)需要能被保存。 AJAX 可以讓 Web UI 呈現更多樣化簡易使用的使用者介面，但需要查詢或企業邏輯運算等，仍是需要連結後端系統的。這是設計的議題，絕對不會是有什麼所謂的 "銀彈" 技術幫你解決如軟體的變動性議題等。

我發現到，絕大部分 Web EC系統的開發，仍是傳統 2-tier 的思維，也就是 "Client-Server" 的架構，請記得， "browser + Web Server" = Windows Form，這是屬於同一個層級，就是 Presentation 層。在該層級，不要賦予它太多的責任，它只要能專心作好一個工作即可：呈現出美美簡易使用的使用者介面。 至於企業相關的邏輯運算等，那是中間層的責任，所以為何中間層又稱為 "Business Logic" 核心。所謂的三層架構，這是與技術平台沒啥關係的，這是一種設計的基本思維，也是軟體設計人員的責任與基本態度。我會建議 Web EC系統的開發人員，首先就先從瞭解 MVC 模式開始，在現實的實作上絕對會比你想像得還簡單，但系統的延展、彈性度與可維護性等，就起碼會進展一大步。

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

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

剛剛 (03/05 PM23:10) 左右，要向「博客來」網購書籍，點選購物車快速結帳(我發現到，名不其實，根本沒有快速)，光是要選個 {7-11 取貨門市}，點選了好幾次，網頁就一直在那邊轉著，沒有啥回應。吼，已經忍受他們不理想的購物介面好久了，此時實在不吐不快！

我應該算是他們多年來的忠實用戶了，現在買書，幾乎都是在該網站買書的，主要原因可不是方便，而是便宜。對我而言，只要書比外面實體書店便宜、取貨快速(這點博客來被統一集團併購後，透過該物流的確非常迅速)、再來就是買書時簡單乾脆，也就是購書的流程能越簡單越好 (喔，還有啦，最起碼基本資料也不應該被外洩的)。

其它諸如搜尋系統之類的，是另一回事，我主要最不滿意的，就是那個「選擇 7-11」的功能。吼~ 如此差勁的設計，幾年來還是沒有任何長進！！ 我知道他們的作法肯定是把所有的 7-11 店家，以及全台灣省鄉鎮縣市給全部塞到網頁這邊來了，大概就是利用 JavaScript 之類的動態網頁技巧把它給實現功能。介面要作得好，這其實設計與實作並不困難，從需求面來看，舉個例，我就打個 "興南"，就會列出 興字開頭的店家、或是興南路等都可以，簡單的說，我可以利用很隨性的打上幾個關鍵字來搜尋門市，就可以篩選列出店家。我只是列出其中之一的作法，其實要能設計更便利的介面方法肯定有很多種，任何一種我看都會比現在你要透過選擇框，先選哪一個縣市，再選路名，吼(再來一次吼聲)~，我們家中和，每次我要選到那個興南路，總是要用滑鼠拉著捲軸找好久，每次拉我總是嘴裡碎碎唸，什麼時代啦，還有這種介面啊。

我曾經寫過一篇：「Javascript 是爛東西？」，其實要提醒軟體設計人員，不要以為有些資料的取得方式是很固定，不容易變動，且可能資料量不大，所以乾脆先一次給全塞到最前端的網頁來，再透過具有動態效果如 Javascript 的網頁語言來操作存取，就是所有的動作都是在網頁(已經與 Server 無關)給全做掉了。在網頁塞了許多不必要的資料，或是讓網頁這邊處理企業邏輯等，這都不是好的設計方式。

無論如何，像這種大型的購物網站，是屬於交易型的系統，也就是稱之為 OLTP(On-Line Transaction Processing)的企業系統，除了在現實上，效能與穩定是必然的要求外，其實在設計上是蠻重視 UI 與在後端系統 (後端系統我比較偏稱之為 Application Server，而不僅是 Web Server)的互動過程，也就是需要向系統動態要求取得或處理資訊，這是一種屬於對話互動式的設計作法。所以當以 {選擇 7-11 取貨門市} 這個案例來說，使用者 (UI)會需要與後端 AP Server 一到多次(可能會有兩三次吧)的互動，才會取得最後的結果，反而這樣的方式在操作過程中，會比較順暢且簡潔。

我估其他們不這麼做的原因應該是考量到了效能 (performance)，其實這真的也蠻好解的，我再強調，是與後端 AP Server 互動，並不是每一次都要連到資料庫操作的。由於資料量實在不大，台灣全省鄉鎮縣市 加上好幾千家的 7-11，在記憶體也不會佔用多少。所以也可以利用如 "虛擬DB"，也可稱之為 MemoryDB 的設計方法來達成的，是絕對可以兼顧效能與彈性的，沒有問題的。

結果我這篇文章寫了一個小時，再去點選那個 7-11 門市，再一次的給它吼~ 還是不能點選耶！！ 拜託啦，這樣再幾次也會讓如我這樣的忠實客戶給落跑不再去光顧了。如果，嗯，相關單位對該功能還是不知道該如何設計與實現的好，歡迎來找我們聊聊吧，不是只有唸唸空談而已，如何提供具體的解決方案，這點倒是還瞭解的。