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

开发 架构
UML建模语言有很多值得学习的地方,这里就像大家介绍一下UML状态图,相信通过本文图例讲解大家能够很快掌握UML状态图的相关知识,欢迎大家一起来学习。

本节接着向大家介绍一下UML状态图方面的内容,希望通过本节学习,你对UML状态图的基础知识有一定的认识,下面让我们继续来看一下UML状态图的详细介绍吧。

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

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

图⒊Seminar的高阶状态图。

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

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

  变换和动作

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

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

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

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

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

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

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

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

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

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

  用过去式命名转换事件

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

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

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

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

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

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

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

  变换线条右边的往下。

  变换线条左边的往上。

  警戒点

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

  警戒点不应该重叠

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

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

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

  警戒点不必配套

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

  一致的命名警戒点

  图1包含了诸如seatavailable和noseatavailable的警戒点,两个警戒点的描述是一致的。然而,诸如seatsleft、noseatleft、noseatsleft、noseatsavailable、seatunavailable之类的描述就是不一致,而且难于理解的。本节关于UML建模风格之UML状态图介绍到这里。

【编辑推荐】

  1. UML建模风格中UML状态图表现形式
  2. 在回归测试中UML状态图切片的应用 
  3. UML用例图用法实例剖析
  4. 术语汇编 UML统一建模语言简介
  5. 技术分享 嵌入式建模中UML状态图的形式化方法
责任编辑:佚名 来源: csdn.net
相关推荐

2010-07-12 13:00:49

UML建模

2010-06-10 17:02:40

UML建模

2013-09-03 13:01:01

团队管理团队

2010-07-06 11:21:37

UML状态图

2021-12-08 23:32:42

云计算云迁移数据

2009-12-17 10:14:04

UML建模

2010-07-09 16:30:31

UML状态图

2009-04-23 14:30:19

UML建模

2010-07-06 16:19:56

UML图形

2010-07-06 12:00:23

UML活动图

2010-06-09 14:31:31

UML状态图

2010-06-13 15:03:25

UML实践

2009-06-10 15:36:25

ubuntu netb开发过程

2010-06-10 13:14:48

UML状态图

2010-07-09 11:01:30

UML动态建模

2010-07-15 14:47:05

Perl开发

2010-07-05 12:21:36

UML行为图

2010-06-09 14:21:05

UML状态图

2010-06-09 15:19:20

UML状态图

2010-07-09 17:21:32

UML状态图
点赞
收藏

51CTO技术栈公众号