一、UML图
UML提供了9种不同的模型图，用来对系统建模。
类图、
对象图、
用例图、
序列图、
协作图、
状态图、
活动图、
构件图、
部署图。
UML的设计视图包含了类、接口和协作，其中，设计视图的静态方面有类图和对象图表现；动态方面由交互图（序列图和协作图）、状态图和活动图表现。
1、类图
描述系统的对象结构，它们显示构成系统的对象类以及这些对象类之间的关系。
类图是：静态设计视图。
2、对象图
对象图类似类图，但并不描述对象类，它们对实际的对象实例建模—显示实例属性的当前值。
对象图是：静态设计视图。
3、用例图
用例图以图形化的方式描述系统与外部系统及用户的交互。换句话说，它们以图形化的方式描述了谁将使用系统，以及用户期望以什么方式与系统交互。
4、序列图
是场景的图形化表示，描述以时间顺序组织的对象之间的交互活动。
序列图：动态方面进行建模。
5、协作图
或称通信图。强调收发消息的对象的结构组织，类似序列图，但重点不是消息的时间顺序，它以一种网状格式表现对象之间的交互。
协作图和序列图称为：交互图。
协作图：动态方面进行建模。
6、状态图
对一个特定对象的动态行为建模，说明一个对象的生命周期---对象可以
经历各种状态，以及引起对象从一个状态向另一个状态转换的事件。
状态图：动态方面进行建模。
7、活动图
活动图是一种特殊的状态图，它展示了在系统内从一个活动到另一个活动的流程。
活动图：动态方面进行建模。
8、构件图
用来描述系统的物理结构，它可以用来显示程序代码如何分解模块。展示一组构件之间的组织和依赖。
构件图：静态实现视图。
9、部署图
描述系统中硬件和软件的物理架构，它描述构成系统架构的软件构件，处理器和设备。
它与构件图相关，通常一个节点包含一个或多个构件。
部署图：静态实施视图。
二、UML叙述
UML文档仅仅是设计与开发人员采用UML语言进行系统分析与设计的结果，并没有给出如何进行开发和采用何种开发流程，同样也不指导如何进行面向对象设计。
UML文档描述了面向对象分析与设计的结果。
三、UML关系
UML有4种关系：依赖、关联、聚集（关联一种）、组合（聚集的另一种形式）、泛化（继承）、实现
1、依赖
1）、------->或------是依赖。
2）、其中一个事物（独立事物）发生变化会影响另一事物（依赖事物）的语义。
3）、例如自行车bicycle和打气筒pump
Bicycle类和Pump类之间是依赖关系，在Bicycle类中无需定义
Pump类型的变量。Bicycle类的定义如下：
public class Bicycle{
/** 给轮胎充气*/
public void expand(Pump pump){
pump.blow();
}
}
Bicycle类调用Pump，但是并不是Pump p=new Pump();的那种实例
化的调用，它依赖的是现在已存在一个对象，而不是实例化的一
个新对象。
Bicycle -------> Pump。Bicycle 依赖Pump。
2、关联
1）、——>或——是关联。
2）、两个相对独立的系统，当一个系统的实例与另一个系统的一些特定实例存在固定的对应关系，这两个系统之间为关联关系。
给定一个连接两个类的关联，可以从一个类的对象导航到另一个类
的对象，反之亦然。通过一个指示的单向箭头修饰关联，可以显示
地描述导航的方向。
3）、[A] —-c—>[B]，正确的描述是：类A的实例中包含了对类B的实例的引用。
导航方向A——>B，说明从类A的实例导航到类B的实例，因此类A中必然包含一个对类B的实例的引用。图C表示的是关联一端的角色名称。
4）、例如客户和订单，每个客户对应一个特定订单；再例如公司和员工，每个公司对应一些特定的员工，每个员工对应一特定公司；例如自行车和主人。
Person类与Bicycle类之间存在关联关系，这意味着在Person类中需要定义一个Bicycle类型的成员变量。以下是Person类的定义：
public class Person{
private Bicycle bicycle; //主人的自行车
public Bicycle getBicycle(){ return bicycle; }
public void setBicycle(Bicycle bicycle){ this.bicycle=bicycle; }
/** 骑自行车去上班*/
public void goToWork(){ bicycle.run(); }
}
5）、关联关系是类与类之间的联接，它使一个类知道另一个类的属性和方法。关联
关系包括单向关联、双向关联、聚合关联、合成关联、反射关联关系。6）、多重度。
UML中关联的多重度是指一个类的实例能够与另一个类的多少个实例相关联。
关联表示了对象间的结构关系，在很多建模问题中，说明一个关联的实例中有多少个互相连接的对象是很重要的。这个“多少”被称为关联角色的多重度。
指定关联一端的多重度，就是说明：在关联另一端的类的每个对象要
3、聚集
1）、——<>是聚集。
2）、是一种特殊类型的关联，它描述了整体和部分间的结构关系。某个类是另外某个类的一部分。在一个聚合关系中，子类实例可以比父
类存在更长的时间
3）、车和轮胎间的聚合关系的例子
4）、当系统A被加入到系统B中，成为系统B的组成部分时，系统B和系统A之间为聚集关系。例如自行车和它的响铃、龙头、轮胎、钢
圈以及刹车装置就是聚集关系，因为响铃是自行车的组成部分。而
人和自行车不是聚集关系，因为人不是由自行车组成的，如果一定
要研究人的组成，那么他应该由头、躯干和四肢等组成。由此可见，
可以根据语义来区分关联关系和聚集关系。
5）、聚集关系和关联关系的区别还表现在以下方面：
A、对于具有关联关系的两个对象，多数情况下，两者有独立的生
命周期。比如自行车和他的主人，当自行车不存在了，它的主
人依然存在；反之亦然。
B、对于具有聚集关系（尤其是强聚集关系）的两个对象，整体对
象会制约它的组成对象的生命周期。部分类的对象不能单独存
在，它的生命周期依赖于整体类的对象的生命周期，当整体消
失，部分也就随之消失。比如小王的自行车被偷了，那么自行
车的所有组件也不存在了。
6）、不过，在用程序代码来表示关联关系和聚集关系时，两者比较相例如自行车Bicycle与响铃Bell的聚集关系。
public class Bicycle{
private Bell bell;
public Bell getBell(){return bell;}
public void setBell(Bell bell){this.bell=bell;}
/** 发出铃声*/
public void alert(){bell.ring();}
}
在Bicycle类中定义了Bell类型的成员变量，Bicycle类利用自身的bell
成员变量来发出铃声，这和在Person类中定义了Bicycle类型的成员
变量，Person类利用自身的bicycle成员变量去上班很相似。
4、组合
1）、——<黑>是组合。
2）、组合聚合关系是聚合关系的另一种形式，但是子类实例的生命周期依赖于父类实例的生命周期。在图13中，显示了Company类和
Department类之间的组合关系，
注意组合关系如聚合关系一样绘制，不过这次菱形是被填充的。
在UML中，关联，依赖，聚集，组成的联系十分紧密，不容易区分，本文试图用通俗的语言来讲解这四种关系的区别。
关联，即是发生关系，一个类A关联类B，说明类A中的字段（或属性）中含有类B的实例链接（在C++中为指针），类B也可以关联类A，他们是对等的，没有主次之分。
依赖，类A依赖类B，说明类A中用到了类B，这个“用到”，比关联的程度更浅，比如，在局部变量（函数中的变量和函数参数）中用到了类B，也可能是类A用到了类B的静态函数。
聚集：聚集也是一种关联，但是对于关联来讲，关联的双方都是对等的，没有主次之分，在聚集中，则有主次之分，“主”的一方只能有一个。那计算机来说，“计算机”是一个对象，他就是“主”，而“硬盘”，“主板”，“显示器”等等则是“次”的一方，“硬盘”，“主板”，“显示器”聚集成“计算机”，他们只是聚集的关系，主板完蛋了，并不影响显示器，所以大家可以理解为聚集中的对象，即是一个整体，又各自独立。
组成：组成是一种特殊的聚集（那当然也是关联喽），拿桌子来说吧，桌子有桌面和桌腿组成，然桌面没有了或桌腿没有了，都不能称之为桌子，这个意思就是说，对于组成对象的个部分来讲，他们有一个有机的整体，不可分割的整体。桌子对象（主体对象）要负责桌面，桌腿（“次”对象，主次之分的“次”）的生命
周期。拿C++语言来讲，桌子对象内部含有桌面对象和桌腿对象的对象实例，这可不是指针喽，但在“聚集”中是指针，这也就是聚集和组成的区别。
5、泛化
1）、——l>是泛化。
2）、泛化（generalization）是一种特殊/一般关系，在其中特殊元素（子元素）基于一般元素（父元素）而建立。用这种方法，子元素共享
了父元素的结构和行为（也就是说“子元素”继承了“父元素”）。
3）、表示类与类之间的继承关系，接口与接口之间的继承关系，或类对接口的实现关系。一般化关系是子类指向父类的，或从实现接口的
类指向被实现的接口，与继承或实现的方向相反。如下图所示：
6、实现
1）、-------l>是实现。
2）、实现（realization）是类目之间的语义关系，其中的一个类目指定了
由另一个类目保证执行的合约。在两种地方会遇到实现关系：一种是在
接口和实现它们的类或构件之间；另一种是在用例和实现它们的协作之
间。
四、UML构件概念
构件的定义:构件是系统的可替代的物理部分,它表示的是实际的事物.构件是定义了良好接口的物理实现单元.它是系统中可以替代的部分.每个构件体现了系统设计中的特定类的实现.良好定义的构件不直接依赖于其它构件而依赖于构件所支持的接口.
在这种情况下,系统中的一个构件可以被支持正确的接口的其它构件所替代.
接口是被软件或硬件所支持的一个操作集.通过使用命名的接口,可以避免在系统的各个构件之间直接发生依赖关系.有利于新构件的替换.
五、大题知识点
第四章P75
1、补充类的属性。
2、判断类之间的关系，补充。
3、根据序列图，判断实例化的例子个数。
第六章P125
4、补充父类公共属性
5、填写关联的多重度
6、识别类应有的方法
第八章P181
7、识别多重度
8、选择类适合的方法
9、判断关联和聚集的联系和区别
第十章P235
10、补充关系图中适合的类名
11、填写类的属性
12、多重度补充
总结大题考UML考以下知识点：
1、给出类，填写类的属性，例如父类的公共属性等。这类题只需细读题目都可
以找出。记住答题的时候按照题目给出的名词进行填写，不要自己画蛇添足。
2、给出类，选择类适合的方法。同上，细读题目。如果在序列图里面查找对应
方法，要看清楚，如果有返回箭头虚线的，则方法名应该选择Get***什么的，例如P181页的题目。如果没有箭头虚线返回，则应该是Create***或者Add***，是属于一个无需返回值的操作动作。
3、给出类，画类与类之间的关系。这类题目要熟读说明，区分出继承关系，关
联关系和聚集关系。普遍是这几种关系。
继承关系：父类子类
聚集关系：部分整体，整体决定部分的生命周期，部分生命周期之间无必然联系。
关联关系：实在不行就关联吧。
组合关系：部分整体，整体决定部分的生命周期，部分生命周期也影响部分的生命周期，就是说部分之间有关联关系存在。没怎么出现过。
依赖关系和实现关系。。。目前还没看到实际出现过。
4、给出关系，画出应该填写的类名。
这种题一般还是比较好做，因为有上下关系给出，加上说明和已出现的类名，可以参考出来应该填写什么答案。
5、给出UML关系图，填写多重度。
参考说明，这种题不难，不过要懂得多重度的各种表示方式。
例如：
一个CustomerSystem有0个或多个Customer 则如下面表示：[CustomerSystem]———0..*>[Customer]。
一个Customer只存在1个CustomerSystem里面则如下表示：[CustomerSystem]1————>[Customer]。
所以综合可得出CustomerSystem和Customer的多重度为：[CustomerInfomationSystem]1————0..*>[Customer]
6、根据序列图，判断实例化的例子个数。
难度比较大，需要充分掌握一些实际经验来判断。外加猜吧。
7、理论知识回答。
看运气咯。