介紹：
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允許設計人員以聲明方式定義商業規則，例如初始值的設置和級聯刪除約束。域模型的所有定義在低層的應用模型和實際的代碼中被重用和繼承。設計人員在域模型定義的內容越多，從域模型自動生產的內容越多。
域模型層將設計人員和底層的實現細節隔離，讓他們將工作重心集中在應用系統的功能而不是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的技術模式來處理。
產生的應用模型包含三種模型：
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用技術模式自動從模型產生數據庫模型，以此來處理對象－關系鏡像。數據庫模型用來建模和鏡像所有的相關的數據庫定義。數據庫模型支持大綱、表、字段、行、外部鍵、主鍵和唯一約束。
?
對模型中的每一個元素，重要的是在定義中沒有實現的細節，這意味著在這個階段不產生任何類型的技術類或組件。
?
所有以上模型都能用相應的圖形編輯器以圖形化的方式觀看，這樣使模型更直觀和更容易理解。
OptimalJ模型的實現
一旦從域模型產生應用模型，OptimalJ自動用實現模式轉換應用模型到實際代碼。
?
商業邏輯(EJB)、數據庫(DBMS)和展示(WEB)模型的代碼可以分別生成或一次全部產生。當這些模型創建或更新時，它們繼承了域模型的所有相關定義。一旦所有的應用模型存在，OptimalJ產生實際的代碼完成各自模型的組件。自動產生的過程確保了和域模型的一致性，節省了大量的時間并減少了潛在的編程帶來的錯誤。自然，WEB模型依賴商業邏輯模型，而商業邏輯模型依賴數據庫模型。OptimalJ為你維護了模型之間的相互依賴性。
?
OptimalJ用它的動態同步工具(active synchronization facility)，確保模型和代碼一直保持同步。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為此提供了集成測試和部署環境。
數據庫模型的實現
開發一個新的應用系統需要數據庫腳本去創建數據庫表。當域模型完成后，菜單項“從域模型生成數據庫(Generate Database from Domain)”將從域模型產生數據模型。數據模型包含了應用系統的關系數據庫定義。OptimalJ產生對底層DBMS創建/刪除相應數據庫表的SQL命令腳本。
開發人員需要定義為哪一個數據生成SQL腳本。OptimalJ提供了一個集成的SQL工作臺去執行SQL腳本。OptimaJ用JDBC(Java Database Connectivity)對數據庫進行訪問。
OptimalJ生成一個部署描述符文件，J2EE包容器通過此文件部署J2EE應用系統。
?
OptimalJ也提供給設計人員用數據訪問對象(DAO)代替EJBs讀取數據的設計方案。但是，保存數據時，EJBs是更好的方案，因為它能確保保存交易的安全性。
?
OptimalJ從域類轉換為數據庫模型時生成數據訪問對象(DAO)組件。數據訪問對象(DAO)組件也包含了頁迭代器(Page Iterator)的功能。迭代器是數據訪問對象組件的擴展。當瀏覽大批量數據時，它提升了應用系統的性能。不返回整個數據集，而是維護代表數據集對象的主鍵列表，迭代器只返回需要的數據到客戶端瀏覽器。列表和頁的數據量定義在屬性文件中。
展示模型的實現
展示層定義了一組默認展示組件的集合。這些組件基于JSPs和Servlets并為HTML或WML的客戶端實現。展示層源自域模型，域模型確保一致性和前端組件的質量。
?
展示和商業層的分離使開發人員可以在存在的EJB層上，創建新的WEB前端。因此，OptimalJ包含了一組展示模型用了生成附件的組件。例如，通過選擇不同的展示模型，相同的EJB層可以用基于HTML的WEB組件也可以用基于窗口的用戶接口組件。OptimalJ的可拆卸的模型架構使相同的EJB而用不同的表現形式成為可能。在生成Web組件后，開發人員有一個簡單的展示層和菜單結構。由于Web組件連接到EJB層，可以立即對數據庫進行操作如讀、新建、刪除和更新等。
?
OptimalJ用基于模型－視圖－控制器(MVC)概念的Apache Struts架構實現展示模型。MVC的設計主要為了便于適應控制的改變。它分開了商業邏輯和數據的接口并提供僅僅基于JSP的多項優勢。編輯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或任何其它技術書寫的方法的時候，執行器模式產生相應的代碼去調用這個方法。
總結：
在模型驅動開發環境中，構建成功應用系統關鍵的第一步是全面和精確的建模。為了管理大的應用系統，基于模型的設計和開發是極為重要的。
?
OptimalJ基于MDA/J2EE的模型驅動開發和集成環境為商業建模和軟件開發間的鴻溝搭建了橋梁，通過構建正確的商業模型驅動應用開發，而不是其它的方法。OptimalJ在不同的抽象層次上提供了實質潛在的重用，它使得為了商業的需要使用變化而重新建模系統更為容易。通過分離商業模型和架構模型，分離架構模型和實現語言，OptimalJ也提升了系統性能的質量、抗擺動行和可維護性。通過這些方法，OptimalJ決定將變化應用到系統的哪一個層：
l???????? 商業變化在域模型。
l???????? 架構變化在應用模型。
l???????? 代碼變化在代碼層。