UML用例图

用例视图

用例视图：从外部用户的角度捕获系统子系统或类的行为，它将系统功能划分为对活动者系统的理想用户，具有意义的事务这些功能片被称为用例。用例通过系统与一个或多个活动者之间的一系列消息描述了与活动者的交互术语，活动者包括人员，其它的计算机系统和进程图。

下面举两个例子：

一、用例关系的种类

1. 关联关系：参与者与用例之间的关系。

2. 包含关系: include(不可分)

由用例A连向用例B，表示用例A包含用例B中的行为或功能。比如ATM系统中，提款、转账和查询余额三个用例，可将“确认用户”的新用例加入到系统中。

当几个用例具有相同的行为时，这个共同行为可以抽象为了一个公共用例。

（1） 如果有多个用例，并且这些用例包含大量的类似的行为，应该考虑将这些类似的行为通过包含关系包含到用例中；

（2） 对两个或多个互相独立的用例建模里做了重复的工作，可以通过包含关系包含这些重复的操作；

（3） 如果某个行为可能会引起冗余，或者当行为发生变化时可能导致不一致性，这时，应该对这种行为进行孤立建模并将它包含到用例中。

3. 扩展关系: extend

由用例A连向用例B，表示用例B描述了一项基本要求，而且用例A则描述了该基本要求的特殊情况，即扩展。

4. 泛化关系：

是一种特殊的扩展关系。父用例与子用例之间的关系，类似于类图中的父类与子类的关系。如用例：支付与用例：现金支付的关系。

二、对参与者与用例的识别

参与者一般包括系统用户、其它系统和可运行的进程。

1. 识别参与者

(1) 需要借助于系统完成日常工作的人中谁

(2) 谁来维护管理系统次要角色，保证系统正常工作

(3) 系统控制的硬件设备有哪些

(4) 系统需要与哪些其它系统交互？其它系统（包括计算机系统，也包括该系统）将要使用的计算机中的其它应用软件，其它系统也分成二类一类是启动该系统的系统另一类是该系统要使用的系统

(5) 对系统产生的结果感兴趣的人或事是哪些

2． 识别用例

(1) 角色需要从系统中获得哪种功能？角色需要做什么？

(2) 角色需要读取、产生删除、修改或存储系统中的某种信息吗？

(3) 系统中发生的事件需要通知角色吗？或者角色需要通知系统某件事吗？这些事件功能能干些什么？

(4) 如果用系统的新功能处理角色的日常工作，是简单化了，还是提高了工作效率？

(5) 还有一些与当前角色可能无关的问题也能帮助建模者发现用例。例如系统需要的输入/输出是什么信息？这些输入/输出信息从哪儿来到哪儿去？

(6) 系统当前的这种实现方法要解决的问题是什么？也许是用自动系统代替手工操作