OV-5 的表達可說是幾乎與 UML 活動圖表達一般，它會描述在諸多活動之間包括 性能 (capibility), 活動 (activity, 或稱為工作, task), 輸入/輸出流 (I/O Flow)等資訊。

為了呈現某一連串活動所組成的活動圖，其目的為何，則可以利用企業層級的使用案例 (Business Use Case)來表達。

OV-5 精要 (Essential)筆記：

• 利用企業層級的使用案例圖 (Business-level Use Case Diagram) 表達系統的規劃範圍。(本範例為 JFC 系統，亦即將聯合作戰指揮部當作系統)
• 從使用案例可以看出：
  • 系統觸發事件的主要參與者 (primary actor)，與系統的支援性參與者 (supporting actor)。
  • 系統所提供的服務 (service)，每一個系統服務即為一個使用案例 (use case)。
• 區分系統 “內” 與 “外” 時的好處在於：
  • 外部觀點即為功能性的需求分析，是站在外面看待如何 “用” 系統。
  • 內部觀點則著重在系統內部的組成結構元素，一般即以所謂物件導向的分析設計思維。


圖 1、OV5 – Business Use Case (點擊圖可察看原圖)

• 作業活動圖 (Operational Activity Diagram)的重點在於表達什麼人(角色, role)，在什麼時候，做什麼樣的事情(活動, activity)，以及這些活動之間的流程關連。
• 本張視圖的關鍵為呈現 “整體性的業務流程 (business process)”。


圖 2、OV5 – Operational Activity Model (點擊圖可察看原圖)

※延伸參考
　o DoDAF 案例規劃與演練《1》 — OV1(高階概念視圖)。
　o 聊聊 DoDAF/MoDAF 規格與實作議題。

延伸閱讀：

• DoDAF 案例規劃與演練《1》 — OV1(高階概念視圖)
• 以軟御硬的產品整合設計觀—從合成結構圖到使用案例模型
• UML OCUP 題型 Reveiw 與 解析 <1>
• 進銷存系統有幾個資料庫？
• 【iThome 連載單元—4】人面獸身的 ERP 系統–異質平台整合的問題與茫點

兩個主要的觀點： Operation View and System View。 又依照每個觀點所涵蓋的層次(layer) 與 功能性質的不同，又分為 OV1~OV7, SV1~SV11。 有趣的是，即使是 Operation View，也會利用如 UML 的循序圖(sequence diagram)，如 OV6，來表達節點之間的動態互動情形。 而 UML 循序圖一般是被用來表達軟體系統內部，參與物件之間的互動合作關係。 其實這隱含什麼意思呢？ 很簡單的道理！ 在 Operation View，也可以運用物件導向分析的手法，與 System View 所不同的只有：一個是把 Node 當物件；另一個是把 System 當物件；但是相同的是：兩者均用物件導向分析設計的思維來作塑模(Modeling)。

依據「DoDAF Deskbook v1」的建議，Architecture View 的開發步驟可以參考如下圖的各種視圖的先後開發順序。 當然，這不會是絕對的，對我而言，在抓這類大型系統的架構時，首要就是要先能界定出系統的整體框架。當把某一個設計的目標框架，界定為一個系統時，就會分出 "外" 與 "內"，而兩者的分析手法與看待系統的角度就會不一樣了。 "外" 重視的是 "用"，所以會觀察系統所提供的服務，而服務就會衍生出，系統應該提供什麼 "介面(interface" 讓外部的參與者來用；再來 "內" 重視的就是系統的組成元素，這就是屬於結構分析的角度。結構分析觀察的兩個重點是，一個為靜態的結構關係、另一個就是，在動態為了完成某一個 "用" 的功能服務時，會有哪些元素的參與、它們彼此之間又是如何傳遞訊息的。 最終，你就會發現到，到底是如何 "界定" 某一個框架為一個系統，會是架構師最大的課題與其必備的素養了。

圖 1、 摘錄自「DoDAF Deskbook v1 p.2-5」

從上圖中可以看出， 「DoDAF Deskbook」所建議的開發步驟，是以 AV1 開始觸發、以 AV2 涵蓋所有的視圖。 事實上，AV-1 是什麼呢？ "Overview and Summary"。 其實它就是一份 SAD(System Architecture Document)。 文件內容大概就是包含了專案的目的、專案的描述與說明、架構規劃的標的、情境、任務、願景與目標 …等。 也就是說，在未來展開這個系統的規劃時，範圍與目標均是在該文件所描述的範圍之內。 AV-2 呢？ "Integrated Dictionary"，它就是未來在涵蓋所有的視圖內，經常會使用的術語(terminology)，要能給予一個明確的定義及其該字彙的意涵。

所以， "All-View" 只是文件的報告而已，真正的第一張視圖是 OV1— "High Level Operational Concept"。 這一張也可以說是要能涵蓋所要規劃系統全貌最大格局的視圖了。 它是給指揮官以上的層級所看的概念性視圖，所以盡量不要以技術面的角度來表達這張視圖。 參考下圖：

圖 2、OV-1— 高階概念視圖

前述所提，架構師當能從任何一張視圖，看得出系統的 "外" 與 "內"。 並且在心中就要能轉化的出來能表達出整體框架的設計圖。 哪一張 UML 設計圖最適合被用來表達 "外" 與 "內" 呢？ 也就是說，要能表達的出 系統所提供的服務介面，以及系統內部的組件關係。 UML 合成結構圖(Composite Structure Diagram)，可以說是最適切的表達了。

圖 3、將 OV-1 概念視圖在心中轉為合成結構圖

所以，OV-1 的精要(Essential)為何呢？
利用視覺化的視圖協助高階決策者(如指揮官)，以 “鳥瞰” 的方式來看出系統的全貌 (包括系統的外與內部觀點)。

