軟體架構設計鮮思維(1) 系統整合－誰是老大？

作者：王克明／信仁軟體設計顧問中心軟體架構師，機械化師文書官、系統工程師、Oracle DBA、IT部門副理、講師、顧問。

什麼是架構？
架構一詞非常難解釋，若真要一言以蔽之，那麼，可以說，「架構」是一種整體觀，需要保持從各角度看待架構時，仍有一致性與調和的觀點。

對「架構」要能有充分的理解與認識，至少要能確實瞭解與體會下列幾個與架構至為關鍵的意涵與術語，包括了：整體—局部（Whole-Part）、觀點（View），包括巨（Macro）觀與微（Micro）觀、焦點（Focus）、層次（Layer）與廣度（Boundary）等。

先從觀點看架構
筆者首先以「觀點（Viewpoint）」一詞來解釋架構。要能具軟體架構的整體與協調性，最起碼要能有三個觀點：

．　需求面的觀點
．　結構面的觀點
．　實作面的觀點

關於系統整合— 架構的呈現
應用系統的整合，講究的是以「介面」作為溝通的唯一管道，這難不難？技術上其實並不難，但在設計上，確是需要專注於介面的設計，而且還需要存在著一種那麼一點抽象與創新的思維。

筆者就以某一公司的「人力資源系統」（Human Resource，HR）為例，當該公司要導入請假的電子簽核流程，而電子簽核可能是外購的工作流程（Workflow）系統，因而會牽涉到系統整合時，是要如何看待彼此之間的架構整合設計呢？什麼是架構？

架構一詞非常難解釋，若真要一言以蔽之，那麼，可以說，「架構」是一種整體觀，需要保持從各角度看待架構時，仍有一致性與調和的觀點。

對「架構」要能有充分的理解與認識，至少要能確實瞭解與體會下列幾個與架構至為關鍵的意涵與術語，包括了：整體—局部（Whole-Part）、觀點（View），包括巨（Macro）觀與微（Micro）觀、焦點（Focus）、層次（Layer）與廣度（Boundary）等。

擔任軟體架構師（Software Architect）必備的素養，即在於：觀照整體的能力。

筆者在輔導許多軟體公司的專案開發與教育訓練時，發現到與開發團隊對「架構」一詞的認知與定義大不相同。個人發現到，大部分的IT技術開發人員，所表達出來的架構，是比較偏向於實體層次如.NET、J2EE的IT技術層次。不是不對，而是IT實體層次僅是架構的觀點之一，並不足以代表整體的架構觀。

筆者想試著利用以上述幾個術語來解釋「架構」。畢竟，架構的設計，牽涉到相關於設計中系統的議題與範圍太廣了，包括：團隊開發的共識、開發流程（Development Process）的制訂，分工與外包（Outsourcing）控管、系統的彈性、延展（Scalibility）與維護性等。

有經驗的架構師（Architect），會以各種不同的角度（以上所涵蓋的幾個術語），建構各類型的軟體模型，來看待並解釋「架構」。如同「以指標月」一般，對架構有深一層體會的架構師，會以導師（Mentor）的角色，利用各種工具來具化產出，以引導系統開發團隊的成員們認識「架構」。

UML或程式碼等只是個標示工具，而所謂「架構」，是一種共識、一種默契、一種無以言欲的整體調和感。先從觀點看架構

筆者首先以「觀點（Viewpoint）」一詞來解釋架構。要能具軟體架構的整體與協調性，最起碼要能有三個觀點：

1.需求面的觀點
2.結構面的觀點
3.實作面的觀點

● 需求面的觀點：
需求（Requirement），代表著的是系統外部的觀點，也就是從參與者（Actor）的角度來看待系統所提供的功能（Function）。

筆者會建立使用案例模型（Use Case Model），來代表需求面的觀點，每一個使用案例，即代表系統所該履行的功能。

使用案例模型的建立，筆者會視系統規模的廣度，來決定是否建立企業使用案例（Business Use Case Model）模型與系統使用案例模型（System Use Case Model）兩個層次。

