基于ESSH框架的软件日志系统毕业设计

江西经济管理干部学院毕业设计（论文）题目：基于ESSH框架的考勤日志系统
系别信息工程系专业班级
学生姓名
指导教师
指导教师职称
2016年5月20日
目录
摘要 0
引言 (1)
一、需求分析 (2)
(一)考勤日志系统需求规格说明书编写目的 (2)
(二)具体需求分析 (3)
二、系统设计 (13)
（一）总体架构 (13)
（二）数据库结构 (14)
（三）详细设计 (20)
三、编码实现 (26)
（一）编码规范 (26)
（二）算法分析 (28)
（三）单元测试 (29)
（四）部分代码分析 (29)
四、系统测试 (33)
（一）软件测试方法分类 (33)
五、小结 (37)
致谢 (38)
参考文献 (39)
运用ESSH框架的考勤日志系统
摘要：日志考勤系统应用ESSH框架（easy ui，struts2，spring，hibernate），这个框架开发效率快、稳定、可以大大简化代码量，采用MVC模式，减少软件间的耦合度，力求做到系统的稳定性、可重用性和可扩充性、能把开发更好的分工，可以进一步提高效率。

系统开发工具MyEclipse 8.5，开发语言为JAVA，后台数据库使用Oracle，Tomcat6.0作为系统服务器。

在这个模式框架上又应用了easy ui、jquery,进行前台的优化。

设计目的是为了减少公司因为请假加班这些繁琐的事务而去浪费大量的人力物力来审批请假、加班请求。

该软件功能主要有以下四个模块：用户模块、请假模块、加班模块、日志模块。

请假系统、加班系统、日志系统这三个系统都需要建立在用户模块上，需要有用户登录才可以进行这些业务修改。

小结：应用MVC模式的软件都有个共同的特点，层次分明，视图层只做视图，数据层只会和逻辑层进行交互，给开发带来方便，而MVC对于SSH 设计模式是这个的核心，MVC就是SSH框架的思想，再加上eqsy ui和jquery 技术，使得对jsp页面进行id选择更加简便。

关键词：ESSH easy ui jquery MVC
引言
随着软件行业的兴起，经济的飞速发展，越来越多的管理者认识到管理与效益是息息相关的，实现数据规范化、自动化的电脑管理规范、运作高效的企业单位的必然要求。

现在的市场竞争是知识的竞争，管理手段的竞争，谁有先进的技术设备和管理手段，谁就有成功的先机，但是，目前国内大多数企业在进行考勤管理时，使用的是传统的手工、半手工方式，如通过纸质的EXCEL 表进行记录和统计，这样的考勤管理方式不仅效率低，也容易出错，维护成本比较高，而通过单机的打卡机，进行请假和加班的申请和数据维护。

为加强对工作人员的管理工作，我们为公司开发了“考勤日志系统”，解决了该公司管理工作程序复杂、不规范等问题，优化了管理流程，实现了该公司管理工作的优化办公。

一、需求分析
(一)考勤日志系统需求规格说明书编写目的
考勤日志系统[1]定位于软件开发行业信息化建设的基础软件平台——在
对软件公司的办公、管理和信息沟通提供强有力的网络化、电子化支持外，还为其它信息化系统的引入、为这些系统间的信息交流提供帮助，实现单位信息化程度的全面提升。

该系统主要是基于Internet\Intranet和网络数据库，集流程管理、人员组织管理、系统权限管理、公共信息管理、信息共享为一体的信息管理系统。

以其特有的技术、结合各单位办公管理业务流程的特点，提供一套完整的计算机应用解决方案，最终使贵单位真正提高管理的质量和效率。

此需求规格说明书对《考勤日志系统》软件做了全面细致的用户需求分析，明确所要开发的软件应具有的功能，性能与界面，使系统分析人员及软件开发人员能清楚地了解用户的需求，并在此基础上进步提出概要设计说明书和完成后续设计与开发工作。

本说明书的预期读者为客户，业务或需求分析人员，测试人员，用户文档编写者，项目管理人员。

1、考勤日志系统范围
日志管理系统全面支持安全设备（如防火墙等）、网络设备（如交换机、路由器等）多种产品的系统日志数据的采集和分析。