• 開發的系統為何？ (聯合作戰指揮系統)
• 誰觸發(Trigger)系統作業？ (通信雷達偵測系統偵測到敵空降部隊與敵軍機的來襲)
• 系統的外部支援為何？ (UDA, 台美聯防艦隊)
• 系統的內部組成元素？ (各節點，包括直屬部隊、陸、空軍作戰指揮中心、後勤中心等)

再來，我們就會利用戰情演練與情境描述等，來作為系統的架構規劃，以及持續驗證系統的作業。

戰情演練：
「海防部隊接獲情資，敵軍空降約一個營兵力的傘兵，於 0608:1200 在林口台地附近登陸，並往台北方向推進。約此同時，雷達偵測系統偵測敵 20 餘架戰鬥軍機於 0608:1230 往空降地點方向移動，預計約 10 分鐘後抵達林口台地，準備支援敵空降傘兵部隊。」

情境描述：
我軍聯合作戰指揮部 (Joint Force Commander，簡稱 JFC)，偵察與接收到敵軍來襲狀況，指揮官即刻下達決策命令：

• 即刻派遣直屬衛戍部隊，至敵空降單位守衛迎擊，並以殲滅敵登陸軍為主要作戰目標。
• 協調空軍作戰指揮部 (AirForce Commander，簡稱 AFC)，派遣軍機攔擊，並以殲滅敵軍機為作戰目標。
• 即刻派遣防砲部隊，擔負迎擊敵軍機防禦任務。
• 協調台美聯防艦隊 (Union Defense Armada，簡稱 UDA)，防衛與監控敵海軍艦隊，防止敵艦隊登陸。
• 聯絡陸軍作戰指揮部 (Army Commander ，簡稱 AC)，整備作戰部隊、並緊急動員後備部隊，以備後續支援作戰。
• 聯絡後勤補給中心 (Logistics Supply Center，簡稱 LSC)，派遣前線必要物資，啟動後勤補給戰備支援作業流程。

※延伸參考
　o 聊聊 DoDAF/MoDAF 規格與實作議題。

延伸閱讀：

• 以軟御硬的產品整合設計觀—從合成結構圖到使用案例模型
• UML OCUP 題型 Reveiw 與 解析 <1>
• 進銷存系統有幾個資料庫？
• 【iThome 連載單元—4】人面獸身的 ERP 系統–異質平台整合的問題與茫點
• {軟體架構} Tier vs. Layer Enterprise Architecture

其實原來是上個月初過去介紹的是 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 概念視圖

延伸閱讀：

• {程序員邀稿} 以架構為中心的主要設計產出(2)
• {程序員邀稿} 以架構為中心的主要設計產出(1)
• 聊一下「版本控管」與 「Issue Tracking 」的專案開發機制
• {程序員邀稿} 從軟體架構師(Architect)的觀點來看軟體開發流程
• 進銷存系統有幾個資料庫？

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 精華第三版中譯本

Bill Gates 曾於 1999 年在「數位神經系統」一書中提出 DNA (Distributed Network Architecture) 架構，那麼，又與現今當紅 SOA (Service-Oriented Architecture)架構有何異同？

理念相同

　o 業務驅動 IT 技術，科技支援商業。
　o 企業間的協同合作，提供即時精確的服務。
簡言之，即為以服務為導向 (service-oriented) 的架構規劃與整合，讓 IT 與 企業合為一體。

作法不同

　o DNA 走自家的 COM/COM+ 分散式技術，是屬於 “緊密式耦合 (tight-coupling)” 的連結方式；SOA 則走 Web-Service 的寬鬆連結方式 (loose-coupling)。
　o DNA 偏以自家產品 (MS Solution)為中心的整合方式；SOA 則為異質平台的整合方式，依循標準的 HTTP/SOAP, XML 的整合方式。

SOA 的四大特質

　o 簡單
　o 異質
　o 彈性
　o 寬鬆連結

• 不同的平台之間 (.NET, J2EE, PHP/Ruby … 等)，均可以透過 HTTP/SOAP 協定傳遞 XML 資料 (純文字的格式)。
• 利用 WSDL (Web-service description language) 描述 Web服務 的公佈介面 (interfaces)。這是一個基於 XML格式的標準，以描述如何與 Web服務 通訊和使用的服務。
• 因為是寬鬆連結，最好不要期待 Web-service 可以處理交易機制的協調處理，取用一次，完成所需的服務即可。
• Web-service 的本質就是屬於 “state-less (無狀態)” 的機制，若是應用在 UI 與 Middleware 的系統連結上 (如 .NET Form 透過 web-service 連結 J2EE)，需注意用戶端與伺服端的狀態保存與維護。

SOA 的挑戰

　o 如何作整體性的架構規劃？
　o 如何快速部署 (deploy) Web-service based 的應用程式？
　o 如何讓設計比較有彈性，以快速應付外界的需求？

整體性的架構規劃

　o 可以利用 UML 使用案例圖 (use case diagram)呈現整體架構設計。
　o Use Case 本來就是以需求服務為導向的設計，與 SOA 的標的一致，故用其作為架構設計的呈現，最為適合。
　o 每一個由 web-service 所揭露的服務 (service)，會對應至一到多個使用案例 (use case)。

快速部署 WebService

　o 這是屬於系統廠商的責任，包括 MS, IBM (WebSphere), BEA (Weblogic), TiBCO 等，均能提供快速部署 Web Service 的應用程式。
　o 先進的工具還能支援：
　　o 資料物件與 XML 的格式轉換
　　　o Java Bean to XML (反之亦然)。
　　　o DataSet to XML (反之亦然)。
　　o Support XML Schema 的設計與定義。

彈性的設計

　o 這是屬於 Developer 的責任。
　o 這是軟體設計最為嚴謹且為最大挑戰的領域。
　o “應變” 是軟體設計者應有的態度。
　o 可先以 “分層結構 (後述)” 作為系統開發的 “cook book”，先瞭解與熟悉 “委派(delegate)” 的設計手法。

延伸閱讀：

