产品经理必看:常用的UML建模详解

AI时代,如何更快入行抢占红利得高薪?前阿里巴巴产品专家带你15天入门AI产品经理。了解一下>

关于UML,我相信在做B端的产品经理一定知道它的重要性。那么UML常用的图都包含哪些呢?它们都在什么场景什么阶段使用?如何使用?这篇文章主要帮助小伙伴们解答这些问题。

一、UML的分类及用途

首先简单给大家介绍一下什么是UML,UML的全称是Unified Modeling Language。翻译过来就是统一建模语言。它对产品经理最主要的作用是用于需求分析中更好的梳理逻辑,同时能够提升沟通效率。

UML主要包括图表中的十一种,那在本次的介绍中,只讲解类图、构件图、部署图、活动图、状态机图、顺序图、用例图。

通常对业务概念等静态结构进行系统化的梳理和提炼,我们叫它结构建模。而于对业务流程等动态内容进行系统化的梳理和提炼,我们叫它行为建模。

而需求分析的核心目的是解决软件有没有用的问题,软件设计是解决软件用多大的成本做出来的问题,所以需求分析首要任务是保证软件的价值。

那么如何学好UML呢?其实UML的语法很简单,但是想要学好UML关键在于要改变思维习惯。要在平时多培养自己的书面表达能力、归纳总结能力、思维能力和抽象能力。

二、类图

装逼的讲,类图(Class diagram)是显示了模型的静态结构,特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。那它其实就是用来帮助我们识别出人、事、物和业务的概念,并理清它们的关系的一种方法。

2.1 类图的基础知识

在聊类图之前先让我们理清几个概念。

首先,什么是类?将某类东西归纳在一起就可以成为一个类。

例如,本文的读者,我们就可以分为初级产品经理,高级产品经理;或者分为产品经理和非产品经理;这些都可以叫做类。

然后,什么是类图?类图就是一个矩形的方框,上面是类的名字,中间是属性,下面是操作。

比如这篇文章的读者是产品经理,那产品经理的属性就有性别,年龄,级别等;如果要列举当然会有很多属性,但是我们只找出相关且对我们有用的属性。

那一般如何用类图获取需求呢?首先要识别出类。其次识别出类的主要属性。然后描述出类之间的关系,最后在对各类进行分析、抽象、整理。

2.2 类之间的关系

(1)直线关系

直线关系其实就是我们常说的关联关系,A关联B,如下图:

那如果在直线两端加上数字1,那就是1对1的关系,如下图:

同样,如果将B旁边的1改成*,那就是1对多的关系,如下图:

那如果将*改成0..3,那就是0到3的意思。如果是1..4那就是1到4的意思。下入就是1对0..3的意思:

如果把数字换成了上司和下属,那么他们就是角色关系了,就代表a是b的上级,b是a的下属。如下图:

如果把数字换成箭头,那就变成了导航关系,即由A可找到B,如下图:

(2)包含关系

包含关系有两种表示方法,一种是空心菱形,一种是实心菱形;空心菱形可以表示为弱包含的关系,实心菱形可以表示为强包含的关系。

弱包含关系即部门没有了,员工可以继续存在。强包含关系是部门没有了,员工也就不存在了。

以下图中表示的为,一个部门可以包含多个员工:

(3)继承关系

继承关系是谁继承了谁的属性。例如香蕉,苹果,葡萄他们继承了水果的属性,同时又拥有自己的属性。

我们用一个三角来表示,如下图:

(4)依赖关系

所谓的依赖关系,依赖程度是相对而言的,不一定是A没有B就不能生存了。

在实际的业务逻辑当中,对于某个事情,A需要B来协助完成,也是一种依赖关系,依赖关系使用虚线箭头表示。

2.3 类图的进阶

(1)递归关系

我们常用的电脑系统中,如果用类图表示出文件夹与文件的关系,那么该如何表达呢?是文件夹包含文件吗?那文件夹和文件夹的关系呢?

使用递归关系,我们就可以更好的表达出来。

递归关系分为自包含和自关联,和字面的解释一样,就是自己包含自己,自己关联自己。

下图分别是自包含和自关联:

(2)三角关系

当某些属性值并不是由该类本身就可以确定的时候,我们可以使用三角关系;

例如员工的薪资,职位等,并不是由公司可以确定的,而是由劳动合同来确定的,那么我们的表达方式如下:

三、活动图

活动图是用来表达流程最常用的一种UML图,它和流程图很类似。

3.1 基本语法

(1)基础流程图

