UML状态图创建过程中需要注意什么问题

小编给大家分享一下UML状态图创建过程中需要注意什么问题，相信大部分人都还不怎么了解，因此分享这篇文章给大家参考一下，希望大家阅读完这篇文章后大有收获，下面让我们一起去了解一下吧！

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

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

图⒊Seminar的高阶状态图。

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

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

　　变换和动作

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

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

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

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

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

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

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

出口动作，用exit/标记来表示，工作方式类似于入口动作。

只有当你想终止并再进入该状态时才建模递归变换

UML状态图中一个递归的变换是那些两个端点都拥有相同状态的变换。一个重要的暗示是实体从状态出来，又回到原有的状态，因此，那些由于entry/或exit/动作标记而被调用的所有一种操作都可能被自动调用。图１的OpenForEnrollment状态就是这种递归变换的例子，因此当前班级大小就在入口处被记录下来。

　　用过去式命名转换事件

图１中的转换事件，例如seminarsplit和cancelled，是使用过去式命名的，反映了这样一个事实：变换是事件的结果－－因为事件发生在变换之前，因此应该用过去式命名。

把转换标记放在接近源状态的地方

虽然图１比较复杂，变换标记尽可能放在靠近来源的地方，例如seminarsplit和studentenrolled。Furthermore,thelabelswerejustified(leftandrightrespectively)tohelpvisuallyplacethemclosetothesourcestate.

以转换方向为基础放置变换标记

为了更易于判断哪个标记和变换是一起的，按照如下的规则来放置变换标记：

在变换线条上的从左到右。

在变换线条下的从右到左。

变换线条右边的往下。

变换线条左边的往上。

警戒点

一个警戒点是为了穿过一个转换而必须为真的一个条件。

警戒点不应该重叠

UML状态图离开状态的相似变换上的警戒点必须彼此一致。举例来说，x<0,x=0,及x>0的警戒点是一致的，而x<=0和x>=0的警戒点就不是一致的，因为他们重叠了，他并没有明确的指出当x为0时将发生什么。在图1中，你能看到警界点的一致性，从填写注册表活动出发的该学生划线变换上的警戒点没有重叠，决策点上的警戒点也相同。

为可视化的定位警戒点而引入接合点。

在图２中你能看到从BeingTaught触发studentdropped事件存在两个变换，而图３中仅有一个，变换被合并了，因此我们需要一个接合点（填满的圆）。这种方法的好处是目前图上的两个警戒点更彼此接近了，更容易看出警戒点是否重叠。

警戒点不必配套

一个状态的变换警戒点有可能是不完整的。例如，一个bankaccount对象可能从Open状态变换到NeedsAuthorization状态，这时需要一个大额存款"largedeposit"的警戒点。可是，一个带有"smalldeposit"的警戒点的deposit变换可能并不必建模，他是被隐含的，我们遵循了AM的实践－－简单的描述模型和仅仅包括相关的信息。

一致的命名警戒点

图１包含了诸如seatavailable和noseatavailable的警戒点，两个警戒点的描述是一致的。然而，诸如seatsleft、noseatleft、noseatsleft、noseatsavailable、seatunavailable之类的描述就是不一致，而且难于理解的。

以上是“UML状态图创建过程中需要注意什么问题”这篇文章的所有内容，感谢各位的阅读！相信大家都有了一定的了解，希望分享的内容对大家有所帮助，如果还想学习更多知识，欢迎关注亿速云行业资讯频道！