UML的浸染域不限于支持面向工具的剖析与设计，还支持从需求剖析开始的软件开拓的全过程。UML被运用到面向工具的问题办理上，面向工具的问题处理的关键是建模问题，建模可以把繁芜业务的许多主要的细节给抽象出。不仅可以借助于UML来完成与用户的需求沟通，而且可以辅导程序员进行开拓。
UML分构造图和行为图，构造是静态的，它描述构造元素构成的系统或函数，显示构造或运行时体系构造的静态关系，比如类图、工具图、构件图、支配图、包图。行为是动态的，它描述一个别系或业务过程的行为特色，显示动态模型的视图，比如活动图、状态图、顺序图、通信图、用例图、时序图。
每种图形都是从需求或设计的不同层面来描述模型，通过各种模型描述系统的类、工具、关联、职责、行为、接口、用例、包、顺序、协作，以及状态，以便产品经理通过图形化的办法从各个角度理解产品，更好的表达思想，便于互换。
常用的UML建模工具有：ProcessOn、Enterprise Architect 、Visio、StarUML、OmniGraffle、ArgoUML。常见的UML建模有：业务建模、需求模型、设计模型、实现模型、数据库模型。UML建模重点不在于如何画UML，而是如何利用UML思考办法去管理好一个产品。
UML各种图都适用于不同的场景，可从不同角度诠释产品。因侧重向产品经理角度谈UML建模，以是只先容用例图、状态图、活动图、时序图与类图。
一、用例图（UseCase Diagram）
用例图从外部不雅观察者的角度描述系统的浸染。它描述了系统的功能哀求，利用者浸染于系统边界的方法以及系统的反应。
参与者便是与运用程序或系统进行交互的用户或系统；用例便是外部可见的系统功能，对系统供应的做事进行描述；子系统用来展示系统的一部分功能，这部分功能联系紧密。以某电商系统的客服为例，在设计用例的时候，一样平常是按用户角度从Uc级描述统功能，并指各功能的操作者。比如她紧张卖力的功能有查看数据，查看用户，管理订单和分配客服，我们就可以一种可视化的办法设计系统的功能需求，实质还是扩展功能的增编削查。
二、状态图（State Diagram）
状态图由状态、转换、事宜和活动组成，描述类的工具所有可能的状态以及事宜发生时的转移条件。常日状态图是对类图的补充，仅需为那些有多个状态的、行为随外界环境而改变的类画状态图。
它定义了一个工具，这些状态掌握外部或内部事宜的不同状态，也可以奉告一个工具可以拥有的状态，并且事宜会若何随着韶光的推移来影响这些状态。根本便是阐明在其生命周期的韶光和状态图是用于此目的的一个工具将知足某些条件、实行某些活动、等待某些事宜。
以某共享充电移动端为例，客户完成扫码充电的订单工具的生存期间的状态序列，引起转移的事宜，以及因状态转移而伴随的动作。从扫码充电订单状态从待支付，已支付到已退款都是一个完全的业务闭环。
但实际运用中并不是所有的类都须要画状态图，有明确意义的状态，在不同状态下行为有所不同的类才须要画状态图。
三、活动图（Activity Diagram）
活动图是一种表述过程基理、业务过程以及事情流的技能，直白点便是使事情流和业务过程可视化的图。它描述活动的顺序，展现从一个活动到另一个活动的掌握流，有利于识别并行活动。
动作状态便是指原子的，不可中断的动作，并在此动作完成后通过完成转换转向另一个状态；动作流便是动作之间的转换称之为动作流；节点紧张有开始节点、终止节点、分支节点与合并节点，实质都是对流程的约束。以某业务系统为例，客户完成项目外包的这一活动过程中，分别是用户下单，选择做事，供应做事这三方面完成流程的转换，实在便是侧重从行为的动作描述。
四、时序图（Sequence Diagram）
时序图是一种强调韶光顺序的交互图，它通过描述工具之间发送的韶光顺序显示多个工具之间的动态协作。时序图具备了韶光顺序的观点，供应了掌握流随着韶光推移的清晰的可视化轨迹，从而可以清晰地表示出工具在其生存期的某一个时候的动态行为。
生命线是一条垂直的虚线，从工具底部延伸出来的，表示时序图中工具存在的韶光；掌握焦点是时序图中表示韶光段的符号，在这个韶光段内工具将实行相应的操作；显示为箭头，可以完成传输，也可能丢失和找回，它可是同步的，也可是异步的，即可以是调用，也可以是旗子暗记。以某H5商城网站为例，用户通过或扫描二维码在微信内打开网页时，可以调用微信支付完成下单购买的流程。
五、类图（ClassDiagram）
类图是一种静态模型，它通过显示出系统的类以及这些类之间的关系来表示系统。类图是静态的，可以展现软件系统中的类、接口以及它们之间的静态构造。类之间关系紧张有泛化，实现，关联，聚合，组合与依赖。
类是工具类型的表现形式，反响出这类工具在系统内的的构造和行为；接口是履行者须要知足的行为规范；包是一个命名空间，也是一个元素。以某共享推拿系统为例，我们可以直不雅观的开出公司、司机、车辆、设备、业务员之间的对应关系。比如一个公司对应多个车辆，一个车辆又对应多个推拿设备，理清他们之前的构造关系就可以快速理解业务逻辑和完成表构造设计。
UML在全体软件开拓过程中，办理了“一盘散沙”的问题，在海内不少地方得到了运用。作为产品人，学习UML必须从模型的建造开始，一个萝卜一个坑的去将UML建模实践到产品中，不断历练自己，才能真正的学有所成。当我们把UML建模措辞下的各图形都有所理解后会创造，通过这些图可以全面的、立体的从各个角度表达产品，让产品的表达变得更丰富、更形象。
对付产品经理而言，闇练节制UML有助于梳理业务流程和传达产品需求。产品经理不仅要深挖前端业务流程，还要理解看不见的后端实现逻辑。
很多产品在敏捷开拓和版本迭代阶段，产品经理很随意马虎忽略产品的隐性特性，对产品的核心功能无法深挖或理解，导致履行中还在谈论需求，上线后各种Bug影响产品体验，紧张是短缺对后端整体功能的统筹与把控。而UML的涌现，让PM拥有一套与技能职员沟通的共同措辞，在事情中需求对称就会变得更顺畅。
本文由 @PMLink 原创发布于大家都是产品经理，未经容许，禁止转载。
题图来自 Unsplash，基于CC0协议。
