电梯系统的UML文档13

5.2.6 CarPositionControl 的状态图

图 24: CarPositionControl 的状态图

5.2.7 Dispatcher 的状态图

图 25: Dispatcher 的状态图

5.3 填补从需求到状态图鸿沟的实用方法

状态图能对类的行为，一个用例，或系统整体建模。在本文中，状态图被用于每个对象的行为建模。在系统后面的阶段，如实施阶段和测试阶段，每个对象的状态机都将用到。

UML 中没有提供详细的方法，即该如何从需求文档或UML 图表如类图画出状态图。我尝试在这里从课程上的项目经验总结一些从需求文档画出状态图实用的方法，如下:

第 1 步:

如果你想画出每个对象的状态图，应该完成对象结构和系统架构的分析。在我们的课程项目中，这部份工作在我们开始自己的项目之前由老师完成了。

第 2 步:

仔细读系统中每一个类或对象的需求。

状态图的大部分需要的信息都可以通过这个方法找到，提供好的充足的需求文档就可以了。我不确定需求文档有没有任何格式标准。

举一个我们课堂中的例子来说用，我们的电梯系统需求文档中有一些方面应给于不同的关注。

· 回答: 这个部份简述主要功能和特殊对象的存在条件。画状态图的时候这个部份用处不大，但是当状态图完成时可以用来检查功能实现了没有。

·初始化:初始状态由给出的信息决定。以HallButtonControl 为例，初始状态是 " 所有的 HallCalls 初值是false " 和 " 所有的HallLights 初值是关"。从这些描述中我们至少能得出结论：初始状态是"门厅呼叫是False " 或 " 门厅 Light is off 灯是False "，但这还不完全，让我们继续。

· 输入介面: 这个对象将会从其他的对象中取得的输入信息。

输入变量将触发状态变化，例如状态图中的过渡。

在 HallButtonControl 例子中，DesiredFloor 和 HallCall 的数值变化，建立一组事件，触发我们未来状态图中所有的状态变化。

· 输出介面:这些信息帮助建立状态图中的状态。在我们的例子中，HallLight 是这个对象的处理的单一输出。我们可以想象一下HallLight 可以处于多少个状态。凭直觉门厅灯能打开和关闭，因此它在状态图中可能有两个状态 :

开和关。

让我们看看还有没有别的东西需要加入。

· 状态: 这里的状态和状态图无关，在这些项中一些记号用来速记描述行为。

· 约束和行为:都将用来检查这个对象的状态机是否实现了系统的功能需求而不打破约束。我们从行为描述知道状态机的变化如何被触发，这很重要。

第 3 步:

现在我们有来自需求的一些想法。现在可以产生最初的状态机。