軟工藝術 : [轉貼]軟體架構設計鮮思維

• 發表新主題

發表者	討論內容
冷日 (冷日)	發表時間：2008/3/14 9:06
Webmaster 註冊日: 2008/2/19 來自: 發表數: 15771	[轉貼]關於系統整合— 架構的呈現 關於系統整合— 架構的呈現 一般軟體公司普遍存在最大的系統整合問題點即在於：把資料庫當作應用系統來看待！這問題很大。為什麼？因為軟體設計人員就不會有「介面」（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），以避免複雜無法維護而不可收拾的結果。」
回覆

平面展開

前一個主題 | 下一個主題 | | | |

討論串

•    [轉貼]軟體架構設計鮮思維 (冷日
  (冷日), 2008/3/14 9:03)
•      [轉貼]軟體架構設計鮮思維(1) 系統整合－誰是老大？ (冷日
  (冷日), 2008/3/14 9:03)
•        [轉貼]什麼是架構？ (冷日
  (冷日), 2008/3/14 9:04)
•          [轉貼]先從觀點看架構 (冷日
  (冷日), 2008/3/14 9:04)
•          » [轉貼]關於系統整合— 架構的呈現 (冷日
  (冷日), 2008/3/14 9:06)