你通常通过下面三种方式使用类图：
1，为系统词汇建模型
为系统的词汇建模实际上是从词汇表中发现类，发现它的责任。
2，模型化简单的协作
协作是指一些类、接口和其他的元素一起工作提供一些合作的行为，这些行为不是简单地将元素加能得到的。例如：当你为一个分布式的系统中的事务处理过程建模型时，你不可能只通过一个类来明白事务是怎样进行的，事实上这个过程的执行涉及到一系列的类的协同工作。使用类图来可视化这些类和他们的关系。
3，模型化一个逻辑数据库模式
想象模式是概念上设计数据库的蓝图。在很多领域，你将想保存持久性数据到关系数据库活面向对象的数据库。你可以用类图为这些数据库模式建立模型。
1. 类（Class）
一般包含3个组成部分。第一个是类名；第二个是属性（attributes）；第三个是该类提供的方法（ 类的性质可以放在第四部分；如果类中含有内部类，则会出现第五个组成部分）。类名部分是不能省略的，其他组成部分可以省略。
类名书写规范：正体字说明类是可被实例化的，斜体字说明类为抽象类。
属性和方法书写规范：修饰符 [描述信息] 属性、方法名称 [参数] [：返回类型|类型]
属性和方法之前可附加的可见性修饰符：
加号（+）表示public；减号（-）表示private；#号表示protected；省略这些修饰符表示具有package（包）级别的可见性。
如果属性或方法具有下划线，则说明它是静态的。
描述信息使用 << 开头和使用 >> 结尾。
类的性质是由一个属性、一个赋值方法和一个取值方法组成。书写方式和方法类似。
2. 包（Package）
包是一种常规用途的组合机制。UML中的一个包直接对应于Java中的一个包。在Java中，一个包可能含有其他包、类或者同时含有这两者。进行建模时，通常使用逻辑性的包，用于对模型进行组织；使用物理性的包，用于转换成系统中的Java包。每个包的名称对这个包进行了惟一性的标识。
3. 接口（Interface）
接口是一系列操作的集合，它指定了一个类所提供的服务。它直接对应于Java中的一个接口类型。接口的表示有大概两种方式。具体画法见下例：
4. 关系
常见的关系有：一般化关系（Generalization），关联关系（Association），聚合关系（Aggregation），合成关系（Composition），依赖关系（Dependency）。
其中，聚合关系（Aggregation），合成关系（Composition）属于关联关系（Association）。
一般关系表现为继承或实现关系(is a)，关联关系表现为变量(has a )，依赖关系表现为函数中的参数(use a)。
一般化关系：表示为类与类之间的继承关系，接口与接口之间的继承，类对接口的实现关系。
表示方法： 用一个空心箭头＋实线，箭头指向父类。或空心箭头＋虚线，如果父类是接口。
关联关系：类与类之间的联接，它使一个类知道另一个类的属性和方法。
表示方法：用 实线＋箭头， 箭头指向被使用的类。
聚合关系：是关联关系的一种，是强的关联关系。聚合关系是整体和个体的关系。关联关系的两个类处于同一层次上，啊聚合关系两个类处于不同的层次，一个是整体，一个是部分。
表示方法：空心菱形＋实线＋箭头，箭头指向部分。
合成关系：是关联关系的一种，是比聚合关系强的关系。它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期，合成关系不能共享。
表示方法：实心菱形＋实线＋箭头，
依赖关系：是类与类之间的连接，表示一个类依赖于另一个类的定义。例如如果A依赖于B，则B体现为局部变量，方法的参数、或静态方法的调用。
表示方法：虚线＋箭头
通用建模技术
没有类是单独存在的，他们通常和别的类协作，创造比单独工作更大的语义。因此，除了捕获系统的词汇以外，还要将注意力集中到这些类是如何在一起工作的。使用类图来表达这种协作。
l 确定你建模的机制。机制代表了部分你建模的系统的一些功能和行为，这些功能和行为是一组类、接口和其他事物相互作用的结果。
l 对于每个机制，确定类、接口和其他的参与这个协作的协作。同时确定这些事物之间的关系。
l 用场景来预排这些事物，沿着这条路你将发现模型中忽略的部分和定义错误的部分。
l 确定用这些事物的内容来填充它们。对于类，开始于获得一个责任（类的职责），然后，将它转化为具体的属性和方法。
图7-1是一个自治机器人的类图。这张的图焦点聚集那些让机器人在路上行走的机制对应的类上。你可以发现一个虚类Motor和两个从它派生出来的类：SteeringMotor和MainMotor。这两个类都从它的父亲Motor继承了五个方法。这两个类又是另一个类Driver的一部分。类PathAgent和Driver有一个1对1的关系，和CollisionSensor有1对n的关系。
在这个系统中其实还有很多其他的类，但这张图的重点是放在那些将机器人移动的类上的。在其他的图中你可能也会看到这些类。通过将焦点放在不通的功能上，可以获得从不通的角度对整个系统的认识，最终达到认识整个系统。
很多系统都是有持久性数据的，也就是说要将这些数据保存到数据库中以便下一次使用。通常你会使用关系型数据库或面向对象的数据库，或其它类型的数据库来保存数据。UML很适合为逻辑数据库模式建模。
UML的类图是E-R图（为逻辑数据库建模的通用工具）的超集，尽管E-R图的重点是数据，类图的扩展允许模型化行为。在物理数据库中这些逻辑操作一半转化为触发器或存储过程。
l 确定那些状态比其生命周期要长的类。
l 创建一张包含这些类的图，标记它们为持久性的。
l 详细定义它们的属性。
l 对于使得物理数据库设计复杂的模式如：循环关系、1对1关系、N元关系，考虑创建中间抽象来使得逻辑结构复杂。
l 详细定义这些类的操作，特别是那些访问数据和涉及数据完整性的方法。
l 如果可能的话使用工具来将你的逻辑设计转化为物理设计。
建模是重要的，但要记住的是对于开发组来说软件才是主要的产品，而不是图。当然，画图的主要目的是为了更好地理解系统，预测什么时候可以提供什么样的软件来满足用户的需要。基于这个理由，让你画的图对开发有指导意义是很重要的。
某些时候，使用UML。你的模型并不能直接映射成为代码。例如，如果你在使用活动图为一个商业过程建模，很多活动实际上涉及人而不是计算机。
很多时候，你创建的图形可以被映射成为代码。UML并不是专门为面向对象的语言设计的，它支持多种语言，但使用面向对象的语言会更直观些，特别是类图的映射，它的内容可以直接映射成为面向对象语言的内容。如：C＋＋，SMALLTALK、ADA、ObjectPascal、Eiffel和Forte。UML还支持如Visual Basic这样的面向对象的语言。
正向工程：是从图到代码的过程。通过对某中特定语言的映射可以从UML的图得到该语言的代码。正向工程会丢失信息，这是因为UML比任何一种程序语言的语义都丰富。这也正是为什么你需要UML模型的原因。结构特性、协作、交互等可以通过UML直观地表达出来，使用代码就不是那么明显了。
对类图的正向工程：
l 选择将图形映射到哪一种程序语言。
l 根据你选择的语言的语义，你可能要对使用某写UML的特性加以限制。例如：UML允许你使用多重继承，而SmallTalk只允许一重继承。
l 使用标记值来指定比的目的语言。你可以在类级进行也可以在协作或包的层次上进行。
l 使用工具来对你的模型进行正向工程。
反向工程：反向工程是从代码到模型的过程。
进行反向工程：
l 确定将你的程序语言的代码反向成模型的规则。
l 使用工具（Rose C++ Analyzer）进行反向工程。
提示和技巧
一个结构化好的类图：
l 焦点放在系统静态设计视图的一个方面。
l 只包含为了理解该方面而应该存在的元素。
l 提供足够的信息来理解该图。
l 不让读者产生错误的信息。
当你画类图的时候：
l 给它起一个名字，这个名字能表达类图的用途。
l 用最少的交叉线来组织它的元素。