可以發現，整個應用軟件的開發周期中，在交流溝通上，以及為糾正溝通產生的誤解，花費了大量的人力物力。為了解決溝通的問題，特別是業務人員和技術人員之間的溝通，軟件開發過程中引入了許多模型。模型能夠在一定程度上對問題提供抽象，能夠作為不同領域之間有效交流的共通符號。
說到模型，就會想到常用的數據庫設計的ER模型，應用程序設計的UML，以及一些其他一些業務流程模型。隨著軟件開發工具的不斷進步，許多模型只要能夠提供完備的需求描述，完全能夠直接產生應用的實現代碼，而且也能夠按照實現代碼利用逆向工程產生對應的模型。這樣的模型多數是來自于技術領域的模型，例如：ER模型和UML中的模型。模型和代碼之間的雙向工程，極大的方便了應用系統的設計和維護。相對于改變代碼，對模型的更改更加迅速高效，而且避免手工編碼對模型的誤解。相對而言，來自于業務領域的模型基本上只能作為需求描述的工具，并不能直接映射到工作流程和業務系統的實現。而SOA的出現，讓這種情況得到改觀。
面向對象模型中對象層次的抽象——類、對象、屬性、事件，等等，是技術領域首次試圖通過模仿客觀世界的存在讓業務領域能夠更好理解應用系統。SOA把這種嘗試成功的推進了一步，通過更高層次的抽象，讓業務功能模塊——或者稱作“服務”包含更多業務的因素，而把實現的技術細節完全隱藏在標準的接口界面之后。更高抽象的“服務”，正好契合了業務流程模型的抽象粒度。業務人員熟悉的模型，就能直接映射到工作流程和業務系統的實現。
所以，SOA讓模型驅動的開發進入業務層次，業務人員而非技術人員成為這個層次上的創新主體。軟件開發的生命周期中，增加了“服務”組裝成復合應用(Composite Application)的環節，分工更加明確合理。業務分析人員有機會通過模型來直接產生需要的業務流程實現，減少和技術人員溝通的誤解。技術人員能夠專注特定的業務模塊的實現，特別是對完全定義的接口的實現。模型驅動的開發遵循敏捷化開發的思路，在循環的原型創建和細化中，業務模型、對象模型和數據模型，等各個層次的模型不斷完備，直到能夠直接生成應用系統。而隨后的系統維護也變成了對模型的維護。應用系統的模型和實現之間的雙向工程進一步擴展到更高的業務流程層次，對業務系統的修改直接針對模型完成，高效，快捷，減少錯誤。
總之，模型驅動SOA憑借更高層次的業務功能抽象，達成業務模型和業務系統實現的雙向工程，幫助提高開發團隊效率。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
