扫码获取 VIP 码
添加管理员微信获取 VIP 码
在正式展开之前，必须先给用例图一个精准、可应试的定义。用例图是统一建模语言中用于刻画系统外部可见行为的一种静态结构图，它从系统使用者的视角出发，描述系统应当提供哪些功能、这些功能由谁触发、以及功能之间如何组织复用。在面向对象分析与设计的语境里，用例图承担的是功能需求捕获的第一道关口：它不回答"系统内部如何实现"，只回答"系统对外能够做什么、谁能做、谁被允许做"。
从教材与标准文档的术语体系看，用例图由四个核心要素构成。第一是参与者，它是系统之外与系统发生交互的任何事物，可以是使用系统的人、外部的硬件设备、上游的软件系统，甚至时间本身。第二是用例，它是系统提供给参与者的一段可观测、有价值的功能序列，通常以动宾短语命名。第三是系统边界，它用一个矩形框把系统内部与外部隔开，参与者站在框外，用例位于框内，这条界线画错，整张图的语义就塌了。第四是关系，它连接参与者与用例、用例与用例，包括关联、包含、扩展与泛化四种，后三者正是软考反复命题、考生反复失分的关键。
用例图并不是唯一能表达功能需求的图，但它是唯一纯粹站在"黑盒"立场上看系统的图。类图描述系统内部静态结构，顺序图描述对象消息交互的时序，状态图描述单个对象的状态迁移，而用例图始终把系统当作不透明的整体，只关心边界之外的交互。这决定了它在需求阶段不可替代的地位，也决定了命题人总会围绕"参与者站在哪里""关系属于谁"做文章。
参与者是软考关于用例图的最常见命题点之一，绝大多数考生的错误都源于一个先入为主的误解：以为参与者就是使用系统的人。这个理解是片面的。参与者的标准定义是"系统外部与系统交互的一切事物"，其外延远大于"人类用户"。一个定时触发的批处理任务，参与者是时钟；一个调用当前系统接口的第三方支付平台，参与者是那个外部系统；一个采集温度数据并上报的传感器，参与者是那台硬件设备。凡是与系统交换信息、又不属于系统本身的实体，都可以被建模为参与者。
软考真题对此的考查方式非常稳定。历年反复出现的一道题表述为"关于用例图中的参与者，说法正确的是哪一个"，四个选项通常是：参与者都是由人来承担；当系统需要定时触发时，时钟就是一个参与者；参与者可以在系统外部也可能在系统内部；系统某项特定功能只能有一个参与者。正确答案几乎毫无例外落在"时钟是参与者"一项。这道题经典，是因为它同时考察三个边界判断：参与者是否限定为人、是否必须位于系统外部、与用例是否一一对应。三个结论分别是：参与者不限于人；一定位于系统外部；一个用例可由多个参与者触发，一个参与者也可触发多个用例。
还要补充一个容易被忽略的细节：参与者是角色，而非具体个人。系统不会为"张三"和"李四"分别建模两个参与者，而是抽象出"顾客""管理员"等角色。同一个人在不同场景下可能扮演不同角色，从而对应多个参与者。这种"角色抽象"是理解泛化关系的前提，后文会展开。
与参与者并列，用例自身的定义同样暗藏考点。一个用例不是系统的任意一个功能点，而是一段"完整、可观测、对参与者有价值"的交互序列。判断一段流程是否构成独立用例，标准是它能否独立地为某个参与者交付一次完整的价值。用户登录中的"输入用户名""输入密码"不是独立的用例，因为它们合在一起才构成一次有价值的"登录"；而"登录""查询余额""转账"各自都是独立用例，因为每个都能单独为参与者带来一份可感知的结果。
这个"价值完整性"原则直接解释了为什么软考会考察用例的粒度划分。一个用例应当用动词短语命名，且命名本身要能体现参与者的目标，而不是体现系统的内部动作。"保存数据到数据库"是系统内部实现，不应作为用例出现；"管理客户信息"才是参与者视角的功能。命题人有时会故意把系统内部实现描述成用例，考察考生能否识别出用例图的"黑盒"属性，这类陷阱在后文常见误区一节会专门拆解。
理解了概念之后，必须追问一个更底层的问题：在面向对象分析与设计的方法体系中，为什么偏偏是用例图被推到了功能需求建模的最前台？答案藏在需求工程的本质矛盾里——需求方不会用开发者的语言描述诉求，开发者又常常过早地陷入技术实现细节，二者之间缺少一个双方都能看懂的中间契约。用例图恰好充当这个契约：它用参与者和用例两个朴素概念，把"谁想用系统做什么"翻译成一张连非技术人员都能读懂的图。
从方法论源流看，用例图与用例驱动开发的思想密不可分。统一过程把软件开发组织为一系列以用例为牵引的迭代，每一个迭代都围绕若干关键用例展开，从用例出发去发现对象、分配职责、设计交互。这意味着用例图不只是需求阶段的一张静态产物，它是一条贯穿分析、设计、实现与测试的线索：分析阶段从用例细化出领域模型，设计阶段从用例推导出协作与类职责，测试阶段又回到用例编写验收场景。软考命题人之所以让用例图在系统分析师与软件设计师两个级别反复出现，正是因为它处在需求与设计的交汇点上，牵一发而动全身。
把一段文字需求转化为一张合格的用例图，背后有一套可以固化的机制。第一步是识别参与者：找出所有与系统交互的外部实体，包括人类角色、外部系统、硬件设备与时间触发器。第二步是枚举用例：围绕每个参与者，追问它想借助系统完成什么目标，每个目标对应一个用例。第三步是绘制边界与关联：画出系统边界框，把用例放进框内，用关联关系把参与者与它触发的用例连起来。第四步是提炼复用与扩展：当多个用例共享一段公共行为时，抽取出包含关系；当某个用例在特定条件下才会追加一段可选行为时，引入扩展关系；当多个参与者或用例存在"一般—特殊"结构时，引入泛化关系。
这套机制的价值在于，它把用例图的绘制从"凭感觉画"变成"按步骤走"，每一步都有明确的判断标准。软考的下午案例分析题和上午选择题，本质上考察的都是考生能否熟练执行这四步，尤其是第四步中三种关系的判定。判定包含、扩展、泛化三种关系的关键，不在于背口诀，而在于抓住它们各自背后的语义驱动力，这正是下一节要展开的核心。
理解用例图的定位，还需要把它放进完整的UML图体系里做横向比较。UML的图分为结构图与行为图两大类，用例图属于结构图，因为它刻画的是参与者、用例及关系构成的静态拓扑，而非随时间演化的动态过程。与它同属结构图的还有类图、对象图、组件图、部署图、包图等；属于行为图的则有顺序图、通信图、状态图、活动图等。软考曾直接考查这个分类，例如要求判断"用例图、类图、对象图和通信图"与"顺序图、活动图、状态图和通信图"哪个组合才是正确的结构图与行为图划分。
这道分类题背后的逻辑是：用例图虽然描述"交互"，但它描述的是"谁能调用什么功能"的静态授权关系，而非"某个时刻发生了什么"的动态时序，所以被归入结构图。考生若只死记"用例图描述交互"，就容易翻车——描述交互不等于行为建模，用例图描述的是交互的静态结构。这个细微区分，是命题人区分"真懂"与"假懂"的经典手段。
用例图中的关系是整套知识点的核心，也是软考每年必考、每年必有人栽的地方。用例图涉及的关系共四种：关联关系、包含关系、扩展关系与泛化关系。关联关系是参与者与用例之间的连线，语义最简单，表示"该参与者触发或参与该用例"；后三者都发生在用例与用例之间，或者参与者与参与者之间，语义复杂得多，是命题的重灾区。下面逐个拆解。
包含关系用一条从基本用例指向被包含用例的虚线箭头表示，箭头旁标注关键词。它表达的语义是：基本用例的执行必然触发被包含用例，被包含用例是基本用例不可缺少的组成部分。被包含用例通常是一段被多个用例共同复用的公共行为，比如"检查权限"可能被"课程学习""课程考试""查看成绩"等多个用例共同调用，于是把"检查权限"抽取为独立用例，让所有需要它的用例通过包含关系引用它。包含关系的本质是功能复用与强制依赖：基本用例发生，被包含用例就必然发生。
扩展关系同样用虚线箭头表示，但箭头方向与包含关系相反，它从扩展用例指向基本用例，箭头旁标注扩展条件。它表达的语义是：在满足某个特定条件时，扩展用例才会被插入到基本用例的某个扩展点上执行。与包含关系的"必然发生"截然相反，扩展关系的核心是"条件触发、可选发生"。例如"补缴学费"是"课程学习"的扩展用例：只有当学习者所缴学费不足这个条件成立时，它才会被触发，正常学习流程不会每次都走到补缴。扩展关系的本质是可选增强与条件追加：它不改变基本用例的主干，只在特定情形下附加一段行为。
泛化关系用一条从子用例指向父用例的实线加空心三角箭头表示，与类图中的泛化记号一致。它表达的语义是：子用例是父用例的一种特殊化，子用例继承父用例的行为，同时又可以有自己的差异。"电话注册"与"网络注册"都是"课程注册"的泛化，它们各自
本篇完！