【软考高级·系统分析师全链路通关实战】第 32 篇面向对象分析 OOA——用例驱动的分析方法本系列定位面向有开发经验、从零备考软考高级「系统分析师」的工程师以《系统分析师教程第 2 版》为主线按「综合知识 → 案例分析 → 论文」三科组织需求工程与 UML 建模深拆60 篇带你从考试小白到三科同过。本篇你将学到OOA 三大模型用例模型、分析类模型、分析包各自的定位与产出用例实现从用例规约推导分析类的完整路径边界类/控制类/实体类三版型Stereotype的判定口诀概念类图与领域模型什么时候画概念类图、职责分配怎么落在类上OOA 与结构化分析的对比功能分解 vs 对象协作案例答题的选型论证套路云诊通实战在线问诊「提交图文问诊」用例 → 边界/控制/实体三类分析类的完整推导过程学完本篇需求工程模块第 26-32 篇的分析方法链路闭环案例题「补分析类 / 判定类版型 / 论证 OOA 与 SA 选型」三类设问你都有标准作答结构。考点热力表|| 知识点 | 综合知识 | 案例分析 | 论文 ||--------|:—:—:—| 边界类/控制类/实体类三版型判定 | ★★★ | ★★★ | ★★ || 用例模型与分析类模型的推导关系 | ★★ | ★★★ | ★★ || 概念类图与领域模型 | ★★ | ★★ | ★★ || OOA 与结构化分析的对比 | ★★ | ★★★ | ★★ || 分析包与包间依赖 | ★ | ★ | — |一、OOA 在需求工程中的位置与三大模型1.1 OOA 是需求分析的一条建模路线第 28 篇讲过需求建模的双路线结构化模型DFD第 25 篇专攻与对象模型UML。面向对象分析OOA, Object-Oriented Analysis就是后一条路线的完整方法论用面向对象的概念模型去描述系统要做什么而不是怎么做。它承接用例模型第 16 篇用例图向下走输出给 OOD面向对象设计接手——分析与设计的分界线是「逻辑视角到实现视角的切换」。OOA 的核心思想一句话用例驱动、以对象为中心、迭代增量。用例是功能的组织单位对象是责任的承载单位两者通过「用例实现」衔接。1.2 三大模型模型回答的问题核心产出对应 UML 图用例模型系统对外的功能边界是什么参与者、用例、用例规约事件流用例图 用例规约文本分析类模型系统内部由哪几类职责对象协作完成用例边界类/控制类/实体类及关系分析类图带版型的类图 交互图分析包分析类如何分组形成高内聚的逻辑单元包及包间依赖包图三个模型的关系用例模型是输入分析类模型是主体分析包是组织结构。考试里问「OOA 的三个模型」直接答这张表的第一列。用例实现交互协作推导按业务域分组高内聚低耦合用例模型参与者用例规约分析类模型边界/控制/实体类分析包包图组织结构交付 OOD细节设计接手二、从用例到分析类三版型判定2.1 用例实现推导的起点一个用例的事件流里每一步都隐含着对象协作。推导方法案例题的标准动作把用例规约的事件流逐步走一遍凡是「参与者与系统交互」的步骤产生边界类「系统内部加工/编排」的步骤产生控制类「读写持久信息」的步骤产生实体类。2.2 三版型判定口诀必背版型英文职责判定线索云诊通例边界类 boundaryboundary参与者与系统之间的接口表单、屏幕、窗口、外部接口适配事件流中「用户输入/查看」「与外部系统交互」患者端问诊表单、监管上报报文适配器控制类 controlcontrol用例的编排逻辑校验、计算、流程协调一个用例通常一个「系统验证/计算/流转/触发」问诊资格校验器、处方流转协调器实体类 entityentity持久信息与业务规则系统要长期记住的东西「记录/保存/查询/状态」问诊单、处方、患者档案判定口诀见人参与者设边界见流程设控制见数据设实体。综合知识常考反向题给一个类名问属于哪类版型——「登录窗口」边界、「订单提交处理器」控制、「订单」实体。2.3 三个易错点边界类不等于页面边界类是分析级概念一个边界类可能对应多个页面也可能对应一个对外接口如监管上报接口不与 UI 一一对应。控制类不承载业务规则像「复诊凭证必须 6 个月内」这类规则属于实体类问诊单自己知道资格控制类只负责编排调用。规则放错位置是案例题常见扣分点。一个用例一个控制类是默认不是铁律简单 CRUD 用例可省控制类边界直接调实体复杂用例可多个控制类。答「必须一一对应」是错的。三、概念类图、领域模型与职责分配3.1 概念类图与领域模型在画带版型的分析类图之前OOA 通常先建领域模型domain model用概念类图conceptual class diagram表达业务域中客观存在的概念及其关系——患者、医生、问诊单、处方、药品……此时只标属性与关联含多重性不标方法。领域模型是第 28 篇「提炼实体需求」的可视化落地也为第 11 篇 E-R 建模提供前身。概念类图与设计类图的区别是综合知识考点概念类图无操作、职责用自然语言设计类图有完整操作签名。OOA 阶段的重心是概念层。3.2 职责分配分析类识别出来后要回答「这件事归谁管」数据职责归实体类属性业务规则行为职责归控制类流程编排通信职责归边界类协议转换、输入输出格式化。职责分配的原则是信息专家谁拥有完成某职责所需的全部信息职责就分给谁——这就是为什么资格规则放问诊单实体而非控制类。四、OOA vs 结构化分析选型论证案例题爱问「本项目应采用结构化分析还是面向对象分析请说明理由」。标准论证从四个维度对比维度结构化分析 SA面向对象分析 OOA分解单位功能加工/数据流对象类与协作核心模型DFD 数据字典 E-R用例模型 分析类模型稳定性需求变化时功能结构震荡大对象层稳定改协作不改结构复用性模型与实现断层难复用分析模型平滑过渡到 OOD支持复用适用场景数据处理密集、流程稳定的系统交互复杂、需求易变、迭代开发的系统答题模板云诊通示范结论选 OOA 三条理由①问诊业务交互复杂、六类干系人参与对象视角更自然②项目采用迭代开发第 13 篇OOA 到 OOD 到编码语言同范式模型可平滑演进③需求变更频繁第 31 篇处方变更即例对象封装使变更局部化 一条边界数据上报等强流程批处理子域仍可用 DFD 辅助描述。这种「结论理由边界」的论证结构第 54 篇会正式总结。五、云诊通实战在线问诊用例 → 分析类完整推导5.1 用例规约输入用例UC-04 提交图文问诊患者发起主事件流①患者选择医生并填写病情描述与图片 → ②系统校验复诊资格6 个月内同科室就诊记录→ ③系统创建问诊单并扣减该医生问诊额度 → ④系统通知医生接诊 → ⑤系统全程记录会话留痕。5.2 逐步推导标准动作示范事件流步骤推导动作产出分析类① 患者填写并提交见参与者交互 → 边界类ConsultForm患者端问诊表单boundary② 校验复诊资格系统内部编排校验 → 控制类EligibilityChecker资格校验器control② 读就诊记录读写持久信息 → 实体类VisitRecord就诊记录entity③ 创建问诊单持久业务对象 → 实体类Consultation问诊单含资格规则entity③ 扣减额度编排多对象协作 → 控制类ConsultController问诊协调器control④ 通知医生跨参与者交互 → 边界类DoctorNotifier医生通知端口boundary⑤ 会话留痕读写持久信息 → 实体类AuditLog留痕日志entity5.3 分析类图带版型提交校验查6个月记录判定资格规则创建问诊生成并扣额度推送接诊写入留痕«boundary»ConsultForm患者端问诊表单«boundary»DoctorNotifier医生通知端口«control»EligibilityChecker复诊资格校验编排«control»ConsultController问诊创建协调«entity»Consultation问诊单资格规则«entity»VisitRecord就诊记录«entity»AuditLog会话留痕5.4 收口分析包按业务域把问诊域的分析类打包为consultation包与prescription处方域、monitor监管上报域建立依赖——监管上报包只依赖问诊包的实体类接口而不触碰其边界类这正是第 28 篇「实时性 vs 留痕合规」冲突在结构上的解法留痕通过实体类异步外送不侵入问诊主流程。这套分析包边界后来直接演化为垂直拆分的服务边界第 37 篇微服务拆分时回看。推导流程整链路一图收口参与者交互系统编排持久信息用例规约UC-04 事件流逐步判定边界类ConsultForm/DoctorNotifier控制类EligibilityChecker/ConsultController实体类Consultation/VisitRecord/AuditLog分析类图含版型与关系按业务域分包consultation/prescription/monitor交付 OOD设计类图接手真题风格自测题1. OOA 的三个核心模型是 。A. 用例模型、分析类模型、分析包 B. DFD、数据字典、E-R 图 C. 用例图、序列图、状态图 D. 实体模型、功能模型、行为模型2. 负责参与者与系统之间交互的分析类版型是 。A. 实体类 B. 控制类 C. 边界类 D. 服务类3. 「问诊单在提交时自行判断是否满足复诊资格规则」该规则应分配给 。A. 边界类 B. 问诊单实体类 C. 控制类 D. 工具类4. 一个用例的事件流中出现「系统验证用户身份并计算费用」通常识别出 。A. 边界类 B. 控制类 C. 实体类 D. 包5. 关于控制类错误的说法是 。A. 一个用例通常对应一个控制类 B. 简单 CRUD 用例可省略控制类 C. 控制类应承载核心业务规则 D. 控制类负责用例的流程编排6. 概念类图与设计类图的关键区别是 。A. 概念类图有操作签名 B. 概念类图只含属性与关联不标操作 C. 概念类图必须含包 D. 两者完全相同7. 与结构化分析相比OOA 的突出优点是 。A. 只适合批处理系统 B. 需求变化时对象结构相对稳定变更局部化 C. 不需要需求获取 D. 不需要文档8. 「见人设边界见流程设控制见数据设实体」中「人」指的是 。A. 开发人员 B. 参与者含外部系统 C. 项目经理 D. 最终用户中的一种9. 云诊通监管上报的外部接口适配器应识别为 。A. 边界类 B. 控制类 C. 实体类 D. 工具类10. 分析包设计遵循的原则是 。A. 高内聚低耦合 B. 包越多越好 C. 所有类放一个包 D. 按开发人员分包11. 简答为什么把「复诊资格规则」放在 Consultation 实体类而不是 EligibilityChecker 控制类参考答案1.A 2.C 3.B 4.B 5.C 6.B 7.B 8.B 9.A 10.A 11. 依据信息专家原则完成某职责所需的信息就诊时间、科室、同医生就诊历史全部由问诊单持有规则放实体类使职责与数据同处一地资格规则变更时只改一个类第 31 篇监管新规式变更的影响面最小化且多个用例提交问诊、续方、随访复用同一规则不必重复编排控制类只做流程编排规则内聚在实体上也避免了编排逻辑与业务逻辑耦合导致的难测试、难复用。本篇小结|| 知识点 | 核心内容 ||--------|---------|| OOA 三大模型 | 用例模型输入、分析类模型主体、分析包组织 || 三版型判定 | 见人参与者设边界、见流程设控制、见数据设实体 || 边界类 | 参与者与系统的接口表单、窗口、外部接口适配不与页面一一对应 || 控制类 | 用例编排逻辑默认一用例一个不承载核心业务规则 || 实体类 | 持久信息业务规则信息专家原则分配职责 || 概念类图/领域模型 | 业务概念关联多重性无操作签名是 E-R 建模前身 || OOA vs SA | 功能分解 vs 对象协作易变交互系统选 OOA论证用「结论三条理由一条边界」 || 云诊通推导 | UC-04 七步事件流 → 2 边界 2 控制 3 实体 → 分析类图 → 分析包 |下篇预告第 33 篇需求工程案例分析真题模式精讲需求工程模块收官历年案例题的三大命题模式找缺失需求/评价文档质量/设计获取方案、「方法名场景适配理由具体动作」三段式答题模板以及 2 道完整真题风格演练含参考答案与评分点自评。如果本篇内容对你有帮助欢迎点赞收藏有任何疑问欢迎在评论区交流。
