有限状态机编程

① 有限状态机的编程

有限状态机体现了两点：首先是离散的，然后是有限的。
State：
状态这个词有些难尘铅以定义，状态存储关于过去的信息，就是说它反映从系统开始到现在时刻的输入变化。
Actions & Transitions：
转换指示状态变更，并且用必须满足来确使转移发生的条件来描述它。动作是在给定时刻要进行的活动的描述。
Guards:
检测器出现的原因是为了检测是否满足从一个状态切换到另外一个状态的条件。
Event：
事件，又见事件，笼统说来，对系统重要的并州某件事情被称为事件。
恩，就这些了，有些迷惑么:),恩，我们来理清一下思路：先从事件说起，事件是有生命
的，它经历:
1).被产生(被接受，等待被处理，一般放入事件队列)
2).被分发(从事件队列取出，分发到响应的状态机处理)
3).死亡(当状态机处理了该事件，它随之死亡)
从一个状态切换到另外一个状态被称为派蔽好状态转换，而引起它的事件称为触发事件.(可以看到，不是所有的事件都会引起状态的转换).
提到状态转换，不能不提及检测器(Guards)，只有当检测器的值为TRUE时候，才能启动转换

② 软件工程里面系统分析和系统需求分析有区别吗

看看这个吧 希望能对你有帮助“普及计算”时代：嵌入式系统重新划分计算机类别 由于事物的发展性，对事物的定义是很难放之四海而皆准的，尤其对于计算机领域而言，这种现象更加明显。以前我们把计算机按其体系结构、运算速度和结构规模等因素分为大、中、小型机和微机，并以此来组织学科和产业分工，后来随轿姿搜着微机处理速度的迅速提高，使得这种划分界限大大模糊化。而嵌入式计算机系统在当前及未来的大量应用，无疑会使得这一幕重新上演。 计算技术在各行各业的广泛渗透，使得嵌入式计算机在应用数量上将远远超过传统意义上的计算机，它可以应用于制造业、通讯、仪表、汽车、军事、航空航天和消费类电子产品等广阔领域。许多学者主张以应用为中心把计算机划分为两类：通用计算机（典型的如PC）和嵌入式系统。因为科技发展的动力在某种程度上总是欲使人类自身更为舒适，所以未来必定是一个“普及计算”（Pervasive Computing）的时代，在诸如家庭网络（Home Network）、汽车网络（Automobile Network）、移动电子商务（Mobile e-business）以及Financial Service Everywhere等普及计算的重要内容中，嵌入式系统都将是核心的组成部分之一。 在嵌入式系统中，软件与硬件是紧密集成在一起的。它和通用计算机有着本质的区别，由于它基于具体应用，所以在各种不同嵌入式系统之间，很难找到共通的特性。嵌入式系统的分析和设计无法延用传统方法。本专题围绕“嵌入式系统开发技术”这个核心，组织了以下四篇文章： 1. 实时系统软件分析和设计方法综述 2. 嵌入式系统软件的面向对象开发技术 3. 实时操作系统任务间通信的设计与分析 4. 嵌入式计算机系统的设计技术 本专题分两次刊出，本期刊出前两篇文章. 实时系统简介 实时系统在工业、商业和军事等领域都有非常广泛的用途，并且已经有很多实际的应用。一般来说，实时系统通常是比较复杂的，因为它必须处理很多并发事件的输入数据流，这些事件的到来次序和几率通常是不可预测的，而且还要求系统必须在事先设定好的时限内做出相应的响应。 那么，是不是响应时间在多少毫秒或多少微秒以内的系统就是实时系统，而超出这个时限的就不算呢？事实上，实时系统并非是指“快速”的系统，实时系统有限定的响应时间，从而使系统具有可预测性。实时系统又可以分为“硬实时系统”和“软实时系统”。二者的区别在于：前者如果在不满足响应时限、响应不及时或反应过早的情况下都会导致灾难性的后果；而后者则在不满足响应时限时，系统性能退化，但并不会导致灾难性的后果。 实时系统具有以下一些特点，从而区分于其他系统： 嵌入式系统 实时系统通常是嵌入式的系统，也就是由封装好的软件系统控制与其相关的硬件。 与外部环境交互 实时系统通常需要与外部环境进行交互，例如，可以控制机器及生产过程，或者监控化学反应并随时汇报危急情况，这种情况通常需要从外部接收数据并提供输出和控制外部环境。 时限 实时控制 实时系统经常包括实时控制，从接收到的输入数据中做出控制决策。 “反应”系统 很多实时系统都是“反应”的系统，也就是说，由事件驱动并且必须对外界事件进行响应。 并发处理 绝大多数实时系统的一个重要特点是并发处理，通常，事件发生的顺序是不可预测的。 一些重要概念与一般的系统设计一样，实时系统软件也包括一些和一般系统相同的分析和设计概念，在这里不再讨论。下面列出几点对于实时系统设计有特别重要意义的概念： 有限状态机（FSM） 很多实时系统，特别是实时控制系统，其整个分析机制与系统的状态有相当大的关系。有限状态机由有限的状态和相互之间的转移构成，在任何时候只能处于给定数目的状态中的一闭历个。当接收到一个输入事件时，状态机产生一个输出，同时也可能伴随着状态的转移。主要有两种方法来建立有限状态机，一种是“状态转移图”，另一种是“状态转移表”，分别用图形方式和表格方式建立有限状态机。实时系统经常会应用于比较大型的系统中，这时采用图形或表格方式对理解复杂的系统具有很大的帮助。 并发任务 实时系统通常都会有很多事件同时产生。一个任务描述一个事件，整个系统的并发机制是通过让很多任务并行运行而实现的。一个强调并发任务的系统设计通常都会显得更加清楚并且易于理解。 信息隐藏 信息隐藏是一个与各种系册兄统设计都有关的设计概念，原则是每个模块应该隐藏可能会做改变的设计结果。采用信息隐藏的原因是使模块可供修改，易于理解，因此也便于维护。 实时系统分析和设计的常用方法 首先要区分两个不同的概念：系统分析和系统设计。系统分析指的是由用户提供的，说明软件系统应该做什么以及需要在什么环境下运行等情况的方案；系统设计则是指那些由系统分析员或设计者提供的描述软件系统如何实现这些需求的方案。在实时系统的设计中，系统的瞬时表现是最难描述的，但同时也是最重要的因素。 以下具体地介绍实时系统设计的常用方法。 语言描述及数学分析 在系统分析和设计中，语言描述是不可缺少的，但其功能也只是对其他方法提供的分析和设计进行补充。在系统分析中，也可以采用数学分析来描述对系统功能的需求。数学分析是一种精确而有效的方法，对系统性能的优化可以通过优化相应的数学模型而获得，但在大系统中，其作用相对受限。 流程图 流程图也许是最早出现的软件系统模型，而且也有着很广泛的应用，因此，简单的系统可以采用流程图来进行建模。流程图适合指令不超过5000到10000条的系统。在多任务的系统中，流程图可用来对各个任务进行分别描述，但是进程之间的交互就不太容易描述，同时也无法描述其瞬时的表现。 结构图 结构图是一种广泛采用的、用以描述系统模块结构的方法。结构图从左到右代表了执行的顺序，从上到下代表了程序模块的细节化。结构图可以在相当多的计算机科学的文献以及其他描述系统的文章中见到。 伪代码和编程设计语言(PDL) 编程设计语言与伪代码只有细小的差别。编程设计语言是一种与系统运行的底层硬件环境相分离开来的抽象语言，它以一种类似于真正的编写代码的方式来说明系统。ADA就是一个成功应用编程设计语言的例子。 使用编程设计语言或伪代码的好处是，它们比直接应用语言来描述系统需求更抽象，而同时比前述所有方法都更接近实际的编程语言。 有限状态机 有限状态机是实时系统设计中的一种数学模型，是一种重要的、易于建立的、应用比较广泛的、以描述控制特性为主的建模方法，它可以应用于从系统分析到设计的所有阶段。有限状态机的组成如下： （1） 一个有限的状态集合Q （2） 一个有限的输入集合I （3） 一个变迁函数δ：Q×I→Q 变迁函数也是一个状态函数，在某一状态下，给定输入后，FSM转入该函数产生的新状态。δ的定义域内的某些数值可以是未定义的。 有限状态机通常用图的方式来表示，其节点代表状态。若在输入ｉ下状态由q1转变为状态q2，则有一条标有输入ｉ的弧线从状态q1指向q2。此时，其变迁函数δ(q1,i)=q2。图１示意了一个简单的有限状态机。
图1 简单有限状态机 图1中的左图表明该FSM有q0、q1、q2、q3四个状态，输入集中有a、b、c三个元素；右图中各个状态之间的转换关系则更清晰。有限状态机非常适合于描述这样的系统：系统含有有限个状态，不同事件的发生可以用不同状态之间的转换来模拟。 总的来说，有限状态机的优点在于简单易用，状态间的关系能够直观看到。但应用在实时系统中时，其最大的缺点是：任何时刻系统只能有一个状态，无法表示并发性，不能描述异步并发的系统。另外，在系统部件较多时，状态数随之增加，导致复杂性显着增长。为了消除这些缺点，一些新的方法应运而生。下面介绍的Petri网就是其中一种，与FSM相比，它具有更强的建模能力，并能描述系统的并发、异步、同步等特性。 Petri网 Petri网是一种使用图形方式对系统进行需求规格说明的技术，用来定义多进程、多任务系统的数学模型，易于描述系统的并发、竞争、同步等特征，并可用于评价和改进系统。如今，Petri网已经大量应用于各种系统的模型化。与FSM相比，Petri网不仅能描述同步模型，更适合于相互独立、协同操作的处理系统。 Petri网的组成成分包括： (1)一个有限的库所（place）集合，表示系统的状态。 (2)一个有限的变迁（transition）集合，表示系统中的事件。 (3)一个有限的连接库所到变迁或者反向的有向箭头的集合，又分输入和输出。 图2为一Petri网示例，图中的库所用圆圈表示，变迁由矩形表示。 Petri网有如下特性： (1)状态 通过标记Petri网的库所来给出其状态，标记Petri网的库所在图形中表现为对库所插入数目不同的令牌。 (2)状态变化规则 一个变迁可以有多个输入或输出库所，如果一条有向箭头是从库所到变迁，则该库所是该变迁的一个输入库所，反之则为输出库所。如果一个变迁中每一个输入库所都至少有一个令牌，则称该变迁是一个使能变迁。 (3)点燃 一个使能变迁可以被点燃，即从该变迁的每一个输入库所中移走一个令牌，在该变迁的每一个输出库所中增加一个令牌。 图2 Petri网示例� 图2中，库所中的星号代表令牌。由(a)中可以看出，变迁t1和t2都是使能的，(b)表示了点燃t1的过程，(c)表示了点燃t2的过程。从这个模型中可以看出，在给定初始令牌后，Petri网的发展过程可能是不同的。在Petri网中，经常利用变迁来模拟一个事件，而点燃则用来表示事件的发生。这样，如果一个变迁所表示的事件的发生条件是满足的，那么这个变迁就是使能的，库所中的星号标记则说明某个条件是满足的。图2中的Petri网可分为两部分，一部分是由变迁t1、t3组成，另一部分由t2、t4组成，这相当于是两个独立的工作流，并且共享了资源p3。开始时，双方可以互不干涉地、异步地进行，因为变迁t1和t2双方互不妨碍。点燃t1后，t3处于使能状态，点燃t2后，t4处于使能状态。在两个变迁都点燃后，两个工作流都有新的变迁处于使能状态，但是这两个变迁的点燃处于竞争状态，两个工作流中只能有一个获得p3的资源从而得以继续变迁。如果资源满足的情况可以解决这种冲突，就可以设p3的令牌有两个，两个工作流就互不干扰，可以并发执行。 数据流图 数据流图主要是作为软件系统建模中的结构化分析工具。建立数据流图从分析系统的功能需求开始，分析系统中的数据流并且确定主要的函数。数据流图需要细分系统和子系统，从而在图中对数据流有清楚的表现。 表1方 法优点缺点语言描述广泛应用，能起说明作用不够明确，无法相应产生代码。数学分析精确，是一种正式的分析方法，可在此基础上进行代码优化。难于应用，并非很多系统设计人员都能够通过数学方式对系统分析。流程图广泛应用，对单任务系统非常适合。没有并发处理，不能表现瞬时状态，多采用GOTO语句。结构图广泛应用，适合于小系统，鼓励自顶向下的设计方式。没有条件转移，没有并发处理，不能表现瞬时状态。伪代码和PDL与编程语言接近，是正式应用的分析和设计方法。容易出错且不易发现。有限状态机广泛应用，易于建立，方便于代码产生和优化。没有并发处理，随着状态的增加系统复杂性显着增加。Petri网广泛应用，适合于多进程处理，对并行性有很好的表示。应用于过小的系统时显得不必要。数据流图广泛应用，并发处理，易于理解。不易于表示同步性控制流图是一种在系统中实现控制信号流的数据流图。这些控制信号能够描述离散的从开关或感应器得到的信号数据，同时也能包含从离散时钟得到的离散的定时信息。数据流图和控制流图结合使用，可以提供更具控制性的信息。 总体来说，数据流图特点是：强调数据的流动，不太强调控制信号的流动，对于确定并发性很有用。实际上，如果缺少了并发性的特点，数据流图就是有限状态机。数据流图最主要的缺点是描述同步很困难。 数据流图容易理解，应用广泛，通常是和一些其他方法结合使用来产生连贯的软件需求文档。实时系统分析和设计方法总结 本文对应用于实时系统的、常用的多种分析和设计方法进行了简单的介绍。应该明确的一点是，没有一种分析或设计方法是可以应用于任何场合的，事实上，很多情况都是几种方法的混合使用。表１列出了文中所介绍的各种分析和设计方法，并简单列出其优缺点。

