学了UML知识结束后，我们应该多看看案例。


现在让我们拆解餐饮系统。


该系统是餐厅使用的订购、预订和外卖业务系统。


我将分为几篇文章逐一拆解。


系统大致可分为： 企业：财务管理、物资管理、员工管理。


用户管理、交易管理(包括点餐、预订、排队)、营销管理。


帮助企业通过数据做出决策。


这一次，我们梳理了员工的结构和工作职责。


你需要有图形产品的知识背景。


一、梳理人员结构和工作职责 为了设计餐厅系统，有必要考虑谁参与餐厅（利益相关者）和参与者（使用系统的人），并整理参与者的工作职责。


如何整理它？ 这些内容都存在于图形产品中。


一般的方法是，你需要从三个角度找到所有的参与者，然后从他们中澄清参与者。


这些参与者是使用系统的人，然后通过四种研究方法找到所有的工作职责。


下图是我用这本书的方法梳理: 这张照片是一张类别图片，表达了服务员、厨师、商店经理和他们的工作职责之间的关系。


例如，服务员和厨师都是员工，有姓名、地址等内容，但他们的工作不同，如厨师负责烹饪，服务员负责送食物。


二、为什么这么梳理？ 1. 指导背景原型 为了在后台创建员工，每个员工都应该有一些公共字段和一些独特的字段。


例如，每个员工都有年龄、性别等，但厨师也应该有健康证书、厨师水平等内容。


通过这种图片，您可以清楚地知道新员工在后台填写的字段。


2. 明确要实现的业务 只有在了解了每个员工的工作职责后，产品经理才能谈论如何设计业务。


通过这个类别，你可以知道你的工作，然后在网上完成一些工作。


3. 实现研发方便 类图严谨无歧义。


R&D也很清楚什么是类，这些符号的意思，便于R&D构建数据库。


其实即使不画这张图，R&D也会从你的原型图中抽象出来，但这样做会增加沟通成本。


三、都要画吗？怎么梳理？ 1. 都要画吗？画多详细？ 这是基于目的、受众、阶段、业务复杂性等方面的考虑。


而是中型系统的常见内容。


与实战不同的是，梳理的角色稍少，没有老板、财务等角色；列出的员工信息也稍少，没有列出每个员工的特殊字段。


2. 如何梳理？ 梳理清楚（厨师、服务员等）是产品经理技能的表现。


这些类别大致相当于职位名称，但并不总是如此。


更准确地说，我们应该整理工作职能块，而不是职位名称。


这实际上是领域建模的范畴，设计复杂的中间平台和SaaS核心知识是领域建模，但仅限于篇幅。


四、符号的含义是什么？ 在《图形产品》一书中，你用了30多页来谈论类知识（信息结构一章）。


你必须阅读才能理解为什么它被称为类，以及符号的意义和梳理方法。


本文仅补充了书中没有提到的内容。


1. 继承关系 继承关系是指一类(服务员)会继承另一类(员工)的属性和行为。


表达如下图所示。


在这种关系中，服务员也被称为子类，员工被称为父类（超级类）。


子类有父类的所有属性和行为，但子类有父类没有的特殊内容。


例如，服务员继承了员工的姓名等内容，但服务员仍（称为操作或行为），但普通员工没有上菜。


通过梳理继承关系，可以明确后台各类员工的公共和特殊属性。


继承的另一种说法是泛化，也就是说服务员泛泛而谈是员工。


2. 类的操作 类的操作是你能做的，或者你或其他人能做的。


在这种情况下，服务员可以端茶送水，但不能做饭，这表明服务员可以做什么，不能做什么。


另一个例子是，你可以在洗衣机上添加衣服、洗衣粉、开关和关闭开关。


操作的画法很简单，就是在所有属性(姓名等)下加一条横线，然后写上具体的操作，比如上菜。


但要注意，按照UML标准应写为上菜()而不是上菜。


该操作的默认值和类型可以添加到括号中(如果可以默认的话)XX如果不想加任何值，也要用()来表示。


但为了方便产品经理的理解，本文没有括号。


研发可以在括号中添加内容，产品经理通常不需要这样做。


五、如何做好翻译 产品经理是翻译，要见人说人话，见鬼说鬼话。


以上是关于研发的。


当你这么说的时候，研发很容易理解，没有歧义，可以很容易地转换成代码。


也许研发会称赞你男孩，是的，你知道所有的类图。


但是，如果这样的内容是给业务人员听的，可能会被骂，说你不画人图，不说人话。


然后你必须用一些不严格的说法来保护自己。


你可以说员工包括服务员、商店经理、厨师等，他们都有性别、姓名和其他信息。


他们自己的工作是XXX，其中，餐厅服务员可以要求酒保送菜单。


其实这个说法还是上图的内容，只是换个说法。


你也可以用脑图表达上图，这样画得快，方便业务人员理解。


但请注意，该说法中的包含一词并不严谨，包含在研发体系中具有特定的含义。


嗯，这就是用类图来表达员工的信息和工作。


事实上，类图是一种梳理业务的方式，也是一种无歧义的表达方式，可以帮助你理顺思路。


产品经理也应该是一名好的翻译，以便有更强的发言权并得到对方的认可。


希望这篇文章能帮到你，下次见！ 作者：擎苍，图解产品：产品经理的业务设计与UML作者建模，微信官方账号:产品设计图 本文由 @设计图形产品 原创发布 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。


本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。


如有侵权行为，请联系网站管理员删除，。