本节接着向大家介绍一下UML状态图方面的内容,希望通过本节学习,你对UML状态图的基础知识有一定的认识,下面让我们继续来看一下UML状态图的详细介绍吧。
创新互联建站是一家专业提供柳林企业网站建设,专注与网站设计制作、做网站、H5建站、小程序制作等业务。10年已为柳林众多企业、政府机构等服务。创新互联专业网站制作公司优惠进行中。
为复杂的实体创建一个分层的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状态图介绍到这里。
标题名称:UML状态图创建过程中需要注意问题
URL链接:http://www.36103.cn/qtweb/news46/26296.html
网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等
声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联