AF（操作者框架）系列（1）-LabVIEW中的模块化应用概述

一、引子

在前面对LabVIEW介绍的文章中，关于框架开发的内容涉及很少。为了讲解操作者框架（Actor Framework）的优缺点，也只是拿出来QDSM（Queue-Driven State Machine ）框架进行了比较。

所以，在写这个开篇之前，其实一直想一篇关于LabVIEW框架开发的文章，讲解一下当前的LabVIEW开发环境中，主要有哪些框架，各自的优缺点、使用情景，以及框架的演变历程。腹稿有了大致的架构，写完这篇文章，准备再找个时间写一下。

二、正文

本系列有13个视频，但是最后一个是基于NXG版本的开发，当前坑比较多，暂不考虑使用。

所以准备写12篇笔记文章。

首先，进入本系列视频文章的解读：

在这个系列中，目的是让大家了解如何使用Actor Framework，在LabVIEW中开发面向操作者的应用程序。操作者框架是LabVIEW中的一个高级概念，也是当前可以使用的官方支持的快速开发框架。

编程人员总希望以稳定可靠的方式，尽可能多地重用代码。而Actor Framework（以下文中简称AF）满足这个需求，它支持代码重用。使用AF还有很多其他好处，当然，也有一些缺点，我们将在这个系列中的后面的文章中介绍这些缺点。

本系列的技术文章讲解，需要技术人员可以熟练使用QMH模式，在LabVIEW中进行模块化软件开发的能力。

首先，我们将使用QMH模式，编写一个基本需求，来演示其如何工作的。然后，再使用AF替代，用以表明这可能是一种更好的软件开发方法。

根据常用的最佳软件设计原则，我们将代码分成具有高内聚性和低内聚性的模块。

为了举例说明这一点，在一个简单的数据显示应用程序中，我们编写一个数据采集模块、一个文件i/o模块、一个用户界面模块和一个控制模块，来组织不同循环之间的所有消息。程序框图如下：

 

 

 

然后将基本的功能模块用QMH框架写出来，如下图：

 

 

 

用户界面模块实际上由两个循环组成，一个是基于事件的循环，另一个是基于键值的循环。

所谓的高内聚性，就是每个模块都应该有一个明确的目的，只负责一件事，例如用户界面模块只负责接收和显示数据或响应用户输入，但它不负责判断文件是不是你的，也不具备做文件i/o的能力。低耦合，意味着一个模块不应该依赖于另一个模块。例如，即使I/O文件没有加载，用户界面也应该运行。

所以，内聚性指的是模块本身如何编写，而耦合指的是模块如何依赖于其他模块。高内聚性的主要好处是它的可读性，如果你在一个模块中有密切相关的函数，那么很清楚该模块做什么的，也使该模块变得可维护。

举个可维护性的例子，假如，在写入一个文件时有一个bug，您知道另一个必须出现在两个文件I/O模块中，因此您可以很快的测试那些特定的函数，来判断问题所在。

因为该模块只有一个明确的用途，该模块也变得高度可重用,。

如果您有其他需要使用文件i/o模块的应用程序，则有一个明确的目的：它们可以在您想要的任意多个应用程序中将其放到您的框图中，因为低耦合的好处是可维护性，因此对特定模块的更改仅限于该单个模块，而不会对其他模块产生连锁反应模块可测试性。因此，单元测试中涉及的模块可以保持在最低限度。如果所有功能都是一个模块的一部分，那么您可以使用同一个模块测试这些功能。

现在我们知道为什么有这些单独的循环，让我们来演示如何在循环之间进行通信。

 

 

 

首先，点击开始按钮，消息依次在“用户接口模块”、“信息处理循环”、“数据采集模块”进行传递，实现了各模块的功能运行。

综上，搭建了整个通信系统，即队列或用户事件，这些队列或用户事件的引用将存储在功能全局变量（FGVs）中，与其他模块共享。在实际运行过程中，并非所有模块都需要实际加载，它们可以在运行时异步动态启动。

虽然，这只是一个模块化软件开发的概况，但基本覆盖了已知的大多数情况，如果您注意到这些“用户界面模块”、“消息处理循环”、“数据采集模块”，它们都是完全相同的代码，但是不得不重复它三次，所以如果使用QMH框架，通过努力，可以将部分的逻辑封装成子程序，放在单独的项目库中，以简化程序，但仍然有些重复。

 

 

 

现在，我们可以使用一种更为结构化的技术，在开发代码时，最大化将代码重用和高效使用。而这正是AF所具备的特性。所以在下一篇文章解读中，要向您展示AF是如何派生的，以便展示它如何解决代码重用的问题，特别是在这样的模块化应用程序中。

---

原创码字不易，如有收获，希望关注、点赞和喜欢。