简介：本资源为合肥工业大学计算机与信息学院2020年《软件工程》课程期末考试A卷真题，面向高校计算机类专业本科生及软件工程备考学生，助力系统梳理核心知识点、检验理论掌握深度与应试能力。试卷覆盖需求分析、模块化设计、结构化程序设计、软件测试（单元/验收/边界值/判定覆盖）、软件维护成本、迭代模型对比、总体设计产出、信息隐蔽与模块独立性等关键内容，题型完整，含判断题、选择题、填空题、名词解释与简答题五大类，附带标准答案格式与命题教师信息，具备典型教学权威性与实战训练价值。资源为1个25KB的docx文档，内容排版规范，可直接打印复习或导入笔记工具精读解析。目前已有1802人学习下载，是理解软件工程全生命周期实践要求、强化概念辨析与解题逻辑的优质一手复习资料。

1. 软件工程考试最反直觉的得分点：不是写对代码，而是“不写代码”时答对判断题

你翻过合肥工业大学2020年软件工程A卷，第一反应可能是：“全是概念题？没一道编程？”——这恰恰是它最狠的考点设计。整张卷子6大题型、70分主观题里，真正要动笔写代码的只有最后一道应用题的第3小问（18分），其余62分全靠你对“软件工程黑匣子”的精准拆解：比如判断题第2题“向延晚项目追加人员可能使它更晚”，考的是布鲁克斯定律，但90%考生只记得“人多力量大”，一选就错；再比如选择题第10题用-1.001、-1.0、1.0、1.001这组数测输入X∈[-1.0,1.0]，表面看像边界值，实则暗藏陷阱——-1.001和1.001根本不在等价类内，是典型错误推测法干扰项。这张卷子本质在考三件事：能不能把教科书定义嚼碎了还原成工程现场的决策逻辑；能不能在“没写代码”的前提下，用模块化思维预判代码会怎么崩；能不能把测试用例设计成一张防漏网，而不是凑数清单。它适合两类人：一类是正在啃《软件工程导论》却总被“信息隐蔽”“作用范围”绕晕的本科生；另一类是面试前突击系统设计题、发现“高内聚低耦合”张口就来但画不出结构图的转行人。别急着背UML图谱——先搞懂为什么第4题说“非直接耦合独立性最弱”是错的，你才算摸到及格线。

2. 高频考点：模块化设计与结构化程序设计的底层逻辑链

模块化设计不是贴标签，而是用一套可验证的规则约束代码的“呼吸节奏”。合工大这张卷子把模块独立性拆成四层考：耦合类型、作用范围、信息隐蔽、结构化判定。它们环环相扣，漏掉任一环，判断题和选择题就会集体翻车。

2.1 耦合强度排序：从“非直接耦合”到“内容耦合”的致命误读

题目4明确指出：“如果两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的，这就是非直接耦合。这种耦合的模块独立性最弱。”——这句话前半句对，后半句错。非直接耦合（也称无耦合）是耦合度最低的类型，因为模块间零交互，仅靠主模块调度，就像两个车间共用同一套排班表，但产线完全隔离。而真正独立性最弱的是内容耦合：一个模块直接修改另一个模块的内部数据，或跳转到其内部语句标号。合工大命题教师吴克伟老师在这里埋了认知陷阱——用“非直接”字面误导考生联想“间接=不透明=难维护”，实则工程中“无耦合”才是理想态。真题中若出现类似描述，直接判F。

提示：耦合强度从低到高必须死记硬背：无耦合 < 数据耦合 < 标记耦合 < 控制耦合 < 外部耦合 < 公共耦合 < 内容耦合。其中“标记耦合”指模块间传递的是数据结构（如struct），而非单个变量，比数据耦合更重；“外部耦合”指模块共享外部环境（如全局变量、文件），极易引发隐式依赖。

2.2 模块作用范围 vs 控制范围：画结构图前必过的生死线

