| 编辑推荐: |
本文主要介绍类的名称、属性与操作，希望对您有所帮助。
本文来源于：网络，由火龙果软件Linda编辑，推荐。 |
|
类是具有相同属性、操作、关系的对象集合的总称。通常在UML中类被画成矩形。 名称
每个类都必须有一个名字，用来区分其它的类。类名是一个字符串，称为简单名字。路径名字是在类名前加包含类的包名为前缀。例如Wall、java::awt::Wall都是合法的类名。
属性
属性是指类的命名的特性，常常代表一类取值。类可以有任意多个属性，也可以没有属性。在类图中属性只要写上名字就可以了。如下图
也可以在属性名后跟上类型甚至缺省取值，如下图：
操作
操作是类的任意一个实例对象都可以调用，并可能影响该对象行为的实现。操作在类图中如下图描述：
组织属性和方法
在画类图的时候没有必要将全部的属性和操作都画出来。实际上，在大部分情况下你也不可能在一个图中将类的属性和操作都画出来。在画类图时可以只将感兴趣的属性和操作画出来就可以了。可以用”...”表示还有属性或方法没有画出来。为了更好地组织属性或方法，可以在一组功能相同的属性或方法前加上一个描述的前缀（<<>>中的文字），如下图：
 职责
职责指的是类所担任的任务，类的设计要完成什么样的功能，要存担的义务。一个类可以有多种职责，设计得好的类一般至少有一种职责，在定义类的时候，将类的职责分解成为类的属性和方法。
通常在UML中在类图的最下方用单独的部分列出类的职责。
类的职责其实只是一段或多段文本描述。 通用建模技术
1. 为系统的词汇建立模型
l 标识出用户或解决问题时用来描述问题的东西，使用CRC卡片和基于USE－CASE的分析来找出这些抽象。
l 对每一个抽象，标识出它的职责集合。确定明确地定义了每一个类，在为所有类确定的职责中取得了很好的平衡。
l 为类提供实现类的职责所需要的属性和方法。
2. 为系统的职责分配建立模型
l 标识出行为相类似的对类
l 找出这些类的职责
l 把这些类作为整体看待，把职责多的类分为几个小类
l 考虑这些类如何协作，重新进行类的职责分配已满足协作中没有类太多职责或太少职责
3. 为非软件的事务建立模型
l 为抽象成类的事务建立模型
l 如果你建模的是硬件本身包含有软件，建模时考虑为一种NODE，这样可以对它进一步的分解。
4. 为原始类型建模
l 为类型或枚举建立模型
l 如果要对这种类型取值范围进行说明，使用约束。
| 
