模型驅動SOA幫助提高開發團隊效率

做過應用軟體開發的朋友們大多都熟悉傳統的開發生命週期：應用軟體首先從業務分析員畫在在紙上或者流程圖工具中的業務草圖開始，乙個個功能被定義出來；然後交到開發人員手裡，設計，編碼，組裝；接著應用軟體又交付業務分析員做測試；業務人員按照當初設計草圖勾勒的功能去測試，發現問題後報乙個

bug，提請開發人員修改**。反覆多次，最後交付的軟體很少有和設計

100%

契合的，大部分是業務人員與開發人員互相讓步的結果。由業務人員直接參與測試，還是比較理想的情況，多數開發過程，測試由專門的測試人員按照他們對業務設計的理解做測試，他們對業務的理解又會同業務分析員以及開發人員有所偏差。

可以發現，整個應用軟體的開發周期中，在交流溝通上，以及為糾正溝通產生的誤解，花費了大量的人力物力。為了解決溝通的問題，特別是業務人員和技術人員之間的溝通，軟體開發過程中引入了許多模型。

模型能夠在一定程度上對問題提供抽象，能夠作為不同領域之間有效交流的共通符號。

說到模型，就會想到常用的資料庫設計的

er模型，應用程式設計的

uml，以及一些其他一些業務流程模型。隨著軟體開發工具的不斷進步，許多模型只要能夠提供完備的需求描述，完全能夠直接產生應用的實現**，而且也能夠按照實現**利用逆向工程產生對應的模型。這樣的模型多數是來自於技術領域的模型，例如：

er模型和

uml中的模型。模型和**之間的雙向工程，極大的方便了應用系統的設計和維護。相對於改變**，對模型的更改更加迅速高效，而且避免手工編碼對模型的誤解。相對而言，來自於業務領域的模型基本上只能作為需求描述的工具，並不能直接對映到工作流程和業務系統的實現。而

soa的出現，讓這種情況得到改觀。

soa之所以成為業界的熱門議題，其中乙個重要的因素就是對應用系統的模組做出了更高層次的抽象，同時提供了面向業務和面向技術的方**。物件導向模型中物件層次的抽象——類、物件、屬性、事件，等等，是技術領域首次試圖通過模仿客觀世界的存在讓業務領域能夠更好理解應用系統。

soa把這種嘗試成功的推進了一步，通過更高層次的抽象，讓業務功能模組——或者稱作「服務」包含更多業務的因素，而把實現的技術細節完全隱藏在標準的介面介面之後。更高抽象的「服務」，正好契合了業務流程模型的抽象粒度。業務人員熟悉的模型，就能直接對映到工作流程和業務系統的實現。

所以，soa讓模型驅動的開發進入業務層次，業務人員而非技術人員成為這個層次上的創新主體。軟體開發的生命週期中，增加了「服務」組裝成復合應用

的環節，分工更加明確合理。業務分析人員有機會通過模型來直接產生需要的業務流程實現，減少和技術人員溝通的誤解。技術人員能夠專注特定的業務模組的實現，特別是對完全定義的介面的實現。模型驅動的開發遵循敏捷化開發的思路，在迴圈的原型建立和細化中，業務模型、物件模型和資料模型，等各個層次的模型不斷完備，直到能夠直接生成應用系統。而隨後的系統維護也變成了對模型的維護。應用系統的模型和實現之間的雙向工程進一步擴充套件到更高的業務流程層次，對業務系統的修改直接針對模型完成，高效，快捷，減少錯誤。

總之，模型驅動

soa憑藉更高層次的業務功能抽象，達成業務模型和業務系統實現的雙向工程，幫助提高開發團隊效率

模型驅動SOA幫助提高開發團隊效率

模型驅動SOA幫助提高開發團隊效率

模型驅動SOA幫助提高開發團隊效率

模型驅動開發

相關推薦