最近在「iThome 雜誌」的技術專題上連載我對軟體架構的看法，並利用一些以往所碰過的個案來探討。每一個單元以一張(最多兩張) UML 圖為主軸，再以此延伸，以文字敘述出來，文章內容會有些批判與暗諷性質，當然不會指名道姓。
連載主題：軟體架構鮮思維—利用 UML 圖看圖說故事。
第一期的主題是從我以前 Blog 所整理出來的，題目是：「漫談系統整合—誰是老大？」因為雜誌版面有限，無法將我完整的內容刊出，所以待雜誌出刊後，同時我會將我的原稿公布在 Blog 內，供讀者們參考。
另，包括大陸的雜誌，也同時有邀稿，所以關於爾後的投稿內容，我均會公布在新分類「雜誌邀稿」上。
前言
筆者擔任軟體顧問輔導與服務已多年，本身所擔任的角色為 “軟體架構師(Software Architect)” 一職，輔導的對象為一般軟體 ISV(Independent Software Vendor) 以及中、大型公司的 IT 部門。擔任架構師多年，經常一直思考架構師的職掌及所該具備的技能與素養，也逐漸培養出一種直覺、感覺，往往一眼可以看出某系統的架構好壞、或是軟體設計師的設計意涵等．．．。也藉此，筆者準備在本連載單元內，以曾經輔導過的個案，或所經歷、看過的一些 “現象” ，包括個人的心得與體會等，以 UML 圖來 “看圖說故事”，每一個單元都是一段個案、故事，同時也是案例分析。藉由各種面象與分析，帶領讀者們來看待與解釋架構，在之前，筆者先對 “架構” 一詞作個基本的說明。
由於國內軟體應用開發廠商係偏以專案開發(Project-based)的方式來從事應用軟體開發，而專案開發，先天有個不良的本質 – 時間永遠不足，所以專案開發的首要目標是要在有限甚至不合理的時程內把系統給 “做出來”，再來是求效能佳，至於彈性、可維護性等，那是以後的事情，而根本問題是，那個 “以後” 也就是系統爾後糾纏不清的 “病因”，同時，這也導致軟體開發人員普遍存在一個很大的茫點 – 見樹不見林。
那個 “樹” 代表著軟體技術人員只重視將系統給做出來的實體平台“技術”，諸如深入去瞭解 “如何用” .NET 或 J2EE 的系統平台技術；或是系統分析人員往 “問題領域(Problem Domain)” 的方向鑽研。兩者卻鮮少用心於 “純” 軟體設計，俱足軟體領域應有的技能與技術，那麼，什麼是 “純” 軟體的技術？ 答案又是很簡單：抽象(Abstraction)、封裝(Encapsulation)、介面(Interface)與相依性(Dependency)分析的觀念 …等。
兩者的角色，一則往系統面的技術鑽研；一則往問題領域面的知識來走，兩者是越來越偏離，而不容易有互補了。自然而然，這也就如 “第五項修練” 一書所提及的，開發團隊已經喪失了整體系統思考的主動積極，同時，那個 “林”，也就是一種 “整體”，或稱之為 “架構(Architecture)”，早已蕩然無存，不知架構為何物了。
什麼是架構(Architecture)？
架構(Architecture)一詞，非常之難解釋，若真要一言以蔽之，那麼，可以說， ”架構” 是一種整體觀，需要保持從各角度看待架構時，仍有一致性與調和的觀點。
對 ”架構” 要能有充分的理解與認識，至少要能確實瞭解與體會下列幾個與架構至為關鍵的意涵與術語，包括了：整體-局部(Whole-Part)、觀點(View)，包括巨(Macro)觀與微(Micro)觀、焦點(Focus)、層次(Layer)與廣度(Boundary)等。
擔任軟體架構師(Software Architect)必備的素養，即在於：觀照整體的能力。
筆者在輔導許多軟體公司的專案開發與教育訓練時，發現到與開發團隊對 “架構” 一詞的認知與定義大不相同。個人發現到，大部分的 IT 技術開發人員，所表達出來的架構，是比較偏向於實體層次如 .NET, J2EE 的 IT 技術層次。不是不對，而是 IT 實體層次僅是架構的觀點之一，並不足以代表整體的架構觀。
筆者想試著利用以上述幾個術語來解釋 “架構”。畢竟，架構的設計，牽涉到相關於設計中系統的議題與範圍太廣了，包括：團隊開發的共識、開發流程(Development Process)的制訂,分工與外包(Outsourcing)控管、系統的彈性、延展(Scalibility)與維護性等。
金剛經有云：「凡所有相，皆屬虛妄，見諸相非相，即見如來」。
“相”，是被具化、可以看得到的形，如同軟體模型，是被具化的產出(Artifact)，也就是 “相”。而 “如來”，是不著相的，架構即為如來，所以架構也可以說是一種空、無。
問題來了，既然不著相，你又如何知道何為正道，何為如來？
佛教禪宗有個「以指標月」的譬喻：對於一個從不來不知月亮為何物的人，在蒼茫的星空中，不知那一個叫做月亮，這時候就需要一個認識月亮的人，用手指著月亮說：「那就是月亮」。同樣的道理，你又能如何瞭解甚至來驗證架構(如來)的正確性呢？
有經驗的架構師(Architect)，會以各種不同的角度(以上所涵蓋的幾個術語)，建構各類型的軟體模型，來看待並解釋「架構」。如同「以指標月」一般，對架構有深一層體會的架構師，會以導師(Mentor)的角色，利用各種工具來具化產出，以引導系統開發團隊的成員們認識「架構」。
UML, 程式碼等只是個標示工具，而所謂「架構」，是一種共識、一種默契、一種無以言欲的整體調和感。
先從觀點看架構
筆者首先以 “觀點(Viewpoint)” 一詞來解釋架構。要能具軟體架構的整體與協調性，最起碼要能有三個觀點：
ˇ 需求面的觀點
ˇ 結構面的觀點
ˇ 實做面的觀點
- 需求面的觀點：
需求(Requirement)，代表著的是系統外部的觀點，也就是從 參與者(Actor) 的角度來看待系統所提供的功能(Function)。筆者會建立使用案例模型(Use Case Model)，來代表需求面的觀點，每一個使用案例，即代表系統所該履行的功能。
使用案例模型的建立，筆者會視系統規模的廣度，來決定是否建立企業使用案例(Business Use Case Model)模型與系統使用案例模型(System Use Case Model) 兩個層次。
不以使用案例模型來代表需求面的觀點，未嘗不可。例如，利用如 XP(Extreme Programming, 敏捷性開發的代表性流程) 的使用者陳述(User Story)來紀錄系統的功能點(Functional Point)，當然可以更形簡化需求面的陳述。只是，筆者個人是偏好於利用視覺化來建立各種觀點的模型，感覺會更有助於對整體系統的瞭解。尤其是，筆者經常以 “套件圖(Package)”，表達在使用案例圖內，子系統與子系統之間範圍的界定與溝通。
圖1、範例—銀行業務企業使用案例圖
圖2、範例—Web ATM 系統使用案例圖
- 結構(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 年以上(最保守的估計)，培養軟體設計者的反思與創意思考能力，來鍛鍊對軟體設計的基本功夫。
圖3、範例—高階類別圖(Class Diagram)
圖4、範例—高階循序圖(Sequence Diagram)
- 實作(Implementation)面的觀點：
程式碼(Source Code) 是實做最主要的產出，也可以說是最直接、有效的產出。因為，無論你的設計圖作得多棒，卻很難以工具來驗證、測試其正確性。但是，程式碼，經過語法檢查、編譯後，能不能執行，馬上就可以知道，並且可以透過各種的測試機制，來測試包括功能、效能、容錯(Fault Tolerance) ．．．等各類的測試項目。從實做面的觀點，筆者一直大力主張要能針對系統功能作測試自動化，而不要僅流於紙張上的測試案例。功能絕對會善變，功能一變，測試程式碼就必須得跟著改變，否則無法通過自動化的測試。
這非常重要，因為會直接影響到 “驗收” 這一環節。這裡筆者太認同 XP 其中之一的實務；測試先行(Test First)。由客戶撰寫測試的情節(Scenario)與提供測試相關的數據；開發團隊負責撰寫測試程式碼。
使用者接受度測試(UAT, User Acceptance Test)，是可以透過撰寫功能測試程式碼來達到自動化的測試，不過，卻無法測試程式碼的結構內涵。結構的測試，更是一個重要的議題。有太多的軟體開發單位，是先寫程式碼，再反轉回(Reverse)設計圖，把設計圖當文件(Document)交差了事。這很危險，脆弱的結構，是導致系統複雜難以維護，以及無法應變的主因。
我會利用如 Together, EA(Enterprise Architect) 等 UML 工具，幫程式碼照 “X” 光，檢驗其脈絡。反轉程式碼，呈現視覺化的模型後，最重要的是檢查元素的相依性(Dependence)，從巨觀包括子系統、模組，至微觀包括套件(Package)、元件(Component)等，是否有違背原先所承諾客戶的結構設計。
圖5、範例—利用 Borland Together 檢視套件與類別的相依性關係
關於系統整合–架構的呈現
一般軟體公司普遍存在最大的系統整合問題點即在於：把資料庫當作應用系統來看待！！這問題很大，為什麼？ 因為軟體設計人員就不會有 “介面(Interface)” 的觀念，這導致每一個應用系統均無法獨立成為個別的模組(Module)(或者，稱之為元件(Component)更為適合)。也就是說，若要讓每個應用系統能成為獨立的個體，就需要有明確的溝通介面。資料庫僅是應用系統的私有倉儲(private storage)，其它應用系統是不能也不應該直接至某一個應用系統的資料庫 “撈” 資料來處理，這如同硬體的主機板設計，為了取巧，而以跳線的方式來讓某些元件之間快速得以連結，想想看，這樣的主機板，你會肯買嗎？ 然而，大部在軟體系統所謂的整合技術，卻比比皆是用這種 “跳線” 的投機方式來應付。以資料庫的整合方式為手段，而所謂的模組(Module)，卻僅是在業務邏輯領域的分辨而已，例如，”進銷存” 系統，你到世貿軟體應用展所看到各種號稱軟體產品廠商所推出的產品，一定是 “一個” 進銷存系統，不可能也無法明確分離成 “進”、”銷”、”存” 三個實體的模組，甚至可以將甲廠商的 “進貨” 模組，連結到乙廠商的 “存貨” 模組。這是一種 “草本植物” 的整合，雜草叢生，而根卻早已彼此糾纏不清，剪不斷、理還亂了。
那麼，回歸到應用系統的整合，講究的是以 “介面” 作為溝通的唯一管道，這難不難？ 技術上其實並不難，但在設計上，確是需要專注於介面的設計，而且還需要存在著一種那麼一點抽象與創新的思維。
筆者就以某一公司的 “人力資源系統” 為例，當該公司要導入請假的電子簽核流程，而電子簽核可能是外購的 工作流程(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 則顯明地表達流程簽核係外部 工作流程系統 的責任，同時這也代表著兩個很重要的設計意涵：
- 把工作流程當作外部系統，明顯表達 HR系統不需實做流程簽核功能。而工作流程系統可以是其它外購產品(如 Ultimus)、OpenSource(如 jBPM)的系統。
- 當定義出與外部工作流程系統溝通的介面(Interface)，例如依循 WFMC 的規格，即可造成 “Plug-and-Play” 效果，亦即，工作流程系統是隨時可以被抽換的。
這也是為何筆者從圖A導出圖B的使用案例圖時，還特意把 Workflow 戲稱為 “小弟” 。筆者一直以為，在現實人工的請假流程中，誰來負責傳遞請假單？ 稍具規模的公司，會由兼職的小弟或小妹擔任傳遞的工作，而若小弟不乖，傳遞效率不彰，影響到請假當事人權益，該怎麼辦？ 二話不說，就是換掉！！
但回到現實許多公司導入外購的電子簽核系統後，卻反而由工作流程系統成為主角，其它的系統是被整合體。導入某廠商的工作流程產品後，若覺效能或穩定度不佳，想換掉？ 門都沒有！ 在導入工作流程系統，在整合自家既有的系統時，已大部由廠商以 “跳線” 的手法，利用資料庫的整合，早已將自家的系統與外購的工作流程系統，整合成 “連體嬰” 了，想切掉？ 可得要找醫術高明的外科醫師才有點機會。
當然，筆者也遇到許多的 IT 技術人員，質疑圖B 的實做方式，甚至，會疑惑若該 Workflow 系統沒有提供標準、明確的介面，那又該如何溝通？
諸如實做面的技術問題，筆者永遠傾向拿出第一個利器：Prototyping (雛形設計)，以檢驗在實做面可能會遇到的技術面問題，先不論這該用何技術來解決系統整合的問題，反正在第一個時間點，就該具體呈象細部的系統整合，以及產出可以被執行的程式碼，以解決技術人員們的疑惑。
至於第二個問題，若撇開政治面非得採用某家產品以外來說，我們可以反思，Workflow 是一個非常成熟的領域，OMG 轄下的 WFMC 組織，早已在多年前，明確規範工作流程系統的標準規格，甚至，還更細分至 Workflow 是由多個模組所組成，模組之間，並規劃明確的介面，來供彼此之間以及外部系統的溝通，這些，是可以至 WFMC 下載規格文件來參考之。而國內已有多家 Workflow 廠商宣稱已加入 WFMC 認證組織，所以，客戶在採購 Workflow 系統時，當然優先以採購經由認證、品質保證的為主。
仍然找不到可以連結至工作流程系統的介面？ 好吧，了不起，我們幫它寫個 “調變器(Adapter)” 吧，這個 Adapter 同時也是一種 “包裹(Wrapper)” 的角色 – 封裝外部善變的系統，未來得以把它換掉。
基本結論
所以，Workflow 並不是老大，當它是屬於 “小弟” 的角色時，”不乖” 就應該把它換掉，但前提是不能影響到本來已在執行的業務流程。所以，換成是 HR 系統是老大囉？ 這也不然，從 “架構” 的整體觀點來考量，HR 系統也應該會被當成是可被抽換的模組，HR 與 Workflow 系統都是可以被抽換的，但是彼此誰也不應該也影響到誰。所以，到底是那一個系統，才是整合的老大呢？
放棄「自我本位」的觀點，試著以「同理心」從客戶的角度來看待系統的整合，則整合的解決方案 卻是意外的簡單！ 我們只要加上“主機板(Mother-board)”的設計觀念就可以了。關於 “主機板” 的整合設計，留待爾後的單元再以實際的個案來分析與討論。
這裡先帶一句話，來說明整體架構設計所應該瞭解其中一個重要的設計素養：
「從客戶的角度來看時，所有的子系統(或模組)均是一視同仁的，客戶不希望因為其中一個子系統的抽換，而牽連到其它的子系統，減少其耦合度(Coupling)，以避免複雜無法維護而不可收拾的結果。」