说明：以下文字来自《疯狂Java讲义》和《UML建模、设计与分析》

用例图

   用例图用于描述系统提供的系列功能。而每个用例则代表系统的一个功能模块。
   用例图包括用例（以一个椭圆表示，用例的名称放在椭圆的中心或椭圆下面）、角色（Actor，也就是与系统交互的其他实体，以一个人形符号表示）、角色和用例之间的关系（以简单的线段来表示），以及系统内用例之间的关系。用例图一般表示出用例的组织关系——要么是整个系统的全部用例，要么是完成具体功能的一组用例。

用例图

用例图主要在需求分析阶段使用，用于描述系统实现的功能，方便与客户交流，保证系统需求的无二性，用实例图表示系统外观，不要指望用例图和系统的各个类之间有任何联系。

类图

 类图表示系统中应该包含哪些实体，各实体之间如何关联。

类在类图上使用包含三个部分的矩形来描述，最上面的部分显示类的名称，中间部分包含类的属性，最下面的部分包含类的方法。下图显示了类图中类的表示方法。

类图中类的表示方法

UML中Public类型用符号“+”表示，Private类型用符号“-”表示，Protected类型用符号“#”表示

除了上图中提供的每一个参数名及其数据类型外，还可以指定参数子句in、out或者inout。其中，in是默认的参数子句，通过值传递的参数使用in参数子句，或者不使用任何参数子句。通过值传递参数意味着把数据的副本发送到操作，因而操作不会改变值的主备份。如果希望修改传递到操作的参数值的主备份，需要使用inout类型的参数子句标记参数，这意味着值通过引用传递，操作中任何对参数值的修改也就是对变量主备份的修改。除此之外，还有一种out参数子句，使用该参数子句时，值不是被传递给操作，而是由操作把值返回给参数。

约束和注释在类的标记中说明类的职责是消除二义性的一种非形式化的方法，而使用约束则是一种形式化的方法。约束指定了类应该满足的一个或者多个规则。约束在UML规范中是用由花括号括起来的文本表示的。如下图为Teacher类所添加的约束。

约束

除约束外，还可以在类图中使用注释，以便为类添加更多的说明信息，注释可以包含文本和图形。如下图所示为Teacher类所添加的注释。

注释

类图除了可以表示实体的静态内部结构之外，还可以表示实体之间的相互关系。

类之间有三种基本关系：

• 泛化（与继承同一个概念）
• 依赖和实现
• 关联（包括聚合、组合）

泛化

泛化关系用一个末端带有空心三角形箭头的直线表示，有箭头的一端指向父类。 泛化

依赖和实现

依赖

依赖关系用一个一端带有箭头的虚线表示 依赖

UML规范中定义了4种基本的依赖类型，它们分别是使用（Usage）依赖、抽象（Abstraction）依赖、授权（Permission）依赖和绑定（Binding）依赖。（不展开了。。。）

实现

实现关系（Realization）用于规定规格说明与其实现之间的关系、它通常用在接口以及实现该接口的类之间，以及用例和实现该用例的协作之间。

UML中将实现关系表示为末端带有空心三角形的虚线，带有空心三角形的那一端指向被实现元素。 实现

关联

关联和属性很像，关联和属性的关键区别在于：类里的某个属性引用到另外一个实体时，则变成了关联。

• 单向关联
  　通常是一个类里面有的属性的类型是另一个类
  符号表示：
  

  　　 类A里面存在属性，该属性类型是类B

• 双向关联
  　　通常是关联双方都存在对方类类型的属性
  符号表示：
  

  　　 关联双方都存在对方类类型的属性

聚合

聚合（Aggregation）关系是在关联之上进一步的紧密耦合，用来表明一个类实际上不拥有但可能共享另一个类的对象。聚合关系是一种特殊的关联关系，它表示整体与部分的关系，且部分可以离开整体而单独存在。在聚合关系中，一个类是整体，它由一个或者多个部分类组成。当整体类不存在时部分类仍能存在，但是当它们聚集在一起时就用于组成相应的整体类。例如，车和轮胎就可以看作是聚合关系，车为整体，轮胎为部分，轮胎离开车后仍然可以存在。 聚合

组合

组合关系和聚合关系很相似，都是整体与部分的关联关系，但是它们之间的不同之处在于部分不能离开整体而单独存在，当整体类被销毁时，部分类将同时被销毁。

组合

组件图（不是很清楚，但好像也不是很重要）

组件图也叫构件图，提供系统的物理视图，它的用途是显示系统中的软件对其他软件组件（例如，库函数）的依赖关系。

组件图通常包含组件、接口和Port等图元。使用圆圈代表接口，使用位于组件边界上的小矩形代表Port。组件的接口表示它能对外提供的服务规范。

没有接口的组件
实现接口的组件