流程中一般只有一个开始,会有一个或多个结束。箭头表示流程的走向,一个圆角矩形表示一个活动,活动可以理解为流程中的一个步骤,需要用主动宾的形式来表达。

例如员工填写工时,项目经理审批工时。菱形代表判断,会有两个或两个以上的分支。

判断一般有三种表达方式:在判断菱形旁写下判断的句子;直接通过监护来表示这个判断;在菱形判断之前加一个活动来表明判断动作。

分支流程汇合时,也会使用菱形,然后会合并成一条路线。如下图:

(2)泳道图

上面的流程图当中,如果流程简单,那么就可以很好的表达,如果流程很长,涉及到的角色很多,且很复杂时,看到就会非常乱,不止画的人觉着乱,看的人也会感觉很乱。

那么,这个时候我们就可以用泳道图。

泳道图一般是会按照角色进行分区,那么在画和浏览时都非常清晰。如下图:

3.2 活动图的进阶

(1)并行的活动

当遇到需要并行的活动或分支时,我们可以使用粗短棒。

短粗棒会有两个同时出现:第一个是有一个箭头指入,多条箭头指出,这个叫做分叉;第二个是多条箭头指入,一条箭头指出,这个叫汇合。如下图:

(2)对象流

当我们用矩形框来表示某个节点,并将矩形框的文字标注下划线,那它就代表对象。

每个活动都有可能有一个或多个输入或输出,与输入输出直接相连的箭头叫对象流,而活动和活动之间相连的叫控制流。

如图:

(3)连接件

有的时候活动图很大,一张纸画不下,我们可以使用另一张纸继续画,这个时候,我们可以使用连接件(其实现在的画图软件大多都不会出现这种情况)。

如下图,左边的图是箭头指向A,则是活动图到这里转向另一张图;右边的图是A指出一个箭头,表示从A开始继续这个活动图:

3.3 关于活动图的其他问题

对于活动图的粒度是如何控制的呢?其实这个是没有标准答案的,下面只是一些实践建议。

  1. 首先要清楚活动图要表达什么内容,表达的重点是什么,以此来确定合适的粒度;
  2. 其次,可以先用粒度比较大的活动图,大致搞清楚流程的总体情况;
  3. 最后在逐步细化,需要重点说明的部分,活动的粒度应该足够细,足够说明问题。

那如何画好活动图呢?

  1. 建议你一个活动图只表达一个事情,同时在画之前要明确该流程要达到怎样的业务目的、有什么角色参与、哪些是主要角色;
  2. 先画出主流程,明确主流程中涉及到的角色,然后在逐步增加分支流程,这里主要表达出关键的分支即可;
  3. 同时异常流程也不用全部表达出来,必要的时候,可以用文字来说明;控制好粒度,然后分别画出当前的流程和优化后的流程。
  4. 对照差异,整理出需要调整的地方。

四、状态机图

状态机图其实和大家常说的状态图是一个东西,只是它的专业名称叫做状态机图。

4.1 基本语法

状态机图的开始状态和结束状态与活动图的一致,活动机图用一个圆角矩形来代表一个状态。

与活动图不同,活动图是用圆角矩形代表一个活动,而且状态机图一般使用名词或形容词来表示某种状态。

如下图:

4.2 其他问题

关于状态数量的问题:在使用状态机图时,若流程不合理,可以考虑通过增加、减少、修改状态来完善。

增加一个新的状态会解决很多问题,但是也会增加流程的复杂度,可能会出现其他问题。

关于状态图的实践会有一些建议可供大家参考:

  1. 流程围绕某一事物开展时,可以考虑使用状态机图来分析;同样也需要弄清楚它的目的,参与的角色,以及这些角色是如何推动流程的发展;并且列出流程中存在的问题;
  2. 同时要考虑事物在流程不同阶段有什么变化,然后列出当前的流程,再根据流程的目的和存在的问题进行调整。

五、顺序图

当流程设计到多种角色,并且通过多个角色交互展开时,顺序图是不二选择。

5.1 基本语法

角色可以用一个小人的图标来表示,下面写明角色。也可以用一个矩形来表示,但是需要在矩形里面说明角色。

生命线是角色下面的那条虚线,激活框也叫会话,是生命线中细长的矩形。

消息用箭头表示,并在上面说明做了什么事情;箭头可以从A指向B,也可以指向自己。

返回值用虚线箭头表示,并在上面说明返回的内容,一般是反馈某个东西给相应的对象。

如下图:

5.2 顺序图的进阶

