抽象并簡化模型
使得不同的利益關聯者協調工作
為不同解釋進行補充（不同觀眾/利益相關者）
提取關于特定關聯的相關信息
因此，將會用到什么類型的視圖以及什么時候用到它們是強烈依賴于哪個人正在使用和需要完成的相關任務。然而，視圖并不是軟件開發的銀彈，因為它們具體表達基本問題；它們內部及它們之間表現出對等數量的建模元素冗余。
要給出一個簡單例子，考慮我們有個設計（例如按照UML類圖的形式）的軟件開發案例和產品實現（例如，C++代碼）。類圖和代碼表述不同的視圖，用不同的方法表達相同或類似的信息。雖然，代碼可以從設計中自動產生，這種逼近是有限的，還必須多次加入一些信息。更糟糕的是，現在這些冗余的信息片斷必須保持一致――后者大多是手工活動。這樣，無論什么時候設計變更了，代碼就會變得不一致（反之亦然），我們要應用一些視圖調和活動找到產生的不一致并一再保證模型概念的完整性。
視圖不匹配和冗余
既然視圖是我們處理復雜性唯一有效手段，我們不能指望用某些較少冗余的事物來替代它們。我們需要視圖在任何給定的時間對軟件開發者不得不處理的信息總數進行分解�！斑@不是帶來復雜性的細節數量本身，而是我們不得不同時了解的細節的數量�！盵Siegfried 1996]
然而，冗余性是一個必需的不幸。這暗示我們需要某種鑒別和解決視圖之間不匹配的自動化活動的方法。這樣，我們所需要就是一些集成和分析視圖的框架形體。有趣的是，視圖不匹配問題可能的逼近方法是基于它特有的問題――冗余性。我們利用一套視圖之間的冗余性意味著一個視圖包含關于其它視圖并可用作約束該視圖的信息。這樣，我們使用冗余信息來檢驗視圖之間的一致性和完整性。
例如，如果我們使用一些體系結構模式的形態來構造系統（例如，分層風格），那么設計必須反映體系結構對立的約束。這意味著如果體系結構定義了三層結構，那么體系結構隱含地定義了處理中第一層不使用第二層而與第三層直接對話是不允許的。如果后來系統使用UML設計（例如，使用類和序列圖），那么設計元素之內的調用依賴要求與上述的體系結構約束一致。我們將在后面說明一個例子。
UML視圖描述 vs 集成
啟用視圖集成來確定和調和視圖要求兩個層次的集成――符號集成和語義集成。對于符號集成，意思是模型需要完整表達視圖的能力。語義集成通過定義什么信息可以交換以及怎樣交換作更進一步精煉。只有在什么和怎樣在確立之后，不一致性才可以確定。
統一建模語言（UML），像其他通用軟件系統開發模型一樣，只是不能很滿足上述語義集成。UML提供一個模型用于表達不同框圖的視圖來處理類、對象、活動、狀態、包及其它（參看圖 1 ）。然而，UML 不擅長集成他們。在UML視圖之間的關聯和依賴關系很少被捕獲。如果后者沒有完成，模型僅僅是松散耦合的或完全無關聯的視圖集。雖然UML及其元模型在細節上定義了單個視圖的符號和語義特征，視圖內關聯的獲取仍然是不夠的（在視圖之間只存在一些微弱形式的依賴關系，例如類和對象）。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