题目5：“模块的作用范围包括它本身及其所有的从属模块。”——这是典型混淆概念。作用范围（Scope）指受该模块判定影响的所有模块集合，即一个if语句的条件判断，会影响哪些后续模块执行；而控制范围（Control Scope）指该模块本身及其所有下属模块（直接/间接调用）。二者关系是：作用范围必须全部落在控制范围内，否则结构图存在逻辑断层。例如，若模块A含判定语句，但模块B（不在A的控制范围内）却依赖该判定结果，说明设计违反“作用范围⊆控制范围”原则，需重构。合工大应用题第2问要求画生产科和技术科的软件结构图，本质就是考你能否用此规则校验模块调用链是否合法。

2.3 信息隐蔽：不是“藏起来”，而是“划清责任田”

题目5的干扰项常与信息隐蔽绑定。信息隐蔽（Information Hiding）的核心不是加密数据，而是每个模块只暴露必要接口，隐藏内部实现细节和数据结构。它直接支撑模块独立性——当技术科修改工艺设计算法时，只要输入输出格式不变，生产科无需任何改动。选择题第5题“信息隐蔽概念与（ ）直接相关”，正确答案是A“模块的独立性”，而非C“软件结构定义”。因为结构定义是静态拓扑，而信息隐蔽是动态契约：它规定“谁可以碰什么”，而非“长什么样”。

2.4 结构化程序设计：单入口单出口只是表象，本质是控制流可推演

题目6：“如果一个程序只有一个入口和一个出口，则称这个程序是结构化的。”——错。结构化程序设计的三大基石是顺序、选择、循环，且要求所有控制流路径必须能用这三种结构组合表达，禁止goto跳转。单入口单出口只是必要不充分条件：一个满是嵌套if-else但逻辑混乱的函数，虽满足单入单出，却因路径爆炸无法验证正确性，不算结构化。合工大此处考的是本质认知——结构化的目标是让程序具备数学归纳法可证性，即每条路径都能被穷举、被测试、被追溯。这也是后续基本路径测试（应用题第3问）的理论根基。

2.5 易错题：模块化设计四大失分点

错在哪 → 为什么错 → 怎么答对

1. 混淆“非直接耦合”与“内容耦合”的强弱关系
   错因：望文生义，“非直接”被脑补为“难以追踪”，误以为独立性差。
   正解：耦合强度由模块间依赖深度决定。非直接耦合=零依赖；内容耦合=侵入式修改，后者破坏封装性最彻底。判断题见“非直接耦合独立性最弱”直接打F。

2. 把“作用范围”等同于“调用链长度”
   错因：认为从主模块调用A，A调用B，B调用C，则C的作用范围最大。
   正解：作用范围取决于判定节点的影响域。例如模块A中if (x>0)后调用模块D，而模块E虽在A的调用链末端，却不受该判定影响，则E不在A的作用范围内。画结构图时，先标出所有判定模块，再逆向追踪其影响模块。

3. 将“信息隐蔽”理解为“变量私有化”
   错因：Java里用private修饰字段就以为达成信息隐蔽。
   正解：信息隐蔽是接口级契约。即使字段public，只要模块不暴露内部计算逻辑（如不提供getInternalState()方法），仍算隐蔽；反之，private字段若通过getter/setter暴露过多状态细节（如getBufferPointer()），反而破坏隐蔽性。答题时紧扣“接口最小化”原则。

4. 误判“单入口单出口=结构化”
   错因：忽略结构化对控制流结构的强制要求。
   正解：结构化程序必须能被N-S图（盒图）完整表达。若代码中存在break跳出多层循环、或异常处理中catch块跳转到非结构化位置，即不满足。判断题见此类描述一律判F。

3. 高频考点：软件生命周期模型与需求分析的工程博弈

软件工程不是按部就班走流程，而是不同模型在“确定性”与“响应速度”间的动态权衡。合工大试卷用选择题和简答题撕开模型外衣，逼你看到背后的真实战场：当销售合同突然变更交货期，RUP模型如何用迭代缓冲风险？当用户说不清需求，敏捷过程凭什么敢砍掉详尽文档？

