基于ESSH框架的软件日志系统毕业设计论文Word文档格式.docx

基于ESSH框架的软件日志系统毕业设计论文Word文档格式.docx

《基于ESSH框架的软件日志系统毕业设计论文Word文档格式.docx》由会员分享，可在线阅读，更多相关《基于ESSH框架的软件日志系统毕业设计论文Word文档格式.docx（53页珍藏版）》请在冰豆网上搜索。

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

1、考勤日志系统范围

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

支持对不同日志格式的分类、筛选、最大效率保存；

日志自动导出、导入、删除、备份、恢复等日志管理功能。

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

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

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

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

（二）具体需求分析

1、登录模块分析

登录模块主要有登录功能，新增功能，修改功能，删除功能。

如下图1.1用户模块所示：

图1.1在用户模块

登录功能：

用户填写帐号密码进行登录，账号和密码传递到后台进行和数据库进行比较，如果符合，将登录成功，如果不符合，返回错误信息。

如图1.2身份验证所示：

图1.2身份验证

新增功能：

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

如果注册失败会弹出提示信息，如果格式错误控件也会弹出提示框，流程如下图1.3所示：

图1.3新增用户

修改功能：

首选要选择修改的用户（管理员权限下），对要修改的信息进行修改：

并且修改的格式要相同，具体流程如下图1.4修改用户所示：

图1.4修改用户

删除用户：

首先要选择用户，然后点击删除按钮，点击确定删除，即可删除该用户。

如图1.5删除用户所示：

图1.5删除用户

2、请假模块分析

登录模块主要有请假申请，修改请假，删除请假，审批请假。

如下图1.6请假模块所示：

图1.6请假模块

申请请假：

用户登录后对请假进行申请，首先开始请假日期不能小于结束请假日期，并且提交请假日期不能大于开始请假日期，然后进行填写其他的信息，提交失败会弹出提示，格式错误控件也会弹出提示框，流程如下图1.7请假所示：

图1.7申请请假

请假修改：

首选要选择修改的请假信息（修改的请假信息没有通过审批），对要修改的信息进行修改，具体流程如下图1.8请假修改所示：

图1.8请假修改

删除请假：

首先要选择用户，然后点击删除按钮（删除的请假信息没有通过审批），点击确定删除，即可删除该用户。

如图1.9删除请假所示：

图1.9删除请假

审批请假：

审批顺序必须先是组长通过然后经理才可以进行审批。

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

在对审批的信息进行适当修改，然后通过如图1.10审批请假所示：

图1.10审批请假

3、加班模块分析

登录模块主要有加班申请，修改加班，删除加班，审批加班。

如下图1.11登陆模块所示：

图1.11登陆模块

申请加班：

用户登录后对加班进行申请，开始加班日期不能小于结束加班日期，提交加班日期不能大于开始加班日期，然后填写其他的信息，如果提交失败会弹出提示信息，格式错误控件也会弹出提示框，如下图1.12申请加班所示：

图1.12申请加班

加班修改：

首选要选择修改的加班信息（修改的加班信息没有通过审批），对要修改的信息进行修改：

并且修改的格式要相同，具体流程如下图1.13加班修改所示：

图1.13加班修改

删除加班：

首先要选择加班信息，然后点击删除按钮（删除的加班信息没有通过审批），点击确定删除，即可删除该用户。

如图1.14删除加班所示：

图1.14删除加班

审批加班：

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

在对审批的信息进行适当修改，然后通过如图1.15审批加班所示：

图1.15审批加班

4、日志模块分析

日志模块主要有新增日志，修改日志，删除日志，审批日志。

如下图1.16日志模块所示：

图1.16日志模块

申请日志：

用户登录后对日志进行申请，首先填写日志名，日志内容，然后进行填写其他的信息，如果提交失败会弹出提示信息，如果格式错误控件也会弹出提示框，流程如下图1.17申请日志所示：

图1.17申请日志

日志修改：

首选要选择修改的日志信息（修改的日志信息没有通过审批），对要修改的信息进行修改，具体流程如下图1.18日志修改所示：

图1.18日志修改

删除日志：

首先要选择日志信息，然后点击删除按钮（删除的日志信息没有通过审批），点击确定删除，即可删除该用户。

如图1.19删除日志所示：

图1.19删除日志

审批日志：

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

在对审批的信息进行适当修改，然后通过如图1.20审批日志所示：

图1.20审批日志

二、

系统设计

（一）总体架构

1、系统架构

完成了需求分析之后，就进入系统的设计阶段，在整个系统开发周期，设计阶段也很重要，设计任务分为两个阶段，第一阶段是概要设计阶段，，主要任务是建立软件的总体结构，即软件的组成，以及各组成成分（子系统或模块）之间的相互联系，第二阶段是详细设计，该任务是确定模块的算法结构。

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

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

