企业官网建设流程全解析

导师一句"把系统设计图补齐"，听起来简单，做起来容易卡住：E-R 图、流程图、数据流图、用例图、类图、时序图、架构图、功能结构图——名字都见过，但到底要交哪几张，每张里面该放什么？

更常见的问题是画完之后，八张图各自都像那么回事，放在一起却发现描述的不是同一套功能。功能结构图上有"会员等级管理"，用例图里没有对应的用例，数据库里也找不到那张表。

这篇不按图种一个个介绍术语，而是按"这张图要回答什么问题"来分组。先想清楚要回答什么，再决定画哪张。

先明确一件事：不是每张都要画

课题要求里写"系统设计图若干"，通常不等于"把能画的都画一遍"。画了但说不清楚，比不画更减分——答辩时导师指着图问"这个模块对应哪段代码"，答不上来就很被动。

判断要不要画一张图，用两个问题：

1. 这张图回答的问题，课题里有人在关心吗？
2. 我能解释图上每一个方框和连线吗？

第二个问题的门槛比想象中高。下面每张图都配了"检查什么"，答不上来的就别急着放进论文。

“系统由哪些部分构成”——功能结构图和架构图

这两张图经常被混着用，但它们回答的问题不同。

功能结构图回答"系统提供哪些模块"。它是一棵树，从系统往下拆到具体功能，连线表示归属，不表示先后顺序。

看这张图注意两点：树的层级深度（拆到第几层还说得清楚），以及右侧的角色-功能对应。层级太深通常说明把"操作"也画进去了——功能结构图拆到功能为止，再往下是流程图的事。

检查什么问题：模块名是不是名词性短语（“会员信息管理"而不是"管理会员”），有没有和需求文档里的功能对不上。

系统架构图回答"系统由哪些层和组件实现"。它和功能结构图最大的区别是：架构图必须和实际用的技术栈一致。

这张图里能看到分层：用户层、Web 前端层、MVC 层、数据访问层、持久层，每一层里写的是具体的框架或组件名。

检查什么问题：图上写的技术名称，和最终交付的源码是不是同一套。架构图画着 Vue，交上去的是 JSP 页面，这是答辩现场很容易被抓的一处。

“数据之间是什么关系”——E-R 图

E-R 图回答"系统里有哪些业务对象，它们之间怎么关联"。

这张图来自"学生信息管理系统"示例，和本文其他几张界面截图不是同一个项目——它是导出后的成品图。

看这张图关注三样：实体（矩形）、属性（椭圆）、关系（菱形）。特别留意中间那个"学生选课"，它上面挂着分数、备注、选课时间——这些是选课这个动作产生的信息，不属于学生也不属于课程。中间实体建对了，多对多关系才表达得完整。

检查什么问题：图上的每个实体能不能在数据库里找到对应的表；每条联系的基数（1/N/M）能不能用业务规则解释。

“一个业务怎么走完”——三张图，三个角度

这三张图都在讲业务过程，但追踪的东西不同，不要互相替代。

系统流程图追踪的是步骤和判断。它回答"用户做一件事，系统按什么顺序处理，在哪里分叉"。

看这张图找"菱形"——判断节点，以及从菱形出去的不同分支。图中的例子是会员身份验证：验证不通过会走一条单独的分支。

检查什么问题：每条失败分支有没有交代。如果图上从"开始"一路画到"结束"全是直线，那这张图没有表达出任何异常处理，答辩时问一句"如果这步失败了会怎样"就答不上来。

数据流图（DFD）追踪的是数据。它回答"数据从谁那里来，经过什么处理，存到哪里，最后给谁"。

看这张图注意箭头的方向：外部实体在两边，系统处理在中间。数据流图里不应该出现判断菱形——那是流程图的元素。另外每条箭头上应该写清楚流的是什么数据，只画箭头不写名字等于没画。

检查什么问题：有没有"数据凭空产生"或"数据有进无出"的地方。这两种情况通常意味着漏了一个外部实体或一条数据流。

系统时序图追踪的是一次调用。它回答"用户点一下之后，消息在参与者之间按什么顺序传递"。

看这张图关注竖直的生命线和横向的消息箭头。右侧面板列出了参与者（用户、页面、服务、数据库等）和消息序列。

检查什么问题：校验是在写库之前还是之后，失败时有没有返回。这两点在时序图上一目了然，也是答辩常问的。

“谁能做什么”——用例图和类图

用例图回答"哪些角色能用哪些功能"。它最直接的用途是核对权限设计。

看这张图检查参与者（小人）和用例（椭圆）之间的连线：管理员连了哪些用例？普通用户连了哪些？

这里有个容易搞混的地方：图上画了连线，不代表程序里真的做了权限控制。用例图描述的是设计意图，实际的越权拦截要在接口层面验证——界面上看不到按钮，不等于接口禁止了越权调用。

UML 类图回答"代码层面有哪些对象，它们的属性和方法是什么"。

看这张图关注类的属性区和方法区。右侧面板列出类清单和方法清单。

检查什么问题：类图不是数据库表的翻版。每张表机械对应一个类，往往说明模型没做抽象——服务类、工具类、以及那些不对应任何表的业务对象，也应该出现在类图里。

八张图之间的关系

把上面几组放在一起，能看到它们其实回答的是四个层次的问题：

不需要每张都画。数据库课设可能只要求 E-R 图和数据字典；系统设计类课题通常要功能结构图 + 流程图 + 用例图；论文里想体现设计深度，再补时序图和类图。

用一条业务线把所有图串起来自检

图纸画完，挑一个核心业务（比如"选课"或者"会员消费"），沿着它把画过的图走一遍：

• E-R 图：有没有承载这个业务的实体和字段？
• 功能结构图：有没有对应的功能模块？
• 用例图：这个功能给了正确的角色吗？
• 流程图：主流程和失败分支都画了吗？
• 数据流图：数据最终写进了哪个存储？
• 时序图：调用顺序和校验时机对不对？
• 架构图：这套流程在你选的技术栈里跑得通吗？
• 类图：实现这个业务的类和 E-R 图里的实体对应得上吗？

能沿着一条业务线把图串起来，才说明这些图描述的是同一个系统。串不起来的地方，就是需要回去改模型的地方——通常问题出在最上游的 E-R 图或功能结构图上，改了之后往下逐层同步。

需要动手试的话，可以从 捷码AI工作台 建立项目，按课题需要生成各类图纸初稿，再逐张按上面的问题核对。生成出来的是初稿，能不能用要看你的课题要求和你自己的判断。