《图解产品 产品经理业务设计与UML建模》读书笔记

版本	日期	修订人	描述
V1.0	2025/3/15	nick huang	创建文档

背景

在企业级信息系统开发中，业务是一大难点。
最近在想，如何更好地理解和整理我们系统的业务。
阅读了一本书，与之稍有关系 —— 《图解产品之产品经理业务设计与UML建模》。
讲的是「产品经理对设计产品的过程」以及「过程中如何更好地使用UML进行建模」。
与我们更好地理解和整理业务，或许有一些帮助。
本文记录书本如何使用UML更好地理解和整理业务的笔记，对设计产品过程的技术会轻微带过。

产品经理对设计产品的过程

业务，是指由用户发起，并由系统执行的有结果的商业活动。
以业务为中心的设计，就是要思考一项业务要如何设计。为此，我们结构化地把业务设计分成了四层九要素。

由于本文主要想了解如何使用UML更好地理解和整理业务。
其中在以下环节会使用到相应的UML图：
1、功能框架 —— 用例图
2、业务流程 —— 流程图 / 活动图
3、业务操作 —— 状态图
4、信息结构 —— 类图、ER图

功能框架 —— 用例图

搭建功能框架的目的：厘清业务有什么功能，而不考虑小的功能点。
从另一个角度说，搭建功能框架，是要厘清业务宽度，而不是业务深度。
通过厘清业务宽度，产品经理就可避免功能的遗漏。

厘清业务宽度，很适合使用用例技术进行分析。
用例技术，是一种有层次和有步骤地找到功能的方法。该方法从使用者的角度，思考用户要用系统做什么，从而再梳理出功能。

用例，是对参与者发起的一组动作的描述，系统相应该组动作，并产生可观察到的显著效果。
简单来说，用例就是表述一件事，这件事是“用户在系统上做了什么”。

用例的表述为“动词+宾语”
1、动词：指的是用户做出的动作
2、宾语：动作的对象
比如：申请贷款、审核贷款

有宽度、有层次地梳理业务

要有宽度地梳理业务，就要有层次地进行梳理，要不断把大的需求有层次地拆解成小的需求。
用例是可以分层的，我们可以把用例分为目标层用例、实现层用例、步骤层用例。
一、目标层用例
目标层用例，要从目标和用例两方面理解。
目标，是用例使用系统的理由，或要达到的效果。
用例，是指用例实际做的一件事。
既然是目标层用例，那么表示的事务既是目标，也是用例。

例子
购买商品：这个是目标层用例，因为它是我使用这个系统的理由，也是我想要做的事情。
而我为了“购买商品”而做的一些用例，如登录系统，加入购物车、付款，都不是目标层用例。

目标层用例的判断，有一些技巧：
1、用户在做完这件事后能满意地离开
2、员工工作职责

例子
一个客户来到银行营业厅，办理一项业务。
银行柜员作为系统用户，使用系统来完成业务（也是“员工工作职责”），这个属于目标层用例。

二、实现层用例
为实现用户的目标层用例，产品经理就要定义产品如何实现，这个实现方法被称为实现层用例。

例子
用户注册系统，实现方式可以分为两个：
手机号注册
微信快速注册

注意：实现层用例可以跳过
区分目标层用例和实现层用例是一个好习惯，这有助于产品经理思考为满足业务目标有哪些可选方案。
但这种区分不是必须要做的。

步骤层用例

无论实现层用例是什么，都需要系统来实现。用户使用系统的过程，就是一步一步地操作系统的过程，这就是步骤层用例。

例子
订外卖，这个目标层目标，可以拆分为以下3个步骤层用例：
1、选择菜品
2、提交订单
3、支付订单
其中，提交订单，这个步骤层用例，还可以继续拆分为：
1、设置收货地址
2、选择优惠券

业务流程 —— 流程图 / 活动图

一项业务是有流程的，而不是无规律乱跑的。
在做细节的三大要素中，第一要素就是梳理业务流程。在梳理业务流程时要用到流程图。

用例方法是为了扩宽度，不是为了扩深度。所谓的深度，是指异常的情况和分支的情况。
流程图的作用就是梳理业务，包括业务的主主流程、分支流程和异常流程等。

在UML标准中，流程图被称为活动图。流程图和活动图之间没有本质的不同。

UML的发明者在《UML用户指南》：
一个活动图在本质上是一个流程图，展现从活动到活动的控制流。与传统的流程图不同的是，活动图能够展现并行和控制分支。

