综述
用例图(use case diagram)是指由参与者(Actor)、用例(Use Case)以及它们之间的关系构成的用于描述系统功能的视图。主要用来描述“用户、需求、系统功能单元”之间的关系。用例图定义了系统的功能需求,它是从系统的外部看系统功能,并不描述系统内部对功能的具体实现。用例图多用于静态建模阶段(主要是业务建模和需求建模),帮助开发团队以一种可视化的方式理解系统的功能需求。
构成
用例图由参与者(Actor)、用例(Use Case)、系统边界、箭头组成,用画图的方法来完成。
参与者
参与者(Actor)是指系统以外,使用系统或与系统直接交互的角色。需要注意以下两点:
1.参与者不是特指人,它可以是人,可以是事物,也可以是时间或其他系统等等。
2.参与者不是特指人或事物本身,而是表示人或事物当时所扮演的角色。例如一个图书管理员,他参与图书管理系统的交互,它既可以作为管理员参与图书的管理,也可以作为借书者从图书馆借书。因此,在这里他扮演了两个角色,是两个不同的参与者。
在UML图中,参与者用简笔人物画来表示,人物下面附上参与者名称即可
用例
用例是对包括变量在内的一组动作序列的描述,系统执行这些动作,并产生传递特定参与者的价值的可观察结果。我们可以这样简单地理解,用例是参与者想要系统做的事情。对于对用例的命名,我们可以给用例取一个简单、描述性的名称,一般为带有动作性的词。用例在画图中用椭圆来表示,椭圆下面附上用例的名称用例图定义了系统的功能需求,它是从系统的外部看系统功能,并不描述系统内部对功能的具体实现。
系统边界
系统边界是用来表示正在建模系统的边界。边界内表示系统的组成部分,边界外表示系统外部。系统边界在画图中用方框来表示,同时附上系统的名称,参与者画在边界的外面,用例画在边界里面。因为系统边界的作用有时候不是很明显,所以我个人理解,在画图时可省略
箭头
箭头用来表示参与者和系统通过相互发送信号或消息进行交互的关联关系。箭头尾部用来表示启动交互的一方,箭头头部用来表示被启动的一方,其中用例总是要由参与者来启动。
关系(Relationship)
用例图中包含的元素除了系统边界、角色和用例,另外就是关系。关系包括用例之间的关系,角色之间的关系,用例和角色之间的关系。
角色之间的关系
泛化关系(Inheritance)的含义是把某些角色的共同行为提取出来表示为通用的行为。由于角色实质上也是类,所以它拥有与类相同的关系描述,即角色之间存在泛化关系是一般和特殊关系,就是通常理解的继承关系。
箭头指向(需要特别注意)父角色。
用例之间的关系
包含关系(Include):基本用例的行为包含了另一个用例的行为,基本用例描述在多个用例中都有的公共行为。包含关系本质上是比较特殊的依赖关系。它比一般的依赖关系多了一些语义。简单来说,包含关系用来把一个较复杂用例所表示功能分解成较小的步骤。包含用例是必须的,如果缺少包含用例,基用例就不完整;包含用例必须被执行。
箭头指向:指向分解出来的功能用例。
泛化关系(Inheritance):代表一般与特殊的关系。它的意思和面向对象程序设计中的继承的概念是类似的。不同的是继承使用在实施阶段,泛化使用在分析、设计阶段。在泛化关系中子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以增加新的行为和含义或者覆盖父用例中的行为和含义。父用例通常是抽象的。
箭头指向(特别注意)父用例
扩展关系(Extend)是指用例功能的延伸,相当于为基础用例提供一个附加功能。扩展关系的基本含义和泛化关系类似,但在扩展关系中,对于扩展用例有更多的规则限制,基本用例必须声明扩展点,而扩展用例只能在扩展点上增加新的行为和含义。与包含关系一样,扩展关系也是依赖关系的版型。扩展用例是可选的,如果缺少扩展用例,不会影响到基用例的完整性。
箭头指向(需要特别注意):指向基用例
角色与用例之间的关系
关联关系(Association)表示参与者与用例之间的交互,通信途径,任何一方都可发送或接受消息。
箭头指向:指向消息接收方。
用例之间关系的举例
包含:业务中,总是存在着维护某某信息的功能,如果将它作为一个用例,那新建、编辑以及修改都要在用例详述中描述,过于复杂;如果分成新建用例、编辑用例和删除用例,则划分太细。这时包含关系可以用来理清关系。
扩展:系统中允许用户对查询的结果进行导出、打印。对于查询而言,能不能导出、打印查询都是一样的,导出、打印是不可见的。导出、打印和查询相对独立,而且为查询添加了新行为。
泛化:子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。
完整的用例图示例
作用
用例图主要的作用有三个:(1)获取需求;(2)指导测试;(3)还可在整个过程中的其它工作流起到指导作用。