外文文献翻译-LabVIEW程序框图设计

《外文文献翻译-LabVIEW程序框图设计》由会员分享，可在线阅读，更多相关《外文文献翻译-LabVIEW程序框图设计（7页珍藏版）》请在毕设资料网上搜索。

1、 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 数与总的节点数之比，

6、再乘 100。这些数据的大小可以通过选择ToolsProfileVI Metrics 快速查看到。典型应用程序的模块化率推荐为 3.0 以上。 2 取决于设计样式，许多 顶层程序都应包含结构，连线， VI 组件和子 VI。 VI 组件是处于非常高层的子 VI，或者是将一个应用程序的主要部分或子系统封装为插件后动态调用的 VI。一个应用程序的图形用户见面和数据采集引擎是以单独的 vi 实现的，它们就是组件 VI 的一个例子。顶层和高层 vi 应该尽可能减少的低层数据处理函数，例如数学函数，数组处理，格式化字符串以及类似的函数。 一些应用程序需要大量的数值属性节点来控制 GUI 行为。许多属性节点

7、的读写操作是由 GUI事件触发。因此，事件结构是理想的处理属性节点的结构。因为，事件结构为每个事件分支包含一个单独的子程序，通常一个事件分支的程序不会跑到其他的事件分支。然而，多事件分支需要许多个相同的属性节点，它们的值因每次读写操作而不同。将这些普通的属性节点模块化为子 VI，通过控件引用和属性值传递到子 VI 中。每个子 VI 程序代表在内存中同一属性节点的备份。这减小了内存使用和程序复杂性 。 同样的，将你程序中的高层组件模块化为较低级的子 VI。使用自顶向下的设计和开发方法，将任何低层程序模块化为强内聚的子 VI。在任何的地方如果你用到了已有代码的副本来共同构成一个程序，将这些代码替换

8、成子 VI。一个子 VI 是否是内聚的要看你是否 能将它要完成的工作清楚的描述为两三句话，就像子 VI 描述信息那样。 子 VI 非常有用，因为相对于一个大型程序来说，它易于开发，测试，调试，维护和代码重用。如图 4-2C 所示，子 VI 也为程序开发中节省了可观的背面板空间。总之，如果同一函数，属性节点，程序被多次用到，将这些重复代码换成子 VI 将使程序开发变简单。同样，如果几个没用被重复使用的节点彼此相关，并且一起完成某项工作，不管它们是否被多次用到，也将它们变为一个内聚的子 VI。但是，也不要为了节省空间而随便选择将程序的某部分变成子 VI。以这种方式创建的子 VI 不是内聚 的，也不

9、够直观并且不可重用。同样也不要为只有少量接线端的程序代码创建子 VI。这种情况，子 VI 图标不需要在程序框图掩盖它下层的代码 。 子 VI 只包含一个数组索引函数。然而，子 VI 的图标，名字和描述信息掩盖数组索引函数。 LabView函数和将子 VI 打包成的 VI.lib通常是可识别的，因而不需再单独将它们封装成子 VI。 为每个子 VI 创建一个有含义的图标和相结合的描述。住为每个子 VI 创建一个有含义的图标和相结合的描述。再怎么强调它的重要性都是不够的。这是我们最神圣的信条。图标和描述信息能帮助我们在调用这些子 VI 的程序时 通过帮助窗口的文字识别这些子 VI。这些描述迫使我们进

10、行内聚性测试。如果你不能通过 2到 3句话总结子 VI 的功能，子 VI 可能包含了太多的子代码。 隧道 连线 通过 结构 左侧边界 进入 结构，并 从 结构 的右侧边界穿过结构。不要让隧道在结构的顶部或底部穿过。同样如果结构内部未使用到也不要让连线穿过结构， 除非其目的是 为了 标示清楚 。特别令人困苦的是浏览一个多帧结构的许多帧时，要去寻找那些在连线上被修改的数据，比如说条件结构或者是事件结构。然而，有时条件结构通过一些额外的连线线是非常有用的将没有连线的前面板控件在程序框图上放在一起，那 样程序开发人员就能非常容易的将找到它们。标记那些在程序只用到一次，不在循环结构中的接线端 。 实践中

11、大多数局部变量，全局变量和顺序结构都不是必要的。没有学习过有效数据流法则的开发者经常过多地使用局部变量和全局变量。强迫自己避免使用变量和顺序结构是最有效的掌握数据流的方法，除非完全必要要用到它们。的确，掌握数据流和尽可能避免使用变量和顺序结构具有相同的含义。 为了避免连线混乱且保持有组织秩序，紧凑地放置移位寄存器且将它们聚集到靠近循环的顶部。这样如同在靠近循环顶端位置有限的区域内修建一条数据公路且使线路交叉最 少。除了聚合了包括错误簇和条件选择器的移位寄存器外。只要在移位寄存器之间留下刚好够放置自由标签的位置就行了， 3 这些标签将被放置在靠近移位寄存器左边终端的线上。错误簇经常在循环的底部进

12、出，而条件选择器经常处于中间位置。因此，错误簇和条件选择器经常与靠近循环顶部的数据公路是分离的。 最糟的编程习惯是从一个选定区域创建一个 VI 而且不清理创建子 VI 后的狼藉场面。终端位置，标签，线，连接器分配，图标以及描述文档都需要进行矫正。有时这样还会导致子 VI 的程序结构图就像在里面投了一颗炸弹一样。用这种工具创建的子 VI 从来就不是 一个好的风格而且程序必须改写。 关闭检查展示出从右向左的线是一个文件路径，它是由 Case结构里面的若干底层函数所形成的。不管怎样，在顶层 VI 上由若干底层函数共同组成以完成某种功能的程序最好用一个子 VI 的形式出现 。 这篇文章提出的风格能确保我们实际应用中在规定时间内开发出整洁，结构清晰的程序。结合其他规则，我们能开发出可读性好的，易于维护的 LabView源代码。而且，遵守这些好的编程风格所要求的准则将可能会使我们开发出令人赞叹的 LabView程序。