UML简单介绍-如何看懂UML(一)

 

在计算复杂的数学题时，我们必然会打草稿计算

在绘画课中，我们可以素描出来看到的事物

那么在程序设计中呢？

如何描绘传达你脑海中的关于这个程序 ，设计的蓝图草稿？

 

OOP的程序设计中，最多的自然是类、接口层次接口的设计

简单的设计，可能在脑海中想象下就过了，比如A继承B

但是复杂的呢？

对于OOP程序设计中，类的层次、关系设计如何描绘？

用文字么? A继承B A实现C，A中有一个D的引用

显然，图形化的方式更加直观，简洁

那么到底如何表示OOP中的事物与关系？每个人有每个人的书写方式，如何进行交流？

你画了一个三角形说这是一个接口，我花了一个圆形，跟你讲这个是接口？这其中的问题不言而喻。

 

UML起源

1997年，OMG 组织（Object Management Group对象管理组织）发布了统一建模语言（Unified Modeling Language，UML）

UML 是一种为面向对象开发系统的产品进行说明、可视化、和编制文档的标准语言

UML 作为一种模型语言，它使开发人员专注于建立产品的模型和结构

UML 是不同于其他常见的编程语言，如Java等，它是一种绘画语言，用来做软件蓝图

 

UML 提出了一套 统一的，标准的建模符号

首先它提供了一套建模符号，用于类的层次结构设计

另外，统一的也就意味着只要按照标准构图，就可以无障碍的通过UML图进行沟通

计算机软件的世界里面，总是“分久必合”，UML的发展历史也不例外

UML 统一了Booch、OMT、OOSE和其他面向对象方法所涉及的基本概念和建模符号

UML的发展不是一蹴而就的，而是吸收了现有的精华，而发展出来的大一统的形式

 

UML逻辑原理

UML是面向对象程序设计的描绘语言

是面向对象程序设计的建模语言，是对面向对象程序设计世界的抽象

 

UML的基本逻辑是很简单的

将面向对象程序设计中的元素进行抽象，比如类还是接口，UML中称之为事物，就如同积木的基础形状

将元素之间的联系关系进行抽象，比如到底是继承还是组合（聚合），如同积木中的卡扣，可能有多种卡扣连接形式

 

而我们看到的UML图也就是如同一整块已经搭建好的积木

当然

UML肯定不会向积木那样简单，所以自然还会有很多的规则、限制、要求，这些一起构成了完整的UML

但是根本是事物和关系，这两者是UML的主体

 

事物就是面向对象程序设计中的元素

关系则是他们的相互联系形式

图则是按照不同事物的组织形式进而产生的分类

 

UML组成

 

上图是UML的大致基本组成部分，部分类型并未全部列举

事物是是实体抽象化的最终结果，是 UML 构建块最重要的组成部分

最基本的是类和接口

关系是事物之间的联系的抽象分类

有了事物和联系，就可以绘制出各种各样的UML图

按照他们的逻辑功能性质，又有了图的分类

 

UML是软件需求分析、设计的强大工具，并非简单介绍就可以认知的

本文重在简单了解基本知识以更好学习设计模式

 

UML常用关系

关联关系使用一条直线表示，比如  A与B关联

用于描述不同类的对象之间的结构关系，将多个类的实例联系在一起

是一种静态关系，基本与程序的运行没有关系

比如，部门与员工的关系，就是关联关系

关联关系一般不强调方向，表示互相“知道”对方，也就是存在引用

关联关系有多重性 比如一对一关联 一对多关联等 可以任意关联N对N关联

如果特别强调方向，就使用箭头，比如

那么表示A知道B但是B不知道A

也就是说，关联关系有两种图形

直线或者直线箭头

 

关联关系表示存在引用，比如员工类的定义中有“部门”属性字段

实现关系是带空心箭头的虚线表示的，比如A实现B，箭头指向父类、接口

实现可以狭隘的认为是一种实现类与父类、接口的关系（其实在UML中实现的含义远不止实现类这层含义）

泛化关系是带空心箭头的直线表示的，比如A继承B

用于说明继承关系
泛化关系是从子类到父类的关系，箭头指向的是父类

聚合关系是带空心的菱形的直线表示的，比如 A聚合到B上，也就是B由A组成

聚合关系用于类图，表达整体由部分构成的语义，比如部门由许多人员组成
整体和部分不是强依赖的，即使整体不存在，依然可以存在部分，即使没有部门，人员仍旧存在

组合关系是带实心的菱形的直线表示的，比如A组合成B，或者说B由A构成

表达整体拥有部分的含义，组合关系是一种特殊的强依赖的聚合关系
如果整体不存在，那么部分也不存在了
比如，汽车由轮胎底盘发动机构成，汽车不存在了，自然也不存在发动机了

依赖关系使用带箭头的虚线表示，比如  A依赖B

用于描述一个对象在运行期间会使用到另外一个对象的关系
依赖关系是一种临时性的，简言之就是不同场景会发生变化
比如人和车
如果是驾驶场景，车依赖人（驾驶员），如果是乘车出行，那就是人依赖车（公交、出租）
很显然，依赖关系比关联关系更加弱
依赖关系是一种使用关系
比如一个类的方法中的局部变量、方法的参数或者对静态方法的调用，都是一种依赖

 

UML类的属性和方法

类包括类名、属性、方法

都在类图中

 

属性：可见性  名称 ：类型 [ = 缺省值]

方法：可见性  名称(参数列表) [ ： 返回类型]

中括号表示缺省的

可见性使用+  -  #表示

+ public

- private

# protected

 

常用工具

UML的工具有很多，比如 StarUML 、astah

 

astah，前身是JUDE 

下图为astah中的sample

以下图为例简单的了解下UML的图形标识符号

 

Tracer中与Engine、Steering、Monitor单项关联，也就是含有引用

与State双向关联

Engine与Steering由Motor组成 他们是可以独立存在的

Monitor由LightSensor组成 他们是可以独立存在的

Idle OnCourse OutOfCourse 是State的实现类

Monitor中，Threshold是boolean类型的私有属性 

isBlack和isWhite是返回类型为void的 public方法

 

 

总结

本文简单介绍了UML的历史以及组成部分，目的不在于详细介绍UML，只在于能够读懂以及绘制类图

UML是可视化的程序设计描绘语言，通过图形和符号直观的表达含义

对于类图需要理解清楚类图相关的关联关系

另外，不同的软件对于各种图形的表示可能局部细节会有差别，实际使用时应该注意

UML是Unified Modeling Language ，并不是一种具体的工具，而是标准

UML建模工具就如同“实现类”一样，细节上有差异也很正常，很多软件也可以调整显式的式样，比如StarUML就可以