Unified Model Language 之 用例图

来源:互联网 发布:海淘用哪个软件 编辑:程序博客网 时间:2024/03/29 01:28

前言

  UML九种图的理解非常重要,每种图的关键要素我们抓住之后,操作起来如鱼得水。下面小编对于用例图的理解进行下面的总结。


一、宏观角度

1.用途

主要用来描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。

帮助用开发团队以一种可视化的方式理解系统的功能需求,表现如下:

(1)获取需求;

(2)指导测试;

(3)还可在整个过程中的其他工作流中起到指导作用。

2.地位

在UML系统开发中有三个主要的模型:用例图是其中功能模型中的图。

还有对象模型:采用对象、属性、操作和关联等概念展示系统的结构和基础,包括类图,对象图和包图。

动态模型:展现系统的内部行为,包括序列图、协作图、活动图和状态图。


二、具体认识

1.包含的元素



参与者(Actor)——不是特指人,是指系统以外的,在使用系统或系统交互中所扮演的角色。

用例(Use Case)——是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果。

子系统(subsystem)——用来展示系统的一部分功能,他们之间的联系紧密。如下图所示:



关系——用例图中涉及到的关系有:关联、泛化、包含、扩展。



项目(artifact)——用例图虽然是用来帮助人们形象地理解功能需求,但却没多少人能够通看懂它。很多时候跟用户交流甚至用Excel都比用例图强,VS2010中引入了“项目”这样一个元素,以便让开发人员能够在用例图中链接一个普通文档。  

用依赖关系把某个用例依赖到项目上:



注释(comment)



   


      


2.元素之间的关系

>>角色之间的关系:

泛化关系

由于角色实质上也是类,所以它拥有与类相同的关系描述,即角色之间存在泛化关系,泛化关系的含义是把某些角色的共同行为提取出来表示为通用的行为。



>>用例之间的关系:

包含关系

基本用例的行为包含了另一个用例的行为。基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。在包含关系中箭头的方向是从基本用例到包含用例。



扩展关系

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

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

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

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




泛化关系

子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。

子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。

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



3.用例的泛化、包含、扩展关系的比较。

一般来说可以使用“is a”和“has a”来判断使用那种关系。

泛化和扩展关系表示用例之间是“is a”关系,包含关系表示用例之间是“has a”关系。扩展与泛化相比多了扩展点,扩展用例只能在基本用例的扩展点上进行扩展。 



结语

  每一个阶段,每一具体的图,需要我们不断地去了解和加深印象。用例图的总结大概这些,更多内容,站在巨人的肩膀上,发现得更多。

0 0
原创粉丝点击