员工|餐饮系统大拆解：用类图拆解员工结构与工作职责（1）( 二 ) 车机系统|驾驶技术|吉利旗下

如服务员继承了员工这个类的“姓名”等内容，但服务员还有上菜这个工作（称其为操作或行为），但一般员工却没有该工作。
通过继承关系的梳理，可明确后台每类员工的公共和特殊属性有什么。
继承的另一个说法是泛化，也就是说服务员泛泛而谈就是一个员工。
2. 类的操作类的操作就是类自己能做的事情，或者是你或他人能对类做的事情。
在本案例中，服务员能端茶送水，但却不能做菜，这就是在表明服务员这个类能做什么，不能做什么。再如，一个洗衣机你可以对他加衣服、加洗衣粉，打开开关和关闭开关等操作。
操作的画法很简单，就是在类的所有属性（姓名等就是属性）下面再加一条横线，再写上具体的操作，如写上“上菜”等。
但要注意，按照UML的标准应写作“上菜”而不是“上菜”。括号内可加上该操作的默认值和类型（如可默认上XX菜），如不想加任何值也要用“”来表示。
但为了便于产品经理理解，本文没有加括号。而研发则可能在括号里再加内容，产品经理通常不需要做。
五、如何做好翻译官产品经理是个翻译官，要见人说人话，见鬼说鬼话。
上面话就是说给研发听的。当你这样说了以后，研发容易理解，也没有歧义，并可轻松转化成代码。
也许研发还会夸你一句“小子，可以啊，类图都懂”。但这样的内容如说给业务人员听，就可能被骂，说你“不画人图，不说人话”。
那你就要用一些不严谨的说法，从而保护好自己。你可以说员工“包含”服务员、店经理、厨师等，他们都有性别，姓名等信息。而他们各自的工作是XXX，其中餐厅服务员可以要求酒保递送菜单等。
其实这个说法还是上图内容，只是换了个说法。而你还可将上图用脑图表达出来，这样画的又快，又便于业务人员理解。
但注意该说法中的“包含”一词并不严谨，“包含”在研发体系中有特定的含义。
好了，以上这就是用类图表达员工信息与工作。而一个类图其实是就是一种梳理业务的方法，也是一种无歧义的表达方法，这可帮助你理顺思路。而产品经理也应做好翻译官，这样才能拥有更强的话语权，并获得对方的认同。
希望本文能帮到你，我们下期见！
作者：擎苍，《“图解”产品：产品经理业务设计与UML建模》作者，公众号：图解产品设计
本文由 @图解产品设计原创发布于人人都是产品经理。未经许可，禁止转载。
【员工|餐饮系统大拆解：用类图拆解员工结构与工作职责（1）】题图来自Unsplash，基于CC0协议