---
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]]

## 相关页面

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