循环分支属于业务流程中比较常见的特殊结构。

  1. loop,也叫循环,是满足循环条件的前提下,不断地重复做某些事情;
  2. alt,条件分支,是根据不同的条件选择不同的分支;
  3. opt,可选分支,是满足一定条件则执行该分支,否则就跳过。

如下图:

上图的流程中,loop,中括号内是循环条件的内容,表示如果满足循环条件,则重复执行本框的内容;alt,如果满足条件1则执行上半部分,如果满足条件2则执行下半部分;opt,如果满足条件,则执行框中的内容,否则跳过。

5.3 其他问题

关于顺序图使用的一些建议:

  1. 先从复杂的业务中整理出一条一条的流程,然后分析参与的角色,角色担任的职责和专业特色。
  2. 然后在将流程分解成角色与角色的交互,想清楚各个角色之间是如何交互的,用顺序图把它组织起来,在这个过程中要不断的进行优化。

活动图,状态机图和顺序图,被称为流程分析的三大利器,那么每种图都有不同的特点和应用场景。

  1. 顺序图,强调角色之间的交互,强调按时间顺序分别发生了什么事情,不太适合表达复杂的特殊流程;
  2. 活动图,强调每个角色做了什么事情,这些事情的先后关系,适合表达各种特殊流程,如分支,并发等;
  3. 状态图,主要是事情围绕某东西开展,并且有不同的状态。

那么在实际工作中如何选择呢?

通过上面说明的特点我们可以很清楚的知道。如果事情围绕某个东西开展,就可以考虑使用状态机图。

如果不是,则可以考虑顺序图或活动图;如果没有复杂的特殊流程,可以考虑顺序图。如果有负责的特殊流程,则可以考虑活动图。

当然,在实际工作中,不要被上面的条条框框所限制,有的时候可以有两种甚至三种图来表示,可以从多个角度来分析问题,再做适当取舍。

六、用例图

用例图对于很多人来说只是给一些角色配置一些权限。其实用例图是可以帮我们搞清楚这个产品是谁在用,通过这个系统能做什么事情。

6.1 基本语法

小人(actor,执行者),执行者可能是人也可能是系统。如果是人的话,可称之为角色。如果是系统的话,可以将另外一个系统画成执行者就可以了。

圈圈(用例,use case)圈圈里面的文字是动词加名词,这个就代表了系统能做什么事情。

大框框(系统边界,system boundary)这个框只框住了用例,没有框住执行者,这个就叫系统边界。

线条(关联,association)线条指用例和角色之间的线条,一般有三种,无箭头的,指向用例的箭头,指向执行者的箭头。同时,一般情况下也会有两种解释,一种是数据流向,还有一种是谁启动谁。

如下图:

6.2 进阶语法

用例的进阶语法主要包括继承、include(包含)、extend(扩展)

(1)include(包含)

包含一般有两种用法,一种是以树的方式组织各种用例,用包含来组织好父子用例,子用例可以再次包含自己的子用例,这样层次分明。

还有一种是某些用例的一部分可以抽离出来成为子用例,该子用例同时也被其他用例包含。

如下图:

(2)extend(扩展)

扩展的意思就是在某用例的基础上,还能做什么事情。例如用户在查看报表的时候,还可以导出报表,打印报表。如下图:

(3)继承

继承与类图中的继承性质是一样的,但是一般在画用例图的时候很少用,都会用其他的方式替代,因为不太好理解,而且还会降低沟通效率。如下图:

6.3 用例图的其他问题

那么我们日常工作中,如何画好用例图呢?

下面是一些在实践中的建议:

  1. 首先,在客户能全面理解的基础上,越精简越好;
  2. 同时用例应该使用客户的语言,让客户能够看得懂,要全面的表达用例,对于重点的地方要详细描述,非重点的地方不要过多描述;
  3. 通过使用扩展和包含来细化用例图,但要灵活把握,用例图只是一种表达方式,必要时可以结合其他方式来表达。

七、部署图、构件图

部署图和构件图一般用来获取和描述非功能需求。非功能性需求,一般包括两个方面,一方面的软件技术的架构要求。另一方面是安全性、易用性、性能等方面的要求。

7.1 部署图

在实际环境中的电脑、服务器或硬件设备,在部署图中用节点(Node)来表示,就是图中一个个立体矩形。

每个节点都有一个名字,如图中的财务的pc等。

门店的pc中有标记,标记(Tags)用来详细说明节点的配置情况,如Number=50-70,说明有50到70台门店的pc。

