软件工程——实体关系图 + 状态转换图 + 数据流图

前言

关于我为什么要写这篇文章
上完软件工程，其实多数人会发现，实际我们没有会什么东西，很多东西不论是概念还是说实践都十分缺乏，很多教材十分老旧，视频也要么是陈年老视频要么很多地方都没有讲完整，不是说书和视频不好，只能说这些东西需要有些新鲜血液注入，而且其实学习的顺序都杂乱的，没有整体性，所以我打算帮大家进行整理，按照标准的顺序进行绘制项目中的所需要的图。

请大家根据文章顺序看不要乱跳

实体关系图

ER模型，全称为实体联系模型、实体关系模型或实体联系模式图（ERD）（英语：Entity-relationship model）由美籍华裔计算机科学家陈品山发明，是概念数据模型的高层描述所使用的数据模型或模式图。

这种ER图应该大家在学数据库的时候就会接触到

图像

1. 实体集用矩形框表示，矩形框内写上实体名。
2. 实体的属性用椭圆框表示，框内写上属性名，并用无向边与其实体集相连。
3. 实体间的联系用菱形框表示，联系以适当的含义命名，名字写在菱形框中，用无向连线将参加联系的实体矩形框分别与菱形框相连，并在连线上标明联系的类型，即1-1、1-N或M-N。

我们常看到的实体关系图

让我们进行分析一下（提示：在我看来这张图是有问题的！）

分析

实体分析

这里包含三个实体分别是：课程、学生、教师
我们首先将三个实体分别拿出来

1. 学生：学生具有的属性（班级，姓名，学号，性别）
2. 教师：教师具有的属性（教师编号，姓名，性别，所在系）
3. 课程：课程具有的属性（课程号，课程性质【选修/必修】，课程状态【这里我认为不应该叫开课，而是叫课程状态：分为=》课程未开始、课程进行中、课程已结束】）

这里大家应该发现了，我并没有把学生实体上的登录密码放到属性中，也没有把课程中的应修人
放到属性中。
原因：
我们来分析一下这个系统，这是个学生选课系统，在学生选课系统中用户扮演两种主要使用角色：1.学生，2.教师，但是我们要明确一点，学生和老师都是属于用户！所以说学生和老师都是用户类的泛化产物（意思是学生类和老师类继承用户类）

所以我们应该产生一个问题，难道学生有登录密码，老师就不需要登录密码吗？
因此我们应该是

接下来是课程，原图中课程中包含了应修人，我们站在数据库的角度思考一下是否合理，我给出以下场景：有一门软件工程，本门课被60个学生选修，那么这个课程的实体中的应修人是不是需要有60个！如果是你会怎么存？这里只能一个人存一行。那么怎么样会更好呢？
我们去除应修人这个选项，使用课程号进行外键映射出一个新的实体选课单！（这里要注意了！选课单实体的主键就是课程号+序号这里课程号外键改名为选课单号），让课程分出一个选课单，让选课单处理学生选课我们就会出现下面的样子：
选课单：属性（序号（主键），选课单号，学号，课程时间【指明课程开设的时间，不让多个选课单冲突，这里要是没有必要性可以考虑在课程状态为已结束时直接将选课单清除，就不需要这个属性了】）

关系分析

接下来我们进行关系分析

1. 课程 and 选课单：一个课程可以对应的只有一个选课单，其中选课单中有课程时间就是为了让课程永远锁定最新的选课单，而抛弃之前老的选课单，但之前的选课单通过这个属性也可以做到保留的作用，所以他们是1对1的关系
2. 课程 and 学生：一个学生可以选择多个课程，一门课程可以被多个学生选择所以必然是选择的多对多的关系
3. 课程 and 老师：实际上老师可以开设多个课程，一门课程也可能有多个老师一起教学，所以是多对多的关系
4. 老师 and 学生：这里学生和老师之间的串联通过课程进行连接，一个学生有多个老师，一个老师也可以教多个学生，就是多对多的关系
5. 选课单 and 学生：学生选择课程后，选课单会记录学生的学号，将其加入课程中，选课单和课程直接连接，和学生形成间接关系，其实还是一个多对多，（1对1 × 多对多 = 多对多）
6. 选课单 and 老师：同理学生，多对多
   接下来我们进行绘制联系

改进后的实体关系图

这里我要说一个注意点：课程和选课是一一对应的但是，选课单中包含的是多个数据，所以在写程序的时候

当然100个人有100个哈姆雷特，我这样认为不代表其他人也这样认为，可能别人认为我画的也是有问题的，这里只能说提供一个参考

项目实体关系图（下面围绕这张图展开）

数据流图

数据流图（Data Flow Diagram）：简称DFD，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。

图形表示

项目数据流图

顶层

双层

三层

绘制方法

数据流图按照层次来绘制有一个循序渐进的过程
根据我们给出的三层，我们可以看出

这里的逻辑还是比较简单的
就是说我们看到一个行为，要实际的分析行为中的逻辑组成
如：
文章处理含有：文章撰写==>文章提交==>文章审核==>文章发布这些流程
需要大家把这些东西分解出来
而其中产生的文件就是我们所要存储的文件
根据上方疫情管理系统的例子
信息处理：填写信息表==>信息表基本审核，在这里产生了一个文件就是个人|家庭信息文件，这个就是我们在数据库需要存储下来的数据

状态转换图

在Visio模板里叫UML状态机

状态转换图，即STD图(State Transform Diagram)，表示行为模型。
STD通过描述系统的状态和引起系统状态转换的事件，来表示系统的行为，指出作为特定事件的结果将执行哪些动作（例如处理数据等）。STD描述系统对外部事件如何响应，如何动作。
STD图发生在软件工程的需求分析阶段。状态模型是一种描述系统对内部或者外部事件响应的行为模型。它描述系统状态和事件，以及事件引发系统在状态间的转换。这种模型适用于描述实时系统。

图形表示