注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

何静媛 勇往直前

学无止境!

 
 
 

日志

 
 
 
 

用例图中的关系整理  

2012-11-28 10:00:03|  分类: 默认分类 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
1 、包含(include)

包含关系:使用包含(Inclusion )用例来封装一组跨越多个用例的相似动作(行为片断),以便多个基(Base )用例复用。基用例控制与包含用例的 关系,以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含用例执行的结果,但是双方都不能访问对方的属性。
包含关系对典型的应用就是复用,也就是定义中说的情景。但是有时当某用例的事件流过于复杂时,为了简化用例的描述,我们也可以把某一段事件流抽象成为一个被包含的用例;相反,用例划分太细时,也可以抽象出一个基用例,来包含这些细颗粒的用例。这种情况类似于在过程设计语言中,将程序的某一段算法封装成一个子过程,然后再从主程序中调用这一子过程。  

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

2 、扩展(extend)

扩展关系:将基用例中一段相对独立并且可选的动作,用扩展(Extension )用例加以封装,再让它从基用例中声明的扩展点(Extension Point )上进行扩展,从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性,因此它能根据基用例中扩展点的当前状态来判断是否执行自己。但是扩展用例对基用例不可见。

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

3 、泛化(generalization)

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

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

 

include与extend的区别

include 是指用例中的包含关系,通常发生在多个用例中,有可以提取出来的公共部分(就象提取公因式一样),例如 UseCaseA 中包括了 a 和 b 两个流程,而 UseCaseC 中包含了 c 和 b 两个流程。为了提高复用性,可以把 b 提取出来,形成另一个用例 UseCaseB,此时,UseCaseA include UseCaseB(表现为一条指向 UseCaseB 的虚线,箭头在 UseCaseB 侧),UseCaseC 也 include UseCaseB。因而,当有 include 关系时,被 include 的用例通常会被两个以上的其他用例 include(否则就不需要重用,也就不需要提取出来了)因为子用例被抽出,基用例并非一个完整的用例,所以include关系中的基用例必须和子用例一起使用才够完整,子用例也必然被执行。

在 include 关系中,“UseCaseA 和 UseCaseC 知道 UseCaseB 的存在,而 UseCaseB 根本不知道有 UseCaseA 和 UseCaseC);

extend 则恰好相反。假设 UseCaseA 的功能描述为“发送一条通知”,可是,发送通知的方式可能有许多种,例如通过邮件发送、通过短信发送等。在需求分析阶段,可能无法明确到底有多少种方式,在用例分析阶段,UseCaseA 需要留出扩展接口,然后把已知的发送方式作为扩展用例给出,例如 UseCaseB 是“通过短信发送”,而 UseCaseC 是“通过邮件发送”,此时,UseCaseB 和 UseCaseC extend 了 UseCaseA,表现为两根虚线,箭头指向 UseCaseA

基用例是一个完整的用例,即使没有子用例的参与,也可以完成一个完整的功能。


在 extend 关系中,UseCaseA 不知道 UseCaseB 和 UseCaseC 的存在,但 UseCaseB 和 UseCaseC 却是知道 UseCaseA 并且知道如何在 UseCaseA 中作扩展的。
另:在用例图中,有时会看到两个用例之间有依赖关系(表现为一条单向或双向的实线),这是错误的,说明用例没有提纯。


也许有人会问“如果两个用例之间,一个要调用另一个时,怎么办?”(有可能是混淆了用例和模块的关系),那么,首先要区分概念,用例就是用例,用例不是模块,也不是组件(虽然一个用例能发展成为“一个或多个”模块或组件);其次,从用例分析的角度来看,如果用例 A 确实要调用到用例 B,那么,可以进一步分析:A 是调用了 B 的所有流程呢,还是其中一部分流程?
(1)如果是调用了一部分,此时可以把 B 中的那部分流程提取出来,形成用例 C,然后 A 和 B 都 include C;
(2)如果是调用了所有流程,那么,A 直接 include B 即可;
(3)如果 A 没有调用 B 中的任何流程……faint,那还画那条代表依赖的实线干嘛?

 

  评论这张
 
阅读(834)| 评论(3)
推荐 转载

历史上的今天

在LOFTER的更多文章

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017