[UML建模]用例图（Use Case Diagram）

1、软件开发过程

（1）分析：是为了说明系统是什么（what），也就是搞清楚我们要开发一个什么样的系统，并说明这个系统会做哪些事。
（2）设计：是为了说明系统如何工作（how），也就是说明系统应该如何一步一步地做到在分析阶段所承诺的事情。
（3）实现：就是按照系统设计，真正地开始编写程序代码了。

用例发生在系统分析阶段。

2、用例图

2.1 什么是用例图？

用例图是外部用户（参与者）所能观察到的系统功能的模型图。是指由参与者、用例，边界以及它们之间的关系构成的用于描述系统功能的视图。

2.2 用例图包括哪些元素？

（1）参与者
（2）用例
（3）系统边界

2.3 如何寻找要素？

2.3.1 找参与者？

参与者是位于系统外部的用户、联网的其他系统、硬件设备或者数据库，它们并不是系统的一部分，所以开发团队不需要构建这些参与者。

如何寻找参与者？以下可供参考
1、谁来使用这个系统？
2、谁来安装这个系统？
3、谁来启动这个系统？
4、谁来维护这个系统？
5、谁来关闭这个系统？
6、哪些系统使用这个系统？
7、谁会从这个系统获取信息？
8、谁会给这个系统提供信息？
9、在预先设定的时间到达时，有什么事情会自动发生吗？
10、哪些系统会与这个系统联网？
11、是否有硬件设备会与这个系统联网？
12、哪些数据库会与这个系统联网？
13、公司内部有哪些人员会使用这个系统？
14、公司外部有哪些人会使用这个系统？
15、当特定的时间或事件发生时，这个系统需要自动通知什么人，或者是自动通知其他系统吗？

2.3.2 找用例

“用例是系统的一项行为，它能够生成参与者可评价的结果。”隐含两个重点：
（1）用例是系统的行为，所以它将包含事件的概念，它会花费一段时间，具有一个执行过程。因此，当系统分析师描述用例时，要特别注意它所经历的一连串操作，而且这一连串操作，正是参与者与系统之间的互动。
（2）用例不仅能够，同时也必须，生成可以供参与者评价的服务或结果。也就是说，用例执行结束时，必须有一项明确的结果，并且参与者要能够接受这项结果。

如何寻找用例？
1、参与者想要从这个系统获得什么样的功能？
2、这个系统存储信息吗？哪些参与者将建立、读取、更细或删除这些信息？
3、当系统内部状态有变化时，这个系统需要通知参加者吗？
4、是否有什么外部事件是这个系统需要知道的？当这些外部事件发生时，哪些参与者会通知这个系统呢？
5、这个系统需要定期执行什么操作呢？
6、当发生了某些重要的外部事件时，这个系统需要自动执行什么操作呢？
7、这个用例的名称够明确吗？是否能够从这个用例的名称，直接判断出它的结果呢？
8、这个用例会有许多不同结果吗？还是这些结果，其实是在不同的时间点产生的？

参与者的特性？
1、参与者位于系统外部，它不属于系统的某一部分，所以我们不需要去构建参与者。
2、只有会使用系统、会跟系统互动、会跟系统交换信息的，才是系统的参与者。
3、参与者会启动、参与用例，所以找到参与者，就可以引导我们找到用例。
4、我们虽然不需要构建参与者，但是却需要考虑接口。系统需要提供接口让参与者使用，或者系统需要用到参与者提供的接口。

2.3.3 确立系统边界

确立系统边界就是先划定一个系统范围，晚点再来推敲系统范围内该做的细节。
对于系统分析主要是以下两个方面：
（1）找出位于系统外部的事物，画小人。
（2）找出系统内部的事物，画椭圆。
“确立系统边界”是句很抽象的话，而具体的做法就是：分内外，向系统内找用例，向系统外找参与者。

2.4 如何绘制用例图？

2.4.1 用例

用例采用椭圆形园标，它的名称可放置于椭圆内部或者外部下方，通常用来表示系统对外提供的服务和功能。

2.4.1.1 UML 2.0用例相关的指南？

第58条指南 以“强动词”作为用例名称的开头。
第59条指南 使用领域术语作为用例名称。
第60条指南 以用例的对方顺序“暗示”发生时间。

2.4.2 参与者

参与者（actor）是指位于系统外部的对象，它会在参与用例执行期间，与系统发生交换信息的互动。一般的人类用户、公司组织、联网的信息系统或者联网的硬件设备，都是极为常见的参与者。

2.4.2.1 UML 2.0参与者相关的指南？

第61条指南 把主要参与者放置于图标的左上角。
第62条指南 将参与者放置于用例图的边框外。
第63条指南 用单数的、领域相关的名称来为参与者命名。
第64条指南 每个参与者关联到一个或多个用例。
第65条指南 以角色命名参与者，不以职务头衔命名。
第66条指南 使用<>表示系统参与者。
第67条指南 不允许参与者之间有互动。
第68条指南 用“时间”参与者表示预定事件。

