2022年人力资源管理系统UML设计方案.docx

《2022年人力资源管理系统UML设计方案.docx》由会员分享，可在线阅读，更多相关《2022年人力资源管理系统UML设计方案.docx（32页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精品学习资源基于 UML的人力资源治理系统建模1人力资源治理系统建模过程分析1.1 人力资源治理的需求本部分用自然语言对系统进行描述；假设用户单位是一家企业公司，公司有职工 近2000 人，公司原先的人力资源治理方式主要以人工治理为主，个别业务用运算机处理；为了提高工作效率和决策水平，公司预备开发一套人力资源治理系统，以取代原先的人工处理方式；本系统的开发目标是：为人力资源治理部门供应一个全面的信息治理系统，通过系统可以比较简洁地获得所需的关于组织体系、薪酬福利成本、人力资源状况等静态数据，也可以便利地获得各种变动信息来进行趋势预Nt371 ；在企业内实现信息依据权限的共享，人力资源治理的Et

2、 常业务在信息系统的帮助下变得高效快捷；为了开发本系统，第一要懂得人力资源治理功能，通常人力资源治理系统包含以下模块，各模块功能简述如下1 组织机构治理；主要治理集团下属的各级公司以及公司下属的各级部门，处理公司和部门的新建、合并、撤销业务，为公司、部门供应信息保护，统计分析功能，支持输出组织机构图；2 职位治理；主要治理职务分析后每个职位的职位描述、任职资格、后备人员、以及各职位的任职情形、超编情形、空缺情形，并按部门供应职位表和空缺职位表；3 人力资源规划；重要用于治理人力资源规划和机构编制，并供应人力资源规划表、机构编制表；4 绩效考评；依据职务分析，将员工分为不同层面、不同类别，分别设

3、计考评标准；对业绩、才能、态度等进行月份、季度、年度考评，对考核数据供应统计分析功能，为薪酬、奖惩、培训开发等方面供应依据；5 人事治理；主要负责完成对在职员工、解聘员工、离退员工的基本信息、任职情形、组织变动、奖惩情形等档案数据的保护、统计分析，晋升、降职、辞职、辞退、退休等人事变动业务的处理，并供应各类员工信息卡片、信息报表；6 劳动合同治理；全面治理员工劳动合同的签订、变更、续订、中止、接触全过程；并针对不同时期，不同的合同版本，供应版本治理，以及对于到期合同供应自动提示；7 聘请治理；对编制聘请方案、发布聘请信息、采集应聘信息、聘请甄选、通知面试、聘用这一过程进行全面治理；8 培训治理

4、；治理采集培训需求、编制培训方案、发布培训信息、保护培训档案、评估培训结果这一过程，以及对培训资源进行治理；并对培训情形供应查询统计分析功能；9 薪资治理；供应对企业员工薪资标准的设定，员工工资定级，工资调整的申请、审批，工资核算发放，自动运算社会保险等代扣代缴工程，经费方案、统计分析等；10 福利治理；供应员工的各项福利基金的提取和治理功能，包括定义基金类型，设置基金提取条件，进行基金的日常治理，并供应统计分析；因本论文偏向于理论讨论及篇幅限 制，以下内容仅以聘请治理模块为例论述建模过程；关于聘请治理事务描述如下：本公司聘请组织的治理方式是这样的：人才聘请工作由人力资源部参考用人部门看法，负

5、责拟定聘请方案并组织实施，用人部门参与聘请测评的技术设计和部分实施工作； 人力资源需求方案的制定通常在每年初人力资源部依据公司的整体方案编制年度人力资源需求方案，报总经理办公会审批；人力资源需求方案制定方法如下：1 制定人力资源需求方案的基本依据：将来组织结构的猜测、人员供求关系、现有人欢迎下载精品学习资源员的调配培训等；2 人员需求猜测要综合考虑公司战略、可能获得的财务资源、竞争对手的人才政策、治理变革可能导致的公司规模变化、员工流淌等因素造成的人力资源需求的变动；3 人员供应猜测要综合考虑内部人才和外部人才供应情形；人力资源部建立内部人才库，信息包括每位员工的绩效记录及评判、职业爱好、训练

