本文笔者将为大家总结一些在需求分析与设计阶段会常用的到的UML图，并且对每一个UML图进行了详细讲解。
最近在学习UML相关的知识，结合了以往的项目以及之前学习编程时的面向对象思想，瞬间感觉UML真的是产品需求分析和设计的强大武器（尤其针对于复杂的2B类项目）！同时，在产品文档中多融入UML图也可以很好的增加文档的可读性。
本文就来总结一下UML的相关知识吧~
一、UML基础知识
UML的全称是Unified Modeling Language，翻译过来就是统一建模语言。
UML是一种开放的方法，用于说明、可视化、构建和编写一个正在开发的、面向对象的、软件密集系统的制品的开放方法。UML展现了一系列最佳工程实践，这些最佳实践在对大规模，复杂系统进行建模方面，特别是在软件架构层次已经被验证有效（摘自百度百科，真拗口……）。
UML其实就是一系列的图形，那么为什么说是语言呢？
——因为语言是包括文字和图形的，在机械工程或建筑领域，设计图纸内都是包含大量图形和语言的，在这两个领域都有各自的标准来描述设计。
那么同理，在软件开发界，就需要UML来帮助我们完成软件开发的工作，UML就是软件领域的标准。当然，UML并不是唯一的标准，只不过UML是业内比较推崇的一类罢了。
二、UML有何作用？
很多初学UML的人会认为：UML是开发人员专门使用的，可以用来生成代码，可以用来指导编程，如果不是开发人员会很难理解UML的。
其实不然，我认为：UML可以很有效的帮助产品经理或产品设计师进行前期的产品需求分析与产品的设计。在我们梳理项目的业务流程时就会用到活动图，在我们整理系统功能时就会用到用例图，在我们与客户面对面进行沟通调研时用例图、活动图、顺序图等UML可以使得沟通变得更加顺畅。
将UML应用在项目需求分析和设计时，会使得它的学习门槛大大降低，而且也不一定需要掌握开发知识。通过学习应用UML，将会使我们的工作事半功倍。
三、UML图
废话不多说了，开始介绍几种在需求分析和设计阶段会用到的UML图（在以下的介绍中，我会加入各种UML图的推荐指数，这个推荐指数是针对于在需求分析与设计阶段的一个推荐度）。
1. 活动图
（1）什么是活动图?
这里的活动，可以指企业的活动，也可以指应用程序中的活动。因此，也可说活动图是用来陈述活动与活动之间的流程控制的迁移。
（2）活动图的画法
活动图的绘制涉及几个重要的元素：
起始点：是一连串活动的开始点，在一个活动图中，有且只有一个起始点。
起始点的图示：
结束点：是一连串活动的终结点，在一个活动图中，可以有多个结束点。
结束点的图示：
活动：是活动图最核心的元素，指人或系统的一连串执行细节。比如，用户在淘宝APP内的“要求退货”就是一个活动，在这个活动中，可能会包括用户的一连串的动作——比如“打开APP、进入订单页面”等，但是这些细节都要通过“要求退货”这个活动来表达。
活动的图示：
迁移：代表流程控制权的迁移，当某一个活动结束后，流程的控制权就通过迁移给另一个活动。如下图：
分支：代表一个判断的准则，以菱形块表示。当指定一个分支时，从分支连接出去的迁移必须要有必要条件，这在UML中称为约束。在UML中，使用“[]”来表示约束：
分叉以及会合：代表对于后续活动的同步处理，这也是活动图区分与流程图的关键一点。当某个活动结束后，需要同时进行两个以上的活动，此时需要用分叉来表达；而当某个活动必须要等其前置的多个活动完成后方可执行，此时会用会合来表达。
分叉与会合的图示都是：
通常来说，分叉与会合会搭配出现，当活动图中出现了分叉点，那么在后续的某个特定环节必定会有会合点。
泳道：对于产品经理来说并不陌生，利用泳道可以分配对应的角色，可以帮助我们清晰地知道发起活动的角色是谁。
泳道的图示：
活动图范例：
（3）活动图的使用场景
由于活动的定义不是十分的明确，因此，在系统设计时不会利用活动图来表达应用程序的架构。活动图通常适用于表达企业或系统的工作流程关系，例如：在梳理业务流程时，我们通常会使用带泳道的活动图。
此外，活动图非常类似于流程图，因此也适用于表达程序的内部的工作流或结构。
（4）推荐指数
活动图在需求分析与规划阶段是梳理业务流程的必备工具，同时在涉及单独模块流程时也应用频繁。因此，推荐指数：★★★★★
2. 用例图
（1）什么是用例？
根据用例的创始人Ivar Jacobson的定义：“用例是在一个系统中所进行的一连串的活动，该活动要能够满足系统外部的执行者对系统的预期”。
其实说白了，一个产品或系统的用例，就是用户对于产品或系统的某一个完整的预期。从另一个角度来说，用例也代表着一个具体的业务场景。
（2）用例图的画法
用例图涉及到的几个重要元素：
用例：如前所述，用例代表着用户对于产品或系统的完整预期，也就是用户在系统内期望的事，在完成了该预期后用户可以离开产品或系统。是不是有点“用完即走”的意思？微信的一个用例，就可以是“聊天、支付或发朋友圈”等。
用例通常会用一个椭圆形表示：
执行者/角色：即是扮演着某个角色的用户或系统，执行者通常版扮演者对于产品或系统来说有实际作用的用户或其他系统。
在UML中，执行者的图示如下：
系统边界：展示了系统的内外之分，明确的划分了开发过程中需要关心和不需要关心的边界。系统边界的图示：
泛化：执行者之间可以有泛化关系，泛化关系可以简单理解为继承关系——比如：职员拥有“申请开票”功能，经理拥有“申请开票、审核”功能，那么经理类就可以是职员类泛化生成的。用例之间也会具有泛化关系，比如“筛选用例”可以泛化出“按播放量”和“按订阅数”的用例。
泛化通常是子类指向基类：
关联：执行者与用例之间，只能有关联的关系。
关联用来连接执行者和用例：
扩展：扩展是用例与用例之间的关系，指的是一个用例的扩展功能——比如：“登录”用例的扩展用例是“忘记密码”，这个“忘记密码”功能不一定会使用。
扩展一般使用extend表示（注意箭头方向）：
包括：区别于扩展，包括指的是一个用例内，包括的子用例——比如：“角色管理”用例包括“创建角色”、“查询角色”等用例。
包括使用include表示（注意箭头方向）：
用例图范例：
（3）用例图的使用场景
用例图表达的是：什么角色通过软件系统能做什么事情？
从用户的角度描述了系统的功能，并指出各个功能的执行者，强调用户的使用者，系统为执行者完成哪些功能。因此，我们可以使用用例图系统地表达软件系统的绝大部分功能性需求。
（4）推荐指数
用例图通常应用在需求分析，和产品或系统的功能描述与定义上。因此，对于需求分析与描述是至关重要的，推荐指数：★★★★★
3. 序列图
（1）什么是序列图？
序列图也叫顺序图，序列图最主要的目的就是表达对象与对象之间是如何沟通与协作的。
用例常常被细化为一个或者更多的序列图，同时序列图更有效地描述如何分配各个类的职责以及各类具有相应职责的原因。
（2）序列图的画法
序列图涉及到的几个重要元素：
对象：在序列图中，每个参与部分都是对象。在序列图中，主要是以“对象名称”的方式来表述。
图示：
消息：对象与对象之间只能通过消息来进行联系，消息可以理解为对象的某一个操作。消息分为同步消息、异步消息和自关联消息，同步消息需要同步等待消息。
图示为：
异步发送消息时不需要等待，图示为：
自关联消息是对象给自身发送消息，图示为：
生命线：对象是有生命周期的，因此对象必须在其生命线中才能彼此交换消息。
序列图中生命线的图示如下：
约束：是对象与对象之间进行消息交互式的约束条件，也就是要完成此次消息交互必须需要的条件约束。
约束通常使用“[]”表示，图示：
注释：一般是对象行为的解释性内容，图示为：
序列图范例：
（3）序列图的使用场景
序列图强调了角色/对象之间的交互，信息传递是非常明确的。当流程内涉及到多种角色或对象，并且会经过这些角色或对象展开交互，并且会有信息进行传递时，顺序图就会派上用场了。
比如：在用户网购时，就会涉及到譬如“用户、平台、订单中心、支付平台”等对象之间的交互。
再比如：小程序内基于微信支付的支付业务，也会用序列图来进行描述。
（4）推荐指数
在分析对角色或对象之间的交互时，会使用到序列图进行分析交互过程。序列图通常会搭配活动图和用例图进行使用，我个人还是比较喜欢序列图的，所以推荐指数：★★★★★
4、状态机图
（1）什么是状态机图？
状态机图从某个对象的状态是如何变化的角度来展示流程的，是一种由状态、变迁、事件和活动组成的状态机，用来描述类的对象所有可能的状态以及时间发生时状态的转移条件。
（2）状态机图的画法
状态机图涉及到的几个重要元素：
起始状态：在一个状态机图里，只能有一个起始状态，这一点类似于活动图。
起始状态的图示：
结束状态：结束状态代表整个状态到此活动结束。在一个状态机图中，可以有多个结束状态。
结束状态的图示：
状态：状态显示了状态的变化。
图示为：
复合状态：指的是某个状态内包括其他的状态组合。
例如：
迁移。状态之间使用迁移表达期间的关系，图示为：
警戒条件：如果某个状态需要在某个特殊的条件下才可发生，可以在迁移条件上标注警戒条件。警戒条件用一个“[]”表示。
状态机图范例：
（3）状态机图的使用场景
在产品的需求分析中，如果一个流程是围绕某一事物/对象的状态变化而展开时，我们应该优先使用状态机图。
比如：常见的订单流程就可以使用订单的状态图来表示订单对象的流程。再比如，在请假系统中，请假条的状态变化流程也可以用状态机图来进行分析。
（4）推荐指数
状态机图通常会搭配活动图、用例图和序列图来共同使用，方便分析事物或对象的状态变化过程，在需求分析与设计阶段也会用的到。推荐指数：★★★★
5. 类图
（1）什么是类图？
类图其实更加的贴近于开发，一些UML的工具可以通过类图直接生成代码。我理解的类图，是根据之前的用例抽象而成的，一个用例往往就是一个类。类图描述了类的内部结构和类和类之间的关系。
对于类，一些没有面向对象基础的同学可能很不好理解，其实类就是对一些业务对象的抽象。
以游戏为例：在穿越火线游戏中，枪可以是一个类，那么AK、43等型号的枪可是继承于“枪类”的泛化类。再比如，人是一个类，男人和女人就可以是继承于“人类”的泛化类。
通过学习编程我了解到，类也可以是数据表，表中的字段就是这个类的属性。
（2）类图的画法
类机图涉及到的几个重要元素：
类：图中最重要的就是类，类是由名称、属性和操作组成。属性可以简单理解为这个类包括的字段，操作就是该类可以实现的方法。
图示如下：
类图中最为重要的，就是类之间的关系，UML类图中有六大关系。
关联关系：类与类之间最基本的关系。关联表达了两个类的对象之间的结构性关系，比如老师类与课程类之间有一个关联，那么就代表着一个老师一定会管理着一个学生（一对一家教或多对多的学习）。
关联的图示：
泛化：在用例图中我们介绍过泛化，同理，类与类之间的泛化关系也可以理解为继承，也就是特殊类与一般类之间的关系。泛化图示，通常为子类指向基类：
实现：是一种类与接口的关系，表示类是接口所有特征和行为的实现。可以理解为，类通过接口实现了什么功能。
实现的图示：
依赖：是一种使用关系，比如司机使用汽车。
依赖的图示：
聚合：是整体与部分的关系，且部分可以离开整体而单独存在。如车和轮胎是整体和部分的关系，轮胎离开车仍然可以存在。
聚合的图示：
组合：是整体与部分的关系，但部分不能离开整体而单独存在。如公司和部门是整体和部分的关系，没有公司就不存在部门。
组合的图示：
类图范例：
（3）类图的使用场景
类图显示了类、类的方法、类的接口以及它们之间静态结构和关系。运用类图可以理清业务概念以及它们的关系，能更加深入地剖析系统/产品业务。
类图可能不容易上手，使用类图时，尽量从用例图出发，每一个用例抽象为一个类。类图可以初步用来梳理概念性的内容，比如：在理清订单概念时，订单都会涉及什么字段（属性），订单与其他对象类之间的关系如何，订单类可以提供哪些方法等。
（4）推荐指数
相较于上述几个行为型的UML图，类图在使用上不是那么的好上手，对于有面向对象编程基础的同学比较好理解，但是个人觉得类之间的这些关系在梳理业务概念时还是很有用的。
推荐指数：★★★
6. 其他UML图
在上面介绍类图中，说到了活动图、用例图、序列图和状态机图都属于行为型的UML图。那么，UML图为什么会分为结构型和行为型两种呢?
结构型的图描述的是某种结构，这种结构在某段时间内应该是稳定的，“静态”的；而结构型的图描述的是某种行为，是“动态”的。
分析系统需求时，我们会面对很多业务概念，它们之间会有某些关系，这些内容可以看成是“静态”的，我们可以利用UML的结构性的图来分析，比如上述的类图。
同时，业务会涉及大量的流程、过程等，这些内容是“动态”的，此时就可以用行为型的UML图来分析，比如活动图、用例图、序列图和状态机图。
行为型的UML图除了活动图、用例图、序列图和状态机图，还包括通信图和时间图。结构型的UML图除了类图，还包括对象图，包图，组件图和部署图。
（1）通信图
通信图其实和序列图表达的是同一件事，并且通信图和序列图在一些UML工具中二者是可以相互转换的。在涉及多对象或系统的交互描述时，序列图会比通信图更加明确。所以，在需求分析与设计阶段，几乎不会用到通信图，有此方面的需求使用序列图就可以了。
通信图范例：
（2）时间图
时间图是表示某对象或系统的状态随时间变化而变化的一种图，如下图是一个ATM操作的时间图：
时间图是UML2.0新增加的一个图形，从图中可以看出时间图的重要元素包括：生命线、状态、时间轴、时间线和事件。
在需求分析与设计阶段，用到时间图的情况几乎没有。
（3）对象图
在面向对象的编程中，对象是由类实例化得到的。对象图和类图的样子很相似，对象是类的实例化，“person : Person”表示对象person是类Person的实例。
对象图往往只在需要描述复杂算法时才会使用，画出来的对象图往往不会只有一个对象，该图只画了一个对象，其目的是尽量简化以便读者的理解什么是对象图。
在需求分析与设计工作中基本上不需要使用对象图，通常会用类图完成相关工作。
（4）包图
包图是一个高阶的UML视图。包图的主要用途是“打包”类图。用类图描述业务概念时，很多时候会因为业务类太多，而导致类图非常庞大，不利于阅读，这时可以将某些类放入“包”中，通过包图来组织业务概念图。
如下图所示，包图包括的元素有包、命名空间（在包的下方加入一个用小括号表达的说明方式）和依赖关系。
包图在需求分析与设计阶段很少会使用到。
（5）组件图
组件图也叫构件图。一个软件往往是由很多“物理部件”(如：控件、重用构件等)组成的，构件图就是用来描述软件内部物理组成的一种图。
如下图所示，组件图涉及的元素包括组件、提供接口、需求接口和依赖关系。
在需求分析和设计工作中，需要用到组件图的情况不是很多，除以下情况：
待开发的系统需要与第三方的系统、原有系统、某些老系统等交互，这时可用构件图描述交互要求。
客户对软件设计有某些特殊要求，这时可用构件图来描述要求。
构件图有时不会单独使用，还会和部署图一起结合使用。
（6）部署图
部署图是用来描述系统如何部署、本系统与其他系统是怎样的关系的一种图。
从下图可以看出，部署图包括的要素有：节点（代表某个物理资源，如存储设备或计算机）、组件、关联关系和依赖关系。
在为客户开发项目时，有的客户场地会具备一定的IT基础环境，比如：局域网、服务器等。我们的系统需要基于当前的IT环境来进行规划和设计，比如：电视台的客户，通常都会有自己的服务器和数据库，是不允许外网访问的。此时就可以使用部署图来描述IT环境。
分析系统软件的需求，不能忽略系统架构、部署、IT架构等方面的要求，我们要基于客户当前的IT基础环境，做出一个最符合客户利益的规划设计。
组件图和部署图的应用，通常需要具备一定的IT技术架构以及软件设计知识。在业务需求分析与设计阶段更多的还是分析业务，提炼功能需求，用到组件图和部署图的情况还是比较少的。但是，作为有抱负的青年，我还是希望自己能逐步积累，慢慢了解IT架构方面的知识。
四、总结
本文我们总结了一些在需求分析与设计阶段会常用的到的UML图，并且对每一个UML图进行了详细讲解。对于那些我觉得不太会常用到的UML图就没有做过多的表述。希望可以利用好UML图，让UML图成为支持我们工作的得力助手。
系统学写了UML后，对比自己之前项目中绘制的一些流程图，确实不是特别的规范。在未来的项目中，我打算要充分利用好UML了。
最后推荐给大家绘制UML的工具——ProcessOn，用着还不错~
