简介面向软件工程自考备考生这份PDF针对02333科目整理了系统复习要点覆盖软件工程概念与发展、软件复用的新技术、需求获取与规约、结构化分析与设计、数据流图绘制及模块结构图等核心章节。资料按教材顺序提炼概念对高频考点如需求分类、需求规约性质、DFD图元素与绘制注意事项、判定表与判定树等均有要点说明并附有考试题型单选、填空、简答、综合应用与分值分布特别提示综合题多出现在第3章和第6章便于合理分配复习精力。内容以单个PDF文件存放大小约1MB共1份文档结构紧凑适合打印或手机端随时查阅。目前已有785人学习下载对需要快速建立知识框架、加强概念记忆并练习重点题型的自考生而言是实用性较强的备考资料。1. 软件工程复习资料不是背诵清单是考点地图拿到《软件工程》02333 复习资料第一反应往往是按顺序背名词解释。实际上这份资料的价值不在罗列了多少知识点而是把考试题型和章节权重直接透明化了单选 30 分、填空 20 分、简答 30 分、综合应用 20 分且综合题高度集中在第 3 章结构化方法和第 6 章面向对象设计。这意味着只要把“需求获取→结构化分析→UML→RUP”这条主线走通就能覆盖 80% 以上的得分点。适合自考冲刺、期末复习也适合刚入行想补软件工程基础理论的开发者在项目间隙当“体检表”用。下面直接按考试逻辑拆透每一块。2. 从软件危机到需求规约02333 高频概念怎么记才不混这章的考点密度大但真正需要死记的只有几个锚点软件危机的三个核心问题、“软件程序文档”、需求的五条基本性质、需求规约的四条性质。其余概念都可以由这些锚点推导出来。2.1 软件危机与软件开发的本质用“三个核心问题”串起全章复习资料里给的答案很干脆软件危机是“速度、质量、成本”三个问题软件工程要解决的也正是这三件事。记住这个三元组之后再去看“软件开发本质是映射”“系统建模是抽象”就不会觉得抽象了——因为映射的目的就是让问题空间到解空间的转换更可控从而改善速度、质量、成本。软件的定义是“程序文档”这个定义经常出填空题。注意文档不是可选项它承载了建模、通信和后续维护的信息。开发本质那句“实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射”是简答常客答题时要把“问题空间”“解空间”“映射”三个词写全并补充一句“通过模型来表达”。系统模型分概念模型和软件模型概念模型描述软件是什么软件模型又包括设计模型、实现模型和部署模型这个层次关系建议画成一个小树系统模型 ├── 概念模型描述软件是什么 └── 软件模型描述软件的解决方案 ├── 设计模型 ├── 实现模型 └── 部署模型这里的“边界”“模型元素”“语义描述”就是判定一个模型是否完整的三个要素。考试如果你只写“模型是抽象”只能得一半分必须把“特定意图下所确定的角度和抽象层次”点出来。2.2 需求分类与接口/约束一张表分清“功能”与“非功能”需求分类是必考选择题和填空题。功能需求是需求主体描述系统“要做什么”非功能需求包含性能、外部接口、设计约束和质量属性。最容易丢分的是给一句描述让你判断属于哪一类比如“响应时间不超过 2 秒”——这是性能需求不是功能需求。我一般用一张表把容易混的类别钉死需求类别典型描述判断要点功能需求系统应支持订单查询有明确动作和结果性能需求在 1000 并发下响应时间小于 3 秒带测量指标外部接口需求支持与 ERP 系统通过 REST API 对接强调“外部”设计约束必须使用 Java 17遵循等保要求“必须”“不得”质量属性系统 7×24 小时可用故障恢复不超过 30 分钟可靠性、可维护性等关于接口需求资料列出七个子类用户接口、硬件接口、软件接口、通信接口、内存约束、运行、地点需求。这里“内存约束”很多人会忽略它其实是资源限制类约束不是软件接口。设计约束里的“法规政策”和“安全保密”容易判断但“握手协议”和“高级语言要求”看起来像技术方案本质也是设计约束——它们限制了实现方式。2.3 需求规约的四条性质用验收场景反推记忆并给代码自检需求规约SRS的考点集中在“基本性质”和“作用”。四条性质是重要性和稳定性程度、可修改的、完整的、一致的。记忆窍门是站在验收场景里重要性和稳定性程度——需求要分级避免所有需求同等权重可修改的——需求变更时文档要能低成本更新完整的——验收时不能出现“这个功能没写进文档但用户以为有”一致的——不能有两条需求互相矛盾。考试常考“一致性”和“完整性”的区别完整性对应遗漏一致性对应冲突。这组辨析值得用代码写成一个简单的自检函数帮助理解“可测试”的含义def check_srs(reqs): reqs: 每个元素是 {id: str, text: str, priority: int} ids [r[id] for r in reqs] # 一致性检查完整需求列表中不允许存在重复 id 且文本冲突 conflicts [] for i, r in enumerate(reqs): if ids.count(r[id]) 1: conflicts.append(r[id]) # 完整性检查允许非空 id且每个需求必须有 priority 字段 missing [r[id] for r in reqs if r.get(priority) is None] return { duplicate_ids: sorted(set(conflicts)), missing_priority: missing } reqs [ {id: FR-001, text: 用户可登录, priority: 1}, {id: FR-002, text: 用户可修改密码, priority: 2}, {id: FR-001, text: 用户可一键登录与FR-001冲突, priority: 1}, ] print(check_srs(reqs))参数说明reqs列表里每个字典代表一条需求id是需求编号text是陈述priority是重要程度等级。这个函数会把重复 id 和缺少 priority 的需求找出来对应“一致”和“可修改/分级”两个性质的落地检查。实际复习时可以把自己整理的需求描述放进这个结构里跑一遍就能看见哪些条目需要合并或删改。3. 结构化方法核心DFD、数据字典与判定表的实战拆解第 3 章是综合应用题的重灾区尤其是数据流图和后期的内聚耦合分析。复习资料建议“自顶向下、逐步求精”这八个字不是口号而是画 DFD 的强制顺序。3.1 DFD 建模三步法与“黑洞/灰洞”自动检查DFD 的建模过程分三步先画系统环境图只画一个加工、外部实体和数据流再画 0 层图从 0 开始对所有元素编号最后逐层细化为 1 层图。编号规则要注意数据流、加工、数据存储都有自己的编号体系0 层图开始加工编号为 1,2,3…下一层子加工编号为 1.1, 1.2…。检查错误时最典型的是三个洞黑洞只有输入没有输出只有输出没有输入多半是漏了数据来源灰洞输入不足以产生输出例如有两个输入但加工逻辑只用了一个。我把这三个洞写成 Python 检查逻辑方便复习时对任意加工做自检def check_process(process_name, inputs, outputs, logic_usesNone): inputs: 加工输入数据流名称列表 outputs: 加工输出数据流名称列表 logic_uses: 加工逻辑实际使用的输入数据流列表 logic_uses logic_uses if logic_uses else inputs if inputs and not outputs: return f{process_name}: 黑洞只有输入没有输出 if outputs and not inputs: return f{process_name}: 只有输出没有输入检查数据源 if inputs and outputs and len(logic_uses) len(inputs): unused set(inputs) - set(logic_uses) return f{process_name}: 灰洞这些输入未参与产生输出 - {unused} return f{process_name}: 正常 print(check_process(P1 订单校验, [订单信息, 库存状态], [校验结果], [订单信息]))这段代码里的logic_uses参数用于模拟“加工逻辑实际使用的输入”。如果输入有两个但加工只用了一个函数会判定为灰洞。实际画图时灰洞很难一眼看出来因为 DFD 图面上输入输出都画全了但语义上某条输入没有参与变换。遇到这种情况回到数据字典里查这条数据流是否被加工的描述引用即可。3.2 数据字典的三种运算符与加工描述工具数据字典定义数据流和数据存储的结构考试常考运算符含义顺序AB 表示 A 和 B 依次出现|选择A|B 表示 A 或 B 出现其中一个{}重复{A} 表示 A 重复 0 次或多次m..n子界{A}1..5 表示 A 出现 1 到 5 次。加工描述的三种工具是判定表、判定树、结构化语言。其中判定表最容易拿分因为它有固定格式左上条件、左下结果、右上条件取值、右下结果标记。给出一个订单折扣规则如何填完整条件/结果条件取值组合1组合2组合3组合4C1 订单金额 ≥ 1000YYNNC2 会员等级为 VIPYNYNA1 折扣 15%XA2 折扣 10%XXA3 折扣 5%X判定表的列数由条件组合数决定两个条件最多 4 列。考试如果条件有 3 个就是 8 列。写判定期时要注意右下角的结果格不要出现多选矛盾同一列只能有一个 X 对应对应结果除非规则允许并行动作。3.3 内聚与耦合用“修改影响范围”反向选择内聚和耦合是简答题和选择题的常客。内聚从差到好排序是偶然、逻辑、时间、过程、通信、顺序、功能耦合从强到弱排序是内容、公共、控制、标记、数据。死背顺序容易记反我一般用“修改影响范围”来判断如果修改一个模块内部成分会牵动别处说明内聚低、耦合高。给一张速查表类型核心特征维护表现偶然内聚语句凑在一起无关联改一处可能要拆模块逻辑内聚按功能逻辑相似性组合传入开关参数控制分支时间内聚同一时间段执行的动作组合初始化模块通信内聚引用同一数据集读写同一文件顺序内聚输出作为下一个输入前一步结果流向下一步功能内聚模块完成单一功能一个模块一个职责内容耦合一个模块直接访问另一模块内部数据危害最大公共耦合多个模块共享全局数据改数据结构要查所有使用方控制耦合传递控制信号控制对方逻辑主模块传 flag 给子模块标记耦合传递数据结构但只使用其中部分字段传整个对象只用一个字段数据耦合只传简单数据参数最理想鼓励使用记忆原则是“尽量用数据耦合少用控制耦合限制公共耦合范围避免内容耦合”。综合应用题如果要画模块结构图扇出大放在顶层底层模块扇入大作用域尽量落在控制域内这几点写进答案里就是得分点。4. UML 与 RUP从类图到生命周期阶段理清建模语言考核边界UML 部分考的多数是概念辨析几乎不要求画完整图但要求你面对一个场景时知道该用哪种图。资料把图分成结构图类图、对象图、包图、构件图、部署图和行为图用况图、活动图、状态图、顺序图、协作图这个二分法是填空题的高频点。4.1 类图的三栏结构与可见性符号类图是最常考的静态结构图。一个类的矩形框分三栏类名、属性、操作。属性的语法是“可见性 属性名类型 默认值 {性质串}”操作语法是“可见性 操作名参数表返回类型 {性质串}”。可见性有四种符号public、-private、#protected、~包内可见。考试给一段描述要求写成类图表示class Customer: def __init__(self, name: str, address: str): self.name name # name: String self.__address address # - address: String def get_address(self) - str: return self.__address class VipCustomer(Customer): def __init__(self, name: str, address: str, discount: float): super().__init__(name, address) self.discount discount # discount: Real这个代码对应类图Customer的公开属性name私有属性address公有操作get_address()VipCustomer通过继承关系成为子类新增属性discount。写类图时注意关联、聚合、组合的区别关联是平级引用聚合是整体和部分的弱关系菱形在整体端组合是强关系菱形实心。考试常让判断“订购单与订购项”是聚合还是组合——通常选组合因为订购项离开订购单没有独立意义。4.2 用况图、状态图、顺序图的场景选择这三种图都描述行为但视角不同。用况图展示参与者与系统功能的关系适合需求阶段状态图关注单个对象在生命周期中的状态变化适合描述订单状态机顺序图关注对象间消息的时间次序适合体现一次交互的过程。图类型核心元素典型场景高压考点用况图参与者、用况、关联、泛化、依赖描述系统功能边界参与者可以是另一个系统或时间状态图状态、事件、转换、初始状态订单从未付款到已付款状态由属性值集合决定顺序图生命线、活动条、消息用户登录的交互时序同步消息实心箭头、异步空心箭头顺序图的“生命线”是从对象向下画的一条竖线时间从上往下流。消息种类里“反身消息”指对象给自己发消息这在循环控制场景里可能出现定时消息会在消息上附加时间约束比如“5 秒后超时”。这些细节选择题偶尔会设坑注意看箭头是否实心。4.3 RUP 二维模型与核心工作流迭代不是阶段RUP 的二维模型是一个典型的横纵轴结构横轴是时间分初始、细化、构造、交付四个阶段纵轴是内容分商业建模、需求、分析设计、实现、测试、部署六个核心过程工作流加配置变更管理、项目管理、环境三个支持工作流。这里容易混淆的是“阶段”和“工作流”阶段是时间切片工作流是逻辑活动每次迭代都会穿越多个工作流。初始阶段结束于生命周期目标里程碑细化阶段结束于生命周期结构里程碑构造阶段结束于初始功能里程碑交付阶段结束于产品发布里程碑。记忆时用每个里程碑的产物去对应目标→判断项目能否活下去结构→确定体系结构基准初始功能→能否部署到测试环境产品发布→是否开始下一个周期。5. 综合应用题得分技巧与复习脚本化落地综合题每题 10 分通常考 DFD 补全或内聚/耦合分析。我的经验是先看数据流不要一上来画加工。对于 DFD 补全题按顺序做四件事找外部实体所有数据流的起点和终点必须是外部实体或加工不能从数据存储直接发到外部实体标加工编号环境图只有一个加工0 层图要编 1、2、3检查每一个加工的输入输出直接套上面第 3 章的判定逻辑至少保证没有黑洞和灰洞最后检查数据流命名动词性数据流后面往往隐藏着加工。对于内聚耦合判断题先说结论再给依据。比如“某模块通过全局变量控制另一模块内部执行分支”判断是公共耦合加逻辑内聚依据是共享全局数据且控制信号影响内部逻辑。答题时要写出“建议改为数据耦合并拆分为单一职责模块”这样能拿满 5 分简答或 10 分应用。复习资料的东西比较多我建议把整份 PDF 转成 Markdown 或 JSON然后写个小脚本抽取名词和定义生成每日自测卡片import json cards [ {term: 软件危机, def: 软件开发速度、质量、成本三个核心问题}, {term: 需求规约, def: 所有需求陈述的正式文档表达概念模型}, {term: 灰洞, def: 加工输入不足以产生输出}, {term: 功能内聚, def: 模块完成单一功能内聚程度最高}, ] def quiz(num): import random for item in random.sample(cards, num): kw input(f请解释 {item[term]}) if kw.strip(): print(f参考答案{item[def]}\n) quiz(2)cards列表存放考点和答案quiz函数随机抽取指定数量的卡片在终端里先默写再对答案。这个脚本直接跑就能用数字参数控制一次抽几张。用这种方式过三轮比反复看 PDF 效率高得多。把容易写不全的定义例如“需求规约的作用”四条拆成独立卡片每天自测一次到考前基本不会失分。本文还有配套的精品资源点击获取
简介面向软件工程自考备考生这份PDF针对02333科目整理了系统复习要点覆盖软件工程概念与发展、软件复用的新技术、需求获取与规约、结构化分析与设计、数据流图绘制及模块结构图等核心章节。资料按教材顺序提炼概念对高频考点如需求分类、需求规约性质、DFD图元素与绘制注意事项、判定表与判定树等均有要点说明并附有考试题型单选、填空、简答、综合应用与分值分布特别提示综合题多出现在第3章和第6章便于合理分配复习精力。内容以单个PDF文件存放大小约1MB共1份文档结构紧凑适合打印或手机端随时查阅。目前已有785人学习下载对需要快速建立知识框架、加强概念记忆并练习重点题型的自考生而言是实用性较强的备考资料。1. 软件工程复习资料不是背诵清单是考点地图拿到《软件工程》02333 复习资料第一反应往往是按顺序背名词解释。实际上这份资料的价值不在罗列了多少知识点而是把考试题型和章节权重直接透明化了单选 30 分、填空 20 分、简答 30 分、综合应用 20 分且综合题高度集中在第 3 章结构化方法和第 6 章面向对象设计。这意味着只要把“需求获取→结构化分析→UML→RUP”这条主线走通就能覆盖 80% 以上的得分点。适合自考冲刺、期末复习也适合刚入行想补软件工程基础理论的开发者在项目间隙当“体检表”用。下面直接按考试逻辑拆透每一块。2. 从软件危机到需求规约02333 高频概念怎么记才不混这章的考点密度大但真正需要死记的只有几个锚点软件危机的三个核心问题、“软件程序文档”、需求的五条基本性质、需求规约的四条性质。其余概念都可以由这些锚点推导出来。2.1 软件危机与软件开发的本质用“三个核心问题”串起全章复习资料里给的答案很干脆软件危机是“速度、质量、成本”三个问题软件工程要解决的也正是这三件事。记住这个三元组之后再去看“软件开发本质是映射”“系统建模是抽象”就不会觉得抽象了——因为映射的目的就是让问题空间到解空间的转换更可控从而改善速度、质量、成本。软件的定义是“程序文档”这个定义经常出填空题。注意文档不是可选项它承载了建模、通信和后续维护的信息。开发本质那句“实现问题空间的概念和处理逻辑到解空间的概念和处理逻辑之间的映射”是简答常客答题时要把“问题空间”“解空间”“映射”三个词写全并补充一句“通过模型来表达”。系统模型分概念模型和软件模型概念模型描述软件是什么软件模型又包括设计模型、实现模型和部署模型这个层次关系建议画成一个小树系统模型 ├── 概念模型描述软件是什么 └── 软件模型描述软件的解决方案 ├── 设计模型 ├── 实现模型 └── 部署模型这里的“边界”“模型元素”“语义描述”就是判定一个模型是否完整的三个要素。考试如果你只写“模型是抽象”只能得一半分必须把“特定意图下所确定的角度和抽象层次”点出来。2.2 需求分类与接口/约束一张表分清“功能”与“非功能”需求分类是必考选择题和填空题。功能需求是需求主体描述系统“要做什么”非功能需求包含性能、外部接口、设计约束和质量属性。最容易丢分的是给一句描述让你判断属于哪一类比如“响应时间不超过 2 秒”——这是性能需求不是功能需求。我一般用一张表把容易混的类别钉死需求类别典型描述判断要点功能需求系统应支持订单查询有明确动作和结果性能需求在 1000 并发下响应时间小于 3 秒带测量指标外部接口需求支持与 ERP 系统通过 REST API 对接强调“外部”设计约束必须使用 Java 17遵循等保要求“必须”“不得”质量属性系统 7×24 小时可用故障恢复不超过 30 分钟可靠性、可维护性等关于接口需求资料列出七个子类用户接口、硬件接口、软件接口、通信接口、内存约束、运行、地点需求。这里“内存约束”很多人会忽略它其实是资源限制类约束不是软件接口。设计约束里的“法规政策”和“安全保密”容易判断但“握手协议”和“高级语言要求”看起来像技术方案本质也是设计约束——它们限制了实现方式。2.3 需求规约的四条性质用验收场景反推记忆并给代码自检需求规约SRS的考点集中在“基本性质”和“作用”。四条性质是重要性和稳定性程度、可修改的、完整的、一致的。记忆窍门是站在验收场景里重要性和稳定性程度——需求要分级避免所有需求同等权重可修改的——需求变更时文档要能低成本更新完整的——验收时不能出现“这个功能没写进文档但用户以为有”一致的——不能有两条需求互相矛盾。考试常考“一致性”和“完整性”的区别完整性对应遗漏一致性对应冲突。这组辨析值得用代码写成一个简单的自检函数帮助理解“可测试”的含义def check_srs(reqs): reqs: 每个元素是 {id: str, text: str, priority: int} ids [r[id] for r in reqs] # 一致性检查完整需求列表中不允许存在重复 id 且文本冲突 conflicts [] for i, r in enumerate(reqs): if ids.count(r[id]) 1: conflicts.append(r[id]) # 完整性检查允许非空 id且每个需求必须有 priority 字段 missing [r[id] for r in reqs if r.get(priority) is None] return { duplicate_ids: sorted(set(conflicts)), missing_priority: missing } reqs [ {id: FR-001, text: 用户可登录, priority: 1}, {id: FR-002, text: 用户可修改密码, priority: 2}, {id: FR-001, text: 用户可一键登录与FR-001冲突, priority: 1}, ] print(check_srs(reqs))参数说明reqs列表里每个字典代表一条需求id是需求编号text是陈述priority是重要程度等级。这个函数会把重复 id 和缺少 priority 的需求找出来对应“一致”和“可修改/分级”两个性质的落地检查。实际复习时可以把自己整理的需求描述放进这个结构里跑一遍就能看见哪些条目需要合并或删改。3. 结构化方法核心DFD、数据字典与判定表的实战拆解第 3 章是综合应用题的重灾区尤其是数据流图和后期的内聚耦合分析。复习资料建议“自顶向下、逐步求精”这八个字不是口号而是画 DFD 的强制顺序。3.1 DFD 建模三步法与“黑洞/灰洞”自动检查DFD 的建模过程分三步先画系统环境图只画一个加工、外部实体和数据流再画 0 层图从 0 开始对所有元素编号最后逐层细化为 1 层图。编号规则要注意数据流、加工、数据存储都有自己的编号体系0 层图开始加工编号为 1,2,3…下一层子加工编号为 1.1, 1.2…。检查错误时最典型的是三个洞黑洞只有输入没有输出只有输出没有输入多半是漏了数据来源灰洞输入不足以产生输出例如有两个输入但加工逻辑只用了一个。我把这三个洞写成 Python 检查逻辑方便复习时对任意加工做自检def check_process(process_name, inputs, outputs, logic_usesNone): inputs: 加工输入数据流名称列表 outputs: 加工输出数据流名称列表 logic_uses: 加工逻辑实际使用的输入数据流列表 logic_uses logic_uses if logic_uses else inputs if inputs and not outputs: return f{process_name}: 黑洞只有输入没有输出 if outputs and not inputs: return f{process_name}: 只有输出没有输入检查数据源 if inputs and outputs and len(logic_uses) len(inputs): unused set(inputs) - set(logic_uses) return f{process_name}: 灰洞这些输入未参与产生输出 - {unused} return f{process_name}: 正常 print(check_process(P1 订单校验, [订单信息, 库存状态], [校验结果], [订单信息]))这段代码里的logic_uses参数用于模拟“加工逻辑实际使用的输入”。如果输入有两个但加工只用了一个函数会判定为灰洞。实际画图时灰洞很难一眼看出来因为 DFD 图面上输入输出都画全了但语义上某条输入没有参与变换。遇到这种情况回到数据字典里查这条数据流是否被加工的描述引用即可。3.2 数据字典的三种运算符与加工描述工具数据字典定义数据流和数据存储的结构考试常考运算符含义顺序AB 表示 A 和 B 依次出现|选择A|B 表示 A 或 B 出现其中一个{}重复{A} 表示 A 重复 0 次或多次m..n子界{A}1..5 表示 A 出现 1 到 5 次。加工描述的三种工具是判定表、判定树、结构化语言。其中判定表最容易拿分因为它有固定格式左上条件、左下结果、右上条件取值、右下结果标记。给出一个订单折扣规则如何填完整条件/结果条件取值组合1组合2组合3组合4C1 订单金额 ≥ 1000YYNNC2 会员等级为 VIPYNYNA1 折扣 15%XA2 折扣 10%XXA3 折扣 5%X判定表的列数由条件组合数决定两个条件最多 4 列。考试如果条件有 3 个就是 8 列。写判定期时要注意右下角的结果格不要出现多选矛盾同一列只能有一个 X 对应对应结果除非规则允许并行动作。3.3 内聚与耦合用“修改影响范围”反向选择内聚和耦合是简答题和选择题的常客。内聚从差到好排序是偶然、逻辑、时间、过程、通信、顺序、功能耦合从强到弱排序是内容、公共、控制、标记、数据。死背顺序容易记反我一般用“修改影响范围”来判断如果修改一个模块内部成分会牵动别处说明内聚低、耦合高。给一张速查表类型核心特征维护表现偶然内聚语句凑在一起无关联改一处可能要拆模块逻辑内聚按功能逻辑相似性组合传入开关参数控制分支时间内聚同一时间段执行的动作组合初始化模块通信内聚引用同一数据集读写同一文件顺序内聚输出作为下一个输入前一步结果流向下一步功能内聚模块完成单一功能一个模块一个职责内容耦合一个模块直接访问另一模块内部数据危害最大公共耦合多个模块共享全局数据改数据结构要查所有使用方控制耦合传递控制信号控制对方逻辑主模块传 flag 给子模块标记耦合传递数据结构但只使用其中部分字段传整个对象只用一个字段数据耦合只传简单数据参数最理想鼓励使用记忆原则是“尽量用数据耦合少用控制耦合限制公共耦合范围避免内容耦合”。综合应用题如果要画模块结构图扇出大放在顶层底层模块扇入大作用域尽量落在控制域内这几点写进答案里就是得分点。4. UML 与 RUP从类图到生命周期阶段理清建模语言考核边界UML 部分考的多数是概念辨析几乎不要求画完整图但要求你面对一个场景时知道该用哪种图。资料把图分成结构图类图、对象图、包图、构件图、部署图和行为图用况图、活动图、状态图、顺序图、协作图这个二分法是填空题的高频点。4.1 类图的三栏结构与可见性符号类图是最常考的静态结构图。一个类的矩形框分三栏类名、属性、操作。属性的语法是“可见性 属性名类型 默认值 {性质串}”操作语法是“可见性 操作名参数表返回类型 {性质串}”。可见性有四种符号public、-private、#protected、~包内可见。考试给一段描述要求写成类图表示class Customer: def __init__(self, name: str, address: str): self.name name # name: String self.__address address # - address: String def get_address(self) - str: return self.__address class VipCustomer(Customer): def __init__(self, name: str, address: str, discount: float): super().__init__(name, address) self.discount discount # discount: Real这个代码对应类图Customer的公开属性name私有属性address公有操作get_address()VipCustomer通过继承关系成为子类新增属性discount。写类图时注意关联、聚合、组合的区别关联是平级引用聚合是整体和部分的弱关系菱形在整体端组合是强关系菱形实心。考试常让判断“订购单与订购项”是聚合还是组合——通常选组合因为订购项离开订购单没有独立意义。4.2 用况图、状态图、顺序图的场景选择这三种图都描述行为但视角不同。用况图展示参与者与系统功能的关系适合需求阶段状态图关注单个对象在生命周期中的状态变化适合描述订单状态机顺序图关注对象间消息的时间次序适合体现一次交互的过程。图类型核心元素典型场景高压考点用况图参与者、用况、关联、泛化、依赖描述系统功能边界参与者可以是另一个系统或时间状态图状态、事件、转换、初始状态订单从未付款到已付款状态由属性值集合决定顺序图生命线、活动条、消息用户登录的交互时序同步消息实心箭头、异步空心箭头顺序图的“生命线”是从对象向下画的一条竖线时间从上往下流。消息种类里“反身消息”指对象给自己发消息这在循环控制场景里可能出现定时消息会在消息上附加时间约束比如“5 秒后超时”。这些细节选择题偶尔会设坑注意看箭头是否实心。4.3 RUP 二维模型与核心工作流迭代不是阶段RUP 的二维模型是一个典型的横纵轴结构横轴是时间分初始、细化、构造、交付四个阶段纵轴是内容分商业建模、需求、分析设计、实现、测试、部署六个核心过程工作流加配置变更管理、项目管理、环境三个支持工作流。这里容易混淆的是“阶段”和“工作流”阶段是时间切片工作流是逻辑活动每次迭代都会穿越多个工作流。初始阶段结束于生命周期目标里程碑细化阶段结束于生命周期结构里程碑构造阶段结束于初始功能里程碑交付阶段结束于产品发布里程碑。记忆时用每个里程碑的产物去对应目标→判断项目能否活下去结构→确定体系结构基准初始功能→能否部署到测试环境产品发布→是否开始下一个周期。5. 综合应用题得分技巧与复习脚本化落地综合题每题 10 分通常考 DFD 补全或内聚/耦合分析。我的经验是先看数据流不要一上来画加工。对于 DFD 补全题按顺序做四件事找外部实体所有数据流的起点和终点必须是外部实体或加工不能从数据存储直接发到外部实体标加工编号环境图只有一个加工0 层图要编 1、2、3检查每一个加工的输入输出直接套上面第 3 章的判定逻辑至少保证没有黑洞和灰洞最后检查数据流命名动词性数据流后面往往隐藏着加工。对于内聚耦合判断题先说结论再给依据。比如“某模块通过全局变量控制另一模块内部执行分支”判断是公共耦合加逻辑内聚依据是共享全局数据且控制信号影响内部逻辑。答题时要写出“建议改为数据耦合并拆分为单一职责模块”这样能拿满 5 分简答或 10 分应用。复习资料的东西比较多我建议把整份 PDF 转成 Markdown 或 JSON然后写个小脚本抽取名词和定义生成每日自测卡片import json cards [ {term: 软件危机, def: 软件开发速度、质量、成本三个核心问题}, {term: 需求规约, def: 所有需求陈述的正式文档表达概念模型}, {term: 灰洞, def: 加工输入不足以产生输出}, {term: 功能内聚, def: 模块完成单一功能内聚程度最高}, ] def quiz(num): import random for item in random.sample(cards, num): kw input(f请解释 {item[term]}) if kw.strip(): print(f参考答案{item[def]}\n) quiz(2)cards列表存放考点和答案quiz函数随机抽取指定数量的卡片在终端里先默写再对答案。这个脚本直接跑就能用数字参数控制一次抽几张。用这种方式过三轮比反复看 PDF 效率高得多。把容易写不全的定义例如“需求规约的作用”四条拆成独立卡片每天自测一次到考前基本不会失分。本文还有配套的精品资源点击获取
` 方法)
