uml类图

[size=medium][b]UML类的表示[/b][/size]
类的命名尽量应用领域中的术语，应明确、无岐义，以利于相互交流和理解。类的属性、操作中的可见性使用＋、 # 、－分别表示 public 、 protected 、 private;若未用修饰符则可以理解为Java的friendly;

[size=medium][b]UML 类之间的几种常见关系[/b][/size]
[list]
[*]关联关系(association)
[*]聚合关系(aggregation)
[*]组合关系(compostion)
[*]依赖关系(dependency)
[*]泛化关系(Generalization)
[/list]
Generalization(泛化)表现为继承或实现关系(is a)。具体形式为类与类之间的继承关系，接口与接口之间的继承关系，类对接口的实现关系;

Association关联关系表现为变量(has a )。类与类之间的联接，它使一个类知道另一个类的属性和方法。例如如果A依赖于B，则B体现为A的全局变量。关联关系有双向关联和单向关联。双向关联：两个类都知道另一个类的公共属性和操作。单向关联：只有一个类知道另外一个类的公共属性和操作。大多数关联应该是单向的，单向关系更容易建立和维护，有助于寻找可服用的类。

Aggregation(聚合关系) 是关联关系的一种，是强的关联关系。聚合关系是整体和个体的关系。普通关联关系的两个类处于同一层次上，而聚合关系的两个类处于不同的层次，一个是整体，一个是部分。同时，是一种弱的“拥有”关系。体现的是A对象可以包含B对象，但B对象不是A对象的组成部分。具体表现为，如果A由B聚合成，表现为A包含有B的全局对象，但是B对象可以不在A创建的时刻创建。

Composition(组合关系)是关联关系的一种，是比聚合关系强的关系。它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期。Composition(组合关系)是一种强的“拥有”关系(组合关系是“contains－a”关系)，体现了严格的部分和整体的关系，部分和整体的生命周期一致。如果A由B组成，表现为A包含有B的全局对象，并且B对象在A创建的时刻创建;

Dependency(依赖关系)表现为函数中的参数(use a)。是类与类之间的连接，表示一个类依赖于另一个类的定义，其中一个类的变化将影响另外一个类。例如如果A依赖于B，则B体现为局部变量，方法的参数、或静态方法的调用;

其中Aggregation(聚合关系)、Composition(合成关系)属于Association(关联关系)，是特殊的Association关联关系;