③ 编程所需要的数学知识

计数的能力： for循环中经常用， 小学生都会。
数字的加减乘除 ： 每种编程语言都会内置支持， 都不需要你自己算
余数和模： 偶尔会用得到
集合运算： 交集、并集、差集 ， 编程中用的不多。
布尔运算： AND , OR, 非
各种进制： 二进制、十进制、十六进制
还有哪些？ 我想不起来了， 欢迎补充。
当然这和我从事的编程领域有极大关系， 如果我做的不是Web开发， 而是搜索，游戏， 安全，算法，人工智能等， 那对数学的要求估计就开始飙升了。
其实计算机的基础是数学， 只是我们一直在应用层编程， 体会不到罢了。
比如说我们日常使用的计算机，绝大部分都是所谓冯诺依曼结构(参见文章《冯·冯诺依曼计算机的诞生》) ，这个结构可以说是图灵机这个概念机器的具体实现，而图灵机就是一个纯数学的东西啊 ，没有图灵机这么伟大的抽象作为数学基础， 现代的计算机是制造不出来的。
再比如说密码领域需要很多数论的知识，RSA算法就涉及到大素数的分解；
我们常用的Mysql, Oracle 等关系数据库的底层基础是离散数学的笛卡尔乘积；
通信系统中很重要的一个原理就是傅里叶变换。
编译器会用到有限状态机；
数据的压缩会用到各种数学的算法；
项目管理中的进度管理，甘特图数学基础就是图论。

