做过应用软件开发的朋友们大多都熟悉传统的开发生命周期：应用软件首先从业务分析员画在在纸上或者流程图工具中的业务草图开始，一个个功能被定义出来；然后交到开发人员手里，设计，编码，组装；接着应用软件又交付业务分析员做测试；业务人员按照当初设计草图勾勒的功能去测试，发现问题后报一个Bug，提请开发人员修改代码。反复多次，最后交付的软件很少有和设计100%契合的，大部分是业务人员与开发人员互相让步的结果。由业务人员直接参与测试，还是比较理想的情况，多数开发过程，测试由专门的测试人员按照他们对业务设计的理解做测试，他们对业务的理解又会同业务分析员以及开发人员有所偏差。
可以发现，整个应用软件的开发周期中，在交流沟通上，以及为纠正沟通产生的误解，花费了大量的人力物力。为了解决沟通的问题，特别是业务人员和技术人员之间的沟通，软件开发过程中引入了许多模型。模型能够在一定程度上对问题提供抽象，能够作为不同领域之间有效交流的共通符号。
说到模型，就会想到常用的数据库设计的ER模型，应用程序设计的UML，以及一些其他一些业务流程模型。随着软件开发工具的不断进步，许多模型只要能够提供完备的需求描述，完全能够直接产生应用的实现代码，而且也能够按照实现代码利用逆向工程产生对应的模型。这样的模型多数是来自于技术领域的模型，例如：ER模型和UML中的模型。模型和代码之间的双向工程，极大的方便了应用系统的设计和维护。相对于改变代码，对模型的更改更加迅速高效，而且避免手工编码对模型的误解。相对而言，来自于业务领域的模型基本上只能作为需求描述的工具，并不能直接映射到工作流程和业务系统的实现。而SOA的出现，让这种情况得到改观。
SOA之所以成为业界的热门议题，其中一个重要的因素就是对应用系统的模块做出了更高层次的抽象，同时提供了面向业务和面向技术的方法论。面向对象模型中对象层次的抽象——类、对象、属性、事件，等等，是技术领域首次试图通过模仿客观世界的存在让业务领域能够更好理解应用系统。SOA把这种尝试成功的推进了一步，通过更高层次的抽象，让业务功能模块——或者称作“服务”包含更多业务的因素，而把实现的技术细节完全隐藏在标准的接口界面之后。更高抽象的“服务”，正好契合了业务流程模型的抽象粒度。业务人员熟悉的模型，就能直接映射到工作流程和业务系统的实现。
所以，SOA让模型驱动的开发进入业务层次，业务人员而非技术人员成为这个层次上的创新主体。软件开发的生命周期中，增加了“服务”组装成复合应用(Composite Application)的环节，分工更加明确合理。业务分析人员有机会通过模型来直接产生需要的业务流程实现，减少和技术人员沟通的误解。技术人员能够专注特定的业务模块的实现，特别是对完全定义的接口的实现。模型驱动的开发遵循敏捷化开发的思路，在循环的原型创建和细化中，业务模型、对象模型和数据模型，等各个层次的模型不断完备，直到能够直接生成应用系统。而随后的系统维护也变成了对模型的维护。应用系统的模型和实现之间的双向工程进一步扩展到更高的业务流程层次，对业务系统的修改直接针对模型完成，高效，快捷，减少错误。
总之，模型驱动SOA凭借更高层次的业务功能抽象，达成业务模型和业务系统实现的双向工程，帮助提高开发团队效率发表于 @ 2007年07月23日 11:05:00|评论(loading...)|编辑