聊聊UML（1）关于UML
UML.jpg
写在前面
为了了解UML，我们开篇先大致了解一些UML的概念。
我觉得这些概念看了之后大致有个印象就好了。
因为不在实际的过程中使用，没有讲到具体的图的时候，很难理解。
特别是对象之间的关系，以及各种图的分类和名称。
但是，这个部分又不能不讲。
UML发展至今其实是融合了很多大神的经验及智慧。
其初衷其实是为了发展出一套让全世界从业人员都可以看懂的建模语言。
类似于软件界的五线谱。
你即便不懂英语、日语、德语等等，你看一张UML图，也能大致理解表达的意思，并且不用别人过多解释。
所以我觉得如果你是要画UML图就要遵循UML的规范，而不是自创。
否则别人就会看不懂了。
然鹅，让我一直很困惑的是，各个大厂的UML建模软件却完全各搞各的，没有严格遵循规范。
可能也是因为UML本身也在不断发展的缘故吧。
尽管如此，我还是建议大家尽量用规范的表达方法，这样不容易产生歧义。
如果要用工具，那么至少在一个项目或者在公司内部保持统一，并且给出图例规范说明。
防止大家有理解不一致的地方，如果造成更多的困扰，那么就有违UML的初衷了。
具体的发展史大家可以自行度娘，或者去OMG的官网查看详细信息。
OMG.jpg
在这里，我想特别标注几点我觉得很重要的信息：
UML起源于多种面向对象建模
方法，由OMG开发，目前已经成为工业标准。
UML自1997年发布1.1版本以来，经历10年后，已经发展到了2.5版本了。
最新的版本可以去OMG官方下载。
OCUP-2-logo.jpg
UML的意义在于：
-
在发展的过程中，统一了Booch、OMT和OOSE等方法中的基本概念和符号。
-
UML吸取了面向对象领域中各种优秀思想，是开发者们根据最优秀的OO方法和丰富的计算机科学实践经验综合提炼而成的。
-
UML在演变的过程中还提出了一些新的概念，不断推动着OO思想的发展。
为什么着重要提这几点？
面向对象OO，是UML的根本。
你想要理解UML，想要用好UML，一定要有OO的思维方式。
这也是我为什么会在列大纲的时候就专门列了一篇关于OO的介绍。
下一篇我们再详细来说OO。
另外，我们需要注意的是，UML还在逐步发展中。
所以时不时的新版本出来，你会发现由多了几种图，有一些新的概念。
但是其实个人觉得没有必要去追求所谓的最新版本，因为我们常用的几种图在UML2的版本中都涉及到了。
除非UML升级到UML3，否则基本上都是一些扩展和补充。
我们的目的也不是进行UML的专业研究，我们的目的是用起来。
所以呢，如果你想要买一些UML的书来看的话，关注一下书籍信息，UML1的就不要买了。
现在市面上大部分是UML2.3，UML2.4的。
看这个版本目前也差不多够了。
UML的组成
UML的组成主要有：事物、图和关系。
-
事物是UML中重要的组成部分。
-
关系把各个元素紧密的联系在一起。
-
图是一种表达形式。
因为翻译的关系，可能有的书上不这么描述。
不过问题不大，我们这篇的主要目的是让大家有个大体上的印象。
下面这些概念看上去比较难理解，给这种抽象的东西下定义，真的挺难的。
后面在讲到具体图的时候回一一提及。
如果看不懂，也没关系。
UML事物
UML主要包括四种事物：构件、行为、分组和注释。
构件
构件事物是UML模型的静态部分、描述概念或者物理元素。
包括：
类 ：是对象的抽象。后面会在类图、包图等中进行详细介绍。
接口 ：描述了类或组件对外可见的动作。
协作 ：一组事物相互作用的集合。
用例 ：常见于用例图，用来描述一系列动作。
组件 ：抽象了的物理或逻辑的部分。
节点 ：主要使用在部署图中。
行为
交互 ：实现某个功能的组件之间的消息集合。
状态机 ：描述事物生命周期的状态序列。
分组
主要由包实现，描述事物的结构组成。
注释
对模型中的元素进行说明、解释。
关系
UML中主要的关系：依赖、关联、泛化和实现。
依赖
A元素的变化会影响B元素。
A被称为独立元素，被影响的B元素称为依赖元素。
关联Association
两个对象之间的关系，在类图、用例图中很常见。
泛化Generalization
又称为继承，子继承父。
在用例图和类图中比较常见。
实现Realization
条条大路通罗马，每条路都可以实现到达罗马的目的。
其他
还有一些关系会在具体降到类图、用例图等的时候再进行介绍。
比如组合、聚合、包含、扩展等等。
具体的如果感兴趣，可以看《大象，Think in UML》的第3章内容，里面描述的比较详尽。
UML的图
UML包括众多的图，在《UML2 软件建模：概念、规范和方法》中有这样一张图，看上去比较清晰，分享给大家。
image.png
主要分成两大类：静态图、动态图（也称为行为图）。
- 静态图
顾名思义，描述的是对象的静态结构，与时间无关。
- 动态图
描述的是对象的动态行为，除用例外，其他图会随着时间“流动”。
写在最后
UML的图其实很有意思的一点在于，相互独立又相互验证。
如果你在画一个用例图，那你就应该关注用例。
什么执行者有哪些操作、有哪些活动。
而不关注这些活动的状态和触发条件。
但是用例图中的这些活动可以和活动图的活动进行对应。
用例图中的执行者可以和活动图中的角色进行对应。
活动图中的阶段可以映射到状态机图。
……
这也使得UML图的维护更新比较耗费精力。
那我们干嘛还要用UML呢？
这就不得不提到下一篇的内容，面向对象了。
嗯，期待下吧！
PS：这篇没写太多的例子，还是放到后面写具体图的时候再写例子吧。因为害怕这个坑还没填到用例图，你就已经不记得啥叫做“继承”了……
小婧是一名行走在实践路上的资深业务分析师（BA），如果想与我同行，就请关注我吧！
