uml 产品经理（产品经理必备利器——UML）

购物车简笔画步骤产品经理及。的必备武器——UML

产品经理经常和文档打交道，如果想输出高质量的文档，可以 没有UML的帮助是不行的。本文将通过具体的需求实例介绍产品经理必须掌握的几种UML图、绘制 及其使用场景。

互联网上有关于UML的定义和语法的详细教程。本文不细说，用一句话来定义

UML(统一建模语言)是一种在软件设计中提供给分析师、设计师和工程师的通用语言。

也就是通过面向对象的方式建立统一的、通用的模型来解决问题，那么UML建立的模型到底包括什么呢？

我们知道，社会各个领域或多或少都会存在需求问题。在整理分析需求的时候，我们可以把共同的需求抽象成一个基本的模型。模型由它的相关对象组成，不同的对象有不同的特征和操作。通常，对象通过类来实例化，其中对象的特征决定对象的状态，并且通过消息传递在对象之间交换信息。

这可能有点太抽象了。我举个简单的例子。

在某电商平台上，用户A需要购买电子商品，用户B需要购买生活用品，用户C需要购买生鲜食品.等等，而这种需求完全可以抽象为一种购物模式。该模型包含的两类对象分别是用户和商家。其中，用户具有身份信息、购物需求等属性，商家具有店铺性质、商品价格等属性。，用户可以添加购物车、下单等操作，商家可以发布商品、发货等操作。如果用户已经购买了商品，那么他的状态就会变成没有购买需求。在整个购物过程中，用户和商家通过平台进行信息交流。

对于产品经理来说，掌握UML是为了

梳理产品需求和业务流程，梳理产品实现价值及其应用场景，将产品需求精准传达至设计开发。也就是说，UML为产品经理提供了一套能够分析问题、准确沟通的图形化语言，是产品经理必备的工具之一。

下面这篇文章将从产品经理的角度介绍几种产品经理必备的UML图。的工作和产品实现过程并结合具体案例。

一.用例图

1.1定义

用例图是产品经理在产品需求分析中最常用的工具图。在许多高质量的产品需求陈述(PRD)中不难找到用例图。作为一个经常写PRD的产品经理，大家都知道用例是描述产品需求的一种方式，产品需求的根本来源还是来自用户。要快速理解用例图的含义，只需记住以下几点

Where:需求产生的地方，即需求产生的领域。谁谁是相关用户，即从用户 的观点？什么是产品/系统？如何如何使用该产品/系统？为什么用户不。不关心产品/系统的实现？比如小明有 的需求，所以从小明 的观点，他只需要知道一个电子商务网站满足他的需求，并知道如何使用它，他不 我不在乎。

用一句话来概括

用例图强调了产品/系统是什么，以及用户如何使用它。s自己的观点，不考虑其具体实现。

作为产品经理，用例图有三个更大的优势

需求分析根据不同的用例分析，生成不同的需求引导测试在产品/系统测试中，可以根据用例生成测试用例，方便交流；产品经理、设计师、开发人员和客户可以通过用例轻松地交流需求。

在学习如何绘制用例图之前，您必须知道一个完整的用例图包含哪些元素

元素含义图备注参与使用系统/产品的用户一般是使用系统/产品的用户。用户直接使用的功能可以理解为用户 需求子系统由几个密切相关的用例组成。如果没有，关系用例图的各个部分之间的连接可以省略。有关具体的关系类型，请参见下表。有关注释，请参见下表。解释用例或关系。如果没有，那么可以省略与项目用例相对应的项目描述文档的链接。5它很少被使用。

这种关系分为四种类型

关系意义图备注了关联角色与用例之间的关系表示信息的传递，概括了角色与用例之间的继承关系将复杂的用例分解为从子到父的小功能将复杂的用例分解为基本用例，从附加到基本用例增加附加功能。

1.3案例

现在我们结合以上的画图 ，画出一个完整的电商平台案例的用例图。画图前先分析需求(个别需求是为了迎合上面的画图 而刻意讲解的，真实场景可能略有不同):

购物网站一般有两类用户注册用户和未注册用户。整个购物系统可以分为搜索、添加购物车、下单、搜索支付四个流程，可以根据价格、品牌等条件展开过滤。通过支付宝、微信或银行卡，从用例图中可以清楚地看到支付。

注册用户和未注册用户都属于用户 广义购物。该系统是某电商网站按条件搜索的子系统，是搜索功能的延伸，但不同的是筛选搜索的广义支付包括支付宝、微信、银行卡。图表清晰简洁地描述了系统的用户、需求和主要功能之间的关系，这是用例图的更大优点。

二、序列图

2.1定义

在用例图中，我们只关心用户如何使用系统的各种功能(用例),我们不关心用户如何使用系统。不关心功能的具体实现(用例)。序列图通过引入时间的概念，表示用例中各个对象的行为顺序以及对象之间的消息交互过程，所以序列图也叫序列图。

例如，在小明 s ，参与者是小明本人， 平台和支付平台。那么序列图就可以展示 开始到结束这段时间内，三者之间的消息传递过程。

也用一句话来定义

序列图是面向对的

象的动态图形，显示用例中参与交互的所有对象之间消息传递的时间顺序。

而作为产品经理，顺序图能更加清晰的梳理业务关系及流程，保证产品需求的准确性、可实现性。

2.2 画法

从定义中不难发现，顺序图是以对象和时间为维度的二维图形，图形中的对象是按照时间顺序排列。在了解其画法之前，先来看看顺序图中重要的元素（高级元素暂不介绍）

元素含义图示备注角色用户或系统或子系统①并不是用例图中的用户，注意区分对象参与交互的所有对象②命名方式类名:对象名、:对象名、类名（匿名对象）生命线由对象向下延伸的一条虚线，表示其存在时间③生命线上有两种状态休眠和激活，生命线的长度为交互对象的全部生命周期激活期一段矩形表示对象的活跃时间④也被称为控制焦点消息对象之间的通信方式见下表见下表

其中消息分为四种

消息含义图示同步消息发送者通过消息把信号传递给接收者并停止活动，等待接受者放弃、返回或控制。⑤异步消息发送者通过消息把信号传递给接收者，并继续活动，不等待接受者返回或控制。⑥返回消息发送者发送消息后的反馈⑦自关联消息对象给自身发送消息，一般为相同对象中 之间的调用⑧

特别注意

顺序图必须是两个或两个以上对象间进行交互顺序图的阅读是从上到下、从左到右进行消息的传递代表的是责任分配，不代表数据传递

2.3 案例

结合上述画法，继续来看一个具体案例。该案例为用户在购物平台上从挑选商品到下单成功支付的过程，先来分析一下需求（个别需求为了迎合上述画法而刻意说明，真实场景可能略有差异）

用户登录购物网站，并进行搜索并确认商品，进行下单操作创建订单后进入第三方支付平台进行支付操作支付结果会反馈给平台购物结果会反馈给用户

从上图可以清晰的看到随着时间变化，用户与用例中其他对象的消息交互顺序，这也为产品经理与开发之间提供了更加简洁有效的沟通方式。

三、活动图

3.1 定义

不知道大家有没有了解或使用过泳道图，泳道图其实就是活动图的一种，只不过在泳道图中，各个活动会根据其对应的对象或系统来分隔。那么什么是活动图呢？

活动图与顺序图很相似，也是一种描述用例的动态图形。与顺序图不同的是，活动图强调了用例中各项活动之间的约束关系及其控制流程，说白了活动图用于展示系统中一个功能（用例）的操作步骤。

用一句话来定义

活动图展示了用例的具体业务与工作流程，以及各项业务之间的约束关系。

作为产品经理，熟练掌握活动图有以下几个好处

分析与梳理业务流程深刻理解系统功能挖掘潜在的业务需求

3.2 画法

带泳道的活动图是产品经理必备的技能之一，在了解其画法之前，先来了解活动图中重要的元素

元素含义图示备注起点与终点表示活动的起始与结束①起点只有一个，终点可有多个活动状态表示活动中的某个节点②可以是文字、表达式或 转换表示活动与活动之间的转移③没有触发条件判断与条件根据不同条件有不同的活动分支④类似流程图中的判断分叉与合并表示两个或以上并发活动的开始与结束⑤判断并不是并发，注意区别

注意

活动图很像流程图，但不等同于流程图活动图强调对象的活动，顺序图强调对象及其生命周期泳道并不是必须的元素

3.3 案例

由于活动图与顺序图很相似，所以我们可以将顺序图的案例改成一个带泳道的二维活动图，其中以活动作为纵轴，以对象/系统作为横轴。先来分析一下需求（个别需求为了迎合上述画法而刻意说明，真实场景可能略有差异）