支持对不同日志格式的分类、筛选、最大效率保存；日志自动导出、导入、删除、备份、恢复等日志管理功能。

提供了多样、灵活的日志信息查询，同时支持按用户设定的条件进行不同日志的相关查询，帮助管理员实现更加全面、深入的分析事件。

软件研发日志管理系统主要运用于公司管理员工的日常工作情况，员工每天上班所做的事情都要填写在日志，记录工作信息。

员工可以登录日志管理系统，根据自己的信息查询自己的日志信息。

项目经理根据员工填写的日志信息进行审批，并将审批的结果返回给员工。

(二) 具体需求分析
1、 登录模块分析
登录模块主要有登录功能，新增功能，修改功能，删除功能。

如下图1. 1用户模块所示：
图1.1 在用户模块
登录功能：用户填写帐号密码进行登录，账号和密码传递到后台进行和数据库进行比较，如果符合，将登录成功，如果不符合，返回错误信息。

如图
1.2身份验证所示：
图1.2 身份验证
N
新增功能：管理员登录后新增，首先姓名要不为空，并且密码两次验证，然后进行填写其他的信息，邮箱和号码必须要符合格式。

如果注册失败会弹出提示信息，如果格式错误控件也会弹出提示框，流程如下图1.3所示：
图1.3 新增用户
修改功能：首选要选择修改的用户（管理员权限下），对要修改的信息进行修改：并且修改的格式要相同，具体流程如下图1.4修改用户所示：
图1.4 修改用户
N
Y
删除用户：首先要选择用户，然后点击删除按钮，点击确定删除，即可删除该用户。

如图1.5删除用户所示：
图1.5 删除用户
2、 请假模块分析
登录模块主要有请假申请，修改请假，删除请假，审批请假。

如下图1.6请假模块所示：
图1.6 请假模块
N
申请请假：用户登录后对请假进行申请，首先开始请假日期不能小于结束请假日期，并且提交请假日期不能大于开始请假日期，然后进行填写其他的信息，提交失败会弹出提示，格式错误控件也会弹出提示框，流程如下图1.7请假所示：
图1.7 申请请假
请假修改：首选要选择修改的请假信息（修改的请假信息没有通过审批），对要修改的信息进行修改，具体流程如下图1.8请假修改所示：
图1.8 请假修改
N
N
删除请假：首先要选择用户，然后点击删除按钮（删除的请假信息没有通过审批），点击确定删除，即可删除该用户。

如图1.9删除请假所示：
图1.9 删除请假
审批请假：审批顺序必须先是组长通过然后经理才可以进行审批。

组长或者项目经理（管理员）首先要选择用户，然后点击审批按钮（删除的请假信息没有通过审批），点击审批，即可审批该用户。

在对审批的信息进行适当修改，然后通过如图1.10审批请假所示：
图1.10 审批请假
N
N
3、 加班模块分析
登录模块主要有加班申请，修改加班，删除加班，审批加班。

如下图1.11登陆模块所示：
图1.11 登陆模块
申请加班：用户登录后对加班进行申请，开始加班日期不能小于结束加班日期，提交加班日期不能大于开始加班日期，然后填写其他的信息，如果提交失败会弹出提示信息，格式错误控件也会弹出提示框，如下图1.12申请加班所示：
图1.12 申请加班
N
加班修改：首选要选择修改的加班信息（修改的加班信息没有通过审批），对要修改的信息进行修改：并且修改的格式要相同，具体流程如下图1.13加班修改所示：
图1.13 加班修改
删除加班：首先要选择加班信息，然后点击删除按钮（删除的加班信息没有通过审批），点击确定删除，即可删除该用户。

如图1.14删除加班所示：
图1.14 删除加班
N
N
审批加班：审批顺序必须先是组长通过然后经理才可以进行审批。

组长或者项目经理（管理员）首先要选择用户，然后点击审批按钮（删除的加班信息没有通过审批），点击审批，即可审批该用户。

在对审批的信息进行适当修改，然后通过如图1.15审批加班所示：
图1.15 审批加班
4、 日志模块分析
日志模块主要有新增日志，修改日志，删除日志，审批日志。

