首页 理论教育消息队列状态机模式优化后的标题

消息队列状态机模式优化后的标题

【摘要】:根据5.2.2节中基本状态机的局限性1)~3),需要对模式进行改进。本节将分析这些问题对应的解决方案,并最终形成一种新的状态机模式——消息队列型状态机模式。在LabVIEW程序设计模式中将这种具备处理状态序列的状态机称为“消息队列型状态机”,它是在基本状态机基础上的改进,这种模式通常被用于需要特定处理顺序的场合。

根据5.2.2节中基本状态机的局限性1)~3),需要对模式进行改进。本节将分析这些问题对应的解决方案,并最终形成一种新的状态机模式——消息队列型状态机模式。

(1)状态的分类不清晰

这是一个涉及各个状态分类管理的问题,是一个组织问题。可以做一个类比,在一个书桌上有许多种类的书籍(通信、计算机、机械法律等),这些书都摆放在书桌上很整齐。但是在寻找一本书时并不会觉得很迅速和随意,因为书籍的摆放是无序的,每次寻找书籍不得不从第一本开始浏览直至找到想要的书籍。如果做一些改变,设置一些书立,将不同种类的书使用书立分开。并且在书立上标明这些书籍表示的种类。这样在寻找某一种书籍时就不需要从第一本书开始寻找了,只需要找到对应的书立,在这些书立中寻找即可。

回到程序,并给程序的状态设置一些“书立”。如图5-8所示,系统共有9个有效状态(UI Initial、Data Initial、Instrument Initial、Temperature、Power、FFT、JTFA、Data Clean、Exit)。如果把这些状态混在一起,我们需要找到某一个状态时会比较困惑和麻烦。如同上面所述,将这些状态分为4类并设置了4个“书立”(Initial、Acquire、Analyse、System)分隔这些状态。在实际的状态控制中,需要确保程序只会进入实际的状态中运行而不会进入到“书立”分支中,因此对每个“书立”加入了“-------”以示区别。

978-7-111-49442-3-Chapter05-10.jpg

图5-8 状态分类

状态分类有利于程序状态的组织和阅读,尤其是当程序具有很多个状态的时候。

(2)缺乏数据共享和错误处理机制

在层叠式的顺序结构中,数据在帧之间的传递是靠“顺序局域变量”实现的。那么如果在条件结构中如何传递不同分支的数据呢?这个问题似乎很容易解决,使用局域变量,全局变量或共享变量都能够解决,但是这些并不是最优的解决方案。因为上述的方式会占用系统运行的内存空间和时间。由于状态机的基本组成元素除了条件结构之外还有循环,因此可以使用移位寄存器来传递数据。如图5-9所示。

978-7-111-49442-3-Chapter05-11.jpg

图5-9 状态机中的数据传递

使用移位寄存器进行数据共享和传递,将所有的数据封装在一个簇中并对每个数据命名,这样在使用数据时就可以使用“按名称解除捆绑”或“按名称捆绑”。需要说明的是,即使只有一个数据需要共享,仍然希望采用簇的封装形式,这样当后续需要增加扩展数据的时候就不会影响现有的数据引用。

(3)每一个状态分支只能够决定后面的一个状态,而无法决定一个状态序列(多个状态)

在基本状态机中之所以存在这个问题是因为状态的传递使用的是Scalar(标量)形式,如果需要传递一个状态序列,很明显可以使用队列或数组进行状态的传递。在LabVIEW程序设计模式中将这种具备处理状态序列的状态机称为“消息队列型状态机”,它是在基本状态机基础上的改进,这种模式通常被用于需要特定处理顺序的场合。

顾名思义,这种模式就像银行办理业务时排队一样采用队列的方式。当储户进入银行时,首先到叫号机处领取号码进行排队(进入队列)并等待。然后,当前面的储户办理完业务后就可以到相应的窗口办理业务(退出队列)。事实上,这种方式在现代生活中随处可见。

程序员可以将消息队列看成一段存储空间,用来暂存各种消息。之所以称为队列,是由其消息处理机制决定的,按照FIFO(先进先出)的思想,需要使用队列的方式处理各种消息。在程序初始化时,首先创建消息队列缓冲器,程序可以根据发生的事件将相应的消息投入到消息队列中,消息处理机构会实时探测消息队列中的消息并按照消息处理机制进行处理;当消息被接收后程序会执行相应的代码,并将消息从消息队列中删除;当接收到“Exit”消息时,应用程序停止运行,并释放队列空间。

在LabVIEW中至少有两种实现消息队列的方法。如图5-10所示。前者使用数组函数实现队列元素的入列和出列;后者使用队列函数(位于函数选板“同步”→“队列操作”,详见5.4.2节)实现队列元素的入列和出列。二者都能够实现队列的有序操作和状态的序列变化。