架构设计：

架构的本质在于其抽象性，包括两个方面的抽象：

业务抽象和技术抽象。

优点：

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

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

应用模式：

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

架构模式:

层次模式:

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

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

MVC[3]模式:

即模型-视图-控制模式。

在MVC模式中,应用分为三部分:

模型负责数据和其中的规则,视图负责信息如何展现给用户,控制则负责处理用户的输入。

（二）数据库结构

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

1、表汇总

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

如表2-1标汇总所示：

表2-1表汇总

表名

功能说明

T_BASE_LOG

日志表，用户填写、修改的日志表都会上传到这个表里面

T_BASE_USER

用户表，组员组长管理员的表

T_BASE_ROLE

用户角色

T_BASE_ORGAN

组织表

T_BASE_USER_ORGAN

用户组织

T_SYS_DICTIONARYTYPE

数据字典类型

T_SYS_DICTIONARY

数据字典

T_BASE_USER_ROLE

用户角色表

T_RESOURCE_ROLE

资源角色

T_BASE_RESOURCE

资源表

T_BASE_ROLE_MENU

角色菜单

T_BASE_MENU

菜单

T_SYS_BUG

漏洞

2、日志表

这是日志表，存放日志信息，当进行业务时，就是对这个表进行处理。

具体如表2-2T_BASE_LOG所示：

表2-2T_BASE_LOG

列名

数据类型（精度范围）

空/非空

约束条件

ID

NUMBER（19）

非空

外键

LOGNAME

VARCHAR2（255CHAR）

Type

state

NUMBER（6）

context

LOG_ID

主键

补充说明

除了主键、登录名外，其他的都可为空

3、用户表

这是用户表，存放用户信息，当进行业务时，就是对这个用户表进行处理。

具体如表2-3T_BASE_USER所示：

表2-3T_BASE_USER

CREATE_TIME

TIMESTAMP（6）

CREATE_USER

VARCHAR2（36CHAR）

STATUS

NUMBER（10）

UPDATE_TIME

UPDATE_USER

VERSION

EMAIL

LOGINNAME

VARCHAR2（32CHAR）

MOBILEPHONE

NAME

PASSWORD

VARCHAR2（64CHAR）

SEX

TEL

用户的登录等操作查询这个表

4、角色表

这是角色表，存放角色信息，控制用户权限。

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

来控制用户权限。

具体如表2-4T_BASE_ROLE所示：

表2-4T_BASE_ROLE

主键、外键

组员和组长的关系

5、组织表

这是组织表，存放组织信息。

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

具体如表2-5T_BASE_ORGAN所示：

表2-5T_BASE_ORGAN

ADDRESS

CODE

MANAGER

PHONE

PARENT_ID

6、用户组织外表

这是用户和组织的外表，两个都为外键。

具体如表2-6T_BASE_USER_ORGAN所示：

表2-6T_BASE_USER_ORGAN

ORGAN_ID

USER_ID

组织

7、字典类型表

这是字典表，存放数据字典信息，当进行相关业务是，就是对这个表处理。

具体如表2-7T_SYS_DICTIONARYTYPE所示：

表2-7T_SYS_DICTIONARYTYPE

ORDER_NO

这个表是数据字典类型

8、字典表

具体如表2-8T_SYS_DICTIONARY所示：

表2-8T_SYS_DICTIONARY

REMARK

DICTIONARYTYPE_CODE

VARCHAR2（12CHAR）

PARENT_CODE

这个表是数据字典

9、用户角色外表

这是用户角色的外表，控制用户权限的表。

具体如表2-9T_BASE_USER_ROLE所示：

表2-9T_BASE_USER_ROLE

ROLE_ID

这个表是用户角色

10、资源表

这是资源的表。

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

具体如表2-10T_BASE_RESOURCE所示：

表2-10T_BASE_RESOURCE

ICON

ORDERNO

PERMISSION

TYPE

URL

11、资源角色表

这是资源角色的表，控制角色的表。

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

具体如表2-11T_RESOURCE_ROLE所示：

表2-11T_RESOURCE_ROLE

RESOURCE_ID

12、角色菜单外表

这是角色菜单的外表，控制菜单的表。

具体如表2-12T_BASE_ROLE_MENU所示：

表2-12T_BASE_ROLE_MENU

MENU_ID

13、菜单表

这是菜单的外表，控制菜单的表，与角色表外键连接，控制权限。

具体如表2-13T_BASE_MENU所示：

表2-13T_BASE_MENU

ICO

MARK_URL

14、BUG

这是系统BUG的表。

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

具体如表2-14T_SYS_BUG所示：

表2-14T_SYS_BUG

TITLE

VARCHAR2（2