软件生存周期过程相关产品与规范的调研
2009-05-01 11:01
218 查看
关于软件过程、或者是软件生存周期领域内的工作流、过程规范、产品研究了差不多半年时间了。研究的主要是开源、开放、业界标准相关,有点肤浅的心得,概要如下 :-)
对软件过程支持环境而言:
Eclipse: EPF
比较成型的社区规模,没有深入研究。不过感觉 eclipse 下面的东西基本是比较难用的,而且社区开发进度令人担忧。
OMG: SPEM
规范就是规范,也只是规范。SPEM 的实现比较罕见,国内研究非常少,貌似中科院有个实现。国外关注也比较少,仍停留在理论上。规范,大而全啊....
IBM: Jazz
基于 Jazz 的 Concert 在产品功能上非常有参考价值,终归是 IBM 精心打造的。可惜的是不是开源的,对外来开发者比较封闭,实现细节看不到。总的说OSGi 的应用目前总是在大投入的前提下才能做的。
EmForge
处于快速开发阶段,基于 jBPM 3 实现的流程处理,设计比较糟糕,实现代码质量底下。不过有一定的参考价值。特别是 Spring 整合 jBPM、JSPWiki 等有借鉴的价值。
JIRA
非常成熟了,对开源项目提供免费支持。流程实现基于 OSWorkflow,不过 JIRA 修改了非常多的引擎实现,以支持其应用,在功能有很多可以参考的地方。
mingle
对于开发人员来说过于封闭(毕竟是纯商业性质,不像 Jazz 的半封闭....),不过对于敏捷团队支持需求有非常值得学习的地方。
对工作流引擎、语言而言:
jBPM 3
没有好的设计,作为客户代码的实现、设计者可以体会到其 APIs 的糟糕。从代码上可以看出设计者基本是修修改改,在前期版本上参考了非常多的理论,后期版本(3.2.3)基本是个四不象的东西,虽然提出了基于图的编程模型,但我认为这个是没有任何实际意义的。不就是个可视化流程设计环境与执行引擎么?但是,可以肯定的是作者让开源社区多了一种稳定的选择。
jBPM 4 / PVM
目前还在开发中,设计上比较成熟了,至少暴露给客户代码的 APIs 设计上比较合理了。可惜,PVM 是不是像作者、JBoss 吹得那样好,那样可行(全面兼容 BPEL),只有作者才有谱。从目前的实现上看,全新的 jPDL 仍然是 PVM 的重点.... 这个版本的 jPDL 确实设计非常优秀,通用性很好(Java、Bean shell、SQL、etc),但是,支持越多越好????
WS-BPEL / BPMN
还是那句话,规范就是规范。虽然 BPEL 主要针对的是服务编制,但从 sub-process 扩展、HumanTask、BPEL4People 上看,BPEL 是完全可以胜任工作流、BPM 的。可惜,扩展都是商业实现,要用得爽,钱跟上。BPMN 2.0 貌似是解决了到 BPEL 的变换问题,我还没有机会使用。
国内的一些解决方案
普元快速开发平台....买不起,我只看了工作流方面的设计,产品设计者确实功底深厚,理论扎实。不过类似目前比较惹人关注的是 fireflow 。其思想与实现不敢恭维....作者对 Petri 网理论的运用是有问题的,至少不是像作者说的那样基于“严格的形式化定义”,而且国外类似将“业务”与“引擎系统”分开的研究很多....Petri 网是可以解决问题,但要看怎么用了,如果是基于 Petri 网,一定要注意并发、选择的定义与实现。
题外话:
门户实现
Liferay 是值得看看源代码的,整合确实非常正宗,国外的应用确实值得我们国内开发者好好学习。
Google
相信研究的人不少,最近的 GAE(Google App Engine)对支持 Java 更是引起了我们这些 Java 开发人员对它的关注。Google 下的东西确实是值得看看,特别是暴露给客户的 APIs 的设计。
对软件过程支持环境而言:
Eclipse: EPF
比较成型的社区规模,没有深入研究。不过感觉 eclipse 下面的东西基本是比较难用的,而且社区开发进度令人担忧。
OMG: SPEM
规范就是规范,也只是规范。SPEM 的实现比较罕见,国内研究非常少,貌似中科院有个实现。国外关注也比较少,仍停留在理论上。规范,大而全啊....
IBM: Jazz
基于 Jazz 的 Concert 在产品功能上非常有参考价值,终归是 IBM 精心打造的。可惜的是不是开源的,对外来开发者比较封闭,实现细节看不到。总的说OSGi 的应用目前总是在大投入的前提下才能做的。
EmForge
处于快速开发阶段,基于 jBPM 3 实现的流程处理,设计比较糟糕,实现代码质量底下。不过有一定的参考价值。特别是 Spring 整合 jBPM、JSPWiki 等有借鉴的价值。
JIRA
非常成熟了,对开源项目提供免费支持。流程实现基于 OSWorkflow,不过 JIRA 修改了非常多的引擎实现,以支持其应用,在功能有很多可以参考的地方。
mingle
对于开发人员来说过于封闭(毕竟是纯商业性质,不像 Jazz 的半封闭....),不过对于敏捷团队支持需求有非常值得学习的地方。
对工作流引擎、语言而言:
jBPM 3
没有好的设计,作为客户代码的实现、设计者可以体会到其 APIs 的糟糕。从代码上可以看出设计者基本是修修改改,在前期版本上参考了非常多的理论,后期版本(3.2.3)基本是个四不象的东西,虽然提出了基于图的编程模型,但我认为这个是没有任何实际意义的。不就是个可视化流程设计环境与执行引擎么?但是,可以肯定的是作者让开源社区多了一种稳定的选择。
jBPM 4 / PVM
目前还在开发中,设计上比较成熟了,至少暴露给客户代码的 APIs 设计上比较合理了。可惜,PVM 是不是像作者、JBoss 吹得那样好,那样可行(全面兼容 BPEL),只有作者才有谱。从目前的实现上看,全新的 jPDL 仍然是 PVM 的重点.... 这个版本的 jPDL 确实设计非常优秀,通用性很好(Java、Bean shell、SQL、etc),但是,支持越多越好????
WS-BPEL / BPMN
还是那句话,规范就是规范。虽然 BPEL 主要针对的是服务编制,但从 sub-process 扩展、HumanTask、BPEL4People 上看,BPEL 是完全可以胜任工作流、BPM 的。可惜,扩展都是商业实现,要用得爽,钱跟上。BPMN 2.0 貌似是解决了到 BPEL 的变换问题,我还没有机会使用。
国内的一些解决方案
普元快速开发平台....买不起,我只看了工作流方面的设计,产品设计者确实功底深厚,理论扎实。不过类似目前比较惹人关注的是 fireflow 。其思想与实现不敢恭维....作者对 Petri 网理论的运用是有问题的,至少不是像作者说的那样基于“严格的形式化定义”,而且国外类似将“业务”与“引擎系统”分开的研究很多....Petri 网是可以解决问题,但要看怎么用了,如果是基于 Petri 网,一定要注意并发、选择的定义与实现。
题外话:
门户实现
Liferay 是值得看看源代码的,整合确实非常正宗,国外的应用确实值得我们国内开发者好好学习。
相信研究的人不少,最近的 GAE(Google App Engine)对支持 Java 更是引起了我们这些 Java 开发人员对它的关注。Google 下的东西确实是值得看看,特别是暴露给客户的 APIs 的设计。
相关文章推荐
- 软件生存周期过程相关产品与规范的调研
- 软件生存周期过程相关产品与规范的调研
- 网站产品移动化策略制定过程
- 产品开发过程(Jerry贡献)
- MYSQL存储过程:批量更新数据2(产品品牌)
- 华为软件编程规范学习(六)--函数、过程
- 肿瘤与癌症检测相关产品的生物信息分析
- Google C++编程风格指南(二)之函数的相关规范
- gvim配置及相关插件安装(过程详细,附图)
- 解析C++编程中异常相关的堆栈展开和throw()异常规范
- Mybaits的执行过程及相关组件的生命周期
- Google C++编程风格指南(三)之作用域的相关规范
- SAP开发技术相关的产品介绍
- 产品研发过程常见问题2:难以量化的需求开发与管理
- Google C++编程风格指南(四)之类的相关规范
- 产品经理做市场调研和数据分析的方法
- Android系统编译环境初始化时Product产品的import-nodes过程
- RAC安装过程中相关问题解决方法
- 科学应用产品调研
- Java内容仓库规范及产品介绍