2.3 UML的应用

2.3.1 UML的应用范围

1.UML的广泛应用

虽然UML的初衷是要解决软件设计的问题，但是UML的使用是跨领域的，既可用在软件领域，也可用在非软件领域，可以说UML是一个“野心勃勃”的标准。

在软件领域中，UML可用在银行系统、餐饮零售系统、电子商务系统、在线教育系统等软件系统的建模上；在非软件领域中，UML可用在餐饮服务流程、法律服务流程、医院的药品传送系统等流程和结构的设计上；在特殊领域中，UML可用于设计战斗机的控制系统、安全网关的软硬件系统。

在本书的12.2.1节中，我们用文字描述了线下餐厅迎宾人员的工作流程，虽然该流程和产品经理无关，但也可以用UML中的流程图（活动图）表达。因此，即使不做产品经理，学习UML也是有用的。

2.在软件领域中的应用

在软件领域中，我们可将UML用于分析业务、设计业务和构建软件。

分析业务：即梳理线下的业务流程，比如，在银行的贷款系统中，有哪些部门涉及贷款业务，申请贷款的审批流程是什么，以及还款逾期的处理流程是什么。

设计业务：在理解了线下业务后，产品经理就要设计产品，并编写需求文档，此时也要描述新的流程。比如，描述线上的贷款审批流程、分级的权限管理系统、贷款逾期的自动处理规则等。

构建软件：在描述清楚产品需求后，研发人员就要进行开发，这就需要描述软件系统如何实现，如模块之间的调用关系、模块之间的消息传递等。

总之，无论是分析业务、设计业务，还是构建软件，都是在描述一个系统，都可以用UML来描述。

2.3.2 UML的应用举例

2.3.1节介绍了UML的应用范围，2.3.2节将要介绍产品经理如何用UML。同时，我们知道产品经理要用UML设计产品，研发人员要用UML构建软件。常常有产品经理画了构建软件的UML图，这是错误的。所以我们也要了解研发人员如何用UML，避免画错。

UML图一共有14种之多，在第14章中，我们将介绍这些图。下面，仅对产品经理常用的UML图做介绍。通过了解这些内容，我们能对UML形成总体性认知。

1.产品经理设计产品

在以业务为中心的设计框架中，和UML关系密切的是功能框架、业务流程、业务操作和信息结构这四个要素，这四个要素都要用UML来表达。

1）功能框架

搭建功能框架的目的是梳理出大的功能，并且保证功能没有遗漏。这用UML的用例（Use Case）方法就可实现。通俗地讲，用例描述的是用户做了什么，是一种面向用户的思考方式。图2-1就是一个用例图（Use Case Diagram），该图描述了一个银行系统，该系统可实现个人用户的存取款、申购基金和申请贷款三项业务，这三项业务也是个人用户要做的事。

用例图描述了用户要做的事，在明确要做的事后，我们就可梳理出要实现的功能。与用例分析相关的概念有用例、参与者、系统、目标层用例、步骤层用例等，这些内容都是为挖掘功能而设置的。另外，用例的价值在于思考框架，而不在于画出用例图。在实战中，我们常用文字表达用例，而不是用用例图来表达。

2）业务流程

要梳理业务流程，就要有业务流程的表达方式。我们可以用文字表达，也可以用图形表达，其中图形的表达方式就是流程图。流程图在UML中被称为活动图（Activity Diagram），该图可以描述业务的流程。图2-2就是一个身份审核流程图，该图描述了审核身份的流程。此时，用户提交身份信息，然后客服审核身份信息，如果信息查验合格就可单击“审核通过”按钮。

虽然产品经理对流程图非常熟悉，但是该图也是标准混乱的一种图。产品经理如果学了不标准的流程图，出现错误是其次的，更重要的是会导致思路混乱，弄不清楚业务。和流程图相关的概念有活动、并行、合并、选择、泳道等。我们尤其应学习分层绘制流程图，这就要明确业务流程图、交互流程图等内容。这样就能确保画出的流程图简单、有效。

3）业务操作

通过流程图能梳理出业务流程，但是还要明确用户和员工的操作，这种操作是指在系统上进行的操作。要梳理这些操作，就要用到状态图（State Diagram），状态图描述了事务的状态，以及触发状态变迁的操作。图2-3描述了身份审核的操作。比如，在用户提交了身份信息后，身份信息就变成了待审核状态。此时，客服可以单击审核通过或审核不通过的按钮，之后身份信息就可变成其他状态。

状态图和流程图非常类似，但是作用不同，后面我们会做说明。和状态图相关的概念有状态、操作、锁定、角色等。状态图虽然简单，但能和前后台的操作按钮形成严格的对应关系，这样就能有效指导原型图绘制。

4）信息结构

信息结构表述了信息内容之间的关系。这种关系可以用类图（Class Diagram）来表达。图2-4就是一个订单的类图。该类图表明，一个订单可开0或1张发票，一个订单可支持多个物流配送，这表明了类间的数量关系，并且订单含有订单编号、下单时间等信息。

这些数量关系和信息内容，决定了前后台的展示和交互。和类图有关的概念有类、对象、数量关系、聚合关系、组成关系等。很多产品经理虽然不用类图，但是也要明确信息间的数量关系，这将影响到原型图的结构，这其实就是在梳理类。因此，学习类图将有利于厘清业务关系，保证考虑周全。

以上就是UML在功能框架、业务流程、业务操作和信息结构中的应用，当然，本书不仅讲如何画图，也讲实战的思路，从而有方法地梳理出业务。

2.研发人员构建软件系统

产品经理在做完系统设计后，还要绘制原型图，并将其汇总成产品需求文档。之后，研发人员就要进行开发。开发工作有两部分内容，分别是系统构建和代码编写。要进行系统构建，研发人员要用到UML中的用例图、流程图、状态图、类图等，这些也是产品经理要用的。同时研发人员还会使用UML中的顺序图、构件图、部署图、包图等，这些主要是研发人员用的。

无论研发人员使用什么图，都是为了设计软件系统。尤其是用例图和流程图，既可以表达业务是什么，也可以表达软件如何构建。下面，我们看看研发人员如何用这些图。

1）研发人员的用例图

和产品经理不同，研发人员绘制用例图的目的是明确模块之间的关系。图2-5所示是研发人员的取钱用例图，可分成四个模块，分别是取钱、验证卡、打印小票和退出卡，并且取钱模块“包含”验证卡和退出卡两个模块，打印小票“扩展”了取钱的功能。模块间的关系明确了，研发人员就能做进一步的开发。

2）研发人员的流程图

研发人员要用流程图表达软件系统是如何工作的，图2-6描述了软件系统如何实现用户的查询，这样的图产品经理是没必要画的。产品经理的其他错误有：① 将软件系统划分为前台和后台系统，然后表达系统间的交互。② 在图里表达该系统创建了订单或执行了查询等。研发人员表达这些内容有意义，产品经理表达这些内容就意义不大。

以上就是UML在研发中的应用。读者应了解研发人员和产品经理画的图的差异，并在后面章节中仔细体会。