• {程序員邀稿} 以架構為中心的主要設計產出(1)
• 進銷存系統有幾個資料庫？
• 【iThome 連載單元—4】人面獸身的 ERP 系統–異質平台整合的問題與茫點
• 【iThome 連載單元—1】漫談系統整合—誰是老大？
• {軟體架構} Tier vs. Layer Enterprise Architecture

結構面的設計產出

關於軟體結構

所謂的系統結構(System Structure)分析與設計(Analysis and Design)，係指如何正確、有效地分解設計範圍內系統的元素(Element，一般泛指物件(Object))，指派每一個物件所應有的屬性(attributes)與行為(behavior, 責任的分派)，抽象表達靜態類別之間的關係，動態組合物件在執行期間(run-time)的訊息(Message)傳遞，以履行系統的功能需求(ex. 來自於 Use Case 的功能分析)．．．。做好結構分析、捕捉有效的領域概念，以成為系統的主結構，才能建構出堅若磐石的軟體系統，來應付現實複雜系統的善變，甚而讓系統呈現有機的次序成長、生生不息。

如何找出問題領域(Problem)的概念具化成為企業物件(Business Object)、指派每一個物件應盡的責任，並以此來建構系統中的軟體規格模型，已是高階系統分析與設計人員最大的挑戰與應具備的本質學能。更為難的是，如何將企業物件配合現實面的平台，例如如何活用 J2EE Spring and Hibernate 系統框架。因為，現實上，物件的狀態(state)就是被永續(persistent)儲存在資料庫系統內，而在需要用到(企業邏輯的運算)的時候才被活化(activate)起來；同時因為物件共用的議題而需要 AP 應用伺服器的系統支援，包括交易(transaction)控管、安全性(security)、效能(performance)、分散(distribution)等議題的設計考量。兩個層次(高階概念性的分析設計；細部平台面的設計)，互補且缺一不可。

系統的內，也就在於分析所組成的內部結構元素，套現在 IT 的術語來說，也就是所謂的物件導向分析與設計(Object-Oriented analysis and design)。相對於系統的外，是著重在功能性的需求分析(也就是前一期內容所介紹如利用使用案例建構的需求模型)。兩者是互補—找出內部穩定的結構元素(物件,Object)，來應變外部的功能需求。

而系統的結構分析，正是現今軟體人員們最大的罩門所在。在速成短線的專案開發生態，軟體人員只會看到現在所看到的—找出一個一個的功能，快速地利用所提供的平台技術(如 .NET, J2EE)，疊床架屋的方式，Quick and Dirty 快速的給開發出來。不要以為利用 .NET 或 Java 等 OOP 語言，就是所謂的物件導向開發模式，這是兩回事，如果沒有用心地萃取具本質性(Essential)的物件(再一次強調，源自於問題領域的概念術語)，而只是看到一個功能就成為一個 Class，那麼，這樣的系統完全會受限於需求性的變動而導致震盪不穩，是不會具軟體系統的彈性(flexibility)、穩定性(stability)與延展性(extensibility)！

什麼是軟體的結構？

軟體系統的整體呈現是來自於問題領域(Problem Domain)，也就是把該領域中經常溝通的術語(terminology) 對映至軟體系統的物件，稱之為領域物件(Domain Object)或企業物件(Business Object)。 例如，”人事資源(Human Resource) 管理” 系統的開發，其核心的問題領域當然是以 “人事” ，經常溝通的術語會有 “員工(Employee)”、”部門(Department)”、”請假”、”請假細項(AskLeave Lineitem)”、”考績” …等，而這些術語自然地就會被捕捉(capture)至軟體系統內，而成為構成軟體系統主結構(main-structure)的成分元素了。

將組成軟體系統結構的元素組織在一起，並利用視覺化的方式來呈現，稱之為 “領域模型(domain model)”。領域模型代表真實世界中的概念性類別，呈現的是領域中的概念性類別或真實世界中的物件。在 UML 的模型中，最重要也是最必要的一張結構圖也就是類別圖(Class Diagram)。

參考下圖 1，通常使用 UML 表示法呈現的領域模型，凸顯的是概念(concept)，再來則是以及概念之間的關連(association)與屬性(attributes)。例如 “Order”, “OrderLineItem”, “Customer” 都是屬於在該領域中的概念； Customer 與 Order 之間則存在著 1 對 1..多 的關連(一個客戶會有 1到 1..多筆訂購交易)； Product(產品) 具有 description, price 的屬性。在概念性的分析時，細節(包括操作,屬性,資料型態等)在目前並不重要，最重要的是能突顯出概念的呈現，也就是找出類別(Class)。

（點擊圖片鏈接看原圖）圖 1、範例—訂購系統的類別圖(Class Diagram)

那個時候最能表現出結構設計的應變能力？ 筆者常說，當 SA(System Analyst) 遇到 有點像又不太像 這類的需求時，也就是結構設計發揮的時機了。 舉個例，訂購 若會視訂購的類型，可能是書籍、雜誌、百貨商品等，而有不同的訂購流程與處理邏輯，此時，懂得虛與實互補設計之道的 SA，會很自然地把訂購分為一般化與特殊化(generalization-specialization)—把已知的部分放在一般化；而未來要具體實現的部分放在特殊化。事實上，這也才只是利用到多型(polymorphism)的基本技巧而已，就已經足以解決為何程序員經常會為了訂購類型寫了一堆的 switch, if…then…else 這種的條件敘述，而造成程式碼混雜，難以維護了。

如何找出軟體的穩定結構元素，是系統分析人員最大的挑戰。SA 並不需要具備領域知識(Domain Knowledge)，但卻要懂得如何與領域專家(Domain Expert)溝通合作，萃取其知識，並抽象(abstract)成為軟體的主結構。這相當不容易，那並非是純技術面，真正的軟體設計行家，絕對是具高度的抽象的能力，要能懂得從多個構面觀察，時常在反思與找問題(不是找答案)。筆者正是被這在 虛 與 實 均要能互補、一輩子也學不完的軟體設計領域，給深深地著迷，才從原來是系統管理與 Oracle 資料管理師，而至中年才轉到軟體一職來，並已把此視為是終身之職，是要窮究一輩子、甚至帶至下一輩子繼續來修行的。

