設計模式在燃料電池測試系統中的應用

摘 要： 針對傳統的面向過程的軟件設計方法已無法應對市場對燃料電池測試系統快速的需求變化，提出將設計模式應用于燃料電池測試系統軟件的開發過程，重點介紹了抽象工廠模式、命令模式、觀察者模式、外觀模式的應用。實驗結果表明，基于面向對象設計模式開發的燃料電池測試系統軟件具有良好的架構，實現了程序模塊間的低耦合和模塊內部的高內聚，提高了程序的可維護性和可復用性，能夠靈活應對功能需求的變化。采用該架構開發完成的多款燃料電池測試軟件運行穩定可靠。

關鍵詞： 面向對象設計模式； 燃料電池； 測試系統； 軟件開發

中圖分類號： TN964?34 文獻標識碼： A 文章編號： 1004?373X（2014）22?0153?04

Application of design patterns in fuel cell test system

HE Bing?lin

（Guangdong Electronic Technology Research Institute， Guangzhou 510630， China）

Abstract： Because the traditional process?oriented software design methods have been unable to cope with rapidly changing needs of the market for fuel cell test system， the design patterns are proposed to apply to the fuel cell test system software development process. Four important patterns， including abstract factory pattern， command pattern， observer pattern and facade pattern， are described in detail. The experimental results show that the fuel cell test system software developed on the base of object?oriented design pattern has a good architecture， as well as implemented low coupling between modules and high cohesion within the module， and make the software more flexible to the functional requirements. The fuel cell test softwares developed with this architecture run stable and reliable.

Keywords： object?oriented design pattern； fuel cell； test system； software development

燃料電池是一種能夠將儲存在氫燃料和氧化劑中的化學能直接轉化為電能的發電裝置，它具有能量轉換效率高、對環境污染小等優點[1]。燃料電池在世界范圍掀起研究的熱潮，目前國內外不少公司研制出專門的測試系統，以實現對燃料電池進行性能的評估。燃料電池測試系統（以下簡稱測試系統）包括測試設備以及配套的測試軟件，其中測試軟件平臺提供用戶與測試設備之間操作接口，是整個測試系統的核心。鑒于傳統的面向過程的軟件開發方法存在的問題，本文將研究如何將設計模式應用于燃料電池測試軟件，設計出良好體系結構的系統，從而不僅使測試系統很好地應對快速多變的需求，同時使測試系統具有更好的穩定性、擴展性、維護性。

1 設計模式簡介

設計模式是指經過驗證的，用于解決在特定環境下、重復出現的、特定問題的解決方案，可以幫助設計者更加簡單地復用成功的設計和體系結構[2]。Erich Gamma等人總結了23種常見的軟件設計模式，從此設計模式在軟件設計和開發中得到廣泛的應用。軟件設計模式是利用面向對象技術來解決特定環境中的問題的方法，是針對軟件設計過程中某個特定環境下出現的問題的可重用軟件設計方案[3]。23種常見的軟件設計模式在粒度和抽象層次上各不相同，根據其目的可分為創建型、結構型、行為型3種。創建型模式抽象了實例化過程，使一個系統獨立于創建、組合和表示構成它的對象，包括抽象工廠、單例等模式；結構型模式處理類與對象的組合，以獲得更大的結構，包括外觀、代理等模式；行為型模式描述類或對象間交互和職責分配，包括命令、觀察者等模式。在實際的應用中，只有深入理解各個設計模式及其相互間的關系，才能很好地將設計模式應用于將要設計的系統。

2 設計模式應用

本文所述的測試系統采用模塊化設計，由配氣、加濕、電池溫控、電子負載、單模檢測、報警共6個模塊組成：各個模塊在測試軟件的統一管理調度下協同工作，以實現對氣體的流量、壓力、溫度、濕度等參數的測控，以及模擬燃料電池恒流、恒壓、恒功率放電等多種工況；測試軟件還為燃料電池測試過程數據提供豐富的表現形式和分析手段，且有完善報警功能，使用戶全面掌握電池測試性能[4]。限于篇幅，本文僅以其中4種設計模式的應用舉例進行說明，分別是抽象工廠模式、命令模式、觀察者模式、外觀模式。

2.1 抽象工廠模式

抽象工廠模式意圖提供一個創建一系列相關或相互依賴對象的接口，無需指定它們具體的類[2]。在抽象工廠模式中，工廠類與產品類具有平行的對等結構，它們之間一一對應。核心的抽象工廠類不負責所有產品的創建，僅負責給出具體工廠類必須實現的接口，具體產品的創建由具體工廠類去實現[5]。endprint

