软件工程之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）

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

• 描述方式：椭圆表示某个用例；人形符号表示角色。

• 目的:帮助开发团队以一种可视化的方式理解系统的功能需求，建立需求模型。

3.静态图

主要描述系统的静态表示和关系。

(1)类图（ClassDiagram）

描述系统中类的静态结构。是显示了一组类、接口、协作以及他们之间的关系。在UML中问题域最终要被逐步转化，通过类来建模，通过编程语言构建这些类从而实现系统。描述方式：三个矩形 

在UML类图中，常见的有以下几种关系: 泛化（Generalization）,  实现（Realization），关联（Association)，聚合（Aggregation），组合(Composition)，依赖(Dependency)

(2)包图（PackageDiagram）

是包和类组成的，表示包与包之间的关系，包图描述系统的分层结构。

(3)对象图（ObjectDiagram）

类图的一个实例，描述系统在具体时间点上所包含的对象以及各个对象的关系

4.行为图

描述系统动态模型和对象组成的交换关系。

(1)活动图（ActiveDiagram）

描述了业务实现用例的工作流程。一种特殊的状态图，展现了系统内一个活动到另一个活动的流程。活动图有利于识别并行活动。表示两个或多个对象之间在处理某个活动时的过程控制流程。

【描述方式】 

• 起始点：实心圆 

• 活动：圆角矩形 

• 终止点：内部包含实心圆的圆 

• 泳道：实际执行活动的对象

(2)状态图（StateDiagram）

是描述状态到状态控制流，常用于动态特性建模，由状态、转换、事件和活动组成，描述类的对象所有可能的状态以及事件发生时的转移条件。通常状态图是对类图的补充，仅需为那些有多个状态的、行为随外界环境而改变的类画状态图。表示某个类所处的不同状态以及该类在这些状态中的转换过程

【描述方式】 

• 起始点：实心圆 

• 状态之间的转换：使用开箭头的线段 

• 状态：圆角矩形 

• 判断点：空心圆 

• 一个或多个终止点：内部包含实心圆的圆

(3)数据流图

数据流图（Data Flow Diagram, DFD）是一种便于用户理解和分析系统数据流程的图形工具，他摆脱了系统和具体内容，精确的在逻辑上描述系统的功能、输入、输出和数据存储等，是系统逻辑模型的重要组成部分

• 数据流：是由一组固定成分的数据组成，表示数据的流向，除了流向数据存储或从数据存储流出的数据不必命名外，每个数据流必须要有一个合适的名字，以反映该数据流的含义

• 加工：加工描述了输入数据流到输出数据之间的变换，也就是输入数据流经过什么处理后变成了输出数据

• 数据存储：数据存储表示暂时存储的数据,每个数据存储都有一个名字

• 外部实体：外部实体是存在于软件系统之外的人员或组织

​

5.交互图

用于描述对象间的交互关系，由一组对象和它们之间的关系组成，包含它们之间可能传递的消息。

(1)顺序图/序列图（SequenceDiagram）

描述对象之间的交互顺序，着重体现对象间消息传递的时间顺序

• 描述方式：横跨图的顶部，每个框表示每个类的实例或对象；类实例名称和类名称使用冒号分开

• 目的：显示流程中不同对象之间的调用关系，还可以显示不同对象的不同调用。

(2)协作图（CollaborationDiagram）

描述对象之间的协助关系

6.实现图

就是指示如何组织构件和具体的构件部署到具体的节点上。

(1)组件图（ComponentDiagram）

展现了一组组件的物理结构和组件之间的依赖关系。部件图有助于分析和理解组件之间的相互影响程度。提供系统的物理视图，根据系统的代码构件显示系统代码的整个物理结构

(2)部署图（DeploymentDiagram）

展现了运行处理节点以及其中的组件的配置。部署图给出了系统的体系结构和静态实施视图。它与组件图相关，通常一个节点包含一个或多个构建。显示系统的硬件和软件的物理结构

【描述方式】 

• 三维立方体表示部件 

• 节点名称位于立方体上部