回歸正題，關於結構設計的好書相當稀少，筆者這裡特別推薦 Peter Coad 軟體大師，從早期 1990年的 “Object-Oriented Analysis”，“Object-Oriented Design”，至 1998 年的 “Object Models”、1999年 ” Java Modeling In Color with UML” 等著作。尤其是 “Object Models” 一書所揭露出以交易為核心的 交易樣式(Transaction Pattern)，更是軟體結構分析人員必讀的聖經。在筆者經常訪問與輔導各領域的公司時，經常在當場就直接展現與證明不用懂領域知識，也能馬上抓出該領域的核心結構，所使用的利器即是 交易樣式(Transaction Pattern)。

另一個結構利器—複合結構圖

複合結構圖 (Composite Structure Diagram)是 UML 2.0 規格所新增的視圖，它相當具有價值，因為它同時融合了 類別圖 與 元件(Component)圖的特質—對外凸顯的是元件所提供(provide)與需要(require)的介面(interface)；對內則表達了元件內部的組件(part)結構；以及介面是由哪些組件所委託(delegate)處理的。

參考下圖 2，即是利用複合結構圖來呈現 BPM (business process management)系統與外部的溝通介面，以及系統內部的結構組件。筆者經常看到諸多由 Workflow 所演進的 BPM 產品，都是將 已知 的功能部分給一窩蜂地 塞 進系統內，但是客戶永遠有第 101 種需求，此時 BPM 廠商就是隨便 跳線(從資料庫整合) 給硬兜實做出來，當然就會造成 連體嬰 式的系統，永遠都綁在一起，剪不斷、理還亂了。BPM 系統內部當然可以有預設好的服務，如 組織(Organization)結構、規則引擎(Rule Engine)等，但也應該定義標準的溝通介面，來連接外部如 Directory Server、Rule Engine 等；甚而，流程定義 (process definition)也是可以透過 OMG 的 WFMC 國際工作流組織所定義的 Interface-1，來連接外部的 流程定義 的服務系統。

複合結構圖能讓架構師一目了然即在於：瞭解系統內部的結構組件，以及系統的介面定義，來與其它的外部系統溝通。請記得，不要再尋求資料庫的資料整合方式了，那是 草本植物 的作法，是會導致系統的盤根錯節，Design for interface，這可以說是軟體設計的根本真理了。

（點擊圖片鏈接看原圖）圖 2、範例—BPM 系統的複合結構圖

實做面的設計產出

關於實體系統的分層結構

以往 IT 技術人員所認知的架構，即是在實體層次中的分層結構，例如 Client-Server, 3-tier 等。實體的分層結構，僅算是在整體架構其中之一環，是屬於與技術平台相關連的實做層次。在實做面，分層結構當然非常重要，這決定了爾後程序員寫碼的規範，而且是絕對不可違背的原則。例如，在分層結構中已規範定義了：WebUI 表單(Form) 只能呼叫 控制(control)物件，而不允許直接連結資料庫，那麼，程序員無論如何就不能在 WebUI 內寫 SQL 相關的程式碼。

筆者規劃實體的分層結構，並不一定要使用 UML 的部署圖(deploy diagram)，可能就是非標準的圖形表示，但最主要的兩個要素：套件(package)與相依性(dependency) 絕對要能表達清楚，並且在專案開發初期就要能與團隊所有開發成員取得共識，均認同這樣的分層結構，後續才不致引起紛爭。

領域模型具體化到資訊系統的實現，必須配合現實的技術平台，包括系統廠商所提供的 圖形使用者介面(GUI, Graphic User Interface)的使用、開發與呈現(例如 Browser, Struts/ASP.NET, Web Server)、資料永續儲存的儲存庫(一般泛稱資料庫, Database,如 Oracle, MySQL)、應用程式伺服器(Application Server, 又可稱之為 Middleware, 提供包括如交易, 權限控管, 分散, 資源控管等系統服務,如 MTS, JBoss, WebLogic)，尤其是為了能完整實現領域模型的建構與實現，更需要能讓程式開發人員有物件導向程式語言(OOP, Object-Oriented Programming)的開發機制，例如 .NET 平台所提供的 VB.NET, C#.NET，以及 J2EE 平台的 Java 語言，甚而 PHP, Ruby 等，也都是提供物件化的開發機制。只是後者與前兩者的差別在於，PHP, Ruby 等所提供的系統框架(System Framework)偏於 Web 端的開發，而 .NET 與 J2EE 則在UI端、中間層(Middleware)等均提供了適合於企業層級系統開發的 Frameworks，得以享有諸多便利的系統服務機制。

參考下圖 3，典型的所謂物件導向式資訊系統在設計時會分成幾個分層的結構與模組(modules)，幾個主要的分層結構如下：