6、背景、工作体会、培训课程、外语水平、具备的技能和证书等；进行内部人才供应猜测时要调用内部人才库，判定内部人员是否与所需工作相匹配；在内部供应无法满意需求的情形下进行外部供应猜测，外部供应猜测要依据总体经济状况、全国和地方劳动力市场状况和拟聘请职位的市场状况进行判定；4 人力资源部在人力资源需求与供应猜测的基础上，制定出年度的人力资源需求方案； 聘请方案应包括聘请人数、聘请标准 年龄、性别、学历、工作体会、工作才能、个性品质等 、聘请经费预算、聘请具体行动方案等；聘请流程分为如下工作环节：提出人员需求、拟定聘请方案、发布聘请公告、人员挑选录用、聘请工作评估；其中人员挑选录用环节又 可分为以下过程

7、：1 初步挑选；报名截止后，依据聘请岗位的要求，由人力资源部会同各用人部门进行初选；审查求职者的个人简历和求职表，并依据收集到的求职者信息建立外部人才库；2 初试；人力资源部向初选合格的求职者发面试通知，并要求其面试时供应学历、证书、身份证等相关证件的原件；初试由人力资源部人员和用人部门共同组成；人力资源部对应聘人员的智力、品德和综合素养进行初试和评判，用人部门从工作体会与才能对应聘人员进行初试和评判；3 复试；复试由复试小组进行；复试小组一般由以下三方面人员组成：一、用人部门代表；二、人力资源部部长；三、资深专业人士；一般岗位的聘请可无资深专业人士，专业技术人才和治理人才的聘请必需有资深专业

8、人士参与；高级专业技术人才和治理人才由总经理负责面试，人力瓷源部负责和谐；重要岗位的复试可以考虑实行笔试的形式，由人力资源部和用人部门共同组织进行；4 复审；通过复试的应聘人员由用人部门的主管领导进行审核，并签署看法；全部拟录用的人员应经总经理最终签字批准；5 录用；人力资源部依据应聘人员体检结果，对体检合格者办理录用手续；对社会应聘人员发试用通知书，并到相应劳动部门办理劳动手续；对被录用的应届毕业生向其所在高校发接 受函，签定就业协议书；同时，人力资源部将面试结果通知落选的应聘者；6 报到；被录用员工必需在规定时间内向公司报到；如在发出录用通知15天内不能正常报到者，可取消其录用资格；特别情

9、形经批准后可延期报到；7 试用；试用期的人员，尚不属于公司正式员工；在此期间，本人可以随时提出辞职；试用人员如不能胜任本职工作或工作中显现重大失误，公司有权随时将其辞退；8 转正；试用期满后的员工，经考核合格，人力资源部应在试用期满一星期前向使用部门书面征询看法；1.2 体系结构设计在2 1节介绍了软件体系结构在软件开发中的作用以及目前应用最广泛的信息系统的体系结构 BS结构和 C届结构；B S结构最大的优点就是可以在任何地方进行操作而不用安装任何特地的软件；只要有一台能上网的电脑就能使用，客户端零保护；系统的扩展特别简洁，只要能上网，再由系统治理员安排一个用户名和密码，就可以使用了；甚至可以

10、在线申请，通过公司内部的安全认证 如cA证书 后，不需要人的参与，系统可以自动安排给用户一个账号进入系统；欢迎下载精品学习资源人力资源治理系统作为单位信息化的一个重要组成部分，它的应用无论是现在仍是将来都有着特别重要的意义；随着信息化的进展，无纸化办公的推广，人力资源治理系统的功能仍会不断完善、扩展；采纳B S软件体系结构可以在本治理系统基础上进一步开发，满意单位进一步进展；因此，本系统采纳B S软件体系结构；1.3 建模过程要胜利地建立一个软件系统的模型，离不开建模语言、软件过程和建模工具三方面的支 持；对于人力资源治理系统实例，本论文挑选uMI作为建模语言，挑选PowerDesigner

11、作为建模工具，采纳 Rational统一过程 RUP软件开发过程；软件过程描述的是傲什么、怎么做、什么时候做以及为什么要做，描述一组按某种次序完成的活动，在已产生的软件过程中，Rational统一过程 RUP是目前最具有普遍意义的开发过程； RUP的核心思想是：用例驱动，迭代化开发；人力资源治理系统实例的建模过程吸取RUP的思想，鉴 RUP的过程成分“需求分析”及“分析与设计”中的工作流程，将建模过程划分为以下动；5个活1 设计用例模型：设计用例模型是开发过程的起点，用例模型驱动着系统的整个开发过程；2 设计实体类模型：类模型是面对对象分析的核心，类图是定义其它图的基础；用例就是通过类之问的交