2.4.3 用例之间的关系

2.4.3.1 UML 2.0用例关系相关的指南？

第69条指南 如果参与者出现在用例中，则可以在参与者与用例之间放置关联。
第70条指南 在参与者与用例之间的关联中，避免出现箭头。
第71条指南 用例“一定”会启动，适用于包含关系。
第72条指南 用例“可能”会启动，适用扩展关系。
第73条指南 谨慎地使用扩展关系。
第74条指南 描述相似业务逻辑时，适用泛化关系。
第75条指南 不要使用<>、<>或<>。
第76条指南 用例之间的包含关系或扩展关系，避免达到两层以上。
第77条指南 把被包含用例放置于基础用例的右方。
第78条指南 把扩展用例放置于基础用例的下方。
第79条指南 应用“就像是”规则来判断用例之间的泛化关系。
第80条指南 把子用例放置于父用例的下方。
第81条指南 应用“就像是”规则来判断参与者之间的泛化关系。
第82条指南 把子参与者放置于父参与者的下方。
第83条指南 避免使用扩展点。
第84条指南 只有在不够清楚的情况下，才使用扩展条件。

2.4.3.2 包含关系

如果常剪贴某段相同的用例叙述，就意味着叙述内容中有一部分的流程是可以重用的，这时候就可以将可重用的这段文字叙述独立出来，放置到另一个新的用例叙述中。原用例与拆分出来的用例就是包含关系。

包含要素的要点表
（1）需要共享的相同流程，才能够独立出来。
（2）暂存数据或者存取数据库的操作，不要轻易独立出来。
（3）如果只是一两句相同的流程叙述，不需要大费周章地独立出来。

2.4.3.3 扩展关系

不同于包含关系的无条件，扩展关系是有条件的执行，要在特定条件成立时，才能够执行额外扩展的用例。既然称之为“扩展”，意味着它是在不影响原始用例的情况下，额外加入的行为。也因此，扩展关系通常出现在系统改版需要扩展旧版功能，或者系统定制化需要扩展原有功能的情况下。

扩展关系要点表
（1）谨慎地使用扩展关系，避免因为滥用扩展关系，而让用例图变得很难理解。
（2）扩展关系通常用于系统上线之后的改版，可以在不变动已经写好的用例叙述的情况下，利用扩展关系，加上一段新的用例叙述，以满足新的需求。
（3）不一定会执行的流程，可以放置在替代流程中，要是想要跟其他用例共享这段流程的话，也可以改用扩展关系。

2.4.3.4 泛化关系

在用例图中，两个参与者之间可以存在泛化关系，而且两个用例之间也可以存在泛化关系。一般所谓的“继承关系”，在UML中则称为“泛化关系”，它的图标是一端带有大三角形的实现，从特殊化元素连接指向一般化元素。

2.4.4 系统范围

2.4.4.1 UML 2.0系统范围相关的指南？

第85条指南 在系统范围方框内指出发布范围。
第86条指南 避免无意义的系统范围方框。

2.5 替代流程

替代流程问题表
（1）在这个流程步骤中，是否还有其他期待的操作？
（2）在这个流程步骤中，是否会发生什么样的错误？
（3）在整个用例执行过程中，是否随时可能发生其他未记录在叙述中的操作？
（4）参与者输入数据时，是否会提供不完整的数据，需要重新补上的数据？
（5）是否会出现错误的数据，需要特别处理的？
（6）参与者是否会在操作期间，临时中断流程？
（7）参与者是否会在用例执行期间，随时取消交互？
（8）参与者是否会想要挑选其他执行方法？
（9）参与者在流程执行过程中，会不会有需要协助的地方？
（10）系统发生宕机时，是否需要特殊的处置？
（11）系统响应时间过长时，是否需要特殊的响应方法？

2.6 撰写用例描述需要避免的错误

（1）花费一个月的时间，只是为了决定该采用包含关系还是扩展关系。
（2）没有将焦点放置于用例内部，而是关注其他事情，例如如何达到这一点（前置条件）或是之后会发生什么事情（后置条件）之类的事情。
（3）遗漏了替代流程。
（4）仅描述用户交互的情况，却忽略了系统的响应。
（5）不以用户的角度撰写用例叙述，而且还是用被动语态。
（6）避免给外界对象明确的称呼。
（7）强迫自己在撰写用例叙述时，完全脱离用户界面。
（8）编写用例叙述过于简洁。
（9）描述属性与方法，而不是描述是用情况。
（10）编写功能性需求，而不是编写使用情况说明。

内容参考自《系统分析师UML用例实战》