• 表達層(Presentation)：圖形使用者操作介面，包括 Windows Form, Web Form, Java Swing 等，都是屬於系統廠商所提供給圖形介面開發人員來使用的工具與框架。
• 中間層：領域物件模型主要所在的位置。為了應付功能性需求，UI 端的功能性呼叫(functional call)是透過中間層的控制物件(Co, Control Object)來控制與協調為完成該功能所需要相關領域物件互動參與的資訊與企業邏輯(business logic)運算；為了隔離外部系統(包括資料庫與外部系統)的變動性，控制物件會透過 邊界類型的物件(boundary object)，如 永續性物件(PO, Persistent Object)，連結資料庫系統、調變性物件(AO, Adapter Object)，連結外部系統，如 Mainframe, Message Quese System, 其它需透過介面(interface)傳遞的系統等，來取得外部系統的資訊。而真正軟體的主結構，其實就是落在 Domain 物件(在中間層稱之為企業物件，Bo, Business Object)上，也就是源自於問題領域的概念性物件，以滿足應用程式的需求。所謂的軟體結構分析設計人員，其實就是應該要聚焦在如何作好領域物件的結構分析與設計！

  三種類型的物件(Control, Entity, Boundary)，均會呼叫系統平台所提供的技術層級服務，瞭解平台特性的系統設計人員，會透過系統框架(System Frameworks)所提供的 APIs(Application Programming Interfaces)，來呼叫取得所需要的系統服務。這些服務通常與應用領域無關，例如與資料庫之間的溝通介面或記錄程式執行與錯誤的紀錄(log)，這些是系統廠商(.NET or J2EE)，甚至是 3rd party 的工具廠商，所會提供的。請注意！ 不要把這些類型的系統物件當作是要 “可重用(reuse)” 的對象，領域物件才是！ 它們只是便於取得系統服務的工具物件而已，會隨著技術的規格變動而變動，甚至有更好用的工具出現，就要換掉原來在用、卻不會影響到系統的主結構。

• 資料層：中間層領域物件在妥協於現實(記憶體容量與揮發性問題)的技術環境下，需把其狀態(state)永續(persistent)儲存於資料庫內，並且需要使用資料時再透過永續性的機制，將其取出至中間層的領域物件，運算取得結果，並送達至客戶端呈現。現今對於企業層級主流的資料庫系統是以 關連式(Relation)DB 為主，例如 Oracle, MySQL, SQL Server 等。同時關連式資料庫也是最有效可以完整表達問題領域的資料模型，它運用 E-R(Entity-Relationship)的分析技術，就可以呈現為資料庫的 Table Schema，而且其分析的手法與在中間層對於領域物件的分析方式是一致的，可以說 領域物件模型 與 E-R 模型 是 “本是同根生(源自於問題領域)”，而兩者主要的差別只在於，E-R 呈現的是領域概念的資料層，而領域物件(企業物件)則再加上物件應有的行為(behavior)，在軟體模型中，是稱之為操作(operation)，而在程式語言中，則稱之為 方法(method)。


（點擊圖片鏈接看原圖）圖 3、資訊系統的分層結構圖

表達物件互動合作的循序圖

筆者是覺得，要與程序員溝通，最有效的一張圖就是循序圖(sequence diagram)了，因為它直接表達了在系統執行期間 (run-time)時，一組物件之間的訊息(message)傳遞。每一張循序(Sequence)圖，均代表一個情節或劇本(Scenario)，情節內描述了所參與的物件，以及物件之間的訊息(Message)傳遞。軟體設計師如同電影導演，依照劇本(使用案例)，安排適當的演員(物件)照劇本演戲。軟體設計人員在規劃循序圖時，非常重要的一個想像是：物件是活的，是有生命的。

物件導向分析與設計其中一項重要的範疇在於：指派責任(Responsibility)給物件。利用循序圖，就是設計創意最有價值的開發步驟。因為，當設計師畫循序圖，從某物件傳遞訊息給另一物件時，發現到給現在已存的物件均不恰當，這也就代表了，還有潛伏尚未被探索出來的物件，作適切的分類後，再行修正更新類別圖。

基本上，畫循序圖主要的前導來源有：由使用案例(Use Case)所提供的功能案例，也就是劇本(scenario)；以及由類別圖所提供的參與物件(Participant Object)。

觀察下圖 4，是一個實現(realize) 填寫請假單 使用案例的循序圖範例。在中間層(middleware)所參與的物件共有四個：處理請假_Uco (Use case control), 請假, 請假_PO(persistent object), workflow_adaptor 等。在此循序圖並沒有表達 UI 表單物件，筆者是給直接隱含在 申請者 這個參與者(actor)；另外，在本案例中，也需要與兩個外部系統連結，一為 HR RDB，另一為 Workflow 系統。

（點擊圖片鏈接看原圖）圖 4、範例—填寫請假單的循序圖

請注意，SA 所設計的循序圖不一定會是正確的，這需要透過實體技術平台的實做驗證。例如，UCO 物件(亦即為控制物件)會把請假資料透過 PO 與 Adaptor 物件寫入到資料庫與 Workflow 系統，而且也加了註解(note)，說明兩者的寫入必須能達成 2-phase commit，也就是要嘛就全部寫入正確，而若有其一寫入失敗就要執行 rollback 的動作。但現實上，workflow 系統可能是外購的，整個系統是被視為黑箱(black-box)，是需要透過 workflow 所提供的 APIs 介面來連結。若其本身並不支援 “支援(support)” 的交易屬性，那麼在現實上兩個系統的整合是無法達成 2-phase commit 的。怎麼辦？ 從程式的實做驗證，將其結果與意見回饋給 SA 後，循序圖就需要作修正，例如使用 沖銷 的手法，也就是若第一個系統寫入成功，但第二個系統寫入失敗，丟回一個例外(exception)錯誤後，就必須再回去第一個系統將原先所寫入的刪除掉。當然麻煩多了，但設計並非是昧於現實的，當現實的技術尚未能達成設計的理念時，那麼勢必就需要作一些妥協性的設計修正。

結語

軟體架構師，要能具備大局觀，要能知道在不同層次的構面中，應該利用什麼樣的工具與設計圖來與各類開發職的軟體人員溝通討論，更要能懂得如何調和諸多不同面向的觀點。軟體架構師是近年來國外才興起的熱門角色嗎？ 不然，請參考「古文觀止」，柳宗元所寫的一篇「梓人傳」，即是在闡述擔任架構師一職所需具備的本職素養。

延伸閱讀：

