外文文獻(xiàn)翻譯-labview程序框圖設(shè)計

1、<p>　　LabVIEW程序框圖設(shè)計</p><p>　　摘要：一個真正好的程序就像一件藝術(shù)品一樣，而差的程序看起來就像意大利面那樣亂。這篇文章提出的風(fēng)格能確保我們實際應(yīng)用中在規(guī)定時間內(nèi)開發(fā)出整潔，結(jié)構(gòu)清晰的程序。結(jié)合其他規(guī)則，我們能開發(fā)出可讀性好的，易于維護(hù)的LabView源代碼。</p><p>　　LabVIEW的程序框圖長于源代碼表述。一個真正好的程序是發(fā)人深省的，甚至

2、是令人敬畏的，就是一件藝術(shù)品一樣。而一個差的程序，看起來就像一碗意大利面條那樣凌亂。事實上，這兩種極端的情況就像《風(fēng)格的重要性》中Meticulous VI 和 Spaghetti VI所表現(xiàn)的那樣。而大部分程序處于藝術(shù)品和意大利面條之間。一些程序開發(fā)者有連線整齊的習(xí)慣，但程序框圖往往卻大而寬泛。其他的一些程序開發(fā)者卻過度使用模塊化編程，就像自己在搭建筑一樣。而仍有一些編程人員喜歡使用變量方式而非數(shù)據(jù)流方式。很多很多開發(fā)人員在文檔上節(jié)省

3、時間。此外，很多程序是在好的風(fēng)格和節(jié)約時間兩者之間取得平衡下為特征下完成工作的?？傮w結(jié)論就是在吸引人的程序外觀，個人喜好和程序功能上取得折中。</p><p>　　大多數(shù)開發(fā)人員都錯誤認(rèn)為吸引人的程序編寫上受到許多束縛使開發(fā)進(jìn)度變慢，而現(xiàn)實中程序開發(fā)都有時間限制。似乎快速開發(fā)程序的和程序具有美感是相矛盾的。事實上，多花些時間來優(yōu)化復(fù)雜程序的外觀是可能的如果你知道什么才是好的風(fēng)格所要遵循的規(guī)則和如何執(zhí)行這些規(guī)則，你

4、將會在程序開發(fā)中更加輕松。</p><p>　　屏幕分辨率決定程序開發(fā)人員在開發(fā)程序時的可見區(qū)域和程序移植到用戶計算機后的界面顯示。因此，將程序分辨率統(tǒng)一是非常有好處的，那樣應(yīng)用程序在使用相同分辨率的PC上打開時窗口界面將保存一致。程序分辨率設(shè)置得越高，界面上的控件將根據(jù)屏幕大小相應(yīng)的縮小，屏幕上也能容納更多的程序代碼。合適的屏幕分辨率是不僅要能使程序的可見區(qū)域最大化，而且不能讓你的眼睛不舒服。LabView開發(fā)

5、環(huán)境設(shè)定的最小程序分辨率為1024*768。與PC顯示技術(shù)發(fā)展相適應(yīng)的1280*1024的屏幕分辨率能提供更多的可視區(qū)域。不要采用高于1280*1024的分辨率，因為當(dāng)前還不廣泛支持如此高的分辨率，更大的工作區(qū)域也意味者程序框圖更大，模塊化程度降低。同時，取決于顯示器的大小，如果過高的分辨率容易使你的眼睛疲勞。</p><p>　　今天許多計算機都支持多顯示器。在LabView開發(fā)環(huán)境采用兩個顯示器是非常有好處的

6、。使用一個顯示器來顯示前面板，另外一個顯示器來顯示程序框圖。這樣就能同時看到這兩個窗口，而不需要在前面板和程序框圖之間進(jìn)行切換。</p><p>　　不要給程序框圖著色。界面的背景色和每個結(jié)構(gòu)的子界面都默認(rèn)為白色。數(shù)據(jù)流向必須非常容易識別。我們希望對象盡量布局緊湊，但同時不希望對象靠得太近引起對象和連線重疊?？傊?，盡量縮小程序框圖大小使之能在一個屏幕顯示出來。在某些情況下，比如說某些復(fù)雜的程序包含很多個并行循環(huán)，

