可以发现，整个应用软件的开发周期中，在交流沟通上，以及为纠正沟通产生的误解，花费了大量的人力物力。为了解决沟通的问题，特别是业务人员和技术人员之间的沟通，软件开发过程中引入了许多模型。模型能够在一定程度上对问题提供抽象，能够作为不同领域之间有效交流的共通符号。
说到模型，就会想到常用的数据库设计的ER模型，应用程序设计的UML，以及一些其他一些业务流程模型。随着软件开发工具的不断进步，许多模型只要能够提供完备的需求描述，完全能够直接产生应用的实现代码，而且也能够按照实现代码利用逆向工程产生对应的模型。这样的模型多数是来自于技术领域的模型，例如：ER模型和UML中的模型。模型和代码之间的双向工程，极大的方便了应用系统的设计和维护。相对于改变代码，对模型的更改更加迅速高效，而且避免手工编码对模型的误解。相对而言，来自于业务领域的模型基本上只能作为需求描述的工具，并不能直接映射到工作流程和业务系统的实现。而SOA的出现，让这种情况得到改观。
面向对象模型中对象层次的抽象——类、对象、属性、事件，等等，是技术领域首次试图通过模仿客观世界的存在让业务领域能够更好理解应用系统。SOA把这种尝试成功的推进了一步，通过更高层次的抽象，让业务功能模块——或者称作“服务”包含更多业务的因素，而把实现的技术细节完全隐藏在标准的接口界面之后。更高抽象的“服务”，正好契合了业务流程模型的抽象粒度。业务人员熟悉的模型，就能直接映射到工作流程和业务系统的实现。
所以，SOA让模型驱动的开发进入业务层次，业务人员而非技术人员成为这个层次上的创新主体。软件开发的生命周期中，增加了“服务”组装成复合应用(Composite Application)的环节，分工更加明确合理。业务分析人员有机会通过模型来直接产生需要的业务流程实现，减少和技术人员沟通的误解。技术人员能够专注特定的业务模块的实现，特别是对完全定义的接口的实现。模型驱动的开发遵循敏捷化开发的思路，在循环的原型创建和细化中，业务模型、对象模型和数据模型，等各个层次的模型不断完备，直到能够直接生成应用系统。而随后的系统维护也变成了对模型的维护。应用系统的模型和实现之间的双向工程进一步扩展到更高的业务流程层次，对业务系统的修改直接针对模型完成，高效，快捷，减少错误。
总之，模型驱动SOA凭借更高层次的业务功能抽象，达成业务模型和业务系统实现的双向工程，帮助提高开发团队效率。
文章来源于领测软件测试网 https://www.ltesting.net/
