原文链接：https://blog.csdn.net/mj_ww/article/details/53020080
1. 如何识别用例
任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。
可以通过以下问题来寻找用例：
(1)参与者希望系统提供什么功能？
(2)参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果是的话，参与者又是如何完成这些操作的？
(3)参与者是否会将外部的某些事件通知给系统？
(4)系统中发生的事件是否通知参与者？
(5)是否存在影响系统的外部事件。
2.用例的粒度
用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。
如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。
如果用例数目过多会造成用例模型过大和引入设计困难大大提高。 如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。
3.用例规约
对于每一个用例，我们还需要有详细的描述信息，以便让别人对于整个系统有一个更加详细的了解，这些信息包含在用例规约之中。
每一个用例的用例规约都应该包含以下内容：
(1)简要说明:对用例作用和目的的简要描述。
(2)事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。
(3)用例场景:同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景，也可以说用例场景就是用例的实例。
(4)特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。
(5)前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。
(6)后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。
用例间关系：
1、包含include
包含关系指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。在UML中，包含关系是通过带箭头的虚线段加<>字样来表示，箭头由基础用例(Base)指向被包含用例(Inclusion)。在处理包含关系时，具体的做法就是把几个用例的公共部分单独的抽象出来成为一个新的用例。主要有两种情况需要用到包含关系：
第一，多个用例用到同一段的行为，则可以把这段共同的行为单独抽 象成为一个用例，然后让其他用例来包含这一用例。
第二，某一个用例的功能过多、事件流过于复杂时，我们也可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的。
2、扩展extend
在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例(Extension)，原有的用例叫做基础用例(Base)，从扩展用例到基础用例的关系就是扩展关系。
一个基础用例可以拥有一个或者多个扩展用例，这些扩展用例可以一起使用。
3、泛化（继承）
用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。
在用例的泛化关系中，子用例继承了父用例所有的结构、行为和关系，子用例是父用例的一种特殊形式。
子用例还可以添加、覆盖、改变继承的行为。在UML中，用例的泛化关系通过一个三角箭头从子用例指向父用例来表示。