不以使用案例模型來代表需求面的觀點，未嘗不可。例如，利用如XP（eXtreme Programming，敏捷性開發的代表性流程）的使用者陳述（User Story）來紀錄系統的功能點（Functional Point），當然可以更形簡化需求面的陳述。只是，筆者個人是偏好於利用視覺化來建立各種觀點的模型，感覺會更有助於對整體系統的瞭解。尤其是，筆者經常以「套件圖（Package）」，表達在使用案例圖內子系統與子系統之間範圍的界定與溝通。

● 結構（Structure）面的觀點：
系統的結構設計，可以說才是決定系統的彈性、延展、效能、穩定等主要成敗因素。國內軟體專案的開發，絕大部分並不重視系統的結構設計。主因在於專案開發時程偏短線的不合理、軟體人員對結構設計未能俱足抽象與實務並重的技能，以及內部的結構是客戶所看不到，並且短期無法能感受到的。專案開發因重視短線立即性的效果，所以反而以功能需求面、使用者介面（UI）為主要的開發重點。

這如同購買房子一樣，一開始因為樣品屋美輪美奐的室內佈置（UI），以及附贈許多的家具、生活用品（功能），卻忽視掉房屋的結構設計。短期感受不到問題，住久後才逐漸顯現出如漏水、海砂屋甚至因鋼架的偷工減料而導致強烈地震一來即崩垮的慘劇。
軟體的結構模型，至少有兩個主要的產出：類別（Class）設計圖與循序（Sequence）圖。

類別圖表達的是系統的內部靜態結構；循序圖表達的是系統內部元素（稱之為物件比較理想）之間，為完成某一交付的任務（系統功能），物件之間互動合作的動態行為。

傳統的軟體結構分析與設計，會以為主要的工作是建立資料庫的E-R（Entity-Relationship）模型。這該算是靜態結構設計的一種退化解，雖然 E-R圖是以問題領域（Problem Domain）的術語作為分解的依據，這與類別圖設計的分解思維是一致的。不過最主要的問題，仍在於E-R圖的分解元素沒有自主性的行為（Behavior）能力，把行為抽離出來而分散至Form Script、Web Page、Stored-procedure …，甚至亂分一番，隨便實做某個物件，把演算邏輯「塞」進去就號稱為物件導向設計。

行為的分散，造成系統彈性與維護的困難性，是注重以E-R資料模型為結構設計主體的問題點。類別圖（Class Diagram）回歸至本質面，把資料與行為有效歸納至所該承擔的物件上。類別圖的設計最困難與謹慎之處，即在於如何有效分派責任（Responsibility Assign）至物件上。

結構的設計若以層次（Layer）之分，又分為高階抽象的領域模型，與細部、平台面相依的軟體規格模型。層次的問題，筆者會以另外一個主題：從層次來解釋架構時再來討論。

越是高階、抽象的結構模型，會比較偏向於「本質面」。當越能抽至最接近本質面的那一層，結構越為穩定。越接近本質面的那一層，其呈象反而越是簡單（Simple），但是，要能呈現出簡單，本身卻不簡單，是最為難之分析、設計的。理由是，結構設計師需要非常高度的抽象理解能力。抽象能力的培養，講究悟性，左、右腦需能平衡協調，絕非純左腦邏輯的分析，也無法利用所謂的方法論（Methodology），以所謂的「規則」來套用。這是「純（Pure）」軟體設計的修練，起碼要花上 5～10年以上（最保守的估計），培養軟體設計者的反思與創意思考能力，來鍛鍊對軟體設計的基本功夫。

● 實作面的觀點：
程式碼（Source Code）是實作最主要的產出，也可以說是最直接、有效的產出。因為，無論你的設計圖作得多棒，卻很難以工具來驗證、測試其正確性。但是，程式碼經過語法檢查、編譯後能不能執行，馬上就可以知道，並且可以透過各種的測試機制，來測試包括功能、效能、容錯（Fault Tolerance）…等各類的測試項目。

