5.5 來自第三方的LabVIEW設計模式-面向組件的設計2

5.5來自第三方的LabVIEW設計模式——面向組件的設計（LCOD）［上］（LabVIEWdesignpatternsfromathirdparty-acomponentorienteddesign(LCOD)）版本5

創(chuàng)建于:2011-2-8下午8:34作者jwdz-最后修改:

2011-2-18上午7:01作者jwdz

面向組件的設計模式——LCOD（LabVIEWComponentOrientedDesign）來自于JonConway，SteveWatts所著的《ASoftwareEngineeringApproachtoLabVIEW》一書（原版2003）。該書的譯者：羅宵、周毅等，中文版書名為：《軟件工程方法在LabVIEW中的應用》（中譯本2006年）。

筆者相信許多LabVIEW開好者和開發(fā)者都不止一次的、認真的讀過此書。但是，從直接的信息反饋來看（主要來自網評），大家對此書的內容褒貶不一。甚至有讀者認為此書苦澀難懂、不易理解。

這本書的確不易讀懂，筆者也曾不止一次的讀過此書，盡管某些地方到現在還無法認識和真正的理解，但是每次認真讀后都會有些體會。

筆者認為：本書從軟件工程的角度，提出了LabVIEW面向組件的設計模式。盡管面向組件的設計模式在LabVIEW的設計中尚未成為主流（或者根本就不會成為主流的設計方法），但是它的設計思想和原則會給我們提供很好的設計借鑒。

5.5.1軟件工程中好的軟件——松耦合、強內聚、信息隱藏和封裝

與基于文本的編程語言相比LabVIEW圖形化語言似乎天生就具備了好軟件的要求，因為圖形化代碼本身就具備——松耦合、強內聚、信息隱藏、抽象的特點，應該講這些特點絕對是毋庸置疑的。

盡管如此，在圖形化設計中，我們還是會遇到這樣或那樣的問題。比如：程序代碼的重用問題；代碼維護的問題、程序運行是否安全可靠等等問題。這些問題不是圖形化語言特有的，而是所有語言都面臨的問題，也就是軟件工程所要求的。如果在設計之初我們就按照軟件工程的要求安排和思考設計方案，我們就會將問題降到最少、將問題的影響降到最低。

圖形化代碼的松耦合、強內聚

松耦合

軟件設計中的耦合指——程序模塊間無關程度的度量。如果兩個模塊間很少交互，那么我們稱之為松散耦合。如果兩個模塊間交互程度很高，則稱之為緊密耦合。

眾所周知，圖形化代碼是基于數據流運行機制的，所以VI間的耦合（數據流動）是不可可少、必然存在的。

但是，從耦合的角度來看，人們自然非常希望每個VI的輸入、輸出連線應最少，并且應該將數據處理過程盡可能的包含在VI中，輸出僅僅包含最終的有效數據。

書中提供了一個松耦合測量系統(tǒng)的示例。參見下圖。

圖-1松耦合示例（中譯本-圖3.7）

上圖所示的測量系統(tǒng)可以完成某測試系統(tǒng)中的所有測量功能。你所要做的就是告訴它要測量什么，在輸出端就會得到相應的數據結果（這是一個組件）。

在LabVIEW中，最能體現松耦合的實例就是多功能信號發(fā)生器。如果已經確定其它參數不會發(fā)生改變，通過枚舉常量就可以任意選擇輸出信號類型：SineWave、TriangleWave、SquareWave、SawtoothWave。參見下圖。

圖-2松耦合的多功能信號發(fā)生器

松耦合能夠確保整個圖形化程序清晰、可讀，并且易于理解設計者的目的和用途。應該是每個圖形化程序設計者所追求的終極目標。

但是，在實際應用開發(fā)中我們仍然會遇到這樣或那樣的問題。比如：虛擬儀器本身要求有良好的、交互式的人機對話用戶界面。這樣就不可避免的使得數據在人機對話界面和程序框圖中傳遞，從而導致了VI間復雜的數據耦合關系存在。

如何減少VI間復雜的數據耦合關系，簇應該是一個很好的選擇。因為簇中可以包含眾多的同指向的、不同數據類型的控件。

面向組件的設計可以滿足上面的一些要求，也是作者所一再強調采用面向組件設計的原因之一。

下面我們在來看看軟件中的內聚。

強內聚

