抽象并简化模型
使得不同的利益关联者协调工作
为不同解释进行补充（不同观众/利益相关者）
提取关于特定关联的相关信息
因此，将会用到什么类型的视图以及什么时候用到它们是强烈依赖于哪个人正在使用和需要完成的相关任务。然而，视图并不是软件开发的银弹，因为它们具体表达基本问题；它们内部及它们之间表现出对等数量的建模元素冗余。
要给出一个简单例子，考虑我们有个设计（例如按照UML类图的形式）的软件开发案例和产品实现（例如，C++代码）。类图和代码表述不同的视图，用不同的方法表达相同或类似的信息。虽然，代码可以从设计中自动产生，这种逼近是有限的，还必须多次加入一些信息。更糟糕的是，现在这些冗余的信息片断必须保持一致――后者大多是手工活动。这样，无论什么时候设计变更了，代码就会变得不一致（反之亦然），我们要应用一些视图调和活动找到产生的不一致并一再保证模型概念的完整性。
视图不匹配和冗余
既然视图是我们处理复杂性唯一有效手段，我们不能指望用某些较少冗余的事物来替代它们。我们需要视图在任何给定的时间对软件开发者不得不处理的信息总数进行分解。“这不是带来复杂性的细节数量本身，而是我们不得不同时了解的细节的数量。”[Siegfried 1996]
然而，冗余性是一个必需的不幸。这暗示我们需要某种鉴别和解决视图之间不匹配的自动化活动的方法。这样，我们所需要就是一些集成和分析视图的框架形体。有趣的是，视图不匹配问题可能的逼近方法是基于它特有的问题――冗余性。我们利用一套视图之间的冗余性意味着一个视图包含关于其它视图并可用作约束该视图的信息。这样，我们使用冗余信息来检验视图之间的一致性和完整性。
例如，如果我们使用一些体系结构模式的形态来构造系统（例如，分层风格），那么设计必须反映体系结构对立的约束。这意味着如果体系结构定义了三层结构，那么体系结构隐含地定义了处理中第一层不使用第二层而与第三层直接对话是不允许的。如果后来系统使用UML设计（例如，使用类和序列图），那么设计元素之内的调用依赖要求与上述的体系结构约束一致。我们将在后面说明一个例子。
UML视图描述 vs 集成
启用视图集成来确定和调和视图要求两个层次的集成――符号集成和语义集成。对于符号集成，意思是模型需要完整表达视图的能力。语义集成通过定义什么信息可以交换以及怎样交换作更进一步精炼。只有在什么和怎样在确立之后，不一致性才可以确定。
统一建模语言（UML），像其他通用软件系统开发模型一样，只是不能很满足上述语义集成。UML提供一个模型用于表达不同框图的视图来处理类、对象、活动、状态、包及其它（参看图 1 ）。然而，UML 不擅长集成他们。在UML视图之间的关联和依赖关系很少被捕获。如果后者没有完成，模型仅仅是松散耦合的或完全无关联的视图集。虽然UML及其元模型在细节上定义了单个视图的符号和语义特征，视图内关联的获取仍然是不够的（在视图之间只存在一些微弱形式的依赖关系，例如类和对象）。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
