一 哪些 UML 图需要画

1 大中型系统都要画

对于大中型系统，用例驱动设计、流程驱动设计、领域驱动设计的方法都可使用，并辅以状态图来梳理业务的具体操作。比如，一个银行系统用用例驱动设计的方式，梳理出贷款功能、开户功能、存取款功能。然后，再用流程驱动设计的方法，梳理贷款审批的流程，并辅以状态图梳理出关键的操作。最后，再用领域驱动设计的方法，梳理后台贷款信息的组织和展现。

在采取了以上方法后，对应的 UML 图是否要画呢？对于一项复杂业务，流程图、状态图和类图都应画出，这样表达也很清晰。用例图则可不画，用思维导图代替即可，我们主要用的是用例的思路。

2 中小型系统建议画 

首先，如果业务不复杂，就可不画。如果流程图和状态图都很简单，那么就可以不画。但前提是，产品经理要能做到纸上无图，心中有图。也就是说，在脑中有图，即使不画图，其文档也没问题。

其次，还要看研发人员的需求。因为虽然产品经理自己明白了，但是研发人员也要通过看图，来理解业务并设计软件。所以，如果研发人员需要，就应画一下。

二 UML 的成就和问题

UML 因为内容全面而被业界广泛认可，也因为过于复杂，而被专家和从业人员批评。但是复杂不是 UML 的错，UML 仅仅是一种语言，如何使用它关键在于人。

1 UML 因表达全面而应用广泛

UML 的目标是应用在各行各业，所以必须全面和复杂。也正是因为全面，UML 才会被 ISO 所接受。对于 UML 而言，不仅可以用在软件行业中，还可用在非软件行业中，并且系统越大、越复杂，效果就越好。

UML 可以用在银行系统、电力系统、医疗电子软件设计中，或用在法律部门的工作流、战斗机飞行系统及通信设备的设计中。

2 UML 因过于复杂而饱受批评

虽然 UML 的复杂有其道理，但其因为过于复杂而饱受批评。

业界的主要批评是，UML 过于庞大和复杂，以致于人们很难熟练掌握它，并很难有效应用它。而 UML 的有些概念也很少使用，一些概念间只有细微的差别，找到这些差别又缺乏现实意义。另一种意见是，UML 应定义一个精炼的核心，只提供最常用的建模元素。但这个目标没有实现，UML 仍然很复杂。

3 复杂是必须的，用好用坏在于人

虽然 UML 的一些表达有一定的问题，如用例的包含关系和扩展关系的划分，但 UML 的复杂是必须的，因为 UML 是一种语言。

但是，UML 的规定的确多，导致其难以掌握和有效运用。因此，我们只需要学习部分内容，并且要多学如何用。只有这样，才能更好地梳理业务、设计业务。同时，也应把 UML 图和文字描述结合起来，让它们发挥各自的优势。

三 UML 的学习误区

1 认为没必要深入学 UML

如果要做一个小系统，无论是产品经理还是研发人员，都不太需要用 UML。但如果要做一个大系统，或者要把小系统做的游刃有余，则产品经理和研发必须掌握 UML。这也是做过较大系统的产品经理和研发人员的共识。

比如，我们可用用例图梳理出业务范围、定义出功能模块。我们还可以用流程图梳理业务流程，用状态图梳理操作，用类图梳理后台管理等。这些都是好的思考习惯。同时，运用结构化的思考模式，产品经理能把业务想得周全，并有利于对外沟通和对内表达。

2 认为 UML 要学全、用全

学全，用全大可不必。如果都学会固然是好的，但如果花了大量时间去学知识却很少得到应用，这样就失去了意义。

四 UML 图的分类

1 结构事务

第一类：基本结构

类图、对象图、部署图

第二类：体系结构

构建图、组成结构图、包图、扩集图

2 行为事务

第一类；基本行为

用例图、活动图、状态图

第二类：交互行为

顺序图、通信图、定时图、交互图