一、UML
UML的全称是Unified Modeling Language。翻译过来就是统一建模语言。它对产品经理最主要的作用是用于需求分析中更好的梳理逻辑，同时能够提升沟通效率。
UML主要包括图表中的十一种，那在本次的介绍中，只讲解类图、构件图、部署图、活动图、状态机图、顺序图、用例图。
通常对业务概念等静态结构进行系统化的梳理和提炼，我们叫它结构建模。而于对业务流程等动态内容进行系统化的梳理和提炼，我们叫它行为建模。
而需求分析的核心目的是解决软件有没有用的问题，软件设计是解决软件用多大的成本做出来的问题，所以需求分析首要任务是保证软件的价值。
二、类图
装逼的讲，类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。那它其实就是用来帮助我们识别出人、事、物和业务的概念，并理清它们的关系的一种方法。
2.1 类图的基础知识
在聊类图之前先让我们理清几个概念。
首先，什么是类？将某类东西归纳在一起就可以成为一个类。
例如，本文的读者，我们就可以分为初级产品经理，高级产品经理；或者分为产品经理和非产品经理；这些都可以叫做类。
然后，什么是类图？类图就是一个矩形的方框，上面是类的名字，中间是属性，下面是操作。
比如这篇文章的读者是产品经理，那产品经理的属性就有性别，年龄，级别等；如果要列举当然会有很多属性，但是我们只找出相关且对我们有用的属性。
那一般如何用类图获取需求呢？首先要识别出类。其次识别出类的主要属性。然后描述出类之间的关系，最后在对各类进行分析、抽象、整理。
2.2 类之间的关系
（1）直线关系
直线关系其实就是我们常说的关联关系，A关联B，如下图：
那如果在直线两端加上数字1，那就是1对1的关系，如下图：
同样，如果将B旁边的1改成*，那就是1对多的关系，如下图：
那如果将*改成0..3，那就是0到3的意思。如果是1..4那就是1到4的意思。下入就是1对0..3的意思：
如果把数字换成了上司和下属，那么他们就是角色关系了，就代表a是b的上级，b是a的下属。如下图：
如果把数字换成箭头，那就变成了导航关系，即由A可找到B，如下图：
（2）包含关系
包含关系有两种表示方法，一种是空心菱形，一种是实心菱形；空心菱形可以表示为弱包含的关系，实心菱形可以表示为强包含的关系。
弱包含关系即部门没有了，员工可以继续存在。强包含关系是部门没有了，员工也就不存在了。
以下图中表示的为，一个部门可以包含多个员工：
（3）继承关系
继承关系是谁继承了谁的属性。例如香蕉，苹果，葡萄他们继承了水果的属性，同时又拥有自己的属性。
我们用一个三角来表示，如下图：
（4）依赖关系
所谓的依赖关系，依赖程度是相对而言的，不一定是A没有B就不能生存了。
在实际的业务逻辑当中，对于某个事情，A需要B来协助完成，也是一种依赖关系，依赖关系使用虚线箭头表示。
2.3 类图的进阶
（1）递归关系
我们常用的电脑系统中，如果用类图表示出文件夹与文件的关系，那么该如何表达呢？是文件夹包含文件吗？那文件夹和文件夹的关系呢？
使用递归关系，我们就可以更好的表达出来。
递归关系分为自包含和自关联，和字面的解释一样，就是自己包含自己，自己关联自己。
下图分别是自包含和自关联：
（2）三角关系
当某些属性值并不是由该类本身就可以确定的时候，我们可以使用三角关系；
例如员工的薪资，职位等，并不是由公司可以确定的，而是由劳动合同来确定的，那么我们的表达方式如下：
三、活动图
活动图是用来表达流程最常用的一种UML图，它和流程图很类似。
3.1 基本语法
（1）基础流程图
流程中一般只有一个开始，会有一个或多个结束。箭头表示流程的走向，一个圆角矩形表示一个活动，活动可以理解为流程中的一个步骤，需要用主动宾的形式来表达。
例如员工填写工时，项目经理审批工时。菱形代表判断，会有两个或两个以上的分支。
判断一般有三种表达方式：在判断菱形旁写下判断的句子；直接通过监护来表示这个判断；在菱形判断之前加一个活动来表明判断动作。
分支流程汇合时，也会使用菱形，然后会合并成一条路线。如下图：
（2）泳道图
上面的流程图当中，如果流程简单，那么就可以很好的表达，如果流程很长，涉及到的角色很多，且很复杂时，看到就会非常乱，不止画的人觉着乱，看的人也会感觉很乱。
那么，这个时候我们就可以用泳道图。
泳道图一般是会按照角色进行分区，那么在画和浏览时都非常清晰。如下图：
3.2 活动图的进阶
（1）并行的活动
当遇到需要并行的活动或分支时，我们可以使用粗短棒。
短粗棒会有两个同时出现：第一个是有一个箭头指入，多条箭头指出，这个叫做分叉；第二个是多条箭头指入，一条箭头指出，这个叫汇合。如下图：
（2）对象流
当我们用矩形框来表示某个节点，并将矩形框的文字标注下划线，那它就代表对象。
每个活动都有可能有一个或多个输入或输出，与输入输出直接相连的箭头叫对象流，而活动和活动之间相连的叫控制流。
如图：
（3）连接件
有的时候活动图很大，一张纸画不下，我们可以使用另一张纸继续画，这个时候，我们可以使用连接件（其实现在的画图软件大多都不会出现这种情况）。
如下图，左边的图是箭头指向A，则是活动图到这里转向另一张图；右边的图是A指出一个箭头，表示从A开始继续这个活动图：
3.3 关于活动图的其他问题
对于活动图的粒度是如何控制的呢？其实这个是没有标准答案的，下面只是一些实践建议。
首先要清楚活动图要表达什么内容，表达的重点是什么，以此来确定合适的粒度；
其次，可以先用粒度比较大的活动图，大致搞清楚流程的总体情况；
最后在逐步细化，需要重点说明的部分，活动的粒度应该足够细，足够说明问题。
那如何画好活动图呢？
建议你一个活动图只表达一个事情，同时在画之前要明确该流程要达到怎样的业务目的、有什么角色参与、哪些是主要角色；
先画出主流程，明确主流程中涉及到的角色，然后在逐步增加分支流程，这里主要表达出关键的分支即可；
同时异常流程也不用全部表达出来，必要的时候，可以用文字来说明；控制好粒度，然后分别画出当前的流程和优化后的流程。
对照差异，整理出需要调整的地方。
四、状态机图
状态机图其实和大家常说的状态图是一个东西，只是它的专业名称叫做状态机图。
4.1 基本语法
状态机图的开始状态和结束状态与活动图的一致，活动机图用一个圆角矩形来代表一个状态。
与活动图不同，活动图是用圆角矩形代表一个活动，而且状态机图一般使用名词或形容词来表示某种状态。
如下图：
4.2 其他问题
关于状态数量的问题：在使用状态机图时，若流程不合理，可以考虑通过增加、减少、修改状态来完善。
增加一个新的状态会解决很多问题，但是也会增加流程的复杂度，可能会出现其他问题。
关于状态图的实践会有一些建议可供大家参考：
流程围绕某一事物开展时，可以考虑使用状态机图来分析；同样也需要弄清楚它的目的，参与的角色，以及这些角色是如何推动流程的发展；并且列出流程中存在的问题；
同时要考虑事物在流程不同阶段有什么变化，然后列出当前的流程，再根据流程的目的和存在的问题进行调整。
五、顺序图
当流程设计到多种角色，并且通过多个角色交互展开时，顺序图是不二选择。
5.1 基本语法
角色可以用一个小人的图标来表示，下面写明角色。也可以用一个矩形来表示，但是需要在矩形里面说明角色。
生命线是角色下面的那条虚线，激活框也叫会话，是生命线中细长的矩形。
消息用箭头表示，并在上面说明做了什么事情；箭头可以从A指向B，也可以指向自己。
返回值用虚线箭头表示，并在上面说明返回的内容，一般是反馈某个东西给相应的对象。
如下图：
5.2 顺序图的进阶
循环分支属于业务流程中比较常见的特殊结构。
loop，也叫循环，是满足循环条件的前提下，不断地重复做某些事情；
alt，条件分支，是根据不同的条件选择不同的分支；
opt，可选分支，是满足一定条件则执行该分支，否则就跳过。
如下图：
上图的流程中，loop，中括号内是循环条件的内容，表示如果满足循环条件，则重复执行本框的内容；alt，如果满足条件1则执行上半部分，如果满足条件2则执行下半部分；opt，如果满足条件，则执行框中的内容，否则跳过。
5.3 其他问题
关于顺序图使用的一些建议：
先从复杂的业务中整理出一条一条的流程，然后分析参与的角色，角色担任的职责和专业特色。
然后在将流程分解成角色与角色的交互，想清楚各个角色之间是如何交互的，用顺序图把它组织起来，在这个过程中要不断的进行优化。
活动图，状态机图和顺序图，被称为流程分析的三大利器，那么每种图都有不同的特点和应用场景。
顺序图，强调角色之间的交互，强调按时间顺序分别发生了什么事情，不太适合表达复杂的特殊流程；
活动图，强调每个角色做了什么事情，这些事情的先后关系，适合表达各种特殊流程，如分支，并发等；
状态图，主要是事情围绕某东西开展，并且有不同的状态。
那么在实际工作中如何选择呢？
通过上面说明的特点我们可以很清楚的知道。如果事情围绕某个东西开展，就可以考虑使用状态机图。
如果不是，则可以考虑顺序图或活动图；如果没有复杂的特殊流程，可以考虑顺序图。如果有负责的特殊流程，则可以考虑活动图。
当然，在实际工作中，不要被上面的条条框框所限制，有的时候可以有两种甚至三种图来表示，可以从多个角度来分析问题，再做适当取舍。
六、用例图
用例图对于很多人来说只是给一些角色配置一些权限。其实用例图是可以帮我们搞清楚这个产品是谁在用，通过这个系统能做什么事情。
6.1 基本语法
小人（actor，执行者），执行者可能是人也可能是系统。如果是人的话，可称之为角色。如果是系统的话，可以将另外一个系统画成执行者就可以了。
圈圈（用例，use case）圈圈里面的文字是动词加名词，这个就代表了系统能做什么事情。
大框框（系统边界，system boundary）这个框只框住了用例，没有框住执行者，这个就叫系统边界。
线条（关联，association）线条指用例和角色之间的线条，一般有三种，无箭头的，指向用例的箭头，指向执行者的箭头。同时，一般情况下也会有两种解释，一种是数据流向，还有一种是谁启动谁。
如下图：
6.2 进阶语法
用例的进阶语法主要包括继承、include（包含）、extend（扩展）
（1）include（包含）
包含一般有两种用法，一种是以树的方式组织各种用例，用包含来组织好父子用例，子用例可以再次包含自己的子用例，这样层次分明。
还有一种是某些用例的一部分可以抽离出来成为子用例，该子用例同时也被其他用例包含。
如下图：（2）extend(扩展)
扩展的意思就是在某用例的基础上，还能做什么事情。例如用户在查看报表的时候，还可以导出报表，打印报表。如下图：
（3）继承
继承与类图中的继承性质是一样的，但是一般在画用例图的时候很少用，都会用其他的方式替代，因为不太好理解，而且还会降低沟通效率。如下图：
6.3 用例图的其他问题
那么我们日常工作中，如何画好用例图呢？
下面是一些在实践中的建议：
首先，在客户能全面理解的基础上，越精简越好；
同时用例应该使用客户的语言，让客户能够看得懂，要全面的表达用例，对于重点的地方要详细描述，非重点的地方不要过多描述；
通过使用扩展和包含来细化用例图，但要灵活把握，用例图只是一种表达方式，必要时可以结合其他方式来表达。
七、部署图、构件图
部署图和构件图一般用来获取和描述非功能需求。非功能性需求，一般包括两个方面，一方面的软件技术的架构要求。另一方面是安全性、易用性、性能等方面的要求。
7.1 部署图
在实际环境中的电脑、服务器或硬件设备，在部署图中用节点（Node）来表示，就是图中一个个立体矩形。
每个节点都有一个名字，如图中的财务的pc等。
门店的pc中有标记，标记（Tags）用来详细说明节点的配置情况，如Number=50-70，说明有50到70台门店的pc。
节点与节点直接有物理联系，则直接拉条直线，在直线上写上连接的方式。
如下图所示。
7.2 构件图
构件图也叫组件图，构件指的是物理上独立的一个东西，它可以单独维护、升级、替换。
下图展示了构件和构件的接口：
下图中的A和B表示依赖关系，表示A依赖于B，A需要调用B提供的一些服务。而C和D则是接口对接，D提供的服务是C所需要的，也可以画成C依赖D。
如图：
7.3 部署图和构件图结合使用
通常部署图和构件图需要综合使用，才能表达清楚在架构设计上的要求。
如下图：
7.4 关于部署图和构件图的实践建议
首先不要写放在任何地方都可用的东西，要根据项目的业务需求，IT架构环境写出针对性的要求；
其次，抓住主要问题，列出具体要求。主要考虑正常使用情况下系统应达到的要求，出现几率低的情况可不考虑；
最后，要文字表达准确，内容应该是可被验证的。
八、一些实践
本章主要为前面所讲的内容，通过一个案例，将部分串联起来。
我们的需求是做一个考勤系统。主要目标是规范员工的上下班、请假、外出工作等行为，同时方便计算员工薪资，方便管理各种带薪假期。
在整个过程中，需要遵循战略分析、相关方与目标分析、业务分析、需求细化这样的流程。那在业务分析阶段可以通过使用类图来分析业务概念，使用活动图、顺序图、状态机图来分析业务流程。
在需求细化阶段可以使用用例图来整理用例。同时也可以使用部署图和构件图来分析整理非功能性需求。
那在这里直接省略战略分析、相关方与目标分析阶段，直接进入到业务概念分析。假设已经目标清晰，且明确了相关方。那么下一步进入到业务概念分析。
8.1 业务概念图
这个考勤系统主要涉及到考勤，请假，外出。考勤和请假很好理解，外出是指外出工作，性质仍然是工作。
这三类事情全都涉及到流程，流程的问题咱们后面在分析，通常我们管理一个事情，除了管理流程，还要对一条或多条记录进行管理。
打卡不是会留下打卡记录吗？请假不是会有请假申请吗？外出不是会有外出申请吗？管理这些记录，就是管理这些事情了。
如下图，列出了关键的业务概念、业务概念的重要属性、业务概念之间的关系、相关业务信息通过注解来补充。
每个人所在的公司情况不一样，理解的角度不一样，业务概念图自然就会不一样。
8.2 外出申请审批流程分析
这里只对外出申请做举例，分别画出它的活动图和状态机图。
当然，也可以用顺序图来表达，但是此处用活动图和状态机图更合适，所有省略了顺序图。
活动图
状态机图
8.3 普通员工的用例分析
这里只对普通员工做举例，进行了用例分析。这里考虑到用户需要拥有管理自己外出的权限，管理自己请假，包含可休年假的权限。
同时为了方便安排工作，所以增加了可以查看所有员工请假的权限，以及查看自己打卡记录的权限。
如下图：
8.4 其他
关于部署图和构件图，一般情况下是由架构师来完成。所以在这里就不进行举例了。
九、所以
关于UML，是我们日常工作中，最常见的一种手段。它很简单，也很复杂。
简单的原因在于一学就会，容易上手，便于理解；复杂的原因是要画好uml建模需要不断的思考，反复验证，重复修改，才能达到最终的目的。
