本文为在校大学生提供系统设计的全面指导，涵盖角色定义、功能模块划分及接口设计等核心内容。通过详细解析如何确定系统角色及其权限、设计合理的功能模块，并介绍E-R图绘制、静态与动态数据处理方法，以及不同场景下的接口设计策略。帮助学生掌握实际项目开发中的关键技术点，为未来的职业生涯做好准备。
定义角色和用户
1. 定义好系统角色及用户
参与者，我认为称为角色更加合适，也就是系统为哪些类型的用户提供服务，他们都各自承担哪些不同的职责。参与者不仅包括人，还包括那些外部系统和自动触发器。例如：资产管理系统涉及到的角色，采购员、仓库管理员、普通用户、系统管理员等。
例如员工考勤工资管理系统可能 涉及到的角色 :员工、人力资源HR、财务等。
**2. 用户与角色： **
用户与角色是使用权限的基本单位，角色是一组具有相同权限的用户集合。
用户与用户之间不存在相互隶属关系，它只能属于某个角色，角色可以隶属于其它角色，且可以为多重隶属关系。
一个用户可以有多个角色、一个角色也可以分配给多个用户。
定义功能模块及模块下的操作
- 需求确定之后需要对系统进行整体分析和设计。这包括系统功能的描述、对功能模块的划分和对系统流程的分析。
- 功能模块化是将程序划分成若干个功能模块，每个功能模块完成了一个子功能，再把这些功能模块总起来组成一个整体。以满足所要求的整个系统的功能。
- 模块分析是描述系统需求的一个过程，需要将需求分析中的感性描述进行抽象，提取出要实现的功能，这是整个系统开发的一个关键过程。分析的根本目的是在开发者和提出需求的人之间建立一种理解和沟通的机制。
- 模块确定后，再细化各模块需要的业务操作。
- 可以借助思维导图形成系统的功能结构图。
设计E-R图
对各模块展开分析，确定系统所涉及到的实体和实体间的关系，最终形成E-R图
1.分析系统中所涉及到的实体（名词）
2.确定实体与实体间的关系：1对1，1对多和多对多的关系
例如：用户实体
| 实体名称：用户基本信息 | |||
| 序号 | 属性 | 类型 | 备注 |
| 1 | 用户ID | 整型 | |
| 2 | 用户名称 | 字符型 | |
| 3 | 性别 | 整型 | 0：男 1：女 2：其他 |
| 4 | 手机号码 | 整型 | |
| 5 | 密码 | 字符型 | 加密处理 |
| 6 | 身份证号码 | 字符型 | 长度18位 |
| 7 | 昵称 | 字符型 |
静态数据和动态数据分析
静态数据和动态数据都是指系统运行过程中的数据，其区别在于二者一个可变化一个不可变化。静态数据是指在运行过程中主要作为控制或参考用的数据,它们在很长的一段时间内不会变化，一般不随运行而变。动态数据包括所有在运行中发生变化的数据以及在运行中需要输入、输出的数据及在连机操作中要改变的数据。
一、变化不同
1、静态数据：静态数据在很长的一段时间内不会变化，一般不随运行而变
2、动态数据：动态数据在系统应用中随时间变化而改变。
二、包含不同
1、静态数据：静态数据不包括输入、输出的数据及在连机操作中要改变的数据
2、动态数据：动态数据包括输入、输出的数据及在连机操作中要改变的数据。
三、用途不同
1、静态数据：静态数据在运行过程中主要作为控制或参考用。
2、动态数据：动态数据直接反映事务过程
最终形成交付物：字典数据、参数数据（静态数据）动态数据:表单的输入输出项。
通常分成两张表来实现，一个是字典类型，一个是字典
- 字典类型表: T_SYS_DICTTYPE
| 字段名 | 类型 | 作用 | 备注 |
|---|---|---|---|
| code | varchar | 编码 | 主键 |
| name | varchar | 类型 | 展示用 |
- 字典表 : T_SYS_DICT
| 字段名 | 类型 | 作用 | 备注 |
|---|---|---|---|
| code | varchar | 编码 | 主键 |
| type_code | varchar | 类型code | 外键 |
| name | varchar | 字典名 | 展示用 |
| value | varchar | 字典值 | 使用值 |
| fixed | int | 是否是固定的 | default 0不固定，固定的话用1 |
人工或自动分析
分析哪些功能是采用人工的方式，例如：数据采集的方式：可以是界面录入、Excel数据导入、网络爬虫自动采集等。
任务的触发：人工触发，系统自动根据规则触发。例如：凌晨进行数据库的自动备份。往往用在任务调度。
1.自动化的主要优点
2.高度的自动化程序,无需人工操作
3.工作效率高,提高企业生产效率
接口分析
一、什么是接口
百科上对接口的定义：API（Application Programming Interface,应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。
要理解接口是什么，首先理解一下为什么要用接口？
两个独立的系统，它们的数据或程序是独立的，这就使得它们无法直接访问对方的数据库或程序（两个独立的数据相当于两个独立的家庭，每个家庭肯定是不允许外人随便进入的，否则会发生偷窃等后果严重的事件）。但是某些业务场景下，独立的系统之间又必须相互共享数据或共用一套程序逻辑，如统一业务流程上的不同业务操作系统，下游系统的业务依赖于上游系统的数据。
既然如此为什么不把它们设计成一个系统，这样不就没有上面的问题了吗？
这是因为有的业务流程很长很复杂，如果设计成一个系统，整个系统变得很庞杂，不论是功能设计、开发维护都很难。因此一般都会把虽然有上下游业务关系但又有清晰边界的业务划分成独立的系统实现，如采购系统和仓储系统。此外，很多时候我们需要获取的数据是我们外部其他公司拥有的数据，更不可能设计成同一个系统了。
基于以上两点：接口就是两个独立系统之间同步数据或访问对方程序的途径。
二、如何设计接口
1. 搞清楚是主动访问还是被动请求：
a. 若是主动访问，有两种情况：
一是我方是数据的使用方，需要主动从对方获取数据；二是我方是数据的提供方，需要主动将数据同步给对方。
主动访问时无需做接口，而是访问对方的接口，要搞清楚的问题是：我们需要在什么节点访问对方的接口？是用户触发某个操作的时候实时去访问？还是没有实时性要求，只是周期性地访问？
若我方是数据的使用方且需要的数据是用户使用某个功能必须的数据，因此必须在用户操作时实时去访问对方的接口获取数据并展示给用户，典型的有我们注册某网站时获取验证码的功能。
若我方是数据的使用方且需要的数据是一些跟用户实时操作无关的基础数据，如客服系统需要从其他业务系统获取用户的基础数据，以在系统中的某些功能下展示用户的信息（如客服在处理客诉等问题时，需要知道客户的一些详细信息，这些信息只有业务系统有）。这种情况下，一般会新增一个脚本定时（如两小时一次）访问对方的接口将数据获取过来存储到自己的数据库，在用到的时候直接从自己数据库获取并展示。
若我方是数据的提供方且提供的数据是下游系统需要的实时要求高的数据则更多地用实时同步；若是基础数据，则选择周期性同步的方式。
b. 若是被动请求，有两种情况：
一是我方是数据提供方，需要对方来获取数据；二是我方是数据使用方，需要对方主动将数据同步过来。
被动请求需要提供接口供对方访问，此时要搞清楚：让对方来访问的时候，需要提供什么样的参数？根据他提供的参数我们需要返回什么数据？这些数据从哪里取值？
若有一些数据的来源是本系统，其他系统需要使用这些数据，则可提供接口让其他系统通过访问接口获取这些数据。
若我方是数据使用方且让对方将数据主动同步过来，此种场景典型如------我们是业务的下游，上游系统产生数据后，需要将数据同步到下游系统让流程继续进行，并且流程的及时性要求高，不能有延迟。这种情况下，只有上游系统知道什么节点产生了数据，因此只有等他产生数据后主动推送给下游系统，因为下游系统因无法知道数据生成的时间，也就无法及时去获取数据，这时最好的方式是让对方主动将数据同步过来。
2. 搞清楚数据交互的实时性要求
a. 对于我方是数据使用方的情况，要根据业务的需要决定获取数据的实时性。
如上文所说，如果是用户使用功能时需要的数据就是即时性访问。如果是定期获取基础数据，根据我们对数据准确性的要求和对方数据变更的频率决定获取的周期。如我们对数据的准确性要求不是100%的要求，且对方的数据变更频率也不是很高，则周期可设计得长一些，如每天一次，每几个小时一次等。
b. 对于我方是数据提供方的情况，则以对方的业务需要为准，但是对于获取数据的访问量大等特殊情况，应在需求中或评审中做好说明和交代，以帮助开发设计更满足需要的接口。
3. 选择合适的接口方式
结合接口的不同类型和实时性要求两方面，可以选择合适的接口实现方式：
a. mq消息队列
是一个中间件，数据提供方将数据放到中间件，数据获取方从中间件中获取数据。针对向多个系统同步基础数据的需要，消息队列是最适合的方式。
若选择这种同步方式，要注意的一点是：增量同步还是全量同步，若是增量同步，对方是增量获取还是全量获取？若是全量同步，在什么情况下，对方应该更新数据，什么情况下应该更新数据？
b. otter同步
数据同步方直接访问数据获取方的数据表将数据写入对应的表中，这种方式实时性最高，若对数据的准确性要求很高，此方式是很好的数据同步方式。
c. http
一般在功能设计中常用的接口是此种方式，双方通过http地址保持数据同步和通信。
在设计具体的数据同步接口时，具体的方式产品经理不用关注，由开发根据需求设计合理的方式，然后产品可帮助开发一起确定所选方式是否满足业务需要。除非业务上有特殊要求，则在需求中可指定具体的方式。
三、如何编写接口文档
不同的接口使用场景，需要关注的点和交代清楚的规则不一样，以主动/被动+数据使用方/数据获取方的维度，有以下四种情况：