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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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