3.1 瀑布模型：线性幻觉下的成本黑洞

选择题第2题问“哪个模型没有采用迭代思想”，答案是A瀑布模型。但陷阱在于——瀑布模型的“无迭代”不是技术缺陷，而是契约选择。它假设需求绝对稳定、技术绝对可控，把“变更成本”前置到合同阶段：一旦签署SOW（工作说明书），后续任何修改都触发商务谈判。合工大命题教师刻意强调这点，暗示考生：不要批判瀑布模型“落后”，而要理解其适用场景——如航天嵌入式系统开发，需求冻结是铁律。而软件维护占生命周期70%费用（选择题第1题），正是瀑布模型在后期暴露的代价：前期省下的分析时间，全在维护期连本带利还回去。

3.2 RUP与敏捷：不是二选一，而是“阶段粒度”的战争

简答题第2题要求比较Rational统一过程（RUP）和敏捷过程。标准答案常罗列“RUP重文档、敏捷重人”，但合工大想听的是阶段压缩逻辑：

• RUP将生命周期划为初始、细化、构建、移交四阶段，每阶段含需求、分析、设计、实现、测试子活动，但各阶段可迭代（如细化阶段内多次迭代完善架构）；
• 敏捷（如Scrum）则将迭代压到1-4周冲刺（Sprint），每个冲刺交付可运行增量，需求在Product Backlog中持续梳理，但不设阶段里程碑。
  关键差异在于：RUP用阶段锚定商业目标（如“细化阶段结束前必须确认核心架构风险已化解”），敏捷用冲刺锚定交付价值（如“本次冲刺必须上线登录页AB测试”）。答题时若只说“RUP重计划”，会被扣分——它重的是风险可控的计划。

3.3 需求分析：不是记录用户说的话，而是翻译“未说出的约束”

题目1：“有了对项目目标的大概了解，便足以开始编写程序，有关细节以后再慢慢了解。”——这是所有新手程序员的血泪经验起点。错因在于混淆“目标”与“约束”。用户说“我要一个电商网站”，目标明确；但约束如“支付接口必须对接银联而非支付宝”“商品列表首屏加载<1s”“支持10万并发”才是需求分析核心。合工大在摘要中强调“需求分析需考虑维护问题”，指向可维护性需求也是需求：如日志格式需兼容运维监控系统、配置参数需支持热更新。填空题第4题“需求分析三类模型”答案为“数据模型、功能模型、行为模型”，其中行为模型（如状态图、活动图）正是捕捉约束的利器——GUI状态转换图（应用题第1问）本质就是把“用户操作序列+系统响应规则”转化为可验证的状态机。

3.4 可行性研究：经济可行性常被低估的“死亡红线”

填空题第3题考可行性研究三方面：技术、经济、操作。学生易漏“操作可行性”，但合工大命题深意在此：技术上能做≠业务上愿用。例如某厂要上MES系统，技术团队证明可行，但一线工人拒绝录入数据（操作不可行），系统即成废铁。经济可行性更残酷——选择题第1题“软件维护费用最高”，暗示前期投入再少，若维护成本失控（如架构腐化致每次改bug耗3天），项目终将破产。答题时若只写“成本收益比”，需补一句：“须包含隐性成本，如知识转移耗时、供应商锁定风险”。

3.5 易错题：生命周期与需求分析的隐形地雷

错在哪 → 为什么错 → 怎么答对

1. 认为“敏捷过程不需要需求文档”
   错因：将“轻量文档”误解为“零文档”。
   正解：敏捷用User Story替代传统SRS，但Story需含验收标准（Acceptance Criteria），本质是结构化需求。简答题若答“敏捷不要求需求分析”，直接不得分。应答：“以用户故事为载体，在每次Sprint计划会中动态细化需求”。