流程图，是为了完成某一特定任务而描述的相关活动，以及这些活动的执行顺序的图形化表示。
关于这个概念，我们要理解活动和执行顺序的含义：
1、活动
活动，是对一组动作的描述，这组动作可以是用户做的，也可以是系统做的。
2、执行顺序
执行顺序，强调几个活动之间要有明确的顺序。

活动名称采用“主语+动词+宾语”的写法。
简写就是“动词+宾语”，主语省略，也就是省略了用户作为主语。

Tips
在UML标准中，没要求活动必须加入主语，但我们建议加入主语。
加入主语后，可让读者明晰谁做了这个事情。

流程图的按层分类

流程图的运用非常灵活，常因为应用广泛而导致出现许多问题。
比如，有的产品经理画的流程图，既表达业务分析，还用于指导原型图绘制，然后还告诉研发人员如何开发。这就显得很凌乱。
所以，可以对流程图进行分类：业务流程图、交互流程图、实现流程图。

一、业务流程图
业务流程图表达的是人和人之间的交互，目标是厘清和设计业务。

例子：发票配送
发票配送的流程图，人和人之间的交互：
1、财务人员开具发票
2、物流人员配送发票
3、用户接收发票

业务流程图绘制的原则：
1、手递手的人人交互
手递手的人人交互原则，即强调一个人做了一个活动，后面紧跟着另一个人的活动。
而不是在一个人的多个活动后，再跟着另一个人的一个活动。

2、去掉页面交互
3、去掉系统实现

二、交互流程图
交互流程图表达的是人和机器之间的交互，目标是指导原型图的绘制。
人和机器间的交互可以理解为用户输入信息，系统反馈信息。

交互流程图的绘制原则：
1、涉及规则的步骤要画出来

例子：用户注册
用户输入“手机号”后，系统会做一系列规则判断（如手机号长度、手机号是否已注册），然后各个规则引导到不同的交互上。

2、手递手的人机交互
我们在讲解业务流程图时，讲过手递手的人人交互原则，即强调一个人做了一个活动，后面紧跟着另一个人的活动。
对于交互流程图，手递手人机交互原则，即强调在用户做了一个活动后，系统必须紧跟一个反馈。

三、实现流程图
实现流程图，表达了系统在做什么，目标是设计软件，一般由技术人员负责绘制。
书本主要讲解产品经理业务设计与UML建模，对于技术层面的实现流程图，因相关性不大，描述篇幅较少。

业务操作 —— 状态图

做细节三大要素中的第二个要素是业务操作，在梳理业务操作时要用到状态图。
流程图梳理的是一项业务的大致过程，状态图梳理的是一项业务的细致操作。

状态图，也被称为状态机图，描述一个对象所处的状态，以及用什么操作可促成状态的改变。

状态的注意点

状态图的表达方式有5种，非常简洁，但很容易被画错，我们要注意以下几点：
1、有对象才有状态
对象就是实际存在的一个事务，是对象就要有状态，并且状态只针对该对象。

2、表达“一个”对象
状态图用来表达对象的状态，并且一个状态图只能表达“一个对象”的状态。

3、不可有菱形标志
流程图用菱形来表达判断或分支，状态图在有的资料中也有菱形，但这不是主流。因为不加入菱形标志，将使状态图的表达更简洁和无歧义。

信息结构 —— 类图、ER图

做细节三大要素的第三个要素就是信息结构，要梳理信息结构，就要用到类图。
无论流程图还是状态图，梳理的都是业务的动态行为，而类图梳理的是业务的静态结构。
用了类图后，就能厘清信息之间的结构关系。

除了类图，用ER图（实体关系图）也能表达信息关系。
类图和ER图存在一定的转换关系，但类图能表达更丰富的内容。也就是说，类图可以代替ER图，但ER图代替不了类图。

UML发明者在《UML用户指南》：
UML中的类图是ER图的超集。传统的ER图只针对数据建模，类图则进了一步，它还允许对行为建模。

注意
因为技术人员本身常使用面对对象编程、数据库表设计和ER图，本章节内容内容跳过较大篇幅。
虽然较常接触上述内容，但还是仅仅使用类图表达数量关系、关联关系。
类图中其他的聚合关系、组成关系等，还是较少涉猎，后续补充上这部分内容。

快速带过设计产品过程的技术

这里将快速带过设计产品过程的技术，如果大家感兴趣，可以购买书籍阅读。
一、定方向

二、搭框架

三、做细节

四、画界面

参考书籍

• 《图解产品 产品经理业务设计与UML建模》—— 电子工业出版社

最后

小弟不才，学识有限，如有错漏，欢迎指正哈。
如果本文对你有帮助，记得“三连”（“点赞”、“评论”、“收藏”）哦！