《外文文献翻译LabVIEW程序框图设计》由会员分享，可在线阅读，更多相关《外文文献翻译LabVIEW程序框图设计（6页珍藏版）》请在金锄头文库上搜索。
1、LabVIEW程序框图设计摘要：一个真正好的程序就像一件艺术品一样，而差的程序看起来就像意大利面那样乱。这篇文章提出的风格能确保我们实际应用中在规定时间内开发出整洁，结构清晰的程序。结合其他规则，我们能开发出可读性好的，易于维护的LabView源代码。LabVIEW的程序框图长于源代码表述。一个真正好的程序是发人深省的，甚至是令人敬畏的，就是一件艺术品一样。而一个差的程序，看起来就像一碗意大利面条那样凌乱。事实上，这两种极端的情况就像风格的重要性中Meticulous VI 和 Spaghetti VI所表现的那样。而大部分程序处于艺术品和意大利面条之间。一些程序开发者有连线整齐的习惯，但程序
2、框图往往却大而宽泛。其他的一些程序开发者却过度使用模块化编程，就像自己在搭建筑一样。而仍有一些编程人员喜欢使用变量方式而非数据流方式。很多很多开发人员在文档上节省时间。此外，很多程序是在好的风格和节约时间两者之间取得平衡下为特征下完成工作的。总体结论就是在吸引人的程序外观，个人喜好和程序功能上取得折中。大多数开发人员都错误认为吸引人的程序编写上受到许多束缚使开发进度变慢，而现实中程序开发都有时间限制。似乎快速开发程序的和程序具有美感是相矛盾的。事实上，多花些时间来优化复杂程序的外观是可能的如果你知道什么才是好的风格所要遵循的规则和如何执行这些规则，你将会在程序开发中更加轻松。屏幕分辨率决定程序
3、开发人员在开发程序时的可见区域和程序移植到用户计算机后的界面显示。因此，将程序分辨率统一是非常有好处的，那样应用程序在使用相同分辨率的PC上打开时窗口界面将保存一致。程序分辨率设置得越高，界面上的控件将根据屏幕大小相应的缩小，屏幕上也能容纳更多的程序代码。合适的屏幕分辨率是不仅要能使程序的可见区域最大化，而且不能让你的眼睛不舒服。LabView开发环境设定的最小程序分辨率为1024*768。与PC显示技术发展相适应的1280*1024的屏幕分辨率能提供更多的可视区域。不要采用高于1280*1024的分辨率，因为当前还不广泛支持如此高的分辨率，更大的工作区域也意味者程序框图更大，模块化程度降低。
4、同时，取决于显示器的大小，如果过高的分辨率容易使你的眼睛疲劳。今天许多计算机都支持多显示器。在LabView开发环境采用两个显示器是非常有好处的。使用一个显示器来显示前面板，另外一个显示器来显示程序框图。这样就能同时看到这两个窗口，而不需要在前面板和程序框图之间进行切换。不要给程序框图着色。界面的背景色和每个结构的子界面都默认为白色。数据流向必须非常容易识别。我们希望对象尽量布局紧凑，但同时不希望对象靠得太近引起对象和连线重叠。总之，尽量缩小程序框图大小使之能在一个屏幕显示出来。在某些情况下，比如说某些复杂的程序包含很多个并行循环，要满足这个限定非常困难。在这种情况下，调整程序框图，或者将一些
5、循环变成子VI来减小所占背面板空间，使背面板仅在一个方向上滑动。开发程序时，VI之间应采用从上至下和自下而上相结合的方法来构建多层次结构关系。VI的层次结构可以通过选择ViewVI Hierarchy 来查看。从窗口的工具条中取消选择包括VI Lib ,包括全局变量和包括自定义类型，并且只显示你自己提供的用户VI。通常的几何形状包括金字塔形，钻石形和椭圆形。除了非常简单的应用程序外，VI层次结构中在顶层VI之下的应包含多行子VI。在第一章中，模块化率被定义为是用户VI数与总的节点数之比，再乘100。这些数据的大小可以通过选择ToolsProfileVI Metrics快速查看到。典型应用程序的
6、模块化率推荐为3.0以上。取决于设计样式，许多顶层程序都应包含结构，连线，VI组件和子VI。VI组件是处于非常高层的子VI，或者是将一个应用程序的主要部分或子系统封装为插件后动态调用的VI。一个应用程序的图形用户见面和数据采集引擎是以单独的vi实现的，它们就是组件VI的一个例子。顶层和高层vi应该尽可能减少的低层数据处理函数，例如数学函数，数组处理，格式化字符串以及类似的函数。一些应用程序需要大量的数值属性节点来控制GUI行为。许多属性节点的读写操作是由GUI事件触发。因此，事件结构是理想的处理属性节点的结构。因为，事件结构为每个事件分支包含一个单独的子程序，通常一个事件分支的程序不会跑到其他
7、的事件分支。然而，多事件分支需要许多个相同的属性节点，它们的值因每次读写操作而不同。将这些普通的属性节点模块化为子VI，通过控件引用和属性值传递到子VI中。每个子VI程序代表在内存中同一属性节点的备份。这减小了内存使用和程序复杂性。同样的，将你程序中的高层组件模块化为较低级的子VI。使用自顶向下的设计和开发方法，将任何低层程序模块化为强内聚的子VI。在任何的地方如果你用到了已有代码的副本来共同构成一个程序，将这些代码替换成子VI。一个子VI是否是内聚的要看你是否能将它要完成的工作清楚的描述为两三句话，就像子VI描述信息那样。子VI非常有用，因为相对于一个大型程序来说，它易于开发，测试，调试，维
8、护和代码重用。如图4-2C所示，子VI也为程序开发中节省了可观的背面板空间。总之，如果同一函数，属性节点，程序被多次用到，将这些重复代码换成子VI将使程序开发变简单。同样，如果几个没用被重复使用的节点彼此相关，并且一起完成某项工作，不管它们是否被多次用到，也将它们变为一个内聚的子VI。但是，也不要为了节省空间而随便选择将程序的某部分变成子VI。以这种方式创建的子VI不是内聚的，也不够直观并且不可重用。同样也不要为只有少量接线端的程序代码创建子VI。这种情况，子VI图标不需要在程序框图掩盖它下层的代码。子VI只包含一个数组索引函数。然而，子VI的图标，名字和描述信息掩盖数组索引函数。LabVie
9、w函数和将子VI打包成的VI.lib通常是可识别的，因而不需再单独将它们封装成子VI。为每个子VI创建一个有含义的图标和相结合的描述。住为每个子VI创建一个有含义的图标和相结合的描述。再怎么强调它的重要性都是不够的。这是我们最神圣的信条。图标和描述信息能帮助我们在调用这些子VI的程序时通过帮助窗口的文字识别这些子VI。这些描述迫使我们进行内聚性测试。如果你不能通过2到3句话总结子VI的功能，子VI可能包含了太多的子代码。隧道连线通过结构左侧边界进入结构，并从结构的右侧边界穿过结构。不要让隧道在结构的顶部或底部穿过。同样如果结构内部未使用到也不要让连线穿过结构，除非其目的是为了标示清楚。特别令人
10、困苦的是浏览一个多帧结构的许多帧时，要去寻找那些在连线上被修改的数据，比如说条件结构或者是事件结构。然而，有时条件结构通过一些额外的连线线是非常有用的将没有连线的前面板控件在程序框图上放在一起，那样程序开发人员就能非常容易的将找到它们。标记那些在程序只用到一次，不在循环结构中的接线端 。实践中大多数局部变量，全局变量和顺序结构都不是必要的。没有学习过有效数据流法则的开发者经常过多地使用局部变量和全局变量。强迫自己避免使用变量和顺序结构是最有效的掌握数据流的方法，除非完全必要要用到它们。的确，掌握数据流和尽可能避免使用变量和顺序结构具有相同的含义。为了避免连线混乱且保持有组织秩序，紧凑地放置移位
11、寄存器且将它们聚集到靠近循环的顶部。这样如同在靠近循环顶端位置有限的区域内修建一条数据公路且使线路交叉最少。除了聚合了包括错误簇和条件选择器的移位寄存器外。只要在移位寄存器之间留下刚好够放置自由标签的位置就行了，这些标签将被放置在靠近移位寄存器左边终端的线上。错误簇经常在循环的底部进出，而条件选择器经常处于中间位置。因此，错误簇和条件选择器经常与靠近循环顶部的数据公路是分离的。最糟的编程习惯是从一个选定区域创建一个VI而且不清理创建子VI后的狼藉场面。终端位置，标签，线，连接器分配，图标以及描述文档都需要进行矫正。有时这样还会导致子VI的程序结构图就像在里面投了一颗炸弹一样。用这种工具创建的子
12、VI从来就不是一个好的风格而且程序必须改写。关闭检查展示出从右向左的线是一个文件路径，它是由Case结构里面的若干底层函数所形成的。不管怎样，在顶层VI上由若干底层函数共同组成以完成某种功能的程序最好用一个子VI的形式出现。这篇文章提出的风格能确保我们实际应用中在规定时间内开发出整洁，结构清晰的程序。结合其他规则，我们能开发出可读性好的，易于维护的LabView源代码。而且，遵守这些好的编程风格所要求的准则将可能会使我们开发出令人赞叹的LabView程序。3The LabVIEW Program Diagram DesignABSTRACT：A really good diagram is l
13、ike a work of art. Some developers have neat wiring practices but large, flat diagrams. This 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
14、 and maintainable LabVIEW source codeThe 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 practices but large, flat diagrams. Others have overly modular diagrams that disguise the ar
15、chitecture. . Indeed, these two extremes are depicted by Meticulous VI and Spaghetti VI in Chapter 1, The Significance of Style. Somewhere in the middle between artwork and spaghetti is where most applications reside. Still others prefer variables over data flow. Many, many developers skimp on docum
16、entation to save time. Moreover, most diagrams are characterized by tradeoffs between good style and shortcuts deemed necessary to get the job done. The overall outcome is a compromise among attractive appearance, personal preferences, and functional performance.Many developers wrongfully assume that attractive diagrams require a level of toil that is impractical for real-world applications that have tight deadlines. It seems faster and more
