模式和抽象
單獨的介于圖 4 中的高層視圖以及圖 5 的低層視圖之間的映射不足以確定不匹配。例如，在圖 4 可以看到付款是消費者的一部分，然而在圖 5 中這種關系更加復雜。為校驗兩個圖是按相同的方法討論關系，我們可以使用Rose/Architect概念。
Rose/Architect [Egyed-Kruchten 1999]認為模式分組為三類，并且使用及物關系替換為更簡單的模式。在類圖中，及物關系論述那些不直接連結的類之間的關系。然而一個關系可以通過其他類（例如helper類）存在，它在它們之間形成了一個橋（例如，假設上述例子中付款和消費者并不直接相連，但是它仍然通過helper（幫助者）類事務（transaction）和賬目（account）類給出關系）。這樣，如果發現某些公式，它們可以按有效精度導出及物關系，那么，可以按工具形式提供簡化和抽象類圖方面的自動支持。這將允許設計者通過刪除“幫助者類”從現有的、更細節化的模型中抽象出重要的類，這樣將使得它們更進一步描寫和分析類之間中間關系，即使這些類分散在整個模型的不同位置（例如，不同的框圖，或者在不同的包和名字空間中）。
RA提供這種機制而[Egyed-Kruchten 1999]詳細地討論了這種技術。當前，RA模型由大概80條抽象規則組成。例如規則4，論述了一個類被第二個類泛化（繼承的反義詞）并且父類是第三個類的聚集（部分）（參看圖 7 ）的情形。這種三類模式現在可以刪除中間類來簡化并創建一個從第一個類到第三個類的及物關系（在該例子中的一個聚集）。下面的RA模型討論這些規則以及必須怎樣應用它們來產出有效的結果。
圖 7 表明我們的低層設計視圖（圖 5 ）中的付款給消費者關系案例的RA精煉步驟。在應用兩個規則（分別是規則4和規則17）之后我們得到一個具有兩個類以及它們之間依賴關系的簡化模式。如果這也可以對其他類以及在映射小節中討論的模式【[4]】進行處理，我們就可以自動產生更高層次的類圖（圖 8 ）。產生的這個抽象視圖現在就可以與我們在圖 4 中描寫的原始的更高層次類圖直接進行比較了。這樣，通過模式的使用我們可以轉換視圖以便它以非常類似其它視圖的方式表達信息。比較視圖現在可以簡單地使用一些圖形比較算法（也可參看上面所說的分化）的形式來完成。圖 8 也顯示了可能的不一致性。例如，從付款到訂單的聚集丟失了，存貨系統對Oracle數據庫的調用沒有使用網絡部件，以及一些鏈接是不同的（例如，使用關聯鏈接而不是依賴鏈接）。在變換（抽象）之后，這些不匹配可以容易地識別。
必須注意的是抽象沒有徹底地自動完成。雖然，模式有助于在某些建模信息之間確定映射和變換，它們不能完全自動化該過程。因此，需要一些手工輔助來導出圖 8 。而且，RA工具當前只能對付如圖 7 討論的簡單的三類模式而不能處理圖 6 中討論的更加高級的設計模式。這樣，由于該作業的緣故，抽象設計模式（例如代理）由手工完成。然而，一旦更加復雜的設計模式概念體現到RA中，這種抽象可以是自動的。對此，設計模式需要按照它們的輸入（源）和目的以及它們的訪問點進行討論。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
