大年夜话PM｜产品经理必备利器：UML

对付 UML 的定义及其语法在网络上已经有了详细的教程，本文不做详细的展开解释，这里用一句话来定义：

UML（统一建模措辞）是一种在软件设计时供应给剖析师、设计师和工程师之间的通用措辞。

即通过面向工具的办法构建一个统一并通用的模型来办理问题，那么话说回来 UML 所构建的模型到底包括哪些内容呢？

我们知道，社会中各个领域都会存在或多或少的需求问题，在需求整理和剖析时，可以将具有共性的需求抽象成一个基本模型。
模型由其干系的工具组成，不同的工具具有不同的特色和操作。
一样平常通过类来对工具进行实例化，个中工具的特色决定了工具的状态，而工具之间则通过通报来进行信息互换。

这样说可能有点过于抽象，举一个很大略的例子：

在某电商平台上，用户A须要购买电子商品，用户B须要购买生活用品，用户C须要购买生鲜食品…等等，这类需求就完备可以抽象为一个购物模型。

该模型中包含的两类工具分别为用户和商家，个顶用户具有身份信息、购物需求等属性，而商家则具有店铺性子、商品价格等属性。
同时用户可以进行加入购物车、下单等操作，商家则可以进行发布商品、发货等操作。

如果用户已经购买的商品，那么他的状态会变成无购买需求。
在购物的全体过程中，用户和商家之间通过平台进行信息互换。

对付产品经理，闇练节制 UML 的浸染在于：

梳理产品需求及其业务流程；梳理产品实现代价及其利用场景；准确向设计及开拓传达产品需求。

也便是说，UML 给产品经理们供应了一套既能剖析问题又能准确互换的图形化措辞，以是说它是产品经理必备的利器之一。

下面本文将从产品经理事情及产品实现流程角度并结合详细案例，分别先容几种产品经理必备的 UML 图。

一、用例图1.1 定义

用例图是产品经理在产品需求剖析中最常用的工具图，在很多高质量的产品需求解释（PRD）中不难创造用例图的踪影。
作为常常写 PRD 的产品经理都知道用例是一种描述产品需求的方法，而产品需求的根本来源还是来自用户。

想要快速理解用例图的含义只须要记住以下几点：

Where：需求在哪里产生，即需求产生的领域；Who：谁是干系的用户，即从用户角度出发；What：产品/系统是什么；How：如何利用这个产品/系统；No Why：用户不关心产品/系统为什么可以实现。

举个例子来说，小明有网购的需求，那么从小明的角度来说，他只要知道某个电商网站知足他的需求，并且知道如何利用即可，并不关心网站如何开拓实现。

用一句话总结来说：

用例图强调了从用户自身角度办理其需求的产品/系统是什么以及如何利用，不关心它的详细实现。

而作为产品经理，利用用例图最大的三个优点在于：

需求剖析：根据不同的用例剖析，产生不同的需求；辅导测试：在产品/系统测试时，可以根据用例天生测试用例；便于沟通：产品经理与设计、开拓以及客户之间可以很随意马虎的通过用例沟通需求。

1.2 画法

在学会如何画用例图之前，必须理解一个完全的用例图详细包含哪些元素：

个中关系分为四种：

1.3 案例

现在我们结合上述画法，画一个完全的电商平台案例的用例图。

在画图之前先剖析一下需求（个别需求为了迎合上述画法而刻意解释，真实场景可能略有差异）：

购物网站一样平常有两种用户：注册用户、非注册用户；用户全体购物系统可以分为四个过程：搜索、添加购物车、下单、付款；搜索又可以按价格、品牌等条件进行扩展筛选；付款可以通过支付宝、微信或银行卡等办法。

从用例图中可以非常清晰的看到：

注册用户和非注册用户都属于用户的泛化；购物的四个过程组成的系统是一个电商网站的子系统；按条件进行搜索，这是对搜索功能的扩展，而不同的条件是筛选搜索的泛化；付款包含了支付宝、微信、银行卡三种办法；

上图清晰并简洁的描述了用户、需求和系统紧张功能之间的关系，这便是用例图最大的优点。

二、顺序图2.1 定义