如下图1. 16日志模块所示：
图1.16 日志模块
N
申请日志：用户登录后对日志进行申请，首先填写日志名，日志内容，然后进行填写其他的信息，如果提交失败会弹出提示信息，如果格式错误控件也会弹出提示框，流程如下图1.17申请日志所示：
图1.17 申请日志
日志修改：首选要选择修改的日志信息（修改的日志信息没有通过审批），对要修改的信息进行修改，具体流程如下图1.18日志修改所示：
图1.18 日志修改
N
N
删除日志：首先要选择日志信息，然后点击删除按钮（删除的日志信息没有通过审批），点击确定删除，即可删除该用户。

如图1.19删除日志所示：
图1.19 删除日志
审批日志：审批顺序必须先是组长通过然后经理才可以进行审批。

组长或者项目经理（管理员）首先要选择用户，然后点击审批按钮（删除的日志信息没有通过审批），点击审批，即可审批该用户。

在对审批的信息进行适当修改，然后通过如图1.20审批日志所示：
图1.20 审批日志
N
N
二、系统设计
（一）总体架构
1、系统架构
完成了需求分析之后，就进入系统的设计阶段，在整个系统开发周期，设计阶段也很重要，设计任务分为两个阶段，第一阶段是概要设计阶段，，主要任务是建立软件的总体结构，即软件的组成，以及各组成成分(子系统或模块)之间的相互联系，第二阶段是详细设计，该任务是确定模块的算法结构。

应用ESSH框架（easy ui，struts2，spring，hibernate[2]）。

本系统根据需求分析在进行设计出原型，然后在原型的基础上进行测试和改进。

架构设计：架构的本质在于其抽象性，包括两个方面的抽象：业务抽象和技术抽象。

优点：
有助于提高重用性,根据实际情况决定不同类间的耦合度,必须客观的评价耦合度。

根据需求的稳定性，来决定耦合的程度恰到好处在同样都能够满足需要的情况下，一项简单的设计远比复杂的设计来的直接和有效。

应用模式：
模式和功能组件的区别就在于模式会引发你的思考模式,应用在架构设计上，能够大大增强架构的稳定性。

架构模式:
层次模式: 在层次模式中, 应用被分解为若干层次。

现在流行的应用系统三层架构, 网络服务的七层协议都是典型的层次模式的例子。

MVC[3]模式: 即模型-视图-控制模式。

在MVC 模式中, 应用分为三部分: 模型负责数据和其中的规则, 视图负责信息如何展现给用户,控制则负责处理用户的输入。

（二）数据库结构
数据库[4]的设计实际上是对项目设计的一个整体规划，因为数据库中表的结构都是与程序紧密相关的，如果数据库设计如果没有到位，设计会受到一定的影响。

1、表汇总
本系统采用Oracle[5]数据库，系统数据库名为LGMS，数据库ORCL中包括13个数据表。

如表2-1标汇总所示：
表 2-1表汇总
2、日志表
这是日志表，存放日志信息，当进行业务时，就是对这个表进行处理。

具体如表2-2 T_BASE_LOG所示：
表 2-2 T_BASE_LOG
这是用户表，存放用户信息，当进行业务时，就是对这个用户表进行处理。

具体如表2-3 T_BASE_USER所示：
表 2-3T_BASE_USER
4、角色表
这是角色表，存放角色信息，控制用户权限。

与菜单表和用户表可以进行外键连接。

来控制用户权限。

具体如表2-4 T_BASE_ROLE所示：
表 2-4T_BASE_ROLE
这是组织表，存放组织信息。

可以与用户进行外键连接，来控制用户权限的必要的表。

具体如表2-5 T_BASE_ORGAN所示：
表 2-5T_BASE_ORGAN
6、用户组织外表
这是用户和组织的外表，两个都为外键。

具体如表2-6 T_BASE_USER_ORGAN 所示：
表 2-6T_BASE_USER_ORGAN
7、字典类型表
这是字典表，存放数据字典信息，当进行相关业务是，就是对这个表处理。

具体如表2-7 T_SYS_DICTIONARYTYPE所示：
表 2-7T_SYS_DICTIONARYTYPE
8、字典表
这是字典表，存放数据字典信息，当进行相关业务是，就是对这个表处理。