7、要滿足這個限定非常困難。在這種情況下，調(diào)整程序框圖，或者將一些循環(huán)變成子VI來減小所占背面板空間，使背面板僅在一個方向上滑動。</p><p>　　開發(fā)程序時，VI之間應(yīng)采用從上至下和自下而上相結(jié)合的方法來構(gòu)建多層次結(jié)構(gòu)關(guān)系。VI的層次結(jié)構(gòu)可以通過選擇View»VI Hierarchy 來查看。從窗口的工具條中取消選擇包括VI Lib ,包括全局變量和包括自定義類型，并且只顯示你自己提供的用戶VI。通常

8、的幾何形狀包括金字塔形，鉆石形和橢圓形。除了非常簡單的應(yīng)用程序外，VI層次結(jié)構(gòu)中在頂層VI之下的應(yīng)包含多行子VI。在第一章中，模塊化率被定義為是用戶VI數(shù)與總的節(jié)點數(shù)之比，再乘100。這些數(shù)據(jù)的大小可以通過選擇Tools»Profile»VI Metrics快速查看到。典型應(yīng)用程序的模塊化率推薦為3.0以上。</p><p>　　取決于設(shè)計樣式，許多頂層程序都應(yīng)包含結(jié)構(gòu)，連線，VI組件和子VI

9、。VI組件是處于非常高層的子VI，或者是將一個應(yīng)用程序的主要部分或子系統(tǒng)封裝為插件后動態(tài)調(diào)用的VI。一個應(yīng)用程序的圖形用戶見面和數(shù)據(jù)采集引擎是以單獨的vi實現(xiàn)的，它們就是組件VI的一個例子。頂層和高層vi應(yīng)該盡可能減少的低層數(shù)據(jù)處理函數(shù)，例如數(shù)學(xué)函數(shù)，數(shù)組處理，格式化字符串以及類似的函數(shù)。</p><p>　　一些應(yīng)用程序需要大量的數(shù)值屬性節(jié)點來控制GUI行為。許多屬性節(jié)點的讀寫操作是由GUI事件觸發(fā)。因此，事件

10、結(jié)構(gòu)是理想的處理屬性節(jié)點的結(jié)構(gòu)。因為，事件結(jié)構(gòu)為每個事件分支包含一個單獨的子程序，通常一個事件分支的程序不會跑到其他的事件分支。然而，多事件分支需要許多個相同的屬性節(jié)點，它們的值因每次讀寫操作而不同。將這些普通的屬性節(jié)點模塊化為子VI，通過控件引用和屬性值傳遞到子VI中。每個子VI程序代表在內(nèi)存中同一屬性節(jié)點的備份。這減小了內(nèi)存使用和程序復(fù)雜性。</p><p>　　同樣的，將你程序中的高層組件模塊化為較低級的子

11、VI。使用自頂向下的設(shè)計和開發(fā)方法，將任何低層程序模塊化為強內(nèi)聚的子VI。在任何的地方如果你用到了已有代碼的副本來共同構(gòu)成一個程序，將這些代碼替換成子VI。一個子VI是否是內(nèi)聚的要看你是否能將它要完成的工作清楚的描述為兩三句話，就像子VI描述信息那樣。</p><p>　　子VI非常有用，因為相對于一個大型程序來說，它易于開發(fā)，測試，調(diào)試，維護(hù)和代碼重用。如圖4-2C所示，子VI也為程序開發(fā)中節(jié)省了可觀的背面板空

12、間?？傊?，如果同一函數(shù)，屬性節(jié)點，程序被多次用到，將這些重復(fù)代碼換成子VI將使程序開發(fā)變簡單。同樣，如果幾個沒用被重復(fù)使用的節(jié)點彼此相關(guān)，并且一起完成某項工作，不管它們是否被多次用到，也將它們變?yōu)橐粋€內(nèi)聚的子VI。但是，也不要為了節(jié)省空間而隨便選擇將程序的某部分變成子VI。以這種方式創(chuàng)建的子VI不是內(nèi)聚的，也不夠直觀并且不可重用。同樣也不要為只有少量接線端的程序代碼創(chuàng)建子VI。這種情況，子VI圖標(biāo)不需要在程序框圖掩蓋它下層的代碼。子VI

