第一章 UML简介
1、定义
统一模型语言（Unified Modeing Language,UML）代表同一家族的图形表示法，在这些表示法背后有一个共通的超模型（meta model）存在。它们可以帮助我们描述与设计软件系统，特别是那些用面向对象风格设计的软件系统。
模型背后的基本原因：编程语言无法以够高的抽象度，方便我们讨论设计的相关议题。
UML是相当开放的一种标准，有对象管理协会负责管理它，此协会是一个有多家公司所组成的开放性联合组织。成立的宗旨是为了简历支援互通性的相关标准，特别是对象导向系统间的互通性。
2.UML的不同用法
针对uml的特性有三种使用模式，分别当成：草稿、蓝图与编程语言来用。其中将其视为草稿是三种中最常见的一种用法。
草稿用法跟蓝图用法一起搭配时，我们可以从正向工程或反向工程两个不同方向来使用草稿。
正向工程：在写程序之前先画图UML图
反向工程：通过现有程序画出UML图，以帮助我们了解代码。
注释：搭配草稿、蓝图两种用法的步骤为（1）先画出UML草稿、（2）以case工具用正向工程写出编码大纲、（3）修改优化代码、（4）定期通过代码以case工具用反向工程画出UML设计模型。
将UML视为草稿本质上就是在谈选择性。以正向使用草稿来看，你会粗略画出将要在编码中体现的议题出来，然后用它跟团队中的一群人讨论。使用草稿的目的是为了帮助我们来沟通想法或讨论即将要做的一些替代做法。你不会想要跟大家说明所有预计要写的代码中所有的细节，而只会针对一些重要议题跟同事讨论一下，或者在开始编码之前，先将部分设计方式以视觉方式展现出来。
以反向使用草稿来看，你可能会用草稿画出系统中的某个部分是如何运作的。我们不会秀出所有类别，只会秀出有兴趣或深入代码之前值得一提的部分。
将UML视为蓝图则是跟完整性有关的做法。如果采用正向工程的话，那么我们就会先有设计师画出蓝图，他的工作就是画出详细的设计结果，让程序开发工程师依样画葫芦写程序。设计结果必须够完整、做出所有的设计决策。程序开发人员不太需要思考，就可以赢直觉方式遵循它写出程序来。
常见的做法是请设计师画出蓝图等级的模型，这里面只包含子系统的接口而已，稍后再由开发人员完成具体的细节。
评注：子系统接口在开发初期不容易定义出来，因为他们大部分涉及到的都是功能性接口，所以在未设计完整个系统之前，不容易先定义出来。还有就是软件系统不断会有设计上的变动与需求上的变动，以至于我们就算在初期把接口定义出来，事实上也不容易稳定下来，这都是不易施行的阻碍所在。好的设计师了解系统那些部分容易受到需求影响而不断修改，而能把系统中不变与易变得部分隔开，因而能控制需求上的变动。不过，设计上的变动只能靠好的单元测试当做好的防护网，协作我们进行设计上的变动。
如果采用反向工程的话，蓝图的目的是为了表达出更程序有关的详细信息，我们有可能用纸张或在互动式的图形浏览器上秀出蓝图。蓝图里面可以用图像方式秀出类别的所有细节，让开发人员更容易了解。
蓝图和草稿间的界限有点模糊，不过个人认为两者间的差距在于：我们会刻意让草稿变得不完整，以强调重要信息；而蓝图则意图变得无所不包，通常希望编码工作可以变成简单、相当机械化的动作。简言之，我认为草图是探索式的，而蓝图则是已决定好的东西。
将UML视为程序语言的其中的一个有趣的问题是：如何画出行为逻辑的模型来。UML2版中提供三种建立行为模型的方法：互动图、状态图和活动图。
看待UML的另一种不同观点在于：大家究竟是以偏概念或建立软件模型的方式来用它。大部分人都习惯一建立软件模型的方式来用UML。
采用软件观点时，UML中的各种元素都可直接对应到软件系统中的元素。
采用概念性观点时，UML就是我们对所研究领域的一种描述。这时候，我们不是在讨论跟软件元素有关的东西，而是在建立一套讨论某个特定领域的字汇。
本书比较多的焦点放在草稿用法上。很幸运地，这一点对间断的入门手册来说是有帮助的。我无法以更本书同样大小的内容来充分发挥UML其他两种用法的价值。不过这种大小的书可以有效的帮助你去看那些采用其他用法的书。
3、UML的发展历程
（此处省略。。。）
4、表示法和超模型
表示法是我们在模型中所看到的图形部分，它也代表模型语言的语法。
对模型表示法的使用者来说，超模型具有多少意义呢？答案大部分要视他们对UML的用法而定。采用草稿用法的人通常不会太关心超模型；采用蓝图用法的人应该会多关心一点。至于那些将UML视为程序语言的人来说，超模型对他们是相当重要的东西，因为他帮助我们定出语言的抽象语义。
下图是UML超模型中一小部分，里面说明特性间的关系：
5、UML中所包含的图
UML标准会指出某些特定元素典型的用法是将它们放在某些特定的图形种类中，不过这并不是强制性的规定。
如下是UML中的官方图形种类：
| 图形种类 | 章节 | 目的 | 引进此图的版本 |
| 活动图（activity diagram） | 11 | 程序性或平行性行为 | UML1.1版 |
| 类别图（class diagram） | 3、5 | 类别、特性和关系 | UML1.1版 |
| 通讯图（communication diagram） | 12 | 对象间的互动情形；焦点在链接关系（link）上 | UML1版的合作图上 |
| 组件图（component diaagram） | 14 | 组件的结构与链接关系（connection） | UML1版 |
| 组合结构（composite structure） | 13 | 类别在执行时期的合成情形 | UML2版新增 |
| 配置图（deployment diagram） | 8 | 将工作成果配置到节点（node）上 | UML1版 |
| 互动概图（interaction overview diagram） | 16 | 混合循环图和活动图两者 | UML2新增 |
| 对象图（object diagram） | 6 | 类别实例的组态 | UML1中非正式使用 |
| 包图（package diagram） | 7 | 编译时期的阶层结构 | UML1中非正式使用 |
| 序列图（sequence diagram） | 4 | 对象间的互动情形；焦点在信息的先后顺序上 | UML1 版 |
| 状态机图（state machine diagram） | 10 | 说明事件在对象的生命中如何改变状态 | UML1 版 |
| 时序图（timing diagram） | 17 | 对象间的互动情形；焦点在时序上 | UNL2新增 |
| 使用案例图（use case diagram） | 9 | 说明使用者如何跟系统互动 | UML1 版 |
UML中图形种类分类如下：
6、什么才是合法的UML
如果你是采用草稿或蓝图用法的人，那么有件事很重要，就是不要把太多焦点放在得到合法的UML上。让你的系统有好的设计结果是更加重要的事。
7、UML所代表的含义
虽然规格书中详细地描述了定义良好的UML为何，不过里面去没有提到在UML超模型的纯纯世界之外，UML所代表的意义为何。
8、只靠UML是不够的
如果没有UML的图适合你的用途，那么请毫不犹豫地去用不属于UML的图。
9、UML要从何学起
没有人，甚至是UML的创始人，都无法完全了解或用到UML中的所有东西。大多数人只会用到UML中的很小部分，而且只用它们就可以行的通了。大家必须找到自己跟同事们适用的那一部分UML。
如果你刚开始学UML，我建议你先把焦点放在类别图和序列图的基本型上。它们是最常见的图形中类，而且就我个人观点而言，它们也是最有用的。
一旦你抓住它们的窍门，接下来就可以开始去看一些更高等的类别图表示法，当然也可以看看其他种类的图形。