一、问题：
1. 有快速的类似PB的J2EE开发工具吗？
2. 客户需求不确定、易变时，如何保证J2EE体系的开发效率？
近期开发了套EJB3.0+JSF的业务系统。从技术、开发时间等方面，开发人员是自信的。但是，老板和客户，却觉得开发效率、用户界面操作不够理想。
原因在于，老板和客户，认为应当有PB、Delphi这样的快速开发工具，来快速开发复杂的J2EE的分布式系统。而采用Jbuilder、Eclipse，和基于Annotation、Tag的单向代码生成方式，开发效率仍然不能让他们满足，尤其是业务需求易变、不稳定的时候。
二、解决问题的方法，MDA是方向吗？
为了取悦老板和客户，便狂找是否有IDE能解决这个问题。最后，却在MDA处，朦胧地找到，应对易变和不确定的需求，高效开发J2EE这种复杂应用体系的软件的大致方向。
未来主流的开发方式和支持工具，肯定不是走PB、Delphi的道路。而是走MDA/MDD（模型驱动和开发），Pattern Driven（模式驱动），支持Plugin的IDE的道路。
那些固定技术模式（业务+界面的组成）的开发工具（如PB、Delphi），是不可能支持不同客户的独特业务需求和多种类的客户端界面。这就是Borland要出售IDE的内在原因。
而Eclipse的前途，也在于其Plug-In的体系。
而采用MDA/MDD（模型驱动和开发）、Pattern Driven（模式驱动）、支持Plugin的IDE，企业就可以开发出自己的工具（IDE），根据业务，快速产生符合自己的Framework的代码。
所以，市面上的J2EE开发工具，才都不提供现成的组件，用固定的模式，实现象PB那样的开发方式。
三、MDA/MDD、Pattern Driven支持Plugin的IDE，怎样实现高效率的开发？
采用了MDA，项目组的结构，肯定要调整。简单说，就是贫富差距拉大，能者越重要，普通程序员越普通。
1.BA、SA：
只需要跟客户沟通，获取需求，确定功能，确定模型（Domain Model，或者E-R图），写需求功能文档。他们最多只需要UML画图（PIM层次），不需要深入技术细节。身份接近于“咨询师”，业务知识是他们的价值所在。
2.架构师：
根据SA的反馈，尽早确定技术方案，创建Framework.
确定了前后端（Business、Gui）的Framework后，架构师根据MDA规范和具体工具，定义模型驱动模板（Pattern Plug-In）、代码转换模板（Transaction）。
基于Annotation、Tag的单向代码生成方式，会很少采用。
他是项目的灵魂，Framework+代码转换摸板，他帮助项目生成了核心的代码，尤其是业务端（如EJB、数据库关联层）。
3.SA、高程：
根据Domain Model，转换为PSM.
在PSM级，根据模型驱动模板（Pattern Plug-In），生成业务组件类代码。如为实体生成Session Bean，生成Command模式的代码。
SA、高程，适当地手工调整好PSM，根据代码转换模板（Transaction），生成符合企业Framework的Java代码。如根据实体类，生成EJB或Hibernate；根据Session Bean等组件，生成客户端（Gui）需要的代码（JSF的ManageBean、Struts的Action或Swing的布局代码）。
具体语言技术、模式知识，是他们要把握的。SA懂技术，就更能把业务模型设计好。
这里，可以生成全部业务端（中间件层）代码，比如实体类、Session Bean、业务代理类。
假如需求变化，比如增减字段，修改Domain Model后，变化可以同步到Code.而且，不会覆盖Code中手工输入的部分。真正作到双向同步。
4.程序员：
在前期，辅助BA、SA，设计原型。根据客户需求，用快速开发工具，画出界面，模拟交互操作，但无须绑定到数据源。如，用JSF或Swing，画Gui界面。
从目前MDA工具和界面技术，完全靠工具自动生成Gui代码，无论是Swing或jsp，都不是很现实。所以，只需要用工具生成Gui代码框架就足够了。
而业务部分的代码，主要在中间件层，而中间件层是由工具生成。所以，Gui除了布局，只是简单地调用中间件的业务接口。所以，程序员的主要工作，就是实现界面，单元测试。
四、通过Rational Architect，实践基于MDA的快速开发
理论要实践。MDA的前途，是大家都迷惑的。那么，通过项目，先用Rational Architect来逐步实现；通过结果看，目前的MDA工具，到底可以作到什么程度。
1. 根据新项目的业务特点，调整中间层Framework.
2. 通过自定义的Pattern Plug-In，把实体类模型（E-R），转换成EJB3.0有关的PSM.主要生成细粒度的Session Bean.
3. 在PSM里，手工定义粗粒度Session Bean.
4. 通过自定义的Pattern Plug-In，为粗粒度Session Bean的业务接口，生成Command.
5. 通过自定义的Pattern Plug-In，为每个实体，生成Gui代码框架，先实现基于Swing的。
6. 当业务变更，只需要增减PIM的实体模型里的字段，就能同步更新到PSM.
7. 当业务逻辑变更，调整PSM中的Session Bean的方法的细节，与代码变更同步。
8. 当业务端变更，重新生成Command.程序员手工调整Gui以适应Command在接口细节上的变化。
原文地址：http://blog.csdn.net/fancyhf/archive/2006/03/11/621754.ASPx
