在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应用”。
本文地址：http://com.8s8s.com/it/it16804.htm