軟件設計中的內聚指——軟件模塊中各組成部分的相關程度強弱的度量。相關程度越強越好。

對于強內聚的理解，作者給出了一個針對內聚而言比較有說服力的測試系統(tǒng)示例。

整個測試系統(tǒng)是由一臺示波器和一臺信號發(fā)生組成，并通過GPIB控制和管理示波器和信號發(fā)生器以及整個測試系統(tǒng)。

測試工作為30次獨立的測試任務，為此創(chuàng)建了30個測試VI（Test1.vi-Test30.vi）。其中每個測試任務中都包含了對示波器和信號發(fā)生器的調用。

顯然，這種方式的內聚性不好。比如：要變更某個測試頻率，那就要對每個測試VI都進行修改，這對系統(tǒng)維護和升級相當不利。

最有效的解決的方案是改進內聚，也就是說：創(chuàng)建示波器VI、信號發(fā)生器VI和測試系統(tǒng)VI。

示波器VI——負責GPIB對示波器的讀、寫

信號發(fā)生器VI——負責GPIB對信號發(fā)生器的讀、寫

測試系統(tǒng)VI——負責整個30個測試任務中對示波器VI和信號發(fā)生器VI的控制和管理

在這樣的結構下，變更測試頻率只需變更示波器VI、信號發(fā)生器VI中的某些參數即可（不必對每個測試VI進行更改）。

這個例子告訴我們：選擇合理的設計方案和結構可以使得系統(tǒng)維護和升級相當簡便，這種設計思維方式是值得我們學習和掌握的。

本書在強內聚方面提供的另一個例子是使用ActiveX創(chuàng)建一個VI來控制Word97所需的全部功能。下面看看該組件。

圖-3WordControl.vi（組件）實現用ActiveX控件實現對Word97的控制

它實現的控制功能多達6種，其中包括：打開Word、關閉Word、插入文本、保存文檔、轉到書簽、粘貼等。參見下圖。

圖-4豐富的控制功能（Word97）

這是一個展示強內聚很好的組件。該組件也具有實際意義，在沒有《報告生成工具包》的情況下，它是一個很好的Word文檔處理組件?？上У氖翘幚淼腤ord版本太低。該程序代碼可以下載（LabVIEW——北方客棧－下載中心）。

實際上在LabVIEW中，許多多態(tài)VI都具備了強內聚的基本特性，讀者可以自己細心去慢慢品味，這里就不再一一列舉了。

圖形化代碼的信息隱藏和封裝

圖形化代碼的模塊化組織結構已經確保了信息隱藏和封裝已經作的很好了，這里所指的信息隱藏和封裝是相對于軟件工程中的要求和實際應用時需要注意的問題。

信息隱藏

軟件設計中的信息隱藏——常用于將復雜的東西隱藏在簡單的界面下。下面我們給出一個實際應用中的例子。

例：-1用USB-6211的I/O數據線控制繼電器組

在某應用項目中，我們需要使用USB-6211的I/O數據線控制一個繼電器組（僅在初始化時發(fā)送一組數字編碼），提供給4個不同的測試程序分別使用。數字I/O的數據輸出使用4條數據輸出線控制外部硬件譯碼器的4個輸入端，譯碼器的輸出端驅動繼電器。

我們使用了DAQ助手來實現這個DIO.vi的設計，其中確定使用的物理通道和控制的邏輯關系如下：

數字輸出順序

使用的物理通道

數字輸出_0

USB-6211/port1/line0

數字輸出_1

USB-6211/port1/line1

數字輸出_2

USB-6211/port1/line2

數字輸出_3

USB-6211/port1/line3

所代表的邏輯關系及物理意義如下：

0000——電壓1V

0001——電壓5V

0100——電流1A

0101——電流5A

圖-1DIO.vi程序框圖

圖-2DIO.vi前面版圖

這個DIO.vi的設計就是依據信息隱藏的設計思想方法實現的。我們可以在整個項目中的4個測試程序的初始化中使用它（不會同時運行）。僅依靠修改命令參數就可以實現不同的繼電器驅動。參見下圖。

圖-3初始化數字I/O

同時如果發(fā)生設計上的變更，僅僅修改命令和Case結構中的程序代碼就可以了。這里需要說明的是由于僅在測試程序初始化時運行該VI，所以我們?yōu)榱撕啽阍O計使用了DAQ助手來設計實現。

封裝