2. 把“RUP的迭代”等同于“敏捷迭代”
   错因：忽略RUP迭代服务于阶段目标，敏捷迭代服务于交付价值。
   正解：RUP中一次迭代可能只产出架构原型（无用户价值），敏捷中每次迭代必须交付可演示功能。比较时必提：“RUP迭代是阶段内的风险缓冲，敏捷迭代是价值交付单元”。

3. 需求分析只关注用户显性需求
   错因：未识别隐性约束（如合规、性能、安全）。
   正解：题目1的纠错关键在“细节”二字——细节即约束。答题需举例：“如医疗软件需符合HIPAA隐私规范，此为隐性需求，必须纳入需求规格说明书”。

4. 混淆“可行性研究”与“需求分析”的输入输出
   错因：认为可行性报告就是需求文档初稿。
   正解：可行性研究输入是初步想法，输出是“做不做”的决策；需求分析输入是可行性结论，输出是“做成什么样”的规格说明书。填空题若将“可行性研究”答成需求分析步骤，全错。

4. 高频考点：软件测试覆盖策略与缺陷定位的数学本质

测试不是“多跑几遍”，而是用数学工具在无限输入空间中撒网捕鱼。合工大试卷把测试考点浓缩成三把刀：覆盖准则的逻辑关系（判断题第9题）、测试用例设计方法的本质（选择题第10题）、基本路径测试的机械可执行性（应用题第3问）。掌握它们，你就拿到了打开质量大门的密钥。

4.1 判定覆盖 vs 条件覆盖：布尔代数里的独立王国

判断题第9题：“判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖。”——这是唯一全对的判断题，也是整卷最难啃的骨头。判定覆盖（Decision Coverage）要求每个判定（if/while的真假分支）至少执行一次；条件覆盖（Condition Coverage）要求每个条件（a>0、b<5等原子布尔表达式）的真假值各取一次。二者不等价，根源在于判定是条件的逻辑组合。例如：

if (a > 0 and b < 5): # 判定为真需a>0且b<5同时成立

• 判定覆盖：用(a=1,b=4)→真，(a=-1,b=6)→假，即覆盖；
• 条件覆盖：需a>0、a≤0、b<5、b≥5各一次，但(a=1,b=4)只覆盖a>0和b<5，(a=-1,b=6)只覆盖a≤0和b≥5，看似满足，实则漏了a>0+b≥5、a≤0+b<5的组合——这正是条件组合覆盖（Multiple Condition Coverage）的要求。合工大用此题警告：别迷信“覆盖”二字，先看清覆盖对象是“判定”还是“条件”。

4.2 边界值分析：不是测边界，而是测“边界附近的失效模式”

选择题第10题给X∈[-1.0,1.0]，测试用例-1.001,-1.0,1.0,1.001，问设计方法。答案是C边界值分析法，但陷阱在于：边界值分析法默认测试点为边界值±1（或最小增量），-1.001和1.001正是-1.0和1.0的“下溢/上溢”点。而错误推测法（D）是凭经验猜bug，如“程序员可能把>=写成>”，需针对性设计（如X=-1.0时检查是否被拒）。此处-1.001明显是浮点精度失效的典型场景，属边界值范畴。答题关键：边界值分析针对输入域端点，错误推测法针对代码弱点。

4.3 基本路径测试：用圈复杂度切割程序，让测试可穷举

应用题第3问是全卷分值最高（18分）、最体现工程能力的题。它要求对PDL伪码求平均值程序：
① 画程序图/N-S图/PAD图；
② 计算McCabe环路复杂度；
③ 求独立路径集；
④ 设计测试用例。
核心是McCabe公式：V(G) = E - N + 2P（E边数、N节点数、P连通分量数），对单入口单出口程序简化为判定节点数+1。本题PDL中：

• DO WHILE（行2）是判定节点；
• IF（行5）是判定节点；
• 行10的IF是判定节点；
  故V(G)=3+1=4，需4条独立路径。独立路径必须包含至少一条新边，常见错误是列出4条路径却重复覆盖同一条边。正确路径应覆盖：