測試軟件在設計中使用到系統參數（如放電功率、電流、電壓的最大最小值）、工步集合（如恒流、恒壓、恒功率等放電工步）、過程數據（如氣體流量、壓力、溫度）等數據模型，因技術規格不同，每個型號的系統擁有一套數據模型，不同型號系統的數據模型中屬性集合不同，或者屬性取值范圍不同。傳統的軟件設計方法通常通過條件選擇（如switch?case）區分不同型號系統的數據模型，使得數據模型的創建不靈活，并且違背了開放?封閉原則。如果將系統參數、工步集合、過程數據看作一系列的產品，而采用抽象工廠模式實現產品族的創建而無需關心構建過程，只關心什么產品由什么工廠生產即可，那么抽象工廠模式很好地解決了這個問題。

圖1給出基于抽象工廠模式創建10與20兩套不同型號系統的系統參數、工步集合的結構示意圖：抽象產品ISysParam與IWorkStepSet分別為系統參數、工步集合對象定義抽象的操作接口；抽象工廠IFctsFactory為創建系統參數、工步集合對象定義了抽象的操作接口，通過該接口可以實現具體產品；10Factory與20Factory類為具體工廠，其工廠方法CreateSysParam和CreateWorkStepSet分別負責具體系統參數（10SysParam和20SysParam）、工步集合（10WorkStepSet和20WorkStepSet）對象的創建工作。由于具體工廠返回的是抽象產品的實例，從而屏蔽了客戶端對具體產品類訪問所造成的差異。當創建一套新型號21系統對應的數據模型時，運用“反射+配置文件”的技術【6?7】，不需要修改抽象工廠類和現有的具體工廠類，只需要增加21系統對應數據模型的具體工廠和具體產品，不但遵守了開放?封閉原則，又保持了封裝數據模型對象創建過程的優點。

2.2 命令模式

命令模式意圖將一個請求封裝為一個對象，從而使你可用不同的請求對客戶進行參數化；對請求排隊或記錄請求日志，以及支持可撤銷的操作[2]。命令模式定義一個命令接口，用來約束所有命令對象的行為，每個命令實現對象是對客戶端某個請求的封裝。命令實現對象是虛的實現，它并不知道如何處理命令，但它持有相應的接收者對象來真正執行命令。命令對象和接收者對象的關系不是與生俱來，由裝配者對象按需組裝。命令模式還提供一個調用者對象持有命令對象，命令發起對象通過調用者對象來觸發命令的執行。

圖1 抽象工廠模式結構示意圖

測試系統的氣體流量、加濕溫度、電池溫度等物理量分別由專門的控制器實現控制，測試軟件在設計中需要與這些控制器通信以處理氣體流量設定、加濕溫度設定、電池控制溫度設定等命令的發送。控制器的選型要考慮控制精度、價格等因素，因此不同型號的系統可能選用不同廠家的控制器，不同廠家的控制器提供不同的操作指令，并且采用不同的通信協議。傳統的軟件設計方法一般針對具體的控制器定義一個控制對象完成所有的處理工作，這樣導致代碼的耦合性太強，不便于程序的擴展。當更換某個控制器時，必須修改原代碼，違背了開放?封閉原則。由于命令模式使得發起命令的對象和具體實現命令的對象完全解耦，因此能夠很好的解決這個問題。圖2給出了基于命令模式實現氫氣、空氣流量設定的結構示意圖： MFC為質量流量控制器接口，它聲明了設定流量的方法；H2MFC與AirMFC是MFC的兩個實現類，H2MFC（氫氣質量流量控制器）與AirMFC（空氣質量流量控制器）都是接收者，它們分別知道如何執行氫氣與空氣流量設定操作；CMD聲明了命令執行操作的接口；FlowSetCmd是流量設定命令，它綁定于某個MFC對象并調用其的DoFlowSet操作，以實現Excute；裝配者對象Client創建FlowSetCmd對象，并根據上下文指定它的接收者為H2MFC或AirMFC；調用者對象MFCManager持有FlowSetCmd對象，當命令發起對象觸發它的SetFlow操作提交一個流量設定請求，FlowSetCmd對象調用它的接收者對象的DoFlowSet操作完成流量的設定。

圖2 命令模式結構示意圖

