摘 要： 針對傳統(tǒng)的面向過程的軟件設(shè)計方法已無法應(yīng)對市場對燃料電池測試系統(tǒng)快速的需求變化，提出將設(shè)計模式應(yīng)用于燃料電池測試系統(tǒng)軟件的開發(fā)過程，重點(diǎn)介紹了抽象工廠模式、命令模式、觀察者模式、外觀模式的應(yīng)用。實(shí)驗(yàn)結(jié)果表明，基于面向?qū)ο笤O(shè)計模式開發(fā)的燃料電池測試系統(tǒng)軟件具有良好的架構(gòu)，實(shí)現(xiàn)了程序模塊間的低耦合和模塊內(nèi)部的高內(nèi)聚，提高了程序的可維護(hù)性和可復(fù)用性，能夠靈活應(yīng)對功能需求的變化。采用該架構(gòu)開發(fā)完成的多款燃料電池測試軟件運(yùn)行穩(wěn)定可靠。

關(guān)鍵詞： 面向?qū)ο笤O(shè)計模式； 燃料電池； 測試系統(tǒng)； 軟件開發(fā)

中圖分類號： TN964?34 文獻(xiàn)標(biāo)識碼： 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

燃料電池是一種能夠?qū)Υ嬖跉淙剂虾脱趸瘎┲械幕瘜W(xué)能直接轉(zhuǎn)化為電能的發(fā)電裝置，它具有能量轉(zhuǎn)換效率高、對環(huán)境污染小等優(yōu)點(diǎn)[1]。燃料電池在世界范圍掀起研究的熱潮，目前國內(nèi)外不少公司研制出專門的測試系統(tǒng)，以實(shí)現(xiàn)對燃料電池進(jìn)行性能的評估。燃料電池測試系統(tǒng)（以下簡稱測試系統(tǒng)）包括測試設(shè)備以及配套的測試軟件，其中測試軟件平臺提供用戶與測試設(shè)備之間操作接口，是整個測試系統(tǒng)的核心。鑒于傳統(tǒng)的面向過程的軟件開發(fā)方法存在的問題，本文將研究如何將設(shè)計模式應(yīng)用于燃料電池測試軟件，設(shè)計出良好體系結(jié)構(gòu)的系統(tǒng)，從而不僅使測試系統(tǒng)很好地應(yīng)對快速多變的需求，同時使測試系統(tǒng)具有更好的穩(wěn)定性、擴(kuò)展性、維護(hù)性。

1 設(shè)計模式簡介

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

2 設(shè)計模式應(yīng)用

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

2.1 抽象工廠模式

抽象工廠模式意圖提供一個創(chuàng)建一系列相關(guān)或相互依賴對象的接口，無需指定它們具體的類[2]。在抽象工廠模式中，工廠類與產(chǎn)品類具有平行的對等結(jié)構(gòu)，它們之間一一對應(yīng)。核心的抽象工廠類不負(fù)責(zé)所有產(chǎn)品的創(chuàng)建，僅負(fù)責(zé)給出具體工廠類必須實(shí)現(xiàn)的接口，具體產(chǎn)品的創(chuàng)建由具體工廠類去實(shí)現(xiàn)[5]。endprint

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

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

2.2 命令模式

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

圖1 抽象工廠模式結(jié)構(gòu)示意圖

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

圖2 命令模式結(jié)構(gòu)示意圖

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

2.3 觀察者模式

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

圖3 觀察者模式結(jié)構(gòu)示意圖

2.4 外觀模式

外觀模式意圖為子系統(tǒng)中的一組接口提供一個一致的界面，F(xiàn)acade模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用[2]。

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

通過使用外觀模式：不僅封裝了子系統(tǒng)外部和子系統(tǒng)內(nèi)部多個模塊的交互過程，從而簡化了外部的調(diào)用；而且松散了客戶端與子系統(tǒng)的耦合關(guān)系，讓子系統(tǒng)內(nèi)部模塊能更容易擴(kuò)展和維護(hù)[8]。

圖4 外觀模式結(jié)構(gòu)示意圖

3 結(jié) 語

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

參考文獻(xiàn)

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

[2] GAMMA Erich， HELM Richard， JOHNSON Ralp.設(shè)計模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)[M].李英軍，馬曉星，蔡敏，等譯.北京：機(jī)械工業(yè)出版社，2000.

[3] 莊立偉，衛(wèi)建國，毛留喜.軟件設(shè)計模式在農(nóng)業(yè)氣象系統(tǒng)開發(fā)中的應(yīng)用[J].應(yīng)用氣象學(xué)報，2011，22（5）：631?640.

