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