OA办公自动化系统文档.docx
《OA办公自动化系统文档.docx》由会员分享,可在线阅读,更多相关《OA办公自动化系统文档.docx(55页珍藏版)》请在冰豆网上搜索。
OA办公自动化系统文档
OA办公自动化系统报告
OA办公自动化系统报告1
摘要3
Abstract3
1需求分析3
1.1可行性分析3
1.1.1经济可行性3
1.1.2技术可行性3
1.2需求分析3
1.2.1目标分析3
1.3.2结构分析3
1.3.3功能分析3
1:
业务流程图3
2项目概要设计分析3
2.1:
项目概要分析3
2.1.1:
用例分析3
2.1.2:
流程分析3
2.1.3:
关系分析3
3:
项目详细设计3
3.1:
业务对象模型设计3
3.1.1:
业务对象提取3
3.1.2:
关系设计3
3.2:
功能逻辑顺序设计3
3.3:
数据库设计3
3.3.1:
数据库概念设计3
3.3.2:
表结构设计3
3.4:
界面设计3
4:
代码设计3
4.1:
配置文件代码设计3
4.2:
Dao层的代码设计3
4.3:
Service层代码的实现3
4.4:
action层代码的实现3
4.5:
页面js和Ajax部分代码3
5项目总结3
摘要
本次项目编写的办公自动化系统(OA)是一个比较成熟的系统,它主要负责公司日常工作管理的事务。
包括了用户权限管理、员工管理、日常管理、考勤管理、办公用品管理、客户管理、合同管理、报销管理共八个部分。
基本实现了公司无纸化办公。
在开发过程中,我们以小组为单位进行。
技术方面使用的是Struts2+Spring+Hibernate(MVC)三框架技术,数据库使用Mysql,前台页面与后台交互使用了部分Jquery脚本和Ajax技术。
页面布局和基本弹窗提醒使用CSS+DIV+JavaScript技术
在小组中我负责的模块是员工管理和日常管理。
其中员工管理包括了员工管理、部门管理和培训管理三大功能,分别实现了员工信息的添加删除修改,普通查询以及多条件查询,部门信息的增添修改删除和查询。
员工培训申请的提交审批以及安排等等。
完整地系统是对现存的OA系统的简化版本。
关键字:
OA办公自动化员工管理日常管理
Abstract
Theprojectpreparedbytheofficeautomationsystem(OA)isarelativelymaturesystem,whichismainlyresponsibleforthedailymanagementoftheaffairsofthecompany.Includesuserrightsmanagement,staffmanagement,dailymanagement,attendancemanagement,officesuppliesmanagement,customermanagement,contractmanagement,claimsmanagementofeightparts.Thebasicrealizationofthecompany'spaperlessoffice.Inthedevelopmentprocess,weasateamunit.TechnicalaspectsofusingStruts2+Spring+Hibernate(MVC)threeframeworktechnology,databaseusingMysql,frontpageandbackinteractiveusesomeJqueryscriptsandAjaxtechnologies.PagelayoutandbasicpopupremindertouseCSS+DIV+JavaScripttechnologyInthegroupIwasresponsibleforstaffmanagementmoduleanddailymanagement.Whichincludesstaffmanagementstaffmanagement,departmentalmanagementandtrainingmanagementthreefunctions,respectively,toachievetheadddeletemodifyemployeeinformation,generalinquiriesandmulti-criteriaquery,thedepartmentaddedmodificationanddeletionofinformationandqueries.Stafftrainingapplicationssubmittedforapprovalandarrangingandsoon.CompletetheexistingsystemisasimplifiedversionofOAsystem.
Keywords:
OAofficeautomationdailymanagementofstaffmanagement
1需求分析
1.1可行性分析
1.1.1经济可行性
对于一个具有一定规模的企业来说办公自动化部分是十分重要的,同时也有一定的复杂性。
若是没有相应的系统支持,会花费大量的人力物力以及时间资源。
并且容易出现问题,一个好的办公自动化,则可以避免这种情况的发生。
它可以解放企业在这方面所花费的大量资源,并且提供更高效更合理的管理逻辑。
提高了企业的经济效率。
1.1.2技术可行性
小组编写的管理系统可以实现。
企业的信息共享,方便了公司对员工的出勤考察,薪酬管理,办公用品、日志管理的完善。
同时使得管理更加合理化和公正化。
避免了人员手动管理带来的速度慢、准确性不高的缺点,为企业的员工提供更加方便和便捷的工作环境。
其中我负责的系统管理和奖惩管理,则可以规化企业的管理流程,有利于提高企业的相关信息性,同时避免了相关信息被不具有相关权限的人修改。
同时也方便了管理人员对员工的一年工作奖惩情况统计,为员工查询自己的奖惩情况提供依据。
1.2需求分析
当今社会,企业部人力资源管理和办公管理越来越完善,这方便了办公自动化管理系统的搭建。
而由于办公自动化系统的操作简单。
功能全面。
可以用于对企业员工信息的存储,对员工日常工作生活的管理,有利于管理人员对员工的薪资和出勤、工作任务的完成情况、新员工的招收、辞职员工的处理等方面做出更快更好的处理响应。
一个好的办公自动化系统可以提高企业的效率,使得管理更加网络化、科学化。
这一部分主要完成了整个系统的目标、结构、功能等方面的分析和整个系统结构的划分,为以后的详细设计打好基础,也为小组的分工提供依据。
1.2.1目标分析
小组编写的是一个公司的办公自动化管理系统,通过分析,对该系统的目标有了如下的认识和总结:
总目标
●对公司职员的考勤、培训、日常提供管理
●对单个员工的详细资料和奖惩情况提供查询的操作
●对公司非公开资料提供有一定安全性的存储
●系统设计合理,结构合理,符合设计要求
功能目标
1)员工管理:
提供员工信息的查询、按员工id查询、录入、修改、删除操作
2)日常管理:
提供培训的申请,日志的添加查询审批。
3)考勤管理:
通过员工每日的签到可以完成对员工考勤和请假信息的统计
4)办公管理:
对公司的资源(会议室,公车,办公品)的调配和相应资源的申请。
5)报销管理:
员工填写报销单,管理员或者经理审核报销单,批准或者打回报销单
6)客户管理:
管理员填写客户单,保存客户信息,同时保存练习人信息。
7)合同管理:
管理员保存合同信息和合同签署人信息。
8)权限管理:
超级管理员和管理员的权限管理,实现管理员的添加删除、系统登陆等操作。
性能目标
(1)使用系统可以提高对员工的管理效率,提高公司的整体运行效率
(2)使用该系统提高了公司管理的合理性和安全性
(3)只限于部员工对系统的操作,非本公司员工无法操作
项目运行环境
安装有浏览器的windows2000/windowsxp/windows7
项目开发环境
项目是在Myeclipse的环境下开发编写的,部分网页的编写使用了Dreamweaver
服务器:
Tomcat,数据库:
Mysql数据库
1.3.2结构分析
本部分是对系统的一个模块划分,便于组员分配工作
1.3.3功能分析
这部分是根据系统的需求来分析该系统的功能。
其中我负责的是员工管理和日常管理两部分的功能实现。
下面是从用例、流程等方面说明我负责部分的功能
1:
业务流程图
业务流程图让我们更清晰的认识到整个系统的各个功能模块的划分,下面是次系统的业务流程图
管理员登陆流程:
普通员工登陆流程:
2项目概要设计分析
2.1:
项目概要分析
概要设计主要包括了项目开发前期对项目涉及的用例以及相互之间的关系进行分析,同时对每个模块需要实现的流程和逻辑作出设计和分析
2.1.1:
用例分析
一:
员工管理用例分析
用户管理分为两个部分:
员工管理、部门管理,其中员工管理部分,管理员可以对员工进行添加操作,可以根据员工的,入职时间,所在部门等条件查询符合要求的员工,可以对不需要的员工信息进行删除,对已录入员工信息进行变更。
员工方面则可以在登陆之后修改自己的账号密码
部门管理中,管理员可以根据部门编号查询部门,可以在需要的情况下添加新的部门信息,也可以删除已合并或者重组的部门,可以修改部门信息。
以下是员工管理的整体用例图
二:
日常管理用例分析
1:
日志管理
员工每天完成自己的工作之后,需要提交一个日志,员工登录系统后,选择日志管理界面,点击新建日志,会有弹出窗或者新跳转一个页面进入日志的编写界面,在员工完成日志的编辑之后点击提交按钮,会在后台数据库中添加一条日志记录,同时日志的状态自动设置为未审核,级别为null。
日志管理员需要登录系统,进入日志管理页面查询日志,查询状态为未审核的日志,在每条日志记录的操作栏中会有详细信息的按钮,点击可阅读日志全文,在日志阅读界面(弹窗或者跳转)下方会有一个级别单选按钮组(优良差)选择后点击审核,会自动把日志状态设置为已审核,同时会将级别加入数据库
员工可以登录系统后点击我的日志,可以根据登陆的id查看自己的日志,也可以选择一定的日志区间来查看某段时间的日志
下面是日常管理的用例图
2.1.2:
流程分析
在权限管理中,主要是对项目中某个功能的工作流程作出比较详细的规划
员工管理流程分析:
员工管理中,主要是管理员的操作,通过登录时判断是否是管理员可以拥有不同权限。
其中,管理员可以根据员工的、入职时间、性别、部门来查询特定的员工,可以修改,删除和添加员工信息,可以查询部门信息,可以添加部门,删除部门和修改部门信息。
在部门管理中,还可以根据部门查看部门所有的员工信息。
而普通员工登陆之后,可以在输入密码之后修改自己的登陆密码,但是无法进行其他操作。
以下是员工管理流程图:
日常管理流程分析:
在日常管理中分为两部分,员工操作和日志管理员操作
在员工操作中,员工能够上传当天的工作日志,同时可以根据登陆时的id查看自己的所有工作日志,而且可以根据日期区间的选择查看相应日期区间的日志容
在管理员操作中,管理员登陆日志模块后,首先看到的是前一天的日志以及审核状况,在该页面中管理员可以根据自身的需要查找相应的日志,也可以对日志进行评级。
下面是日常管理的流程图
2.1.3:
关系分析
员工管理关系分析
每一个员工都包含了自身的信息,包括员工号,部门号等等的信息,同时每个部门也包括人数,部门经理,部门号,部门名称等等的一系列属性。
而管理员则是对他们信息进行维护管理的操作
下面是员工管理的E-R图
日常管理关系分析
日常管理中,员工和管理员都分别对日志进行操作,其中管理员是对日志进行审核,而员工是对日志进行添加和查看,下面是日常管理的E-R图:
3:
项目详细设计
进行了项目的整体分析和自己所负责部分的逻辑分析之后,我们需要对项目进行详细的设计了。
,对于项目的详细设计我们分为
⏹业务对象模型设计
⏹数据库设计
⏹功能逻辑设计
⏹界面设计
3.1:
业务对象模型设计
在业务对象逻辑设计中我们会首先提取出业务对象,并对对业务对象的属性,基本操作以及相互之间的关联关系和组合关系等进行设计。
同时我们也会根据需要,对业务对象进行优化。
3.1.1:
业务对象提取
在OA办公自动化系统中,我负责的模块是员工管理和日常管理。
在这两个模块中涉及到的对象包括普通员工、管理员、部门、日志文件等等对象,以下是我提取的业务对象。
每一个业务对象都有自己特有的属性,根据系统的系能分析和对每个业务对象进行分析,以下是每个业务对象的性质表以及每个业务对象所包含的操作
业务对象名称
具有属性
可完成操作
员工
员工编号、员工、登录密码、性别、出生日期、联系方式、所属部门、直接上级、
入职时间、离职时间、职务
员工可以登录系统后完成对自己密码的更改,可以查询自己之前提交的日志,可以在工作结束后提交当天的工作日志
管理员
员工编号、员工、登录密码、性别、出生日期、联系方式、所属部门、直接上级、
入职时间、离职时间、职务
管理员在登录系统后,可以对员工的信息进行增加删除修改等等操作,可以根据自身需求通过不同条件查询员工信息同时管理员可以管理部门信息,可以根据部门查看员工信息。
日志管理方面,管理员可以管理日志,可以对日志进行评价
部门
部门编号、部门名称、部门职能、负责人、当前人数
部门信息可以被管理员修改和查询,与员工之间有关系
日志
日志编号、提交人、提交日期、日志容、工作难点、担任职务、日志状态、日志级别
日志是被员工提交,被管理员评价,,可以查看详细信息
3.1.2:
关系设计
同一个系统中,实体与实体之间难免存在着联系,不同的实体之间的对应关系是不同的,下面是我负责模块的实体之间的关系叙述
●部门与员工之间存在着一对多的关系,一个部门可以有多个员工。
●员工与日志之间存在一对多的关系,员工在正常出勤的情况下每天都需要提交工作日志
●员工表还包括员工职位,这与职位表也存在着多对一的关系,例如职位为经理的员工就不止一个
●员工对应的功能有多对多的关系,一个功能可以有多个员工拥有,一个员工也可以拥有多个功能
根据以上分析,下面是实体之间的关系图
3.2:
功能逻辑顺序设计
在系统的设计过程中,设计者需要考虑人(管理员)与系统之间的交互情况,同时要清楚的知道各个对象之间信息交互的时序关系以及逻辑联系。
在我负责的模块中,用户登录之后会判断是否是管理员,若是管理员,主页面显示管理员所有的权限操作,若不是,则显示员工所有的权限操作。
在首页进行相应的功能选择之后,就会进入相应的功能界面,在功能界面中进行相应对象的增删改查操作,或者相应的业务操作,比如员工管理可以添加员工,而日志管理中管理员可以对日志进行审核操作等等。
操作完成后等待下次操作。
下面是员工管理部分的逻辑顺序图
下面是部门管理的逻辑顺序图:
日志管理逻辑顺序
管理员登陆之后,点击日志审核,首先看到的是前一天所有员工提交的日志,在日志查询界面上,管理员可以根据需要输入多条件,在查询结果后面的操作列上有日志审核按钮。
管理员可以点击进入到日志审核界面。
在日志审核界面上管理员可以阅读日志详细信息,并且对日志进行评级。
同时将日志的状态置为“已审核”。
下面是日志管理部分的逻辑顺序图:
3.3:
数据库设计
根据项目需要,我们需要对项目的实体类进行相应的数据库设计。
而数据库设计又分为概念设计(包括了主外键约束,类的持久化)、逻辑设计、以及物理设计等方面。
首先先进行的是数据库的概念设计,
3.3.1:
数据库概念设计
首先进行数据库的概念设计,下面是我们的数据库设计表
表名称
表属性
表主键
外键
员工表
员工ID,员工,员工所属部门,员工职位,员工,入职时间,离职时间
员工ID
部门编号
职位编号
部门表
部门ID,部门名称,部门领导,部门职能,部门人数
部门ID
无
日志表
日志编号,日志提交日期,日志提交员工,工作难点,日志正文,日志状态,日志级别
日志编号
员工ID
功能表
功能编号,功能名称,对应职位
功能编号
对应职位编号
职位表
职位编号,职位名称
职位编号
无
3.3.2:
表结构设计
接下来是对各表的优化和设计,以及表字段类型的设计和所占大小的设计。
下面是我负责模块涉及到的几表结构,包括了表之间的主外键关系和表字段的类型等等。
1:
员工表
字段名
中文名
数据类型
是否主键
是否外键
可否空值
Pk_emp_id
员工编号
Int
是
否
否
emp_name
员工
Varchar(50)
否
否
否
emp_pass
登录密码
Varchar(225)
否
否
否
emp_sex
性别
Varchar(20)
否
否
是
emp_birth
出生日期
Date
否
否
是
emp_phone
联系方式
Varchar(225)
否
否
是
Fk_bm_id
所属部门
int
否
是
否
emp_boss
直接上级
Varchar(50)
否
否
是
emp_rztime
入职时间
Date
否
否
是
emp_lztime
离职时间
Date
否
否
是
emp_zw
职务
Varchar(50)
否
否
是
2:
部门表
字段名
中文名
数据类型
是否主键
是否外键
可否空值
Pk_bm_id
部门编号
Int
是
否
否
bm_name
部门名称
varchar(50)
否
否
否
bm_zn
部门职能
varchar(225)
否
否
否
bm_fzr
负责人
varchar(50)
否
否
否
Bm_rs
当前人数
int
否
否
否
3:
日志表
字段名
中文名
数据类型
是否主键
是否外键
可否空值
Pk_Rz_id
日志编号
int
是
否
否
Fk_emp_id
提交人
int
否
是
否
Rz_date
提交日期
date
否
否
是
Rz_main
日志容
text
否
否
是
Rz_diff
工作难点
Varchar(225)
否
否
是
Rz_zw
担任职务
Varchar(50)
否
否
否
Rz_zt
日志状态
Varchar(50)
否
否
是
Rz_jb
日志级别
Varchar(20)
否
否
是
4:
功能表
字段名
中文名
数据类型
是否主键
是否外键
可否空值
Pk_gn_id
功能编号
Int
是
否
否
Gn_name
功能名
Varchar(50)
否
否
否
Fk_user_zw
职位
varchar(50)
否
是
否
5:
职位表
字段名
中文名
数据类型
是否主键
是否外键
可否空值
Pk_dz_id
职位编号
Int
是
否
否
Fk_user_zw
职位名称
varchar(50)
否
是
否
为了方便数据库存储,不容易导致错误,所有表名和属性名均由英文书写。
最终数据库各表之间关系和表属性的总结如下图:
3.4:
界面设计
登陆界面设计
首页截图
在登陆后会进入到系统首页,根据登陆者不同的权限,会看到不同的首页菜单,下面是管理员的首页菜单
下面是普通员工的首页菜单
普通用户登录之后看到的菜单比管理员的功能要少很多,因为普通用户没有响应的权限
员工界面:
在员工界面,可以查询所有员工,可以根据员工id,所在部门,性别,入职时间等条件进行多条件查询。
可以添加员工,对员工信息进行修改等操作
员工修改界面:
密码修改界面
部门界面
部门界面包括了部门的增加和查询以及删除功能
日志界面
日志包括员工查看日志和管理员查看日志两部分,管理员还可以根据不同的条件对日志进行查询
管理员日志界面
日志添加界面
4:
代码设计
4.1:
配置文件代码设计
配置文件中的Spring部分我是使用注解的形式进行编写的,并对Spring配置文件进行了拆分。
而对应的hibernate是利用Spring的注入,Struts2则是利用Xml文件的动态匹配方法实现的,以下是代码
Action的Spring配置文件
xmlversion="1.0"encoding="UTF-8"?
>
xmlns:
xsi=".w3.org/2001/XMLSchema-instance"xmlns:
p=".springframework.org/schema/p"
xmlns:
context=".springframework.org/schema/context"
xsi:
schemaLocation=".springframework.org/schema/beans.springframework.org/schema/beans/spring-beans-2.5.xsd
.springframework.org/schema/context.springframework.org/schema/context/spring-context-2.5.xsd">
annotation-config/>
component-scanbase-package="Nice..employee.action">
component-scan>
component-scanbase-package="Nice..department.action">
component-scan>
component-scanbase-package="Nice..Rz.action">
component-scan>
Service部分的配置文件
xmlversion="1.0"encoding="UTF-8"?
>
xmlns:
xsi=".w3.org/2001/XMLSchema-instance"xmlns:
p=".springframework.org/schema/p"
xmlns:
context=".springframework.org/schema/context"
xsi:
schemaLocation=".springf