嵌入eclipse JDT的类图概述

"嵌入eclipse JDT的类图"，即完全整合/嵌入在Java集成开发环境(IDE)eclipse JDT中的类图。

那么，"嵌入eclipse JDT的类图"和"一般的UML类图"有什么不同？

从设计模式MVC角度来看：

• 二者的V(View)都是类图，都表现的是系统的静态结构；
• 但是二者的M(Model)却不同，"嵌入eclipse JDT的类图"的Model，即数据来自Java源码；而"一般的UML类图"则来自UML模型文件（如XMI，Rose的MDL）等。也就是说，"嵌入eclipse JDT的类图"表达的信息，如类的字段、操作、继承、实现等所有信息都来自Java源码，有了源码，就可以展示其静态结构，而无须再转换为UML的类、字段、操作、继承、实现等。
• 对C(Control)而言，"嵌入eclipse JDT的类图"直接通过控制操作Java源码、并改变源码。而"一般的UML类图"则改变的是UML模型。如在"嵌入eclipse JDT的类图"改变类的名字，实际的操作就是改变源码中对应的类的名字；又如在"嵌入eclipse JDT的类图"中删除一个字段，实际的操作就是删除源码中对应的字段。即类图和Java源码完全对应，换句话说，"嵌入eclipse JDT的类图"表现的就是Java源码的静态结构信息。

为什么在Kant 2008 for Java已经提供"一般的UML类图"的前提下，还要提供"嵌入eclipse JDT的类图"呢？

首先，对大多数Java程序员而言，类图只是一个辅助工具，而编码是主要工作。当需要将已有的代码展示为类图时：

• 如果采用"一般的UML类图"，则首先需要导入源码到UML模型，或者同步到UML模型，然后再生成类图。一方面在将Java源码转换为UML模型时，会有信息的耗损或变形；另一方面，当Java源码不断的更新时，UML模型却不会自动的随Java源码更新，因此渐渐的UML模型和源码之间就产生隔阂，甚至完全不一致，最终导致UML模型完全实效。这个结果是由于两个数据源－Java源码和UML模型导致的。
• 而如果采用"嵌入eclipse JDT的类图"，则上述问题完全不存在。因为只有一个数据源－Java源码，无须转换和导入，所以展示为类图是一一完全对应，没有任何的耗损或变形；另外，当数据源更新时，作为视图的类图当然会自动同步，立刻更新，因此也就没有同步的问题。这样，类图和源码永远同步，永远等同。

另外，通过操作图的方式来操作Java源码，也是"嵌入eclipse JDT的类图"给予用户的新的完全不同的体验，从而让编码更有乐趣！而且，代码和类图的完全对应、自动同步、实时改变，也让原来只重视编码的程序员对系统的静态结构有了更清晰的认识，从而大大提高自己的设计能力！

举例：下图展示的是自动生成"java.awt.print"包的继承关系图：

"嵌入eclipse JDT的类图"支持的功能如下：

• 新建Java类图
• 包资源管理器(Package Explore)到类图的拖放：支持将Java元素从包资源管理器拖放到类图，并显示到类图。可拖放的Java元素包括Java包，Java类型（类、接口、枚举）。
• Java项目的反向工程：批处理操作。自动生成Java项目所有选择包的类图。每个包1个类图。同时提供清理操作，可以清除生成的所有类图文件。
• 包的自动生成类图：可以自动生成包下选择类型的继承关系、关联关系图，并自动布局。
• 类的自动生成类图：可以自动生成类的继承关系图。
• 框图和源码的交互操作：通过框图操作，生成包、类、接口、枚举、字段、方法、继承、实现；通过框图操作，重命名Java元素。通过Java编辑器修改源码并保存时，框图自动同步。框图打开时，自动同步Java源码。
• 其他功能：显示选项，复制图像，打印，导出图像，自动布局，框图元素到Java元素的导航。