软件工程之UML建模

从公众号转载，关注微信公众号掌握更多技术动态

---------------------------------------------------------------

一、建模基础

1.建模的底层逻辑

用一个公式表达建模的底层逻辑：建模 = 图形 + 逻辑 + 现实的抽象，用一句概括即是用图形逻辑地表达现实业务的抽象

(1)图形

图形即为UML图形，下面是6种对象间的关联图形，在建模中尽量遵循UML标准画图，方便大家理解。

继承：子类继承父类的特性，有的语言仅支持单继承。
实现：子类实现父类定义的接口。
组合：一个类包含另外的类，但它强调的是一种强关联关系。
聚合：也是表达一个类包含另外的类，但它的关联关系比组合要弱。
关联：通过一个类可以关联到另外一个类，可分为单向关联和双向关联，一般以类的成员变量体现。
依赖：比较弱的一类关联关系，一般是以接口参数的形式体现。

(2)现实的抽象

我们的现实业务有的是非常复杂的，如果涉及到专业领域概念，新手想入门是挺难的，当我们不清楚业务链路和逻辑时，直接看代码实现时很难有全局的视野，不能够串起全局业务间的内在联系。

当我们切入到一个新领域中，并非短时间内就要成为该领域的专家，急需一种方法用20%的时间能够掌握该领域80%的业务知识，一个可行的方法就是建模，通过对现实业务进行抽象，构建出全局业务概念模型，有了全局的认识，再去了解业务细节就会快得多。我们要建模的对象即是问题域，我们并不需要覆盖所有的点，而是基于核心的内容进行建模，Eric Evans 在建模书中提到一个观点：建模是出于某种目的而概括地反映现实，这里的概括就是抓住核心的意思。

现实的抽象有三层意思：一类是直接映射，比如现实有一个杯子，那么我们的模型中就有一个杯子；另一类是往上抽象一层映射，比如我们的组织中有一级结构、二级结构、三级结构等，那我们可以抽象成组合结构，形成父子节点的结构，这种抽象就更灵活了；最后一类是隐性抽象，前面两类抽象比较容易做到，最难的是隐性概念抽象，它很大可能是之前不存在的，需要新造出一个概念，就像软件设计中，通过新增加一层来实现解耦一样，通过新造的概念串联元素间的内在关联关系

(3)逻辑

逻辑即为因果，也即元素之间存在某种关系，如果两个完全没有关系的元素放在一些，就会显得前因不达后果、风马牛不相及，让人不好理解。那么对应到建模上，我们的模型应该是非常具有逻辑性的，从模型上能看出业务核心要素，要素与要素之间的关系是怎样的。

逻辑主要体现在时空两个维度上：时间维度，一件事情节点完成之后，会影响后续的事情节点；空间维度，更多的体现在结构上，我们常说的空间结构就是这个意思。以时间维度为例，在电商结算中，当订单支付成功后，结算收单，收单后接受到放款的执行指令，在放款之前需要计算出放款明细信息，如卖家应收到多少钱、公司应收到多少佣金等，最后是打款转账，这个过程就是按照时间节点不断往后驱动，可抽象出如下图的模型。

空间维度即是结构关系，比如下图中的组织结构，像这样的结构类型，我们还可以找到更多的实际案例，比如交易订单有主子订单结构，执行单包含多个执行明细信息，模型最终呈现出来的就是一个结构，从结构维度也可以将其分解出更小的粒度。

不管哪种建模的方法，最根本的还是体现出了建模的逻辑性，用例建模的逻辑性体现在能够清晰地定义出用例场景，把所需要做的事讲清楚；四色建模通过人、事、物、时间、地点维度描述清楚一件事；事件风暴通过时间轴勾画出核心关键的事件。当我们构建不出模型时，并不是我们缺少建模的方法，而是建模的逻辑性上有问题，建模缺的不是方法而是经验和实践。我们不能神化建模，建模是很纯粹的，就是为了简化对复杂事物的认识，并且模型能够映射到实际开发的模型中。

2.建模的方法

因果法的本质同事件风暴建模一样的，在用熟的基础上按照自己的习惯进行运用，不管什么方法，只有内化成自己的方法才有用。它的核心是基于一个对象不断往前和往后找因果关联对象，最终构建出完整的业务概念模型。

二、UML简介

1.什么是UML

UML(Unified Modeling Language)的是要成为一种标准的统一语言，使得IT专业人员能够进行计算机应用程序的建模。UML成为"标准"建模语言的原因之一在于，它与程序设计语言无关。而且，UML符号集只是一种语言而不是一种方法学。因为语言与方法学不同，它可以在不做任何更改的情况下很容易地适应任何公司的业务运作方式。

2.用例图（UseCaseDiagram）

从用户角度描述系统功能，并指各功能的操作者；主要用来描述用户、需求、系统功能单元之间的关系。它展示了一个外部用户能够观察到的系统功能模型图。