模組與耦合

最近克明兄《軟體的模組化(Modulize)設計應該要徹底實踐!》的主題討論中特別提到~

Process Definition 是與 Workflow 核心分離的。各位可以以此來審視國內的 Workflow 產品,是否有哪一套產品確實可以做到這一點,這還只是 Interface-1 而已喔。

其實國內的workflow engine廠商都聲稱符合WfMC工作流程標準,但一般人很難了解它們各模組間是否有做到真正的分離。曾問過幾家workflow engine要如何整合其應用程式,所得到的答案多半是「客製化」這個專業術語,但進一步了解才發現,他們並未設計界面來做為減震點(Decouple Point)以減少不必要的模組相依,而是模組必須和特定的實作緊密耦合在一起,也就是他們的客製化會使原先定義良好的模組被破壞了。因此可以推知他們並不是採用模組分離的設計,也就是並未符合所謂的模組鬆散耦合的理想。我想這當中除了作業環境會有不相容的問題外(Web base vs. AP base),更重要的原因就是市場利基的考量,技術問題容易克服的,但workflow市場恐怕還沒具備須鬆散耦合設計的條件。

這讓我想起過去開發workflow軟體的經驗,規劃的架構看起來是很具模組概念,但真正在設計實作的過程卻是完全的資料驅動設計。例如要整合人事薪資管理系統時,規劃的內容竟是雙方的資料表如何交換資料,並沒有比其它廠商高明到那裡。所謂「井蛙不可語於海者,拘於墟也;夏蟲不可語於冰者,拘於時也;曲士不可語於道者,束於教也」(《莊子秋水篇》),對於資料驅動設計的信徒而言,我們的忠告他們並不能了解,當然不可能接納。

如果把模組化看成是鬆散耦合的模組設計,那麼到底模組化設計是技術、工具或是設計理念呢?表面上看起來,模組化設計似乎與元件化設計(Component-based design)有很大的關係,所以很多人會認為沒有特殊技術或工具沒辦法做到模組化,似乎模組化就必須花費一些技術成本;但我認為模組化設計是一種設計理念,不一定要用元件化或物件導向設計才能實現,所以要花費的不是技術成本而是溝通及學習成本。舉個例子來說,過去從事金融付款系統時,用C語言搭配訊息中介軟體(MOM, Message-Oriented Middleware)就可以建立金融付款系統的技術平台,所用的並不是物件導向的技術,雖然沒有界面或抽象類別來封裝模組間的呼叫,但利用程序共享或訊息分享來取代資料共享,即使不用物件導向技術,還是充分地展現出模組化的設計理念。所以把模組化當成是一種設計理念,工具與技術只是運用手段,設計的思路千萬不要被它們所框限住了。

Please follow and like us:
分類: 分析設計建模, 設計原則, 軟體開發。這篇內容的永久連結

在〈模組與耦合〉中有 4 則留言

發佈留言

發佈留言必須填寫的電子郵件地址不會公開。 必填欄位標示為 *