從實作面的觀點，筆者一直大力主張要能針對系統功能作測試自動化，而不要僅流於紙張上的測試案例。功能絕對會善變，功能一變，測試程式碼就必須得跟著改變，否則無法通過自動化的測試。
這非常重要，因為會直接影響到「驗收」這一環節。這裡筆者太認同XP其中之一的實務：測試先行（Test First）。由客戶撰寫測試的情節（Scenario）與提供測試相關的數據；開發團隊負責撰寫測試程式碼。

使用者接受度測試（UAT，User Acceptance Test），是可以透過撰寫功能測試程式碼來達到自動化的測試，不過，卻無法測試程式碼的結構內涵。結構的測試，更是一個重要的議題。有太多的軟體開發單位是先寫程式碼，再反轉回（Reverse）設計圖，把設計圖當文件（Document）交差了事。這很危險、脆弱的結構，是導致系統複雜難以維護，以及無法應變的主因。

我會利用如Together，EA（Enterprise Architect）等UML工具，幫程式碼照「X」光，檢驗其脈絡。反轉程式碼，呈現視覺化的模型後，最重要的是檢查元素的相依性（Dependence），從巨觀包括子系統、模組，以至於微觀的套件（Package）、元件（Component）等，是否有違背原先所承諾客戶的結構設計。關於系統整合— 架構的呈現

一般軟體公司普遍存在最大的系統整合問題點即在於：把資料庫當作應用系統來看待！這問題很大。為什麼？因為軟體設計人員就不會有「介面」（Interface）的觀念，這導致每一個應用系統均無法獨立成為個別的模組（Module）（或者，稱之為元件（Component）更為適合）。

也就是說，若要讓每個應用系統能成為獨立的個體，就需要有明確的溝通介面。資料庫僅是應用系統的私有倉儲（private storage），其它應用系統是不能也不應該直接至某一個應用系統的資料庫「撈」資料來處理，這如同硬體的主機板設計，為了取巧而以跳線的方式來讓某些元件之間快速得以連結。想想看，這樣的主機板你會肯買嗎？然而，大部在軟體系統所謂的整合技術，卻都是用這種「跳線」的投機方式來應付。以資料庫的整合方式為手段，而所謂的模組（Module），卻僅是在業務邏輯領域的分辨而已。例如，「進銷存」系統，你到世貿軟體應用展所看到各種號稱軟體產品廠商所推出的產品，一定是「一個」進銷存系統，不可能也無法明確分離成「進」、「銷」、「存」三個實體的模組，甚至可以將甲廠商的「進貨」模組，連結到乙廠商的「存貨」模組。這是一種「草本植物」的整合，雜草叢生，而根卻早已彼此糾纏不清，剪不斷、理還亂了。

那麼，回歸到應用系統的整合，講究的是以「介面」作為溝通的唯一管道，這難不難？技術上其實並不難，但在設計上，確是需要專注於介面的設計，而且還需要存在著一種那麼一點抽象與創新的思維。

筆者就以某一公司的「人力資源系統」（Human Resource，HR）為例，當該公司要導入請假的電子簽核流程，而電子簽核可能是外購的工作流程（Workflow）系統，因而會牽涉到系統整合時，是要如何看待彼此之間的架構整合設計呢？

HR與Workflow系統—誰是老大？

將原本是人工作業的請假業務流程，改為可以讓員工填寫電子表單，填寫完畢後系統即自動傳送至直屬主管供其簽核，整個請假流程完全是電腦化、自動化，這也是一種BPR（Business Process Re-Engineering）的範疇。

利用使用案例圖（Use Case Diagram）界定HR系統範圍（System Boundary），同時也找出使用該系統的參與者（Actor），以及參與者使用該系統的目的（使用案例，Use Case），觀察第一版的使用案例圖A。

圖A：HR系統隱含實作電子簽核的功能。

筆者在擔任架構師時，當遇到系統分析人員畫出如圖A的使用案例圖時，首先一個直覺的問題就是：實作請假電子簽核流程是由那個系統負責？

從圖A其實看不出來，請假電子簽核流程到底是否是由HR還是工作流程系統來負責？而事實上，電子簽核由HR 系統來負責實作明顯不合理，因為若如此，那麼，該公司如公文簽核系統，難道也是公文系統負責，也要實作一個電子簽核系統嗎？但從圖A的設計意涵，卻表達隱含了HR系統需擔負流程簽核的責任。這似乎不妥當，所以第二版本的使用案例如圖B。