12、互来实现的；3 设计接口类模型：接口类模型描述活动者与系统交互的界面；4 设计窗口结构：窗口结构描述窗口之间的关系；在设计用户接口原型之前，第一要设计窗口结构；窗口结构与 UMI_不直接有关；5 设计动态模型：动态模型描述每一个用例路径所涉及的如干对象的交互行为；动态模型特别重要，其作用或价值与面对过程方法中的软件结构图相当；迭代式的开发是一个循环往复的开发过程；但是，为节约篇幅，在开发过程中不作过多的迭代假设；1.4 4设计用例模型用例模型是开发过程的起点，并驱动建模全过程；用例模型包括系统的用例图及用例描述；2系统用例模型通过设计系统顶层的用例模型，可使建模人员从总体上对系统功能有一个明白

13、；在设计系统用例模型之前，先要识别活动者和用例，然后才能建立用例模型；1、活动者识别活动者是系统分析员与用户沟通的起点，也是工程获得后续产品的关键；通常情形下，活动者是指使用系统功能的人，但也可以是其他外部的系统包括软件系统和硬件设备；总之，凡是与系统进行信息交换 包括数据信息和掌握信息的交换的外部事物，都可以是系统的活动者；识别活动者需要系统分析员与系统用户进行广泛深化的沟通以明确系统的范畴、系统的作用以及与系统交互的外部事物等，这个过程不行能一次完成，可能会需要往复多次；可以通过向用户询问以下问题来识别系统活动者谁，什么对系统运行产生的结果 值感性趣 .谁什么将会转变系统的数据.谁什么要从

14、系统中得到信息.谁什么要与系统交互 .这些问题的答案往往包含了全部与系统有关联的用户，进一步分析这些用户即可识别系统的活动者；通过前面 3 1节对人力资源治理的系统描述可知，在系统的顶层上可以识别出8欢迎下载精品学习资源类活动者：1 公司主管4培训部门7 系统治理员2 人力资源部 5 财务处8应聘人员3 用人部门公司工会2、用例识别能否胜利地开发一个工程，在很大程度上取决于能否采纳一种对于工程组人员和用户来说都特别直观的方式定义系统的需求；用例就是目前定义系统需求的正确方式用例识别是应用 UML进行面对对象分析的关键的一步，是后续工作的前提；用例是面对目标的，它代表的是系统将做什么，而不是系统

15、将怎么做；它相当于一个容器，一个满意系统各种交互的容器；识别出用例并不总是很直观的；可以从大事表中来识别用例，一旦大事被定义，用例的定义就变得简洁了；活动者是大事的主体，事件从系统活动者中查找；大事可以依据下面的格式来定义：主语+动词 +宾语其中：主语一表示已被识别出来的活动者，例如人力资源部； 动词表示动作，例如规划、治理、考评；宾语一表示动词涉及的目标，例如劳动合同或人事档案；由此，生成用例的过程如图1所示；识别活动大事列表产生用例者图1用例的生成过程大事表中的每个大事并不总是对应一个用例；可能有些大事是相近或相同的，假如多个大事有共同点或者多个大事的最终目标相同，那么就可以将这些大事合并

16、为一个大事；系统层的用例识别过程如下：通过前面对人力资源治理的系统描述，依据上面介绍的用力识别方法，可以从系统顶层得到系统层大事表 I 枷，表3-1 中的描述短语是从系统层识别出的用例；它们是：1 治理组织机构2 治理聘请3 治理职位欢迎下载精品学习资源4 规划人力资源5 考评员工绩效6 治理人事档案7 治理劳动合同8 治理培训9 治理员工薪资10 治理员工福11 治理系统权限12 登录系统13 修改个人资料识别出用例以后，就可以画出系统的用例图，如图3 2所示是当前分析得到的系统层的用例图；欢迎下载精品学习资源人力资源系统考评员工绩效治理员工福利公司工会治理组织机构治理职位公司主管用人部门治

17、理系统权限治理聘请系统治理员规划人力资源登陆系统治理人事档案修改个人资料应聘人员人力资源部治理劳动合同治理员工薪资财务处培训部门治理培训图2系统层的用例图欢迎下载精品学习资源44、用例描述一个用例对应并描述一个完整的功能；路径是用例中大事的步骤；一个路径也称为一个场景；每一个用例包含多种路径，每一个路径由一系列业务步骤组成；假如用例的粒度太粗，一个路径甚至一个业务步骤也可以定义为一个用例；假如用例的粒度太细，就一个用例只有一条路径，这会导致某一功能支离破裂；因此要合理把握用例的粒度；路径有 3个层次：主要的、可选的和例外的；主路径是用例中最通常情形下发生的路径； 可选路径是合法的但不是常常发生