在用例图中，我们只关心用户如何利用系统的各个功能（用例），但并不关心功能（用例）的详细实现。
而顺序图通过引入韶光的观点，展示了用例中各个工具的行为顺序以及工具之间的交互过程，以是顺序图也叫做时序图。

举个（不严谨的）例子：在小明网购的用例中，参与的工具有小明自己、网购平台和支付平台。
那么顺序图则可以展示从网购开始到结束这段韶光内，三者之间的通报过程。

同样用一句话来定义：

顺序图是一种面向工具的动态图形，显示用例中参与交互的所有工具之间通报的韶光顺序。

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

2.2 画法

从定义中不难创造，顺序图因此工具和韶光为维度的二维图形，图形中的工具是按照韶光顺序排列。

在理解其画法之前，先来看看顺序图中主要的元素（高等元素暂不先容）：

个中分为四种：

特殊把稳：

顺序图必须是两个或两个以上工具间进行交互；顺序图的阅读是从上到下、从左到右进行；的通报代表的是任务分配，不代表数据通报。

2.3 案例

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

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

从上图可以清晰的看到随着韶光变革，用户与用例中其他工具的交互顺序，这也为产品经理与开拓之间供应了更加简洁有效的沟通办法。

三、活动图3.1 定义

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

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

用一句话来定义：

活动图展示了用例的详细业务与事情流程，以及各项业务之间的约束关系。

作为产品经理，闇练节制活动图有以下几个好处：

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

3.2 画法

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

把稳：

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

3.3 案例

由于活动图与顺序图很相似，以是我们可以将顺序图的案例改成一个带泳道的二维活动图，个中以活动作为纵轴，以工具/系统作为横轴。

先来剖析一下需求（个别需求为了迎合上述画法而刻意解释，真实场景可能略有差异）：

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

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

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

四、类图4.1 定义

与顺序图、活动图这两种动态图形不同的是，类图显示的是系统/产品中的静态关系及关系。
在先容什么是类图之条件个问题，还记得本文开头对 UML 框架的解释中对类的定义吗？

如果记得的话，你会知道：类是工具的实例化。

通过前三种图形的学习，我们对工具这个观点已经很熟习了，你可以大略算作是系统/产品的参与者（可以作为利用者参与，也可以作为子系统参与）。
在工具实例化成类后，参与者的特色及操作也被相应的实例化成属性和方法。

那么有没有一种图形，可以描述用例中不同的类的数据和方法之间的关系呢？

没错，那便是类图。
这里给出一句话定义：

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

作为产品经理，利用类图可以理清业务观点以及它们的关系，能更加深入地阐发系统/产品业务。

4.2 画法

从定义中不难创造，类图须要表现各个类之间的关系。
在理解其画法之前，先来看看类图中主要的元素：

个中多样性示例如下：

把稳：

类的操作是针对类自身，并不是操作其他类；由于类图中关系繁芜，一定要把稳规范；一个繁芜的实例可以被分为多个类。

4.3 案例

结合上述画法，连续来看一个详细案例，仍旧是用户网购用例，先来剖析一下需求（个别需求为了迎合上述画法而刻意解释，真实场景可能略有差异）：

用户必须利用电脑/手性能力进行网购，也便是用户依赖于电脑/手机；搜索可以按照关键字/价格/品牌等进行搜索，那么搜索可以封装成接口；在全体订单中包含了订单详情，发货状态等部分；可以通过支付宝/微信等办法进行支付，相称于继续了支付的所有功能。

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

五、总结

好了，已经将 UML 中四种产品经理最常用且最有用的四种图先容完了，现在来总结一下各图浸染以及它们的利用场景：

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

利用画图工具的意义在于提升效率，而打算效率时一定要撤除学习工具的韶光本钱，有很多非常专业的软件学习起来比较吃力，极不推举。
又由于产品经理碰着的图形非常多，如果每种图形都利用一种工具的话，不仅切换麻烦而且兼容性、同等性都很差。

在这里只大略推举几款：

频繁利用、专业利用 UML ：推举 StarUML；作为赞助工具利用：Win 端 Visio，Mac 端 OmniGraffle；在线协作：ProcessOn。

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

参考资料：

产品必修课——轻松搞定 UML

本文由 @ iamxiarui 原创发布于大家都是产品经理。
未经容许，禁止转载

题图作者供应