发展史：吃水不忘挖井人，先记记创立者吧。
统一建模语言UML（Unified Modeling Language）是由Grady Booch、Jim Rumbaugh和Ivar Jacobson三人共同努力，于1996年6月和10月发布。1997年11月17日，OMG采纳UML 1.1作为基于面向对象技术的标准建模语言，成为可视化建模语言事实上的工业标准。
1、James Rumbaugh
参与创立了称为对象建模技术（Object Modeling Technique，简写OMT）的早期建模语言。
OMT包括对象模型、动态模型、功能模型用于分析、系统设计、对象设计和实现等步骤。
2、Grady Booch
开发了Booch方法，是一个面向对象的软件解决方案开发方法，用来分析、模型化和记录系统要求。
使用对象图、状态转换图、交互图来进行逻辑建模和物理建模。
3、Ivar Jacobson
创立了面向对象的软件工程（Object-Oriented Software Engineering，简称OOSE）方法。OOSE是一种真正的面向对象的软件方法，突出的特点是Ivar Jacobson加入的用例驱动和方法。
（可惜，这三个人的名字不会读，有人标出音标来吗？英语水平太差。）
UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
UML可用于下列领域：
1、机构的工作流程
2、业务分析
3、用户描述
4、数据库设计
5、对象设计
6、组件
7、部署（域和服务器）
8、GUI设计
UML是模型，不是实现，所以可用于任何类型的环境。在设计的方法，UML都独立于编程语言。当然，在某些位置，需要在UML模型做出一些决策，来反映物理和技术选择，这是UML的另一个强大特性。也就是说，不仅所有开发人员可使用UML，而且业务分析师和技术架构师能在了解所有要求、当前状态、未来状态、交互和约束前，不需要选择技术平台，即开始分析和设计解决方案。
UML由图形符号组成，开发人员、分析师、客户、用户和其他股东都能理解。
UML模型分为三类：功能、行为和实现。功能类别模型用来收集要求和描述功能。行为类别模型用于描述解决方案的对象和用户的行为。实现类别模型用于解决方案功能和行为的物理实现。
1、功能模型：用例图、类图
2、行为模型：交互图（顺序图和协作图）、状态图、活动图
3、实现模型：组年图、部署图
功能类模型：包括用例图和类图，它们将准确了解解决方案的作用及开发方式。
用例图：用来收集用户要求。由行动者（actor）、用例（use case）及它们之间的关系组成。
1、行动者（actor）指与系统交互的某人或某事。行动者要么从解决方案接收信息，要么将信息传给系统。通常包括人（如用户）或另一个系统。行动者一般指一个角色，而非操作者。例如：如果两个操作者以完全相同的方式使用解决方案，则行动者是一个，而不是两个。
2、用例（Use Case）指一个过程。
类图：用于收集要求阶段。它提出总是，并验证系统确能完成要求。
行为类模型：描述解决方案的行为或交互。
1、交互图：包括顺序图和协作图。这两种图之间的区别在于：顺序图基于时间，按时间顺序显示出现的任务；而协作图显示任务和信息（对象）的交互方式。
2、状态图：显示对象的生命期。
3、活动图：描述工作流以及谁完成工作。
实现类模型：描述如何打包和实现解决方案。
1、组件图：指在解决方案中构建实际物理组件模型的方式。组件图可显示源代码组件、COM+组件及其它二进制和可执行文件。组件图还显示组件接口。
2、部署图：显示解决方案的部署方式，由处理器、设备和连接器构成。用来描述组件运行在哪些物理计算机上，以及解决方案如何与硬件交互。
用例图（use case diagram）
基本元素：
行动者（Actor）：有翻译为参与者、角色，感觉“角色”似乎更适合，更易于理解。微软中文VISIO中使用参与者。
关系（Relationship）
过程（Process）
包（Package)
系统边界（System Boundary）
关系用来指示行动者与哪些元素有关。行动者可能与其他行动者相关，也可与用例相关。行动者与用例相关，以表明它们从用例接收信息，或将输入或信息输给用例。
用例图包括三类关系：
communicates（通信关系）
uses（使用关系）
extends（扩展关系）
communicates关系表明行动者从用例接收信息，或向用例提供输入或信息。更可能的情况是，它表明行动者与用例交互，即行动者执行用例中包含的任务。communicates关系常被称为associations（关联关系）。
uses关系表示用例使用另一个用例提供的功能。
extends关系表明一个用例可使用另一个用例的功能。
uses和extends的区别：
extends表明的是一种可选决策
uses表明的是一种必选决策
顺序图（sequence diagram）
顺序图是以图形方式记录情景（scenarios）的方式。每当要记录一系列动作时，就可以构建顺序图。
顺序图包含元素：
对象（Objects）
激活（Activations）
消息（Messages）
注解（Notes）
对象是解决方案中的持久元素。它们可能是表、物理窗体或类。
激活是过程的执行，包括它等待嵌套过程执行的时间。
消息是对象之间执行的动作，消息标志着两个对象之间的通信，从而表示一个动作。
消息：连接到两个不同对象生命线的连接点。此类消息表示一个动作，与接收对象的方法或操作相关，接收消息的对象执行这个请求上的动作。消息可含传给要执行方法的参数。
消息（调用）：似乎与消息是一样的。
消息（返回）：将信息返给对象的消息。
消息（异步）：发送对象将消息发送给接收对象，并不等待接收对象的响应。
（这一段好难理解，还不如这一段：
简单消息(Simple Message) 表示简单的控制流。用于描述控制如何在对象间进行传 递,而不考虑通信的细节。
同步消息(Synchronous Message) 表示嵌套的控制流。
操作的调用是一种典型的同 步消息。
调用者发出消息后必须等待消息返回,只有当处理消息的操作执行完毕后,调用 者才可继续执行自己的操作。
异步消息(Asynchronous Message) 表示异步控制流。
当调用者发出消息后不用等待 消息的返回即可继续执行自己的操作。
异步消息主要用于描述实时系统中的并发行为。
简单消息和同步消息感觉总是理解不清楚。
）
协作图：显示对象及相应关联
协作图包含三个基本元素：对象、链接（对象之间）、消息
对象包含名称、状态和行为。
协作图与顺序图的区别是：顺序图基于时间，但协作图不强调时间。在记录过程涉及的任务时，将构建协作图。与顺序图相比，协作图更面向对象，因为它强调的是消息和对象，而在顺序图，因为按基于时间的方式记录过程，所以强调的是过程路径。
活动图：用来构建业务过程工作流的模型。业务过程是一个过程，描述业务如何执行特定任务。业务过程涉及到所有行动者和过程。
活动图由以下元素构成：
1、泳道（Swimlanes）
2、活动（Activities）
3、转换（Transitions）
4、状态（States）
5、决策（Decisions）
每个泳道表示一个对象，对象负责泳道中发生的一切。
泳道中包含活动。活动表示对象所实现的功能。
每个活动必须正好有一个传出转换。转换有两种类型：对象流（指示活动与该活动相关的对象之间的关系），控制流（显示一个活动触发另一个活动或转换到一个新对象状态）
对象可能处于多种不同状态。对象可能有状态，也可能无状态。当对象有状态时，若执行一个或多个操作 ，或设置一个或多个属性时，则对象从一种状态转换成另一种状态。
决策基于不同条件向不同方向发展。
行为类型UML模型中的部分元素与.net语言有映射关系，具体包括：
包——命名空间（或系统）
顺序图：对象——通常是.net类的一个实例
顺序图：消息——通常是.net类的一个方法（或事件、属性）
类图（Class diagram）：用来确定解决方案的（静态）结构。通过类图，可看到将实现哪些类、COM+组年和ASP页面等。也可看到这些元素的交互方式。
当开发人员开发解决方案时，类图将是主要的信息来源，从中可详细了解要开发的操作代码，以及数据类型、参数和命名空间等信息。如果开发人员需要一些有关解决方案行为的支持信息，则可查看行为图，如顺序图和活动图等。
类图的主要元素包括：包、类、关系。
对类图而言，包有两个功能：
1、可构建组合相关元素的包，以构建模型的普通视图。
2、可表示命名空间。
类包含名称（Name）、特性（Attributes）、操作（Operations）
关系包含三种基本关系：Binary association（二元关联）、Dependency（依赖）、Generalization（泛化）。
二元关联：指定两个类是相关的，即它们以某些方式交互。
依赖关系：指一个类对另一个类的构建依赖，但不维护到该类对象的永久链接。如果更改一个类，则将影响所有依赖于这个特定类的所有类。一般地，依赖关系表明：依赖类至少调用其所依赖类的一个操作。依赖关系对代码生成没有任何影响，但在项目引用中有所表现。
泛化关系：指示一个类是另一个类的子类，并继承基类的公共操作和特性。