【iThome 連載單元—1】漫談系統整合—誰是老大?

最近在「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、範例—銀行業務企業使用案例圖

    範例—Web ATM 系統使用案例圖
    圖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 年以上(最保守的估計),培養軟體設計者的反思與創意思考能力,來鍛鍊對軟體設計的基本功夫。

    範例—高階類別圖(Class Diagram)
    圖3、範例—高階類別圖(Class Diagram)

    範例—高階循序圖(Sequence 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)等,是否有違背原先所承諾客戶的結構設計。

    範例—利用 Borland Together 檢視套件與類別的相依性關係
    圖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。

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

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

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

將 Workflow 系統抽離出來,成為 HR 的外部參與者
圖B、將 Workflow 系統抽離出來,成為 HR 的外部參與者

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

  1. 把工作流程當作外部系統,明顯表達 HR系統不需實做流程簽核功能。而工作流程系統可以是其它外購產品(如 Ultimus)、OpenSource(如 jBPM)的系統。
  2. 當定義出與外部工作流程系統溝通的介面(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),以避免複雜無法維護而不可收拾的結果。」

文章導覽

   

發表迴響

你的電子郵件位址並不會被公開。 必要欄位標記為 *