1. 全不进入循环（value[1]=-999）；
2. 进入循环但全无效（value[i]均超出[min,max]）；
3. 进入循环且部分有效（sum>0）；
4. 进入循环且全有效（total.valid=total.input）。

4.4 单元测试的80%神话：被严重误读的统计学真相

判断题第7题：“单元测试能发现约80%的软件缺陷。”——此说法流传甚广，但合工大标准答案为T，需谨慎理解。这里的80%指在编码阶段引入的缺陷中，单元测试可捕获的比例，不包括需求错误、架构缺陷等上游问题。更关键的是：80%的前提是“高质量单元测试”，即满足：

• 每个函数有对应测试用例；
• 覆盖所有分支（判定覆盖≥100%）；
• 输入包含边界值、非法值、正常值；
• 测试用例与代码同步更新。
  现实中，若只测happy path（主流程），覆盖率可能不足20%。答题时若只写“T”，建议补注：“指在严格遵循测试规范前提下，对编码缺陷的检出率”。

4.5 易错题：测试策略的五大认知断层

错在哪 → 为什么错 → 怎么答对

1. 认为“路径覆盖=100%测试”
   错因：路径覆盖仅保证每条执行路径跑过，不保证路径内数据状态正确。
   正解：路径覆盖是基础，还需数据流覆盖（如def-use链）。判断题若见“路径覆盖能发现所有缺陷”，必判F。

2. 混淆“验收测试”与“系统测试”的执行主体
   错因：以为都是用户参与。
   正解：系统测试由开发方测试工程师执行，验证整体功能；验收测试由用户或客户代表执行，验证是否满足合同需求。题目8“验收测试由最终用户实施”为T，但需注意“最终用户”指签约方代表，非泛指所有使用者。

3. 将“等价类划分”用于非数值输入
   错因：只记得数字区间划分，忽略字符串、状态机等。
   正解：等价类适用于任何有明确分类的输入。如登录用户名：有效类（6-12位字母数字）、无效类（空、超长、含特殊字符）。选择题若选项含“等价类只用于数值”，直接排除。

4. 误以为“单元测试=函数测试”
   错因：忽略集成层面的单元交互。
   正解：单元测试对象是“可独立编译的最小单元”，对Java是class，需Mock外部依赖。填空题第8题“单元测试相关文档”答案为“详细设计说明书”，因其定义模块接口契约。

5. 用“错误推测法”替代系统化测试设计
   错因：依赖个人经验，缺乏可复现性。
   正解：错误推测法是补充手段，必须基于边界值、等价类等主干方法。应用题若只写“我猜这里会错”，不得分；需写“根据边界值分析，X=-1.001可能触发浮点溢出，故设计用例...”。

5. 高频考点：面向对象建模与UML图谱的实战映射

UML不是画图比赛，而是用标准化图形翻译人类语言需求。合工大试卷把UML考点压进选择题第8题（包图）、名词解释第5题（UML）、应用题第1问（状态图），直击痛点：为什么用包图？状态图里“退出命令”该画成事件还是动作？

5.1 包图（Package Diagram）：主题划分的物理容器

选择题第8题：“表示主题划分的建模图形是（ ）”，答案A包图。但学生常错选C顺序图，因混淆“主题”与“交互”。包图的核心价值是“命名空间管理”：它把逻辑相关的类、用例、子系统打包，解决大型系统命名冲突和依赖管理。例如，技术科的“产品结构设计”和“工艺设计”可划为DesignPackage，生产科的“月计划制定”和“周计划分解”划为ProductionPackage，二者通过接口（如DesignResultInterface）通信。这正是填空题第2题“面向对象软件工程采用（ ）模型”的答案——RUP模型，因其天然支持包图组织迭代产物。

5.2 状态图（State Diagram）：捕捉GUI的“不可言说”规则