13、只包含一個數(shù)組索引函數(shù)。然而，子VI的圖標(biāo)，名字和描述信息掩蓋數(shù)組索引函數(shù)。LabView函數(shù)和將子VI打包成的VI.lib通常是可識別的，因而不需再單獨將它們封裝成子VI。</p><p>　　為每個子VI創(chuàng)建一個有含義的圖標(biāo)和相結(jié)合的描述。住為每個子VI創(chuàng)建一個有含義的圖標(biāo)和相結(jié)合的描述。再怎么強調(diào)它的重要性都是不夠的。這是我們最神圣的信條。圖標(biāo)和描述信息能幫助我們在調(diào)用這些子VI的程序時通過幫助窗口的文字識

14、別這些子VI。這些描述迫使我們進(jìn)行內(nèi)聚性測試。如果你不能通過2到3句話總結(jié)子VI的功能，子VI可能包含了太多的子代碼。</p><p>　　隧道連線通過結(jié)構(gòu)左側(cè)邊界進(jìn)入結(jié)構(gòu)，并從結(jié)構(gòu)的右側(cè)邊界穿過結(jié)構(gòu)。不要讓隧道在結(jié)構(gòu)的頂部或底部穿過。同樣如果結(jié)構(gòu)內(nèi)部未使用到也不要讓連線穿過結(jié)構(gòu)，除非其目的是為了標(biāo)示清楚。特別令人困苦的是瀏覽一個多幀結(jié)構(gòu)的許多幀時，要去尋找那些在連線上被修改的數(shù)據(jù)，比如說條件結(jié)構(gòu)或者是事件結(jié)構(gòu)。

15、然而，有時條件結(jié)構(gòu)通過一些額外的連線線是非常有用的將沒有連線的前面板控件在程序框圖上放在一起，那樣程序開發(fā)人員就能非常容易的將找到它們。標(biāo)記那些在程序只用到一次，不在循環(huán)結(jié)構(gòu)中的接線端 。</p><p>　　實踐中大多數(shù)局部變量，全局變量和順序結(jié)構(gòu)都不是必要的。沒有學(xué)習(xí)過有效數(shù)據(jù)流法則的開發(fā)者經(jīng)常過多地使用局部變量和全局變量。強迫自己避免使用變量和順序結(jié)構(gòu)是最有效的掌握數(shù)據(jù)流的方法，除非完全必要要用到它們。的確

16、，掌握數(shù)據(jù)流和盡可能避免使用變量和順序結(jié)構(gòu)具有相同的含義。</p><p>　　為了避免連線混亂且保持有組織秩序，緊湊地放置移位寄存器且將它們聚集到靠近循環(huán)的頂部。這樣如同在靠近循環(huán)頂端位置有限的區(qū)域內(nèi)修建一條數(shù)據(jù)公路且使線路交叉最少。除了聚合了包括錯誤簇和條件選擇器的移位寄存器外。只要在移位寄存器之間留下剛好夠放置自由標(biāo)簽的位置就行了，這些標(biāo)簽將被放置在靠近移位寄存器左邊終端的線上。錯誤簇經(jīng)常在循環(huán)的底部進(jìn)出，

17、而條件選擇器經(jīng)常處于中間位置。因此，錯誤簇和條件選擇器經(jīng)常與靠近循環(huán)頂部的數(shù)據(jù)公路是分離的。</p><p>　　最糟的編程習(xí)慣是從一個選定區(qū)域創(chuàng)建一個VI而且不清理創(chuàng)建子VI后的狼藉場面。終端位置，標(biāo)簽，線，連接器分配，圖標(biāo)以及描述文檔都需要進(jìn)行矯正。有時這樣還會導(dǎo)致子VI的程序結(jié)構(gòu)圖就像在里面投了一顆炸彈一樣。用這種工具創(chuàng)建的子VI從來就不是一個好的風(fēng)格而且程序必須改寫。</p><p&g