由于發起命令的對象和具體的實現完全解耦：當更換某個質量流量控制器，只需實現新的命令實現對象，并在裝配時設置到命令對象中，其他代碼完全不用變化；擴展新的命令（FlowClearCmd）也很容易，只需實現新的命令對象，然后在裝配時，把具體的實現對象設置到命令對象中，然后就可以使用這個命令對象，已有的實現完全不用變化。

2.3 觀察者模式

觀察者模式意圖定義對象間的一種一對多的依賴關系，當一個對象的狀態發生改變時，所有依賴于它的對象都得到通知并被更新[2]。這一模式中的關鍵對象是目標（Suject）和觀察者（Observer）。一個目標可以有任意數目依賴于它的觀察者。一旦目標的狀態發生變化，所有觀察者都得到通知。測試軟件在設計中需要將過程數據以多種方式（如圖形界面、趨勢曲線、特性曲線、數據列表、柱狀圖等）進行表示，這涉及到過程數據狀態與多種數據表現方式的狀態保持一致問題。如果將過程數據看作目標對象，將圖形界面、趨勢曲線、特性曲線、數據列表、柱狀圖等看作觀察者。傳統的軟件設計方法是當目標對象的狀態發生變化時，由它直接調用所有觀察者對象進行數據的更新，這樣導致目標對象與觀察者對象的關系過于耦合，不利于程序的擴展。如果使用觀察者模式，目標只知道觀察者接口，并不知道具體觀察者類，從而實現目標類與具體觀察者類之間的解耦。一個目標并不需要知道它有幾個觀察者，也不需要知道具體是哪一個觀察者。圖3為基于觀察者模式實現過程數據發布的示意結構圖：觀察者Observer為當目標發生改變時需要獲得通知的對象定義一個更新接口；目標Subject可以擁有任意多個觀察者，并提供注冊、刪除和通知觀察者對象的接口；圖形界面MainForm和曲線界面CurveForm為具體的觀察者；過程數據分發者ProcessDataDispatcher為具體目標；客戶端通過Attach接口將MainForm和CurveForm注冊進ProcessDataDispatcher，表示MainForm和CurveForm希望訂閱過程數據；一旦過程數據發生變化，ProcessDataDispatcher通過NotifyObservers接口通知所有觀察者；各個觀察者就可通過Subject.GetData獲取更新后的過程數據。觀察者模式允許在不改動目標和其他觀察者的前提下增加觀察者DataListForm、HistogramForm等，從而允許建立動態、可靠和靈活的系統。

圖3 觀察者模式結構示意圖

2.4 外觀模式

外觀模式意圖為子系統中的一組接口提供一個一致的界面，Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用[2]。

為了提高測試系統軟件的可重用性，通常把它分割成多個子系統，例如啟動工步子系統、查看曲線數據子系統、設置系統參數子系統等等。各子系統內部由更小的模塊組成，如果客戶端直接使用子系統的功能，它通常需要和子系統的多個模塊交互，任意一個模塊的變動將會引起客戶端的變動。本文通過為每個子系統建立一個外觀來封裝客戶端與子系統的交互，如圖4所示：StartWorkFacade外觀為工步子系統提供了StartWork和StopWork接口，方便客戶端進行啟動和停止工步的操作；ViewCurveFacade外觀為曲線數據子系統提供DisplayRealtimeData和DisplayHistoryData接口，方便客戶端進行查看實時和歷史數據的操作；SetSysParamFacade外觀為系統參數子系統提供SetParam和ModifyParam接口，方便客戶端進行設置和修改系統參數的操作。

通過使用外觀模式：不僅封裝了子系統外部和子系統內部多個模塊的交互過程，從而簡化了外部的調用；而且松散了客戶端與子系統的耦合關系，讓子系統內部模塊能更容易擴展和維護[8]。

圖4 外觀模式結構示意圖

3 結 語

本文雖然僅以抽象工廠模式、命令模式、觀察者模式、外觀模式為例講述設計模式在測試系統軟件中的應用。但在測試系統軟件開發各階段還使用到如下設計模式：在文件存儲和日志管理中應用了單例模式，保證在系統運行期間一個類只有一個實例并且該實例易于外界訪問，從而節約了系統資源；在控制器命令和數據庫存儲過程的執行步驟應用了模板方法，這樣可以將代碼的公共行為提取出來，達到復用的目的。在網絡通信應用代理模式，根據用戶選擇的通信方式（如以太網、RS 485、CAN）委托相應的通信驅動程序完成數據的收發。正是由于在測試系統軟件的開發過程廣泛運用了設計模式，實現了程序模塊間的低耦合和模塊內部的高內聚，提高了程序的可維護性和可復用性，能夠快速應對客戶需求的變化，成功設計出FCTS10、FCTS20、FCTS21等多個型號的測試系統。本文論述的設計模式具有一定的通用性，對于其他測試系統軟件開發具有一定的參考價值。

