资料目录（截图原因可能偏模糊，实际都是高清版）
备考《软件工程原理》，最致命的误区是把它当成《软件工程导论》的“理论升级版”——继续背瀑布模型、敏捷开发、软件测试的概念，结果遇到“如何证明一个并发控制算法是正确的”这类问题时，只会罗列“用测试用例”几个字，却看不见软件工程原理的本质是用严谨的数学和逻辑，为软件构造建立可靠的理论根基。这门课与导论课的根本分野在于：导论告诉你“怎么做”，原理逼问你“为什么这么做可靠”。
第一，从“流程记忆”彻底切换为“形式化思维”。 绝大多数考生按软件过程、需求工程、设计方法、测试策略的章节顺序死守，这是工程经验的总结逻辑，不是原理课的思维逻辑。高分考生的知识库是按“模型→规约→验证→演化”这条科学主线重组的。 建议手绘一张“软件工程原理逻辑链图”，起点是“软件模型”（用什么语言描述软件？形式语言/半形式语言），经过“规约”（如何精确表达需求？前置/后置条件、不变式），到达“验证”（如何证明软件满足规约？模型检验/定理证明/测试覆盖），最后是“演化”（如何管理变更？耦合度、内聚性度量）。把教材各章的有限状态机、Petri网、Z语言、程序正确性证明、环路复杂度全部挂载到它们在逻辑链中的位置。合上笔记能从“并发控制算法”这个任务，推演出需要用形式模型描述并发状态（如Petri网），用时序逻辑规约安全性（无死锁）和活性（最终可执行），用模型检验工具验证规约是否满足，才算读懂了软件工程原理的科学逻辑。
第二，死磕“形式化规约”这个理论心脏。 这是全书一切验证的基础，也是无数考生把前置条件、后置条件、不变式背成几个名词、却从未真正用它们精确描述一个简单函数的致命失血。自然语言是模糊的，形式语言才是精确的。 复习形式化规约，不能只背定义，必须追问：为什么只有前置/后置条件还不够，还需要类不变式？因为对象有内部状态要维护。如何用Z语言描述一个栈的操作？用模式（schema）结构化地定义状态和操作。形式化规约的代价是什么？学习曲线陡，开发慢，但适用于安全关键系统（如航天、医疗）。建议制作“形式化规约推演卡”，以栈、队列、计数器、自动售货机四个简单系统为横轴，每轴完成三层作业：用自然语言描述需求、用前置/后置条件+不变式形式化规约、指出这种规约消除了哪些自然语言的歧义。考场遇“如何精确描述一个银行的取款操作”题，你从账户余额不小于取款额（前置条件）、余额更新（后置条件）、余额始终不小于零（不变式）三个层面展开。
第三，用“程序正确性证明”这把尺子击穿验证技术。 这是软件工程原理中最硬核的部分，也是无数考生把测试、评审、证明背成三种验证手段、却从未理解它们各自的理论基础和适用边界的认知断层。测试只能证明有错，不能证明没错；证明才能说“绝对正确”。 复习程序正确性证明，不能只背Floyd的前置断言法、Hoare的公理化方法，必须追问：为什么要在循环中找不变式？因为循环次数可能未知，不变式刻画了循环的本质。如何为一个排序算法设计断言？需要证明结果是有序的且是原序列的排列。证明的局限性是什么？工作量大，自动化程度低，只适用于核心模块。建议制作“验证技术对比档案”，以测试、代码评审、模型检验、定理证明四种技术为横轴，每轴完成三层作业：技术原理、适用范围、优缺点。考场遇“航天飞机飞控软件应采用什么验证技术”题，你从安全关键、错误容忍度极低的角度，推荐模型检验+定理证明+严格测试的组合，并说明理由。
第四，建立“软件度量”的量化意识。 这是从“感觉”走向“科学”的关键一步，也是无数考生把代码行数、环路复杂度、内聚耦合背成几个指标、却从未真正理解它们如何指导设计的认知断层。不能度量的东西，就不能有效管理。 复习软件度量，不能只背指标的定义和计算公式，必须追问：为什么环路复杂度可以预测模块的出错概率？因为复杂度高意味着逻辑路径多，测试难覆盖。为什么高内聚低耦合是好的设计？因为内聚高意味着模块职责单一，耦合低意味着修改影响范围小。如何用这些指标指导重构？识别出复杂度高、内聚低的模块，进行拆分或重写。建议制作“度量指标应用档案”，以环路复杂度、扇入扇出、内聚度、耦合度四个指标为横轴，每轴完成三层作业：指标含义、计算方法、如何用该指标评价和改进设计。考场遇“如何识别系统中的‘坏味道’代码”题，你从过高复杂度、过低内聚、过高耦合等多个指标联合分析的角度展开。