具体如表2-8 T_SYS_DICTIONARY所示：
表 2-8T_SYS_DICTIONARY
9、用户角色外表
这是用户角色的外表，控制用户权限的表。

具体如表2-9 T_BASE_USER_ROLE 所示：
表 2-9T_BASE_USER_ROLE
10、资源表
这是资源的表。

用来和角色进行外键连接，从而进行权限的控制。

具体如表2-10 T_BASE_RESOURCE所示：
表 2-10T_BASE_RESOURCE
11、资源角色表
这是资源角色的表，控制角色的表。

和用户表进行外键连接，控制用户权限。

具体如表2-11 T_RESOURCE_ROLE所示：
表 2-11T_RESOURCE_ROLE
12、角色菜单外表
这是角色菜单的外表，控制菜单的表。

具体如表2-12 T_BASE_ROLE_MENU 所示：
表 2-12T_BASE_ROLE_MENU
13、菜单表
这是菜单的外表，控制菜单的表，与角色表外键连接，控制权限。

具体如表2-13 T_BASE_MENU所示：
表 2-13T_BASE_MENU
14、BUG
这是系统BUG的表。

系统的BUG全部会存入这个表。

具体如表2-14
T_SYS_BUG所示：
表 2-14T_SYS_BUG
（三）详细设计
1、请假模块
请假设计主要有以下界面如下图2. 1请假申请所示：
1)请假申请：所有员工进入请假申请页面，选项卡方式显示我的请假。

2)点击请假申请，弹出请假申请的对话框。

3)在对话框填入申请人、请假类别、请假日期、开始时间、结束时间、请假天
数、请假事由等信息。

4)点击请假申请按钮，将请假申请提交给项目经理。

图2.1 请假申请
修改申请：
1)当所有员工进入我的申请页面时，点击修改申请按钮弹出其界面。

修改申请界面需填写的主要内容包括：请假人姓名，请假类别，开始时间，结束时间，最底部的修改申请按钮为事件触发按钮即当您点击此按钮时会弹出如图2. 2申请主页图和2.3修改页面图的界面，单您点击确定按钮时，你的修改信息将被写入数据库，即您的本次修改已成功。

图2.2 申请主页
图2.3 修改页面
请假撤销：
1)选择你要撤销的请假信息，然后点击撤销请假按钮。

2)点击确定的话就执行撤销申请的操作，否则反之，返回主界面。

如图2.4删
除申请所示：
图2.4 删除申请
2、加班模块
加班申请：
1)加班申请：点击添加按钮，弹出一个加班申请页面。

2)在页面上显示申请人，项目名称，加班日期，加班类型，加班时长，开始和
结束时间。

3)当填写完信息后点击保存。

4)申请完后页面自动刷新。

如图2.5加班申请和图2.6加班主页所示：
图2.5 加班申请
图2.6 加班主页
3、日志模块
日志新增：
1)用户通过日志管理系统登录，然后点击首页（日期查询页面）的+号可以展
开，可以在那边的日期添加日志。

组员进入日志添加页面，选项卡方式只显示自己的日志，用户在每个分页面输入要查询的条件，点击查询，页面列表显示所有符合查询条件的日志信息。

3)点击新增会在日志页面列表弹出链接，显示日志名称、日志类型、状态。

4)日志分为公共日志、个人事务、其他日志，状态包括待审批、拒绝、已审批。

开始日期和结束日期的日期选择控件的第一列为星期四(默认)，最后一天为星期三。

如图2.7日志主页、图2.8日志新增和图2.9日志查询所示：
图2.7 日志主页
图2.8 日志新增
图2.9 日志查询
日志删除：
1)通过日志管理系统登录，然后点击首页（日期查询页面）的+号可以展开，
可以在那边的日期下面删除日志。

所有用户进入日志日期查询页面，管理员在每个分页面输入要查询的条件，点击日期可以查到自己的日志，页面列表显示所有符合条件的日志信息。

3)日志删除只能是自己删除自己的日志，组长没有权限删除他人日志。

