波仔
🧩 第八章 UML：查看无形软件的工具
📄 一句话概括

用例图只回答谁、让系统做什么——实测 2 个参与者、6 个用例、2 条包含＋1 条扩展，它一个字都不说【怎么做】。

📝 本节和前面几节的关系

8.10 说 UML 能表示非 OOP 信息，这一节起逐个介绍第三类图：用例、活动、状态机。

一、用例图的两个词：参与者与用例

参与者：站在系统外面、跟系统打交道的人或其他系统，画成小人（或方块）。 用例：系统提供的、对参与者有价值的一件事，画成椭圆。 边界：一个方框圈住所有用例，框外面是人，框里面是系统。

二、实测：2 个参与者、6 个用例

读者：借书、还书、查书——3 个用例。 管理员：办证、催缴、盘点——3 个用例。 每个用例都绑了参与者，0 处说不清【谁做】。

三、包含与扩展的区别

包含（include）：每次都会走的那一段，抽出来共用——借书与还书都包含【验证身份】。 扩展（extend）：有条件才走的那一段——借书【扩展】出预约，只有无库存时才走。 记法：包含是必须，扩展是可选；箭头都从子指向基，虚线加构造型。

四、它不写怎么做

借书是先查库存还是先验证身份，用例图一个字都不说——那属于活动图或时序图。 所以用例图适合跟业务方对齐【做什么】，跟程序员对齐【怎么做】要换图。 最常见的滥用：把用例图画成流程图，那已经不是用例图了。

五、动手 Demo：使用用例图表示交给计算机的工作

列一个图书馆系统的参与者与用例，按参与者分组计数。 再数包含关系与扩展关系各有几条。

actors = ["读者", "管理员"]
cases = [("借书", "读者"), ("还书", "读者"), ("查书", "读者"),
         ("办证", "管理员"), ("催缴", "管理员"), ("盘点", "管理员")]
rel = [("借书", "验证身份", "包含"), ("还书", "算逾期", "包含"),
       ("借书", "预约", "扩展")]

print(len(actors), len(cases),
      len([r for r in rel if r[2] == "包含"]),
      len([r for r in rel if r[2] == "扩展"]))   # 2 6 2 1

实跑输出：

--------------------------------------------------------------------
使用用例图表示交给计算机的工作
--------------------------------------------------------------------

  用例图只回答一件事：**谁，让系统做什么。**实测一个图书馆系统：

  参与者     用例数     用例
  ---------------------------------------
  读者       3          借书／还书／查书
  管理员     3          办证／催缴／盘点

      参与者                      2 个
      用例                        6 个
      包含关系                    2 条
      扩展关系                    1 条
      用例里有几处【谁做】说不清   0 处（每个用例都绑了参与者）

  **用例图的边界是【系统的边界】**：图外面的是人，图里面的是系统要做的事。
  **它不写怎么做**——借书是先查库存还是先验证，用例图一个字都不说。
  **所以它适合跟业务方对齐【做什么】，不适合跟程序员对齐【怎么做】。**

实测：2 个参与者、6 个用例、2 条包含、1 条扩展。 每个用例只有一个参与者——说不清谁用的用例，通常是【系统内部功能】而不是用例。 用例图不写顺序，借书里先做什么后做什么，它一个字都不管。

30 秒实验

  1. 给你的系统列出参与者和用例，检查每个用例是否都能说出【谁用】。
  2. 找一个被画成流程图的用例图，指出它混进了哪些不属于这里的信息。

常见误区

  1. 把用例图画成流程图。顺序属于活动图，用例图只管谁做什么。
  2. 以为用例越多越完整。用例是【有价值的一件事】，不是功能清单。
自测三问（点开对答案） 1. 用例图回答什么？ —— 谁（参与者），让系统做什么（用例）——不谈实现与顺序。 2. 包含与扩展怎么分？ —— 包含是每次都会走的那段（抽出来共用），扩展是有条件才走的那段。 3. 实测数字是多少？ —— 2 个参与者、6 个用例、2 条包含、1 条扩展，0 处说不清谁做。

相关笔记