不易工程化部分，或說控制部分，是以自動機為基礎的，有人干脆稱之為業務引擎，在CMM中沒有討論到一點。容易理解業務引擎可以使得業務規則"動"起來，從而得到結果。這種方法在目前的軟件工程中引起了越來越廣泛的重視，因此各種各樣的業務引擎被采用和商品化。這些業務引擎常被稱之為"中間件"。
如果把某程序開發語言定義為源語言，則業務引擎可以看作為（meta-Interpreter）元解釋器，并且業務邏輯可以看作為元程序。理論研究表明，采用元結構的軟件有更好的可控性。
5.2 軟件結構
當一個軟件的說明成份和控制成份被分離之后，軟件的結構也一定發生變化。因為在原來的軟件中說明和控制成份是相混合的。變化后的軟件結構我們稱之為分層軟件結構（或簡稱分層結構），如下圖所示：
從上圖可以看出數據表示已不再是軟件的核心，并且數據的變化事實上成為了業務流程的"副作用"（Side-effect）。
在復雜信息系統中，業務邏輯對應實體對象可能不只一種，例如，ERP中的人事和生產管理，其中人事管理所對應的實體對象是員工，而生產管理所對應的實體對象是產品。如果用不同的業務引擎來處理不同實體對象的業務規則，并且，使得它們之間是松耦合的，則構成了一個多agents系統結構。采用這樣的結構事實上使得復雜業務邏輯被分解了。無疑這可以降低軟件復雜程度，從而降低開發風險。
CMM的一個基本假設是，用戶的需求是確定的，并且經過軟件工程人員的努力是可以搞清楚的。在這種情況下，以過程控制保證軟件的質量，從而完成軟件工程。但是這一假定在大多數情況下是不成立的。因為，在通常的情況下，用戶無法敘述清楚他們的需求，并且僅僅*人?quot;努力"也不能保證理解用戶敘述清楚的需求，特別是，用戶的需求本身就是在變化的，因此通常需求是不確定的。對于需求不確定的軟件工程，僅僅從過程管理的角度，無論如何也是無法解決的問題。
對于不確定的軟件需求，軟件的結構應當支持這種不確定性。軟件的分層和代理結構能夠比較好地支持這種不確定性。事實上所有的軟件都在一個進化的過程中，確定只是相對的，因此支持不確定性的軟件結構也可稱為可進化的軟件結構�？蛇M化的軟件結構是提升軟件質量的關鍵技術。
5.3 開發平臺
如果人們可以把對軟件開發的主要注意力集中在對業務邏輯的理解和描述上，而不是集中在所采用的計算機實現技術上，則顯然可以大大地降低軟件的開發的難度，并且使得軟件開發過程容易做到透明化。但是軟件無論如何是與計算機技術相關的。為解決這一問題可研究一組引擎（中間件）來適當地屏蔽計算機技術相關性，這一組引擎我們稱之為開發平臺，其中包括：
●操作控制引擎
Form調度自動機，每個Form為最小調度單位，它的輸入是Form屬性描述和Form之間的調度關系和條件等。
●對象狀態引擎
對象狀態推導自動機，它根據對象狀態變化的規則集自動演繹對象的狀態變化。它的輸入為對象屬性描述，狀態變化規則集，當前所發生的事件等。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
