本节和大家一起学习一下UML建模风格中的UML状态图，为了便于大家理解本节通过具体的图例讲解，希望通过本节的介绍大家对UML状态图的相关知识有大致的了解。下面让我们一起来看一下具体介绍吧。
UML建模风格之UML状态图
UML状态图描述一个实体基于事件反应的动态行为，显示了该实体怎么根据当前所处的状态对不同的时间做出反应的。通常我们创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。建模实时系统。
通用准则
当行为的改动和状态有关时才创建状态图。
敏捷建模(AM)(Ambler2002)的原则－－最大化项目干系人的投资－－建议你只有当模型能够提供正面价值的时候才创建模型。如果一个实体，比如一个类或组件，表示的行为的顺序和当前的状态无关，那么画一个UML状态图可能是没有什么用处的。例如一个SurfaceAddress类就非常简单，表示了那些你将会在系统中显示和操作的数据，因此一个UML状态图就没有所有相关之处。而一个Seminar对象就非常的复杂，学生注册这样一个事件将会根据他的当前状态有不同的反应，就像你在图１中看到的。
图⒈班级注册的一个UML状态图。
把初始状态放置在左上角。
如你在图１所见的，初始状态被建模成一个实心圈，把初始状态放在左上角反映西方人的阅读文化的习惯。
把最终状态放置在右下角。
如你在图１所见，最终状态被建模为一个带边界的实心圆。把最终状态放右下角反映了西方的文化的从左到右，从上到下的阅读习惯。
状态指南
UML状态图中状态是个实体的行为模式的某个阶段。状态的表示是通过实体的属性值。例如，在图１中，当seminar被标记为open，并且存在空位的时候，seminar就处于OpenForEnrollment的状态。
状态名称要简单但应具有描述性。
象OpenForEnrollment和Proposed这种的状态名称非常容易理解，从而提高了图⒈的沟通价值。理论上状态名称应该是目前时，不过用过去式写成的诸如Proposed的名称要比用目前时写成的诸如IsProposed的名称好的多。
避免"黑洞"状态。
黑洞状态是那种只有变换进来但没有所有变换发出的状态，这种情况要么由于该状态是个最终状态，要么就是你已错过了一个或多个变换变换。
避免"奇迹"状态。
奇迹状态是那种只有变换发出但没有所有变换进来的状态，这种情况要么由于该状态是个起点，要么就是你已错过了一个或多个变换变换。
子状态建模指南
为复杂的目标建模子状态。
图１中展示的UML状态图是不完整的，因为他没有建模Seminar的post-enrollment（注册后）状态。图２建模了一个Seminar的完整的生命周期，把图１描述为一个新的包括子状态集合的Enrollment的复合状态，也称作超状态。注意按理说你会像图１的模型那样处理标记，但为了简化起见在原先变换上的标记都没有包括在内。当一个现有状态表现出复杂的行为时，建模子状态就是有意义的，从而促使你来研究他的子状态。当几个现有状态共用一个通用的入口条件或出口条件(Douglass1999)时，引入超状态是有意义的，在图１中你能看到所有的状态共用一个通用的closed变换，以到达最终状态。
图⒉Seminar的完整生命周期
把通用的子状态变换放在一起
和图１中每一个子状态都拥有一个cancelled变换不同，在图２中你能看到cancelled变换仅用于描述Enrollment超状态，这使图像得到简化。如果子状态都共享一个入口变换或出口变换，都能使用一个同样的方法。变换上的警戒点和动作（如果有）也应该使相等的。请期待下节UML建模风格之UML状态图介绍。
【编辑推荐】