④ 状态机到底是什么

状态机是有限状态自动机的简称，是现实事物运行规则抽象而成的一个数学模型。

先来解释什么是“状态”（State）。现实事物是有不同状态的，例如一个LED等，就有亮和灭两种状态。我们通常所说的状态机是有限状态机，也就是被描述的事物的状态的数量是有限个，例如LED灯的状态就是两个亮和灭。

状态机，也就是StateMachine，不是指一台实际机器，而是指一个数学模型。说白了，一般就是指一张状态转换图。

状态机由状态寄存器和组合逻辑电路构成，能够根据控制信号按照预先设定的状态进行状态转移，是协调相关信号动作、完成特定操作的控制中心。有限状态机简写为FSM（Finite State Machine），主要分为2大类：

第一类，若输出只和状态有关而与输入无关，则称为Moore状态机；

第二类，输出不仅和状态有关而且和输入有关系，则称为Mealy状态机。

有限状态机是一种概念性机器，它能采取某种操作来响应一个外部事件。具体采取的操作不仅能取决于接收到的事件，还能取决于各个事件的相对发生顺序。之所以能 做到这一点，是因为机器能跟踪一个内部状态，它会在收到事件后进行更新。为一个事件而响应的行动不仅取决于事件本身，还取决于机器的内部状态。另外，采取 的行动还会决定并更新机器的状态。这样一来，任何逻辑都可建模成一系列事件/状态组合。