參考文獻

[1] 詹姆斯·拉米尼，安德魯·迪克斯.燃料電池系統：原里·設計·應用[M].2版.北京：科技出版社，2005.

[2] GAMMA Erich， HELM Richard， JOHNSON Ralp.設計模式：可復用面向對象軟件的基礎[M].李英軍，馬曉星，蔡敏，等譯.北京：機械工業出版社，2000.

[3] 莊立偉，衛建國，毛留喜.軟件設計模式在農業氣象系統開發中的應用[J].應用氣象學報，2011，22（5）：631?640.

[4] 楊成胡，何炳林，梁柱揚，等.質子交換膜燃料電池測試系統的研發[J].計算機測量與控制，2013，21（10）：2627?2629.

[5] 雷金勇，李鵬，于學軍，等.面向對象的設計模式在暫態仿真中的應用[J].電力系統及其自動化學報，2012，24（3）：35?40.

[6] 陳臣，王斌.研磨設計模式[M].北京：清華大學出版社，2011.

[7] 程杰.大話設計模式[M].北京：清華大學出版社，2007.

[8] 秦小波.設計模式之禪[M].北京：機械工業出版社，2010.

圖3 觀察者模式結構示意圖

2.4 外觀模式

外觀模式意圖為子系統中的一組接口提供一個一致的界面，Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用[2]。

為了提高測試系統軟件的可重用性，通常把它分割成多個子系統，例如啟動工步子系統、查看曲線數據子系統、設置系統參數子系統等等。各子系統內部由更小的模塊組成，如果客戶端直接使用子系統的功能，它通常需要和子系統的多個模塊交互，任意一個模塊的變動將會引起客戶端的變動。本文通過為每個子系統建立一個外觀來封裝客戶端與子系統的交互，如圖4所示：StartWorkFacade外觀為工步子系統提供了StartWork和StopWork接口，方便客戶端進行啟動和停止工步的操作；ViewCurveFacade外觀為曲線數據子系統提供DisplayRealtimeData和DisplayHistoryData接口，方便客戶端進行查看實時和歷史數據的操作；SetSysParamFacade外觀為系統參數子系統提供SetParam和ModifyParam接口，方便客戶端進行設置和修改系統參數的操作。

通過使用外觀模式：不僅封裝了子系統外部和子系統內部多個模塊的交互過程，從而簡化了外部的調用；而且松散了客戶端與子系統的耦合關系，讓子系統內部模塊能更容易擴展和維護[8]。

圖4 外觀模式結構示意圖

3 結 語

本文雖然僅以抽象工廠模式、命令模式、觀察者模式、外觀模式為例講述設計模式在測試系統軟件中的應用。但在測試系統軟件開發各階段還使用到如下設計模式：在文件存儲和日志管理中應用了單例模式，保證在系統運行期間一個類只有一個實例并且該實例易于外界訪問，從而節約了系統資源；在控制器命令和數據庫存儲過程的執行步驟應用了模板方法，這樣可以將代碼的公共行為提取出來，達到復用的目的。在網絡通信應用代理模式，根據用戶選擇的通信方式（如以太網、RS 485、CAN）委托相應的通信驅動程序完成數據的收發。正是由于在測試系統軟件的開發過程廣泛運用了設計模式，實現了程序模塊間的低耦合和模塊內部的高內聚，提高了程序的可維護性和可復用性，能夠快速應對客戶需求的變化，成功設計出FCTS10、FCTS20、FCTS21等多個型號的測試系統。本文論述的設計模式具有一定的通用性，對于其他測試系統軟件開發具有一定的參考價值。

參考文獻

[1] 詹姆斯·拉米尼，安德魯·迪克斯.燃料電池系統：原里·設計·應用[M].2版.北京：科技出版社，2005.

[2] GAMMA Erich， HELM Richard， JOHNSON Ralp.設計模式：可復用面向對象軟件的基礎[M].李英軍，馬曉星，蔡敏，等譯.北京：機械工業出版社，2000.