节点与节点直接有物理联系,则直接拉条直线,在直线上写上连接的方式。

如下图所示。

7.2 构件图

构件图也叫组件图,构件指的是物理上独立的一个东西,它可以单独维护、升级、替换。

下图展示了构件和构件的接口:

下图中的A和B表示依赖关系,表示A依赖于B,A需要调用B提供的一些服务。而C和D则是接口对接,D提供的服务是C所需要的,也可以画成C依赖D。

如图:

7.3 部署图和构件图结合使用

通常部署图和构件图需要综合使用,才能表达清楚在架构设计上的要求。

如下图:

7.4 关于部署图和构件图的实践建议

  1. 首先不要写放在任何地方都可用的东西,要根据项目的业务需求,IT架构环境写出针对性的要求;
  2. 其次,抓住主要问题,列出具体要求。主要考虑正常使用情况下系统应达到的要求,出现几率低的情况可不考虑;
  3. 最后,要文字表达准确,内容应该是可被验证的。

八、一些实践

本章主要为前面所讲的内容,通过一个案例,将部分串联起来。

我们的需求是做一个考勤系统。主要目标是规范员工的上下班、请假、外出工作等行为,同时方便计算员工薪资,方便管理各种带薪假期。

在整个过程中,需要遵循战略分析、相关方与目标分析、业务分析、需求细化这样的流程。那在业务分析阶段可以通过使用类图来分析业务概念,使用活动图、顺序图、状态机图来分析业务流程。

在需求细化阶段可以使用用例图来整理用例。同时也可以使用部署图和构件图来分析整理非功能性需求。

那在这里直接省略战略分析、相关方与目标分析阶段,直接进入到业务概念分析。假设已经目标清晰,且明确了相关方。那么下一步进入到业务概念分析。

8.1 业务概念图

这个考勤系统主要涉及到考勤,请假,外出。考勤和请假很好理解,外出是指外出工作,性质仍然是工作。

这三类事情全都涉及到流程,流程的问题咱们后面在分析,通常我们管理一个事情,除了管理流程,还要对一条或多条记录进行管理。

打卡不是会留下打卡记录吗?请假不是会有请假申请吗?外出不是会有外出申请吗?管理这些记录,就是管理这些事情了。

如下图,列出了关键的业务概念、业务概念的重要属性、业务概念之间的关系、相关业务信息通过注解来补充。

每个人所在的公司情况不一样,理解的角度不一样,业务概念图自然就会不一样。

8.2 外出申请审批流程分析

这里只对外出申请做举例,分别画出它的活动图和状态机图。

当然,也可以用顺序图来表达,但是此处用活动图和状态机图更合适,所有省略了顺序图。

活动图

状态机图

8.3 普通员工的用例分析

这里只对普通员工做举例,进行了用例分析。这里考虑到用户需要拥有管理自己外出的权限,管理自己请假,包含可休年假的权限。

同时为了方便安排工作,所以增加了可以查看所有员工请假的权限,以及查看自己打卡记录的权限。

如下图:

8.4 其他

关于部署图和构件图,一般情况下是由架构师来完成。所以在这里就不进行举例了。

九、总结

关于UML,是我们日常工作中,最常见的一种手段。它很简单,也很复杂。

简单的原因在于一学就会,容易上手,便于理解;复杂的原因是要画好uml建模需要不断的思考,反复验证,重复修改,才能达到最终的目的。

所以以上只是基于前者,来简单的说明常用的UML。若要提高建模能力,需要在日常的工作,生活中,不断的练习思考,终有所成。

 

本文由 @侯学峰 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
1人打赏
评论
欢迎留言讨论~!
  1. 文件夹和文件为啥不是 强包含呢?

    回复
    1. 文中有提到强包含和若包含的含义。同理,如果文件夹不存在了,那么这个文件夹里面的文件夹和文件依然存在,所以说弱包含。

      回复
  2. 第一个状态机图,大于三天的审批的时候没有拒绝呢?

    回复
    1. 别人端盘好菜给你吃,你问盘子上花纹啥意思,干这行的不需要每件事都做成这样规范,但是每个环节都要像作者写的这样思考

      回复
    2. 有拒绝呀~从部门经理到拒绝的那条线就是高层经理的拒绝。
      可以这样理解,在状态为部门经理批准,且大于三天时,高层经理进行了拒绝操作,所以状态变为拒绝。

      回复
    3. 我说的是 4.1章节的那个图,我还是觉得 大于三天时还是少了一根到 拒绝的线呀

      回复