18、的路径；例外路径是不按设想次序进行的路径，是应用程序 中必需要捕捉的错误情形；用例描述了系统做什么，但没有规定怎么做，即用例图没有显示不 同的路径，只显示了活动者与用例之间的关系；因此，需要为用例配上结构化表达的文体；为 了统一格式，每个工程应当使用一个用例模板；在论文中，系统实例使用如下所示的用例模板来描述用例；用例模板用例名称用例名 用例目标 用例在系统中的目标级别概要任务首要任务子功能活动者此用例的活动者 状态 未定义路径只定义了初始路径路径定义完成前件条件用例执行前系统应具有的状态胜利后件 用例胜利执行后系统应具有的状态主路径用例主路径的名称 可选路径 用例的可选路径 例外路径用例的例

19、外路径 这个模板描述了一个用例的主要方面；下面以治理聘请用例为例说明用例模板的用法；用例名称治理聘请；用例目标制定年度人力资源方案及聘请方案，发布聘请公告，治理员工挑选过程及评估工作；级别子功能；活动者人力资源部，公司主管，用人部门； 状态只定义了初始路径；前件条件人力资源部登录系统； 胜利后件治理整个聘请过程；主路径用人部门提出人员需求，人力资源部拟定聘请方案，公司主管审批聘请方案，人力资源部发布聘请公告，人力资源部挑选录用应聘者，人力资源部评估聘请工作； 可选路径特别人员员聘请；例外路径无；其它用例描述从略；3 员工聘请治理模块用例模型对系统顶层识别出的员工聘请治理用例进一步细化，从而建立

20、比较具体的员工招欢迎下载精品学习资源聘治理用例模型；1、活动者识别通过 3 1节对员工聘请治理功能模块的文字描述，与系统发生交互的实体有总经理、人力资源部、人力资源部部长、用人部门、用人部门主管领导、应聘人员、复试 小组、用人部门代表、资深专业人士和劳动部门；总经理直接与系统交互参与聘请管 理，可以识别为活动者：总经理：人力资源部和人力资源部部长与系统直接进行交互， 二者的目标相同，可识别为一个活动者：人力资源部；用人部门、用人部门代表和用 人部门主管领导与系统直接进行交互，三者的目标相同，可识别为一个活动者：用人 部门；应聘人员参与系统交互，可以识别为一个活动者：应聘人员；劳动部门参与系 统

21、交互，可以识别为一个活动者：劳动部门；资深专业人士不参与系统交互，不能识别为活动者，复试小组虽然与系统直接交互，但它由用人部门代表、人力资源部部长、资深专业人士组成，不能识别为活动者；综上所述，员工聘请治理功能模块共识别出5类活动者；1 总经理4应聘人2 人力资源部5 劳动部门3 用人部门2、用例识别依据前面介绍的用例识别方法，下面来定义大事；通过已识别的活动者并结合对员工聘请治理功能模块的文字描述，将表3-1 系统层大事中的治理聘请大事细化，可以得到表3 2所示的治理聘请大事表；表3-2 中的描述短语是从系统层的员工聘请治理用例中识别出的子用例；他们是：1 提出人员需求6发布聘请公告2 制定

22、人力资源需求方案7登记个人简历和求职表3 审批人力资源需求方案8 参与员工挑选录用4 拟定聘请方案9评估聘请工作5 审批聘请方案3、员工聘请治理用例模型用例识别出来以后，就可以画出员工聘请治理用例模型，如图3-3 所示；4、用例描述用例名称提出人员需求；用例目标依据本部门的具体情形，制定本部门的年度人员需求方案并提交到数据库： 级别子功能；活动者用人部门；状态只定义初始路径；前件条件用人部门登录系统；胜利后件用人部门登录系统后可以编辑、修改、查看、删除本部门的人员需求方案； 主路径用人部门登录系统后编辑、修改、查看、删除本部门的人员需求计划并提交到数据库中；可选路径1、修改并提交； 2、查看：

