软件建模分析与设计 学习日志（2）用例图 Use Case

1. 用例图的基本概念

• 定义：由Actor（参与者），Use Case（用例）和其间的关系构成的用于描述系统功能的动态视图
• 主要作用：描述Actor与Use Case之间的关系，帮助开放人员可视化地了解系统的功能 （所以用例图是需求分析中的产物）
• 其他作用：系统用户，系统分析人员，系统设计人员，领域专家能够 以可视化的方式探讨问题，减少了交流障碍，便于达成共识。
• 其他作用：可视化表达系统需求，直观且规范，客服了纯文字性说明的不足。
• 其他作用:将需求和设计分离，使得系统相当于黑盒，只提供了对外访问/使用的接口，而无需知道内部具体结构。

2. 用例图的构成要素

• Actor
  定义：存在于系统外部并和系统进行交互的人/系统/子系统/类的外部实体的抽象
  每个参与者可以参与1或多个用例，每个用例可以有1/多个参与者。
  PS:Actor描述的是外部实体的抽象而非 具体对象/具体的某一人
  

• Use Case
  定义：参与者可以感受到的系统服务/单元（定义了系统如何被使用）
  用例是从系统外部描述系统功能，不关心内部如何完成（所以其用例名不包含具体实现方式）
  PS:毕竟是出于需求分析阶段所用，根本不需要具体实现方式。

  识别（绘制）用例的方法:首先分析系统参与者的交互行为/业务逻辑，期间往往会发现新的参与者。

• 用例的粒度：用例所包含的系统服务或功能单元的多少。用例粒度越大，包含功能越多，用例数目可能过少而不便充分分析问题；用例的粒度越小，包含的功能越少，用例的数目可能过多而造成用例模型过大和引入设计困难加大

• 用例规范
  对于每一个用例，有详细的描述信息，以便让别人对于整个系统有一个更加详细的了解
  具体包括：
  (1)简要说明:对用例作用和目的的简要描述。
  (2)事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行时的场景。
  (3)用例场景:同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景，也可以说用例场景就是用例的实例。
  (4)特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。
  (5)前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。
  (6)后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例

3. 用例图的关系
系统边界：系统边界是指系统与系统之间的界限
系统：一系列的相互作用的元素形成的具有特定功能的有机整体

• 关联关系
  分为无方向的（Association）和有方向的（DirectedAssociation）关联，连接参与者与用例，表达参与者对用例的使用关系。
  
• 泛化关系
  “继承”关系，
  Actor：
  1.参与者与参与者之间主要是泛化关系。
  2.某些参与者的共同行为提取出来表示成通用行为，并描述成超类
  
  Use Case
  1.用例的泛化指的是一个父用例可以被特化形成多个子用例
  2.子用例继承了父用例所有的结构、行为和关系，子用例是父用例的一种特殊形式

• 包含关系
  定义：指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。
  主要有两种情况需要用到包含关系：
  第一，多个用例用到同一段的行为，则可以把这段共同的行为单独抽 象成为一个用例，然后让其他用例来包含这一用例。
  第二，某一个用例的功能过多、事件流过于复杂时，我们也可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的。

• 扩展关系
  定义：在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例(Extension）
  方向和Include是反的，表示的是一种可能具备的功能。