软件开发的未来中程序员与客户的矛盾

               软件开发的未来中程序员与客户的矛盾

近期开发了套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在接口细节上的变化。

你可能感兴趣的:(bean,swing,session,ejb,开发工具,Delphi)