每日一得

不求多得,只求一得 about java,hibernate,spring,design,database,Ror,ruby,快速开发
最近关心的内容:SSH,seam,flex,敏捷,TDD
本站的官方站点是:颠覆软件

  BlogJava :: 首页 :: 新随笔 :: 联系 :: 聚合  :: 管理 ::
  220 随笔 :: 9 文章 :: 421 评论 :: 0 Trackbacks

这一段时间,参加了部门组织的 RUP 教学项目,由一位“外援”架构师为我们指导教练。最近一直在忙于业务建模,今天刚刚将自己负责部分的系统用例识别了一遍。其间一直有一个问题,缠绕着包括我在内的很多同事,那就是用例之间的关系——包含、扩展、泛化——到底该如何使用。

    翻阅了同事去年参加 RUP 培训时带来的材料,终于能基本分清三者之间的关系。

 

用例是从系统外部可见的行为,是系统为某一个或几个参与者( Actor )提供的一段完整的服务。从原则上来讲,用例之间都是独立、并列的,它们之间并不存在着包含从属关系。但是为了体现一些用例之间的业务关系,提高可维护性和一致性,用例之间可以抽象出包含 (include) 、扩展 (extend) 和泛化 (generalization) 这几种关系。

在分开介绍它们之前,先说下它们的共性:都是从现有的用例中抽取出公共的那部分信息,作为一个单独的用例,然后通后过不同的方法来重用这个公共的用例,以减少模型维护的工作量。

 

1 、包含 (include)

  包含关系:使用包含 Inclusion 用例来封装一组跨越多个用例的相似动作(行为片断),以便多个基( Base )用例复用。基用例控制与包含用例的关系,以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果,但是双方都不能访问对方的属性。


 

包 含关系对典型的应用就是复用,也就是定义中说的情景。但是有时当某用例的事件流过于复杂时,为了简化用例的描述,我们也可以把某一段事件流抽象成为一个被 包含的用例;相反,用例划分太细时,也可以抽象出一个基用例,来包含这些细颗粒的用例。这种情况类似于在过程设计语言中,将程序的某一段算法封装成一个子 过程,然后再从主程序中调用这一子过程。 

    例如:业务中,总是存在着维护某某信息的功能,如果将它作为一个用例,那新建、编辑以及修改都要在用例详述中描述,过于复杂;如果分成新建用例、编辑用例和删除用例,则划分太细。这时包含关系可以用来理清关系。

 

 

 

2 扩展 (extend)

扩展关系:将基用例中一段相对独立并且可选的动作,用扩展( Extension )用例加以封装,再让它从基用例中声明的扩展点( Extension Point )上进行扩展,从而使基用例行为更简练和目标更集中。

扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性,因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

对于一个扩展用例,可以在基用例上有几个扩展点。

 

例如,系统中允许用户对查询的结果进行导出、打印。对于查询而言,能不能导出、打印查询都是一样的,导出、打印是不可见的。导入、打印和查询相对独立,而且为查询添加了新行为。因此可以采用扩展关系来描述:

 

 

用例详述里面大致可以这样来写:

执行查询

  基本流:

1. 员工选择查询功能

        员工期望查询业务数据时,选择查询链接,从而启动本用例的执行。

2. 系统转入查询页面,并显示备选的查询选项

       

3. 员工填写查询条件并提交

               

4. 系统验证查询条件的合法性

                验证条件的格式以及简单逻辑,如大小、前后、范围

5. 系统将符合条件的信息返回

        系统将查询结果以分页列表的形式显示在页面上

6. 员工退出查询功能

        员工点击退出链接,返回到上一级页面

    扩展点:导出、打印扩展点定义在步骤 5

 

导出

    该用例是在“导出、打印”扩展点上扩展了执行查询用例

    基本流:

        1 .如果员工要求导出,选择导出按钮

        。。。。。。

 

由上例可以看出 : 扩展用例的事件流往往可以也可抽象为基用例的备选流。但是在基用例本身已经是一个很复杂的情况下,选用扩展关系将备选流抽象成为单独的用例可以使基用例行为更简练和目标更集中(当然上面的例子中基用例可能简单了些)。

 

 

4 泛化 (generalization)

泛化关系:子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。

 

例如,业务中可能存在许多需要部门领导审批的事情,但是领导审批的流程是很相似的,这时可以做成泛化关系表示:

 

用例详述里面大致可以这样来写:

审批

  基本流:

7. 领导选择要审批的记录

        领导期望审批记录时,选择待审批记录链接,从而启动本用例的执行。

8. 系统转入审批页面,并显示记录的详细信息

       

9. 领导填写审批意见

                领导根据记录的合理性来填写个人审批意见

10.              提交审批结果

       

 

工资调整审批

    该用例是审批用例的子用例

    基本流:

        1 .领导选择要审批的记录

 

2. 系统转入审批页面,并显示记录的详细信息

 

3. 领导填写审批意见

 

4. 提交审批结果

                如果调整幅度较大,则要提交上级审批

 

 

上面分析了用例之间的三种关系。其中最容易让人迷惑的就是包含关系和扩展关系得区别。如果你现在对两者还有迷惑,请再仔细的对比一下上面两者的描述:)。


posted on 2006-08-29 22:23 Alex 阅读(520) 评论(1)  编辑  收藏 所属分类: 建模

评论

# re: [zt]RUP之用例间的关系 2008-01-25 10:51 Uranus
你那个Include画的有问题  回复  更多评论
  


只有注册用户登录后才能发表评论。


网站导航: