科技猎结合实例入门产品经理必学的UML
经常听见一些产品大佬在产品设计时提到使用UML分析，作为一个产品新人，我去学习了一下关于UML的知识，套用到实际的工作中后发现真的是用处非常大，能够快速帮我们梳理需求，并指导产品设计。本文将为大家介绍一下UML的基本概念，并以一个例子介绍一下常见的UML图。欢迎各位拍砖~
一. 什么是UML？
UML的全程是Unified Modeling Language，中文翻译叫统一建模语言，你可以简单理解为一种有特殊用途的语言。为什么说是一种语言呢？因为有很多内容光用文字是无法表达的，所以语言包括文字与图形，UML就是用图形来表达需求与设计的一种语言。
我们用UML建立了一套软件开发界的标准，但这并不是唯一标准，只是目前大家比较推崇的一种，我们的目的是善用包括UML在内的各种标准，来提高我们的需求分析与产品设计水平。
二. UML有什么用？
很多人认为，UML的主要用途就是软件设计。也有人认为，如果你不是开发人员，是难以理解UML的。实际上，UML能大大帮助产品经理做软件需求分析和软件设计的工作。
对于新手来说，先将UML应用于软件需求分析时，其学习难度会大大降低，而且你基本不需要掌握软件开发的知识，只要你对软件需求分析感兴趣，认真学习和应用UML，就很有机会成为软件需求分析高手！
三. UML具体有哪些图形？
初识UML的学习者可能会被这么多的UML图搞晕，其实UML图可以分为两种：结构型UML图和行为型UML图。
1、结构型的UML图包括：
- 类图(Class Diagram）
- 对象图(Object Diagram)
- 构件图(Component Diagram)
- 部署图(Deployment Diagram)
- 包图(Package Diagram)
2、行为型的UML图包括：
- 活动图(Activity Diagram)
- 状态机图(State Machine Diagram)
- 顺序图(Sequence Diagram)
- 通信图(Communication Diagram)
- 用例图(Use Case Diagram)
- 时序图(Timing Diagram)
结构型图描述的是某种结构，这种结构在某段时间内是稳定的，是“静态”的，而行为型图描述的是某种行为，是“动态”的。分析系统需求时，我们会面对很多业务概念，他们之间会有某种关系，这些内容可以看成是“静态”的。同时，业务会涉及大量的流程、过程等，这些内容是“动态”的。
UML图例众多，但是实际产品设计工作中一般主要使用其中几种，那么接下来我将根据UML的实际应用情况来介绍几种常用的UML图，首先放上一张UML的应用场景表：
本文将依次介绍类图、活动图、状态机图、顺序图、用例图。
1. 类图
1.1 类图基础知识
首先我们了解一下类的概念，将各种业务概念、人物等经过抽象之后都可以视之为类。比如可以将人分为男人和女人两类，他们的属性有年龄、职业、兴趣爱好等。我们将类抽象为一个矩形的方框，上面是类的名字，中间是类的属性。
如何用类图获取需求呢？首先要识别出类。其次识别出类的主要属性。然后描述出类之间的关系，最后在对各类进行分析、抽象、整理。
1.2 类之间的关系
（1）直线关系
直线关系就是我们常说的关联关系，表示A关联B，如下图：
如果在直线两端加上数字1，表示1个A对应1个B，如下图：
如果将一端的1改成 ， 代表0到多个的意思，表示1个A对应0到多个B，如下图：
如果将一端的*改成0..3，0..3代表0到3个的意思，表示1个A对应0到3个B，如下图：
如果将直线改为箭头，那就变成了导航关系，表示由A可以找到B，如下图：
（2）包含关系
这里有两种表示方法，一种是空心菱形，一种是实心菱形。空心菱形表示若包含关系，实心菱形表示强包含关系。以下图为例，两者区别在于：弱包含表示部门不存在员工也可以继续存在，强包含表示部门不存在员工也不存在。
2. 活动图
2.1 基础流程图
一个流程图一般只有一个开始状态、一个结束状态，但有时候会在某个分支结束流程，这时就会有多个结束状态。箭头表示流程的走向，流程应开始于开始状态，结束于结束状态。一个活动图有一个开始状态，一个或者多个结束状态，这并不是绝对的，有时候你可能只想表达流程的一部分，那么就可以不画开始状态和结束状态。一个矩形表示的是一个活动，一个菱形表示一个判断。
2.2 泳道图
如果业务流程简单，基础流程图就能清楚描述清楚。如果流程很长，涉及到的角色很多，且很复杂时，基础流程图不能很清楚表达，这个时候我们就可以用泳道图。
泳道图是按照角色进行分区的流程图，如下图：
3. 状态机图
状态机图即我们平时所说的状态图，其开始状态和结束状态与活动图的一致，但活动图是用矩形代表一个活动，而且状态机图一般使用名词或形容词来表示某种状态，连接线上填写了状态变更的条件，如下图：
关于状态数量的思考：
1、流程不合理时，可以考虑通过增加、减少、修改状态来完善。
2、增加一个合适的新状态，可能会解决很多问题。
3、但新增状态的副作用就是增加流程的复杂度，可能会因此带来其他问题。
下图是状态数量与流程复杂度之间关系的示意图。
合适而准确的状态划分，是画好状态机图的难点和关键，这需要长时间的磨练。
4. 顺序图
当业务流程设计到多种角色，并且多个角色之间有频繁交互时，使用顺序图是非常好的选择。
人形公仔表示一种角色，公仔下面的文字说明该角色的名字。
由一个角色指向另一个角色的实线箭头表示传递的消息。
自己指向自己的箭头表示角色本身做了什么事情。
虚线的反方向箭头表示反馈信息。
示例如下图：
活动图与顺序图在一定程度上有些相似，但是他们之前的区别也很明显。活动图适用于梳理系统的一系列流程，明确流程各个步骤，其中泳道图能清楚展示各角色需要做的事；顺序图特点在于能展示“交互”，展示角色之间动作的交互与信息的传输，包括系统与外部角色/系统之间，或系统内部不同部分之间的交互。
5. 用例图
用例图可以帮助我们梳理角色能使用系统做什么，也能表示系统具备的功能。
用例图包含的元素如下：
- 小人（执行者），执行者可能是人也可能是系统。如果是人的话，可称之为角色。如果是系统的话，可以将另外一个系统画成执行者就可以了。
- 圈圈（用例），圈圈里面的文字是动词加名词，这个就代表了系统能做什么事情。
- 大框框（系统边界），这个框只框住了用例，没有框住执行者，这个就叫系统边界。
- 线条（关联），线条指用例和角色之间的线条，一般有三种，无箭头的，指向用例的箭头，指向执行者的箭头。同时，一般情况下也会有两种解释，一种是数据流向，还有一种是谁启动谁。
示例图如下：
用例的Include：
我们实际遇到的产品中实际上有非常多的动作：增加信息、读取信息、更新信息、删除信息等，如果每个用例都用一个圈圈表示，用例圈圈会遍地都是，用例显得很多、很杂。对于这些用例，可以用“管理某某”这个用例代替之。
“管理菜式”用例有四根虚线，箭头分别指向“增加菜式”、“修改菜式”、“查看菜式”、“删除菜式”，虚线上有“<>”字眼，这表示“管理菜式”包含这四个子用例，子用例是父用例的一部分，这就是Include的意思。
五. UML实际案例应用分析
1. 需求背景
某传统制造业公司，员工人数100人左右，包括普通员工、行政人员、财务人员、经理等角色。在没有考勤系统之前，与考勤相关的管理工作是这样的：
- 每位员工需要上午上班时打一次卡，下午下班时打一次卡，中午的休息不需要打卡。
- 期间如果需要外出工作，从公司出发时需要打一次卡，回到公司时需要再打一次卡。
- 员工请假需要填写请假条，请假分为事假、病假、年假等多种情况，请假需要直接领导审批，甚至还需要高层领导的审批。
- 行政部每天统计考勤信息，包括打卡信息、外出信息请假信息，每月将考勤汇总信息提交给财务部。
- 财务部根据考勒汇总信息，调整员工的薪金。
但这样的管理方式，出现了一些意外事件：
- 某员工想请年休假，但行政部告知该员工的当年度年休假已经休完了。年休假的管理出现了问题，很可能会影响员工的工作积极性。
- 某员工投诉当月薪金多扣了钱，原因是考勤信息统计有误。于是财务部将责任推到行政部，行政部推诿财务部要求不明确。
- 某天出现了紧急状况，高层领导想找员工A来处理，但员工A当天请了假，高层领导并不知情。
因此，公司高层期望通过考勤系统提高考勤工作的效率和准确性，避免因为考勤问题影响正常工作
2. 目标及涉众分析
3. 业务概念分析
说明：由于上述需求涉及的流程与产品功能较多，限于篇幅后文我们仅针对 员工外出请假申请 这个需求进行分析。案例中涉及的其他需求分析读者可自行思考与练习，或者在留言处评论若人数多可再出一篇文章进行分析。
外出申请的关键属性包括开始与结束时间、外出事由，一个外出申请仅对应一个外出申请状态。部门经理审批的关键属性包括是否同意、审批意见、审批时间，一个部门经理审批仅对应一个部门经理的操作。副总经理与总经理的属性相同。
4. 业务流程分析
4.1 流程图
员工发起外出申请流程为，员工发起申请，由部门经理审批，同意后由副总经理审批，副总经理同意后若该请假单时长大于3天则需交由总经理审批，若小于等于3天则直接审批通过。总经理同意后，审批通过。任一人员拒绝申请该申请即不通过。
4.2 状态机图
该业务中，主要的状态有5种，待审批、已拒绝、部门经理已审批、副总经理已审批、总经理已审批。梳理请假申请过程中请假单的各个状态之间的流转状态，十分有助于厘清业务流程。
4.3 顺序图
顺序图以参与业务流程的各个角色为基线，梳理了信息在各个角色间流转的顺序。梳理顺序图的好处是能清楚各角色的任务与职责，特点在于能展示“交互”，展示角色之间动作的交互与信息的传输，包括系统与外部角色/系统之间、或系统内部不同部分之间的交互。
5. 功能分析
梳理用例图能够帮助产品经理理清该角色对于产品的需求以及对应的产品功能，相当于梳理了产品的结构，后续的原型设计可据此为总纲设计。
6. 原型设计
原型设计本文不做展示，需求的分析与梳理过程才是重要的。
六. 如何学好UML？
学UML之难，不在于学习语法，关键是要改变思维习惯。UML是一种有用的工具，但同时也代表了一种不用的思考方法，如果不能掌握这样的方法，只能是学到了UML的形，而没有掌握其神髓。要用好UML，你需要在平时多多培养下面的能力:
1.书面表达能力。
2.归纳总结能力。
3.“面向对象”的思维能力和抽象能力。
平时你可以利用各种机会来提升第1种和第2种能力，如多写写项目文档、日记或博客等，名思考和总结平时自己的工作得失等。
第3种能力说起来有点虚，大家在大学中可能也学过相关知识。训练这种能力的最好方法就是多应用类图我们将会在第3章类图再重点介绍，通过实例来体会什么才叫“面向对象”!
只要你有进取之心，多练习、多实践、多思考、多总结，定会取得长足进步!
本文由 @书丰 原创发布于产品壹佰，未经许可，禁止转载。本文参考张传波所著《火球：UML大战需求分析》，如有侵权，联系删除。题图来自Unsplash，基于CC0协议。
