昨天下午收到电话了科诺的说是9月才能提供试用。（希望他们不是微软-__-#）
昨天把能搞到的资料都看了一遍下面放出对比。个人观点难免偏颇欢迎讨论。。
比较项目
科诺
上海普元
理念
面向业务处理，以系统工程、自动化工艺的理论为基础，追求软件开发全过程的改善
从技术开发层面上细化、以IDE的可视化为目标
系统总体结构
技术构架
J2EE
J2EE
技术复杂度(未试用，仅从文档)
低
高
开发习惯
实现传统手工开发过程自动化，对不能自动化的部分，并不改变原有的开发方式，而是提供辅助工具
在原有开发习惯的基础上可视化，并且深入到程序细节，工作量由手写代码转移到可视化编程
开放性
所有技术都使用国际标准
所有技术都使用国际标准
实现方式
开放式的源代码自动生成和基于工作流的应用系统组装
可视化集成开发环境
可维护性
具有优先级的多层二维配置方式，垂直维度实现平台、应用、客户二次开发的优先级分离；水平维度实现同层业务定义的优先级分离（没看懂）
没找到说明
项目管理
提供全套的开发方法论，如PRD等文档模板；集成了版本管理的自动编译技术（说的不错啊）
没找到说明
人才技术要求与人才培养
只要掌握了面向对象原理的技术人员，无论是java程序员，还是.net程序员，或其它如PB等开发人员，都可以在短时间内快速掌握大型J2EE架构系统的原理、程序结构，并能迅速成长为高级技术人才（那偶不是要失业（T.T））
需要j2ee开发者才能掌握和发挥其功能
应用系统实现
根据用户需求，自动生成大部分代码，对于不能自动生成的部分，用户可以通过手工代码扩展的方式达到目的；应用系统自动组装
通过可视化环境配置参数及构件，在集成环境下手写代码
特殊功能的实现
对于平台难以实现，或不能自动生成的特殊功能，可以通过传统的手工编写代码方式实现，并与系统无缝连接，不增加任何额外工作量，同时还可利用平台中的各种API
集成环境下手写代码
构件(业务组件)
原理
基于业务的组件概念，形象地实现了从现实生活中的业务对象到信息系统中的组件单元的映射关系，实现了业务组件大小的最优化
可视化编程的概念，类似于图解程序单元和技术组件，对于业务的分析、组合需要开发人员自己掌握
来源
基于大型系统的自动生成，按需定制而非万能组件（组件生成？）
基于同一种规则文档的手写构件
质量
按需定制的概念，可以适应不同行业、不同应用的需求变化；生成代码的质量总体优于手写代码
万能组件概念，如果应用环境不同，需要做大量的配置
复用性与质量控制
基于同一平台、同一开发工具的业务组件，以源代码的形式进行交换，组件提供者和使用者可以根据需要进行灵活调整和重新生成，保证组件的质量与重用性
以回收构件的形式扩大构件源，日本的构件联盟？
兼容性
可以使用任何符合J2EE规范的第三方组件，第三组件可以在任意一层(业务组件、程序模块、应用系统等)进行替换
没找到说明，应该是J2EE标准
应用组装
理念
工艺化的自动生产、自动组装技术，业务组件和流程自动连接，最大可能地减少手写代码量，并与集成技术要结合，实现不同系统的组装
可视化的、基于自动机的底层技术概念，细化了处理流程
工作流
面向业务的图形化流程描述和展现，可以实现业务人员的需求调查和沟通；符合WfMC标准
面向技术开发人员的自动机，更象程序流程，业务人员很难看明白
可扩展性
应用系统通过WEB界面或图形化工具调整业务处理流程，无需编码，多版本随时切换
没找到说明
代码生成
页面控制
按照定义的模板自动生成jsp源代码，用户可通过修改CSS和JSP代码的方式，灵活改变页面布局
基于TAG的手写jsp页面
完整性
一个业务组件所需要的各种层面(jsp/java/sql)都自动生成，并按基本业务逻辑连接，100%可运行
按业务自动机或可视化来表达中间层，数据库层、业务层、页面层手工编写代码（应该有API）
可扩展性
自动生成代码和手写代码隔离，自动生成代码可以无限多次生成而不影响手写代码质量
生成代码和手写代码没有明显界限（个人感觉）
集成功能
系统接口
支持本地集成和远程WEB集成，所有业务组件提供WSDL接口包装工具，所有生成的业务组件带有XML数据接口
没找到说明，应该可以做到相同功能
