使共享项目信息更加容易
通过将设计和开发的工作产品作为Reusable Asset Specification (RAS)的产物，你能够将阶段性的工作产品作为公司资产进行存档，并将他们发布到本地的或共享的RAS存储库中。 另一种共享你的工作成果的方法是，使用Rational XDE Extensibility APIs将你开发的模型输出成为HTML的形式，拷贝图形到Word文档或者创建自定义的报告和表格，将这些形式的文档分发给你的同伴。
Rational XDE 的核心功能是软件开发中的分析与设计，它使用统一建模语言(UML)作为建模语言。本文的目的在于向读者介绍结合使用Ratioanl XDE和WebSphere Studio 来加快开发速度，提高开发质量，以及最大限度的释放模式的力量的特性。因此并不会对如何使用UML进行软件建模作详细的讲述。而只是在介绍使用Ratioanl XDE之前对使用UML进行可视化建模的好处和必要性作以简要说明。
为什么要进行可视化建模
我们前面已经将到过，软件开发仍然是一个非常复杂而又困难的工作。有不同角色的具有不同技术背景的代表不同人群的参与者在同一个软件系统的构建过程中，发挥各自的作用，同时还要彼此沟通与协作。而不同角色的参与者对系统的关注角度又是不同的，这就需要对系统在不同的方面进行描述与表现。例如系统的用户所关心的是系统将有什么样的功能，这些功能能不能很好的为他们服务。而系统架构人员关心的是系统的体系结构是什么样的，应该使用什么样的技术平台和开发模型。为了更好的对系统的各个方面进行描述，可视化建模是一个理想的选择。可视化建模的好处在于它能够通过简单且易于理解的图形来描述系统的各个方面。即使没有受过专门培训的人也可以非常容易的理解。UML是一种业界公认的可视化建模的标准语言。通过使用UML可以非常准确的描述系统，同时也可以很好的解决项目成员之间的沟通问题。我们知道不同技术背景的人之间进行沟通是很困难的，让一个程序开发人员去理解企业的业务是十分困难的，但为了构建满足企业需求的系统，开发人员必须理解系统的需求。使用UML对系统需求进行建模，通过用例（use case）来表达系统应该具备的功能。开发人员可以完全理解UML的表示方法，这样开发人员就可以准确的理解需求人员的分析结果。
建模也可以很好的将复杂的系统分解成相对简单的部分，同时建立不同部分之间的关联，这样就可以非常有效的管理系统的复杂性。有利于系统开发过程中的变更与跟踪，使系统在需求，设计，代码之间保持良好的一致性。如果在整个项目团队中都使用UML，并且项目成员使用了同一种UML工具，这样就消除了由于工具之间的难于集成所带来的麻烦。
UML简介
这里只对UML作简单的介绍，通过对UML中七种图（用例图、类图、序列图、状态图、活动图、组件图和部署图）的介绍讲述他们的用途。如果您对UML已经十分熟悉，您可以跳过这部分。
用例图
用例图描述了系统提供的一个功能单元。用例图的主要目的是帮助开发团队以一种可视化的方式理解系统的功能需求，包括"角色"（也就是将与系统交互的人类）与基本流程的关系，以及不同用例之间的关系。用例图一般给出了用例组--或者是整个系统的全部用例，或者是一组分开的具有相关功能（例如，所有用户管理相关的用例）的特定用例组。
类图
类图显示不同的实体（人、事物和数据）如何彼此相关；换句话说，它显示了系统的静态结构。类图可用于显示逻辑类，逻辑类通常就是公司业务人员所谈及的事物种类。类图还可以用来显示实现类，实现类就是程序员通常处理的事物。实现类图或许会与逻辑类图显示一些相同的类。然而，实现类图不会使用相同的属性来绘制，因为它很可能具有对诸如Vector和HashMap这种事物的引用。
序列图
序列图显示特定用例（甚至特定用例的某一部分）的详细流程。它们几乎是自描述的，并且显示了它们的序列中不同对象之间的调用关系，同时可以在很详细的级别上显示对不同对象的不同调用。序列图有两个维度：垂直维度以发生的时间顺序显示消息/调用的序列；水平维度显示消息被发送到的对象实例。
状态图
状态图对某个类可能所处的不同状态和该类从一个状态转换到另一个状态进行建模。有人可能会争论说每个类都有状态，但不是每个类都应该有一个状态图。只有哪些有受关注的状态的类（也就是说，在系统活动期间具有三个或更多潜在状态的类）才应该建模。
活动图
活动图显示在处理某个活动时，两个或者更多类对象之间的过程控制流。活动图可用于在业务单元的级别上对更高级别的业务过程进行建模，或者对低级别的内部类操作进行建模。根据我的经验，活动图最适合用于对较高级别的过程建模，比如公司当前在如何运作业务，或者业务运作看起来如何。这是因为与序列图相比，活动图在表面上是非技术性的，而有商业头脑的人们往往能够更快速地理解它们。
组件图
组件图提供系统的物理视图。它的用途是显示系统中的软件对其他软件组件（例如，软件库）的依赖关系。组件图可以在一个非常高的层次上显示，从而仅显示粗粒度的组件，也可以在组件包层次上显示。
部署图
部署图显示系统将如何物理地部署到硬件环境中。它的用途是显示系统的不同组件将在何处物理地运行，以及它们将如何彼此通信。既然部署图对物理运行情况进行建模，系统的生产人员就可以很好地利用这种图。
上面我们已经讨论了目前软件开发人员所面临的各种挑战和压力，也介绍了为什么要进行可视化建模以及UML的七种核心图。下面我们来看一下Rational XDE是如何为软件开发人员提高效率，减轻压力的。我们将从以下开发人员所面临的压力方面进行阐述：
1． 开发工具的多样性
2． 代码与设计之间缺乏一致性保障
3． 学习UML是困难的
4． 软件重用
5． 文档化
6． 开发效率低，软件质量不能保证
开发工具的多样性
我们首先来看一下传统的开发过程中会用到哪些工具。需求人员使用需求开发的工具产生软件的需求，设计人员使用分析设计工具（如 Rational Rose）产生软件的设计，编码人员使用象Websphere Studio等开发工具开发出软件的源代码。我们可以看到由于在软件开发的不同阶段使用了不同的工具，而在当前的项目中往往一个开发人员要扮演一个以上的角色，比如一个开发人员既要负责某一模块的设计，又要对这个模块进行编码。同时这个开发人员可能还要使用需求开发工具来浏览软件需求。因此一个开发人员需要学习使用多种工具。而学习使用一种工具又是非常费时费力的。Rational XDE为您消除了学习多种工具的烦恼。如果你正在使用WebSphere Studio 或 Eclipse ，你就可以在其上安装Rational XDE插件。当你安装了Rational XDE插件，你将可以看到在你的WebSphere Studio或 Eclipse中多了一个"建模（Modeling）"菜单。同时你会发现在透视图选择对话框多了一个"建模（Modeling）"透视图，见图2
图2 建模菜单
有了Rational XDE，项目中的开发人员可以使用同一种工具进行软件的分析、设计和编码了，省去了很多学习其他工具的时间。
代码与设计之间缺乏一致性保障
开发人员经常会遇到这样的问题：我的代码和设计出现了不一致的现象。造成这种问题的原因在于代码与设计或者说是代码与模型之间没有一个自动同步的机制，只能靠开发人员的脑袋来进行"同步"，这势必会有遗漏和错误。在传统的软件开发方式下，设计和编码使用不同的工具，这种同步就更是难上加难了。Rational XDE的出现给广大软件开发人员带来了解决这个问题的"灵丹妙药"。Rational XDE提供了一个叫做"双向工程"的特性，使代码和设计（模型）可以进行自动的双向同步。也就是说当你修改设计的时候，你的代码也会相应的自动发生改变。同样的道理，当你的代码中出现了结构上的变化，相应的模型也会自动的发生变化。