軟件設計中的封裝——對構成抽象概念的結構和行為的基本元素進行劃分的過程；封裝用于分離抽象概念及其實現之間的接口。

LabVIEW中的封裝更多的用于子VI的設計和實現。OpenG和MGI的VI就是利用封裝實現不同的函數（方法）處理。

封裝是使圖形化代碼模塊化的重要手法之一。

根據任務的要求能夠抽象出最基本結構和處理方法進行重新封裝近而達到實現模塊化設計和設計重用的目的。同時也標志著你的設計能力和水平在不斷地提高。下面我們看一個實際應用實例。

例：-2用諧波分析.vi實現信號基波提?。ā袄硐搿睘V波器）

在振動測試中，加速度測量一般是通過加速度傳感器來提取加速度信號。這里就面臨著一個問題：加速度的測量結構通常是用峰_峰值來表示的，可是我們所獲得的加速度信號中往往包含很多高次分量（諧波分量），用這樣的信號來表征加速度值往往是不正確的。因為包含諧波分量的信號峰_峰值與純正弦信號的峰_峰值是不一樣的。這樣就需要對含有諧波分量的加速度信號進行濾波，以期獲得純正的正弦信號來計算峰_峰值。

設計一個濾波器當然也可以，但是能否有更簡單、實用的方法呢？回答是可以的，我們利用對諧波分析.vi的重新封裝實現加速度信號的基波提取，同樣達到了濾波的效果（我們稱之為：理想濾波器）。將這個VI命名為：數字濾波器.vi。

設計思路是對LabVIEW內置VI——HarmonicDistortionAnalyer.vi進行設置后重新封裝而實現。參見下圖。

圖-4數字濾波器前面版圖

圖-5數字濾波器程序框圖

上圖中的Case結構“假”為：Inputsignal（不進行濾波）。

使用這個VI即完成頻率和諧波失真的測量又能夠提取基波信號（通過“濾波器加入”開關控制）相當有實用價值（輸入信號必須是周期信號）。當然，實現這個功能前提是必須對HarmonicDistortionAnalyer.vi有足夠的深入了解。對于多通道輸入信號稍加改動同樣可以實現。

它的演示說明和下載地址：/content/docs/DOC-12964

實際上，工程項目應用中我們需要許多自己定義封裝后的VI。下面在來看一個實際應用中的例子。

例：-3用諧波分析.vi實現諧波分量的顯示

我們都使用過HarmonicDistortionAnalyer.vi，一般用它來測量THD。可是有時候我們不僅需要知道THD的大?。〝抵担?，我們更想知道它的分布情況或者說THD中各次諧波所占有的比例關系。比如說：已知某信號的諧波失真THD為：10％，但是無法確定其中的2次諧波是多少？三次諧波又是多少？…….

這就需要我們創(chuàng)建一個新的VI來做諧波分量的分析。我們的基本目的是分析信號中各次諧波（20次以內）各占多少？并希望以圖形和數值的方式顯示出來。其實筆者也不具備這種精細的設計能力，也是從其它例程分析、摘得獲得的。對于大多數開好者而言，這是一種很好的學習方式。

現在我們命名這個VI為：Display_THD.vi。并給出它的前面版圖和程序框圖。參見下面的圖示。

圖-6Display_THD.vi前面版圖

圖-7Display_THD.vi程序框圖

該VI的設計方法以及各部分的功能就不談了，讀者可下載看看。相關的介紹參見下面的連接：/content/docs/DOC-14221。

為了演示這個VI的運行分析結果，我們特編制了一個演示VI（THD_3.vi），參見下面的圖示。

圖-8THD_3.vi前面版

圖-9THD_3.vi程序框圖

在上面的演示程序中，我們使用了一個三角波發(fā)生器代表含有諧波的信號，因為三角波的THD值是已知的（12.11％）。通過分析我們知道：三角波僅含有奇次諧波，其中三次諧波分量最大，同時它的諧波分布比較廣泛（我們僅分析到20次諧波）。

利用軟件工程的一些概念和原則指導我們進行圖形化代碼設計，可以使得應用程序變得更加健壯、容易移植、重用性更強。所以說本書中的內容具有很好的指導作用。

5.5.2LabVIEW面向組件的設計（LCOD）

作者在書中談到：在LabVIEW圖形化設計方法中，面向組件的設計應該是最佳的設計方法。我們認為設計組件的基本目的是圖形化代碼的模塊化，當然組件還有其它的好處，下面會慢慢談到。所以筆者也認同：組件是模塊化設計的最好方法之一。