18、t;　　關(guān)閉檢查展示出從右向左的線是一個文件路徑，它是由Case結(jié)構(gòu)里面的若干底層函數(shù)所形成的。不管怎樣，在頂層VI上由若干底層函數(shù)共同組成以完成某種功能的程序最好用一個子VI的形式出現(xiàn)。</p><p>　　這篇文章提出的風(fēng)格能確保我們實際應(yīng)用中在規(guī)定時間內(nèi)開發(fā)出整潔，結(jié)構(gòu)清晰的程序。結(jié)合其他規(guī)則，我們能開發(fā)出可讀性好的，易于維護(hù)的LabView源代碼。而且，遵守這些好的編程風(fēng)格所要求的準(zhǔn)則將可能會使我們開發(fā)出

19、令人贊嘆的LabView程序。</p><p>　　The LabVIEW Program Diagram Design</p><p>　　ABSTRACT：A really good diagram is like a work of art. Some developers have neat wiring practices but large, flat diagrams. Th

20、is chapter presents style rules that ensure neat and organized diagrams that are practical to implement in real applications with tight deadlines. Combined with the rules in other chapters, they ensure readable and maint

21、ainable LabVIEW source code</p><p>　　The LabVIEW block diagram excels at conveying source code. A really good diagram is enlightening, even awe-inspiring, like a work of art. Some developers have neat wiring

22、 practices but large, flat diagrams. Others have overly modular diagrams that disguise the architecture. . Indeed, these two extremes are depicted by Meticulous VI and Spaghetti VI in Chapter 1, "The Significance of

23、 Style." Somewhere in the middle between artwork and spaghetti is where most applications reside. Still others pref</p><p>　　Many developers wrongfully assume that attractive diagrams require a level of

24、 toil that is impractical for real-world applications that have tight deadlines. It seems faster and more productive to avoid getting caught up in diagram aesthetics. Indeed, it is possible to expend excessive time optim

25、izing the appearance of a complex diagram, If you know the style rules and how to implement them, you eliminate the toil. </p><p>　　The LabVIEW development environment is designed for a minimum 1024x768 reso

26、lution. A resolution of 1280x1024 provides additional real estate while maintaining compatibility with mainstream PC display technology. Avoid resolutions much higher than 1280x1024 because higher resolutions are less un

27、iversally supported, and the larger work area promotes larger diagrams and potentially less modularity. Also, depending on the monitor size, very high resolutions may strain your eyes.</p><p>　　The display r

28、esolution affects the visible area the developer has to work with and how the diagram appears when opened on a given target computer. It is beneficial to standardize on one display resolution so that the diagram window m

29、aintains a consistent appearance when opened on PCs with similar display capabilities. The higher the resolution setting, the smaller the diagram objects shrink relative to the screen size, and the more code fits on one

30、screen. A fairly high resolution is recommended</p><p>　　Do not color the diagrams. Leave the background of the diagram, and every subdiagram of every structure, default white. Data flow must be easy to visu

31、alize. A high density of objects is desired, without crowding objects too close and causing wires and objects to overlap. In general, try to limit the diagram size to one display screen. In some situations, it is difficu

32、lt to work within this constraint, such as a complex diagram containing multiple parallel loops. In this case, organize the large </p><p>　　Develop your applications as a multilayer hierarchy of subVIs using

33、 a combination of top-down and bottom-up design and development techniques. The VI Hierarchy is viewed by selecting View»VI Hierarchy. Deselect Include VI Lib, Include Globals, and Include typedef from the toolbar t

34、o remove these items from the window, and view only the hierarchy of user VIs that you provided. Common geometries include pyramid, diamond, and oval. Except for very simple applications, the VI Hierarchy should contai&l

35、t;/p><p>　　Depending on the design pattern, most top-level diagrams should consist of structures, wires, component VIs, and subVIs. Component VIs are very high-level subVIs, or dynamically loaded plug-in VIs, t

36、hat encapsulate a major portion or subsystem of the application. An application's graphical user interface and data acquisition engine, implemented as separate VIs, are examples of component VIs. The top-level and hi