• {程序員邀稿} 以架構為中心的主要設計產出(1)
• {程序員邀稿} 從軟體架構師(Architect)的觀點來看軟體開發流程
• 進銷存系統有幾個資料庫？
• 【iThome 連載單元—4】人面獸身的 ERP 系統–異質平台整合的問題與茫點
• 從觀點來解釋架構 — Kenming 看架構 <1>

前言

筆者在輔導專案的初期，第一個時間點就要能抓出系統開發的架構全貌，請注意一下，系統不全然是指軟體資訊系統，也有可能是將企業當成是系統，並對其作需求分析、結構設計，此稱之為企業塑模(Business Modeling)。這是牽涉到系統開發的範圍與層級，無論是企業或軟體系統，如何讓開發團隊所有成員與利益關係人(stakeholder)，都能對待開發的系統有一致性的整體觀，這會是架構師首重的工作與責任。

保持整體觀可不是只透過一種設計產出就能讓所有人瞭解，道理很簡單，開發人員經常會有各自所關注的觀點，例如，需求分析人員關心的是系統能提供什麼功能與服務給使用者，他重視的是系統外部的功能需求；結構設計人員關注的是如何找出穩定的結構元素(經常是源自於問題領域的概念(concepts))，來支撐與應變外部需求的變動，他重視的就是系統內部的結構組成元素；實做人員當然就是重視能不能快速寫出程式(program)，同時還能有高效率與彈性，他重視的就是系統平台面(ex. .NET or J2EE)的實做與相關設計議題；甚至，連客戶單位的高層管理人員，也有他重視的觀點，如資訊系統是如何協助與協助企業流程(Business Process)的自動化 …。

所謂架構呈現的整體，並不是靜態不變的，而是持續性的動態調和，架構師就是要能懂得如何調和 需求功能面、結構面與平台實作面 等多重觀點，凝聚各種不同的角色，還能有一致性的全貌見解。這可不是容易的事，軟體架構不只跟結構與行為有關，同時也跟背景環境有關，包括：使用方式、功能性(Functionality)、效能、彈性、再利用性(Reuse)、可理解性(Comprehensibility)、經濟效應與技術的限制與取捨 … 等。

本篇內文，筆者是希望利用一些 UML 視覺化的設計產出(artifacts)，來說明這些產出是如何來協助架構師觀照與協調整體。這些設計產出，彼此之間有某種程度的關連性，並且要能保持一致性；架構師也容易瞭解架構的全貌是從哪一種角度來看待的觀點，然後知道如何在表象複雜的系統中，聚焦(focus)在系統廣度與深度的某一點，而不致偏離所探討的主題。 聚焦可是架構師必具備的能力，知道焦點的所在，決定是否再細分下去探究內部的細節；還是因為成員之間常因細節爭擾不紛時，就知道應該再把討論的焦點層次再往上，才比較能取得共識。

以架構為中心的觀點與產出

在前一期的專欄中，筆者提及了三個觀點來呈現架構(關於該三個觀點的解釋，請參照上期內容)，參考如下圖 1。

（點擊圖片鏈接看原圖）圖 1、表達軟體架構的三種觀點

以下列出筆者個人經常在使用的設計圖，用來呈現與解釋各種架構的觀點。請注意，筆者並不是會全部用到所有的設計圖，會視專案的規模與性質來決定該有哪些架構設計，有時甚至也會有額外、不一定非得是標準 UML 的設計圖。重點還是在於：你要知道該設計產出是在那一個觀點、表達的是那一個範圍與層次。筆者太常看到，團隊成員們之間，爭論的話題，根本就是不同觀點、不同層次，卻又不自知，難怪會經常導致溝通障礙的問題了。

需求功能觀點：

• 表達大範圍企業流程的Eriksson-Penker Business Extension Diagram
• 表達單一企業流程的活動圖(Activity Diagram)
• 表達系統範圍的使用案例圖(Use Case Diagram)

結構觀點：

• 表達軟體主結構的類別圖(Class Diagram)
• 表達元件、子系統之間介面(interface)溝通的複合結構圖(Composite Diagram)

實做觀點：

• 表達資訊系統與套件之間相依的部署圖(deploy diagram)
• 表達物件互動的循序圖(sequence diagram)

需求面的設計產出

需求面是從系統外部，一般也就是從使用者的角度來看待系統所提供的功能(function)，從系統的角度來看時，也就是系統應該提供什麼服務(service)給外部的使用者。筆者一直在強調，既然是站在系統外部，那就是以 用 的角度來看系統，千萬不要在此階段討論到系統的 How-to 面議題，否則可是會永遠都分析不完，陷入癱瘓。那會是留待在結構設計與實做的階段。

需求面主要有兩個焦點的設計議題： 企業流程(Business Process) 與 系統功能(System Functions)。

企業流程對軟體資訊系統而言，是一個大的框架。從流程當中，我們才可以得知，哪些流程的活動(activity)，需要資訊系統的協助與參與；活動與活動之間，是否也要透過資訊系統的傳遞轉移(transition)。UML 活動圖，是表達企業流程的最佳工具，不過它只能表達單一的流程(例如訂購流程)，有時我想看某一流程(內有多個活動與條件判斷)結束後，又會轉移到另一個流程，這些流程之間的資訊流是什麼樣的關係。就是想知道更大一點範圍的業務流程，例如，訂購(Order)循環→採購(PurchaseOrder)循環→出貨循環。那麼筆者還會使用非標準 UML 圖：Eriksson-Penker Business Extension，由於該圖形很像火箭，所以筆者常簡稱為火箭圖(Rocket Diagram)。簡單的說，小 BP 用活動圖即可；而大BP，則可以使用火箭圖。

圖 2、表達訂購流程的火箭圖

