1. 从一份作业标题看总体设计的真实分量
“《软件工程》第五章 总体设计 作业”——这个标题看起来平平无奇，甚至有点像教务系统里复制出来的任务条目。但如果你正在学软件工程，或者正在带团队做项目，看到“总体设计”这四个字，应该会有点条件反射式的紧张。因为这一章讲的东西，直接决定了一个软件项目是“盖成大楼”还是“搭成危房”。
我带过不少刚入行的开发者，也帮一些朋友看过他们的课程设计。一个很普遍的现象是：很多人拿到需求之后，第一反应就是打开编辑器开始写代码，数据库表先建起来，接口先定义几个，页面先画出来。结果做到一半发现模块之间耦合严重，改一个功能牵动三四个文件，数据库字段频繁变更，前端后端互相甩锅。这种局面的根源，往往不是编码能力不行，而是总体设计这一步被跳过了，或者做得太草率。
总体设计要解决的问题，说白了就是：在动手写代码之前，先把系统拆成几个大的部分，想清楚每个部分负责什么、它们之间怎么通信、数据怎么流动、哪些东西是核心哪些是辅助。它不关心某个函数怎么写、某个类怎么定义，那是详细设计的事。总体设计关心的是“骨架”和“接口”。
这份作业通常要求学生完成几个核心任务：需求分析到设计模型的转换、系统功能模块划分、模块间调用关系设计、数据流设计、接口设计，以及设计文档的撰写。不同教材和课程的具体要求会有差异，但核心逻辑是一致的——让你体验一次“从问题域到解空间”的完整推演过程。
这篇文章我会围绕这份作业展开，把总体设计到底该怎么做、每一步背后的逻辑是什么、有哪些容易踩的坑、怎么写出让老师或评审眼前一亮的文档，全部拆开来讲。无论你是正在赶作业的学生，还是想补一补设计基本功的开发者，应该都能从中找到可以直接用的东西。
2. 总体设计到底在设什么：核心任务与底层逻辑
2.1 总体设计的边界：它不做什么，比它做什么更重要
很多人对总体设计有误解，觉得它就是把详细设计提前做一遍，或者画几张架构图交差。实际上，总体设计有非常明确的边界。
它不做的事情包括：不定义具体的类和方法签名、不写算法伪代码、不设计数据库表的每个字段类型、不规定前端用什么组件库。这些都属于详细设计的范畴。总体设计如果陷得太深，会导致两个问题：一是设计周期拉长，二是过早锁定实现细节，反而限制了后续的优化空间。
它要做的事情，我习惯用“四个定”来概括：定模块、定接口、定数据、定约束。定模块是把系统拆成高内聚低耦合的功能单元；定接口是明确模块之间通过什么方式交换信息；定数据是梳理核心数据实体及其流转路径；定约束是记录技术选型、性能指标、部署环境等限制条件。
这个边界感非常重要。你在写作业的时候，如果老师给的评分标准里有“设计粒度是否合适”这一项，那基本就是在考察你有没有守住这个边界。粒度太粗，等于没设计；粒度太细，等于越界做了详细设计的事。
2.2 为什么总体设计决定了项目的“可修改性”
软件工程里有一个残酷的现实：需求一定会变。不管你在需求分析阶段做了多少访谈、写了多少用例，到了开发中后期，总会有新的需求冒出来，或者原有需求被推翻。这时候，一个系统的“可修改性”就决定了它是能快速响应变化，还是直接推倒重来。
总体设计的核心价值，就是通过合理的模块划分和接口设计，把变化的影響控制在局部。举个例子：假设你把“用户认证”和“订单处理”写在一个模块里，某天认证方式要从账号密码改成手机验证码，你就得动订单相关的代码。但如果你在总体设计阶段就把认证抽成独立模块，通过接口对外提供服务，那认证方式的变更就只需要改这一个模块，订单模块完全不受影响。
这就是为什么总体设计强调“高内聚、低耦合”。高内聚是指一个模块内部的功能要紧密相关，不要什么都往里塞；低耦合是指模块之间尽量少依赖，依赖也要依赖接口而不是实现。这两个原则听起来简单，做起来需要反复权衡。
2.3 从需求到设计的映射：怎么把“做什么”翻译成“怎么做”
总体设计的第一步，是把需求分析阶段产出的东西（用例图、数据流图、需求规格说明）转换成设计模型。这个转换过程不是机械的，需要设计者做出判断和取舍。
一个常用的方法是：从数据流图导出模块结构图。数据流图描述的是数据在系统中的加工和流动，而模块结构图描述的是功能模块的层次关系。转换的核心思路是：把数据流图中的每个“加工”映射为一个模块，把数据流映射为模块间的调用或数据传递。
但这里有一个关键决策：是“以变换为中心”还是“以事务为中心”。变换型数据流图有明显的输入、变换、输出三段，适合映射成“输入模块—处理模块—输出模块”的结构；事务型数据流图有一个事务中心，根据事务类型分派到不同处理路径，适合映射成“调度模块+多个事务处理模块”的结构。
实际项目中的数据流图往往是混合型的，需要你先识别出主导类型，再决定顶层结构。这个判断过程，就是总体设计中最考验经验的地方。我见过不少作业，直接把数据流图原样抄一遍，然后画几条线连起来，这等于没做设计。
3. 模块划分的实操方法：从混沌到清晰
3.1 模块划分的三种常用策略及适用场景
模块划分不是随便切蛋糕，不同的划分策略适用于不同的系统类型。我总结下来，最常用的有三种：
按功能划分：这是最直观的方式，每个模块对应一组相关的功能。比如电商系统分成用户模块、商品模块、订单模块、支付模块。优点是结构清晰，容易理解；缺点是如果某个功能横跨多个业务领域，可能会被拆散。
按数据划分：以核心数据实体为中心来组织模块。比如以“用户”为中心，把用户信息管理、用户行为记录、用户偏好设置都放在一个模块里。优点是数据一致性容易保证；缺点是可能导致功能分散。
按层次划分：把系统分成表现层、业务逻辑层、数据访问层。这是分层架构的基础，优点是职责分明，便于替换某一层的实现；缺点是层与层之间的接口设计需要格外小心，否则会变成“过度分层”。
在实际作业中，我建议采用功能划分为主、层次划分为辅的混合策略。先按业务功能切出大模块，再在每个模块内部按层次组织。这样既保证了业务边界的清晰，又保留了技术实现的灵活性。
3.2 耦合与内聚的量化判断：别只凭感觉
“高内聚低耦合”这句话谁都会说，但怎么判断一个设计是不是真的做到了？这里给几个可操作的判断标准。
耦合程度从低到高可以分为：非直接耦合、数据耦合、标记耦合、控制耦合、外部耦合、公共耦合、内容耦合。总体设计阶段，至少要保证模块间是数据耦合——即一个模块调用另一个模块时，只传递简单的数据参数，不传递控制信息，不共享全局变量。
内聚程度从高到低可以分为：功能内聚、顺序内聚、通信内聚、过程内聚、时间内聚、逻辑内聚、偶然内聚。总体设计阶段，每个模块至少应该达到通信内聚——即模块内的各个部分操作同一组数据。
你可以拿这个标准去检查自己的模块结构图：如果两个模块之间传递的是整个对象或者复杂数据结构，考虑能不能拆成更简单的参数；如果一个模块里塞了七八个不相关的功能，考虑能不能拆成多个模块。
3.3 模块结构图怎么画才专业
模块结构图是总体设计文档的核心产出之一。它不是随便画几个框连几条线就行，有几个规范需要注意。
首先，模块结构图是层次结构，顶层是主控模块，下层是被调用模块。箭头表示调用关系，不是数据流向。数据流向通常用带注释的箭头或者单独的数据流图来表示。
其次，每个模块要标注模块名和功能说明。模块名用动宾结构，比如“验证用户身份”“计算订单总价”，不要用“用户模块”“订单模块”这种模糊的命名。
再次，模块之间的调用关系要标注调用类型。是顺序调用、选择调用还是循环调用？这决定了模块的执行逻辑。
最后，如果模块间传递数据，要在调用箭头上标注数据参数。这一步很多人会省略，但它是后续详细设计和测试用例设计的重要依据。
注意：模块结构图不是流程图，不要画成从上到下的执行顺序。它是静态的结构关系，执行顺序由调用逻辑决定。
4. 接口设计与数据设计：让模块真正能协作
4.1 接口设计的三个层次：从粗到细
接口设计是总体设计中最容易被轻视的部分。很多人觉得“接口嘛，就是定义几个函数”，结果到了集成阶段发现模块之间根本对不上。
接口设计其实有三个层次：
第一层是模块接口，定义模块对外提供哪些操作、需要哪些输入、产生哪些输出。这一层在总体设计阶段完成，通常用接口清单或接口表来记录。
第二层是数据接口，定义模块之间传递的数据结构。比如订单模块调用支付模块时，传递的是一个包含订单号、金额、支付方式的支付请求对象。这一层需要明确字段名、类型、约束条件。
第三层是协议接口，定义模块之间通信的技术协议。如果是本地调用，可能是函数签名；如果是远程调用，可能是HTTP接口或消息队列。这一层在总体设计阶段可以只做选型，具体协议格式留到详细设计。
我建议在作业中至少完成前两层。每个接口用一张表来描述，包含接口名称、调用方、被调用方、输入参数、输出参数、异常情况。这样后续做详细设计和测试的时候，直接拿这张表就能用。
4.2 数据流设计：别让数据在系统里迷路
数据流设计要回答的问题是：核心数据从哪来、经过哪些模块、发生什么变化、最终到哪去。
一个实用的方法是画数据流图的细化版本。在需求分析阶段，数据流图可能只画到“加工”级别；在总体设计阶段，要把每个“加工”对应到具体的模块，并标注数据存储的位置。
比如一个在线考试系统，核心数据“试卷”的流转路径可能是：教师模块创建试卷→题库模块抽取题目→组卷模块生成试卷结构→存储模块持久化→考试模块加载试卷→判分模块读取答案。每一步都要明确数据形态的变化。
这里有一个容易忽略的点：数据的所有权。每个数据实体应该有一个明确的“属主模块”，其他模块只能通过接口访问，不能直接修改。这能有效避免数据不一致的问题。
4.3 接口设计检查清单
在完成接口设计后，用下面这个清单自查一遍：
- 每个模块是否都有明确的对外接口？
- 接口的输入输出是否都是简单数据类型或明确定义的数据结构？
- 是否存在循环调用？如果存在，是否可以通过引入中间模块或事件机制来消除？
- 接口的异常情况是否都有定义？调用方是否知道如何处理？
- 接口的命名是否清晰表达了意图？是否避免了“doSomething”“handleData”这类模糊命名？
- 接口的粒度是否合适？是否出现了“一个接口做太多事”或“一个功能拆成太多接口”的情况？
5. 完整实操：从需求到总体设计文档的推演过程
5.1 以一个模拟项目为例：在线课程学习系统
为了把前面的方法串起来，我以一个模拟项目为例，完整走一遍总体设计的过程。项目背景是：某在线教育平台需要开发一个课程学习系统，支持课程浏览、选课、视频学习、作业提交、学习进度跟踪等功能。
需求分析阶段已经产出了用例图和数据流图。现在要做的是：划分模块、设计接口、梳理数据流、撰写设计文档。
5.2 第一步：识别核心功能域
先把需求中提到的功能列出来，然后归类：
- 课程相关：课程浏览、课程详情、课程搜索
- 选课相关：选课、退课、选课记录
- 学习相关：视频播放、学习进度记录、学习时长统计
- 作业相关：作业提交、作业批改、成绩查询
- 用户相关：登录、注册、个人信息管理
归类之后，可以初步确定五个核心功能域：课程管理、选课管理、学习管理、作业管理、用户管理。
5.3 第二步：确定模块层次结构
顶层是系统主控模块，负责初始化和模块调度。第二层是五个核心功能模块。第三层是每个功能模块内部的子模块。
以“学习管理”模块为例，内部可以拆成：视频播放控制、进度记录、时长统计三个子模块。视频播放控制负责与播放器交互，进度记录负责将学习位置持久化，时长统计负责累计学习时间。
这里要注意：子模块的划分要基于功能相关性，而不是基于代码复用。如果两个功能虽然都用到了同一个工具类，但业务上不相关，不应该放在同一个模块里。
5.4 第三步：定义模块接口
以“选课管理”模块为例，它对外提供的接口可能包括：
| 接口名称 | 输入 | 输出 | 异常 |
|---|---|---|---|
| 查询可选课程 | 用户ID、课程分类、分页参数 | 课程列表 | 用户不存在 |
| 提交选课 | 用户ID、课程ID | 选课结果 | 课程已满、重复选课 |
| 取消选课 | 用户ID、课程ID | 取消结果 | 未选课、超过取消期限 |
| 查询选课记录 | 用户ID、学期 | 选课记录列表 | 用户不存在 |
每个接口都要明确输入输出的数据结构。比如“课程列表”是一个数组，每个元素包含课程ID、课程名、教师名、学分、剩余名额等字段。
5.5 第四步：梳理核心数据流
以“作业提交”这个场景为例，数据流是这样的：
学生在前端选择作业文件→作业管理模块接收提交请求→校验文件格式和大小→调用存储模块保存文件→更新作业提交记录→通知批改模块有新作业待批改→批改模块更新批改队列。
这个过程中，数据经历了“文件流→存储路径→提交记录→批改任务”的形态变化。每个环节的输入输出都要在设计中明确。
5.6 第五步：撰写总体设计文档
总体设计文档通常包含以下章节：
- 引言：目的、范围、术语定义、参考资料
- 总体设计概述：设计目标、设计原则、技术选型
- 模块划分：模块结构图、模块清单、模块功能说明
- 接口设计：接口清单、接口详细定义
- 数据设计：核心数据实体、数据流图、数据字典
- 运行设计：部署架构、运行环境、性能考虑
- 出错处理：异常分类、处理策略
- 安全设计：认证、授权、数据保护
写文档的时候，有一个原则：让一个没参与需求分析的人，只看这份文档就能理解系统怎么工作。如果你写完文档，别人还要问你“这个模块到底干嘛的”，那说明文档没写清楚。
6. 常见问题与避坑指南
6.1 模块划分太粗或太细怎么办
这是最常见的问题。太粗的典型表现是：一个模块叫“业务处理模块”，里面什么都干。太细的典型表现是：每个函数都单独成一个模块，模块结构图有七八层。
判断标准很简单：一个模块应该能用一句话说清楚它的职责，且这句话里不包含“和”“以及”“等”这类并列词。如果一句话说不清楚，说明太粗；如果一句话就能说清楚，但模块数量超过二十个，可能太细。
调整方法：太粗就按功能相关性拆分，太细就按调用关系合并。合并的原则是：如果两个模块总是一起被调用，且它们操作同一组数据，可以考虑合并。
6.2 接口定义模糊导致集成困难
接口定义模糊的典型表现是：参数类型写“对象”“数据”“字符串”，没有具体结构；返回值写“成功/失败”，没有错误码；异常情况写“其他异常”，没有分类。
解决方法是：把接口当成一份合同来写。调用方需要知道传什么、被调用方需要知道收什么、双方需要知道出错了怎么办。每个参数都要有名称、类型、是否必填、取值范围；每个返回值都要有结构定义；每个异常都要有错误码和含义说明。
6.3 数据流图与模块结构图对不上
这个问题通常是因为画图的时候没有对照检查。数据流图里的某个“加工”在模块结构图里找不到对应的模块，或者模块结构图里的某个模块在数据流图里没有数据来源。
解决办法是：画完两张图之后，做一次交叉验证。逐个检查数据流图中的加工是否都有模块对应，逐个检查模块结构图中的模块是否都有数据输入输出。对不上的地方，要么是需求理解有偏差，要么是设计遗漏。
6.4 设计文档写成“需求复述”
有些作业的设计文档，读起来像是把需求规格说明书换了个标题。模块划分就是把用例图里的用例名抄一遍，接口设计就是把用例描述里的步骤抄一遍。这种文档没有体现“设计”的价值。
设计文档应该体现决策过程。比如：为什么选择按功能划分而不是按数据划分？为什么这个接口设计成同步调用而不是异步消息？为什么这个数据实体放在这个模块而不是那个模块？这些决策的理由，才是设计文档的核心内容。
6.5 常见问题速查表
| 问题现象 | 可能原因 | 排查思路 | 解决方向 |
|---|---|---|---|
| 模块结构图层次混乱 | 划分策略不统一 | 检查是否混用了多种划分策略 | 统一按功能或按层次划分 |
| 接口参数过于复杂 | 模块职责不清 | 检查模块是否承担了过多职责 | 拆分模块，简化接口 |
| 数据流图出现数据黑洞 | 数据来源或去向未定义 | 追踪每个数据的产生和消费 | 补充数据存储或外部实体 |
| 模块间循环调用 | 职责边界模糊 | 分析调用链，找到循环点 | 引入中间模块或事件机制 |
| 设计文档无法指导开发 | 设计粒度过粗 | 检查每个模块是否有明确接口 | 补充接口定义和数据设计 |
提示：做总体设计作业的时候，建议先用手绘草图把模块结构和数据流画出来，反复调整几轮之后再录入电子文档。直接在工具里画图，容易被工具的操作分散注意力，反而忽略了设计本身的逻辑。
7. 一些来自实际项目的经验补充
7.1 设计评审时最容易被问到的三个问题
如果你把这份作业当成一次模拟的设计评审，那有三个问题是评审者最常问的：
第一，“这个模块为什么存在？”——如果你答不上来，说明这个模块可能是多余的，或者职责不清晰。
第二，“这两个模块之间为什么要这样调用？”——如果你答不上来，说明接口设计缺乏依据，可能是凭感觉画的。
第三，“如果这个需求变了，哪些模块需要改？”——如果你答不上来，说明模块划分没有考虑可修改性，耦合可能太紧。
提前准备好这三个问题的答案，你的设计文档质量会提升一个档次。
7.2 总体设计不是一次性的
很多人以为总体设计做完就完了，后面直接进入编码。实际上，总体设计是一个迭代的过程。在详细设计和编码阶段，你可能会发现某些模块划分不合理，某些接口定义有遗漏，这时候需要回到总体设计进行修正。
关键是要控制修改的影响范围。如果每次修改都导致大面积调整，说明总体设计的稳定性不够。好的总体设计应该能承受一定程度的局部修改，而不需要推倒重来。
7.3 工具选择：够用就好
画模块结构图和数据流图，工具不是关键。Visio、Draw.io、ProcessOn、甚至PPT都能画。重要的是图的内容是否准确、清晰、规范。
我个人的习惯是：先用纸笔快速勾勒，确定结构没问题之后，再用工具正式绘制。工具里要注意对齐、间距、字体大小这些细节，因为设计文档是要给别人看的，排版混乱会严重影响可读性。
7.4 关于作业评分的一点观察
如果你是在校学生，这份作业的评分通常看重几个方面：模块划分是否合理、接口定义是否清晰、数据流是否完整、文档是否规范。其中模块划分的合理性往往是权重最高的。
什么叫合理？就是每个模块的职责单一且明确，模块之间的依赖关系清晰且最少，整体结构能支撑需求中描述的所有功能。做到这几点，基本就能拿到不错的分数。至于技术选型是否先进、架构是否时髦，在课程作业的语境下，反而不是最重要的。
我在实际带人的过程中发现，那些在总体设计阶段愿意花时间反复推敲的人，后续编码阶段的返工率明显更低。反过来，那些急着写代码的人，往往在集成阶段付出更大的代价。这份作业的价值，不在于交出一份文档，而在于让你体验一次“先想清楚再动手”的完整过程。这个过程本身，比任何具体的知识点都更值得带走。
