UML建模风格之状态图

　　UML状态图描述一个实体基于事件反应的动态行为，显示了该实体如何根据当前所处的状态对不同的时间做出反应的。通常我们创建一个UML状态图是为了以下的研究目的：研究类、角色、子系统、或组件的复杂行为。建模实时系统。

　　通用准则

　　当行为的改变和状态有关时才创建状态图。

　　敏捷建模( AM) ( Ambler 2002)的原则－－最大化项目干系人的投资－－建议你只有当模型能够提供正面价值的时候才创建模型。 如果一个实体，比如一个类或组件，表示的行为的顺序和当前的状态无关，那么画一个UML状态图可能是没有什么用处的。例如一个SurfaceAddress类就很简单，表示了那些你将会在系统中显示和操作的数据，因此一个UML状态图就没有任何相关之处。而一个Seminar对象就非常的复杂，学生注册这样一个事件将会根据它的当前状态有不同的反应，就像你在图１中看到的。

图⒈班级注册的一个UML状态图。

　　把初始状态放置在左上角。

　　如你在图１所见的，初始状态被建模成一个实心圈，把初始状态放在左上角反映西方人的阅读文化的习惯。

　　把最终状态放置在右下角。

　　如你在图１所见，最终状态被建模为一个带边界的实心圆。把最终状态放右下角反映了西方的文化的从左到右，从上到下的阅读习惯。

　　状态指南

　　状态是一个实体的行为模式的某个阶段。 状态的表示是通过实体的属性值。 例如，在图１中，当seminar被标记为open，并且存在空位的时候，seminar就处于Open For Enrollment的状态。

　　状态名称要简单但应具有描述性。

　　象Open For Enrollment和Proposed这种的状态名称很容易理解，从而提高了图⒈的沟通价值。理论上状态名称应该是现在时，但是用过去式写成的诸如Proposed的名称要比用现在时写成的诸如Is Proposed的名称好的多。

　　避免黑洞状态。

　　黑洞状态是那种只有变换进来但没有任何变换发出的状态，这种情况要么由于该状态是一个最终状态，要么就是你已经错过了一个或多个变换变换。

　　避免奇迹状态。

　　奇迹状态是那种只有变换发出但没有任何变换进来的状态，这种情况要么由于该状态是一个起点，要么就是你已经错过了一个或多个变换变换。

　　子状态建模指南

　　为复杂的目标建模子状态。

　　图１中展示的UML状态图是不完整的，因为它没有建模Seminar的post - enrollment（注册后）状态。 图２建模了一个Seminar的完整的生命周期，把图１描述为一个新的包括子状态集合的Enrollment的复合状态，也称作超状态。 注意按理说你会像图１的模型那样处理标记，但为了简化起见在原先变换上的标记都没有包括在内。当一个现有状态表现出复杂的行为时，建模子状态就是有意义的，从而促使你来研究它的子状态。 当几个现有状态共用一个通用的入口条件或出口条件( Douglass 1999)时，引入超状态是有意义的，在图１中你可以看到所有的状态共用一个通用的closed变换，以到达最终状态。

图⒉Seminar的完整生命周期

　　把通用的子状态变换放在一起

　　和图１中每一个子状态都拥有一个cancelled变换不同，在图２中你可以看到cancelled变换仅用于描述Enrollment超状态，这使图形得到简化。 如果子状态都共享一个入口变换或出口变换，都可以使用一个同样的方法。 变换上的警戒点和动作（如果有）也应该使相等的。

　　为复杂的实体创建一个分层的状态图

　　虽然这种表现子状态的方法是很好使的，但是最终的图可能变得相当复杂－－我们只要设想一下如果Being Taught状态也有子状态的话，图２会变成什么样就知道了。 一个替代的方法是创建一个分层的UML状态图。 例如，图３表示高阶视图，而图１描述了一个细节视图。这种方法的好处是如果需要的话，马上就可以建立一张详图来研究Being Taught状态。

图⒊Seminar的高阶状态图。

　　最高阶的状态图总有初始态和最终态

　　一个高阶的UML状态图，例如图2描述的这样，应该表示实体的完整的生命周期，包括出生和最后的死亡。 低阶的图未必包含初始状态和最终状态，特别是那些建模一个实体的生命周期的中间状态的图。

　　变换和动作

　　变换是从一种状态到另一种状态的序列，它可能是通过一个事件触发的。简而言之就是被建模的实体的内部或外部的行为。 对一个类来说，变换一般是将会导致状态的重要改变的操作调用的结果，因此我们需要了解一点，并不是所有的方法调用都会导致变换产生的，这一点非常重要。 一个动作就是某个东西，对类来说就是一个操作，被建模的实体所调用的操作。

　　用实现语言的命名规则命名软件动作

　　图１中的动作遵循Java操作的命名规则( Vermeulen et. 2000)，因为系统使用
用叙述性文字命名角色动作

　　UML状态图可用于建模非软件实体的生命周期，特别是UML图上的角色。 例如学生角色就可能有诸如Accepted、Full Time、Part Time、Graduated、Masters、Doctoral、和Post - Doctoral等状态，以显示各人的不同行为。 当你在建模现实世界的角色时，与软件中Student类不同的是，状态间的变换最好是使用叙述性文字来描述，例如drop seminar和pay fees，而不是dropSeminar ()和payFees ()，因为现实生活中的人是做事情，而不是执行操作。

　　只有对所有的入口变换都合适时才注明入口动作

　　在图１中你可以看到Closed To Enrollment状态的入口中操作notifyInstructor ()都是经由entry动作标记来调用的。 这暗示着每次进入状态时都需要调用该操作，如果你不希望每次都发生，那么就把动作关联到特定的入口变换。 例如，addStudent ()动作是在student enrolled变换到Open For Enrollment变换发生，而在到opened变换则不会发生，这是因为每次你在进入该状态并不需要增加一个学生。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有