(4)有限状态机编程扩展阅读：

状态机的四大概念：

State，状态。一个状态机至少要包含两个状态。例如上面灯泡的例子，有灯泡亮和灯泡灭两个状态。

Event，事件。事件就是执行某个操作的触发条件或者口令。对于灯泡，“打开开关”就是一个事件。

AcTIon，动作。事件发生以后要执行动作。例如事件是“打开开关”，动作是“开灯”。编程的时候，一个AcTIon一般就对应一个函数。

TransiTIon，变换。也就是从一个状态变化为另一个状态。例如“开灯过程”就是一个变换。

状态机的应用：

状态机是一个对真实世界的抽象，而且是逻辑严谨的数学抽象，所以明显非常适合用在数字领域。可以应用到各个层面上，例如硬件设计，编译器设计，以及编程实现各种具体业务逻辑的时候。

进程5状态模型：

进程管理是Linux五大子系统之一，非常重要，实际实现起来非常复杂，我们来看下进程是如何切换状态的。

⑤ 有限状态机系统在嵌入式软件中是个什么地位

有限状态机是嵌入式软件的一种结构。

有限状态机是实时系统设计中一种重要的，容易建立的，应用比较广泛的，以描述控制特性为主的建模方法，它可以应用于从系统分析到设计的所有阶段。
有限状态机系统优点：简单易用，状态间关系直观看到，便于编程；可以快速执行；只是通过改变输出功能来改变机器的响应。悄埋缺点：任何时刻系统败运凳只能有一个状态，无法表示并发性，不能描述异步并发系统；在系统部件多时，状态数察旅随之增加，导致复杂性显着增长；对于大的应用系统，难于调试。 —— 转自 http://blog.csdn.net/chinaunixj/article/details/737

