作业描述
| 所属课程 | 软件工程1916|W（福州大学） |
|---|---|
| 作业要求 | 团队作业第五次—项目系统设计与数据库设计 |
| 团队名称 | 待就业六人组 |
| 作业目标 | 宏观的对系统的整体结构设计，并在此基础上，进行数据库设计 |
| 系统设计说明书.pdf | Github链接 |
| 数据库设计说明书.pdf | Github链接 |
| 第五次作业评审表.pdf | Github链接 |
| 第五次作业答辩PPT.pdf | Github链接 |
一、设计类图
在OOA模型中，我们初步建立了类图，描述了系统中行为实体间的静态结构。在OOD阶段，我们详细分析了类与类之间所存在的关联性，从控制类、边界类、实体类的角度出发，进一步总结梳理出系统整体的静态组织结构。
1.1 登录子系统类图
1.2 参与者类图
1.3 智能推送类
1.4 信息管理类图
1.5 信息查询类图
1.6 投递简历类图
1.7 审核简历类图
1.8 私信类图
二、系统体系结构设计
2.1 系统分析
由OOA阶段的分析可知，类图体现了校招平台在微观上的静态结构，但由于整个系统内容繁多，较为庞大，使用类图分析将大大增多工作量，因此我们从宏观上对整个系统进行分析，将之划分为互有联系又相对独立的几部分，如下图所示。
2.1.1 用户包图
2.1.2 登录包图
2.1.3 界面包图
2.1.4 接口包图
2.2 结构设计
进行了以上分析之后，本平台根据小组成员过去的开发经验，决定采用MVC框架模式。MVC采用单一入口模式进行项目部署和访问，准确处理好模块与模块之间的联系。MVC包括三个部分:控制器，定义后使用视图和模型，负责通信、转发请求、响应请求；视图，实现静态的图形界面设计；模型定义相应的控制器编写算法等等实现程序功能、实现具体的数据管理和数据库设计。MVC通用的模型设计如下图所示。
针对MVC架构对类和操作进行分析，得到的分析结果如下图：
2.3 功能模块设计
根据系统需求分析对系统进行整体的模块设计，设计出校招平台的总体功能模块结构图（HIPO图）将系统分为八部分，如下图所示。
三、数据库设计
根据系统的功能需求和系统架构模型，完成了系统的数据库设计。
3.1 数据流图
3.1.1 顶层数据流图
3.1.2 求职者数据流图
3.1.3 招聘者数据流图
3.2 E-R图设计
根据不同实体类型、属性和联系，完成对数据库E-R图设计，如下图。
3.3 关系模型分析
将E-R图转换为关系模型。
- 公司（公司id，电话号码，密码，公司名，头像链接，邮箱，企业描述，是否通过审核）
- 学生（学生id，密码，电话号码，用户名，头像链接，邮箱，性别，学校，专业，职业，当前城市，期望城市）
- 招聘会（招聘会id，公司id，时间，地点，面向人群，描述）
- 招聘信息（招聘信息id，公司id，时间戳，岗位描述，联系人及联系方式，任职资格，工作地点，投递要求，工作职责，薪酬福利，招聘或者兼职，有效）
- 简历（简历id，student_id，电话号码，用户名，简历头像链接，邮箱，性别，最高学历，职业，当前城市，期望城市，教育背景，证书，项目经历，实践经历，自我评价，简历状态）
- 简历投递（简历投递id，公司发布的职位信息的id，简历id，投递状态）
- 聊天室（学生id，hr_id，聊天室id，发送方）
- 聊天记录（记录id，聊天室id，内容，时间戳）
3.4 表结构设计
结合MySQL数据库管理系统特点和E-R图设计，主要表的结构如下：（1）student表
| 字段名 | 数据类型 | 空 | 默认 | 注释 |
|---|---|---|---|---|
| student_id | char(128) | 否 | 无 | 随机生成的主键 |
| passwd | char(32) | 否 | 无 | 密码 |
| telephone | char(14) | 否 | 无 | 电话号码 |
| user_name | char(20) | 否 | 无 | 用户名 |
| head_url | varchar(256) | 否 | 无 | 头像链接 |
| char(32) | 否 | 无 | 邮箱 | |
| sex | tinyint(4) | 否 | 无 | 性别 |
| school | char(64) | 否 | 无 | 学校 |
| specialty | varchar(64) | 否 | 无 | 专业 |
| occupation | varchar(32) | 否 | 无 | 职业 |
| present_city | varchar(64) | 否 | 无 | 当前城市 |
| expected_city | varchar(64) | 否 | 无 | 期望城市 |
（2）企业信息表
| 字段名 | 数据类型 | 空 | 默认 | 注释 |
|---|---|---|---|---|
| company_id | char(128) | 否 | 无 | 随机生成的主键 |
| telephone | char(14) | 否 | 无 | 电话号码 |
| passwd | char(32) | 否 | 无 | 密码 |
| company_name | varchar(50) | 否 | 无 | 公司名 |
| head_url | varchar(256) | 否 | 无 | 头像链接 |
| char(32) | 否 | 无 | 邮箱 | |
| description | text | 否 | 无 | 企业描述 |
| status | tinyint(4) | 否 | 无 | 是否审核 |
（3）招聘职位信息表
| 字段名 | 数据类型 | 空 | 默认 | 注释 |
|---|---|---|---|---|
| publish_time | timestamp | 否 | 当前时间 | 时间戳 |
| company_id | char(128) | 否 | 无 | 公司id |
| description | text | 否 | 无 | 岗位描述 |
| recruitment_id | int(11) | 否 | 无 | 主键 |
| contact | varchar(32) | 否 | 无 | 联系人及联系方式 |
| qualifications | varchar(128) | 否 | 无 | 任职资格 |
| location | varchar(64) | 否 | 无 | 工作地点 |
| delivery_request | varchar(64) | 否 | 无 | 投递要求 |
| duty | varchar(64) | 否 | 无 | 工作职责 |
| salary | varchar(64) | 否 | 无 | 薪酬福利 |
| type | int(11) | 否 | 无 | 招聘或者兼职 |
| validate | int(11) | 否 | 无 | 有效 |
（4）简历信息表
| 字段名 | 数据类型 | 空 | 默认 | 注释 |
|---|---|---|---|---|
| resume_id | int(11) | 否 | 自增 | 简历id |
| user_id | char(128) | 否 | 无 | 外键 |
| telephone | char(14) | 否 | 无 | 电话号码 |
| user_name | char(20) | 否 | 无 | 用户名 |
| head_url | varchar(256) | 否 | 无 | 头像链接 |
| char(32) | 否 | 无 | 邮箱 | |
| sex | tinyint(4) | 否 | 无 | 性别 |
| highest_education | tinyint(4) | 是 | NULL | 最高学历 |
| occupation | varchar(32) | 否 | 无 | 职业 |
| present_city | varchar(64) | 否 | 无 | 当前城市 |
| expected_city | varchar(64) | 否 | 无 | 期望城市 |
| degree | varchar(1024) | 否 | 无 | 教育背景 |
| certificate | varchar(1024) | 否 | 无 | 证书 |
| project_experience | varchar(2048) | 否 | 无 | 项目经历 |
| practical_experience | varchar(2048) | 否 | 无 | 实践经历 |
| self_evaluation | varchar(128) | 否 | 无 | 自我评价 |
| resume_status | int(11) | 否 | 无 | 0代表未投递，1代表已投递， |
（5）简历投递表
| 字段名 | 数据类型 | 空 | 默认 | 注释 |
|---|---|---|---|---|
| resume_delivery_id | int(11) | 无 | 自增 | 简历投递id |
| recruitment_id | int(11) | 无 | 无 | 招聘信息的id |
| resume_id | int(11) | 无 | 无 | 简历id |
| delivery_status | int(11) | 无 | 0 | 投递状态 |
四、验收验证标准
界面和功能验收验证标准已经在需求规格说明书中已经涉及，这里不再赘述。这次的验收验证标准主要是对系统设计和数据库设计：
4.1 系统体系结构需满足MVC设计模式
MVC设计模式是将整个系统划分为
（1）表现层（Presentation layer）：包含表示代码、用户交互GUI、数据验证。 该层用于向客户端用户提供GUI交互，它允许用户在显示系统中输入和编辑数据，同时 系统提供数据验证功能。
（2）业务逻辑层（Business layer）：包含业务规则处理代码，即程序中与业务 相关专业算法、业务政策等等。该层用于执行业务流程和制订数据的业务规则。业务逻 辑层主要面向业务应用，为表示层提供业务服务。
（3）数据持久层（Persistence layer）：包含数据处理代码和数据存储代码。数 据持久层主要包括数据存取服务，负责与数据库管理系统（如数据库）之间的通信。
三个层次的每一层在处理程序上有各自明确的任务，在功能实现上有清晰的区分， 各层与其余层分离，但各层之间存有通信接口。
4.2 数据库需满足第三范式
- 第一范式（1NF）：强调的是列的原子性，即列不能够再分成其他几列。
- 第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。
- 第三范式（3NF）：首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。
4.3 数据库对不同的用户要有明确的权限划分
- 游客：只有查看公开数据的权限
- 求职者：游客的权限+投递简历的权限
- 招聘者：游客的权限+发布招聘消息+审核求职信息的权限
- 系统管理员：具有系统提供的一切权限
五、预期规划
六、组员贡献占比
| 队员学号 | 队员昵称 | 用时 | 完成度 | 分工 | 贡献占比 |
|---|---|---|---|---|---|
| 221600306 | XRK | 7h+1h | 95% | 系统体系结构设计、答辩 | 19.76% |
| 221600307 | Yellye | 6h | 90% | 系统体系结构设计 | 14.33% |
| 221600315 | 黎焕明 | 8h+1h | 90% | 关系模型设计、数据表设计、答辩 | 20.49% |
| 221600319 | Litm | 4h | 85% | 类图改进、功能模块层次图、算法改进 | 11.3% |
| 221600327 | oirving | 2.5h | 85% | 类图改进、功能模块层次图、评审表 | 8.24% |
| 221600329 | supermingjun | 10h+1h | 95% | 任务安排、数据流图、类图改进、文档审核&整合、博文撰写、PPT制作、答辩 | 25.88% |