23、 3、删除； 例外路径无；其它用例这里不再描述；欢迎下载精品学习资源员工聘请治理用例模型提出人员需求登记个人简历和求职表应聘人员参与员工挑选录用劳动部门用人部门审批人力资源需求方案拟定聘请方案总经理发布聘请广告审批聘请方案人力资源部评估聘请工作制定人力资源需求方案图3 员工聘请治理用例模型3 4 3 参与员工挑选录用用例细化由于上述员工聘请治理用例模型中的参与员工挑选录用用例与多个活动者有关，因此该用例图仍需进一步的细化；欢迎下载精品学习资源1、活动者识别通过 3 1节对员工聘请治理功能模块的文字描述，与参与员工挑选录用发生交互的实体有总经理，人力资源部，人力资源部部长，人力资源部人员，用人部

24、门，用人部门代表，用人部门主管，用人部门的主管领导，员工所在部门部长，求职者，“拟予聘任”的人员，“拟予复试” 的人员，通过复试的应聘人员，应聘人员，拟录用的人员，体检合格者，社会应聘人员，被录用的应届毕业生，被录用员工，员工，落选的应聘者，试用期的人员，劳动部门，资深专业人士，复试小组，小组成员和公司；总经理直接与系统交互参与聘请治理，可以识别为活动者： 总经理；人力资源部，人力资源部部长和人力资源部人员与系统直接进行交互，三者的目标相同，可识别为一个活动者：人力资源部；用人部门，用人部门代表，用人部门主管，用人部门的主管 领导和员工所在部门部长与系统直接进行交互，他们的目标相同，可识别为一

25、个活动者：用人部门；求职者，“拟予聘任”的人员，“拟予复试”的人员，通过复试的应聘人员，应聘人员，拟录用的人员，体检合格者，社会应聘人员，被录用的应届毕业生，被录用员工，员工，落选的应聘者，试用期的人员与系统直接进行交互，其目标相同，可识别为一个活动者：应聘人 员；劳动部门直接与系统交互参与聘请治理，可以识别为活动者：劳动部门；资深专业人士和公司没有直接与系统交互参与聘请治理，不行识别为活动者；复试小组和小组成员虽然与系统直接交互，但它由用人部门代表、人力资源部部长、资深专业人士组成，不能识别为活动者；综上所述，员工聘请治理功能模块共识别出5类活动者；1 总经理3用人部门5劳动部门2 人力资源

26、部4 应聘人员2、用例识别依据前面介绍的用例识别方法，下面来定义大事；通过已识别的活动者并结合对员工聘请治理的文字描述，将表3-2 中的参与员工挑选录用大事细化，可以得到表3 3所示的参与员工挑选录用大事表；可得到以下用例：1 初步挑选简历和求职表2 建立外部人才库3 发送面试通知4 填写初试测评表5 填写复试记录表6 填写复试结果举荐书7 审核并签署复审看法8 签字批准拟录用人员9 检查体检结果10 办理劳动手续11 发送试用通知书12 填写员工登记表13 签定试用劳动合同14 征询试用看法15 出具试用看法16 填写转正定级审批表17 填写试用期工作小结18 填写考核看法欢迎下载精品学习资

27、源19 批准考核看法20 签订正式劳动合同4、参与员工挑选录用用例模型用例识别出来以后，就可以画出参与员工挑选录用用例模型，如图4所示；员工挑选录用用例模型提出人员需求参与员工挑选录用登记个人简历和求职表参与员工挑选录用发布聘请广告应聘人员发布聘请广告参与员工挑选录用劳动部门发布聘请广告用人部门拟定聘请方案审批人力资源需求方案发布聘请广告总经理发布聘请广告审批聘请方案发布聘请广告发布聘请广告评估聘请工作发布聘请广告总经理发布聘请广告发布聘请广告制定人力资源需求方案图4 员工挑选录用用例模型4、用例描述欢迎下载精品学习资源用例名称初步挑选个人简历和求职表：用例目标对个人简历和求职表进行初步挑选，

28、依据个人资料将不合格者删除，将就合格者加入人才库，合格者预备面试；级别子功能；活动者人力资源部，用人部门；状态路径定义完成；前件条件人力资源部登录系统；胜利后件对应聘者个人简历和求职表进行初步挑选并分类；主路径对个人简历和求职表进行初步挑选，依据个人资料将不合格者删除，将就合格者加入人才库，合格者预备面试；可选路径无：例外路径无；其它用例这里不再描述；5 基于UML的人力资源治理系统建模5.1 设计实体类模型类是面对对象方法的一个全新的概念，类模型是面对对象分析的核心脚l ；实体类是系统需要长久储存的对象，最终要映射到数据库；实体类模型用类图描述；在实体类模型的设计过程中，第一识别出实体类，接

