title: 软件工程关键过程与设计 tags:

module
software-engineering
design
joplin type: module source_type: reconstructed created: 2026-04-23 updated: 2026-04-23 ---

软件工程关键过程与设计

[!abstract] 这一模块聚焦生命周期中最容易出题、也最容易决定项目质量的部分：需求分析、建模、结构化设计与模块划分。

模块结论

关键过程不是机械阶段名，而是一套从问题澄清到结构落地的转换链路。
需求分析的核心是把模糊需求转成结构化表达，比如 DFD、E-R 图、用例图。
设计阶段的核心不是“画图”，而是借由模块划分和接口组织控制复杂度。
[[高内聚低耦合]] 是模块独立性的核心判断标准。

一、可行性研究

目标：判断项目值不值得做、能不能做。
常见维度：
- 经济可行性
- 技术可行性
- 操作可行性

可行性研究在流程中的位置

它发生在需求细化之前。
如果可行性判断失误，后续需求和设计再精细也可能建立在错误前提上。

二、需求分析

核心任务：
- 明确功能需求
- 明确性能和约束要求
- 明确数据需求
- 确定系统边界和外部交互

常见建模工具

数据流图 DFD：描述数据如何流动、加工和存储。
数据字典：统一数据元素定义。
E-R 图：描述实体、属性和联系，偏向数据库逻辑建模。
用例图：从参与者视角描述系统功能边界。

这些工具分别解决什么问题

DFD 强调过程和流动。
E-R 图强调数据结构。
用例图强调系统功能和使用者关系。

三、设计阶段

概要设计

决定系统结构、模块划分、接口关系和层次组织。
输出通常包括结构图、层次图、模块说明。

详细设计

落到具体算法、处理流程和数据结构细节。
常见表达包括流程图、PAD 图或伪代码。

四、模块化与独立性

模块化的目标是把复杂系统拆成可理解、可实现、可维护的部分。
理想状态是模块内部职责集中，对外依赖尽量简单稳定。

耦合

描述模块之间联系的紧密程度。
一般希望耦合尽量低。
常见次序可按从较优到较差理解为：数据耦合、控制耦合、公共耦合、内容耦合。

内聚

描述模块内部功能的一致性和集中程度。
一般希望内聚尽量高。
常见次序可按从较差到较优理解为：偶然内聚、逻辑内聚、时间内聚、功能内聚。

为什么强调高内聚低耦合

高内聚让模块职责清晰，更容易理解和修改。
低耦合让局部变更不至于牵连全局。
它本质上是在控制变化传播范围。

五、设计启发原则

模块规模适中，避免过大难维护或过碎难组织。
扇入扇出合理，避免一个模块依赖过多下层模块。
控制范围和作用范围尽量一致，减少隐藏副作用。
通过抽象和信息隐藏减少外部对内部实现细节的依赖。

六、易错点

需求分析不是把用户原话抄下来，而是把需求结构化、模型化。
E-R 图和 DFD 解决的问题不同，不要混用。
高内聚低耦合不是口号，答题时要能说明它如何影响维护和扩展成本。

七、复习提问

可行性研究为什么不能跳过？
DFD、E-R 图、用例图分别最适合描述什么？
为什么“模块独立性”会直接影响后续测试和维护难度？

来源

[[raw/Joplin/计算机专业基础/软件工程/_软件工程考研复试终极整理版.md]]
[[raw/Joplin/计算机专业基础/软件工程/3.软件工程——关键过程与工具.md]]

相关页面

[[软件工程]]
[[软件测试与维护]]
[[高内聚低耦合]]