团队作业第四次—项目系统设计与数据库设计
| 这个作业属于哪个课程 | 班级的链接 |
|---|---|
| 这个作业要求在哪里 | 作业要求的链接 |
| 这个作业的目标 | ① 1篇博客随笔，发表在团队博客的博客中，博客标题设置为“XXX（团队名称）——项目系统设计与数据库设计”，并提交作业② 1份《系统设计说明书》（pdf文件）；③ 1份《数据库设计说明书》（pdf文件）数据库设计要求使用工具PowerDesigner；④ 04月22日系统设计和数据库设计答辩准备：1份《系统设计和数据库设计答辩PPT》（课堂现场评审）。⑤ 建立github团队仓库，将《系统设计说明书》《数据库设计说明书》《系统设计和数据库设计答辩PPT》等团队文档提交到团队仓库；⑥ 现场评审要求 |
| 作业正文 | .... |
| 其他参考文献 | ... |
一.预期开发计划时间安排
| 起始时间 | 任务安排 | 截止时间 |
|---|---|---|
| 4月13日 | 1.制作系统设计说明书2.制作数据库设计说明书3.制作系统设计和数据库设计答辩PPT | 4月19日 |
| 4月20日 | 前端后端同时开始开发 | 4月26日 |
| 4月27日 | 前端后端完成简易版本的《校易》 | 5月3日 |
| 5月4日 | 调试软件，修复发现的bug | 5月10日 |
| 5月11日 | 优化《校易》界面和代码 | 5月17日 |
| 5月18日 | 调试软件，修复新的bug | 5月24日 |
| 5月25日 | 优化《校易》界面和代码 | 5月31日 |
| 6月1日 | 调试软件，修复新的bug | 6月7日 |
二.预期开发计划分工安排
| 组员 | 角色 | 负责的开发部分 |
|---|---|---|
| 洪志雍 | 前端 | 1.调用接口，和后端对接2.协助设计一些css,js样式 |
| 张云淳 | 前端 | 1.界面设计和排版2.负责大部分css和js |
| 江李悦 | 后端 | 1.搭建服务器2.创建数据库3.完成功能模块中的管理员模块 |
| 程顺明 | 后端 | 1.完成功能模块中的用户注册登录模块2.完成功能模块中的用户个人设置模块 |
| 冯志成 | 后端 | 完成功能模块中的用户商品上架下架模块 |
| 连辛集 | 后端 | 完成功能模块中的用户查询模块 |
| 缪彬鑫 | 后端 | 完成功能模块中的用户聊天交流模块 |
| 王永乐 | 测试 | 测试《校易》，寻找其中的bug和不足，以及对软件提出改进意见 |
三.体系结构设计
1.技术架构
小程序客户端采用C/S（小程序客户端—服务器）架构，管理端采用B/S架构（浏览器—服务器）。
2.使用PHP三层体系架构：
表示层：主要使用WEB-Render方式，逻辑层强大和完善，无论表现层如何定义和更改，各司其职，逻辑层都能完善地提供服务。
业务逻辑层：主要针对具体问题操作，也是对数据Data层的操作，对数据业务进行逻辑处理，实现积木拼接式搭建。
抽象接口层：对数据访问层抽象出接口，业务逻辑层经过抽象接口层去调用，保证调用分离，扩展分离。
数据访问层：主要对原始数据进行加工和提取，为业务逻辑层提供数据服务。
3.总体设计原则
安全设计:信息内部传输通过MD5不可逆加密算法。
小程序架构方面：微信小程序的架构包含两部分View视图层、App Service逻辑层。View层用来渲染页面结构。AppService层用来逻辑处理、数据请求、接口调用，它们在两个线程里运行。视图层和逻辑层通过系统层的JSBridage进行通信，逻辑层将数据进行处理后发送给视图层，同时接受视图层的事件反馈。视图层将逻辑层的数据反应成视图，同时将视图层的时间发送给逻辑层。在用户使用时，只允许用户输入我们期望的数据。
小程序后台管理方面：后端编写主要是用java，主要框架springboot，开发工具eclipse。
4.设计思路
由于设计的是小程序，所以客户端采取客户端到服务器的架构，管理端采用浏览器到服务器的架构。
使用php三层架构划分成三层，有利于系统的开发、维护、部署和扩展。分层可以把问题分开解决，易于控制。
四.功能模块层次设计
1.功能模块层次图
2.校易系统模块功能说明
用户注册登录模块有登录、注册以及找回密码三个功能。其中注册和找回密码需要学号验证。
用户商品模块有用户上架商品功能和用户下架商品功能。
用户查询模块有查询商品信息功能和查询用户信息功能，查询商品可以按字母表排序查询，而用户信息查询可以按条件查询用户。
用户聊天交流模块有发送商品信息、文字、图片、语音以及视频等功能。
用户个人设置模块可以设置用户等个人信息。
管理员模块的功能有用户注册信息存储、管理员登录信息核对、管理员安全信息检测、管理员删除用户账号、和管理员删除下架用户商品等功能。
3.设计思路
我们打算做一个类似于微信朋友圈微商的一个校园二手交易市场，我们不直接干预交易，所以我们不需要设计资金流向和资金安全性设置。我们要提供良好的聊天交流系统和优秀的商品展示平台。
用户注册登录模块就是登录需要。
设计思路上和淘宝之类的网上商城大体一致，有完整的商品信息展示，同时二手交易模块设置了“我要买”和“我要卖”。在我要买当中添加了按顺序搜索功能。用户交流模块则是能够使用户正常的聊天和发送商品信息。
管理员模块的设计思路使为了我们后台工作人员能够下架非法商品和删除非法用户。
五.设计类图
1.用户界面
2.实体类
3.管理员界面
4.设计思路
首先划分出四个重要的类，用户类、商品类、管理员类和继承于用户类的卖家类，并画出它们之间的关系。之后再详细的补充用户类和管理员类。
在用户类中，数据只保留了注册时必填的数据，之后再画出有关用户类的一些可操作界面的类图并连接起来。
管理员类也是一样，画出和管理员类相关的一些操作界面的类图并连接起来。
六.ER分析
1.局部E-R
登录局部E-R
界面信息局部E-R
修改个人信息局部E-R
商品局部E-R
2.全局E-R
3.设计思路
设计思路是站在用户角度，从用户注册登录进入主页界面，再到一些其他的功能，如浏览历史商品、客服等等。接着再到交易方面，有与买家/卖家的聊天界面，还有消息通知。除了主要从用户方面进行分析，再对管理员方面进行分析。
首先，先确定实体与属性：
用户（注册、登录）、
主页信息（下架商品、发布商品、修改商品、搜索商品、“我的”信息、消息、浏览商品）、“
我的”信息（设置详情、修改个人信息、客服、管理权限、我的商品、退出登录、历史浏览）、
个人信息（密码、昵称、姓名、学号、账号）、
商品（id、图片、简介、名字、价格）、
商品交易（查看卖家信息、与卖家私聊）、
消息（与买家/卖家聊天、通知）、
管理权限（删除用户信息、注销用户、查找用户）。
接着整理实体之间的关系：
用户开登录后到达主页界面，是一对一的关系。
主页信息的搜索商品通过搜索与商品进行联系，是m对n的关系；主页信息的发布商品通过发布与商品进行联系，是1对n的关系；主页信息的浏览商品通过浏览与商品进行联系，是m对n的关系；主页信息的消息通过拥有与消息进行联系，是1对n的关系；主页信息通过点击与“我的”信息进行联系，是1对1的关系。
商品通过交易与商品交易进行联系，是1对1的关系。
“我的”信息通过修改与修改个人信息进行联系，是1对1的关系；“我的”信息通过拥有与管理权限进行联系，是1对1的关系。
七.表结构设计
1.具体设计
| 表名 | 功能说明 |
|---|---|
| STUDENT | 学生表，用于验证是否是学生 |
| USER_INFO | 用户信息表 |
| COMMODITY | 商品表，存放商品信息 |
STUDENT表（学生表）
| 表名 | STUDENT | |||
|---|---|---|---|---|
| 列名 | 数据类型（精度范围） | 空/非空 | 约束条件 | 其他说明 |
| STUDENT_ID | VARCHAR(22) | 非空 | PRIMARY KEY | 学号 |
| STUDENT_NAME | VARCHAR(40) | 非空 | 学生姓名 | |
| IS_REGISTER | VARCHAR(22) | 是否已注册（没注册为空，已注册为用户账号） |
USER_INFO表（用户信息表）
| 表名 | USER_INFO | |||
|---|---|---|---|---|
| 列名 | 数据类型（精度范围） | 空/非空 | 约束条件 | 其他说明 |
| USER_ID | VARCHAR(22) | 非空 | PRIMARY KEY | 账号 |
| USER_NAME | VARCHAR(40) | 非空 | UNIQUE | 用户名 |
| USER_PASSWORD | VARCHAR(40) | 非空 | 密码 | |
| USER_PICTRUE | IMAGE | 头像（空的话，用默认头像） |
COMMODITY表（商品表）
| 表名 | COMMODITY | |||
|---|---|---|---|---|
| 列名 | 数据类型（精度范围） | 空/非空 | 约束条件 | 其他说明 |
| COMMODITY_ID | VARCHAR(20) | 非空 | PRIMARY KEY | 商品号 |
| COMMODITY_NAME | VARCHAR(40) | 非空 | 商品名 | |
| COMMODITY_INFO | VARCHAR(400) | 非空 | 商品信息 | |
| COMMODITY_PRICE | INT | 非空 | 商品价格 | |
| COMMODITY_PICTRUE | IMAGE | 非空 | 商品图片 |
2.设计思路
首先建立三张表，学生表、用户信息表、商品表。然后由于学生表只用来验证是否是学生，所以只存学号、姓名和是否已创建账号，其中是否已创建账号内容为注册的账号，这样如果需要，随时可以根据账号，查出该账号对应的是哪个学生，同时也减少对学生表的访问次数，提高对学生学号姓名的保护。其次用户信息表减就是存放用户资料的表，存放用户的各种信息。最后是商品表，用来存放用户上架的商品信息。
八.系统安全和权限设计
1.系统安全设计原则
由于在网络环境下，任何用户对任何资源包括硬件和软件资源的共享，所以必须通过制定相应的安全策略来防止非法访问者访问数据资源，对数据资源的存储以及传输进行安全性保护。
1.1 标识与确认
任何用户访问系统资源，必须得到系统的身份认证以及身份标识，如用户号码、密码、学号。当用户信息与确认信息一致时，才能获准访问系统。在本系统中，对操作系统，数据库系统和应用系统都有相应的用户和权限的设置。
1.2 授权
对系统资源，包括程序、数据文件、数据库等，根据其特性定义其保护等级；对不同的用户，规定不同的访问资源权限，系统将根据用户权限，授予其不同等级的系统资源的权限。
1.3 日志
为了保护数据资源的安全，在系统中对所保护的资源进行任何存取操作，都做相应的记录，形成日志存档，完成基本的审计功能。
1.4 加密
为了保护数据资源的安全，在系统中对在网络中传输的信息必须经过高强度的加密处理来保证数据的安全性。
通过整体考虑来保证网络服务的可用性、网络信息的保密性和网络信息的完整性。
2. 系统级安全
系统级安全主要体现系统软件平台的安全设置上。
2.1 物理设备的安全措施
在系统设备的选用上，必须对各产品的安全功能进行调查，选用。要求对系统设备提供容错功能，对系统的备份方案在下节进行讨论。采用各种网络管理软件，系统监测软件或硬件，实时监控服务器，网络设备的性能以及故障。对发生的故障及时进行排除。
2.2 操作系统平台的安全管理
在操作系统平台上，应进行如下设置：
系统的超级用户口令应由专人负责，密码应该定期变换。
建立数据库的专用用户，系统在与数据库打交道时，应使用专用用户的身份，避免使用超级用户身份。
在系统的其他用户的权限设置中，应保证对数据库的数据文件不能有可写、可删除的权限。选用较高安全级别的操作系统，时刻了解操作系统以及其他系统软件的动态，对有安全漏洞的，及时安装补丁程序。
2.3 数据库系统的安全管理
数据库系统是整个系统的核心，是所有业务管理数据以及清算数据等数据存放的中心。数据库的安全直接关系到整个系统的安全。在本系统中对此考虑如下：数据库管理员（ SA ）的密码应由专人负责，密码应该定期变换。
客户端程序连接数据库的用户绝对不能使用数据库管理员的超级用户身份。
客户端程序连接数据库的用户在数据库中必须对其进行严格的权限管理，控制对数据库中每个对象的读写权限。
利用数据库的审计功能，以对用户的某些操作进行记录。
充分使用视图以及存储过程，保护基础数据表。
对于不同的应用系统应建立不同的数据库用户，分配不同的权限。
3. 应用级安全
针对本系统，我们在考虑其应用级安全时，主要针对以下几个方面：
系统的用户授权及安全访问控制
全面的日志管理机制
采用相关的网络版的防病毒软件
3.1 用户授权及安全访问控制
对于用户授权和安全访问控制的有关需求，我们在实现本系统时，利用系统的基本定制功能实现对用户属性的定制，可新建用户及用户组，新建角色，用户组可为多层嵌套结构，可按不同用户级别和组级别进行权限分配；角色可以按不同用户级别和组级别进行权限分。
3.2 日志管理机制
实现系统使用情况的日志记录，系统对重要的操作都自动进行日志记录，管理人员对日志记录进行查询、管理；
提供用户访问系统记录，目前提供用户名，用户IP，登录时间，记录时间，操作内容等。
3.3 数据加密及数据保护
系统将对传输过程中的信息进行加密处理，对信息进行保护，以防止信息泄露。
4. 灾难备份与应急故障恢复
4.1 系统备份
为保证系统长期、稳定的运行，设计必须考虑系统的备份方案，根据系统的硬件环境，可对主机、磁盘子系统、通信介质备份或容错。
4.2 数据备份与恢复
在系统运行过程中，经常会由于设备以及其他因素的原因，导致系统的崩溃，数据库的毁坏。为了系统数据安全，无论采用何种系统备份方案，也必须进行数据备份。在系统设计中，应建立一套有效的备份策略，建立完善的备份制度。在本系统中考虑如下：
备份方式可采用完全备份与增量备份相结合方式进行备份；
备份时间频度应结合系统的数据增量来确定，如每天一次、每周一次等。
5. 权限管理
权限管理是用户进行系统权限划分和设置的平台，按照管理的层次可划分为三个层面进行管理，用户、角色和功能。
5.1 用户
通过系统用户注册功能实现登录用户的信息保存。为保证各系统间采用统一的登录验证，可采用统一的用户信息表的办法，保证统一的用户信息数据来源。
用户表可包括：用户ID、用户名、密码、角色信息、其他相关信息。
注：密码加密采用MD5的方式进行加密。
5.2 角色
角色是系统功能和用户相对应的桥梁，主要作用指定用户所能操作的功能。
角色和用户的关系是：一个用户可以同时对应多个角色，一个角色可以对应
多个用户。主要采用在用户信息表中保存角色编码序列的方式保存用户和权限的对应关系。
角色和功能的关系：一个功能可以同时对应多个角色，一个角色可以对应多个功能。主要采用在学生表中保存功能编码序列的方式保存用户和权限的对应关系。
5.3 功能
保存的是用户所能操作的功能，这里主要指的是页面，是用户所能管理的最小功能单元。
6.设计思路
采用这样系统安全和权限设计的思路，既保证了系统有着相对的安全和权限的分配，也应该是目前我们能力所能完成的程度。
九.Q&A
Q：学生的学号信息如何更新？
A：学号信息因为平时有变动的概率不大，所以采取每年新生入校时更新数据库，确保新生能够注册。
十.针对上次需求分析作业的改进部分和改进过程
1.根据老师的建议，为需求分析报告添加了版本信息部分，并在之后每次更新时填写更新内容。
2.修改了需求分析报告中的各种图，状态图由张云淳和缪彬鑫修改，用例图由江李悦和王永乐修改，类图由洪志雍和连辛集修改，活动图由冯志成和程顺明修改。
十一.工作流程、组员分工、组员贡献度比例
| 学号 | 名字 | 工作内容 | 贡献度 |
|---|---|---|---|
| 211706178 | 江李悦 | 1.负责《系统设计说明书》的第四章数据库设计部分2.负责《数据库设计说明书》的第四章运用设计部分 | 12.5% |
| 211706201 | 王永乐 | 1.负责《系统设计说明书》的第一章引言部分2.负责《数据库设计说明书》的第一章引言部分 | 12.5% |
| 211706122 | 缪彬鑫 | 1.负责《数据库设计说明书》的第二章外部设计部分2.负责《系统设计说明书》的第六章系统安全和权限设计部分3.负责画数据流图 | 12.5% |
| 211706109 | 洪志雍 | 1.负责《系统设计说明书》的第五章用户界面部分2.负责《系统设计说明书》的第二章体系结构设计部分3.负责《系统设计说明书》的第二章系统设计部分 | 12.5% |
| 211706166 | 程顺明 | 1.负责《数据库说明书》的第三章3.1概念结构设计部分内容2.负责《系统设计说明书》的排版整理 | 12.5% |
| 211706184 | 连辛集 | 1.负责《数据库说明书》的第三章3.2逻辑结构设计2.负责《数据库说明书》的第三章3.3的逻辑结构设计和物理结构设计 | 12.5% |
| 211706170 | 冯志成 | 1.负责《系统设计和数据库设计答辩PPT》2.负责《数据库设计说明书》的排版整理 | 12.5% |
| 211706155 | 张云淳 | 1.负责《系统设计说明书》的第五章用户界面部分2.负责《系统设计说明书》的第六章功能模块层次设计部分 | 12.5% |
十二.github链接
1.github团队仓库链接：
https://github.com/carry-code-succeed/Campus_Transaction
2.码到成功_系统设计说明书.pdf：
https://github.com/carry-code-succeed/Campus_Transaction/tree/master/校易系统设计说明书
3.码到成功_数据库设计说明书.pdf：
https://github.com/carry-code-succeed/Campus_Transaction/tree/master/校易数据库设计说明书
4.码到成功_系统设计和数据库设计答辩PPT.pdf：
https://github.com/carry-code-succeed/Campus_Transaction/tree/master/系统设计和数据库设计答辩