UML用例图总结

UML 用例图总结

用例图（Use Case Diagram）主要用于描述“用户、需求、系统功能单元”之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。

【用途】：帮助开发团队以一种可视化的方式理解系统的功能需求。

核心元素

用例图主要包含以下核心元素：

1. 参与者 (Actor)

表示与应用程序或系统进行交互的用户、组织或外部系统。在图中通常用一个小人图标表示。

2. 用例 (Use Case)

用例是外部可见的系统功能，用于描述系统提供的服务。在图中用椭圆表示。

3. 子系统 (Subsystem)

用来展示系统的一部分功能，这部分功能通常联系紧密。

关系类型

用例图中涉及的关系主要有：关联、泛化、包含、扩展。如下表所示：

1. 关联 (Association)

表示参与者与用例之间的通信，任何一方都可发送或接受消息。

• 箭头指向：指向消息接收方。

2. 泛化 (Generalization/Inheritance)

即通常理解的继承关系。子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。

• 箭头指向：指向父用例。

3. 包含 (Include)

包含关系用来把一个较复杂用例所表示的功能分解成较小的步骤。

• 箭头指向：指向分解出来的功能用例。

4. 扩展 (Extend)

扩展关系是指用例功能的延伸，相当于为基础用例提供一个附加功能。

• 箭头指向：指向基础用例。

5. 依赖 (Dependency)

注意：以上 4 种关系是 UML 定义的标准关系。但在 Visual Studio 2010 的用例模型图中，添加了依赖关系，用带箭头的虚线表示，表示源用例依赖于目标用例。

• 箭头指向：指向被依赖项。

其他元素

1. 项目 (Artifact)

用例图虽然是用来帮助人们形象地理解功能需求，但并非所有干系人都能轻松理解。很多时候跟用户交流甚至用 Excel 都比用例图直观。VS2010 中引入了“项目”这样一个元素，以便让开发人员能够在用例图中链接一个普通文档。

使用方法：用依赖关系把某个用例依赖到项目上。

然后把「项目 -> 属性」的 Hyperlink 设置到你的文档上；这样当你在用例图上双击项目时，就会打开相关联的文档。

2. 注释 (Comment)

关系辨析

包含 (Include)、扩展 (Extend)、泛化 (Inheritance) 的主要区别如下：

• 条件性：泛化中的子用例和 Include 中的被包含的用例会无条件发生，而 Extend 中的延伸用例的发生是有条件的。
• 直接性：泛化中的子用例和 Extend 中的延伸用例为参与者提供直接服务，而 Include 中被包含的用例为参与者提供间接服务。

• 内容关系：

  • 对 Extend 而言，延伸用例并不包含基础用例的内容，基础用例也不包含延伸用例的内容。
  • 对 Inheritance 而言，子用例包含基础用例的所有内容及其和其他用例或参与者之间的关系。

示例

一个完整的用例图示例如下：

局限性与思考

尽管用例图有助于需求分析，但在实际应用中也存在一些局限性：

1. 理解门槛：用例图并不能很好地表达系统的所有需求细节，没有 UML 背景的用户几乎不知道画的是些什么。
2. 符号歧义：包含关系、扩展关系的箭头符号竟然是同样的箭头，仅靠上方写个文字来加以区别，翻译成其他语言的话，几乎就不知道代表什么意思。扩展关系的箭头朝向也很难理解，为何要指向基用例，而不指向扩展用例。
3. 工具设计：VS2010 添加的“项目”元素，是个很好的创新，能够在用例图中关联 Word、Excel 这些文档。但为什么不把这些功能直接集成到用例里面，双击用例就弹出一份文档岂不更容易理解，非要画蛇添足地加一个元件，仅仅为了提供个链接功能。

补充：用例描述表

鉴于用例图并不能清楚地表达功能需求，开发中大家通常用描述表来补充某些不易表达的用例，下图的表给大家提供一个参考：

说明：本文部分内容（如“依赖关系”、“项目/Artifact 元素”）基于 Visual Studio 2010 建模工具的特性整理，可能与标准 UML 2.x 规范或其他建模工具的实现存在差异，请结合实际使用的工具版本参考。