UML学习笔记（五）【用例图】

基本概念：

用例图（Use Case Diagram）:用例图显示谁是相关的用户，用户希望系统提供什么服务（用例），以及用例之间的关系图。用例图主要的作用是获取需求、指导测试。

基本组件：参与者(Actor)、用例(Use Case)、关系(Relationship)和系统。

关系(Relationship)：为了体现一些用例之间的业务关系，提高可维护性和一致性，用例之间可以抽象出包含(include)、扩展(extend)和泛化(generalization)几种关系。

共性：都是从现有的用例中抽取出公共的那部分信息，作为一个单独的用例，然后通后过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

包含(include)：就是为了共性，具体语言方法体现在，抽出一个公有的方法，它存在于别的用例体内一起用，本身不完整，或者说它是业务片段。本人觉得也可以为了将来好灵活使用该片段业务或开发维护，可以抽出来。

扩展(extend)：本身是一个完整的业务，但在流程上，是从基用例上触发出来的。文字形式的用例描述可以很好的体现扩展，如流程走到A的时候，基用例是B，（可以扩展下）不同的情况下或者基础上添点其他功能业务，可以是B1、B2。（B1、B2扩展用例，独立且可选）

泛化(generalization)：继承

方向：对于刚才的几种关系的图形方向箭头，我们先谈依赖关系，一段虚线的箭头，箭头指向被依赖的对象。以上关系，都遵循依赖关系，比如包含关系，基用例依赖它所包含的用例，箭头指向包含用例。扩展用例依赖基用例，它由基用例触发出来的，箭头指向基用例。泛化，儿子是父亲生出来的，儿子依赖父亲，箭头指向父亲。

几者的区别

●泛化侧重表示子用例间的互斥性；它必定发生，如审批泛化出工资调整审批、请假审批。

●包含侧重表示提供间接性的服务；它必定发生，如发送邮件包含在修改密码中，又包含在其他通知业务中。

《UML精粹》下的用例：

用例是捕获系统功能需求的技能。用例描述了系统用户和系统本身的典型交互，提供了系统如何被使用的说明。

场景（scenario）：用户和系统之间交互的步骤序列。

目标，用例的关键，用例通过共同用户目标绑在一起的场景集合。

我们为了目标，挑选出一个场景，作为主成功场景，把其他场景作为扩展。而扩展的场景，需要一个条件触发。他们保证会完成某个目标。同时，某个复杂的步骤可以抽出来变为一个用例，该用例包含于它的母用例中。

用例的一些公共信息：

前置条件（pre-condition）：用例开始之前，确保为真的东西。该用例本身不会去检查该条件，调用者检查。

触发器（trigger）：触发用例开始的事件

保证（guarantee）：用例结束时，系统会确保的东西。成功场景结束后得到成功保证；任何场景结束后都会得到最小保证。

用例的级别；

风筝级别（kite-level）：业务用例。

海平面级别（sea-level）：核心用例，对主执行者有价值的东西，通常花几分钟到半小时完成。（系统用例）

鱼级别（fish-level）：包含于海平面级别。（系统用例）

特性与用例：

特性可能是整个用例、用例中的场景、用例中的步骤或一些变体。

推荐：使用文本形式表达用例，表达系统的外部视图，不要期望和系统类之间的关联，上面有些关联了，只是为了便于理解反过来说明的。

如：

用例名
用例级别

主成功场景：
1
2
3

扩展
2a：当某某情况的时候
     1。。。
     2。。。
3a：当某某情况的时候
     1。。。
     2。。。

参考资料：

用例图《UML精粹：标准对象建模语言建模指南（第3版）》Martin Fowler

用例图_百度百科 http://baike.baidu.com/view/1281729.htm

博客园 UML用例图博客 http://www.cnblogs.com/panjun-Donet/archive/2008/10/20/1315030.html