全文均刊登於北京「程序員(Programmer)」雜誌(台灣天瓏書局可購得), 2007 6月刊, p74~p77。 感謝朱海豔(helenna)小姐用心將文稿轉為簡體專業術語，以及將 Model 重新美編，並轉為簡體。

前言

筆者在輔導專案的初期，第一個時間點就要能抓出系統開發的架構全貌，請注意一下，系統不全然是指軟體資訊系統，也有可能是將企業當成是系統，並對其作需求分析、結構設計，此稱之為企業塑模(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)的觀點來看軟體開發流程