用户登录有成功和失败判断下单直接购买和结算购物车两种方式不管用哪种下单方式，都会进入支付流程支付有成功和失败判断

注用户应该参与全过程，这里为了说明二维泳道图的画法，刻意去除了购物与支付流程的参与。

从图中可以清晰的看到用户从登录到购物结束的整个活动过程，并能看到每个活动所对应的对象，这在业务流程梳理环节能给产品经理们提供很大的帮助。

四、类图

4.1 定义

与顺序图、活动图这两种动态图形不同的是，类图显示的是系统/产品中的静态关系及关系。在介绍什么是类图之前提个问题，还记得本文开头对 UML 框架的说明中对类的定义吗？如果记得的话，你会知道通过类创建的类实例是对象的实例化。

通过前三种图形的学习，我们对对象这个概念已经很熟悉了，你可以简单看成是系统/产品的参与者（可以作为使用者参与，也可以作为子系统参与）。在对象实例化成类后，参与者的特征及操作也被相应的实例化成属性和 。

那么有没有一种图形可以描述用例中不同的类的数据和 之间的关系呢？没错，那就是类图。这里给出一句话定义

类图是用于描述系统/产品结构化设计的静态图形，显示了类、类的 、类的接口以及它们之间静态结构和关系。

作为产品经理，运用类图可以理清业务概念以及它们的关系，能更加深入地剖析系统/产品业务。

4.2 画法

从定义中不难发现，类图需要表现各个类之间的关系。在了解其画法之前，先来看看类图中重要的元素

元素含义图示备注说明类对象的实例化①类中有其属性和 接口只可以被实现，不可以实例化②其结构与类相似泛化子类与父类之间的继承关系③子类拥有父类的所有属性和 实现类与接口之间的继承关系④类拥有接口的所有属性和 聚合整体与部分的关系，两者可以分开⑤一种组合关系，两者不可以分开，这里省略说明关联类与类之间的联系⑥双向关联有两个箭头或没有箭头，单向关联有一个箭头依赖一个类依赖于另一个类⑦此关系经常体现在某个类的 使用另一个类的对象作为参数

其中多样性示例如下

多样性示例含义n..m有n到m个实例，n可以是00.. 或 没有实例个数的限制，可以没有1只有一个实例1..最少一个实例

注意

类的操作是针对类自身，并不是操作其他类由于类图中关系复杂，一定要注意规范一个复杂的实例可以被分为多个类

4.3 案例

结合上述画法，继续来看一个具体案例，仍然是用户 用例，先来分析一下需求（个别需求为了迎合上述画法而刻意说明，真实场景可能略有差异）

用户必须使用电脑/手机才能进行 ，也就是用户依赖于电脑/手机搜索可以按照关键字/价格/品牌等进行搜索，那么搜索可以封装成接口在整个订单中包含了订单详情，发货状态等部分可以通过支付宝/微信等方式进行支付，相当于继承了支付的所有功能

从图中可以清晰的看到各个被实例化之后的对象（也就是类）之间的相互关系，既能帮助产品经理更深刻的认识整个用例系统，也能便于其与开发人员之间的沟通。

五、

好了，已经将 UML 中四种产品经理最常用且最有用的四种图介绍完了，现在来一下各图作用以及它们的使用场景

图形作用使用场景用例图从用户角度介绍整个系统/产品是什么分析用户需求顺序图显示整个用例中各个对象的生命周期分析业务流程中对象的交互时间顺序活动图显示整个用例中各对象与各活动的业务流程分析某个用例具体的工作流类图显示系统/产品的静态结构及关系分析用例具体的实例及其 、接口

产品经理可以根据根据实际情况选取更佳的图形，那么作为产品经理该如何选取画 UML 的工具？

使用画图工具的意义在于提升效率，而计算效率时一定要除去学习工具的时间成本，有很多非常专业的软件学习起来比较吃力，极不推荐。又由于产品经理遇到的图形非常多，如果每种图形都使用一种工具的话，不仅切换麻烦而且兼容性、一致性都很差。在这里只简单推荐几款

频繁使用、专业使用 UML 推荐 StarUML作为辅助工具使用Win 端 Visio，Mac 端 OmniGraffle在线协作ProcessOn

根据个人需求酌情择优，毕竟只有适合自己的才是更好的。

产品经理为什么要uml建模 产品经理业务设计与uml建模