《SysML精粹》学习记录--第五章

---

第五章：用例图（Use Case Diagram）

用例图简介

  用例图可以显示各种类型的元素和关系，以说明系统提供的服务信息，以及需要服务的利益相关者的信息。用例图会简洁地传递一系列用例：系统提供的外部可见服务——以及触发和参与用例的执行者。用例图是系统的一种黑盒视图，很适合作为系统的情境图。用例图是一种分析工具，一般会在系统生命周期的早期创建。系统分析师可能会枚举各种用例，然后在系统概念和操作（ConOps）的开发阶段创建用例图。在某些方法中，分析师会在系统生命周期的需求引出和指定阶段，以基于文本的功能性需求方式创建用例。之后，系统架构师会分析系统级别的用例，以导出和分配子系统，并在架构设计阶段创建组件级别的用例。
  在《统一建fe语言参考手册(第二版)》（The Unified Modeling Language Reference Mannal, second edition）中，James Rumbaugh、Ivar Jacobson 和 Grady Booch 把用例定义为“特定的一系列动作，包括变种系列动作和错误系列动作，系统、子系统或 者类可以通过与外部对象交互来执行，以提供值的服务。”在列举系统用例的时候需要注意：
  1）用例是系统将会执行的一种服务 种行为。因此用例名称总会是一个动词短语。
  2）系统所执行的所有行为并非都是用例。用例只是系统行为的子集，是外部执行者能够直接触发或者参与的那些行为。
  3）执行者可以是一个人或者一个外部系统，执行者和系统之间存在接口。
  4）触发用例的执行者叫做主执行者。参与到用例中的执行者叫做次执行者。主执行者也可以是次执行者。
  5）每个用例都应该代表主执行者的目的。要从执行者的角度而不是系统的角度来为用例起名字（对应的动词短语）。例如，如果卫星的飞行控制器需要发送命令，那么用例的名称应该是发送命令而不是接收命令。
  6）用例名称不会传达大量信息。要为每个用例创建用例说明书，以讲述系统和其执行者会如何协作来达成用例目标。
  用例说明书会传达主执行者触发用例的时候发生的情况。用例说明书在传统上是 文字文档。Alistair Cockburn在他的书籍《编写有效用例》中提供了一种很好的用例说明书格式：

• 用例名称：一个动词短语
• 范围：拥有（提供)用例的实体（例如，组织、系统、子系统或者组件的名称）
• 主执行者：触发用例的执行者（用例会代表该执行者的目标）
• 支持（次要）执行者：为系统提供服务的执行者（通过执行动作参与到用例中）
• 利益相关者：和系统行为之间有既定利益关系的某人或某物
• 预置条件：必须满足才能让用例开始的条件
• 保证（后置条件）：在用例结束的时候必须为真的条件
• 触发器：让用例开始的事件
• 主要成功场景：没有出现任何错误的场景（一系列步骤）
• 扩展（可置换分支）：可置换的系列步骤，它们从主要成功场景分支出来
• 相关信息：项目为了得到额外信息而需要的内容

  也可以使用SysML活动图创建图形化的用例说明书。活动图要比传统文字形式的用例说明书更简洁、更清晰。因此，很多建模者会犯这样的错误，在头脑构思用例描述的时候就使用建模工具创建活动图。这种实践会阻碍创造力。建模者需要首先关注描述；撰写好文字描述，清晰、正确地表述执行者在执行用例的时候，会如何与系统交互。一旦开始创建活动图，就会花费大量时间和精力在活动图的布局上，那会让建模者无法专心进行清晰、正确的说明。建议团队中的设计师首先以文字形式记录描述（使用上面显示的模板），和利益相关者一起精炼那些描述。然后再使用建模工具在活动图上以可视化的方式来表达那些描述。当用例只拥有一个主要成功场景的时候，它就处在了合适的粒度级别上。所有通过用例说明书表达的其他执行路径都应该是错误或者异常序列。
  场景：通过用例执行的每个路径，从开始到结束是一个独立的场景。用例至少会包含一个或多个场景。用例至少会包含一个主要成功场景——正常的执行路径。通常用例还会包含额外的场景，代表错误和异常的序列，那些都是主要成功场景的分支。一幅SysML序列图很适合用图形化的方式表示单独的场景。