上圖是訂購業務流程的範例，它綜合了火箭圖與活動圖，也就是在火箭內部表達出收到訂單之後訂購活動的流程。一般筆者是會另行以一張活動圖來表達比較複雜一點的流程活動。火箭圖表達了事件(event)的觸發者(trigger)，圖中就是 收到訂單 後即觸發訂購的業務流程；它也呈現了在該流程的進行過程中，有哪些會支援或提供的資訊，如圖 出貨與財務部門 均會支援(或者參與)訂購業務流程，而 訂購資訊 則是在流程中會使用到的資訊；筆者最喜歡該火箭圖的一點就是它能呈現出該業務流程的目的(goal)為何。這重要，這可以讓利益關係人知道某業務流程所能呈現的價值與目的為何，而可以省略掉看諸多細節的活動。以圖中的例子而言，訂購業務流程的目的即是可以處理客戶訂單與出貨事宜。其實火箭圖說穿了，就是一種很典型的 I-P-O(Input-Process-Output) 表示法，但很有效，它可以封裝(encapsulate)流程內複雜的活動，而這些細部的活動，則由活動圖來表達比較理想。

（點擊圖片鏈接看原圖）圖 3、訂購流程的活動圖

上圖則是利用 UML 活動圖 表達了訂購的業務流程。在此筆者並不打算來說明活動圖的語法，這在一般 UML 入門書籍即可以看到。總之，活動圖很像傳統行之有年的流程圖(flow-chart)，但有經過一些語法上改良與修正，例如增加了並行流程的表示法。

有件事可要注意，筆者在表達業務流程，無論是使用活動圖或火箭圖時，都絕對不會加入資訊系統的表達，也就是完全是先以純人工作業的方式來看這些傳統業務流程活動之間的資訊傳遞，如此會單純化很多，也能夠比較能把焦點擺在一個個的活動。為什麼不要加入資訊系統呢？ 因為在此階段，你不容易瞭解所要開發的資訊系統會有幾個，是的，這可是一個最常見的問題，軟體開發人員經常會把開發的系統當成僅有一個，且都是自行開發，是這樣嗎？ 請看看上圖的訂購業務流程，假如需求有說到活動處理完畢需要電子簽核，那麼，會有哪幾個系統的參與呢？ 是否有 訂購系統、出貨系統、財會系統，還有工作流程系統(workflow)，或者根本就只是 ERP 系統與工作流程系統呢？

如何界定有哪些系統的參與，不會是在畫業務流程圖時來決定的，因為你不能：1.決定哪些活動是由哪一個資訊系統來支援；2.不是所有的活動都需要資訊系統的參與，有些活動可能仍是人工作業。表達資訊系統的範圍界定與外部系統的互動，以及參與的使用者，利用使用案例圖是最佳的呈現。筆者看過許多的軟體開發單位，會直接從業務流程圖轉至系統的開發，這絕對不是一個好方法，除了上述提及的問題外，也因為這樣，而忽略掉了系統內部的結構分析與設計，而這才真正是支撐系統的彈性應變與穩定性的根本所在！

火箭圖與活動圖都是與資訊系統無關，它就是單純表達原來在企業上就會有的流程。經由一些原則與步驟，其實可以很容易地從活動圖中的活動，找出局部功能觀點的資訊系統使用案例圖。因為使用案例可以明確地釐清系統範圍、系統操作的使用者、使用者操作系統的目的，所以，使用案例可以成為實現系統功能需求的最佳前導工具。

如何得知活動圖中的每一個活動是否需要資訊系統的參與？ 基本上，就是針對每一個活動詢問幾個問題：1. 誰是主要的參與者？ 2. 需要系統提供服務嗎？若是，是由哪一個系統負責？ 3. 系統提供什麼服務？ 4. 系統是否需要支援的參與者(Supporting Actor)？若需要，是哪一個外部系統？ 筆者曾在前幾期連載的內容中，有說明與範例，如何從企業流程(活動)圖找出資訊系統的使用案例，可以參考。

使用案例圖(Use Case Diagram)可以說是筆者擔任架構師的最愛，它最大的價值反而不是在釐清有多少功能需求，需求功能的釐清，是需求分析師會需要瞭解的，而架構師反而關注的是系統的範圍。
下圖係利用套件(Package)圖來界定網路訂購系統範圍(System Boundary)。
界定了系統範圍，即代表框框內橢圓形的使用案例是我們負責設計開發的系統，包括了軟體與硬體。而在框框之外的，則表示並非是由我們負責設計的，例如表達外部系統的參與者，它是在我們的系統設計範圍之外。

界定系統範圍最大的價值，乃在於，決定什麼是內？什麼是外？；什麼該作、什麼不需作。

下圖左邊棒形人偶圖示，包括客戶、財會人員、業務人員，他們是屬於主要的參與者(Primary Actor)，是站在從系統外面來看系統所提供的功能。他們關注的是自身的利益，是否系統能滿足他們的需求，這也就是為什麼筆者說使用案例是表達系統的局部功能的原因了。而外部功能的觀點是站在 用 的角度來看系統提供的服務，自然就不應該也不需要知道系統內部的實做面議題。使用案例圖易學難精，原因正是要讓 SA 不去考量到流程(那會是表達在活動圖)、不想到權限控管等實做面問題(那是系統內部的結構設計或實作的議題)，好像很困難。簡單的說，要能寫得好使用案例，就是要能表現出無知，只看系統怎麼用就好了。

右邊棒形人偶圖示，包括 庫存系統、Banking 系統、會計系統，它們是提供服務給網路訂購系統，是屬於支援性參與者(Supporting Actor)。被歸為外部系統，也就是並不屬於在系統的開發範圍內，系統的開發範圍是被界定在網路訂購系統內。對於 訂購商品 這個使用案例而言，它需要兩個外部系統的支援，一為 庫存系統，以取得庫存商品資訊；另一為 Banking 系統，以取得信用卡付款時的驗證扣款的服務。

只要是被界定為外部系統者，則不需要去探究外部系統的內部結構，只要知道如何透過 介面(interface) 的呼叫連結，來取得相關的服務即可(再一次強調，這就是一種用的角度)。例如庫存系統可能是提供 Web Service 介面供外界呼叫使用，那麼訂購系統就要知道如何呼叫該 Web Service 的連結方式；而若是 Banking 系統只提供 Main-Frame 大型系統的連結介面，那麼我們就要知道，在實做層次的階段時，是如何連接呼叫該系統所提供的 APIs 了。