29、着识别出类及类之间的关系，然后画出类图，最终识别类的属性与操作；5.2 识别方法识别类的方法通常使用的识别方法是名词识别方法一般来说，描述问题域实体都用名词或 名词短语；应用名词识别方法时，要从系统描述中找出名词、名词短语或名词性代词，由于它 们往往对应着对象 类；其中单数名词可以识别为对象，而复数名词就可以识别为类，但是要留意，并不是每个名词都对应着一个对象 类 ，可能有的名词只是其他对象的一个属性，也可能几个名词对应着一个对象 类；要看找出的名词是否都应当成为系统的对象 类，考察其是否有与该对象 类6识别过程第一从 3 1节系统文字描述中找出用来描述问题域实体的名词；依据聘请治理事务描述可

30、以得到以下名词：总经理，人力资源部，用人部门，劳动部门，求职者，“拟予聘任”的人员， “拟予复试”的人员，通过复试的应聘人员，应聘人员，拟录用的人员，体检合格者，社会应聘人员，被录用的应届毕业生，被录用员工，员工，落选的应聘者，试用期的人员，部门，部门人员需求，年度人力资源需求方案，聘请方案，聘请公告，个人简历，求职表，面试通知， 初试测评表，复试记录表，复试结果举荐书，复审看法，拟录用人员，体检结果，劳动手续， 试用通知，员工登记表，试用劳动合同，试用看法，转正定级审批表，试用期工作小结，考核看法，正式劳动合同下面对上述名词进行分析，从而得到实体类；总经理，人力资源部，用人部门，劳动部门属于

31、系统的用户，可以识别为一个类：用户；求职者，“拟予聘任”的人员， “拟予复试”的人员，通过复试的应聘人员，应聘人员，拟录用的人员，体检合格者，社会应聘人员，被录用的应届毕业生，被录用员工，员工，落选的应聘者，试用期的人员，拟录用人员，个人简历可以识别为一个类：应聘者；部门可以识别为一个类：部门；部门人员需求可以识别为一个类：部门人员需求；年度人力资源需求方案可以识别为一个类年度人力资源需求方案；聘请方案可以识别为个类：聘请方案：聘请公告可以识别为一个类：聘请公告；求职表可以识别为一个类：求职表；面试通知可以识别为一个类：面试通知；初试测评表可以识别为欢迎下载精品学习资源一个类：初试测评表；复试

32、记录表可以识别为一个类：复试记录表；复试结果举荐书可以识别为一个类：复试结果举荐书；复审看法可以识别为一个类：复审看法：体检结果可以识别为一个类：体检结果：试用通知可以识别为一个类：试用通知；员工登记表可以识别为一个类：员工登记表：试用劳动合同可以识别为一个类：试用劳动合同；试用看法可以识别为一个类：试用看法；转正定级审批表可以识别为一个类：转正定级审批表；试用期工作小结可以识别为一个类：试用期工作小结；考核看法可以识别为一个类：考核看法：正式劳动合同可以识别为一个类：正式劳动合同；61类的关联要建立类模型，不仅要识别出类，仍要识别出类与类之间的关系；通常显式的关系可以从用例中找到，而隐式的关

33、系在用例中没有明确的说明，这需要仔细的分析；6.2 聘请治理功能模块子系统类图依据上面分析的表 4_1 和表舢 2可以得到聘请治理功能模块子系统实体类类图，6.3 设计接口类模型接口类模型描述系统活动与系统交互的界面，在UML建模过程中通常用类图和包图来描述；设计接口类模型，第一要识别出接口类，然后再识别出接口类之间的关 系；它是应用程序的“可视区”，也是系统与外界的隔离层；识别接口类可以从用例去识别，用例驱动接口类设计；用户接口直接与用例相连，用户是通过用户接口发起和终止用例的；由于用户接121 直接面对用户，设计过程中要反复与用户商议，充分懂得用户的要求；在将用例映射到用户界面时，要依据用

34、户的需要对用例进行适当的组合；接口类之间的关系主要用二种：组成关系和依靠关系；一个特定的窗口是由很多构件组成的，窗口与构件之间就是组成关系；由一个窗口迸入另一个窗口，这两个窗口就是依靠关系；为了保持本论文的系统性，第一从人力资源治理系统的高层识别出本系统实例的主窗口接口类图；然后就聘请治理模块进行接口类图具体分析设计；本系统需要处理的事务有：组织机构治理、聘请治理、职位治理、人力资源规划、绩效考评、人事治理、劳动合同治理、培训治理、薪资治理、福利治理等；在上面的系统顶层用例图中，以从系统顶层识别出13个用例：治理组织机构、治理聘请、治理职位、规划人力资源、考评员工绩效、治理人事档案、治理劳动合

