UML的初步回顾到放弃

今天呢，主要是跟大家一起初步回顾和学习一下 UML。以及如何从入门到放弃……

首先跟大家说明一下，选择跟大家分享UML，我觉得是我做的一个错误的选择……

一、UML简史

随着市场所要求的软件的复杂度不断增大，软件开发的方法学也在不断进化。从没有方法到简单的功能分解法，再到数据流/实体关系法。进入20世纪90年代，面向对象分析设计（OOAD）方法学开始受到青睐，许多方法学家纷纷提出了自己的OOAD方法学。流行度比较高的方法学主要有Booch、Shlaer/Mellor、Wirfs-Brock负责驱动设计、Coad/Yourdon、Rumbaugh OMT和Jacobson OOSE。

这种百花齐放的局面带来了一个问题：各方法学有自己的一套概念、定义和标记符号。造成了混乱，开发人员无从选择，也妨碍了面向对象分析设计方法学的推广。于是经过各方努力，1997年11月，OMG 组织（Object Management Group对象管理组织）发布了统一建模语言（Unified Modeling Language，UML）

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

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

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

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基本表示法

下面的图表示的 UML 类，该图被分为四个部分。

• 顶端部分被用来命名类。
• 第二个是用来显示类的属性。
• 第三部分是用来描述由类执行的操作。
• 第四部分是可选的显示附加组件。

Student 类的 UML 大致如下：

六、UML 示例

下图是从网上找的一个 UML 建模的示例。

 

 

七、思考

上图看上去感觉还可以，条理清晰，但是这个东西真的有用吗？我们需要去学习吗？

作为程序员我们做的事情是什么呢，我们目前在做应该是编写面向对象语言——也就是我们说的“源代码”。

 

最初的源代码是机器语言。程序员在纸带或者卡片上打孔来表达0和1。后来，发现这个太累了，于是发明了一些助记符，这就是汇编语言。后来抽象级别提升，有高级语言C，面向对象语言Java 等。 

如果人脑只需要编辑 UML模型就可以实现系统，那么“模型就是源代码”。当然最终这个模型也可以是X模型、Y模型。

UML是软件需求分析、设计的强大工具，并非简单介绍就可以认知的，学习成本和使用成本其实并不低。从我觉得这个可以分享并着手去学习了之后，个人认为这个工具的使用简单了解一下就可以，具体要去学习的应该是它的思想：如何去建模。至于根据 UML 生成代码等功能没有必要去了解，工具会过时，会被淘汰，但是思想可以一直发光发热。

今天回顾UML呢，并不是技术分享，就是聊一聊软件方法。顺带抛出“建模”这个概念。在做一个系统的时候，我们要不要建模、怎样去建模？很多人说建模是可以带来竞争优势的。这个也是我接下来要去了解、验证和学习的。

UML 2.5 规范

UML相关工具一览

Windows建议下载工具： WhiteStarUML 

 

后记：

问大家一个问题：你们觉得编程语言发展的目的是为了什么？

 

个人感觉这个和我为什么而工作，为什么而加班是一样的。我工作就是为了不工作，加班也是为了不加班。编程语言的发展就是为了消除编程语言，一直是在追求一种简单高效的方式去改变这个世界。为此，当下我觉得软件方法中的业务建模是很重要的。老大在年终总结上曾说过，有些人工作两三年可能有行业三到五年的经验，有些人工作了十年，可能只有两年的行业经验。成长是一个不断审视自己、和自己对话的一个过程。

参考：

https://www.w3cschool.cn/uml_tutorial/

https://www.cnblogs.com/noteless/p/9907703.html