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

《SysML精粹》学习记录

• 第五章：用例图（Use Case Diagram）
• • 用例图简介
  • 用例图外框
  • 小结

---

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

用例图简介

展示元素及其相互关系的各种图形化表示方法（如类图、对象图等）均能够清晰地传达系统提供的服务信息及与之相关的利益相关者的信息。这些图形不仅能够直观地描述系统的功能模块及其交互关系，并且能够明确地标识出驱动其执行的各种操作者及其作用机制。这种基于黑盒模型的视图工具是一种常用的分析工具，在软件开发过程中通常会将其作为重要的辅助设计手段之一。通过这种图形化的方式能够有效地帮助设计人员快速识别系统的功能边界、操作流程及各子系统的协作关系等关键信息。

根据《统一建模语言参考手册(第二版)》（The Unified Modeling Language Reference Mannal, second edition）中 James Rumbaugh、Ivar Jacobson 和 Grady Booch 的定义可知：用例被定义为"一系列特定的动作序列（包括变种动作序列及错误动作序列），这些动作能够在外部对象与系统的交互过程中由目标实体（如系统、子系统或类）所执行并提供相应的值的服务"。在列举具体用例时应当注意以下几点：

• 用例名称：代表（提供）该用例的实体
• 范围：由（负责）该用例的所有实体构成
• 主执行者：触发者：负责启动该用例的主要主体
• 支持（次要）执行者：辅助执行者：为系统提供支持的服务实体
• 利益相关者：相关利益方：与系统功能直接相关的各方主体
• 预置条件：前置条件：实现该用例所需的前提要素
• 保证（后置条件）：
  • 结果条件1: 须在用例完成时满足的第一层次目标
  • 结果条件2: 须在用例完成时满足的第二层次目标

• 触發器：
  • 触发源1: 引发该用例初始激活的原因因素
  • 触發源2: 激发该类特定流程的根本驱动因素
• 主要成功场景：
  • 正常运行场景1: 未出现任何错误的情况序列
  • 正常运行场景2: 系统各环节协同运转的结果序列
• 扩展（可置换分支）：
  • 可替代路径1: 在正常运行路径中分出的一系列替代步骤序列
  • 可替代路径2: 根据特殊需求可能采用的不同操作流程序列
• 相关信息：
  • 项目所需信息库中的具体内容项列表

在使用SysML活动图创建用例说明书时需要注意以下几点：第一，在描述用例的主要成功场景时要格外谨慎——这指的是那些能够顺利执行的操作序列。第二，在详细描述其他可能的异常路径时也要确保准确无误——这些路径应该清晰地标识为异常操作序列或者错误状态转移过程。建议团队成员先以文字形式记录下这些描述（按照上面所示的模板），然后再利用建模工具将其可视化地呈现出来。这样既能保证描述的完整性与准确性，又能在后续开发过程中提供清晰的技术参考依据。当一个用例仅包含一个主要成功场景时，则处于适当的粒度级别上；而其他可能存在的异常路径则应明确标注为错误或异常序列

用例图外框

该术语用于表示UC类别的用例图。该外框可能代表以下几种类型之一：包、模型、模型库或视图。由于存在多种组织方式的不同选择，因此不同类型的组织结构可能会导致同一图表在头部区域与内容区域中的展示有所差异。下图为用例图示例：

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

• 不允许在执行者与用例间建立复合型联系
• 规定了任何两个执行者之间不应存在任何形式的联系
• 禁止任何两个用例间产生任何形式的联系

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

小结

作为黑盒视图的一种表现形式, 用例图所展示的是系统提供的各项服务, 并且能够体现那些在被触发后主动参与执行过程的参与者. 它通常呈现给利益相关者作为其生命周期早期阶段所需的系统视图, 并能够展示参与者之间的泛化关联以及与各个用例之间的联系. 建模者可以通过在每个用例中展示其内部关联性以及扩展性来实现重构技术的应用——该技术旨在实现对多个高层次服务拥有的一般性行为进行重构.