应用程序有两大类：

1. 一种是数据处理的程序，我们常常用算法来描述它，程序对某些输入数据进行预定的处理，以便得到某些输出的数据，程序目前的状态可以用资料目前的状态来描述，例如：人事薪资系统、仓储物流系统等等；

2. 另外一类是与外界环境互动的系统，例如：操作系统、文书处理系统、飞航管制系统、交通管制系统、游戏等等，这一类系统一般来说没有明确的输入/输出数据，但是有很多与外界不预期的互动，通常系统响应的方法与系统内部的状态有密切的关联，系统内部通常有许多记录状态的变量。

针对这两大类的程序，我们描述它们的方法也不太一样，对于前者，我们通常用控制流程图或是数据流程图来描述，对于后者则常用状态图来描述。基本上流程图中最重要的部份是 "处理 process" 单元，程序由几个主要的处理单元组合而成，状态图中最主要的是程序目前的状态，每一个状态总结记录程序由开始到目前所有接到的输入。

控制流程图常常只描述单一的程序 (执行绪)，多个程序的控制流程图需要使用同步机制来描述，如果流程图中各个区块的连结非常复杂的话，有可能式程序不属于数据处理类的，无法用 "处理单元" 来清楚地描述，需要改用其它的方法来描述。状态图基本上并没有限制只能描述单一的程序 (执行绪)，状态图上任一时间点系统只能在某一状态下，而任一时间点只会有单一的事件发生 (假设时间的精确度足够的话，任何两件事一定可以分辨出先后的顺序)。状态图上的动作基本上是由事件来驱动的，和事件驱动的对象导向式程序模型相当契合。

一个状态图是否可以用流程图来取代呢?

以下面的这组状态图及流程图为例：

状态图

流程图

控制流程图一般描述单一的处理器 (行程) 之处理过程，上面流程图中任意时间点都只执行单一一个区块的内容，如果有不同的处理器共同参与的话，也一定有先后的顺序，某一区块 (例如 a1) 也有可能让多个处理器一起共同执行以加快处理的速度。流程图中条件测试必须依序执行，例如： e1, e2, e5, 如果都不成功的话，会不断地重复测试，此时 e1, e2, e5 的条件有可能因为外界环境改变或是其它程序干涉而改变。在状态图中系统所有的处理器一并考虑在内，任何时间点上系统必然处于三个状态之一，假设在 state 1，此时不管哪一个处理器使得 e1, e2 或是 e5 发生，则系统会让相对应的 a1, a2 或是 a5 执行完毕 (不论是用哪些个处理器来完成)，然后系统状态进入 state 2。

在这个范例上状态图明显在架构上比流程图要简单，包容的模型也比较丰富，需做的假设比较少。另外，状态图比较重视事件/动作的完成，比较不在意是哪一个程序完成的。流程图则很在意动作是如何完成的。在状态图上如果某一个状态下少考虑了哪一个输入事件的话，可以很快地检查出来，可是在流程图上就无法分辨了。状态图上没有事件发生时，系统就暂停下来等待 (没有做什么有意义的事情)，流程图上则变成一个所谓的 busy loop。状态图比较适合对象导向的程序，流程图则比较适合描述程序导向或是数据处理的程序。
状态图范例:

TCP 联机状态图 (See Steven's book)

Delete Document 对象运作状态图 (see Kerr's book)

绘制状态图常用组件

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号