之前指导过这样一位学生，情况是这样的：

这位学生想给自己的论文“贴金”，具体做法是在毕设中增加一些图，增加“美感”，可不知道在论文的什么位置放什么图，就问到我：“我看别人的毕业设计中有各种图，流程图、类图、E-R图、数据流图、时序图、用例图、架构图等等，这些图具体是放到毕业设计中的什么位置？”

其实不止是这位学生，许多工作多年的开发人员，也不清楚这些图到底是干什么的，有什么用。

如果你也有这样的疑虑，那么希望你好好学习本篇文章介绍的方法，给“XX图”找到合适的位置，给论文“贴金”。

本篇文章内容比较“干”，但能解决你的疑虑。

提到系统设计，大多数人联想到的是“概要设计”和“详细设计”，其实这已经是历史了。

概设和详设，是结构化开发时代的设计方法，我们计算机专业，大学都应该学过软件工程吧，那大家应该或多或少知道“瀑布模型”和“V模型”。软件开发的流程类比瀑布，从需求-设计-实现-验证-维护，是单方向的，这里的设计就包括概要设计和详细设计。

后来因为瀑布模型的单方向流程缺点，引出了V模型，也就是在设计的时候考虑了测试和验证，在瀑布模型的每个阶段都考虑测试和验证，就成了V模型。这两种开发模型，不适合现在主流的面向对象开发，随着系统的复杂度不断提高，架构方法论的出现，以及面向对象开发的盛行，“历史”的方法基本已经淘汰，出现了RUP、螺旋模型、敏捷开发等。

尽管如此，现在很多公司还在用“概要设计”和“详细设计”，作为项目的规范文档，这样还勉强说得过去，总比没文档强。过分的是，有的公司干脆“零文档”，然后非常自信地说他们拥抱了“敏捷开发”，殊不知完全把敏捷给玩坏了（以后大家如果在这样的公司工作，果断换工作吧 ^_^ ）。

回到我们毕业设计，既然这“概要设计”和“详细设计”都是历史文物了，那我们就别考古了。在撰写毕设的时候，就别考虑这个维度了。下面我总结了一个思维导图，我们只关注5个层面，并标注了“毕设关注”。接下来一一介绍，在毕设中如何撰写这5个层面的内容。

架构设计

我的建议，毕设的架构设计，只写“分层”这个架构风格（架构模式），因为它简单、易理解，作为学生，也只能做到分层架构了。为什么这么说呢？如果你不服，那么往下看。

独立构件，这是一个非常专业的架构模式，大公司比较常见，公司内部有自己的构件库，开发新的系统时，会从已有的构件库中寻找合适构件，然后进行组装，如果没有合适的构件，那么他们会制定开发任务，开发新的构件（我最近就在开发网络构件和分布式缓存构件），最后经过严格的测试与评审，再将新开发的构件放入构件库，以备后用，目前国内的大公司比如BAT，都会有自己的构件库。大多数的中小型公司，都达不到这种程度，中小公司开发的所谓的“构件”都是跟应用强相关的，根本称不上构件。

再说下解释器，这个就更专业了，大多用于开发系统软件，非应用软件。目前国内，还没有哪个系统软件，能真正完成解释功能。使用解释器架构模式开发的Java虚拟机JVM，最具代表性，需要制定解释规则和解释引擎，如果你是学术研究类论文，还可以写一写，如果是软件工程论文，千万别扯上这种架构。当然了，如果你觉得自己很牛，在伯克利大学深造过，你可以试着设计与实现一下？

仓库风格，大数据领域的毕业设计可以写一写，主要涉及到数据分析、用户行为分析等。

目前比较流行的微服务架构，是在SOA（面向服务的架构）的基础上发展起来的，它相对轻量级，服务之间使用HTTP通讯，目前比较火爆的电商行业的后端大都是这种结构，如果你的毕业设计是使用SpringCloud框架、SpringCloudAlibaba等进行开发的， 可以写微服务的架构。但是，注意一点，如果你已有源码，可以写微服务架构，如果没有源码，老老实实写分层吧， 微服务架构，要写出深度，不是一两个月就能搞定的。

刚才也说到了SOA，一般在大型金融机构、银行、保险公司会用，一般的电商后端，不太会涉及到SOA，SOA涉及到的子系统上百个，每个子系统又有单独的架构，可以微服务实现，也可以分层实现，而且SOA基于ESB（企业服务总线），属于比较重量级的中间件，中小型公司基本用不到这种架构，毕业设计中就更不要写这种架构了。

下面我列出了基于SpringBoot的OA系统的架构设计图，整体是“分层风格”，供大家参考。TIPS：注意千万别把干巴巴的图放上去，你多少写点描述性的文字，解释下图的各个部分，所谓“图文并茂，尽显奇效”，有图的地方都是这个套路哦，不然只有图，显得有点突兀。