35、同、治理培训、治理员工薪资、治理员工福利、治理系统权限、登录系统、修改个人资料；用户进入系统之前要进行登录，因此，用户与系统的第一个接口是用户登录窗口，命名为 UserLogin 类；用户登录以后进入系统主窗口，命名系统主窗口为MainWindow 类；在主窗口上设计一个系统主菜单，主菜单包含上述12个菜单项：治理组织机构、 治理聘请、治理职位、规划人力资源、考评员工绩效、治理人事档案、治理劳动合同、治理培训、治理员工薪资、治理员工福利、治理系统权限、修改个人资料；主菜单根据登录用户权限的不同，显示不同的菜单项；命名主菜单为MainMenu类；通过挑选12个菜单项，可以分别显现12 个下拉菜单

36、，命名 12 个菜单为： M_Invite类、 Mjob类、 M_Power类、 review 类、 M_File 类、 M_Pact 类、 M_Train 类、 M_Wag类e 、 M_Boon欢迎下载精品学习资源类、 M Adm类、 M ind 类；以上是从系统用例的顶层识别出来的系统主窗口的接口类；上述各类之间的关系为：UserLogin 类依靠 MainWindow类， MainWindow类包含 MainMenu类， MainMenu类依靠 M Org类、 M Invite类、 M_Job类、 M_Power类、 Review 类、 M_File 类、 M_Pact 类、 M_Tra

37、in 类、 M_Wage类、 M_Boon类、 M_Adm类、 M_Ind类；图5系统主窗口接口类图下面介绍聘请治理功能模块的接口类，依据图3 3员工聘请治理用例模型可知，聘请治理功能模块已经识别出9个用例：提出人员需求、制定人力资源需求方案、审批人力资源需求方案、拟 定聘请方案、审批聘请方案、发布聘请公告、登记个人简历和求职表、参与员工挑选录用、评估聘请工作；在聘请治理菜单中定义7个菜单项与上述 9个用例对应，并为 M Invite类 聘请治理菜单 定义如下 9个操作； 1、AdvanceReq 当挑选欢迎下载精品学习资源“提出人员需求”菜单项时，该操作被调用；2、SetMPlan当挑选“制

38、定需求方案”菜单项时，该 操作被调用； 3、ApproveMPlan 当挑选“审批需求方案”菜单项时，该操作被调用；4、SetIPlan当挑选“拟定聘请方案”菜单项时，该操作被调用；5、ApproveIPlan当挑选“审批聘请方案”菜单项时，该操作调用； 6、IssueI当挑选“发布聘请公告”菜单项时，该操作被调用；7 、FillInBio 当挑选“登记个人简历”菜单项时，该操作被调用；8 、Filter当挑选“员工挑选录用”菜单项时，该操作被调用；9、evaluation当挑选“评估聘请工作”菜单项时，该操作被调用；当各 用人部门用户挑选“提出人员需求”菜单项后，应用系统供应一个窗口，通过该

39、窗口，各用人部门用户可以编辑本部门人员需求，查看本部门人员需求，修改本部门人员需求，删除本部门人员需求；将完成该任务的类称作AdvanceReq类；当人力资源部门用户挑选“制定需求方案” 菜单项后，应用系统供应一个窗口，通过该窗口，人力资源部可以查看各部门人员需求、可以编辑人力资源需求方案，查看人力资源需求方案，修改人力资源需求方案，删除人力资源需求方案；将完成该任务的类称作SetMPlan 类；当总经理用户挑选“审批需求方案”菜单项后，应用系统供应一个窗口，通过该窗口，总经理可以编辑人力资源需求方案，查看人力资源需求计划，修改人力资源需求方案，删除人力资源需求方案，审批人力资源需求方案；将完

