状态图的建模指南
发布网友
发布时间：2022-05-12 17:59
共1个回答
热心网友
时间：2023-10-16 19:57
和图1中每一个子状态都拥有一个cancelled变换不同，在图2中你可以看到cancelled变换仅用于描述Enrollment超状态，这使图形得到简化。 如果子状态都共享一个入口变换或出口变换，都可以使用一个同样的方法。 变换上的警戒点和动作（如果有）也应该使相等的。
为复杂的实体创建一个分层的状态图
虽然这种表现子状态的方法是很好使的，但是最终的图可能变得相当复杂－－我们只要设想一下如果Being Taught状态也有子状态的话，图2会变成什么样就知道了。 一个替代的方法是创建一个分层的UML状态图。 例如，图3表示高阶视图，而图1描述了一个细节视图。这种方法的好处是如果需要的话，马上就可以建立一张详图来研究Being Taught状态。
最高阶的状态图总有初始态和最终态
一个高阶的UML状态图，例如图2描述的这样，应该表示实体的完整的生命周期，包括出生和最后的死亡。 低阶的图未必包含初始状态和最终状态，特别是那些建模一个实体的生命周期的中间状态的图。 变换是从一种状态到另一种状态的序列，它可能是通过一个事件触发的。简而言之就是被建模的实体的内部或外部的行为。 对一个类来说，变换一般是将会导致状态的重要改变的操作调用的结果，因此我们需要了解一点，并不是所有的方法调用都会导致变换产生的，这一点非常重要。 一个动作就是某个东西，对类来说就是一个操作，被建模的实体所调用的操作。
用实现语言的命名规则命名软件动作
图1中的动作遵循Java操作的命名规则( Vermeulen et. 2000)，因为系统使用
用叙述性文字命名角色动作
UML状态图可用于建模非软件实体的生命周期，特别是UML图上的角色。 例如学生角色就可能有诸如Accepted、Full Time、Part Time、Graated、Masters、Doctoral、和Post - Doctoral等状态，以显示各人的不同行为。 当你在建模现实世界的角色时，与软件中Student类不同的是，状态间的变换最好是使用叙述性文字来描述，例如drop seminar和pay fees，而不是dropSeminar ()和payFees ()，因为现实生活中的人是做事情，而不是执行操作。
只有对所有的入口变换都合适时才注明入口动作
在图1中你可以看到Closed To Enrollment状态的入口中操作notifyInstructor ()都是经由entry/动作标记来调用的。 这暗示着每次进入状态时都需要调用该操作，如果你不希望每次都发生，那么就把动作关联到特定的入口变换。 例如，addStudent ()动作是在student enrolled变换到Open For Enrollment变换发生，而在到opened变换则不会发生，这是因为每次你在进入该状态并不需要增加一个学生。
只有对所有的出口变换适合时才注明出口动作
出口动作，用exit/标记来表示，工作方式类似于入口动作。
只有当你想终止并再进入该状态时才建模递归变换
一个递归的变换是那些两个端点都拥有相同状态的变换。 一个重要的暗示是实体从状态出来，又回到原有的状态，因此，那些由于entry/或exit/动作标记而被调用的任何一种操作都可能被自动调用。 图1的Open For Enrollment状态就是这种递归变换的例子，因此当前班级大小就在入口处被记录下来。
用过去式命名转换事件
图1中的转换事件，例如seminar split和cancelled，是使用过去式命名的，反映了这样一个事实：变换是事件的结果－－因为事件发生在变换之前，因此应该用过去式命名。
把转换标记放在接近源状态的地方
虽然图1比较复杂，变换标记尽可能放在靠近来源的地方，例如seminar split和student enrolled。 Furthermore, the labels were justified (left and right respECtively) to help visually place them close to the source state.
以转换方向为基础放??为了更易于判断哪个标记和变换是一起的，按照如下的规则来放置变换标记：
在变换线条上的从左到右。
在变换线条下的从右到左。
变换线条右边的往下。
变换线条左边的往上。
警戒点 一个警戒点是为了穿过一个转换而必须为真的一个条件。
警戒点不应该重叠
离开状态的相似变换上的警戒点必须彼此一致。 举例来说，x <0, x = 0,以及x > 0的警戒点是一致的，而x < = 0和x > = 0的警戒点就不是一致的，因为他们重叠了，它并没有明确的指出当x为0时将发生什么。在图1中，你可以看到警界点的一致性，从填写注册表活动出发的该学生划线变换上的警戒点没有重叠，决策点上的警戒点也一样。
为可视化的定位警戒点而引入接合点。
在图2中你可以看到从Being Taught触发student dropped事件存在两个变换，而图3中仅有一个，变换被合并了，因此我们需要一个接合点（填满的圆）。 这种方法的好处是现在图上的两个警戒点更彼此接近了，更容易看出警戒点是否重叠。
警戒点不必配套
一个状态的变换警戒点有可能是不完整的。例如，一个bank account对象可能从Open状态变换到Needs Authorization状态，这时需要一个大额存款large deposit的警戒点。可是，一个带有small deposit的警戒点的deposit变换可能并不需要建模，它是被隐含的，我们遵循了AM的实践－－简单的描述模型和仅仅包括相关的信息。
一致的命名警戒点
图1包含了诸如seat avAIlable和no seat available的警戒点，两个警戒点的描述是一致的。 然而，诸如seats left、no seat left、no seats left、no seats available、seat unavailable之类的描述就是不一致，而且难于理解的。 来源：LinuxAid