為了能夠更清楚的理解面向組件的設計思想和設計方法，我們下面要探討什么是組件？組件的基本功能？組件應該如何設計、實現？

組件的一些基本要求

軟件中的組件應該能夠滿足下面的最基本要求：

組件的基本要求

組件必須對所有要提供的服務提供明確的說明組件和其它組件交互的唯一途徑就是預先定義好的接口。組件的所有數據和進程都必須封裝在接口背后。組件應當足夠獨立，以便能夠單獨測試。組件或者使用組件的軟件都必須只依賴與預先定義的接口和指定的操作。

具體到LabVIEW圖形化編程語言，對組件的定義是：組件由VI構成。構成組件的VI通過簡單的接口提供多種服務。組件應具備強內聚（VI的層次結構）、信息隱藏（子VI功能隱藏）和松耦合（簡單的接口）。

我們設計圖形化組件的最主要目的就是：模塊化可在其它項目中可重復使用維護簡單升級和更改方便可靠性高自行完成初始化自行完成錯誤處理能夠在本地永久地保存其狀態(tài)

組件的最終模式參見下圖。

圖-1組件

組件滿足了軟件設計中的松耦合、強內聚的基本原則。本著這樣的基本原則，我們就可以設計自己應用項目中的組件。品嘗組件為我們帶來的好處。

如何設計組件？

事實上，如果僅僅需要使用LabVIEW做些簡單的試驗和設計，完全不需要考慮設計什么組件。

但是，如果為了更好的適應項目的需求，保證項目的內容更加容易修改，當然未來也許還會被重用。所以還是建議考慮使用設計組件的方法，至少應該采用模塊化的設計方法。

那么如何設計組件呢？程序中的那些部分應該使用組件來設計呢？

這的確是一個很頭疼的問題，因為大多數的LabVIEW愛好者并不熟悉如何解決這類的問題。他們更看重的是項目應用的結果或者說能否實現項目的設計。其實，我們在軟件設計中有一個解決復雜問題的法寶——就是抽象處理。

抽象

在解決復雜問題時的一種思維方式。

對于復雜問題最好的處理方法是將其抽象處理，也就是將復雜問題簡單化，然后尋求最佳的處理方案或處理方法。

比如說：在一個測試項目中，我們根本不知道那些程序應該放置到圖-1所示的組件黑盒子中。也就說，黑盒子中應該包含那些程序代碼是不清晰的。

解決這個問題的方法就是將項目抽象的分成幾個部分或階段，針對每一個不同階段采用不同的處理方法。

我們來看看作者是如何處理這樣的問題。

在軟件苦旅中，它將WidgetometerTestSystem劃分為幾個主要部分來處理：

UIController-MessageQueue（UI控制器——消息隊列處理）SectionKeyedDataHandling（分組關鍵字數據處理）Control>Drive>Read（控制》驅動》讀?。〦rrorControl（錯誤處理）

作者為上述部分單元都給出了使用組件設計的實例。關于組件設計方法，書中給出了組件的基本設計原則，這些基本原則包括：自定義的枚舉常量、狀態(tài)機架構、移位寄存器、錯誤處理等等。利用這些基本原則完全可以幫助我們實現組件的設計，這里就不做更多的討論了。因為在例：-1用USB-6211的I/O數據線控制繼電器組中我們已經看到組件的設計實例（盡管它很簡單）。

盡管包括我在內的許多讀者都看不懂這些實例的真正內涵，是因為我們沒有真正理解項目的要求，所以也就自然無法理解、認識如何處理這些問題的方法。比如，我們完全可以使用事件結構來處理GUI消息，而并非一定要采用隊列的方式。

初學者（包括我）往往陷入這樣的狀況之中，就是期待直接獲得最實用的圖形化程序代碼來拓展、指導我們的設計。

我們說，在一些實用技巧和應用實例中，直接獲得實例代碼是最快、最有效的程序設計方法。但是，在應對大型項目的設計，我們真的很難獲得這樣的幫助。應該說，這本書做到了這一點。

我們似乎自相矛盾，一會說：此書難懂；一會又強調此書很有幫助。那么到底這本書為我們帶來了什么？

它為我們帶來了LCOD的設計思想。這種設計思想將指導我們實現組件設計或模塊化設計。

