一. UML的关系

在建立抽象的过程中会发现类很少独立存在，大多数类都以某种方式彼此协作。因此，在为系统建模时，不仅需要从问题域的词表中抽象出类和对象，还需要描述这些抽象间的关系。

1. 依赖关系（Dependency Relationship）

依赖关系描述了类之间的使用关系。

如果一个模型元素的变化会影响另一个模型元素（这种影响是不可逆的），那么就说在这两个模型元素之间存在依赖关系。例如，有两个元素X、Y，如果修改元素X的定义可能会引起元素Y的定义的修改，则称元素Y依赖于元素X。

依赖关系的UML符号表示是带箭头的虚线，指向被依赖的模型元素。

2. 类属关系（Generalizatin Relationship）

类属关系描述了类之间“一般”与“特殊”的关系。

在解决复杂性问题时，通常需要将具有共同特性的元素抽象成类别，并通过增加其内涵而进一步分类。例如，学生可以分为大学生、中学生和小学生，火车可以分为客运列车和货运列车。在面向对象方法中，将前者称为一般元素、基类元素或父类元素，将后者成为特殊元素或子元素。子元素继承父元素所具有的结构和行为，通常子元素还要添加新的结构和行为，或者修改父元素的行为。

在UML中，类属关系用带空心箭头的实线表示，箭头指向父元素。

3. 关联关系（Association Relationship）

关联关系描述了对象间的结构关系。

关联关系表示两个类之间存在某种语义上的联系。它是一种结构关系，规定了一种事物的对象可以与另一种事物的对象相连。例如，雇员为公司工作，一个公司有很多部门，就可以认为雇员和公司、公司和部门之间存在某种语义上的联系，在类图模型中，就可以在类Employee和类Company、类Company和类Department之间建立关联关系。

关联关系的UML符号表示是一条实线。

4. 实现关系（Realize Relationship）

实现关系是分类器之间的语义关系，一个分类器规定合同，另一个分类器保证实现这个合同。大多数情况下，实现关系北用来规定接口和实现接口的类或组件之间的关系。接口是操作的集合，这些操作用于规定类或组件的服务，也就是说，接口规定了类或组件必须实现的合同。一个接口可以被多个类或组件实现，一个类或组件也可以实现多个接口。接口的使用将操作的接口和操作的实现分离开来。当类或组件实现一个接口时，它意味着类或组件实现了接口的所有操作，完全遵守接口所建立的客户之间的协议，并响应客户使用接口中的操作所发出的消息。

实现关系的UML符号表示用带有空心箭头的虚线表示。

二. UML的符号

1. 注释（Note）

2. 参与者（Actor）

参与者代表与系统交互的人、硬件设备、或另一个系统。尽管可以在模型中使用参与者，但参与者并不是软件系统的组成部分，参与者存在于系统的外部。一个参与者可以：

只向系统输入信息。

只从系统接受信息。

既可以输入信息给系统，也可以接收系统的输出信息。

3. 用例（Use Case）

用例规定了系统或部分系统的行为，它描述了系统所执行的动作序列集，并为执行者产生一个可供观察的结果。也就是说，用例是：

系统行为的模板。

参与者与系统所执行的相关的动作序列。

交付值等给参与者。

4. 协作（Collabration）

协作命名了彼此合作完成某个行为的类、接口和其他元素的群体。协作可以用来规定用例和操作的实现，微系统体系结构上的重要机制建模。

协作有两个方面：

结构部分：结构部分规定了合作执行所命名的协作的类、接口和其他元素。

行为部分：行为部分规定了这些元素如何交互作用的动态方面。

5. 类（Class）

类是面向对象系统中最基本的组成元素。类是一种最重要的分类器（Classifier），分类器是描述结构和行为特性的机制，它包括类、接口、信号、组件、节点、用例和子系统。