用例图外框

  用例图的类别缩写是uc。图的外框代表的模型元素类型可能是以下中的一种：包、模型、模型库、视图。模型有很多种组织方式，而模型的组织形式一般会影响图在头部和内容部分显示内容。下图为用例图示例：

  用例图的标识法是一个椭圆形。可以显示用例的名称——一般是一个动词短语——或者在椭圆中，或者在下方（把名称放在椭圆中更常见一些）。和模块一样，用例可以泛化，也可以特殊化，这意味着可以创建并显示从一个用例到另一个用例的泛化关系。泛化在此的意义和它在模块部分的意义相同：继承。 正如在第三章中所提到的，可以把这种关系读作“……是一种……”。泛化的标识法也和第三章中一样：在泛化元素（超类型）末尾带有空心三角形箭头的实线。特殊化元素（子类型）会出现在线的尾端。
  系统边界（也叫做主题）代表拥有并执行图中用例的系统。系统边界的标识法是围绕用例的矩形框（不要和图的外框混淆）。主题的名称——显示在矩形的顶部—— 必须是一个名词短语。在系统概念和操作（ConOps）开发过程中，系统边界的名称应是建模者正在设计的系统的名称。在那个阶段，建模者的目标是把系统显示为一个黑盒，并指定它会为环境中的执行者提供的服务。稍后，在架构设计过程中，建模者会从结构上把系统分解为子系统和组件。在那个阶段，建模者会为每个子系统，最终为每个组件创建新的用例图。当建模者这样做的时候，系统边界的名称会是建模者在描述的子系统或者组件的名称。（如果那时候仍然叫做“系统”边界会让建模者感到困扰，那么建模者可以把它叫做“主题”。）
  执行者有两种标识法：火柴棍小人，或者是名称前面带有 <<actor>>关键字的矩形。建模者约定俗成，一般会使用火柴棍小人代表人，矩形标识法代表系统。和BDD—样，建模者可以在用例图中显示执行者之间的泛化关系。如果超类型（类似于面向对象中的父类）和一个用例有关联，那么子类型也会继承那种关联，并能够访问那个 用例。
  可以在执行者和用例之间创建关联，从而表示执行者与系统交互，以触发和参与到用例中。需要注意的是：

• 不能在执行者和用例之间创建复合的关联
• 不能在两个执行者之间创建（任意类型）关联
• 不能在两个用例之间创建（任意类型）关联

  基础用例是通过关联关系与主执行者连接在一起的任意用例，即基础用例代表的是主执行者的目标。内含用例是任意一种用例，它是内含关系的目标——也就是位于箭头端的元素。内含关系的标识法是带有箭头的虚线，在旁边会有关键字<<include>>。尽管内含关系的标识法和依赖关系非常类似，但内含关系并不是一种依赖；依赖关系的“客户端一提供方”语义在此并不适用。内含关系表示的是，当源端——关系的尾端——的用例被触发时，目标端的内含用例也会执行。内含用例行为是源端用例所需要的组成部分。但是内含关系并没有传达内含行为在源用例中何处执行——开始、中间还是结朿（只知道它执行了）。为了确定内含用例在序列中的何处发生，看图者可能需要查看与源用例相关的文字描述、活动图或者序列图。建模者只能从一个用例到另一个用例使用内含关系。它一般是从基础用——与主执行者关联的用例——向内含用例绘制的。只有在建模者想要表示一些常见的行为，而那些行为又是从多个基础用例中提取出来的时候，才应该创建内含案例。注意：永远不要在主执行者和内含用例之间创建关联关系。
  扩展用例是任意一种用例，它是扩展关系的源——位于尾端的元素。扩展关系的标识法是带有箭头的虚线，附近带有关键字<<extend>>。和内含关系一样，扩展关系并不是一种依赖。扩展关系要传达的是，当目标端的用例位于关系的箭头端被触发时，源端的扩展用例可能被选择性地执行。这意味着扩展关系目标端的用例自动完成。建模者可以在扩展关系旁边的注释中指定触发条件，但更加推荐在为目标用例创建的活动图中指定触发条件。建模者还可以指定扩展点，在那里扩展用例会在目标用例的行为中生成分支。扩展点会在目标用例的分隔框中命名。

小结

  用例图是一种黑盒视图，它代表的是系统所提供的服务，以及需要那些服务并在触发之后参与到执行过程中的执行者。用例图通常作为系统情境图——利益相关者在生命周期早期期望看到的系统视图。用例图可以显示执行者之间以及用例之间的泛化关系。建模者还可以在用例之中显示内含关系和扩展关系——用于重构多个高层次服务 拥有的通用行为的技术。