系统模块设计

这一小节，主要写你要实现的系统有哪些功能模块，以“组织结构图”的形式展示出来，然后对每个模块进行简要的描述，说一说你是怎么设计的就可以了。前提是你需要理清系统的功能模块划分，之后就可以自由发挥。

列举一个例子，根据 OA 系统的功能模块，我简要画了一个系统功能模块图，另外也附上了系统的运行截图，供你参考。

模块流程设计

这里主要就是描述你的系统是如何“跑起来”的，各个模块是如何交互的， 各个模块的前置依赖是什么，后续流程是什么，以流程图的形式展示出来。流程图也比较简单，还是OA系统的例子，提供你参考。

数据库设计

这一小节，又比较“干”，软件工程中都将数据库设计，细分了出来，称之为“数据库工程”

数据库设计包含这么几个步骤：数据库需求分析、概念模型设计、逻辑模型设计、物理模型设计，而且数据库设计有一定的难度，主要你需要了解“关系规范化”、“关系模式”、“元祖演算”、“无损连接”、”函数依赖“等等理论，像国外都有专门的职位”数据库工程师“，在国内好像很少这样的职位。

导致什么问题呢？ 没有专门的工程师来设计数据库，以至于设计的数据库表，逻辑乱七八糟、性能稀里哗啦。这同时也反应了国内一种现象叫做“膨胀”，程序员学了点语言基础，会写点SQL语句，会业务CRUD，就可以去工作了，会点算法，就可以去大厂了，真正能深挖底层的少之又少，这也就注定了，程序员这条路，没有理论支撑，走的非常曲折，“35岁危机”也就发生在这样的程序员身上，希望大家，看一下麻省理工大学的公开课，温斯顿教授的 “How to Speak”，相信你会收获满满。

闲话不说了，我们回到毕业设计，数据库设计主要写两个小节就可以了，一个是概念模型设计，另一个是逻辑模型设计。需求分析也可以写，但是跟系统的需求分析有点点重叠，这里不在建议写数据库的需求分析（数据库需求分析涉及的图是DFD图，也就是数据流图）。

概念模型设计

这一小节，主要是画图，E-R图又称为实体-关系图，其主要包括全局E-R图和局部E-R图。我想大部分学生，在写毕业设计的时候，手上都有源码了，数据表结构也有了。如果没有，可以关注我的公众号，里面我会分享一些容易写毕业设计的系统源码，大家可以持续关注。

有了表结构，再进行画E-R图，就容易了。可以通过SQLyog，连接到数据库，打开表结构看一下，各个表之间的联系。其实在概念模型设计阶段，还没有“表”这个概念，现在都是以实体的形式展现。

实体与实体之间有1:1、 1:n、n:m 关系，也就是一对一、一对多、多对多关系，每个实体都有一个或多个属性。

那怎么识别是那种关系呢？ 我举个例子，虽然例子不是很恰当，但是普遍性极强。

你和你女朋友，对感情都非常专一，在你的世界中，男孩和女孩，就是1:1关系。

你是一个名副其实的海王，你有多个女朋友，在你的世界中，男孩和女孩，就是1:n关系。

你俩都是海王，那么在你们的世界里，男孩和女孩就是n:m关系。

还有更为复杂的，就是实体与实体之间还会有“联系”，联系也有属性，这种就比较复杂了，我们毕业设计中一般不会有这样的情况。后面我的实战视频中，会实战讲解这种情况，这里就不细说了。

有了上面的例子，我们去看数据库中的每一个实体，也就是未来要创建的“表”，就很容易分析出他们的关系了。下面我以 OA 系统为例，分析没一个“表”，然后画出部分主要的全局E-R图。

这次作图软件，我们用Visio，微软的软件，收费的，我想你又办法让它可用。^_^

新建一个visio文件， 选择Chen's数据库表示法

或者随便选一个模板，进入后找到Chen's数据库表示法

下面我根据 OA 系统画出的部分全局E-R图，这个图放到毕业设计足够了，千万别画的太多，一个系统那么多功能，你一个人不可能完成，你一个人也设计不完这么多实体。

实体属性图，就非常简单了，这其实是个体力活，每个数据库的表都对应一个实体属性图，如下列出了OA系统考勤实体的实体属性图，供你作参考。

逻辑模型设计

这一节，不涉及图，但涉及到了表格，具体写一下表是怎么设计的，表名是什么、字段名是什么、字段的类型是什么，表格的最后一列标注上字段的属性说明，是个体力活，这里就不过多解释了。

这是一篇学生选课管理系统的设计与实现的例子，供你参考

获取更多毕设资源或服务： 高质量论文范例、毕设定制、源码定制、系统讲解、设计出图