37、gh-level diagrams should contain very few low-level data-manipulation functions, such</p><p>　　Some applications require large numbers of Property Nodes for controlling GUI behavior. Most Property Node read

38、and write operations are triggered by GUI events. Consequently, the Event structure is an ideal construct for handling Property Nodes. Because the Event structure contains separate subdiagrams for each event case, it is

39、uncommon to run out of space. However, it is common to have multiple event cases that require many of the same Property Nodes, with different values read or written to </p><p>　　Likewise, modularize the diag

40、rams of your high-level component VIs into lower-level subVIs. Using the top-down design and development approach, modularize any low-level routines into cohesive subVIs. Anywhere you have a collection of related functio

41、ns that work together to perform a specific routine, replace them with a subVI. A subVI is cohesive if you can clearly describe its purpose in two or three sentences, such as when entering the subVI's description.<

42、;/p><p>　　SubVIs are advantageous because it is easier to develop, test, debug, maintain, and reuse software modules as subVIs versus sections of a large diagram. As shown in Figure 4-2C, they also provide a co

43、nsiderable space-saving benefit. In general, if the collection of functions or Property Nodes or other routine is used in more than one place, it is an easy decision: Replace the repeated code with a subVI. Likewise, if

44、several nonrepetitive nodes are related to one another and work together to perf</p><p>　　Create a meaningful icon and cohesive description for every subVI!Always create a meaningful icon and cohesive descri

45、ption for every subVI. I cannot emphasize this enough. At Bloomy Controls, this is one of our most sacred precepts. The icon and description identify the subVI from the diagram of the calling VI through the Context Help

46、window. The description enforces the cohesion test. If you cannot summarize its purpose in two or three sentences, it probably contains too much code for one subVI</p><p>　　Tunnel wires into structures throu

47、gh their left border, and out of structures through their right border. Avoid tunneling wires through the top and bottom borders. Also avoid passing wires through structures if they are not utilized within the structure,

48、 unless their purpose is clearly labeled. It is particularly annoying to flip through many frames of a multiframe structure, such as a Case or an Event structure, searching for places where the data in the wire is modifi

49、ed.</p><p>　　Place any unwired terminals of front panel objects in a consistent location on the diagram so that developers can find them easily. Note that any terminals not contained by a repeating structure

50、 are read only once.</p><p>　　Most local and global variables and Sequence structures used in practice are not necessary. Most often, they are overused by developers who have not learned efficient dataflow p

51、rinciples. The best way to master data flow is to force oneself to avoid variables and Sequence structures unless absolutely required. Indeed, mastering data flow is synonymous with minimizing variables and Sequence stru

52、ctures.</p><p>　　To avoid wire clutter and maintain organization, space most shift registers tightly, and group them near the top of the loop. This creates a data highway that is limited to an area near the

53、top of the loop and minimizes wire crossovers. Leave just enough space between the shift registers to apply free labels on each wire near the left terminals. Exceptions to shift register grouping include error clusters a

54、nd case selectors. Error clusters normally enter and exit near the bottom of loops. Also, </p><p>　　For example, the task ID and error control terminals are improperly labeled task ID out and error out. Addi

55、tionally, one of the indicators has the generic label Numeric. What is curious is that the subVI has a custom icon and description, and the control terminals are within reasonable proximity to the structure. Perhaps it w

56、as partially repaired. The wiring and terminal labels have been cleaned up in Figure 4-14B. Also, Figure 4-14C contains equivalent code using the waveform data type and the </p><p>　　Close inspection reveals

57、 that the right-to-left wire is a file path that is formed by some low-level functions within an inner Case structure. Whenever a collection of low-level functions that work together to perform a cohesive routine appears

58、 on the diagram of a high-level VI, it is a good opportunity for a subVI,</p><p>　　This chapter presents style rules that ensure neat and organized diagrams that are practical to implement in real applicatio

59、ns with tight deadlines. Combined with the rules in other chapters, they ensure readable and maintainable LabVIEW source code. Moreover, mastery of these style rules may lead to awe-inspiring LabVIEW diagrams.</p>