在掌握UML基础之后，深入案例实践方能融会贯通。
本次，我们聚焦于“快缩短网址”团队正在探索的餐饮业务系统——一个集点餐、预订与外卖于一体的数字化餐厅解决方案。我们将以系列文章的形式，层层拆解其架构逻辑。

本篇聚焦于员工结构与职责建模，旨在为后续系统设计奠定清晰的业务语义基础。

---

一、厘清角色：谁在使用系统？

构建系统前，须先识别所有利益相关者（Stakeholders）与系统参与者（Actors）。
在餐饮场景中，核心参与者包括：服务员、厨师、店长等一线运营人员。他们不仅是系统的使用者，更是业务流程的执行主体。

如何系统化梳理？
答案藏于《图解产品》所倡导的信息结构建模方法中——通过类图（Class Diagram），将人员抽象为“类”，其属性与行为即为系统需承载的数据与功能。

> 示例：
> - 员工（Employee） 是父类，拥有姓名、工号、联系方式等通用属性；
> - 服务员（Waiter） 与 厨师（Chef） 作为子类，分别继承通用信息，并扩展专属职责：
> - 服务员可执行“上菜()”、“引导入座()”；
> - 厨师则具备“烹饪菜品()”、“检查食材库存()”等操作。

此类图不仅描绘了组织结构，更隐含了权限边界与业务流入口。

---

二、为何要如此建模？

#### 1. 指导后台原型设计
员工管理模块需兼顾共性与个性。
- 公共字段（如身份证号、入职日期）统一归于“员工”类；
- 特殊字段（如厨师的健康证编号、职级证书）则归属子类。
类图直接映射数据库表结构，避免字段冗余或遗漏。

#### 2. 锚定业务实现边界
产品经理唯有明晰“谁做什么”，才能精准设计功能路径。
例如：
- 服务员不可修改菜品配方 → 系统应限制其访问后厨配置界面；
- 店长可查看当日营收 → 需为其开放财务数据接口。
职责即权限，权限即产品逻辑。

#### 3. 降低研发沟通成本
类图是无歧义的“技术契约”。
- 继承关系明确代码复用层级；
- 操作列表直接对应API方法名；
- 属性定义即数据库字段规范。
与其让研发从原型图中反向推测业务规则，不如前置交付结构化模型。

---

三、是否需要事无巨细地绘制？

不必追求大而全，而应服务于目标。



- 复杂度决定粒度：中型餐饮系统可聚焦核心角色（服务员、厨师、店长），暂略财务、老板等外围角色；
- 阶段决定深度：MVP阶段仅需关键属性，后期再扩展资质、排班等细节；
- 本质是职能块，而非职位名：同一岗位可能承担多类职责，建模应以“行为域”为单位，这正是领域驱动设计（DDD）的精髓所在。



---

四、符号背后的语言

类图非美术创作，而是精密语义工具。

#### ▶ 继承（Inheritance / Generalization）
- 表示“是一种”（is-a）关系：服务员 是 员工；
- 子类自动拥有父类所有属性与操作，并可覆写或扩展；
- 在代码中体现为 class Waiter extends Employee。

#### ▶ 操作（Operations）
- 描述“能做什么”：上菜()、烹饪()；
- UML规范要求写作 serveDish() 而非“上菜”，括号表示方法调用；
- 产品经理可简化表达，但需知其技术含义，以便与研发对齐。

---

五、做一名优秀的“翻译官”

产品经理的核心能力，在于在不同语境间无缝切换。

- 对研发：用类图说话，严谨、无歧义，展现专业建模素养；
- 对业务方：转译为自然语言：“我们的员工分三类，服务员负责接待，厨师专注出餐……” 或辅以脑图快速传达；
- 切忌混淆术语：如“包含”在UML中特指组合/聚合关系，日常交流中却易被误解为隶属。

真正的高手，既能画出精准的类图，也能用一杯咖啡的时间讲清系统逻辑。

---

类图，不只是UML的一种图形，更是结构化思维的外显。
它帮我们剥离表象，直抵业务本质——谁，在什么条件下，能做什么事。

在“快缩短网址”（suo.run）的实践中，我们始终相信：清晰的模型，是高效产品的起点。

下期，我们将拆解“交易管理”模块，看订单、预订与排队如何交织成一张动态业务网。

—— 擎苍，《图解产品》作者
微信公众号：产品设计图