用例图主要用来描述用户,需求,系统功能单元之间的关系.
〇概述
用例图可使用的工具集(EA工具箱)有:
一用例图元素
1.参与者
Actor,图形表示为一个小人,参与者的版型(StereoType)有:
1)普通参与者,表示为一个小人,如图Actor1
2)业务参与者(业务工人),表示为一个小人+头上一条斜线,如图Actor2
3)其他参与者,表示为一个小人+书名号包含的具体版型,如图Actor3,4,5...
参与者的表示就是个小人,不论上面是否多了一斜线,还是多了一对书名号,仍代表参与者,他们都只是参与者的一个具体的版型.
[注1]所谓的版型(StereoType)是一种特例,不管是五香瓜子还是原味瓜子都叫瓜子.可以简单的认为,使用版型只是为了描述更具体!
[注2]加了删除线的"普通"两字实际并不存在,只是为了描述清楚,没有普通参与者的说法,就叫参与者.(下同)
[注3]其他参与者中的其他是泛指,表示除以上之外的参与者.(下同)
2.用例
Usecase,图形表示为一个带有实线边框的椭圆,用例的版型(StereoType)有:
1)普通用例,表示为一个椭圆,如图UseCase1
2)测试用例,表示为一个椭圆+叉号,如图TestCase1
3)业务用例,表示为一个椭圆+一条斜线,如图UseCase2
4)其它用例,表示为一个椭圆+书名号包含的具体版型,如图UseCase3
[注4]注意用例与业务用例的区别,用例是系统用例的简称.另外,业务用例的范围一般大于用例(系统用例).
3.协作(也称用例实现)
Collaboration,图形表示为一个带有虚线线边框的椭圆,协作的版型(StereoType)有:
1)普通协作,表示为一个虚线边框的椭圆,如图Collaboration1
2)业务协作,表示为一个虚线边框的椭圆+一条斜线,如图Collaboration2
[注5]UML2.x已经取消协作图,定义为通信图(CommunicationDiagram),但仍保留协作.
4.边界(子系统)
Boundary,图形表示为一个空心矩形,边界没有其它版型(StereoType)
[注6]如果在用例图上看到如虚线边框的空心矩形或其他线形,均指边界,和实线空心矩形没有区别.
5关系
Relationships,图形表示为一条线(实线或虚线)[+单向或双向的空心或实心箭头],关系的种类有:
1)关联,association,表示为一条实线[+单向或双向开口箭头],如图客户和订单直接属于关联关系
2)包含,include,表示为一条虚线+单向的开口箭头+书名号包含的include字样,如图订单和付款属于包含关系(订单包含付款,付款被订单包含)
3)扩展,extern,表示为一条虚线+单向的开口箭头+书名号包含的extern字样,如图订单和请求商品目录属于扩展关系(请求商品目录是订单的扩展)
4)泛化,generalization,表示为一条实线+单向空心箭头,如图使用现金支付是付款的实现
[注7]泛化不是实现(inheritance),泛化是指继承;实现是类图中的元素,实现的父类必须是接口.
5)依赖,dependency,表示为一条虚线+单向或双向空心箭头
如图,使用信用卡支付依赖Pos机.
[注8]在关系上,使用信用卡支付依赖Pos机是没有问题的,但是Pos机显然不能作为一个用例而存在(用例必须以动宾形式存在),因此,使用依赖和其它关系时需谨慎.
6)其它,如invoke,trace...同类图中描述,同样存在以上注意事项,不推荐.
[注9]UML手册中除了关联,包含,扩展和泛化关系,不存在其它关系的介绍,dependency,invoke,trace...这些在某些建模工具中存在(如EA,VisualStudio).
6.包
Package,图形表示为一个文件夹,包的版型(StereoType)有:
1)普通包,表示为一个文件夹,如图Package1和Package4
2)其它包,表示为一个文件夹+书名号包含的具体版型或特殊符号,如图Package2和Package3
[注10]用例图上的包一般引用自包图,包图内部的画法,参见包图部分.
7.Artifact(制品/物件/项目翻译不明属于UML2.x图形的一种)
Artifact,图形表示为一个实心矩形,Artifact的版型(StereoType)有:
1)普通Artifact,表示为一个实心矩形+Icon,如图Artifact1
2)其它Artifact,表示为一个实心矩形+Icon+书名号包含的具体版型,如图UserStory1
[注11]Artifact的画法和Artifact图一致,参见Artifact图部分.
Artifact是软件开发过程中的产物,包括过程模型(比如用例图,设计图等等),源代码,可执行程序,设计文档,测试报告,需求原型,用户手册等等.
二用例图关系
1.关联
执行者与用例之间的通信路径.
2.包含
一个用例可以简单地包含其他用例具有的行为,并把它所包含的用例行为作为自身行为的片段,这种关系称为包含关系.
被包含的用例不是原用例的特化,并不能替代原用例.
包含关系指向被包含的用例.
3.扩展
一个用例可以被定义为基用例的增量扩展,这叫做扩展关系.
同一个基用例的几个扩展用例,可以在一起应用.
基用例的扩展增加了基用例的语义,实例化时是实例化基用例而不是扩展用例.
扩展关系指向被扩展的用例.
4.泛化
一个用例可以被特别细化为一个或多个子用例,这被称作用例泛化.
任何子用例都可以用于其父用例能够应用的场合.
用例泛化和其他泛化的表示法相同,用一个三角箭头从子用例指向父用例.
三执行者和用例
1.执行者
执行者是与系统,子系统或类发生交互作用的外部用户,进程或其他系统的理想化角色.
[注12]协作是用例的实现
四用例图总结
1.用例图主要是用于描述需求的
2.用例图包含的元素中,只有参与者,用例,协作,边界和关系属于特有的,包和Artifact的画法直接使用对应的包图和Artifact图画法
3.用例是指系统用例,业务用例的范围一般大于系统用例
4.用例的几个特性
1)用例是相对独立的,不需要与其它用例交互而独自完成参与者的目的.
2)用例必须由一个参与者发起,不存在没有参与者的用例,用例也不应该自己启动.
3)用例不是功能也不是特性，用例不能被逐层分解为更小的用例,用例的价值在于展现系统最终能帮用户做什么以及如何做到的.
4)用例必须以动宾形式描述,如前文描述的"使用信用卡付款"是合法的用例,"Pos机"是非法用例.
5)用例不是需求的唯一定义形式,需要用例和其他定义形式一起定义完整的需求.
5.用例的划分粒度没有标准,一般是以该用例是否完成了参与者的目的为依据
五UML通用元素
参见UML参考手册中的特性描述部分,如一些注释元素,不单只能画到用例图中,而是通用的可以画到任何UML图形上的.