应用题第1问要求画GUI状态转换图，含主菜单、文件菜单、退出命令。易错点在于：“退出命令”不是状态，而是触发状态迁移的事件。正确画法：

• 状态：MainMenu（主菜单显示）、FileMenu（文件菜单展开）、OpenDialog（打开文件对话框）、ExitConfirm（退出确认弹窗）；
• 事件：ClickFile（点击文件菜单）、ClickOpen（点击打开）、ClickExit（点击退出）；
• 动作：ShowFileMenu()、OpenFile()、ShowExitDialog()。
  关键规则：每个状态必须有明确进入/退出动作，事件必须标注在箭头旁。若画成“主菜单→退出命令→关闭”，即违反UML语义——退出命令是事件，关闭是动作，状态迁移需经ExitConfirm中间态（因需用户二次确认）。

5.3 UML五层抽象：从领域到代码的降维路径

填空题第9题：“对象模型五个层次：（ ）、类与对象层、结构层、属性层、服务层。”答案是主题层。这五层是面向对象分析的思维脚手架：

• 主题层：识别业务领域核心概念（如“电器集团”“生产计划”）；
• 类与对象层：将主题具象为类（ProductionPlan）和实例（2020Q3Plan）；
• 结构层：定义类间关系（ProductionPlan关联ProductDesign）；
• 属性层：描述类特征（Plan.startDate, Plan.status）；
• 服务层：定义类行为（Plan.generateSchedule()）。
  合工大此处考的是建模顺序——必须从主题层出发，避免过早陷入属性细节。

5.4 PDL伪码：结构化设计的最后防线

选择题第7题：“PDL是指（ ）”，答案A伪码。PDL（Process Design Language）是介于自然语言和编程语言间的桥梁，其价值在于：让设计者专注逻辑，不被语法绑架。应用题第3问的PDL代码：

PROCEDURE Average; INTERFACE RETURNS average, total.input, total.valid; INTERFACE ACCEPTS value, minimum, maximum; ...

INTERFACE声明清晰定义了模块契约，比代码注释更可靠。答题时若被问“为何用PDL不用流程图”，答：“PDL可直接映射为代码骨架，减少设计到编码的语义损耗”。

5.5 易错题：UML与建模的四大实践误区

错在哪 → 为什么错 → 怎么答对

1. 把“包图”当成“模块图”
   错因：认为包图等同于软件结构图（如模块调用图）。
   正解：包图描述逻辑分组，结构图描述物理调用。包图中DesignPackage可包含多个类，但不指定调用顺序；结构图中ProductionModule必须标明调用DesignModule。选择题若混淆，选错。

2. 状态图遗漏“历史状态”
   错因：GUI返回主菜单时，应恢复之前状态（如文件菜单展开态）。
   正解：UML支持H（浅历史）和H*（深历史）伪状态。应用题若只画线性状态流（MainMenu→FileMenu→Exit），未处理“从OpenDialog返回MainMenu”，扣分。

3. 误将“用例图”用于描述系统内部流程
   错因：用例图主角是Actor（用户），非系统模块。
   正解：技术科任务描述属系统内部流程，应画活动图（Activity Diagram），而非用例图。名词解释若答“UML用例图描述用户需求”，正确；若答“描述模块交互”，错误。

4. PDL中混用编程语言语法
   错因：写for(i=1;i<=100;i++)而非DO WHILE。
   正解：PDL禁用具体语言语法，用DO WHILE、IF...THEN...ENDIF等通用结构。填空题若将PDL答成“高级语言”，不得分。

6. 答题技巧：用“三遍审题法”拿下应用题，把30分变成保底分

应用题占30分，是合工大试卷的胜负手。它不考死记硬背，而考你能否把零散知识点拧成一股绳——比如画GUI状态图（4分），表面考UML，实则考你是否理解“退出命令”是事件而非状态；画生产科结构图（4分），表面考模块设计，实则考你是否吃透“作用范围⊆控制范围”原则。我带过的学生里，80%失分不是不会，而是没把题干当工程需求文档读。下面这套“三遍审题法”，是我从合工大历年真题里榨出来的血泪经验。

