软件开发的未来,是MDA/MDD/面向模式/Plug-in IDE吗?[转]

软件开发的未来,是MDA/MDD/面向模式/Plug-in IDE吗?

一、问题:

1. 有快速的类似PBJ2EE开发工具吗?

2. 客户需求不确定、易变时,如何保证J2EE体系的开发效率?

 

近期开发了套EJB3.0+JSF的业务系统。从技术、开发时间等方面,开发人员是自信的。但是,老板和客户,却觉得开发效率、用户界面操作不够理想。

原因在于,老板和客户,认为应当有PBDelphi这样的快速开发工具,来快速开发复杂的J2EE的分布式系统。而采用JbuilderEclipse,和基于AnnotationTag的单向代码生成方式,开发效率仍然不能让他们满意,尤其是业务需求易变、不稳定的时候。

 

二、解决问题的方法,MDA是方向吗?

 

为了取悦老板和客户,便狂找是否有IDE能解决这个问题。最后,却在MDA处,朦胧地找到,应对易变和不确定的需求,高效开发J2EE这种复杂应用体系的软件的大致方向。

 

未来主流的开发方式和支持工具,肯定不是走PBDelphi的道路。而是走MDA/MDD(模型驱动和开发),Pattern Driven(模式驱动),支持PluginIDE的道路。

 

那些固定技术模式(业务+界面的组成)的开发工具(如PBDelphi),是不可能支持不同客户的独特业务需求和多种类的客户端界面。这就是Borland要出售IDE的内在原因。

 而Eclipse的前途,也在于其Plug-In的体系。

而采用MDA/MDD(模型驱动和开发)、Pattern Driven(模式驱动)、支持PluginIDE,企业就可以开发出自己的工具(IDE),根据业务,快速产生符合自己的Framework的代码。

 

所以,市面上的J2EE开发工具,才都不提供现成的组件,用固定的模式,实现象PB那样的开发方式。

 

三、MDA/MDDPattern Driven支持PluginIDE,怎样实现高效率的开发?

 

采用了MDA,项目组的结构,肯定要调整。简单说,就是贫富差距拉大,能者越重要,普通程序员越普通。

 

1BASA

只需要跟客户沟通,获取需求,确定功能,确定模型(Domain Model,或者E-R图),写需求功能文档。他们最多只需要UML画图(PIM层次),不需要深入技术细节。身份接近于“咨询师”,业务知识是他们的价值所在。

2.架构师:

根据SA的反馈,尽早确定技术方案,创建Framework

确定了前后端(BusinessGui)的Framework后,架构师根据MDA规范和具体工具,定义模型驱动模板(Pattern Plug-In)、代码转换模板(Transaction)。

基于AnnotationTag的单向代码生成方式,会很少采用。

他是项目的灵魂,Framework+代码转换摸板,他帮助项目生成了核心的代码,尤其是业务端(如EJB、数据库关联层)。

3SA、高程:

根据Domain Model,转换为PSM

PSM级,根据模型驱动模板(Pattern Plug-In),生成业务组件类代码。如为实体生成Session Bean,生成Command模式的代码。

SA、高程,适当地手工调整好PSM,根据代码转换模板(Transaction),生成符合企业FrameworkJava代码。如根据实体类,生成EJBHibernate;根据Session Bean等组件,生成客户端(Gui)需要的代码(JSFManageBeanStrutsActionSwing的布局代码)。

具体语言技术、模式知识,是他们要掌握的。SA懂技术,就更能把业务模型设计好。

这里,可以生成全部业务端(中间件层)代码,比如实体类、Session Bean、业务代理类。

如果需求变化,比如增减字段,修改Domain Model后,变化可以同步到Code。而且,不会覆盖Code中手工输入的部分。真正作到双向同步。

4.程序员:

在前期,辅助BASA,设计原型。根据客户需求,用快速开发工具,画出界面,模拟交互操作,但无须绑定到数据源。如,用JSFSwing,画Gui界面。

从目前MDA工具和界面技术,完全靠工具自动生成Gui代码,无论是SwingJsp,都不是很现实。所以,只需要用工具生成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

posted on 2008-06-25 15:24  Neo0820  阅读(717)  评论(0编辑  收藏  举报

导航