需求的图形化分析-状态转换图

实时系统和过程控制应用程序可以在任何给定的时间内以有限的状态存在。当满足所定义的标准时，状态就会发生改变，例如在特定条件下，接收到一个特定的输入激励。这样的系统是有限状态机的例子。此外，许多业务对象（如销售订单、发票，或存货清单项）的信息系统处理是贯穿着复杂生存周期的；此生存周期也可以看成有限状态机。大多数软件系统需要一些状态建模或分析，就像大多数系统涉及到转换过程、数据实体和业务对象。
用自然语言描述一个复杂的有限状态机可能会忽略一个允许的状态改变或者引起一个不允许的改变。与状态机的行为有关的需求可能将多次出现在软件需求规格说明中，它取决于软件需求规格说明是如何组织的。这对综合理解系统行为造成困难。状态转换图(state-transition diagram，S T D )为有限状态机提供了一个简洁、完整、无二义性的表示（ Davis 1993）。状态转换图包括如下面三种元素：
• 用矩形框表示可能的系统状态。
• 用箭头连接一对矩形框表示允许的状态改变或转换。
• 用每个转换箭头上的文本标签表示引起每个转换的条件。标签经常既指示条件也指示相应的系统输出。
状态转换图没有表示出系统所执行的处理，只表示了处理结果可能的状态转换。对于软件系统中只能存在于特定状态的那一部分，你可以使用状态转换图来建模。特定状态或者指诸如汽车巡航控制系统等实时世界实体的行为，或者是这系统操纵的个体项状态。状态转换图有助于开发者理解系统的预期行为，它对于检查所要求的状态和转换是否已全部正确地写入功能需求中也是一种好方法。测试者可以从覆盖所有转换路径的状态转换图中获得测试用例。用户只要稍微学一些符号就可以读懂状态转换图。

回想一下，在化学制品跟踪系统中有一个主要功能是允许称为请求者的操作员提出对化学制品的请求，这一请求可以由化学制品仓库中的存货清单来执行完成，也可以通过向外界供应商发出订单来执行完成。每一个请求从创建到完成或取消这一时间段内将经历一系列可能的状态。于是，我们就可以把化学制品请求的生存周期看成一个有限状态机，其建模如图1 0 - 3所示。这个状态转换图说明了一个请求可取下列七种可能状态中的一种：

• 准备(in preparation)—请求者正在创建一个新的请求，已经从系统的其它部分进入那个功能。
• 延迟( p o s t p o n e d )—请求者存储他/她的工作以备后用，而并不向系统提交请求或者取消请求。
• 接受( a c c e p t e d )—用户提交一个完整的化学制品请求，系统判断该请求顺序是否有效，如果有效就接受该请求进行处理。
• 提出( p l a c e d )—采购员向供应商订货，并且外部供应商必须满足请求。
• 执行完成( f u l f i l l e d )—通过从化学制品仓库交付一个化学制品容器给请求者或者收到供应商的化学制品收据时才能使请求得以满足。
• 订单返回( b a c k - o r d e r e d )—供应商没有可用的化学制品，他通知采购员货物已订购以后再交付。

• 取消( c a n c e l e d )—在请求执行完成之前，请求者取消一个已被接受的请求，或者采购员在订单执行完成或返回订单之前，取消供应商订单。
当“化学制品跟踪系统”的用户代表评审最初的化学制品请求的状态转换图时，他们发现有一个不必要的状态，另外有一个必不可少的状态但分析者却没有记录，还有两个不正确的转换。这些错误在他们评审功能需求时，却没有一个人发现。
状态转换图并没有提供使开发者如何构造系统的详细细节。因此，软件需求规格说明必须包括与处理化学制品请求和它的可能状态变化相关的功能需求。然而，状态转换图对可能的请求状态和它们是如何允许变化提供了一个简洁的可视化表示。
实时系统的状态转换图除了包括一个空闲状态外，与图1 0 - 3所示的相类似，在这种系统中，当系统不再执行其它处理时就返回空闲状态。相反，对于一个贯穿整个定义的生存期的对象，例如一个化学制品请求，其状态转换图将有一个或多个终结状态；在图1 0 - 3中则表现为执行完成和取消状态。