6.1 第一遍：划出所有“角色-动作-约束”三角组

拿到应用题，先拿笔圈出三个要素：

• 角色：谁在做事？（如“生产科”“技术科”“用户”）；
• 动作：做什么事？（如“制定月生产计划”“调整月生产计划”“产生装配图”）；
• 约束：有什么限制？（如“每次只有一个文件能够打开”“以月生产计划为依据”“根据组装计划进行”）。
  以应用题第2问为例：
• 角色：生产科（主）、技术科（次）、销售公司（上游）、供应科（下游）；
• 动作：生产科“制定→调整→制定→传达→分解”，技术科“进行→产生→进行→产生”；
• 约束：“根据销售公司转来的内部合同”“以月生产计划为依据”“根据组装计划进行”。
  这一步做完，你已自动完成需求提取——后续画图只是把三角组可视化。

6.2 第二遍：用“模块契约表”锁定接口与数据流

把每个角色的动作转化为模块，并填写契约表。以生产科为例：

注意：表中“调用模块”指本模块主动调用谁，“被调用模块”指谁调用本模块。填空时若颠倒，结构图必然错。

6.3 第三遍：用“路径验证法”检查图的逻辑闭环

画完结构图，别急着交卷，用三句话验证：

1. 每个模块是否有明确输入输出？（如“传达计划”模块若只写“传给技术科”，没写“传什么”，扣分）；
2. 每个判定节点的作用范围是否全在控制范围内？（如“调整月计划”模块含if判断，其影响模块必须是它的子模块）；
3. 是否存在悬空箭头？（如生产科模块指向“零件厂”，但题干未提零件厂是本系统模块，属越界设计）。

6.4 应用题实战：平均值程序的“四步拆解模板”

应用题第3问18分，按步骤拆解：
① 程序图/N-S图/PAD图（6分）

• 程序图：用圆圈标节点（1,2,3...），箭头标流向，判定节点双圈；
• N-S图：用矩形嵌套，DO WHILE用循环框，IF用选择框；
• PAD图：用二维树状图，左缩进表嵌套，DO WHILE用循环符号。

关键：所有图必须严格按PDL行号标注，行2是DO WHILE起始，行9是结束，行10是新判定。

② McCabe环路复杂度（2分）

• 公式：V(G) = 判定节点数 + 1 = 3（行2、5、10）+ 1 = 4；
• 或用图算法：E=12, N=10, P=1 → V(G)=12-10+2=4。

③ 独立路径（4分）

• 路径1：1→2（value[1]=-999）→10→11→13；
• 路径2：1→2→3→4→5→6→7→8→9→10→12→13；
• 路径3：1→2→3→4→5→6→7→8→9→10→11→13；
• 路径4：1→2→3→4→5→6→7→8→9→10→11→13（覆盖total.valid=0分支）。

注意：路径3和4区别在循环内是否执行sum+=value[i]，需用不同输入触发。

④ 测试用例（6分）

• 路径1：value=[-999,...] → total.valid=0；
• 路径2：value=[-2,-2,...]（全无效）→ sum=0；
• 路径3：value=[0,0,...]（全有效）→ average=0；
• 路径4：value=[0,1,...]（部分有效）→ average=0.5。

每个用例需写明：输入数组、minimum/maxmum值、预期average。

从那以后我每次带学生刷应用题，都强制他们先抄三遍题干，再动手画图。不是为了磨时间，而是让大脑把文字需求翻译成工程信号——当“销售公司转来内部合同”在你脑子里自动变成“输入数据流”，当“调整月生产计划”浮现为“模块间反馈环”，30分就不再是玄学，而是可拆解、可验证、可复制的肌肉记忆。希望帮到你。

本文还有配套的精品资源，点击获取