类是分享同样的属性、操作、关系和语义的对象的集合。类是现实世界中的事物的抽象，当这些事物存在于真实世界中时，它们是类的实例，并被成为对象。类可以实现一个或多个接口。

类描述了一类对象的属性（Attibute）和行为（Behavior）。在识别类时，要与领域专家合作，对问题域进行仔细深入地分析，抽象出问题域中的概念，定义其含义及相互关系，从而抽象出系统中的类，并用领域中的术语为类命名。

类的UML符号是划分成3个格子的长方形。顶部的格子放类名，中间的格子放类的属性、属性的类型和值（属性的初始值），下面的格子放方法、方法的参数表和返回类型。

在不同的视图中给出类的UML表示时，可以根据需要选择隐藏全部或部分的属性格或方法格。

6. 对象（Object）

对象代表了类的一个特定实例。对象具有身份（Identity）和属性值（Attribute Values）。

实例和对象基本上是同义词，它们常常可以互换使用。实例是抽象的具体表示，方法可以作用于实例，实例可以有状态来存储方法的结果。

7. 消息（Message）

消息是对象间的通信，它传达了要执行动作的信息，它能触发事件。接收到一个消息通常被认为是一个事件。通常，当一个对象调用另一个对象中的方法时，即完成了一次消息传递。

消息的UML符号表示是带箭头的实线。

8. 接口（Interface）

接口是用来规定类或组件服务的操作的集合。与类不同，接口没有规定任何结构，也没有规定任何实现。

9. 包（Package）

包是一个用来将模型单元分组的通用机制。可以将一个系统看做一个单一的、高级的包。

10. 组件（Component）

组件代表了一个接口定义良好的软件模块。组件是系统的一个物理的、可替代的部分，它遵循接口定义，并为接口提供了实现。组件是其他逻辑单元的物理封装，这些被封装的逻辑单元可以是类、接口、协作等。

组件的特点如下：

（1）组件是物理的，它存在，不是概念。

（2）组件是可替代的。

（3）组件是系统的一部分。

组件与类的区别：

（1）类代表了逻辑的抽象；组件是物理的、是可以存在于现实世界中的。也就是说，组件可以在节点上存在，而类不能。

（2）组件代表了其他逻辑单元的物理封装，与类的抽象实在不同的层次上。

（3）类本身有属性和操作。而通常，组件的操作只能通过接口来访问。

11. 状态（State）

12. 跃迁（Transitions）

13. 判定（Decision）

14. 同步条（Synchronization Bars）

15. 活动（Activities）

16. 节点（Node）和设备（Device）

三. 视图（View）

1. 用例视（Use Case View）

系统的用例视通过用例描述了可以为最终用户、分析人员和测试人员所看见的系统行为。视的静态方面由用例图捕捉；动态方面由交互作用图、状态图和活动图捕捉。

2. 设计视（Design View）

系统的设计视包括形成问题域词汇表和解决方案的类、接口和协作，支持系统的功能需求，也即系统应该提供给最终用户的服务。设计视的静态方面由类图和对象图捕捉；动态方面由交互作用图、状态图和活动图捕捉。

3. 过程视（Process View）

系统的过程视包括形成系统的并发和同步机制的线程和过程，描述了系统的性能、可扩展性和总处理能力。过程视的静态方面由类图和对象图捕捉；动态方面由交互作用图、状态图和活动图捕捉。

4. 实现视（Implementation View）

系统的实现视包括用于组装物理系统的组件和文件，主要描述了系统版本的配置管理。系统版本是由独立的组件和文件构成的可运行系统。实现视的静态方面由组件图捕捉；动态方面由交互作用图、状态图和活动图捕捉。

5. 配置视（Deployment View）

配置视包括了构成用于运行软件系统的系统硬件拓扑的节点，主要描述了物理系统组成部分的分布、交付和安装。配置视的静态方面由配置图捕捉；动态方面由交互作用图、状态图和活动图捕捉。