编辑导语：通过使用类图，产品经理可以更清晰地梳理设计思路，进而推动后续方案的迭代优化。同时，通过梳理类图，也可以降低团队内部的沟通成本。应该如何拆除？本文作者结合餐饮系统，做了一个类图拆解整理的案例总结，让我们一起来看看。
在学习了UML的知识之后，我们应该看更多的案例。我们来拆解一下餐饮系统，这是一个餐厅点餐、订餐、外卖的系统。我将分几章逐一拆解。
该系统大致可分为：
1.财务管理、物资管理和员工管理。
2.面向用户：用户管理、交易管理(包括订购、预订和排队)和营销管理。
3.面向数据，即通过数据帮助企业决策。
这一次，我们梳理了员工结构和工作职责。而且你需要《图解产品》的知识背景。
# 1.梳理人员结构和工作职责
设计餐厅系统，需要考虑清楚餐厅中的利益相关者(涉众)是谁，利益相关者中的参与者(系统的使用者)是谁，并梳理参与者的工作职责。怎么梳理？
这些内容都在《图解产品》这本书里。大致来说，你需要从三个角度找到所有的利益相关者，然后确定参与者，他们是系统的人，然后通过四种研究方法找到全部的工作职责。
下图是我用这本书的方法整理出来的：
这个图是一个类图，表达了服务员、厨师、店长之间的关系以及他们的工作职责。比如服务员和厨师都是员工，都有姓名、地址等内容，但工作岗位不同，比如厨师负责做饭，服务员负责送餐。
# 2.为什么要这样梳？
## 1\.指导背景的原型
要在后台创建员工，每个员工必须有一些公共字段和一些唯一字段。例如，每个员工都有年龄、性别等。但厨师还需要有健康证、厨师等级等。通过这个类图，可以明确在后台创建新员工时需要填写的字段。
## 2\.定义要实施的业务。
只有当产品经理知道每个员工的工作职责时，他才能说如何设计业务。通过这个类图，我们可以知道对方的工作，然后在线完成一些工作。
## 3\.实现便捷的研发
类图严谨明确。研发。d也很清楚一个类是什么，这些符号的含义，以便于研发；建立一个数据库。其实就算不画这个图，R & ampd将从您的原型图中抽象出来，但这将增加通信成本。
# 3.我一定要全部画出来吗？怎么梳理？
## 1\.你想把它们都画出来吗？这幅画有多详细？
这要根据目的、受众、舞台、业务复杂程度等考虑。这个数字是一个中型系统的常见内容。
这个数字和实战的区别是需要梳理的角色比较少，没有boss、财务等角色。列出的员工信息也略少，没有列出每个员工的特殊字段。
## 2\.怎么梳理？
整理类别(厨师、服务员等)。)是产品经理基本功的表达。这些类别大致相当于职称，但并不总是如此。更准确地说，我们应该整理工作功能块，而不是职称。
其实这是领域建模的范畴,和复杂设计平台的核心知识，SaaS是领域建模，但由于篇幅限制，这里就不展开了。
# 4.符号的意义是什么？
在《图解产品》这本书里，有30多页是关于类的知识(关于信息结构的章节)。你需要阅读书籍来理解为什么叫类，符号的意义和分类的方法。这篇文章只是补充书中没有提到的内容。
## 1\.继承关系
继承关系的意思是一个阶层(服务员)将继承另一个阶层(员工)的属性和行为。表达式如下。
在这种关系中，服务员也叫子类,员工叫父类(特级)。http://www.sina拥有新浪http://的所有属性和行为。
比如服务员继承了员工的“姓名”，但服务员仍然有上菜的工作(称为操作或行为)，但一般员工没有这个工作。
通过对子类,的梳理，我们可以明确背景中每一类员工的公共属性和特殊属性是什么。
继承的另一种表现形式是泛化，意思是服务员一般来说是员工。
## 2\.班级运营
一个类的操作就是这个类自己能做什么，或者你或者别人能为这个类做什么。
在这种情况下，服务员可以端茶倒水，但他不会做饭，这说明服务员能做什么，不能做什么。再举个例子，对于洗衣机，可以添加衣物、洗涤剂、开关等。
绘图的操作非常简单，即在
类的所有属性（姓名等就是属性）下面再加一条横线，再写上具体的操作，如写上“上菜”等。但要注意，按照UML的标准应写作“上菜”而不是“上菜”。括号内可加上该操作的默认值和类型（如可默认上XX菜），如不想加任何值也要用“”来表示。
但为了便于产品经理理解，本文没有加括号。而研发则可能在括号里再加内容，产品经理通常不需要做。
# 五、如何做好翻译官
产品经理是个翻译官，要见人说人话，见鬼说鬼话。
上面话就是说给研发听的。当你这样说了以后，研发容易理解，也没有歧义，并可轻松转化成代码。
也许研发还会夸你一句 “小子，可以啊，类图都懂” 。但这样的内容如说给业务人员听，就可能被骂，说你 “不画人图，不说人话” 。
那你就要用一些不严谨的说法，从而保护好自己。你可以说员工“包含”服务员、店经理、厨师等，他们都有性别，姓名等信息。而他们各自的工作是XXX，其中餐厅服务员可以要求酒保递送菜单等。
其实这个说法还是上图内容，只是换了个说法。而你还可将上图用脑图表达出来，这样画的又快，又便于业务人员理解。
但注意该说法中的“包含”一词并不严谨，“包含”在研发体系中有特定的含义。
好了，以上这就是用类图表达员工信息与工作。而一个类图其实是就是一种梳理业务的方法，也是一种无歧义的表达方法，这可帮助你理顺思路。而产品经理也应做好翻译官，这样才能拥有更强的话语权，并获得对方的认同。
希望本文能帮到你，我们下期见！
作者：擎苍，《“图解”产品：产品经理业务设计与UML建模》作者，公众号：图解产品设计
本文由 @图解产品设计 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于CC0协议
