参考：刘立嘉老师的统一建模语言课程的课件
关联关系
参与者与用例之间是关联关系，表示参与者与用例之间具有使用，交互信息的关联。
泛化关系
用例与用例之间存在一般与特殊的关系。
包含关系
两个用例之间，一个用例(基本用例)的行为包含了另外一个用例(包含用例)的行为。
包含关系用依赖关系的<<include>>构造型来表示。
扩展关系表示基本用例在扩展点要增加新行为或功能，扩展到新用例。扩展关系用依赖关系的<<extend>>构造型来表示。
类似于泛化关系，但添加了一些新规则
扩展用例可以在基用例之上添加新的行为，但是基用
例必须声明某些特定的“扩展点”，并且扩展用例只能在这些扩展点上扩展新的行为。
用例图用来描述软件需求模型中的系统功能，通过一组用例可以描述软件系统能够给用户提供的功能。用例图可以作为整个系统开发过程中的开发依据，指导和驱动其他模型。
包含关系是一种(因子化)重组关系。当几个用例具有共同的行为时，这个共同行为可以抽象为一个公共用例。
一个特殊用例包含一个公共用例作为其一部分 时，将完全包含那个公共用例的行为，即整个公共用例被使用。
包含的可视化表示：由用例A连向用例B，表示用例A中包含了用例B中的行为或功能。
扩展与包含相似，从几个用例中抽取公共行为并放入一个单独用例中作为基本用例，然后增加新的特殊情况作为其基本用例的扩展。
在扩展情况下，一个给定的执行者将执行基本用例及其所有的扩展。对于包含关系，通常执行者不会和公共用例相关联。
扩展的可视化表示：由用例A连向用例B, 表示用例B描述了一项基本需求，而用例A则描述了该基本需求的特殊情况，即一种扩展。（关键在于拓展点）
下列规则可用来判断应采用包含关系或扩展关系u包含：当一个通用的用例可以成为几个特殊的用例的组成部分时用包含关系。因此，当在两个或更多的用例中出现重复描述而又想避免这种重复时，采用包含关系。
扩展：当一个用例是另一个一般化用例的特例时，用扩展关系。因此，当描述一般行为的变化时，采用扩展关系。
要说明扩展点
关联的表示：
用一条无向线段表示，是一种双向关系。例如客户和订单的关联：从客户看，订单是他提交的；从订单看，它有一个客户。 § 用一条有向线段表示，是一种单向关系
关联的命名：可以用动词词组或名词命名。但只要这个关联的含义明确，则可省略这个名字。
关联的两端与类之间(或与类的实例之间)的接口表示该类(或该类的实体)在这个关联中的行为，称之为角色。
每个关联有两个角色。例如，对于客户和订单之间的关联是：客户和订单。
角色可具有多元性(一个角色可以有多个对象来扮演)。例如，每个客户对象可以有零或多个订单对象。
多元性的表示。1 表示 1..1 ；*代表零到无穷；0..1是选择符，表示没有或仅有1个；一个数；一个范围；数字和范围不连续的组合。
箭头表示导航特性。如果只在一个方向上有导航表示，称作单向关联。如果在两个方向上都有导航表示，称作双向关联。如果不带箭头，表示未知或尚未确定。
单向关联时，说明模型中的订单指出它是由哪个客户发出的；实现模型中的订单包含一个指向客户的指针。
对双向关联的限制是两个角色必须互逆。
继承是实现泛化的一种机制。在这种机制中，超类的任何一个子类都须具有其超类的所有行为：
不仅要求其操作界面在文法上一致，而且要求其行为在语义上一致。
当子类中的一个操作重载其超类中相应的操作时，必须确保它提供与超类中的操作相同的服务(内容可以更多或更具体)。
如没有证明子类的行为是否与父类相同，就试图用继承来实现新类中的行为，当两者不一致时，会导致难以预测的错误。
类图和对象图小结
类和对象的表示法
（1）名称；（2）属性；（3）行为；
类之间的各种关系
（1）继承：子类继承了超类的所有属性和行为；
（2）关联：两个不同类之间关联，可以单向或双向；
（3）聚合：强关联，整体与部分的生命周期分开；
（4）组合：强聚合，整体与部分的生命周期相同；
三个概念层次
（1）概念层；（2）说明层；（3）实现层
类图的建模分析步骤
（1）寻找出需求中的名词(候选对象)。
（2）合并含义相同的名词，排除范围以外的名词，并寻找隐含
的名词。
（3）去掉只能作为类属性的名词。
（4）剩下的名词就是要找的分析类（候选类)。
（5）根据常识、问题域、系统责任确定该类的属性。
（6）补充该类动态属性，如状态、对象间联系（如聚合、关联）
等属性。
（7）从需求中的动词、功能或系统责任中寻找类的操作（候选
操作）。
（8）从状态转换，流程跟踪、系统管理等方面补充类的操作。
（9）对所寻找的操作进行合并、筛选。
（10）对所寻找的操作在类间进行合理分配（职责分配），形成
每个类候选操作。
（11）补充每个类的的分析文档，为类的进一步设计打下基础。