(以下引用自[http://www.uml.org.cn/oobject/201007275.asp])
UML的最终目标是识别出所有必须的类，并分析这些类之间的关系，类的识别贯穿于整个建模过程，分析阶段主要识别问题域相关的类，在设计阶段需要加入一些反映设计思想、方法的类以及实现问题域所需要的类，在编码实现阶段，因为语言的特点，可能需要加入一些其他的类。

[b][size=medium]建立类图的步骤：[/size][/b]

（1）研究分析问题领域确定系统需求。
（2）确定类，明确类的含义和职责、确定属性和操作。
（3）确定类之间的关系。

类的识别是一个需要大量技巧的工作，寻找类的一些技巧包括：名词识别法；根据用例描述确定类；使用CRC分析法；根据边界类、控制类、实体类的划分来帮助分析系统中的类；参考设计模式确定类；对领域进行分析或利用已有领域分析结果得到类；利用RUP中如何在分析和设计中寻找类的步骤。

[b]1. 名词识别法：[/b]
这种方法的关键是识别系统问题域中的实体。对系统进行描述，描述应该使用问题域中的概念和命名，从系统描述中标识名词及名词短语，其中的名词往往可以标识为对象，复数名词往往可以标识为类。

[b]2. 从用例中识别类：[/b]
用例图实质上是一种系统描述的形式，自然可以根据用例描述来识别类。针对各个用例，可以提如下的问题辅助识别：

用例描述中出现了那些实体？
用例的完成需要哪些实体合作？
用例执行过程中会产生并存储哪些信息？
用例要求与之关联的每个角色的输入是什么？
用例反馈与之关联的每个角色的输出是什么？
用例需要操作哪些硬设备？

在面向对象应用中，类之间传递的信息数据要么可以映射到发送方的某些属性，要么该信息数据本身就是一个对象。综合不同的用例识别结果，就可以得到整个系统的类，在类的基础上，我们又可以分析用例的动态特性来对用例进行动态行为建模。

[b]3. 使用CRC分析法：[/b]
CRC（Class,Responsibilities,Collaboration）卡的最大价值在于把人们从思考过程模式中脱离出来，更充分的专注于对象技术。CRC卡允许整个项目组对设计做出贡献。参与系统设计的人越多，能够收集到的好主意也就越多。因为CRC会议是大家全力参与的，通常只需要很少的有类名的卡片，实际上没有写出完整的卡片。CRC会议进行中，一些人模拟系统和对象交流，把消息传给其他的对象。通过一步步处理，问题很容易地被解决。它由三部分组成：类(Class)、职责(Responsibility)、协作(Collaborator)。下面是一个CRC卡的示例：

类名
[table]
|职责1|职责1的协作|
|职责2|职责2的协作|
|……|…… |
[/table]
职责是类需要知道或做的任何事物。这些职责是类自身所知的知识，或类在执行时所需的知识。协作是指为获取消息，或协助执行活动的其他类。创建CRC模型需要下面的步骤。

1) 建立团队，包括客户、设计人员、分析人员和一个导引者。如果没有那么多人，那么可以是客户和你自己两个人。
2) 找出需求中存在的名词和名词词组，特别注意复数（通常是集合），他们对应的单数才是。把你第一次想到的所有概念都写在白板或纸上。不管看起来这些概念是如何荒谬，把他们都写下来。
3) 筛选。把对象分为三类，核心对象（必须首先实现），可选的（目前不能确定），以及不需要的对象。这之前最好确定一下你的项目范围。某些不属于本项目范围的对象可以使用轻量的adapter或proxy实现。这里可以加入对分析、设计模式的考虑和应用。
4) 建卡。取出CRC卡，把核心类写在每一张卡上，把可选的类和排除的类分别写在不同的纸上。
5) 角色扮演。最好是一个团队执行，一个人很难做。每个人负责几个类。对每一个Use case其中的情景。导引者指定从某一个人的类开始，某一个人看一看自己能够独立完成，如果不能完成，大家看一看手中的类，谁能完成，就站起来，宣布自己能够完成，以致继续这个过程，每个人完成自己的职责就坐下。在这过程中不断修改类的责任，并写下协作者的名字。

[b]4. 根据边界类、控制类、实体类帮助分析系统中的类[/b]

UML中类有三种主要的版型：边界类、控制类和实体类。引入边界类、控制类及实体类的概念有助于分析和设计人员确定系统中的类。

边界类位于系统与外界的交界处，窗体、报表、以及表示通讯协议的类、直接与外部设备交互的类、直接与外部系统交互的类等都是边界类。通过用例图可以确定需要的边界类，每个Actor/Use Case对至少要一个边界类，但并非每个Actor/Use Case对要唯一的边界类。

实体类保存要放进持久存储体的信息。持久存储体就是数据库、文件等可以永久存储数据的介质。实体类可以通过事件流和交互图发现。通常每个实体类在数据库中有相应的表，实体类中的属性对应数据库表中的字段。

控制类是控制其他类工作的类。每个用例通常有一个控制类，控制用例中的事件顺序，控制类也可以在多个用例间共用。其他类并不向控制类发送很多消息，而是由控制类发出很多消息。

[b]5. 领域进行分析[/b]

建立类图的过程就是对领域及其解决方案的分析和设计过程。类的获取是一个依赖个人创造力的过程，有时需要和领域专家合作，对研究领域进行仔细分析，抽象出领域中的概念，定义其含义及相互关系，分析出系统类，并用领域中的术语为类命名。领域分析是：通过对某一领域中的已有应用系统、理论、技术、开发历史等的研究，来标识、收集、组织、分析和表示领域模型及软件体系结构的过程，并得到结果。

[b]D. 使用类图[/b]

类图几乎是所有面向对象方法的支柱，应该如何使用类图呢？以下提供了一些使用类图的一些建议。

不要试图在项目的初始阶段使用所有的符号，首先应该从简单概念开始。比如类的关系等等，在需要的时候才使用。在项目的不同开发阶段，应该使用不同的观点来画类图。如果处于分析阶段应该画概念层类图，当开始着手软件设计时，应该画说明层类图，当针对某个特定的技术实现时应该画实现层类图。不要为每个事物都画一个模型，应该把精力放在关键的领域。使用类图的最大危险是过早的陷入实现的细节，为了避免这个问题，应该将重点放在概念层和说明层。