虽然如此，个人认为，有限状态机虽然不能用于表示并发和描述异步这一点显而易见，但是仍然还是可以用于实现异步并发系统。

⑥ stateflow怎么删除输入口接口

看了下上面的答岁陵案，呵呵了

不多吐槽，点开model explorer 位置在乎兆戚这里

选择你想改名或者猜伍删除的变量，键盘上按下Delete即可

⑦ 在实现一个任务时，为什么要使用状态机编程

大多数的应用程序如果在开发时考虑采用两个以上线程，那么一般情况下是为每个线程分配了独立的功能，且这些功能能够“并发地”执行。讲一个二楼同学说到的网络I/O例子：点对点的聊天工具，需要在我们编写信息的同时能够接受并打印出来对方说的话。如果将信息的发送和接受放在一个线程里，线程的单一顺序控制流程特性就使得发送和接受两者不能兼顾。其实说到“并发地”，实际上，这两个线程并不是同时在执行，而是相斥地，但是由于计算机的数据处理能力很强大，能够把系统资源快速地在这两者之间进行调配（切换），以至于我们人感觉不到这个切换的过程，好像它是在并发地执行，也就是说计算机通过多线程提供的所谓“并发性”满足了程序使用者对于并发性的要求。
上面这个例子就说明了在单核计算机上，多线程程序还是有其存在的合理性滴。

⑧ 什么叫提机状态

提机状态机是一种编程思路。一种对对自然界某种事物(或数据)状态变化的抽象。 让你的程序开发维护,思路更加返配清晰方便。它规定了一个实例(某种抽象),某一时刻只能有一种状态(属性)。一般用字符串表示。 规定了只能通过实例的方法,即执行某个动作(函数),之后才可以改变状态(属性)。

状态机由状态寄存器和组合逻辑电路构成，能够根据控制信号按照预先设定的状态进行状态转移，是协调相关信号动作、完成特定操作的控制中心。有限状态机简写为FSM（Finite State Machine），主要分为2大类：

第一类，若输出只和状态有关而与输入无关，则称为Moore状态机。

第二类，输出不仅和状态有关而且和输入有关系，则称为Mealy状态机。

状态机由状态寄存器和组合逻辑电路构成，能够根据控制信号按照预先设定的状态进行状态转移，是协调相关信号动作,完成特定操作的控制中心漏竖指。

状态机分为摩尔（Moore）型状态机和米莉纤纯（Mealy）型状态机。

状态机就是状态转移图。

⑨ [因为我不懂啊]-什么是状态机编程（设计模式）（3）