如图
2.10日志删除所示：
图2.10 日志删除
三、编码实现
（一）编码规范
1.文件命名规范
2.方法排版规则
1)方法名和其后的括弧之间不应有空格。

2)在方法的局部变量声明和语句之间加一个空行。

3)块注释或单行注释之前必须有一行空行。

4)方法内的两个逻辑段之间必须有一行空行。

5)简单语句每行至多包含一条语句。

3.语句排版规则
1)必须用“{”和“}”将if内的语句括起来。

(即使只有一条语句
的情况下)。

2)每当一个case顺着往下执行时(因为没有break语句)，通常
应在break语句的位置添加注释。

3)使用JavaDoc，列出功能、版本信息、日期、作者和版权声明。

4)如果对文件进行了修改，必须说明修改目的、修改日期、修改
人，并变更版本信息。

4.类方法注释规则
1)用中文写出每个参数和返回值的含。

2)当修改其他组员创建的类时，增加@author标签。

块注释规则：
1)方法内部的块注释位于所描述内容之前。

2)块注释前留一行空行。

单行注释规则：
1)单行注释位于所描述内容之前。

2)单行注释之前留一行空行。

5.变量命名规则
1)变量名采用大小写混合的方式，第一个单词的首字母小写，其
后单词的首字母大写。

2)除一次性的临时变量（如for循环变量）以外，不能用单个字符
的变量名。

3)如果变量名代表容器（collection），如Array, Vector等，在
变量名后加“List”或者“s”。

6.方法命名规则
1)方法名是动词或动词＋名词对，采用大小写混合的方式，第一个单词的
首字母小写，其后单词的首字母大写。

7.方法的参数命名规则：
1)使用全英文命名。

首字母小写，后续单词首字母大写。

8.数组命名规则：
1)将[] 放在类型后。

9.变量规范
1)不要将不同类型变量的声明放在同一行。

2)提供对实例以及类变量的get和set方法。

3)不要在一个语句中给多个变量赋相同的值。

10.尾端注释规则
1)对变量或常量的简短注释在代码右端。

2)代码和尾端注释之间留有足够多的空白。

（二）算法分析
1、逻辑删除
除了一般的增删改查，该系统还毒用户进行了权限管理，如果是员工A登录系统，那么查询的信息只能是A的信息，如果A删除日志（逻辑删除），那么那条日志A将无权限看到删除的日志，如果组长删除A那条日志，同理，组长也无权限访问那条日志。

2、回显查询
在jsp页面的查询条件有下拉框查询，下拉框的数据是有后台提供，并且显示该权限下用户可以查到的条件在进行下拉框查询。

（三）单元测试
测试分为四大模块进行测试：用户模块、请假模块、加班模块、日志模块。

这四个模块分别对系统进行了系统性的测试，详情请查询《测试用例书》。

1)登录测试
测试是否登录成功，如果失败将会回到原页面，成功将会跳到下一页面。

详
情如下表3-1所示：
表3-1 用户登录测试表
2)修改密码测试
测试是否密码修改成功，如果失败将会返回出错信息，成功将会跳到下一页
面。

详情如下表3-2所示：
表3-2 用户登录测试表
（四）部分代码分析
这是一段获取数据并将数据转换成json数据通过jsp页面显示出来。

