建立了這個框架后，架構師通過幾次迭代對解決方案加以發展。每次迭代都合并額外的功能 — 發票、待交定單、親自訂購、電話訂購等等。在每種情況下，架構師都更新適當的抽象層次，然后將這些更新改進到物理實現層。
重訪抽象層次核心原則
讓我們對照核心抽象層次原則來測試我們的示例。
| • |
這些層次的數量和范圍是定義完善的：我們有四個不同的層次：公司黑盒子、系統黑盒子、系統內的邏輯設計以及物理實現。 |
| • |
每個層次內的多個視圖：在這個簡單示例中，我們在每個層次上展示了一個動態視圖和靜態視圖。 |
| • |
必須保持層次間的一致性：如果對域模型作出了更改，則更改也一定會影響到較低層次。舉例來說，如果零售商決定為其產品提供維護合同，分析師就會將MaintenanceContract 添加到域模型，并將其改進為其物理表現形式。對于維護大型系統來說，同步所有層次是很重要的。因為提交了增強請求，所以分析師執行對相應細節層次的影響評估。一些增強請求影響域層次（并且因此影響所有后續層次）。其他請求只影響物理層次。 |
擴展層次以支持企業解決方案
既然我們已經展示了帶有四個抽象層次的簡單示例，現在就讓我們擴展這個方法來支持 IT 企業的解決方案。圖 9 展示了一個 Rational 統一過程 (Rational Unified Process，RUP) 配置，它將項目產品組織到定義完善的抽象層次中。
表中的層次描述如下。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
