学《软件方法》最痛的不是概念记不住而是给你一段真实的业务描述你画出来的图跟答案差好几层。我最近又把第二章的自测题翻出来做了一遍其中“门诊自助”和“鼠鸭识别”这两个场景一共凑成8道题顺手就把它们拆开聊了聊。这套题好就好在两个场景特别反着来一个是业务链条完整、牵一发动全身的门诊系统另一个是看起来就一个功能的图像识别应用。正好能讲清楚第二章里那些最容易混淆的考点也适合正在啃书、准备应付建模作业的同学做个对照练习。我先把结论放在前面这两道题如果只背概念一道都答不扎实。它们考察的全是同一件事——你能不能分清“业务建模”和“系统建模”的层次能不能把“需求”落到“为谁解决什么问题”上。下面我按第二章的主流知识线结合这两个场景把考点拆开讲再讲解题套路和容易踩的坑。1. 先搞懂《软件方法》第2章到底在考什么1.1 需求、业务用例和系统用例是一条线第2章的核心不是教你怎么画图而是让你建立一条完整的分析链从一个组织的业务出发找到真正的问题再推导出系统应该干什么。很多人一上来就画用例图画出来的却是“假用例”原因就是跳过了业务层。这条链一般长这样识别涉众谁为这件事出钱、谁干活、谁受益、谁可能被影响。定义业务用例从业务执行者的视角看这个组织为顾客提供了什么价值。梳理业务流程用活动图或序列图把业务步骤画清楚。提取系统用例把业务流程中适合由新系统自动化的部分挑出来。编写用例规约把系统用例的交互路径、前置条件、异常路径写清楚。分析建模用分析类图和序列图表达系统内部的结构与协作。第2章的自测题通常不会只考某一环而是把整条链串起来考。门诊自助的例子偏向业务链的完整梳理鼠鸭识别的例子偏向单一功能的系统和用户价值确认正好形成互补。1.2 两个场景是两种极端考点完全不同我拿表格对比一下这两个场景的建模特征这样你做题时能更快判断出题人想考你什么。对比维度门诊自助鼠鸭识别业务复杂度高牵涉挂号、缴费、检查、取药等多环节低核心动作就是“传图片、出结果”涉众数量多患者、医生、收费员、信息科都沾边少主要看使用者是巡检员、管理人员还是算法人员用例粒度需要从业务流程中一层层抽容易把系统内部能力误当用例典型陷阱把系统用例画进业务用例图把“识别”当成用例名称却说不清价值门诊自助最典型的问题是边界太大画着画着就把整个医院的业务都装进去了鼠鸭识别最典型的问题是边界太小画着画着只剩一个算法调用。这两类坑恰好覆盖了大多数建模初学者的弱点。1.3 8道题最常见的考点布局我不能代替原卷还原题目原文但按第二章的标准知识结构和这两个场景的类型8道题大概率是按这个布局走的门诊自助场景的涉众识别与目标分析。门诊自助场景中业务用例图与系统用例图的边界判断。门诊自助系统中某个用例的规约补全或改错。门诊自助场景的模型一致性判断业务流程与用例是否对应。鼠鸭识别场景的执行者识别与用例名称判断。鼠鸭识别场景的功能与用例辨析。鼠鸭识别场景的用例规约编写。鼠鸭识别场景的分析建模类图或序列图判断。这8道题的共同突破口只有一个先搞清楚“谁在用这个功能要达到什么目的”再谈怎么画怎么写。下面我分场景展开讲。2. 门诊自助案例业务边界和用例提取的完整拆解2.1 先把门诊的涉众和目标盘清楚拿到门诊自助的题干第一步别急着画图先列涉众。门诊场景的涉众不是只有患者还牵扯很多角色。我按“受影响程度”和“目标”列一份典型清单患者希望快速完成挂号、缴费、取报告减少排队时间少跑窗口。门诊医生希望患者能按时就诊检查检验结果能及时回传减少重复解释工作。收费员和挂号员工作内容可能被自助机替代他们关心岗位调整和收费差错率。导诊护士需要指导患者使用自助机关心设备是否稳定、指引是否清晰。检验科和药房关心缴费与执行环节是否衔接避免漏费或重复执行。门诊管理者关心服务效率、患者满意度、平均候诊时间。信息科运维人员关心系统可用性、故障处理和接口稳定性。涉众清单列完你要能看出来一件事自助系统的价值不是“让机器能挂号”而是“降低患者的排队时间、减少收费窗口压力、提升门诊流转效率”。所有用例都要能回到这些目标上。这里有个高频丢分点把“自助机”当成涉众。自助机是系统本身的组成部分不是被影响的利益相关者。题目如果问“谁是涉众”你写“患者、收费员、信息科”都没问题写“自助机”就错了。2.2 业务用例图别画成系统功能清单门诊场景里最容易翻车的就是业务用例图。很多人把“挂号”“缴费”“打印报告”直接画在业务用例图里最上面放一个“患者”再画三条线连到这三个用例觉得这样就完事了。这其实是把业务用例图和系统用例图混成了一锅粥。正确的思路是这样的业务用例是“组织”对“业务执行者”提供的价值。门诊部这个组织向患者提供的业务用例应该是“接受门诊诊疗”“获取检查结果”这类价值表述而不是“自助挂号”这种功能动作。举个例子你就明白了。假设你画一张医院门诊部的业务用例图业务执行者是患者业务用例可以是接受门诊诊疗获取检查检验结果获得药品处方办理费用结算自助挂号、自助缴费既不构成一项业务价值也不属于某个业务组织单元它们是“为了完成上述业务用例而可能被自动化的若干步骤”。画业务用例图的时候它们不该出现在这一层。做题时怎么判断问自己一个问题如果这家医院没有自助机这个“业务用例”还能成立吗显然“接受门诊诊疗”没有自助机也成立而“自助挂号”没有自助机就消失了。凡是“没有某系统就不成立”的多半是系统用例不是业务用例。2.3 从业务流程一步步推出系统用例把业务层理清楚之后再看系统用例怎么来。我习惯先画一张门诊流程的活动链把患者从进院到离院的动作排一遍建档 → 挂号取号 → 候诊 → 医生接诊 → 开具检查/处方 → 缴费 → 执行检查/取药 → 获取报告 → 离院这张活动链里有几个环节天然适合“自助化”建档和挂号取号可以由自助机完成身份识别、科室选择和号源锁定。缴费可以由自助机完成费用查询、医保结算和支付。报告获取可以由自助机完成报告打印或电子报告推送。于是从业务流程中抽出的系统用例可以写成自助建档自助挂号取号自助缴费自助查询指引自助打印报告注意这些用例的名称都带上了“自助”说明执行者是患者边界是自助系统。然后每个系统用例再对应到业务流程中的那个具体步骤。我在做题时会用箭头标注“这一步被自动化后对应哪个系统用例”这样模型之间能对得上。这里也有一个容易扣分的地方业务用例和系统用例的关系不是“包含”或“扩展”而是“自动化替代”。少写这个推导过程评卷人看不出你的逻辑分数自然上不去。2.4 边界取舍哪些功能不应该放进门诊自助系统门诊自助场景通常还会挖一个坑给你一堆功能让你判断哪些属于这个系统。这时候不能凭感觉选我给你的判断标准是——用例的边界由“为谁创造什么可观察价值”决定。拿几个常见功能做例子预约挂号如果你做的是“门诊自助终端”预约挂号通常属于互联网渠道或手机端放进终端会导致边界扩大。如果题干明确说这个自助系统覆盖线上渠道你才可以纳入。退费退费涉及审批、原路退回、财务复核不是患者一个人能自助完成的。自助系统最多提供一个“退费申请”入口不能直接作为“自助退费”用例。医生排班查询可以支持但它是辅助信息一般不作为主流程用例更适合写成扩展路径。院内导航如果是自助机的优势功能可以作为独立用例但如果题干只强调挂号缴费别贪多。一句话总结这个部分的解题心法能不能由一个患者独立完成、能不能产生明确结果、算不算这个系统该负的责任。三者都满足才放进来。但凡有一个不满足就要谨慎。3. 鼠鸭识别案例一个AI功能如何装进用例框架3.1 先还原业务场景别被“识别”两个字带走鼠鸭识别这个名字很有迷惑性直接看会以为就是一个“图片分类”功能。但软件方法的题不会只考你有没有见过模型它考的是你能不能把这个功能放回业务场景里。我习惯先假设一个具体场景某个养殖场或农业监测项目中工作人员定期检查场地画面需要自动判断画面中出现的是鼠类还是鸭类。也可能是某个生态监测平台用于统计特定区域内两类目标的出现频率。不管哪个版本核心都是同一个问题——谁拿这个识别结果干什么。你不能把“鼠鸭识别”当作一个凭空存在的系统。没有执行者、没有目标、没有价值任何用例都不成立。3.2 执行者到底是谁直接决定用例怎么写换不同的执行者同一个识别能力会变成完全不同的用例。这个考点是鼠鸭识别场景最隐蔽的坑。假设执行者是养殖场的巡检员。他的目标是快速核查某个区域是否有鼠害入侵、鸭群是否异常。那系统用例应该写成“识别画面中的目标动物类别”价值是“辅助巡检员判断异常情况”。这时候识别结果需要包含置信度、时间戳、画面来源甚至需要支持批量画面导入。假设执行者是养殖场的管理人员。他的目标不是盯单张图而是要统计一段时间内鼠类出现的频次、鸭类数量变化趋势。那系统用例应该写成“统计区域动物分布情况”单张图片识别只是内部步骤不是顶层用例。假设执行者是算法工程师。他的目标是评估模型在真实数据上的表现那系统用例会变成“评测模型识别效果”需要提供标注对比、混淆矩阵、错误样本导出等功能。这就是第二章一直在强调的需求不是功能能力而是“某个涉众在某个情境下要达到的目标”。你在答卷上把执行者写死成“用户”虽然不算全错但会让用例价值和路径写得非常空评卷人一眼就能看出来你真懂还是假懂。3.3 功能不等于用例别把“识别”当成用例名很多人在鼠鸭识别这道题上会写“用例名称鼠鸭识别”然后基本路径是“上传图片→模型分类→输出结果”。这个写法我见过太多次了问题在于“识别”是一个系统内部能力不是用例。用例必须是一个完整的人机交互场景能让执行者获得业务价值。同样一个识别能力我通常建议用例名写成“识别图片中的目标动物类别”并搭配下面这样的规约结构用例名称识别图片中的目标动物类别执行者巡检员前置条件系统已部署可用识别模型巡检员已登录系统基本路径巡检员上传或选择待识别图片。系统校验图片格式和大小。系统调用识别模型进行分类。系统展示目标类别和置信度。巡检员查看结果并决定是否标记异常。扩展路径图片格式不支持系统提示重新上传。置信度低于阈值系统标记为“待人工确认”不直接输出结论。画面中目标数量过多系统提示并列出多个识别框。后置条件识别任务记录被保存可追溯到原始图片。你看功能只是第三步而真正让这个用例成立的是上一步的“谁”和下一步的“他拿结果干什么”。写规约的时候基本路径每一步都必须是有执行者参与或系统可观察的交互而不是神经元怎么运算、特征怎么提取。那些属于设计细节不属于用例规约。3.4 分析模型别画成神经网络架构图鼠鸭识别如果考到分析建模通常会给你一个类图或序列图让你判断对错。分析层的重点是“职责分配”不是“技术实现”。我建议至少画出三个分析类边界类识别交互界面负责接收图片、展示结果。控制类识别任务管理负责调度校验、调用模型、处理结果。实体类识别记录负责保存图片路径、类别、置信度、时间、执行者。如果你只画一个“图片”类和一个“识别系统”类等于什么都没做。图片这个实体类尤其容易漏属性它不只是“路径”还应该有“格式”“大小”“上传时间”“来源设备”。识别结果实体类要有“类别列表”“置信度”“是否人工确认”“关联图片”。序列图方面消息顺序要和用例基本路径一一对应从“提交图片”开始到“展示结果”结束。中间不要出现模型训练、GPU显存、数据集划分这些内容那些是设计和实现层的概念放在分析模型里会让层级混乱。4. 8道题常见的四种题型和解题套路4.1 涉众与目标题三步列出正确答案题干通常会给你一段业务背景然后问“这个系统涉及哪些涉众各自目标是什么”。我总结的答题顺序是第一步把题干中提到的组织边界画出来明确哪些人在里面、哪些人在外面。 第二步列出所有会被系统影响的人或组织包括受益者和可能受损者。 第三步给每个涉众写一个动词性目标不要写“需要系统”这种废话。门诊自助里你要写“收费员希望减少人工窗口差错”而不是“收费员需要自助机”。鼠鸭识别里你要写“管理人员希望统计鼠类出现频次”而不是“用户需要AI识别功能”。目标的写法最能看出你有没有真懂业务。4.2 业务用例与系统用例题记住“三层转写法”如果题目问你画业务用例图或判断某张图的错误我建议先在心里做一次“三层转写”。第一层组织给业务执行者提供的价值即业务用例。 第二层这些价值对应的完整业务流程即活动链。 第三层业务流程中被系统自动化的步骤即系统用例。答题时不要跨层。看到“自助缴费”四个字先问自己一句这层是在描述组织价值还是在描述系统功能如果是后者就别放到业务用例图上。这道题如果出成改错题大概率就是混层错误。4.3 用例规约题主路径清晰扩展路径写全写用例规约是这门课最拉分的部分。我的经验是主路径五步以内讲清楚扩展路径宁可多写不能漏写。基本路径的每一步必须是执行者或系统的可观察动作。比如“系统校验图片格式”“系统展示支付结果”可以写“模型进行卷积计算”不能写。扩展路径要覆盖输入异常、业务规则冲突、外部接口失败。鼠鸭识别场景里“置信度低于阈值”是几乎必考的扩展点别忘了加“人工确认”的后置分支。4.4 模型一致性题用四张图互相校验最后一种题型是给你多张模型图让你判断它们是否互相一致。我总结有四个容易出问题的地方业务用例图里有系统用例层级混用。系统用例与业务流程步骤不对应自动化对象找错。序列图消息顺序与用例基本路径不一致交互逻辑跳步。类图没有实体类或实体类属性缺失职责分配不完整。做题时我常用一个笨办法把用例基本路径的每一步编号再拿到序列图里去对应。只要有一步在序列图里找不到或者序列图里多出一步用例里没有的动作那就是不一致。这套校验法虽然笨但对8道题里的模型判断题非常有效。5. 三张自查表把建模题的错误率降下来5.1 我实测有效的一套建模做题流程这套流程是我在这套自测题上磨出来的后来用在其他建模题目里也很好用。第一步读完题干先不动笔用三分钟列出“涉众清单”和“业务目标”写在草稿纸最上方。 第二步画出业务层的核心活动链从触发到结束至少写六个步骤。 第三步从活动链里圈出哪些步骤可以被新系统自动化这一步是在为系统用例做准备。 第四步把圈出的步骤转换成系统用例每个用例写清楚执行者是谁。 第五步选择一个最核心的用例写基本路径和至少两条扩展路径。 第六步把模型之间对应关系标出来比如在活动链步骤后面标注“对应自助缴费用例”。这套流程看起来慢但非常稳。我实测做一套8题能保证至少不会犯层级混乱的大错而层级混乱正是这套题扣分最狠的地方。5.2 我在两个场景上踩过的坑门诊自助那个场景我第一版把“自助挂号”“自助缴费”画进了业务用例图还觉得自己画得很顺。后来对照概念才发现业务用例图是描述组织价值的不是描述系统功能的。我马上改成“接受门诊诊疗”“获取检查结果”作为业务用例再往下抽系统用例整张图才真正对味。鼠鸭识别那个场景我的第一反应是写“用例鼠鸭识别”基本路径只有三条上传、识别、返回。后来把执行者换成“巡检员”把用例名改成“识别图片中的目标动物类别”补上置信度阈值处理和人工确认这道题的答案才完整。这两个坑其实都是同一个原因我一开始把“功能”当成了“用例”。还有一个细节坑写序列图的时候我一度把“识别模型”当作控制类画在正中结果整张图变成了内部调用。改成分层结构——边界类收输入、控制类调度、实体类存取结果模型只作为控制类调用的外部服务才不再跑偏。5.3 常见问题速查表症状原因解法业务用例图画成了功能清单从系统视角出发没从组织价值出发先问“没有这个系统价值还在吗”用例名称是一个名词或技术词把功能或模块当成了用例改成“动词对象目标”结构基本路径写成了内部算法没分清分析层与实现层每一步写执行者可观察的交互序列图和用例对不上跳过了用例规约直接画序列图先编号基本路径再映射消息顺序涉众清单里出现“系统”把技术实体当成了利益相关者只列出钱、出力、受益、受影响的人或组织扩展路径只写了一个异常没考虑业务规则和外部接口失败至少补输入异常和结果阈值异常两条这套题做完一遍之后我给自己立了个规矩每个用例名称旁边必须标注一句话说明“给哪个角色带来什么可观察价值”。写不出来的用例我就当它还没找对。后来我做需求评审和架构方案时也保持着这个习惯确实帮我挡掉了很多“伪需求”和“自嗨功能”。你如果正被这套8题折磨不妨也先别急着看答案拿这个标准回去重新审视一遍自己的图多半能发现问题。