用例图的泛化、扩展和包含
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
⽤例图的泛化、扩展和包含
在画⽤例图的时候,理清⽤例之间的关系是重点。
⽤例的关系有泛化(generalization)、扩展(extend)和包含(include)。
其中include和extend 最易混淆。
下⾯我们结合实例彻底理清三者的关系。
基本概念
⽤例图(Use Case Diagram):⽤例图显⽰谁是相关的⽤户,⽤户希望系统提供什么服务(⽤例),以及⽤例之间的关系图。
⽤例图主要的作⽤是获取需求、指导测试。
⽤例图的4个基本组件:参与者(Actor)、⽤例(Use Case)、关系(Relationship)和系统。
泛化(generalization):泛化关系是⼀种继承关系,⼦⽤例将继承基⽤例的所有⾏为,关系和通信关系,也就是说在任何使⽤基⽤例的地⽅都可以⽤⼦⽤例来代替。
泛化关系在⽤例图中使⽤空⼼的箭头表⽰,箭头⽅向从⼦⽤例指向基⽤例。
扩展(extend): extend关系是对基⽤例的扩展,基⽤例是⼀个完整的⽤例,即使没有⼦⽤例的参与,也可以完成⼀个完整的功能。
extend的基⽤例中将存在⼀个扩展点,只有当扩展点被激活时,⼦⽤例才会被执⾏。
extend关系在⽤例图中使⽤带箭头的虚线表⽰(在线上标注<<extend>>),箭头从⼦⽤例指向基⽤例。
包含(include): include为包含关系,当两个或多个⽤例中共⽤⼀组相同的动作,这时可以将这组相同的动作抽出来作为⼀个独⽴的⼦⽤例,供多个基⽤例所共享。
因为⼦⽤例被抽出,基⽤例并⾮⼀个完整的⽤例,所以include关系中的基⽤例必须和⼦⽤例⼀起使⽤才够完整,⼦⽤例也必然被执⾏。
include关系在⽤例图中使⽤带箭头的虚线表⽰(在线上标注<<include>>),箭头从基⽤例指向⼦⽤例。
实例需求场景
联通客户响应OSS。
系统有故障单、业务开通、资源核查、割接、业务重保、⽹络品质性能等功能模块。
现在我们抽出部分需求做为例⼦讲解。
需求1:客户响应⽤户和国际客服可以进⾏割接通知查询,在页⾯上有⾻⼲割接查询、省间割接查询、省级割接查询的Tab。
分析:可以很容易看出割接查询和不同的割接⼦查询Tab之间是继承的关系,所以此处⽤泛化。
⽤户和客户响应、国际客服也是继承的Actor 关系。
需求2:客户响应⽤户和国际客服可以查看某条割接通知信息,可以在页⾯上导出割接信息Excel格式,可以查询和该条割接相关联的故障单信息。
分析:因为导出割接和查看相关联的故障单信息都是可选的,就是说我查看割接的时候,也可以不进⾏这些操作,所以这⾥⽤extend关系。
也就是导出割接和查看故障单信息扩展了查看割接信息。
需求3:客户响应⽤户可以以⽹管系统为来源创建割接通知,在创建割接通知时可以保存为草稿,也可以直接发布割接通知。
分析:由于创建割接通知时,发布割接通知可以同时进⾏,也可以先存为草稿,所以发布割接是可选的,⽤extend就⽐较合适。
也就是发布割接扩展了创建割接通知。
需求4:⽤户在进⾏业务开通、发布割接通知、发布重保通知及相关跨省的业务时需要进⾏数据分发。
分析:由于业务开通、重保、割接及其它跨省的业务都需要⽤到数据分发⽤例,我们可以将数据分发⽤例单独抽出来,供各业务使⽤,这⾥⽤include就⽐较合适。
实际的系统中数据分发也是单独抽出来⽤jms和webservice实现的接⼝服务。
其它需求:可以看到删除割接通知和查看割接明细也可以做为割接通知查询⽤例的扩展,因查询列表时,⼀般可以选择继续查看明细或者删除操作。
但在实际化图中,这两个extend可以不画,这⾥只是为了让⼤家理解概念。
⽤例图:⼤家可以参照着图,好好理解。
加深理解
我们再⽤另外⼀个场景的⽤例说明⼀下include和extend,因为就这两个玩意⽐较容易搞混。
销户:因为销户必需先进⾏账户结算,所以这⾥⽤include
停机提醒:有两个可选项,短信提醒和邮件提醒,所以⽤extend.
经过以上的分析,相信⼤家对三种关系已经有⽐较好的理解了。
⼤家有什么其它想法或好的见解,欢迎拍砖。
PS:以上⽤例图⽤Enterprise Architect 7.5所画,在此推荐⼀下EA,⾮常不错。
可以替代Visio和Rose了。
Visio功能不够强⼤,Rose太重。
唯有EA⽐较合适。