2。1。2 技术可行性
学生公寓管理系统使用的技术都是较为基础的,通过一定时间的学习完全可以熟练掌握。而Eclipse、MySQL等开发工具都是较为成熟的,在设计和实现的过程中不会有太大问题。因此该系统对现有技术来说,是完全不成问题的。
2。1。3 操作可行性
本系统采用B/S架构,在windows系统下运行,通用于各种常见浏览器。只要是熟悉计算机的人员通过短时间的运用就能熟练操作本系统。
2。2 需求分析
通过对该系统进行详细的需求分析,并结合实际情况,该系统应具备以下功能:
(1)界面良好,易于操作
(2)管理员和学生分别登录
(3)管理员注册学生账号,并且能够批量注册
(4)管理员对公寓信息进行增删改查
(5)学生用户对自身信息进行查询和修改
(6)学生对公寓信息进行查询
(7)学生请求调换宿舍和管理员的审阅
(8)管理员可以发布公告
第三章 系统概要设计
3。1 系统结构设计
根据学生公寓管理系统的实际需求,该系统结构层次图如图3-1所示:
图3-1 系统结构层次图
所有用户均可查看和下载公告内容。
3。2 系统用例图
本系统包含2种用户,管理员和学生用户。两种用户的功能图如图3-2所示:
图3-2 系统用例图
3。3 系统流程图
本系统包括系统流程图如图3-3所示:
图3-3 系统流程图
3。4 数据库概要设计
根据系统的实际需求可以建立学生、管理员、公寓、请求、公告五种实体。使用实体-关系图(E-R图)建立数据模型,具体如图3-4所示:
图3-4 实体-关系图
实体关系如下:
学生(学号,密码,姓名,性别,专业,毕业年份)
管理员(用户名,密码)
公寓(楼号,层号,宿舍号,床位号,学生学号)
请求(编号,学号,旧宿舍,新宿舍,理由,审核状态)
公告(编号,标题,内容,发布时间)
一个管理员可以管理多个学生,一个学生能被多个管理员管理,所以管理员和学生之间是多对多的关系。一个管理员可以管理多个公寓,一个公寓能被多个管理员管理,所以管理员和公寓之间是多对多的关系。一个管理员可以处理多条请求,一条请求只能被一个管理员处理,所以管理员和请求之间是一对多的关系。一个管理员可以管理多条公告,一条公告能被多个管理员管理,所以管理员和公告之间是多对多的关系。
第四章 系统详细设计
4。1 数据库设计
为了方便管理学生公寓系统的各项信息,本节对系统进行数据库设计并规划出数据库结构,主要设计出管理员信息表、学生信息表、公寓信息表、调换公寓请求表和公告信息表。这五张表的详细介绍如下:
4。1。1 管理员信息表(admin)
管理员信息表用来存储管理员登录的用户名和密码。各字段详情如下:
(1)username: 该字段表示管理员用于登录的用户名,是该表的主键。
(2)password: 该字段表示管理员用于登录的密码。
管理员信息表设计详情如表4-1所示:
表4-1 管理员信息表
列 名 数据类型 字符长度 约束条件 说 明
username varchar