978-7-111-49442-3-Chapter05-12.jpg

图5-10 消息队列型状态机模式

使用数组操作函数对消息进行操作,结构简单,只需要配合移位寄存器使用即可,不需要额外的函数,而且不需要使用特别的函数手动销毁队列空间,在应用程序推出时会自动销毁队列。使用队列函数处理消息队列的原理和使用数组方式是一样的,二者的构造和流程也相同。“删除数组中的元素”相当于“从队列中移出元素”函数,“往数组中增加元素”相当于“将元素移入队列”函数,实现的方式也是一样的。但两者的消息传递方式不同,前者采用的是移位寄存器方式,而后者采用队列技术;并且前者可以在程序结束时自动释放,后者的队列资源也可以在程序结束后自动释放,但是当程序作为子程序时,队列资源并不会随着子程序的结束而自动销毁,而是需要等到主程序结束时才释放。所以有必要使用“释放队列引用”函数手动销毁队列。

本节解决了基本状态机模式中的1)~3)个问题,为了更好地比较和使用这些特点,特使用一个实例说明消息队列型状态机的使用过程。

【例5-3】自动贩卖机

本例要模拟一个自动贩卖机的工作过程。它的一次正常交易过程为“投币”→“选择需要购买的商品”→“找币”,当币值不足或商品已经销售完毕时则无法购买。

程序的前面板如图5-11所示。在贩卖机的左上侧有4个按钮,单击“1USD”时表示投入1美元的货币,单击“2USD”和“5USD”类同;“Change Back”表示找零,也就是将目前剩余的货币退还给用户。

程序的右侧是5个按钮,表示5种不同类别的可乐(这里均使用可口可乐的图标),每种可乐的价格均是1美元。可乐下面的数字表示贩卖机中剩余的该商品的数量,初始为每种20瓶。“Current money”显示贩卖机中剩余的货币数,你可以继续购买可乐或者选择退回。单击“Stop”按钮将退出应用程序。

本例将使用本节介绍的消息队列状态机模式解决这个应用(也可以使用其他的设计模式)。系统的功能并不复杂,关键是要判断贩卖机中的剩余钱数和剩余的货物数以决定交易是否成功。自动贩卖机前面板如图5-11所示。

978-7-111-49442-3-Chapter05-13.jpg

图5-11 自动贩卖机前面板

系统分为5个状态,并分为2大类。

(1)第一类:Initial

·UIInitial:前面板界面的初始化。

·DataInitial:数据的初始化。

(2)第二类:System

·Idle(Default):空闲状态。

·CheckMoney:贩卖机中的剩余钱数和剩余的货物数以决定交易是否成功。

·Exit:退出程序。

程序开始运行时进入UI Initial和Data Initial状态,完成初始化操作。从图5-12中可以看出系统采用数组函数处理消息队列。

978-7-111-49442-3-Chapter05-14.jpg

图5-12 自动贩卖机程序框图

在UIInitial中,系统给标题栏和说明栏赋值,并将前面板的商品设置为不可购买状态,因为在初始化时还没有完成投币动作,如图5-13所示。

978-7-111-49442-3-Chapter05-15.jpg

图5-13 UIInitial状态

在Data Initial中包含两个共享的数据:Money和GState,前者表示贩卖机中剩余的币值,初始化值为0;而后者表示贩卖机中各个商品剩余的数量,初始化值为20。数据使用移位寄存器传递以便于在各个case分支中共享和使用,如图5-14所示。

978-7-111-49442-3-Chapter05-16.jpg

图5-14 DataInitial状态

CheckMoney分支主要是为了防止不合法的交易(如投入的币值不足或商品数量不足),如图5-15所示。

978-7-111-49442-3-Chapter05-17.jpg

图5-15 CheckMoney状态

当程序运行到Exit分支时,将停止循环并退出程序,如图5-16所示。

如图5-17所示,Idle分支用来监控前面板各个按钮控件的变化并执行相应的状态。该分支比较复杂,当检测到第0个按钮被按下时(即1USD按钮),贩卖机中的货币值应该加一,同时需要判断是否达到了交易条件(即进入CheckMoney状态)。其他的状态可以执行相应的代码即可,这里不再重复解释。

978-7-111-49442-3-Chapter05-18.jpg

图5-16 Exit状态

978-7-111-49442-3-Chapter05-19.jpg

图5-17 Idle状态

从本例可以看出,相比基本状态机而言,尽管程序的复杂度增加了,但是在构建大型的应用程序时也更加完善,代码也易于维护和查看。