第一次接触UML（Unified Modeling Language统一建模语言）是在2年前，当时正在学项目管理。当书中讲到系统设计阶段时，作者引入了UML的相关内容，但是2年过去了，笔者对UML的印象也就只停留在概念和样式上，并没有进行实操理解。统一建模语言(Unified Modeling Language，UML)是一种为面向对象系统的产品进行说明、可视化和编制文档的一种标准语言，是非专利的第三代建模和规约语言。UML是面向对象设计的建模工具，独立于任何具体程序设计语言。在这2年期间，在笔者PRD**现频率最多的就是流程图（+泳道）以及状态机图。对这些图的使用和理解都是凭直觉和经验，并没有过多去深挖他们的区别和原理，也没有想过是否还有其他能够更好表述自己思想的图。巧合的是，在最近正在上的产品训练营课中，再次听到主讲老师讲到了他使用UML来向工程师描述需求的案例，同时课堂中的一些引导和实操也让我对「系统了解和学习UML」产生了好奇心。于是，在经过学习后笔者整理输出了下面4个产品经理对UML最关注的4个问题：产品经理是否有必要学习UML？如何学习UML？如何选择哪种图来表达？如何把控画图的粒度？话不多说，下面将就上述4个问题进行一一解答。
一、产品经理是否有必要学习UML？
答案是肯定的，但是没有必要全学。UML，表面上是一种以图来展示的语言，但其本质是一种看待事物的思想和角度。通过UML，我们能够拥有一个抓手，快速去挖掘到事物背后的属性、特征和行为。举个例子，当你要向公司请假时，需要先向leader沟通审批；leader同意后，再将请假条拿给HR存档；财务则要在核对上班和请假天数后计算出你的当月最终工资。这件事涉及到了时间、请假、4个岗位部门的人、请假条、薪资等多个角度的内容，其中有人、有物、有事，怎样才能有一个抓手让我们快速去捋清楚这件事的全貌和特征呢？我们最惯用的就是流程图，而流程图就正和UML中的活动图不谋而合，通过时间的先后顺序去捋清楚事件（活动）的时间线及逻辑，这是我们最常惯用的一种角度；但是，在这种角度下，如果我想快速了解请假这整件事的当前状态和状态之间的变换方式时，就需要依赖UML中的状态机图，这样我们就能快速了解做哪些事可以发起请假、哪些事会被leader拒绝等。由UML中的活动图和状态机图举例来看，UML能够赋予我们看待事物的不同角度，帮助我们快速找到问题和事物的本质。看到这里，是不是就和我们进行需求分析的目标有共同之处了？因此，个人是比较推荐产品经理去学习一下UML的，我们不仅可以用UML对事物的本质进行更多视角的解读，也可以借用它在我们和工程师之间搭建一座沟通的桥梁，更好地向工程师表达和阐述我们的产品和思想。二、如何学习UML？
UML总共有十多种图，包含类图、活动图、状态机图、顺序图、用例图、部署图、构建图、包图、时序图、交互概览图、组合结构图。我们是不是要全部掌握呢？当然不是！作为一般的业务型产品经理，只需要掌握类图、活动图、状态机图、顺序图和用例图即可。这5种图能够帮助我们更好地进行问题解构和需求分析，也是没有技术背景的产品经理很好掌握的5种图。一般我们会把UML图分为结构型图和行为型图2种。结构型图描述的是事物及事物之间的结构，这个结构在某段时间内应该是稳定的、静态的；而行为图则描述的是事物的行为，是动态的。在这5种图中，类图是其中唯一的一种静态结构型图，其余4种都是行为型图。下面我们逐一来和大家讲解一下这5种图：2.1 类图 class diagram
在这5种图中，类图可谓作是其他图的基础。因为每个系统都涉及到了大量的人、事、物，这些抽象出来的人事物或者概念就是我们所说的类。而任何UML图都需要建立在有概念和类的基础上才能展开结构和行为的描述。其实在了解类图时，我不自觉联想到了之前学习数据库时的E-R图（Entity-Relationship实体-关系图），这里类和实体的概念其实是有一些相似之处的。类图也是一种帮助我们快速提炼出业务概念并识别出其属性和关系的工具。类的属性我们这里不过多展开，下面重点来了解下类之间的关系。常见的类与类之间的关系有：包含、继承、依赖，其中包含又分为聚合aggregation和组合composition。包含
类的包含关系分为聚合aggregation和组合composition2种，从中文上看起来有些不直观，我们直接用图说话。下图为聚合关系，其中A只能属于B一个类，那么我们称A和B是聚合（强包含）关系。例如A员工只能属于某一个部门。
（组合关系）
继承
继承关系指A继承了B的属性，但同时也有自己特有的特点。例如，老师和学生都是「人」，但是老师和学生各自有各自的特性，那么他们就和「人」之间是一种继承关系。继承关系有助于我们抽丝剥茧地观测到事物之间的本质，是一种进行业务提炼的重要手段。依赖
依赖关系指A需要B协助才能完成某事，但并不是必须和赖以生存的关系。就像我们开会依赖于使用投影仪一样，但没有投影仪我们也照样完成会议，只是可能没那么方便。下面，我们用一个例子来完整表示一下类图。以大家阅读这篇文章为例，这次阅读事件所涉及到的类有：读者、作者、文章、微信公众平台。
作者将文章发表在微信公众平台读者前往微信公众平台阅读文章作者可以发布0到多篇文章，但一篇文章仅属于1个作者读者也可以阅读0到多篇文章，1篇文章也可以被0到多个读者阅读
2.2 活动图 activity diagram
活动图应该是这5种图中最不需要多废口舌的，因为它和我们常见的流程图很像，就是按照时间顺序将活动的逻辑整理出来。下图就是一个简单的审批活动图，通过该图我们能清晰地了解一个完整的审批流程和逻辑。
看到这里，自然有人会问，这些实心圆圈、圆角矩形等的具体UML绘图语法必须要全部掌握吗？按下图这样「原始」的画法去画有没有问题？
其实，在日常的工作中，基本没有工程师会太过于纠结你的绘图语法正确与否。因此，形式和语法不用太过学院派，只要能够向读者清晰表达和传递意思即可。
2.3 状态机图 state machine diagram
活动图是将流程分解为一个个的活动，通过活动的先后顺序来展示流程；而状态机图则是围绕一个事物的状态为中心来讲述流程。还是以审批为例，这次我们围绕审批单为中心来描述流程。假设审批单有待审批、已撤销、审批通过和审批拒绝这4种状态，那么我们绘制的状态机图如下：
通过这个审批单的状态机图，我们能够清晰地看出审批单的状态以及影响其状态的原因和活动。在一定程度上，它帮助我们减轻了设计审批单的工作量，也帮助工程师对审批流程有更好的理解。
2.4 顺序图 sequence diagram
顺序图，有时候也会被混称为时序图，中文名字大家可以不用纠结，重点记住sequence这个单词就好。在前述的活动图中，虽然流程较为清晰，但我们很难清晰地定义角色的具体职责边界和通信交互，而顺序图则帮助我们补充到了这一点。下面，我们尝试一下从顺序图的角度来描述审批流程：
从上图中能够很明显的看出销售负责什么、系统负责什么、而管理员又负责什么；同时也能清晰看出这3个角色各自的输入输出。由此可见，顺序图能够帮助我们逐层拨开一个复杂业务的内部运作。
2.5 用例图 use case diagram
对于产品经理而言，用例图应该也是相对比较容易掌握的一种图。用例图是以操作者的角度出发，去看这个产品能够带给他哪些价值、支持他去操作和查看哪些东西。继续沿用审批举例：
如上图所示，我们能够清晰地看出销售能够发起审批、撤销审批和编辑审批，管理员能够查看和执行审批。换言之，用例图能够帮助业务方、产品和工程师以最直观的角度认识到产品能给客户带来什么价值，产品在帮助客户做什么事。用例图关注的是系统的外在表现、系统与人的交互、系统与其他系统的交互。用例图没有太多的技术用语和实现细节，在需求初期对团队和客户都是一种非常好的沟通工具。
发表评论