5.5.3LabVIEW面向組件（LCOD）的設計思想

可以說，讀此書給我?guī)淼淖畲笫斋@不是那些實例代碼。而是那些實現這些實例代碼的設計思想。這應該是最有價值的收獲之一。

縱觀此書，依據軟件工程要求提出了以下LCOD的設計思想。

LCOD設計的黃金法則

“代碼內抽象，代碼外細節(jié)”［］

“看看自己的VI，每次你看到數字或字符串，它們都會被放在一個文件或數據庫中，是的，它們中的每個都如此?！保郏?/p>

解讀：在程序代碼中消滅一切數字（常量）和字符串（常量），統(tǒng)統(tǒng)將它們隱藏到配置文件或數據庫中。取而代之的是枚舉命令常量。這樣設計的組件才具有靈活性、強壯性和良好的維護性。

如何做到這些呢？書中給出了一個例子（原書中的圖6.25和圖6.26）。

圖-1代碼細節(jié)外露，不好！

這是一個測量組件，通過Command來配置設定某項目中的測量通道（使用的驅動是傳統(tǒng)DAQ），顯然圖中代碼的細節(jié)外漏無疑。如果項目中使用的通道發(fā)生變化或者測量范圍發(fā)生變化或者是硬件發(fā)生變化時，則必須修改這個VI中的許多參數。如果通道數較多，那就只好慢慢來吧！

依據黃金法則，作者設計出了一個更加實用有效的例子。

圖-2代碼中的細節(jié)隱藏，好！

看清楚了吧，原圖-1代碼中的數字常量和字符串常量都不見了，取而代之的是3個Config.vi和一些枚舉常量。通過Config.vi的讀將配置文件或數據庫中的信息直接讀入，這樣再修改和變更某些參數，就可以通過修改相應的文件或數據庫內容既可以了，無須在直接修改程序代碼。

現在，依據這樣的設計思想就可以實現你的應用項目設計了。很麻煩嗎？在項目中這可是一個極為理想的解決方案。本書的最后部分給出了當用戶提出新的要求時，變更是如此的簡單和方便。

當然，如何保存和讀取這些信息就引出了分組關鍵字文件。

LCOD設計中的分組關鍵字文件

所謂分組關鍵字文件，也就是通常所說的配置文件（.ini文件）。此書的作者對此進行了一些特殊的設計。比如設置了文件讀取、保存時的密碼等。最終設計出系統(tǒng)配置管理器組件（SysremConfigDataManager）。這樣那些不準備外露的程序代碼終于有地方和有辦法讀取了。

現在好了，用戶需要變更硬件或硬件的測量通道，那么修改相關的配置文件中的某些參數就可以了，根本無須改動更多的程序代碼。只有新的硬件出現或者說新的命令出現，我們才需要設計更新部分代碼（新命令中所涉及到的那部分）。應對自如，決不是幻想，而是現實。

圖-3WidgetometerConfigini文件

舉一個例子，我們設計完成了一套振動測試系統(tǒng)。當時設計的硬件選擇的是：NIUSB9233。此后NI又陸續(xù)推出了：NIUSB9234、NIUSB4431、NIUSB4432。這些硬件都可以使用在我們所設計的振動測試系統(tǒng)中，如果有用戶需要選擇這些硬件，我們必須認真、仔細的一個一個的修改原來振動測試系統(tǒng)軟件中的一些VI。

當真正地理解了組件的設計思想我們還會那樣做嗎？

這部分的其它關鍵內容還是希望大家自己去看看，這對于理解組件和設計使用組件會有很大的幫助。

5.5.4LabVIEW面向組件的設計帶給我們什么？

有朋友會問到：LabVIEW面向組件的設計帶給我們什么？

筆者認為：它帶給我們的是一種設計思想。這種設計思想不僅可以指導我們實現面向組件的設計。同時，還可以用來指導我們進行模塊化設計。我們認為：模塊化設計比組件設計低一個層次。這樣說教可能很難令人真正理解和信服，下面我們還是通過一個最簡單的模塊化設計例子來看看二者之間的細微差別。

例：5.5.4-1TopLevelVI

我們知道，每個項目中都有一個TopLevelVI。所以當我們做一個新項目時，就會設計一個新的TopLevelVI。

開始做項目時，我們還故弄玄虛把界面作的很花哨，時間長了，做多了就會感到這樣的做法很煩。于是慢慢就想到使