圖 5 描寫了對應的低層實現，它不只是解決用于圖 4 中的模式，而且也精煉其它的一些建模元素。頂部三個類對應用戶界面層，存貨系統可以通過存貨代理來訪問，倉庫可以類似地通過倉庫代理來訪問。要找出該視圖是否和先前的視圖一致，我們可以運用幾個集成技術。
首先，我們需要找出哪些模型元素互相對應（映射）。這有幾種技術可以應用，例如名字的相似性等等�？墒�，在該例子中模式的廣泛使用使我們能夠開發關于它們用于映射的知識。通過圖4中的高層設計我們明白幾個事實：
模板模式用于訂單行（OrderLine）
代理模式用于橋接訂單行（OrderLine）（產品）與存貨系統
代理模式用于使用Oracle 數據庫橋接訂單框架子系統
接口特征（例如，消費者類與訂單、付款、和消費者UI接口）
圖 6 結構化模式知識（改編自[Buschman et al. 1996]）
雖然從技術上講，最后一項并不是一個清楚定義的模式，然而它構成類配置的知識――這樣，接口特征可以看作模式，即使它們大部分只是領域模式。關于領域的模式知識如同預定義的模式（參看圖 6 ）一樣使我們現在可以推論建模信息的關系。映射圖 4 和圖 5 的任務被精簡為使用如圖 6 所論述的預定義結構化模式知識來確定上述模式和（接口）特征的位置。
用圖 6 作為指導，我們可以容易地確定模板模式（產品，隊列，以及產品隊列對應于訂單行（OrderLine））的對應。雖然，它也可以容易找到代理模式，怎樣能夠區分它們卻不夠清楚。注意到目標是使得計算機自動鑒別它們。要在后來做到這一點，我們可以使用上面討論的接口特征（模式）。想法是，至少存在一些映射或者能夠通過名稱相似性來建立。使用該額外信息它可能自動從Oracle模式區分存貨（Inventory）模式。
不幸的是，通過模式的映射仍然比上述例子可說明的要更困難一些。我們作了簡化的假定，就是模式的結構和行為是靜態的。雖然，通常模式不是那些精確定義的，并且我們需要它們更一般的描述。圖 5 表明這樣一個例子，倉庫代理模式看上去不象定義的那樣。然而，既然網絡是部分代理類，它就可以合并到代理類中，并且代理類繼承它所有的依賴關系（下一節的Rose/Architect將表達一個模型來這樣做）。
該映射技術的另一個問題是模式，在識別的時候，有時可能只是粗糙地指出它們的位置。例如，對應于隊列，產品，和產品隊列，訂單行隊列（OrderLine Queue）可以在低層框圖中找到。雖然這也是正確的，但是它丟失了同時在低層框圖中表示的組成訂單行（OrderLine）。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
