LabVIEW程序设计模式研究和探讨(三)—消息队列型状态机模式
时间：10-02
整理：3721RD
点击：
针对基本状态机模式的第(1~3)个问题，需要对模式进行改进。本节将一一分析这些问题对应的解决方案，并最终形成一种新的状态机模式——消息队列型状态机模式。
(1) 状态的分类不清晰。
这是一个涉及各个状态分类管理的问题，是一个组织问题。我们可以做一个类比，在一个书桌上有许多种类的书籍(通信、计算机、机械、法律等)，这些书都摆放在书桌上很整齐。但是我们在寻找一本书时并不会觉得很迅速和随意，因为书籍的摆放是无序的，每次寻找书籍我们不得不从第一本开始浏览直至找到我们想要的书籍。或许可以做一些改变，我们设置一些书立，将不同种类的书使用书立分开。并且在书立上标明这些书籍表示的种类。这样我们在寻找某一种书籍时就不需要从第一本书开始寻找了，只需要找到对应的书立，在这些书立中寻找即可。
让我们回到程序，并给程序的状态设置一些“书立”。如图 4所示，系统共有9个有效状态(UI Initial、Data Initial、Instr Initial、Temperature、Power、FFT、JTFA、Data Clean、Exit)。如果把这些状态混在一起，我们需要找到某一个状态时会比较困惑和麻烦。如同上面所述，将这些状态分为4类并设置了4个“书立”(Initial、Acquire、Analyse、System)分隔这些状态。在实际的状态控制中，需要确保程序只会进入实际的状态中运行而不会进入到“书立”分支中，因此对每个“书立”加入了“-------”以示区别。
图 4 状态分类
尽管我们只是进行了少量的修改，但是这的确有利于程序状态的组织和阅读，尤其是当程序具有很多个状态的时候。
(2) 缺乏数据共享和错误处理机制。
在层叠式的顺序结构中，数据在帧之间的传递是靠“顺序局域变量”实现的。那么如果在case结构中如何传递不同分支的数据呢?这个问题似乎很容易解决，使用局域变量，全局变量或共享变量都能够解决，但是这些并不是最优的解决方案。因为上述的方式会明显系统运行的内存空间和时间。由于状态机的基本组成元素除了case结构之外还有循环，因此可以使用移位寄存器来传递数据。如图 5所示。
图 5 状态机中的数据传递
图 5使用移位寄存器进行数据共享和传递，将所有的数据封装在一个簇中并对每个数据命名，这样在使用数据时就可以使用“Unbundle by name”或“bundle by name”。需要说明的是，即使使用一个数据需要共享，仍然希望采用簇的封装形式，这样当后续需要增加扩展数据的时候并不会影响现有的数据引用。
(3) 每一个状态分支只能够决定后面的一个状态，而无法决定一个状态序列(多个状态)。
在基本状态机中之所以存在这个问题是因为状态的传递使用的是Scalar(标量)形式，如果需要传递一个状态序列，很明显可以使用队列或数组进行状态的传递。在LabVIEW程序设计模式中将这种具备处理状态序列的状态机称为“消息队列型状态机”，它是在基本状态机基础上的改进。
顾名思义，这种模式就像银行办理业务时排队一样采用队列的方式。当储户进入银行时，首先到叫号机处领取号码进行排队(进入队列)并等待。然后，当前面的储户办理完业务后就可以到相应的窗口办理业务(退出队列)。事实上，这种方式在现代生活中随处可见。
在LabVIEW中至少有两种实现消息队列的方法。如图 6所示。前者使用数组函数实现队列元素的入列和出列;后者使用队列函数实现队列元素的入列和出列。二者都能够实现队列的有序操作和状态的序列变化。
图 6 消息队列型状态机模式
本节解决了基本状态机模式中的(1)~(3)个问题，为了更好地比较和使用这些特点，特使用一个实例说明消息队列型状态机的使用过程。
【应用2】
本例要模拟一个自动贩卖机的工作过程。它的一次正常交易过程为：投币→选择需要购买的商品→找币，当币值不足或商品已经销售完毕时则无法购买。
程序的前面板如图 7所示。在贩卖机的左上侧有4个按钮。
(1) 1USD：单击时表示投入1美元的货币，2USD和5USD类同;
(2) Change Back：表示找零，也就是将目前剩余的货币退还给用户。
程序的右侧是5个按钮，表示5种不同类别的可乐(这里均使用了可口可乐的图标)，每种可乐的价格均是1美元。可乐的下面数字表示贩卖机中剩余的该商品的数量，初始为每种20瓶。Current money显示贩卖机中剩余的货币数，你可以继续购买可乐或者选择退回。单击Stop按钮将退出应用程序。
本例将使用本节介绍的消息队列状态机模式解决这个应用(也可以使用其它的设计模式)。系统的功能并不复杂，关键是要判断贩卖机中的剩余钱数和剩余的货物数以决定交易是否成功。
图 7 自动贩卖机前面板
程序背面板如图 8所示。系统分为5个状态，并分为2大类。
(1) 第一类：Initial
a) UI Initial：前面板界面的初始化。
b) Data Initial：数据的初始化。
(2) 第二类：System
a) Idle(Default)：空闲状态。
b) CheckMoney：贩卖机中的剩余钱数和剩余的货物数以决定交易是否成功。
c) Exit：退出程序。
程序开始运行时进入UI Initial和Data Initial状态，完成初始化操作。从图中可以看出系统采用数组函数处理消息队列。
图 8 自动贩卖机背面板
在UI Initial中，系统给标题栏和说明栏赋值，并将前面板的商品设置为不可购买状态，因为在初始化时还没有完成投币动作。如图 9所示。
图 10 Data Initial分支
CheckMoney分支主要是为了防止不合法的交易(如投入的币值不足或商品数量不足)，如图 11所示。
图 11 CheckMoney分支
当程序运行到Exit分支时，将停止循环并退出程序，如图 12所示。
图 12 Exit分支
Idle分支用来监控前面板各个按钮控件的变化并执行相应的状态。该分支比较复杂，当检测到第0个按钮被按下时(即1USD按钮)，贩卖机中的货币值应该加一，同时需要判断是否达到了交易条件(即进入CheckMoney状态)。其它的状态可以执行相应的代码即可，这里不再重复解释。
图 13 Idle分支
从本例可以看出，相比基本状态机而言，尽管程序的复杂度增加了，但是在构建大型的应用程序时也更加地健壮，代码也易于维护和查看。
(1) 状态的分类不清晰。
这是一个涉及各个状态分类管理的问题，是一个组织问题。我们可以做一个类比，在一个书桌上有许多种类的书籍(通信、计算机、机械、法律等)，这些书都摆放在书桌上很整齐。但是我们在寻找一本书时并不会觉得很迅速和随意，因为书籍的摆放是无序的，每次寻找书籍我们不得不从第一本开始浏览直至找到我们想要的书籍。或许可以做一些改变，我们设置一些书立，将不同种类的书使用书立分开。并且在书立上标明这些书籍表示的种类。这样我们在寻找某一种书籍时就不需要从第一本书开始寻找了，只需要找到对应的书立，在这些书立中寻找即可。
让我们回到程序，并给程序的状态设置一些“书立”。如图 4所示，系统共有9个有效状态(UI Initial、Data Initial、Instr Initial、Temperature、Power、FFT、JTFA、Data Clean、Exit)。如果把这些状态混在一起，我们需要找到某一个状态时会比较困惑和麻烦。如同上面所述，将这些状态分为4类并设置了4个“书立”(Initial、Acquire、Analyse、System)分隔这些状态。在实际的状态控制中，需要确保程序只会进入实际的状态中运行而不会进入到“书立”分支中，因此对每个“书立”加入了“-------”以示区别。
图 4 状态分类
尽管我们只是进行了少量的修改，但是这的确有利于程序状态的组织和阅读，尤其是当程序具有很多个状态的时候。
(2) 缺乏数据共享和错误处理机制。
在层叠式的顺序结构中，数据在帧之间的传递是靠“顺序局域变量”实现的。那么如果在case结构中如何传递不同分支的数据呢?这个问题似乎很容易解决，使用局域变量，全局变量或共享变量都能够解决，但是这些并不是最优的解决方案。因为上述的方式会明显系统运行的内存空间和时间。由于状态机的基本组成元素除了case结构之外还有循环，因此可以使用移位寄存器来传递数据。如图 5所示。
图 5 状态机中的数据传递
图 5使用移位寄存器进行数据共享和传递，将所有的数据封装在一个簇中并对每个数据命名，这样在使用数据时就可以使用“Unbundle by name”或“bundle by name”。需要说明的是，即使使用一个数据需要共享，仍然希望采用簇的封装形式，这样当后续需要增加扩展数据的时候并不会影响现有的数据引用。
(3) 每一个状态分支只能够决定后面的一个状态，而无法决定一个状态序列(多个状态)。
在基本状态机中之所以存在这个问题是因为状态的传递使用的是Scalar(标量)形式，如果需要传递一个状态序列，很明显可以使用队列或数组进行状态的传递。在LabVIEW程序设计模式中将这种具备处理状态序列的状态机称为“消息队列型状态机”，它是在基本状态机基础上的改进。
顾名思义，这种模式就像银行办理业务时排队一样采用队列的方式。当储户进入银行时，首先到叫号机处领取号码进行排队(进入队列)并等待。然后，当前面的储户办理完业务后就可以到相应的窗口办理业务(退出队列)。事实上，这种方式在现代生活中随处可见。
在LabVIEW中至少有两种实现消息队列的方法。如图 6所示。前者使用数组函数实现队列元素的入列和出列;后者使用队列函数实现队列元素的入列和出列。二者都能够实现队列的有序操作和状态的序列变化。
图 6 消息队列型状态机模式
本节解决了基本状态机模式中的(1)~(3)个问题，为了更好地比较和使用这些特点，特使用一个实例说明消息队列型状态机的使用过程。
【应用2】
本例要模拟一个自动贩卖机的工作过程。它的一次正常交易过程为：投币→选择需要购买的商品→找币，当币值不足或商品已经销售完毕时则无法购买。
程序的前面板如图 7所示。在贩卖机的左上侧有4个按钮。
(1) 1USD：单击时表示投入1美元的货币，2USD和5USD类同;
(2) Change Back：表示找零，也就是将目前剩余的货币退还给用户。
程序的右侧是5个按钮，表示5种不同类别的可乐(这里均使用了可口可乐的图标)，每种可乐的价格均是1美元。可乐的下面数字表示贩卖机中剩余的该商品的数量，初始为每种20瓶。Current money显示贩卖机中剩余的货币数，你可以继续购买可乐或者选择退回。单击Stop按钮将退出应用程序。
本例将使用本节介绍的消息队列状态机模式解决这个应用(也可以使用其它的设计模式)。系统的功能并不复杂，关键是要判断贩卖机中的剩余钱数和剩余的货物数以决定交易是否成功。
图 7 自动贩卖机前面板
程序背面板如图 8所示。系统分为5个状态，并分为2大类。
(1) 第一类：Initial
a) UI Initial：前面板界面的初始化。
b) Data Initial：数据的初始化。
(2) 第二类：System
a) Idle(Default)：空闲状态。
b) CheckMoney：贩卖机中的剩余钱数和剩余的货物数以决定交易是否成功。
c) Exit：退出程序。
程序开始运行时进入UI Initial和Data Initial状态，完成初始化操作。从图中可以看出系统采用数组函数处理消息队列。
图 8 自动贩卖机背面板
在UI Initial中，系统给标题栏和说明栏赋值，并将前面板的商品设置为不可购买状态，因为在初始化时还没有完成投币动作。如图 9所示。
图 9 UI Initial分支
在Data Initial中包含两个共享的数据：Money和GState，前者表示贩卖机中剩余的币值，初始化值为0；而后者表示贩卖机中各个商品剩余的数量，初始化值为20。数据使用移位寄存器传递以便于在各个case分支中共享和使用，如图 10所示。
图 10 Data Initial分支
CheckMoney分支主要是为了防止不合法的交易(如投入的币值不足或商品数量不足)，如图 11所示。
图 11 CheckMoney分支
当程序运行到Exit分支时，将停止循环并退出程序，如图 12所示。
图 12 Exit分支
Idle分支用来监控前面板各个按钮控件的变化并执行相应的状态。该分支比较复杂，当检测到第0个按钮被按下时(即1USD按钮)，贩卖机中的货币值应该加一，同时需要判断是否达到了交易条件(即进入CheckMoney状态)。其它的状态可以执行相应的代码即可，这里不再重复解释。
图 13 Idle分支
从本例可以看出，相比基本状态机而言，尽管程序的复杂度增加了，但是在构建大型的应用程序时也更加地健壮，代码也易于维护和查看。
谢谢小编解答
thank you
THANKS
学习
谢谢小编分享资料
学习中，感谢分享
先看看再说。然后再学习！
能帮忙给共享消息队列型状态机模式模板吗?
有没有源代码 小编
好好学习 ， 天天向上
多谢小编，收藏了，下次再学习！
看来我还得好好消化一下
好东东啊，
非常好的讲解，谢谢
有没有队列消息处理器模块
学习学习
还不错~~
ok,学习了。
谢谢小编如此详细介绍，正在学习...
0000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000000000
消息列队是个很好的方法
有具体模板多好啊 呜呜
是来温习一下的...
求源码啊，有些看不清
学习学习！
学习