简介这份文档资料面向软件工程、信息系统专业的学生及企业信息化设计人员围绕《基于UML的人力资源管理系统设计》展开帮助读者掌握以统一建模语言完成业务建模与系统设计的完整思路。资源共1个doc文件压缩包约1.85MB内容以文字与图示为主便于直接阅读与二次整理。文档系统梳理了组织机构、职位、人力资源规划、绩效考评、人事、劳动合同、招聘、培训、薪资与福利等十大模块的功能需求并以招聘管理为例深入讲解需求计划制定、人员供需预测、筛选录用流程以及类图、序列图、状态图、活动图等UML元素的建模方法同时涉及B/S体系结构与PowerDesigner工具选型。目前已有183人学习适合作为课程设计、毕业设计或系统分析建模的参考范本帮助读者快速理解复杂业务逻辑并提升设计文档的规范性与可读性。1. 一份 UML 建模文档为什么值得你花时间拆开看很多做企业信息化的同行一听到“UML 设计文档”就下意识觉得是学校里交作业的东西跟真实项目隔着十万八千里。但这份《人力资源管理系统UML设计.doc》不太一样——它拿一家近 2000 人规模的企业做背景从需求描述一路推到用例模型、实体类模型、接口类模型、窗口结构最后落到动态模型里的序列图完整走了一遍 RUP 的“需求分析 分析与设计”工作流。换句话说它不是教你 UML 语法而是给你看一个真实业务域是怎么被拆成可落地模型的。这份资料适合三类人一是正在做 HR 系统或类似管理后台需要一套能直接抄的建模骨架二是准备用 PowerDesigner 做 UML 建模但不知道从哪张图开始下手三是想搞清楚“用例驱动、迭代开发”到底怎么落到具体图上的开发者。它解决的核心问题就一个把“人力资源管理”这种又大又虚的业务切成一张张能画、能评审、能交给开发去实现的图。下面我按自己拆文档的顺序把关键节点和踩过的坑讲清楚。2. 从需求到用例模型活动者识别与用例粒度怎么定2.1 先别急着画图把活动者识别做扎实文档里有一句话我特别认同活动者识别是系统分析员与用户交流的起点也是项目获得后续产品的关键。很多人画用例图翻车不是 UML 语法不熟而是活动者没识别干净。这份资料给了一个很实用的自问清单——谁对系统运行结果感兴趣谁会改变系统数据谁要从系统拿信息谁要和系统交互在系统顶层它识别出 8 类活动者公司主管、人力资源部、用人部门、培训部门、财务处、公司工会、系统管理员、应聘人员。到了招聘管理模块又收敛成 5 类总经理、人力资源部、用人部门、应聘人员、劳动部门。这里有个关键判断资深专业人士和复试小组虽然参与业务但不直接与系统交互所以不能识别为活动者。这个边界如果划错后面用例图会多出一堆无意义的连线。我一般会这么做先按部门/角色列一张表逐个问“这个角色会不会登录系统、会不会点按钮、会不会看报表”三个都否的直接划掉。文档里把人力资源部、人力资源部部长、人力资源部人员合并成一个活动者依据是“目标相同”这个合并逻辑在实操里非常省事能避免用例图爆炸。2.2 用例识别从事件表到用例的收敛过程文档给的用例识别方法很直接事件 主语 动词 宾语。主语是已识别的活动者动词是动作宾语是目标。比如“人力资源部 管理 劳动合同”就是一个事件。把所有事件列成事件表再把目标相同或相近的事件合并就得到用例。系统顶层最终收敛出 13 个用例管理组织机构、管理招聘、管理职位、规划人力资源、考评员工绩效、管理人事档案、管理劳动合同、管理培训、管理员工薪资、管理员工福利、管理系统权限、登录系统、修改个人资料。到了招聘管理模块又细化为 9 个子用例提出人员需求、制定人力资源需求计划、审批人力资源需求计划、拟定招聘计划、审批招聘计划、发布招聘公告、登记个人简历和求职表、参与员工筛选录用、评估招聘工作。这里有个粒度问题值得单独说。文档明确提到用例粒度太粗一个路径甚至一个业务步骤也能定义成用例粒度太细一个用例只有一条路径功能会支离破碎。我的经验是如果一个用例的主路径超过 7 步就该考虑拆如果两个用例的活动者和目标完全一样只是操作对象不同就该合并。招聘模块里“参与员工筛选录用”被进一步细化成 20 个子用例从初步筛选简历一直到签订正式劳动合同这就是典型的“粗用例往下钻”的做法。2.3 用例模板把“系统做什么”写清楚文档给了一个统一的用例模板字段包括用例名称、用例目标、级别、活动者、状态、前件条件、成功后件、主路径、可选路径、例外路径。这个模板的价值在于它强迫你把“系统做什么”和“系统怎么做”分开——用例图只显示活动者和用例的关系不显示路径路径要靠结构化叙述来补。以“管理招聘”用例为例活动者是人力资源部、公司主管、用人部门前件条件是人力资源部登录系统主路径是“用人部门提出人员需求 → 人力资源部拟定招聘计划 → 公司主管审批招聘计划 → 人力资源部发布招聘公告 → 人力资源部筛选录用应聘者 → 人力资源部评估招聘工作”。这条主路径其实就是后面序列图的骨架。我一般会要求团队在写主路径时每一步都对应一个明确的系统动作不要写“处理招聘事宜”这种模糊描述。可选路径和例外路径也不能空着哪怕写“无”也要显式声明否则开发阶段一定会有人问“如果审批不通过怎么办”。3. 实体类模型名词识别法与类关系梳理3.1 名词识别法从业务描述里捞类实体类模型是面向对象分析的核心最终要映射到数据库。文档用的识别方法是名词识别法从系统描述里找出名词、名词短语或名词性代词单数名词识别为对象复数名词识别为类。但要注意不是每个名词都对应一个类有的可能只是其他类的属性有的几个名词其实指向同一个类。在招聘管理模块文档从业务描述里捞出了一大串名词总经理、人力资源部、用人部门、劳动部门、求职者、拟予聘任的人员、拟予复试的人员、通过复试的应聘人员、应聘人员、拟录用的人员、体检合格者、社会应聘人员、被录用的应届毕业生、被录用员工、员工、落选的应聘者、试用期的人员、部门、部门人员需求、年度人力资源需求计划、招聘计划、招聘公告、个人简历、求职表、面试通知、初试测评表、复试记录表、复试结果推荐书、复审意见、拟录用人员、体检结果、劳动手续、试用通知、员工登记表、试用劳动合同、试用意见、转正定级审批表、试用期工作小结、考核意见、正式劳动合同。然后做合并总经理、人力资源部、用人部门、劳动部门合并为“用户”类求职者、拟予聘任的人员、拟予复试的人员、通过复试的应聘人员、应聘人员、拟录用的人员、体检合格者、社会应聘人员、被录用的应届毕业生、被录用员工、员工、落选的应聘者、试用期的人员、拟录用人员、个人简历合并为“应聘者”类部门单独成类部门人员需求、年度人力资源需求计划、招聘计划、招聘公告、求职表、面试通知、初试测评表、复试记录表、复试结果推荐书、复审意见、体检结果、试用通知、员工登记表、试用劳动合同、试用意见、转正定级审批表、试用期工作小结、考核意见、正式劳动合同各自成类。这个合并逻辑很关键。很多新手会把“求职者”“应聘人员”“拟录用人员”拆成三个类结果类图里全是冗余关联。文档的判断标准是如果两个名词描述的是同一个业务实体在不同阶段的状态就合并成一个类用状态字段区分。3.2 类关系显式关系从用例找隐式关系靠分析识别出类之后下一步是识别类与类之间的关系。文档提到显式关系可以从用例中找到隐式关系在用例里没有明确说明需要认真分析。比如“应聘者”和“个人简历”之间是聚合关系“招聘计划”和“招聘公告”之间是关联关系“部门”和“部门人员需求”之间是组合关系。我一般会画一张类关系矩阵行和列都是类名交叉点填关系类型。填不出来的格子先空着回头对着用例描述逐个补。文档里招聘管理模块的实体类类图就是这么做出来的虽然原文没有贴出完整类图但从名词合并和关系描述能看出它至少覆盖了用户、应聘者、部门、招聘计划、招聘公告、面试通知、初试测评表、复试记录表、劳动合同等核心实体。3.3 实体类到数据库的映射思路实体类最终要映射到数据库这一步文档没有展开但按常见做法每个实体类对应一张表类的属性对应字段类之间的关系对应外键或中间表。比如“应聘者”和“个人简历”是一对一可以在应聘者表里加简历字段也可以单独建简历表用应聘者 ID 关联“招聘计划”和“招聘公告”是一对多公告表里加计划 ID 作为外键。这里有个坑UML 类图里的多对多关系映射到数据库时必须拆成两个一对多中间加一张关联表。文档里“用户”和“部门”之间可能是多对多一个用户属于多个部门一个部门有多个用户如果直接映射会出问题。我一般会在类图阶段就把多对多拆开避免后期改表结构。4. 接口类模型与窗口结构从用例到界面的映射4.1 接口类识别用例驱动界面设计接口类模型描述活动者与系统交互的界面是应用程序的“可视区”也是系统与外界的隔离层。文档的做法是从用例去识别接口类用户接口直接与用例相连用户通过用户接口发起和终止用例。系统主窗口的接口类包括 UserLogin用户登录窗口、MainWindow系统主窗口、MainMenu主菜单。主菜单包含 12 个菜单项对应 12 个下拉菜单类M_Org、M_Invite、M_Job、M_Power、Review、M_File、M_Pact、M_Train、M_Wage、M_Boon、M_Adm、M_Ind。这些类之间的关系是UserLogin 依赖 MainWindowMainWindow 包含 MainMenuMainMenu 依赖 12 个下拉菜单类。招聘管理模块的接口类更细M_Invite招聘管理菜单依赖 AdvanceReq、SetMPlan、ApproveMPlan、SetIPlan、ApproveIPlan、IssueI、FillInBio、Filter、Evaluation 九个类。每个类对应一个操作比如 AdvanceReq() 对应“提出人员需求”菜单项SetMPlan() 对应“制定需求计划”菜单项。这里有个设计原则接口类之间的关系主要有组成关系和依赖关系。一个特定窗口由许多构件组成窗口与构件之间是组成关系由一个窗口进入另一个窗口这两个窗口就是依赖关系。文档里 SetMPlan 依赖 AdvanceReqApproveMPlan 依赖 SetMPlanSetIPlan 依赖 ApproveMPlan这条依赖链其实就是招聘流程的业务顺序。4.2 窗口结构先定切换流程再画原型窗口结构描述窗口之间的切换流程通过窗口结构可以直观看到用例的路径流程。文档强调一个软件在实用性上满足用户需求是不够的如果窗口结构不合理也不会受到用户欢迎。系统总体窗口结构是先经过用户权限验证窗口通过验证后弹出系统主窗口主窗口包含 9 个菜单项根据用户权限不同显示不同菜单项。招聘管理模块的窗口结构是M_Invite 菜单下挂 9 个菜单项每个菜单项弹出一个窗口窗口之间按依赖关系切换。我一般会先画一张窗口切换图节点是窗口边是切换动作然后对着用例的主路径走一遍看有没有断点。文档里“提出人员需求”的窗口结构是用人部门登录 → 主窗口 → 选择“提出人员需求”菜单 → 弹出下拉菜单 → 选择“编辑/查看/修改/删除人员需求” → 弹出相应窗口 → 完成工作 → 系统保存。这条链路如果中间缺一个窗口用户就卡住了。4.3 接口类与实体类的对应关系接口类负责展示和采集数据实体类负责持久化数据两者之间需要建立对应关系。比如 AdvanceReq 窗口采集的“部门人员需求”数据最终要写入“部门人员需求”实体类Filter 窗口处理的“初试测评表”“复试记录表”“复试结果推荐书”数据要分别写入对应的实体类。文档里没有显式画接口类和实体类的映射图但按常见做法可以在接口类图旁边标注它操作的实体类。我一般会在接口类的方法签名里体现实体类比如AdvanceReq.save(DepartmentDemand demand)这样开发一看就知道数据流向。5. 动态模型序列图怎么画才不翻车5.1 序列图的基本要素对象、消息、生命线动态模型描述每一个用例路径所涉及的若干对象的交互行为文档选用序列图来描述。序列图的基本要素是对象、消息和生命线。对象来自类图消息序列来自用例路径。以“提出人员需求”序列图为例参与的对象有用人部门活动者、UserLogin 窗口、MainWindow 窗口、MainMenu 菜单、M_Invite 菜单、AdvanceReq 窗口、部门人员需求实体类。消息序列是用人部门登录 → UserLogin 验证 → MainWindow 显示 → MainMenu 显示 → 选择“提出人员需求” → M_Invite 显示下拉菜单 → 选择“编辑人员需求” → AdvanceReq 窗口弹出 → 填写需求 → 保存 → 部门人员需求实体类持久化。文档里每个用例都配了一张序列图从提出人员需求、制定人力资源需求计划、审批人力资源需求计划、拟定招聘计划、审批招聘计划、发布招聘公告一路画到员工筛选录用。这些序列图的共同结构是活动者先登录再选菜单再操作窗口最后系统保存。5.2 序列图与用例路径的对应关系文档明确说一个用例路径用一个序列图来描述。这意味着如果一个用例有主路径、可选路径和例外路径理论上要画三张序列图。但文档为了节省篇幅只画了主路径的序列图可选路径和例外路径用文字描述。我一般会要求团队至少画主路径和例外路径两张序列图。主路径用来对齐正常流程例外路径用来暴露异常处理逻辑。比如“审批人力资源需求计划”用例主路径是总经理审批通过例外路径是总经理审批不通过后者需要回退到“制定人力资源需求计划”步骤这个回退在序列图里就是一条反向消息。5.3 序列图设计中的类操作检验文档提到一个很重要的点在设计序列图时前面已经识别出来的类或类的操作都要受到检验有的可能要修改有的可能要摒弃需要而又缺少的就要添加。这就是迭代式开发的核心——模型不是一次成型的画序列图的过程就是检验类图的过程。比如在画“发布招聘公告”序列图时如果发现 IssueI 窗口需要调用一个“生成公告编号”的操作但类图里没有这个方法就要回头补上。如果发现某个类在序列图里从来没被用到就要考虑是不是多余了。我一般会在画完所有序列图后回头对着类图做一次交叉检查确保每个类至少在一个序列图里出现过每个操作至少被一条消息调用过。6. 避坑与排查UML 建模里最容易翻车的五个地方6.1 活动者识别过度拆分现象用例图里活动者数量爆炸同一个部门拆出部长、主管、专员三个活动者连线密密麻麻。原因没有按“目标相同”的原则合并活动者把组织架构里的岗位直接当成了活动者。解决回到文档里的判断标准——是否直接与系统交互、目标是否相同。人力资源部、人力资源部部长、人力资源部人员目标相同合并为一个活动者用人部门、用人部门代表、用人部门主管领导目标相同合并为一个活动者。6.2 用例粒度失控现象一个用例的主路径写了二十几步或者一个简单功能拆成十几个用例用例图看不出业务主线。原因没有控制用例粒度要么把业务流程当用例要么把业务步骤当用例。解决主路径超过 7 步就往下拆拆到每个用例的主路径在 3 到 7 步之间。文档里“参与员工筛选录用”拆成 20 个子用例每个子用例的主路径都很短这就是正确的拆法。6.3 实体类合并错误现象类图里出现大量含义相近的类比如“求职者”“应聘人员”“拟录用人员”各成一个类关联关系混乱。原因没有识别出这些名词其实是同一个业务实体在不同阶段的状态。解决按业务实体合并用状态字段区分阶段。文档里把求职者、应聘人员、拟录用人员、体检合格者、试用期人员、员工全部合并为“应聘者”类就是这个思路。6.4 接口类与用例脱节现象界面设计得很漂亮但跟用例对不上用户找不到入口或者入口进去了没有对应的业务操作。原因接口类不是从用例推导出来的而是凭感觉画的。解决每个用例至少对应一个接口类操作每个接口类操作至少对应一个用例。文档里 M_Invite 菜单的 9 个操作一一对应招聘管理的 9 个用例这就是正确的映射。6.5 序列图与类图不一致现象序列图里调用的方法在类图里找不到或者类图里的类在序列图里从来没出现过。原因画序列图时没有回头检验类图两张图各画各的。解决画完序列图后对着类图做一次交叉检查。每个消息对应一个类操作每个类操作至少被一条消息调用。文档里明确说“有的可能要修改有的可能要摒弃需要而又缺少的就要添加”这就是迭代检验的过程。7. 进阶用法用 PowerDesigner 把模型导出成可评审的文档文档里提到建模工具选的是 PowerDesigner软件过程选的是 RUP。我平时用 PowerDesigner 最多的场景是把 UML 模型直接导出成 Word 或 HTML 格式的评审文档省去手工整理的时间。具体做法是在 PowerDesigner 里建好用例图、类图、序列图之后用 Report Wizard 生成报告选择需要输出的图类型和属性字段导出成 RTF 或 HTML。这里有个技巧在导出之前先把每个用例的模板字段填完整尤其是前件条件、成功后件、主路径、可选路径、例外路径。PowerDesigner 会把这些字段作为用例属性一起导出评审的时候一目了然。另外类图里的类注释也要写清楚导出后会变成类的说明文字开发看文档时不用再回头翻原始需求。还有一个进阶用法是用 PowerDesigner 的模型检查功能检查类图里有没有孤立类、有没有未使用的操作、有没有循环依赖。我一般会在导出评审文档之前跑一遍检查把低级错误先清掉。文档里提到的“迭代式开发是一个循环往复的开发过程”在工具层面就是靠这种检查来落地的。从那以后我每次做完 UML 建模都会强制走一遍“用例模板填完整 → 类图交叉检查 → 序列图与类图对齐 → PowerDesigner 模型检查 → 导出评审文档”这个流程少一步后面就会有人来问“这个用例的例外路径是什么”“这个类为什么没有操作”。希望帮到你。本文还有配套的精品资源点击获取