| 版本 | 日期 | 修订人 | 描述 |
|---|---|---|---|
| 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建模》------ 电子工业出版社
最后
小弟不才，学识有限，如有错漏，欢迎指正哈。
如果本文对你有帮助，记得"三连"（"点赞"、"评论"、"收藏"）哦！