介绍：
OptimalJ是一个高级的企业级应用开发环境，它使用成熟的模式(Pattern) 直接从可视化模型生成全面的、可运行的J2EE应用系统，实现了最好的实践经验并基于J2EE规则编写代码。使用OMG的模型驱动架构标准，OptimalJ帮助简化开发，使架构师、设计人员和开发人员快速开发可靠的应用系统。
OptimalJ以五个关键基础概念为特性，将在一系列的技术白皮书进行讨论它们。
１、模型驱动开发 ― 如何提高生产力
２、 商业规则 ― 如何适应商业的快速变化。
３、模式 ― 如何转换UML模型为高质量的J2EE应用系统。
４、动态同步 ― 如何确保模型和代码的一致性。
５、集成部署 ― 如何简化测试。
在阅读技术白皮书系列之前，我们强烈建议您访问如下网址－http://www.compuware.com/products/optimalj/detail.htm，以便对OJ有一个的整体概念和理解MDA在OptimalJ中的作用。
模型驱动架构(MDA)的重要性
在领导优良应用系统的部署中，建模是核心过程之一。建模是为了传达系统应包含的结构和行为；建模为了可视化系统架构并能掌控它；建模为了更好地理解我们正在建立的系统；建模经常揭示简化和重用的机会；建模为了管理风险。
然而，当今建模面临的问题是模型在许多组织中是基于书面的一项活动。这便产生了模型间的同步问题，即应用系统蓝图和应用系统本身。因为应用系统被更新而模型没有变化，模型仅仅作为文档 (perspective)是没有用的。
关键是在建模和开发间的鸿沟间搭建桥梁，使建模构成整体所需要的一部分。OMG的模型驱动架构是志在解决此问题的框架，在此框架中模型驱动开发进程。MDA远景定义了一个详细说明和构建系统的新方法，用UML作为基础建模。MDA扩展了UML以前仅仅是漂亮图片的作用。
统一建模语言(UML)
UML是用于MDA的关键技术标准之一。MDA是以OMG为主导的，康博公司(Compuware)是该组织的成员之一。UML是一个标准化的图形语言，可以可视化浏览、详细说明、搭建和文档化一个软件系统的模型。UML给出了一个描绘系统蓝图的标准方法，涵盖了概念性和具体事物，概念如商业流程和系统功能，具体如用特定程序语言熟悉的类，数据基础大纲和可重用的软件组件。UML是一个被广泛采用的标准，它代表了从十多年软件系统建模的经验总结的最好的实践和经验。建模有如下几个主要优点：
l 提供了应用系统架构和行为的概要视图。
l 便利对象和规则的重用。
l 确保了开发过程的一致性。
l 运行独立实现，这样当变化（如基础技术架构）发生时，模型保持有效。
模型驱动开发实践
OptimalJ是一个以MDA为基础的模型驱动开发环境，它结合企业标准建模技术和在UML中使用的符号，用来设计和开发企业J2EE应用系统。
OptimalJ允许设计和开发人员在更高的抽象层次上进行开发，从一开始就减少J2EE平台和复杂性。从建模到部署，在OptimalJ中的应用开发都是模型驱动。OptimalJ通过可视化模型确保定义和重用。模型驱动开发范例允许设计和开发人员集中在做什么，而不是如何做。
OptimalJ域模型的定义
OptimalJ高级模型驱动开发环境的核心是以UML为基础的域模型(Domain Model)。域模型是一个高层次的对象模型，包含应用系统的信息结构和行为以及不同数据结构间的关系。域模型是一个商业为中心的模型并调整商业信息的集成，它不关注技术细节并和OMG的MDA中的平台无关模型(PIM)对应。换言之，域模型不包含实现和代码细节，例如不包含实现应用系统所必须的技术类。开发和完善域模型时，OptimalJ允许设计人员以声明方式定义商业规则，例如初始值的设置和级联删除约束。域模型的所有定义在低层的应用模型和实际的代码中被重用和继承。设计人员在域模型定义的内容越多，从域模型自动生产的内容越多。1
域模型层将设计人员和底层的实现细节隔离，让他们将工作重心集中在应用系统的功能而不是J2EE平台的具体实现细节。而且，设计人员能够在模型层快速修改。
OptimalJ在域模型标识两种模型：域类模型(Domain Class Model)和域服务模型(Domain Services Model)。
域类模型定义应用系统运行依赖的信息结构，例如客户、订单、产品和它们的属性、关系、集成、商业方法( 操作)和商业规则。
域服务模型以独立实现的方法定义应用系统的交易，例如订单登录、根据订单开发票、订单发货和其他典型的商业任务。服务模型的关键优势是它能生成自动生成会话组件(Beans)，会话组件的典型特征是定义应用系统的行为。
域模型的可视化
编辑域模型可以在图形化的域模型编辑器或模型资源导航器中的中进行。
域模型编辑器在网格上显示所有的类和它们的关系。类图以UML符号为基础并包含属性和操作。关联端用一个数字和象征性的符号显示多重性。一个小菱形标识聚合关系。你可以在类编辑器中将类图放大、缩小或移动，也可以通过小拇指视图以及布局管理方便地浏览类图。在许多种情况下，结构或模型已经存在，此存在的结构或模型可以作为域模型的开始点。例如，已经存在的某种UML模型工具定义的模型或客户已经使用的包含数据关系的数据库，可以在域模型中重用。OptimalJ提供了UML/XMI导入/导出工具，域模式和DBMS导入工具来处理这些情境。
UML/XMI 导入/导出工具
当设计人员用第三方UML建模工具，例如Rational Rose，他们尽可能从建模阶段重用以有效地利用以前的工作成果。在以UML为基础的建模有几个阶段，每个阶段有不同的模型活动。范围从在概念阶段的高层分析到最终的单个组件的细节模型。当模型完成时，最终产生可用的类模型。类模型可以导出为XML元数据接口（XMI）文件。用OptimalJ的UML/XMI导入/导出工具，XMI文件能够移植到OptimalJ的域模型。一旦导入完成，用OptimalJ的域模型编辑器可以查看、扩展和修改域模型。另外，如果创建或更新域模型时，在必要情况下可以通过导入/导出工具和其他建模工具交互。
域模式(Domain Patterns)
UML建模是一个费时和复杂的过程。OptimalJ通过域模式简化这个过程。域模式帮助设计人员创建可以重用的的模型，加速建模阶段并减少错误。因此，域模式加速新模型的创建。域模式可以将模型拷贝到空的目标域模型或同已经存在的域模型进行合并。在OptimalJ中，这个过程称为模式组合。在模式组合时，从源域模式可以继承和合并关联和属性。
域模式用新建域模型相似的方式创建，但与域模型不同的是，域模式在域模式库中创建。模式库保存、分组和组织域模式，用一个完全兼容的UML/XMI格式做为域模式模块。
域模式给设计人员带来了一些关键优点：
1. 设计人员能够在不同应用系统间重用域模型或域模型的子集，以此减少在建模阶段的错误。
2. 域模式强制设计人员基于标准和最好的实践用一致性的方法为应用系统建模。
3. 域模式增加了建模阶段的生产力。
DBMS导入工具
在OptimalJ中客户可以重用已经存在的数据库。如果该数据库能通过JDBC驱动访问，分类文件能够导入到应用模型层的DBMS模型。OptimalJ通过“关系型到面向对象”的镜像模式，自动转换DBMS模型到域模型。在正常情况下，首先，定义域模型，然后从域模型产生DBMS模型，但在导入情况下，以重用已存在的数据库做为应用系统的基础。
OptimalJ应用模型的来源
一旦第一次域模型迭代完成，OptimalJ自动转换域模型到应用模型。OptimalJ的应用模型对应于OMG的MDA的对象相关模型(PSM)，应用模型目标集中在J2EE平台。从域模型到应用模型的镜像和转换由OptimalJ的技术模式2来处理。
产生的应用模型包含三种模型：
l 展示(WEB)模型
l 业务逻辑(EJB)模型
l 数据库(DBMS)模型
为了完成J2EE应用系统，应用模型定义了开发J2EE所需的内容。模型展示了由每一层构成所有J2EE组件的概要视图。用这种方法，当技术方面软件升级和变化时，而从商业方面的域模型却可以保持不变。
展示(WEB)模型
产生应用系统WEB前端需要的信息包含Web模型。通过编辑代码模型中模版、层叠样式表单(CSSs)和JSP页面，你可以修改自动生成应用系统的外观(Look and feel)。镜像模式从域模型生成WEB模型，自动镜像域模型的元素到WEB模型的元素。在WEB模型的重要元素有：
l web模块(modules)――web组件的包容器。
l web数据大纲(Data Schema)――定义了一个数据类的集合
l web组件――定义了指定数据类集合的用户接口
l web验证组件――为应用系统定义验证方法
web展示类型――定义展示和校验
开发人员能根据向导(wizards)，以声明的方式尽一步精制(refine)Web模型。精制的一个例子是用户接口的扩展。因为布局和格式化属性仅能在WEB模型层定义，OptimalJ确保这些属性在全部应用系统内保持一致。使用在不同展示组件如JSP页面的一个属性，继承在这个模型中定义的布局和格式化方式。因为以一种声明的方式进行许多精细，使展示组件开发更快速。定义在模型中格式化和布局属性，最终体现在生成的代码中。
因为有变更时仅需要在应用模型修改一次，系统的维护变的更为容易。当精细WEB模型元素的属性时，开发人员对他们的配置有更多的想法。这包括设置日期或数字格式、选择大小写的转换、对一个元素的HTML类型和设置某种HTML属性，包括层叠式表单。另外，开发人员可以在OptimalJ用正则表达式去建模数据校验(如特定格式的校验)。定义后的属性将传导到在展示层产生的源代码中。
商业逻辑模型
企业Java Bean模型是中间件层，处理如交易、安全性、持久性和可扩展性。它是代码模型之上的抽象层。
OptimalJ用包含在域模型的定义产生EJB模型，包括应用系统实体和会话组件的模型元素。EJB模型包括实体组件、数据大纲、主键类和其他EJB相关的组件。
虽然域模型驱动开发过程，开发人员能够扩展由域模型产生的EJB模型，可以定义附件组件如查找、商业、Home和选择方法等。
数据库(DBMS)模型
在J2EE开发中，数据持久性是一个重要的问题。通用的方法是用关系型数据库存储数据。为了存储数据，必须定义在对象模型和数据库间的对象－关系镜像。
OptimalJ用技术模式3自动从模型产生数据库模型，以此来处理对象－关系镜像。数据库模型用来建模和镜像所有的相关的数据库定义。数据库模型支持大纲、表、字段、行、外部键、主键和唯一约束。
对模型中的每一个元素，重要的是在定义中没有实现的细节，这意味着在这个阶段不产生任何类型的技术类或组件。
所有以上模型都能用相应的图形编辑器以图形化的方式观看，这样使模型更直观和更容易理解。
OptimalJ模型的实现
一旦从域模型产生应用模型，OptimalJ自动用实现模式4转换应用模型到实际代码。
商业逻辑(EJB)、数据库(DBMS)和展示(WEB)模型的代码可以分别生成或一次全部产生。当这些模型创建或更新时，它们继承了域模型的所有相关定义。一旦所有的应用模型存在，OptimalJ产生实际的代码完成各自模型的组件。自动产生的过程确保了和域模型的一致性，节省了大量的时间并减少了潜在的编程带来的错误。自然，WEB模型依赖商业逻辑模型，而商业逻辑模型依赖数据库模型。OptimalJ为你维护了模型之间的相互依赖性。
OptimalJ用它的动态同步工具(active synchronization facility5)，确保模型和代码一直保持同步。OptimalJ生成的代码是J2EE全部功能并和其规范相一致。产生的代码由Java、JSP和XML文件、实体Beans、会话Beans和SQL脚本组成。
由OptimalJ产生的全部代码放置在保护块(guarded blocks)。“Guarded”意味着产生的代码是被保护的，所有开发人员不能修改。然而，OptimalJ提供了自由块使开发人员能够增加对生成代码的扩展内容。当应用系统被重新生成时，OptimalJ保留在自由块中的定制代码。
独立于集成开发环境
开发人员能够在OptimalJ中定制代码，OptimalJ包含一个基于源代码开发的集成开发环境NetBeans的Java集成开发环境。OptimalJ有所有NetBeans功能的特色，例如：
l Java语法敏感的源代码编辑器，含有代码自动完成和关键字颜色标识。
l 工程支持结构化应用系统，允许开发人员快速切换上下文。
l 远程调试
l 构造器和编译器
l Java存档包装器可以打包Java类集合为部署包。
另外，开发人员可以在OptimalJ中用Java类图编辑器以图像化的方式查看。Java类图编辑器自动从Java源文件所在的包生成和显示UML风格的类图。Java类图和OptimalJ资源导航树以及Java源代码编辑器完全同步。这意味这在这三个窗口(图表、导航和源代码编辑器)所作的任意修改将在其它两个窗口将跟着变化。
即使OptimalJ包含了NetBeans集成开发环境并同其分享了与开发人员接口的菜单和窗口，开发人员能够选择用NetBeans集成开发环境或其它的集成开发环境。OptimalJ已经扩展了对Borland Jbuilder、IBM WebShpere Applicatin Studio Developer(WSAD)和Sun SunOne Studio的支持。此扩展支持帮助开发人员区分由OptimalJ自动生成代码的保护块和开发对生成代码的增加子集扩展的自由块。另外，这些集成开发环境也包括一系列OptimalJ特定的菜单项，例如SQL workbench和一个集成测试部署环境。
EJB模型的实现
由OptimalJ生成的EJB1.1或EJB2.0的EJBs和在域模型所定义的内容一致。EJB模型包含和前端组件(JSPs)交互的功能也有和数据库与EJB服务器交互的方法。OptimalJ存在如下主要EJB模型元素：
l EJB模块(module)－所有生成的EJB模型元素的包容器。
l EJB数据大纲－具体指定EJB组件的数据结构，包含有EJB数据类和EJB数据关联关系。
l EJB主键类－代表主要唯一约束。在EJB主键类中的EJB主键属性来源于在域模型中的主要唯一约束。
l EJB实体组件－代表数据库中的数据和作用于该数据的商业方法。
l EJB会话组件－一个组合数据集的抽象。一个会话组件是服务为中心的并意谓对实体组件执行操作。它提供代表客户端的服务去聚集逻辑上的相关数据并从一个单一接口表示服务。会话组件根据域服务创建。
l EJB消息驱动组件－代表一个在EJB模型中设计的JMS消息消费者。它或者消费一个特定的消息或者消费一个为特别目的(主题或队列)的所有消息。对此组件生成的代码是一个J2EE消息驱动Bean的实现。
OptimalJ减少了生成EJBs的复杂性并帮助开发人员最大化生产力、灵活性和质量。OptimalJ确保旨在更有效地书写应用系统所的努力，真正区分了公司的业务并减少了提交到市场的时间。然而，为了增加生产力，不仅关心EJB在代码的开发方面是必须的，同时对EJBs的部署和测试方面的关心也是必不可少的。OptimalJ为此提供了集成测试和部署环境。6
数据库模型的实现
开发一个新的应用系统需要数据库脚本去创建数据库表。当域模型完成后，菜单项“从域模型生成数据库(Generate Database from Domain)”将从域模型产生数据模型。数据模型包含了应用系统的关系数据库定义。OptimalJ产生对底层DBMS创建/删除相应数据库表的SQL命令脚本。
开发人员需要定义为哪一个数据生成SQL脚本。OptimalJ提供了一个集成的SQL工作台去执行SQL脚本。OptimaJ用JDBC(Java Database Connectivity)对数据库进行访问。
OptimalJ生成一个部署描述符文件，J2EE包容器7通过此文件部署J2EE应用系统。
OptimalJ也提供给设计人员用数据访问对象(DAO)代替EJBs读取数据的设计方案。但是，保存数据时，EJBs是更好的方案，因为它能确保保存交易的安全性。
OptimalJ从域类转换为数据库模型时生成数据访问对象(DAO)组件。数据访问对象(DAO)组件也包含了页迭代器(Page Iterator)的功能。迭代器是数据访问对象组件的扩展。当浏览大批量数据时，它提升了应用系统的性能。不返回整个数据集，而是维护代表数据集对象的主键列表，迭代器只返回需要的数据到客户端浏览器。列表和页的数据量定义在属性文件中。
展示模型的实现
展示层定义了一组默认展示组件的集合。这些组件基于JSPs和Servlets并为HTML或WML的客户端实现。展示层源自域模型，域模型确保一致性和前端组件的质量。
展示和商业层的分离使开发人员可以在存在的EJB层上，创建新的WEB前端。因此，OptimalJ包含了一组展示模型用了生成附件的组件。例如，通过选择不同的展示模型，相同的EJB层可以用基于HTML的WEB组件也可以用基于窗口的用户接口组件。OptimalJ的可拆卸的模型架构使相同的EJB而用不同的表现形式成为可能8。在生成Web组件后，开发人员有一个简单的展示层和菜单结构。由于Web组件连接到EJB层，可以立即对数据库进行操作如读、新建、删除和更新等。
OptimalJ用基于模型－视图－控制器(MVC)概念的Apache Struts架构实现展示模型。MVC的设计主要为了便于适应控制的改变。它分开了商业逻辑和数据的接口并提供仅仅基于JSP9的多项优势。编辑JSP、CSS和JSP模版能够改变由于系统的外观。设计人员用可利用的Web动作定义和应用系统的用户交互，Web动作可以被编辑。添加新的WEB动作是非常容易的。设计人员通过在JSP页面嵌套Java脚本增强同HTML表格的交互。OptimalJ提供的Dreamweaver插件可以改变布局，方便网页设计人员改变WEB组件的外观。
模型驱动集成
当今企业面临最大的商业挑战是如何有效利用现有资源，如当前正在应用的系统。因此，集合每一个开发项目都需要某种层次的集成。因为开发和集成是紧密相关的，OptimalJ扩展了它的模型驱动开发环境，包含了模型驱动集成环境。作为对应用模型的扩展，OptimalJ提供了集成模型。当开发一个新的J2EE应用系统时，集成模型减少了复杂性并加速了应用系统的集成。
OptimalJ能够集成：
l 现存的Web services，包括在.Net平台上的Web services。
l OS/390平台，通过Java连接器架构(JCA)标准。
l 现存Java应用系统
l 现存CORBA应用系统。
OptimalJ的调用模式是集成模型的基础。设计人员通过导入如下接口文件可以加速和简化了应用集成：
l Web服务描述语言(WSDL)文件。
l 动态程序连接(DPL)CICS COBOL应用系统
l 用COBOL书写的消息处理程序(MPP)IMS交易
l Java类签名
l CORBA接口定义语言(IDL)文件。
执行器模式重构WSDL、CICS、IMS应用系统、Java签名和接口定义文件转换到域服务模型。从域服务模型，生成JSP页面，作为测试这些组件的用户接口。
另外，也生成了会话Bean和它的部署描述符，会话Bean中包含了对第三方组件的调用代码。当OptimalJ需要调用一个用Java或任何其它技术书写的方法的时候，执行器模式产生相应的代码去调用这个方法10。
总结：
在模型驱动开发环境中，构建成功应用系统关键的第一步是全面和精确的建模。为了管理大的应用系统，基于模型的设计和开发是极为重要的。
OptimalJ基于MDA/J2EE的模型驱动开发和集成环境为商业建模和软件开发间的鸿沟搭建了桥梁，通过构建正确的商业模型驱动应用开发，而不是其它的方法。OptimalJ在不同的抽象层次上提供了实质潜在的重用，它使得为了商业的需要使用变化而重新建模系统更为容易。通过分离商业模型和架构模型，分离架构模型和实现语言，OptimalJ也提升了系统性能的质量、抗摆动行和可维护性。通过这些方法，OptimalJ决定将变化应用到系统的哪一个层：
l 商业变化在域模型。
l 架构变化在应用模型。
l 代码变化在代码层。
1参见Compuware白皮书“OptimalJ:商业规则如何对变化的快速响应”
2 参见Compuware白皮书“OptomalJ:模式如何将UML模型转换为高质量的J2EE应用”。
3参见Compuware白皮书“OptomalJ:模式如何将UML模型转换为高质量的J2EE应用。
4参见Compuware白皮书“OptomalJ:模式如何将UML模型转换为高质量的J2EE应用。
5参见Compuware白皮书“OptomalJ:动态同步如何确保模型的代码的一致性”。
6参见Compuware白皮书“OptomalJ:如何集成部署易于测试”。
7参见Compuware白皮书“OptomalJ:如何集成部署易于测试”。
8参见Compuware白皮书“OptomalJ:模式如何将UML模型转换为高质量的J2EE应用”。
9参见Compuware白皮书“OptomalJ:模式如何将UML模型转换为高质量的J2EE应用”。
10参见Compuware白皮书“OptomalJ:模式如何将UML模型转换为高质量的J2EE应用”。