Login Now 学完UML的语法和符号，如果只停留在书本上，很难直接用在实际工作中。想真正掌握，最好的办法是找个真实的业务场景，把静态的知识点放进动态的业务流里跑一遍。今天我们就拿一套典型的餐饮系统做例子，看看怎么用类图把“人员结构”和“工作职责”理顺。这套系统前台有点餐、预订、排队和外卖，后台还连着财务、物资、用户和营销等模块。功能看着多，但拆解到底，系统的骨架始终是由“人”和“流程”撑起来的。这期我们先从最基础的一步入手：理清系统中涉及的角色，以及他们各自该管什么。
做系统设计，第一步往往不是急着画原型，而是先搞清楚“谁在参与”。这里的参与包含两层意思：一是业务上的利益相关方，二是实际操作系统的人。怎么把这些人找全？思路其实很直接：从核心业务场景出发，筛出关键角色，再通过梳理流程或日常推演，把他们的具体职责一条条列出来。这时候用UML类图画出来，会特别直观。拿餐饮系统来说，我们可以把“员工”设为一个父类，服务员、厨师、店长都归在它下面。大家共享姓名、入职时间、联系方式这些基础信息，但具体分工完全不同：厨师管后厨出品和菜品质量，服务员负责前厅接待和订单流转。这样归类，既能一眼看清岗位间的共性和差异，也方便后续做权限划分。
有人可能会觉得，直接在后台按部门建账号不就行了，何必多此一举画图？其实这一步的铺垫作用很实在。它首先直接决定了后台表单长什么样。新建员工账号时，哪些是必填的公共字段，哪些是特定岗位才需要的扩展字段？类图画清楚了，设计表单时自然心里有数。比如所有员工都要填工号和电话，但厨师必须额外上传健康证和评定技能等级，店长则得绑定门店信息和财务审批权限。更重要的是，它能帮产品经理把模糊的业务需求转化成明确的系统逻辑。只有摸清每个角色的工作边界，才知道哪些环节该搬到线上，哪些可以自动化，避免设计出脱离实际的空想方案。
对于研发团队而言，一张清晰的类图能省下大量沟通成本。没有图纸，开发只能对着原型图自行推断数据库结构，很容易出现理解偏差或者字段冗余。有了明确的类、属性和关系映射，表结构设计和接口定义就能一次到位。当然，图不用画得一模一样，详略程度完全看项目阶段、系统复杂度和阅读对象。如果是成熟团队或者轻量级系统，角色和字段适当精简就好，不必面面俱到。梳理时我们更应该关注“职能模块”，而不是死板的“职位名称”。职位名称会随公司习惯变，但职能边界相对固定。这其实已经触及了领域建模的核心：用业务语言定义模型，而不是被组织架构牵着走。掌握这种“职能优先”的思路，对后续搭建中后台或SaaS产品非常有帮助。
很多产品经理看到UML符号会觉得陌生，其实抓住几个关键点就能用顺手。以继承关系为例，它表达的就是子类继承父类的属性和行为。服务员作为子类，天生带着员工的基础字段，同时自带“上菜”“翻台”这些专属操作。在UML里，继承有时也叫泛化，意思就是服务员本质上就是一种员工。另一个常用符号是“操作”，用来定义类能执行的动作。画法上，通常在属性列表下面加一条分隔线，下面写操作。虽然标准写法要求带括号和参数类型，但产品日常梳理时，为了图纸整洁好读，完全可以省略这些技术细节，把具体实现留给开发去补全。工具始终是为业务服务的，能准确传达意图才是关键。
产品经理在日常工作中，很大程度上是个“翻译官”。对研发团队，我们交付严谨的类图和字段定义，他们能直接映射到数据库和代码，沟通高效且不易出错；但对业务方或运营同事，如果直接甩出一张UML图，很容易显得不接地气。这时候就得切换表达方式：用大白话说清楚“员工包含店长、厨师、服务员等，大家共享基础档案，但负责的业务线不同，比如前厅服务员得把点单需求准确传递给后厨和吧台”。如果想更直观，换成思维导图或业务流程图通常接受度更高。业务沟通里常用的“包含”“属于”这类词，在技术语境里可能不够严谨，但只要双方意图对齐、能把事情往前推，就达到了目的。
类图从来不是为了画图而画图。它更像是一套结构化工具，帮产品经理理清业务脉络、消除表达上的歧义。把复杂的人员关系和职责边界拆清楚，不仅能让产品设计更有依据，也能让跨团队协作少很多无效沟通。当你能够自如地在技术严谨性和业务可读性之间切换，产品推进自然会顺畅得多。希望这次结合餐饮系统的拆解，能为你接下来的业务建模提供一点实实在在的参考。