[4] 楊成胡，何炳林，梁柱揚(yáng)，等.質(zhì)子交換膜燃料電池測試系統(tǒng)的研發(fā)[J].計算機(jī)測量與控制，2013，21（10）：2627?2629.

[5] 雷金勇，李鵬，于學(xué)軍，等.面向?qū)ο蟮脑O(shè)計模式在暫態(tài)仿真中的應(yīng)用[J].電力系統(tǒng)及其自動化學(xué)報，2012，24（3）：35?40.

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

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

[8] 秦小波.設(shè)計模式之禪[M].北京：機(jī)械工業(yè)出版社，2010.

圖3 觀察者模式結(jié)構(gòu)示意圖

2.4 外觀模式

外觀模式意圖為子系統(tǒng)中的一組接口提供一個一致的界面，F(xiàn)acade模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用[2]。

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

通過使用外觀模式：不僅封裝了子系統(tǒng)外部和子系統(tǒng)內(nèi)部多個模塊的交互過程，從而簡化了外部的調(diào)用；而且松散了客戶端與子系統(tǒng)的耦合關(guān)系，讓子系統(tǒng)內(nèi)部模塊能更容易擴(kuò)展和維護(hù)[8]。

圖4 外觀模式結(jié)構(gòu)示意圖

3 結(jié) 語

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

參考文獻(xiàn)

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

[2] GAMMA Erich， HELM Richard， JOHNSON Ralp.設(shè)計模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)[M].李英軍，馬曉星，蔡敏，等譯.北京：機(jī)械工業(yè)出版社，2000.

[3] 莊立偉，衛(wèi)建國，毛留喜.軟件設(shè)計模式在農(nóng)業(yè)氣象系統(tǒng)開發(fā)中的應(yīng)用[J].應(yīng)用氣象學(xué)報，2011，22（5）：631?640.

[4] 楊成胡，何炳林，梁柱揚(yáng)，等.質(zhì)子交換膜燃料電池測試系統(tǒng)的研發(fā)[J].計算機(jī)測量與控制，2013，21（10）：2627?2629.

[5] 雷金勇，李鵬，于學(xué)軍，等.面向?qū)ο蟮脑O(shè)計模式在暫態(tài)仿真中的應(yīng)用[J].電力系統(tǒng)及其自動化學(xué)報，2012，24（3）：35?40.

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

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

[8] 秦小波.設(shè)計模式之禪[M].北京：機(jī)械工業(yè)出版社，2010.

圖3 觀察者模式結(jié)構(gòu)示意圖

2.4 外觀模式

外觀模式意圖為子系統(tǒng)中的一組接口提供一個一致的界面，F(xiàn)acade模式定義了一個高層接口，這個接口使得這一子系統(tǒng)更加容易使用[2]。

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

通過使用外觀模式：不僅封裝了子系統(tǒng)外部和子系統(tǒng)內(nèi)部多個模塊的交互過程，從而簡化了外部的調(diào)用；而且松散了客戶端與子系統(tǒng)的耦合關(guān)系，讓子系統(tǒng)內(nèi)部模塊能更容易擴(kuò)展和維護(hù)[8]。

圖4 外觀模式結(jié)構(gòu)示意圖

3 結(jié) 語

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

參考文獻(xiàn)

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

[2] GAMMA Erich， HELM Richard， JOHNSON Ralp.設(shè)計模式：可復(fù)用面向?qū)ο筌浖幕A(chǔ)[M].李英軍，馬曉星，蔡敏，等譯.北京：機(jī)械工業(yè)出版社，2000.

[3] 莊立偉，衛(wèi)建國，毛留喜.軟件設(shè)計模式在農(nóng)業(yè)氣象系統(tǒng)開發(fā)中的應(yīng)用[J].應(yīng)用氣象學(xué)報，2011，22（5）：631?640.

[4] 楊成胡，何炳林，梁柱揚(yáng)，等.質(zhì)子交換膜燃料電池測試系統(tǒng)的研發(fā)[J].計算機(jī)測量與控制，2013，21（10）：2627?2629.

[5] 雷金勇，李鵬，于學(xué)軍，等.面向?qū)ο蟮脑O(shè)計模式在暫態(tài)仿真中的應(yīng)用[J].電力系統(tǒng)及其自動化學(xué)報，2012，24（3）：35?40.

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

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

[8] 秦小波.設(shè)計模式之禪[M].北京：機(jī)械工業(yè)出版社，2010.