圖 3 UML中的高層設計（包圖和依賴）
確定這些不匹配并沒有對他們的起因給出任何反饋。例如，是體系結構還是設計錯誤？表格 3 說明通過提升存貨系統到訂單框架同一個級別來解決上述所有不匹配而不會引入新的不匹配的可能方法。我們不相信實際的不匹配解決方法將徹底地自動完成。這種方法與先前的自我糾錯源代碼編譯器的嘗試相同，這種努力最后因為所包含的社會和技術的復雜性而失敗了�？墒�，我們相信提供給設計者不僅僅使用（潛在的）不匹配，而且用關于怎樣在處理不匹配以及理解它們這兩者高度有利的情況下解決它們。此外，它可能對發現處理具有更好選擇情形的技術非常有好處。我們將在[Egyed 1996]中更詳細地討論這種情形。
映射
圖 4 表明我們系統的另一個視圖，圖 3 的一個精煉。另外，該視圖可以對修訂的體系結構和高層設計都能進行校驗，然而，并沒有發現不匹配。該視圖用另外的設計模式例如模板【[2]】（Template）模式（通過<>構造型指定）和代理【[3]】（Proxy）模式（通過《Proxy》構造型指定）。我們將使用它們進一步探究模式在視圖集成中的價值。
圖 4 高層設計視圖使用UML類和包的精煉
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
