在画类图的时候，理清类和类之间的关系是重点。类的关系有泛化(Generalization)、实现（Realization）、依赖(Dependency)和关联(Association)。其中关联又分为一般关联关系和聚合关系(Aggregation)，合成关系(Composition)。下面我们结合实例理解这些关系。
基本概念
类图（Class Diagram）: 类图是面向对象系统建模中最常用和最重要的图，是定义其它图的基础。类图主要是用来显示系统中的类、接口以及它们之间的静态结构和关系的一种静态模型。
类图的3个基本组件：类名、属性、方法。
泛化(generalization)：表示is-a的关系，是对象之间耦合度最大的一种关系，子类继承父类的所有细节。直接使用语言中的继承表达。在类图中使用带三角箭头的实线表示，箭头从子类指向父类。
实现（Realization）:在类图中就是接口和实现的关系。这个没什么好讲的。在类图中使用带三角箭头的虚线表示，箭头从实现类指向接口。
依赖(Dependency)：对象之间最弱的一种关联方式，是临时性的关联。代码中一般指由局部变量、函数参数、返回值建立的对于其他对象的调用关系。一个类调用被依赖类中的某些方法而得以完成这个类的一些职责。在类图使用带箭头的虚线表示，箭头从使用类指向被依赖的类。
关联(Association) : 对象之间一种引用关系，比如客户类与订单类之间的关系。这种关系通常使用类的属性表达。关联又分为一般关联、聚合关联与组合关联。后两种在后面分析。在类图使用带箭头的实线表示，箭头从使用类指向被关联的类。可以是单向和双向。
聚合(Aggregation) : 表示has-a的关系，是一种不稳定的包含关系。较强于一般关联,有整体与局部的关系,并且没有了整体,局部也可单独存在。如公司和员工的关系，公司包含员工，但如果公司倒闭，员工依然可以换公司。在类图使用空心的菱形表示，菱形从局部指向整体。
组合(Composition) : 表示contains-a的关系，是一种强烈的包含关系。组合类负责被组合类的生命周期。是一种更强的聚合关系。部分不能脱离整体存在。如公司和部门的关系，没有了公司，部门也不能存在了；调查问卷中问题和选项的关系；订单和订单选项的关系。在类图使用实心的菱形表示，菱形从局部指向整体。
多重性(Multiplicity) : 通常在关联、聚合、组合中使用。就是代表有多少个关联对象存在。使用数字..星号（数字）表示。如下图，一个割接通知可以关联0个到N个故障单。
聚合和组合的区别
这两个比较难理解，重点说一下。聚合和组合的区别在于：聚合关系是“has-a”关系，组合关系是“contains-a”关系；聚合关系表示整体与部分的关系比较弱，而组合比较强；聚合关系中代表部分事物的对象与代表聚合事物的对象的生存期无关，一旦删除了聚合对象不一定就删除了代表部分事物的对象。组合中一旦删除了组合对象，同时也就删除了代表部分事物的对象。
实例分析
联通客户响应OSS。系统有故障单、业务开通、资源核查、割接、业务重保、网络品质性能等功能模块。现在我们抽出部分需求做为例子讲解。
大家可以参照着类图，好好理解。
1． 通知分为一般通知、割接通知、重保通知。这个是继承关系。
2． NoticeService和实现类NoticeServiceImpl是实现关系。
3． NoticeServiceImpl通过save方法的参数引用Notice,是依赖关系。同时调用了BaseDao完成功能，也是依赖关系。
4． 割接通知和故障单之间通过中间类(通知电路)关联，是一般关联。
5． 重保通知和预案库间是聚合关系。因为预案库可以事先录入，和重保通知没有必然联系，可以独立存在。在系统中是手工从列表中选择。删除重保通知，不影响预案。
6． 割接通知和需求单之间是聚合关系。同理，需求单可以独立于割接通知存在。也就是说删除割接通知，不影响需求单。
7． 通知和回复是组合关系。因为回复不能独立于通知存在。也就是说删除通知，该条通知对应的回复也要级联删除。
经过以上的分析，相信大家对类的关系已经有比较好的理解了。大家有什么其它想法或好的见解，欢迎拍砖。
PS：还是那句话：以上类图用Enterprise Architect 7.5所画，在此推荐一下EA,非常不错。可以替代Visio和Rose了。Visio功能不够强大，Rose太重。唯有EA比较合适。
http://peterwei.iteye.com/blog/979557
UML用例图之泛化(generalization)、扩展(extend)和包含(include)关系-UML一波流系列讲解:
在画用例图的时候，理清用例之间的关系是重点。用例的关系有泛化(generalization)、扩展(extend)和包含(include)。其中include和extend最易混淆。下面我们结合实例彻底理清三者的关系。
基本概念
用例图（Use Case Diagram）:用例图显示谁是相关的用户，用户希望系统提供什么服务（用例），以及用例之间的关系图。用例图主要的作用是获取需求、指导测试。
用例图的4个基本组件：参与者(Actor)、用例(Use Case)、关系(Relationship)和系统。
泛化(generalization)：泛化关系是一种继承关系，子用例将继承基用例的所有行为，关系和通信关系，也就是说在任何使用基用例的地方都可以用子用例来代替。泛化关系在用例图中使用空心的箭头表示，箭头方向从子用例指向基用例。
扩展(extend)： extend关系是对基用例的扩展，基用例是一个完整的用例，即使没有子用例的参与，也可以完成一个完整的功能。extend的基用例中将存在一个扩展点，只有当扩展点被激活时，子用例才会被执行。 extend关系在用例图中使用带箭头的虚线表示(在线上标注<<extend>>)，箭头从子用例指向基用例。
包含(include)： include为包含关系，当两个或多个用例中共用一组相同的动作，这时可以将这组相同的动作抽出来作为一个独立的子用例，供多个基用例所共享。因为子用例被抽出，基用例并非一个完整的用例，所以include关系中的基用例必须和子用例一起使用才够完整，子用例也必然被执行。include关系在用例图中使用带箭头的虚线表示(在线上标注<<include>>)，箭头从基用例指向子用例。
实例需求场景
联通客户响应OSS。系统有故障单、业务开通、资源核查、割接、业务重保、网络品质性能等功能模块。现在我们抽出部分需求做为例子讲解。
需求1：客户响应用户和国际客服可以进行割接通知查询，在页面上有骨干割接查询、省间割接查询、省级割接查询的Tab。
分析：可以很容易看出割接查询和不同的割接子查询Tab之间是继承的关系，所以此处用泛化。用户和客户响应、国际客服也是继承的Actor关系。
需求2：客户响应用户和国际客服可以查看某条割接通知信息，可以在页面上导出割接信息Excel格式，可以查询和该条割接相关联的故障单信息。
分析：因为导出割接和查看相关联的故障单信息都是可选的，就是说我查看割接的时候，也可以不进行这些操作，所以这里用extend关系。也就是导出割接和查看故障单信息扩展了查看割接信息。
需求3：客户响应用户可以以网管系统为来源创建割接通知，在创建割接通知时可以保存为草稿，也可以直接发布割接通知。
分析：由于创建割接通知时，发布割接通知可以同时进行，也可以先存为草稿，所以发布割接是可选的，用extend就比较合适。也就是发布割接扩展了创建割接通知。
需求4：用户在进行业务开通、发布割接通知、发布重保通知及相关跨省的业务时需要进行数据分发。
分析：由于业务开通、重保、割接及其它跨省的业务都需要用到数据分发用例，我们可以将数据分发用例单独抽出来，供各业务使用，这里用include就比较合适。实际的系统中数据分发也是单独抽出来用jms和webservice实现的接口服务。
其它需求：可以看到删除割接通知和查看割接明细也可以做为割接通知查询用例的扩展，因查询列表时，一般可以选择继续查看明细或者删除操作。但在实际化图中，这两个extend可以不画，这里只是为了让大家理解概念。
用例图：大家可以参照着图，好好理解。
加深理解
我们再用另外一个场景的用例说明一下include和extend,因为就这两个玩意比较容易搞混。
销户：因为销户必需先进行账户结算，所以这里用include
停机提醒：有两个可选项，短信提醒和邮件提醒，所以用extend.
经过以上的分析，相信大家对三种关系已经有比较好的理解了。大家有什么其它想法或好的见解，欢迎拍砖。
PS：以上用例图用Enterprise Architect 7.5所画，在此推荐一下EA,非常不错。可以替代Visio和Rose了。Visio功能不够强大，Rose太重。唯有EA比较合适。