圖B：將Workflow系統抽離出來，成為HR的外部參與者。

圖B則顯明地表達流程簽核係外部工作流程系統的責任，同時這也代表著兩個很重要的設計意涵：

1. 把工作流程當作外部系統，明顯表達HR系統不需實做流程簽核功能，而工作流程系統可以是其它外購產品（如 Ultimus）、OpenSource（如jBPM）的系統。

2. 當定義出與外部工作流程系統溝通的介面，例如依循 WFMC的規格，即可造成「Plug-and-Play」效果，亦即工作流程系統是隨時可以被抽換的。

這也是為何筆者從圖A導出圖B的使用案例圖時，還特意把工作流程戲稱為「小弟」。筆者一直以為，在現實人工的請假流程中，誰來負責傳遞請假單？稍具規模的公司，會由兼職的小弟或小妹擔任傳遞的工作，而若小弟不乖、傳遞效率不彰，影響到請假當事人權益，該怎麼辦？二話不說，就是換掉！

但回到現實許多公司導入外購的電子簽核系統後，卻反而由工作流程系統成為主角，其它的系統是被整合體。導入某廠商的工作流程產品後，若覺效能或穩定度不佳，想換掉？門都沒有！在導入工作流程系統，在整合自家既有的系統時，已大都由廠商以「跳線」的手法，利用資料庫的整合，將自家的系統與外購的工作流程系統，整合成 「連體嬰」了。想切掉？可得要找醫術高明的外科醫師才有點機會。

當然，筆者也遇到許多的IT技術人員，質疑圖B的實作方式，甚至會疑惑若該Workflow系統沒有提供標準、明確的介面，那又該如何溝通？

諸如實作面的技術問題，筆者永遠傾向拿出第一個利器：Prototyping（雛形設計），以檢驗在實作面可能會遇到的技術面問題。先不論這該用何技術來解決系統整合的問題，反正在第一個時間點，就該具體呈現細部的系統整合，以及產出可以被執行的程式碼，解決技術人員們的疑惑。

至於第二個問題，若撇開政治面非得採用某家產品以外來說，我們可以反思，Workflow是一個非常成熟的領域。OMG轄下的WFMC組織，早已在多年前，明確規範工作流程系統的標準規格，甚至還更細分至Workflow是由多個模組所組成，模組之間並規劃明確的介面，作為彼此之間以及外部系統的溝通，這些是可以至WFMC下載規格文件來參考之。而國內已有多家 Workflow廠商宣稱已加入WFMC認證組織，所以客戶在採購Workflow系統時，當然優先以採購經由認證、品質保證的為主。

仍然找不到可以連結至工作流程系統的介面？好吧，了不起，我們幫它寫個 「調變器（Adapter）」吧。這個 Adapter同時也是一種「包裹（Wrapper）」的角色—封裝外部善變的系統，未來得以把它換掉。

基本結論
所以，Workflow 並不是老大，當它是屬於「小弟」的角色時，「不乖」 就應該把它換掉，但前提是不能影響到本來已在執行的業務流程。所以，換成是HR系統是老大囉？這也不然，從 「架構」的整體觀點來考量，HR系統也應該會被當成是可被抽換的模組，HR 與Workflow系統都是可以被抽換的，但是彼此誰也不應該也影響到誰。所以，到底是那一個系統，才是整合的老大呢？

放棄「自我本位」的觀點，試著以「同理心」從客戶的角度來看待系統的整合，則整合的解決方案卻是意外的簡單！我們只要加上「主機板（Mother-board）」的設計觀念就可以了。關於 「主機板」的整合設計，留待爾後的單元再以實際的個案來分析與討論。
這裡先帶一句話，來說明整體架構設計所應該瞭解其中一個重要的設計素養：「從客戶的角度來看時，所有的子系統（或模組）均是一視同仁的，客戶不希望因為其中一個子系統的抽換，而牽連到其它的子系統，減少其耦合度（Coupling），以避免複雜無法維護而不可收拾的結果。」