以下注释对代码简单的介绍：
public String datagrid2() throws Exception {
try {
//获得登录对象
User sessionUser = userManager.getCurrentUser();
// 自动构造属性过滤器
List<PropertyFilter> filters = HibernateWebUtils
.buildPropertyFilters(Struts2Utils.getRequest());
Page<Log> p = getEntityManager().find(page, rows, sort, order,filters);
//获取所有数据
List<Log> datalist=p.getResult();
//循环，如果user有数据改为空
for (Log log:datalist){
log.setUser(null);
}
//如果是管理员则不需要判断身份
if(!(sessionUser.getId()==1)){
//循环，对数据进行移除
for(int i=0;i<datalist.size();i++){
Log log=datalist.get(i);
int visble=log.getVisble();
//如果登录名和数据的名字一致或者是组长登录
if(!log.getLoginName().equals(sessionUser.getLoginName())&& sessionUser.getId()!=1738822)
{
datalist.remove(i);
i--;
}
//如果是组长登录或者该数据状态为组长不可见
if(sessionUser.getId()==1738822 &&
(1==visble||100==visble)){
datalist.remove(i);
i--;
}
//如果是组员登录或者该数据状态为组员不可见
if(sessionUser.getId()!=1738822 &&
(10==visble||100==visble)){
datalist.remove(i);
i--;
}
}
}
else
{jurisdiction = 2; }
if(sessionUser.getId()==1738822){ jurisdiction = 1; }
//将身份标示传到jsp页面
session.setAttribute("jurisdiction", jurisdiction);
Datagrid<Log> dg = new Datagrid<Log>(datalist.size(),datalist);
Struts2Utils.renderJson(dg);
} catch (Exception e) {throw e; }
return null;
}
四、系统测试
（一）软件测试方法分类
软件测试技术按照不同的划分方法，有不同的分类：静态测试、动态测试；黑盒测试、白盒测试；单元测试、集成测试、回归测试、系统测试、验证测试以及确认测试。

1、静态测试与动态测试
按照软件测试分析与非分析方法而论，软件测试可以分静态测试和动态测试。

1)静态测试
指不实际运行软件，主要是对软件的编程格式、结构等方面进行评估。

静态测试包括：代码检查、静态结构分析、代码质量度量等。

它可以由人工进行，也可以借助软件工具自动进行。

2)动态测试
动态测试方法是指计算机必须真正运行被测试的程序，通过输入测试用例，对其运行情况即输入与输出的对应关系进行分析，以达到检测的目的。

动态测试包括：功能确认与接口测试，覆盖率分析，性能分析，内存分析。

2、黑盒与白盒测试
1)黑盒测试
按照软件测试用例的设计方法而论，软件测试可以分为白盒测试法和黑盒测试法。

若测试规划是基于产品的功能，目的是检查程序各个功能是否能够实现，并检查其中的功能错误，则这种测试方法称为黑盒测试(Black-box Testing)方法。

黑盒测试又称为功能测试、数据驱动测试和基于规格说明的测试。

它是一种从用户观点出发的测试，一般被用来确认软件功能的正确性和可操作性。

黑盒测试主要根据规格说明书设计测试用例，并不涉及程序内部构造和内部特性，只依靠被测程序输入和输出之间的关系或程序的功能设计测试用例。

2、黑盒测试的特点
黑盒测试与软件的具体实现过程无关，在软件实现的过程发生变化时，测试用例仍然可以使用。

黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。

若测试规划基于产品的内部结构进行测试，检查内部操作是否按规定执行，软件各个部分功能是否得到充分使用，则这种测试方法称为白盒测试(White-box Testing)方法。

2)白盒测试
白盒测试又称为结构测试、逻辑驱动测试或基于程序的测试，一般用来分析程序的内部结构。

白盒测试要求是对某些程序的结构特性做到一定程度的覆盖，或者说这种测试是“基于覆盖率的测试”。

通常的程序结构覆盖有：语句覆盖，判定覆盖，条件覆盖，判定/条件覆盖，路径覆盖。

单元测试、集成测试、系统测试、验证测试和确认测试。

按照软件测试的策略和过程来分类，软件测试可分为单元测试、集成测试、系统测试、验证测试和确认测试。

测试中的错误分类：
A类错误：致命错误——引起程序异常中断或死机的错误等。

B类错误：功能错误——业务功能实现错误、程序执行结果错误等。

C类错误：功能缺陷——功能操作不方便、缺少操作提示等。

D类错误：界面缺陷——界面设计不符合本系统的界面设计规范等。

E类错误：测试正确——正确的测试项、测试结果与预期的一致等。

测试报告：
本系统经过测试，功能基本正常，达到了预期的目的。

通过对系统的全面测试，我学到了许多测试方面的知识，了解到测试方法、测试经验。

通过本次设计，使我了解到测试的重要性。

通过测试，可以使软件更适合用户的需求，更加稳定、可靠地运行。

我发现测试原来可以把bug更仔细的找出来，包括编码过程中无法发现的小bug。

渐渐的对测试有了浓厚的兴趣，为以后就业方向提供了帮助。