圖 1 也表明問題的另一個方面――那就是擴展UML以表達新的和外部概念（例如，風格和模式）。例如，怎樣才能在UML中使用更高級的模式例如分層的體系結構模式【[1]】或代理設計模式？在UML中，我們需要再次區分僅僅表述模式和完整集成它們。
圖 1 UML中表示法 vs. 集成
視圖集成框架
視圖集成的主要的障礙是缺乏完好定義的（工程的）模型基礎。視圖經常使用迥然不同的表示信息方法，而這使得確定它們在哪里和怎樣出現重疊非常困難。這樣，組合和比較視圖的任務經常是手工的而且潛伏著錯誤的。集成框架的目標是要補償鑒別和解決體系結構不匹配自動化輔助手段的不足。
如前面簡短的敘述，這樣做的時候，我們的框架需要處理什么信息和怎樣進行交換。我們在那里寫到什么信息可被交換以及它怎么能交換的判斷需求。在我們的視圖集成框架中，我們提到映射和變換這兩個活動。我們也說只有在這些活動定義之后，才能夠嘗試鑒別不一致性。后者我們稱之為分化（參看圖 2 ）。
圖 2 在高層次式樣上描寫我們的視圖集成框架。在那里，系統模型用于表達軟件系統的知識基礎。軟件開發者使用視圖增加新的數據到系統模型并且復審現有數據（視圖綜合）。對于UML，系統模型可能被看作通過UML設計工具（例如Rational Rose）完成的UML模型和視圖綜合。
系統模型和視圖綜合兩者交互影響就是視圖分析。一旦加入新的信息，它就可以針對系統模型進行驗證以保證其概念完整性。圖 2 表示視圖分析可以怎樣進一步細分為其上述三個主要活動：
文章來源于領測軟件測試網 http://www.kjueaiud.com/
