员工工资管理信息系统课程设计.doc

课 程 设 计 报 告学生姓名:学 号：学 院:班 级:题 目:员工工资管理信息系统课程设计教授王欣指导教师： 职称: 2011年 7 月 15 日目录目 录1. 选课背景12. 人事工资管理系统需求分析22.1 人事工资管理系统的需求陈述22.2 需求分析22.2.1 功能需求22.2.2 性能需求32.3 系统需求建模32.3.1 确定参与者42.3.2 确定用例42.3.3 系统用例建模62.3.4 用例描述63. 员工工资管理系统系统分析83.1 系统用例建模83.2 静态结构模型113.2.1 类的识别113.2.3 类的属性描述113.2.4 类图的构建123.3 系统动态模型123.3.1 系统执行顺序分析123.3.2 系统的协作分析143.3.3 系统状态分析143.3.4 系统活动分析154.系统设计与实现174.1 uml体系结构设计174.1.1 硬件体系结构设计174.1.2 软件体系结构设计184.2 对象模型设计194.3 系统实现204.3.1 组件分析204.3.2 配置分析215.课程设计心得体会22参考文献231.选课背景1. 选课背景随着社会的进步和计算机技术的发展，特别是微型计算机的大范围普及，现在应用在大中型企业的信息管理系统中，几乎都包括了工资管理模块。有些环境中是有大型erp软件中的一个模块引进的，有些作为企业的财务系统的一部分。计算机处理的数据量不断增加。文件管理系统采用的一次最多存取一个记录的访问方式，以及在不同文件之间缺乏相互联系的结构，越来越不能适应管理大量数据的需要，于是数据库管理系统便应运而生。有了数据库我们便能方便快捷的对数据进行读取、存取，并维护数据库的数据。但，西方管理制度设计的工资管理软件，在很多时候还不能完成解决中国特色中小企业的问题，本文介绍的毕业设计的研究工作就是要为这些具有中国特色的中小企业解决他们在工资管理方面的问题。今天，数据库管理已成为计算机信息管理的主要方式。数据库的应用非常广泛，可应用于各行各业，只要是稍复杂的数据，都可制作成数据库，交由电脑来管理。用电脑管理数据，运算速度快，检索迅速、查找方便、可靠性高、存储量大、保密性好、寿命长、成本低且不易出错等，这些优点能够极大地提高工资管理的效率,也是科学化、正规化管理的重要条件，尤其是现在的中小型企业正需要这种对口的工资管理系统，并且是现行的财务管理系统所代替不了的。12.员工工资管理系统需求分析2. 员工工资管理系统需求分析2.1 员工工资管理系统的需求陈述工资管理系统的主要任务是通过工资费用的计算和分配，为成本核算与账务处理提供依据，并且根据工资制度和职工劳动数量与质量，计算并发放应该支付给职工的工资。工资核算时工资管理的主要内容。工资核算包括工资结算与工资分配两个方面。工资结算是指应付工资、代扣款项和实发工资的计算；工资分配是指按部门、类别进行工资汇总，并按工资的用途对工资进行分配。工资总额是指各单位在一定时期内支付给本单位全体职工的全部劳动报酬总额。按照国家统计局的规定，工资总额有计时工资、计件工资、奖金、津贴和补贴、加班加点工资和特殊情况下支付的工资6部分组成，其中计时工资和计件工资是工资总额中最基本的部分。上述工资构成要件所组成的工资总额只是应发工资，并非每个职工拿到手的实发工资，原因在于存在一些应扣项目，例如水电费、工会会费、保险费、公积金、病事假扣款、旷工扣款和个人所得税等。在计算每个职工实发工资之前应在工资总额中扣除这部分款项，即有如下关系：应发工资 = 基本工资 + 工龄工资 + 岗位津贴 + 固定补贴 + 加班加点工资 + 奖金扣款合计 = 水电费 + 保险费 + 个人所得税 + 病假扣款 + 事假扣款 + 旷工扣款 + 其他扣款实发工资 = 应发工资 扣款合计每个月财务部门根据人事部门提供的职工基本工资数据、所得税率和人事变动情况计算所有员工的基本工资信息，然后根据各个部门提供并审核后的各种表格，如完成任务表、考勤表、考核表、职工当月的扣款情况（包括水电费、病事假扣款等）等计算职工变动工资、个人所得税和应发放工资等，编制工资单。按类进行汇总，编制工资汇总表。将实发工资转入代发银行，由银行代发工资，并进行账务处理。工资结算过程主要设计如下会计账户：现金、银行存款、应付工资、其他应付款、其他应收款等。2.2 需求分析2.2.1 功能需求工资管理系统涉及到员工基本信息的录入、修改和删除，工资标准的设定、查询和结算等。典型的工资管理系统主要有以下基本功能：a) 系统数据初始化b) 员工基本信息的录入、修改、删除等功能c) 工资标准的设定功能，集体包括职务工资、职称工资、其他工资标准和福利的设定。d) 工资信息的浏览e) 员工工资信息表的创建及查询f) 工资调整管理g) 工资计算h) 工资报表打印2.2.2 性能需求需求分析的目的在于与开发人员与用户之间达成系统开发的共识，使开发人员所考虑的系统在功能（系统能做什么）、简单操作，良好界面，个人信息保密性，系统安全与稳定，良好帐户管理，友好信息返回模式（如报表及打印功能）。此工资管理系统对工资数据精度的计算能在默认情况之下精确到小数点后3位小数，即是精确到分的计算。但在用户使用过程中，能自行根据实际情况进行小数计算精度的设定，最大能允许保留小数点后5位的精度。在时间特性上，当用户发出命令请求时的服务器的响应时间、对数据更新处理、工资数据的查询检索等上，同样要求系统响应时间不会超过0.5秒时间。系统支持多种操作系统的运行环境，多不同操作系统，不同文件格式的磁盘上的数据均能实现信息的互通，及共享。当服务器移植到其他的系统平台，如：linux平台下时，同样能和其他的系统进行数据存取同步，不会出现系统之间互不兼容的情况，系统支持多系统之间的互连互通，系统有巨大的强健性。2.3 系统需求建模在进行用例建模之前，我们首先了解到用例模型描述的是外部执行者(actor)所理解的系统功能。它主要用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。它的重要作用对于我们人事管理系统的分析和设计主要体现在以下几个方面：首先，它描述了待开发系统（人事管理系统）的功能需求；其次，它将系统看作黑盒，从外部执行者的角度来理解系统；再次，它驱动了需求分析之后各阶段的开发工作，不仅在开发过程中保证了系统所有功能的实现，而且被用于验证和检测所开发的系统，从而影响到开发工作的各个阶段和uml的各个模型。从本质上讲，一个用例是用户与计算机之间的一次典型交互作用。在uml中，用例被定义成系统执行的一系列动作，动作执行的结果能被指定执行者察觉到。几乎在任何情况下都会使用用例。用例用来获取需求，规划和控制项目。用例的获取是需求分析阶段的主要任务之一，而且是首先要做的工作。大部分用例将在项目的需求分析阶段产生，并且随着工作的深入会发现更多的用例，这些都应及时增添到已有的用例集中。2.3.1 确定参与者在分析过程开始的时候，我们考虑到获取用例首先要找出系统的执行者。，有鉴于此，我们通过用户回答一些问题的答案来识别执行者。1.谁使用系统的主要功能(主要使用者)。2.谁需要系统支持他们的日常工作。3.谁来维护、管理使系统正常工作(辅助使用者)。4.系统需要操纵哪些硬件。5.系统需要与哪些其它系统交互，包含其它计算机系统和其它应用程序。6.对系统产生的结果感兴趣的人或事物。通过回答这六个问题以后，再进一步分析可以识别出系统顶层上的8个活动类：公司主管 、人力资源部、用人部门、培训部门、财务处、公司工会、系统管理员、应聘人员2.3.2 确定用例在对现行住院管理系统的分析过程中，在我们获取了执行者之后，我们就对每个执行者提出以下问题以获取用例。1.执行者要求系统提供哪些功能(执行者需要做什么)。2.执行者需要读、产生、删除、修改或存储的信息有哪些类型。3.必须提醒执行者的系统事件有哪些，或者执行者必须提醒系统的事件有哪些，怎样把这些事件表示成用例中的功能。4.为了完整地描述用例，还需要知道执行者的某些典型功能能否被系统自动实现。除了以上考虑到的问题之外，我们还考虑了一些不针对具体执行者问题(即针对整个系统的问题)，以使自己的分析结果更加准确。1.系统需要何种输入输出，输入从何处来，输出到何处。2.当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题。因为系统比较大，因此不可能给出全部的分析过程，因此列举出在人事分系统中一部分比较有代表性的过程。 事件列表产生用例识别活动者 图2.1用例的生成过程每个事件并不总是对应一个用例。可能有些事件是相近或相同的，如果多个事件有共同点或者多个事件的最终目标相同，那么就可以将这些事件合并为一个事件。系统层的用例识别过程如下：通过前面对人力资源管理的系统描述，按照上面介绍的用力识别方法，可以从顶层系统中识别出的用例。它们是：(1)管理组织机构(2)管理招聘(3)管理职位(4)规划人力资源(5)考评员工绩效(6)管理人事档案(7)管理劳动合同(8)管理培训(9)管理员工薪资(10)管理员工福(11)管理系统权限(12)登录系统(13)修改个人资料2.3.3 系统用例建模针对人事管理系统的流程的分析，我们采用的是面向对象的分析方法(ooa)。使用用例图来描述参与者与外部用户所能观察到的系统功能的模型图，在此模型中列出了系统中的用例和参与者，并显示哪个参与者参与了哪个用例的执行。2.3.4 用例描述一个用例对应并描述一个完整的功能。路径是用例中事件的步骤。一个路径也称为一个场景。每一个用例包含多种路径，每一个路径由一系列业务步骤组成。如果用例的粒度太粗，一个路径甚至一个业务步骤也可以定义为一个用例；如果用例的粒度太细，则一个用例只有一条路径，这会导致某一功能支离破碎。因此要合理掌握用例的粒度。路径有3个层次：主要的、可选的和例外的。主路径是用例中最通常情况下发生的路径；可选路径是合法的但不是经常发生的路径；例外路径是不按设想顺序进行的路径，是应用程序中必须要捕获的错误情况。用例描述了系统做什么，但没有规定怎么做，即用例图没有显示不同的路径，只显示了活动者与用例之间的关系。因此，需要为用例配上结构化叙述的文体。为了统一格式，每个项目应该使用一个用例模板。在论文中，系统实例使用如下所示的用例模板来描述用例。 用例模板用例名称 (用例名)用例目标 (用例在系统中的目标)级别 (概要任务首要任务子功能)活动者 (此用例的活动者)状态 (未定义路径只定义了初始路径路径定义完成)前件条件 (用例执行前系统应具有的状态)成功后件 (用例成功执行后系统应具有的状态)主路径 (用例主路径的名称)可选路径 (用例的可选路径)例外路径 (用例的例外路径)这个模板描述了一个用例的主要方面。下面以管理招聘用例为例说明用例模板的用法。用例名称：工资管理；用例目标：制定年度人力资源计划及招聘计划，发布招聘公告，管理员工筛选过程及评估工作；级别：子功能；活动者：人力资源部，公司主管，用人部门；状态：只定义了初始路径；前件条件：人力资源部登录系统；成功后件：管理整个员工信息过程；主路径 考勤部门对员工进行日常出勤考察并登记出勤和缺勤情况，并且对员工的工作情况作出评价。例外路径 无。 图2.2 员工工资管理系统用例图233.员工工资管理系统系统分析3. 员工工资管理系统系统分析3.1 系统用例建模1、职工档案管理：实现对员工基本信息的管理操作，包括员工基本数据信息的添加、修改、删除和查询等功能。 2、职工信息定义： 实现对工资结构信息的添加、修改、删除和查询等功能。3、考勤管理：根据职务分析，将员工分为不 同层面、不同类别，分别设计考评标准。对业绩、能力、态度等进行月份、季度、年度考评，对考核数据提供统计分析功能，为薪酬、奖惩、培训开发等方面提供依据。4、工资款项标准：设定工资款项的标准。5、工资数据汇总：实现对工资数据的汇总、查询等功能。6、工资项目定义：实现对工资公式定义以及工资的多次发放定义。7、输入工资：输入职工工资信息。8、工资发放：发放工资，查看工资发放情况。 图3.1 职工信息管理用例图 图3.2 职工工作评价管理用例图 图3.3 员工福利管理用例图 图3.5 员工工资管理用例图 图3.4 员工考勤管理用例图3.2 静态结构模型3.2.1 类的识别识别类的方法通常使用的识别方法是名词识别方法一般来说，描述问题域实体都用名词或名词短语。应用名词识别方法时，要从系统描述中找出名词、名词短语或名词性代词，因为它们往往对应着对象(类)。其中单数名词可以识别为对象，而复数名词则可以识别为类，但是要注意，并不是每个名词都对应着一个对象(类)，可能有的名词只是其他对象的一个属性，也可能几个名词对应着一个对 象(类)。要看找出的名词是否都应该成为系统的对象(类)，考察其是否有与该对象(类)3.2.3 类的属性描述属性是对象的性质，通过对象类和结构有更深入，更具体的认识。一般来说确定属性的过程包括分析和选择两个步骤。属性的确定既与问题有关，也和目标系统的任务有关。应该仅考虑与具体应用直接相关的属性，不要考虑那些超出所要解决的问题范围的属性。在分析过程中应该首先找出最重要的属性，以后在逐渐把其余属性添加进去。此次分析过程中，我们在分析阶段没有考虑那些纯粹用于实现的属性。只是在最后认真考察了经初步分析而确定下来的那些属性，从中删掉了那些不正确的或不必要的属性。部分对象类的属性描述如下：经理：部门编号员工：员工编号、姓名、部门编号相关部门：增加部门、删除部门员工工资：员工编号、基本工资、动态工资员工管理员：增加员工、删除员工、查询员工、需该员工、调动员工用户：用户姓名部门：部门编号员工管理者：姓名、编号、所在部门用户管理者：参勤情况：员工编号、迟到天数、早退天数、请假天数、加班次数3.2.4 类图的构建图3.6 员工工资管理类图3.3 系统动态模型3.3.1 系统执行顺序分析为了实现一个合适的系统，第一步应对公司目前情况进行调研分析，掌握现有的工作模式和工作流程。经过对现行公司的调查和分析，人事部门的业务主要涉及两大块，一块是员工基本信息，另一块是工资管理，两块业务相对独立。本文研究的是人事管理系统中的工资管理系统，根据调查得出工资管理过程。在顺序图中，一条竖线代表一个对象，每个时间用一条水平的箭头线表示，箭头方向从事件的发送对象指向接受对象，时间从上向下递增，箭头线在垂直方向上的相对位置表示事件发生的先后。根据工资管理过程可以绘制出如图3.7所示的员工信息管理子模块的顺序图。 图3.7员工信息管理顺序图3.3.2 系统的协作分析合作图也称为协作图，用于描述相互合作的对象间的交互关系和链接关系。与顺序图一样，合作图也展示了对象间的动态协作关系。它除了说明信息的交换外，还显示对象间的连接关系，描述信息在连接的对象之间的传递。根据对员工信息管理系统的业务流程进行分析得出的顺序图，可以得出该系统的协作图如图3.8所示 图3.8员工基本信息管理子模块协作图3.3.3 系统状态分析状态图(state diagram)用来描述一个特定对象的所有可能状态及其引起状态转移的事件。状态图描述了事件和对象状态的关系。用户在使用该系统之前要先进行注册，输入密码注册成功后进入系统。在进入系统之后要验证用户身份，若无权访问则被强制退出系统，若有权访问则可进入系统。进入系统后课根据需要修改、增加和删除员工信息，确认才做后则修改完成 图3.9 管理员注册状态图 图3.10员工信息管理状态图3.3.4 系统活动分析活动图是由状态图转化而来的，它描述了系统中各种活动执行的顺序，刻画了一个系统中所要进行的各项活动的执行流程。根据上文中绘制得出的顺序图以及合作图，对两图中相互交互的对象进行分析可以得出系统主要的活动如下： 图3.11 用户注册活动图 图3.12员工信息管理系统活动图4.系统设计与实现4.系统设计与实现4.1 uml体系结构设计人事管理子系统采用面向对象技术对系统进行总体的设计和实现，用uml及其集成环境rational rose对系统进行分析和建模，采用powerbuilders完成组件平台建设，后端数据存储是当前流行的oracle9i数据库。本系统基于powerbuilders构建三层c/s结构，数据库服务器运行数据库管理系统软件，com+组件运行在应用服务器上，客户机运行住院管理系统客户端软件。4.1.1 硬件体系结构设计本系统采用c/s结构开发，三层c/s结构是在客户和服务器之间引入应用层的概念，即在客户端与数据库之间加入了一个“中间层”。它将应用逻辑移到应用层完成，而客户端弱化为一个图形用户接口，成为一个瘦客户机。其解决方案是:对这三层进行明确分割，并在逻辑上使其独立形成三层软件结构。在这种结构中，表示层、业务逻辑层和数据访问层在逻辑上是彼此分离的，表示层向用户提供数据，并有选择地允许用户使用逻辑数据。对于基于pc的应用程序来说，本机用户和基于web的用户接口是其两个主要的用户接口。本机用户接口使用底层操作系统服务，基于web的用户以html为基础，可通过任何平台的浏览器来阅读。本系统的三层c/s结构如图4.1所示。 用户控制对象数据库模型层层控制层层视图层功能实体数据图4.1硬件体系结构图4.1.2 软件体系结构设计信息系统的软件结构是由信息系统软件的各子系统按照确定的关系构成的结构框架，一般呈现多层次结构模式。子系统是对软件进行分解的一种中间形式，也是组织和描述软件的一种方法。软件结构设计就是把软件分解成多个子系统，并确定各子系统及其接口之间的相互关系。员工工资管理子系统的软件结构如图4.2所示用户用户界面员工管理考勤管理数据库员工信息库考勤信息部门管理部门变动工资管理工资信息福利管理福利信息用户层用户界面层应用层数据库层员工管理员 图4.2员工工资管理软件体系结构图4.2 对象模型设计在前文中，对系统所有关联对象经过非正式分析后得出员工工资管理子模块的初始类如下：员工、经理、部门、部门管理者评价、评价分、员工请假信息、历史调动信息、员工档案、员工管理者、参勤情况、福利信息、员工工资、用户、用户管理者对以上候选类进行严格的考察筛选，去掉不正确的或不必要的，仅保留确实应该记录其信息或需要其提供服务的那些对象，增加和实现有关的类与对象，得出以下类与对象：员工、经理、部门、评价、评价分、历史调动信息、员工管理者、参勤情况、福利信息、员工工资、用户、用户管理者此次分析过程中，我们在分析阶段没有考虑那些纯粹用于实现的属性。只是在最后认真考察了经初步分析而确定下来的那些属性，从中删掉了那些不正确的或不必要的属性。部分对象类的属性描述如下：员工：员工编号、姓名、部门编号；增加福利、修改福利、评价组内员工经理：部门编号；评价员工部门：部门编号、部门经理、员工人数部门管理者：增加部门员工管理者：增加员工、删除员工、修改员工、调动员工经理对员工评价：工作分工、完成情况、工作态度；部门经理评分评价分：部门经理评分、组内员工评分；计算总分组内员工评价：工作态度、合作情况；组内员工评分历史调动信息：员工编号参勤情况：员工编号、正常出勤天数、迟到早退次数、请假天数、加班次数；统计出勤情况、修改加班表福利信息：员工编号用户：用户编号、权限等级用户管理者：用户添加、用户删除、用户权限等级设置 图4.3 员工工资管理对象模型图4.3 系统实现本章使用uml建模技术，对人事管理系统进行了建模设计，使的开发出的产品在面对不同的客户时方便修改和维护，大大减少了投入的人力和时间，同时大大缩小了产品的成本。在uml中，描述实现的视图称为组件视图。它对模型中的组件建模，描述应用程序搭建的软件单元以及组件之间的依赖，从而可以估计更改的影响。它还对类及其他元素在组件中的分配建模。布局视图包括组件图、配件图以及配置图，他们分别从不同的角度反映并显示了本系统的软件和硬件的物理配置。4.3.1 组件分析组件可以看作包与类对应的物理代码模块，逻辑上与包、类对应，它实际上是一个文件，可以有源代码构件、二进制构件、可执行构件。构件对外提供的可见操作和属性称为构件的界面。在uml中，组件图描述了组件及组件之间的关系，表示了组件之间的组织和依赖关系。组件图是用来为面向对象系统的物理方面建模的图形之一。经过分析，员工工资管理子系统的组件图如图4.3所示。 图4.3 员工工资管理子系统组件图4.3