51 LabVIEW图形化编程语言的设计模式.doc

第5章 LabVIEW图形化编程语言的设计模式（LabVIEW graphical programming language, design patterns）版本 4 创建于: 2010-12-26 上午6:58 作者 jwdz - 最后修改: 2011-1-14 下午10:06 作者 jwdz 在基本上弄清楚了图形化代码的基本功能以及它的数据流运行机制后，许多人都可能会有一种跃跃欲试的编程冲动，因为他们相信通过对上述内容的了解和认识后，自己已经具备了 使用图形化编程语言进行程序设计的能力。 是的，我们也深信这绝对应该是可以的！但是，需要要告诫的是：如果要想使用图形化代码设计出令用户满意的程序，或者说，把它作为职业生涯的一种技术手段，仅仅了解到这些 显然还是不够的。 那么，还需要知道哪些方面的一些内容呢？ 崭且不考虑其它方面的因素，比如：硬件及硬件驱动体系等等。仅就软件编程方面至少还需要了解图形化代码的一些基本的设计模式。这些正是本章所要介绍的主要内容。5.1 设计模式概述 什么是设计模式？图形化语言的设计模式会有那些？它对图形化程序的设计会带来那些帮助？5.1.1 设计模式 许多讲解LabVIEW图形化编程语言的教课书中都谈到了设计模式重要性，那什么是设计模式呢？ 首先，我们要说明的是：设计模式是包含在许多工程设计领域中的基本概念。我们这里所说的设计模式是指软件范畴中的基本概念。 下面我们给出软件设计中设计模式的基本定义： 设计模式软件设计中，在某情境下，针对某问题的某种解决方案。 情境就是应用某个模式的情况。这应该是会不断出现的情况。 问题就是你想在某情境下达到的目标，但也可以是某情境下的约束。 解决方案就是你所追求的，一个通用的设计，用来解决约束，达到目标的方法。 我们在一同来看看维基百科中的解释或说明： “设计模式这个术语是由Erich Gamma等人在1990年代从建筑设计领域引入到计算机学科的。它是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。 设计模式并不直接用来完成程序代码的编写，而是描述在各种不同情况下，要怎么解决问题的一种方案。” 根据设计模式的定义，应该对设计模式应该有了一个最基本的了解。 严格地讲，设计模式是针对某些经常出现的问题而给出的一种行之有效的设计解决方案。设计模式是软件的战术思想，它侧重于设计思想的重用。 通俗地讲，就是已经有人遇到了你正在经历（或还不曾经历）的问题，并且他们已经成功的解决了这些问题，我们可以参考或借见这些现成的方案。 尽管设计模式是软件的战术思想，但对于不同的编程语言而言，它们的设计模式是不相同的。比如，仅针对Java语言OOP的设计模式就多达23种。由此可见，编程语言中的 设计模式是多么的重要。 我们在此强调：设计模式是侧重于设计思想的重用，本意是说明设计经验重用的这一基本概念。这些经验来自众多的程序员的实践和验证，并证明它们是行之有效的。 我们知道：在LabVIEW图形化语言的程序设计中，子VI在概念上也表示出一种重用的特征。但是，这里特别提醒大家注意：子VI所体现的重用仅仅是代码的重用，而并非 是设计思想的重用，所以子VI不是设计模式，而是代码重用的设计方法。 关于设计模式本身的一些特点，简单总结如下： 设计模式是一种设计思想，它应该固化在程序员的大脑之中。 设计模式被认为是经过验证的设计经验。 设计模式不是被发明的，而是被发现的。 设计模式不是程序代码，而是针对设计问题的通用解决方案。 应用设计模式，可以确保软件具有良好的质量体系。 现在，经过对设计模式的简单了解后，大家更关心、更希望看到的是LabVIEW图形化语言的设计模式都有那些。 5.1.2 LabVIEW图形化编程语言的设计模式 LabVIEW图形化编程语言经过二十多年的发展总结出了许多行之有效的设计模式，并将这些设计模式以模版的形式提供给程序的设计者使用。下面我们就来初略的认识一下L abVIEW的设计模式。 启动、运行LabVIEW开发环境，参见下图。 图 5.1.2-1 LabVIEW开发环境启动界面 点击：VI from Template. More 都可以看到图形化的设计模式，参见下图。 图 5.1.2-2 LabVIEW的设计模式（Design Patterns） 上图中，我们可以看到在LabVIEW开发环境中为我们提供了以下的6种设计模式。 Master/Slave design pattern Producer/Consumer design pattern（Data） Producer/Consumer design pattern（Events） Queued Message Handler Standard State Machine User Interface Event Handler 这些设计模式都是在图形化应用程序设计中比较常见的设计方法。关于这些设计模式的特点的分析和描述我们将在下一节进行。 细心的读者可能会发现，在图 5.1.2-2 中，设计模式是包含在框架（Frameworks）的目录下。换句话说，设计模式也是框架中的一种。 这里我们也顺便来讨论一下，什么是框架？5.1.3 LabVIEW图形化编程语言的程序框架 什么是框架？ “框架为软件设计构建了一个与特定编程语言相关的、可重用的设计模版，重点在于强调设计上的重用。框架足可以应付复杂的应用软件开发，并确保快速有效。通过框架可以从宏 观上控制软件整体的结构和流程。框架内也可能包含多个设计模式。” 在图 5.1.2-2 中我们可以看到包括设计模式在内的6种框架，我们只讨论其中比较简单且很常用地的一个框架。 在图 5.1.2-2 中，用鼠标点击“SubVI with Error Handling”，开发环境会打开这个模版。参见下图。 图 5.1.3-1 SubVI with Error Handling前面版 图 5.1.3-2 SubVI with Error Handling程序框图（No Error） 图 5.1.3-3 SubVI with Error Handling程序框图（Error） 相信这是大家比较常用的一个VI，同时它也是最简单的一个程序框架。 我们知道，图形化语言的运行机制是基于数据流的。而利用公共线程错误簇，提供数据流的直接关系是十分简单并且直观、有效。另外，图形化代码本身具有层次结构，构成层 次结构最主要的手法就是使用子VI。框架 SubVI with Error Handling.vi 恰好满足了这两个层面的要求。 SubVI with Error Handling.vi 的结构很简单，case结构与错误簇结合，并且错误簇直接接到case结构的分支选择端。它的工作原理是通过case结构的“分支选择器”来判断输入错误簇中的“Sta tus（布尔量）来决定case结构所执行的状态。尽管错误簇中存在有三种数据类型，但case结构仅对布尔量做出反应，其它类型的信息正常传递。 它的数据流运行机制是这样的： 程序开始运行时，首先判断连接到“分支选择器”错误簇中的“Status”的状态： 如果“Status”0，则执行“无错误case“中的正常程序代码（也就是子vi的程序代码）； 如果“Status”1，则通过“错误case“将错误信息直接传递到“错误出”的端口。 错误快速传递是这个vi的最基本特点，它大大的降低了错误信息传递的延迟时间。这里面有两点还需要注意：一是，错误信息是来自前面的子vi；二是，传递的只是错误信息并 没有进行任何的报告和处理。 框架提供了设计上的重用，对于上面所讨论的这个框架，希望在子vi设计中能得到广泛应用。5.1.4 LabVIEW图形化编程语言设计模式的深入探讨 这里我们想一起来探讨这样一个问题：数据流（编程）是LabVIEW图形化编程语言的一种设计模式吗？ 可以这样讲，正是这个问题的提出，才导致了本书的出现。 在此前撰写LabVIEW图形化系统设计和实践时，从查看的资料中曾看到有的资料中将数据流被列为LabVIEW的一种设计模式。这种说法引发了笔者的认真思考，思 考的最终结果就是导致了LabVIEW编程思想一书的出现。 在LabVIEW编程思想一书中，笔者将数据流编程看作LabVIEW图形化语言的核心编程思想而不是设计模式完全是基于这样的理由： 其一，使用LabVIEW图形化编程语言进行程序设计必须依据数据流的编程原则。这是应用LabVIEW图形化编程语言的充分且必要的条件，别无其它方式