[3] 莊立偉，衛建國，毛留喜.軟件設計模式在農業氣象系統開發中的應用[J].應用氣象學報，2011，22（5）：631?640.

[4] 楊成胡，何炳林，梁柱揚，等.質子交換膜燃料電池測試系統的研發[J].計算機測量與控制，2013，21（10）：2627?2629.

[5] 雷金勇，李鵬，于學軍，等.面向對象的設計模式在暫態仿真中的應用[J].電力系統及其自動化學報，2012，24（3）：35?40.

[6] 陳臣，王斌.研磨設計模式[M].北京：清華大學出版社，2011.

[7] 程杰.大話設計模式[M].北京：清華大學出版社，2007.

[8] 秦小波.設計模式之禪[M].北京：機械工業出版社，2010.

圖3 觀察者模式結構示意圖

2.4 外觀模式

外觀模式意圖為子系統中的一組接口提供一個一致的界面，Facade模式定義了一個高層接口，這個接口使得這一子系統更加容易使用[2]。

為了提高測試系統軟件的可重用性，通常把它分割成多個子系統，例如啟動工步子系統、查看曲線數據子系統、設置系統參數子系統等等。各子系統內部由更小的模塊組成，如果客戶端直接使用子系統的功能，它通常需要和子系統的多個模塊交互，任意一個模塊的變動將會引起客戶端的變動。本文通過為每個子系統建立一個外觀來封裝客戶端與子系統的交互，如圖4所示：StartWorkFacade外觀為工步子系統提供了StartWork和StopWork接口，方便客戶端進行啟動和停止工步的操作；ViewCurveFacade外觀為曲線數據子系統提供DisplayRealtimeData和DisplayHistoryData接口，方便客戶端進行查看實時和歷史數據的操作；SetSysParamFacade外觀為系統參數子系統提供SetParam和ModifyParam接口，方便客戶端進行設置和修改系統參數的操作。

通過使用外觀模式：不僅封裝了子系統外部和子系統內部多個模塊的交互過程，從而簡化了外部的調用；而且松散了客戶端與子系統的耦合關系，讓子系統內部模塊能更容易擴展和維護[8]。

圖4 外觀模式結構示意圖

3 結 語

本文雖然僅以抽象工廠模式、命令模式、觀察者模式、外觀模式為例講述設計模式在測試系統軟件中的應用。但在測試系統軟件開發各階段還使用到如下設計模式：在文件存儲和日志管理中應用了單例模式，保證在系統運行期間一個類只有一個實例并且該實例易于外界訪問，從而節約了系統資源；在控制器命令和數據庫存儲過程的執行步驟應用了模板方法，這樣可以將代碼的公共行為提取出來，達到復用的目的。在網絡通信應用代理模式，根據用戶選擇的通信方式（如以太網、RS 485、CAN）委托相應的通信驅動程序完成數據的收發。正是由于在測試系統軟件的開發過程廣泛運用了設計模式，實現了程序模塊間的低耦合和模塊內部的高內聚，提高了程序的可維護性和可復用性，能夠快速應對客戶需求的變化，成功設計出FCTS10、FCTS20、FCTS21等多個型號的測試系統。本文論述的設計模式具有一定的通用性，對于其他測試系統軟件開發具有一定的參考價值。

參考文獻

[1] 詹姆斯·拉米尼，安德魯·迪克斯.燃料電池系統：原里·設計·應用[M].2版.北京：科技出版社，2005.

[2] GAMMA Erich， HELM Richard， JOHNSON Ralp.設計模式：可復用面向對象軟件的基礎[M].李英軍，馬曉星，蔡敏，等譯.北京：機械工業出版社，2000.

[3] 莊立偉，衛建國，毛留喜.軟件設計模式在農業氣象系統開發中的應用[J].應用氣象學報，2011，22（5）：631?640.

[4] 楊成胡，何炳林，梁柱揚，等.質子交換膜燃料電池測試系統的研發[J].計算機測量與控制，2013，21（10）：2627?2629.

[5] 雷金勇，李鵬，于學軍，等.面向對象的設計模式在暫態仿真中的應用[J].電力系統及其自動化學報，2012，24（3）：35?40.

[6] 陳臣，王斌.研磨設計模式[M].北京：清華大學出版社，2011.

[7] 程杰.大話設計模式[M].北京：清華大學出版社，2007.

[8] 秦小波.設計模式之禪[M].北京：機械工業出版社，2010.