关于UML,我相信在做B端的产品经理一定知道它的重要性。那么UML常用的图都包含哪些呢?它们又都在什么场景什么阶段使用呢?又如何使用呢?这篇文章主要帮助小伙伴们解答这些问题。
一、UML的分类及用途
首先简单给大家介绍一下什么是UML,UML的全称是Unified Modeling Language。翻译过来就是统一建模语言。它对产品经理最主要的作用是用于需求分析中更好的梳理逻辑,同时能够提升沟通效率。
UML主要包括图表中的十一种,那在本次的介绍中,只讲解类图、构件图、部署图、活动图、状态机图、顺序图、用例图。
通常对业务概念等静态结构进行系统化的梳理和提炼,我们叫它结构建模。而于对业务流程等动态内容进行系统化的梳理和提炼,我们叫它行为建模。而需求分析的核心目的是解决软件有没有用的问题。软件设计是解决软件用多大的成本做出来的问题。所以需求分析首要任务是保证软件的价值。
那么如何学好UML呢?其实UML的语法很简单,但是想要学好UML关键在于要改变思维习惯。要在平时多培养自己的书面表达能力、归纳总结能力、思维能力和抽象能力。
二、类图
装逼的讲,类图(Class diagram)是显示了模型的静态结构,特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。那它其实就是用来帮助我们识别出人、事、物和业务的概念,并理清它们的关系的一种方法。
2.1 类图的基础知识
在聊类图之前先让我们理清几个概念。
首先,什么是类?将某类东西归纳在一起就可以成为一个类。例如,本文的读者,我们就可以分为初级产品经理,高级产品经理。或者分为产品经理和非产品经理。这些都可以叫做类。
然后,什么是类图?类图就是一个矩形的方框,上面是类的名字,中间是属性,下面是操作。比如这篇文章的读者是产品经理,那产品经理的属性就有性别,年龄,级别等。如果要列举当然会有很多属性,但是我们只找出相关且对我们有用的属性。
那一般如何用类图获取需求呢?首先要识别出类。其次识别出类的主要属性。然后描述出类之间的关系,最后在对各类进行分析、抽象、整理。
2.2 类之间的关系
- 直线关系
直线关系其实就是我们常说的关联关系,如下图。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,如下图:
- 包含关系
包含关系有两种表示方法,一种是空心菱形,一种是实心菱形。空心菱形可以表示为弱包含的关系,实心菱形可以表示为强包含的关系。弱包含关系即部门没有了,员工可以继续存在。强包含关系是部门没有了,员工也就不存在了。以下图中表示的为,一个部门可以包含多个员工。
- 继承关系
继承关系是谁继承了谁的属性。例如香蕉,苹果,葡萄他们继承了水果的属性,同时又拥有自己的属性。我们用一个三角来表示,如下图:
- 依赖关系
所谓的依赖关系,依赖程度是相对而言的,不一定是A没有B就不能生存了。在实际的业务逻辑当中,对于某个事情,A需要B来协助完成,也是一种依赖关系。依赖关系使用虚线箭头表示。
2.3 类图的进阶
- 递归关系
我们常用的电脑系统中,如果用类图表示出文件夹与文件的关系,那么该如何表达呢?是文件夹包含文件吗?那文件夹和文件夹的关系呢?使用递归关系,我们就可以更好的表达出来。递归关系分为自包含和自关联,和字面的解释一样,就是自己包含自己,自己关联自己。下图分别是自包含和自关联。
- 三角关系
当某些属性值并不是由该类本身就可以确定的时候,我们可以使用三角关系,例如员工的薪资,职位等,并不是由公司可以确定的,而是由劳动合同来确定的,那么我们的表达方式如下:
三、活动图
活动图是用来表达流程最常用的一种UML图,它和流程图很类似。
3.1基本语法
- 基础流程图
流程中一般只有一个开始,会有一个或多个结束。箭头表示流程的走向。一个圆角矩形表示一个活动,活动可以理解为流程中的一个步骤,需要用主动宾的形式来表达。例如员工填写工时,项目经理审批工时。菱形代表判断,会有两个或两个以上的分支。判断一般有三种表达方式:在判断菱形旁写下判断的句子;直接通过监护来表示这个判断;在菱形判断之前加一个活动来表明判断动作。分支流程汇合时,也会使用菱形,然后会合并成一条路线。如下图:
- 泳道图
上面的流程图当中,如果流程简单,那么就可以很好的表达,如果流程很长,涉及到的角色很多,且很复杂时,看到就会非常乱,不止画的人觉着乱,看的人也会感觉很乱。那么,这个时候我们就可以用泳道图。泳道图一般是会按照角色进行分区,那么在画和浏览时都非常清晰。如下图:
3.2活动图的进阶
- 并行的活动
当遇到需要并行的活动或分支时,我们可以使用粗短棒。短粗棒会有两个同时出现。第一个是有一个箭头指入,多条箭头指出,这个叫做分叉。第二个是多条箭头指入,一条箭头指出,这个叫汇合。如下图:
- 对象流
当我们用矩形框来表示某个节点,并将矩形框的文字标注下划线,那它就代表对象。每个活动都有可能有一个或多个输入或输出。与输入输出直接相连的箭头叫对象流,而活动和活动之间相连的叫控制流。如图:
- 连接件
有的时候活动图很大,一张纸画不下,我们可以使用另一张纸继续画,这个时候,我们可以使用连接件。(其实现在的画图软件大多都不会出现这种情况),如下图,左边的图是箭头指向A,则是活动图到这里转向另一张图。右边的图是A指出一个箭头,表示从A开始继续这个活动图:
3.3 关于活动图的其他问题
对于活动图的粒度是如何控制的呢?其实这个是没有标准答案的,下面只是一些实践建议。首先要清楚活动图要表达什么内容,表达的重点是什么。以此来确定合适的粒度。其次,可以先用粒度比较大的活动图,大致搞清楚流程的总体情况。最后在逐步细化,需要重点说明的部分,活动的粒度应该足够细,足够说明问题。
那如何画好活动图呢?建议你一个活动图只表达一个事情。同时在画之前要明确该流程要达到怎样的业务目的,有什么角色参与,哪些是主要角色。先画出主流程,明确主流程中涉及到的角色。然后在逐步增加分支流程,这里主要表达出关键的分支即可,同时异常流程也不用全部表达出来,必要的时候,可以用文字来说明。控制好粒度,然后分别画出当前的流程和优化后的流程。对照差异,整理出需要调整的地方。
四、状态机图
状态机图其实和大家常说的状态图是一个东西,只是它的专业名称叫做状态机图。
4.1 基本语法
状态机图的开始状态和结束状态与活动图的一致。活动机图用一个圆角矩形来代表一个状态。与活动图不同,活动图是用圆角矩形代表一个活动。而且状态机图一般使用名词或形容词来表示某种状态。如下图:
4.2 其他问题
关于状态数量的问题。在使用状态机图时,若流程不合理,可以考虑通过增加、减少、修改状态来完善。增加一个新的状态会解决很多问题,但是也会增加流程的复杂度,可能会出现其他问题。
关于状态图的实践会有一些建议可供大家参考。流程围绕某一事物开展时,可以考虑使用状态机图来分析。同样也需要弄清楚它的目的,参与的角色,以及这些角色是如何推动流程的发展。并且列出流程中存在的问题。同时要考虑事物在流程不同阶段有什么变化。然后列出当前的流程,在根据流程的目的和存在的问题进行调整。
五、顺序图
当流程设计到多种角色,并且通过多个角色交互展开时,顺序图是不二选择。
5.1基本语法
角色可以用一个小人的图标来表示,下面写明角色。也可以用一个矩形来表示,但是需要在矩形里面说明角色。生命线是角色下面的那条虚线。激活框也叫会话,是生命线中细长的矩形。消息用箭头表示,并在上面说明做了什么事情。箭头可以从A指向B,也可以指向自己。返回值用虚线箭头表示,并在上面说明返回的内容。一般是反馈某个东西给相应的对象。如下图:
5.2 顺序图的进阶
循环分支属于业务流程中比较常见的特殊结构。loop,也叫循环,是满足循环条件的前提下,不断地重复做某些事情。alt,条件分支,是根据不同的条件选择不同的分支。opt,可选分支,是满足一定条件则执行该分支,否则就跳过。如下图:
上图的流程中,loop,中括号内是循环条件的内容,表示如果满足循环条件,则重复执行本框的内容。alt,如果满足条件1则执行上半部分,如果满足条件2则执行下半部分。opt,如果满足条件,则执行框中的内容,否则跳过。
5.3 其他问题
关于顺序图使用的一些建议。先从复杂的业务中整理出一条一条的流程。然后分析参与的角色,角色担任的职责和专业特色。然后在将流程分解成角色与角色的交互,想清楚各个角色之间是如何交互的,然后用顺序图把它组织起来,在这个过程中要不断的进行优化。
活动图,状态机图和顺序图,被称为流程分析的三大利器,那么每种图都有不同的特点和应用场景。 顺序图,强调角色之间的交互,强调按时间顺序分别发生了什么事情。不太适合表达复杂的特殊流程。活动图,强调每个角色做了什么事情,这些事情的先后关系,适合表达各种特殊流程,如分支,并发等。状态图,主要是事情围绕某东西开展,并且有不同的状态。
那么在实际工作中如何选择呢?通过上面说明的特点我们可以很清楚的知道。如果事情围绕某个东西开展,就可以考虑使用状态机图。如果不是,则可以考虑顺序图或活动图。如果没有复杂的特殊流程,可以考虑顺序图。如果有负责的特殊流程,则可以考虑活动图。当然,在实际工作中,不要被上面的条条框框所限制,有的时候可以有两种甚至三种图来表示,可以从多个角度来分析问题,再做适当取舍。
六、用例图
用例图对于很多人来说只是给一些角色配置一些权限。其实用例图是可以帮我们搞清楚这个产品是谁在用,通过这个系统能做什么事情。
6.1 基本语法
小人(actor,执行者),执行者可能是人也可能是系统。如果是人的话,可称之为角色。如果是系统的话,可以将另外一个系统画成执行者就可以了。圈圈(用例,use case)圈圈里面的文字是动词加名词,这个就代表了系统能做什么事情。大框框(系统边界,system boundary)这个框只框住了用例,没有框住执行者,这个就叫系统边界。线条(关联,association)线条指用例和角色之间的线条,一般有三种,无箭头的,指向用例的箭头,指向执行者的箭头。同时,一般情况下也会有两种解释,一种是数据流向,还有一种是谁启动谁。如下图:
6.2 进阶语法
用例的进阶语法主要包括继承、include(包含)、extend(扩展)
- include(包含)
包含一般有两种用法,一种是以树的方式组织各种用例,用包含来组织好父子用例,子用例可以再次包含自己的子用例,这样层次分明。还有一种是某些用例的一部分可以抽离出来成为子用例,该子用例同时也被其他用例包含。如下图:
- extend(扩展)
扩展的意思就是在某用例的基础上,还能做什么事情。例如用户在查看报表的时候,还可以导出报表,打印报表。如下图:
- 继承
继承与类图中的继承性质是一样的,但是一般在画用例图的时候很少用,都会用其他的方式替代,因为不太好理解,而且还会降低沟通效率。如下图:
6.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关于部署图和构件图的实践建议
首先不要写放在任何地方都可用的东西。要根据项目的业务需求,IT架构环境写出针对性的要求。其次,抓住主要问题,列出具体要求。主要考虑正常使用情况下系统应达到的要求,出现几率低的情况可不考虑。最后,要文字表达准确,内容应该是可被验证的。
八、一些实践
本章主要为前面所讲的内容,通过一个案例,将部分串联起来。
我们的需求是做一个考勤系统。主要目标是规范员工的上下班、请假、外出工作等行为,同时方便计算员工薪资,方便管理各种带薪假期。
在整个过程中,需要遵循战略分析、相关方与目标分析、业务分析、需求细化这样的流程。那在业务分析阶段可以通过使用类图来分析业务概念,使用活动图、顺序图、状态机图来分析业务流程。在需求细化阶段可以使用用例图来整理用例。同时也可以使用部署图和构件图来分析整理非功能性需求。
那在这里直接省略战略分析、相关方与目标分析阶段,直接进入到业务概念分析。假设已经目标清晰,且明确了相关方。那么下一步进入到业务概念分析。
- 业务概念图
这个考勤系统主要涉及到考勤,请假,外出。考勤和请假很好理解,外出是指外出工作,性质仍然是工作。这三类事情全都涉及到流程。流程的问题咱们后面在分析。通常我们管理一个事情,除了管理流程,还要对一条或多条记录进行管理。打卡不是会留下打卡记录吗?请假不是会有请假申请吗?外出不是会有外出申请吗?管理这些记录,就是管理这些事情了。如下图,列出了关键的业务概念,业务概念的重要属性,业务概念之间的关系,相关业务信息通过注解来补充。每个人所在的公司情况不一样,理解的角度不一样,业务概念图自然就会不一样。
- 外出申请审批流程分析
这里只对外出申请做举例,分别画出它的活动图和状态机图。当然,也可以用顺序图来表达,但是此处用活动图和状态机图更合适,所有省略了顺序图。
活动图
状态机图
- 普通员工的用例分析
这里只对普通员工做举例,进行了用例分析。这里考虑到用户需要拥有管理自己外出的权限,管理自己请假,包含可休年假的权限。同时为了方便安排工作,所以增加了可以查看所有员工请假的权限,以及查看自己打卡记录的权限。如下图
- 其他
关于部署图和构件图,一般情况下是由架构师来完成。所以在这里就不进行举例了。
九、总结
关于UML,是我们日常工作中,最常见的一种手段。它很简单,也很复杂。简单的原因在于一学就会,容易上手,便于理解。复杂的原因是要画好uml建模需要不断的思考,反复验证,重复修改,才能达到最终的目的。所以以上只是基于前者,来简单的说明常用的UML。若要提高建模能力,需要在日常的工作,生活中,不断的练习思考,终有所成。