40、成该任务的类称作 ApproveMPlan 类；当人力资源部用户挑选“拟定聘请方案”菜单项后，应用系统供应一个窗口，通过该窗口，人 力资源部可以编辑聘请方案，查看聘请方案，修改聘请方案，删除聘请方案；将完成该任务的 类称作 SetIPlan类；当总经理用户挑选“审批聘请方案”菜单项后，应用系统供应一个窗口， 通过该窗口，总经理可以编辑聘请方案，查看聘请方案，修改聘请方案，删除聘请方案，审批聘请方案将完成该任务的类称作ApprovelPlan类；当人力资源部用户挑选“发布聘请公告”菜单项后，应用系统供应一个窗口，通过该窗口，人力资源部可以编辑聘请公告，查看聘请公告，修改聘请告，删除聘请公告；将完

41、成该任务的类称作IssueI类； 当应聘者用户挑选“登记个人简历”菜单项后，应用系统供应一个窗口，通过该窗口，应聘者可以填写个人简历，查看个人简历，修改个人简历，删除个人简历，填写求职表，查看求职表，修改求职表，删除求职表；将完成该任务的类称作FilllnBio类；当公司挑选录用工作小组用户挑选“员工挑选录用”菜单项后，应用系统供应 一个窗口，通过该窗口，公司挑选录用工作小组可以挑选个人简历，挑选求职表，存入人才库，发送面试通知，填写初试测评表，填写复试记录表，填写复试结果举荐书，审核并签署复审看法，签字批准拟录用人员，填写体检结果，办理劳动手续，发送试用通知书，填写员工登记表，签定试用劳动合

42、同，征询试用看法，出具试用看法，填写转正定级审批表，填写试用期工作小结，填写考核看法，批准考核看法，签订正式劳动合同；将完成该任务的类称作Filter类；当人力资源部用户挑选“评估聘请工作”菜单项后，应用系统供应一个窗口，通过该窗 口，人力资源部可以填写评估结果，查看评估结果，修改评估结果，删除评估结果；将完成该任务的类称作 evaluation类；归纳以上分析结果，聘请治理功能模块的接口类如表t4 所示；聘请治理功能模块的接口类这间的关系为：M Invite类依靠于 AdvanceReq类、 SetMPlan 类、ApproveMPlan 类、 SetlPlan类、 ApproveIPlan

43、类、 HlllnBio类、 Hlter类、 evaluation类；SetMPlan 类依靠于 AdvanceReq 类； ApproveMPlan 类依靠于 SetMPlan 类； SetlPlan类依靠于ApproveMPlan 类； ApprovelPlan类依靠于 SetlPlan类； Issuel类依靠于 ApprovelPlan类； HlllnBio类依靠于 lssueI类； Hlter 类依靠于 HlllnBio类；聘请治理功能模块的接口类如图6所示；欢迎下载精品学习资源图6聘请治理功能模块的接口类6.3 设计窗口结构图6聘请治理功能模块的接口类窗口结构是窗口之问的切换流程，通过

44、窗口结构可以直观地看到通过用例的路径流程；一个软件在有用性上满意用户的需求是不够的，由于假如窗口结构不合理，也不会受到用户的欢迎；这里只介绍总体窗口结构；在进入系统窗口之前，第一要经过用户权限验证窗口，通过验证后弹出系统主窗口，在系统主窗口中共包含9个菜单项，依据用户权限的不同，使主菜单显示不同的菜单项；6.4 设计动态模型类图仅仅从静态角度描述了系统，而面对对象系统是通过对象之间相互发送消息来实现系统功能的，所以需要为系统建立动态模型才能全面反应系统的情形；另外，在具体描述用例 时，是从用户角度动身，没有涉及系统内部；在通过分析得到了满意系统需求的类之后，依据用例驱动的思想，用这些类之问的交

45、互来实现用例；在UML的图例中供应了 4种动态模型：序列图，协作图，状态图和活动图，其中序列图和协作图都是交互图；序列图可以清晰地描述一个用例路径的实现步骤，所以在系统设计中用得最多；因此本系统的动态模型用序列图来描述；一个用例路径用一个序列图来述；序列图中的消息序列来自用例路径，选用的对象序列来自类图；在设计序列图时，前面已经识别出来的类或类的操作都要受到检验，有的可能要修改，有的可能要摒弃，欢迎下载精品学习资源需要而又缺少的就要添加；由图3员工聘请治理用例模型知，员工聘请治理功能模块模块包含9个用例，下面分别画出每个用例的序列图；6.5 提出人员需求序列图提出人员需求的过程由以下几个步骤组成：1 用人部门登录人力资源治理系统，通过验证后进入系统主窗口；2 用人部门挑选“提出人员需求”菜单； 3 系统弹出其下拉菜单；4 用人部门挑选下拉菜单中的某一