业务架构中间件与辅助开发平台的差异_Android, Python及开发编程讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  Android, Python及开发编程讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 3173 | 回复: 0   主题: 业务架构中间件与辅助开发平台的差异        下一篇 
赖文婷
注册用户
等级:少校
经验:1094
发帖:81
精华:0
注册:2012-11-5
状态:离线
发送短消息息给赖文婷 加好友    发送短消息息给赖文婷 发消息
发表于: IP:您无权察看 2012-11-9 23:41:27 | [全部帖] [楼主帖] 楼主

在整个软件开发项目的过程中,都要经历在软件需求分析、系统设计、系统实现的过程,即使我们采用了组件化的开发、面向对象的设计,还是会发现,分析设计人员、程序员和用户之间,仍然无法沟通的很好,应用系统在交付用户使用时,仍然离用户的真实意图比较远。这是因为,提出需求的用户和系统设计的技术人员看问题的角度不同。

用户是从业务的角度,提出应用软件是哪个职能范围的、有哪些应用模块、每个模块又有哪些子模块,这是一种基于业务对象的描述方法。而开发人员则是从技术的角度,架构是什么?数据库的结构是什么样的?表间关系是什么?业务逻辑如何编写?页面展现如何设计?这是传统的组件构件思路。所以,用户和开发人员之间沟通起来仍然很难,业务实现及业务调整都依然为软件开发项目带来很大的难度和不可控因素。

而对应与应用系统实现,软件开发平台为了解决这些问题,经历了语言级开发到辅助开发平台的升级,直到我们所提供的面向业务架构的中间件平台。

而辅助开发平台源自与语言级软件开发环境,是从软件项目框架和程序开发过程各环节的开发效率上增加了许多特色的工具,从而为开发团队、开发者提供了更为高效的开发工具和项目控制与组织管理的手段,最终为整个项目降低了开发成本,提高了开发效率,但这并未真正意义上解决上面的问题。

例如:基于软件辅助开发平台,我们依然遵循需求分析,数据库建模,业务逻辑建模,页面设计,调试跟踪,测试,发布等过程,但是在每个节点上辅助开发工具都会提供相应厂商所特有的可视化工具以减低过程的操作难度,提升开发效率。

我们从软件系统开发实现的过程来看,开发人员会按照调研的需求分析报告,按照数据库建模,业务逻辑建模,页面设计的过程对业务需求进行分层的计算机语言转化,然后再将业务逻辑与物理数据库、展现页面与业务逻辑之间建立映射关系,之后在开始跟踪调试,最终发布应用程序。在这整个过程中程序员会利用辅助开发平台的可视化工具进行配置和关联,去自动生成系统的70%-80%的代码,复杂业务逻辑仍需手工代码编写实现。这对开发人员来说确实减低了很大的开发工作量,具体体现在开发过程中的普遍性及通用性的工作量,细节性的复杂业务逻辑处理难度和工作量并没有得到改善,这大概会占20%-30%的代码量。

但是软件系统的并不是一成不变的,随着业务需求的升级,软件系统功能及业务处理必须进行同步的更新,例如数据结构上需要增加一个字段,这时就会涉及物理数据库的调整,也会涉及业务逻辑的调整和页面展现的调整等等,当然也包括各层面的映射关系的调整。这时不管是哪个方面的调整都会影响其他层面的设计,而且既可能是通过可视化工具自动生成的代码部分,也可能是自定义的代码部分,而这种虽然只是系统从1.01.01的升级,都需要我们调整这0.1的升级部分所涉及的三层调整,以此看来并不是20%80%的关系了,而是100%的调整。

而面向业务结构的中间件平台又是如何解决上述问题的呢?

业务架构平台是以业务对象建模为核心的业务中间件及其集成开发工具。在它的支持下,应用软件彻底实现业务驱动导向的软件开发模式,并实现应您所需,随时而变的应用系统。基于业务中间件平台,开发者只需要基于业务和管理的层面,而非技术的层面来理解、设计、构架和集成企业的信息系统(基于业务层面是指开发人员只需描述企业的组织机构、业务流程、业务信息、业务资源、业务逻辑、业务事件等业务内容,而不考虑技术层面的东西),就可以实现各类基于WEB的高层次的信息化应用。而且,用户可以随时在运行中重新定义或调整业务模型,从而达到使自己的信息系统完全贴近不断变化的业务需求,这也是灵动的价值体现。

在这样的平台里,开发者所关注的就是业务模型,在集成开发环境中通过对业务对象(BO的分析来设计描述模型,而业务模型的处理流程通过业务流程(BP来描述业务对象的逻辑关系,业务模型提交至中间件服务器后自动会生成标准应用系统的三层架构,自动建立关联映射关系。当业务对象调整时,只需要修正业务模型重新提交至服务器,服务器又自动修正应用系统中的每个层面,关联映射关系会自动关联。

通过以上我们可以看出,随着两大主流语言开发工具的发展,辅助开发平台的生存空间将会不断缩小,这主要源自各种辅助开发平台的初衷只是语言级开发工具的补充,事实上这是一厢情愿的做法,从计算机语言的发展趋势来看,它将是主流的语言开发工具的过度品,这种现象在微软.net架构的VS上已经有了较大的体现。而且我们通过对各种辅助开发平台的对比可以看出,其核心的差异主要体现为:一方面业务逻辑分解上的颗粒度粗细不同,组件、构件、服务……;另一方面所提供的工具的便捷性不同,可视化、图形化、向导模式、拖拽模式……;而这些差异特色都将会在主流语言的开发工具的逐步体现。

而业务架构平台则是在开发工具之上的业务模型描述工具,它与开发工具之间是分工关系,可以基于.net也可以基于J2EE,而且他会随着开发语言的发展而越来越强大,毕竟业务模型的建立永远是在系统开发设计实现之前。




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论