上一篇文章写完之后，我一直在想做一个游戏示例，想将之前学到的状态机模式运用在其中。然而一直遇到各种奇怪的bug（之后写出来），所以一直没有完成这件事。而且加之自己又犯懒了，所以我决定做一件更简单的事，以更容易接近的目标来引诱懒的不行的自己。

废话说完，来说正经事了。前几天认真看了一篇 博客-游戏状态机 （侵立删），觉得厅念碰挺不错的，建议盆友们认真看一看。

读完博客之后，之前计划的示例貌似有了头绪，（废话型）总结出来，实现一个游戏状态机结构需要进行如下几步：

我要做一个简单的UI切换示例，所以简述需求就是: 打开程序进入主界面，主界面中点击开始游戏，进入游戏界面，游戏界面中点击结束游戏，进入结算界面，结算界面可以点击回到主界面，进入主界面，也可以点击重新开始游戏，再次进入游扮谈戏界面。

从需求描述来看，状态有三个:

事件有四个:

然后（装模作样的）画了一个状态转换表：

之前一篇文章中有提到过的，在Cocos2d-x游戏开发中，刚好使用Scene来作为控制器，由Scene来控制各层的出现和消失。

这里贴出Scene的源码(完整的源文件，包括了后续步骤才会出现的状态基类，以及派生的状态类)：
QFLGameTwoScene.hpp

QFLGameTwoScene.cpp

上面可以看到，Scene中主要包含了:

包含了以上内容，本示例中的这个Scene就能起到控制器的作用了。

状态基类是很有必要的，为了达到各个同级状态都能通过同一个控制器来进行状态转换的目标，各个状态类进行切换时必须有一套统一的流程。
这里贴出本示例中状态基类的源码:
QFLGameTwoStateBase.hpp

这个源文件中包含了:

所有的派生状态类都会 include 这个文件，实现虚基类 GameTwoState 中的方法，所以所有的状态类都有统一的切换流程:

而且在完成某个事件，需要进行状态转换时，可以通过发送自定义事件来完成消息的传递，自定义事件名放在这里也是为了方便起见。

这里直接贴出几个State的源码了，其高扰中包含注释，废话就不重复再写了:

QFLGameTwoMainLayer.hpp

QFLGameTwoMainLayer.cpp

QFLGameTwoGameLayer.hpp

QFLGameTwoGameLayer.cpp

QFLGameTwoResultLayer.hpp

QFLGameTwoResultLayer.cpp

到这里，上面所提到的步骤全部进行完了。这个UI切换的状态机示例也就完成了。

在AppDelegate.cpp中，直接进入Scene中:

进入主界面 :

此时的Log:

点击Start，进入游戏界面 :

此时的Log:

<Exit> ->MainLayer
<Enter> ->GameLayer
<Execute> ->GameLayer

点击Over，进入结算界面 :

此时的Log:

<Enter> ->GameLayer
<Execute> ->GameLayer
[Event]->Game_Over
<Exit> ->GameLayer

<Enter> ->ResultLayer
<Execute> ->ResultLayer

点击Replay，重新进入游戏界面 :
此时的Log:

<Enter> ->GameLayer
<Execute> ->GameLayer
[Event]->Game_Over
<Exit> ->GameLayer

<Enter> ->ResultLayer
<Execute> ->ResultLayer
[Event]->Result_Replay
<Exit> ->ResultLayer

<Enter> ->GameLayer
<Execute> ->GameLayer

点击Over，再次进入结算界面，然后在结算界面点击Home，回到主界面
上面的两次操作完成后，Log如下:

<Enter> ->GameLayer
<Execute> ->GameLayer
[Event]->Game_Over
<Exit> ->GameLayer

<Enter> ->ResultLayer
<Execute> ->ResultLayer
[Event]->Result_Replay
<Exit> ->ResultLayer

<Enter> ->GameLayer
<Execute> ->GameLayer
[Event]->Game_Over
<Exit> ->GameLayer

<Enter> ->ResultLayer
<Execute> ->ResultLayer
[Event]->Result_Home
<Exit> ->ResultLayer

<Enter> ->MainLayer
<Execute> ->MainLayer

这里用FSM实现UI切换示例只是众多方法中的一种，暂时还没有去比较它们的优劣。(使用markdown编辑器的经验值+1)

可能性多种多样，如果有小伙伴比较过这些方法。求留言告知，求分享经验。