UML-用例图

定义

用参与者（Actor）、用例（UserCase）以及他们的关系共同组成的用于描述参与者角度上的系统功能的静态视图。

功能&组成

用于描述某一个角色所拥有的系统功能。即某一类参与者可见的功能。用例图是客户和需求人员沟通的桥梁和工具。用例图把系统当做一个黑盒，它重点在于表现软件要"做什么"，而不是"怎么做"。

用例图有如下几个要素：

• Actor：参与者，可以是用户、其他系统、某个事件，甚至是时间
• Case：用例，表示系统的功能
• Relationship：Actor与Actory直接的关系以及Case与Case间的关系
• 流（Flow）：暂时不用理会这个东西

图例

下面我来列举一些用例图中的可视化元素。

用户（Actor）

UML用这样的图标表示参与者。

用例（Case）

这个萌萌的椭圆形表示系统提供给参与者的功能。

关系（Relationship）

正如我前面所言，用例图是由参与者（Actor）、用例（Case）和他们之介的关系（Relationship）组成。这其中"关系"由可分为如下几种：

关联（Association）

参与者与用例间的关系，表示参与者与这个用例间有关联（使用这个功能）。

上图表示"超级管理员"这个参与者和"学生信息管理"这个功能之间的联系。其中箭头指向消息的接收者，上图中，"超级管理员"是消息发送者，"学生信息管理系统"接受消息并做出处理后的响应。

包含

用例间的关系，A包含B，B属于A。箭头指向被包含的一端。

上图表示"会员管理"用例包含两个子用例："人员管理"和"权限管理"。

扩展

用例间的关系。表示一个用例是另一个用例的扩展。但是使用这个扩展是有条件的。

上图表示用例"人员管理"拥有一个扩展的用例——"打印全体成员"（有打印机才能打，所以是有条件的、可选的）。

泛化

用例图中的泛化关系包括两种：用例与用例之间的关系以及参与者与参与者之间的关系。我们可以把泛化关系理解为"继承"，即：子元素继承父元素的行为、特征，但是子元素在某些方面表现出了更多与众不同的特性。箭头源于子级元素，指向父级元素。

上图表示：

平台用户"继承了"用户"的行为和权限。

"支付"用例有两种具体的支付策略"网银"，"支付宝"。他们都具有支付功能，但是具体实现却有不同。

注释

说明性的文字，此处不谈。

一个典型的用例图

上图表示

1. "管理员"和"平台用户"都继承自"用户"，管理员拥有系统的全部权限，而平台用户只能访问购买服务及其子用例。
2. "网银支付"和"支付宝支付"继承自"支付"。二者都是用来支付，但各自又有所不同。
3. "打印全体成员"是"人员管理"用例的一个扩展用例。它是可选的。
4. 其他一些包含、关联关系非常明了，此处不做多余解释了。

   总结

其实在UML用例图中，还包括如下上文未提及的元素：

• 项目。表示一个系统的边界。如果一张用例只表现了一个系统，则可以省略。
• 依赖。Viso中的特性，暂时不用顾及。

上面的介绍和最后的图例如果有什么不妥之处，请留言，在线秒回。