（點擊圖片鏈接看原圖）圖 4、網路訂購系統的使用案例圖

再來思考一個問題，庫存系統為什麼會是外部系統呢？ 這就是界定系統範圍的重點了。有可能庫存系統已經存在，我們不需要再重新設計一個新的庫存系統；也有可能在系統架構設計時，就打算將訂購系統與庫存系統分成兩個獨立的模組(Module)，讓彼此之間的耦合度(coupling)不致太過緊密，而可以形成可抽換(PnP, Plug and Play) 的高度彈性。但只要切開後，就需要定義明確的介面規格，這是非常困難的事，同時也要耗費更多的開發成本。一般以專案導向(Project-based)的開發，會比較傾向是把兩者合成同一個系統(此時系統名稱就可能會改為進銷存系統較為適合)；而開發產品(product)者，因為會賣給不同的客戶有不同功能的模組，且需要順應客戶需求的客製化(customization)，是需要有較高度的彈性，如此把兩者分開會是比較理想的。

筆者已經是將使用案例圖當成在架構設計規劃時，用來表達多個資訊應用系統整合時的重要工具。但筆者在此階段從來不提資料庫系統，原因在於系統整合講究的是介面的整合，而不是資料的整合。資料庫是被封裝在每一個應用系統內部的私有倉儲(private storage)了，例如 訂購系統、庫存系統、會計系統 都各有自己所屬的資料庫，資料庫之間，絕對嚴禁直接連結，否則即會違背了整體架構的設計，那也不用再談所謂的彈性與延展性了！

※ 延伸參考：
o　{程序員邀稿} 從軟體架構師(Architect)的觀點來看軟體開發流程

延伸閱讀：

• {程序員邀稿} 從軟體架構師(Architect)的觀點來看軟體開發流程
• 進銷存系統有幾個資料庫？
• 【iThome 連載單元—4】人面獸身的 ERP 系統–異質平台整合的問題與茫點
• 【iThome 連載單元—1】漫談系統整合—誰是老大？
• 從觀點來解釋架構 — Kenming 看架構 <1>

參考下圖，典型的所謂物件導向式資訊系統在設計時會分成幾個分層的結構與模組(modules)。

（點擊圖片鏈接看原圖）圖、資訊系統的分層結構

幾個主要的分層結構如：

• 表達層(Presentation)：圖形使用者操作介面，包括 Windows Form, Web Form, Java Swing 等，都是屬於系統廠商所提供給圖形介面開發人員來使用的工具與框架。
• 中間層：領域物件模型主要所在的位置。為了應付功能性需求，UI 端的功能性呼叫(functional call)是透過中間層的控制物件(Co, Control Object)來控制與協調為完成該功能所需要相關領域物件互動參與的資訊與企業邏輯(business logic)運算；為了隔離外部系統(包括資料庫與外部系統)的變動性，控制物件會透過 邊界類型的物件(boundary object)，如 永續性物件(PO, Persistent Object)，連結資料庫系統、調變性物件(AO, Adapter Object)，連結外部系統，如 Mainframe, Message Quese System, 其它需透過介面(interface)傳遞的系統等，來取得外部系統的資訊。而真正軟體的主結構，其實就是落在 Domain 物件(在中間層稱之為企業物件，Bo, Business Object)上，也就是源自於問題領域的概念性物件，以滿足應用程式的需求。所謂的軟體結構分析設計人員，其實就是應該要聚焦在如何作好領域物件的結構分析與設計！

  三種類型的物件(Control, Entity, Boundary)，均會呼叫系統平台所提供的技術層級服務，瞭解平台特性的系統設計人員，會透過系統框架(System Frameworks)所提供的 APIs(Application Programming Interfaces)，來呼叫取得所需要的系統服務。這些服務通常與應用領域無關，例如與資料庫之間的溝通介面或記錄程式執行與錯誤的紀錄(log)，這些是系統廠商(.NET or J2EE)，甚至是 3rd party 的工具廠商，所會提供的。請注意！ 不要把這些類型的系統物件當作是要 「可重用(reuse)」 的對象，領域物件才是！ 它們只是便於取得系統服務的工具物件而已，會隨著技術的規格變動而變動，甚至有更好用的工具出現，就要換掉原來在用、卻不會影響到系統的主結構。

• 資料層：中間層領域物件在妥協於現實(記憶體容量與揮發性問題)的技術環境下，需把其狀態(state)永續(persistent)儲存於資料庫內，並且需要使用資料時再透過永續性的機制，將其取出至中間層的領域物件，運算取得結果，並送達至客戶端呈現。現今對於企業層級主流的資料庫系統是以 關連式(Relation)DB 為主，例如 Oracle, MySQL, SQL Server 等。同時關連式資料庫也是最有效可以完整表達問題領域的資料模型，它運用 E-R(Entity-Relationship)的分析技術，就可以呈現為資料庫的 Table Schema，而且其分析的手法與在中間層對於領域物件的分析方式是一致的，可以說 領域物件模型 與 E-R 模型 是 本是同根生(源自於問題領域)，而兩者主要的差別只在於，E-R 呈現的是領域概念的資料層，而領域物件(企業物件)則再加上物件應有的行為(behavior)，在軟體模型中，是稱之為操作(operation)，而在程式語言中，則稱之為 方法(method)。

延伸閱讀：

• 驗測「Workflow 產品」系統整合彈性度的 POC
• 進銷存系統有幾個資料庫？
• 【iThome 連載單元—4】人面獸身的 ERP 系統–異質平台整合的問題與茫點
• 【iThome 連載單元—1】漫談系統整合—誰是老大？
• {軟體架構} Tier vs. Layer Enterprise Architecture